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>
I have seen several folks building this package in a RHEL 8 environment.
This won't prevent them doing so, but at least they will be forced to make changes,
acknowledging the fact that what they are doing has consequences.
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
python3-devel is not installed, hence the conditional needs to be on python3.
It only "worked" with toml because toml was pulled as a transitive dependency.
Related: rhbz#2208971
This makes the tests work on EL 9 and Fedora 36.
- Move metadata to setup.cfg in self-referential extras tests
- Skip tests for pyproject.toml [project] metadata when setuptools < 60
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
When the build backend prints to stdout via non-Python means,
for example when a setup.py script calls a verbose program via os.system(),
the output leaked to stdout of %pyproject_buildrequires was treated as generated BuildRequires.
Fore example, if the setup.py script has:
rv = os.system('/usr/bin/patch -N -p3 -d build/lib < lib/py-lmdb/env-copy-txn.patch')
(From https://github.com/jnwatson/py-lmdb/blob/py-lmdb_1.0.0/setup.py#L117)
The stdout of /usr/bin/patch leaked to stdout of %pyproject_buildrequires:
[lmdb-1.0.0]$ /usr/bin/python3 -Bs /usr/lib/rpm/redhat/pyproject_buildrequires.py --python3_pkgversion 3 2>/dev/null
python3dist(setuptools) >= 40.8
python3dist(wheel)
patching file lmdb.h
patching file mdb.c
python3dist(wheel)
patching file lmdb.h
patching file mdb.c
This resulted in DNF errors like this:
No matching package to install: 'lmdb.h'
No matching package to install: 'mdb.c'
No matching package to install: 'patching'
Moreover, it resulted in bogus BuildRequires that may have existed (e.g. "file").
By replacing the usage of contextlib.redirect_stdout
(which only redirects Python's sys.stdout)
with a custom context manager that captures stdout on file descriptor level
(in addition to Python's sys.stdout),
we avoid this leak.
File descriptor magic heavily inspired by the capfd pytest fixture.
Related: rhbz#2168193
