This leads to problems (notably on slower systems) because: 1) test suites may do tests requiring many parallel processes/threads, so the tests can run out of resources 2) individual tests may be time limited, causing time-outs because individual time-critical tasks cannot finish in an otherwise timely manner It looks like this is due to the way python_test is run, if defined, namely that it is treated like any other phase, so that the test suites are run concurrently for different implementations. My current workaround in testing python packages is to set MAKEOPTS=-j1, with the undesired but expected side effect of increasing build time significantly.
We already have a DISTUTILS_NO_PARALLEL_BUILD variable that you can set. I guess we could add a special case for testing like DISTUTILS_NO_PARALLEL_TEST.
src_test() { local DISTUTILS_NO_PARALLEL_BUILD=1 distutils-r1_src_test }
(In reply to Michał Górny from comment #2) > src_test() { > local DISTUTILS_NO_PARALLEL_BUILD=1 > > distutils-r1_src_test > } And then find out and correct that for individual ebuilds? Shouldn't we rather do this in the eclass itself? Index: distutils-r1.eclass =================================================================== RCS file: /var/cvsroot/gentoo-x86/eclass/distutils-r1.eclass,v retrieving revision 1.73 diff -u -B -r1.73 distutils-r1.eclass --- distutils-r1.eclass 21 Jul 2013 19:00:56 -0000 1.73 +++ distutils-r1.eclass 27 Jul 2013 17:57:50 -0000 @@ -626,6 +626,7 @@ debug-print-function ${FUNCNAME} "${@}" if declare -f python_test >/dev/null; then + local DISTUTILS_NO_PARALLEL_BUILD=1 _distutils-r1_run_foreach_impl python_test fi
Back to old portage EAPIs doing 'make -j1' just to make sure?
My intent in proposing DISTUTILS_NO_PARALLEL_TEST is that it could be set in make.conf for individual users. Disabling parallel testing globally at the eclass level is a regression, as mgorny indicates.
How is that a regression? Do you expect or need 5 test suites to run in parallel and always succeed?
(In reply to Jeroen Roovers from comment #6) > How is that a regression? Do you expect or need 5 test suites to run in > parallel and always succeed? Yes. If they don't, then they're ... what was the word Diego was using?
(In reply to Michał Górny from comment #7) > (In reply to Jeroen Roovers from comment #6) > > How is that a regression? Do you expect or need 5 test suites to run in > > parallel and always succeed? > > Yes. If they don't, then they're ... what was the word Diego was using? Could you be more specific? I see lots of tests fail due to optimistic time-outs even without having resource intensive stuff running in the background already, regardless of the bandwidth of the system in question. Perhaps these are bugs in the test suites, but then again stress testing a system is rarely the purpose of an application specific test suite, so we shouldn't perhaps be out to fix upstream's expectations.
(In reply to Jeroen Roovers from comment #8) > (In reply to Michał Górny from comment #7) > > (In reply to Jeroen Roovers from comment #6) > > > How is that a regression? Do you expect or need 5 test suites to run in > > > parallel and always succeed? > > > > Yes. If they don't, then they're ... what was the word Diego was using? > > Could you be more specific? I see lots of tests fail due to optimistic > time-outs even without having resource intensive stuff running in the > background already, regardless of the bandwidth of the system in question. > > Perhaps these are bugs in the test suites, but then again stress testing a > system is rarely the purpose of an application specific test suite, so we > shouldn't perhaps be out to fix upstream's expectations. I found the quote: | And non-deterministic tests are stupid, useless, broken tests. And this is exactly the case. Tests which rely on optimistic timeouts fail randomly due to system load. Those tests are basically broken by design and they will fail sometime. Randomly. To decrease the amount of failures, the package in question can disable parallel testing. But there's no real point in disabling parallel testing for *all* packages just because some of them are broken by design.
We have generic way of making phases non-parallel, and you can use portage's pre/post-phase hooks to do that per-phase as well. Since the bug hasn't seem any more activity since the last comments, closing as WONTFIX.
