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
- lua-srpm-macros and python-srpm-macros already pulled in by redhat-rpm-macros
- python2-rpm-macros - not in RHEL9
- python-rpm-macros and python3-rpm-macros pulled n by python-devel/python3-devel
- fpc-srpm-macros - buildroot only, set to recommends for now
Signed-off-by: Troy Dawson <tdawson@redhat.com>
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
Mattias Ellert
Artur Frenszek-Iwicki
Maxwell G
Jitka Plesnikova
Carl George
Miro Hrončok
Troy Dawson
Michel Alexandre Salim
Neal Gompa
Todd Zullinger
Kevin Fenzi