Hi Carl, Carl Dong skribis: > 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. Yeah. :-/ > 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? ‘--without-tests’ should work, but you need to pass the right version number I guess? > 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) I agree it’s a problem, and yes, it would probably be a good idea to release 1.2.1 with the upgraded GnuTLS we now have in ‘master’. Longer-term, we need to find a way to address or avoid this issue. A brute-force approach would be to have the build machines at ci.guix run with a clock ten years ahead. That should generally be fine since the only place where timestamps matter are unmodified upstream tarballs. In all other cases, mtime is set to 1. Perhaps we could start by testing this hypothesis on a separate build farm. Chris, Mathieu, WDYT? Thanks, Ludo’.