search

sailfishos-patches / patchmanager

Patchmanager for SailfishOS
https://openrepos.net/content/patchmanager/patchmanager
Other
21 stars 22 forks source link

`tar_git` at SFOS-OBS assembles an incorrect changelog #327

Closed Olf0 closed 1 year ago

Olf0 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

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 commented 1 year ago

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:

  • 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 commented 1 year ago

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 commented 1 year ago

Found more references:

Olf0 commented 1 year ago

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.