bug#44559:

[Carl Dong <contact@carldong.me>]

Hi Guix!

Thanks to all of you for your thoughtful replies!

On Feb 19, 2021, at 10:33 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> 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’.
I’m very heartened by your affirmation of the project’s support of bootstrappability and building from source. :-)

In addition, I think it would be good to make sure that the package transformation options are powerful enough to allow users to sidestep these problems in their own workflow and decrease the pressure on maintainers.

On Feb 19, 2021, at 10:33 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> ‘--without-tests’ should work, but you need to pass the right version
> number I guess?

Oh! That may be the case. I am using `guix time-machine` however, and that does not yet have the `--without-tests` flag, I have opened bug#46650 so that we can discuss that issue there.

On Feb 19, 2021, at 1:32 PM, Maxime Devos <maximedevos@telenet.be> wrote:
> Alternatively, could the build container be adjusted to always begin at
> 1970-01-01, using ‘time namespaces’?
Unfortunately, as Ludovic mentioned earlier in this thread, time_namespaces(7) is only for CLOCK_MONOTONIC and. CLOCK_BOOTTIME. :-(

Carl Dong
contact@carldong.me
"I fight for the users"

> On Feb 19, 2021, at 10:33 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> 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’.