I'm going to upgrade to this today.  I came in this morning and found
two computers with hung coda clients.  This is the first time in a while
this has happened.  Both of the clients had these log messages (sorry I
can't give a backtrace -- these machines were don't have gdb):

[ D(31) : 0000 : 09:00:00 ] userent::Connect: VGAPlusSHA_Supported -> 1

[ W(30) : 0000 : 09:00:00 ] userent::Connect: Authenticated bind
failure, uid = 0
[ W(30) : 0000 : 09:00:00 ] WAITING(SRVRQ):

[ W(20) : 0000 : 09:00:00 ] userent::Connect: Authenticated bind
failure, uid = 0

09:00:00 Coda token for user 0 has been discarded
Assertion failed: p->ai_family == PF_INET, file
"/home/pwalsh/working/coda/BUILD/coda-6.0.10/coda-src/venus/realm.cc",
line 182


	Hopefully the update will fix this problem...

..Patrick



On Tue, 2005-06-07 at 16:27 -0400, Jan Harkes wrote:
> Coda-6.0.11 has been released.
> 
> Binary packages have been built on Redhat 9.0, Fedora Core 2 and Debian,
> SRPM and the source tarball are also available.
> 
> This release consists mostly of small fixes, it shouldn't be necessary
> to reinitialize the client. The most important changes are,
> 
> - Fixed kernel device check in venus-setup. (Maurice van der Pot)
> - libc5 compilation fixes. (Dan Fandrich)
> - Reintegration of 'mkdir bar; chown foo bar' was incorrectly considered
>   as a conflicting update.
> - Fix iterators to make sure we keep objects pinned down with a refcount to
>   prevent them from being pulled out when we yield (make an RPC2 call) during
>   the iteration.
> - Send error messages from the backup scripts to root_at_localhost instead of the
>   current (/dev/null-ed) addresses in the Coda domain.
> 
> We have been running the new clients and servers for a couple of days
> already to see if the iterator changes introduced any unforeseen
> problems, and everything seems to be working just fine.
> 
> Jan
> 
-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/