Your message dated Sun, 18 Oct 2015 12:38:40 +0200
with message-id <20151018103838.gk18...@raptor.chemicalconnection.dyndns.org>
and subject line Re: [Debichem-devel] Bug#802030: psi4 FTBFS on mips, testsuite
timeout
has caused the Debian Bug report #802030,
regarding psi4 FTBFS on mips, testsuite timeout
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
802030: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802030
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: psi4
Version: 1:0.3-1
Severity: serious
The last three uploads of your package (0.3-1, 0.3-2 and 0.3-3) have all
failed on mips with testsuite timeouts.
--- End Message ---
--- Begin Message ---
(Adding the mips list to CC)
On Sat, Oct 17, 2015 at 04:13:38AM +0100, peter green wrote:
> Package: psi4
> Version: 1:0.3-1
> Severity: serious
>
> The last three uploads of your package (0.3-1, 0.3-2 and 0.3-3) have
> all failed on mips with testsuite timeouts.
Right, the problem is apparently that all the mips autobuilders do not
have an FPU (ball and swarm maybe did, but they were decomissioned), so
running computation-heavy testsuites is cumbersome.
I don't think it's a problem with psi4 (so I am closing this bug for
now), if you look at the build log, one of the tests before the timeout
was a near miss:
|42/95 Test #101: dfmp2-1 .......................... Passed 19441.39 sec
| Start 105: dfmp2-grad1
|43/95 Test #105: dfmp2-grad1 ...................... Passed 579.99 sec
| Start 106: dfmp2-grad2
|44/95 Test #106: dfmp2-grad2 ......................***Failed 1224.16 sec
| Start 109: dfomp2-1
|45/95 Test #109: dfomp2-1 ......................... Passed 454.26 sec
| Start 110: dfomp2-2
|46/95 Test #110: dfomp2-2 .........................***Failed 954.27 sec
| Start 122: dft1
|make: *** wait: No child processes. Stop.
|make: *** Waiting for unfinished jobs....
|make: *** wait: No child processes. Stop.
|E: Caught signal ‘Terminated’: terminating immediately
|debian/rules:54: recipe for target 'override_dh_auto_test' failed
|make[1]: [override_dh_auto_test] Terminated (ignored)
|Build killed with signal TERM after 720 minutes of inactivity
19441 seconds are 324 minutes. For reference, those are the numbers on
mipsel:
|42/95 Test #101: dfmp2-1 .......................... Passed 239.63 sec
| Start 105: dfmp2-grad1
|43/95 Test #105: dfmp2-grad1 ...................... Passed 12.09 sec
| Start 106: dfmp2-grad2
|44/95 Test #106: dfmp2-grad2 ...................... Passed 15.59 sec
| Start 109: dfomp2-1
|45/95 Test #109: dfomp2-1 ......................... Passed 9.56 sec
| Start 110: dfomp2-2
|46/95 Test #110: dfomp2-2 ......................... Passed 18.00 sec
| Start 122: dft1
|47/95 Test #122: dft1 ............................. Passed 1169.88 sec
So mips seems to be around 80x slower than mipsel and the timeout would
need to be around 1700 minutes rather 720 minutes for it to have a
chance to build that.
So I see three alternatives:
1. Reschedule on a different, presumably more powerful, buildd, if one
exists (I don't think so?)
2. Crank up the testsuite timeout to 2000 minutes or so
3. Add it to not-for-us on mips, or otherwise blacklist it, and remove
the .deb (which built by accident on lucatelli when the testsuite was
not exercised)
Mips porters/buildd maintainers, what is your preference?
Michael
--- End Message ---
