`tar_git` at SFOS-OBS assembles an incorrect changelog

[Olf0]

PATCHMANAGER VERSION: 3.x.y

BUG DESCRIPTION

tar_git assembles an incorrect changelog, see e.g. for v3.2.4.

Consequently rpmlint at the SFOS-OBS complains:
patchmanager.aarch64: W: incoherent-version-in-changelog 3.2.3 ['3.2.4-1.12.1.jolla', '3.2.4']
The latest entry in %changelog contains a version identifier that is not coherent with the epoch:version-release tuple of the package.

AFAICS, Patchmanager currently does not provide an rpm/patchmanager.changes file, a %changelog section in the spec file or any other file accumulating the changes for each release.

STEPS TO REPRODUCE

Compile Patchmanager 3 at the SailfishOS-OBS.

ADDITIONAL INFORMATION

As we provide proper changelogs in Patchmanager's releases page at GitHub and git provides full traceability on commit level, IMO git_tar's flaw provides insufficient reason to address this by duplicating administrative work (i.e., maintain two changelogs, which must be kept in sync).

Consequently I labelled this as #wontfix. If someone thinks this is wrong, please remove the #wontfix label and address this issue.

[nephros]

That rpmlint complaint stems from the Version-Release mangling the OBS build process does.

Even if there were a .changelog file this would appear for every rebuild (the x.y.z-jolla revisions OBS generates).

AFAIK one could use a .changes.in file which can generate a changelog from git, and possibly would shut up rpmlint.

[Olf0]

That rpmlint complaint stems from the Version-Release mangling the OBS build process does.

Yes, see my analysis of Jolla's tar_git.

Even if there were a .changelog file this would appear for every rebuild (the x.y.z-jolla revisions OBS generates).

Ack.

AFAIK one could use a .changes.in file which can generate a changelog from git, and possibly would shut up rpmlint.

IMO a lot of effort and maintenance for minimal, and only potential gain (it may not work this way, too).

Basically I created this issue to document exactly that, plus the consequence: Won't fix.
Hence closing this issue now. Cool, one now can close an issue at GitHub as "Not planned (Won't fix, can't repro, duplicate, stale)"!

[nephros]

Without diving into the code, from doing a rpm -q --changelog, it seems the OBS build process (or rather, tar_git):

• will ignore any a %changelog entry in the .spec
• append the contents of a .changes file as a %changelog entry if that file is present
• execute a process specified in a .changes.in file as a %changelog entry if that file is present
• in absence of any of these, generate a changelog by
  1. comparing the tag it was given as a parameter and a previous tag (how is that selected?)
  2. selecting any commit titles containing a word in brackets at the beginning of the line ( e.g. [bump] update version)
  3. it can also do something with the token parameter (from the _service entry) to select change lines.

So, OBS-built RPMs of Patchmanager do contain changelogs, which are notprecisely wrong, but do not match up with the release changelog. They contain a rather confused collection of change entries instead.

[Olf0]

Without diving into the code,

tar_git is just a shell script; a bit convoluted, but basically understandable. When I analysed it, I focused on its mangling of the git-tag with the %release from the spec file and ultimately the resulting RPM file name, but not these changelog conversions.

from doing a rpm -q --changelog, it seems the OBS build process (or rather, tar_git):

• will ignore any a %changelog entry in the .spec

So AFAIU, this means, that:

• My PR #395 is fine, because it will be discarded by tar_git. OTOH, that may or may not silence rpmlint's complaint at the SFOS-OBS about a missing %changelog, depending on if rpmlint is provided with the original or converted spec file. I think that silenced it, so rpmlint might be run on the original spec file: I will try to remember to check that (see, e.g., sfos-upgrade 3.9.14 at SailfishOS:Chum).
• The builds from CI runs at GitHub do not contain a changelog (because we do not provide one), right? So for these a "dummy changelog" which provides a correct link to a "pseudo changelog" (the release messages at GitHub) would constitute an improvement, right?

• append the contents of a .changes file as a %changelog entry if that file is present

• execute a process specified in a .changes.in file as a %changelog entry if that file is present

• in absence of any of these, generate a changelog by

  1. comparing the tag it was given as a parameter and a previous tag (how is that selected?)
  2. selecting any commit titles containing a word in brackets at the beginning of the line ( e.g. [bump] update version)
  3. it can also do something with the token parameter (from the _service entry) to select change lines.

So, OBS-built RPMs of Patchmanager do contain changelogs, which are not precisely wrong, but do not match up with the release changelog. They contain a rather confused collection of change entries instead.

O.K. now I see, why some packages at SailfishOS:Chum choose to maintain a separate <pkg-name>.changelog file and why many of Jolla's own RPMs use the more complex route via a <pkg-name>.changes.in file.

I concur that I have never seen a %changelog section reaching an RPM file built by the SFOS-OBS.

Still I can tell from my own experience with either %changelog sections or a <pkg-name>.changelog file, that I regularly miss to update them synchronously with all relevant commits or PRs and when a git-tag is set (e.g., for a release) they are frozen in this likely incomplete state (without resorting to manipulating git or performing a re-release).
In contrast to that, the Markdown-annotations for a GitHub-"release" (basically a git-tag with these annotations and optionally attached files) can be altered any time (i.e., also retrospectively). This is why I have developed a strong preference to properly denote the changes only there.
Hence my suggestion to use a "dummy changelog", with its only entry being a link pointing to the project's releases page at GitHub.

[Olf0]

Oh, actually the measure suggested in PR #395 makes the SFOS-OBS do nothing, plus suppresses the rpmlint's error, see e.g., https://build.merproject.org/package/show/sailfishos:chum:testing/sailfishos-chum-gui-installer

[Olf0]

Found more references:

• In Jolla's Sailfish-SDK documentation, page "Building packages", chapter "Packaging formats, section "tar_git packaging structure", second paragraph
• In one of Fedora's many RPM documentation locations: rpmautospec, which provides the %autorelease and %autochangelog RPM macros appears to be what Jolla's tar_git or the SailfishOS-OBS uses.

[Olf0]

The guess in the second bullet point above was wrong, tar_git does not use RPM macros, but does everything on its own:
The shell script's main section calls the function generate_changes, which does a lot, among calling the function do_changelog_block.