On Fri, 2021-01-29 at 15:28 +0000, Daniel P. Berrangé wrote:
On Fri, Jan 29, 2021 at 04:20:53PM +0100, Andrea Bolognani wrote:
> the timeout multiplier has been added to the upstream spec file,
> which the Fedora spec file is based on, so while you're correct that
> Fedora is not yet using it, it's fair to assume it will soon make its
> way there for the benefit of e.g. the virt-preview COPR.
I think this is the wrong solution. IMHO RPM should be making th
%meson_test macro include the timeout arg automatically when
running on a emulated environment. This would fix the problem for
all users of meson, without causing unecessarily long timeouts
for native builds.
How likely is it that some broken test will take longer than 30
seconds and less than 5 minutes to run on your average developer's
laptop? My experience suggests tests either take way less than half a
minute to complete, or go on spinning forever.
So yeah, in the unlikely event that your changes have introduced an
infinite wait in one of the tests, it will take you a couple more
minutes to realize that; however, considering how fast the test suite
is under meson you'd probably get suspicious way before actually
hitting the timeout, and introducing such an issue is hopefully not a
very frequent occurrence anyway.
Note that emulated environments are not the only ones hitting this:
native builds on slow architectures failing because of the timeout
are the reason why I introduced the timeout multiplier in Debian, for
example.
Finally, not everyone uses RPMs, and even those who do might not want
to use "rpmbuild" as a substitute for "meson test" - especially not
on the kind of hardware where the default test timeout is a problem!
Raising the timeout at the meson level makes it possible for people
to just run "meson test" and be reasonably confident it will only
fail if there's an actual bug in libvirt.
--
Andrea Bolognani / Red Hat / Virtualization