Page MenuHomePureOS Tracker

Building Packages With Git-buildpackage
Updated 75 Days AgoPublic

The goal is to have a standardized, repeatable way to build packages via the git distributed version source control tool. Inspired by DEP-14


Git buildpackage, or gbp for short, is a tool to maintain Debian packages via git. Using git as the distributed version control system to store the data as well as packaging meta-data means that packages can be built directly from a git repository.

This page is dedicated to the use of gbp in PureOS but it should be applicable in any Debian-based distro.


General packaging prerequisites;

sudo apt install build-essential devscripts

On PureOS, gbp is installed via this command;

sudo apt install git-buildpackage


If you're not familiar with Debian packaging it's likely a good idea to mention some terms we use in this document. Gbp builds packages from git branches. The branches used refer to specific artifacts, like the upstream tarball. The terms we'll refer to are;

pristine tarballthe untouched source code stored as a binary tar archive.
upstreambranch that usually stores the upstream source code
debbinary archive containing executable

Packaging workflow

The following is an example of rebasing a package from our Debian upstream. It needs to be elaborated upon but can serve as an example.

# once after cloning forked source 
git remote add salsa 

# repeat for each rebasing 
git pull origin 
git fetch salsa 
git reset --hard debian/$NEW 
git cherry-pick debian/${OLD}..pureos/${OLD}pureos1~3 
dch --local pureos . && gbp dch -a && dch --vendor pureos --distribution amber --release 
$EDITOR debian/patches/series # remove all pre-applied Debian patches 
quilt push -a 
rm -rf .pc 
git add -A 
git reset HEAD debian 
git commit -m "Pre-apply patches." 
git checkout -- debian/patches/series debian/rules debian/control TESTDIR= 
git commit -m "Prepare for release: Update changelog, and control file." -a gbp tag 
git merge --strategy ours --allow-unrelated-histories -m "Fake-merge previous PureOS fork." origin/pureos/esr60/master

Pristine tar

In our example, we'll use tar to create a pristine tarball.

tar cvfJ stream-0.1.0.orig.tar.xz --exclude-vcs Stream/

Build package

$ git-buildpackage --

PureOS specific requriements

Maintainer:  Cool Package Maintainers <>

it should be changed to:

Maintainer: PureOS Maintainers <>
XSBC-Original-Maintainer: Cool Package Maintainers  <>

Note that the Uploaders: field remains untouched.

Version Control System fields

In addition to the maintainer address, please make sure to fill in the Vcs-Browser and Vcs-Git fields. This allows one to correlate releases with source code and is also required.

The original Vcs-* fields should be retained as XSBC-Original-Vcs-*:





This help to identify the repository where new Debian versions should be pulled from.

Uploading packages to the package repositories

Uploading via dput

To upload packages to the PureOS archive via the dput tool, use the following ~/ snippet. Please note that your GPG key needs to be in the PureOS Keyring. Currently the policy for getting added to the keyring is ad hoc but a more formal policy is in the works.

fqdn =
method = ftp
incoming = ~/incoming/
login = anonymous

The upload might take about 20 minutes or so to be processed after the upload is fully complete.

See also NEW queue and archive layout

If you want to get notification about any new upload that gets submitted to the archive, consider subscribing to the pureos-changes mailinglist.

Please use source-only uploads (created by passing -S -sa to dpkg-buildpackage, e.g. by using gbp via gbp buildpackage -S -sa) if possible, and only upload binaries directly if absolutely necessary (e.g. for bootstrapping). The autobuild system of the Laniakea archive management system will usually build new packages pretty quickly.

Uploads targeted at the current development release of PureOS (currently byzantium) will automatically be redirected to landing, just like uploads to the *-updates suite of a stable release will automatically go to *-proposed-updates first.

Uploading via git tag

Packages can also be uploaded by tagging them appropriately in git. Have a look at
The flow of a package once accepted by the archive is the same.

Tracing the package after the upload

gitlab-ci example

Last Author
Last Edited
May 21 2021, 07:51

Event Timeline

jeremiah.foster edited the content of this document. (Show Details)Feb 26 2021, 10:24
jeremiah.foster edited the content of this document. (Show Details)Apr 18 2021, 16:57
jeremiah.foster edited the content of this document. (Show Details)Apr 20 2021, 19:57
jeremiah.foster edited the content of this document. (Show Details)
jeremiah.foster edited the content of this document. (Show Details)Apr 26 2021, 11:41
jeremiah.foster edited the content of this document. (Show Details)
jeremiah.foster edited the content of this document. (Show Details)Apr 26 2021, 11:45
jeremiah.foster published a new version of this document.
jeremiah.foster edited the content of this document. (Show Details)May 14 2021, 12:40
jeremiah.foster added a project: Restricted Project.
jeremiah.foster edited the content of this document. (Show Details)May 21 2021, 07:51