10 May 2026
Planet Grep
Frederic Descamps: Dealing with caching_sha2_password as authentication method in MariaDB Server
MariaDB Server supports different authentication methods just like MySQL. Depending on your installation, the number of available and active authentication plugins can vary. But you should always have those 3 by default: If we compare with MySQL 9.7, we can see only 2 default authentication plugins: About caching_sha2_password module In some packaging, the caching_sha2_password auhentication […]
10 May 2026 5:33am GMT
Frederic Descamps: Adding a New Data Type to MariaDB with Type_handler – Part 5
We are concluding our series related to new data types using the Type_handler framework, with some limitations that are not yet covered by the framework: It would have been handy for our MONEY datatype to have the possibility to define, for example, the currency to show. Or the format to have something like this: Unfortunately, […]
10 May 2026 5:33am GMT
Frederic Descamps: Adding a New Data Type to MariaDB with Type_handler – Part 4
This is part 4 of a series related to extending MariaDB with a custom data type using the Type_handler framework. You can find the previous articles below: Overriding Existing Types In the previous examples, our MONEY data type inherits from DOUBLE and then we override some methods. But all the methods of every type cannot […]
10 May 2026 5:33am GMT
09 May 2026
Planet Debian
Dirk Eddelbuettel: RcppSpdlog 0.0.29 on CRAN: Small Enhancement

Version 0.0.29 of RcppSpdlog arrived on CRAN today, has been uploaded to Debian and built for r2u. The (nice) documentation site has been refreshed too. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. You can learn more at the nice package documention site.
This release features a rewritten internal routine unpacking the R variadic arguments into C++ variadic template arguments. This in turn allows to turn back to std::format in C++ mode when C++20 is used. We also adjust for the not-quite-ready-for-this state of the x86-64 based macOS machine at CRAN. It is running a compiler and SDK choice that cannot fully deal with C++20, so we dial compilation on it down to C++17. Similarly, and as we found out after the release, Ubuntu jammy is also too old to default to std::format so we need to add a better detection here too so that we can also fall back to the included fmt there.
The NEWS entry for this release follows.
Changes in RcppSpdlog version 0.0.29 (2026-05-08)
Some small continuous integration updates
The internal formatter was rewritten as a recursive generator of variadic templates.
Switch back to
std::formatwith C++20, but force inferior macos-release-x86_64 to use C++17 rather than default C++20 which fails
Courtesy of my CRANberries, there is also a diffstat report detailing changes. More detailed information is on the RcppSpdlog page, or the package documention site.
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.
09 May 2026 10:49pm GMT
Jelmer Vernooij: Remove-after Annotations for Debian Files
deb-scrub-obsolete is a tool in the debian-codemods suite that tries to identify and remove cruft automatically. It knows about dummy transitional packages, superseded alternatives, and similar patterns it can detect by querying the archive. But some workarounds are too project-specific for a generic tool to recognise on its own.
Developers can leave structured comments in their packaging files that tell deb-scrub-obsolete when a particular line or block can be removed.
The Debian Janitor regularly runs various codemods like deb-scrub-obsolete on all vcs-accessible Debian packages. This means that if you leave a "remove-after: trixie" annotation in your package, you will automatically get a pull request to remove the annotated code once trixie has been released, without needing to remember to do it yourself.
The Comment Format
The annotations take the form of specially-formatted comments. For shell files (and by extension most maintainer scripts), a line-level annotation looks like this:
install -m 755 compat-wrapper /usr/lib/foo/ # remove-after: trixie
When trixie has been released, deb-scrub-obsolete will remove that line entirely. The comment can appear anywhere on the line - before or after other comments - and additional explanatory text can follow:
blah # Trixie comes with blah built in # remove-after: trixie
For larger sections, block-level annotations bracket the code to remove:
# begin-remove-after: trixie alternatives --add foo bar alternatives --add foo bar1 # end-remove-after
These blocks can be nested, which is useful when one outer condition wraps several inner ones with finer-grained timing.
Expressions
The initial set of supported expressions is deliberately small. The main one is a Debian release name: remove-after: trixie means "once trixie has been released". The condition is checked against distro-info <https://manpages.debian.org/trixie/distro-info/distro-info.1.en.html>_, the same data source that other Debian tooling uses to track release status.
The expression language is designed to be monotonic - conditions should only ever go from false to true, not back. A workaround that needs to be re-introduced after removal belongs in a new commit, not in an annotation. If deb-scrub-obsolete cannot parse an annotation it finds in a file, it leaves all annotations in that file untouched, to avoid a situation where related blocks are only partially removed.
Annotations can also carry a marker name - an arbitrary label with no spaces, commas, or the word "after" - which can then be passed to deb-scrub-obsolete on the command line. This makes it possible to trigger removal of a named set of annotations together, useful for coordinated transitions where several packages need to be cleaned up at the same time.
Future Extensions
The initial expression set is minimal; the design leaves room for richer conditions. Some candidates under consideration:
- Whether a particular suite has a new enough version of a package (removing a Build-Depends version constraint once it is satisfied everywhere)
- Whether a package has been removed from the archive
- Whether all currently-supported releases contain a new enough version
- Whether a Debian transition has completed
Compound expressions using "and" / "or" are also on the list, for cases where removal depends on multiple conditions being true simultaneously.
Status
The annotation format is specified but not yet implemented in deb-scrub-obsolete - it is planned for a future release. If you maintain Debian packages and have opinions on the annotation format or the expression language, feedback is welcome. The specification lives in scrub-obsolete/doc/scrub-annotations.md in the lintian-brush repository. Many thanks to Helmut Grohne for the initial suggestion and feedback on the design.
09 May 2026 6:45pm GMT
Russell Coker: Packaging Amazfish for Debian
I have done some packaging work on Amazfish (the smart-watch software that works with the PineTime among others) for Debian. Here is my Git repository for libnemodbus (a dependency for Amazfish that isn't in Debian) [1]. Here is my Git repository for Amazfish itself [2].
These packages are currently using QT5 which is a good reason to not upload them now as the transition to QT6 is in progress. Patching them to work with QT6 (as the libnemodbus upstream is apparently not migrating to QT6 yet) shouldn't be that difficult but is something that needs some care and communication to get it right.
Running this package on my laptop with my PineTime (which worked very reliably when run by GadgetBridge on Android) wasn't reliable and the PineTime would disconnect and refuse to connect again. Doing it on the Furilabs FLX1s gave a similar result. If Amazfish was the only Bluetooth program having problems on my laptop and on my FLX1s then I'd blame it, but both those systems have some other Bluetooth issues.
Running this on my laptop Amazfish would send it's own test notifications to my watch but system notifications (from notify-send among others) wouldn't get sent. Running this on my FLX1s I got ONE notification from my network monitoring system sent to my watch before my phone and watch stopped talking to each other.
To make things even more difficult for me the harbour-amazfish-ui program doesn't work correctly with the libraries installed on my FLX1s and doesn't display the content of many screens but it works correctly when running in a container environment with stock Debian/Testing.
Below is the script that I'm currently using to launch apps in a Debian/Testing container on my FLX1s. The comment about unshare-user doesn't apply to this version of the script but I left it in to avoid the potential for future confusion. The Furilabs people diverted the bwrap binary and have a wrapper that removes a set of parameters that they think will cause problems.
#!/bin/bash set -e BUILDBASE=/chroot/testing # bwrap: Can't mount proc on /newroot/proc: Device or resource busy # get the above with --unshare-user and --unshare-pid exec bwrap.real --bind /tmp /tmp --bind /run /run --bind $HOME $HOME --ro-bind $BUILDBASE/etc /etc --ro-bind $BUILDBASE/usr /usr --ro-bind $BUILDBASE/var/lib /var/lib --symlink usr/bin /bin --symlink usr/sbin /sbin --symlink usr/lib /lib --proc /proc --dev-bind /dev /dev --die-with-parent --new-session "$@"
Due to the range of problems I'm having I think it would be best to pass this package on to someone else who has a different test setup. It could be that further testing will reveal that my issues are related to bugs in Amazfish but I can't prove it either way at this time. Maybe when using a smart watch other than a Pine Time it will work more reliably but it seems most likely that my laptop and phone are to blame. I can't make more progress on this now.
09 May 2026 12:04pm GMT
05 May 2026
Planet Lisp
ECL News: ECL 26.5.5 release
We are announcing a bugfix ECL release that addresses a few issues that has slipped through testing of the recent one.
Addressed issues:
-
bugfix: MAKE-PACKAGE destructively modified defining form's cons cells of the package local nicknames, breaking package literals in bytecmp (#839)
-
bugfix: the first environment is now always page-aligned by using the same allocation mechanism as all subsequent envs (#828)
-
bugfix: allow loading concatenated fasc files (#842)
-
bugfix: defclass does not redefine existing classes at compile time with forward-referenced classes in the bytecodes compiler (#843)
This release is available for download in a form of a source code archive (we do not ship prebuilt binaries):
Happy Hacking,
The ECL Developers
05 May 2026 12:00pm GMT
Gábor Melis: DRef Leaves Home
Version 0.5 of DRef, the definition reifier, is now available. It has moved to its own repository, completing its separation from PAX, where it was originally developed.

This was a long time coming. Twelve years ago today, PAX was born. From the start, PAX used the concept of locatives to refer to definitions without first-class objects. For example, to generate documentation for the *MY-VAR* variable, one could use the VARIABLE locative as in (*MY-VAR* VARIABLE). PAX needed to be able to tell whether such a definition exists, as well as access its docstring and source location.
Over time, this mechanism evolved into a portable, extensible introspection library independent of PAX. I began separating the two projects two years ago and named the new library, though they continued to share a repository. I have now removed the remaining dependencies so that DRef can live on its own.
05 May 2026 12:00am GMT
01 May 2026
Planet Lisp
Joe Marshall: Echoes of the Lisp Listener
The Lisp Machine Listener had an electric close parenthesis. When the user typed a close parenthesis, and this was the close parenthesis that finished the complete form at top level, the form would be sent to the REPL right away with no need to press enter. Here's how to get this behavior with SLY:
(defun my-sly-mrepl-electric-close-paren ()
"Insert ')' and auto-send ONLY if we are closing a top-level Lisp form."
(interactive)
(let ((state (syntax-ppss)))
(insert ")")
;; Safety checks:
;; 1. We were at depth 1 (so we are now at depth 0)
;; 2. We aren't in a string or comment
;; 3. The input actually starts with a paren (it's a form, not a sentence)
(when (and (= (car state) 1)
(not (nth 3 state))
(not (nth 4 state))
(string-match-p "^\\s-*("
(buffer-substring-no-properties (sly-mrepl--mark) (point))))
(sly-mrepl-return))))
Another cool hack is to get the REPL to do double duty as a command line to the LLM chatbot. When you type RET in the REPL, it will check if the input is a complete lisp form. If so, it will send the form to the REPL as normal. If not, it will send the input to the chatbot. Here's how to do this:
(defun my-sly-mrepl-electric-return ()
"Send to Lisp if it's a form/symbol, or wrap in (chat ...) if it's a sentence."
(interactive)
(let* ((beg (marker-position (sly-mrepl--mark)))
(end (point-max))
(input (buffer-substring-no-properties beg end))
(trimmed (string-trim input)))
(cond
;; If it's empty, just do a normal return
((string-blank-p trimmed)
(sly-mrepl-return))
;; If it starts with a paren, quote, or hash, it's definitely a Lisp form
((string-match-p "^\\s-*[(#'\"]" trimmed)
(sly-mrepl-return))
;; If it's a single word (no spaces), treat it as a symbol/form (e.g., *package*)
((not (string-match-p "\\s-" trimmed))
(sly-mrepl-return))
;; Otherwise, it's a sentence. Wrap it and fire.
(t
(delete-region beg end)
(insert (format "(chat %S)" trimmed))
(sly-mrepl-return)))))
Install as follows:
;; Apply to SLY MREPL with a safety check for the mode map (with-eval-after-load 'sly-mrepl (define-key sly-mrepl-mode-map (kbd "RET") 'my-sly-mrepl-electric-return) (define-key sly-mrepl-mode-map (kbd ")") 'my-sly-mrepl-electric-close-paren))
01 May 2026 5:29pm 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