[6863] in testers

home help back first fref pref prev next nref lref last post

Re: RHEL 4 X upgrade issue

daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Mar 27 16:14:07 2005

From: Greg Hudson <ghudson@MIT.EDU>
To: William Cattey <wdc@mit.edu>
Cc: rhe-release@mit.edu, testers@mit.edu
In-Reply-To: <883814ff6b7498d8f550f196b58f7f04@mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1111958034.9732.11.camel@egyptian-gods.mit.edu>
Mime-Version: 1.0
Date: Sun, 27 Mar 2005 16:13:55 -0500

On Sat, 2005-03-26 at 14:57, William Cattey wrote:
> Is this X configuration bumpiness something we should report as a bug 
> to Red Hat?
> It might affect stand-alone RHEL3 users at MIT who upgrade.

Red Hat takes care of this as part of the upgrade process (as I
discovered after a few hours of poking around), by invoking
/usr/sbin/fix-mouse-psaux from anaconda.  We can have Athena do the same
thing, probably at boot time.  So, while it would have been cleaner for
Red Hat to take care of this in the xorg-x11 RPM (where they take care
of renaming XF86Config and a few other things), we don't really have a
bug to report on that front.

I don't know if it's worth reporting the failure to shut down the X
server properly.  If it only happens on a bad mouse configuration, then
it's probably not very worthwhile since mouse configuration is simpler
(everything is supposed to use /dev/input/mice).  If it only happens on
rare hardware like the old Thinkpad I'm testing on, then it may not be
worthwhile.  If it is worthwhile, it may be better to pursue it through
X.org, which means first checking if the problem has already been fixed
in the mainline, which means figuring out how to build an X server.  My
guess is that we want to put this on the back burner until we see it in
another situation.


home help back first fref pref prev next nref lref last post