Welcome to the September 2026 report from the Reproducible Builds project! In our reports, we try to outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not. As ever, if you are interested in contributing to the project, please visit our Contribute page on our website. In this month s report, we cover:

1. Reproducible Builds Summit 2026 held in Gothenburg, Sweden
2. dettrace expanding architecture support for PGO & Lisp dumps
3. They don t care about this!
4. SOURCE_DATE_EPOCH specification updates
5. Reproducible Builds at SeaGL 2026
6. New Code of Conduct (CoC)
7. Supporter Spotlight: Jochen Sprickerhof
8. Mailing list news
9. Tool and documentation development
10. Patches

Reproducible Builds Summit 2026 held in Gothenburg, Sweden The annual Reproducible Builds summit took place from 22 to 24 September 2026 in Gothenburg, Sweden. The event brought together developers, distribution maintainers, security researchers and free software advocates from across the ecosystem to share updates on current initiatives, address outstanding toolchain bottlenecks and strengthen cross-project collaboration. Participants engaged in a series of working sessions and technical roundtables focused on expanding the practical scope of reproducibility. Discussions covered ongoing work within major Linux distributions, language-specific package ecosystems and the various parts of the binary verification infrastructure. Strategic planning formed a pillar of the gathering, with participants discussing long-term roadmap goals for supply-chain security, software integrity and related topics. Attendees explored new methods for automated verification, discussing how to lower the adoption barriers for maintainers and streamline the integration of deterministic build pipelines into established continuous integration (CI) systems. The event was then followed by two days of unmoderated hacking sessions. These hacking sessions provided space for technical progress, allowing attendees to draft specification updates, prototype new tool features and resolve standing reproducibility bugs in-person.

Dettrace expanding architecture support for PGO & Lisp dumps Bernhard M. Wiedemann announced major updates to dettrace, porting the tool across most architectures supported by Debian and openSUSE. The release addresses key stability issues, passing test suites across these targets and making it ready for production build pipelines. These improvements enable deterministic builds when utilising Profile-Guided Optimisations (PGO), removing the need to sacrifice runtime performance for reproducibility. Additionally, dettrace can now be applied to (notoriously difficult-to-reproduce) Lisp and Scheme memory dumps, including environments such as CLISP, SBCL, Scheme 48, Racket and GNU Emacs.

They don t care about this Annika Wilde, Marco Gutfleisch, Felix Reichmann, Anirban Chakraborty, Yuval Yarom, M. Angela Sasse and Ghassan Karame published a paper this month entitled They don t care about this : A Systematic Study of Trusted Execution Environments Build Reproducibility in the Wild:

Trusted Execution Environments (TEEs) have become a cornerstone of modern cloud computing, providing strong confidentiality and integrity guarantees for both code and data. A critical component of this trust model is remote attestation, which enables external entities to verify the authenticity and integrity of code executing within a TEE through cryptographic measurements. However, the effectiveness of remote attestation fundamentally depends on the verifier s ability to trace the reported measurement back to the original source code - a property that can only be guaranteed through reproducible builds. [ ]

The full PDF can be read online.

SOURCE_DATE_EPOCH specification updates Bernhard M. Wiedemann shared a number of proposals regarding updating the SOURCE_DATE_EPOCH specification following discussions at a project summit. Seven distinct proposed changes have been submitted as merge requests on Salsa. Bernhard s proposed modifications are independent of one another, allowing for any combination to be merged depending on community feedback. Bernhard noted that one proposal may see the most debate, and could still benefit from further refinement before reaching consensus. Community members are invited to review and provide feedback on the individual merge requests by 1 December 2026. Input can be submitted via reactions or comments on Salsa, directly by email to Bernhard or the mailing list. The specification was first published in 2015 and updated in 2017.

Reproducible Builds at SeaGL 2026 Reproducible Builds will be present at SeaGL in Seattle, WA, on October 23rd & 24th. Come chat with us in person! Founded in 2013, SeaGL is a free, grassroots technical summit dedicated to spreading awareness and knowledge about free source software, hardware and culture.

New Code of Conduct (CoC) for the Reproducible Builds project Mattia Rizzolo announced the official launch of a Code of Conduct for the Reproducible Builds project. This follows work and community discussions originally initiated in 2024, incorporating feedback gathered over email and during project summits, as well as with input from the Software Freedom Conservancy. The new Code of Conduct establishes guidelines emphasising mutual respect among project contributors. It also defines a formalised process for submitting and handling complaints regarding community misconduct, ensuring transparent governance across project spaces. Along with the core policy document, an accompanying Code of Conduct FAQ has been published to outline the rationale behind adopting the guidelines.

Supporter Spotlight: Jochen Sprickerhof As a reminder, another supporter spotlight interview was published featuring long-time Debian and Reproducible Builds contributor Jochen Sprickerhof, highlighting his work on package verification and project infrastructure.

Mailing list news On our mailing list this month:

• Jonathan Starr from the Institute of Open Science Practices (IOSP) posted with an announcement of its upcoming 2026 workshop series in Leiden in the Netherlands. This free-to-attend event aims to build a participant-owned data storage consortium, allowing community members to publish datasets, code and knowledge objects alongside algorithms designed to evaluate trust and value. The event features a dedicated Community Track for talks and discussions, a tool showcase and an opening session on resilient data storage.
• Following up on IRC discussions regarding profile-guided optimization (PGO) on build servers, kpcyrd created a demonstration repository showing how PGO profiling can introduce non-determinism into output binaries. The demo highlights how runtime randomness (specifically, the randomised keys used in HashMaps to prevent denial-of-service attacks) causes varying bucket collision rates during test runs. These structural variances alter execution weights on underlying code branches, prompting the compiler to generate differing final assembly output for builds that would otherwise be perfectly reproducible if PGO was disabled. Rather than abandoning PGO performance gains, kpcyrd suggested treating generated profiling data as a documented build input or recorded environment artifact (similar to .buildinfo files), rather than regenerating profiles dynamically on the fly during build execution.
• An autonomous AI agent (!), posted a controlled build result and reproducer demonstrating that pre-creating an obj directory in libmilter source trees prevents kernel-release path leaks (obj.Linux.<release>.x86_64) into debugging symbols. kpcyrd followed up with a helpful reply.
• Alexander Sosedkin inquired on the mailing list about the preferred approach for sourcing pinned translation files to create reproducible GnuTLS release tarballs, asking whether external hosting should provide versioned downloads, or if projects ought to use Git submodules, dedicated side-repositories or some other mechanism.

Tool and documentation 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 330, 331 and 332 to Debian. In particular, Chris committed support for radare2 versions greater than 5.9.0 [ ] based on input from Guillaume Girol [ ], and committed support for .nar files via Guix. [ ][ ]. Chris later modified diffoscope to not Build-Depend on the Debian package of GNU Guix, as its status in the Debian bug tracking system would transitively render diffoscope as being overly buggy for the next stable release [ ]. Similarly, he adjusted the Build-Depends on the apksigcopier package as it has been removed from Debian testing [ ] and, finally, he updated a number of copyright years [ ][ ]. Vagrant Cascadian updated diffoscope in GNU Guix to version 332.
reprotest is our tool for building the same source code twice in different environments and then checking the binaries produced by each build for any differences. This month, reprotest version 0.7.33 was uploaded to Debian by Holger Levsen with the following changes:

• Sergei Tachenov fixed the fileordering test on all filesystems, including the likes of ZFS, which could return a different order across two builds due to build being done in a different directory [ ].
• Holger Levsen bumped the Standards-Version to 4.7.4, reflected that Priority: optional is the default now [ ], fixed the old Free Software Foundation address [ ] and bumped the debhelper compat level to 14 after confirming there are only desired changes [ ].
• Vagrant Cascadian updated *reprotest* to version 0.7.33 in GNU Guix.

rebuilderd, our server designed monitor the official package repositories of Linux distributions and attempt to reproduce the observed results there; it powers, amongst other things, reproduce.debian.net. This month, Bernhard M. Wiedemann submitted a pull request to rebuilderd that refactors RPM repository metadata handling. The change extracts rpm-md parsing out of the Fedora-specific scheduler module and into a shared one.
Lastly, there were a number of improvements made to our website this month as well. For example:

• Chris Lamb:
  • Added a note re. TZ=UTC vs. TZ=UTC0 to the Timezones page. [ ][ ][ ]
  • Make a bunch of cosmetic updates to Jochen s supporter spotlight. [ ]
• Holger Levsen made a very large number of changes to the Gothenburg summit page. [ ][ ][ ][ ][ ][ ]
• Jochen Sprickerhof wrote and published another supporter spotlight. [ ][ ][ ][ ][ ]
• Mattia Rizzolo:
  • Made a number of changes to the Gothenburg summit page. [ ][ ][ ][ ][ ]
  • Add and publish the new Code of Conduct. [ ][ ][ ]
  • Update translation POs. [ ]
• kpcyrd also made a number of changes to the Gothenburg summit page. [ ][ ][ ][ ]

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 applicable or possible. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • apache-arrow
  • dtaidistance
  • gcc 3.3
  • gcc 4.8
  • gcc 7
  • golang-github-prometheus-prometheus
  • gromacs
  • jason
  • lkl
  • ltfat
  • memory-constraints
  • MozillaFirefox
  • obs-build
  • obs-build
  • otp
  • pythia
  • python-autobahn
  • python-django-cacheops
  • python-hdf5plugin
  • python-mypy
  • python-slycot
  • qt6-base
  • rpm
  • rust1.98
  • rusty_v8
  • scotch
  • vlang
• Chris Lamb:
  • #1146687 filed against lektor.
  • #1147673 filed against golang-forgejo-xorm-xorm.
  • #1147674 filed against python-vermin.
  • #1148657 filed against python-eventlet.
  • #1148658 filed against golang-github-miekg-pkcs11.
  • #1148660 filed against python-prov.
  • #1148973 filed against lemonade.
  • #1148977 filed against yuzu.
  • #1148979 filed against python-mne.
• Jochen Sprickerhof:
  • #1147645 filed against bitshuffle.
• Tianyu Chen:
  • #1147760 filed against nss.
• Klemen Ferjancic:
  • Debian:
    • ace-of-penguins
    • fonts-meera-inimai
    • fonts-smc-keraleeyam
    • nsnake
    • reprotest
  • Upstream:
    • doxygen
    • fontforge
    • freefont
    • openstack oslo.config
    • openstack watcher
    • systemtap
    • util-linux
    • yudit
• Vagrant Cascadian:
  • libecoli [ ]
  • cdebootstrap [ ]

Vagrant Cascadian also performed a number of Non-Maintainer Uploads (NMUs) and Quality Assurance (QA) uploads in Debian for several packages with outstanding reproducibility issues. These included molttemplate, buddy, xfonts-nexus, fte and lifelines. At the time of this writing, that leaves 130 submitted patches, with only 61 outstanding submitted patches that older than a year in the Debian bug tracking system. This number is only 26 if we exclude any low-priority build path issues.

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

• beaker (contributed supporting fix upstream)
• bitstruct
• cachelib
• dep-logic
• django-guardian
• django-oauth-toolkit (fixing use of an old Bootstrap version)
• django-polymorphic (contributed supporting fix upstream)
• djangorestframework (fixing CVE-2026-73228 and CVE-2026-73229)
• flask-security
• isort
• langtable
• magic-wormhole-mailbox-server (fixing use of pkg_resources)
• multipart
• nagiosplugin
• poetry-plugin-export
• proglog (fixing use of pkg_resources)
• prospector (fixing use of pkg_resources)
• pybind11-stubgen
• pydantic
• pydantic-core
• pytest-rerunfailures
• python-anyio (fixing CVE-2026-63349, CVE-2026-63374, and CVE-2026-64847 and a build failure on Python 3.15)
• python-asttokens
• python-asyncvarlink
• python-blockbuster (fixing a build failure on Python 3.15)
• python-btrees
• python-django-health-check
• python-django-otp
• python-django-simple-history
• python-email-validator
• python-forbiddenfruit
• python-ldap
• python-linuxnamespaces
• python-plaster-pastedeploy
• python-pydash
• python-pyzipper (fixing CVE-2026-44722)
• python-quart-trio
• python-rich-click (fixing harlequin)
• python-repoze.lru
• python-repoze.tm2 (fixing use of pkg_resources)
• python-time-machine
• python-urllib3 (filed upstream issue with recent Python 3.14 versions)
• python-vblf
• quart
• responses
• sphinx-autodoc-typehints
• storm (fixing a build failure with Python 3.15, which I helped to land upstream)
• trove-classifiers
• twine
• vdirsyncer

• flufl.password
• junos-eznc
• python-decopatch
• python-launchpadlib
• python-plaster-pastedeploy
• python-pyramid-retry
• sphinxcontrib-log-cabinet
• sphinxcontrib-restbuilder
• straight.plugin

• aiosignal
• frozenlist
• python-cheroot
• python-propcache

• afew
• django-downloadview
• django-filter
• django-polymorphic
• drf-haystack
• drf-yasg-nonfree
• pydantic-core
• pylint
• pytest-openfiles
• pytest-remotedata
• python-aiohttp-oauthlib
• python-cron-descriptor
• python-django-nh3
• python-graphene
• python-pydash
• python-pysolr
• python-time-machine
• python-vblf
• social-auth-core
• sphinx-book-theme
• tagpy: FTBFS against python 3.15rc2
• tagpy: TypeError: include_dirs (if supplied) must be a list of strings
• typer

• python-pycudwt: Requires manual rebuild for python3.14-only transition
• python-testing.postgresql: Fails to build source after successful build
• tomopy: Requires manual rebuild for python3.14-only transition
• typer: Fails to build source after successful build
• vdirsyncer: Fails to build source after successful build

Welcome to the August 2026 report from the Reproducible Builds project! In our reports, we try to outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not. In this month s report, we cover:

1. New updated SBOM specification from CISA.gov
2. LWN on Bootstrappable builds at FOSSY 2026
3. What s missing to have reproducible builds on PyPI?
4. Distribution work
5. Unreproducible builds under EROFS filesystem fixed
6. Tool and documentation development
7. Six new scholarly papers
8. Patches

New updated SBOM specification from CISA.gov CISA, the Cybersecurity and Infrastructure Security Agency of the U.S. government published some the joint guidance entitled Minimum Elements for a Software Bill of Materials (SBOM), which updates and supersedes the baseline 2021 version covered in previous editions of these reports. Whilst the PDF is worth skimming, the interesting changes include that the specification now mandates standard cryptographic hashes: unlike earlier standards that allowed hash omission or manifest-only parsing, hashes must be computed from the output. This is is important for reproducible builds, as it ensures the recording of the metadata required to demonstrate the shipped software matches the build output precisely where applicable. In addition, where the top-level only dependency limitation that was present in the 2021 version has been removed in favour of complete coverage with no minimum depth. That is, SBOMs are expected to reflect all linked libraries, vendored dependencies and other build-time inclusions.

LWN on Bootstrappable builds at FOSSY 2026 In the Toolchains and Other Development Tools track at Software Freedom Conservancy s FOSSY 2026 in British Columbia, Canada, Timothy Sample gave a presentation on bootstrappable builds. This presentation was then covered in a Linux Weekly News article by Jake Edge entitled Bootstrappable builds: how and why, which serves as an excellent introduction to the concept:

The basic idea behind bootstrappable builds is to create a system that can be built without relying on pre-built artifacts. Can we go from zero to the modern day without having to just assume the existence of these already-built-for-us artifacts? The classic recipe for yogurt requires some yogurt to start the process, which is like how we normally build a C compiler today we start with an existing C compiler binary. You might think about making sourdough bread with your grandmother s starter brought over from the old country; we re basically making C compilers with Dennis Ritchie s starter carried over from Bell Labs .

The article, which goes on to cover GNU Mes and other projects that overlap with Reproducible Builds, also has a number of thought-provoking comments.

What s missing to have reproducible builds on PyPI? Core Python developer, Brett Cannon wrote an interesting blog post this month addressing What s missing to have reproducible builds on PyPI, the official public repository for third-party Python software packages:

The reason I like the idea of making reproducible builds work is that I think it can be done in such a way as to not require any work on the part of the producer of a distribution (which is a technical term for sdists or wheels, i.e., the people who upload stuff to PyPI), and thus make reproducible builds very low-friction for people to opt into supporting. [ ]

Brett goes on to outline What s missing from the specs and how reproducibility might be visible on PyPI to consumers:

Assuming all of this comes to pass and we record the where the source code is that went into a distribution and the software used to make the distribution, how do we make it useful to people? Does every person who cares about having a secure supply chain have to rebuild everything they use themselves? Is there some way for even people who don t care about this stuff to benefit? [ ]

Distribution work In Debian this month, 23 reviews of Debian packages were added, 28 were updated and 27 were removed this month adding to our knowledge about identified issues. A number of issue types have been updated as well, such as the addition of a new toolchain issue related to python-traitlets [ ], and the note for an existing issue related to texi2html was updated as well [ ]. Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.

Unreproducible builds under EROFS filesystem fixed Martin Pitt reported on Fosstodon that they had identified an issue where the mkfs ( make filesystem ) command for the EROFS (Enhanced Read-Only File System) subsystem of the Linux kernel did not have sorted extended file attributes, leading to reproducible builds. Thankfully, Martin also reported that they had fixed this in a commit to the kernel which order[s] each inode s xattrs by name so that images stay reproducible . [ ]

Tool and documentation 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 327, 328 and 329 to Debian. In particular, he ensured that diffoscope did not require python3-guestfs in the autopkgtests on 32-bit architectures in order to fix Debian bug (#1144372) [ ]. Colin Watson made an additional change, handling a potentially missing openssh-client package when running the autopkgtests [ ], and Jochen Sprickerhof made a similar change to cope with missing cpio and qemu-img functionality [ ] whilst also updating the XML comparator to be considered when comparing SVG images [ ].
Yet again, there were a number of improvements made to our website this month as well. For example:

• Chris Lamb added draft for a Gothenburg summit-related news article. [ ][ ]
• Holger Levsen then published the same article. [ ][ ]
• Lastly, a large number of commits were pushed comprising an interview with Reproducible Builds developer Jochen Sprickerhof to be published within the next week. [ ][ ][ ][ ][ ][ ][ ]

Six new scholarly papers Jens Dietrich, Spencer Sun, Tim W. White and Behnaz Hassanshahi (the result of a collaboration between Victoria University of Wellington and Oracle Australia published a paper this month entitled No Snake Oil: Verifying Python Package Builds. Drawing on the metaphor of snake oil , that is, a fake or ineffective medicine or solution sold with exaggerated claims of curing or fixing everything, the authors write that

Two tools that are designed to automate [PyPI] rebuilds and run them at scale are macaron and oss-rebuild. We study 12,180 popular releases from PyPI and find that the byte-for-byte equivalence rate is generally low. We analyse the reasons why they produce different wheels, and find that equivalence between the original and rebuilt wheels can often still be established, preserving most of the guarantees users expect from rebuildable releases. We present and evaluate daleq4py, a tool to establish the equivalence of Python wheels through the kernel of a normalisation function that is based on provenance-preserving datalog rules. Experimental results show that daleq4py substantially expands the set of rebuilds that can be accepted as equivalent.

The full PDF of their paper can be viewed online, and Jens Dietrich to our mailing list to announce the availability of both the paper and the daleq4py tool itself.
Dimitri Kokkonis, Micha l Marcozzi and Stefano Zacchiroli published an article this month titled Not In My Git Yard: Catching Backdoors at Commit and Release Time on the topic of code-level backdoors that is, stealthy code changes that grant hidden privileges via secret triggers . These issues:

pose a persistent threat to opensource software. Known attempts to inject such backdoors into widely used projects through malicious commits, tampered release packages, or compromised third-party dependencies, were stopped only by luck and manual review. Existing Continuous Integration (CI) pipelines cannot detect these attacks, and downstream binary analysis tools require substantial manual effort. In this work, we present Lily, an automated approach that strengthens open-source development and release processes against backdoor injection. Lily integrates a backdoor detection mechanism into (1) CI pipelines to block malicious commits, and (2) release vetting workflows to prevent tampered releases or compromised dependencies from entering large ecosystems, such as Linux distributions.

The full PDF can be read online.
Ranindya Paramitha and Laurie Williams of North Carolina State University along with Christian K stner of Carnegie Mellon University published a paper this month with the title of The Software Supply Chain as a Market for Lemons: A Multivocal Review of Trust Signal Collapse. (A lemon in American English, is a vehicle that turns out to have several manufacturing defects .) Their abstract is as follows:

Practitioners evaluating open-source dependencies rely on cheap trust signals, e.g., stars, download counts, and contributor activity, as substitutes for direct code inspection, assuming those signals reflect genuine trustworthiness. Prior work has documented individual signal gaming, but the landscape of collapses across all dependency-adoption signals, as well as the ecosystem s response, remains unexplored. The goal of this study is to aid software practitioners in understanding the reliability of dependency adoption trust signals, such as download counts and contributor activity, by conducting a multivocal review of 252 Google Search sources and 870 Reddit threads.

Worryingly, after their review, the authors conclude that cheap trust signals collapse under three simultaneous forces: adversarial manipulation, gaming techniques indistinguishable from legitimate behavior, and non-adversarial AI-driven inflation. The full PDF of the paper is available online.
Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli and Th o Zimmermann published a paper this month on Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation:

Ken Thompson s trusting-trust attack, in which a compromised compiler backdoors the programs it builds and reproduces the backdoor in subsequent rebuilds of itself, is widely regarded as a threat specific to compilers. We show that it is not. We construct a complete trusting-trust attack around GNU strip, an ordinary build utility that neither inspects nor generates source code, using only manipulations of finished ELF files.

Scarily, in the authors example, a single tampered strip in the binary seed implants a payload that propagates from one generation of strip to the next and survives into the final standard environment after the seed leaves the dependency closure [ ] without failures and backdoors . A full PDF of the paper is available for download online.
Mehdi Keshanimm, Amirhossein Rahmati, Mohammad Hossein Aref and Abbas Heydarnoori published a paper that is currently under review at Emperical Software Engineering titled AROMA+: A Study of Factors Affecting Reproducible Builds in the Maven Ecosystem. (Maven is a/the build automation tool used for Java projects.) In their paper, the authors note that

[ ] reusing external software in a project presents a security risk when the source of the component is unknown or the consistency of a component cannot be verified. The SolarWinds attack serves as a popular example in which the injection of malicious code into a library affected thousands of customers and caused a loss of billions of dollars. [ ] Our research aims to support [reproducibility] efforts in the Maven ecosystem through automation. We investigate the feasibility of automatically finding the source code of a library from its Maven release and recovering information about the original release environment. Our tool, AROMA+, can obtain this critical information from the artifact and the source repository through several heuristics and we use the results for reproduction attempts of packages on Maven Central.

The full PDF of their article can be downloaded online.
Lastly, Oreofe Solarin, Kelechi Kalu, James C. Davis and Paschal Amusuo published a paper this month titled Reproducibility is Not Enough: Artifact Verifiability in Decentralized-Build Package Ecosystems:

[A]rtifact verification requires more than deterministic builds: a verifier must also recover the source state, build environment, dependencies, and build instructions that produced the artifact. Decentralized-build ecosystems make this difficult because artifacts are produced through heterogeneous tools, maintainer-controlled workflows, and fragmented metadata. As a result, it remains unclear how often artifacts in these ecosystems can be independently verified. This paper studies artifact verifiability across four popular decentralized-build package ecosystems. We define an independent verifier model that relies only on registry-derivable metadata and an artifact comparison model with tiered equivalence levels. We implement these models in an Artifact Verification Pipeline and use it to measure artifact verifiability across the target ecosystems.

The authors conclude that beyond build determinism, verifiability is limited by missing source and build metadata, implicit release transformations, and unconventional build practices . A PDF of their paper can be reviewed online.

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 applicable or possible. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • Botan
  • Rivet
  • boost
  • ceph
  • cosmic/xdgen
  • cpio
  • dmd
  • dvgt
  • efl
  • firefox-esr
  • fritzing
  • gcc/esbuild
  • git-annex
  • go1.27/esbuild
  • gputils/sdcc
  • grass
  • gri
  • java-21-openj9
  • java-25-openj9
  • ksh
  • llvm22
  • llvm
  • llvm
  • lutgen
  • maxima
  • mingw64-filesystem
  • neochat
  • obs
  • python-PyMuPDF
  • python-gguf
  • python-langgraph
  • python-pook
  • python-pyzmq
  • python-xgrammar
  • python-xlsx2csv
  • qt6-tools
  • sbcl
  • scons
  • virtualbox
  • xpenguins
  • zabbix
• Chris Lamb:
  • #1143615 filed against keychain.
  • #1143616 filed against python-nameparser.
  • #1143617 filed against lcov.
  • #1144065 filed against displaycal-py3.
  • #1144066 filed against redmine.
  • #1144407 filed against django-htmx.
  • #1144409 filed against pybdsf.
  • #1145914 filed against golang-github-adamkorcz-go-fuzz-headers-1.
  • #1145915 filed against googletest.
• Jochen Sprickerhof:
  • #1145443 filed against cross-toolchain-base.
  • #1146088 filed against ferret-vis.
• Robin Candau:
  • bashburn
  • LMMS
• Werner Fink:
  • bash

If you are interested in contributing to the project, please visit our Contribute page on our website.

openssh (1:10.4p1-5) unstable; urgency=medium
  The openssh-client and openssh-server packages no longer include GSS-API
  authentication and key exchange support; this adds pre-authentication
  attack surface and generally increases complexity, and should only be used
  where specifically needed.  Users who need these features should install
  openssh-client-gssapi or openssh-server-gssapi instead.
 -- Colin Watson <cjwatson@debian.org>  Sun, 23 Aug 2026 17:39:55 +0100

• anorack
• djangorestframework (fixing a build failure)
• isort
• lazr.delegates (dropping pkg_resources)
• lazr.restfulclient (dropping pkg_resources)
• lazr.uri (dropping pkg_resources)
• nbclient (fixing a build failure)
• pydantic-settings
• python-argcomplete
• python-blockbuster
• python-makefun (fixing a build failure)
• python-persistent
• python-pytest-run-parallel
• python-time-machine
• python-typing-inspection
• wcwidth
• zope.hookable
• zope.i18nmessageid
• zope.interface
• zope.proxy
• zope.security
• zope.testrunner

• pydantic
• python-typing-extensions

• anorack
• buildbot
• codespell
• django-prometheus
• pendulum
• pydantic-core
• python-argcomplete
• python-ast-serialize
• python-bcrypt
• python-cross-web
• python-datamodel-code-generator
• python-djangorestframework-flex-fields
• python-openapi-core
• python-treq
• scikit-build-core

• python-librosa: Hardcoded Python 3.13 in rules file
• python-makefun: Fails to build source after successful build

Rendering in Lynx, a text browser

Rendering below the paragraph on a narrow viewport

Rendering in the margin on a large viewport

<sup id="fnref:YYY" data-anchor="--lf-sn-YYY">
  <a href="#sidenote-YYY">1</a>
</sup>

<aside role="note" id="sidenote-YYY" data-anchor="--lf-sn-YYY">
  <sup>1</sup>
  <p>A first paragraph.</p>
  <p>A second paragraph.</p>
</aside>

aside[role="note"]  
  margin-block: 1rlh;
  color: #444;
 

@supports (anchor-name: attr(data-anchor type(<custom-ident>)))  
  @media (min-width: 72rem)  
    main  
      position: relative;
      sup[data-anchor]  
        anchor-name: attr(data-anchor type(<custom-ident>));
        /*   anchor-name: --lf-sn-YYY */
       
      aside[role="note"][data-anchor]  
        anchor-name: --lf-sidenote;
        position: absolute;
        position-anchor: attr(data-anchor type(<custom-ident>));
        /*   position-anchor: --lf-sn-YYY */
        top: max(anchor(top), anchor(--lf-sidenote bottom, -1rlh) + 1rlh);
        left: 100%;
        margin: 0 2rem;
        width: 18rem;
        color: inherit;
       
     
   
 

The three cases for the vertical position of a note

1. The first note s top edge aligns with the top edge of its reference mark: as there is no previous note, anchor(--lf-sidenote bottom, -1rlh) + 1rlh resolves to 0 and max() returns anchor(top).
2. When the reference mark of a later note sits above the bottom of the previous note, plus some vertical space, the note goes below the previous one to avoid a collision. max() returns anchor(--lf-sidenote bottom) + 1rlh.
3. Otherwise, the note s top edge aligns with the reference mark s top edge, as max() returns anchor(top).

Also in this series:

• The Four Horsemen of the LLM Apocalypse
• The people vs the AI overlords

The Debian vote context This is not a coming out. I am not using LLMs on a daily basis, and this blog is, again, written out of my cold dead hands in a dying world, with over-engineered hardware and (to a certain extent, hi Emacs!) software, powered by 100% green energy built on stolen land. There is a vote going on in Debian. If you're unfamiliar with it, you can catch up at LWN. So far I've essentially said "LLM is bad" which is not a very balanced or useful opinion. Obviously, people are using LLMs, sometimes unknowing or unwillingly, and we need to take that into account. Furthermore, there has been many different blog posts on Debian planet about this. Some that I found balanced, good summaries, even if I didn't fully agree with them, at least some did the basic civil service of being short. But others were just not only Wrong but also so long that I couldn't finish that I just had to write something.¹ This is not an explanation of the ballots, nor how I will vote. This vote is Debian's failure of framing that debate in a reasonable way: we have 8 options on the ballot with many duplicates. We have failed to do the hard work of summarizing and aggregating options into a meaningful set. I doubt the final vote will represent a readable position we can rally around. I have not read the two months of debates on the topic either. Normally, before voting, I take a cursory look at the debate to see points of view I might have missed. But in this case, it will just make me sad, add noise, and I'm already pretty sure on where I stand on this. So let me describe how I use LLMs and how I think they fit in our work, as computer engineers and hobbyists.

My LLM use

Debian Packaging An astute reader has pointed out that I maintain a package in Debian made to use Anthropic. It's actually multiple packages:

• llm: a CLI utility and Python library for interacting with Large Language Models, with OpenAI as its default API backend
• llm-anthropic: a plugin for llm which allows me to talk to Anthropic's API instead of OpenAI
• anthropic-sdk-python: the SDK llm-anthropic requires to do its work

As I previously explained in response, I am not entirely comfortable with this work: it's a compromise. In fact, I first uploaded llm to the contrib section of Debian, where we keep software that depends on other non-free software, but I was told that, since yt-dlp was in main, llm belonged there as well. So I moved it to main, alongside similarly controversial tools like llama.cpp or the python-openai library.

OpenAI and Anthropic usage An important part of my work is technology watch. I keep tabs on thousands of (new and old) software projects, follow news, and generally try to keep my skills up to date. It's a pretty impossible race, especially as I grow older, but I still think I'm doing the right choices in my job. Testing large language models is part of that work. At first, I was using ChatGPT's web interface, but it was annoying to copy-paste things into a browser, so I looked for different interfaces. For a while I tried gptel, a "simple, extensible LLM client for Emacs" but I found it kind of terrifying. Giving a LLM control over an Emacs buffer seems like a security nightmare, so I stopped doing that. So I use the llm command-line tool to talk to Anthropic's API. I started that in the summer of 2025, when I bought 20$USD of API credits. Before that, I paid for a ChatGPT subscription and then OpenAI credits, which expired and sent me over to Anthropic, which seemed then to have better ethics. As it turns out, Anthropic is also happy to work for the US military (which is a big red line for me). Anthropic also won't let you talk about the genocide in Gaza, it is destroying physical books, and is blackmailing us to use their product for security coverage. Needless to say, Anthropic and "Claude" are not my friends, but they seem like the lesser evil in current "frontier models". So I have renewed, a couple of weeks ago, another 20$USD of API credits with Anthropic.

Actual prompts and responses So what does 20$ give you at Anthropic anyways? What am I using LLMs for and how? The neat thing with llm is that everything is logged in a sqlite database, so there are some answers that are easy to get:

> llm logs status
Logging is ON for all prompts
Found log database at /home/anarcat/.config/io.datasette.llm/logs.db
Number of threads logged:   7
Number of turns logged:     12
Number of legacy conversations: 543
Number of legacy responses: 970
Database file size:         9.61MB

That is 10MB of logs, with about a thousand prompts. My logs go back to 2024-03-07, a little over two years ago, and include a mix of Anthropic and OpenAI responses. I used it more in 2024 than 2025, and if the trend continues, I will have used it less in 2026 again:

> llm logs list -n 0  --json   jq -r .[].datetime_utc   sed 's/-.*//'   sort   uniq -c 
    527 2024
    357 2025
     98 2026

It looks like about 10 prompts per month right now, down from a peak of about 60 per month in 2024. It's pretty difficult to analyze those actual logs to get more patterns and I won't run the prompts through a model again to process them.

How I'm using models now At first, I was using it partly for benchmarking model's capabilities, like Simon Willison does with his pelicans, clearly not trusting its output. But I was impressed by the capacities of the Claude Opus 4.5 model when it wrote this script in January. Impressed, but also scared: it's the first time I felt I could delegate the entirety of my programming to a model. Just run the code, if it works, it works, right? So what do I use it now? As an example, here are the 10 last prompts in my history:

1. there is now Claude 5, and a fable model, maybe you know about it?
2. impress me
3. not impressive, i already know all of this
4. chat
5. in postfix, i have a 300k mailing that happens regularly here. normally, it delivers within about...
6. is there a way i could have drained the maildrop queue faster without removing the milter?
7. the problem was that rspamd was timing out on the FUZZY_CALLBACK check. how do i disable that?
8. how do i disable all spam checks? i just want rspamd to add dkim signatures
9. how do the default_destination_concurrency_limit and initial_destination_concurrency settings int...
10. mic check

The first one was me trying to confirm which model I am using, which is not always obvious when going through the whole llm stack I've been using. The following two are an attempt at seeing what the model is capable of and I was "not impressed", to which Claude answered that I have a "high bar", which, fair enough. The chat is me failing to use a command line, which shows that perhaps I need to readjust that "high bar", again. The next five are a rather embarrassing debacle in a large Postfix mailing that went sideways, and where I couldn't find an actual Postfix expert of my level to help. The fabled Claude Fable 5 answered rather correctly, but dangerously, that I could empty the queue by disabling the non_smtpd_milters. What Fable (and myself) did not realize is that the milter was also adding DKIM signatures, so while the mailing was expedited, it was done without those precious signatures, which got us promptly blocked at Gmail. We have recovered since, and, thanks to the model and reading the Postfix manual for the hundredth time, that pickup(8) is single-threaded and that we needed to review the architecture of that mailing (and our spam filters) a bit. Many tickets ensued. The last one is a test I did to make sure my last uploads of llm-anthropic and its dependency worked correctly.

Note that the above excludes 5 questions I asked Anthropic while writing this article, where I asked for synonyms and "what nanometer scale are arduino processors built from? how is an arduino CPU printed?", a question which Wikipedia furiously evades providing a good answer.

Those prompts are pretty typical of my LLM use: I'm testing the models to see if they work at all, but also, out of desperation, I fire off a prompt after I fire off questions to colleagues or search engines (in that order). It's often weird edge cases like the Prometheus query language, Python's matplotlib, LaTeX, Elisp, optimizations, and so on. I use models for translation a lot. Being fully bilingual, it is common for me to think of a word in French or English and fail to find exactly the right word for that in the other language. Models help with that, and are also useful to find synonyms. Those are low-token uses that seem pretty innocuous to me, but I realize the irony of this after writing about the tower of Babel.

What I am not using models for I am not using models to write prose. I am not using models to read prose. If it's generated with LLMs, I stop reading. I am not using models to write code, with the exception of that single Python script above. I am generally not using models to review code, with exceptions. If I get stuck on a hard problem, I might feed a piece of code to the model. I repeatedly fed asncounter into Claude to try to fix a performance regression I had introduced. It found micro-optimizations that taught me a thing or two about Python's internal implementations, but overall, it was mostly a waste of time. This was in June 2025, so perhaps now models would fare better. I have not tried again. I am not using LLMs to do Debian packaging. When I can, I manually review the diffs of packages I upload into Debian, still, by hand. I do this for the reasons outlined in The Four Horsemen of the LLM Apocalypse, because I refuse to be complicit in the:

1. aggressive and illegal scraping of the servers I steward
2. world-wide computer hardware shortage (making it, by the way, nearly impossible to run presumably clean local models) and the attack on our job conditions (also discussed in The people vs the AI overlords)
3. death of copyright and free software
4. complication and enshifitication of everything, and the destruction of our communities
5. the imperialist Nerd Reich that wants to take over the world

Like I reluctantly use Intel computers, I do fire off a prompt. But I still hold on to the dream that we can build communities of practice that hold human knowledge collectively and not offload that as a utility to some megalomaniac billionaire.

Their LLM use I am forced into So that's me. Clearly, I'm going against the grain here. Everywhere I look, I see LLM-generated code and projects. Slop and botnets have flooded the web. I use Wadamesh, clearly vibe-coded, because it's the best graphical interface for MeshCore that runs on portable devices. I wish it was made by a human, in a community I could participate in, but it isn't, and I don't. I package the above llm toolset, which is more and more vibe-coded, but I still review the diffs. And I have to say: I trust Simon here. The code is verbose as hell, feels overengineered, and llm feels slow, but it generally works, and Simon is still at the gate. The Anthropic SDK is another thing entirely. The 0.91.0 to 0.120 upload, for example, was nuts:

 806 files changed, 72281 insertions(+), 1478 deletions(-)

I explicitly did not review that entire diff. It feels like there's a lot of garbage there to just have a shim between a proprietary API and Python. But this is the hand I've been dealt.

Larger projects LLM use LLMs are being used in the Linux kernel, Firefox, rsync, Rust, and other places. I don't feel good about this, particularly in Rust, but they at least made a decent policy. I am glad GCC made a policy against LLM contributions and I support the human Emacs project. We need to have a set of foundational tools that are "clean" in the sense that they are built upon a community of people that understand how they are built. Maybe that's naive or even impossible. The Linux kernel and GCC, in particular, are massive projects that have long grown past the scale of a single person's understanding. But the theory was that a community of humans can understand collectively. Now we seem to be throwing up our hands and giving up on that community. That LLMs will just fix the problem, whatever it is. But we're all just one rug pull away from being completely incapable of managing those projects. The argument there is that we'll just switch to local models, but no one is actually doing that. All I see is people use local models as a corner case (for privacy) or as in theory, but in reality, everyone uses the centralized frontier models right now. We just can't fallback. We're in the same situation we were, a decade or two ago, when Microsoft decided it would kill free office alternatives by making Office free for non-profits. It worked: thousands, if not millions of schools, community groups and individuals stopped looking for alternatives (including free software but also "piracy") for Office and embraced what seemed like a generous offer. Now Microsoft pulled the plug and Over 170,000 Nonprofits Lost All Their Data. I'm afraid the rug pull on LLMs will be much worse: never mind that Linus won't be able to use his tireless helper to fix obscure kernel bugs; we're looking at a collapse of the economy so large that we are already talking about bailing out the companies responsible. In a sense, the most striking thing about the Debian vote is it has actually no option to completely refuse upstream LLM contributions. It seems the community has taken it for granted that it's now impossible to build Debian entirely without LLMs. We lost the battle even without a fight, it seems.

A plea for small If it has really become impossible for us to manage the complexity we have built, maybe it's time to stop and think about what we're doing in the first place. We're struggling to even bootstrap our current toolchain! This is one of the things I like the most about working on the mesh: it's low tech, small Arduino devices that is built with decades-old semiconductor processes that is understandable by human beings. Maybe the answer lies more in single-purpose devices like those communicators and simpler multi-purpose computers than what we have now, which is what the permacomputing movement is about. Small is beautiful, let's scale it down.

---

1. and yes, I'm sorry this has gotten this long, I hope you will forgive those 3000 words.

• [1] https://www.youtube.com/watch?v=TCn7bA1eg_0
• [2] https://www.youtube.com/watch?v=ZJ8KThKAfbs
• [3] https://www.youtube.com/watch?v=gpSghW4J3ws
• [4] https://tinyurl.com/28b6jclu
• [5] https://zanestjohn.com/blog/reing-with-claude-code
• [6] https://tinyurl.com/2y2b6a58
• [7] https://tinyurl.com/2awjppn5
• [8] https://tinyurl.com/2y89gftt
• [9] https://tinyurl.com/2b27vo8o
• [10] https://365tomorrows.com/2024/03/27/cold-war-2/
• [11] https://tinyurl.com/2aqkn4z6
• [12] https://tinyurl.com/2dy5vy8g
• [13] https://tinyurl.com/25rld7v3
• [14] https://doctoreww.github.io/EvilFontTool/
• [15] https://tinyurl.com/2c2guu89
• [16] https://tinyurl.com/27kq4qqu
• [17] https://tinyurl.com/2blp477w
• [18] https://tinyurl.com/27aybgge
• [19] https://tinyurl.com/29covbrp
• [20] https://tinyurl.com/27qdj6co
• [21] https://tinyurl.com/22pxub8v
• [22] https://tinyurl.com/25zf4hnp

2026-07-24 15:43:17 status triggers-pending wordpress:all 7.0+dfsg1-1
2026-07-24 15:43:19 upgrade wordpress:all 7.0+dfsg1-1 7.0.2+dfsg1-1

1. WordPress doesn t seem to store the version it s running at the time of operations. So anyone who doesn t have a suitable external log of versions deployed (such as the dpkg.log file for a Debian managed installation) won t know for sure which version was running. It supports automatic updates but you can t be sure that they happened soon after the release.
2. There is no log of IP addresses used for operations. There are apparently some 3rd party modules to log such things and web pages documenting how to modify the PHP to add it but nothing in the standard distribution.
3. Software should have a standard distribution with some support for logging of security relevant data. The typical situation is that people don t plan for logging such things until after they have been attacked so the data should be recorded without users going out of their way to log it.
4. A log of security relevant data should be stored in a database table with only insert access (no update, delete, or drop).
5. Ideally a CMS would support different database accounts for different purposes. Someone from an internal network or VPN could talk to an instance of the web server which has a database username and password giving full access. Everyone from outside the trusted range gets an instance of the web server with database access only allowing to read the posts and appearance configuration and to enter comments. If the database didn t allow the account used for public access to create new admin users or create posts then it would be a lot harder for attackers.
6. Ideally for everything that stores user account data there would be an easy way of getting a list of users in a plain text format to allow running diff. The design of WordPress has two tables, one for users and one for encoded metadata about users of which one will be the access level. The following SQL command will give a list of all users that aren t subscribers (everyone above the minimum level of access which is typical for new users) along with their encoded password and access level. This could be used in a monitoring system to alert about new privileged users. The TABLE_PREFIX variable is for the prefix for WordPress tables, which is wp_ by default but can be any legal value.

   select $TABLE_PREFIXusers.user_login, $TABLE_PREFIXusers.user_pass, $TABLE_PREFIXusermeta.meta_value from  $TABLE_PREFIXusers join $TABLE_PREFIXusermeta on $TABLE_PREFIXusers.id = $TABLE_PREFIXusermeta.user_id and meta_key='$TABLE_PREFIXcapabilities' and meta_value != 'a:1: s:10:"subscriber";b:1; ';

• [1] https://doc.coker.com.au/
• [2] https://en-au.wordpress.org/download/releases/
• [3] https://jamstack.org/generators/
• [4] https://etbe.coker.com.au/2011/12/31/server-cracked/

• curl
• diffoscope
• glome
• golang-github-appleboy-easyssh-proxy
• parsyncfp2
• rsync

• cryptodatahub (fixing a build failure)
• dep-logic
• django-q
• flufl.lock
• more-itertools
• multipart
• pyasn1 (fixing CVE-2026-59884, CVE-2026-59885, and CVE-2026-59886)
• pytest-rerunfailures
• python-auditwheel
• python-build
• python-certifi
• python-datamodel-code-generator (fixing a build failure, and an incompatibility with pydantic 2.13 that I reported upstream)
• python-django-parler
• python-httplib2
• python-pgbouncer
• python-time-machine
• python-treq
• python-typing-extensions
• python-wheezy.template
• storm
• ubelt
• webpy
• zope.testing

• django-q: autopkgtest failure with Python 3.14 (reported upstream)
• httpx: FTBFS: E assert [( uvicorn.ac 1.1 200 OK )] == [( httpx , 20 1.1 200 OK )]
• libntruprime: autopkgtest failures with Python 3.14
• pygments: Handle None object before HTML escaping (fixed build failures in cmd2, gunicorn, python-inline-snapshot, and python-openapi-core)
• python-authlib: some of tests/flask/test_oauth2/rfc9068/ failed
• python-click: autopkgtest regression with pytest 9.1 (contributed upstream)
• python-httplib2: FTBFS: ERROR tests/test_proxy.py - Failed: forked not found in markers configuration option
• python-maturin: Please upgrade goblin dependency to 0.10
• python-memray: FTBFS on armhf (segfault)
• python-mne: FTBFS: E pytest.PytestRemovedIn10Warning: Passing a non-Collection iterable to parametrize is deprecated (actually fixed in scikit-learn; contributed upstream)
• python-softlayer: autopkgtest fails with python3-click 8.3.3 (contributed upstream)
• python-urllib3: FAILED test/contrib/test_pyopenssl.py

• django-pipeline: Fails to build source after successful build
• more-itertools: Please mark python3-more-itertools with M-A: foreign

• openssh: sshd-session built without crypt(), breaking UsePAM=no password auth (merged and uploaded)
• openssh: Slovak debconf templates translation (merged and uploaded)
• python-treq: Fails to build source after successful build (merged and uploaded)
• python-better-exceptions: FTBFS: failing tests (sponsored upload for Seyed Mohamad Amin Modaresi)
• yubihsm-connector: patch to make the build reproducible (merged and uploaded)

Changes in Rcpp release version 1.1.2 (2026-07-01)

• Changes in Rcpp API:
  • Use of execinfo.h is again conditional to avoid build complexity (Dirk in #1445 addressing #1442)
  • An internal state component for Datetime is now int (Dirk in #1448 and #1449 fixing #1447)
  • Three new (in R 4.6.0) attribute accessors are used conditionally (Dirk in #1450 closing #1432)
  • An UBSAN error in the Sugar-based NA comparison has been corrected (I aki in #1453 fixing #1452)
  • Treatment of Inf outside of integer range in Sugar function has been corrected (I aki in #1458 fixing #1455)
  • Integer overflow protection has been added for sugar functions (I aki in #1457 fixing #1454)
  • The parent environment is now accessed via R_ParentEnv (Dirk in #1460 fixing #1459)
  • Change to returning dataptr again for better handling of empty vectors (I aki in #1462 fixing #1461)
  • Undefined behavior errors in use of ListOf proxies have been addressed (I aki in #1464 fixing #1463)
  • Under newer R version, R_UnboundValue is no longer used (I aki in #1466 fixing #1465)
  • New R API access point R_getRegisteredNamespace() is used with current R versions (Dirk in #1469 fixing #1468)
  • The Nullable::as() exporter now uses an explicit cast to the templated type (Dirk in #1471 fixing #1470)
  • A memory leak in the variadic Rcpp::warning() template has been fixed (Kevin in #1475 fixing #1474)
  • The Nullable::operatorT() has been added as a 'opt-out' (Dirk in #1477 with coordination in #1472)
  • Add templated integer-index overload for operator[] on small systems such as WASM (Jeroen Ooms in #1482)
  • The attribute accessors in AttributeProxyPolicy no longer rely on get__() (Kevin in #1484 fixing #1483)
• Changes in Rcpp Documentation:
  • Reference in the bibliography used by the package vignettes have been updated.
• Changes in Rcpp Deployment:
  • Excute permissions are set consistently on scripts with shebangs (Mattias Ellert in #1467)
  • R 4.5.* has been added to the CI matrix (Dirk in #1476)
  • Three nag messages issued when obsolete build flag accessors are used now show Rcpp::: (Dirk in #1480 fixing #1456)
  • Reference GitHub Actions have been updated to their current versions (Dirk in #1481)
• Non-release Changes:
  • A non-release hotfix 1.1.1-1 used by CRAN accommodates breaking changes to the API in R 4.6.0. It would be nice to have the same level of release management in R itself that CRAN expects from us.

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 Related Work

• Uploaded wofi 1.5.3-1 to unstable
• Uploaded wob 0.16-1 to unstable
• Uploaded labwc 0.20.0-1 and 0.20.1-1 to unstable; these releases come with support for wlroots-0.20, which made labwc reenter testing
• Uploaded swaylock 1.8.5-2 to unstable to make it use the common-auth directive of pam (seeh #1140096)
• Uploaded swayimg 5.4-1 to unstable
• Uploaded wayback 0.3-2 to unstable, which was waiting in experimental for a reupload and I had forgotten about it; also fixed a typo in wayback upstream
• Uploaded xdg-desktop-portal-wlr 0.8.3-1 to unstable

DH Related Work The search app I was working on last month was still a focus in June. I refactored the data model a bit and made it simpler. I stumbled over the Python Koans and Koan 15: The Invisible Ink gave me the idea of using unicode normalization when indexing the items. I released a couple of bug fix releases for the APIS framework, namely 0.64.2, 0.64.3 and 0.64.4. I also release 0.65.0 which is one step further in dropping support for the legacy apis_entities app. When the search module is merged it will give way for removing the last bits of the old cruft to be removed. During a regular dependency update session I looked at the changes in the dal dependency. After a long time with no commits, the project suddenly had a lot of commits co-authored by Claude and then released a new major version with a regression. Given the state of the project, we decided to keep using the previous release for now and look into replacing the dependency with an HTMX based solution. I implemented a POC for one of the plugins we develop and it was actually pretty easy. I also managed to combine the autocomplete approach with a multi-select form field, based on this blog post. In the PFP project I finally merged the stats endpoint which give statistics about the named graphs that are used as data sources.

Other I attended BSidesVienna 0x7EA but it was on one of the hottest days this year so far so I left after a couple of talks.

• omniorb-dfsg (along with upgrading to 4.3.4)
• openssh
• yubihsm-shell

• certipy
• juptyer-server (fixing CVE-2025-61669, CVE-2026-35397, CVE-2026-40110, and CVE-2026-40934)
• magicgui
• pydantic
• pydantic-core
• pydantic-settings
• pylint
• pytest-rerunfailures (fixing a build failure with pytest 9.1)
• python-certifi
• python-django-celery-beat
• python-numpy-groupies
• python-packaging (aided by Debusine testing of reverse-dependencies)
• python-pytest-run-parallel
• python-pytest-unmagic
• python-service-identity
• python-tabulate
• python-urllib3 (fixing CVE-2026-9375 and CVE-2026-44432)
• python-watchfiles
• python-yubihsm
• responses
• uncertainties

• domdf-python-tools (contributed upstream)
• flask-caching (contributed upstream)
• magicgui (contributed upstream)
• pydantic-core
• pydantic-extra-types (contributed upstream)
• pydantic (contributed upstream)
• pylint
• pytest-codeblocks
• python-docx (contributed upstream)
• python-numpy-groupies (contributed upstream)
• python-openapi-core (contributed upstream)
• python-urllib3 (contributed upstream)
• python-watchfiles
• sphinx-automodapi

• depthcharge-tools: Traceback with 3.14: args for positionals must be != 0
• domdf-python-tools: autopkgtest failure with Python 3.14

• dh-python: Dependency parsing is too picky about spacing
• psygnal: Allow building without msgspec
• pydantic-core: Accept and require uuid 1.23.0, now that it s in Debian
• pygame: FTBFS: FAIL: test_fill_rle (pygame.tests.surface_test.SurfaceTypeTest.test_fill_rle)
• pyro5: FTBFS: Unable to determine debhelper compatibility version
• python-persistent: Bump timeout in test_rapid_create_destroy_cycle (contributed upstream)
• python-yubihsm: Depends: python3-cryptography (< 47) but 47.0.0-1 is to be installed
• sphinx-gallery: <!nodoc> build dependency removed from testing
• tpm2-pytss: Fix support for cryptography 47
• twisted: Tests fail with pyopenssl 26.3.0: module OpenSSL.crypto has no attribute X509Req

• psygnal: Fix reproducibility
• python-nacl: Updating the python-nacl Uploaders list
• python-tabulate: Fails to build source after successful build
• tpm2-pytss: Fails to build source after successful build

• rust-asn1 (needed by new python-cryptography)
• rust-asn1-derive

• buildbot: [INTL:sv] Swedish translation of debconf templates (merged and uploaded)
• openssh: Support DPKG_ROOT (merged and uploaded)
• openssh: Fix GSS C25519 server blob bounds check (merged and uploaded)
• python-pyramid: CVE-2023-40587 Backport patch (merged and uploaded)

• busybox: chdir no longer available -> breaks d-i live-installer.udeb
• debmirror: Refresh mirror_size documentation

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

Go default compatibility, by Helmut Grohne At the MiniDebConf Hamburg, Andrew Lee had prepared a talk on how Debian accidentally chooses Go compatibility. Helmut joined Tobias Quathammer and Andrew Lee in looking into the problem. Go has a compatibility system where modules declare a desired Go version to be compatible with. This influences various features such as whether RSA keys smaller than 1024 bits are accepted. Unfortunately, Debian s way of building Go packages is unique in setting GO111MODULE=off, which practically implies a very old compatibility version that enables a number of insecure settings. Most Linux distributions use the default GO111MODULE=on and therefore consult a go.mod file that often declares a sensible version. While doing so is the way for Debian longer term, getting there involves major changes so we also sought a more short term workaround. We developed a patch to the Go compiler that would enable it to pick up a compatibility version from the environment. Tobias uploaded it to unstable. The next step is communicating the declared compatibility version from go.mod to the compiler via the new variable. Then, rebuilding the archive resolves the immediate symptoms. This does not save us from having to perform the larger transition to GO111MODULE=on, but this shortcut can be backported to trixie.

Trimming build-essential, by Helmut Grohne One of the harder problems of the architecture cross bootstrap is correctly expressing the Build-Depends of glib during the toolchain bootstrap. It implicitly depends on build-essential, which happens to depend on libc6-dev. This poses a cycle. It applies even for cross building, because it is interpreted for the host architecture and that there is no way of satisfying this dependency during the toolchain bootstrap. Given discussions at MiniDebConf Hamburg with Jochen Sprickerhof and others, a seemingly stupid idea evolved: Let s delete build-essential. What looks insane on the surface might deserve a second look. Given how we moved away from C, C++ and autotools, what is in build-essential no longer is required by much of the archive. With the rise of debputy, debian/rules no longer has to be a makefile. While the task would be huge, those packages relevant to architecture bootstrap could explicitly support building without the implied dependency making their dependencies explicit. In a number of cases, this amounts to issuing a dependency on g++-for-host. This dependency requires the use of architecture-prefixed tools. Therefore, Helmut wrote a debhelper change that makes it always pass build tools to various build systems. This also enables more packages to honour environment variables such as CC and CXX.

Python upstream engagement, by Stefano Rivera Stefano attended PyCon US (at personal expense) to improve upstream relations and ensure Debian s voice is heard where it needs to be. On Friday there was a packaging summit (notes) with good discussion on the future of the wheel format, and some discussion of the new abi3t shared library format for free-threaded python. In preparation for the event, Stefano did a complete review of the current patch stack. Stefano s primary goal was to get some of Debian s patches merged during the sprints, and results were mixed. Some trivial patches (e.g. GH-150098, made progress and merged, but the most consequential patch Debian is carrying is still blocked. Stefano will continue to try to drive progress on this.

Miscellaneous contributions

• Carles worked on po-debconf-manager: Reviewed Catalan translations for 6 packages, submitted 10 packages to maintainers, and removed 3 packages from po-debconf-manager.
• Carles worked on check-relations: Continued improving the backend, including importing source package build dependencies to better support analysis of Debian blends. Added support for ignoring packages using regular expressions and source package names in response to user feedback. Used the tool to report 5 new bugs and followed up on previously reported issues.
• Helmut sent a cross build patch on behalf of a customer.
• Helmut uploaded debvm and guess_concurrency both featuring improved reproducibility and documentation.
• Helmut continued maintaining rebootstrap and made it correctly handle binNMUs of gcc-defaults. Additionally, he poked at existing gcc patches giving answers, rebasing or closing them.
• Helmut supported the video team in Hamburg mixing audio.
• Helmut continued to report undeclared file conflicts of various kinds and corresponded with maintainers about them.
• Antonio attended a debate during the Brazil Internet Forum about the impacts of the child protection regulation (ECA Digital) on free software operating systems.
• Antonio worked on Debian CI to improve the system transparency for users. This included listing any pending jobs explicitly in the job lists for each package/architecture/suite page, as well as adding a queue status page that users can check for an estimate of test latency.
• Antonio worked on several Debian CI maintenance tasks, including but not limited to some monitoring improvements, replacing usage of fonts-font-awesome with fonts-fork-awesome, and adding the ability in debci to configure a global notice (which is being used in Debian CI to point to the system status pages).
• Antonio started doing some tests related to the change of default Debian CI backend from lxc to incus-lxc. This helped identify an omission in the creation of incus-lxc images. It was missing dpkg-dev, which caused a few packages that assumed its presence to fail. In the end, the incus-lxc backend will be fixed to include dpkg-dev by default in the image, but that uncovered an undeclared dependency in gem2deb (Ruby packaging helper) and in ruby-byebug, both already fixed in unstable.
• Stefano did some minimal work on debian-reimbursements to get it working with current versions of django-allauth.
• May included the discovery of several high-severity Linux kernel root exploits. Stefano updated kernels and rebooted debian.social infrastructure several times.
• Stefano supported the Hamburg miniDebConf s wafer website during the event, and set up an instance for the 2027 edition too.
• Stefano supported the bursary team issuing bursaries for DebConf 26.
• Stefano uploaded routine updates of python-pip, pystemmer, snowball-data, snowball (making up a mini, uncoordinated snowball transition), python-authlib, python-discovery, python-installer, python-mitogen, python-pipx, python-cachecontrol, platformdirs, and python-virtualenv.
• Stefano fixed a small number of bugs in dh-python, culminating in the 7.20260524 upload.
• Thorsten finally managed to upload a new upstream version of hplip. He also uploaded a new upstream version of epson-inkjet-printer-escpr. Last but not least with the help of other contributors he could fix bugs in lprng.
• Lucas and Santiago contributed significantly to the DebConf 26 Content team; helping to organize the team, review and rate talk proposals.
• Lucas also supported a packaging sprint held in India by rebuilding and publishing the latest results of the Ruby 3.4 transition effort.
• Santiago continued contributing to the efforts to organize DebConf 26, especially supporting the local team with different tasks.
• In collaboration with Emmanuel Arias, Santiago is mentoring Aryan Karamtoth, a GSoC participant that is working to introduce linux live-patching support in Debian. The GSoC project started in May, with community bonding and coding. Santiago reviewed a merge request to prepare the clang-extract package for debian. clang-extract is one of the building blocks that will help to extract specific functions from large C code, so only relevant code can be patched, without recompiling the whole original basecode.
• Anupa assisted Jean-Pierre Giraud with the point release announcements for Debian 13.5 and Debian 12.14.
• Colin backported various security fixes from OpenSSH 10.3 to all supported releases (including LTS and ELTS).
• Colin backported IP quality-of-service fixes to OpenSSH in trixie. The situation there had been unsatisfactory for some time, and upstream reworked their QoS support in OpenSSH 10.1 in a way that typically produces much better results.
• Colin imported new upstream versions of 26 Python packages, and fixed around 25 RC bugs for the Python team.

• 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

• 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)

• 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

• 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 nodoc build 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)

Debian Related Work

• Uploaded labwc 0.9.7-1 to unstable; labwc 0.20 was released upstream since then, but it requires wlroots 0.20.1 which has not landed in Debian yet
• Uploaded usbguard 1.1.4+ds-3 & 1.1.4+ds-4: cleaned up the packaging and fixed some long standing issues with the configuration; the legacy permission system isn t the default anymore
• Uploaded foot 1.27.0-1 to unstable
• Uploaded scdoc 1.11.4-2 to unstable
• Uploaded cage 0.3.0-2 to unstable
• Uploaded sway 1.12~rc3-2 to unstable; on the same day sway 1.12 was released and I uploaded 1.12-1 to unstable
• Uploaded swayimg 5.2-1 to unstable
• Uploaded git-quick-stats 2.11.0-1 to unstable
• Uploaded grim 1.5.0+ds-1 to unstable

DH Related Work A big chunk of my DH related work went into designing & implementing a search app for the APIS framework. Our goal is to have a way of searching over various types of Django models. The app introduces a search model that indexes all registered models. We use a combination of PostgreSQLs full text search and Trigram Similarity to find the search results. Using a SearchVectorField and GinIndices for the trigram indexed fields we can reach a somewhat acceptable performance. We released versions 0.63 and 0.64 of the APIS framework. The 0.63 release introduced the new entities app, which will soon hopefully replace the legacy apis_entities & apis_metainfo modules. Version 0.64 moved some logic from the legacy modules the entities module. We made some progress in defining the endpoints for the PFP API.