I updated the tahoe debian/control rules to declare a dependency upon pycryptopp-0.5.15: the tahoe .debs now correctly refuse to install.
Zooko: I set up a bunch of "flappserver upload-file" services for uploading tahoe .debs to the repository on hanford (which gets mirrored to allmydata.org). Let's do the same for the pycryptopp debs.
In buildslave@hanford, do this one or more times:
flappserver add ~/.flappserver -C DIST/main/binary-i386 upload-file ~/tahoe-debs/dists/DIST/main/binary-i386
(setting DIST appropriately for each time)
Each time you run that, it will emit a furl. Copy this to the buildslave, stored in something like ~/main-deb.furl . Then add an upload step to the buildmaster config, which runs:
flappclient --furlfile ~/main-deb.furl upload-file ../pycryptopp*.deb
You should also copy the "tahoe-update-apt.furl" and have a step to update the APT index by running
flappclient --furlfile ~/tahoe-update-apt.furl run-command
(take a look at any of the tahoe deb builders for an example)
I don't know how you ought manage the variety of platforms, though. We build
and host tahoe debs for etch/edgy/feisty/gutsy/hardy/hardy-amd64, so it'd be
nice to provide pycryptopp debs for all of those. The tahoe .deb process only
actually has rules for etch, lenny, and sid: basically we use the etch rules
for the py2.4 platforms (etch and edgy), sid for sid, and lenny for
everything else. But we run those rules on actual edgy/feisty/etc systems so
they declare the right dependencies (in general you can't install a newer deb
on an older system, because it will declare a dependency upon newer versions
of libc, etc).
You'd need to find some similar mapping for pycryptopp, and create debs for
all the same platforms we do for Tahoe. It sounds like you're only currently
creating debs for one of those platforms (sid), and that .deb probably won't
install on any of the earlier ones.
