GNU bug report logs - #44559
gnutls 3.6.12 fails to build: FAIL: status-request-revoked

Previous Next

Package: guix;

Reported by: Christopher Baines <mail <at> cbaines.net>

Date: Tue, 10 Nov 2020 20:50:02 UTC

Severity: important

Tags: moreinfo

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Carl Dong <contact <at> carldong.me>
Cc: 44559 <at> debbugs.gnu.org, Mathieu Othacehe <othacehe <at> gnu.org>, Christopher Baines <mail <at> cbaines.net>
Subject: bug#44559: 
Date: Fri, 19 Feb 2021 16:33:48 +0100
Hi Carl,

Carl Dong <contact <at> 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 <at> 3.6.14
> 	2. --without-tests=gnutls
> 	3. --with-input=gnutls=gnutls <at> 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’.




This bug report was last modified 2 years and 364 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.