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

["Ludovic Courtès" <ludo@gnu.org>]

Hi Konrad!

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

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

That’s a commit from January 2018, which is a few months before the
release of 0.15.0, the first release with proper ‘guix pull’ support:

  https://guix.gnu.org/en/blog/2018/gnu-guix-and-guixsd-0.15.0-released/

In other words: warranty void.  :-)

We can go back to 1.0.0, and presumably to 0.15.0, but anything older
than this is unknown territory.

> First attempt:
>
>    $ guix time-machine --commit=f250a868d8c687df08559682fa68fb4ea2a1ea69 -- build nmoldyn
>    Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...

[...]

>    ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>    error: %guix-register-program: unbound variable

It’s a variable that used to exist in (guix config) but was removed long
ago (in ea0a06cee2ba05451f94714a4f913db02efbe92c, shortly before
0.15.0.)

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

It could check whether the target commit is in the closure of the
v0.15.0 commit, but then that would give special treatment to the
existing commit history.  Maybe that’s OK though?

> 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

We’d have to check what’s in ‘test-suite.log’; it might as well be an
environment issue more than a “real” problem.

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

IIRC that was a bug in a Gnulib test (bundled in several GNU packages)
that would hang on machines with maybe more than 4 cores.  (See commit
acc2dab7f2f50c9169d6388007c770878eae4a9c for example.)  There might be
hints on how to work around it in the mailing list archive…

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

Again, none of this should be necessary as long as the target commit is
after 0.15.0 (or 1.0.0).

That said, it may be possible to build that Jan. 2018 Guix using an
environment created from Guix 0.15.0 or 1.0.0; it’s likely to have the
right versions of dependencies, and it should be reachable with
time-machine.

I’d be curious to hear how it goes!

Besides, I recently added ‘etc/time-travel-manifest.scm’ and added a
corresponding jobset at <https://ci.guix.gnu.org/jobset/time-travel>
(the jobset is not working well, but that’s because there are several
processes concurrently accessing the same cached checkout; we need a
trick to work around that…).  I’d like to consolidate this so we can
make sure that traveling back in time (after 0.15.0 or 1.0.0) remains a
possibility.

Thanks,
Ludo’.