DOKK / manpages / debian 11 / git-buildpackage-rpm / gbp-pq-rpm.1.en
gbp-pq-rpm(1) git-buildpackage Manual gbp-pq-rpm(1)

gbp-pq-rpm - Manage patches and development branches in Git


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

gbp pq-rpm helps in managing patches and development branch(es) for packages that are maintained with gbp. It designed to be used for packages that are maintained using the "orphan-packaging" model. gbp pq-rpm has multiple subcommands, or actions, for working with the branches and patches.

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

Create a development (patch-queue) branch by applying all patches from the packaging branch on top of the upstream version. The patches must apply without fuzz.
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 verified and committed manually.
Switch to the development branch and rebase it against the current upstream version (indicated in the spec file of the associated packaging branch).
Drop (delete) the development branch associated to the current branch. For example, you're on branch foo this would drop branch development/foo.
Add a single patch to the development branch - similar to using git-am.
Switch between the development branch and the associated packaging branch.

Print version of the program, i.e. version of the git-buildpackage suite
Verbose execution
Print help and exit
Whether to use colored output.
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).
Subdirectory that contains the RPM packaging files.
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.
Use this tag format when looking for tags of upstream versions, default is upstream/%(version)s.
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.
Import even if the development (patch-queue) branch already exists. Only valid for the import action.
--[no-]drop
Whether to drop (delete) the patch queue branch after a successful export.
--[no-]patch-numbers
Whether the patch files should start with a number or not.

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.

Ignores the commit, no patch is generated out of it.
Conditional patch. Put patch inside "%if <expression>" in the spec file.
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

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

Markus Lehtonen <markus.lehtonen@linux.intel.com>

1 February 2021