Subject: bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

From: Chris Marusich <[email-masked]>
Date: Mon, 04 Jan 2021 19:54:01 -0800

Chris Marusich <[email-masked]> writes:

> If it's just for the sake of trying one last time, we could just add
> --cores=1 to the Guix invocations, or run everything in a single-core
> VM.  Wouldn't that have the same effect?
>
> I think you'll probably agree, so I've proactively started another build
> on two fresh single-core VMs (using the same procedure I described
> earlier, starting from the 1.2.0 installation ISO image).  It'll take a
> few days to finish, I'm sure.  Please let me know if you think we need
> the patch to run this final experiment.  Otherwise, I'll just report the
> results of this latest experiment in a few days' time.

The builds finished on both of my VMs (new ones) the other day. The
result was the same as before: Even when built from source using a
single core and with --cores=1, gcc-static differed, and all other
binaries were identical.  This is more evidence to support the
conclusion that the non-reproducibility is not due to concurrency.

For the record, this is the summary of the final experiment I did:

- I created two new x86_64 VMs using QEMU.
- I used
  https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz
  to install Guix System 1.2.0 on these two VMs.
- I ran: guix pull --cores=1 --no-substitutes --commit=1ced8379c7641788fa607b19b7a66d18f045362b
- I ran: guix build --cores=1 --no-substitutes --target=powerpc64-linux-gnu bootstrap-tarballs
- I didn't run "guix system reconfigure" after installing Guix System;
  theoretically it shouldn't matter, but for the purpose of our
  experiment, I just left the system in its default configuration in
  order to ensure that the kernel etc. would be the same on both VMs.

In reality, it didn't go so smoothly.  While running "guix pull", the
build for guile failed many times before I got it to succeed, which
prompted me to submit this bug report:

"Guile 3 fails to build non-deterministically"
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45574

While running "guix pull", the build for gnutls failed many times and
never succeeded - so I actually did substitute gnutls.  I submitted a
bug report for that one here, too:

"gnutls 3.6.12 can consistently fail to build"
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45578

In any case, this confirms Leo's findings.  It's clear that concurrency
is not the reason why gcc-static builds non-reproducibly.

-- 
Chris