Hi Simon, On 2023-08-28 11:07, Simon McVittie wrote: > On Sun, 27 Aug 2023 at 21:18:38 +0200, Aurelien Jarno wrote: > > test(t, test_bin, > > suite: suite_name, > > env: test_env, > > + timeout: 100, > > ) > > It's probably worth mentioning before you file too many bugs similar to > this one that Meson has a feature that's really useful in this situation:
I do not expect a lot similar bugs, as riscv64 was built before on debian-ports, it's mostly for the packages which evolved since they got built on debian-ports. That said, the fact that the development is reopened after the Bookworm release and the lack of experimental on the debian archive increase the chances to have such cases. > if debian/rules passes an argument like `--timeout-multiplier 5` to > `meson test`, then all test(timeout:) arguments are multiplied by 5. > > Choosing an appropriate --timeout-multiplier is often enough to make > tests pass on slower buildds without having to patch any upstream source, > which reduces the time spent on rebasing patches later. Thanks a lot for the explanation. That's indeed way better. I therefore came with the following patch instead: --- clutter-1.0-1.26.4+git2779b932+dfsg/debian/rules +++ clutter-1.0-1.26.4+git2779b932+dfsg/debian/rules @@ -56,7 +56,7 @@ ifneq (,$(filter armel s390x,$(DEB_HOST_ARCH))) # Ignore test failures on architectures where they fail else ifneq (,$(filter hppa hurd-i386 kfreebsd-i386 kfreebsd-amd64 mips mipsel mips64el powerpc ppc64 sparc64,$(DEB_HOST_ARCH))) - -dbus-run-session -- xvfb-run -a dh_auto_test + -dbus-run-session -- xvfb-run -a dh_auto_test -- --timeout-multiplier 3 else - dbus-run-session -- xvfb-run -a dh_auto_test + dbus-run-session -- xvfb-run -a dh_auto_test -- --timeout-multiplier 3 endif I didn't try to use a different multiplier depending on the architecture as it has no impact on working tests anyway. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
