On Mon, 18 Dec 2017 at 09:17:46 +0000, Simon McVittie wrote:
> [#884660] can also be seen in
> https://tests.reproducible-builds.org/debian/rbuild/buster/amd64/glib2.0_2.54.1-1.rbuild.log
gdbus-threading.c tests that GDBus is thread-safe. Three client threads
call into a server: thread 1 calls the Sleep() method 100 times with a 40ms
argument, thread 2 calls the Sleep() method 20 times with a 200ms argument,
and thread 3 calls it 100 times with a 40ms argument. The Sleep() method
just waits the indicated time and returns. The main thread waits for the
three client threads - they should all take 4000ms, plus D-Bus overhead,
minus up to 40ms because GLib timeouts with 1ms granularity can finish
slightly early - and asserts that the time elapsed was in the range
[3950, 8000) ms. In this case it took 8220ms.
The 8 second limit is essentially arbitrary: David Zeuthen increased it
from 5 to 6 seconds in 2010 because an 867MHz PowerPC took too long, and
Martin Pitt increased it from 6 to 8 seconds in 2012 because a PandaBoard
(~1 GHz ARM) was also taking too long. So we can increase the timeout as
far as is necessary, within reason.
However, I'm surprised that a 2017 x86_64 server is doing this test slower
than a 2003 PowerPC laptop or a 2010 low-cost ARM developer board. Are
the reproducible-builds machines building multiple unrelated packages in
parallel? If so, then I don't think it's necessarily all that unexpected
that timing-dependent automated tests will sometimes fail.
smcv
