Translations by Dmitry Shachnev

It is also possible to use your normal tools, as long as they are able to strip the .bzr directories from the package, e.g.::

Now that we have the source package, we need to patch it to fix the vulnerability. You may use whatever patch method that is appropriate for the package, including :doc:`UDD techniques<./udd-intro>`, but this example will use ``edit-patch`` (from the ubuntu-dev-tools package). ``edit-patch`` is the easiest way to patch packages and it is basically a wrapper around every other patch system you can imagine.

You should start by ensuring no patches are applied. Unfortunately a commit is needed before you can merge in the new upstream (this is `bug 815854`_)::

`Work-Needing and Prospective Packages`_ - Information on how to file "Intent to Package" and "Request for Package" bugs as well as list of open ITPs and RFPs.

Now that we have the source package, we need to patch it to fix the vulnerability. You may use whatever patch method that is appropriate for the package, including :doc:`UDD techniques<./udd-intro>`, but this example will use ``edit-patch`` (from the ubuntu-dev-tools package). ``edit-patch`` is the easiest way to patch packages and it is basically a wrapper around every other patch system you can imagine.

This would use the source package in ``/tmp/glib2.0-2.35.7/`` and run the tests from this tree against the package ``glib2.0`` from the archive. The option ``-S`` also supports schemes for bzr, git, and apt sources. If you only specify a source with ``-S`` but do not specify a package name, this will instead build the branch and install the binaries from that build; this is useful if you want to run tests on a newer version than the one packaged in Ubuntu, or the package is not in Ubuntu at all. If use the ``-k`` flag you can log into the virtual machine after the tests were run. This makes it very easy to debug issues.

You can ask for reviews in ``#ubuntu-motu`` IRC channel, or on the `MOTU mailing list`_. There might also be a more specific team you could ask such as the GNU team for more specific questions.

Even if it builds the .deb binary package, your packaging may have bugs. Many errors can be automatically detected by our tool ``lintian`` which can be run on both the source .dsc metadata file and the .deb binary package::

Once you've got a local branch of the source package, you can investigate the bug, create a fix, and upload your proposed fix to Launchpad, in the form of a Bazaar branch. When you are happy with your fix, you can :ref:`submit a merge proposal <merge-proposal>`, which asks other Ubuntu developers to review and approve your change. If they agree with your changes, an Ubuntu developer will upload the new version of the package to Ubuntu so that everyone gets the benefit of your excellent fix - and you get a little bit of credit. You're now on your way to becoming an Ubuntu developer!

Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it. In Ubuntu Distributed Development this is done by :ref:`branching the source package <branching>` branch corresponding to the source package. Launchpad maintains source package branches for all the packages in Ubuntu.

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 <https://help.launchpad.net/Packaging/PPA>`_ or prepare a backport.

You need one last step to get your changes uploaded into Ubuntu or your PPA; you need to ``dput`` the source package to the appropriate location. For example, if you want to upload your changes to your PPA, you'd do::

The `merge-upstream` command will either tell you that it completed successfully, or that there were conflicts. Either way you will be able to review the changes before committing as normal.

`Debian Mentors FAQ`_ - debian-mentors is for the mentoring of new and prospective Debian Developers. It is where you can find a sponsor to upload your package to the archive.

See :doc:`uploading<./udd-uploading>` for more information.

``.la`` libtool files are needed on some non-Linux systems with poor library support but usually cause more problems than they solve on Debian systems. It is a current `Debian goal to remove .la files`_ and we should help with this.

a better idea of how to join our community,

your development environment set up correctly,

Library symbols are tracked in ``.symbols`` files to ensure none go missing for new releases. KDE uses C++ libraries which act a little differently compared to C libraries. Debian's Qt/KDE Team have scripts to handle this. See `Working with symbols files`_ for how to create and keep these files up to date.

We'll describe specifics on how to branch the code, push your fix, and request a review in the following sections.

Welcome to the Ubuntu Packaging and Development Guide! This is the official place for learning all about Ubuntu Development and packaging. After reading this guide you will have:

fixed an actual Ubuntu bug as part of the tutorials.

Don't worry though, the `Ubuntu development release wiki page <https://wiki.ubuntu.com/UsingDevelopmentReleases>`_ shows a variety of ways to safely use the development release.

heard about the most important players, processes and tools in Ubuntu development,

To push it to Launchpad, as the remote branch name, you need to stick to the following nomenclature::

If the problem is just in Ubuntu, you might want to consider :doc:`Seeking Review and Sponsorship<./udd-sponsorship>` to get the fix included.

Getting the fix included

Committing the fix

In our case we established that we have a problem with the packaging, both in Ubuntu and Debian. As Ubuntu is based on Debian, we will send the fix to Debian. Once it is included there, it will be picked up by Ubuntu eventually. The issue in our tutorial is clearly non-critical, so this approach makes sense. If it is important to fix the issue as soon as possible, you will need to send the solution to multiple bug trackers. Provided the issue affects all parties in question.

It makes to get fix included as Upstream as possible. Doing that you can guarantee that everybody can take the Upstream source as-is and don't need to have local modifications to fix it.

This file gives the copyright information for both the upstream source and the packaging. Ubuntu and `Debian Policy (Section 12.5) <http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile>`_ require that each package installs a verbatim copy of its copyright and license information to ``/usr/share/doc/$(package_name)/copyright``.

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`_ for a full explanation.

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 <https://help.launchpad.net/Packaging/PPA>`_ or prepare a backport.

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

While Debian does not have an automatic testing infrastructure set up yet, they should still be submitted to Debian, as DEP-8 is a Debian specification and Debian developers or users can still manually run the tests.

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

The `libxml2 tests`_ are very similar. They also run a test-build of a simple piece of C code and execute it.

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

The `gvfs tests`_ have comprehensive testing of their functionality and are very interesting because they emulate usage of CDs, Samba, DAV and other bits.

Packages in Debian with a testsuite header will also be automatically added when they are synced to Ubuntu.

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

The `auto-package-testing documentation`_ has a lot more valuable information on other testing options.

The downside of this approach is that you test it locally, but can't ensure that this will work in a minimal environment. For example will it be hard to ensure that all the required packages are installed for the tests. With `lp:auto-package-testing`_ we have a more comprehensive testing tool. It uses a pristine virtual machine to run the tests. To set it up, firstly install the needed dependencies::

In the `ubiquity tests`_ the upstream test-suite is executed.

The test script can be easily executed on its own, but if you want to make sure that the testbed is properly set up, you might want to use ``adt-run`` from the ``autopkgtest`` package to execute the test. The easiest way to do this is to run this command in the source tree::

While this test is very small and basic, it tests quite a number of core components on a system. This may help to uncover critical issues early on.

In ``debian/tests/control`` you specify what to expect from the testbed. So for example you list all the required packages for the tests, if the testbed gets broken during the build or if ``root`` permissions are required. The `DEP 8 specification`_ lists all available options.

The `DEP 8 specification`_ defines how automatic testing can very easily be integrated into packages. To integrate a test into a package, all you need to do is:

add the following to the Source section in ``debian/control``::

If your package works only with Python 2.x or 3.x, build depend only on one ``-all`` package and use only one ``-Version`` field.