Jérémy Bobbio wrote:
Michael Matz wrote:
On Fri, 11 Dec 2015, Adam Spiers wrote:
Is anyone working on (or thinking of working on) making our build process reproducible?
We have that since about forever as far as easily possible. The hard part is changing packages to not depend on things like build time (e.g. encoding build date/time into strings into executables). That's not something you can do generally in a build system, but must be changed in each and every individual package.
It's probably worth to explain the difference between our reproducible builds and this new interpretation. SUSE and openSUSE distributions have always had reproducible builds, for something like 20 years now. Reproducible in the sense that a packager never builds binaries on his own system in some magic way and then uploads binaries. […]
Thanks Ludwig for your explanations as we unfortunately use some common words to convey different ideas.
Exactly. The Maximum RPM book already advertised "Reproducible Builds" in 1997 without promising bit identical results :-)
I want to try to elaborate on them so we can better colaborate between projects as we—in Tor, Debian and many other projects—strongly believe that these issues concern all free software projects.
I believe we have trouble understanding one another because, from my understanding, we have been working on solving different problems:
The problem openSUSE has solved with OBS is “Can a software be rebuilt from source?”
Yes, we take that for granted.
[...] But end users might want to verify by themselves that binaries match a source code they can audit. When a build process doesn't produce bit-for-bit identical results, this become much harder.
No doubt about that.
Speaking of build-compare, the tool that we built to debug differences between two builds, diffoscope, is getting wider exposure and becoming quite versatile. It's in Python and designed to be as modular as possible. The hope was to have something more maintainable and extensible than a single shell script.
One feature diffoscope is missing to become a proper alternative to build-compare is the ability to filter differences. It's on my list of things to implement, and I'll eventually get to it, but contributions would be great if anyone is interested.
To be usable within build roots it would have to be sufficiently standalone though. Due to the automatic boot strapping and always fresh build roots we have to be careful to avoid polluting build environments and causing build cycles.