From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 01 03:34:47 2022 Received: (at 53214) by debbugs.gnu.org; 1 Feb 2022 08:34:47 +0000 Received: from localhost ([127.0.0.1]:41648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEocg-0004T0-Os for submit@debbugs.gnu.org; Tue, 01 Feb 2022 03:34:47 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:50930) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nEoce-0004Sj-Ay for 53214@debbugs.gnu.org; Tue, 01 Feb 2022 03:34:44 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id A53944A; Tue, 1 Feb 2022 09:34:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PTeysJ9FhHw; Tue, 1 Feb 2022 09:34:36 +0100 (CET) Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 9C0873F3; Tue, 1 Feb 2022 09:34:35 +0100 (CET) From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Leo Famulari Subject: Re: bug#53214: Release 1.4.0 progress References: <87sftsrhbe.fsf@inria.fr> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 13 =?utf-8?Q?Pluvi=C3=B4se?= an 230 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 01 Feb 2022 09:34:35 +0100 In-Reply-To: (Leo Famulari's message of "Sat, 29 Jan 2022 16:11:25 -0500") Message-ID: <87zgnb6l44.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / Authentication-Results: hera.aquilenet.fr; none X-Rspamd-Server: hera X-Rspamd-Queue-Id: A53944A X-Spamd-Result: default: False [0.53 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.63)[subject]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 53214 Cc: 53214@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi, Leo Famulari skribis: > The build farm is having trouble building Guix for i686-linux. In fact, > it hasn't successfully completed the 'guix' job in weeks: > > https://issues.guix.gnu.org/53463 (This issue title doesn=E2=80=99t mention i686.) I=E2=80=99m looking at it= , though a bit slowly because I=E2=80=99ve been busy with other things: https://issues.guix.gnu.org/53506 > And building the guix package does not work on aarch64, also for weeks: > > https://issues.guix.gnu.org/52943 Ah, I thought this had been fixed with Chris Marusich=E2=80=99s commits but apparently not? > Finally, should we consider retiring the armhf port in 1.4.0? It seems > that we have stopped trying to build for it: > > https://ci.guix.gnu.org/search?query=3Dguix+spec%3Amaster+system%3Aarmhf-= linux The =E2=80=9Carmhf-linux=E2=80=9D box was unchecked, not sure why. I=E2=80= =99ve re-added it and we=E2=80=99ll see. (For the record, anyone with access to berlin or with a certificate can do it via the Cuirass web interface.) Bordeaux.guix does have binaries: --8<---------------cut here---------------start------------->8--- $ guix weather -s armhf-linux coreutils guile grep sed computing 4 package derivations for armhf-linux... looking for 6 store items on https://ci.guix.gnu.org... https://ci.guix.gnu.org 0.0% substitutes available (0 out of 6) unknown substitute sizes 0.0 MiB on disk (uncompressed) 0.042 seconds per request (0.2 seconds in total) 23.6 requests per second 0.0% (0 out of 6) of the missing items are queued at least 1,000 queued builds aarch64-linux: 1000 (100.0%) build rate: 17.64 builds per hour i686-linux: 4.74 builds per hour x86_64-linux: 9.23 builds per hour powerpc64le-linux: 3.69 builds per hour looking for 6 store items on https://bordeaux.guix.gnu.org... https://bordeaux.guix.gnu.org 100.0% substitutes available (6 out of 6) 23.1 MiB of nars (compressed) 113.8 MiB on disk (uncompressed) 0.034 seconds per request (0.1 seconds in total) 29.3 requests per second (continuous integration information unavailable) --8<---------------cut here---------------end--------------->8--- Overall it=E2=80=99s not a great situation to be in, but I think we should = be able to address it. Usually I think it=E2=80=99s safer to merge =E2=80=98c= ore-updates=E2=80=99 only after =E2=80=9Cmake assert-binaries-available=E2=80=9D passes. Thanks, Ludo=E2=80=99.