fre 2016-07-22 klockan 11:09 +0200 skrev John Paul Adrian Glaubitz: > Hello Mattias! > > On 07/22/2016 10:56 AM, Mattias Ellert wrote: > > > > https://buildd.debian.org/status/logs.php?pkg=globus-ftp-client&arc > > h=m68k > > > > There is nothing broken with the builds, except that they are a bit > > slow. > > > > The logs say "Build killed with signal TERM after 30 minutes of > > inactivity" during the 4th test in the test suite. > > > > Killing after 30 minutes is a bit aggressive I think, especially on > > a > > slow architecture like m68k. > > Not really. The 30 minutes limit is configured for the qemu-based > m68k > buildds, those are quite fast. > > > > > The build is not really inactive at this point, just busy running > > tests > > and not printing anything to stdout. As long as the tests succeeds > > the > > test suite only writes one line saying PASSED once each test > > completes, > > so for long running tests there can be more than 30 minutes between > > the > > lines of output. > > Do these tests perform any sort of complex multithreading (e.g. using > futexes or using openmp)? If yes, then qemu-m68k is actually locking > up during these tests. > > > > > If I build the package in the aranym emulator the build succeeds - > > after a while. The complete test suite (21 tests) took 28 hours to > > run > > in the emulator, the longest running test took 6 hour 33 min. > > Hopefully > > the official build machines are faster than running the emulator > > inside > > on a VM. > > Please test with qemu-m68k, Aranym behaves much different than qemu- > m68k, > see: https://wiki.debian.org/M68k/sbuildQEMU > > > > > For the other architectures the build usually completes within two > > and > > a half hours, unless it hits a slow build machine. > > > > Can you lift the 30 min inactivity limit for this package? > > Unless I have verified that the timeout is just a timeout because the > buildd > is slow and not because qemu-m68k is locking up because of > multithreading > issues, I'm not going to raise the timeout. > > Adrian Hi again. The instructions were clear. The qemu-m68k was faster than aranym, both running on the same host system. Instead of 28 hours the tests completed in four and a half hours. jul 22 19:27 gridmap 00:05 jul 22 19:32 dir-test.pl.trs 00:05 jul 22 19:37 create-destroy-test.pl.trs 00:04 jul 22 19:41 exist-test.pl.trs 00:52 jul 22 20:33 extended-get-test.pl.trs 00:09 jul 22 20:42 extended-put-test.pl.trs 00:57 jul 22 21:39 extended-transfer-test.pl.trs 00:05 jul 22 21:44 lingering-get-test.pl.trs 00:08 jul 22 21:52 multiple-block-get-test.pl.trs 00:08 jul 22 22:00 partial-get-test.pl.trs 00:04 jul 22 22:04 partial-put-test.pl.trs 00:05 jul 22 22:09 partial-transfer-test.pl.trs 00:05 jul 22 22:14 plugin-test.pl.trs 00:05 jul 22 22:19 get-test.pl.trs 00:08 jul 22 22:27 caching-get-test.pl.trs 00:05 jul 22 22:32 size-test.pl.trs 00:09 jul 22 22:41 transfer-test.pl.trs 00:11 jul 22 22:52 caching-transfer-test.pl.trs 00:52 jul 22 23:44 caching-extended-get-test.pl.trs 00:05 jul 22 23:49 user-auth-test.pl.trs 00:09 jul 22 23:58 put-test.pl.trs 00:05 jul 23 00:03 bad-buffer-test.pl.trs The qemu-m68k is approx 6 times faster than the aranym, but three of the tests still take almost 1 hour to complete, which is more than the 30 minute limit. How the speed of this computer compares to the official buildds I don't know. Mattias
Attachment:
signature.asc
Description: This is a digitally signed message part