Change Details

= Prerequisites = 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. 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'` = 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. 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.

= Prerequisites = 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. 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'` = 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. 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 https://bugs.debian.org/884408)

= Prerequisites = 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. 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'` = 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. 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 https://bugs.debian.org/884408)