This is a tracking bug for Change: Make ambiguous python shebangs error For more details, see: https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot policy script will be changed to make the build fail when it sees an ambiguous python shebang, such as #!/usr/bin/python or #!/usr/bin/env python. (The script has been warning in these cases for 2 Fedora releases already, saying This will become an ERROR.)
Upstream PR: https://github.com/fedora-python/brp-mangle-shebangs/pull/1
Note to self from https://pagure.io/fesco/issue/1979#comment-530129 I'll work with Taskotron people to get the list of packages where this [the Taskotron check for ambiguous python shebang] failed for the latest rawhide build and I will send an e-mail to the maintainers.
(In reply to Miro Hrončok from comment #2) > Note to self from https://pagure.io/fesco/issue/1979#comment-530129 > > I'll work with Taskotron people to get the list of packages where this [the > Taskotron check for ambiguous python shebang] failed for the latest rawhide > build and I will send an e-mail to the maintainers. https://lists.fedoraproject.org/archives/list/python-devel%40lists.fedoraproject.org/message/TYCAE254X7TQZAYONW2TRQ53QLA5WSIT/
Please update the wiki page to specify that if a package using this tool is python2, it must BR python2-devel in order to use the macros as specified. Many packages with shebangs needing fixing don't otherwise need to BR python2-devel.
Added: Note: The examples bellow use some python macros (%{__pythonX} and %{pyX_shbang_opts}). BuildRequire python3-devel (and/or python2-devel) to get those.
Fedora PR: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/39
Thank you!
Built in rawhide. Ambiguous python shebang will error from now on. https://koji.fedoraproject.org/koji/taskinfo?taskID=29749600 The fact is documented in https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes
How is this *possibly* a self-contained change? Isn't it more or less the exact *opposite* of a self-contained change, given that its entire impact is on the building of other packages?
This is how: 1. there was a warning already for 2 releases 2. the fix is trivial 3. FESCo approved it as a self contained change as long as I e-mail the maintainers of affected packages 4. the impact is on limited set of packages only I guess this might have been a system wide change, but it would not change anything about how this was executed. Also it was implemented early, so there was plenty of time. Note that if this blocks you anyhow, I'm always happy to help. How would this be any better as a system wide change?
"How would this be any better as a system wide change?" It would make us more likely to notice it as something that could potentially affect the distro overall when reviewing the Change list, as the list is split into system-wide (at the top) and self-contained (at the bottom). Though I tend not to trust the distinction any more so I do wind up looking at all of them anyway. :)
Note to self: Consult QA on future self-contained change proposals about system wide potential.
to be clear - I'm not actually too worried about this Change at all, as you say, the error is clear and it is always going to be an easy fix. It just seemed like an obvious category error when I was browsing the list.