Hi, some of my packages (e.g. nwchem, but others as well) have floating-point heavy testsuites becuse they are scientific computing applications.
The current state on mips (but not mipsel) is that the testsuite routinely takes too long on some autobuilders, so that sbuild kills it after a testcase has not finished in the configured timeout (up to 5 hours). I had another look today, and it seems this is due to most of the mips autobuilders not having an FPU. The same testcase (cosmo_h3co): mips (mips-aql-01): 524.3u 4873.9s 1:30:56.17 98.9% (0t+0ds+0avg+31986max)k 0i+0o 0pf 0swaps mips (ball): 76.5u 1.9s 1:18.45 100.0% (0t+0ds+0avg+27876max)k 0i+286136o 0pf 0swaps armel (hartmann): 395.8u 1.7s 6:37.76 99.9% (0t+0ds+0avg+31418max)k 0i+291224o 0pf 0swaps i386 (brahms): 10.9u 0.5s 0:11.43 100.0% (0t+0ds+0avg+27026max)k 0i+285672o 0pf 0swaps As you can see, the system is below 2 seconds for all buildds, except for mips-aql-01, where it is almost 5000 seconds. Obviously, this is due to floating point emulation in the kernel. So far, I have been requesting a give-back each time it FTBFS on a mips autobuilder and hoped that it might hit ball next time, but this is not a sustainable approach in my opinion. So I think there are some things to consider here: 1. Is it OK for an autobuilder not to have an FPU? 2. Is it OK for an architecture to only have autobuilders without FPUs? 3. If 1 but not 2 are OK, should there be a way for packages to say "I should really be built on a buildd without softfloat"? One proposal might be to add something like "XS-Buildd-Flags: hardfloat" to debian/control for packages, which ship a floating-point heavy testsuite as a first step. This could possibly be extended for other buildd machine-specific features (though I am not sure off-hand which would benefit). Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141201132211.gh1...@raptor.chemicalconnection.dyndns.org
