On Thu, Aug 13, 2020 at 12:42 PM Qiyu Yan <yanqiyu(a)fedoraproject.org> wrote:
Hello all,
I have some problem with rpmdev-bumpspec recently.
In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
use time+date in the changelog it generates[1], while the packaging
guidelines have not been updated accordingly[2], should the guideline
be updated to the rpmdev-bumpspec change?
I am packaging fcitx5 using forge macros, and upstream have never
tagged a version, in this case, I am packaging like this [3] (The
snapshot dates and git short commit hashesin changelog is manually
added). With this spec file, I noticed that when I try to use
rpmdev-bumpspec to generate a changelog, it will give things like this
[4].
You can see that, in case of using forge, rpmdev-bumpspec can't
include either snapshot dates nor git short commit hashes, will this
be fine (and we can ignore the warning from rpmlint when ran on the
built packages, and start the review process) or I should always
manually include snapshot dates and git commit hashes in the
changelog. Or I should wait for this change [5] to be done and ignore
all changelog things? (and submit for review then?)
Thanks.
You're not wrong, rpmdev-bumpspec is not completely compatible with
the forge macros, especially in the snapshot packaging case (because
the forge macros mess with the value of %dist, as mentioned in the
other response).
While rpmdev-bump will produce changelog entries with "wrong" (or
incomplete) EVR information, SRPM and RPM builds will have the correct
Release set, so it's not a "big deal". For my packages that suffer
from this (e.g. some Go packages that internally use the forge
macros), I tend to manually "fix" the version-release in the changelog
entries after running rpmdev-bumpspec.
Fabio