A real-life test of long-term reproducibility

[Konrad Hinsen <konrad.hinsen@fastmail.net>]

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 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