id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
251	make debian packages of dependencies	warner	zooko	"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 our 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).


"	task	closed	critical	1.1.0	packaging	0.6.1	fixed	debian