Welcome to the February 2026 report from the Reproducible Builds project! These reports outline what we ve been up to over the past month, highlighting items of news from elsewhere in the increasingly-important area of software supply-chain security. As ever, if you are interested in contributing to the Reproducible Builds project, please see the Contribute page on our website.

1. reproduce.debian.net
2. Tool development
3. Distribution work
4. Miscellaneous news
5. Upstream patches
6. Documentation updates
7. Four new academic papers

reproduce.debian.net The last year has seen the introduction, development and deployment of reproduce.debian.net. In technical terms, this is an instance of rebuilderd, our server designed monitor the official package repositories of Linux distributions and attempt to reproduce the observed results there. This month, however, Holger Levsen added suite-based navigation (eg. Debian trixie vs forky) to the service (in addition to the already existing architecture based navigation) which can be observed on, for instance, the Debian trixie-backports or trixie-security pages.

Tool development diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made a number of changes, including preparing and uploading versions, 312 and 313 to Debian. In particular, Chris updated the post-release deployment pipeline to ensure that the pipeline does not fail if the automatic deployment to PyPI fails [ ]. In addition, Vagrant Cascadian updated an external reference for the 7z tool for GNU Guix. [ ]. Vagrant Cascadian also updated diffoscope in GNU Guix to version 312 and 313.

Distribution work In Debian this month:

• 26 reviews of Debian packages were added, 5 were updated and 19 were removed this month adding to our extensive knowledge about identified issues.
• A new debsbom package was uploaded to unstable. According to the package description, this package generates SBOMs (Software Bill of Materials) for distributions based on Debian in the two standard formats, SPDX and CycloneDX. The generated SBOM includes all installed binary packages and also contains Debian Source packages.
• In addition, a sbom-toolkit package was uploaded, which provides a collection of scripts for generating SBOM. This is the tooling used in Apertis to generate the Licenses SBOM and the Build Dependency SBOM. It also includes dh-setup-copyright, a Debhelper addon to generate SBOMs from DWARF debug information, which are extracted from DWARF debug information by running dwarf2sources on every ELF binaries in the package and saving the output.

Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their work there.

Miscellaneous news

• S ren Tempel (nmeum) wrote up their insightful notes on Debugging Reproducibility Issues in Rust Software after nondeterministic issues were found and investigated for pimsync in the GNU Guix review process
• Jeremy Bicha reported a bug in GNOME Clocks after they noticed that version 50.beta regressed in reproducibility compared to 49.0. Specifically, the new generated .oga files differ in their Serial No. and Checksum [fields] . However, Jeremy ended up fixing the issue by replacing ffmpeg with oggenc.
• kpcyrd shared some information from the archlinux-dev-public mailing list on our mailing list this month after a discussion at our latest Summit meeting on the topic of Link-Time Optimisation (LTO) specifically on the reasons why LTO often needs to be disabled in relation to Arch Linux s approach to binary hardening.
• Janneke Nieuwenhuizen posed a question to our list about whether there might be situations where using the UNIX epoch itself (i.e. 0) may materially differ from using SOURCE_DATE_EPOCH) when a situation demands the use of a fixed timestamp.
• Laurent Huberdeau announced that they had recently finished their masters thesis arguing for the use of POSIX shell for diverse double-compilation and reproducible builds . Laurent also presents pnut, a C compiler capable of bootstrapping itself and TCC from any POSIX-compliant shell and human-readable source files.

Upstream patches The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • aiohttp
  • lima
  • meson
  • obs-studio
  • paracon
  • pyshark
  • python-flake8-comprehensions
  • server
  • vlang
• Gioele Barabucci:
  • #1127641 filed against bitsnpicas.
  • #1127643 filed against fonts-topaz-unicode.
  • #1128901 filed against bitsnpicas.

Documentation updates Once again, there were a number of improvements made to our website this month including:

• Aman Sharma added a Java reproducible builds paper to the Academic publications page. [ ]
• Chris Lamb added a reference to the repro-build to the Tools page. [ ]
• Michiel Hendriks corrected an issue on the JVM page in relation to .properties files. [ ]
• kpcyrd added Homebrew to the Who is involved page. [ ][ ]

Four new academic papers Julien Malka and Arnout Engelen published a paper titled Lila: Decentralized Build Reproducibility Monitoring for the Functional Package Management Model:

[While] recent studies have shown that high reproducibility rates are achievable at scale demonstrated by the Nix ecosystem achieving over 90% reproducibility on more than 80,000 packages the problem of effective reproducibility monitoring remains largely unsolved. In this work, we address the reproducibility monitoring challenge by introducing Lila, a decentralized system for reproducibility assessment tailored to the functional package management model. Lila enables distributed reporting of build results and aggregation into a reproducibility database [ ].

A PDF of their paper is available online.
Javier Ron and Martin Monperrus of KTH Royal Institute of Technology, Sweden, also published a paper, titled Verifiable Provenance of Software Artifacts with Zero-Knowledge Compilation:

Verifying that a compiled binary originates from its claimed source code is a fundamental security requirement, called source code provenance. Achieving verifiable source code provenance in practice remains challenging. The most popular technique, called reproducible builds, requires difficult matching and reexecution of build toolchains and environments. We propose a novel approach to verifiable provenance based on compiling software with zero-knowledge virtual machines (zkVMs). By executing a compiler within a zkVM, our system produces both the compiled output and a cryptographic proof attesting that the compilation was performed on the claimed source code with the claimed compiler. [ ]

A PDF of the paper is available online.
Oreofe Solarin of Department of Computer and Data Sciences, Case Western Reserve University, Cleveland, Ohio, USA, published It s Not Just Timestamps: A Study on Docker Reproducibility:

Reproducible container builds promise a simple integrity check for software supply chains: rebuild an image from its Dockerfile and compare hashes. We built a Docker measurement pipeline and apply it to a stratified sample of 2,000 GitHub repositories that contained a Dockerfile. We found that only 56% produce any buildable image, and just 2.7% of those are bitwise reproducible without any infrastructure configurations. After modifying infrastructure configurations, we raise bitwise reproducibility by 18.6%, but 78.7% of buildable Dockerfiles remain non-reproducible.

A PDF of Oreofe s paper is available online.
Lastly, Jens Dietrich and Behnaz Hassanshahi published On the Variability of Source Code in Maven Package Rebuilds:

[In] this paper we test the assumption that the same source code is being used [by] alternative builds. To study this, we compare the sources released with packages on Maven Central, with the sources associated with independently built packages from Google s Assured Open Source and Oracle s Build-from-Source projects. [ ]

A PDF of their paper is available online.

Finally, if you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Mastodon: @reproducible_builds@fosstodon.org
• Mailing list: rb-general@lists.reproducible-builds.org

Changes in version 0.2.8 (2026-03-12)

• Replaced Rf_error with Rcpp::stop in three files
• Maintenance updates to continuous integration

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 now sponsor me at GitHub.

• Setup management board for Qt6 migration in Lomiri [1]
• Setup management board for salsa2ubports package syncing [2]
• Bootstrap Qt 6.8 in UBports APT repository
• Bootstrap Qt 6.8 in Lomiri PPA
• Fix Salsa CI for all Lomiri-related Debian packages
• Facilitate contributor's project around XDG Desktop Portal support for Lomiri.
• Plan how to bring DeltaTouch and DeltaChat core to Debian

• Replace libofono-qt by libqofono in telepathy-ofono
• Rework unit tests in telepathy-ofono utilizing ofone-phonesim
• Obsolete not-used-anymore u1db-qt
• Fixing wrong bin:pkg names regarding snapd-glib's QML module

• qmake -> CMake porting (if needed) and Qt6 porting of shared libraries and QML modules consumed by Lomiri shell and Lomiri apps:
  • biometryd
  • libqofono
  • libqofonoext
  • libqtdbusmock
  • lomiri-account-polld
  • lomiri-action-api
  • lomiri-api
  • lomiri-download-manager
  • lomiri-location-service
  • lomiri-online-accounts
  • lomiri-push-qml
  • lomiri-push-service
  • maliit-framework
  • mediascanner2
  • qtlomiri-appmenutheme
  • qtpim (started, work in progress)
  • qwebdavlib
  • signond (flaws spotted in Debian's porting of signond to Qt6)

• Continuing with Morph Browser Qt6 / LUITK
  • Build, run and fix LUITK unit tests for Qt6
  • various bug fixes and improvements for Morph Qt6
• Add mbim modem support to ofono upstream
• Improve ofono support in Network Manager
• Improve mbim modem support in lomiri-indicator-network
• Package kazv (convergent Matrix client) and dependencies for Debian
• Provide Lomiri images for Mobian

• Research on fuse-based caching Webdav client for lomiri-cloudsync-app.
• Research on alternative ORM instead of QDjango in libusermetrics

$ dig +short IN HTTPS cloudflare-ech.com
1 . alpn="h3,h2" ipv4hint=104.18.10.118,104.18.11.118 ech=AEX+DQBBFQAgACDBFqmr34YRf/8Ymf+N5ZJCtNkLm3qnjylCCLZc8rUZcwAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700::6812:a76,2606:4700::6812:b76

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.

Debian Contributions: 2026-02 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.

DebConf 26 Registration, by Stefano Rivera, Antonio Terceiro, and Santiago Ruano Rinc n DebConf 26, to be held in Santa Fe Argentina in July, has opened for registration and event proposals. Stefano, Antonio, and Santiago all contributed to making this happen. As always, some changes needed to be made to the registration system. Bigger changes were planned, but we ran out of time to implement them for DebConf 26. All 3 of us have had experience in hosting local DebConf events in the past and have been advising the DebConf 26 local team.

Debian CI improvements, by Antonio Terceiro Debian CI is the platform responsible for automated testing of packages from the Debian archive, and its results are used by the Debian Release team automation as Quality Assurance to control the migration of packages from Debian unstable into testing, the base for the next Debian release. Antonio started developing an incus backend, and that prompted two rounds of improvements to the platform, including but not limited to allowing user to select a job execution backend (lxc, qemu) during the job submission, reducing the part of testbed image creation that requires superuser privileges and other refactorings and bug fixes. The platform API was also improved to reduce disruption when reporting results to the Release Team automation after service downtimes. Last, but not least, the platform now has support for testing packages against variants of autopkgtest, which will allow the Debian CI team to test new versions of autopkgtest before making releases to avoid widespread regressions.

Miscellaneous contributions

• Carles improved po-debconf-manager while users requested features / found bugs. Improvements done - add packages from unstable instead of just salsa.debian.org, upgrade and merge templates of upgraded packages, finished adding typing annotations, improved deleting packages: support multiple line texts, add debug to see subprocess.run commands, etc.
• Carles, using po-debconf-manager, reviewed 7 Catalan translations and sent bug reports or MRs for 11 packages. Also reviewed the translations of fortunes-debian-hints and submitted possible changes in the hints.
• Carles submitted MRs for reportbug (reportbug --ui gtk detecting the wrong dependencies), devscript (delete unused code from debrebuild and add recommended dependency), wcurl (format help for 80 columns). Carles submitted a bug report for apt not showing the long descriptions of packages.
• Carles resumed effort for checking relations (e.g. Recommends / Suggests) between Debian packages. A new codebase (still in early stages) was started with a new approach in order to detect, report and track the broken relations.
• Emilio drove several transitions, most notably the haskell transition and the glibc/gcc-15/zlib transition for the s390 31-bit removal. This last one included reviewing and requeueing lots of autopkgtests due to britney losing a lot of results.
• Emilio reviewed and uploaded poppler updates to experimental for a new transition.
• Emilio reviewed, merged and deployed some performance improvements proposed for the security-tracker.
• Stefano prepared routine updates for pycparser, python-confuse, python-cffi, python-mitogen, python-pip, wheel, platformdirs, python-authlib, and python-virtualenv.
• Stefano updated Python 3.13 and 3.14 to the latest point releases, including security updates, and did some preliminary work for Python 3.15.
• Stefano reviewed changes to dh-python and merged MRs.
• Stefano did some debian.social sysadmin work, bridging additional IRC channels to Matrix.
• Stefano and Antonio, as DebConf Committee Members, reviewed the DebConf 27 bids and took part in selecting the Japanese bid to host DebConf 27.
• Helmut sent patches for 29 cross build failures.
• Helmut continued to maintain rebootstrap addressing issues relating to specific architectures (such as musl-linux-any, hurd-any or s390x) or specific packages (such as binutils, brotli or fontconfig).
• Helmut worked on diagnosing bugs such as rocblas #1126608, python-memray #1126944 upstream and greetd #1129070 with varying success.
• Antonio provided support for multiple MiniDebConfs whose websites run wafer + wafer-debconf (the same stack as DebConf itself).
• Antonio fixed the salsa tagpending webhook.
• Antonio sent specinfra upstream a patch to fix detection of Debian systems in some situations.
• Santiago reviewed some Merge Requests for the Salsa CI pipeline, including !703 and !704, that aim to improve how the build source job is handled by Salsa CI. Thanks a lot to Jochen for his work on this.
• In collaboration with Emmanuel Arias, Santiago proposed a couple of projects for the Google Summer of Code (GSoC) 2026 round. Santiago has been reviewing applications and giving feedback to candidates.
• Thorsten uploaded new upstream versions of ipp-usb, brlaser and gutenprint.
• Rapha l updated publican to fix an old bug that became release critical and that happened only when building with the nocheck profile. Publican is a build dependency of the Debian s Administrator Handbook and with that fix, the package is back into testing.
• Rapha l implemented a small feature in Debusine that makes it possible to refer to a collection in a parent workspace even if a collection with the same name is present in the current workspace.
• Lucas updated the current status of ruby packages affecting the Ruby 3.4 transition after a bunch of updates made by team members. He will follow up on this next month.
• Lucas joined the Debian orga team for GSoC this year and tried to reach out to potential mentors.
• Lucas did some content work for MiniDebConf Campinas - Brazil.
• Colin published minor security updates to bookworm and trixie for CVE-2025-61984 and CVE-2025-61985 in OpenSSH, both of which allowed code execution via ProxyCommand in some cases. The trixie update also included a fix for mishandling of PerSourceMaxStartups.
• Colin spotted and fixed a typo in the bug tracking system s spam-handling rules, which in combination with a devscripts regression caused bts forwarded commands to be discarded.
• Colin ported 12 more Python packages away from using the deprecated (and now removed upstream) pkg_resources module.
• Anupa is co-organizing MiniDebConf Kanpur with Debian India team. Anupa was responsible for preparing the schedule, publishing it on the website, co-ordination with the fiscal host in addition to attending meetings.
• Anupa attended the Debian Publicity team online sprint which was a skill sharing session.

So you want to join Outreachy but you don t understand it, you re scared, or you don t know what open source is about.

What is FOSS anyway?

Free and Open Source Software (FOSS) refers to software that anyone can use, modify, and share freely. Think of it as a community garden; instead of one company owning the food, people from all over the world contribute, improve, and maintain it so everyone can benefit for free. You can read more here on what it means to contribute to open source.

Outreachy provides paid internships to anyone from any background who faces underrepresentation, systemic bias, or discrimination in the technical industry where they live. Their goal is to increase diversity in open source. Read their website for more. I spent a good amount of time reading all the guides listed, including the applicant guide and the how-to-apply guide.

The Secret to Applying (Spoiler: It s not a secret)

I know newcomers are scared or unsure and would prefer answers from previous participants, but the Outreachy website is actually a goldmine, almost every question you have is already answered there if you look closely. I used to hate reading documentation, but I ve learned to love it. Documentation is the Source of Truth.

• My Advice: Read every single guide on their site. The applicant guide is your roadmap. Embracing documentation now will make you a much better contributor later.

The AI Trap: Be Yourself

Now for the part most newcomers have asked about is the initial essay. I know it s tempting to use AI, but I really encourage you to skip it for this. Your own story is much more powerful than a generated one. Outreachy and its mentoring organizations value your unique story. They are strongly against fabricated or AI-exaggerated essays.

For example, when I contributed to Debian using openQA, the information wasn t well established on the web. When I tried to use AI, it suggested imaginary ideas. The project maintainers had a particular style of contributing, so I had to follow the instructions carefully, observe the codebase, and read the provided documentation. With that information, I always wrote a solution first before consulting AI, and mine was always better. AI can only be intelligent in the context of what you give it; if it doesn t have your answer, it will look for the most similar solution (hallucinate). We do not want to increase the burden on reviewers their time is important because they are volunteers, too. This is crucial when you qualify for the contribution phase.

The Application Process

There are two main stages:

• The initial application: Here you fill in basic details, time availability, and essay questions (you can find these on the Outreachy website).
• The contribution phase: This is where you show you have the skills to work on the projects. Every project will list the skills needed and the level of proficiency.

When you qualify for the contribution phase:

• A lot of people will try to create buzz or even panic; you just have to focus. Once you ve gotten the hang of the project, remember to help others along the way.
• You can start contributions with spelling corrections, move to medium tasks (do multiple of these), then a hard task if possible. You don t need to be a guru on day one.
• It s all about community building. Do your part to help others understand the project too; this is also a form of contribution.
• Lastly, every project mentor has a way of evaluating candidates. My summary is: be confident, demonstrate your skills, and learn where you are lacking. Start small and work your way up, you don t have to prove yourself as a guru.

Tips

• Watch this: This step-by-step video is a great walkthrough of the initial application process.
• Sign up for the email list to get updates: https://lists.outreachy.org/cgi-bin/mailman/listinfo/announce
• Be fast: Complete your initial application in the first 3 days, as there are a lot of applicants.
• Back it up: In your essay about systemic bias, include some statistics to back it up.
• Learn Git: Even if you don t have programming skills, contributions are pushed to GitHub or GitLab. Practice some commands and contribute to a first open issue to understand the flow: https://github.com/firstcontributions/first-contributions

The most important tip? Apply anyway. Even if you feel underqualified, the process itself is a massive learning experience.

Changes in version 0.3.13 (2026-03-08)

• The methods package is now a Depends as WRE recommends (Michael Chirico in #141 based on a suggestion by Dirk in #140)
• The mkdocs-material documentation site is now generated via altdoc
• Continuous Integration scripts have been updated
• Replace Rf_error with Rcpp::stop, turn remaining one into (Rf_error) (Dirk in #143)
• Vignette now uses the Rcpp::asis builder for pre-made pdfs (Dirk in #146 fixing #144)
• The C++ compilation standard is explicitly set to C++17 if an R version older than 4.3.0 is used (Dirk in #148 fixing #147)
• The vignette references have been updated

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 now sponsor me at GitHub.

• openssh: Please remove/replace usage of dh_movetousr

• aiosmtplib
• bitstruct
• diff-cover
• django-q
• isort
• multipart
• poetry (adding support for Dulwich >= 0.25)
• poetry-core
• pydantic-settings
• python-build
• python-certifi
• python-datamodel-code-generator
• python-flatdict
• python-holidays
• python-maggma
• python-pytokens
• python-scruffy
• python-urllib3 (fixing CVE-2025-66471 and a chunked decoding bug)
• responses
• yarsync
• zope.component
• zope.deferredimport

• genshi (contributed upstream)
• germinate
• mopidy
• nose2
• pokrok (contributed upstream)
• pylama
• python-flask-seeder
• python-maggma (contributed upstream)
• python-pybadges
• python-scruffy (contributed upstream)
• thumbor (contributed upstream)
• zope.deprecation (contributed upstream a while ago, but there hasn t been an upstream release yet)

• flask-dance: FTBFS: No module named pkg_resources (actually fixed by adding a missing dependency to python3-sphinxcontrib.seqdiag)
• paramiko: autopkgtest regression on i386 (contributed upstream)
• poetry: autopkgtest regression on i386
• python-argh
• python-django-celery-beat: FTBFS: FAILED t/unit/test_models.py::HumanReadableTestCase::test_long_name
• python-maturin: rust-itertools update
• python-msrest: FTBFS: FAILED tests/asynctests/test_async_client.py::TestServiceClient::test_client_send (contributed upstream, though not very successfully)
• python-typing-inspect

• python-datamodel-code-generator: Depends: python3-isort (< 8) but 8.0.0-1 is to be installed (contributed upstream)
• python-typeguard: Mark python3-typeguard Multi-Arch: foreign
• wheel: Mark python3-wheel Multi-Arch: foreign
• zope.deferredimport: Please make the build reproducible (contributed upstream, with a follow-up fix)

• librust-pyo3-ffi-dev: Cannot be installed for foreign architectures

• arch-test: Remove build dependency on binutils-mips64el-linux-gnuabi64 (NMU)

• debconf: Add BMP version of debian-logo (merged and uploaded)
• openssh: Reorder pam_selinux(7) usage (merged and uploaded)
• openssh-client: use sysusers.d, drop superflous dependencies (merged and uploaded)
• openssh: Stop deleting system user on remove/purge (merged and uploaded)
• openssh: Do not link against libcrypt on GNU/Hurd (merged and uploaded)
• partman-prep: Align PReP descriptions with other partition types (merged)
• python-better-exceptions (sponsored upload for Seyed Mohamad Amin Modaresi)

$ cat /etc/apt/sources.list.d/unstable.sources
Types: deb
URIs: http://deb.debian.org/debian
Suites: unstable 
Components: main
#This will work with apt 3.1 or later:
#Include: pflogsumm
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp
$ cat /etc/apt/preferences.d/pflogsumm-unstable.pref 
Package: pflogsumm
Pin: release a=unstable
Pin-Priority: 950
Package: *
Pin: release a=unstable
Pin-Priority: 50

$ apt-cache policy pflogsumm
pflogsumm:
  Installed: (none)
  Candidate: 1.1.14-1
  Version table:
     1.1.14-1 950
        50 http://deb.debian.org/debian unstable/main amd64 Packages
     1.1.5-8 500
       500 http://deb.debian.org/debian trixie/main amd64 Packages

This post is an unpublished review for As Answers Get Cheaper, Questions Grow Dearer

Changes in RProtoBuf version 0.4.26 (2026-03-06)

• Minor cleanup in DESCRIPTION depends and imports
• Remove obsolete check for utils::.DollarNames (Michael Chirico in #111)
• Replace Rf_error with Rcpp::stop, turn remaining one into (Rf_error) (Dirk in #112)
• Update configure test to check for RProtoBuf 3.3.0 or later

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.

• [DLA 4474-1] rlottie security update to fix three CVEs related to boundary checks.
• [DLA 4477-1] munge security update to fix one CVE related to a buffer overflow.
• [DLA 4483-1] gimp security update to fix four CVEs related to arbitrary code execution.
• [DLA 4487-1] gegl security update to fix two CVEs related to heap-based buffer overflow.
• [DLA 4489-1] libvpx security update to fix one CVE related to a buffer overflow.
• [ELA-1649-1] gimp security update to fix three CVEs in Buster and Stretch related to arbitrary code execution.
• [ELA-1650-1] gegl security update to fix two CVEs in Buster and Stretch related to heap-based buffer overflow.

• ipp-usb to unstable.
• brlaser to unstable.
• gutenprint to unstable.

• c-munipack to unstable. This package now contains a version without GTK support. Upstream is working on a port to GTK3 but seems to need some more time to finish this.
• libasi to unstable.
• libdfu-ahp to unstable.
• libfishcamp to unstable.
• libinovasdk to unstable.
• libmicam to unstable.
• siril to unstable (sponsored upload).

• pyicloud to unstable.

• libsmpp34 to unstable.

• nuspell to unstable.

• [1] https://tinyurl.com/2ypyzh5w
• [2] https://tinyurl.com/2b9kyl5x
• [3] https://aigarius.com/blog/2026/01/07/sedan-experience/
• [4] https://tinyurl.com/23ekabmj
• [5] https://pluralistic.net/2026/01/30/zucksauce/#gandersauce
• [6] https://tinyurl.com/29j6zzyc
• [7] https://tinyurl.com/2xvfmslu
• [8] https://tinyurl.com/2b7m8pwa
• [9] https://en.wikipedia.org/wiki/Scsh
• [10] https://tinyurl.com/2aajkoyv
• [11] https://tinyurl.com/ywd3kqel
• [12] https://tinyurl.com/2cqep7cj
• [13] https://radleybalko.substack.com/p/the-courage-to-be-decent
• [14] https://serpapi.com/blog/every-google-udm-in-the-world/
• [15] https://theproof.com/eating-oysters-and-mussels-as-a-vegan/
• [16] https://tinyurl.com/229soykv

Why? The main reason why I'm retiring Wallabako is that I have completely stopped using it. It's not the first time: for a while, I wasn't reading Wallabag articles on my Kobo anymore. But I had started working on it again about four years ago. Wallabako itself is about to turn 10 years old. This time, I stopped using Wallabako because there's simply something better out there. I have switched away from Wallabag to Readeck! And I'm also tired of maintaining "modern" software. Most of the recent commits on Wallabako are from renovate-bot. This feels futile and pointless. I guess it must be done at some point, but it also feels we went wrong somewhere there. Maybe Filippo Valsorda is right and one should turn dependabot off. I did consider porting Wallabako to Readeck for a while, but there's a perfectly fine Koreader plugin that I've been pretty happy to use. I was worried it would be slow (because the Wallabag plugin is slow), but it turns out that Readeck is fast enough that this doesn't matter.

Moving from Wallabag to Readeck Readeck is pretty fantastic: it's fast, it's lightweight, everything Just Works. All sorts of concerns I had with Wallabag are just gone: questionable authentication, questionable API, weird bugs, mostly gone. I am still looking for multiple tags filtering but I have a much better feeling about Readeck than Wallabag: it's written in Golang and under active development. In any case, I don't want to throw shade at the Wallabag folks either. They did solve most of the issues I raised with them and even accepted my pull request. They have helped me collect thousands of articles for a long time! It's just time to move on. The migration from Wallabag was impressively simple. The importer is well-tuned, fast, and just works. I wrote about the import in this issue, but it took about 20 minutes to import essentially all articles, and another 5 hours to refresh all the contents. There are minor issues with Readeck which I have filed (after asking!):

• add justified view for articles (Android app)
• more metadata in article display (Android app)
• show the number of articles in the label browser
• ignore duplicates (Readeck will happily add duplicates, whereas Wallabag at least tries to deduplicate articles -- but often fails)

But overall I'm happy and impressed with the result. I'm also both happy and sad at letting go of my first (and only, so far) Golang project. I loved writing in Go: it's a clean language, fast to learn, and a beauty to write parallel code in (at the cost of a rather obscure runtime). It would have been much harder to write this in Python, but my experience in Golang helped me think about how to write more parallel code in Python, which is kind of cool. The GitLab project will remain publicly accessible, but archived, for the foreseeable future. If you're interested in taking over stewardship for this project, contact me. Thanks Wallabag folks, it was a great ride!

Changes in version 0.3.14 (2026-03-05)

• Updated some internals of fastLm example, and regenerated RcppExports.* files
• Several updates for continuous integration
• Switched to using Authors@R
• Replace ::Rf_error with (Rf_error) in old example to aid Rcpp transition to Rcpp::stop (or this pass-through)
• Vignette now uses the Rcpp::asis builder for pre-made pdfs
• Vignette references have been updated, URLs prefer https and DOIs

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 now sponsor me at GitHub.

Traefik & Docker Traefik listens for events on the Docker socket. Each service advertises its configuration through labels. For example, here is the Loki service in Akvorado:

services:
  loki:
    #  
    expose:
      - 3100/tcp
    labels:
      - traefik.enable=true
      - traefik.http.routers.loki.rule=PathPrefix( /loki )

Once the container is healthy, Traefik creates a router forwarding requests matching /loki to its first exposed port. Colocating Traefik configuration with the service definition is attractive. How do we achieve the same for Prometheus metrics?

Metrics discovery with Alloy Grafana Alloy, a metrics collector that scrapes Prometheus endpoints, includes a discovery.docker component. Just like Traefik, it connects to the Docker socket.¹ With a few relabeling rules, we teach it to use Docker labels to locate and scrape metrics. We define three labels on each service:

• metrics.enable set to true enables metrics collection,
• metrics.port specifies the port exposing the Prometheus endpoint, and
• metrics.path specifies the path to the metrics endpoint.

If a service exposes more than one port, metrics.port is mandatory. Otherwise, it defaults to the only exposed port. The default value for metrics.path is /metrics. The Loki service from earlier becomes:

services:
  loki:
    #  
    expose:
      - 3100/tcp
    labels:
      - traefik.enable=true
      - traefik.http.routers.loki.rule=PathPrefix( /loki )
      - metrics.enable=true
      - metrics.path=/loki/metrics

Alloy s configuration is split into four parts:

1. discover containers through the Docker socket,
2. filter and relabel targets using Docker labels,
3. scrape the matching endpoints, and
4. forward the metrics to Prometheus.

Discovering Docker containers The first building block discovers running containers:

discovery.docker "docker"  
  host             = "unix:///var/run/docker.sock"
  refresh_interval = "30s"
  filter  
    name   = "label"
    values = ["com.docker.compose.project=akvorado"]
   
 

This connects to the Docker socket and lists containers every 30 seconds.² The filter block restricts discovery to containers belonging to the akvorado project, avoiding interference with unrelated containers on the same host. For each discovered container, Alloy produces a target with labels such as __meta_docker_container_label_metrics_port for the metrics.port Docker label.

Relabeling targets The relabeling step filters and transforms raw targets from Docker discovery into scrape targets. The first stage keeps only targets with metrics.enable set to true:

discovery.relabel "prometheus"  
  targets = discovery.docker.docker.targets
  // Keep only targets with metrics.enable=true
  rule  
    source_labels = ["__meta_docker_container_label_metrics_enable"]
    regex         =  true 
    action        = "keep"
   
  //  
 

The second stage overrides the discovered port when the service defines metrics.port:

// When metrics.port is set, override __address__.
rule  
  source_labels = ["__address__", "__meta_docker_container_label_metrics_port"]
  regex         =  (.+):\d+;(.+) 
  target_label  = "__address__"
  replacement   = "$1:$2"
 

Next, we handle containers in host network mode. When __meta_docker_network_name equals host, Alloy rewrites the address to host.docker.internal instead of localhost:³

// When host networking, override __address__ to host.docker.internal.
rule  
  source_labels = ["__meta_docker_container_label_metrics_port", "__meta_docker_network_name"]
  regex         =  (.+);host 
  target_label  = "__address__"
  replacement   = "host.docker.internal:$1"
 

The next stage derives the job name from the service name, stripping any numbered suffix. The instance label is the address without the port:

rule  
  source_labels = ["__meta_docker_container_label_com_docker_compose_service"]
  regex         =  (.+)(?:-\d+)? 
  target_label  = "job"
 
rule  
  source_labels = ["__address__"]
  regex         =  (.+):\d+ 
  target_label  = "instance"
 

If a container defines metrics.path, Alloy uses it. Otherwise, it defaults to /metrics:

rule  
  source_labels = ["__meta_docker_container_label_metrics_path"]
  regex         =  (.+) 
  target_label  = "__metrics_path__"
 
rule  
  source_labels = ["__metrics_path__"]
  regex         = ""
  target_label  = "__metrics_path__"
  replacement   = "/metrics"
 

Scraping and forwarding With the targets properly relabeled, scraping and forwarding are straightforward:

prometheus.scrape "docker"  
  targets         = discovery.relabel.prometheus.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
 
prometheus.remote_write "default"  
  endpoint  
    url = "http://prometheus:9090/api/v1/write"
   
 

prometheus.scrape periodically fetches metrics from the discovered targets. prometheus.remote_write sends them to Prometheus.

Built-in exporters Some services do not expose a Prometheus endpoint. Redis and Kafka are common examples. Alloy ships built-in Prometheus exporters that query these services and expose metrics on their behalf.

prometheus.exporter.redis "docker"  
  redis_addr = "redis:6379"
 
discovery.relabel "redis"  
  targets = prometheus.exporter.redis.docker.targets
  rule  
    target_label = "job"
    replacement  = "redis"
   
 
prometheus.scrape "redis"  
  targets         = discovery.relabel.redis.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
 

The same pattern applies to Kafka:

prometheus.exporter.kafka "docker"  
  kafka_uris = ["kafka:9092"]
 
discovery.relabel "kafka"  
  targets = prometheus.exporter.kafka.docker.targets
  rule  
    target_label = "job"
    replacement  = "kafka"
   
 
prometheus.scrape "kafka"  
  targets         = discovery.relabel.kafka.output
  forward_to      = [prometheus.remote_write.default.receiver]
  scrape_interval = "30s"
 

Each exporter is a separate component with its own relabeling and scrape configuration. We set the job label explicitly since no Docker metadata can provide it.

---

With this setup, adding metrics to a new service with a Prometheus endpoint requires only a few labels in docker-compose.yml, just like adding a Traefik route. Alloy picks it up automatically. You can apply the same pattern with another discovery method, like discovery.kubernetes, discovery.scaleway, or discovery.http.

---

1. Both Traefik and Alloy require access to the Docker socket, which grants root-level access to the host. A Docker socket proxy mitigates this by exposing only the read-only API endpoints needed for discovery.
2. Unlike Traefik, which watches for events, Grafana Alloy polls the container list at regular intervals a behavior inherited from Prometheus.
3. The Alloy service needs extra_hosts: ["host.docker.internal:host-gateway"] in its definition.

• 190g plain flour
• 60g strong white bread flour
• 4 tsp baking powder
• tsp bicarbonate of soda
• 1 tsp cream of tartar (optional)
• 1 tsp salt
• 100g unsalted butter
• 180ml buttermilk, chilled
  • If your buttermilk is thicker than the consistency of ordinary milk, you ll need around 200ml.
• extra buttermilk for brushing

1. Slice and then chill the butter in the freezer for at least fifteen minutes.
2. Preheat oven to 220 C with the fan turned off.
3. Twice sieve together the flours, leaveners and salt. Some salt may not go through the sieve; just tip it back into the bowl.
4. Cut cold butter slices into the flour with a pastry blender until the mixture resembles coarse crumbs: some small lumps of fat remaining is desirable. In particular, the fine crumbs you are looking for when making British scones are not wanted here. Rubbing in with fingertips just won t do; biscuits demand keeping things cold even more than shortcrust pastry does.
5. Make a well in the centre, pour in the buttermilk, and stir with a metal spoon until the dough comes together and pulls away from the sides of the bowl. Avoid overmixing, but I ve found that so long as the ingredients are cold, you don t have to be too gentle at this stage and can make sure all the crumbs are mixed in.
6. Flour your hands, turn dough onto a floured work surface, and pat together into a rectangle. Some suggest dusting the top of the dough with flour, too, here.
7. Fold the dough in half, then gather any crumbs and pat it back into the same shape. Turn ninety degrees and do the same again, until you have completed a total of eight folds, two in each cardinal direction. The dough should now be a little springy.
8. Roll to about inch thick.
9. Cut out biscuits. If using a round cutter, do not twist it, as that seals the edges of the biscuits and so spoils the layering.
10. Transfer to a baking sheet, placed close together (helps them rise). Flour your thumb and use it to press an indent into the top of each biscuit (helps them rise straight), brush with buttermilk.
11. Bake until flaky and golden brown: about fifteen minutes.

• These biscuits do come out fluffy but not so flaky. For that you can try using lard instead of butter, if you re not vegetarian (vegetable shortening is hard to find here).
• If you don t have a pastry blender and don t want to buy one you can try not slicing the butter and instead coarsely grating it into the flour out of the freezer.
• An alternative to folding is cutting and piling the layers.
• You can try rolling out to 1 1 inches thick.
• Instead of cutting out biscuits you can just slice the whole piece of dough into equal pieces. An advantage of this is that you don t have to re-roll, which latter also spoils the layering.
• Instead of brushing with buttermilk, you can take them out after they ve started to rise but before they ve browned, brush them with melted butter and put them back in.

• I ve had more success with Dale Farm s buttermilk than Sainsbury s own. The former is much runnier.
• Southern culture calls for biscuits to be made the size of cat s heads.
• Bleached flour is apparently usual in the South, but is illegal(!) here. Apparently bleaching can have some effect on the development of the gluten which would affect the texture.
• British plain flour is made from soft wheat and has a lower percentage of protein/gluten, while American all-purpose flour is often(?) made from harder wheat and has more protein. In this recipe I mix plain and strong white flour, in a ratio of 3:1, to emulate American all-purpose flour. I am not sure why this works best. In the South they have soft wheats too, and lower protein percentages. The famous White Lily flour is 9%. (Apparently you can mix US cake flour and US all-purpose flour in a ratio of 1:1 to achieve that; in the UK, Shipton Mill sell a soft cake and pastry flour which has been recommended to me as similar.) This would suggest that British plain flour ought to be closer to Southern flour than the standard flour available in most of the US. But my experience has been that the biscuits taste better with the plain and strong white 3:1 mix. Possibly Southeners would disprefer them. I got some feedback that good biscuits are about texture and moistness and not flavour.
• Baking powder in the US is usually double-acting but ours is always single-acting, so we need double quantities of that.