|Summary:||x11-base/xorg-server-1.6.2-r2, Xvfb fails to start without some old fonts|
|Product:||Gentoo Linux||Reporter:||Gilles Dartiguelongue <eva>|
|Component:||[OLD] Library||Assignee:||Gentoo X packagers <x11>|
|Severity:||normal||CC:||axiator, bmschwar, gengor, hongqn, mehmet, pacho|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Gilles Dartiguelongue (RETIRED) 2009-07-20 16:02:05 UTC
+++ This bug was initially created as a clone of Bug #265911 +++ remi asked me to feel this so this can double checked.
Comment 1 Samuli Suominen (RETIRED) 2009-07-20 16:06:27 UTC
IMHO, it's been like that since 7.0 that you need font-misc-misc at least, maybe font-cursor-misc as well to start X server at all for font "Fixed" I was adviced to this by upstream X.org dev "ajax" on #xorg years ago when we first migrated into modular X and I wasn't even a dev yet
Comment 2 Rémi Cardona (RETIRED) 2009-07-20 21:20:48 UTC
(In reply to comment #1) > IMHO, it's been like that since 7.0 that you need font-misc-misc at least, > maybe font-cursor-misc as well to start X server at all for font "Fixed" Indeed, that's been true for the past, say, 30 years or so. But recently, work was done to make those fonts optional. Just take a look at the 50 non-EXA-related patches that we ship for 1.5.3, there are half a dozen or so that deal with this very issue. Xorg _is_ able to start without any core fonts, now the real question is: why can't Xvfb? /me will look into it... someday... Thanks
Comment 3 Gordon Malm (RETIRED) 2009-08-08 19:46:26 UTC
(In reply to comment #2) > Xorg _is_ able to start without any core fonts, now the real question is: why > can't Xvfb? > > /me will look into it... someday... > Until then I've added media-fonts/font-cursor-misc to RDEPEND when USE !minimal (was dropped after xorg-server-1.4). Things like media-sound/rubyripper using virtualx.eclass completely fail to compile/install and Xvfb can't be started manually either.
Comment 4 Rémi Cardona (RETIRED) 2009-08-10 06:31:37 UTC
*** Bug 280523 has been marked as a duplicate of this bug. ***
Comment 5 Rémi Cardona (RETIRED) 2009-08-10 17:34:33 UTC
Ok, I've found the real cause of the bug. - Xvfb and Xepyhr, like Xorg, do _not_ require font files any more. They can use the ugly-like-hell 'fixed' font that's literally compiled into libXfont. - Xorg always adds "built-ins" at the end of the font path, while the other DDXs do not, that's why Xorg would work but not the others. So, I've fixed the virtualx eclass to use "built-ins" as the font path, which should solve all FEATURES=test issues. I'll come up with a proper Xorg patch to fix this bug once and for all. @Gordon, btw, please don't change the indentation when fixing X ebuilds, it clobbers the diff for no reason. Thanks
Comment 6 Gilles Dartiguelongue (RETIRED) 2009-08-11 08:54:25 UTC
I suggest sending a mail to dev ml once this is fixed so everyone can review their weird bugs and see if it's in any way related to this issue.
Comment 7 Gordon Malm (RETIRED) 2009-08-11 16:17:57 UTC
(In reply to comment #5) > @Gordon, btw, please don't change the indentation when fixing X ebuilds, it > clobbers the diff for no reason. I'm sorry, I was simply unifying that part of the DEP indentation style with the later ebuilds a tad for better readability. Thanks for fixing up virtualx.eclass.
Comment 8 Rémi Cardona (RETIRED) 2009-08-24 08:30:00 UTC
I've started working on a patch that moves the append-built-ins-to-FontPath code from hw/xfree86 (the "regular" Xorg server) to dix/. That way, all servers (xnest, xvfb, kdrive, ...) should be able to use the internal "fixed" font by default.
Comment 9 Rémi Cardona (RETIRED) 2009-09-04 23:29:42 UTC
I've finally gotten around to writing the patch, and I now have something that I'm happy with. Please test xorg-server-188.8.131.521-r1 and let me know how it works for you. It works for me with Xorg, Xvfb and Xnest. I'll send the patch upstream within a few days for inclusion in the 1.6 and master branches. Thanks
Comment 10 Rémi Cardona (RETIRED) 2009-09-17 08:40:52 UTC
Patch is in master in time for 1.7 and I've nominated it for inclusion in the 1.6 branch. Hopefully, this is now a done deal :) Thanks