This way, when we add new options to the actual macro in pyproject-rpm-macros,
spec files that use them are parsable with the old pyproject-srpm-macros package.
Last time, when we added the -g option in 1.16.0,
it took at least a week for Fedora CI to be able to parse a spec file with it,
as pyproject-srpm-macros 1.16.0+ needed to actually be installed on the CI systems.
Next time this happens, the new option will be parsable with older versions of pyproject-rpm-macros
Note that the (-) syntax is not supported yet on RPM 4.16 in RHEL 9.
I'd use an expression to keep the literal set of flags for older RPM versions:
%pyproject_buildrequires(%[v"0%{?rpmversion}" >= v"4.19" ? "-" : "rRxtNwpe:g:C:"])
But macro options are not processed as macros:
https://github.com/rpm-software-management/rpm/issues/3440
As a result, this is not compatible with RHEL 9 and cannot be backported to it.
Unless the (-) syntax is backported:
https://issues.redhat.com/browse/RHEL-67161https://gitlab.com/redhat/centos-stream/rpms/rpm/-/merge_requests/60
(cherry picked from Fedora commit c1de18f683)
Amended for RHEL 9 to require rpm-build >= 4.16.1.3-37 for the (-) syntax backport.
Change the test source location to support evolving downstream testing
requirements. This is needed both for downstream certification
activities and changes to test development for internal infrastructure
differences.
This test was previously skipped because we didn't have new enough tox.
That's why it was never fixed for setuptools 70+.
This is a fixup for 20b7ac63f3
(cherry picked from commit 1532f1893f)
- wheel is no longer generated as a dependency of the default build system
- test cases are adapted to support both old and new setuptools version
(cherry picked from commit 20b7ac63f3)
Keep the information about the requirement extras by storing the
Requirement instances in the list of the ignored requirements, rather
than the strings in the form they were initially read from metadata.
The requirements strings read from pyproject.toml don't contain the
extra information, we insert the extra marker only after converting them to
Requirement instances. When stored as the text, the information about
the extra went missing in the course of the script.
(cherry picked from commit bc6cb55227)
This adds a new flag, -p, to %pyproject_buildrequires.
When set, the runtime dependencies are read from the pyproject.toml's
[project] table.
See: https://bugzilla.redhat.com/2261939
pyproject_buildrequires.py already had a short `-p` option for
--python3_pkgversion (hidden from the macro users).
This change removes the one-letter option and leaves the long-one.
`-p` is now reused for reading dependencies from pyproject.toml
and made visible to the macro users.
(cherry picked from commit 9f43e2a760)
It is not available in EPEL 10 and we can avoid it by excluding more imports,
which is what this spec file tests anyway.
(cherry picked from commit 459cda2e67)
mock-core-configs-39.3 switched the package manager for Fedora 40 to dnf5
https://fedoraproject.org/wiki/Changes/BuildWithDNF5
dnf5 builddep cannot handle BuildRequires with square brackets,
e.g. with Python extras, leading to errors like:
No match for argument: python3dist(setuptools-scm[toml]) >= 5
No match for argument: python3dist(raven[flask])
No match for argument: python3dist(ini2toml[lite]) >= 0.9
This is reported: https://github.com/rpm-software-management/dnf5/issues/1084
Until it is fixed, we explicitly use the "dnf" (i.e. DNF 4) package manager in mock,
even on Fedora 40+.
- The -l flag can be used to assert at least 1 License-File was detected
- The -L flag explicitly disables this check (which remains the default)
Co-Authored-By: Maxwell G <maxwell@gtmx.me>
