> 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 > [EMAIL PROTECTED], CC: [EMAIL PROTECTED] (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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
