https://bugzilla.redhat.com/show_bug.cgi?id=1728381 Alex Williamson <alex.williamson@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(crobinso@redhat.c | |om) --- Comment #10 from Alex Williamson <alex.williamson@xxxxxxxxxx> --- (In reply to Cole Robinson from comment #9) > (In reply to Alex Williamson from comment #8) > > (In reply to Cole Robinson from comment #7) > > > > > > The source URL looks acceptable per the docs, but looks like the archive in > > > the SRPM is not the same content as github generates. Please fix that > > > > Fixed, I don't know how to control the directory structure github uses in > > the tarball, so I dropped the sha1 from the local build to match github. > > > > I don't think there's any way to control the github directory structure. > There is a way to get a .tar.gz per commit, using some github URL magic. > https://github.com/mdevctl/mdevctl/archive/ > e2bda0996bd37d12da6292d8dc6d4a938f657e86/mdevctl- > e2bda0996bd37d12da6292d8dc6d4a938f657e86.tar.gz Right, github will make an archive from any valid refspec. I was trying to use both the tag and commit id since tags could theoretically be removed and recreated to point at something different, but I don't see an easy way to do that. Using the commit id should be less forgeable, but then it's only the spec file correlating the tagged version to a commit id. If we trust upstream not to change tags, what we have should be fine. > > > - Changelog in prescribed format. > > > > > > Changelog lines should be individually prefixed with '-' and contain a > > > version string > > > at the end. > > > > > > Your changelog there looks more like it should be a NEWS.md file which you > > > can ship > > > as %doc. Using that is better for upstream too IMO because other distros > > > won't want a .spec file to be the canonical release notes. > > > > > > For Fedora spec the changelog should be the package version history so all > > > of those > > > entries should be trimmed except the most recent one basically. > > > > Fixed. What's present now is still entirely auto-generated from the git > > log, as I think that is our canonical release notes. However, the > > formatting now matches the Fedora requirements and we're rolling together > > all the commit subjects between tags. I think this will allow me to merge > > the upstream auto-generated spec file with the Fedora maintained one fairly > > automatically, assuming it's good practice to maintain the logs for Fedora > > specific rebuilds. > > Dealing with changelogs across upstream hosted spec and downstream is a pain. > Most projects I work on just don't include a %changelog upstream. But > whatever > works for you as long as the format is appropriate for Fedora. Would it be considered bad practice in Fedora if the changelog is rewritten between releases? For instance if the upstream auto-generation changes the formatting or contents for previous releases (as I've done in 0.50), how much, if any effort should we make in the Fedora package to retain released changelog contents as-is, versus simply maintaining compliant formatting? Same question for the Fedora specific changelog entries. Would it be considered required or just best-effort to maintain, for example, a mass rebuild 0.49-2 changelog entry when I upload 0.50? Clearly the approach I'm taking assumes this upstream package isn't going to have more than a handful of commits between releases and I hope that merge tools will handle much of this for each release. > The new version looks good, but the archive still doesn't match the Source > content. Please update the src.rpm with the archive from the Source link: > https://github.com/mdevctl/mdevctl/archive/0.49/mdevctl-0.49.tar.gz > > After that I'll approve the review Ok, yes, the previous srpm was generated from the upstream Makefile with a local archive rather than directly using the github link. The contents are the same, but I assume you're looking at md5sum between the two. I hadn't really figured out this part of the process yet. For the version uploaded below, I'm using 'spectool -g -R mdevctl.spec' to fetch the upstream source and 'rpmbuild -bs --rmsource mdevctl.spec' to generate the srpm and cleanup the upstream source tarball. The only other change here is the changelog format, which I hope doesn't churn your stomach or violate Fedora standards. Thanks! http://people.redhat.com/~alwillia/mdevctl/mdevctl.spec http://people.redhat.com/~alwillia/mdevctl/mdevctl-0.50-1.fc29.src.rpm -- 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 _______________________________________________ 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
