On Fri, 2022-10-21 at 10:43 +0200, Ludovic Courtès wrote:
> Moin!
>
> Mathieu Othacehe <othac...@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!).
Vikings also offers hosting of POWER9 hardware.
>
> • 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’.
>
