From: Zooko O'Whielacronx Date: Sun, 2 Aug 2009 02:26:01 +0000 (-0700) Subject: docs: add a couple of details to NEWS, change date and a bit of formatting, name... X-Git-Tag: allmydata-tahoe-1.5.0~6 X-Git-Url: https://git.rkrishnan.org/simplejson/components/com_hotproperty/cyclelanguage?a=commitdiff_plain;h=e784fbdbf3f32d7f64d2338c883272bb316af5ca;p=tahoe-lafs%2Ftahoe-lafs.git docs: add a couple of details to NEWS, change date and a bit of formatting, name of 'Tahoe-LAFS' project --- diff --git a/NEWS b/NEWS index b1bf8a21..cb4958d5 100644 --- a/NEWS +++ b/NEWS @@ -1,6 +1,6 @@ -User visible changes in Tahoe. -*- outline -*- +User visible changes in Tahoe-LAFS. -*- outline -*- -* Release 1.5.0 (2009-07-22) +* Release 1.5.0 (2009-08-01) ** Improvements @@ -28,13 +28,13 @@ and algorithm remains the same, so using mutable files still requires bandwidth, computation, and RAM in proportion to the size of the mutable file. (#694) -This version of Tahoe will tolerate directory entries that contain filecap +This version of Tahoe-LAFS will tolerate directory entries that contain filecap formats which it does not recognize: files and directories from the future. This should improve the user experience (for 1.5.0 users) when we add new cap -formats in the future. Previous versions would fail badly, preventing the -user from seeing or editing anything else in those directories. These -unrecognized objects can be renamed and deleted, but obviously not read or -written. Also they cannot generally be copied. (#683) +formats in the future. Previous versions would fail badly, preventing the user +from seeing or editing anything else in those directories. These unrecognized +objects can be renamed and deleted, but obviously not read or written. Also +they cannot generally be copied. (#683) ** Bugfixes @@ -53,8 +53,8 @@ the Helper's ability to mount a partial-information-guessing attack. (#722) ** Platform/packaging changes -Tahoe-LAFS now runs on NetBSD, OpenBSD, and ArchLinux, and an embedded system -based on an ARM CPU running at 266 MHz. XXX +Tahoe-LAFS now runs on NetBSD, OpenBSD, ArchLinux, and NixOS, and on an +embedded system based on an ARM CPU running at 266 MHz. Unit test timeouts have been raised to allow the tests to complete on extremely slow platforms like embedded ARM-based NAS boxes, which may take @@ -62,16 +62,20 @@ several hours to run the test suite. An ARM-specific data-corrupting bug in an older version of Crypto++ (5.5.2) was identified: ARM-users are encouraged to use recent Crypto++/pycryptopp which avoids this problem. -Tahoe now requires a SQLite library, either the sqlite3 that comes built-in -with python2.5/2.6, or the add-on pysqlite2 if you're using python2.4. In the -previous release, this was only needed for the "tahoe backup" command: now it -is mandatory. +Tahoe-LAFS now requires a SQLite library, either the sqlite3 that comes +built-in with python2.5/2.6, or the add-on pysqlite2 if you're using +python2.4. In the previous release, this was only needed for the "tahoe backup" +command: now it is mandatory. Several minor documentation updates were made. -To help get Tahoe into Linux distributions like Fedora and Debian, packaging -improvements are being made in both Tahoe and related libraries like -pycryptopp and zfec. +To help get Tahoe-LAFS into Linux distributions like Fedora and Debian, +packaging improvements are being made in both Tahoe-LAFS and related libraries +like pycryptopp and zfec. + +The Crypto++ library included in the pycryptopp package has been upgraded to +version 5.6.0 of Crypto++, which includes a more efficient implementation of +SHA-256 in assembly for x86 or amd64 architectures. ** dependency updates