This page is part of the daily release process documentation
Prepare for autolanding
Package inlining checklist
- Download the trunk branch and the packaging branch. Here's a little script I use to speed this up:
1 #!/bin/bash 2 3 package=$(basename $PWD) 4 5 echo 'Branching trunk...' 6 bzr branch lp:$package 7 mv $package trunk 8 9 echo 'Branching packaging...' 10 bzr branch ubuntu:$package 11 mv $package packaging 12 13 echo 'Copying debian/ from packaging to trunk...' 14 cp -r packaging/debian trunk/ 15 16 echo 'Creating .bzr-builddeb/default.conf' 17 mkdir -p trunk/.bzr-builddeb 18 cat >trunk/.bzr-builddeb/default.conf <<EOF 19 [BUILDDEB] 20 split = True 21 EOF 22
So I have this script saved as the file ~/Packages/get-package.sh and I would typically invoke it like this:
$ cd ~/Packages $ mkdir [project] $ cd [project] $ ../get-package.sh
Note that some people are merging the packaging branch into the upstream trunk. Both have pros and cons. I'm not attached to any particular form as debian/changelog is already the history of a package. But before merging, you should revert all generated files (modified or new).
HOWEVER (see what happened with appmenu-gtk). You should checked that modified file directly into the packaging vcs are ported (if relevant) to the upstream VCS. Some have inline patches due to bzr merge-upstream workflow, and we shouldn't miss any. Do not complete the bootstrap before this task is done.
- Drop all quilt patches. They should typically already be merged 'upstream' and can safely be deleted, but otherwise you might have to check that they are not still relevant.
$ rm -rf debian/patches debian/source
(if there is a quilt patch and it actually applies cleanly, then you'll need to apply it and commit the change separately from the package inlining commit).
Check about copyright attribution.
- Drop the watch file, since there are no longer any 'releases' to watch for.
$ rm -rf debian/watch
- Ensure debian/changelog is at the latest possible revision from the current devel release (that we didn't miss any version not committed to the package Vcs before).
- Ensure that we have a symbol file. C++ symbol files should use demarshalling to be readable.
- Wrap and sort. Makes things a ton easier to read. This tool turfs comments stupidly, so do it before adding the comments in the next step.
$ wrap-and-sort -a -t
The -t option is a recent addition which will add a trailing-coma on the last dependency.
debian/compat should be '9' and debian/control should have 'debhelper (>= 9),' somewhere in it's build dependencies.
- If a real Homepage exist list it in control, e.g.:
- Add Vcs-Bzr to debian/control, preferably a stable URL, so lp:project-name is preferred over lp:~team-name/project-name/trunk-name
# if you don't have have commit access to this branch but would like to upload # directly to Ubuntu, don't worry: your changes will be merged back into the # upstream branch Vcs-Bzr: lp:[project-name]
- Priority should be set to "optional" by default.
- Add this line near the top of debian/rules:
- If your package uses autotools, you should Build-Depend on dh-autoreconf and add the following to debian/rules:
%: dh $@ --with autoreconf override_dh_autoreconf: NOCONFIGURE=1 dh_autoreconf ./autogen.sh
- Also, debian/rules should contain some variation of the following:
override_dh_install: dh_install --fail-missing
The current recommended way of doing it is adding --fail-missing to the main dh command, for instance something like this:
%: dh $@ --with autoreconf --fail-missing
- If you find something like this in debian/rules, take it out:
# Act differently if this is a native (daily) build or not. ifneq ($(wildcard autogen.sh),) DEB_BUILD_OPTIONS += nostrip endif
- Bump the version number one minor version, a la x.y.z+1-0ubuntu1
$ dch -i
- Add the changes to bazaar:
$ bzr add .bzr-builddeb debian/
- Make sure stuff builds:
$ bzr bd
Fix any errors you may discover.
- Use pbuilder to be extra-sure that the build will succeed in production.
$ cd .. $ pbuilder-dist raring *dsc
Fix any errors you may discover.
- Commit and push.
$ bzr commit $ bzr push lp:~/[project]/inline-packaging
Then submit your merge proposal and pester (bribing also works) didrocks to review it
Getting it ready for autolanding
Once we have a package that we think is ready for autolanding, there is some checks needed:
- Is the unit test suite strong enough so that we ensure we can't regress easily (and automatically ;)) ubuntu? Those tests need to be run in the packaging.
- If there are integration tests, is there something like autopilot that we can run on an installed system to automate this run at each landing?
- Is debian/changelog still at the latest version in the branch?
If you answered yes to all those questions, congrats! let's get it automatically landing then
- We need a boostrap commit to know where to start from. The system is then going from bzr tip until that revision to grab all bugs fixed and create a proper changelog with attribution. The form is:
* Automatic snapshot from revision <rrrr> (bootstrap)
<rrrr> can be safely replaced with the bzr commit revision id of the latest release (pushed in ubuntu). This is only for the bootstrap, then, everything is automated. If you don't put it, revision 1 will be taken as a reference.
Setting the component on the stack
Pester didrocks I'll write the instructions in a document properly later on and edit this