On Monday, February 1, 2021 10:32:04 AM CET Daniel P. Berrangé wrote: > 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. We don't even expose the pre-configured timeout down to rpmbuild ATM. So for the rpmbuild process (or even mock) it is just an unpredictable async interrupt signal. So indeed, it looks like a good idea to start passing the info down (e.g. as RPM macros) so scripts like meson can adapt to the given timeout. Pavel _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
