From: ludo@gnu.org (Ludovic Courtès)
To: guix-devel@gnu.org
Subject: Re: Reproducible Build Summit
Date: Wed, 09 Dec 2015 15:08:34 +0100 [thread overview]
Message-ID: <87r3ivr9y5.fsf@gnu.org> (raw)
In-Reply-To: <87wpst7tk1.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 04 Dec 2015 20:54:57 +0100")
ludo@gnu.org (Ludovic Courtès) skribis:
> Eelco, Manolis, and I sat together for the hacking sessions. I
> focused on shamelessly stealing the Nix daemon’s ability to rebuild a
> derivation and error out if the result differs (commits 07e70f4 and
> 708d907.)
Commit a8d6564 adds the --check option for ‘guix build’:
‘--check’
Rebuild PACKAGE-OR-DERIVATION, which are already available in the
store, and raise an error if the build results are not bit-for-bit
identical.
This mechanism allows you to check whether previously-installed
substitutes are genuine (*note Substitutes::), or whether a
package’s build result is deterministic. *Note Invoking guix
challenge::, for more background information and tools.
and commit 5b74fe0 adds --rounds:
‘--rounds=N’
Build each derivation N times in a row, and raise an error if
consecutive build results are not bit-for-bit identical.
This is a useful way to detect non-deterministic builds processes.
Non-deterministic build processes are a problem because they make
it practically impossible for users to _verify_ whether third-party
binaries are genuine. *Note Invoking guix challenge::, for more.
Note that, currently, the differing build results are not kept
around, so you will have to manually investigate in case of an
error—e.g., by stashing one of the build results with ‘guix archive
--export’, then rebuilding, and finally comparing the two results.
I encourage you to use the latter when adding new packages and to
investigate any reproducibility issues!
> I also discussed with Eelco the fact that the daemon was leaking the
> real name of the build directory, meaning that if a build machine
> runs:
>
> TMPDIR=/foo/bar guix-daemon
>
> and the other runs:
>
> TMPDIR=/tmp guix-daemon
>
> then the first build process will see a directory called
> /foo/bar/nix-build-xxx. If it captures the build directory name,
> then we get a discrepancy. Eelco quickly changed that, such that the
> build process always sees /tmp/nix-build-xxx:
> <https://github.com/NixOS/nix/commit/8063fc497ab78fa72962b93874fe25dcca2b55ed>.
> I’ll merge this commit soon.
Done in cb96010.
Ludo’.
next prev parent reply other threads:[~2015-12-09 14:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 19:54 Reproducible Build Summit Ludovic Courtès
2015-12-05 9:02 ` Manolis Ragkousis
2015-12-09 14:08 ` Ludovic Courtès [this message]
2015-12-09 16:42 ` Shared reproducibility issue database Ludovic Courtès
2016-01-15 10:36 ` Reproducible Build Summit Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r3ivr9y5.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.