gbp-rpm-ch(1)

📦
version 0.9.43 · 6 versions
, in ubuntu stonking

🎀 gbp-rpm-ch 💖

okay bestie, so this is the manpage for gbp-rpm-ch, which lives in the git-buildpackage Manual family, and it's literally the tool that turns your git commit messages into a shiny RPM changelog ✨. It's giving "let the git history write the changelog for you" and honestly? iconic.

💅 NAME 💅

gbp-rpm-ch; — Generate the RPM changelog from git commit messages 🦋

🌸 SYNOPSIS 🌸

gbp rpm-ch [--version] [--help] [--verbose] [--color=[auto|on|off]]
           [--color-scheme= COLOR_SCHEME] [--tmp-dir= DIRECTORY]
           [--vendor= VENDOR] [--packaging-branch= BRANCH-NAME]
           [--packaging-tag= TAG-FORMAT] [--ignore-branch]
           [--packaging-dir= DIRECTORY] [--changelog-file= FILEPATH]
           [--spec-file= FILEPATH] [--since= COMMIT-ISH] [--no-release]
           [--[no-]git-author] [--[no-]full] [--id-length= NUMBER]
           [--ignore-regex= REGEX] [--changelog-revision= REV-FORMAT]
           [--git-log= GIT-LOG-OPTIONS]
           [--spawn-editor=[always|release|no]] [--editor-cmd= EDITOR]
           [--customizations= CUSTOMIZATION-FILE] [PATH1 PATH2]

🫶 DESCRIPTION 🫶

So gbp rpm-ch reads git commit messages all the way up to the current tip of the current branch, and then it updates the RPM changelog from them. That's it, that's the whole vibe. No cap 🧚

By default, gbp rpm-ch tries to guess the last Git commit that got documented in the changelog. Which is cute of it. But if you wanna be the main character and decide yourself, you've got options:

  • --since tells gbp rpm-ch exactly where it should start in the Git history 👑
  • --all makes it use all commits from the Git history (yes, all of them, no survivors 💀)

You can also pass extra path arguments to restrict which repository paths gbp rpm-ch even looks at. And if you want even more detailed control? Use --git-log to restrict the generated changelog entries further. Like, for example, --git-log="--author=Foo Bar" — that's the move 🔥

✨ OPTIONS ✨

  • --version — Print the version of the program, i.e. the version of the git-buildpackage suite. Say hi to your build tooling 💖
  • -v, --verbose — Verbose execution. She tells you everything she's doing, lowkey oversharing, we love that.
  • -h, --help — Print help and exit. When in doubt, ask for help bestie 🥺
  • --color=[auto|on|off] — Whether to use colored output. Pick your aesthetic 🌈
  • --color-scheme=COLOR_SCHEME — The colors to use in output (when color is enabled, obvi). The format for COLOR_SCHEME is '<debug>:<info>:<warning>:<error>'. Numerical values and color names are both accepted, and empty fields imply the default color. For example, --git-color-scheme='cyan:34::' would show debug messages in cyan, info messages in blue, and other messages in the default color (i.e. warning and error messages in red). So aesthetic, so organized ✨
  • --git-tmp-dir=DIRECTORY — Base directory under which temporary directories are created. A home for the lil temp gworls 🏠
  • --vendor=VENDOR — Distribution vendor name.
  • --packaging-branch=BRANCH-NAME — The branch in the Git repository the package is being developed on. Default is master. (the classic 👵)
  • --ignore-branch — Don't check if the current branch matches PACKAGING-BRANCH. Live your truth, no questions asked 💅
  • --packaging-tag=TAG-FORMAT — Tag format used when tagging releases. Default is %(vendor)s/%(version)s.
  • --packaging-dir=DIRECTORY — Subdirectory that contains the RPM packaging files.
  • --changelog-file=FILEPATH — Relative path to the changelog file to use. The special value auto causes gbp to guess, SPEC uses the spec file, and CHANGES uses a separate changelog file (the name is derived from the spec file name with the .spec suffix replaced by .changes). The guessing logic is simple, babes: use the separate changelog file if it is found, otherwise use the spec file. That's it 🎀
  • --spec-file=FILEPATH — Relative path to the spec file to use. The special value auto causes gbp to search and guess. Other values cause the --packaging-dir option to be ignored — the directory of the spec file is used instead. Note the tradeoff bestie 👀
  • --since=COMMIT-ISH — Start reading commit messages at COMMIT-ISH.
  • --no-release — Do not create a new changelog section, just update the last changelog section. Sometimes you just wanna touch up the last one, and that's valid 🫶
  • --[no-]full — Include the full commit message in the changelog output.
  • --git-log=GIT-LOG-OPTIONS — Options passed on verbatim to git-log(1). Verbatim. She doesn't touch them, she just forwards them, like a good friend 💜
  • --id-length=N — Include N digits of the commit id in the changelog entry. Default is to not include any commit ids at all. Minimalist queen.
  • --ignore-regex=REGEX — Ignore lines in commit message matching REGEX when generating the changelog.
  • --changelog-revision=REV-FORMAT — Format string to use for the revision field in the changelog header. The following string fields are accepted:
    • %(upstreamversion)s — the upstream version
    • %(release)s — the rpm patchlevel, i.e. Release
    • %(version)s — full rpm package version
    • %(tagname)s — tag/commit, i.e. basically what git-describe would give

If empty or not defined, the default from packaging policy is used. Let the policy decide, she knows what's best ✨

  • --ignore-regex=REGEX — Ignore commit lines matching REGEX when generating the changelog. (yes, she's listed twice, both are real, both get listed, we don't erase the twins 🫶)
  • --[no-]git-author — Use user.name and user.email from git-config(1) for the changelog header.
  • --spawn-editor=[always|release|no] — Whether to spawn an editor: always, when doing a release, or no — never. Pick your adventure 🌸
  • --editor-cmd=EDITOR — The editor to use for editing the changelog. Who's your chosen one? 💖
  • --customizations=CUSTOMIZATION-FILE — Load Python code from CUSTOMIZATION-FILE. At the moment, the only useful thing the code can do is define a custom ChangelogEntryFormatter class. Very niche, very powerful, very her 💅

👑 META TAGS 👑

Additional to all the above options, the formatting of the new changelog entries (one-per-commit) in the changelog can be modified by special tags called Meta Tags, which you put right in the git commit message. Spicy but legal 🌶️

The tags must start at the first column of a commit message, but they can appear on any line. They are of the form Tagname: VALUE. Valid Meta Tags are:

  • Git-Rpm-Ch: ACTION — Supported actions are:
    • Ignore, which will ignore this commit when generating new changelog entries 🙈
    • Short, which will only use the description (the first line) of the commit message when generating the changelog entry (useful when --full is given)
    • Full, which will use the full commit message when generating the changelog entry (useful when --full is not given)
  • [Close|Closes|...]: BUGNUMBER — Indicate in the changelog entry that bug BUGNUMBER was addressed in this commit. Close that bug bestie, you ate 🐛✨

So like, the following git commit message:

Document meta tags

so one doesn't have to consult the manual

Git-Rpm-Ch: Short
Closes: #636088

Results in this changelog entry:

- Document meta tags (Closes: #636088)

See?? The way that it just works 😭💖

🌈 CONFIGURATION FILES 🌈

Several gbp.conf files are parsed to set defaults for the above command-line arguments. See the gbp.conf(5) manpage for all the deets, because that's a whole other story 🍓

🦋 SEE ALSO 🦋

gbp-buildpackage-rpm(1), gbp-import-srpm(1), gbp.conf(5), debuild(1), git(1), pristine-tar(1), The Git-Buildpackage Manual ⟨file:///usr/share/doc/git-buildpackage/manual-html/index.html⟩ Cl2vcs ⟨https://honk.sigxcpu.org/cl2vcs⟩ ,

Go read them, they're all in the friend group 🫶

💜 AUTHOR 💜

Markus Lehtonen <markus.lehtonen@linux.intel.com> — ty for your service king 👑

okay so that's literally it bestie ✨ this whole page was written up on 26 May 2026, it's part of the git-buildpackage Manual, and it's page gbp-rpm-ch(1) of that vibe. now go generate some changelogs, you're gonna slay 💅🎀💖

📦 where this page comes from