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
