[Pkg-utopia-maintainers] Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64

[Manuel A. Fernandez Montecelo]

2018-05-03 19:09 GMT+02:00 Simon McVittie <smcv at debian.org>:
> Control: tags -1 + moreinfo
>
> On Thu, 03 May 2018 at 16:30:19 +0200, Manuel A. Fernandez Montecelo wrote:
>> This package fails to build for the riscv64 architecture, because these two test
>> cases don't pass:
>>
>>   https://buildd.debian.org/status/fetch.php?pkg=dbus&arch=riscv64&ver=1.12.8-2&stamp=1525355576&raw=0
>>
>>   ERROR: test-monitor - Bail out! Test timed out (GLib main loop timeout callback reached)
>>   ERROR: test-relay - Bail out! Test timed out (SIGALRM received)
>
> As you conjectured, those arbitrary timeouts are meant to be there to stop
> the tests from waiting forever if there's a deadlock or infinite loop bug.
>
>> So there are high chances that it's only that, slow "hardware".
>
> Looking at the results of other tests, it's taking between 40 and 100
> times as long as my laptop for some tests that succeeded; so yes, very
> slow "hardware".

FWIW I built it in the real hardware board, it built successfully and it took:
  00:28:49


> I'm a little reluctant to just add zeroes to the timeout until it succeeds;
> building and testing dbus takes 10 minutes on x86 and 40 minutes on mips,
> and I suspect you don't want it to take 16 hours (10 minutes * 100x
> worst-case factor) to run the build and the tests on riscv64 :-)

Many packages take days, e.g. Python or the several versions of GCC
uploaded at least once per week, and same for some packages like Qt or
math/science software, so we're used to wait :)

But yeah, I get the point.


> Please could you try the build on a representative
> riscv64 emulator with the attached hack, and send
> the resulting debian/build-main/test/test-monitor.log and
> debian/build-main/test/test-relay.log to this bug? If it fails, increase
> the numbers as desired (they're an arbitrary number of minutes per
> test-case), but either way I'd like to see the logs so that I can tell
> how much margin of error we get.

Thanks for the quick feedback, I'll try overnight.


> Alternatively, do you have a pre-prepared riscv64 qemu image that I could
> try, or some other way to get the equivalent of a porterbox? How fast
> is your slowest host machine for this qemu-system-riscv64 - hopefully
> at least as fast as my laptop?

We don't have porterboxes yet, hopefully we'll set up something within
the month, at least qemu images as you suggested :)


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>