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