On Mon, 2004-02-23 at 11:46, Gavin Hamill wrote: > I seem to have the same problem as this guy, but his e-mail address now > bounces, and was curious if the problem has since come to light by > others before I file a more formal bug report:
I've not had any more feedback on the problem that he had. > A .openoffice directory isn't even created in $HOME, nor .sversionrc > (name from memory...). > > The last .ttf that's opened is one of the Bitstream Vera family which is > being used for the main KDE display, so they seem to be correctly > configured (I tried reinstalling them anyway, just in case) OK. > I've also looked through strace outputs, and none of it seems to suggest > anything is particularly wrong, but will of course provide a full trace > if needed :) > > One of the irritating bits is that I see it trying to write a > 'Setup_err.txt' (again, filename from memory...) but being 'access > denied' - I assume then it's trying to write the errorlog to somewhere > in /usr rather than $HOME where OOo was launched. Is there some way to > override this so I can find where it's failing? I don't know. You could try running /usr/lib/openoffice/setup instead of letting the wrapper run it for you. You might get some extra information that way. Also, take a look at this upstream issue: http://www.openoffice.org/issues/show_bug.cgi?id=17517 "The problem was resolved when I started to use the nfs-kernel Debian package instead of nfs-user Debian package." Also, does the workaround described help? "I've done some experiments on NFS and the problem seems connected with the lock options. Infact by setting STAR_PROFILE_LOCKING_DISABLED=1 export STAR_PROFILE_LOCKING_DISABLED into program/soffice all seems to work. Another way is to mount nfs area with -o nolock option." If you still have a problem, file a bug report to help keep track of the problem. Chris
