Re: Staging branch [substitute availability]

[Mathieu Othacehe <othacehe@gnu.org>]

Hello Tobias,

> I don't think it's obvious and I don't think it's true.

Well obvious was a poor choice of word. But I've been spending several
weeks/months monitoring Berlin and I think I'm starting to have a good
overview of the situation.

This new page[1] shows what the build machines are doing. There are two
workers per machine, and they are always busy as far as I can tell.

If you have a look to the "Pending builds" chart here[2], you will see
that it took 4 days to absorb the ~7000 builds that were added the 9/10th
of January.

Building chromium for aarch64 takes more than 24 hours and will take one
whole worker down for instance. Now think about Linux, webkitgtk and
imagine that we also want to build the core-updates branch and the armhf
architecture, I don't see how it could fit without lagging weeks behind.

> Only because we don't use the non-emulated hardware.  Our (currently 3, one
> crashed) Overdrives 1000 sit idle for ~90% of the time.

As I said, the new remote building Cuirass mechanism is not yet deployed
on those machines and I would need someone with login access to
reconfigure those machines for me.

> The situation is worse for x86_64: 96% idleness based on /proc/uptime.  Am I
> misinterpreting?

On what machine? If it's on the Berlin main node, it's by design. We
don't want the main machine to build things as it interferes too much
with the other stuff happening on that machine such as gc'ing a huge store,
hosting Cuirass and other services.

Thanks,

Mathieu

[1]: https://ci.guix.gnu.org/workers
[2]: https://ci.guix.gnu.org/metrics