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
