Documentation II

riseup notepad for facillitating feedback: FAQ Feedback

Personas

  • users
    • what does a user need to know to make a package build reproducibly?
    • what is a reproducible build?
    • link to definition
  • upstreams
    • how do i make my software reproducible?
    • how to avoid certain programming pitfalls?
    • timestamps, etc. link to FAQ for upstream?
  • package maintainers (Debian specific?)

Homepage

  • Definition for RB (to be defined)

Involved Projects

Current status? no, it will get out of date quicker than anyone can update it

  • Debian - 92% of source packages are reproducible (link to tests.r-b.o ?)
  • FreeBSD - base is mostly ok, loader not, kernel not (but some patch/flag exists), ports (80% with external patch on the framework)

distro / project-specific pages!

  • find a list of contacts for these projects and propose them to add information to the website or to send a link to their documentation,
  • also ask them to add a contact for RB who people can talk to

  • Debian: https://lists.reproducible-builds.org/listinfo/rb-general, IRC: #debian-reproducible @ OFTC
  • ArchLinux
  • Baserock
  • Bitcoin
  • Coreboot: ask lynxis
  • ElectroBSD: https://archive.fosdem.org/2016/schedule/event/electrobsd/
  • F-Droid
  • FreeBSD: -> email alias or ML to be provided (reproducibility@FreeBSD.org)
  • Fedora
  • Guix
  • LEDE
  • NetBSD
  • NixOS
  • openSUSE
  • OpenWRT: ask lynxis
  • Tails: Public development list: tails-dev@boum.org
  • don’t forget to copy and then remove current Debian wiki pages

Top level pages

  • adding talks page! (most from debian), videos
  • reproducible builds definition

Projects

  • add bazel to tool page

FAQ sections (instead of personified personas, let’s ask concrete questions!)

introduction to faq: to add things/links that does fit into five sections

  • “what is reproducible builds?”
  • “what is the status of reproducible builds?”
  • “why should I (as a user) care about reproducible builds?”

(single page so it is easier to search everything at once)

  • I’m interested in verifying the reproducibility of software I use
  • I’m interested in making reproducible software
  • I’m interested in packaging/distributing software in a reproducible way
  • But it still doesnt work! -> link to Currently unresolved issues
  • What are the benefits of reproducible builds
  • how can help with license compliance
  • (take the work on use cases and side-benefits and put it here)
  • I don’t think reproducible builds are actually useful
  • here we need to answer all the questions like “I want to hardcode paths” etc.
  • why can’t we just normalise the <build path, environment, dependencies, whatever>?
  • I really like <timestamps, machine/person who built the binary>!
  • how to build your how build farm?

Get involved page

FAQ

1/ how to deal with compression tools?

  • GZIP: use gzip -n
    • how do I make (GZIP, etc…) give reproducible output? (section: projects)

2/ why is reproducibility important? * where do I get information for XYZ? (section: users)

3/ why using SOURCE_DATE_EPOCH and not simply set everything to 0 (epoch time) lots of build system will reject dealing with files that have a timestamp that old (we need concrete example (section: project)

4/ how to write reproducible code in specific languages - e.g. Rust, Go

  • Python: Pyc files, PYTHONHASHSEED
  • C: uninitialized memory (msan, asan), readdir order
  • emacs bytecode
  • how/who to contact for cross distro collaboration? answer: here!
  • how to handle signatures in binaries
  • squashfs?

To be discussed

  • Merge /tools to the documentation?

How to get involved?

  • how to help various projects?
  • how to help with documentation?
  • how to help with outreach
  • how can I sponsor the effort?

Talks

Tools

  • where to find the tools

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.