[tahoe-dev] Getting Tahoe into Debian (was: Re: linking pycryptopp against system provided cryptopp)

[Brian Warner]

> How about just 'tahoe'? Thats the name I was looking for when I first
> looked to see if it was in Debian.

Yeah, most of the folks who know about tahoe so far would look for that
name. We've been slightly concerned about how generic of a name it is.
Searching google for "tahoe" (and ignoring the skiing resorts and
oversized cars) doesn't hit allmydata.org until page 16 (behind the
tahoe.ca.sandia.gov numerical-methods project on page 2, an embedded
computer board on page 3, and a fluid engineering design software on
page 11). The best-known use of "Tahoe" in my networking circles is a
set of changes to the BSD TCP stack back in the 80s or 90s. I think we
also found a microsoft research project which was using the same name.

Zooko's been using the "tahoe lafs" acronym to emphasize the "Least
Authority File-System" aspect.. perhaps if we need something more
specific than "tahoe", then "tahoe-lafs" might be a good choice.

Anyways, this is probably a discussion that should take place on
debian-devel in response to the ITP.

> The first thing to do here would be to send a message to
> 499699 at bugs.debian.org, CC: 499699-submitter at bugs.debian.org (just in
> case), and ask Stephan what the status of this effort is, if its still
> happening, and if you can help in that process.

Ok, I'll ping Stephan about that.

> >  python-zfec (zooko's)
> >  python-pycryptopp (zooko's)
> 
> For these I think that an ITP[0] should be filed (I'm not sure if Zooko
> wants to handle those Debian packages, or if you would be doing them as
> well? Whichever it would be, one of you should file the ITP :)

Zooko, could you do this?

> Get it to build, and install on your system, if you aren't running an
> up-to-date sid system, you will want to get a chroot (or use pbuilder)
> to build in that environment. Then run lintian (linda is deprecated) to
> iron out any remaining issues. Once you think its all ready to go, give
> me the source package and I'll crawl over it like a monkey picking nits
> to make sure its up to snuff.

Ok. I run debian/sid everywhere. I'll look at the docs on
svn-buildpackage (and more likely darcs-buildpackage, since we keep the
upstream sources in darcs) to try and learn how to manage the .diff.gz
well.

> Lintian is just a checker you run against your build package, its
> separate from the diff.gz.

What's the recommended build process? Once upon a time I did:

 chmod +x debian/rules
 ./debian/rules build
 fakeroot debian/rules binary

But these days I do:

 debuild -uc -us

And I think that runs lintian for me. Is there some other command I
should be doing instead?

> You dont *have* to store your debian packaging work in a revision control
> system, but it sure makes life easier.

Of course.. I wouldn't consider doing this sort of work without VC. I'm
sure that darcs-buildpackage is not as widely used as, say,
svn-buildpackage, but maybe I can find a tutorial on the svn form and
then adapt it to my darcs work.


Thanks for all the references.. I'll see if I can make some progress on
this (in the form of a .diff.gz, .dsc, .orig.tar.gz for you to review)
in the next week.

cheers,
 -Brian