Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2166266 - pcs includes .egg-info with invalid Python version, will FTBFS with python-packaging 22+
Summary: pcs includes .egg-info with invalid Python version, will FTBFS with python-pa...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pcs
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Pospisil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 2151743 2166942
TreeView+ depends on / blocked
 
Reported: 2023-02-01 11:14 UTC by Miro Hrončok
Modified: 2023-03-11 03:13 UTC (History)
8 users (show)

Fixed In Version: pcs-0.11.5-1.fc39 pcs-0.11.5-1.fc38
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-03-02 19:46:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2023-02-01 11:14:37 UTC
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.

Comment 1 Miro Hrončok 2023-02-01 11:22:29 UTC
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)

Comment 2 Miro Hrončok 2023-02-01 11:23:36 UTC
testing in https://copr.fedorainfracloud.org/coprs/build/5387368

Comment 3 Miro Hrončok 2023-02-01 11:32:10 UTC
That fixup works.

Comment 5 Michal Pospisil 2023-02-03 18:30:15 UTC
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.

Comment 6 Ben Cotton 2023-02-07 15:12:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 7 Michal Pospisil 2023-02-17 08:40:13 UTC
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.

Comment 8 Fedora Update System 2023-03-02 18:50:58 UTC
FEDORA-2023-3b9aac1d91 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3b9aac1d91

Comment 9 Fedora Update System 2023-03-02 19:46:35 UTC
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.

Comment 10 Fedora Update System 2023-03-02 19:57:35 UTC
FEDORA-2023-149f9b259d has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-149f9b259d

Comment 11 Fedora Update System 2023-03-03 02:22:38 UTC
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.

Comment 12 Fedora Update System 2023-03-11 03:13:04 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.