[5656] in testers
Re: Issues with athena 9.2
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Jul 20 13:34:14 2003
From: Greg Hudson <ghudson@MIT.EDU>
To: vchudnovsky@alum.MIT.EDU
Cc: testers@mit.edu
In-Reply-To: <1058721321.1323.2168.camel@chudnovsky.homelinux.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1058722449.1470.33.camel@error-messages.mit.edu>
Mime-Version: 1.0
Date: 20 Jul 2003 13:34:10 -0400
On Sun, 2003-07-20 at 13:15, Victor Chudnovsky wrote:
> Workspace switcher:
I'll have to look into this more closely. More later.
> It would awfully nice to have spell-checking enabled in
> Evolution
Maybe in a while. It requires the gnome-spell package, which requires
the pspell package.
We'll be going to Evolution 1.4.3 in a week or two, so your vFolder
problem may be resolved. (Possibly at the expense of raising other
issues.)
> Miscellaneous
> I can't get 'less' to work correctly when I'm logged in as
> myself.
You need to fix your .cshrc not to generate output. See
<http://www.greenwoodsoftware.com/less/#profileout>. The problem is
more visible in Red Hat 9 because they introduced a default LESSOPEN
variable. (Which is kind of neat; try running less on a directory or a
.tar.gz file. But not on Solaris.)
> The upgrade process from 9.2.9 to 9.2.10 seemed to hang (the
> machine was fine, though; I could suspend the process). I did
> 'update_ws 9.2.10' and the process did not terminate by
> itself. I even tried repeating the update (was this wise?) and
> got the same results.
The rpmlib shipped in Red Hat 9 contains some locking problems. (Which
were well known at the time of the release; Red Hat is not exactly
improving its reputation for stability here.) You're the second one to
report this problem showing up in the field (the first report was just a
couple of days ago), and I'm now sufficiently worried that I will renew
my attempt at finding a remedy.
The solution is to kill off all rpm and rpmupdate processes and then
remove /var/lib/rpm/__db.*, which are files containing locks. I think
rebooting might also work; I'm not quite sure whether the locks are
fcntl-style (kernel state which goes away on a reboot) or permanent
state.
