GNU Guix launches [LWN.net]

GNU Guix launches

Posted Nov 26, 2012 7:43 UTC (Mon) by Lev (guest, #41433)
In reply to: GNU Guix launches by idupree
Parent article: GNU Guix launches

You'd probably be interested in Vesta, which dealt with such issues. See http://www.vestasys.org/ and especially http://www.vestasys.org/why-vesta.html

(Log in to post comments)

GNU Guix launches

Posted Nov 26, 2012 8:49 UTC (Mon) by oever (subscriber, #987) [Link]

Guaranteed repeatability of builds. Builds completely specify everything that affects their outcome, including the exact versions of all source files, as well as compiler versions, library versions, etc. This makes it possible to perform any build you've ever done in the past and be certain that you will get identical results. (This can be a big help with finding and fixing bugs and other QA issues; with Vesta you never have to worry that a bug has been masked rather than fixed by intervening changes, because you can always re-build the exact version that exhibited the problem.)

source

In the 'modern' way of working this sounds like magic. I've just tried to build Vesta, but unfortunately it fails on my Fedora machine. So for some reason Vesta did not catch on to a larger audience even though a lot of effort was put in:

Vesta is a mature system. It is the result of over 10 years of research and development at the Compaq/Digital Systems Research Center, and it was in production use by Compaq's Alpha microprocessor group for over two and a half years. The Alpha group had over 150 active developers at two sites thousands of miles apart, on the east and west coasts of the United States. The group used Vesta to manage builds with as much as 130 MB of source data, each producing 1.5 GB of derived data.

source

An updated version of Vesta should probably use Git and combine a sha1 for the toolchain with a sha1 for the code version to get identical binaries and identical binary packages with a checkable checksum.

GNU Guix launches

Posted Nov 26, 2012 16:00 UTC (Mon) by welinder (guest, #4699) [Link]

> Guaranteed repeatability of builds

That would require an audit of all packages' build system to ensure
they only depend on what they claim.

Anything using "date" to embed a timestamp anywhere will not be
repeatable. Anything using /dev/urandom is unlikely to be repeatable.
(I can see collision-hardened hashes do that and hash ordering would
change. You would get in the build phase if that runs anything built.)

GNU Guix launches

Posted Nov 26, 2012 18:54 UTC (Mon) by oever (subscriber, #987) [Link]

The only timestamps in the build should be ones that come from the inputs: the build tools and the source code. There should be no use of randomness in a build.

The value of knowing exactly where your code come from is huge. Currently there is no easy way to check that a binary packages correspond to source packages.

GNU Guix launches

Posted Nov 28, 2012 9:46 UTC (Wed) by oak (subscriber, #2786) [Link]

For example packages going to OBS (OpenSUSE Build Service) are patched to remove such things as it messes up their daily test re-builds. For example:
https://build.opensuse.org/package/view_file?file=inkscap...

Noticing date & time usage in package sources is easy in daily automated builds. Other differentiators taken from the environment are harder to find though, because build machines are pretty identical.