On Tue, Feb 16, 2021 at 04:00:11PM -0500, Carl Dong wrote: > Hi all, > > As bitcoin core begins the planning to officially transition to Guix-based > releases, I've had many community members build guix v1.2.0 from source and > afterward attempt `--bootstrap --no-substitutes` builds. As you may imagine, > they are getting stuck on this gnutls problem and cannot proceed further. > > I'm wondering: > > 1. Is there a workaround that does not involve changing the system time? We > have attempted several flags: > 1. --with-graft=gnutls=gnutls@3.6.14 > 2. --without-tests=gnutls > 3. --with-input=gnutls=gnutls@3.6.14 > These attempts all failed to work around this bug, and I’m curious as > to why that would be. My guess would be that when we do `--bootstrap`, Guix > bootstraps itself first without taking into account these flags? > > 2. Since bootstrappability is one of the core tenets of Guix, might it be > appropriate to cut a v1.2.1 release with this problem (and any other > potential bootstrap problems) fixed? (Happy to discuss in separate thread if > more appropriate)
You should see what the Guix maintainers say about this. My personal opinion is that you should fork Guix your use case. If you are building from the bootstrap, there is little added cost to making minor adjustments like disabling this test. You can periodically re-sync your fork with GNU Guix as convenient. And it's probably more in tune with your threat model. [0] This problem of "expiring software" has occurred several times in Guix's history and I'm sure it will happen again. In general, users are expected to use substitutes to work around it. They are no worse off than with traditional binary distros in that case. [0] Savannah is great but lacking the resources to devote to security.
