Bug 180331

I had similar problems on yum updates to rawhide from FC4 due to the
links in /usr/lib/X11 or /usr/lib64/X11 to /usr/X11R6/lib as well as
the same links for /usr/include/X11 ---> /usr/X11R6/include. With these
present the update puts some of the X11 stuff under /usr/X11R6. At
rawhide level you should not have this directory. You have to move
manually things like rgb.txt to /usr/share/X11 directory etc. Anyhow,
this needs to be cc'ed to Mike Harris to look into. I would remove
those links before upgrade although thay may break  some third party stuff.

This was not an upgrade. It was a clean install.

(In reply to comment #0)
> Clean rawhide-20060206 install on ppc64. Cannot run emacs:
> 
> $ emacs Makefile
> Undefined color: "black"

This is a symptom of incorrectly configured rgb.txt database.  The X
server is compiled to find rgb.txt in /usr/share/X11/rgb.txt, which is
where rgb.txt is currently installed by our packages.  If the RgbPath
is specified in the xorg.conf at all, it will redirect the X server to
look elsewhere for rgb.txt.

Since there is absolutely no good reason to specify RgbPath in xorg.conf,
the X server rpm %post script will remove any RgbPath entries from the
config file during upgrades.  If some other tool subsequently puts RgbPath
back into the config file, and it is pointing to the wrong place, then
this problem will occur.  Our current rawhide X config tools are aware
of this, and to the best of my knowledge, no longer put RgbPath into the
config file.

Run the following and tell me what you get as a result:

[root@fc4i386 RPMS]# rpm -q xorg-x11-server-Xorg
xorg-x11-server-Xorg-1.0.1-4
[root@fc4i386 RPMS]# strings /usr/bin/Xorg |grep /rgb
/usr/share/X11/rgb

Examine your X server log to see where the X server thinks rgb.txt is
located.  Also check to see where rgb.txt is actually installed on the
system.

If you have any applications which are statically linked to old libraries
which specified rgb.txt in another location, they will fail, however I
assume that isn't the case for your emacs.

What method did you use to install rawhide on PPC64 BTW?

TIA




(In reply to comment #1)
> I had similar problems on yum updates to rawhide from FC4 due to the
> links in /usr/lib/X11 or /usr/lib64/X11 to /usr/X11R6/lib as well as
> the same links for /usr/include/X11 ---> /usr/X11R6/include. With these
> present the update puts some of the X11 stuff under /usr/X11R6. At
> rawhide level you should not have this directory. You have to move
> manually things like rgb.txt to /usr/share/X11 directory etc. Anyhow,
> this needs to be cc'ed to Mike Harris to look into. I would remove
> those links before upgrade although thay may break  some third party stuff.

That is an ancient problem, which has long since been fixed however.
The xorg-x11-filesystem package ensures that /usr/lib/X11 is a directory
and not a symlink.  All Xorg packages that install files into /usr/lib/X11
have a hard dependency on xorg-x11-filesystem being installed first.  This
ensures that the directories always exist before packages install files
into them.

Oops, I apologise -- it's not _quite_ a clean installation, because I used my
xorg.conf from FC4. That seemed easier than fighting with system-config-display
to get my dual-head setup working.

I did an NFS install, using VNC in the end, because X segfaulted when run from
the installer. I wasn't able to reproduce that segfault in the installed system
-- it worked fine (albeit on only one head). I'll chase that up shortly.

I'm unable to reproduce this problem on a fresh OS install on x86, and there
is no difference WRT how rgb is handled on other architectures, so PPC should
be the same.  I'm convinced this must be a configuration problem, as
I fixed all rgb related problems over a month ago.

Please attach your X server log and config file for review, and
the output of:

[root@fc4i386 RPMS]# rpm -q xorg-x11-server-Xorg
xorg-x11-server-Xorg-1.0.1-4
[root@fc4i386 RPMS]# strings /usr/bin/Xorg |grep /rgb
/usr/share/X11/rgb

If the X server is using the wrong rgb path, it must be getting overridden
in the config file.  Then it's either an X config tool bug that needs
fixing, or it's a local config file problem.

TIA

As stated in comment #4, I had used my xorg.conf from FC4, which did specify an
rgb path. 

I resorted to this because system-config-display didn't seem able to do anything
with similar functionality. Even if I specify 'option reverseddc true' manually
and re-run system-config-display, I still end up with the right-hand monitor
going blank as if it doesn't like the mode it's presented.

Created attachment 124436 [details]
xorg.conf

(In reply to comment #6)
> As stated in comment #4, I had used my xorg.conf from FC4, which did specify
> an rgb path.

Just confirming that's what you meant.


> I resorted to this because system-config-display didn't seem able to do
> anything with similar functionality. Even if I specify 'option reverseddc
> true' manually and re-run system-config-display, I still end up with the 
> right-hand monitor going blank as if it doesn't like the mode it's presented.

system-config-display works mainly only for the most basic single-headed
systems.  Multihead configuration has always been totally broken since the
feature has been present.  Unfortunately, there's nobody really actively
maintaining system-config-display currently, so bugs that get reported
seem to just pile up from what I can see in MCP.

I recommend making a singlehead config with s-c-d, and then manually
editing it by hand to turn it into a proper multihead config.  That seems
to be the best way to do it.  Just helped pgraner get up and running with
a dualhead radeon with mergedfb that eluded him for a while. ;)



-----
# RgbPath is the location of the RGB database.  Note, this is the name of the 
# file minus the extension (like ".txt" or ".db").  There is normally
# no need to change the default.
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Red Hat 6.0 and later now use a font server independent of
# the X server to render fonts.
	RgbPath      "/usr/X11R6/lib/X11/rgb"


Just remove this section from xorg.conf and the emacs problem should go
away on the next X server restart.

HTH