Summary: | test-fail-continue is ignored after distutils-r1 test phase - The ebuild phase 'test' with pid NNNNN appears to have left an orphan process running in the background. | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | mgorny, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
dev-python:mako-0.7.3-r2:20140211-193646.log (random example)
the remaining output from the emerge run |
Created attachment 370172 [details]
the remaining output from the emerge run
Interesting... I wonder if the test suite is leaving behind processes, or if it is actually one of the other jobs fired off by multiprocessing.eclass. Does the same thing happen if you run the test suite in single-process mode? (export DISTUTILS_NO_PARALLEL_BUILD=1) (In reply to Mike Gilbert from comment #2) > Interesting... I wonder if the test suite is leaving behind processes, or if > it is actually one of the other jobs fired off by multiprocessing.eclass. It's caused by one job calling die() while another is still running. > Does the same thing happen if you run the test suite in single-process mode? > (export DISTUTILS_NO_PARALLEL_BUILD=1) No, but apparently we cannot talk about bug #478378. It's sacred or something. (In reply to Jeroen Roovers from comment #3) > No, but apparently we cannot talk about bug #478378. It's sacred or > something. I think the gist of that bug is we don't want to disable parallel tests by default. I'm still open to adding a way for the end user to more easily toggle it. Parallel thingies are no longer used. |
Created attachment 370170 [details] dev-python:mako-0.7.3-r2:20140211-193646.log (random example) With the parallel test implementation currently in place, when one "impl" fails, src_test is abandoned. I can't tell whether the python-? eclass should wait properly or whether emerge is at fault. Note that in the attached build log, the extra output from emerge is missing (and to be attached shortly).