make debian packages of dependencies

[warner]

To release tahoe-0.7.0, we need debian packages of all runtime dependencies that aren't already in debian, so that the tahoe .debs will actually be usable.

That means:

• zfec-1.3.4
• pycryptopp-0.2.10
• foolscap-0.2.3

The zfec package should really depend upon argparse (/usr/bin/zfec requires it), so that means a debian package for argparse too.

Post-0.7.0, if we implement #47 and depend upon pyutil, then we'll need to make debian packages of pyutil-1.3.12 too.

Foolscap comes with its own debian packaging rules: just do 'make debian-feisty' or whatever.

Zooko's packages use setuptools, and I've been using the 'stdeb' utility to turn them into debian packages. It's not trivial. The first step is to install stdeb (perhaps from ​http://stdeb.python-hosting.com/), then have it generate a .orig.tar.gz, .dsc, and most importantly the .diff.gz debian files. The next step is to unpack the tarball and apply the patch, then run 'debuild -uc -us' or './debian/rules binary' or dpkg-buildpackage (or some other utility that I'm not familiar with) and see if it works. Note that it's best if a copy of the .orig.tar.gz is present in the parent of the working directory, because then debuild has something against which it can generate a new .diff file. Also keep a copy of the stdeb-produced .diff.gz somewhere else, since debuild will probably overwrite the one in the parent directory.

The resulting package must also be inspected to see if it has all the desired files: usually documentation, examples, and README files are missing and/or misplaced. Most importantly, the debian/control file needs to be updated to list all the debian dependencies that the package requires: it can usually figure out C/.so deps by itself, but it can't usually figure out python dependencies. Build-time dependencies also go into debian/control . Edit debian/rules and debian/control until things work the way they ought to, then run 'debuild'/etc again to regenerate the .diff.gz . Then copy the .orig.tar.gz and .diff.gz over to a new directory, unpack/patch/build to make sure it all works. Then the source .orig.tar.gz and .diff.gz get copied to buildslave@hanford:tahoe-debs/dists/DIST/main/source/ , and the .deb file gets copied to main/binary-i386/ .

This needs to be done for each debian/ubuntu release we support: edgy, feisty, gusty, etch, and sid. It would probably be nice to make amd64 versions as well, but we haven't ever done this before and it would require changes to out repository config to actually make them reachable.

The same .diff.gz can probably be used for multiple releases, although several minimum versions probably get recorded in the debian/control files, so if you choose this approach, you might want to run stdeb on our oldest supported platform (which would be edgy) rather than on the newest (sid). Either 1: copy the .orig.tar.gz and .diff.gz to a new host, run debuild, then upload everything to hanford, or 2: copy (on hanford) the .orig.tar.gz and .diff.gz (and .dsc) into DIST/main/source/ for all dists, then go to the debian build host and do 'apt-get update && apt-get source PACKAGENAME', which will grab the source from hanford and unpack it. Doing 'apt-get build-dep PACKAGENAME' will look at the build-time dependencies and install them, which can save a lot of time. If you choose this path, you'll only have to upload the .deb file to hanford.

Once you've added something to tahoe-debs/ , run 'make' in that directory and it will update the index and push a copy out to org.

Once something has been packaged, it is frequently sufficient to apply the old .diff.gz to the new release tarball, add an entry to debian/changelog, modify the version number that stdeb unfortunately embeds in debian/rules, then run debuild.

Debian build hosts:

• edgy: slave-edgy.allmydata.com (inside the firewall)
• feisty: tahoeslave-fesity (inside the firewall)
• gutsy: tahoecs2 (in colo)
• etch: slave-etch (inside the firewall)
• sid: fluxx (inside the firewall)

For reference, we use slave3.allmydata.com (in colo) as a dapper buildslave. We test tahoe on dapper but don't produce debian package for it (although I do make foolscap packages for dapper).