bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44559:


From: Carl Dong
Subject: bug#44559:
Date: Fri, 19 Feb 2021 18:49:20 -0500

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’.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]