||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||

This page is part of the [[DailyRelease|daily release process documentation]]

= Prepare for autolanding =

== Packaging checklist ==

 * 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.:
{{{
Homepage: https://somehomepage.com/important-user-information
}}}

----

 * 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:

{{{
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
}}}

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
}}}

----

 * Configure for split building:

{{{
mkdir -p .bzr-builddeb
cat >.bzr-builddeb/default.conf <<EOF
[BUILDDEB]
split = True
EOF
}}}

 * 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)
}}}

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

----
CategoryPackaging