Re: A real-life test of long-term reproducibility

[blake@reproduciblemedia.com]

Hi Konrad, 

Just one quick comment:

August 4, 2022 8:43 AM, "Konrad Hinsen" <konrad.hinsen@fastmail.net> wrote:

> Hi everyone,
> 
> One of our claims is that Guix can rebuild code identically as long as
> we have a machine with a Linux kernel and a POSIX filesystem.

This actually isn't the claim. Reproducibility is only guaranteed on
Guix systems. It's important that you reproduce the entire system, which
means you will have needed to have saved the commit of your version of
the Guix package manager in order to return to that system.

See the section of the Guix manual "Replicating Guix" for more info.
https://guix.gnu.org/en/manual/devel/en/html_node/Replicating-Guix.html

Happy hacking!

> This week
> I had an occasion to put this to a real-life test. So far it's a
> failure. I can guess reasons for my failed attempts, but I don't think
> they were unreasonable to try. So I'd like to document something that
> works, to avoid others falling into the same traps. I just don't know
> yet what the Right Way To Do It is!
> 
> The package I want to rebuild and use is "nmoldyn" from Guix commit
> f250a868d8c687df08559682fa68fb4ea2a1ea69. That's the commit referenced
> in my notes, obtained via "guix describe" in early 2018. I am pretty
> sure it worked fine back then.
> 
> First attempt:
> 
> $ guix time-machine --commit=f250a868d8c687df08559682fa68fb4ea2a1ea69 -- build nmoldyn
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> Backtrace:
> In guix/store.scm:
> 672:3 19 (_)
> In ice-9/boot-9.scm:
> 1752:10 18 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
> In guix/store.scm:
> 659:37 17 (thunk)
> In guix/status.scm:
> 815:4 16 (call-with-status-report _ _)
> In guix/store.scm:
> 1298:8 15 (call-with-build-handler #<procedure 7ff03a85b960 at guix/ui.scm:1…> …)
> 2168:25 14 (run-with-store #<store-connection 256.99 7ff03b715c30> _ # _ # _ # _)
> In guix/inferior.scm:
> 903:8 13 (_ _)
> In guix/channels.scm:
> 944:2 12 (_ _)
> 891:2 11 (_ _)
> In ./guix/monads.scm:
> 487:9 10 (_ _)
> In guix/store.scm:
> 1996:8 9 (_ _)
> In guix/channels.scm:
> 642:36 8 (_ #<store-connection 256.99 7ff03b715c30>)
> 703:11 7 (_)
> In ice-9/eval.scm:
> 619:8 6 (_ #(#(#(#<directory (build-self) 7ff03a8678c0>) "/gnu/store/…" …) …))
> 626:19 5 (_ #(#(#(#<directory (build-self) 7ff03a8678c0>) "/gnu/store/…" …) …))
> 155:9 4 (_ #(#(#(#<directory (build-self) 7ff03a8678c0>) "/gnu/store/…" …) …))
> 223:20 3 (proc #(#(#(#<directory (build-self) 7ff03a8678c0>) "/gnu/sto…" …) …))
> In unknown file:
> 2 (%resolve-variable (7 . %guix-register-program) #<directory (build-…>)
> In ice-9/boot-9.scm:
> 1685:16 1 (raise-exception _ #:continuable? _)
> 1685:16 0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> error: %guix-register-program: unbound variable
> 
> I don't understand what is going wrong here, but it may be related to
> the fact that the commit I am trying to go back to is older than "guix
> time-machine". If that's the explanation, it would help if Guix showed
> some clear error message instead of crashing.
> 
> Next I tried checking out the source code for commit
> f250a868d8c687df08559682fa68fb4ea2a1ea69, and building it from
> source. This is a bit tricky because 2018 Guix cannot be built in
> today's Guix build environment. For example, today we have Guile 3, but
> back then we had Guile 2.2. So I need to do "guix environment guix" in
> an older Guix, before the Guile 3 transition, but later than the
> introduction of time-machine. I picked one somewhat at random:
> 
> $ guix time-machine --commit=e2293cbbe0cd20ddeb932e6f5616565ab468c087
> -- environment –pure guix
> 
> Then I did "bootstrap", "configure –localstatedir=/var", "make
> check". The latter shows 15 failures, some of which look important:
> 
> FAIL: tests/builders.scm
> FAIL: tests/derivations.scm
> FAIL: tests/packages.scm
> FAIL: tests/guix-environment.sh
> FAIL: tests/guix-daemon.sh
> 
> And indeed I cannot build much with my compiled guix:
> 
> $ ./pre-inst-env guix build nmoldyn
> 
> hangs after a while, running a binary called "test-lock" for hours.
> 
> Given the time lapse, I suppose there have been incompatible changes in
> the build daemon, making the old Guix incompatible with the rather
> recent build daemon running on my machine. But is there a way around
> this, other than installing an old Guix in a fully isolated VM?
> 
> And if installing the old Guix in a VM is the only solution, what would
> be the best way to do that? I can't think of much else than starting
> from another distribution (e.g. Debian) and following the installation
> instructions. That's already a lot of work, but it's made worse by the
> installation instructions being hidden inside the manual of that old
> commit, which I cannot easily consult.
> 
> I'd be grateful for any suggestions!
> 
> Cheers,
> Konrad