ubuntu-packaging-guide-team team mailing list archive

[Jonathan Riddell <jriddell@xxxxxxxxxx>]

Jonathan Riddell has proposed merging lp:~jr/ubuntu-packaging-guide/02-udd-introduction into lp:ubuntu-packaging-guide.

Requested reviews:
  Ubuntu Packaging Guide Team (ubuntu-packaging-guide-team)
Related bugs:
  Bug #792381 in Ubuntu Packaging Guide: "Not really an "Ubuntu Packaging Guide""
  https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/792381

For more details, see:
https://code.launchpad.net/~jr/ubuntu-packaging-guide/02-udd-introduction/+merge/68078

split out udd-intro into a real introduction to UDD and a separate page for getting the source, also add some honesty about UDD on the front page and stub article for traditional packaging
-- 
https://code.launchpad.net/~jr/ubuntu-packaging-guide/02-udd-introduction/+merge/68078
Your team Ubuntu Packaging Guide Team is requested to review the proposed merge of lp:~jr/ubuntu-packaging-guide/02-udd-introduction into lp:ubuntu-packaging-guide.

=== modified file 'debian-dir-overview.rst'
--- debian-dir-overview.rst	2011-06-01 08:05:03 +0000
+++ debian-dir-overview.rst	2011-07-15 11:36:47 +0000
@@ -59,7 +59,7 @@
 number) appended to the end of the Debian version. So if the Debian hello 
 ``2.6-1`` package was changed by Ubuntu, the version string would be 
 ``2.6-1ubuntu1``. If a package for the application does not exist in Debian, 
-then the Debian revision is ``0`` (e.g., ``2.6-0ubuntu1``).
+then the Debian revision is ``0`` (e.g. ``2.6-0ubuntu1``).
 
 For further information, see the `changelog section (Section 4.4) 
 <http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog>`_ of 
@@ -115,7 +115,7 @@
 Maintainer Field spec <https://wiki.ubuntu.com/DebianMaintainerField>`_ on the 
 Ubuntu wiki.
 
-Each additional paragraph describes a binary package built.
+Each additional paragraph describes a binary package to be built.
 
 For further information, see the `control file section (Chapter 5) 
 <http://www.debian.org/doc/debian-policy/ch-controlfields.html>`_ of the Debian 
@@ -264,10 +264,12 @@
  foo usr/bin
  debian/bar.desktop usr/share/applications
 
-In the second case, files installed into ``debian/tmp`` can then be moved into 
-separate binary packages using multiple ``$package_name.install`` files. This 
-is often done to split large amounts of architecture independent data out of 
-architecture dependent packages and into ``Architecture: all`` packages. In 
+When a source package is producing multiple binary packages ``dh`` will
+install the files into ``debian/tmp`` rather than directly into
+``debian/<package>``. Files installed into ``debian/tmp`` can then be moved
+into separate binary packages using multiple ``$package_name.install`` files.
+This is often done to split large amounts of architecture independent data out
+of architecture dependent packages and into ``Architecture: all`` packages. In 
 this case, only the name of the files (or directories) to be installed are 
 needed without the installation directory. For example, ``foo.install`` 
 containing only the architecture dependent files might look like::
@@ -319,6 +321,10 @@
 4.11) <http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch>`_ 
 of the Debian Policy Manual.
 
+For a list of packages where the ``watch`` file reports they are not in sync
+with upstream see `Ubuntu External Health Status
+<http://qa.ubuntuwire.org/uehs/no_updated.html>`_.
+
 The source/format file
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -327,7 +333,7 @@
 to use the newer 3.0 source format. In this case, the file should contain a 
 single line indicating the desired format:
 
-* ``3.0 (native)`` for Debian native packages or
+* ``3.0 (native)`` for Debian native packages (no upstream version) or
 
 * ``3.0 (quilt)`` for packages with a separate upstream tarball
 

=== modified file 'fixing-a-bug.rst'
--- fixing-a-bug.rst	2011-06-03 21:23:43 +0000
+++ fixing-a-bug.rst	2011-07-15 11:36:47 +0000
@@ -19,7 +19,7 @@
 Finding the problem
 ===================
 
-There is a lot of different ways to find things to work on. It might be a bug
+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.
 
@@ -55,28 +55,16 @@
 different binary packages.  To find the source package for a particular binary
 package, type::
 
-    $ apt-cache show tomboy | grep ^Source:
-
-In this case, nothing is printed, meaning that ``tomboy`` is also the name of
-the binary package.  An example where the source and binary package names
-differ is ``python-vigra``.  While that is the binary package name, the source
-package is actually ``libvigraimpex`` and can be found with this command (and
-its output)::
-
-    $ apt-cache show python-vigra | grep ^Source:
-    Source: libvigraimpex
-
-.. XXX: Link to SRU article.
-
+    $ apt-cache showsrc tomboy | grep ^Package:
 
 Getting the code
 ================
 
 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.  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.
+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.
 
 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
@@ -84,7 +72,7 @@
 *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 or your excellent fix - and you get a little bit of
+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!
 
 We'll describe specifics on how to branch the code, push your fix, and request
@@ -182,7 +170,7 @@
 
 With the changelog entry written and saved, you can just run::
 
-  debcommit
+  bzr commit
 
 and the change will be committed (locally) with your changelog entry as a 
 commit message.
@@ -206,3 +194,4 @@
 browser. There find the "(+) Propose for merging" link, click it to get the
 change reviewed by somebody and included in Ubuntu.
 
+.. XXX: Link to SRU article.

=== modified file 'getting-set-up.rst'
--- getting-set-up.rst	2011-07-12 16:11:03 +0000
+++ getting-set-up.rst	2011-07-15 11:36:47 +0000
@@ -4,8 +4,8 @@
 
 There are a number of things you need to do to get started developing for Ubuntu.
 This article is designed to get your computer set up so that you can start 
-working with packages, and upload your packages to Launchpad. Here's what we'll 
-cover:
+working with packages, and upload your packages to Ubuntu's hosting
+platform, Launchpad. Here's what we'll cover:
 
 * Installing packaging-related software. This includes:
 
@@ -33,7 +33,7 @@
 
 There are a number of tools that will make your life as an Ubuntu developer
 much easier.  You will encounter these tools later in this guide.  To install
-most of the tools you will need, run this command::
+most of the tools you will need run this command::
 
     $ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file
 
@@ -55,8 +55,9 @@
 * ``ubuntu-dev-tools`` (and ``devscripts``, a direct dependency) -- a
   collection of tools that make many packaging tasks easier.
 * ``bzr-builddeb`` (and ``bzr``, a dependency) -- distributed version control
-  tools that makes it easy for many developers to collaborate and work on the
-  same code while keeping it trivial to merge each others work.
+  with Bazaar, a new way of working with packages for Ubuntu that will make it
+  easy for many developers to collaborate and work on the same code while
+  keeping it trivial to merge each others work.
 * ``apt-file`` provides an easy way to find the binary package that contains a
   given file.
 * ``apt-cache`` (part of the ``apt`` package) provides even more information 
@@ -84,12 +85,13 @@
 which means the key will never expire. The last questions will be about your
 name and email address. Just pick the ones you are going to use for Ubuntu
 development here, you can add additional email addresses later on. Adding a
-comment is not necessary. Then you will have to set a passphrase. Choose a
-safe one. 
+comment is not necessary. Then you will have to set a passphrase, choose a
+safe one (a passphrase is just a password which is allowed to include spaces). 
 
 Now GPG will create a key for you, which can take a little bit of time; it 
 needs random bytes, so if you give the system some work to do it will be 
-just fine.  Move the cursor around!
+just fine.  Move the cursor around, type some paragraphs of random text, load
+some web page.
 
 Once this is done, you will get a message similar to this one::
 
@@ -107,8 +109,8 @@
 
 This will send your key to one keyserver, but a network of keyservers will 
 automatically sync the key between themselves. Once this syncing is complete, 
-your signed public key will be ready to verify your your contributions 
-around the world.
+your signed public key will be ready to verify your contributions around the
+world.
 
 
 Create your SSH key
@@ -117,10 +119,10 @@
 SSH_ stands for *Secure Shell*, and it is a protocol that allows you to 
 exchange data in a secure way over a network. It is common to use SSH to access 
 and open a shell on another computer, and to use it to securely transfer files. 
-For our purposes, we will mainly be using SSH to securely communicate with 
-Launchpad. 
+For our purposes, we will mainly be using SSH to securely upload source packages
+to Launchpad. 
 
-To generate a SSH key, enter::
+To generate an SSH key, enter::
 
     $ ssh-keygen -t rsa
 
@@ -156,7 +158,7 @@
 configure your system to work with Launchpad. This section will focus
 on the following topics:
 
- * What Launchpad is, and creating a Launchpad account
+ * What Launchpad is and creating a Launchpad account
  * Uploading your GPG and SSH keys to Launchpad
  * Configuring Bazaar to work with Launchpad
  * Configuring Bash to work with Bazaar
@@ -175,6 +177,9 @@
 information. This will allow you to download and upload code, submit bug 
 reports, and more.
 
+Besides hosting Ubuntu, Launchpad can host any Free Software project. For more
+information see the `Launchpad Help wiki <https://help.launchpad.net/>`_.
+
 
 Get a Launchpad account
 --------------------------
@@ -212,8 +217,8 @@
     sub   4096R/51FBE68C 2010-12-06
 
 
-Head to https://launchpad.net/people/+me/+editpgpkeys and copy the part about
-your "Key fingerprint" into the text box. In the case above this would be
+Head to https://launchpad.net/people/+me/+editpgpkeys and copy the "Key
+fingerprint" into the text box. In the case above this would be
 ``5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D``. Now click on "Import
 Key".
 
@@ -253,7 +258,9 @@
 ----------------
 
 Bazaar is the tool we use to store code changes in a logical way, to exchange
-proposed changes and merge them, even if development is done concurrently.
+proposed changes and merge them, even if development is done concurrently.  It
+is used for the new Ubuntu Distributed Development method of working with
+Ubuntu packages.
 
 To tell Bazaar who you are, simply run::
 
@@ -278,7 +285,6 @@
     $ export DEBFULLNAME="Bob Dobbs"
     $ export DEBEMAIL="subgenius@xxxxxxxxxxx"
 
-
 Now save the file and either restart your terminal or run::
 
     $ source ~/.bashrc

=== modified file 'index.rst'
--- index.rst	2011-04-21 14:53:48 +0000
+++ index.rst	2011-07-15 11:36:47 +0000
@@ -3,27 +3,53 @@
    You can adapt this file completely to your liking, but it should at least
    contain the root `toctree` directive.
 
-Welcome to ubuntu-packaging-guide's documentation!
+Ubuntu Packaging Guide
 ==================================================
 
 The guide is split up into two sections:
 
-* A list of articles based on tasks, so things you want to get done.
-* A set of :doc:`knowledge base</knowledge-base>` articles that dig deeper 
+* A list of articles based on tasks, things you want to get done.
+* A set of knowledge-base articles that dig deeper 
   into specific bits of our tools and workflows.
 
+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.
+
+Articles
+--------
+
 .. toctree::
    :maxdepth: 1
 
    introduction-to-ubuntu-development
    getting-set-up
+   udd-intro
    fixing-a-bug
-   knowledge-base
+
+Knowledge Base
+--------------
+
+.. toctree::
+   :maxdepth: 1
+
+   debian-dir-overview
+   testing
+   udd-getting-the-source
+   udd-working
+   udd-sponsorship
+   udd-uploading
+   udd-latest
+   udd-merging
+   udd-patchsys
+   udd-newpackage
+   traditional-packaging
 
 
 Indices and tables
 ==================
 
 * :ref:`genindex`
-* :ref:`modindex`
 * :ref:`search`

=== modified file 'introduction-to-ubuntu-development.rst'
--- introduction-to-ubuntu-development.rst	2011-02-04 16:44:21 +0000
+++ introduction-to-ubuntu-development.rst	2011-07-15 11:36:47 +0000
@@ -13,11 +13,11 @@
 
 Every time a new version of an application is released, or when someone makes
 a change to the source code that goes into Ubuntu, the source package must be
-uploaded to the build machines to be compiled. The resulting binary packages 
-then are distributed to the archive and its mirrors in different countries. 
-The URLs in ``/etc/apt/sources.list`` point to an archive or mirror.  Every 
-day CD images are built for a selection of different Ubuntu flavours.  Ubuntu 
-Desktop, Ubuntu Server, Kubuntu and others specify a list of required 
+uploaded to Launchpad's build machines to be compiled. The resulting binary
+packages then are distributed to the archive and its mirrors in different
+countries. The URLs in ``/etc/apt/sources.list`` point to an archive or mirror. 
+Every day CD images are built for a selection of different Ubuntu flavours. 
+Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required 
 packages that get on the CD. These CD images are then used for installation 
 tests and provide the feedback for further release planning.
 

=== removed file 'knowledge-base.rst'
--- knowledge-base.rst	2011-06-03 09:49:34 +0000
+++ knowledge-base.rst	1970-01-01 00:00:00 +0000
@@ -1,27 +0,0 @@
-============================================
-Knowledge base of the Ubuntu Packaging Guide
-============================================
-
-Table of Contents:
-
-* General
-
-  .. toctree::
-     :maxdepth: 1
-
-     debian-dir-overview
-     testing
-
-* Development Processes
-  
-  .. toctree::
-     :maxdepth: 1
-
-     udd-intro
-     udd-working
-     udd-sponsorship
-     udd-uploading
-     udd-latest
-     udd-merging
-     udd-patchsys
-     udd-newpackage

=== added file 'traditional-packaging.rst'
--- traditional-packaging.rst	1970-01-01 00:00:00 +0000
+++ traditional-packaging.rst	2011-07-15 11:36:47 +0000
@@ -0,0 +1,5 @@
+=====================
+Traditional Packaging
+=====================
+
+FIXME describe traditional packaging here

=== added file 'udd-getting-the-source.rst'
--- udd-getting-the-source.rst	1970-01-01 00:00:00 +0000
+++ udd-getting-the-source.rst	2011-07-15 11:36:47 +0000
@@ -0,0 +1,190 @@
+==================
+Getting the Source
+==================
+
+Source package URLs
+===================
+
+Bazaar provides some very nice shortcuts for accessing Launchpad's source
+branches of packages in both Ubuntu and Debian.
+
+To refer to source branches use::
+
+    ubuntu:package
+
+where *package* refers to the package name you're interested in.  This URL
+refers to the package in the current development version of Ubuntu.  To
+refer to the branch of Tomboy in the development version, you would use::
+
+    ubuntu:tomboy
+
+To refer to the version of a source package in an older release of Ubuntu,
+just prefix the package name with the release's code name.  E.g. to refer to
+Tomboy's source package in Maverick_ use::
+
+    ubuntu:maverick/tomboy
+
+Since they are unique, you can also abbreviate the distro-series name::
+
+    ubuntu:m/tomboy
+
+You can use a similar scheme to access the source branches in Debian, although
+there are no shortcuts for the Debian distro-series names.  To access the
+Tomboy branch in the current development series for Debian use:
+
+    debianlp:tomboy
+
+and to access Tomboy in Debian Lenny_ use::
+
+    debianlp:lenny/tomboy
+
+
+.. _`Bazaar`: http://bazaar.canonical.com/en/
+.. _`Intrepid`: https://wiki.ubuntu.com/IntrepidIbex
+.. _Maverick: https://wiki.ubuntu.com/MaverickMeerkat
+.. _Lenny: http://debian.org/releases/stable/
+
+
+Getting the source
+==================
+
+Every source package in Ubuntu has an associated source branch on Launchpad.
+These source branches are updated automatically by Launchpad, although the
+process is not currently foolproof.
+
+There are a couple of things that we do first in order to make the workflow
+more efficient later.  Once you are used to the process you will learn when it
+makes sense to skip these steps.
+
+
+.. _up-to-date:
+
+Ensure the source branch is up-to-date
+--------------------------------------
+
+Once you've determined which source package to work on, you should ensure that
+the source branch for that package on Launchpad is up-to-date.  Some package
+imports fail for various reasons, and the `status of the package importer`_ is
+always available online.  If the source branch for a package you want to work
+on is out of sync, you'll have to use ``apt-get source`` until the import of
+that package is fixed.
+
+Let's say you want to fix a problem in Tomboy in Natty.  First, find out the
+latest binary package versions that are available::
+
+    $ rmadison tomboy | grep natty
+    tomboy | 1.5.2-1ubuntu4 |         natty | source, amd64, i386
+
+You've already seen how to :ref:`determine the source package corresponding to
+this binary package <what-to-fix>`.  For Tomboy, the binary and source
+packages are both named ``tomboy``.
+
+Whenever the package importer processes a new source package version, it adds
+a Bazaar tag corresponding to that new version.  You can use this tag to
+ensure that the import is up-to-date.  To find the tag of the last revision
+committed by the package importer, do::
+
+    $ bzr log ubuntu:tomboy | grep ^tags | head -n 1
+    tags: 1.5.2-1ubuntu4
+
+By comparing the version number returned by ``rmadison`` and the tag added by
+the package importer, we can see that the ``tomboy`` source package for Natty
+is up-to-date.
+
+Here's an example of a package that is out-of-date.  Let's say you want to fix
+a problem in the ``initscripts`` binary package.  First find out the
+latest binary package versions that are available::
+
+    $ rmadison initscripts | tail -n 1
+    initscripts | 2.87dsf-4ubuntu25 |       oneiric | amd64, i386
+
+Then determine the source package corresponding to this binary package::
+
+    $ apt-cache showsrc initscripts | grep ^Package:
+    Package: sysvinit
+
+Find the latest tag added by the package importer::
+
+    $ bzr log ubuntu:sysvinit | grep ^tags | head -n 1
+    tags: 2.86.ds1-61ubuntu13
+
+Here we can see that ``2.86.ds1-61ubuntu13`` is older than
+``2.87dsf-4ubuntu19`` so the source package is out of date, and in fact we can
+verify that by looking at the status package for the package at
+http://package-import.ubuntu.com/status/sysvinit.html.
+
+When you find such out-of-date packages, be sure to `file a bug on the UDD
+project`_ to get the issue resolved.
+
+A feature in progress is for a warning to be automatically printed when
+branching an out of date import, this will make the above obsolete.
+
+.. _branching:
+
+Creating a shared repository
+----------------------------
+
+Okay, you want to work on the Tomboy package in Natty, and you've verified
+that the source package is up-to-date.  Before actually branching the code for
+Tomboy, create a shared repository to hold the branches for this package.
+The shared repository will make future work much more efficient.
+
+Do this using the `bzr init-repo` command, passing it the directory name we
+would like to use::
+
+    $ bzr init-repo tomboy
+
+You will see that a `tomboy` directory is created in your current working
+area.  Change to this new directory for the rest of your work::
+
+    $ cd tomboy
+
+
+Getting the trunk branch
+------------------------
+
+We use the `bzr branch` command to create a local branch of the package.
+We'll name the target directory `tomboy.dev` just to keep things easy to
+remember::
+
+    $ bzr branch ubuntu:tomboy tomboy.dev
+
+The tomboy.dev directory represents the version of Tomboy in the development
+version of Ubuntu, and you can always ``cd`` into this directory and do a `bzr
+pull` to get any future updates.
+
+
+Getting a branch for a particular release
+-----------------------------------------
+
+When you want to do something like a `stable release update`_ (SRU), or you
+just want to examine the code in an old release, you'll want to grab the
+branch corresponding to a particular Ubuntu release.  For example, to get the
+Tomboy package for Maverick do::
+
+    $ bzr branch ubuntu:m/tomboy maverick
+
+
+Importing a Debian source package
+---------------------------------
+
+If the package you want to work on is available in Debian but not Ubuntu, it's
+still easy to import the code to a local bzr branch for development.  Let's
+say you want to import the `newpackage` source package.  We'll start by
+creating a shared repository as normal, but we also have to create a working
+tree to which the source package will be imported (remember to cd out of the
+`tomboy` directory created above)::
+
+    $ bzr init-repo newpackage
+    $ cd newpackage
+    $ bzr init debian
+    $ cd debian
+    $ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc
+
+As you can see, we just need to provide the remote location of the dsc file,
+and Bazaar will do the rest.  You've now got a Bazaar source branch.
+
+
+.. _`status of the package importer`: http://package-import.ubuntu.com/status
+.. _`file a bug on the UDD project`: https://bugs.launchpad.net/udd
+.. _`stable release update`: https://wiki.ubuntu.com/StableReleaseUpdates

=== modified file 'udd-intro.rst'
--- udd-intro.rst	2011-06-03 20:17:00 +0000
+++ udd-intro.rst	2011-07-15 11:36:47 +0000
@@ -1,225 +1,130 @@
-==============================
-Ubuntu Distributed Development
-==============================
-
-*Ubuntu Distributed Development* (UDD) is a technique for developing Ubuntu
+===================================================
+Ubuntu Distributed Development - Introduction
+===================================================
+
+This guide focuses on packaging using the *Ubuntu Distributed Development* (UDD)
+method.
+
+*Ubuntu Distributed Development* (UDD) is a new technique for developing Ubuntu
 packages that uses tools, processes, and workflows similar to generic
-distributed version control (dVCS) system-based software development.  The
-dVCS used for UDD is Bazaar_.
-
-You should already be familiar with basic Bazaar usage and workflow.  Ubuntu
-Intrepid_ or later is required for these instructions to work.
-
-
-Source package URLs
-===================
-
-Bazaar provides some very nice shortcuts for accessing the source branches of
-packages in both Ubuntu and Debian (on Launchpad).  These shortcuts are
-available in Bazaar version 2.3 or newer.  You can still access source
-branches in older versions of Bazaar, using a slightly more verbose syntax.
-
-The examples in this guide always use the ``ubuntu:`` prefix.
-
-
-Source branch shortcuts
------------------------
-
-To refer to source branches use::
-
-    ubuntu:package
-
-where *package* refers to the package name you're interested in.  This URL
-refers to the package in the current development version of Ubuntu.  As of
-this writing (2011-02-04) that version is Natty_ which will be released as
-Ubuntu 11.04.  Thus, to refer to the branch of Tomboy in Natty, you would
-use::
-
-    ubuntu:tomboy
-
-To refer to the version of a source package in an older release of ubuntu,
-just prefix the package name with the release's code name.  E.g. to refer to
-Tomboy's source package in Maverick_ use::
-
-    ubuntu:maverick/tomboy
-
-Since they are unique, you can also abbreviate the distro-series name::
-
-    ubuntu:m/tomboy
-
-You can use a similar scheme to access the source branches in Debian, although
-there are no shortcuts for the Debian distro-series names.  To access the
-Tomboy branch in the current development series for Debian use:
-
-    debianlp:tomboy
-
-and to access Tomboy in Debian Lenny_ use::
-
-    debianlp:lenny/tomboy
-
-
-Explicit source branches
-------------------------
-
-If you're using an older version of Bazaar, the ``ubuntu:`` and ``debianlp:``
-prefixes won't be available to you.  Instead use the ``lp:`` prefix to access
-the source branch.  For example, Tomboy in the latest Ubuntu development
-release is available at::
-
-    lp:ubuntu/tomboy
-
-while the Maverick version is available at::
-
-    lp:ubuntu/maverick/tomboy
-
-and the Debian Lenny version is available at::
-
-    lp:debian/lenny/tomboy
-
-
-.. _`Bazaar`: http://bazaar.canonical.com/en/
-.. _`Intrepid`: https://wiki.ubuntu.com/IntrepidIbex
-.. _Natty: https://wiki.ubuntu.com/NattyNarwhal
-.. _Maverick: https://wiki.ubuntu.com/MaverickMeerkat
-.. _Lenny: http://debian.org/releases/stable/
-
-
-Getting the source
-==================
-
-Every source package in Ubuntu has an associated source branch on Launchpad.
-These source branches are updated automatically by Launchpad, although the
-process is not currently foolproof.
-
-There are a couple of things that we do first in order to make the workflow
-more efficient later.  Once you are used to the process you will learn when it
-makes sense to skip these steps.
-
-
-.. _up-to-date:
-
-Ensure the source branch is up-to-date
---------------------------------------
-
-Once you've determined which source package to work on, you should ensure that
-the source branch for that package on Launchpad is up-to-date.  Some package
-imports fail for various reasons, and the `status of the package importer`_ is
-always available online.  If the source branch for a package you want to work
-on is out of sync, you'll have to use ``apt-get source`` until the import of
-that package is fixed.
-
-Let's say you want to fix a problem in Tomboy in Natty.  First, find out the
-latest binary package versions that are available::
-
-    $ rmadison tomboy | grep natty
-    tomboy | 1.5.2-1ubuntu4 |         natty | source, amd64, i386
-
-You've already seen how to :ref:`determine the source package corresponding to
-this binary package <what-to-fix>`.  For Tomboy, the binary and source
-packages are both named ``tomboy``.
-
-Whenever the package importer processes a new source package version, it adds
-a Bazaar tag corresponding to that new version.  You can use this tag to
-ensure that the import is up-to-date.  To find the tag of the last revision
-committed by the package importer, do::
-
-    $ bzr log -l 1 ubuntu:tomboy | grep ^tags:
-    tags: 1.5.2-1ubuntu4
-
-By comparing the version number returned by ``rmadison`` and the tag added by
-the package importer, we can see that the ``tomboy`` source package for Natty
-is up-to-date.
-
-Here's an example of a package that is out-of-date.  Let's say you want to fix
-a problem in the ``initscripts`` binary package on Natty_.  First find out the
-latest binary package versions that are available::
-
-    $ rmadison initscripts | grep natty
-    initscripts | 2.87dsf-4ubuntu19 |         natty | amd64, i386
-
-Then determine the source package corresponding to this binary package::
-
-    $ apt-cache show initscripts | grep ^Source:
-    Source: sysvinit
-
-Find the latest tag added by the package importer::
-
-    $ bzr log -l 1 ubuntu:sysvinit | grep ^tags:
-    tags: 2.86.ds1-61ubuntu13
-
-Here we can see that ``2.86.ds1-61ubuntu13`` is older than
-``2.87dsf-4ubuntu19`` so the source package is out of date, and in fact we can
-verify that by looking at the status package for the package at
-http://package-import.ubuntu.com/status/sysvinit.html.
-
-When you find such out-of-date packages, be sure to `file a bug on the UDD
-project`_ to get the issue resolved.
-
-.. _branching:
-
-Creating a shared repository
-----------------------------
-
-Okay, you want to work on the Tomboy package in Natty, and you've verified
-that the source package is up-to-date.  Before actually branching the code for
-Tomboy, create a shared repository to hold the branches for this package.
-The shared repository will make future work much more efficient.
-
-Do this using the `bzr init-repo` command, passing it the directory name we
-would like to use::
-
-    $ bzr init-repo tomboy
-
-You will see that a `tomboy` directory is created in your current working
-area.  Change to this new directory for the rest of your work::
-
-    $ cd foobar
-
-
-Getting the trunk branch
-------------------------
-
-We use the `bzr branch` command to create a local branch of the package.
-We'll name the target directory `natty` just to keep things easy to remember::
-
-    $ bzr branch ubuntu:tomboy natty
-
-The `natty` directory represents the version of Tomboy in Natty, and you can
-always ``cd`` into this directory and do a `bzr pull` to get any future
-updates.
-
-
-Getting a branch for a particular release
------------------------------------------
-
-When you want to do something like a `stable release update`_ (SRU), or you
-just want to examine the code in an old release, you'll want to grab the
-branch corresponding to a particular Ubuntu release.  For example, to get the
-Tomboy package for Maverick do::
-
-    $ bzr branch ubuntu:m/tomboy maverick
-
-
-Importing a Debian source package
+distributed version control system (DVCS) based software development.  The
+DVCS used for UDD is Bazaar_.
+
+Traditional Packaging Limitations
 ---------------------------------
 
-If the package you want to work on is available in Debian but not Ubuntu, it's
-still easy to import the code to a local bzr branch for development.  Let's
-say you want to import the `newpackage` source package.  We'll start by
-creating a shared repository as normal, but we also have to create a working
-tree to which the source package will be imported (remember to cd out of the
-`tomboy` directory created above)::
-
-    $ bzr init-repo newpackage
-    $ cd new-package
-    $ bzr init debian
-    $ cd debian
-    $ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc
-
-As you can see, we just need to provide the remote location of the dsc file,
-and Bazaar will do the rest.  You've now got a Bazaar source branch.
-
+Traditionally Ubuntu packages have been kept in tar archive files.  A
+traditional source package is made up of the upstream source tar, a "debian" tar
+(or compressed diff file for older packages) containing the packaging and a
+.dsc meta-data file.  To see a traditional package run::
+
+    $ apt-get source kdetoys
+
+This will download the upstream source ``kdetoys_4.6.5.orig.tar.bz2``, the
+packaging ``kdetoys_4.6.5-0ubuntu1.debian.tar.gz`` and the meta-data
+``kdetoys_4.6.5-0ubuntu1~ppa1.dsc``.  Assuming you have dpkg-dev installed it
+will extract these and give you the source package.
+
+Traditional packaging would edit these files and upload.  However this gives
+limited opportunity to collaborate with other developers, changes have to be
+passed around as diff files with no central way to track them and two developers
+can not make changes at the same time.  So most teams have moved to putting
+their packaging in a revision control system.  This makes it easier for several
+developers to work on a package together.  However there is no direct
+connection between the revision control system and the archive packages so the
+two must be manually kept in sync.  Since each team works in its own revision
+control system a prospective developer must first work out where that is and
+how to get the packaging before they can work on the package.
+
+Ubuntu Distributed Development
+------------------------------
+
+With Ubuntu Distributed Development all packages in the Ubuntu (and Debian)
+archive are automatically imported into Bazaar branches on our code hosting
+site Launchpad.  Changes can be made directly to these branches in
+incremental steps and by anyone with commit access.  Changes can also be made
+in forked branched and merged back in with Merge Proposals when they are large
+enough to need review or if they are by someone without direct commit access.
+
+UDD branches are all in a standard location so doing a checkout is easy::
+
+    $ bzr branch ubuntu:kdetoys
+
+The merge history includes two separate branches, one for the upstream source
+and one which adds the ``debian/`` packaging directory::
+
+    $ cd kdetoys
+    $ bzr qlog
+
+(This command uses *qbzr* for a GUI, run ``log`` instead of ``qlog`` for
+console output.)
+
+.. image:: images/kdetoys-udd-branch.png
+
+This UDD branch of *kdetoys* shows the full packaging for each version
+uploaded to Ubuntu with grey circles and the upstream source versions with
+green circles.  Versions are tagged with either the version in Ubuntu such as
+``4:4.2.29-0ubuntu1`` or for the upstream branch with the upstream version
+``upstream-4.2.96``.  
+
+Many Ubuntu packages are based on the packages in Debian, UDD also imports the
+Debian package into our branches.  In the *kdetoys* branch above the Debian
+versions from *unstable* are from the merge with blue circles while those from
+*Debian experimental* are from the merge with yellow circles.  Debian
+released are tagged with their version number e.g. ``4:4.2.2-1``.
+
+So from a UDD branch you can see the complete history of changes to the package
+and compare any two versions.  For example, to see the changes between version
+4.2.2 in Debian and the 4.2.2 in Ubuntu use::
+
+    $ bzr qdiff -r tag:4:4.2.2-1..tag:4:4.2.2-1ubuntu1
+
+(This command uses *qbzr* for a GUI, run ``diff`` instead of ``qdiff`` for
+console output.)
+
+.. image:: images/kdetoys-udd-diff.png
+
+From this we can clearly see what has changed in Ubuntu compared to Debian,
+very handy.
+
+Bazaar
+------
+
+UDD branches use Bazaar, a distributed revision control system intended to be
+easy to use for those familiar with popular systems such as Subversion while
+offering the power of Git.
+
+To do packaging with UDD you will need to know the basics of how to use
+Bazaar to manage files.  For an introduction to Bazaar see the `Bazaar Five
+Minute Tutorial
+<http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html>`_ and the
+`Bazaar Users Guide
+<http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html>`_.
+
+Limitations of UDD
+------------------
+
+Ubuntu Distributed Development is a new method for working with Ubuntu
+packages.  It currently has some notable limitations:
+
+* Doing a full branch with history can take a lot of time and network
+  resources.  You may find it quicker to do a lightweight checkout ``bzr
+  checkout --lightweight ubuntu:kdetoys`` but this will need a network access
+  for any further bzr operations.
+
+* Working with patches is fiddly.  Patches can be seen as a branched revision
+  control system, so we end up with RCS on top of RCS.
+
+* There is no way to build directly from branches.  You need to create a source
+  package and upload that.
+
+* Some packages have not been successfully imported into UDD branches.  You
+  should check the `status of the package importer`_ before working on a branch.
+
+All of the above are being worked on and UDD is expected to become the main way
+to work on Ubuntu packages soon.  However currently most teams within Ubuntu do
+not yet work with UDD branches for their  development.  However because UDD
+branches are the same as the packages in the  archive any team should be able to
+accept merges against them.
 
 .. _`status of the package importer`: http://package-import.ubuntu.com/status
-.. _`file a bug on the UDD project`: https://bugs.launchpad.net/udd
-.. _`stable release update`: https://wiki.ubuntu.com/StableReleaseUpdates

=== modified file 'udd-latest.rst'
--- udd-latest.rst	2011-05-20 15:26:22 +0000
+++ udd-latest.rst	2011-07-15 11:36:47 +0000
@@ -12,7 +12,7 @@
 Updating your copy of a branch that corresponds to the package in a particular
 release is very simple, simply use `bzr pull` from the appropriate directory::
 
-    $ cd tomboy/natty
+    $ cd tomboy/tomboy.dev
     $ bzr pull
 
 This works wherever you have a checkout of a branch, so it will work for
@@ -39,7 +39,7 @@
 have committed your current work first::
 
     $ cd tomboy/bug-12345
-    $ bzr merge-package ../natty
+    $ bzr merge-package ../tomboy.dev
 
 Any conflicts will be reported, and you can fix them up.  To review the
 changes that you just merged use `bzr diff`.  To undo the merge use `bzr

=== modified file 'udd-merging.rst'
--- udd-merging.rst	2011-05-27 18:02:49 +0000
+++ udd-merging.rst	2011-07-15 11:36:47 +0000
@@ -1,6 +1,6 @@
-=======
-Merging
-=======
+===========================================
+Merging - Updating from Debian and Upstream
+===========================================
 
 Merging is one of the strengths of Bazaar, and something we do often in Ubuntu
 development.  Updates can be merged from Debian, from a new upstream release,
@@ -47,7 +47,7 @@
 need, you will add a new changelog entry, and commit::
 
     $ dch -i
-    $ debcommit
+    $ bzr commit
 
 as described earlier.
 
@@ -68,8 +68,8 @@
 If you are going to build the source package from this merged branch, you
 would use the ``-S`` option to the ``bd`` command.  One other thing you'll
 want to consider is also using the ``--package-merge`` option.  This will add
-the appropriate ``-v`` and ``-sa`` options to the source package so that all
-the changelog entries since the last Ubuntu change will be included in your
+the appropriate ``-v`` and ``-sa`` options to the source package so that all the
+changelog entries since the last Ubuntu change will be included in your
 ``_source.changes`` file.   For example::
 
     $ bzr bd -S --package-merge
@@ -101,9 +101,8 @@
 
 The last parameter is the location of the tarball that you are upgrading to;
 this can either be a local filesystem path, or a http, ftp, sftp, etc. URI as
-shown.  The command will automatically download the tarball for you.  If you
-point to a `.tar.bz2` or similar tarball then it will recompress it as needed,
-or convert it if you pass it a `.zip` or similar.
+shown.  The command will automatically download the tarball for you.  The
+tarball will be renamed appropriately and, if required, converted to .gz.
 
 The `merge-upstream` command will either tell you that it completed
 successfully, or that there were conflicts.  Either way you will be able to
@@ -113,7 +112,7 @@
 not previously used the UDD layout, `bzr merge-upstream` will fail with an
 error that the tag for the previous upstream version is not available; the
 merge can't be completed without knowing what base version to merge against.
-To work around this, create a tag in your existing existing repo for the last
+To work around this, create a tag in your existing repository for the last
 upstream version present there; e.g., if the last Ubuntu release was
 *1.1-0ubuntu3*, create the tag *upstream-1.1* pointing to the bzr revision you
 want to use as the tip of the upstream branch.

=== modified file 'udd-patchsys.rst'
--- udd-patchsys.rst	2011-02-05 01:02:31 +0000
+++ udd-patchsys.rst	2011-07-15 11:36:47 +0000
@@ -1,9 +1,14 @@
-===========================
-Working with a patch system
-===========================
+==============================================================
+Ubuntu Distributed Development - Working with Patches via Loom
+==============================================================
+
+Here are some guidelines for working with Quilt_ patches using the Bazaar Loom
+plugin. A loom allows the development of multiple patches at once, while still
+giving each patch a branch of its own.  This is a work in progress for the UDD
+developers who will be working on improving this workflow.
 
 Many existing packages that have changes from upstream express those changes
-using a `patch system`_, of which there are several to choose from.  Usually,
+using a patch system, of which there are several to choose from.  Usually,
 when you make an additional change to a package, you'll want to add a patch
 file to the patch system being used, rather than editing the source code in
 place.  Note however that it is considered bad practice to add a patch system
@@ -19,11 +24,6 @@
 problems pushing and pulling your threads to Launchpad.* Do ``bzr plugins`` to
 find the version you're using.
 
-Here are some guidelines that I've found helpful.  Clearly the existing tools
-can be improved, but for now this seems to work well enough.  This assumes
-you're using looms to develop your patch, and that the package itself uses the
-quilt_ patch system.
-
 One important thing to know: all source branches reflect the tree after a
 ``quilt push -a``.  In other words, when you branch a source branch, you get
 the tree with all patches applied, ready for you to jump right into hacking.
@@ -182,7 +182,6 @@
 There's now `a bug` that tracks this.
 
 
-.. _`patch system`: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem/PackagingGuide/PatchSystems
 .. _`Bazaar looms`: https://launchpad.net/bzr-loom
 .. _quilt: http://www.wzdftpd.net/blog/index.php?2008/02/05/3-quilt-a-patch-management-system-how-to-survive-with-many-patches
 .. _`currently includes any existing .pc directory`: https://bugs.launchpad.net/udd/+bug/672740

=== modified file 'udd-sponsorship.rst'
--- udd-sponsorship.rst	2011-02-07 15:34:46 +0000
+++ udd-sponsorship.rst	2011-07-15 11:36:47 +0000
@@ -1,6 +1,6 @@
-==============================
-Seeking Review and Sponsorship
-==============================
+===============================================================
+Ubuntu Distributed Development - Seeking Review and Sponsorship
+===============================================================
 
 One of the biggest advantages to using the UDD workflow is to improve quality
 by seeking review of changes by your peers.  This is true whether or not you
@@ -18,8 +18,8 @@
 Pushing to Launchpad
 ====================
 
-We previously showed you how to :ref:`link your branch to the bug
-<link-via-changelog>` using ``dch`` and ``debcommit``.  However, the branch
+We previously showed you how to :ref:`associate your branch to the bug
+<link-via-changelog>` using ``dch`` and ``bzr commit``.  However, the branch
 and bug don't actually get linked until you push the branch to Launchpad.
 
 It is not critical to have a link to a bug for every change you make,
@@ -27,14 +27,14 @@
 
 The general form of the URL you should push your branch to is::
 
-    lp:~<user-id>/ubuntu/<distroseries>/<package>/bug-12345
+    lp:~<user-id>/ubuntu/<distroseries>/<package>/<branch-name>
 
 For example, to push your fix for bug 12345 in the Tomboy package for Natty,
 you'd use::
 
     $ bzr push lp:~subgenius/ubuntu/natty/tomboy/bug-12345
 
-The last component of the path is actually arbitrary; it's up to you to pick
+The last component of the path is arbitrary; it's up to you to pick
 something meaningful.
 
 However, this usually isn't enough to get Ubuntu developers to review and
@@ -66,7 +66,7 @@
 debdiff, you can generate one like this (from inside your `bug-12345`
 branch)::
 
-    $ bzr diff -rbranch:../natty
+    $ bzr diff -rbranch:../tomboy.dev
 
 Another way is to is to open the merge proposal and download the diff.
 
@@ -94,6 +94,6 @@
 and asking for re-review, or you can reply on the merge proposal page in
 Launchpad.
 
-Note that if you are sponsored via debdiff attached to a bug report you need
+Note that if you are sponsored via a debdiff attached to a bug report you need
 to manually update by generating a new diff and attaching that to the bug
 report.

=== modified file 'udd-uploading.rst'
--- udd-uploading.rst	2011-05-25 14:08:46 +0000
+++ udd-uploading.rst	2011-07-15 11:36:47 +0000
@@ -4,7 +4,7 @@
 
 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
+`Personal Package Archive`_ (PPA).  You might also want to do an upload if
 you are sponsoring someone else's changes.
 
 
@@ -16,17 +16,18 @@
 then upload it.
 
 First, you need to check that you have the latest version of the package in
-your checkout of the development package::
+your checkout of the development package trunk::
 
-    $ cd tomboy/natty
+    $ cd tomboy/tomboy.dev
     $ bzr pull
 
 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 it will take a while to merge them and test the package,
-then you can merge them back into your working branch to do this.  If not,
-then you can carry on merging your working branch to the main one.  You'll
-want to use the Bazaar ``merge-package`` command rather than just ``merge``::
+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. You'll want to use the Bazaar ``merge-package`` command rather than just
+``merge``::
 
     $ bzr merge-package ../bug-12345
 
@@ -41,26 +42,18 @@
 before you upload the source package.
 
 The next step is to build and test the modified source package as you normally
-would.  Once you are happy with the upload then you should `dput` the
-source package.  For example, if you want to upload your changes to your PPA,
-then you'd do::
-
-    $ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes
-
-or, if you have permission to upload to the primary archive::
-
-    $ dput tomboy_1.5.2-1ubuntu5_source.changes
-
-You might want to do one more `debcommit` to make sure all your changes are
-committed in your working tree.
+would::
+
+    $ bzr bd -S
 
 The last step is to mark the change as being the same as the source package
-that was uploaded, so run::
-
-    $ bzr mark-uploaded
-
-This also tells the package importer that what is in the Bazaar branch is the
-same as in the archive.
+that was uploaded, bzr-builddeb will override the `tag` command to
+automatically tag with the version number in debian/changelog so run::
+
+    $ bzr tag
+
+This tag will tell the package importer that what is in the Bazaar branch
+is the same as in the archive.
 
 Now you can push the changes back to Launchpad::
 
@@ -68,6 +61,16 @@
 
 (Change the destination if you are uploading an SRU or similar.)
 
+Once you are happy with the upload then you should use `dput` to upload the
+built source package to Launchpad. For example, if you want to upload your
+changes to your PPA, then you'd do::
+
+    $ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes
+
+or, if you have permission to upload to the primary archive::
+
+    $ dput ubuntu tomboy_1.5.2-1ubuntu5_source.changes
+
 You are now free to delete your feature branch, as it is merged, and can
 be re-downloaded from Launchpad if needed.
 

=== modified file 'udd-working.rst'
--- udd-working.rst	2011-02-05 01:02:31 +0000
+++ udd-working.rst	2011-07-15 11:36:47 +0000
@@ -1,6 +1,6 @@
-====================
-Working on a Package
-====================
+=====================================================
+Ubuntu Distributed Development - Working on a Package
+=====================================================
 
 Once you have the source package branch in a shared repository, you'll want to
 create additional branches for the fixes or other work you plan to do.  You'll
@@ -15,7 +15,7 @@
 The first thing to do is to make sure your source package branch is
 up-to-date.  It will be if you just checked it out, otherwise do this::
 
-    $ cd natty
+    $ cd tomboy.dev
     $ bzr pull
 
 Any updates to the package that have uploaded since your checkout will now be
@@ -25,7 +25,7 @@
 repository you previously created for Tomboy, you can create your bug fix
 branch like this::
 
-    $ bzr branch natty bug-12345
+    $ bzr branch tomboy.dev bug-12345
     $ cd bug-12345
 
 Now you can do all my work in the `bug-12345` directory.  You make changes
@@ -41,9 +41,8 @@
 
 .. _link-via-changelog:
 
-Here's where things diverge a little from typical Bazaar usage.  When you
-added your `debian/changelog` entry, you should have included a bug fix tag
-that indicated which Launchpad bug issue you're fixing.  The format of this
+When you added your `debian/changelog` entry, you should have included a bug fix
+tag that indicated which Launchpad bug issue you're fixing.  The format of this
 textual tag is pretty strict: ``LP: #12345``.  The space between the ``:`` and
 the ``#`` is required and of course the number will be replaced by the actual
 bug number you're fixing.  Your `debian/changelog` entry might look something
@@ -55,18 +54,15 @@
 
      -- Bob Dobbs <subgenius@xxxxxxxxxxx>  Mon, 10 Jan 2011 16:10:01 -0500
 
-Normally, when you want to commit changes to your branch, you just use ``bzr
-commit``, but in the case where you've made a change to ``debian/changelog``,
-you'll want to use the ``debcommit`` command instead::
-
-    $ debcommit
-
-The reason to use ``debcommit`` instead is that it automatically includes your
-``debian/changelog`` entry in the commit message, and it also adds the
-necessary metadata to link your branch to the bug report when you push your
-branch to Launchpad.  You can do that manually with ``bzr commit`` (and
-eventually, ``bzr commit`` may get smart enough to do it for you), but for now
-``debcommit`` is the most convenient way to do it.
+Commit with the normal::
+
+    bzr commit
+
+A hook in bzr-builddeb will use the debian/changelog text as the commit
+message and set the tag to mark bug #12345 as fixed.
+
+This only works with bzr-builddeb 2.7.5 and bzr 2.4, for older versions use
+`debcommit`.
 
 
 Building the package
@@ -95,16 +91,5 @@
 Note that while `bzr bd` has a `--native` switch, it does not have a
 `--no-native` switch.
 
-You might also see an error that looks something like this:
-
-    dpkg-source: error: Version number suggests Ubuntu changes, but
-    Maintainer: does not have Ubuntu address
-
-In a sense, this is a safeguard to ensure that ``update-maintainer`` is run
-when necessary.  However in this case, you can just temporarily set the
-``$DEBEMAIL`` environment variable to a non-@xxxxxxxxxx address::
-
-    $ DEBEMAIL='me@xxxxxxxxxxx' bzr bd -S
-
 Once you've got the source package, you can build it as normal with
-``pbuilder`` or ``sbuild``.
+``pbuilder-dist`` (or ``pbuilder`` or ``sbuild``).