Alex Williamson <alex.williamson(a)redhat.com> changed:
What |Removed |Added
--- Comment #10 from Alex Williamson <alex.williamson(a)redhat.com> ---
(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.
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
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
content. Please update the src.rpm with the archive from the Source link:
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
-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!
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