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

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 if it's a non C++ library

• 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.

• Add this note to debian/control:

Homepage: https://launchpad.net/[project]
# If you aren't a member of ~[team] but need to upload packaging changes,
# just go ahead.  ~[team] will notice and sync up the code again.
Vcs-Bzr: https://code.launchpad.net/~[team]/[package]/trunk

• Add this line near the top of debian/rules:

export DPKG_GENSYMBOLS_CHECK_LEVEL=4

• 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

• 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

Packaging

• 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)

You can think that <rrrr> may be safely replaced with the bzr commit revision id of the latest release (pushed in ubuntu). However, there is a trap: if you merge the packaging branch inside trunk after the latest release, the automated attribution script will climb that branch (as being done post latest revision) and mark again all the bugs since the entire packaging history, fixed into the last release!

In that case, we just need to set <rrrr> to the revision which merged the packaging in the upstream trunk. If some bugs were fixed since last release before and not backported to ubuntu already, please note them manually in debian/changelog, like:

  * Automatic snapshot from revision 1234 (bootstrap):
    - fixed foo in bar (LP: #42)
    - fixed baz because of stuff (LP: #4242)

And then, get it merged

This is not the last thing! If you have commits not released into ubuntu and had to set the rev to the inline packaging merge revision, ensure that you have (once the automated snapshot message merged in) <bzr tip revision> - <revision set in changelog> >= 2. This is the way the bot is ensuring it has something to release in the next daily run. I'm sure you can find something to do, like merging a branch upstream that was never reviewed, looking for a patch in launchpad that was never merged, adding a .pot file, a small packaging fix… Be creative!

This is only for the bootstrap, then, everything is automated

Setting the component on the stack

• Pester didrocks I'll write the instructions in a document properly later on and edit this

CategoryPackaging