Spec URL: https://download.copr.fedorainfracloud.org/results/ksurma/pyp2spec-fedora/fedora-rawhide-x86_64/04538913-pyp2spec/pyp2spec.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/ksurma/pyp2spec-fedora/fedora-rawhide-x86_64/04538913-pyp2spec/pyp2spec-0.5.0~a1-1.fc37.src.rpm Description: pyp2spec is a tech preview. It is a tool generating Fedora RPM spec files for Python distributions. It utilizes the benefits of pyproject-rpm-macros. Fedora Account System Username: ksurma Fedora review was run on the package: https://download.copr.fedorainfracloud.org/results/ksurma/pyp2spec-fedora/fedora-rawhide-x86_64/04538913-pyp2spec/fedora-review/ This package's version 0.1.0 was approved in Nov 2021 and the repo was requested. Then I decided to go on with a Copr repository which provided more flexibility. This time we need to have the package in Fedora in order to use it in Copr natively to build packages. I'd like to get a formal approval for the current package version, then I intend to upload the package to the already existing pagure repository.
JFYI %{pypi_source pyp2spec} should work because it strips any ~s from the %version tag. But maybe explicit is better than magical :)
Hello Karolina, thank you for the contribution. Overall the spec looks good to me, I was able to build it for F35, F36, and Rawhide. I briefly tested the tool and it works for me. I am a bit confused by the versioning (pre-releasing 0.Y.Z.something versions feels like an overkill) but that is an upstream decision that I am not going to question. And it is IMHO packaged properly. However, the package appears to already be in Fedora? Please see RHBZ 2025908, It wasn't built yet, but the DistGit repo exists: https://src.fedoraproject.org/rpms/pyp2spec
(In reply to Jakub Kadlčík from comment #2) > > However, the package appears to already be in Fedora? > Please see RHBZ 2025908, > > It wasn't built yet, but the DistGit repo exists: > https://src.fedoraproject.org/rpms/pyp2spec Karolina indicated clearly that in the first comment: > This package's version 0.1.0 was approved in Nov 2021 and the repo was > requested. Then I decided to go on with a Copr repository which provided > more flexibility. This time we need to have the package in Fedora in order > to use it in Copr natively to build packages. I'd like to get a formal > approval for the current package version, then I intend to upload the > package to the already existing pagure repository. On the other hand I agree with you, it is a bit dubious what is the purpose of this review. In my humble opinion the purpose of these reviews is to ensure that basically the code is legal and that spec file follows all the guidelines. And that clearly is the case both in the initial review, that I have followed, and now. We never require a re-review when there is a considerable change in the code base. :-) We trust the packager, and in this particular case I do trust Karolina's work and so do not see the need for a new review. > This time we need to have the package in Fedora in order to use it in Copr natively to build packages. I would expect that any feedback that could/would be provided here to be more appropriate in other places like, for example, Fedora Python SIG mailing list. Again, this is my view of this process. :-)
> Karolina indicated clearly that in the first comment: Indeed, I overlooked the comment. Thank you for clarifying. > And that clearly is the case both in the initial review, > that I have followed, and now. Agreed :-) I am not particularly sure how we should proceed here, so if anyone has a clear idea, please speak up. However, as I see it, the end result of a package review is a DistGit repository being created. Which already exists https://src.fedoraproject.org/rpms/pyp2spec There is an informal +1 from me and José, and the package is fine. Karolina, I would recommend pushing the package into DistGit, building it in Koji, and submitting a Bodhi update. If everything goes well, I will close this issue as a duplicate of 2025908. If problems occur, we will figure it out. Sounds good? :-)
Thank you, Jakub and José for the comments on the package. I agree this is uncommon situation with package already having the dist-git repository. I see your point here. When evaluating how to make it straight properly, the closest policy seemed to me the one on reclaiming the retired package, which requires a re-review after 8 weeks. I'll build package in the existing repository in Pagure once the Python 3.11 side tag is merged. > I am a bit confused by the versioning (pre-releasing 0.Y.Z.something > versions feels like an overkill) but that is an upstream decision that > I am not going to question. And it is IMHO packaged properly. Thank you for the version feedback. I see that according to the semver 2.0 specification, leading 0 already communicates that it's an alpha (https://semver.org/#spec-item-4) which, together with verbose info in the description, probably states the project's maturity clearly enough.
Successfully built for F37 and F36, F35 coming this week (requesting the branch). Let's close this BZ. *** This bug has been marked as a duplicate of bug 2025908 ***