14 Jun 2026
Planet Grep
Mattias Geniar: Linux debugging tools I use daily
Every server I run, including the fleet behind Oh Dear 's uptime checks, has the same set of debugging tools installed before anything goes wrong. Not because the application needs them, but because the one time you reach for strace is at 2am, the box is misbehaving, and apt install is the last thing you want to be doing while you work out what broke.
14 Jun 2026 2:33pm 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 […]
14 Jun 2026 2:33pm GMT
Frederic Descamps: MariaDB + DuckDB: A New Playground for Analytics – A First Look at the New Storage Engine
MariaDB just announced it has learned to quack: the new DuckDB storage engine has joined the large family of storage engines in MariaDB Server. The idea is very interesting: use MariaDB Server as usual, but create some tables using ENGINE=DuckDB and benefit from DuckDB's columnar storage and vectorized execution for analytical queries. In other words, […]
14 Jun 2026 2:33pm GMT
Planet Debian
Jonathan Dowland: HeroQuest

My youngest daughter and I recently started playing the tabletop game HeroQuest. Specifically, the recently-issued, cut-down variant HeroQuest: First Light. This is quite advanced for her age, and I'm a little surprised she's taken to it, but she's really loving it, It's pushed her to read bits of lore on cards and quest books that is way above her expected reading level, and we've been exercising her maths by adding up the gold we find on our quests and calculating what the heroes can buy with it in the store afterwards.
Originally from 1989, Hasbro re-issued HeroQuest in 2020. I read about it at the time but didn't buy it. I wasn't sure who I would play it with. It also seemed expensive to me. It probably wasn't unusually expensive in 2020, nor now, for the sheer volume of finely-sculpted miniatures included. I also knew I had the original game in the loft, and I wasn't that keen on buying something I already had, although untangling the contents from several similar boxed games would take me many hours, and I wasn't sure how much of the game I would find.
First Light was compelling because it is much, much cheaper than the full remake, so I was happy to take a punt. It's cheaper because it doesn't have any plastic monsters or furniture: instead cardboard cut-outs that stand up on plastic stands. For us, that is a significant drawback: 3D miniatures are much more immersive, But I can re-use the plastic miniatures I can find from the original game. First Light has a newly written adventure, better suited to beginners than the original game.
The re-issue(s) have new art and new model sculpts that look fantastic. They've changed anything which tied into Games Workshop's IP and I'm really happy about that. They've made an effort to add women, almost entirely absent from the original. I'm certain my daughter wouldn't have tried it otherwise.
14 Jun 2026 9:31am GMT
Matthias Klumpp: Introducing pkgcli: A nicer command-line interface for PackageKit
For almost two decades, the PackageKit package management abstraction layer has shipped with pkcon as its command-line client. pkcon does its job, but it was always kind of a "testing" front-end for the PackageKit daemon rather than a tool designed for everyday use. The focus has instead been on the GUI tools, automatic system updates, GUI application managers and other front-ends. Its command names mirror the D-Bus API almost one-to-one (get-details, get-updates, get-depends), output is very plain, and there is no machine-readable mode for scripting. Most importantly though, there has been no development on it at all for almost a decade, so pkcon was stuck in its rudimentary state from that era.
Since a lot of changes will be coming to PackageKit, and testing the daemon and working with it from the command-line was not very pleasant anymore in 2025/2026, I decided to modernize the tool as part of my work as fellow for the Sovereign Tech Agency last year. pkgcli is the new command-line client for PackageKit. It is built from the ground up to be pleasant to use interactively and easy to drive from scripts.
Why a new tool?
Of course, instead of introducing a new tool, I could have just expanded pkcon instead. The problem with that approach is that the pkcon utility has been around for so long and its command-line API had ossified so much, that rather than changing it and potentially breaking a lot of scripts relying on its quirks, I decided to introduce a new tool instead. pkcon can still be optionally compiled for people who need it in their scripts and workflows.
The goals for pkgcli, and the features it now has are:
- Human-friendly command names. Verbs that read the way you'd describe the task, instead of mirroring the D-Bus API 1:1:
show,search,list-updates,what-provides, instead ofget-detailsand friends. - Readable, colored output by default (still respecting
NO_COLORand degrading gracefully). - A real scripting mode. A global
--jsonflag emits JSONL instead of fully human-readable output when possible, to make it easier to use the tool for scripting purposes. - Sensible defaults. A few defaults have been changed, such as the metadata cache-age, or automatic cleanup of unused dependencies being enabled by default. This is more in line with current defaults by other tools and frontends. We also print package information in a slightly different, more readable way.
- Better handling of internationalized text. Text should now align properly in the terminal window, and we should no longer have completely chaotic text output on non-English locales (especially Chinese/Japanese).
Why not pkgctl?
Originally, this tool was called pkgctl, to match other common cross-distro tool names. However, that name was already taken by an Arch-specific distro development tool. When this issue was raised, we decided to just rename our tool to pkgcli with the next release, to avoid the name clash on Arch Linux.
Examples!
Here are some examples on how to use the new tool (some of which include the abridged output pkgcli prints).
Search for anything containing the string "editor" in name or description, then look at the details of one result:
$ pkgcli search editor
Querying [████████████████████████████████████████] 100%
▣ ace-of-penguins 1.5~rc2-7.amd64 [debian-testing-main]
▣ acorn-fdisk 3.0.6-14.amd64 [debian-testing-main]
▣ ardour 1:9.2.0+ds-1.amd64 [debian-testing-main]
✔ audacity 3.7.7+dfsg-1.amd64 [manual:debian-testing-main]
✔ audacity-data 3.7.7+dfsg-1.all [auto:debian-testing-main]
▣ augeas-tools 1.14.1-1.1.amd64 [debian-testing-main]
▣ emacs 1:30.2+1-3.all [debian-testing-main]
▣ gedit 48.1-9+b1.amd64 [debian-testing-main]
▣ gedit-common 48.1-9.all [debian-testing-main]
▣ gedit-dev 48.1-9+b1.amd64 [debian-testing-main]
[...]
$ pkgcli show nano
Package: nano
Version: 9.0-1
Summary: small, friendly text editor inspired by Pico
Description: GNU nano is an easy-to-use text editor originally designed as
a replacement for Pico, the ncurses-based editor from the non-free mailer
package Pine.
[...]
URL: https://www.nano-editor.org/
Group: publishing
Installed Size: 2.9 MB
Download Size: 646.0 KB
Search only within package names rather than descriptions:
$ pkgcli search name python3
Check for updates. refresh updates the metadata, then list-updates reports what's available:
$ pkgcli refresh && pkgcli list-updates
Loading cache [████████████████████████████████████████] 100%
▲ cme 1.048-1.all [debian-testing-main]
▲ gir1.2-gdm-1.0 50.1-2.amd64 [debian-testing-main]
▲ imagemagick 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main]
▲ imagemagick-7-common 8:7.1.2.24+dfsg1-1.all [debian-testing-main]
▲ imagemagick-7.q16 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main]
▲ libdlrestrictions1 0.22.0.amd64 [debian-testing-main]
▲ libfftw3-bin 3.3.11-1.amd64 [debian-testing-main]
▲ libfftw3-dev 3.3.11-1.amd64 [debian-testing-main]
Explore relationships between packages:
$ pkgcli list-depends inkscape # list what inkscape depends on
$ pkgcli list-requiring libappstream5 # list what requires libappstream5
Find the package that provides a capability, here the AV1 GStreamer decoder:
$ pkgcli what-provides "gstreamer1(decoder-video/x-av1)"
✔ gstreamer1.0-plugins-bad 1.28.3-1.amd64 [auto:debian-testing-main]
You can also have JSON output for most commands! Attach --json to any query and pipe the result straight into jq. Each line is a self-contained JSON object:
$ pkgcli --json list-updates | jq -r '.name'
cme
gir1.2-gdm-1.0
imagemagick
imagemagick-7-common
imagemagick-7.q16
libdlrestrictions1
libfftw3-bin
libfftw3-dev
libfftw3-double3
Try it
pkgcli is built by default alongside the rest of PackageKit since PackageKit 1.3.4. If your distribution ships a recent enough PackageKit, it should already be on your PATH. You can read its man page man pkgcli for more information. Feedback, bug reports, and patches are very welcome.
14 Jun 2026 6:22am GMT
12 Jun 2026
Planet Debian
Mike Gabriel: Ayatana Indicators: Call for Translations

In the process of preparing a major Ubuntu Touch release (v24.04-2.0, coming soon...) we will also update Ayatana Indicators in Ubuntu Touch.
Last week various new features have been added to some of the indicators (toggle switch to keep the display switched on permanently, blue tooth pairing agent, redesign of the keyboard indicator, etc.) and those changes require translation updates.
If you can, please visit [1] this weekend and help translating Ayatana Indicators into your native language. Thanks so much!!!
light+love
Mike
[1] https://hosted.weblate.org/projects/ayatana-indicators/
12 Jun 2026 9:50pm 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

