Bug 1532287
Summary: | uwsgi isn't aware of /usr/local on Fedora 27 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Victor Stinner <vstinner> |
Component: | python3 | Assignee: | Michal Cyprian <mcyprian> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 27 | CC: | bkabrda, cstratak, dmalcolm, ishcherb, lzachar, mcyprian, mhroncok, pviktori, rkuska, tomspur, torsava, vstinner |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | python3-3.6.4-8.fc27 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-02-20 17:14:28 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Victor Stinner
2018-01-08 15:17:17 UTC
I understood that the intent of the Fedora change is to not load Python code from /usr/local when using system/platform python. Why using a whitelist approach? Why not doing the opposite, use a blacklist: don't add /usr/local if the binary is the system/platform python? Workaround patch: --- /usr/lib64/python3.6/site.py 2018-01-08 16:18:43.206511043 +0100 +++ /usr/lib64/python3.6/site.py 2018-01-08 16:19:10.374476306 +0100 @@ -332,7 +332,7 @@ and RPM build is not detected to make sudo pip installed packages visible. """ - if (ENABLE_USER_SITE and sys.executable.startswith("/usr/bin/python") + if (ENABLE_USER_SITE and sys.executable.startswith(("/usr/bin/python", "/usr/local/bin/uwsgi")) and 'RPM_BUILD_ROOT' not in os.environ): PREFIXES.insert(0, "/usr/local") for sitedir in getsitepackages(prefixes): The blacklist might make sense. Tomáš, you're probably most up to date now, what do you think? FYI it's not currently possible to run DevStack on Fedora 27, there are at least two other issues: * https://bugs.launchpad.net/devstack/+bug/1741901 * https://bugs.launchpad.net/devstack/+bug/1740194 FYI I don't think there's a need for black/white list anymore. There's no more system python, or platform python either (there is actually platform python in Fedora 27, removed in Fedora 28, but nothing uses is). There is a FTBFS due to https://fedoraproject.org/wiki/Changes/SunRPCRemovalhttps://bugs.python.org/issue32521 https://bugs.python.org/issue32007 So we cannot fix this right away. (In reply to Miro Hrončok from comment #5) > https://fedoraproject.org/wiki/Changes/SunRPCRemovalhttps://bugs.python.org/ > issue32521 https://fedoraproject.org/wiki/Changes/SunRPCRemoval https://bugs.python.org/issue32521 I've created a new patch that does not use the whitelist and solely depends on detecting the rpm build environment. I'm currently doing testing (F27 scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=24098598). It's your then ;) There is a problem with the patch that removes the whitelist. While it fixes the reported issue, it causes venv to break down, and after some investigation I believe that's exactly why the whitelist was put there in the first place. I've created a different patch that broadens the whitelist to any executables in /usr/bin/ and /usr/local/bin, but it's not an ideal solution. I've asked mcyprian to look into it as he's the original author of the change. "... I believe that's exactly why the whitelist was put there in the first place. I've created a different patch that broadens the whitelist to any executables in /usr/bin/ and /usr/local/bin, but it's not an ideal solution." Can't we special case site when running in a virtual environment instead? See venv() function of Lib/site.py. That's right. It seemed to be elegant solution to exclude virtual environments and isolate system/platform python at the same time. As far as platform python won't work as planned, it might be sufficient for now to simply exclude venvs. I am working on the patch. My approach isn't working, the virtualenvs are still broken. Can you please describe your latest idea of patching site.py in more details Victor? Actually simple detection of virtual environments might work, I had a mistake in condition before. I wrote this patch [0] and here [1] is a copr with python3 containing the new patch. Can you please check whether this really resolves the issue? [0] https://github.com/mcyprian/python3/blob/sudo-pip-patch/00251-change-user-install-location.patch [1] https://copr.fedorainfracloud.org/coprs/mcyprian/sudo-pip-change-patch/builds/ python3-3.6.4-8.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-37591178fc python3-3.6.4-8.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-37591178fc python37-3.7.0-0.9.b1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c743211a24 python37-3.7.0-0.9.b1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c743211a24 python3-3.6.4-8.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. python37-3.7.0-0.9.b1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. Sorry, I couldn't test the fix, but it seems like a fix was released anyway: thanks! I will test it. |