(1) It may be purely my own stupidity, but I had a symlink /vice ->
    /playpen/Coda/vice, where my test server setup was.  Somewhere in
    the install process, this got deleted, and a directory /vice was
    made and initialized.  Needless to say, I had a lot of trouble
    getting coda to find my existing data....

    I think this happened somewhere in the dpkg -i process, presumably
    for coda-server_XXX.dpkg.  I'm not entirely sure, because I then
    tried vice-setup (thinking maybe I needed to point the server at
    the data for some reason), but I bailed out of that when it
    threatened to reinitialize my RVM.  Anyway, we really don't want
    to overwrite any existing stuff without a confirmation from the
    admin.

(2) Urk:

tleepslib:/usr/local/Builds# ldd /usr/local/coda-test/sbin/auth2
        librpc2.so.1 => /usr/lib/librpc2.so.1 (0x40021000)
        liblwp.so.2 => /usr/lib/liblwp.so.2 (0x40046000)
--->    libdb.so.2 => /lib/libdb.so.2 (0x4004f000)
        libc.so.6 => /lib/libc.so.6 (0x4005d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

/usr/local/coda-test was configured and built by hand, from Coda
current CVS circa Sept 22.  Note the libdb.so.2; the target is
distributed as part of glibc and is evidently db 1.85 compatible.
glibc was at 2.1.3 (Debian package revision 25 or so) at the time.

tleepslib:/usr/local/Builds# ldd /usr/sbin/auth2 
        librpc2.so.1 => /usr/lib/librpc2.so.1 (0x40021000)
        liblwp.so.2 => /usr/lib/liblwp.so.2 (0x40046000)
--->    libdb2.so.2 => /usr/lib/libdb2.so.2 (0x4004f000)
        libc.so.6 => /lib/libc.so.6 (0x40093000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

The installation in /usr was built from debian/rules, Coda current CVS
circa Oct 9, and /usr/lib/libdb2 is the Sleepycat Berkeley db v 2.77
or so.  I probably upgraded glibc in the interim from 2.1.3 to 2.1.9x
(I'm currently at 2.1.94, but the Coda configuration may have occurred
at glibc-2.1.93; it's unlikely to have been under glibc 2.1.3).

Obviously the new auth2 was not pleased at my databases at all.

I'm not an autoconf wizard, I don't know what went wrong.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."