[tahoe-dev] state of debian packages

Brian Warner warner at lothar.com
Thu Aug 6 17:17:04 PDT 2009

I've spent the last day looking into the state of Tahoe-on-Debian. I've
updated the table at
http://allmydata.org/trac/tahoe/wiki/DownloadDebianPackages with my best
guess at the current situation. I removed the "debian users should build
from source" note at the top, in preference to the updated table of
which debian users can and cannot use "apt-get install".

Basically, hardy/i386 users should be ok, and lenny/sid users should be
able to get by. Everyone else is out of luck.

The main issue is that we only have pycryptopp debs for a few platforms
(hardy/i386, lenny/i386 which should also work for sid). We used to have
pycryptopp debs for every platform that we built tahoe debs, but when
the pycryptopp dependency was upped a few weeks ago, those older debs
ceased to meet the requirement, and new ones have not been built. I
started to look into building those debs myself, but it's not easy:
stdeb is a good tool but still rough, and imposes dependencies of its
own (like debhelper7, which isn't available for anything earlier than

So, I guess it might be time to give up on some of these platforms. The
ones that are most important to me are:

 * debian/sid, because that's what I run
 * latest debian release, i.e. lenny
 * latest ubuntu release, i.e. jaunty
 * latest ubuntu LTS release, i.e. hardy

Also, I personally run i386 and (to a lesser extent) amd64, nothing
else. Tahoe and foolscap are pure-python and therefore
architecture-independent, but the heavy lifting done in zfec and
pycryptopp are arch-dependent. So to support e.g. nexenta or armel,
we'll need pycryptopp/zfec debs produced on such systems.

This would mean we'd stop creating debs for
etch/edgy/feisty/gutsy/intrepid, since without a pycryptopp deb they'd
be useless.

To fill in the gaps, we need:

 * tahoe buildslave for jaunty (both i386 and amd64)
 * tahoe buildslave for lenny (both)
 * tahoe buildslave for sid (amd64)

The sid buildslave is trickier, since sid is (by definition) a moving
target). It should probably be a developer's personal box which gets
updated on a regular basis. I run the sid/i386 buildslave, but I don't
think it's currently producing debs of any sort.

I'll see what I can do about setting up a jaunty slave.. it might be
easiest to cannibalize our edgy slave.

more later,

More information about the tahoe-dev mailing list