Modular X is the future of the X server, it's a new tecnology and many apps are not ready for this at this point, these apps have to be modified for make modular X ready for all. For the problems strictly releated to modular X there is another tracker, bug #112004 Reproducible: Always Steps to Reproduce:
I just fixed ghostscript-gnu and libcaca as well.
I've been through my system determining which systems do not have modular x dependencies. Unfortunately I'm not to certain about how to determine the correct dependencies, and I haven't seen any scripts (like spyderous's included-headers.sh and linking-libs.sh) that will determine the correct runtime dependencies separately from the build time dependencies, so I haven't produced any fixed ebuilds for them. Would it be better to post the complete list here, or file individual bugs without solutions and add them as dependencies here?
(In reply to comment #2) > I've been through my system determining which systems do not have modular x > dependencies. Unfortunately I'm not to certain about how to determine the > correct dependencies, and I haven't seen any scripts (like spyderous's > included-headers.sh and linking-libs.sh) that will determine the correct > runtime dependencies separately from the build time dependencies, so I haven't > produced any fixed ebuilds for them. Would it be better to post the complete > list here, or file individual bugs without solutions and add them as > dependencies here? Have you not seen http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt yet? It describes pretty much the whole process and links to those scripts.
Thanks, I had seen that, although I hadn't thought that was enough to ensure correct dependencies in certain cases such as the requirement for the imake tool, and binary packages (such as vmware-console and opera, both of which are on my need-to-fix list). When I said I hadn't seen scripts that could determine these, I meant ones that use ldd or dumpelf to determine which libraries were linked against. Do these exist yet? I'll get to work on the source-only ebuilds and file individual bugs for any I have fixes for. I guess if they don't work perfectly, someone will just open another bug on it anyway...
betelgeuse has written an ldd-using script -- http://dev.gentoo.org/~betelgeuse/scripts/checkdeps For binary apps, I generally just check to figure out where they install libraries and executables, then run ldd on the whole lot ( find lib/ bin/ -type f | xargs ldd ), cut off the address using cut -d'(' -f1, then pipe to sort | uniq. If you're really lazy, you can track it back to package names but they're usually obvious from the library names. As for applications actually run during the build, you'll have to rely on something like 'grep -e gccmakedep -e xmkmf -e imake /path/to/log'.
Is there anyway to know which package needs update or i have to file a bug for each package i find out?
People are just filing bugs as they come across packages that haven't been ported yet. It's hard to find packages that haven't been ported as there's no definite signature to look for. Looking at the size of the list, it's likely that a bug has already been filed, so search first ;)
FYI I'm busy going thru all of media-fonts/ fixing modular-X issues, as I'm playing with some font stuff at the moment. I'm seeing a number of places where a font package has RDEPEND="virtual/x11" or RDEPEND="X? ( virtual/x11 )", and only installs some docs and a few pcf+bdf files. Since PCF fonts should be usable without having X installed, I'm taking out these useless RDEPEND structures, so you can use PCF fonts standalone (if you have an app that does so).
Bug #118603 should go in the "depends on" list. http://bugs.gentoo.org/show_bug.cgi?id=118603
*** Bug 115071 has been marked as a duplicate of this bug. ***
Bug #143851 should go on the "depends on" list. Thanks.
Nothing left here, closing. SIGPLOP!
