Hi Konrad, Ludovic Courtès writes: > Konrad Hinsen 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 , and yes, I know I ought to update it! :)