On Thu, 17 Nov 2022 at 22:18:04 +0800, Bo YU wrote: > > On Wed, 2022-11-16 at 12:23 +0800, Bo YU wrote: > > > The package has a ftbfs issue on riscv64 due to timeout from tests.
I'd prefer to resolve this by extending the timeout, which is relatively straightforward in Meson, or by reducing the number of repeats. You don't need to send an updated patch, I'll deal with this. > > I guess this happens on every architecture, presumably the problem is > > the slow build hardware, not the riscv64 hardware? > > It seems that it's currently only failing on riscv64 The problem is just that an arbitrary timeout in the upstream build system is too short for slower machines. The same test takes about 5 seconds on armel, 18 seconds on alpha, 29 to 30 seconds on riscv64 and 12 to 30 seconds on mips64el, and the arbitrary timeout is 30 seconds, so riscv64 was just unlucky. mips64el also timed out after 30 seconds in https://buildd.debian.org/status/fetch.php?pkg=dbus-python&arch=mips64el&ver=1.3.2-2&stamp=1668379900&raw=0 but then succeeded in 12 seconds when it was retried in https://buildd.debian.org/status/fetch.php?pkg=dbus-python&arch=mips64el&ver=1.3.2-2&stamp=1668382124&raw=0 (maybe mipsel-osuosl-04 is faster than mipsel-aql-01). > For riscv64, I suspect that the package uses dbus-daemon instead of dbus > to cause the timeout on 1.3.2-2. Before the version, it build > successfully on riscv64. The source change in 1.3.2-2 is just coincidence. It's using the same dbus-run-session(1) and dbus-daemon(1) executables to run its test either way, and 1.3.2-1+b1 had the same failure on riscv64. 1.3.2-1 and 1.3.0-1 took about 29 seconds on riscv64, so they succeeded but were very close to also failing. > > Looking at the bug that this test prevents, it seems that just changing > > the loop from 100 to 2 would be enough. I'd prefer to keep enough repetitions to avoid boundary conditions, but something like 10 would probably be sufficient. > > Another option might be to have the test provide a progress indicator > > to the test supervisor, so that as long as the imports are succeeding, > > the test is able to continue. That's not how Meson tests work: it would time out after an arbitrary length of time, however much output the test produced. We just need to make the arbitrary length of time long enough for the test to pass on any reasonable machine, or make the number of repetitions shorter so that the test finishes sooner. > Ok, Will wait for the maintainer's advices for days and then forward > this to upstream maybe. There is no need to contact the upstream, the upstream is also me. smcv
