Debian's release team has made reproducible builds a hard requirement for the Debian 14 "Forky" cycle. Since May 9, the project's migration software has blocked any package failing a reproducibility check from entering testing.
If a package already in testing breaks reproducibility later, it gets blocked too. Paul Gevers from the release team shared the news on the debian-devel-announce mailing list over the weekend.
What are reproducible builds?
Not rocket science, for starters. When a package is built reproducibly, compiling the same source code in the same environment always produces the exact same binary every single time.
That might sound like it should just be how things work by default, but in practice it often isn't. 😅
The culprits are usually mundane. A timestamp baked into the binary, a build ID generated on the fly, files written to the archive in whatever order the filesystem felt like. None of it changes what the software actually does, but it means two builds of the same source won't match.
That gap has security implications. If binaries don't need to match their source, there's room for something to be slipped in at the build stage without touching the code at all.
Reproducible builds cut that off. Anyone can independently rebuild a package and verify the result against what Debian actually ships.
Debian has been working on this alongside the Reproducible Builds project (linked earlier) for years, steadily pushing reproducibility rates across the archive. The setup at reproduce.debian.net has been running continuous rebuilds and tracking results throughout the forky cycle.
What does this mean?
Tracking reproducibility rates for 'all' on Debian's forky branch.
Currently, 98.29% of architecture-independent packages in Forky reproduce successfully, with 23,731 passing and 414 still flagged as 'bad' for not being reproducible. That 414 figure will only get smaller as the block on non-reproducible migrations takes effect going forward.
For you, the user, this translates into a stronger guarantee that what you install from Debian "Forky" actually matches the published source code. No wondering whether something crept in between the source and the binary you are running.
And that verification isn't limited to Debian's own infrastructure either. Independent rebuilders can check it too, which is kind of the whole point.
Maintainers, meanwhile, have been reminded that cleanly migrating a package is the uploader's responsibility. If a package is blocked because of autopkgtest regressions in reverse dependencies, the expectation is that the uploader files the appropriate release-critical bugs.
Suggested Read 📖: Linux is Getting a Kill Switch!
Sourav Rudra
