24 August 2010

Is packaging new software hard?

EDIT 1: Sorry Planet readers. I tried adding a "read more" thing to shorten it, but apparently that doesn't change the RSS feed, just the blog's front page. And yes, I will fix up the Ubuntu Wiki later.

A common answer to my question about why people aren't packaging is that packaging is hard and the wiki is kind of lacking. Debhelper 7 and Source Version 3.0 (the new Debian packaging format) make things a lot easier.

So is it hard? In the common case, no.

EDIT 2:Switched from "native" to "quilt" since as pointed out in comments, it makes for a smaller upload and debuild can deal with directly-applied patches in the case that you don't know how to use quilt.

Assuming the software you want to package uses something like Python distutils ( python setup.py build && sudo python setup.py install) or Autotools (./configure && make && sudo make install), Debhelper 7 makes things really straightforward.

Backing up, there are 4 files necessary in the debian/ directory:

  • rules
  • control
  • copyright
  • changelog

There are two more files you can include that act as a sort of metadata for what sort of package you're making:

  • compat
  • source/format

Assuming you want to make a Source Version 3.0 quilt package with Debhelper 7 (this is pretty normal these days):

  1. Rename the original source tarball to have the form <package name>_<upstream version>.orig.tar.gz
  2. Unpack the source and change into the unpacked directory: tar xf foo_bar.orig.tar.gz && cd foo
  3. Make a debian directory and enter it: mkdir debian && cd debian/
  4. Now it's time for those files
EDIT TO ADD

Generation

Good news: The version of dh-make in Debian SVN appears to support Debhelper 7.

Bad news It doesn't parse command line arguments properly.

In the meantime, you can use the old one to generate everything but the debian/rules file. If only a single deb will be produced, and it's under the GPLv3, that'd be dh_make -c gpl3 -s Then you'll just delete files not listed above and the debian/rules file and instead put in a debian/rules containing what I'm about to tell you below.

PS: I'm told dh_make is a pretty unclean way to do things. It's probably best if you just copy and paste the examples, then modify.

debian/rules

The boilerplate debian/rules file for standard build systems when you don't need to pass special configure options is:

#!/usr/bin/make -f

%:
 dh $@

Note that that is a tab, not a bunch of spaces, before the "dh". This used to be the most difficult file to write, which is why I used to use dh_make to generate it. Debhelper 7 made it so much easier!

debian/control

This one is long, but it's pretty easy to fill in the blanks. It's the only file of the bunch for which you might continue to need a reference. Here's how the control file should look:

Source: foo
Section: bar
Priority: optional
Maintainer: Foo <foo@example.com>
Build-Depends: eeny-dev, meeny-dev, miney, moe, debhelper (>= 7)
Standards-Version: 3.9.1
Homepage: http://foo-project.org

Package: foo
Architecture: all
Depends:  eeny, meeny, miney, moe
Description: does stuff
 Foo does stuff blah blah blah blah to make things easier for users to
 do whatever they need to do. Long description here.

Source package stanza

  • Source: Put the source package's name. This should be the same as the package name on the orig.tar.gz.
  • Section: For the list of valid Sections, see the Debian Policy Manual section on this. In Debian, you will put something like "non-free/kde" while in Ubuntu only the subsection (kde) is listed and the archive admins put it into the right section. In Debian, if the section is main, just list the subsection.
  • Priority: "optional" is what you want for most applications. Again, see the Debian Policy Manual section on Priorities for other options.
  • Maintainer: your name and email address if you are submitting to Debian, or if you are submitting to Ubuntu, put "Ubuntu Developers <ubuntu-devel@lists.ubuntu.com>"
  • Standards Version: current one (as of August 2010) is 3.9.1, and you shouldn't be starting from an out-of-date one
  • Homepage: the project's homepage

Binary package stanza

Now for the binary packages generated by the source package. For most applications, there will only be one binary package generated, but if there's more than one, just repeat the second stanza of this file once for each one, of course changing the values on each line.

  • Package: name of the binary package (the deb). Use logical names. If there's only one, feel free to repeat the source package's name.
  • Architecture:
    • all: if it can be built once and run anywhere (common for Python)
    • any: if it needs to be built everywhere
    • Otherwise, a list of architectures
  • Description: put a short description after the colon that can fill in the blank at the end of "$PACKAGE_NAME _____" with a short verb phrase (< 80 characters). On the lines below, put the long description with a single space at the beginning of each line. If you want a blank line, put a space and a period.

Build-Depends and Depends

I kept skipping the bit about Build-Depends and Depends. For these, you want to list the names of other binary packages (not source packages!). If a particular version is needed, parentheses and mathematical symbols (like where I put "debhelper (>= 7)") are used.

Usually -dev packages will be in the Build-Depends since that's where header files are in Debian and Ubuntu while non-dev packages will be in the binary package's Depends. You don't need to figure this stuff out completely on your own. The upstream README and INSTALL files should list what libraries are needed. If they're not, complain to upstream about bad documentation!

If you don't know what package provides a certain library, sudo apt-get install apt-file &&apt-file update then use apt-file search to find what package provides it.

Notes

These are the required lines. There are more available in the Debian Policy Manual (I keep referring to that, huh? It's useful!), such as Recommends and Suggests. How do these compare with Depends?

  • Depends: absolutely must be installed in order for the software to work
  • Recommends: useful and common to have with the package but not completely necessary.
  • Suggests: you want apt to notify the user that there's some other software that's kind of useful to use with it

Recommends are installed by default in Debian and Ubuntu nowadays, but some people disable them using sudo apt-get install --no-install-recommends foo, so the difference between Depends and Recommends is important. There are more less-commonly-used package relationships too, but you can read the Policy Manual for that.

PS: If you're packaging a Python app, "${python:Depends}" goes in the binary package's Depends line to avoid typing it all out.

I always find writing a good description to be the hardest part.

debian/copyright

The debian/copyright file is a pretty straightforward fill-in-the-blank.

This package was debianized by Your Name <you@example.com> on
Tue, 24 Aug 2010 20:05:25 -0400

It was downloaded from http://example.com

For the timestamp, run date -R and copy that in there. Make sure the copyrights are listed next, something like this (the COPYING or LICENSE file should have this at the top):

Copyright
© 2010, Author Name <author@example.com>

Double check this by running licensecheck -r in the top level code directory.

License:
The code files in this package are under the GNU General Public License
version 3:
    | This program is free software: you can redistribute it and/or modify
    | it under the terms of the GNU General Public License as published by
    | the Free Software Foundation, either version 3 of the License, or
    | (at your option) any later version.

    | This program is distributed in the hope that it will be useful,
    | but WITHOUT ANY WARRANTY; without even the implied warranty of
    | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
    | GNU General Public License for more details.

    | You should have received a copy of the GNU General Public License
    | along with this program.  If not, see <http://www.gnu.org/licenses/>.

    The full text of the GNU General Public License version 3 is available on
    Debian systems in /usr/share/common-licenses/GPL-3.

Depending on licensecheck's output, you may need to list multiple licenses.

debian/changelog

This is the easiest of the files that require you to do any thought. Run dch -i --create, fix your email name and email address to match who you are, and put in an explanation. In future, you'll just run dch -i to add another entry. Explain what you did to the package. In this case, it'll likely just be "Initial release" which is pretty simple. dch should set the right version number. It'll look something like:

foo (0:1.0-0ubuntu1) maverick; urgency=low

  * Initial release

 -- Your Name <you@example.com>  Tue, 24 Aug 2010 20:05:25 -0400

The first bit is the same as the source package name and will automatically be filled in. The part in parentheses is the package version. It is in the form <epoch>:<upstream version>-<debian version>ubuntu<ubuntu version>

If you're doing the initial packaging, the epoch is 0, and the upstream version will be automatically filled in from the .orig.tar.gz.

  • Debian: Debian version will be 1
  • Ubuntu: Debian version is 0 and Ubuntu version is 1
  • PPA: put 0s for both of those and add +ppa1 (or +yournick1 or whatever)

Next comes the version of Debian or Ubuntu for which you are packaging. Leave urgency at low for now. You're packaging an app, not the kernel. It just affects how quickly the build servers get around to it, and abusing this field will make people Not Happy.

Other files

For the debian/source/format and debian/compat files, just run echo "7" > compat and mkdir source && echo "3.0 (quilt)" > source/format

Time to build!

The hard part is done, and that really wasn't very hard given it's pretty much just fill-in-the-blank the whole way. Now to build and test. My preferred way to test builds is to use pbuilder. It uses a minimal chroot, so your build-dependencies get tested too.

  1. Install the build dependencies you listed in debian/control
  2. sudo apt-get install pbuilder ubunt-dev-tools devscripts (If I missed any, tell me in comments)
  3. Generate the source package: debuild -S—a .debian.tar.gz, a .dsc, and a .changes file will show up in the same directory as the .orig.tar.gz
  4. Make a pbuilder to build your package: ln -s /usr/bin/pbuilder-dist ~/pbuilder-maverick && ~/pbuilder-maverick create—substitute in whatever version of Debian/Ubuntu you are building for (same as you listed in changelog)
  5. Build the source package: ~/pbuilder-maverick build ../foo*.dsc—.debs will be output in ~/pbuilder/maverick_result

PS: The "make a pbuilder" step only has to be done once per release on which you intend to ever build. Keep it up to date with ~/pbuilder-maverick update

If it all builds successfully, congrats! If it doesn't, either you forgot a build dependency or it's not a wonderfully straightforward application and you should visit #ubuntu-packaging on Freenode or #debian-mentors on OFTC for help debugging. We're friendly!

Test

Install the debs and test it out.

Upload

You'll need to sign the package before you can upload it anywhere, if it didn't get signed when you ran debuild (the output would have told you if it did). Generate a GPG key and use debsign -k<your key ID> foo*.changes to sign it. If you're working on Ubuntu, add your key to Launchpad or if Debian add it to Debian Mentors. Then run dput mentors foo*.changes for Debian Mentors or dput revu foo*.chanes for Ubuntu's REVU (where new packages are reviewed by MOTU for inclusion in the archive). You'll get feedback from a mentor or a MOTU, improve your package based on that, and then someone will sponsor it. Or you can upload to a PPA with dput ppa:user/ppa foo*.changes


36 comments:

Ryan said...

This is a pretty good guide to packaging, but if I wanted to package something, I would have to keep referring to this guide. Ideally, a single command would create all the necessary files with a bunch of placeholder values filled in, and then it would say "Go look for anything in [brackets] and replace it with something meaningful. And with a bunch of comments in the files explaining how to fill in each blank.

You could probably convert this blog post into a simple bash script that does just that for the entire debian/ directory.

Mackenzie said...

That's what dh_make did, but it was for the old Source Version 1.0 and didn't know about Debhelper 7's new super-short file. Really, the control file is the only one you end up needing a reference for after one or two times.

Kevix said...

http://mysite.verizon.net/kevin.mark/debian-package.png
I made that diagram to explain some of the details of a debian package. I need to find the source for it. but if you see anything missing (like the new source package format or ubuntu difference) feel free to mention it.
Great intro to packaging!

Greg said...

One quick thing, the package for pbuilder is pbuilder, not pbuilder-dist.

Otherwise, thanks for this intro. You should also note that the pbuilder create step takes a while.

Mackenzie said...

Ah, pbuilder-dist is provided by ubuntu-dev-tools. Whoops!

Mackenzie said...

Just found that dh_make can do dh7 packages, so updated to reflect that.

Laney said...

Actually, most packages don't need to be native, and arguably don't even need to be 3.0 at all. I'd rather advise 3.0 (quilt), 1.0 or not mention debian/source/format.

doctormo said...

maco, I've been scripting and writing out a guide for packaging for this cycle. I've got a lot of this sort of stuff done but it needs more editing a such.

We should talk on IRC.

Zelut said...

While I think you've done a good job of documenting (and improving the current documentation) for creating Debian packages, I still believe the whole process is *far* more complicated than it needs to be.

After years with Ubuntu I still have to refer to documents and ask for help when creating or updating packages. On the other hand, after two weeks using Arch Linux or even FreeBSD I was able to create my own compliant packages.

Keeping it simple is key, and this has left that in the dust.

Loftus said...

To echo Zelut's comments, the amount of random stuff debian requires you to do is simply ridiculous.

1. Why am I creating a rules file which seems to have nothing in it? Why can't the packager assume this is the case without a rules file.

2. Why can't my control file be inferred from by build system. pkg-config is the standard these days.

3. Why do I need to specify a source and binary stanza? Surely I want both anyway.

4. Why am I writing a changelog? This comes from the VCS in modern projects.

5. My final gripe is with all the random arguments the packaging tools seem to take. "debuild -S -uc -us—a .debian.tar.gz" ?

I think my general point is that in making everything so flexible, in the makefile format and with lots of shell scripts there is no "right way to do something". Debian packaging reminds me of writing autotools build files and that is not a good thing!

Mackenzie said...

Zelut:
How are 4 mostly-boilerplate files "too complicated"?


Loftus:
1. Because you need to have a rules file, period. There's a "guess it" syntax which I showed, but if you need to do extra things like install a .desktop file that you made that's not in the source package, you'll have override_dh_* commands to add to it.

2. How are the maintainer name, section, priority, and compatible architectures supposed to be inferred from the build system? And even if it can sort out which exact .lib.so's are build-dependencies from pkg-config, how is it supposed to know the names of the binary packages? And what about runtime dependencies? Those aren't accounted for.

3. As I said in the post, you can have more than one binary stanza because you can have more than one binary from a single source package.

4. In Ubuntu we do it the other direction when updating a package. We edit debian/changelog, then run "debcommit" to commit to bzr with a changelog entry based on debian/changelog. I don't know how the changelog would be expected to pull information from the VCS when you're starting from a tarball though. Besides, have you read VCS changelogs? There's a lot of "whoops, missed a semicolon"


5. "—a .debian.tar.gz" isn't one of the arguments. It's some text after the </code> You can leave off the "-uc -us" and skip the debsign part at the end too if you have environment variables setup to give your proper key, but since I didn't go over those environment variables, I gave the long form.
-S = source package
-uc = unsigned .changes
-us = unsigned .dsc

matt said...

Thanks for doing this Mackenzie! It's a great condensed overview of packaging!

Perhaps the only thing I would add to this is that I think you should have mentioned packaging with code in bzr (bzr bd, dch, debcommit and all of that), and some of the things you proposed, like the copyright file, may need some more work to get the package in Debian. At least personally, I'm quite fond of the DEP-5 (machine-readable) kind of copyright files.

Mackenzie said...

Laney:
I wasn't sure whether I should say native or quilt. I asked in #ubuntu-motu and they said leave it as native because Quilt isn't something to explain to a new person. For me, Quilt was the dragon I had to tame before I was willing to apply to MOTU.

SV 3.0+dh7 is because I figure might as well learn the new way if you're new rather than the mess of old ways that are going out the window anyway. "Here, learn this, then by the time you go to apply for DM/MOTU, it'll be gone anyway." Yuck.

Mackenzie said...

Matt:
When I had a DD/MOTU friend read over this before posting he mentioned DEP-5, but since I've never encountered a package with it, I didn't feel comfortable writing about it without any experience.

Loftus said...

> Because you need to have a rules file, period.

Thats just dogma. You have a rules file because debian says you have to. Why cant the packager look for .desktop files and do the right thing. These should be listed in the build system somewhere anyway.

> How are the maintainer name, section, priority, and compatible architectures supposed to be inferred from the build system?

Put them in the build system.

> And even if it can sort out which exact .lib.so's are build-dependencies from pkg-config, how is it supposed to know the names of the binary packages?

Can't dpkg do this with some random flag? e.g. dpkg --find-the-package `ldconfig `pkg-config --libs gtk`` or whatever.

> And what about runtime dependencies? Those aren't accounted for.

I don't really follow this. Anyway they should also be in the build system for developers who are running from source.

> As I said in the post, you can have more than one binary stanza because you can have more than one binary from a single source package.

Thats an edge case though right? The point is to have a sensible default.

> In Ubuntu we do it the other direction when updating a package. We edit debian/changelog, then run "debcommit" to commit to bzr with a changelog entry based on debian/changelog. I don't know how the changelog would be expected to pull information from the VCS when you're starting from a tarball though.

Why would starting from tarballs ever be a good idea? If you didn't allow starting from a tarball it would lower the amount of ways packaging can happen and reduce the complexity and learning curve.

> Besides, have you read VCS changelogs? There's a lot of "whoops, missed a semicolon"

Then use a summarized output or filter out 1 line changes, or write better changelogs.

>
-S = source package
-uc = unsigned .changes
-us = unsigned .dsc

My point is there are lots of random arguments to the scripts which are impossible to remember. I have actually made a few (ppa) packages. I'm just letting you know I found the experience quite frustrating.

José Ernesto said...

I got confused about the ppa version, it should be like (binary--0ubuntu0+ppa1) ???

JontheEchidna said...

>> Because you need to have a rules file, period.

>Thats just dogma. You have a rules file because debian says you have to. Why cant the packager look for .desktop files and do the right thing. These should be listed in the build system somewhere anyway.

No... it's just that debuild won't *work* without a rules file. .desktop files have nothing to do with this. The rules file tells debuild how to make debs.

>> How are the maintainer name, section, priority, and compatible architectures supposed to be inferred from the build system?

>Put them in the build system.

This would require patching every upstream build system ever. Having a source package stanza in debian/control is much easier.

>> And even if it can sort out which exact .lib.so's are build-dependencies from pkg-config, how is it supposed to know the names of the binary packages?

>Can't dpkg do this with some random flag? e.g. dpkg --find-the-package `ldconfig `pkg-config --libs gtk`` or whatever.

It still wouldn't be able to handle version requirements for dependencies. Not to mention non-library dependencies that cannot be automatically determined.

>> And what about runtime dependencies? Those aren't accounted for.

>I don't really follow this. Anyway they should also be in the build system for developers who are running from source.

Yeah, these are the non-library dependencies I mentioned just above. Every distribution does this differently, and there would be no way in heck that this could ever be determined by the source.

>> As I said in the post, you can have more than one binary stanza because you can have more than one binary from a single source package.

>Thats an edge case though right? The point is to have a sensible default.

Not really, it's quite common for "coolapp" to have "coolapp" for the binaries, "coolapp-data" or "coolapp-common" for the platform-agnostic data files, "coolapp-dbg" for debugging symbols, and even in some cases "coolapp-l10n" for translation files. Not to mention that a lot of source packages (KDE for example) build lots of applications from one tarball, and can have half a dozen or more binary packages. Not a corner case at all.

mario said...

Scrape that! Nobody should waste time on getting dpkg to work. If you're an application developer look into EPM. It builds .deb and .rpm packages (and others) from a single source. And it's way easier to get started.
Don't lock yourself into a single distribution or its convoluted and archaic build tools! dpkg-deb is meant SPECIFICALLY for Debian/Ubuntu package maintainers, not for independet developers.

Mackenzie said...

Hey Mario, if you were paying attention, you'd have noticed that the first paragraph (after the "edit" one I mean) of the article is talking about a question I asked earlier about why people aren't packaging. That is, the previous post on this blog, which is specifically discussing becoming an Ubuntu Developer. So yes, explaining packaging to people so they can more easily become Ubuntu Developers MAKES PERFECT SENSE.

Raphael Hertzog said...

3.0 (native) is not a good choice, your .orig.tar.gz is not used and you recreate a complete tarball on each upload. BTW, debuild would warn you that a native package with a dash is unusual.

3.0 (quilt) is the correct choice, you don't have to explain quilt if they don't plan to apply modifications to the upstream code. And even if they do, they don't have to know quilt from the start since dpkg-source would generate a new patch automatically for the user.

Stapel en Anel said...

Apparently, it is hard! I have never attempted something like this before, but I saw your blog post and thought I'll give it a go.

1. Downloaded the latest gnash tarball.
2. renamed and created debian directory
3. run db_make -c gpl3 -s

If I run this from within the debian directory it complains about not being able to understand the directory name. If I go one level up and run it, I get the following:
Hit to confirm:
Skipping creating ../gnash_0.8.8.orig.tar.gz because it already exists
You already have a debian/ subdirectory in the source tree.
dh_make will not try to overwrite anything.

...and debian directory is still empty. Maybe gnash is just the wrong package to start this learning curve with?

Any ideas?

Stapel en Anel said...

Ok, it seems this guide is using a later version of dh-make than is available form the Lucid repositories.

I deleted the debian directory and and ran dh_make and it created a debian folder with all the goodies inside.

Paraneetharan Sweet&hot said...

Good guide indeed. Thanks for your efforts Mackenzie.

stapel said...

A couple of questions:
1. gnash seems to consist out of a couple of packages, gnash, gnash-common, mozilla-plugin-gnash, gnash-tools, etc. Do I build all these packages from the same tarball?

2. If I want to create a binary package, do I need to compile the source tarball first, with configure & make, before I create the package.

If it sounds like I'm too far out of my depth please let me know (gently) so I can stop now, and maybe attempt an easier package.

stapel said...

Okay, so "db_make -c gpl3 -m" lets you create multiple binary packages.

It automatically puts stubs in the control file for 3 of them. Can I add more myself?

Mackenzie said...

Stapel:
If you're using dh_make, don't make the debian/ directory first.

Also, don't use dh_make. Copy and paste what I supplied. Only the SVN version of dh_make knows how to do dh7 rules fils, so you'll end up with a rules file neither you nor I can really understand, and (as I said in the PS), dh_make is really unclean. By that I mean: you'll have errors in the package that you'll be expected to know how to fix if you submit it on REVU. Just do it the way I explained.

Mackenzie said...

stapel:
No, don't configure & make first. Always upload source packages in Ubuntu. debuild/pbuilder make the binaries.

Yes you can add more binary stanzas, but I think dh_make should've made some files called *.install in debian/ directory. These say which files end up in which binary package, so if you want to rearrange things, you need to edit those.

stapel said...

Where does debuild/pbuilder reside? Does it execute automagically when you upload your package?

>Yes you can add more binary >stanzas, but I think dh_make >should've made some files called >*.install in debian/ directory. >These say which files end up in >which binary package, so if you >want to rearrange things, you need >to edit those.
I thought I shouldn't use dh_make?
How do I know exactly how many packages I should make? How do I figure out the dependencies for each?

Mackenzie said...

stapel:
debuild is one of the commands listed in this post. I specifically say "debuild -S" which makes a source package, though leaving off the -S you'd get a binary package. It wouldn't be cleanly built though (wouldn't test build dependencies), so I explained in the post how to setup and use pbuilder.

Right, you shouldn't really use dh_make, but since you already did...

How many binary packages to make is up to you. You could make it all one, or you could split it out. If you split out so config files are in -common, make sure the main binary package depends on -common too so that the config files are there. I think concerns about the size of the download when it's not all necessary (say the docs are huge, but you don't need them to run the thing) tend to drive splitting packages up.

stapel said...

just run echo "7" > compat and mkdir source && echo "3.0 (quilt)" > source/format

I think this should be
just run echo "7" > compat && mkdir source && echo "3.0 (quilt)" > source/format

Mackenzie said...

Sure you could do it like that if you were running it as one command. The "and" was just the English word "and" between two separate commands in a paragraph, though.

Hmm Loftus also made the mistake of mashing some English in with the code. Are the default monospace fonts in Ubuntu so crappy that they can't be seen as separate things from the sans-serif font?

stapel said...

>Are the default monospace fonts in >Ubuntu so crappy that they can't be seen >as separate things from the sans-serif >font?
Yes I think so.

Anyway, I'm trying to build my package and I get the following errors:

dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh clean
make: dh: Command not found
make: *** [clean] Error 127
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
E: Failed autobuilding of package
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build//30838 and its subdirectories

Any ideas?

stapel said...

I have made some progress. I realised debhelper (>= 7) must be one of the build-depends, and was not just left in your control script as an example.

Anyway, now I get the following error:
dh_auto_configure: ./configure --build=i486-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libexecdir=${prefix}/lib/gnash --disable-maintainer-mode --disable-dependency-tracking returned exit code 1
make: *** [build] Error 9
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package

Mackenzie said...

Yes that one was there intentionally ;-) Are you using dh_make's rules file or the dh7 one I wrote in the post? Is that error output when you run "debuild -S"? If so, do you have all of the build-dependencies installed?

stapel said...

debuild -S was sucessful, except for erors related to my GPG key which I haven't got.

The error is from the last step. I am using your rules file. (I have put the tab in)

Jonas said...

sudo apt-get install pbuilder ubunt-dev-tools devscripts

must be

sudo apt-get install pbuilder ubuntu-dev-tools devscripts