Re: [PATCH v2] Re-enable riscv64-debian-cross-container (debian riscv64 is finally usable again!)

[Philippe Mathieu-Daudé]

On 3/5/24 10:07, Daniel P. Berrangé wrote:
> On Fri, May 03, 2024 at 10:16:34AM +0300, Michael Tokarev wrote:
> > Revert "gitlab-ci: Disable the riscv64-debian-cross-container by default"
> > This reverts commit f51f90c65ed7706c3c4f7a889ce3d6b7ab75ef6a.
> >
> > riscv64 in debian has been non-functioning for almost a year, after the
> > architecture has been promoted to release architecture and all binary
> > packages started to be re-built, making the port not multi-arch-co-installable
> > for a long time (in debian, multi-arch packages must be of the same version,
> > but when a package is rebuilt on one architecture it gets a version bump too).
> > Later on, debiah had a long time64_t transition which made sid unusable for

"debian" (even "Debian")

> > quite some time too.  Both such events happens in debian very rarely (like,
> > once in 10 years or so - for example, previous big transition like that was
> > libc5 => libc6 transition).  Now both of these are finished (where qemu is

("QEMU")

> > concerned anyway).
> >
> > Hopefully debian unstable wont be very unstable.  At the very least it is
> > better to have sporadic CI failures here than no riscv64 coverage at all.
>
> IME of running Debian sid in CI pipelines for libvirt, it is
> way too unstable to be used as a gating job. There are periods
> weeks-long when packages fail to install, even for relatively
> mainstream arch targets like x86, let alone a new target like
> riscv.
>
> Running the job by default is sane, but it should not be made
> gating until in a formal Debian release IMHO.

So it is waste of resources, and each time maintainers will look
for failure and notice "oh this is still this broken image" and
skip. Hard to see the gain of bringing that back TBH.