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>
Macro which allows to pass the import check even if no Python modules
are detected in the package.
Only to be used in the automated environments.
Co-authored-by: Miro Hrončok <miro@hroncok.cz>
RPM 4.19 now requires 2 %s to escape a single literal % in the filelist.
The test has been adjusted to actually run our code
instead of only verifying the assumptions.
Related: rhbz#2208971
Dependencies are recorded to a text file that is catted at the end.
This should prevent subtle bugs like https://bugzilla.redhat.com/2183519 in the future.
Related: rhbz#2208971
An incomplete .dist-info directory in $PWD can confuse tests in %check.
For example, virtualenv uses importlib.metadata to load its
entry points and it does not work when it finds a virtualenv...dist-info without them.
Related: rhbz#2208971
pyproject-srpm-macros is intended to be installed in the default buildroot.
That way, no explicit BuildRequires for pyproject-rpm-macros are required,
as long as %pyproject_buildrequires is used in %generate_buildrequires.
When only pyproject-srpm-macros is installed, the minimal implementation of
%pyproject_buildrequires generates a dependency on pyproject-rpm-macros.
When pyproject-rpm-macros is installed, it overrides the implementation
of %pyproject_buildrequires with the full one.
Note that in Fedora, pyproject-rpm-macros is required by python3-devel,
but not in RHEL.
This allows us to keep pyproject-rpm-macros in the RHEL CRB repository.
Related: rhbz#2168193
That way, if a package (such as python-tox) uses it,
the patches in dist-git are available.
In the future, it also allows us to add patches without URLs to our tested spec files.
Related: rhbz#2168193
When certain modules are deliberately not included into the built RPM,
they shouldn't be listed in the list of qualified module names which are
used by %pyproject_check_import to test importability of the
distribution.
Related: rhbz#2168193
Files still need to be marked as License-File to be considered %license,
but if their path in METADATA is specified relative to dist-info/licenses,
they are correctly recognised.
This makes License-Files specified by hatchling 1.9.0+ marked as %license.
Related: rhbz#2168193
When extension modules are built in %pyproject_buildrequires,
we need to create the package note file.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2097535
This is tested via python-ldap -- %pyproject_buildrequires -w fails without the fix.
Neither python-markupsafe nor python-mistune can be used as a test
because they only warn when the extension module cannot be built
because they fallback to pure Python.
Related: rhbz#2117571
The hook is optional, see https://www.python.org/dev/peps/pep-0517/#prepare-metadata-for-build-wheel
> If a build frontend needs this information and the method is not defined,
> it should call build_wheel and look at the resulting metadata directly.
This is not yet automatically detected because the feature is provisional.
Use `%pyproject_buildrequires -w` to opt-in.
Resolves: rhbz#2060109
The ansible thing that installs packages does that one by one.
Hence, the assumption is that by installing epel-next-release first,
mock should be available next.
Resolves: rhbz#2065590
