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

[Timothy Sample]

Hi Konrad,

Ludovic Courtès <ludo@gnu.org> writes:

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

Agreed.  That’s probably too early in Guix’s history to get good
results.  Keep in mind that the Software Heritage crawlers only started
indexing Guix packages in 2019.  That being said, I was too curious to
leave this alone, so I tried my hand at building that package from that
commit.

> [...]

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

It turns out it’s pretty easy, apart from having to boil the ocean.
Here’s what I did.

I decided to try the easiest thing first, which is checkout f250a86 and
try to build it with an environment from modern Guix.  We still have
Guile 2.2 packages, after all.  Here’s the environment that I used:

    $ guix shell --pure guile@2.2 guile2.2-gnutls guile2.2-gcrypt \
          gcc-toolchain coreutils bash autoconf automake guile2.2-git \
          sqlite bzip2 gettext libtool pkg-config grep sed patch \
          diffutils m4 findutils tar xz gzip libgcrypt gawk make\
          texinfo help2man

>From there, I was able to build Guix normally.  Some of those packages
were guesses, and some were added to placate “configure”, I’m not sure
that all of them are necessary, but they are sufficient.

After that, I tried

    $ ./pre-inst-env guix build nmoldyn

It hummed along for a long time, and then my desktop crashed due to the
kernel’s out-of-memory process killer.  For whatever reason, and even
with 16G of RAM and 16G of swap, the Python 3 build gets smitten by the
OOM killer.  It happens when running the test suite, so I disabled it.
(From what I read, the test suite is used to generate profiles to train
the optimizer, so this is probably a bad idea.  I decided to forge ahead
instead of worry about this too much.)

Next, it couldn’t find the source code for ImageMagick 6.9.9-30.  It
took a minute, but I tracked it down hidden in the following RPM:

    
http://mirror.speedpartner.de/remi-archive/SRPMS/ImageMagick6-6.9.9.30-1.remi.src.rpm

After extracting the tarball and adding it to the store with
“guix download”, the build continued.

There was one other source code issue, which was Mesa 17.2.1.  It was
easy to solve, as they just moved it to the “older-versions” directory
on their server.

The only other two issues were test failures due to certificate expiry.
It happened for Python 2 and NSS.  I remember there was a discussion
about this problem in general recently, but I couldn’t track it down.
For Python 2, I disabled the offending tests, and for NSS, I just
disabled the whole test suite.

After that, I got:

    @ build-succeeded 
/gnu/store/40x598cvpp16m87z52sj98c62dfbmmka-nmoldyn-3.0.11.drv -
    /gnu/store/khf2pf29vfq6b3dcca9p9mvz387jvdl7-nmoldyn-3.0.11

I’m honestly shocked that it worked so well.  I wish I had a better way
to keep track of where the sources came from.  For example, I’m curious
how many came from the build farm or other fallback options.

Overall, I give Guix two thumbs up!  Other than the Python 3 optimizer
bit (which might be solvable), nothing substantive had to be changed to
make this happen.

For best practices, I do have one suggestion.  The Guix package
collection is not uniformly reproducible or archived.  The best thing
you can do to ensure the long-term prospects of your projects is to
actually check how much of the source code is archived and how many of
the builds are reproducible.  There is no turn-key solution for this
(though maybe there should be), but you can check the source code
against the Preservation of Guix database [1], and you can check
reproducibility using the Guix Data Service or with “guix check”.
Ideally everything would be archived and reproducible, but it’s a work
in progress.  By checking, you might be able to fix some of the issues
now while it’s easy instead of in five or ten years when it’s
impossible!

Thanks Konrad for the interesting experiment.  While testing this out, I
came to really appreciate how hackable Guix is.  Even if I couldn’t find
Mesa 17.2.1, say, I could proceed with a similar version or try to build
it with Git.  It’s not ideal to have to make changes, but it’s nice to
know that Guix fails gracefully.

In case it’s useful, I’ve attached the changes I made.


-- Tim

[1] It’s at <https://ngyro.com/pog-reports/latest/>, and yes, I know I
ought to update it!  :)

patch.diff
Description: Text Data