https://bugzilla.redhat.com/show_bug.cgi?id=2123954 --- Comment #16 from Sandro <gui1ty@xxxxxxxxxxxxx> --- Spec URL: https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-rawhide-x86_64/04830894-python-PyMunin3/python-PyMunin3.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora-rawhide-x86_64/04830894-python-PyMunin3/python-PyMunin3-3.0.1-3.fc38.src.rpm (In reply to Parag AN(पराग) from comment #15) > 1) I am not familiar with rpmautospec. Last time I tried to look into it, I > found it frustrating to use it. Hence I am not willing to move my packages > to use it till Fedora mandates it in future someday. That's fine. Every packager gets to chose their preferred way of packaging within the boundaries of the packaging guidelines. I chose rpmautospec since it will use the git commit messages for filling the %changelog entries and take care of bumpspec. A little less work for me. > 2) I will always prefer to see the submitted SPEC file, also included in the > SRPM file. Here your SPEC is updated but not SRPM. Remember if it was > reverse I would have not minded much but in the end we import SRPM when we > initially add new package in Fedora. Well, maybe that's where the confusion started. I started out with providing links to the spec file in Copr. (In reply to Sandro from comment #5) > > Can you upload original spec file? > > I stapled it to this bug. You commented with: (In reply to Parag AN(पराग) from comment #6) > Can you give full URL so that I can use fedora-review on this review bug? So, I uploaded the original spec file on GitHub and provided the URL. > 3) Like I said I am not much aware of rpmautospec usage. I pick your SPEC > that uses auto macros, build SRPM on my machine and ran a build (that uses > auto macros) first time in my copr repo. I am happy that it worked fine. > https://copr.fedorainfracloud.org/coprs/pnemade/misc/build/4843654/ That's what I did when I first submitted this review, In fact I used Copr for every rebuild since, so the spec file and SRPM are still available in Copr (see URLs above). > So why you want different SPEC file in SRPM? Or did I used your SPEC > wrongly? Please check and tell me. I don't. The original spec file (GitHub URL) is what will end up in dist-git. Copr/Koji will use that to rebuild the SRPM, which will then contain the spec file with the rpmautospec macros expanded. > I also realized below thing. > During normal package review concept, packager need to keep bumping release > tag and add relevant changelog entry. But now with usage of rpmautospec > macros I need to think how package review should happen. Maybe I should stop > asking packager for changelog entry as there is actually no real git commits > happening till package gets approved. So in the end release tag looks remain > "1" irrespective of how many times SPEC gets updated. Well, I'm using git locally for tracking changes while the package is under review. So, in my case you will see a couple of changelog entries added as I implemented changes recommended in this review. Hence the current release is 3 in Copr. Now that we have come full circle, back to spec and SRPM as produced by Copr, fedora-review should no longer complain about differences in provided spec file and spec file extracted from SRPM. Hopefully, this will allow you to finalize the review. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2123954 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
