[6874] in testers
Re: install/update of 9.4
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Apr 13 14:52:34 2005
From: Greg Hudson <ghudson@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
Cc: testers@mit.edu
In-Reply-To: <p05230100be82de0981f4@[192.168.1.1]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1113418340.17563.79.camel@egyptian-gods.mit.edu>
Mime-Version: 1.0
Date: Wed, 13 Apr 2005 14:52:20 -0400
On Wed, 2005-04-13 at 12:04, Jonathan Reed wrote:
> I don't know whether this would be expected to work at this stage,
> but a fresh install of 9.4.0 (pointing at the dev cell installer
> volume, and control/control-9.4) fails with:
>
> failed dependencies:
> pyorbit >= 2.0.l is needed by gnome-python2-bonobo-2.6.0-3
I believe this is due to (1) a typo in the gnome-python2-bonobo RPM, and
(2) a difference in the way "2.0.l" and "2.0.1" compare to each other in
different versions of rpm. I think the best fix for us is for the
installer to be using a newer version of rpm. In the mean time, you'll
have to install at 9.3 and update.
> I also updated an IntelliStation to 9.4.0 from 9.3.18, and that seems
> to have gone OK. mkserv failed with "Can't find the mkserv program
> in the mkserv locker", I presume that's to be expected?
If ops could add arch symlinks to the mkserv locker for i386_rhel4 and
sun4x_510, I think that will fix the problem.
> During the boot process, the microcode_ctl service failed with
> "/dev/cpu/0/microcode doesn't exist"
I've seen this as well. I believe it's harmless, but would like to
figure out what bad assumption is being made. We're not loading the
"microcode" kernel module, nor does simply loading it cause /dev/cpu to
exist.
> and "Updating panel menus" failed.
After realizing that I have bits there now, I created 9.4 panel menus.
Just a copy of the 9.3 panel menus for now; at some point the "About the
9.3 release" entry should be changed or eliminated, and Settings should
get the revert-to-sawfish menu item mentioned in the metacity startup
dialog.
> Logging in results in "chown: cannot access 'midi*': No such file or
> directory" in the console, and again for 'sequencer'.
I've submitted a fix for this.
> Then it claimed to be starting metacity and took a LONG time, but eventually
> it worked.
I think the "taking a long time" has something to do with gconf, but
I've only seen it happen occasionally and I haven't tracked it down.
If people do see this happening, and they can ssh into the machine or
log in on a virtual terminal and try to figure out what's going on with
ps and strace, that'd be helpful, though it may be difficult to get very
far without specialized knowledge. (Specifically, if a gconftool-2
process appears to be just waiting on network input, then it's time to
strace the gconfd-2 process.)
> My nautilus desktop seems to have inherited a bunch of
> icons from my KDE desktop, and also my SGI desktop (dumpster, for
> example), I'm not sure how those got there.
The desktop directory location changed from ~/.gnome-desktop to
~/Desktop, I think for compatibility with KDE. Since most users won't
have used KDE or the SGI desktop, I'm not too concerned.
