Debian Related Work

• Uploaded cage 0.3.1-1 to unstable
• Uploaded swaylock 1.8.6-1 to unstable
• Uploaded scdoc 1.11.5-1 to unstable
• Uploaded xdg-desktop-portal-wlr 0.8.4-1 to unstable
• Uploaded swayimg 5.5-1 to unstable
• Uploaded fyi 1.0.4-2 to unstable
• Uploaded labwc 0.20.2-1 to unstable
• Uploaded yambar 1.11.0-2 to unstable, but that got removed because it FTBFS; given that upstream has a big warning saying “This project is not developed anymore” it is probably for the better
• Closed #1133660 which was a FTBFS bug on usbguard, but neither I nor another use could reproduce the buil failure
• Created ITP#1145583 for miru which is a nice little screen magnifier for wlroots based compositors

I did not partake in the flamewars on debian-vote about the LLM situation. I am not sure how anyone can find this style of “discussion” productive. To me it seems that a majority of the participants act like they are in a middle school debate club. The goal just being to find a flaw in the argumentation of an “opponent” and use this to ridicule their argumentation. Basically what politicians do.

The good thing is, that most Debian members did not stoop on that level. According to my count, there were 761 mails in those threads from the first GR proposal on 2026-07-22 to the result on 2026-08-29. Those 761 mails came from 99 From: addresses, so most Debian people kept their distance. Given that according to nm.debian.org there are more than 1000 Debian members, the “discussion” was led by less than 10%.

The distribution of who wrote how many mails is also interesting. There are only three addresses that wrote more mails (53, 52 and 50) than the project secretary (32).

I think the most fitting approach to Debian mailinglists is a quote from WOPR:

A STRANGE GAME. THE ONLY WINNING MOVE IS NOT TO PLAY.

DH Related Work

I released version 0.66.0 and 0.67.0 of the APIS framework as well as a couple of bugfix releases for the 0.67.x version. In 0.67.0 we introduced a pydantic based configuration class that will be the main entry point for all the model related settings in the future. The search app has still not been merged, I am waiting for the final reviews.

Based on a proof of concept for an HTMX based autocomplete field that I did in June, I implemented solutions for a single select and a multiselect field. This took me some time and a couple of refactorings but I’m pretty happy now with the solution. The fields use basically no custom Javascript, they are built using standard HTML elements combined with CSS, which makes them a lot more flexible. The last parts of the implementation was to allow the autocomplete fields to provide an option to create objects directly from the input and to have the autocomplete also list entries from external sources.