random tests failing on s390x

[Ingvar Hagelund]

My two cents: 

On Fedora, official builds are done on central servers. If you don't have special hardware available (s390x, aarch64, ppc64, etc), you may also send "scratch" (test) builds to these as well. On s390x I disable some of the most troublesometime sensitive tests. In addition, I run the test suite in series, ie without any -j parameter to make to not stress the system. But as Red Hat's s390x park is limited, some builds fail just because the builders are busy. And yes, this also means all builds, including just a simple test takes quite some time to finish. So to check if a specific test goes through while debugging some problem, I do a scratch build that runs that single test instead of the whole make check. 

Ingvar 

----- On 8 Jul, 2026, at 07:37, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote: 

> --------
> Marco d'Itri writes:

> > Is this caused by the s390x build daemons being overloaded?

> That's my conclusion.

> We also have a s390x instance in our own "vtest":

> https://vinyl-cache.org/vtest/

> and it shows similar random lossage, even though we run that
> platform with VTEST_DURATION=180

> That said, some of our test-cases are more sensitive to timing than
> others, and we try to improve that where we can, and I recoginize
> the cases you mention as being on my personal "trouble-list".

> We have discussed if some tests should be "advisory", in the sense
> that a failure is just a "warning" not an "error", but that feels
> too much like giving up :-)

> > Is this something that can be worked around, either upstream or in the
> > Debian package, or should I disable the test suite on s390x?

> I would disable tests on s390x.

> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> vinyl-dev mailing list
> vinyl-dev at vinyl-cache.org
> https://vinyl-cache.org/lists/mailman/listinfo/vinyl-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260805/bb0312dd/attachment.html>