Created attachment 305555 [details, diff] ebuild patch for supervisor-3.0_alpha12.ebuild gentoo64 supervisor # USE_PYTHON="2.5 2.6 2.7 2.7-pypy-1.8" emerge supervisor --jobs=1 >>> Installing (1 of 1) app-admin/supervisor-3.0_alpha12 * Compilation and optimization of Python modules for CPython 2.5 [ ok ] * Compilation and optimization of Python modules for CPython 2.6 [ ok ] * Compilation and optimization of Python modules for CPython 2.7 [ ok ] * Compilation and optimization of Python modules for PyPy 1.8 (Python 2.7) ... [ ok ] && gentoo64 supervisor # FEATURES=test USE_PYTHON="2.5 2.6 2.7" emerge supervisor --jobs=1 * Compilation and optimization of Python modules for CPython 2.5 [ ok ] * Compilation and optimization of Python modules for CPython 2.6 [ ok ] * Compilation and optimization of Python modules for CPython 2.7 [ ok ] Now for the hard part. To make the tests pass, I have made a sed statement sed -e s':2009-01-18 22:2009-01-18 23:' -i supervisor/tests/test_childutils.py. This requires an explanation I can't make. From timestamp = time.mktime((2009, 1, 18, 22, 14, 7, 0, 0, 0)) result = get_asctime(timestamp) self.assertEqual(result, '2009-01-18 22:14:07,000') The running of the test turns ((2009, 1, 18, 22, 14, 7, 0, 0, 0)) into ('2009-01-18 23:14:07,000') and it error out stating '2009-01-18 23:14:07,000' != '2009-01-18 22:14:07,000'. Having little notion of what import get_asctime entails, all I can decipher is that 22 turns into 23, which would be an error. For the sake of allowing the remainder of the test suite to run to completion, the sed statement invokes what appears to be an erroneous entry, making what should be wrong making a right. Therefore, I leave it in the patch but commented. Secondly, as the ebuild was initially, the tests are run from an installed system set of files, which breaks the purpose of the sandbox, and also makes it impossible to effect the sed statement. A simple entry of python_copy_sources in prepare() fixes that. To someone who can make sense of the above, consider: to me appears that the test, if it is valid, has proven fault with get_asctime and warrants passing upstream. The above mentioned in mind; good to go.
*** This bug has been marked as a duplicate of bug 401295 ***
