Packaging Overview
Updated 21 Days AgoPublic


To build packages, install the devscripts package: sudo apt install devscripts, which contains a lot of useful helpers for building Debian packages.
Having gbp available is also a good idea: sudo apt install git-buildpackage

Building packages

All packages have to be built in a pristine PureOS landing chroot before being uploaded to PureOS. The preferred method to do that is by using pbuilder. There is documentation on setting up a pbuilder environment using PureOS.
For packages not managed in Git, pbuilder can be invoked via

DIST=landing pdebuild --auto-debsign

For Git-managed packages, gbp provides options to build with pbuilder directly. Alternatively, pdebuild can be passed in like gbp buildpackage --git-builder='DIST=landing pdebuild --auto-debsign'

Don't forget to set your own email address for the Git repository, via git config

Lastly, make sure you set the right distribution, in this case 'green'.

Version numbers

Packages which are available on Debian and are changed in PureOS have a pureosX version tag attached to the Debian revision, with X being the PureOS revision number. So, if the package's upstream version is 2.1, it's Debian revision is 2 (creating the Debian version string 2.1-2) and you make a change for PureOS, the resulting package version must be 2.1-2pureos1. The PureOS revsion is incremented with every change, so the next version would be 2.1-2pureos2.

If the package isn't in Debian, the Debian revision number is assumed to be zero and all other rules from above still apply. So, and upstream package with version 3.4 which is new in PureOS will get the initial version 3.4-0pureos1.

If you do not do any source changes but just rebuild a package, bX is appended to the revision. So, a package of version 1.0-3 gets the new version 1.0-3b1 if it is rebuilt. The rebuild version is incremented on every subsequent rebuild.

If the archive rejects an upload because a +bX version number exists, then this is because of a binary package sync from Debian where the package was binNMUd before. In this particular case, please upload the package again, but append a + before the PureOS version, so 1.0-1pureos1 becomes 1.0-1+pureos1.

Paying attention to the version numbers is important, because the PureOS archive tools will use the version number to make decisions about the package's state, which includes overriding it with a version from Debian or even removing it.
Using the right version number will make the archive do the right thing.

You might be able to use dch --distribution=landing --force-distribution --no-auto-nmu --local=pureos as a starting point.

Validating packages

Use lintian --profile=pureos -IE --pedantic <changes-file> to check a package for compliance with the Debian policy. Ensure it is warning and error-free.

If your Lintian is old and does not support the pureos profile, all warnings related to NMUs and invalid suites can be ignored, as those are different or don't exist in PureOS. (See

Maintainer address

If you change the maintainer address in a Debian package you modify, please use PureOS Maintainers <>. You don't actually need to change the maintainer address (it is a bit nicer though). In any case, you don't need to add yourself as uploader, since all packages in PureOS are team maintained - the Lintian error for that is something we might need to change.

Closing bugs

To close bugs in the PureOS tracker with an upload, use either the PB: #<nnn> or PureOS: #<nnn> syntax in debian/changelog, with <nnn> being replaced with the number of the respective task in Maniphest on tracker.p.n (with the T prefix stripped).

At the moment, the service that automatically closes reports is not active, due to maintenance (the previous implementation had a few bugs and was very slow), so for now you will need to close bugs manually. However, for some packages the bug information is still used to e.g. determine package migration speed.

Uploading packages

See the document on Development/Uploading Packages

Last Author
  • Restricted Project