Learn more about these different git repos.
Other Git URLs
I just noticed this. It doesn't have any immediate impact, but it is against the Packaging Guidelines which are very clear that a changelog entry with a release number must be generated for each new version. The user can probably infer the number from surrounding entries, but sometimes this can be ambiguous, e.g. if the package wasn't built outside of mass rebuilds or some builds failed.
Examples: https://src.fedoraproject.org/rpms/systemd/c/31a512dde108fe2e71bfab8c15350a5bdc46f7dd https://src.fedoraproject.org/rpms/systemd/c/c763537617 https://src.fedoraproject.org/rpms/systemd/c/46a408102a
I tried to convert systemd to rpmautospec, and it's spewing errors and generating bogus release numbers. I started debugging that and then noticed this issue. I'm not sure how widespread the issue is, but a few other packages I checked are fine, so they're probably related and it's some specific bug.
We use rpmdev-bumpspec. If that doesn't do the right thing it's a bug in that...
Metadata Update from @phsmoura: - Issue tagged with: low-gain, low-trouble, ops
rpmdev-bumpspec apparently does not like the way you've conditionalized the Release field. It looks like you've already switched to rpmautospec, but this would've worked:
diff --git a/systemd.spec b/systemd.spec index eb4122e..8a38946 100644 --- a/systemd.spec +++ b/systemd.spec @@ -23,6 +23,8 @@ %bcond_without tests %bcond_without lto +%global baserelease 1 + # Support for quick builds with rpmbuild --build-in-place. # See README.build-in-place. %bcond_with inplace @@ -31,7 +33,7 @@ Name: systemd Url: https://www.freedesktop.org/wiki/Software/systemd %if %{without inplace} Version: 251.3 -Release: 1%{?dist} +Release: %{baserelease}%{?dist} %else # determine the build information from local checkout Version: %(tools/meson-vcs-tag.sh . error | sed -r 's/-([0-9])/.^\1/; s/-g/_g/')
Then, it will bump %baserelease instead of trying to touch both instances of Release: and failing.
Release:
Either way, this is an upstream bug that doesn't fall under the purview of releng.
Thanks for the investigation and pointers. I added the missing tags in the changelog file, in case anyone cares. And since the switch to %autochangelog the tags are inserted by rpmautospec, so this issue is effectively solved.
changelog
%autochangelog
Metadata Update from @zbyszek: - Issue close_status updated to: It's all good - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.