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

[Konrad Hinsen <konrad.hinsen@fastmail.net>]

Hi Ludo and Tim,

Thanks for your comments and experiments!


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

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

Ouch. I wasn't aware that even "guix pull" happened later!

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

I'd say yes, because the only problem is the existing commit history.
At least until we extend time-machine to actually change the past ;-)

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

Hardware dependencies...

> 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'll try with 1.0.0, that looks nicer than 0.15.0 ;-)

> Besides, I recently added ‘etc/time-travel-manifest.scm’ and added a
> corresponding jobset at <https://ci.guix.gnu.org/jobset/time-travel>

Nice! Guix will be certified for time travel!


Timothy Sample <samplet@ngyro.com> writes:

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

Very interesting, thanks!

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

Indeed. And yet, from the point of view of a non-expert user, even the
slightest fix required is a show stopper.

> 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

Yes, that's a good idea, and I have done it for my most recent packages.
Time will tell if this is enough.

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

Definitely!

Cheers,
  Konrad.