__          __  _____   _____  
\ \        / / |_   _| |  __ \ 
 \ \  /\  / /    | |   | |__) |
  \ \/  \/ /     | |   |  ___/ 
   \  /\  /     _| |_  | |     
    \/  \/     |_____| |_|     

Updating packages using bzr

There are two slightly different workflows depending on whether a package has been previously released or not, to say that the latest entry in debian/changelog contains the word UNRELEASED (unreleased package) or the name of a Ubuntu release (released package).

Preparing for the work

First, you'll want to grab a copy of the branch on which you will be working. To do that, create a temporary directory and retrieve the branch:

$ mkdir -p ~/bzr
$ cd ~/bzr
$ bzr branch lp:b-sides

Do the work

Now that you've got a copy of the code on your system, just do the work:

$ cd ~/bzr/b-sides
$ cat >> some-file-I-want-to-change
additional lines and stuff...
^D
$

As much as possible, each individual change should be done in it's own revision, which helps in being able to know exactly what changed and being able to revert or cherrypick stuff you'd want elsewhere, etc. One your individual change is made, it's time to go and update the branch by doing a commit...

Updating the package

First, review the changes you've made, since you want to be sure everything is in place, and it helps to know what has been done to include it in changelog:

$ bzr diff

Once satisfied, look at changelog to know where to go and what to do next:

$ head debian/changelog

If changelog mentions UNRELEASED

That means someone has already been doing changes to the package, but the changes haven't been deemed important enough or ready to be released as a new version of the package, for various rCreating a releaseeasons. You'll want to add to it rather than bumping the version (or bump the version but keep it UNRELEASED):

$ dch -a 

Dch will add a new entry to the changelog below what is already there and put you name as the last maintainer to do changes. In the case someone else did something before you, the changes are attributed to the other maintainer too, in stanzas within the changelog entries.

If changelog mentions <ubuntu release>

If changelog shows a Ubuntu release name besides the version of the package (such as 'karmic' or 'lucid'), it means the last commit has been released, and you should bump the version number as you add your changes. You will want to do this following proper versioning according to the current development cycle's stade. [Add more information about proper versioning]

$ dch -i 

Dch will try to automatically increase the version number according to something it believes is sane, such as adding 'ubuntu1' to a Debian release, or increasing a '-0ubuntu2' release to '-0ubuntu3'.

Committing your changes

First, do one last check before committing that everything is in order: changelog should list your changes, and the changes should be visible in the diff:

$ bzr diff

Once you're ready, just run debcommit to push the changes to bzr and use your changelog entries as a commit message:

$ debcommit

Doing a release

After working for some time on an UNRELEASED changelog entry, you will most likely want to publish changes and push them to a PPA or upload to the archive. When that is the case, let dch do the work for you and change the entry to the right release:

$ dch -r

Dch will replace UNRELEASED by the currently running Ubuntu release, so be sure to change it to the development release if you intend to upload to the archives or REVU.

Then, get the changes committed:

$ debcommit -r

'debcommit -r' just commits to the working branch with the latest version number in changelog.

(If you used 'bzr branch') Push your changes

Now, just push your changes to the branch on Launchpad (or a copy in your personal branches if you don't have commit rights). You're done!

$ bzr push lp:b-sides
or
$ bzr push lp:~mathieu-tl/b-sides/my-b-sides-branch

Building a package with bzr

Building a .deb locally

$ bzr bd

"bzr bd" will use the get-orig-source rule in debian/rules to get a tarball (if it's not already available), and proceed through the other rules to build a package all the way to a .deb file that could be installed with dpkg, along with all supporting files.

Building a source package

$ bzr bd -S

"bzr bd" will use the get-orig-source rule in debian/rules to get a tarball (if it's not already available), and proceed to create a source package by generating the .dsc, .diff.gz and .changes files to go with the source tarball, so you can do an upload.

Examples

libcompizconfig

Here is a recipe for the compiz packaging group that works on a shared repository. The example shows how to checkout/update packages. It maybe useful for other teams too that use a central repository to keep their debian/ directory under VCS control. You'll need the bzr-builddeb package for the "bzr bd" command.

Here are the steps for a new checkout:

$ mkdir -p libcompizconfig/tarballs
$ cd libcompizconfig
$ bzr checkout sftp://$YOUR_LP_ID@bazaar.launchpad.net/~compiz/libcompizconfig/ubuntu/
$ cd tarballs
$ apt-get source --tar-only -y libcompizconfig
$ cd ../ubuntu
# do some changes.
$ dch -i
$ debcommit
$ bzr bd --merge  # build debs
$ sudo dpkg -i ../build-area/*.deb
$ bzr bd -S       # source only
[upload]

Here are the steps for a existing checkout and a new upstream tarball

$ cd libcompizconfig/ubuntu
$ bzr update
# edit away
$ cp new_orig_tarball ../tarballs
$ bzr bd --merge --builder "debuild -S -sa"
# upload tarball in ../build-area

TODO: add a example for a repository where the upstream source is imported into bzr as well.

If you are not a member of the UbuntuDevelopers team yet, you can get your contribution reviewed and uploaded through the SponsorshipProcess.

Go back to PackagingGuide/Recipes.
CategoryPackagingGuide
CategoryPackagingGuideRecipe