- 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?
REPRODUCIBLE FILESYSTEM IMAGES (SEE ALSO: SQUASHFS)
- 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)
BUILDINFO (GENERAL, DOC, ADVOCACY)
- 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?
BUILD INFO (IMPLEMENTATION) / DEBIAN INFRASTRUCTURE
- (debian only) can we do anything productive to get =.buildinfo= files in ftp.debian.org?
- 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)
ADVOCACY TO PROJECTS
- 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
LEGAL AND LAW
- 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
OUTREACH / COMMUNICATIONS (NON TECHNICAL PEOPLE)
- 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?
OUTREACH / COMMUNICATIONS (DEVELOPERS)
- 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 t.r-b.org 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)
TEST.R-B-ORG CROSS DISTRO
- Hack the site for easier extendability to other tested projects (2)
- Adding GNU Guix to t.r-b.org (1)
- Adding openSUSE to t.r-b.org
- Better include non-Debian in t.r-b.org (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 (r-b.org)
- 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)
BUILD PATHS / SOURCE_PREFIX_MAP
- 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)
Follow us on Twitter @ReproBuilds, Mastodon @email@example.com & Reddit 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. • Full contact info