This is a tracking bug for Change: Move /usr/bin/python into a separate package For more details, see: https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package Reflecting the recent changes of https://www.python.org/dev/peps/pep-0394/ PEP 394 -- ''The "python" Command on Unix-Like Systems'', we are moving /usr/bin/python from the {{package|python2}} package into a separate package called {{package|python-unversioned-command}}. {{package|python2}} will recommend this package. This means Fedora users will get it automatically with {{package|python2}}, but they might opt-out and remove it. In Fedora's build system, only packages explicitly buildrequiring /usr/bin/python will get it. This change obsoletes "Avoid /usr/bin/python in RPM build" change.
Setting to depends on PYTHON37. "This change will be done after the switch to Python 3.7 to avoid work on one change from interfering with work on the other."
Prepared in https://src.fedoraproject.org/rpms/python2/pull-request/20
Build in progress https://koji.fedoraproject.org/koji/taskinfo?taskID=28001290
218 packages list one of the following in %files: %{python_sitearch}/* %{python_sitelib}/* Unfortunately, both statements currently evaluate to /*. I think we should mass patch those, as this is a kind of error that passes silently. Thoughts?
Are they actually defined to empty, or are they just undefined? I always thought any undefined macros are not replaced, leading to a non-absolute path, and consequently an error from rpm…
+1 to mass patching, though, as usual ;)
They are basically defined to undefined: (I know this is bash, but it behaves similarly here) $ value=$(nonexisting command is here) bash: nonexisting: command not found $ echo "$value" (empty)
Also, plenty of those use python or %__python and will fail to build. So I'd only patch 42 that don't: abiword afflib cwiid denyhosts did dtc gitosis gr-air-modes gr-fcdproplus gr-iqbal gr-osmosdr gtts langtable libdasm libpfm mathgl player pocketsphinx pyserial python-alsaaudio python-ansi python-anyconfig python-atomicwrites python-bottle python-guppy python-lyricwiki python-nitrate python-openoffice python-optcomplete python-ordered-set python-pygraphviz python-pylcdsysinfo python-pymilter python-repoze-tm2 python-trml2pdf12 python-vkontakte python-xmpp python-yenc stgit sugar-datastore sugar-toolkit wordxtr
(In reply to Miro Hrončok from comment #7) > They are basically defined to undefined: /usr/lib/rpm/macros:%python_sitelib %(%{__python} -Es %{_rpmconfigdir}/python-macro-helper sitelib) /usr/lib/rpm/macros:%python_sitearch %(%{__python} -Es %{_rpmconfigdir}/python-macro-helper sitearch) That's ugly. I think we should update those definitions to something like this: %python_sitelib %{__python} -Es %{_rpmconfigdir}/python-macro-helper sitelib 2>/dev/null || echo %%python_sitelib %python_sitearch %{__python} -Es %{_rpmconfigdir}/python-macro-helper sitearch 2>/dev/null || echo %%python_sitearch
That would work.
https://github.com/rpm-software-management/rpm/pull/469
FTBFS of python-jnius: <snip> BUILD SUCCESSFUL Total time: 0 seconds python setup.py build_ext --inplace -f -g make: python: Command not found The above output is a result of calling: CFLAGS="$RPM_OPT_FLAGS" %py2_build https://koji.fedoraproject.org/koji/taskinfo?taskID=28222392 https://github.com/kivy/pyjnius/blob/a7e791aa26c84645c53dac985dd97183071f7bc4/setup.py
Raphael, the above output is a result of calling "make": https://github.com/kivy/pyjnius/blob/master/Makefile#L20 If you really need to call make, set PYTHON=%{__python2}. Also note that you don't need to set CFLAGS with %py2_build, the macro does that for you. Note that I see no reason to call "%py_build" and follow it with "make" that calls python setup.py build_ext, as they both do essentially the same thing.
Raphael, here is a PR https://src.fedoraproject.org/rpms/python-jnius/pull-request/1
(In reply to Zbigniew Jędrzejewski-Szmek from comment #11) > https://github.com/rpm-software-management/rpm/pull/469 https://src.fedoraproject.org/rpms/rpm/pull-request/14
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This has happened in F29.