Python 3.11 is coming to RHEL 8 soon.
See https://bugzilla.redhat.com/show_bug.cgi?id=2137139
This *could* be shipped in EPEL 8 Next first,
but considering the change is harmless when python3.11-devel is not available
in the repos, it's easier to add it to EPEL 8 directly.
There is a slight difference compared to the older Pythons:
The package names now include the dot in the Python version (3.11 vs. 36, 38, 39).
That was a deliberate decision on the RHEL side
to make the package names equal to the RHEL 9 ones.
rpmautospec koji plugin bakes in the result of %autorelease and
%autochangelog into the SRPM. When used on a Fedora or EL 9 machine with
rpmautospec installed, fedpkg does the same. However, it's currently
impossible to rebuild specfiles that use rpmautospec on EL 8 itself due
to the unexpanded %autorelease and %autochangelog macros failing the
SRPM build.
This adds the same fallback %autorelease and %autochangelog macro
definitions that are available in the Fedora and EPEL 9 buildroots. This
allows locally rebuilding packages that use rpmautospec with plain
rpmbuild or fedpkg on an EL 8 system or with `mock --spec`.
Fedora java packages now make use of a java_arches macro to only build
on specific arches. Backport this to EPEL to allow those packages to be
built in EPEL without modification.
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
%__python_provides in RHEL's python3-rpm-generators does the same thing,
so this wastes time by running it twice. Additionally, our version is
out of date and packages built against alternative python stacks
incorrectly have python3dist(X) Provides.
Related: https://bugzilla.redhat.com/1776941
Related: d809defd2c?branch=c8s
python3-rpm-macros is already pulled in by python3X-devel
(indirectly through platform-python-devel by python36-devel and directly by the rest),
but we explictly Require it here, as it's needed by pythondist.attr.
The options were introduced to python-rpm-macros in Fedora.
Adding them to EPEL prevents failures when processing Fedora specfiles.
The actual functionality was not backported to EPEL.
When used, the options emit warning.
number of CPUs will never be set to less than 1
this now outputs build flag overrides to be used with %make_build etc.
add documentation
Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org>
With $PATH and $PYTHONPATH set to the %buildroot,
the macro tries to import the given Python 3 module(s).
Useful as a smoke test in %check when ruining tests is not feasible.
Accepts spaces or commas as separators.
Backport of https://src.fedoraproject.org/rpms/python-rpm-macros/c/c2305ea3
When building, rpm warns and removes the unnecessary exec perms:
*** WARNING: ./etc/rpm/macros.zzz-epel-override-cmake is executable
but has empty or no shebang, removing executable bit
Update the install command to avoid the warning.
Allow EPEL packages to use the simpler %gpgverify API which is available
in Fedora. This incorporates the changes made to redhat-rpm-config in
the following commits:
3490049 (Simplify the API of %gpgverify, 2019-07-25)
4d93255 (Fix the simple API of %gpgverify, 2019-11-01)
Previous implementation allowed for only one argument to be passed to
the %pycached macro, which made it impossible to combine it with other macros.
Current implementation allows to pass other macros as arguments to
%pycached.
Example:
%pycached %exclude /path/to/foo.py
For macro expansion limitations, the opposite order is not possible.
That is to be documented in the guidelines:
https://pagure.io/packaging-committee/pull-request/986
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1838992
Co-authored-by: Marcel Plch <mplch@redhat.com>
Usage:
%files
...
%pycached %{python3_sitelib}/foo.py
This will list:
/usr/lib/python3.8/site-packages/foo.py
/usr/lib/python3.8/site-packages/__pycache__/foo.cpython-38{,.opt-?}.pyc
Assuming the Python 3 version is 3.8.
The bytecode files are globbed, their presence is not checked.
This will fail:
%pycached %{python3_sitelib}/foo
error: %pycached can only be used with paths explicitly ending with .py
And so will any of this:
%pycached %{python3_sitelib}/*
%pycached %{python3_sitelib}/foo.*
%pycached %{python3_sitelib}/foo.p?
%pycached %{python3_sitelib}/foo.?y
%pycached %{python3_sitelib}/foo.??
But this will work:
%pycached %{python3_sitelib}/foo*.py
And it will generate the following globs:
/usr/lib/python3.8/site-packages/foo*.py
/usr/lib/python3.8/site-packages/__pycache__/foo*.cpython-38{,.opt-?}.pyc
When used with paths that include Python 3 version, it globs with the version:
%pycached /opt/python3.10/foo.py
Generates:
/opt/python3.10/foo.py
/opt/python3.10/__pycache__/foo.cpython-310{,.opt-?}.pyc
While paths without version have less strict globs:
%pycached /custom/foo.py
/custom/foo.py
/custom/__pycache__/foo.cpython-3*{,.opt-?}.pyc
This will generate a warning in RPM build:
warning: File listed twice: /custom/__pycache__/foo.cpython-38.opt-1.pyc
However it ensures the optimized bytecode is there.
Miro Hrončok
Maxwell G
Maxwell G
Jitka Plesnikova
Todd Zullinger
Iñaki Úcar
Pablo Greco
Karolina Surma
Tomas Orsava
Michel Alexandre Salim
Neal Gompa
Troy Dawson
Artur Iwicki