[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A real-life test of long-term reproducibility
From: |
Konrad Hinsen |
Subject: |
Re: A real-life test of long-term reproducibility |
Date: |
Mon, 08 Aug 2022 10:44:44 +0200 |
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.