10 Jun 2026
Planet Grep
Mattias Geniar: The backup SSH daemon I run before every do-release-upgrade
I spent a chunk of the last few weeks upgrading a fleet of Ubuntu servers in place, one LTS to the next, with do-release-upgrade. Dozens of boxes, mostly stateless, mostly boring once you've done the first few.
10 Jun 2026 10:41pm GMT
Frederic Descamps: MariaDB Server 12.3, 11.8, 11.4, 10.11, 10.6 – May 2026’s releases: thank you for your contributions
On May… we have released an update of our 5 current LTS releases: These new releases contain a large amount of external contributions. The number of contributors is constantly growing, which is great! On behalf of the MariaDB Foundation and the entire MariaDB Team, let me thank you all! If we refer to MariaDB Server […]
10 Jun 2026 10:41pm GMT
Frederic Descamps: MariaDB Server 12.3 LTS Released
A few days ago, the MariaDB Server 12.3 LTS was released! MariaDB 12.3 is the new Long-Term Support release in the MariaDB 12 series and will be maintained for several years. The first GA version of the 12.3 series is 12.3.2. For users running production systems, this is the kind of release that matters: not […]
10 Jun 2026 10:41pm GMT
Planet Debian
Mike Gabriel: Future of libayatana-appindicator (v0.6.0 released today)

Some of you might have noticed that the recent (or rather: previous) version of libayatana-appindicator (v0.5.94) notified users and developers of the library being deprecated.
This short post is to notify you, that with today's libayatana-appindicator v0.6.0 release [1] this deprecation warning has now been removed again. Another new feature (added to AppIndicator without ABI breakage) is tooltip support. The new package version has just been uploaded to Debian experimental. Please test if your application (if it gets linked against libayatana-appindicator) continues to work flawlessly. Thanks!
libayatana-appindicator will receive continued support until GTK-3 becomes end-of-life (because libayatana-appindicator has a baked-in GTK-3 dependency which should not be ported to GTK-4 imho). That said, in the future, GTK-3 applications can continue using libayatana-appindicator for sending AppIndicator-like icons and menus over DBus to KStatusNotifierItem-based system tray renderers.
If you are looking for an AppIndicator implementation for GTK-4 applications (or other), I'd like to encourage you to help making libayatana-appindicator-glib [2] a new standard (can be used in GTK and Qt applications alike, implementation is using pure Glib-2.0). Currently, there is only one renderer (ayatana-indicator-application), so more work needs to be done on the renderers' side. (One of the next work items here is to get AppIndicator-Glib support working in Lomiri's desktop/windowed mode).
[1] https://github.com/AyatanaIndicators/libayatana-appindicator/releases/ta...
[2] https://github.com/AyatanaIndicators/libayatana-appindicator-glib/
10 Jun 2026 8:15pm GMT
Colin Watson: Free software activity in May 2026

My Debian contributions this month were all sponsored by Freexian.
You can also support my work directly via Liberapay or GitHub Sponsors.
OpenSSH
I backported various security fixes from 10.3 to trixie, bookworm, bullseye, buster, and stretch. For trixie, I also backported several IPQoS fixes to line up with upstream's traffic management settings and drop a rather hacky Debian-specific patch; this needed a quick follow-up fix.
I upgraded trixie-backports to 10.3.
I fixed openssh uses pidof but does not depend on procps.
PuTTY
I upgraded from 0.83 to 0.84.
Python packaging
New upstream versions:
- bitstruct
- ormar
- pdm (fixing a build failure)
- pydantic
- pydantic-core
- pydantic-settings
- pyglet (fixing a build failure)
- python-asyncssh
- python-bitarray
- python-btrees
- python-build
- python-certifi
- python-charset-normalizer (fixing a build failure)
- python-fakeredis (contributed supporting fix upstream)
- python-holidays
- python-jsonschema-path
- python-memray (fixing a build failure and CVE-2026-32722)
- python-openapi-schema-validator
- python-pathable
- python-persistent
- python-pyftpdlib
- python-pytest-run-parallel
- sorl-thumbnail
- twisted
- zope.interface
- zope.proxy
Other build/test failures:
- beets
- buildbot (contributed upstream)
- dep-logic (contributed upstream)
- diskcache
- khard
- matplotlib
- mkdocs-rss-plugin
- ormar: compatibility with fastapi 0.125 and pydantic 2.13
- pgzero
- py7zr
- pydantic-extra-types (contributed upstream)
- pydata-sphinx-theme
- python-invocations (contributed upstream)
- python-localzone
- python-maturin
- python-nacl
- python-pampy
- python-treq (contributed upstream, including fixing some CI bitrot)
- python-txrequests (contributed upstream)
Other bugs:
- buildbot: (Build-)depends on deprecated module python3-pkg-resources (contributed upstream)
- pysodium: Depends on cruft package libsodium
- python-fakeredis: lua support not working, breaking django-redis cache locking
- python3.14: Drop libnsl-dev build-dependency
I updated python-treq upstream to stop vendoring multipart, now that the packaging issues with that have been sorted out.
Code reviews
- debmirror: User-Agent blocked by Ubuntu/Launchpad repositories (uploaded, and cherry-picked into trixie)
- pydantic: Fix CVE-2024-3772 in bookworm (merged and uploaded)
- pyodbc: Run SQLite tests (merged and uploaded)
- python-jsonschema-path: Transition to starlette 1.0 (merged and uploaded)
- python-maison: FTBFS with the nocheck build profile (followed up to fix the
nodocbuild profile as well) - python-openapi-core: Transition to starlette 1.0
- python-openapi-schema-validator: Transition to starlette 1.0 (merged and uploaded)
- python-openapi-spec-validator: Transition to starlette 1.0 (merged and uploaded)
- python-pathable: Transition to starlette 1.0 (merged and uploaded)
- python-rich-argparse: New upstream version 1.8.0 (merged and uploaded)
Other bits and pieces
I contributed a debian-policy patch to fix several links related to build profiles.
10 Jun 2026 3:10pm GMT
09 Jun 2026
Planet Debian
Vincent Bernat: Blogging with LLMs as a non-native speaker
AI slop is invading the web. A recent story about disallowing LLM-generated submissions on Lobsters triggered a lot of debate. My personal worst offenders are LinkedIn articles with AI-generated images and uninspired articles filled with emojis from people trying to masquerade as experts on a subject they don't care enough to write themselves. While I am unhappy about this situation, I rely on LLMs for grammar, copyediting, and translation. I don't see this as a contradiction.
I am a native French speaker, but I blog in both English and French. When I started writing this blog in 2011, I was composing in French and translating to English, but I found it was better to work in the reverse order to avoid unnatural and non-idiomatic constructions. One of my goals is to write "good" English but I never felt it was my strong point.1 For example, verb tenses are often an issue, even if I mostly stick with the present tense. I learn the rules and forget them right away. I also don't feel like hiring an editor for something I see as an hobby.
As an example, I have kept the history of the successive iterations when writing "Scaling Akvorado BMP RIB with sharding":
- the first draft, authored with the help of a thesaurus,2
- the edited copy revised by the copyediting skill,
- the translation to French generated with the translation skill, and
- the human proofread of the French translation, with minor edits to the English version.
I know that LLMs may alter the author's voice when editing, but the corrections in the second step are minor. The prompt asks to "apply light stylistic edits," with some guidance around avoiding passive voice, long sentences, bland verbs, and filler words. It also defines the target audience: technical with a B2 level in English.
In the following excerpt, I used "long time" instead of "long-standing." The former is missing an hyphen and applies to people-a long-time friend, while the later relates to a situation-a long-standing agreement. I had a hard time understanding the reason of the second change: the LLM prefers a defining relative clause to provide the definition of "RIB sharding."
As the Internet routing table contains more than 1 million routes, Akvorado needs to scale to tens of millions of routes. This has been a
long timelong-standing challenge, but I expect this issue is now fixed by using RIB sharding, a methodto splitthat splits the routing database into several parts to enable concurrent updates.
In the next modification, the LLM puts "device" instead of "equipment." This is correct as "equipment" is an uncountable noun. I know that, but I still fall into this trap.
When Akvorado does not find a route from a specific device, it falls back to a route sent by another
equipmentdevice.
I ask the LLM to use "descriptive verbs" and it complies by replacing a multi-word predicate with a lexically rich verb:
The benchmarks demonstrate it
has better performance thanoutperforms otherpackages, bothpackages for lookups, insertions, and memory usage.
It also fixes grammar errors. In the next excerpt, a "list of routes" is a singular expression. Moreover, "stored" is a state and I should not use "into" as it expresses a change.
The list of routes for each prefix
areis not stored directlyintoin the prefix tree.
As a last example, consider the following snippet. The "require" verb accepts a noun or an object followed by a to-infinitive. I can't use it with just a to-infinitive.
An alternative would be to have one prefix tree for each peer but it would require
to configureconfiguring all routers to export their routes.
As someone who didn't grow up speaking English, I struggle with these grammar rules despite reading a lot of English material.3 French is more complex to get started but more systematic. English is full of irregularities.
On each page, I disclose in the footer whether an AI modified the content. There are three levels:
- 🧠: no AI or almost no AI (e.g., grammar corrections)
- ✨: enhanced (e.g., copyediting)
- 🤖: generated (e.g., translated from another language, even if human-edited)
Hover or tap the icon to reveal the AI's name and its role in the document.

The graph below shows which tool altered each post, year by year. Recently, I applied the grammar skill to past articles. Since 2018, French articles have been translated with the help of DeepL first, then of an LLM. Since 2024, English articles are copyedited.
If you are strongly against any usage of LLMs specifically for writing, I hope you accept my more nuanced position on the usage of these tools as a trade-off to provide clearer and more engaging articles. Years of literature on improving English told us it is important to choose the right word to keep the reader engaged.
[…] Good writing consists of mastering the fundamentals (vocabulary, grammar, the elements of style) and then filling the third level of your toolbox with the right instruments.
― Stephen King, On Writing
Note
Unlike other recent articles, I did not use an LLM to edit this post: an unnamed person kindly accepted to proofread it. I translated it to French without using an LLM either.
-
I recently read cover to cover "Writing for Developers" and I found it stimulating. Michael Lynch is currently writing "Refactoring English" on the same topic and I have subscribed to the early access. ↩
-
I am quite happy with the writing tools provided by Kagi. Both the translate tool and the dictionary are a valuable help to find different wordings. I also lean on Kagi's research assistant when researching a topic. ↩
-
When I was ten, I played Monkey Island 2 in English without having taken any classes. I used a dictionary to translate word by word and I found the irregular verbs confusing-and not in the dictionary. ↩
09 Jun 2026 8:15pm GMT
01 Jun 2026
Planet Lisp
Joe Marshall: Regression
Last year I wrote some Lisp related AI apps. There was a syntax highlighter that used the LLM to determine how to colorize and highlight syntax, and a prompt refiner that takes a wimpy LLM prompt and creates more elaborate prompt from them.
I took the apps down last week. They were `vibe coded' and therefore approximate and had bugs (but that's to be expected), but they had a security hole where you could hijack the LLM processing with your own prompt turning my app into an open relay using my API key. Last week I discovered that my AI spend on video creation was becoming serious. This is odd because I never create AI video. It turned out that my app was being hijacked by a proxy in Luxembourg and was generating videos on my dime.
So I shut down the apps. I knew they had the potential of being abused, and I was willing to tolerate a small amount of abuse, but it didn't occur to me that syntax highlighter could be hijacked to generate gigabytes of video at my expense. Future applications will be careful to obtain the API key from the user.
01 Jun 2026 7:00am GMT
31 May 2026
Planet Lisp
Joe Marshall: CLRHack: Meta-object Protocol
Metaobject Protocol (MOP) Implementation in CLRHack
The Metaobject Protocol in CLRHack is a high-performance implementation of the Common Lisp Object System (CLOS) integrated into the .NET 8.0 Common Language Runtime (CLR). It provides a complete meta-compilation pipeline that bridges the gap between dynamic Lisp semantics and the static CIL (Common Intermediate Language) execution model.
Core Architecture
The MOP is implemented through three primary layers:
- The Metaobject Hierarchy (C#): A set of foundational classes in
LispBaserepresenting classes, methods, generic functions, and slot definitions. - The Runtime Engine (
MopRuntime): A centralized orchestrator that manages class finalization, method combination, dispatch caching, and instance allocation. - The Compiler Bridge (Lisp): Transformations in
ast.lispthat translate high-level CLOS forms (defclass,defmethod) into optimized runtime calls.
Instance Representation
Because the CLR type system is strictly single-inheritance and statically defined, CLRHack decouples Lisp-level inheritance from C# inheritance. All CLOS instances are represented by the StandardObjectInstance class, which contains:
- A reference to its
ClassMetaobject. - A private
object[] storagearray for instance slots, indexed by locations calculated during class finalization.
The Dispatch Pipeline
Generic function invocation is the most complex part of the implementation. When a generic function is called:
- Cache Lookup: The
DiscriminatingFunctionfirst checks a thread-safedispatchCacheusing anInvocationCacheKey(a stack-allocatedstruct) to find a previously computed effective method. - Applicability & Precedence: If the cache misses, the runtime computes all applicable methods and sorts them based on specializer specificity and the Class Precedence List (CPL).
- Method Combination: The
ComputeEffectiveMethodlogic builds a nested execution chain following the Standard Method Combination rules::aroundmethods are called first, withcall-next-methodprogressing to the next around method or the main chain.- The main chain executes all
:beforemethods, the primary method, and finally all:aftermethods in reverse order.
- Fast Invocation: The resulting effective method is compiled into a
Func<object[], object>that uses direct delegate invocation to minimize overhead.
Challenges and Solutions
1. Thread-Safe Non-Local Exits (call-next-method)
Challenge: call-next-method and next-method-p require access to the current invocation's state (the remaining methods and original arguments). Passing this state through every function call would break compatibility with standard Lisp function signatures.
Solution: CLRHack utilizes [ThreadStatic] fields in MopRuntime to store the currentNextMethods and currentArguments. This ensures that even in highly concurrent environments (like a web server), each OS thread has its own isolated invocation context, allowing call-next-method to function correctly without state leakage.
2. Forward References and Lazy Finalization
Challenge: Lisp allows classes to refer to superclasses that haven't been defined yet. The runtime must handle these "zombie" classes without crashing the JIT compiler.
Solution: The system implements a ForwardReferencedClassMetaobject. When a class is defined, it is automatically finalized (computing its CPL and slot layout). If a superclass is missing, a forward reference is created. The EnsureFinalized protocol ensures that inheritance is resolved and slot locations are assigned the moment the class is first instantiated or used in dispatch.
3. Performance Overhead of the "MOP Bridge"
Challenge: A naive implementation of slot-value or generic dispatch using C# reflection or linear searches is orders of magnitude slower than native C# member access.
Solution: Three distinct optimizations were applied:
- O(1) Slot Access: Each
ClassMetaobjectmaintains aSlotDictionary. Slot names are mapped to physical array indices during finalization, allowingslot-valueto perform a direct array access after a single dictionary lookup. - Compiler Primitives: The compiler identifies
SLOT-VALUEandMAKE-INSTANCEcalls and emits direct CILcallinstructions to optimizedLisp.MopRuntimemethods, bypassing the generalFuncallpath. - Zero-Allocation Cache Hits: By making
InvocationCacheKeyareadonly structand avoiding the cloning of the argument array during cache probes, the hot-path for generic function dispatch generates zero garbage for the .NET Collector.
4. Bootstrapping the COMMON-LISP Package
Challenge: Core CLOS functions like make-instance must be available as symbols in the COMMON-LISP package before user code runs, but they rely on the MOP runtime being fully initialized.
Solution: A MopRuntime.Initialize() method is injected into the entry point (Main) of every generated assembly. This method interns the necessary symbols and binds them to GenericFunctionClosureAdapter objects, ensuring that the MOP is "alive" before the first line of Lisp code executes.
Vibe coding the MOP basically involved feeding chapters 4 and 5 of the Art of the Meta-Object Protocol into the LLM and telling it to make an implementation plan. It came up with a twenty-step plan to bootstrap CLOS. I then spent the rest of the day instructing an agent to take on each task of the twenty-step plan in sequential order. At the end of the day, I had a working MOP
This is the end of my series of posts on CLRHack.
31 May 2026 7:00am GMT
30 May 2026
Planet Lisp
Joe Marshall: CLRHack: signal and error
Implementation of SIGNAL and ERROR in CLRHack
In CLRHack, the condition signaling system is implemented in the Lisp.HandlerControl class within the LispBase library. It leverages .NET's [ThreadStatic] storage to maintain a per-thread dynamic stack of active condition handlers.
SIGNAL Implementation
The Signal(object condition) method performs the following logic:
- Retrieval: It fetches the
activeHandlerslist for the current thread. This list is a chain of[LispBase]Lisp.Handlerobjects maintained byhandler-bind. - Iteration: It iterates linearly through the list from the most recently bound handler to the oldest.
- Type Matching: For each handler, it calls
IsType(condition, handler.ConditionType).- If the condition is a symbol, it checks for symbol equality (supporting simple symbol-based conditions).
- If the condition is a .NET object, it checks if the handler's type is assignable from the condition's runtime type (supporting interop with system exceptions).
- It treats the symbols
TorEXCEPTIONas catch-all types.
- Handler Invocation: If a match is found:
- Recursive Signal Protection: Before calling the handler function, the current handler list is temporarily shadowed.
activeHandlersis set tocell.rest(the handlers bound outside the current one). This ensures that if the handler itself callssignal, it won't trigger itself recursively. - Execution: The handler's
Closureis invoked with the condition object as its argument. - Restoration: A
finallyblock ensures the originalactiveHandlerslist is restored if the handler returns normally.
ERROR Implementation
The
Error(object condition)method build uponSignal:- Signaling Pass: It first invokes
Signal(condition). If a handler performs a non-local exit (e.g., viahandler-case), theErrormethod never returns. - Debugger Entry: If
Signalreturns normally (meaning all handlers declined),ErrorcallsEnterDebugger(condition). - Interactive Debugging: The debugger:
- Prints the condition and a list of available restarts (retrieved via
RestartControl.GetActiveRestarts()). - Provides a prompt for the user to select a restart, launch the system-level debugger (Visual Studio/Rider), or abort.
- If a restart is selected, it is invoked interactively (potentially gathering arguments from the user).
- Prints the condition and a list of available restarts (retrieved via
- Final Fallback: If the debugger is exited without invoking a restart,
Errorthrows a C#Exceptionto ensure that execution does not continue on an invalid path.
Notable Implementation Decisions and Edge Cases
- Recursive Signal Protection: Before calling the handler function, the current handler list is temporarily shadowed.
- Handler Shadowing: The decision to pop the handler list during invocation is critical for maintaining Common Lisp semantics. It prevents infinite loops and ensures that "outer" handlers can handle errors raised within "inner" handlers.
- Unified Exception Model: CLRHack attempts to unify Lisp conditions and .NET exceptions.
IsTypeallows Lisp handlers to catch C# exceptions by their class name or Type object. - Thread Isolation: By using
[ThreadStatic]foractiveHandlers, CLRHack ensures that condition signaling is thread-safe. One thread signaling an error will not interfere with the handler state of another thread. - Debugger Capability: The
SYSTEM-DEBUGGERoption inEnterDebuggeris a bridge to the underlying .NET environment, allowing developers to use professional IDE tools to inspect the state of the Lisp VM when an unhandled error occurs.
signal and error complete the Common Lisp condition system implementation for CLRHack
30 May 2026 7:00am GMT
25 Apr 2026
FOSDEM 2026
All FOSDEM 2026 videos are online
All video recordings from FOSDEM 2026 that are worth publishing have been processed and released. Videos are linked from the individual schedule pages for the talks and the full schedule page. They are also available, organised by room, at video.fosdem.org/2026. While all released videos have been reviewed by a human, it remains possible that one or more issues fell through the cracks. If you notice any problem with a video you care about, please let us know as soon as possible so we can look into it before the video-processing infrastructure is shut down for this edition. To report any舰
25 Apr 2026 10:00pm GMT
29 Jan 2026
FOSDEM 2026
Join the FOSDEM Treasure Hunt!
Are you ready for another challenge? We're excited to host the second yearly edition of our treasure hunt at FOSDEM! Participants must solve five sequential challenges to uncover the final answer. Update: the treasure hunt has been successfully solved by multiple participants, and the main prizes have now been claimed. But the fun doesn't stop here. If you still manage to find the correct final answer and go to Infodesk K, you will receive a small consolation prize as a reward for your effort. If you're still looking for a challenge, the 2025 treasure hunt is still unsolved, so舰
29 Jan 2026 11:00pm GMT
26 Jan 2026
FOSDEM 2026
Call for volunteers
With FOSDEM just a few days away, it is time for us to enlist your help. Every year, an enthusiastic band of volunteers make FOSDEM happen and make it a fun and safe place for all our attendees. We could not do this without you. This year we again need as many hands as possible, especially for heralding during the conference, during the buildup (starting Friday at noon) and teardown (Sunday evening). No need to worry about missing lunch at the weekend, food will be provided. Would you like to be part of the team that makes FOSDEM tick?舰
26 Jan 2026 11:00pm GMT