rpminspect reported:
A forbidden code point, 0x202E, was found in the pip-21.2.3/AUTHORS.txt source file on line 635 at column 0.
This issue was already found and fixed upstream
when pip was added to CentOS Stream for Python 3.11.
https://github.com/pypa/pip/pull/12046
However, the fix got overridden by upstream automation (which creates the file from git log).
The regression was reported upstream in https://github.com/pypa/pip/issues/12467
The patch still applies, so we could reuse it again.
However, rpminspect then not only does not stop reporting this,
but it starts reporting the same problem for the patch (from python3.12-pip):
A forbidden code point, 0x202E, was found in the 12046.patch source file on line 19 at column 11. This source file is used by (null).
A forbidden code point, 0x202E, was found in the 12046.patch source file on line 28 at column 1. This source file is used by (null).
A forbidden code point, 0x202E, was found in the pip-23.2.1/AUTHORS.txt source file on line 482 at column 10. This source file is used by python3.12-pip.spec.
A forbidden code point, 0x202E, was found in the pip-23.2.1/AUTHORS.txt source file on line 738 at column 0. This source file is used by python3.12-pip.spec.
The file is fine. It's not code.
Note that ideally, we would only exclude AUTHORS.txt, somehow like this:
unicode:
exclude: ^AUTHORS\.txt$
However, it does not work (at least on CentOS Zuul CI).
Cherry-picked from fd85d3c16a
Not only are the removed Pythons not available in c9s,
testing with other Pythons is redundant
because only Python 3.9 uses the wheel built from this component.
pipenv was retired in Fedora and it was never branched for EPEL 9.
python3-tox was renamed to tox before it was added to EPEL 9.
EPEL is required to:
- use mock
- test integration with virtualenv and tox
Additionally, use c9s tests of pyproject-rpm-macros,
rawhide tests might use features not yet synced to c9s.
Don't run pyproject/clikit test, not enough dependencies in EPEL 9.
In pip 21.2, the Distribution here is a wrapper around the regular Distribution.
It has a limited set of API defined by the BaseDistribution protocol.
dist_location() uses the project_name attribute under the hood --
and that is not part of the API.
If we ever upstream this, we should make this check a property of BaseDistribution.
But, for now, we hotfix it by accessing the private wrapped Distribution object directly.
Yes, this is ugly.
Related: rhbz#1932713
