From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id gJQPCZhoQ2YDDgEAqHPOHw:P1 (envelope-from ) for ; Tue, 14 May 2024 15:35:20 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id gJQPCZhoQ2YDDgEAqHPOHw (envelope-from ) for ; Tue, 14 May 2024 15:35:20 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1715693720; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post; bh=zUErR+ThadWwU9tiMN27/XpB41SOcu1dUwVhL8snDsw=; b=NLfF4MsXEa59ArIBbsQ8eS0ofui9+eFj9P0+l3B5wZznkEScm+KXux6dfZVA4PlzlyzqJx vDb6UTKcsw/QRs9jWZMC/4XVIapBqNi/xXh7hLzUkS22RKtSBCd0o0fVDFFg60eyi0npfF 40BYg6OyL+dew48Q8dpw5vEDcFnLLHAB8mKMBGlp7/uaJaTAUzM5yJHJeHmMtgIcRfT+Bo ZHSCT4tkvwQVbnZKk1OOvpIShEeT3aocPINb4iIUFSdAtJB58JpJED9kOMhglQkEhUnrqN izIZ/d8h3kRYmRvtMeoboOusllroNmC9ISCfgUNssoN6sss4bpDwCsctsQcTWw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1715693720; a=rsa-sha256; cv=none; b=WwzjyGX44nNHkFI/lNwNPf856ESXYHrlG5XE2nsbncaJmxedAtWiczejk2cB/61BcyBhP8 qoUs0j+RrOPyCRsN5Cs4g1GhKyFqnJWMYroD2vjjwEAWZ+orvgJ0/rZHMrXoNkO8x2kx4b RUpd3sUMHFcHeqbr/Vz5Pt35dgcnhPzoN0/Lof/ut001qZ+1OU+zeuLcSAi4pU6wV6ging oGpvPnLCEcZ6aK5ENmBLy4/8ksOPh6ZCVjaSJSFUZIOoMRvX7/DH6i4NKwJ/7l+QH1Nd7u eCeCCGYorTgmHj5PckmOFHge51T2NNldH1GWVSUXaojG2oUAMUYfc/xZjzuHOA== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 04C236BDAA for ; Tue, 14 May 2024 15:35:20 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s6sJ6-0000uy-KH; Tue, 14 May 2024 09:35:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s6sJ2-0000uC-Tp for bug-guix@gnu.org; Tue, 14 May 2024 09:35:00 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s6sJ2-0006fZ-Kw for bug-guix@gnu.org; Tue, 14 May 2024 09:35:00 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s6sJ3-0005G0-IS for bug-guix@gnu.org; Tue, 14 May 2024 09:35:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#70663: nss@3.99 is really hard to build Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 14 May 2024 13:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70663 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Maxim Cournoyer Cc: 70663@debbugs.gnu.org, Ian Eure Received: via spool by 70663-submit@debbugs.gnu.org id=B70663.171569367220189 (code B ref 70663); Tue, 14 May 2024 13:35:01 +0000 Received: (at 70663) by debbugs.gnu.org; 14 May 2024 13:34:32 +0000 Received: from localhost ([127.0.0.1]:39381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s6sIZ-0005FZ-GL for submit@debbugs.gnu.org; Tue, 14 May 2024 09:34:31 -0400 Received: from mira.cbaines.net ([212.71.252.8]:43510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s6sIW-0005FS-3l for 70663@debbugs.gnu.org; Tue, 14 May 2024 09:34:30 -0400 Received: from localhost (unknown [45.67.83.168]) by mira.cbaines.net (Postfix) with ESMTPSA id 4D96927BBE2; Tue, 14 May 2024 14:33:55 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id b8f713c5; Tue, 14 May 2024 13:33:53 +0000 (UTC) From: Christopher Baines In-Reply-To: <87le4czh0z.fsf@gmail.com> (Maxim Cournoyer's message of "Tue, 14 May 2024 08:58:52 -0400") References: <87plu7xla9.fsf@cbaines.net> <87o798zrtz.fsf@cbaines.net> <87le4czh0z.fsf@gmail.com> User-Agent: mu4e 1.12.2; emacs 29.3 Date: Tue, 14 May 2024 14:33:51 +0100 Message-ID: <87cypozfeo.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: bug-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -6.97 X-Migadu-Queue-Id: 04C236BDAA X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -6.97 X-TUID: ubkTvzo/ZE0Z --=-=-= Content-Type: text/plain Maxim Cournoyer writes: >> Before closing this bug, it would be good to understand more about how >> this happened and from that try to think if anything can be done to >> prevent similar issues in the future? >> >> At least from what I can see on the issues, the problem was introduced >> with the update to 3.98.0 [3] and then continued with the update to 3.99 >> [4]. Given the changes in 70662 were sent to guix-patches and then >> merged less than 24 hours later, I'd imagine that wasn't sufficient time >> for data.qa.guix.gnu.org to fail attempting to build nss. > > I think in [3] you meant https://issues.guix.gnu.org/70569, not #70662. Ah, yep. > Since this was security sensitive, I built it on x86_64, tested it there > to ensure that IceCat worked as expected, had others confirmed it worked > for them on #guix then pushed. > > In the past, I've had more patience waiting for QA to build things, but > since this is not guaranteed (it sometimes never happened), it seems > reasonable to me to promptly push security fixes that were manually > built & tested and adjust for any breakage later, if there is any. I think pushing security fixes quickly is good, but this does set a precedent on architecture support (only x86_64-linux matters). For some packages (including nss in this instance), not looking at non x86_64-linux support doesn't just affect users, the data service and ci.guix.gnu.org were particularly affected, so for some packages it's important to test across the "supported" systems just to ensure the projects own tooling doesn't break. >> 3: https://issues.guix.gnu.org/70662 >> 4: https://issues.guix.gnu.org/70618 >> >> Had the changes waited for longer, then these failures should have been >> spotted by QA, I would guess that the revision might have failed to be >> processed, and if it was processed successfully, the nss failures should >> have shown up, so maybe we should start requiring [5] that not only are >> changes sent to guix-patches@gnu.org, but that QA processes them (to >> some extent) before merging? > > I have some apprehensions about that; given the QA build farm is > somewhat under-resourced for builds, I fear security changes could be > gated for longer periods of time than is reasonable to wait. If we go > that route, I think we should dedicate more hardware first. I think that's reasonable, I have been putting time in to the hardware, but it's not been particularly easy going. The data service instances are also still stuck on hardware I'm renting as well. In terms of QA speed, there's the resources for data.qa.guix.gnu.org and there's the hardware available for the bordeaux build farm. There's also the potential to try and add more prioritisation. Currently the data service prioritises branch revisions over patches, and newer revisions more generally, but I guess it could prioritise security related things. I'm not sure how to make that happen yet though, QA can probably come up with the priorities, but I don't know how to convey that to the data service. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmZDaD9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XcTDA/+Pw/fN3P+zkMhqBtpLQssfpjGvQjp+ij3 cGbv2/n5uktDH4NQnqevPScAwt3zmPY34upkG5aIcgBpBDt9s7lYK67ZVAKsZFVZ oX5R7QbIwc/gH4rHFFtCFz7g0iGQlZrpBID7w0UtoJd8+MEoA64Jgs1PI26ZXdD2 wAHCEo7kehW/PBwvQeggjmhwJFexeeZj72qB4WQSYveQLmkMtsjkJtMiiC2xkwgS 0avBTsM7JXq9AnKTOhQfUiYwMPxC1xkij2GFCm/Bph9u02MJ6lsSwNQMapHjNeRK UzkZn1YpX6kWqdkEQ1KNIZhKPzBJpIemoE2jsjyfQlQA9QdK++hcWqx0JkEHJk1V d3rLHLvm9GiIDJOspFHvNuzRgr1yreoexL78hCogVhMNv83Vi5k9YrvJAC35tFZT AeLtrOFD4wtSC/zGtdbL1Ho7WyZfjzSqMog6EEkX0uYmfWm0t8UrVmWT6D1fktGi zi9YDGDffhLmX3OotuejFUym9RnVWXasAjW+LX5TxAd76GZVpKSTwhYbbnE/wrCu Re2ooKQj0MOY+FoKoX9z0lGS/LbnTGGfSamJsRfLJ3igz6W5zzOQ5HfIv4BuwINQ kYFLF+iMf3YTbnI0xJJJVm0mmFU3OvBBIclUlttPCSy/BQQHD7GKD0mJaxKt0lnx EDmhajU+qU4= =vAiA -----END PGP SIGNATURE----- --=-=-=--