Another oddity is that looking at the output of the fedpkg build command I see

$ fedpkg build
Building python-graphql-server-3.0.0-14.b4.fc36 for rawhide
Created task: 74631318

but then

74631602 buildArch (python-graphql-server-3.0.0-4.b4.fc36.src.rpm, noarch): free

Sorry I didn't spot this one earlier, I was busy with other projects and didn't check back as often as I would have liked.

I tried to reproduce this here (Fedora 35), but it would always "do the right thing" (this is with plain 0.2.5, but the same with the changes I've queued up in git):

nils@makake:~/dist-git/fedora/rpms/python-graphql-server (rawhide)> rpmautospec calculate-release .
calculate_release release: 22.b4
nils@makake:~/dist-git/fedora/rpms/python-graphql-server (rawhide)> rpmautospec calculate-release . -n
calculate_release release: 15
nils@makake:~/dist-git/fedora/rpms/python-graphql-server (rawhide)> 

None as a version in the changelog hinted at a problem in the spec file which made it fail to be parsed by rpm --specfile in Koji (not locally because fedpkg put out the right release number). I managed to get to the root of it on Koji in staging:

[nphilipp@koji01 python-graphql-server][STG]$ git log -1
commit cd30d32a0a270b048be0f8a37204d1be848b5f48 (HEAD)
Author: Mattia Verga <mattia.verga@protonmail.com>
Date:   Mon Aug 23 18:00:03 2021 +0200
    Fix %pyproject_extras macro
[nphilipp@koji01 python-graphql-server][STG]$ rpm --specfile python-graphql-server.spec 
python-graphql-server-3.0.0-1.b4.fc34.noarch
python3-graphql-server-3.0.0-1.b4.fc34.noarch
[nphilipp@koji01 python-graphql-server][STG]$ git checkout HEAD^
Previous HEAD position was cd30d32 Fix %pyproject_extras macro
HEAD is now at 0b7d415 Align with newer Python packaging guidelines
[nphilipp@koji01 python-graphql-server][STG]$ git log -1
commit 0b7d41592bae55277943a9e4fc4c036c98cc40b0 (HEAD)
Author: Mattia Verga <mattia.verga@protonmail.com>
Date:   Sun Aug 22 11:41:26 2021 +0200
    Align with newer Python packaging guidelines
[nphilipp@koji01 python-graphql-server][STG]$ rpm --specfile python-graphql-server.spec 
error: line 30: Unknown tag: %pyproject_extras_subpkg -n python3-graphql-server flask webob aiohttp
error: query of specfile python-graphql-server.spec failed, can't parse
[nphilipp@koji01 python-graphql-server][STG]$

I.e. with the (undefined) macro in the wrong place, rpm --specfile couldn't parse the spec file which is supported by the fact that locally I could make it fail by moving away /usr/lib/rpm/macros.d/macros.pyproject which defines this macro. There are two ways I can think of to approach this:

• Define the macro so the spec file parses well. I don't think that scales well though, there can be any number of unknown macros which might muck with the parsing.
• Make the processor more robust against unparseable spec files. I thought I had done this already, i.e. assume the version to be the same as the previous one in this case, but this doesn't seem to be the cae :wink:.

BTW, I've seen that the package is retired now – I hope it's not because of this.

Don't worry, I orphaned the package just because I lost interest in it.

I don't understand where you're saying that "it does the right thing": why calculate-release . returns 22 while calculate-release . -n returns 14? Is that referred to what I wrote in comment#2? Is it the right behavior?

rpmautospec calculate-release -n only counts the number of commits and ignores any flags, e.g. -b 8. It's mainly a debugging aid.

I've just hit another case with rtkit. The release number went down from -34 to -11 because of a spec file error in history:

$ ~/python/rpmautospec/run-rpmautospec.py generate-changelog|grep '^\*'|head -n3
* Fri Apr 22 2022 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> 0.11-14
* Fri Jan 21 2022 Fedora Release Engineering <releng@fedoraproject.org> - 0.11-29
* Fri Jul 23 2021 Fedora Release Engineering <releng@fedoraproject.org> - 0.11-28

The cause seems to be the same:

$ git switch -d 622c2c71c5826b075843dc241fc25ea969bcd3aa
$ rpm --specfile *spec
error: The %systemd_postun macro requires some arguments
error: query of specfile rtkit.spec failed, can't parse

Note that this isn't fixed by the changes in main. I'm calling run-autospec.py directly from git (3a54832858241e93b74cc976468c6a4bb2687f50).

I'll file a follow-up RFE to have generate-changelog warn when history is out of order.

Getting the correct behaviour here is not easy. Let's call commits where evaluation fails as "indeterminate". If those commits are counted as changing release +1, then I think this should give correct behaviour in all cases. We can't be certain that the indeterminate commit wasn't built (maybe it fails now but it worked in the past because of some external changes), so we have to pessimistically assume that it was built.

@zbyszek good catch. I'll close this one now – this wasn’t about spec files that only started to fail being parsed later – and follow up in #247 (rescoped, but see there).