Reproducible Builds summit report


#1

@Profpatsch , @lewo, @edolstra and me went to the summit this week. It was a lot of fun. We met with people from all sorts of distros; Debian, OpenSuse, Arch Linux, Alpine, and obviously Guix. Members of IPFS, QubeOS, Ocaml and Microsoft(?) were also present. We were ~50+ people total.

Some highlights from my side:

Everyone intuitively knows why reproducible builds are important but it’s actually quite hard to explain why. I still don’t have an answer that is easy to explain.

The Guix team is working on bootstrapping GCC from a few bytes of binary, to a minimal scheme interpreter, TCC, an old version of GCC -> until the latest GCC. And happy to share their results with other distros. @edolstra was taking a look at it.

Did you know that nix-build has a --check flat? It builds the derivations twice and tells you if the output differs. And Hydra also supports that feature but it’s undocumented.

https://reproducible-builds.org/ has a bunch of tools that could be useful for us. I think @Profpatsch packaged most of them.

Ruby gems that contain C extensions are not bit-reproducible as they contain logs. @lewo was looking into this.

The only thing I implemented in the end had nothing to do with reproducible builds. Inspired by Guix, Nix will have nicer hash mismatch messages in the next release: https://github.com/NixOS/nix/commit/5e6fa9092fb5be722f3568c687524416bc746423

Please add anything I forgot or didn’t pay attention to :slight_smile:


#2

The event was organized without a fixed schedule, rather the
organizers implemented a scheme wherein participants would form around
topics that interested them.

Most sessions had somebody take notes, the reports are going to be
published in a “Reports” section on the event page soon:
https://reproducible-builds.org/events/paris2018/

Here I wrote down some interesting one-on-one conversations I had over
the three days.

2018-12-11

  • Ludovic
    Met Ludovic, the founder of the Guix project. Asked him how and why
    he started (2012, he’s a Guile maintainer and played around with
    driving Nix with Guile).

  • Bernhard
    OpenSuse employee who works on pushing reproducibility patches
    upstream. He has a suite of scripts to detect these issues.
    https://github.com/bmwiedemann/reproducibleopensuse

  • Repeatr
    Generic stack to repeat containerized computations, via runc &al.
    Not really sure what it does or what’s it for, and the contributors
    weren’t able to give a practical use-case.
    https://github.com/polydawn/repeatr

  • Nix vs. Guile
    Talked to a few people (Eelco, Ludovic, …) about the differences.

    • DSL vs EDSL
      Guile has a giant advantage in tooling, because everything is a
      Scheme library, and to build a tool (even just experiment) you
      have one unified environment at your fingertips.
  • Rep.B. Tooling
    https://pad.riseup.net/p/rbws18-tools
    Quite comprehensive, especially reprotest is nice (can test any
    command for reproducibility!). Not packaged for nixpkgs yet!
    Maybe set up automatic CI for these tests? Hydra?
    There should be a matrix of which tools is packaged on which
    distribution already.

2018-12-12

2018-12-13

  • Missed the first part, joined after lunch (Appartment search)
    It was mostly a hacking session in the afternoon.
    Since I had to organize additional appartment-related things, I
    wasn’t able to continue working on the tools matrix very much.
    The event ended with a thank-you session & continued hacking while
    people were slowly leaving.
  • Tansy
    Tansy is working on a build system similar to bazel, pants. It was
    created by ex-Googlers and used primarily for its excellent Scala
    support (because sbt is a horror show).
    I brought up the notion that build tools tend to be able to
    integrate support for different languages, but don’t play fair when
    it comes to integrate themselves into other build systems. For
    example nix assumes access to /nix, bazel uses a daemon with long
    startup time and makes it hard to inject e.g. a prebuilt protobuf.

#3

This is a really nice event where it’s easy to meet and discuss with a
lot of people, thanks to the non classical format as explained by
@Profpatsch.

The option mentioned by @Zimbatm is actually build-repeat 1 which
is useful to check the reproducibility of builds. But there are still
some reproducibilitly issues that could be hard to hit with this
option such as in [1,2]: the contents of the file depends on the
file order on the FS. For this kind of issues, I started to enable
disorderfs [3] in the sandbox when the build-repeat option is
set, but this is not finished yet.

Since the IPFS community was present, we also discussed about IPFS
and binary caches! Guix people seem to be pretty interested in improving
performances of their binary cache (which doesn’t rely on AWS/CDNs).
To be continued…

[1] https://github.com/pypa/pip/pull/5525
[2] https://github.com/rubygems/rubygems/pull/2524
[3] https://salsa.debian.org/reproducible-builds/disorderfs


#4

This is a great change; thank you @zimbatm!