| Summary: | dev-python/pip-20.1: test failures (test_entrypoints_work[entrypoint0,1,2]) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sam James <sam> |
| Component: | Current packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | mgorny |
| Priority: | Normal | Keywords: | TESTFAILURE |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log (test phase) | ||
|
Description
Sam James
2020-05-13 03:11:37 UTC
I've run pip's test suite a dozen times in these last days, and can't reproduce. Maybe I can help. The reason these tests fail is that the shebang of the generated test file is too long (current limit 127). The test in question (test_entrypoints_work) creates a stub project inside a temp directory and creates a stub executable which contains a shebang "#!/path/to/python. The stub project is encapsulated in a virtual env, thus the /path/to/python is something like /var/tmp/portage/..../temp/.../virtualenv/bin/python. For the default value PORTAGE_TMPDIR, namely /var/tmp/portage, that generated shepang line is 129 characters long, 2 over the limit of 127 (see man execve(2)). This means that the last chars are simply droped and the system tries to execute something like "/var/.../bin/pyth" which obviously does not exists, thus the OS Error. I guess Sam is using the default path "/var/tmp/portage" and Michał something like "/tmp". The workaround for this is to set PORTAGE_TMPDIR to something short, like "/t". If you want to reproduce this you can do mkdir /very/long/path/ ln -s /usr/bin/python /very/long/path/ echo "#!/very/long/path/python" > /tmp/test.py /tmp/test.py Some references: https://github.com/pypa/pip/issues/1773 https://github.com/pypa/virtualenv/issues/596 https://lwn.net/Articles/779997/ Ideas/workarounds I can think of (in random order): * If 'test' is enabled, abort merge (and print a workaround suggestions) if the base path is detected to be longer than 128-chars-needed-by characters. Note that the path contains the version number of pip, i.e. pip-20.10 takes a lot more. * Same as above but instead of aborting print a warning + workaround suggestions. * Modify the build process, such that the generated directory structure is not so deeply nested and/or uses shorter names. * Use something like https://github.com/shlevy/long-shebang or the snippets suggested in the pip issue to circumvent the long shebang line. (probably needs patching of the test sources) * Do use /usr/bin/python instead of the virtualenv python interpreter in the tests. (probably needs modifying of the test sources) The proper solution would be to enlarge the 128 character array of the kernel to handle longer paths, which occur more and more often as time and technology advances. Closing bugs reported for old versions, no longer in ::gentoo. Please reopen if you can still reproduce. |