2018-05-03 19:09 GMT+02:00 Simon McVittie <s...@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.montez...@gmail.com>