Bug 173428 - emacs with modular X: 'Undefined color: "black"'
emacs with modular X: 'Undefined color: "black"'
Status: CLOSED DUPLICATE of bug 173453
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
: 173734 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-11-16 21:06 EST by Horst H. von Brand
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-17 11:52:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Horst H. von Brand 2005-11-16 21:06:34 EST
Description of problem:
Starting emacs just gives the above message, and emacs fails to start. There are
several other applications that complain about colors (like xemacs)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. try to start emacs in an xterm
Actual results:
emacs doesn't start, error message:
  Undefined color: "black"

Expected results:
emacs window...

Additional info:
Comment 1 Jens Petersen 2005-11-17 03:08:22 EST
X team, any ideas about this one?
Comment 2 Jens Petersen 2005-11-17 03:09:50 EST
Is this because /usr/X11R6/lib/X11/rgb.txt moved, perhaps?
Comment 3 Jens Petersen 2005-11-17 03:12:06 EST
Maybe not - emacs seems to include its own rgb.txt fwiw.
Comment 4 Mike A. Harris 2005-11-17 04:51:51 EST
This is most likely a dupe of bug #173036.
Comment 5 Mike A. Harris 2005-11-17 07:27:41 EST
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.

Comment 6 Horst H. von Brand 2005-11-17 11:02:37 EST
Yes, this fixed it. xemacs alsso works now, and xclock (#173483) doesn't
complain about colors anymore.
Comment 7 Mike A. Harris 2005-11-17 11:42:01 EST
CLOSED->DEFERED is not the correct bug state.
Comment 8 Mike A. Harris 2005-11-17 11:52:26 EST

*** This bug has been marked as a duplicate of 173453 ***
Comment 9 Jens Petersen 2005-11-21 02:26:15 EST
*** Bug 173734 has been marked as a duplicate of this bug. ***
Comment 10 Jens Petersen 2005-11-21 02:35:58 EST
Hmm, even without RgbPath or after setting RgbPath, I still get
the 'Undefined color: "black"' message and emacs stops.
Comment 11 Mike A. Harris 2005-11-21 02:46:49 EST
The fixed xorg-x11-server-utils package is in CVS right now, however
beehive will not let me build it, giving an error stating that
"xbitmaps-devel" is an unmet dependency.

Since xbitmaps-devel is a virtual provide of the xorg-x11-xbitmaps package,
and it does exist in dist-fc5, I hereby declare this problem to be blocking
on beehive being broken.

Once beehive is un-broken, and permits the package to be built, we'll be
one step closer to solving the rgb.txt related problems however.

Comment 12 Paul Dickson 2005-11-21 04:14:38 EST
See comment 2 of Bug 173734.  If there's no RgbPath, /usr/lib/X11/rgb.txt will
be used.

Note You need to log in before you can comment on or make changes to this bug.