From: Konrad Hinsen <konrad.hinsen@fastmail.net>
To: "Ludovic Courtès" <ludo@gnu.org>
To: Timothy Sample <samplet@ngyro.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: A real-life test of long-term reproducibility
Date: Mon, 08 Aug 2022 10:44:44 +0200 [thread overview]
Message-ID: <m1czdb3z0j.fsf@fastmail.net> (raw)
In-Reply-To: <87iln3bwrm.fsf@gnu.org>
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.
next prev parent reply other threads:[~2022-08-08 9:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1czdb3z0j.fsf@fastmail.net \
--to=konrad.hinsen@fastmail.net \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.