Building Packages With Git-buildpackage
The goal is to have a standardized, repeatable way to build packages via the git distributed version source control tool. Inspired by DEP-14
Description
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.
Installation
General packaging prerequisites;
sudo apt install build-essential devscripts
On PureOS, gbp is installed via this command;
sudo apt install git-buildpackage
Terminology
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;
Term | Meaning |
pristine tarball | the untouched source code stored as a binary tar archive. |
upstream | branch that usually stores the upstream source code |
deb | binary 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.
shell # once after cloning forked source git remote add salsa https://salsa.debian.org/mozilla-team/firefox.git # 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 --exclude-vcs --create --verbose --xz --file stream-0.1.0.orig.tar.xz Stream/
Build package
$ git-buildpackage --
PureOS specific requriements
Maintainer: Cool Package Maintainers <team-pkg@example.com>
it should be changed to:
Maintainer: PureOS Maintainers <pureos-project@lists.puri.sm> XSBC-Original-Maintainer: Cool Package Maintainers <team-pkg@example.com>
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-*:
Example:
Vcs-Git: https://salsa.debian.org/gnome-team/gnome-control-center.git Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-control-center
becomes:
Vcs-Git: https://source.puri.sm/pureos/packages/gnome-control-center.git Vcs-Browser: https://source.puri.sm/pureos/packages/gnome-control-center XSBC-Original-Vcs-Git: https://salsa.debian.org/gnome-team/gnome-control-center.git XSBC-Original-Vcs-Browser: https://salsa.debian.org/gnome-team/gnome-control-center
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 ~/.dput.cf 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.
[pureos-ftp] fqdn = upload.pureos.net 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 https://source.puri.sm/snippets/138
The flow of a package once accepted by the archive is the same.
Tracing the package after the upload
- If the package didn't have any version in the archive before it will be held in NEW Queue
- If the package gets accepted a mail is sent to the pureos-changes mailing list
- In case of a source package a build for the binary packages will be scheduled and put to the end of the build queue.
- If the package got built successfully it will wait for migration
- The status of a package in a certain suite (including build logs can queried via https://software.pureos.net/package/src/<suite>/<sourcepackage>. Example: phosh's status in byzantium: https://software.pureos.net/package/src/byzantium/phosh
- Once the (suite dependent) migration period passes it will migrate to the target suite. The ultimate reference if a package is in a suite is the archive's package file at e.g. https://repo.pureos.net/pureos/dists/byzantium/main/binary-arm64/Packages.xz for arm64 packages in byzantium.
gitlab-ci example
- Last Author
- jeremiah.foster
- Last Edited
- Sep 7 2021, 08:47