Dev Week -- Bazaar and packaging -- jelmer -- Thu, Jan 28


   1 [19:05] <jelmer> Thanks!
   2 [19:05] <jelmer> Hello everybody!
   3 [19:06] <jelmer> I'm Jelmer Vernooij, one of the Bazaar developers and an occasional contributor to Debian and Ubuntu
   4 [19:06] <jelmer> I'll be leading the next class about packaging with Bazaar
   5 [19:07] <jelmer> For this class you will need the bzr-builddeb package
   6 [19:09] <jelmer> Today we'll have a look at packaging branches on Launchpad, building packages from a branch and making changes to a packaging branch.
   7 [19:10] <jelmer> Is everybody here familiar with Bazaar, or should I give a quick introduction to it as well?
   8 [19:11] <jelmer> Great, let's dig into obtaining a packaging branch
   9 [19:11] <jelmer> As of a couple of releases ago, Launchpad supports packaging branches
  10 [19:11] <jelmer> You can find the packaging branches for a particular package by clicking on "Branches" when viewing a source package on Launchpad
  11 [19:13] <jelmer> For example, contains the packaging branches for the 'tdb' package
  12 [19:14] <jelmer> These branches are different from the upstream branches that live at<project>, and contain upstream
  13 [19:14] <jelmer> QUESTION: can you clarify what a package branch is, and how it's different from a regular branch
  14 [19:15] <jelmer> A package branch is a bzr branch that contains a source package, i.e. the upstream including any changes that have been made to it and the debian/ directory
  15 [19:16] <jelmer> Other than the contents there isn't anything special about a packaging branch
  16 [19:17] <jelmer> lists all of the Ubuntu packaging branches, but James also imports the Debian archive
  17 [19:17] <jelmer> for example, you can have a look at which contains the Debian packaging branches
  18 [19:17] <jelmer>  QUESTION: how do you keep the code in a project branch and it's associated package branch in sync?
  19 [19:19] <jelmer> You can use the "bzr merge-upstream" package to merge in new upstream tarballs
  20 [19:19] <jelmer> This command will also take care of setting the right tags, etc
  21 [19:20] <jelmer> But before we get ahead of ourselves..
  22 [19:20] <jelmer> Let's check out the tdb package and try to build it
  23 [19:20] <jelmer> If you're familiar with bzr this should be no surprise to you:
  24 [19:20] <jelmer> $ bzr branch lp:ubuntu/tdb tdb-lucid
  25 [19:21] <jelmer> After this, you should be able to go into the branch and run "bzr builddeb" (or "bzr bd" for short)
  26 [19:21] <jelmer> this will export the current working tree and try to build it
  27 [19:22] <jelmer> QUESTION: What is the standard naming convention of a bzr ? lp:~ for some and it's lp:<version>/<project> for some..
  28 [19:22] <jelmer> For upstream branches, it is always ~OWNER/PROJECT/NAME
  29 [19:23] <jelmer> for packaging branches, it is ~OWNER/DISTRO/SERIES/PACKAGE/NAME
  30 [19:23] <jelmer> but there are some abbreviated names available - if SERIES is the development series, you can get by by just specifying the DISTOR and the PACKAGE
  31 [19:24] <jelmer> QUESTION:is there a way to search the lp bzr from cli?
  32 [19:25] <jelmer> There is no way to query the lists of branches on Launchpad using the bzr cli at the moment
  33 [19:26] <jelmer> Mainly because nobody has had the time to add it yet, patches to add such support would certainly be welcome :-)
  34 [19:26] <jelmer> (It should also be possible to run "bzr bd lp:ubuntu/tdb", but I haven't tried that in a while)
  35 [19:27] <jelmer> now that we've built the package, let's have a look at making some changes
  36 [19:27] <jelmer> The idea is that in the future it will be possible to upload a new version of package simply by pushing to lp:ubuntu/<packagename>
  37 [19:28] <jelmer> we're not quite there yet, at the moment you will still have to manually build the sourcepackage and upload it.
  38 [19:29] <jelmer> (upload it using dput, that is)
  39 [19:29] <jelmer> There are importer scripts, run by james_w, that update lp:ubuntu/<package> to match whatever has been uploaded using ftp.
  40 [19:29] <jelmer> QUESTION: my build failed because it couldn't sign the package
  41 [19:29] <jelmer> you can use "bzr bd -- -uc -us" to skip the signing, as I assume most of you won't have access to my private GPG key ;-)
  42 [19:30] <jelmer> QUESTION: Do ubuntu-stable-release updates work the same way, except one proposes a merge instead of attaching a diff to a bug?
  43 [19:31] <jelmer> I'm not familiar with the ubuntu-stable-release process, can somebody else tell perhaps?
  44 [19:31] <jelmer> QUESTION: If I want to create a new package branch for a package not yet in Ubuntu, where should I put it?
  45 [19:32] <jelmer> That's a good question - at the moment it is not possible to push a new branch for a package that doesn't exist in Ubuntu yet
  46 [19:32] <jelmer> So at the moment you will have to wait until the first version of your package has been uploaded before you can push your branches
  47 [19:33] <jelmer> Supporting pushing before the upload is something that is on the todo list of the launchpad developers.
  48 [19:34] <jelmer> Let's have a look at making a change and preparing an upload.
  49 [19:34] <jelmer> Let's make a dummy change, perhaps fixing the outdated docs?
  50 [19:34] <jelmer> $ echo "Don't panic." > docs/README
  51 [19:34] <jelmer> Next, we should of course update the changelog:
  52 [19:35] <jelmer> $ dch -i "Fix the documentation. "
  53 [19:35] <jelmer> When we would like to commit this change, the only thing we have to do is run "debcommit"
  54 [19:36] <jelmer> $ debcommit
  55 [19:37] <jelmer> debcommit will create the commit in Bazaar and will automatically figure out the correct commit message based on the changes to the changelog
  56 [19:37] <jelmer> Next, we should be able to build the source package that we'd like to upload
  57 [19:37] <jelmer> e.g. "bzr bd -S" (-S for source package)
  58 [19:38] <jelmer> QUESTION: why is debcommit separate from the bzr- builddeb commands?
  59 [19:38] <jelmer> debcommit is part of the debian developer scripts, and works for a variety of version control systems
  60 [19:39] <jelmer> in newer versions of bzr-builddeb you can also use just "bzr commit"
  61 [19:39] <jelmer> and bzr will fill in a suggested commit message, similar to the one debcommit uses
  62 [19:40] <jelmer> once you have uploaded the package and are happy with it, you should tag the version in bzr by running "bzr mark-uploaded"
  63 [19:40] <jelmer> "bzr tags" should list all of the existing tags
  64 [19:42] <jelmer> the tags should all you to easily navigate all of the versions of a package using bazaar
  65 [19:43] <jelmer> An easy way to browse the history is by using "bzr viz" from the bzr-gtk package
  66 [19:43] <jelmer> Another command that is provided by the bzr-builddeb package is "bzr import-dsc"
  67 [19:44] <jelmer> This command allows you to import existing tarballs that have been published in the past
  68 [19:44] <jelmer> it is the main engine behind the importer scripts that create the branches owned by ~ubuntu-branches
  69 [19:45] <jelmer> bzr-builddeb also includes two commands for merging changes into your packaging branch: import-upstream and import-package
  70 [19:46] <jelmer> import-upstream allows you to import a new upstream version into your package - you specify a tarball and a version string and it will take care of updating your packaging branch and update a new entry to the debian changelog
  71 [19:46] <jelmer> s/update/add/
  72 [19:46] <jelmer> and s/import-upstream/merge-upstream/, obviously - sorry
  73 [19:46] <jelmer> merge-package allows you to merge from another packaging branch
  74 [19:47] <jelmer> for example, if you need to merge changes from a debian packaging branch you can use merge-package
  75 [19:47] <jelmer> among other things, this will take care of merging debian/changelog in a smarter way than "bzr merge" does
  76 [19:47] <jelmer> Is everybody keeping up so far?
  77 [19:48] <jelmer> merge-package should no longer be necessary after the next bzr release, when "bzr merge" will just Do The Right Thing.
  78 [19:49] <jelmer> That concludes what I wanted to talk about - are there any more questions or would you like me to expand on anything?
  79 [19:50] <jelmer> QUESTION: I noticed multiple .deb packages were made, does a package branch create more than one package?
  80 [19:51] <jelmer> A package branch is like a versioned source package - like a source package multiple binary packages can be created from it
  81 [19:52] <jelmer> QUESTION: are there some good resources for someone new to debian packaging to better understand the structure and process?
  82 [19:53] <jelmer> You might want to read the log from the getting started session:
  83 [19:54] <jelmer> There are also some good resources on the wiki and in the Debian developer corner
  84 [19:55] <jelmer> QUESTION: years ago, I think I read 'bazaar' and 'bzr' were two different, closely related programs, maybe forks. Is this true nowadays? Is 'bazaar' exactly the same as 'bzr'?
  85 [19:55] <jelmer> The bazaar project has had two different incarnations: "baz" (written in C, derived from arch) and "bzr" (written in Python, from scratch)
  86 [19:56] <jelmer> baz used to own the package name "bazaar" but has been removed from the archive now, "bzr" is the current app that we work on. The "bzr baz-import" command can import from old repositories.
  87 [19:58] <jelmer> (The developers that used to work on baz all work on bzr these days)
  88 [19:59] <jelmer> Any other questions? Feature requests? Rotten tomatoes?
  89 [20:00] <jelmer> QUESTION: unrelated, but is there a bzr plugin like mercurial queues?  I know about loom, but it doesn't let change the order or patches, etc
  90 [20:01] <jelmer> There is also bzr-pipeline, which is similar to but not entirely unlike looms.
  91 [20:02] <jelmer> I'm not sure if it supports reordering of patches, but you might want to check it out.
  92 [20:02] <jelmer> Thanks for your attention, happy hacking!
  93 [20:02]  * kfogel claps for jelmer

MeetingLogs/devweek1001/BzrAndPkgs (last edited 2010-01-29 10:11:13 by i59F765F3)