Bug 173428

Summary:	emacs with modular X: 'Undefined color: "black"'
Product:	[Fedora] Fedora	Reporter:	Horst H. von Brand <vonbrand>
Component:	xorg-x11	Assignee:	X/OpenGL Maintenance List <xgl-maint>
Status:	CLOSED DUPLICATE	QA Contact:	David Lawrence <dkl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	paul, xgl-maint
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-11-17 16:52:26 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:

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.