Package Details: tahoe-lafs 1.17.1-1

Git Clone URL: https://aur.archlinux.org/tahoe-lafs.git (read-only, click to copy)
Package Base: tahoe-lafs
Description: Secure, decentralized, and fault-tolerant storage system.
Upstream URL: https://tahoe-lafs.org/trac/tahoe-lafs
Keywords: distributed filesystem i2p
Licenses: GPL, custom
Submitter: None
Maintainer: None
Last Packager: fungible
Votes: 36
Popularity: 0.000000
First Submitted: 2010-07-23 19:52 (UTC)
Last Updated: 2022-03-23 10:20 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

2bluesc commented on 2015-06-16 17:21 (UTC)

@fauno I can take it over until a more fitting maintainer surfaces, I may not be the best person long term.

fauno commented on 2015-06-16 14:16 (UTC)

@2bluesc do you want to maintain it? i never got the time to really use it

2bluesc commented on 2015-06-16 05:10 (UTC)

tahoe-1.10.1 was released @ https://tahoe-lafs.org/source/tahoe-lafs/releases/ From the release email: The previous stable release of Tahoe-LAFS was v1.10.0, released on May 1, 2013. v1.10.1 is mostly a bugfix release, but also improves the web-based user interface, adds public-key authentication to the SFTP frontend, improves the behavior of "tahoe cp -r", and offers more control over IP address autodetection. Preliminary (CLI-based) OS-X packages have been added. Over 75 bugs have been fixed. See the NEWS file [1] for details. [1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/NEWS.rst

ammon commented on 2015-05-25 16:41 (UTC)

It should depend on python2-service-identity

daira commented on 2014-12-23 01:48 (UTC)

This will be fixed upstream in Tahoe-LAFS v1.11. (I don't recommend taking the upstream fix for Arch; it's complicated and needs more testing.) Also see https://bitbucket.org/pypa/setuptools/issue/310/document-the-backward-incompatible-pep-440 , which explains how to work around this problem for other applications.

skydrome commented on 2014-12-23 00:14 (UTC)

its not just tahoe-lafs getting affected, setuptools trac is also full of complaints of other software breakage, thus the daily minor version updates to setuptools to "fix" specific issues, but tahoe-lafs still affected. I think we can agree that tahoe-lafs shouldnt need to be changed here, but setuptools changed to allow old behavior.

daira commented on 2014-12-22 21:17 (UTC)

Here's the upstream ticket describing the setuptools breakage: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2354

daira commented on 2014-12-22 21:16 (UTC)

Well, apparently I'm wrong because there has been an incompatible change to setuptools that totally changes the semantics of requirements strings (from disjunctive to conjunctive!) That sucks; I don't know how we're going to work around the breakage it will cause. But the patch looks like the best workaround currently available. (PKGBUILD should probably still be specifying more precise minimum versions for dependencies other than python2-mock and python2-zope-interface.)

daira commented on 2014-12-22 17:50 (UTC)

Note that if "pip list | grep pycrypto" is showing version 2.6.1 but you're getting the "pkg_resources.DistributionNotFound: pycrypto==2.1.0,==2.3,>=2.4.1" error, that can only be because the imported Crypto module is not the same one found by pip. I am almost certain that changing _auto_deps.py to say "pycrypto >= 2.4.1" will not help; if it appears to do so then it's because something else changed as well. To debug which pycrypto is actually getting imported, do: tahoe --version-and-path

« First ‹ Previous 1 2 3 4 5 6 Next › Last »