unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Status of armhf-linux and powerpc64le-linux
Date: Fri, 21 Oct 2022 10:43:33 +0200	[thread overview]
Message-ID: <87h6zx8t3e.fsf_-_@gnu.org> (raw)
In-Reply-To: <87h6zyo811.fsf@gnu.org> (Mathieu Othacehe's message of "Thu, 20 Oct 2022 16:59:38 +0200")

Moin!

Mathieu Othacehe <othacehe@gnu.org> skribis:

>>      - armhf-linux is disabled on ci.guix due to improper offloading
>>        setup (probably along the lines of
>>        <https://issues.guix.gnu.org/53463>).  Should we try and reenable
>>        it, or should we drop it?
>>
>>      - powerpc64le-linux is disabled on ci.guix since today
>>        (maintenance.git commit
>>        d641115e20973731555b586985fa81fbe293aeca).  However it did work
>>        until recently and we have one machine to offload to.  Should we
>>        fix it or drop it?  Mathieu?
>
> Yeah, we only have a single machine to offload to and each time it is
> not reachable, the "guix" specification fails on Cuirass.

How frequently does that machine become unreachable?

Its uptime right now is “only” 51 days, but it seems to have been
reliably building things so far (surprisingly so!).

> That's because we need to offload to a powerpc64le-linux machine in
> order to evaluate the guix derivation for that specific architecture
> (that's true for all the other architectures).

Maybe we should arrange to be more resilient to transient build machine
outage.

For that we need redundancy; we have it for ARM, but not for POWER9.  A
simple way to get redundancy today would be to set up transparent
emulation for POWER9 on one of the x86_64 boxes.  That’ll be
inefficient, but that’ll let Cuirass survive transient failures of that
one POWER9 box.

WDYT?

Longer-term, people interested in POWER9 should look into:

  • Purchasing, setting up, and hosting POWER9 hardware (funds held at
    the FSF are probably sufficient for that!).

  • And/or: getting in touch with companies who could sponsor us by
    providing hardware (the AArch64 port was started thanks to a
    donation by ARM).

In Cuirass, we should arrange to support partial evaluations or
per-system evaluations so that a single missing offload machine doesn’t
cause the whole evaluation to fail.

> Given the lack of workers for powerpc64le-linux I think we should drop
> it.

We can do that, but I find embarrassing to drop the architecture after
all the work people have put it “just” because of infrastructure issues.

> Regarding armhf-linux we can in theory rely on the overdrives but we
> are already struggling on aarch64-linux, we I think we should also
> drop it for now.

In theory, ci.guix has at least 3 Honeycombs (2 are currently offline)
and 2 Overdrives, so it’s not that bad, and they don’t seem to be all
that busy.

So you’re right in a way, but at the same time this seems to be an
infrastructure issue.

> Focusing on x86_64-linux, i686-linux and aarch64-linux for this release
> seems more pragmatic.

That’s radical, but maybe that’s the most reasonable option.

How about a plan like this: until next Thursday, we try to address the
infrastructure issues discussed above to estimate feasibility.  Then we
decide on the way forward.  WDYT?

If we end up dropping architectures, we’ll have to:

  1. Update the documentation (and eventually the web site).

  2. Offer a clear plan as to what it would take to reinstate those
     architectures, and probably define clear criteria for architecture
     support going forward.

Thanks,
Ludo’.


  parent reply	other threads:[~2022-10-21  8:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 14:50 Planning for a release, for real Ludovic Courtès
2022-10-06 16:02 ` Julien Lepiller
2022-10-07  9:49   ` Ludovic Courtès
2022-10-07 10:14     ` Julien Lepiller
2022-10-06 16:07 ` Maxime Devos
2022-10-07  9:50   ` Ludovic Courtès
2022-10-07  9:53     ` Maxime Devos
2022-10-07  6:20 ` Supported architectures Efraim Flashner
2022-10-07 10:02   ` Ludovic Courtès
2022-10-10  7:57   ` Csepp
2022-10-12 20:40   ` Vagrant Cascadian
2022-10-13 15:06     ` Ludovic Courtès
2022-10-07  8:26 ` Planning for a release, for real Christopher Baines
2022-10-07 10:09   ` Ludovic Courtès
2022-10-10 10:33 ` zimoun
2022-10-13 15:19 ` Release progress, week 1 Ludovic Courtès
2022-10-13 15:33   ` Efraim Flashner
2022-10-13 15:42   ` Christopher Baines
2022-10-20 13:49   ` Release progress, week 2 Ludovic Courtès
2022-10-20 20:07     ` Efraim Flashner
2022-10-21  8:51       ` Rust on aarch64-linux Ludovic Courtès
2022-10-21 13:42         ` Efraim Flashner
2022-10-22 20:22         ` Efraim Flashner
2022-10-26  9:01           ` Efraim Flashner
     [not found]     ` <87h6zyo811.fsf@gnu.org>
2022-10-21  8:43       ` Ludovic Courtès [this message]
2022-10-21  9:30         ` Status of armhf-linux and powerpc64le-linux Mathieu Othacehe
2022-10-31 17:40         ` Tobias Platen
2022-10-22 12:18     ` Release progress, week 2 Christopher Baines
2022-10-25  9:50     ` Release progress, week 2, release manifest, what builds are failing? Christopher Baines
2022-10-25 11:29       ` Release progress, week 2, release manifest, what builds are failing: gst-plugins-bad Christopher Baines

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87h6zx8t3e.fsf_-_@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=othacehe@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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).