all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* A real-life test of long-term reproducibility
@ 2022-08-04  8:43 Konrad Hinsen
  2022-08-04 15:35 ` blake
  2022-08-07 20:53 ` Ludovic Courtès
  0 siblings, 2 replies; 15+ messages in thread
From: Konrad Hinsen @ 2022-08-04  8:43 UTC (permalink / raw)
  To: Guix Devel

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-09-07 16:07 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-04  8:43 A real-life test of long-term reproducibility Konrad Hinsen
2022-08-04 15:35 ` blake
2022-08-19  9:34   ` zimoun
2022-08-07 20:53 ` Ludovic Courtès
2022-08-08  5:21   ` Timothy Sample
2022-08-08  8:44   ` Konrad Hinsen
2022-08-19 10:25     ` zimoun
2022-08-22 11:34       ` Konrad Hinsen
2022-08-08  8:49   ` Konrad Hinsen
2022-09-02 13:17     ` Ludovic Courtès
2022-09-02 14:18       ` zimoun
2022-09-05  7:49         ` Konrad Hinsen
2022-09-05  9:32           ` zimoun
2022-09-05  9:51       ` Ludovic Courtès
2022-09-07 15:39         ` Konrad Hinsen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.