%forgemeta is the culprit. It modifies %dist in ways rpmdev-bumpspec cannot foresee. And it is not a supported versioning scheme.

Did you have the sources downloaded and available when you ran rpmdev-bumpspec? I seem to remember that this sometimes fixes this problem :(

%forgemeta is the culprit. It modifies %dist in ways rpmdev-bumpspec cannot foresee.

Somehow rpmbuild -bs can cope with that scheme.

Did you have the sources downloaded and available when you ran rpmdev-bumpspec? I seem to remember that this sometimes fixes this problem :(

I did rpm -i mesaflash-3.4.0-0.3.20200608git946725c.fc31.src.rpm.
Then, in the rpmbuild/SPECS directory, I executed rpmdev-bumpspec.

@dwrobel

What exactly did you expect rpmdev-bumpspec to do? By default, it bumps the "Release" value, and it did the right thing in your example, adhering to Fedora's pre-release versioning scheme. You added a %changelog comment saying "Bump Version", which is wrong and misleading, because you didn't change "Version".

About the %forgemeta macro, rpmbuild is part of RPM and evaluates macros, but it doesn't modify the spec file. It doesn't do what rpmdev-bumpspec tries to do. rpmdev-bumpspec doesn't evaluate RPM macros, so it doesn't know it needs to add the git commit hash to the %changelog comment. That is a minor detail only anyway and doesn't affect the rpmbuild of your spec file.

What exactly did you expect rpmdev-bumpspec to do?

It's described in the initial report:

I received the comment[1] that the changelog in mesaflash.spec[2] is not correct, more precisely it lacks date and git version (20200608git946725c):

--

You added a %changelog comment saying "Bump Version", which is wrong and misleading, because you didn't change "Version".

That's an example showing that rpmdev-bumpspec does not produce correct %changelog entry. If the comment "Bump Version" misleads you, simply ignore it, just look at the:

+* Tue Jun 30 2020 Damian Wrobel dwrobel@ertelnet.rybnik.pl - 3.4.0-0.4

which is wrong as it does not contain date and git sha (missing part: .20200608git946725c).

-Release: 0.3%{?dist}
+Release: 0.4%{?dist}

This is correct and defines the %release value. The same %release value to mention in the changelog. rpmdev-bumpspec cannot know that there is a %forgemeta macro that messes with the %release definition. And it doesn't evaluate RPM macros.

rpmdev-bumpspec cannot know that there is a %forgemeta macro that messes with the %release definition.

Quote from packaging guidelines[3]:

%{forgemeta} centralizes and abstracts our knowledge about those forges, so packagers do not have to handle download quirks manually.

As %forgemeta is part of the official packaging guidelines it would be nice to be fully supported by various rpmdevtools.
In the same way %forgemeta automates downloading sources the rpmdev-bumpspec should update changelog comment correctly and not force people do that manually.

[3] https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control

Well, you are not forced to use rpmdev-bumpspec during review. It is a tool to help during automated mass-rebuilds, and for that task it is good enough.

The E:V-R details right of the email address in changelog comments are not everyone's cup of tea, btw. They are not mission critical but optional. If truncated, they don't break the rpmbuild. However, in your case, V-R is complete and accurate.

The %forgemeta macro messes with the %dist macro definition, and since %dist is not to be included in changelog entries, rpmdev-bumpspec can't do anything about this. Effectively, %forgemeta breaks rpmdev-bumpspec.

Well, you are not forced to use rpmdev-bumpspec during review.

I didn't use, it was a comment I got from reviewer (see: [1]).

It is a tool to help during automated mass-rebuilds, and for that task it is good enough.

I'm using rpmdev-bumpspec on a daily basis to generate a new %changelog entries. Is there another alternative available or a better recommended way of automatically generating %changelog entries before detached rpm changelogs[4] will be introduced?

They are not mission critical but optional.

Then, maybe it would be good to fix it in rpmlint (I guess reviewer got it from it) to not produce those warnings:

mesaflash.x86_64: W: incoherent-version-in-changelog 3.4.0-0.3 ['3.4.0-0.3.20200608git946725c.fc33', '3.4.0-0.3.20200608git946725c']

[4] https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs

Please keep this ticket closed. Thank you!