In case of flatpak module builds, _prefix is redefined as /app.
rpm-build however hardcodes /usr/lib/debug without using the _prefix
macro, so do the same here to match this.
This fixes building Python as a flatpak module.
https://bugzilla.redhat.com/show_bug.cgi?id=1737933#c14
This increases the build time (to ~2 hours on armv7hl Koji),
but should bring more optimized Python to architectures other than x86.
The build time overhead is not so big on Python 3.8,
as only a limited number of tests is used.
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1741015
Installing python3-devel currently brings in:
- annobin
- dwz
- efi-srpm-macros
- fpc-srpm-macros
- ghc-srpm-macros
- gnat-srpm-macros
- go-srpm-macros
- nim-srpm-macros
- ocaml-srpm-macros
- openblas-srpm-macros
- perl-srpm-macros
- python-rpm-macros
- python-srpm-macros
- python3-rpm-generators
- python3-rpm-macros
- qt5-srpm-macros
- redhat-rpm-config
- rust-srpm-macros
For somebody who needs python3-devel to build extension modules,
those are all useless, so we conditionalize it on rpm-build.
Based on the reason for setuptools dependency, we do the same here
(but note that python3 already recommends it).
Installing python3-devel currently brings in:
- annobin
- dwz
- efi-srpm-macros
- fpc-srpm-macros
- ghc-srpm-macros
- gnat-srpm-macros
- go-srpm-macros
- nim-srpm-macros
- ocaml-srpm-macros
- openblas-srpm-macros
- perl-srpm-macros
- python-rpm-macros
- python-srpm-macros
- python3-rpm-generators
- python3-rpm-macros
- qt5-srpm-macros
- redhat-rpm-config
- rust-srpm-macros
For somebody who needs python3-devel to build extension modules,
those are all useless, so we conditionalize it on rpm-build.
Based on the reason for setuptools dependency, we do the same here
(but note that python3 already recommends it).
The license() builtin tries to read it and virtualenv tries to copy it.
See https://github.com/pypa/virtualenv/issues/1352
Up until now, the license() builtin juts felt back to:
See https://www.python.org/psf/license/
However it should output the full license text.
Virtualenv ~16.6 warns:
No LICENSE.txt / LICENSE found in source
Technically, it is probably possible to install the package without
%license files, but that would simply resort to the previous noncritical
behavior.
This fix is not critical and hence it doesn't bump release, for easier
backporting to all our Python packages.
The license() builtin tries to read it and virtualenv tries to copy it.
See https://github.com/pypa/virtualenv/issues/1352
Up until now, the license() builtin juts felt back to:
See https://www.python.org/psf/license/
However it should output the full license text.
Virtualenv ~16.6 warns:
No LICENSE.txt / LICENSE found in source
Technically, it is probably possible to install the package without
%license files, but that would simply resort to the previous noncritical
behavior.
This fix is not critical and hence it doesn't bump release, for easier
backporting to all our Python packages.
- https://fedoraproject.org/wiki/Changes/Python_means_Python3
- The python-unversioned-command package is no longer Python 2, but 3
- The python, pydoc, python-config, python-debug, idle, pygettext.py and
msgfmt.py commands are now in python3
- https://fedoraproject.org/wiki/Changes/Python_means_Python3
- The python-unversioned-command package is no longer Python 2, but 3
- The python, pydoc, python-config, python-debug, idle, pygettext.py and
msgfmt.py commands are now in python3
This allows easier compatibility back and forth once (and if)
https://fedoraproject.org/wiki/Changes/Python_means_Python3
happens. This is not the full implementation of the change,
as the python-unversioned package still needs to be added.
This is currently a no-op as %python_provide does nothing
for python3.
This allows easier compatibility back and forth once (and if)
https://fedoraproject.org/wiki/Changes/Python_means_Python3
happens. This is not the full implementation of the change,
as the python-unversioned package still needs to be added.
This is currently a no-op as %python_provide does nothing
for python3.
The patch landed in Python in be5bb52f5f2d4da4b9d6f42399f7275ab47910f3
However patch 316 still applied cleanly.
Removing it doesn't make any difference, so not bumping anything.
Since Python 3.8.0a4, extension modules are no longer linked against
libpython3.8.so.1.0. As a result, some of them are not linked against
anything at all.
And that is fine. They are not used as standard shared libraries.
