- to CFLAGS_NODIST to take precedence as CFLAGS_NODIST go after EXTRA_CFLAGS
- to EXTRA_CFLAGS to "bake it in" and build extension modules with -Og
- call make regen-all with the same flags, as it invokes gcc as well
Due to Python's handling of CFLAGS and the way we
were passing extra compiler flags through the SPEC
the -Og flag for the debug build was overridden by
the -O2 flag, resulting in various side effects.
See: https://bugs.python.org/issue37631
Resolves: rhbz#1678277
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).
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
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.
Since 2012, when the test was skipped from Python 3.3.0b1 (commit
3b4dd24c42), Linux now have a good
support for punching holes in filesystems.
Only 00160-disable-test_fs_holes-in-rpm-build.patch and
00163-disable-parts-of-test_socket-in-rpm-build.patch patches used
@unittest._skipInRpmBuild @unittest._expectedFailureInRpmBuild
decorators, but these 2 patches have been removed: remove
00132-add-rpmbuild-hooks-to-unittest.patch and
WITHIN_PYTHON_RPM_BUILD environment variable as well.
In diff order:
- gdbm releases in all Fedoras are long above 1:1.13
- the flat package should be called python3.7 but we are lazy to rename
- system-python is long gone, upgrade path works
- python3-enum34 is only required by 2 pkgs [0][1]
- glibc releases in all Fedoras are long above 2.24.90-26
Not removed:
- platform-python obsoletes shall be removed in Fedora 31, they were added in 28
[0] https://src.fedoraproject.org/rpms/python-qt5/pull-request/3
[1] https://src.fedoraproject.org/rpms/python-taskflow/pull-request/1
Such files are only used to create Microsoft Windows installers
and that functionality is broken on Linux anyway.
We can keep the exe files in SRPM, as they are free software as
confirmed by the Python Software Foundation:
> Hello,
>
> Shipping and distributing these files is ok.
>
> These files are stubs, used as the executable part of a self-unzipping
> executable and showing an "installer window" to the user.
> They are original to Python and, while they call win32 functions,
> they don't have Windows SDK code in them.
> The source is at: PC/bdist_wininst/install.c
>
> The binaries are included so that anyone creating a bdist_wininst
> distribution (mostly deprecated, actually) can do so, even when
> cross-compiling.
>
> Thanks,
> Van (Lindberg)
See also https://mail.python.org/pipermail/python-dev/2018-October/155507.html
Python 3 test suite requires various locales. Install all of them to
build the package to make sure that no test is skipped because of a
missing locale.
