On Sun, 21 Jul 2019 at 15:49:38 -0400, Michael Gilbert wrote:
> On i386, the gmenumodel test timed out.
I can't reproduce this locally, and it normally takes about 6-7 seconds
on an i386 VM on my laptop. It has had issues with arbitrary delays in
the past, and got moved to the "slow" test suite because it was sometimes
taking more than 60s in upstream's CI, so I'm quite prepared to believe
that there is some intermittent problem.
The failing test-case seems to be /gmenu/dbus/peer/subscriptions, which
has a watchdog timer that is meant to kill the process with SIGALRM
after 65 seconds, so I'm surprised it survived to 360s - either the
watchdog timer isn't working, or multiple test-cases must have taken a
lot longer than they are meant to.
If I can't reproduce this well enough to debug it, the best I'll be able
to do is to disable this particular test at build-time.
> On mips, the gvariant test timed out.
This is failing a fuzz-test that randomly modifies binary data and
tries to parse it. I thought it might be reaching some pathological
case where the parser breaks, but no - it looks like the actual problem
is that g_random_double_range() is really slow on at least some mips
hardware (repeatedly calling g_random_double_range() in a loop is 100
times as fast on my laptop as on the porterbox minkus, which according
to db.debian.org is the same EdgeRouter Pro hardware as mips-aql-01,
the buildd where this test timed out).
mips porters: Is this something that is expected to be so slow? The
same test took 60 seconds (so at least 6 times as fast) on mips-sil-01,
which is apparently a Rhino Labs UTM8 with a somewhat newer CPU.
For comparison, it took 8 seconds on the i386 buildd.
There probably isn't much point in trying very hard to run this test on
mips, so I'll disable this one as a build-time test too.
smcv
