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
Pablo Greco
Karolina Surma
Tomas Orsava
Michel Alexandre Salim
Neal Gompa
Todd Zullinger
Troy Dawson
Artur Iwicki
Kevin Fenzi
Orion Poplawski
Stephen Smoogen
Mohan Boddu
Fedora Release Engineering