unofficial mirror of 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <>
To: Leo Famulari <>
Subject: bug#53214: Release 1.4.0 progress
Date: Tue, 01 Feb 2022 09:34:35 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YfWtfbOcLXrPBhRe@jasmine.lan> (Leo Famulari's message of "Sat, 29 Jan 2022 16:11:25 -0500")


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:

(This issue title doesn’t mention i686.)  I’m looking at it, though a
bit slowly because I’ve been busy with other things:

> And building the guix package does not work on aarch64, also for weeks:

Ah, I thought this had been fixed with Chris Marusich’s 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:

The “armhf-linux” box was unchecked, not sure why.  I’ve re-added it and
we’ll 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
  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
  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’s not a great situation to be in, but I think we should be
able to address it.  Usually I think it’s safer to merge ‘core-updates’
only after “make assert-binaries-available” passes.


  parent reply	other threads:[~2022-02-01  9:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-12 17:32 Ludovic Courtès
2022-01-26  4:20 ` Leo Famulari
2022-01-29 21:11   ` Leo Famulari
2022-01-30  0:22     ` Vagrant Cascadian
2022-01-30  1:00       ` Thiago Jung Bauermann via Bug reports for GNU Guix
2022-02-01  8:34     ` Ludovic Courtès [this message]
2022-02-03 17:46 ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: bug#53214: Release 1.4.0 progress' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).