aiming for bullseye!

Holger Levsen

  1. Introduction
  2. Status update
  3. Issues in detail


Reproducible Builds have the purpose to enable anyone to reproduce identical binary packages from a given source.

Project goals

Ensure builds have identical results.

We want to change the meaning of ”Free Software”: It’s only Free Software if it’s reproducible!

Other talks

Bornhack, All Systems Go, All ThingsOpen, OSSE, Hackmit, FreeNode Live, CubaConf, Open Compliance Summit,, FOSDEM, Scale, NYLUG, LibrePlanet, Easterhegg, MiniDebConf Curitiba, Foss-North, FLOSSUK, Uni Dakar, Prototype Fund demo day, mentioned in several talks at 3xC3...

New since DebConf18 Taipeh

We have a logo:

4th Reproducible Builds Summit in Paris

R-B now a Software Freedom Conservancy project

Other projects

Arch Linux at ~80% reproducible packages

openSUSE at 93%

openSUSE and Arch Linux now included in tests.r-b.o database

Alpine being tested since yesterday

NetBSD and FreeBSD base systems at 100% for the base install

Tails 3.3, 3.6.1 → 100% reproducible ISO images

OpenWrt images (most targets)

Collaboration is great

lots of very nice, unexpected results...

Arch Linux Status

In test framework ~80%, [core] repository 85%, in real life...

Recording filesize of a package not reproducible on every filesystem (btrfs, ext4)

Infrastructure changes for reproducibility (archive, BUILDINFO)

Developed a tool to reproduce our repository packages

Making more packages reproducible (which are already fixed in Debian by using the changelog date)

Displaying reproducible-builds progress on our website (JSON endpoint)

Debian buster

“Packages should build reproducibly” added in Debian Policy

Debian installer images

Comparing against packages from the archive

Lots of progress in the last 3 months

Need verification, might reach it for buster.1 "only"

Applied and unapplied patches

What (else) is missing?

GCC -fmacro-prefix-map

#include <stdio.h>
int main() {
  fprintf(stderr, "error at %s line %l", __FILE__, __LINE__); return 1;

$ /usr/lib/gcc-snapshot/bin/gcc -o main /home/user/main.c
$ strings main | grep ^/

macro-prefix-map not accepted by upstream (yet)

so we tag this buster-ignore and (probably) bullseye-ignore as well

simple workaround: rebuild in recorded path

needs someone to drive $this

Debian is wrong

93% is a lie. We need infrastructure, processes and policies. (And testing. Currently we only have testing and a vague goal.)

With the upcoming list of bugs we don't want to fingerpoint at individual teams, instead I think we can only solve this if we as Debian decide we want to solve it for buster.
I think this is not happening because people believe things have been sorted out and we take care of them. But we are not, we can't do this alone.

The difference between theory and practice

93% is a lie.

54% on March 5th 2019.

31% today.

We can still improve this, though 24% (6804) of our source packages have not been uploaded nor binNMUed since December 2016.

I'm not sure I want to / we should upload >5000 source packages in the next 2 years. So mass binNMUs for the rescue?

Major blockers, where to help

sbuild, dput, dpkg: source uploads including _amd64.buildinfo causes problems

binNMUs, mtimes and rsync(1) causes problems and binNMUs should be replaced by easy "no-change-except-debian/changelog-uploads"

blocker for #900837 Mass-rebuild of packages for reproducible builds"

.buildinfo files

#862073 Please POST .buildinfo files to

#763822 please include .buildinfo file in the archive

#862538 Please POST .buildinfo files to

.buildinfo files

.buildinfo files allows submissions from everyone ftp view with pool structure and build date based

.buildinfo files from an unofficial service?

there should be a machine serving .buildinfo files to the public.

since December 2016: 965333 files in total, eg 118195 amd64 related.

12 GB files, 4 GB links.

user facing interface

apt: warn when installing packages that are not reproducible

that would be great for bullseye, but...

the goal should be to not install nor to run unreproducible software.

in-toto (see Lukas' talk before) brings this to the next level...

results saved in common database

json for Debian, openSUSE, Arch Linux, OpenWrt, Alpine

shared notes, cross distro links

two kinds of tests: CI tests (like we have now) and tests against what's on "ftp.(debian|archlinux|...).org"

Debian stretch

the 'reproducibly in theory but not in practice' release

Debian buster

the 'we could be reproducible but we are not' release?

Debian bullseye

the 'we are almost there but still haven't sorted out...' release???

Debian bullseye

the release is still far away and we haven't frozen yet! :-)

Thank you and to all the contributors out there!)

Holger Levsen