Bug 176222

Hmm, that's odd, as we fixed all the rgb.txt problems already.  ;o)

Please do a full rawhide update, and ensure you've got
xorg-x11-server-Xorg-1.0.0 and all the latest libs, etc.  Also make
sure your X server config file does not contain any RgbPath overrides.

If the problem is still present in the latest builds of everything and
the server is configured correctly, please attach the log and config file,
and the full output of:

rpm -qa | sort | egrep "^(lib|xorg)"

Thanks in advance.



Reassigning to "devel" product version, as we have not yet released a
Fedora Core 5 test2 release.

Please refer to comment #1, and if this problem still persists after
a full update to current rawhide, please reopen the report and I'll
investigate the current codebase.

The problem is there again with xorg-x11-server-Xorg-1.0.0-3:
Couldn't open RGB_DB '/usr/X11R6/lib/X11/rgb'

[root@pc-32 ~]# grep RGB_DB /var/log/Xorg.0.log
Couldn't open RGB_DB '/usr/share/X11/rgb.txt'
[root@pc-32 ~]# ls -l /usr/share/X11/rgb.txt
-rw-r--r-- 1 root root 17371 Dec 16 19:17 /usr/share/X11/rgb.txt
[root@pc-32 ~]# rpm -q xorg-x11-server-Xorg
xorg-x11-server-Xorg-1.0.1-1
[root@pc-32 ~]# ls -l /var/log/Xorg.0.log
-rw-r--r-- 1 root root 55863 Jan 30 12:34 /var/log/Xorg.0.log
[root@pc-32 ~]#

If you cheat, and specify "/usr/share/X11/rgb" instead of the real file
("/usr/share/X11/rgb.txt") it works.

Strange and rather counterintuitive, though.

Ok, I'll re-investigate the server again, as it seems like it has regressed.
It is kindof odd though that we're not seeing more reports of it, as it should
affect everyone or nobody, at least in theory...

The xorg.conf should normally not have any RgbPath listed, and the upgrade
scripts attempt to remove it if it is present, to ensure the compiled in
path is what gets used.  You can still override it via config file however,
but it'll get removed again on the next upgrade.  If the config file does
have an RgbPath listed at server invocation, it should be honoured though.

Queuing for reinvestigation, and flagging as FC5Blocker

Bug #173453 was the original tracker for this problem.  I've cross indexed them
for additional feedback, to see if any original reporters experience the
regression as well.

If those seeing the problem would be kind enough to attach their xorg.conf
and a sample X server log to the report, that'd be welcome info, although
it's not strictly necessary.  I'd just like to confirm no RgbPath is being
set in the config when the problem occurs, and also see where the X server
is looking for the log.

Anyhow, I'll probably wait a day or so to see what feedback rolls in, and
then have a closer look.  I suspect it will either be a trivial problem to
fix, or it'll turn out to be misconfiguration or a bad rpm script.



(In reply to comment #5)
> If you cheat, and specify "/usr/share/X11/rgb" instead of the real file
> ("/usr/share/X11/rgb.txt") it works.
> 
> Strange and rather counterintuitive, though.

Yeah, I've always thought that to be rather non-intuitive as well, however
the reason for it is that X can be built to handle 3 different types of
RGB databases.  text file (rgb.txt), and I believe berkley db format and
some other.  I'd have to look at the code again to get the specifics,
however due to this, the actual file extension may be different.  As such,
the "logic" *cough cough* in the code expects the path and filename without
the file extension to be supplied.  Definitely rather strange.  ;o)

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


The problem does not seem to be present in 1.0.1-1 on i386 arch, so closing
as fixed in RAWHIDE.  If problem recurs, reopen bug and paste the output of
"rpm -qa |grep ^xorg-x11", and attach a new X server log and config file,
and we'll reinvestigate.

Thanks.