@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.
The event was organized without a fixed schedule, rather the
organizers implemented a scheme wherein participants would form around
topics that interested them.
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).
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 Riseup Pad
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
Hacksession: Package Matrix for Tools — reproducible-builds.org
I hosted two hacking sessions to show & improve the distribution of
Rep. Builds tools on various distros. Writeup here: Riseup Pad
(and later in the agenda)
Typesystem for JSON
Met a person who is writing a typesystem for JSON files for some
IPFS-related project. Since I had already done something similar
for nix expressions
(https://github.com/Profpatsch/nixpkgs/blob/43a5946dd3f2059f960f517f929b174f7099094d/lib/types-simple.nix)
I explained my implementation. An interesting question that came
up: What if you don’t want the type specifications to be literal
functions in an untyped setting, but make them data (e.g. by
representing them in JSON) that can only be combined in a certain
way.
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.
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…
