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.
Maxwell G
Iñaki Úcar
Miro Hrončok
Pablo Greco
Karolina Surma
Tomas Orsava
Michel Alexandre Salim
Neal Gompa
Todd Zullinger
Artur Iwicki
Troy Dawson
Kevin Fenzi
Orion Poplawski
Stephen Smoogen