test failure in 1.10.2 (was: ANN: Tahoe-LAFS 1.10.2 released)
On 7/30/15 8:44 PM, Paul Rabahy wrote: > I just synced to the allmydata-tahoe-1.10.2 tag (commit = > befa4babea7f92609654207c164b6d07f3baf92b) and verified that it was > signed properly (key = E34E 62D0 6D0E 69CF CA41 79FF BDE0 D31D 6866 > 6A7A). I was able to build successfully and encountered 1 error while > running "python setup.py trial". > match = VERSION_RE.search(s) > allmydata.PackagingError: could not parse '1.10.2.postdirty.dev0' due > to TypeError: expected string or buffer Huh, I did a build from the tarball and didn't get that test failure. If you run "git status" on your tree, do you get any indication that you have local uncommitted changes? (I don't think the test is supposed to fail in that case, but the "1.10.2.postdirty.dev0" string suggests that the tree is dirty). thanks for checking it out! -Brian ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: ANN: Tahoe-LAFS 1.10.2 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I just synced to the allmydata-tahoe-1.10.2 tag (commit = befa4babea7f92609654207c164b6d07f3baf92b) and verified that it was signed properly (key = E34E 62D0 6D0E 69CF CA41 79FF BDE0 D31D 6866 6A7A). I was able to build successfully and encountered 1 error while running "python setup.py trial". [ERROR] Traceback (most recent call last): File "c:\users\prabahy\documents\github\tahoe-lafs\src\allmydata\test\test_runner.py", line 171, in _cb norm_ver = normalized_version(ver) File "c:\users\prabahy\documents\github\tahoe-lafs\src\allmydata\__init__.py", line 149, in normalized_version return verlib.NormalizedVersion(verlib.suggest_normalized_version(verstr)) File "c:\users\prabahy\documents\github\tahoe-lafs\src\allmydata\util\verlib.py", line 86, in __init__ self._parse(s, error_on_huge_major_num) File "c:\users\prabahy\documents\github\tahoe-lafs\src\allmydata\util\verlib.py", line 95, in _parse match = VERSION_RE.search(s) allmydata.PackagingError: could not parse '1.10.2.postdirty.dev0' due to TypeError: expected string or buffer allmydata.test.test_runner.BinTahoe.test_path - --- Ran 1182 tests in 680.622s FAILED (skips=14, expectedFailures=3, errors=1, successes=1164) Doesn't look like a big deal to me, so overall I'll call it a success! -BEGIN PGP SIGNATURE- Version: Mailvelope v0.13.1 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJVuu8XCRDRy6KiG82I9gAAKa0QAMt4I0jKoQKt1MjLZE/P ehUpdAs4iLJjwY5ic7xUE1WOiK29M3taRj4LB9jgGxgrHnGcSus/GzrbBS4q Difd2hnoA5c6CjxZSAQEvHDQmkFgbrQ5BYyAvSAhhcOvf9YgrMJAxWIqNew0 SdeYbM1qKcWHjGrlnbTea/LMbfC2eRSb4Qri/7Zq1vWTF03Hi5NRbdv0mvd5 SWaJCqQ/SXN+RmC0wd3MnX5e6rhAQV1YWMa3e6HVmaJ5lrxNXHrObsFNB8DY DSLWE9ebFV78D9yDffhbeSeSvZvfQf9f1+drGfKFnTABUYPoFCr/GRW97Fpd bYEVcJQByuOwLVKb94TJHN8g4I3oPZyHmoXB0izmv0FvebEjj1NHD1clCR4Q oh5MuFfMaKvKne5SY65FHB1GKQyOK3alu1LaGWsXIPqJ/Axl/W9RrD31oCoS dU5M7tEKbgjoDbZPsg2CrOcB0ZU/ed/jrS/A0C4YhbyMJoJRVN9RkMlk1q6k ubFC1bI80lwiYuOYZjoADel0ZjnhmyrLvaNKBASW4J78iDVKTbme+bYYhJft FImaSQJFGf8yw1VvvKAPWbjgWpFbEk45BTrqrutJHn7BViXSuo2MVoyr4GJe g8u16/SGXtf1M76f/PvDCqNxMj6R9O+++gS/++BIuIEdK75jEXo20woTCvqf nfew =+ydp -END PGP SIGNATURE- On Thu, Jul 30, 2015 at 10:57 PM, Brian Warner wrote: > > ANNOUNCING Tahoe, the Least-Authority File System, v1.10.2 > > The Tahoe-LAFS team is pleased to announce version 1.10.2 of > Tahoe-LAFS, an extremely reliable distributed storage system. > Get it here: > > https://tahoe-lafs.org/source/tahoe-lafs/releases/ > > in the following file (among others): > > allmydata-tahoe-1.10.2.tar.bz2 > (SHA256=fed5d719c966d9528a45e8ad66e6c8ff3dcb3c06db94775194c7c75566047be7) > > There are also -SUMO variants (which include all necessary > dependencies). All files are signed by the Tahoe-LAFS Release-Signing > Key, fingerprint E34E 62D0 6D0E 69CF CA41 79FF BDE0 D31D 6866 6A7A (look > for detached .asc files next to the tarballs in the directory above). > > This is git revision befa4babea7f92609654207c164b6d07f3baf92b on > https://github.com/tahoe-lafs/tahoe-lafs.git , which is tagged as > "allmydata-tahoe-1.10.2" (with a GPG-signed tag, using the same > Release-Signing Key as above). > > Instructions for download and installation are in: > > https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst > > Tahoe-LAFS is the first distributed storage system to offer > "provider-independent security" — meaning that not even the > operators of your storage servers can read or alter your data > without your consent. Here is the one-page explanation of its > unique security and fault-tolerance properties: > > https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst > > The previous stable release of Tahoe-LAFS was v1.10.1, released > on June 15, 2015. > > v1.10.2 is a small bugfix release, which fixes a critical > packaging error that prevented v1.10.1 from building against the > latest version of the upstream "mock" library. A few small bugs > were fixed too. See the NEWS file [1] for details. > > > WHAT IS IT GOOD FOR? > > With Tahoe-LAFS, you distribute your filesystem across > multiple servers, and even if some of the servers fail or are > taken over by an attacker, the entire filesystem continues to > work correctly, and continues to preserve your privacy and > security. You can easily share specific files and directories > with other people. > > In addition to the core storage system itself, volunteers > have built other projects on top of Tahoe-LAFS and have > integrated Tahoe-LAFS with existing systems, including > Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, > Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and > more. See the Related Projects page on the wiki [3]. > > We believe that strong cryptography, Free and Open Source > Software, erasure coding, and principled engineering practices > make Tahoe-LAFS safer than RAID, remov
ANN: Tahoe-LAFS 1.10.2 released
ANNOUNCING Tahoe, the Least-Authority File System, v1.10.2 The Tahoe-LAFS team is pleased to announce version 1.10.2 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: https://tahoe-lafs.org/source/tahoe-lafs/releases/ in the following file (among others): allmydata-tahoe-1.10.2.tar.bz2 (SHA256=fed5d719c966d9528a45e8ad66e6c8ff3dcb3c06db94775194c7c75566047be7) There are also -SUMO variants (which include all necessary dependencies). All files are signed by the Tahoe-LAFS Release-Signing Key, fingerprint E34E 62D0 6D0E 69CF CA41 79FF BDE0 D31D 6866 6A7A (look for detached .asc files next to the tarballs in the directory above). This is git revision befa4babea7f92609654207c164b6d07f3baf92b on https://github.com/tahoe-lafs/tahoe-lafs.git , which is tagged as "allmydata-tahoe-1.10.2" (with a GPG-signed tag, using the same Release-Signing Key as above). Instructions for download and installation are in: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst Tahoe-LAFS is the first distributed storage system to offer "provider-independent security" — meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst The previous stable release of Tahoe-LAFS was v1.10.1, released on June 15, 2015. v1.10.2 is a small bugfix release, which fixes a critical packaging error that prevented v1.10.1 from building against the latest version of the upstream "mock" library. A few small bugs were fixed too. See the NEWS file [1] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.rst file [2].) COMPATIBILITY This release should be compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. Except for the new optional MDMF format, we have not made any intentional compatibility changes. However we do not yet have the test infrastructure to continuously verify that all new versions are interoperable with previous versions. We intend to build such an infrastructure in the future. The new Introducer protocol added in v1.10 is backwards compatible with older clients and introducer servers, however some features will be unavailable when an older node is involved. Please see docs/nodekeys.rst [14] for details. This is the nineteenth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the foreseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [4] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.rst" [5] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows,
Re: Rsync with sftp account
The inefficiency has to do with the FUSE frontend to Tahoe-LAFS. Just don't use it... Tahoe-LAFS is not a POSIX compliant filesystem and cannot efficiently perform random writes. I suggest using the tahoe backup command to backup files to a tahoe grid. On Thu, Jul 30, 2015 at 5:10 AM, Freelab initiative wrote: > > > to my humble observations, > > trying to make a rsync over a sftp frontend to tahoe grid is not working > very efficiently > > rsync is asking to read so much the tahoe grid > and tahoe lafs is not a fast file system > > so the rsync at the end is very slow > > > maybe there is another way to achieve what you want to do > > 2015-07-27 21:46 GMT+02:00 David Stainton : >> >> Why is a question about rsync sent to a list about Tahoe-LAFS? >> Seriously, I fail to see the connection between Tahoe-LAFS and >> rsync... except for the file paradigm... they both deal with file like >> objects... and that's cool and all but what exactly do you want? >> >> Do you want to use Tahoe-LAFS with rsync? This isn't trivially >> possible. Tahoe-LAFS does not in fact implement a filesystem... >> instead think of it as a key value data store. >> >> >> On Mon, Jul 27, 2015 at 12:06 PM, InfoTest wrote: >> > Is it true that rsync doesn't know difference between two directory? >> > ___ >> > tahoe-dev mailing list >> > tahoe-dev@tahoe-lafs.org >> > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev >> ___ >> tahoe-dev mailing list >> tahoe-dev@tahoe-lafs.org >> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
Re: Rsync with sftp account
to my humble observations, trying to make a rsync over a sftp frontend to tahoe grid is not working very efficiently rsync is asking to read so much the tahoe grid and tahoe lafs is not a fast file system so the rsync at the end is very slow maybe there is another way to achieve what you want to do 2015-07-27 21:46 GMT+02:00 David Stainton : > Why is a question about rsync sent to a list about Tahoe-LAFS? > Seriously, I fail to see the connection between Tahoe-LAFS and > rsync... except for the file paradigm... they both deal with file like > objects... and that's cool and all but what exactly do you want? > > Do you want to use Tahoe-LAFS with rsync? This isn't trivially > possible. Tahoe-LAFS does not in fact implement a filesystem... > instead think of it as a key value data store. > > > On Mon, Jul 27, 2015 at 12:06 PM, InfoTest wrote: > > Is it true that rsync doesn't know difference between two directory? > > ___ > > tahoe-dev mailing list > > tahoe-dev@tahoe-lafs.org > > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > ___ > tahoe-dev mailing list > tahoe-dev@tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > ___ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
