Bug 173428 - emacs with modular X: 'Undefined color: "black"'
Summary: emacs with modular X: 'Undefined color: "black"'
Keywords:
Status: CLOSED DUPLICATE of bug 173453
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
URL:
Whiteboard:
: 173734 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-17 02:06 UTC by Horst H. von Brand
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-11-17 16:52:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Horst H. von Brand 2005-11-17 02:06:34 UTC
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):
emacs-21.4-8

How reproducible:
Always

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

Expected results:
emacs window...

Additional info:

Comment 1 Jens Petersen 2005-11-17 08:08:22 UTC
X team, any ideas about this one?

Comment 2 Jens Petersen 2005-11-17 08:09:50 UTC
Is this because /usr/X11R6/lib/X11/rgb.txt moved, perhaps?

Comment 3 Jens Petersen 2005-11-17 08:12:06 UTC
Maybe not - emacs seems to include its own rgb.txt fwiw.

Comment 4 Mike A. Harris 2005-11-17 09:51:51 UTC
This is most likely a dupe of bug #173036.

Comment 5 Mike A. Harris 2005-11-17 12:27:41 UTC
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 16:02:37 UTC
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 16:42:01 UTC
CLOSED->DEFERED is not the correct bug state.


Comment 8 Mike A. Harris 2005-11-17 16:52:26 UTC

*** This bug has been marked as a duplicate of 173453 ***

Comment 9 Jens Petersen 2005-11-21 07:26:15 UTC
*** Bug 173734 has been marked as a duplicate of this bug. ***

Comment 10 Jens Petersen 2005-11-21 07:35:58 UTC
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 07:46:49 UTC
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 09:14:38 UTC
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.