pcs-0:0.11.4-3.fc38 has an invalid Python version in Python metadata. See: $ repoquery --repo=rawhide --provides pcs ... python3.11dist(pcs) = 0.11.4.15-f7301 python3dist(pcs) = 0.11.4.15-f7301 The provides are generated from the metadata in /usr/lib/python3.11/site-packages/pcs-0.11.4.15_f7301-py3.11.egg-info where the version is specified as 0.11.4.15-f7301. However, this version is invalid -- it does not parse according to the specification in https://peps.python.org/pep-0440/ The python3dist(pcs) and python3.11dist(pcs) RPM provides are generated by a script that uses the python-packaging library to parse the version. Currently, invalid versions are "parsed" as-is. However, since python-packaging 22.0 invalid versions error. Considering https://fedoraproject.org/wiki/Changes/Update_python-packaging_to_version_22_plus this package will fail to build from source soon if it continues to list an invalid version in its Python metadata. ------------- We have looked into the sources of pcs to figure out where is the version coming from. Prepped sources (fedpkg clone pcs && cd pcs && fedpkg prep) include setup.py.in with: setup( name="pcs", version="@VERSION@", ... ) This VERSION variable is supplied by the configure script which has: # Identity of this package. PACKAGE_NAME='pcs' PACKAGE_TARNAME='pcs' PACKAGE_VERSION='0.11.4.15-f7301' PACKAGE_STRING='pcs 0.11.4.15-f7301' PACKAGE_BUGREPORT='developers' PACKAGE_URL='' The configure script is directly included in the pcs-0.11.4.15-f7301.tar.gz tarball which is listed in the spec as: Name: pcs Version: 0.11.4 ... URL: https://github.com/ClusterLabs/pcs ... %global version_or_commit %{version}.15-f7301 %global pcs_source_name %{name}-%{version_or_commit} ... Source0: %{url}/archive/%{version_or_commit}/%{pcs_source_name}.tar.gz Hence https://github.com/ClusterLabs/pcs/archive/0.11.4.15-f7301/pcs-0.11.4.15-f7301.tar.gz This URL however gives error 404 because there is no such tag or commit on github.com/ClusterLabs/pcs -- and even if it was, the tagged tarball won't have a pre-generated configure script. Hence we believe the tarball was generated by hand when this was committed https://src.fedoraproject.org/rpms/pcs/c/dc07da9166757fe5e3dc1f9c70a1e78ad279549c?branch=rawhide ------------- To mitigate this, always pass valid Python versions to setup(version=...). One possibility is to never create tarballs with invalid versions by hand. If versions like 0.11.4.15-f7301 are actually desirable by pcs, they need to be converted to Python-valid versions before passing them to setup(version=...). E.g. use: setup( name="pcs", version="@PYVERSION@", ... ) And generate PYVERSION from VERSION in the configure script. A valid version might be e.g. 0.11.4.15+f7301 -- see https://peps.python.org/pep-0440/#local-version-segments or simply 0.11.4.15. ----------- Even if we don't update python-packaging in Fedora, recent setuptools https://setuptools.pypa.io/en/latest/history.html#v67-0-0 also drops support for invalid versions, so the package would eventually fail to build from source anyway, even upstream.
A very dirty fixup for this particular downstream-only version might be something like this: %prep ... sed -i 's/@VERSION@/%(echo %{version_or_commit} | sed s/-/+/)/' setup.py.in (untested)
testing in https://copr.fedorainfracloud.org/coprs/build/5387368
That fixup works.
Upstream patch: https://github.com/ClusterLabs/pcs/commit/0b6c1e7f6a8636126a8a7fcdef478ef396ceb68b
Just for some transparency, I will fix the tarball links in the spec file and make it so that the non-release GitHub tarballs could be used for packaging. Our current packaging process relies on using tarballs generated by `make dist`, not the GitHub tarballs (except for upstream releases, those are built from GitHub tarballs). It's not a difficult fix but I need to fix more stuff in the next Fedora builds (find-debuginfo and nodejs packaging changes). Right now, I'm still building RHEL releases but Fedora is my next priority. Expect the fix sometime towards the end of next week.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Update: I didn't start working on the Fedora build until this Tuesday due to problems with our RHEL builds. I have managed to fix this BZ but I need to resolve other issues with this Fedora build. There have been many changes - we removed or changed some rubygems and we stopped bundling (and therefore compiling) rubygems, so we switched to noarch. The first scratch build is not completely functional, so I need to do some debugging. It will be done next week.
FEDORA-2023-3b9aac1d91 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3b9aac1d91
FEDORA-2023-3b9aac1d91 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-149f9b259d has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-149f9b259d
FEDORA-2023-149f9b259d has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-149f9b259d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-149f9b259d has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.