[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A real-life test of long-term reproducibility
From: |
Konrad Hinsen |
Subject: |
A real-life test of long-term reproducibility |
Date: |
Thu, 04 Aug 2022 10:43:57 +0200 |
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
- A real-life test of long-term reproducibility,
Konrad Hinsen <=