Problems building nss@3.98.0

  • Open
  • quality assurance status badge
Details
3 participants
  • Christina O'Donnell
  • Christopher Baines
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Christopher Baines
Severity
normal
C
C
Christopher Baines wrote on 30 Apr 11:02 +0200
(address . bug-guix@gnu.org)
87v83zxly3.fsf@cbaines.net
nss@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].


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

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmYws6RfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XdrqxAAr4lt8ah2D5HVmer5Vmgw6g7/bQgp5wIn
oDm5oYdyR4UOJr5kGQKxl8yuwxOmzxZDws1e+xndAAdLcKxbuiX/afjkhE0N6Oqt
ecDqcSNVAPQ7tHA/iLkxeC5k2GGcQ2OlFr6aXHeiUmN5SBZYNuTJUBr5rU0hcDZB
Z3SN8qU3+X/Geu0TZVYTq9YAvrsKXiDLKG2nSYyxkVsCSqIVJD5sQMOcVssxO/UJ
5Iu+W4tzjUqDI4E52OYmCu+fvOqvDSA9FQmh9ER2I0IOES4sdpetHle1bvHcK26a
BsGvrGYAYycOPjCTGp324mwbA7RZaUu2C4i0hcVOJDLpRYEmKlHikEx3Q474m/Cj
pP6k3wH0mm/0/GeEh0/hA1zm+sMSegmfuamoOMpCednDg3/Wd1epSlOL1ZKoqz9P
ZslbU0qIXLDHSVx9NvpcWMVkNx/i37h0GrDT529L/SUHVwSpJU9cnfH+JbbyDPNx
elN4jCUYy0unhueCbrOvl2+erxVn2yLjo6UBDP4b2YMQ9zEgLNlo2cCs4GLmv8FS
NYrB+UlOJfAumS//75QZixQ4opgHuXbBeLneed90A6sc9V/dlzejxl2oUUk1koLI
aTTw9sdN016V14jze2Tan7je+pnxetnbV+dIXmx34GmofyeP08DQ8a5TyHSywp/C
k0/KA7mpV3E=
=+HgZ
-----END PGP SIGNATURE-----

C
C
Christina O'Donnell wrote on 14 May 12:19 +0200
Re: Scheduling a new release?
339167fe-c899-1303-166f-8040b49f0f59@mutix.org
Hi,

On 08/05/2024 14:01, Christopher Baines wrote:
Toggle quote (12 lines)
> 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?

Toggle quote (2 lines)
> ...

Kind regards,

Christina
M
M
Maxim Cournoyer wrote on 22 May 01:42 +0200
Re: bug#70662: Problems building nss@3.98.0
(name . Christina O'Donnell)(address . cdo@mutix.org)
878r0268ba.fsf_-_@gmail.com
Hi,

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

Toggle quote (29 lines)
> 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:

Toggle snippet (7 lines)
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

with the summary:

Toggle snippet (43 lines)
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

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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 70662@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 70662
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch