[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: riscv64 buildds


On 2022-01-09 12:29, Simon McVittie wrote:
> Two questions about the riscv64 buildds:
> 1. Is riscv64 still using qemu for buildds, or is it exclusively using
>    real hardware now?

We got 2 new hardware buildds recently (rv-osuosl-01 and rv-osuosl-02),
and we switched the QEMU based buildds to only build packages when the
build queue is long (when a package sits there for more than 6 hours).
In practice it means that QEMU buildds were not used anymore.

However the old rv-mullvad-0* buildds started to have issues and now
QEMU buildds are sometimes used from time to time.

We plan to get new buildds, but hardware is difficult to get those

> I ask because several packages I'm involved with have workarounds for tests
> failing with a timeout on qemu, because some operations are much slower on
> qemu than real hardware. If I can disable those workarounds on riscv64, then
> genuine test failures will appear sooner if the test gets stuck as a result
> of a bug.
> Or, failing that, I'd prefer to have a way to detect "running under non-kvm
> emulation" and expand timeouts when that's true, instead of detecting
> riscv64 and assuming that means it might really be a slow emulation.

The QEMU based buildds are rv-aurel32-0* and rv-mit-*. Looking quickly
at a way to detect QEMU, it seems that QEMU based buildds lack the uarch
entry in /proc/cpuinfo.

> 2. Do (some) riscv64 buildds have a smaller /tmp than is typical for other
>    architectures?
> gtk4 4.6.0 in experimental is currently failing to build on rv-mullvad-02
> with "error writing to /tmp/ccjWWAIL.s: No space left on device", which
> suggests that it might need more /tmp. gtk4 is increasingly important for
> GNOME, so we'll probably want this version in unstable soon. I don't think
> it does anything unusual in /tmp, it's just a relatively large package.

/tmp is not on a different partition on the buildds, so it seems like a
general device space issue judging by the other build failures I have

Given the recent issues with rv-mullvad-*, I believe it's just old
schroot sessions that have not been correctly closed. Manuel, can you
please have a look?


Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Reply to: