Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3.

[Marius Bakke]

Leo Famulari <address@hidden> writes:

> On Tue, Mar 14, 2017 at 05:02:12PM -0400, Mark H Weaver wrote:
>> This is not really sustainable.  A single build attempt takes 7 hours on
>> armhf, and about 40 hours on mips.  When the failure occurs, it causes
>> hundreds of other dependency failures, which must be restarted manually,
>> one at a time, via the web interface.  (We have a way to restart *all*
>> dependency failures, but that results in a huge amount of wasted work
>> for Hydra).
>> 
>> We need test suites to be robust on heavily loaded build machines.
>
> I agree that this situation is not sustainable. If we are committed to
> offering substitutes, we can't have such a critical package not building
> reliably.
>
> But, it seems unsatisfactory to not update NSS / nss-certs without
> working towards a real solution.
>
> Nss-certs provides the CA certificate store in Guix. It does get updated
> along with NSS [0], although not in every NSS release.
>
> I think we should find a way to decouple the certificate store from NSS,
> since we can't build NSS reliably.
>
>> Is there a compelling reason not to revert this update for now?
>
> Since there were no changes to the certificates between 3.29.2 and
> 3.29.3, I think it's fine to revert.

NSS is a crypto library in addition to a certificate store and 3.29.3
resolves a crash when TLS 1.3 is enabled. I don't know how serious this
issue is, but we should try to keep up on both packages.

Nevertheless, I've reverted the commits for now so the old substitutes
should be valid again.

Going forward, I wonder if there could be any unintended side effects by
simply increasing the timeouts in nss/gtests/ssl_gtest/tls_connect.cc
from 5000 ms to something like 20000. If a 0-day is discovered in "nss",
we don't want to wait several days to get a successful build.

signature.asc
Description: PGP signature