Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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!