https://bugzilla.redhat.com/show_bug.cgi?id=2123954
--- Comment #16 from Sandro <gui1ty(a)penguinpee.nl> ---
Spec URL:
https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora...
SRPM URL:
https://download.copr.fedorainfracloud.org/results/gui1ty/PyMunin3/fedora...
(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