https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884660

test_method_calls_in_thread() in 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. However, in one case observed on Debian "reproducible builds" infrastructure, 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.

(I was surprised to see an x86-64 still in use in 2017 suffering worse performance than a 2003 PowerPC laptop or a 2010 low-cost embedded developer board, so I have asked whether the "reproducible builds" worker machines are doing other things at the same time or are otherwise particularly slow, but I haven't had any response so far.)