GNU bug report logs - #70662
Problems building nss@3.98.0

Previous Next

To reply to this bug, email your comments to 70662 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: bug-guix <at> gnu.org
Subject: Problems building nss <at> 3.98.0
Date: Tue, 30 Apr 2024 10:02:28 +0100

[Message part 1 (text/plain, inline)]

nss <at> 3.98.0 seems really difficult to build, currently on the bordeaux
build farm it's failed all attempts to build it on all architectures
except riscv64-linux and aarch64-linux [1].

1: https://data.guix.gnu.org/revision/9593750698394b6fecd73e7fca00409ea1ffa2e3/package/nss/3.98.0?locale=en_US.UTF-8

The 3.88.1 version seemed to have built fine, so what's up here?

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 70662 <at> debbugs.gnu.org (full text, mbox):

From: Christina O'Donnell <cdo <at> mutix.org>
To: Christopher Baines <mail <at> cbaines.net>,
 Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: Guix Devel <guix-devel <at> gnu.org>, 70662 <at> debbugs.gnu.org,
 70663 <at> debbugs.gnu.org
Subject: Re: Scheduling a new release?
Date: Tue, 14 May 2024 11:19:57 +0100

Hi,

On 08/05/2024 14:01, Christopher Baines wrote:
> I think it would be nice to have a new release, and indeed release more
> often, I think the way to get there is for less things to be broken
> between releases, such that releasing takes less effort in terms of
> testing and fixing things.
>
> To give some specific issues, I've run up against the recent issues with
> nss [1][2] and I don't think we could release with the nss package as is
> currently.
>
> 1: https://issues.guix.gnu.org/70662
> 2: https://issues.guix.gnu.org/70663

I can fix these by disabling tests, but I would prefer if someone with 
more experience packaging for guix could make a decision on it. 
Otherwise, I don't have any problem reducing the number of tests and 
disabling all tests on PowerPC at least.

I could also do some analysis if it was deemed necessary, inserting a 
patch to measure the timings of each test/cycle. Additionally, I could 
try packaging some of the versions between 0.88 and 0.98 to identify the 
exact change that could be to blame. However, both of these seem 
overkill, given the backlog of patches/issues we have left to get 
through, and the manpower we currently have to work with.

Would any of that be helpful?

> ...

Kind regards,

Christina

Message #11 received at 70662 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Christina O'Donnell <cdo <at> mutix.org>
Cc: Guix Devel <guix-devel <at> gnu.org>, 70662 <at> debbugs.gnu.org,
 Christopher Baines <mail <at> cbaines.net>, 70663 <at> debbugs.gnu.org,
 Simon Tournier <zimon.toutoune <at> gmail.com>
Subject: Re: bug#70662: Problems building nss <at> 3.98.0
Date: Tue, 21 May 2024 19:42:33 -0400

Hi,

Christina O'Donnell <cdo <at> mutix.org> writes:

> Hi,
>
> On 08/05/2024 14:01, Christopher Baines wrote:
>> I think it would be nice to have a new release, and indeed release more
>> often, I think the way to get there is for less things to be broken
>> between releases, such that releasing takes less effort in terms of
>> testing and fixing things.
>>
>> To give some specific issues, I've run up against the recent issues with
>> nss [1][2] and I don't think we could release with the nss package as is
>> currently.
>>
>> 1: https://issues.guix.gnu.org/70662
>> 2: https://issues.guix.gnu.org/70663
>
> I can fix these by disabling tests, but I would prefer if someone with
> more experience packaging for guix could make a decision on
> it. Otherwise, I don't have any problem reducing the number of tests
> and disabling all tests on PowerPC at least.
>
> I could also do some analysis if it was deemed necessary, inserting a
> patch to measure the timings of each test/cycle. Additionally, I could
> try packaging some of the versions between 0.88 and 0.98 to identify
> the exact change that could be to blame. However, both of these seem
> overkill, given the backlog of patches/issues we have left to get
> through, and the manpower we currently have to work with.
>
> Would any of that be helpful?

I just encountered the following single test failure building on
powerpc64le:

--8<---------------cut here---------------start------------->8---
time certutil -K -d /tmp/guix-build-nss-3.99.0.drv-0/nss-3.99/tests_results/security/localhost.1/bigdir -f ../tests.pw
------------- time ----------------------
real 10.32 user 10.25 sys 0.07
10 seconds
dbtests.sh: #27: certutil dump keys with explicit default trust flags  - FAILED
--8<---------------cut here---------------end--------------->8---

with the summary:

--8<---------------cut here---------------start------------->8---
SUMMARY:
========
NSS variables:
--------------
HOST=localhost
DOMSUF=localdomain
BUILD_OPT=
USE_X32=
USE_64=1
NSS_CYCLES=""
NSS_TESTS=""
NSS_SSL_TESTS="crl iopr policy normal_normal"
NSS_SSL_RUN="cov auth stapling signed_cert_timestamps scheme"
NSS_AIA_PATH=
NSS_AIA_HTTP=
NSS_AIA_OCSP=
IOPR_HOSTADDR_LIST=
PKITS_DATA=
NSS_DISABLE_HW_AES=
NSS_DISABLE_HW_SHA1=
NSS_DISABLE_HW_SHA2=
NSS_DISABLE_PCLMUL=
NSS_DISABLE_AVX=
NSS_DISABLE_ARM_NEON=
NSS_DISABLE_SSSE3=

Tests summary:
--------------
Passed:             79016
Failed:             1
Failed with core:   0
ASan failures:      0
Unknown status:     2
TinderboxPrint:Unknown: 2

error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "faketime" arguments: ("2024-01-23" "./nss/tests/all.sh") exit-status: 1 term-signal: #f stop-signal: #f> 
phase `check' failed after 36124.0 seconds
command "faketime" "2024-01-23" "./nss/tests/all.sh" failed with status 1
builder for `/gnu/store/q3cqzzd4fg384lfmk91gd6higsyhs1nq-nss-3.99.0.drv' failed with exit code 1
@ build-failed /gnu/store/q3cqzzd4fg384lfmk91gd6higsyhs1nq-nss-3.99.0.drv - 1 builder for `/gnu/store/q3cqzzd4fg384lfmk91gd6higsyhs1nq-nss-3.99.0.drv' failed with exit code 1
--8<---------------cut here---------------end--------------->8---

So I'm not sure why, but the 'certutil dump keys with explicit default
trust flags' fails on powerpc64le and should probably be disabled.
Also, 36124 s, ouch!  #70950 should help for that.

-- 
Thanks,
Maxim

Previous Next

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