[tahoe-dev] planning for v1.5.1: fully pre-packaged! (apt-get, Windows installer, Mac package)

[Andrej Falout]

Just to suggest that Ubuntu does not equal Linux, and .deb is not the Linux
packaging format.

The fact is that RPM distributions such as RedHat, Fedora and derivates and
Suse and derivates, and many other RPM based distros have larger number of
users then Debian based distros. And in the corporate space this is probably
about 10 to 1 in RPM favor.

I would offer to help with RPMs as such, as I built them in the past, but
looking at Python parallel installation methods that bypass the operating
system packaging I would not have a clue what to do with Python dependencies
that seem to get liberally sprinkled all over the system. Two or three times
in four or five versions...

But if anyone has questions about RPM, I'm happy to answer them.

Andrej Falout


On Fri, Aug 7, 2009 at 4:59 AM, Zooko Wilcox-O'Hearn <zooko at zooko.com>wrote:

> Folks:
>
> There has been a lot of interest in Tahoe-LAFS since the v1.5.0
> release.  It gets mentioned on twitter, there was that
> arstechnica.com article, etc..  Several people have tried it for the
> first time since the v1.5.0 release.  Many of them have reported that
> they can't get it installed.
>
> We have most of the pieces ready for a "fully pre-packaged" version
> of Tahoe-LAFS.  We have .deb's automatically built with every
> revision control commit and automatically uploaded to http://
> allmydata.org/debian/ .  The only problem, I think (?) is that the
> apt index is not getting regenerated after the new .deb's are
> uploaded (#769, #617) and that we don't have an Ubuntu Hardy-amd64
> buildslave (#644).
>
> We have a Windows installer automatically built and uploaded with
> every commit.  The only problem is that it is being uploaded to a
> private server owned by allmydata.com and nobody has volunteered to
> test it or document it.  (It might have bit-rotted due to lack of
> attention and lack of automated tests.)
>
> We have a Mac .dmg package automatically built and uploaded with
> every commit.  I recently wrote automated tests to see whether the
> resulting .dmg was actually mountable and whether the Tahoe-LAFS
> executable therein was actually runnable.  Yay!  Real tests!  Except
> it fails the tests -- the 'tahoe' executable inside the .dmg throws
> an exception (#762, #763).
>
> So, let's get some volunteers to fix these tickets and as soon as
> they are all fixed (see The Roadmap [1]), we'll release Tahoe-LAFS
> v1.5.1!  You can signal to everyone that you are working on a ticket
> by "accepting" it on the trac.  Thank you!
>
> Regards,
>
> Zooko
>
> [1] http://allmydata.org/trac/tahoe/roadmap
>
> tickets mentioned in this email:
>
> http://allmydata.org/trac/tahoe/ticket/617 # Debian etch package size
> mismatch
> http://allmydata.org/trac/tahoe/ticket/644 # tahoe dependencies not
> available for hardy-amd64
> http://allmydata.org/trac/tahoe/ticket/762 # build of mac package
> fails due to pkgutil in zetuptoolz
> http://allmydata.org/trac/tahoe/ticket/763 # build of mac package
> fails due to some mysterious reason (not pkgutil)
> http://allmydata.org/trac/tahoe/ticket/769 # debian 'sid' package
> fails to run: pycryptopp-0.5.15 not available in debian form
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://allmydata.org/pipermail/tahoe-dev/attachments/20090807/e0f12fdc/attachment.htm