On Sun, Jan 31, 2021 at 03:35:14PM +0100, Pavel Raiskup wrote:
On Friday, January 29, 2021 4:26:18 PM CET Daniel P. Berrangé wrote:
> When we attempt to build libvirt in Copr, the test suite times out on
> s390 builds.
>
> IIUC, this is because s390 in Copr is using a QEMU emulated system,
> not native hardware, and thus is massively slower to execute.
>
> We don't want to bump up the default test suite timeout unconditonally,
> as that makes it slower to diagnose problems for the common case
> where the build env is not emulated.
>
> Is there a good way to detect that the build is in an emulated copr
> env rather than native. Does Copr / mock set any env variable to
> show that you're emulated ?
No explicit environment variable I think. It would be a question on
qemu-user-static maintainers probably.
You can check `uname -r` vs. `uname -i`? Or something like that.
> I'm thinking this is not really a libvirt specific problem - any app
> using Meson is liable to hit the default test suite time limit if
> running in an emulated chroot, and thus will need to set
> --timeout-multiplier=10.
> So perhaps RPM's %meson_test macro should automatically include
> --timeout-multiplier=10 when running in an emulated world ?
I thought you mean the Copr limit (copr build --timeout) but this is
probably in-testsuite timetout.
Yeah, I mean making %meson_test expand to
meson test --timeout-multiplier=10
I don't know, perhaps we could have some configurable coefficient
for
timeout _in Copr_ for emulated architectures? If that was say "3", and
the --timeout was 3600s, emulated arches would get 10800s instead?
Yeah, if Copr set some coefficient, that could be used directly as the
meson multiplier.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|