Re: riscv64 buildds
Hi,
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
days...
> 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
found.
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?
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: