Hi Ludo and Tim, Thanks for your comments and experiments!
Ludovic Courtès <l...@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 <samp...@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.
