#10952 systemd changelog entries for mass rebuild are lacking version numbers
Closed: It's all good 2 years ago by zbyszek. Opened 2 years ago by zbyszek.

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

2 years ago

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.

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.

Metadata Update from @zbyszek:
- Issue close_status updated to: It's all good
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog