gbp-pq-rpm(1)

📦
version 0.9.43 · 6 versions
, in ubuntu stonking

💖 gbp-pq-rpm(1) — the git-buildpackage manual, but make it make sense 💖

okay bestie, welcome to the gbp-pq-rpm page from the git-buildpackage manual ✨ this one's a whole vibe and also genuinely useful, so grab a boba and let's go 🧋🦋

✨ NAME ✨

gbp-pq-rpm — manage patches and development branches in Git 💅

🌸 SYNOPSIS 🌸

gbp pq-rpm [--version] [--help] [--verbose] [--color=[auto|on|off]]
           [--color-scheme= COLOR_SCHEME] [--packaging-dir= DIRECTORY]
           [--spec-file= FILEPATH] [--upstream-tag= TAG-FORMAT]
           [--abbrev= num] [--force] [--[no-]drop]
           [--[no-]patch-numbers] drop | export | import | rebase |
           switch | apply

🎀 DESCRIPTION 🎀

gbp pq-rpm is your girl for managing patches and development branch(es) for packages that are maintained with gbp. It's designed to be used for packages that are maintained using the "orphan-packaging" model. And like, it's not ONE command, it's a whole girl group: gbp pq-rpm has multiple subcommands, or actions, for working with the branches and patches. 🫶

The way it works: gbp pq-rpm makes it easy to do source code development on a separate development branch (a patch-queue branch in Debian git-buildpackage terms, iykyk). For example, if the packaging files would be stored in master, the associated development branch would be development/master. cute, right? 💖

🔥 ACTIONS 🔥

  • import — Create a development (patch-queue) branch by applying all patches from the packaging branch on top of the upstream version. Lowkey important: the patches must apply without fuzz. no fuzzy business allowed 💀
  • export — Export patches from the development branch into the packaging branch. It generates patches (one-per-commit) from the development branch and updates the spec file accordingly. It doesn't automatically commit the changes though — they need to be verified and committed manually. yes bestie, you gotta look at it with your own eyes 👀
  • rebase — Switch to the development branch and rebase it against the current upstream version (indicated in the spec file of the associated packaging branch). glow-up time ✨
  • drop — Drop (delete) the development branch associated to the current branch. For example, you're on branch foo, this would drop branch development/foo. it's giving... release the past 🦋
  • apply — Add a single patch to the development branch — similar to using git-am. one patch, one moment 🎀
  • switch — Switch between the development branch and the associated packaging branch. back and forth, like your situationship 🔄

💅 OPTIONS 💅

  • --version — Print version of the program, i.e. version of the git-buildpackage suite. show me your credentials bestie 👑
  • -v, --verbose — Verbose execution. it will tell you EVERYTHING 🗣️
  • -h, --help — Print help and exit. when in doubt 🫶
  • --color=[auto|on|off] — Whether to use colored output. rainbow mode: toggled 🌈
  • --color-scheme=COLOR_SCHEME — Colors to use in output (when color is enabled). The format for COLOR_SCHEME is '<debug>:<info>:<warning>:<error>'. Numerical values and color names are accepted, 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 default (i.e. warning and error messages in red). a whole aesthetic, curated 💅
  • --packaging-dir=DIRECTORY — Subdirectory that contains the RPM packaging files. that's where the goods live 📁
  • --spec-file=FILEPATH — Relative path to the spec file to use. 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. so it's either/or, no cap ✋
  • --upstream-tag=TAG-FORMAT — Use this tag format when looking for tags of upstream versions, default is upstream/%(version)s. the default is the default, fr fr ⭐
  • --abbrev=NUM — When exporting a patch queue abbreviate commit, instead of showing the full 40-byte hexadecimal object name in header lines, show only a partial prefix of length NUM. This is useful when existing patches were not generated by gbp pq. short and sweet, slay ✂️
  • --force — Import even if the development (patch-queue) branch already exists. Only valid for the import action. it's giving main character energy, do it anyway 💥
  • --[no-]drop — Whether to drop (delete) the patch queue branch after a successful export. bye girl 👋
  • --[no-]patch-numbers — Whether the patch files should start with a number or not. numbered or unnumbered, you decide 🔢

🧚 META TAGS 🧚

When exporting patches from a patch-queue branch, gbp pq-rpm will look at the commit message for special tags it recognizes. All tags need to start at the first column and require at least one whitespace after the colon. rules are rules bestie 📏

  • Gbp-Rpm: Ignore — Ignores the commit, no patch is generated out of it. ghosted 💀
  • Gbp-Rpm: If <expression> — Conditional patch. Put patch inside "%if <expression>" in the spec file.
  • Gbp-Rpm: IfArch<expression> — Conditional patch. Put patch inside "%ifarch <expression>" in the spec file.

For example, the following commit message:

Fix around a problem in Fedora

which is not applicable elsewhere.

Gbp-Rpm: If 0%{?fedora}

Will result something like this in the spec file:

# 0001-Fix-around-a-problem-in-Fedora.patch
%if 0%{?fedora}
%patch0 -p1
%endif

see? conditional AND cute 🎀

👀 SEE ALSO 👀

gbp-buildpackage-rpm(1), gbp-import-srpm(1), gbp.conf(5)

go read those next, bestie, the lore goes deep 📚

💜 AUTHOR 💜

Markus Lehtonen <markus.lehtonen@linux.intel.com> — thank you for your service, king 🫡

and that's the whole page!! this was gbp-pq-rpm(1) from the git-buildpackage manual, dated 26 May 2026 💖 periodt, you're a patch-queue girlie now 🦋✨🌸

📦 where this page comes from