Agenda Brainstorming


  • fix for once SQUASHFS (1)
  • fix the mksquashfs file ordering (7)
  • have reproducible SQUASHFS
  • hack on squashfs (2)


  • Removing timestamps from RPM packages (3)
  • How to make repm-build produce repr. rpms (upstream)
  • Discuss RPM metadata reproduc… issues and solutions (2)
  • How to reproduce RPM metadata?


  • What is a (cruft-free) way to save filesystems reproducibly? (defined order, etc.) (1)
  • Check/improve/update the makefs reproducibility patch in FreeBSD (1)
  • Learn how to generate filesystem images reproducibly (ISO, hybridUSB …)
  • Figure out how to build ext4 images reproducibly (in a VM for extra credit) (2)
  • How do we reproduce higher level artifacts, livecds, containers, installers, etc. (2)
  • Determine relevance of reproducibility for non-executable file formats (1)
  • Brainstorm about unreproducible VCS->tarball steps (e.g. autoconf, etc.)
  • What do we use for base images? (2)


  • What is the current status of .buildinfo files? Who uses them, for what reason? (1)
  • How do we use .buildinfo? (1)
  • Disucss .buildinfo service use cases, open questions etc. (7)
  • Write a generic .buildinfo file spec (2)
  • Spread buildinfo in other projects (1)
  • If an executable buildinfo file is good for one precise/pinned version… How do we make the same thing easy to use for future versions?


  • Would like to work on security tools that can be used corss distro/platform. (3)
  • We need tools to find who has reproduced a build? (1)
  • What tooling is out there to help everyone determine reproducibility? (3)
  • How to solve the static library “ar” problem (without breaking apps which build from static libs).
  • How to make reproducibility issues easier to find/debug? (1)
  • How to deal with difference from compress tools like gzip.
  • Is there a way to mitigate the need to sort results of concurrent build operations?
  • Brainstorm/hack on useful docs/tools like SOURCE_DATE_EPOCH and diffoscope
  • How can we remove signatures from OSX applications (1)
  • How can we make VM tests (e.g. OS system test suites) reproducible?
  • How should we explain package relationships OVER TIME? (1)


  • reproducible path from upstream VSC tag to downstream package
  • referencing source state from binaries (1)
  • static analysis scripts/tools to detect possible reproducibility bugs
  • how to address with the timestamp merge


  • collect status on all projects that are trying to become reproducible (1)
  • I am using Mint; is it reproducible?
  • What about Ubuntu; is it reproducible?
  • Get pkgsrc on par with FreeBSD’s ports
  • do a regular inter-project xyz meeting (IRC? Voice?) (1)
  • make “important” packages reproducible, e.g. GCC, glibc, linux, etc (reliably + everywhere)
  • How about fixing legacy/ unmaintained software? (1)


  • there is a perception / accusation amongst the “opponents” of reproducible builds that “we” disagree amongst ourselves what “reproducible” means.
  • which parts of the environment have to change for a repr. build to be allowed to generate a different output? (6)
  • how/what do we hash? (2)
  • can we produce an official definition of r-b?


  • (debian only) can we do anything productive to get =.buildinfo= files in
  • how to patch dak (Debian Archive Kit) in 2016? (4)
  • implement/help with buildinfo distribution in Debian’s FTP (dak software)
  • hack on debrebuild
  • reach 100% r.b. for Debian pkg-pal packages
  • how do debian build profiles and reproducibility fit together?
  • question/Debian: building pkgs in contrib[?] reproducibly? Why do we not do it? :)
  • collect remaining infrastructure issues for reprod. Debian
  • how to make reproducible Debian chroot (get rid of non-deterministic post-installation stuff)? (2)
  • how to archive/distribute Debian buildinfos (1)
  • write dak patch to keep buildinfo files as a temporary measure.
  • discuss Debian “usrmerge” implications for reproducibility
  • scaling reproducibility testing problems and experiences


  • hack diffoscope to make tests less hard linked to specific tool versions (1)
  • what is the state of parallel diffoscope? (7)
  • we need parallel diffoscope
  • collect improvement ideas for tools like diffoscope, stripad[?] (2)
  • what are the main usability issues with diffoscope?
  • bring diffoscope to more platforms (1)
  • look at integrating debdiff & diffoscope
  • hacking session on diffoscope (1)
  • hands on diffoscope, check the new features (1)
  • discuss how diffoscope got better and how it could be even better
  • automatic classification of reproducibility issues in diffoscope (2)


  • Sustained funding
  • How to keep funding sustained & fair (5)
  • Where do we get (more) funding for reproducible builds work? (1)


  • Discuss/advocacy how reproducible builds can improve binary diff (1)
  • Help Mozilla prioritize R.B. HIGHER (2)
  • How to get more upstreams to care
  • How do we socialize benefits of reproducible builds? (overcome developer aversion) (1)


  • Share how Tails takes snapshots of Debian archive
  • How can I address a snapshot of e.g. the Debian archives?
  • Request for skill sharing: vagrant ???? common problems for reproducibility
  • What variables are (surprising) variables affecting builds? (3)
  • Find argument for/against different ways how pkgs built
  • Find the best way of making various packages reproducible


  • Using reproducible builds to improve GPL compliance (4)
  • Are there any legal implications or obstacles to reproducible builds? If so, which jurisdictions are affected? Can we somehow influence the law? In what direction? (2)
  • discuss reproducible builds benefit for GPL enforcement


  • What’s the business case for reproducible builds? (A.K.A. How do I convince non-technical people?)
  • Explaining r-b to non-technical people (2)
  • What can we do to persuade the world that reproducibility really is important?
  • Add new stuff to SELLING POINTS web page
  • Collect benefits of reproducible builds for advocacy
  • Get reproducible builds into space! (NASA? Satellites) Mars colony?) In other words: spread it to more organizations, esp. public research or impacting
  • How do we make the every day user care? (2)
  • How to raise awareness about reproducible builds?


  • Documenting non-obvious benefits of reproducible builds (7)
  • How do we explain with repro.builds are “GOOD”?
  • Are there any projects important for RB, which (we feel) are not cooperative enough? What can we do to address their issues? (1)
  • Convince tool authors about the benefits of reproducibility
  • Coordinate reproducible builds talks at every conference in 2017
  • Selling the reproducible story.
  • How do we communicate the importance of bit-for-bit reproducible?
  • Make a shared statement about bundling and binaries in the package graph. (1)
  • What are all/new uses of reproducible builds? (3)
  • Convince package authors about the benefits of reproducibility
  • How to keep in touch better after this meeting, especially news/changes/improvements (4)
  • Advocacy: How to deal with people that rejects for the sake of debuggability
  • Outrach to potential reproducers: Who can we get to run build farms?


  • Figure out how binary artifact transparency fits into reproducible builds
  • semi OT: What’s the status of binary transparency? (4)
  • What strategies exist for reproducing binaries without build metadata? (1)


  • Design methods for end-user verification of reproducible builds (1)
  • How do we push these benefits to end users? (e.g. apt config to require reproducibility)
  • How can we expose reproducibility to end users? (.e.g user can configure pkg manager to only install pkgs that have been built by >= N people) (1)
  • What tools can we provide for users to gain trust in their systems? (3)
  • If reproducibility is used to increase trust, who actually(!) does the verification?
  • Find a good way to verify coreboot for end users (1)
  • What user-facing tools can we start building now to verify a build? (1)
  • How to let users verify builds on computers w/o keyboards (phones, embedded, etc.)
  • How can we create a “trust infrastructure” on top of reproducible builds? (4)
  • Empower users to verify builds in practice (7)
  • Where do we go next? Assure we get to 100% reproducible package collections, what else should we do? (1)
  • How do we compare reproducible build output (between developers, between projects?, etc.)
  • Discuss user interfaces to repro builds: - ways to check 3rd-party binaries, - ways to choose binaries coming from different orgs


  • Discuss how reprotest could benefit outside Debian
  • Hack on reprotest (2)
  • Make reprotest great & cross-distro (1)
  • Which features should we add to build systems to help reproducibility?
  • How can we simplify finding reproducible build problems?


  • Rebuild everything sytsematically? Can we? Should we? Who is “we?” (1)
  • Drop iframes, how? (2)
  • Make more accessible to screen readers
  • Build and diffoscope debian-cd images on Jenkins
  • Find out how to relay RB test results to the central RB Jenkins
  • Executable reproduce instructions? (2)


  • Hack the site for easier extendability to other tested projects (2)
  • Adding GNU Guix to (1)
  • Adding openSUSE to
  • Better include non-Debian in (6)
  • Work on FreeBSD Jenkins instance (1)
  • Find out how to relay r test results to the central rb Jenkins (2)
  • Build and diffoscope FreeBSD release ISOs (1)
  • Start running r-b tests (arch_dep + arch_indep) on Debian GNU/kFreeBSD and more, submit buildinfos
  • Create a centralized approach/place to share reproducible build patches across distros


  • Easy to use build environment ot make “stand-alone” apps reproducible (2)
  • Talking about reproducibility across very different domains: Android apps, GNU/Linux distctros, JavaEE, ROMs (1)
  • Hack/share issues regarding package systems and format and tools (rpm/deb/freebsd) (5)
  • Move forward the shared database of issues (vz from ath)
  • Discuss more cross-distro coordination opportunitise on an ongoing basis
  • Can we build common tools to record the build environment and dependencies? (2)
  • How do we better collaborate between projects? Debian, Fedora, FreeBSD, …. Issues, technology, patch tracking (3)
  • Are there any good crossplatform build containers/VM setups? (1)
  • Can we make builds verifiable below the distro package level?


  • How do we share reproduce instructions?
  • Get safe hashes everywhere (5)
  • Plan to facilitate collaborative redaction of documentation online (
  • Can we identify formats and toolchains, which are either critical or important for reproducible builds, which are still not taken care of? Is such a list closed?
  • Documentation for package maintainers/upstream to avoid certain pitfalls
  • What are the “best practices” for reproducible builds and we do we spread them? (2)
  • How to make RB project look even less Debian-specific (in marketing, etc.)
  • FAQ: Best practices on website


  • Encourage other toolchains (clang) to adopt SOURCE_DATE_EPOCH and similar approaches (3)
  • Why do we want a SOURCE_DATE_EPOCH other than 1 Jan 1970? (2)
  • Hack Bazel to work with SOURCE_DATE_EPOCH (1)


  • Get GCC build path patches accepted
  • Turn -fdebug-prefix-map environment variable into a standard like SOURCE_DATE_EPOCH
  • Write specification for SOURCE_PREFIX_MAP and promote it (8)
  • Patch LLVM/clang to support SOURCE_PREFIX_MAP (1)
  • Discuss spec for embedded build paths
  • Look at using debugedit in strip-nondeterminism (1)


  • Hack on LLVM/clang/non-GNU toolchains (3)
  • Reproducing binaries with clang (5)
  • Compilers output reproducibility: What’s the current state? Hack on rustc (2)
  • Figure out how to deal with pkgs that use profile-directed optimization (like GCC) (2)
  • How to reproduce Python bytecode .pyc/.pyo files? (4)
  • Is reproducibility attainable between cross builds and native ones? (4)


  • Moving on from x86: bootstrapping new architectures without legacy hardware/software
  • Trusting trust: How close can we get to auditable bootstrapping? (3)
  • Discussing ways to bootstrap GCC from a tinyC compiler (5)
  • Can we build the whole world of Java from source? (3)
  • Drafting recommendations for compiler writers about bootstrapping (1)
  • Debating our stance towards opaque binaries used for bootstrapping (1)
  • Create vision of trustworthy system: free, reproducible, transparent, …
  • Ensure source packages don’t contain binaries/pre-built binaries (1)
  • How to reproduce packages from source only in Debian-like distros
  • How can we trust firmware? (7)
  • How can we trust hardware?
  • Reproducible binaries vs. host dependencies: what is the limit?
  • Are we okay with self-hosted languages? (2)

Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes Agenda brainsorming Post-It notes

Follow us on Twitter @ReproBuilds and please consider making a donation. Content licensed under CC BY-SA 4.0, style licensed under MIT. Templates and styles based on the Tor Styleguide. Logos and trademarks belong to their respective owners. Patches welcome via our Git repository (instructions) or via our mailing list.