> On Wed, Aug 11, 2021 at 4:08 PM Michael J Gruber <mjg(a)fedoraproject.org> wrote:
>
> I think these can be split into a different cases:
>
> - BibTool: spec: Release: 4%{?dist} verrel: BibTool-2.68-4.fc36
> calculate_release release: 6
> - adf-gillius-fonts: spec: Release: 2%{?dist} verrel:
> adf-gillius-fonts-1.009-2.fc36 calculate_release release: 4
> - flickcurl: spec: Release: 15%{?dist} verrel: flickcurl-1.26-15.fc36
> calculate_release release: 17
> - luckybackup: spec: Release: 10%{?dist} verrel:
> luckybackup-0.4.9-10.fc36 calculate_release release: 13
> - tetex-elsevier: spec: Release: 26%{?dist} verrel:
> tetex-elsevier-0.1.20090917-26.fc36 calculate_release release: 32
> These are correct (or at least, expected).
OK. The README said "Calculate the next value for the RPM release field (i.e. to be used for the next build)", so that I wasn't sure whther to expect x or x+1 when at x.
> rpmautospec makes the simple assumption of incrementing Release by 1
> for every commit, and adding a changelog entry for every commit
> message.
> Looking at BibTool, there's two commits in there which didn't bump
> Release (adding BR: make and the second F35 Mass rebuild commit),
> which didn't count previously, but do count now.
It used to be habit to bump for Builds only, not intermediate commits. For the mass re-rebuild it may have been similar (FTBFS before then don't bump).
> This is the reason why I only converted my packages if I also had a
> version update at the same time, so that it definitely lines up to
> Release: 1.
The easy way out :)
I'm maintaining a few stale packages, though.
> - adf-accanthis-fonts: spec: Release: %autorelease (was 25!) verrel:
> adf-accanthis-fonts-1.8-4.fc36 calculate_release release: 4
> This looks like a bug. I see no obvious reason why the new calculated
> Release number would be 4, but it's possible that the %forge macros
> interfere with the calculation somehow, since they inject all sorts of
> weird stuff.
Oh yes, the previous maintainer switched to the macros before they landed and then dumped the package...
PkgHistoryProcessor seems to stop parsing completely at some commit.
On the other hand, looking at the last non-autorelease spec and incrementing from that one would have lead to fewer surprises... I mean, if I opt in at some point and the tool looks at history before which I cannot rewrite (as opposed to the changelog) then things *will* go wrong fpr quite a few packages.
> - dblatex: spec: Release: 5%{?dist} verrel: dblatex-0.3.12-5.fc36
> calculate_release release: 5
> - impressive: spec: Release: 0.9.%{timestamp}svn%{svnversion}%{?dist}
> verrel: impressive-0.13.0-0.9.20210612svn311.fc36 calculate_release
> release: 9
> - notmuch: spec: Release: 2%{?dist} verrel: notmuch-0.32.2-2.fc36
> calculate_release release: 2
> - sil-gentium-basic-fonts: spec: Release: 2%{?dist} verrel:
> sil-gentium-basic-fonts-1.102-2.fc36 calculate_release release: 2
> What's wrong here? The tools all agree.
I wasn't sure about the x vs x+1. Good to know it's fine.
> Note that for "impressive",
> you'd need to use "%autorelease -p -e %{timestamp}svn%{svnversion}" to
> keep the snapshot info in the same format (see the rpmautospec docs
> for details).
Yes. Wanted to convert the easy one first :|
> - portmidi: spec: Release: 41%{?dist} verrel: portmidi-217-41.fc36
> calculate_release release: 30
> This shouldn't happen, unless there are commit(s) that bumped Release
> by more than 1 - in which case you could specify a positive offset for
> the %autorelease macro to take this into account. Maybe the git
> history is a bit messed up, it looks like the last version update
> happened way back before the cvs -> git conversion?
All release bumps are individual commits with "+1", starting from 1.
Maybe PkgHistoryProcessor cannot parse some old specs? Again, relying on that is asking for trouble.
> The only thing I am concerned about is "fedpkg verrel" not printing
> the same number as "calculate_release". I think "fedpkg srpm" etc.
> have been adapted to get the release number from rpmautospec, but it
> looks like "fedpkg verrel" did not receive the same treatment. This
> should probably be reported as a bug against fedpkg / rpkg.
>
> Fabio
Thanks for the detailed analysis!
I do think that taking the last non-autospec spec as a base (rather than parsing ancient history) would be much more robust, though. Or at least parse the changelog (rather than commit log) because we can rewrite that when we opt in.
Michael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
