Ubuntu Wiki

   1 [21:01] <SpamapS> Hello! And welcome aspiring, current, and potential packagers!
   2 [21:02] <SpamapS> The reason for this quick presentation is to disseminate some important Packaging Do's and Don'ts when working in Ubuntu, and when working things back upstream into Debian.
   3 [21:03] <SpamapS> Some of these are just my opinion, or are the general way that things are done in Ubuntu, and may not be compatible with the policies in every package in Debian and/or Ubuntu, so please as always be courteous when carrying this message forward.
   4 [21:03] <SpamapS> Also, some required reading, if you want to package software for Debian and/or Ubuntu:
   5 [21:03] <SpamapS> http://wiki.debian.org/IntroDebianPackaging
   6 [21:04] <SpamapS> There's also amazing information in here about ways to iterate and develop on packages in a clean and repeatable way:
   7 [21:04] <SpamapS> http://wiki.debian.org/mk-sbuild
   8 [21:04] <SpamapS> What not to do:
   9 [21:04] <SpamapS> * Panic!
  10 [21:04] <SpamapS> * Use CDBS for new things
  11 [21:04] <SpamapS> * Use dpatch (or any other patch system other than quilt)
  12 [21:05] <SpamapS> * Use svn for new things (bzr, git, hg, but please not svn)
  13 [21:05] <SpamapS> * Create complicated rules files
  14 [21:06] <SpamapS> CDBS is an old way of doing packages where you include hyper-genericised Makefile rules and then feed in variables to affect the behavior. You are much better off using debhelper.
  15 [21:06] <SpamapS> You'll find if you use 'dh_make' to create a new package, whatever it uses is a safe and suggested practice.
  16 [21:07] <SpamapS> dpatch has been deprecated for quilt. quilt is a patch maintenance system meant to help keep patches to upstream source code separate so they can be managed more easily.
  17 [21:07] <SpamapS> There is some work being done on bzr to add the 'looms' feature so quitl wouldn't be necessary, but I don't know how far along that is.
  18 [21:08] <SpamapS> I don't like svn, because if the server is down or you are not on the internet, you cannot do multiple changes, they end up stacking up as one giant diff.
  19 [21:08] <SpamapS> Just recently somebody suggested that bzr-svn or git-svn can be used to talk to svn for push/pull but have a local git/bzr tree, so that may work if you must use SVN for package maintenance.
  20 [21:08] <SpamapS> Now, WHAT TO DO:
  21 [21:09] <SpamapS> * As little as possible
  22 [21:09] <SpamapS> * use dh_make
  23 [21:09] <SpamapS> * use quilt
  24 [21:09] <SpamapS> * use VCS for packaging
  25 [21:09] <SpamapS> * use UDD for Ubuntu specific packaging
  26 [21:10] <SpamapS> What I mean by as little as possible, is that packaging shouldn't be about forcing your will on users, but rather on bringing upstream's software to users while remaining compliant with policy.
  27 [21:11] <SpamapS> Sometimes that means patching and moving things around and having default configs, and all of that is good, but the best package gets smaller as upstream gets feedback from packagers.
  28 [21:12] <SpamapS> skipping a bit.. about VCS ..
  29 [21:12] <SpamapS> There are multiple ways to use VCS to maintain packaging.
  30 [21:12] <SpamapS> in Ubuntu, all packages are (or at least should) be available via bzr by doing 'bzr branch ubuntu:packagename'
  31 [21:13] <SpamapS> Many Debian teams prefer to keep just the debian/ directory in a VCS, be it git or svn or bzr. Check with the maintainer of the package to find out how it is maintained.
  32 [21:14] <SpamapS> For UDD, the source and debian/ dir are kept together.
  33 [21:14] <ClassBot> dnewkirk asked: How ought we label the version of a package? I know that it is partly based on the version of the package itself, as well as perhaps including the .git info if other patches are needed. Is there a defined practice for this? I've looked at the wiki, but did not see a general policy for this.
  34 [21:15] <SpamapS> Package versions are made up of an upstream version, and a debian revision
  35 [21:15] <SpamapS> The upstream version is generally up to the upstream, and you should try to keep that as consistent with them as possible. Everything after the last - in the version of the package is the Debian revision.
  36 [21:16] <SpamapS> For Debian, it is just a montonically increasing counter.
  37 [21:16] <SpamapS> For Ubuntu, we add 'ubuntu#' to note that our version has superseded the debian version
  38 [21:16] <SpamapS> so if you are packaging foo version 1.2.3 for Debian, its   1.2.3-1  .. but if you are skipping Debian and adding it right into Ubuntu, it is 1.2.3-0ubuntu1
  39 [21:17] <SpamapS> a debian revision can include many many changes, as long as they are all spelled out in debian/changelog
  40 [21:17] <ClassBot> Ceno asked: What do VCS and UDD stand for?
  41 [21:17] <SpamapS> Version Control System
  42 [21:17] <SpamapS> Ubuntu Distributed Development
  43 [21:18] <SpamapS> I should have included a link to UDD .. if somebody can fish it out in chat, I'll paste it here as well.
  44 [21:18] <ClassBot> TiMiDo asked: do you need to have your GPG Sign by any devel Face to face, so they can verify you'r ID
  45 [21:19] <SpamapS> For Ubuntu, no, we use Launchpad as our trust network, and in theory, you don't need your key to be signed by Ubuntu developers. They just need to trust that your launchpad account is secure and lists the GPG key that is "you"
  46 [21:19] <SpamapS> For Debian, you do need to have your key signed by an existing Debian Developer, and most will insist on a face to face meeting.
  47 [21:20] <SpamapS> But if you just do packaging casually, you can have a sponsor sign your packages and upload them for you, which can also help for learning.
  48 [21:20] <SpamapS> http://developer.ubuntu.com/packaging/html/udd-intro.html
  49 [21:20] <SpamapS> noneed4anick: yes, thanks!
  50 [21:20] <ClassBot> There are 10 minutes remaining in the current session.
  51 [21:21] <ClassBot> TiMiDo asked: so if i am an ubuntu member i can contribute via launchpad, and of course using bzr so i can update the branch is that it?
  52 [21:21] <SpamapS> Being an Ubuntu member does not give you upload permissions or permissions to push to the bzr branches that host the packages. So no. You need to apply for those to the Developer Membership Board.
  53 [21:22] <SpamapS> I wanted to share then, a few helpful tools that have made my life easier in packaging.
  54 [21:23] <SpamapS> First is sbuild and mk-sbuild, which I mentioned earlier
  55 [21:23] <SpamapS> these build a working chroot filesystem on your machine that you can use to build packages in an isolated and clean environment.
  56 [21:23] <SpamapS> mk-sbuild in precise and later has a new flag, --eatmydata, which makes these even faster to use, as it disables the nasty dpkg habit of calling 'fsync' after every filesystem operation.
  57 [21:24] <SpamapS> I recommend editting /etc/sbuild/sbuild.conf and setting   $purge_session="successful" so that your failed builds will stay around and you can rejoin them with 'schroot -c sessionid'
  58 [21:24] <SpamapS> you can list the active sessions with 'schroot --all-sessions -l'
  59 [21:25] <SpamapS> Another one is 'licensecheck2dep5'
  60 [21:25] <ClassBot> There are 5 minutes remaining in the current session.
  61 [21:25] <SpamapS> When you are creating a new package, or importing a new upstream version, you need to make sure the source code licensing is well documented.
  62 [21:26] <SpamapS> you can run 'licensecheck --copyright -r .' in the root of the source and it will tell you all the copyright and licenses it can find (its VERY good at finding them)
  63 [21:26] <SpamapS> In the cdbs package, there is a helper script, 'licensecheck2dep5' that will take the output of that command, and turn it into an almost-complete debian/copyright file for you.
  64 [21:27] <ClassBot> jincreator asked: What's different between pbuilder and sbuild?
  65 [21:27] <SpamapS> jincreator, I used to be a pbuilder user, and now I use sbuild. Their basic premise is the same.. a chroot which you build inside to make things cleaner.
  66 [21:28] <SpamapS> jincreator: however, sbuild has a few advantages.. the biggest one being that it is what the Ubuntu buildds use, so you are closer to what Ubuntu will use to build your actual package.
  67 [21:28] <SpamapS> jincreator: there is also the fact that sbuild can make use of btrfs and/or lvm snapshotting to make schroot cleanup faster and less of a disk hog.
  68 [21:29] <SpamapS> Thats all I have today. If you want to get started packaging, I'd suggest coming to #ubuntu-devel, finding a bug, and working on it with us. Thanks for the excellent questions everyone!!