One of my servers at work leads a very light life: it is our main backups server (so it has a I/O spike at night, with little CPU involvement) and has some minor services running (i.e. a couple of Tor relays and my personal email server - yes, I have the authorization for it 😉). It is a very stable machine… But today I was surprised:

As I am about to migrate it to Debian 13 (Trixie), naturally, I am set to reboot it. But before doing so:

$ w
 12:21:54 up 1048 days, 0 min,  1 user,  load average: 0.22, 0.17, 0.17
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
gwolf             192.168.10.3     12:21           0.00s  0.02s sshd-session: gwolf [priv]

Wow. Did I really last reboot this server on December 1 2022?

(Yes, I know this might speak bad of my security practices, as there are several kernel updates I never applied, even having installed the relevant packages. Still, it got me impressed 😉)

Debian. Rock solid.

14 Oct 2025 6:22pm GMT

The seventeenth release of the qlcal package arrivied at CRAN today, once again following a QuantLib release as 1.40 came out this morning.

qlcal delivers the calendaring parts of QuantLib. It is provided (for the R package) as a set of included files, so the package is self-contained and does not depend on an external QuantLib library (which can be demanding to build). qlcal covers over sixty country / market calendars and can compute holiday lists, its complement (i.e. business day lists) and much more. Examples are in the README at the repository, the package page, and course at the CRAN package page.

This releases mainly synchronizes qlcal with the QuantLib release 1.40. Only one country calendar got updated; the diffstat looks larger as the URL part of the copyright got updated throughout. We also updated the URL for the GPL-2 badge: when CRAN checks this, they always hit a timeout as the FSF server possibly keeps track of incoming requests; we now link to version from the R Licenses page to avoid this.

Changes in version 0.0.17 (2025-07-14)

• Synchronized with QuantLib 1.40 released today

• Calendar updates for Singapore

• URL update in README.md

Courtesy of my CRANberries, there is a diffstat report for this release. See the project page and package documentation for more details, and more examples.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

14 Oct 2025 5:55pm GMT

Debian Contributions: 2025-09

Contributing to Debian is part of Freexian's mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

Updating old Debian Printing software to meet C23 requirements, by Thorsten Alteholz

The work of Thorsten fell under the motto "gcc15". Due to the introduction of gcc15 in Debian, the default language version was changed to C23. This means that for example, function declarations without parameters are no longer allowed. As old software, which was created with ANSI C (or C89) syntax, made use of such function declarations, it was a busy month. One could have used something like -std=c17 as compile flags, but this would have just postponed the tasks. As a result Thorsten uploaded modernized versions of ink, nm2ppa and rlpr for the Debian printing team.

Work done to decommission packages.qa.debian.org, by Raphaël Hertzog

Raphaël worked to decommission the old package tracking system (packages.qa.debian.org). After figuring out that it was still receiving emails from the bug tracking system (bugs.debian.org), from multiple debian lists and from some release team tools, he reached out to the respective teams to either drop those emails or adjust them so that they are sent to the current Debian Package Tracker (tracker.debian.org).

rebootstrap uses *-for-host, by Helmut Grohne

Architecture cross bootstrapping is an ongoing effort that has shaped Debian in various ways over the years. A longer effort to express toolchain dependencies now bears fruit. When cross compiling, it becomes important to express what architecture one is compiling for in Build-Depends. As these packages have become available in "trixie", more and more packages add this extra information and in August, the libtool package gained a gfortran-for-host dependency. It was the first package in the essential build closure to adopt this and required putting the pieces together in rebootstrap that now has to build gcc-defaults early on. There still are hundreds of packages whose dependencies need to be updated though.

Miscellaneous contributions

• Raphaël dropped the "Build Log Scan" integration in tracker.debian.org since it was showing stale data for a while as the underlying service has been discontinued.
• Emilio updated pixman to 0.46.4.
• Emilio coordinated several transitions, and NMUed guestfs-tools to unblock one.
• Stefano uploaded Python 3.14rc3 to Debian unstable. It's not yet used by any packages, but it allows testing the level of support in packages to begin.
• Stefano upgraded almost all of the debian-social infrastructure to Debian "trixie".
• Stefano published the sponsorship brochures for DebConf 26.
• Stefano attended the Debian Technical Committee meeting.
• Stefano uploaded routine upstream updates for a handful of Python packages (pycparser, beautifulsoup4, platformdirs, pycparser, python-authlib, python-cffi, python-mitogen, python-resolvelib, python-super-collections, twine).
• Stefano reviewed and responded to DebConf 25 feedback.
• Stefano investigated and fixed a request visibility bug in debian-reimbursements (for admin-altered requests).
• Lucas reviewed a couple of merge requests from external contributors for Go and Ruby packages.
• Lucas updated some ruby packages to its latest upstream version (thin, passenger, and puma is still WIP).
• Lucas set up the build environment to run rebuilds of reverse dependencies of ruby using ruby3.4. As an alternative, he is looking for personal repositories provided by Debusine to perform this task more easily. This is the preparation for the transition to ruby3.4 as the default in Debian.
• Lucas helped on the next round of the Outreachy internship program.
• Helmut sent patches for 30 cross build failures and responded to cross building support questions on the mailing list.
• Helmut continued to maintain rebootstrap. As gcc version 15 became the default, test jobs for version 14 had to be dropped. A fair number of patches were applied to packages and could be dropped.
• Helmut resumed removing RC-buggy packages from unstable and sponsored a termrec upload to avoid its deletion. This work was paused to give packages some time to migrate to "forky".
• Santiago reviewed different merge requests created by different contributors. Those MRs include a new test to build reverse dependencies, created by Aquila Macedo as part of his GSoC internship; restore how lintian was used in experimental, thanks Otto Kekäläinen; and the fix by Christian Bayle to support again extra repositories in deb822-style sources, whose support was broken with the move to sbuild+unshare last month.
• While doing some new upstream release updates, thanks to Debusine's reverse dependencies autopkgtest checks, Santiago discovered that paramiko 4.0 will introduce a regression in libcloud by the drop of support for the obsolete DSA keys. Santiago finally uploaded to unstable both paramiko 4.0, and a regression fix for libcloud.
• Santiago has taken part in different discussions and meetings for the preparation of DebConf 26. The DebConf 26 local team aims to prepare for the conference with enough time in advance.
• Carles kept working on the missing-package-relations and reporting missing Recommends. He improved the tooling to detect and report bugs creating 269 bugs and followed up comments. 37 bugs have been resolved, others acknowledged. The missing Recommends are a mixture of packages that are gone from Debian, packages that changed name, typos and also packages that were recommended but are not packaged in Debian.
• Carles improved the missing-package-relations to report broken Suggests only for packages that used to be in Debian but are removed from it now. No bugs have been created yet for this case but identified 1320 of them.
• Colin spent much of the month chasing down build/test regressions in various Python packages due to other upgrades, particularly relating to pydantic, python-pytest-asyncio, and rust-pyo3.
• Colin optimized some code in ubuntu-dev-tools (affecting e.g. pull-debian-source) that made O(1) HTTP requests when it could instead make O(n).
• Anupa published Micronews as part of Debian Publicity team work.

14 Oct 2025 12:00am GMT

I have pushed and tagged the first release candidate, v2.0.0-rc0, of FSet version 2! I'm keeping it in a GitLab Merge Request (MR) for the moment, but I am very much hoping to get some FSet users to try it out and give me some feedback.

One major change is that sets and maps now use the CHAMP implementations by default. This change should be transparent as long as:

• you haven't written any complex custom compare methods (if all the method does is call compare-slots, it can be easily converted to use the new macro define-equality-slots), and
• you don't care about the ordering of your sets and maps, or in the cases where you do care, you've used the new custom-ordering features.

The second major change is to the defaulting behavior of maps and seqs. FSet 1 uses a "default default" of nil, meaning that if you don't supply an explicit default when creating a map or seq, its default is nil. The default is returned on a map lookup when the supplied key is not in the map; it is returned on a seq lookup when the supplied index is not in bounds (the bounds being 0 up to, but excluding, the size of the seq).

In FSet 2, there is no default default. If you don't supply an explicit default, the map or seq has no default, and an access attempt will signal an error instead in these cases. So, migrating your code to FSet 2 will probably require a little debugging - running your test suite, noting when you get one of the new errors, finding the form where the map or seq involved is initially created, and adding :default nil to the form or wrapping it in (with-default ... nil).

Examples:

But, there's good news! You don't have to convert your code if you don't want to. Merely loading FSet 2 doesn't expose your code to these changes; the behavior of names exported from package fset has mostly not changed. Instead, I've added a new package, fset2, that exports its own versions of the names with new behavior. So, to use FSet 2, change :use fset in your defpackage form(s) to :use fset2.

(There is one change you will see even if you don't use the new package, having to do with the printing of map and seq defaults. Previously, a nil default would not be printed explicitly; now, it will be, so you'll see things like ##{| (a 3) |}/NIL and #[ 3 1 4 ]/NIL.)

For complete details of all changes in this release, see the MR.

So, for anybody who wants to help me out, here's what I ask:

1. Clone this repo (or this one), and in your copy, do: git checkout fset2.
2. If you didn't clone it in ~/quicklisp/local-projects/, arrange for Quicklisp to find this copy, in whatever way you do that (e.g. by pushing the directory pathname onto asdf:*central-registry*).
3. Recompile your client code and test it. If anything doesn't work, please let me know immediately.
4. Go into the :use clause of your defpackage form(s) and change fset to fset2.
5. Recompile your client code again, and test it again. This time you may need to make some changes, as discussed above. Let me know how much trouble you have, whether a little or a lot (and especially let me know if you give up). You can post comments in the MR, or in this GitHub issue.

Again, this is a release candidate, not yet a release. I've tested it pretty thoroughly, but there could still be bugs. OTOH, if there's something in particular you don't like about it, I may be more willing to make changes than I will be after it's released.

Share and enjoy!

11 Oct 2025 7:58am GMT

I deployed three additional AI powered apps.

• Common Lisp Coach - enter your Lisp code and get concrete suggestions for improvement.
• LLM Prompt Refiner - enter a lame LLM prompt and get a much better one.
• LLM System Instruction Refiner - enter a vague System Instruction and get a much better one.

10 Oct 2025 4:46pm GMT

I have improved my trace-macroexpand system so you can say, in effect 'trace the expansion of only the macros in the interface to a given package'. This is a fairly useful thing.

Tracing macroexpansion in Common Lisp is a pretty useful thing to be able to do, in my experience. It is completely possible to do this in portable CL via *macroexpand-hook*: you simply put your tracing function on this hook, making sure it actually does expand the macro. trace-macroexpand does just this, and lets you specify which macros you want to be traced.

It has always allowed you to say 'trace all macros whose home package is this package'. That's less useful than you might think:

• it means that not only macros whose names are exported from the packqge are traced, but any macros in its guts are also traced, which generally a user of the package should not be interested in;
• it doesn't trace macros which are exported from a package but whose home package is not that package.

Very often the second thing is exactly what you want: you want to be able to say 'let me see the expansion of macros in the public interface to this package, but I don't care about the internal details of it'.

It can now do exactly that.

trace-macro-package now takes a list of package specifiers. If a package specifier is a list of one or more other package specifiers, then it changes their meaning to be 'trace the exports of these packages only'.

Here is an example:

> (find-symbol "FOR" :org.tfeb.star)
for
:external

> (symbol-package *)
#<The ORG.TFEB.STAR/IMPL package, 188/512 internal, 6/16 external>

> (trace-macroexpand t)
nil

> (setf *trace-macroexpand-per-line-prefix* "| ")
"| "

> (trace-macro-package :org.tfeb.star)
("ORG.TFEB.STAR")

> (for ((_ (in-naturals 10))))
nil

> (untrace-macro-package :org.tfeb.star)
nil

> (trace-macro-package '(:org.tfeb.star))
(("ORG.TFEB.STAR"))

> (for ((_ (in-naturals 10))))
| (for (#))
|  -> (multiple-value-bind (#:<v>) 0 ...)
nil

As well as this, both trace-macro-package and untrace-macro-package now canonicalise the specifiers they are given, which means, for instance that (trace-macro-package '("FOO" "BAR")) is exactly the same as (trace-macro-package '("FOO") '("BAR")): this means that things like

> (trace-macro-package '("FOO" "BAR"))

[...]

> (untrace-macro-package '("FOO"))

will work properly.

This change is in version 10.9.0 of the TFEB.ORG Lisp hax, git repo.

10 Oct 2025 10:39am GMT

Proposals for stands for FOSDEM 2026 can now be submitted! FOSDEM 2026 will take place at the ULB on the 31st of January and 1st of February 2026. As has become traditional, we offer free and open source projects a stand to display their work to the audience. You can share information, demo software, interact with your users and developers, give away goodies, sell merchandise or accept donations. All is possible! We offer you: One table (180x80cm) with a set of chairs and a power socket Fast wireless internet access You can choose if you want the spot for the舰

02 Oct 2025 10:00pm GMT

Proposals for developer rooms and main track talks for FOSDEM 2026 can now be submitted! FOSDEM offers open source and free software developers a place to meet, share ideas and collaborate. Renowned for being highly developer-oriented, the event brings together some 8000+ geeks from all over the world. The twenty-sixth edition will take place on Saturday 31st January and Sunday 1st February 2026 at the usual location, ULB Campus Solbosch in Brussels. Developer Rooms Developer rooms are assigned to self-organising groups to work together on open source and free software projects, to discuss topics relevant to a broader subset of舰

20 Sep 2025 10:00pm GMT

It's that time again! FOSDEM 2026 will take place on Saturday 31st of January and Sunday 1st of February 2026. Further details and calls for participation will be announced in the coming days and weeks.

17 Sep 2025 10:00pm GMT