Scroll to navigation

gbp-import-srpm(1) git-buildpackage Manual gbp-import-srpm(1)

NAME

gbp-import-srpm - Import source RPM packages into a Git repository

SYNOPSIS


gbp import-srpm
[--version] [--help] [--verbose] [--color=[auto|on|off]] [--color-scheme= COLOR_SCHEME] [--vendor= VENDOR] [--allow-same-versions] [--author-is-committer] [--packaging-branch= BRANCH-NAME] [--packaging-tag= TAG-FORMAT] [--skip-packaging-tag] [--packaging-dir= DIRECTORY] [--filter= PATTERN] [--keyid= GPG-KEYID] [--[no-]create-missing-branches] [--[no-]pristine-tar] [--[no-]sign-tags] [--upstream-branch= BRANCH-NAME] [--upstream-tag= TAG-FORMAT] [--upstream-vcs-tag= TAG-FORMAT] [--native] [--repo-user= [GIT|DEBIAN]] [--repo-email= [GIT|DEBIAN]] SRPM | DIRECTORY [target]

gbp import-srpm
[options] URL [target]

DESCRIPTION

gbp import-srpm imports an RPM source package into a Git repository, notes the package version in the commit logs, and commits the change. All information, including package name, version and upstream source is automatically detected from the source package but you can override the location of the new repository by optionally specifying the target argument. The tool supports importing both archived (src.rpm files) or unpacked (directory) source RPMs. It also imports from http(s)-URLs.

OPTIONS

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).
Distribution vendor name.
The branch in the Git repository the upstream sources are put onto. Default is upstream.
The branch in the Git repository the packaging files are put onto. Default is master.
--[no-]sign-tags
GPG sign all created tags.
Use this keyid for gpg signing tags.
Use this tag format when tagging released versions, default is %(vendor)s/%(version)s.
Do not create packaging tag after importing the packaging files.
Use this tag format when tagging upstream versions, default is upstream/%(version)s.
Add TAG-FORMAT as an additional parent of the commit of the upstream tarball. Useful when upstream uses git and you want to link to its revision history. TAG-FORMAT can be a pattern similar to what --upstream-tag supports.
Subdirectory where to put the RPM packaging files.
Filter out files glob-matching pattern. Can be given multiple times.
Generate pristine-tar delta file.
Allow one to re-import a package with an already existing version. This will not re-import the upstream sources - only packaging files will be re-imported.
Use the author identity as the committer when importing upstream sources and packaging files.
--[no-]create-missing-branches
Create missing upstream and/or packaging branch if missing.
Import packaging files into an orphan branch that will not be based on the upstream branch. Useful if you want to maintain (non-native) package using the 'orphan-packaging' model. This option have no effect if --native is used.
Treat the package as native package. No separate upstream branch or upstream tags will be created.
When set to DEBIAN use the DEBUSER environment variable to set the user.name Git configuration otherwise use Git's defaults. Only affects newly created repos.
When set to DEBIAN use the DEBEMAIL environment variable to set the user.email Git configuration otherwise use Git's defaults. Only affects newly created repos.

CONFIGURATION FILES

Several gbp.conf files are parsed to set defaults for the above command-line arguments. See the gbp.conf(5) manpage for details.

SEE ALSO

gbp-buildpackage-rpm(1), gbp-pq-rpm(1), gbp-rpm-ch(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⟩

AUTHOR

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

1 February 2021