From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Bakke Subject: Re: 02/05: gnu: nss, nss-certs: Update to 3.29.3. Date: Tue, 14 Mar 2017 22:39:48 +0100 Message-ID: <874lyv4jx7.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> References: <20170313174039.25881.89989@vcs0.savannah.gnu.org> <20170313174040.C5C6B20CAB@vcs0.savannah.gnu.org> <878to8qssk.fsf@netris.org> <87innc43ub.fsf@kirby.i-did-not-set--mail-host-address--so-tickle-me> <871stzh8rv.fsf@netris.org> <20170314212701.GA8440@jasmine> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35507) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnuAd-00054y-4J for guix-devel@gnu.org; Tue, 14 Mar 2017 17:39:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cnuAZ-0005kY-5U for guix-devel@gnu.org; Tue, 14 Mar 2017 17:39:55 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:57805) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cnuAY-0005iP-Pa for guix-devel@gnu.org; Tue, 14 Mar 2017 17:39:51 -0400 In-Reply-To: <20170314212701.GA8440@jasmine> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Leo Famulari , Mark H Weaver Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Leo Famulari 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). >>=20 >> 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAljIYyQACgkQoqBt8qM6 VPoefgf/VHI3Awf8pjU1eRZDUhEaQ/stvZAsrHnOZHZ2dz8bdDaM2AevqqBzjmv6 5TOz+Jk2gcuXxMYtjnL3lizl+x7Wk74xcw9s535R30FenTMGWt2Tre/FOGwXCKQQ J+mnjnCun6gbsATi01co4Jv8QixwFjCyLL0euhPADFgiceHzI5eRxkTm5p7abhw4 cxij78ntIHgH2ImtIAiabfHip0Gf2/C7io0P9K7LQmWRHNZOm/nfNVK3CP8nDNEm BglGoCYjuT7h09Su3xDyi7agC5vkHncXqXnJ34D5XawFfhx1MMXI5MwmgVkhhCZO 2MtjEHztjSFJVwjQSknME+cwkJocCw== =2KPw -----END PGP SIGNATURE----- --=-=-=--