pyp2spec builds choke on PEP 625 incompatible packages

[praiskup]

After upgrading the builders to Fedora 41 where's the newer pyp2spec utility:

https://download.copr-dev.fedorainfracloud.org/results/@copr/TEST1732047865954994293-Pyp2spec/srpm-builds/02920033/builder-live.log.gz

When I try locally, I see:

$ spectool -S *spec --get-files
Downloading: https://files.pythonhosted.org/packages/source/p/pello/pello-1.0.4.tar.gz
Download failed:
404 Client Error: Not Found for url: https://files.pythonhosted.org/packages/source/p/pello/pello-1.0.4.tar.gz
-   0.0 B Elapsed Time: 0:00:00  

[praiskup]

@befeleme this is an interesting situation; the new pyp2spec doesn't support --top-level, so old copr-rpmbuild fails with that. When I upgrade copr-rpmbuild (to a new release don just now) to start using #3473, it fails like ^^^.

Shall we keep using the old pyp2spec for some time?

[praiskup]

Shall we keep using the old pyp2spec for some time?

I mean "old copr-rpmbuild" and "old pyp2spec"?

[praiskup]

There's now also the %autochangelog and %autorelease (/me 😢). Is that anyhow useful in Copr?

[praiskup]

The diffeerence between pyp2spec 0.8 (in copr production, on f39) and pyp2spec 0.11.0
(in copr stage, on f41):

- https://files.pythonhosted.org/packages/source/P/Pello/Pello-1.0.4.tar.gz
+ https://files.pythonhosted.org/packages/source/p/pello/pello-1.0.4.tar.gz

[hroncok]

There's now also the %autochangelog and %autorelease (/me 😢). Is that anyhow useful in Copr?

It's easier to generate 😀

[befeleme]

Hi, the main issue is not really in pyp2spec. It's that it has PEP 625 implemented now which standardizes the name of the sdist. Pello has been released too long ago to conform to this PEP - it could help if the sdist was regenerated / new version released. For the time being you can test pyp2spec on any other project that has more recent releases, e.g. pyp2spec itself.

There's now also the %autochangelog and %autorelease (/me 😢). Is that anyhow useful in Copr?

Does that pose a problem in Copr? I could keep the old behavior for the automode. As rpmautospec is gaining popularity in Fedora and we keep building tonnes of its rpms in Copr, it didn't occur to me there could be an issue at your end.

[hroncok]

Shouldn't pyp2spec reach out to PyPI and ask for the sdist filename?

[befeleme]

I see it more as a philosophical question: from practical POV it could (that's what it was doing before). OTOH the idea in my head is that pyp2spec should rely on standard whenever possible, and any identified gaps can be hotfixed and ideally proposed as future upstream standard. The sdist filenames were recently standardized so it felt correct to move to it.

[praiskup]

Does that pose a problem in Copr?

We are generating %changelog from a generated git-log :) and IMVHO empty %changelog is better than a generated and misleading %changelog like this. But since this is probably not causing any technical issues right now, let's leave it as is (we may track it separately later-on, if needed).

It's that it has PEP 625 implemented now which standardizes the name of the sdist.

Yeah, this actually broke our beaker tests in two places :-) I can of course adapt the testsuite and let Copr forget about the "old times", but if there are still too many packages released without conforming to PEP 625 (e.g., copr-cli still is #3521), then pyp2spec generator is not the tool of choice for as many users as it used to be.

[befeleme]

Does that pose a problem in Copr?

We are generating %changelog from a generated git-log :) and IMVHO empty %changelog is better than a generated and misleading %changelog like this. But since this is probably not causing any technical issues right now, let's leave it as is fornow (we may track it separately later-on, if needed).

Alright.

It's that it has PEP 625 implemented now which standardizes the name of the sdist.

Yeah, this actually broke our beaker tests in two places :-) I can of course adapt the testsuite and let Copr forget about the "old times", but if there are still too many packages released without conforming to PEP 625 (e.g., copr-cli still is #3521), then pyp2spec generator is not the tool of choice for as many users as it used to be.

That makes sense. There's not much cost to keep the old behavior going for some more time (years, probably), so I may just revert it.

[praiskup]

@befeleme do you have ETA for the new pyp2spec release & Fedora 41 build? If not, shall we just move to F41 builders, ignoring the the fact these non-pep-625 compliant packages fail to build?

[hroncok]

My opinion: Yes please, update to Fedora 41, don't wait for pyp2spec.

If this problem breaks users, at least we'll know about them if they speak up.

In the meantime, we know that the old Fedora version on builders already breaks existing users who spoke up (yours truly).

[befeleme]

@befeleme do you have ETA for the new pyp2spec release & Fedora 41 build? If not, shall we just move to F41 builders, ignoring the the fact these non-pep-625 compliant packages fail to build?

Seconding Miro: move to F41, I'll ship pyp2spec till the end of this week.

[befeleme]

You can grab https://bodhi.fedoraproject.org/updates/FEDORA-2024-567dc60077

[praiskup]

That helped: https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping:custom:foo/fedora-rawhide-x86_64/02920574-python-copr-cli/builder-live.log

https://pagure.io/fedora-infra/ansible/c/4ffa8cd38e4dffba76dc2bae805ad2d95d1949e9

[praiskup]

Updated in production. Thank you @befeleme