Translations by Kentaro Kazuhama

Note: Since Ubuntu 11.10 "Oneiric Ocelot" (or if you have Backports enabled on a currently supported release), the following command will install the above and other tools which are quite common in Ubuntu development::

This guide focuses on the Ubuntu Distributed Development packaging method. This is a new way of packaging which uses Distributed Revision Control branches. It currently has some limitations which mean many teams in Ubuntu use :doc:`traditional packaging<./traditional-packaging>` methods. See the :doc:`UDD Introduction<./udd-intro>` page for an introduction to the differences.

a better idea of how to join our community,

your development environment set up correctly,

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

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.

If you already have a branch where you are working on the package and you would like to include their changes, then simply run the ``bzr merge`` from that branch, instead of the checkout of the development package. You can then make the changes and commit, and then carry on with your changes to the package.

If you are going to sponsor someone's work, but you would like to roll it up with some changes of your own then you can merge their work in to a separate branch first.

You can do this if you notice something needs more work, or if you would like to ask the contributor to fix up conflicts when sponsoring something.

If there are lots of merge conflicts you would probably want to ask the contributor to fix them up. See the next section to learn how to cancel a pending merge.

When you're finally happy with your branch, make sure you've committed all your changes, then tag the branch with the changelog's version number. The ``bzr tag`` command will do this for you automatically when given no arguments::

This pulls in any changes that may have been committed while you were working on your fix. From here, you have several options. If the changes on the trunk are large and you feel should be tested along with your change you can merge them into your bug fix branch and test there. If not, then you can carry on merging your bug fix branch into the development trunk branch. As of bzr 2.5 and bzr-builddeb 2.8.1, this works with just the standard ``merge`` command::

At any time before you `dput` the source package you can decide to cancel an upload and revert the changes::

Sponsoring something and making your own changes

Sponsoring someone else's change is just like the above procedure, but instead of merging from a branch you created, you merge from the branch in the merge proposal::

You are now free to delete your feature branch, as it is merged, and can be re-downloaded from Launchpad if needed.

But if the changes look good, commit and then follow the rest of the uploading process::

Canceling an upload

or, if you have permission to upload to the primary archive::

Sponsoring a change

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

(Change the destination if you are uploading an SRU or similar.)

Now you can push the changes back to Launchpad::

The next step is to build and test the modified source package as you normally would::

Once that is done you should review the change you are about to commit with ``bzr diff``. This should show you the same changes as a debdiff would before you upload the source package.

This tag will tell the package importer that what is in the Bazaar branch is the same as in the archive.

Next you should make sure the ``debian/changelog`` is as you would like, with the correct distribution, version number, etc.

For older versions of bzr, you can use the ``merge-package`` command instead::

This will merge the two trees, possibly producing conflicts, which you'll need to resolve manually.

First, you need to check that you have the latest version of the package in your checkout of the development package trunk::

When you have a branch with a change that you would like to upload you need to get that change back on to the main source branch, build a source package, and then upload it.

Once your merge proposal is reviewed and approved, you will want to upload your package, either to the archive (if you have permission) or to your `Personal Package Archive`_ (PPA). You might also want to do an upload if you are sponsoring someone else's changes.

Uploading a package

Uploading a change made by you

autopkgtest: Automatic testing for packages

The actual tests

For the Ubuntu ``hello`` package, the ``control`` file looks something like this:

Fixing a bug in Ubuntu

Introduction

There are a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report.

Additional encryption software so you can securely transfer files

``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a collection of tools that make many packaging tasks easier.

``apt-file`` provides an easy way to find the binary package that contains a given file.

Ubuntu Packaging Guide

Ubuntu is not only a free and open source operating system, its platform is also open and developed in a transparent fashion. The source code for every single component can be obtained easily and every single change to the Ubuntu platform can be reviewed.

This means you can actively get involved in improving it and the community of Ubuntu platform developers is always interested in helping peers getting started.

Ubuntu is also a community of great people who believe in free software and that it should be accessible for everyone. Its members are welcoming and want you to be involved as well. We want you to get involved, to ask questions, to make Ubuntu better together with us.

If you run into problems: don't panic! Check out the :doc:`communication article<./communication>` and you will find out how to most easily get in touch with other developers.

The guide is split up into two sections: