ubuntu-packaging-guide-team team mailing list archive
-
ubuntu-packaging-guide-team team
-
Mailing list archive
-
Message #00224
[Merge] lp:~jr/ubuntu-packaging-guide/fixes into lp:ubuntu-packaging-guide
Jonathan Riddell has proposed merging lp:~jr/ubuntu-packaging-guide/fixes into lp:ubuntu-packaging-guide.
Requested reviews:
Ubuntu Packaging Guide Team (ubuntu-packaging-guide-team)
For more details, see:
https://code.launchpad.net/~jr/ubuntu-packaging-guide/fixes/+merge/67951
A bunch of fixes to tidy up parts of the packaging guide
--
https://code.launchpad.net/~jr/ubuntu-packaging-guide/fixes/+merge/67951
Your team Ubuntu Packaging Guide Team is requested to review the proposed merge of lp:~jr/ubuntu-packaging-guide/fixes 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-14 11:58:22 +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-14 11:58:22 +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-14 11:58:22 +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-14 11:58:22 +0000
@@ -3,27 +3,45 @@
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 list of articles based on tasks, things you want to get done.
* A set of :doc:`knowledge base</knowledge-base>` articles that dig deeper
into specific bits of our tools and workflows.
+Articles
+--------
+
.. toctree::
:maxdepth: 1
introduction-to-ubuntu-development
getting-set-up
fixing-a-bug
- knowledge-base
+
+Knowledge Base
+--------------
+
+.. toctree::
+ :maxdepth: 1
+
+ debian-dir-overview
+ testing
+ udd-intro
+ udd-working
+ udd-sponsorship
+ udd-uploading
+ udd-latest
+ udd-merging
+ udd-patchsys
+ udd-newpackage
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-14 11:58:22 +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.
=== modified file 'udd-intro.rst'
--- udd-intro.rst 2011-06-03 20:17:00 +0000
+++ udd-intro.rst 2011-07-14 11:58:22 +0000
@@ -1,43 +1,36 @@
-==============================
-Ubuntu Distributed Development
-==============================
+===================================================
+Ubuntu Distributed Development - Getting the Source
+===================================================
*Ubuntu Distributed Development* (UDD) is a 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_.
+distributed version control system (DVCS) 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.
+You should already be familiar with basic Bazaar usage and workflow. 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>`_.
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
------------------------
+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. 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::
+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,
+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::
@@ -58,28 +51,8 @@
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/
@@ -123,7 +96,7 @@
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:
+ $ 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
@@ -131,20 +104,20 @@
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
+a problem in the ``initscripts`` binary package. First find out the
latest binary package versions that are available::
- $ rmadison initscripts | grep natty
- initscripts | 2.87dsf-4ubuntu19 | natty | amd64, i386
+ $ rmadison initscripts | tail -n 1
+ initscripts | 2.87dsf-4ubuntu25 | oneiric | amd64, i386
Then determine the source package corresponding to this binary package::
- $ apt-cache show initscripts | grep ^Source:
- Source: sysvinit
+ $ apt-cache showsrc initscripts | grep ^Package:
+ Package: sysvinit
Find the latest tag added by the package importer::
- $ bzr log -l 1 ubuntu:sysvinit | grep ^tags:
+ $ 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
@@ -155,6 +128,9 @@
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
@@ -173,20 +149,21 @@
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
+ $ 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 `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.
+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
@@ -211,7 +188,7 @@
`tomboy` directory created above)::
$ bzr init-repo newpackage
- $ cd new-package
+ $ 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
=== modified file 'udd-latest.rst'
--- udd-latest.rst 2011-05-20 15:26:22 +0000
+++ udd-latest.rst 2011-07-14 11:58:22 +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-14 11:58:22 +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-14 11:58:22 +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-14 11:58:22 +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-14 11:58:22 +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-14 11:58:22 +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``).
Follow ups
