bug#44559:

["Ludovic Courtès" <ludo@gnu.org>]

Hi Carl,

Carl Dong <contact@carldong.me> 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’.