Message ID | 3b94b876a23ffdf93df962a161b98b8fa82581ab.1611266145.git.crobinso@redhat.com |
---|---|
State | Accepted |
Commit | 70307548d1622bfeffd60c86e62098d165c95074 |
Headers | show |
Series | spec: Increase meson test timeout 10x | expand |
On Thu, 2021-01-21 at 16:55 -0500, Cole Robinson wrote: > %check > -VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check > +# Building on slow archs, like emulated s390x in Fedora copr, requires > +# raising the test timeout > +VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check --timeout-multiplier 10 Debian has been doing the same thing for a while, even though in that case it's to cope with slow native hardware rather than emulation: https://salsa.debian.org/libvirt-team/libvirt/-/blob/debian/6.9.0-3/debian/rules#L170-179 So Reviewed-by: Andrea Bolognani <abologna@redhat.com> from my side, but please leave the message on the list for a few days to give other people the opportunity to voice any concerns they might have. -- Andrea Bolognani / Red Hat / Virtualization
On 1/22/21 2:46 AM, Andrea Bolognani wrote: > On Thu, 2021-01-21 at 16:55 -0500, Cole Robinson wrote: >> %check >> -VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check >> +# Building on slow archs, like emulated s390x in Fedora copr, requires >> +# raising the test timeout >> +VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check --timeout-multiplier 10 > > Debian has been doing the same thing for a while, even though in that > case it's to cope with slow native hardware rather than emulation: > > https://salsa.debian.org/libvirt-team/libvirt/-/blob/debian/6.9.0-3/debian/rules#L170-179 FYI, I also use the timeout multiplier in the SUSE libvirt package to avoid test failures in OBS, particularly for non-x86 architectures. A value of 5 has worked fine thus far. Regards, Jim
On Thu, Jan 21, 2021 at 4:59 PM Cole Robinson <crobinso@redhat.com> wrote: > > Tests time out when building in slow environments, like emulated > s390x in Fedora copr. Bump up the test timeout > > Signed-off-by: Cole Robinson <crobinso@redhat.com> > --- > libvirt.spec.in | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libvirt.spec.in b/libvirt.spec.in > index 0a8b0ebad4..1731aa8bd9 100644 > --- a/libvirt.spec.in > +++ b/libvirt.spec.in > @@ -1288,7 +1288,9 @@ mv $RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_qemu_probes.stp \ > %endif > > %check > -VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check > +# Building on slow archs, like emulated s390x in Fedora copr, requires > +# raising the test timeout > +VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check --timeout-multiplier 10 > > %post libs > %if 0%{?rhel} == 7 > -- > 2.29.2 > I have to do this for slow hardware too, so I'm fine with it. Reviewed-by: Neal Gompa <ngompa13@gmail.com> -- 真実はいつも一つ!/ Always, there's only one truth!
On 1/21/21 10:55 PM, Cole Robinson wrote: > Tests time out when building in slow environments, like emulated > s390x in Fedora copr. Bump up the test timeout > > Signed-off-by: Cole Robinson <crobinso@redhat.com> > --- > libvirt.spec.in | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libvirt.spec.in b/libvirt.spec.in > index 0a8b0ebad4..1731aa8bd9 100644 > --- a/libvirt.spec.in > +++ b/libvirt.spec.in > @@ -1288,7 +1288,9 @@ mv $RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_qemu_probes.stp \ > %endif > > %check > -VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check > +# Building on slow archs, like emulated s390x in Fedora copr, requires > +# raising the test timeout > +VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check --timeout-multiplier 10 > > %post libs > %if 0%{?rhel} == 7 > Looks like we have consensus here. In the past, we've increased the timeout for qemuxml2argvtest: https://gitlab.com/libvirt/libvirt/-/commit/94146c9d2ba Would it make sense finally admit that not everybody is running top shelf CPU and increase the timeout even for 'ninja test'? I mean, set timeout to a bigger value in tests/meson.build and drop special casing of one test? Michal
On 1/25/21 5:54 AM, Michal Privoznik wrote: > On 1/21/21 10:55 PM, Cole Robinson wrote: >> Tests time out when building in slow environments, like emulated >> s390x in Fedora copr. Bump up the test timeout >> >> Signed-off-by: Cole Robinson <crobinso@redhat.com> >> --- >> libvirt.spec.in | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/libvirt.spec.in b/libvirt.spec.in >> index 0a8b0ebad4..1731aa8bd9 100644 >> --- a/libvirt.spec.in >> +++ b/libvirt.spec.in >> @@ -1288,7 +1288,9 @@ mv >> $RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_qemu_probes.stp \ >> %endif >> %check >> -VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check >> +# Building on slow archs, like emulated s390x in Fedora copr, requires >> +# raising the test timeout >> +VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check >> --timeout-multiplier 10 >> %post libs >> %if 0%{?rhel} == 7 >> > > Looks like we have consensus here. In the past, we've increased the > timeout for qemuxml2argvtest: > > https://gitlab.com/libvirt/libvirt/-/commit/94146c9d2ba > > Would it make sense finally admit that not everybody is running top > shelf CPU and increase the timeout even for 'ninja test'? I mean, set > timeout to a bigger value in tests/meson.build and drop special casing > of one test? > +1 from me. In my case the slow test was virschematest - Cole
diff --git a/libvirt.spec.in b/libvirt.spec.in index 0a8b0ebad4..1731aa8bd9 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1288,7 +1288,9 @@ mv $RPM_BUILD_ROOT%{_datadir}/systemtap/tapset/libvirt_qemu_probes.stp \ %endif %check -VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check +# Building on slow archs, like emulated s390x in Fedora copr, requires +# raising the test timeout +VIR_TEST_DEBUG=1 %meson_test --no-suite syntax-check --timeout-multiplier 10 %post libs %if 0%{?rhel} == 7
Tests time out when building in slow environments, like emulated s390x in Fedora copr. Bump up the test timeout Signed-off-by: Cole Robinson <crobinso@redhat.com> --- libvirt.spec.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.29.2