Translations by Simon Quigley

Below we are having a look at the ``glib2.0`` source package. In a very simple case the file would look like this::

While the test script can be easily executed on its own, it is strongly recommended to actually use ``autopkgtest`` from the ``autopkgtest`` package for verifying that your test works; otherwise, if it fails in the Ubuntu Continuous Integration (CI) system, it will not land in Ubuntu. This also avoids cluttering your workstation with test packages or test configuration if the test does something more intrusive than the simple example above.

The `README.running-tests <running_tests_local_>`_ (`online version <DEP8_>`_) documentation explains all available testbeds (schroot, LXD, QEMU, etc.) and the most common scenarios how to run your tests with ``autopkgtest``, e. g. with locally built binaries, locally modified tests, etc.

The Ubuntu CI system uses the QEMU runner and runs the tests from the packages in the archive, with ``-proposed`` enabled. To reproduce the exact same environment, first install the necessary packages::

The Ubuntu CI system runs packages with only selected packages from ``-proposed`` available (the package which caused the test to be run); to enable that, run::

or to run with all packages from ``-proposed``::

The ``autopkgtest`` manpage has a lot more valuable information on other testing options.

Further examples

Packages which have ``autopkgtest`` enabled will have their tests run whenever they get uploaded or any of their dependencies change. The output of `automatically run autopkgtest tests <jenkins_>`_ can be viewed on the web and is regularly updated.

Debian also uses ``autopkgtest`` to run package tests, although currently only in schroots, so results may vary a bit. Results and logs can be seen on http://ci.debian.net. So please submit any test fixes or new tests to Debian as well.

Getting the test into Ubuntu

The process of submitting an autopkgtest for a package is largely similar to :doc:`fixing a bug in Ubuntu<./fixing-a-bug>`. Essentially you simply:

run ``bzr branch ubuntu:<packagename>``,

edit ``debian/control`` to enable the tests,

add the ``debian/tests`` directory,

write the ``debian/tests/control`` based on the `DEP 8 Specification <dep8_>`_,

add your test case(s) to ``debian/tests``,

commit your changes, push them to Launchpad, propose a merge and get it reviewed just like any other improvement in a source package.

What you can do

The Ubuntu Engineering team put together a `list of required test-cases <requiredtests_>`_, where packages which need tests are put into different categories. Here you can find examples of these tests and easily assign them to yourself.

If you should run into any problems, you can join the `#ubuntu-quality IRC channel <qualityirc_>`_ to get in touch with developers who can help you.

Backporting software updates

Sometimes you might want to make new functionality available in a stable release which is not connected to a critical bug fix. For these scenarios you have two options: either you `upload to a PPA <ppadoc_>`_ or prepare a backport.

Personal Package Archive (PPA)

Using a PPA has a number of benefits. It is fairly straight-forward, you don't need approval of anyone, but the downside of it is that your users will have to manually enable it. It is a non-standard software source.

The `PPA documentation on Launchpad <ppadoc_>`_ is fairly comprehensive and should get you up and running in no time.

Official Ubuntu Backports

The Backports Project is a means to provide new features to users. Because of the inherent stability risks in backporting packages, users do not get backported packages without some explicit action on their part. This generally makes backports an inappropriate avenue for fixing bugs. If a package in an Ubuntu release has a bug, it should be fixed either through the :doc:`Security Update or the Stable Release Update process<./security-and-stable-release-updates>`, as appropriate.

Once you determined you want a package to be backported to a stable release, you will need to test-build and test it on the given stable release. ``pbuilder-dist`` (in the ``ubuntu-dev-tools`` package) is a very handy tool to do this easily.

To report the backport request and get it processed by the Backporters team, you can use the ``requestbackport`` tool (also in the ``ubuntu-dev-tools`` package). It will determine the intermediate releases that package needs to be backported to, list all reverse-dependencies, and file the backporting request. Also will it include a testing checklist in the bug.

Using Chroots

If you are running one version of Ubuntu but working on packages for another versions you can create the environment of the other version with a ``chroot``.

A ``chroot`` allows you to have a full filesystem from another distribution which you can work in quite normally. It avoids the overhead of running a full virtual machine.

Creating a Chroot

Use the command ``debootstrap`` to create a new chroot::

This will create a directory ``trusty`` and install a minimal trusty system into it.

If your version of ``debootstrap`` does not know about Trusty you can try upgrading to the version in ``backports``.

You can then work inside the chroot::

Where you can install or remove any package you wish without affecting your main system.

You might want to copy your GPG/ssh keys and Bazaar configuration into the chroot so you can access and sign packages directly::

To stop apt and other programs complaining about missing locales you can install your relevant language pack::

If you want to run X programs you will need to bind the /tmp directory into the chroot, from outside the chroot run::

Some programs may need you to bind /dev or /proc.

For more information on chroots see our `Debootstrap Chroot wiki page <DebootstrapChroot_>`_.

Alternatives

SBuild is a system similar to PBuilder for creating an environment to run test package builds in. It closer matches that used by Launchpad for building packages but takes some more setup compared to PBuilder. See `the Security Team Build Environment wiki page <SecurityEnv_>`_ for a full explanation.

Full virtual machines can be useful for packaging and testing programs. TestDrive is a program to automate syncing and running daily ISO images, see `the TestDrive wiki page <TestDrive_>`_ for more information.

You can also set up pbuilder to pause when it comes across a build failure. Copy C10shell from /usr/share/doc/pbuilder/examples into a directory and use the ``--hookdir=`` argument to point to it.

Amazon's `EC2 cloud computers <EC2_>`_ allow you to hire a computer paying a few US cents per hour, you can set up Ubuntu machines of any supported version and package on those. This is useful when you want to compile many packages at the same time or to overcome bandwidth restraints.

Communication in Ubuntu Development