On 01. 02. 21 10:53, Pavel Raiskup wrote:
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.
I don't think this has to do anything with the Copr build timeout thou.
What Daniel wants is to specify a timeout of an action during rpmbuild (such as
running the tests) via a multiplier/variable. Such multiplier/variable would be
carefully set by the chroot administrator to reflect the overall slowness of the
builders.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
