Bug 173036
Summary: | rgb.txt should be in an architecture-independent location | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jeremy Katz <katzj> |
Component: | xorg-x11-server-utils | Assignee: | X/OpenGL Maintenance List <xgl-maint> |
Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | michal, mk, nalin, wriede |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-11-23 16:21:51 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 171376 |
Description
Jeremy Katz
2005-11-12 19:56:25 UTC
Moving this file (even from its previous location, /usr/X11R6/lib/X11/rgb.txt) broke/breaks/will break old configuration files which specified this as the value for the RgbPath setting, causing older applications to draw black pixels where colored-by-name pixels were intended. After an update to "modular X" /usr/X11R6/lib/X11/rgb.txt is simply gone. To make things more interesting on x86_64 this file resides in /usr/lib64/X11/rgb.txt. There is no /usr/lib/X11 at all. At least a link for an old location would be nice. 'xdvi', for example, does not start properly without this file. Even when /usr/X11R6/lib/X11/rgb.txt is present there are complaints but at least menus do show up. This is an unintended bug, caused due to upstream X being in a bit of flux. There are 4 problems that we need to solve in a future update: 1) The rgb.txt file should be in /usr/share/X11/rgb.txt as it is arch independent data. 2) Everything that is part of X11R7 that reads this file directly, needs to be updated to find it in the new "correct" location. 3) The Xorg server package needs to be updated to remove RgbPath from the config file, as it should not be necessary to specify this. The X server should use it's built in default, and nobody should ever move this file anyway. Why it is even configurable is somewhat of a mystery. 4) The config tools need to be updated to not write out RgbPath or ModulePath. Please file separate bugs against the config tools for #4. No need to file a bug for 4 -- we've never written out ModulePath and I changed things so that RgbPath shouldn't get written out as of a few days ago (In reply to comment #4) > No need to file a bug for 4 -- we've never written out ModulePath and I changed > things so that RgbPath shouldn't get written out as of a few days ago Ok. I'm still going to have the upgrade scripts update ModulePath if it is present and contains the old X module path, as I know some 3rd party driver installs change the path, and put the X path last. That should keep them happy. *** Bug 173435 has been marked as a duplicate of this bug. *** To everyone experiencing this: Edit your xorg.conf file, and remove the line that has: RgbPath ... Then restart the X server. Does this make the problem go away? If so, then I can have a real quick fix for this problem for everyone by having the upgrade of the X server, remove RgbPath from xorg.conf, as it should never have been put in there by our crazy config tools anyway. ;o) Then the actual location of rgb.txt becomes transparent to the system hopefully, and I can lower the priority of fixing it by a week or so, and divert my resources to other more critical problems that have come up, and either pick up a fix from RC3, or fix it in a few weeks. The new xorg-x11-server-0.99.3-6 package contains a fix for the xorg.conf RgbPath problem. Please test it, and see if the failing applications work now. That does not resolve this bug, however it should make the problem people are experiencing due to this go away hopefully. 0.99.3-6 corrects the problem on my system. rgb.txt is part of xorg-x11-server-utils which is still at 0.99.2-3 ? on my x64_86 it lives in /usr/lib/64/X11, but xorg looks in /usr/lib/X11 for it. even after I set RgbPath in xorg.conf to be "/usr/lib64/X11", something is still not right - from Xorg.0.log: (**) RgbPath set to "/usr/lib64/X11" (==) ModulePath set to "/usr/lib64/xorg/modules" Couldn't open RGB_DB '/usr/lib64/X11' > even after I set RgbPath in xorg.conf to be "/usr/lib64/X11"
I think that "/usr/lib64/X11/rgb" would be really expected but I am not sure.
Just to avoid confusion, there are multiple problems going on here. Let me try to cover them all and give status on each, to avoid everyone from having to guess about things.. ;o) 1) The upstream tarballs install rgb.txt into %{libdir}/X11 which is /usr/lib/X11 on 32bit systems, and /usr/lib64/X11 on 64bit multilib systems. This is bad, as this is an architecture independent data file, which should be shared. It belongs in %{_datadir}, not %{_libdir}. Solution: In the latest xorg-x11-server-utils package in Fedora CVS, the whole package is updated to install the data files from all of the apps it ships, into %{_datadir} where they belong, including rgb.txt. 2) The X config tools in Fedora Core 4, and all earlier releases of FC, RHEL, and RHL all put the line RgbPath into the config file, even though there is _no_ reason to specify this information in the config file, as it is a built in default. Our config tools seem to have a knack for over-specifying defaults in the config file, which eventually change, and the config file no longer points at the right location. Solution: The latest xorg-x11-server package, contains an rpm %post script now, which will remove the RgbPath directive from the xorg.conf if it exists. It also will check for ModulePath directive(s), and if present, it will search and replace the primary X server module directory with the new one, and leave any other ModulePath's alone. 3) The X server, and any other software that directly accesses the rgb.txt file, need to know exactly where it is located, either via built in compile-time defaults, or via configuration files or commandline options. The only sane default operation of course, is for rgb.txt to be found where expected without any config file options or overrides. Solution: Now that the problem #2 is solved above, we remove that from the equasion. Now that problem #1 is solved, we will find out wether the X server needs to be patched and recompiled to find rgb.txt properly or not. In order to have this properly tested, both of the solutions for #1 and #2 must be built and installed first, or one of those 2 problems will hit people. Beehive is not being cooperative with me, so that might take a while. Once we've got things properly built in beehive, we can test wether the rgb.txt file is being found properly or not, and if not, we can start investigating the X server source/configure options for why. Apologies for any inconveniences, but I hope this helps to understand where things are at now. I'll update when I have more news. Thanks for testing! I finally waded through the xorg-horror-story bug alias filesystem symlink/dir issue, and climbed the "fix it" dependency chain to allow the new package to be built in beehive for this bug. xorg-server-utils-0.99.2-5 fixes this problem. > xorg-server-utils-0.99.2-5 fixes this problem.
I am ultimately lost which problem is "this". It is true that
xorg-x11-server-utils-0.99.2-5 package provides /usr/share/X11/rgb.txt;
but when I am starting X server from xorg-x11-server-Xorg-0.99.3-7 without
adding an explicit RgbPath in xorg.conf then I see in logs:
(==) RgbPath set to "/usr/lib/X11/rgb"
(==) ModulePath set to "/usr/lib64/xorg/modules"
Couldn't open RGB_DB '/usr/lib/X11/rgb'
and, of course, there are colour troubles.
Is this is another issue or this bug should be reopened?
To "fix" this problem in FC5test1, add: RgbPath "/usr/share/X11/rgb" to the Files section of xorg.conf |