hello all in finkland,

instead of mailing only with an issue i can't solve, i thought it might be nice 
to report a success and to tell about the weird things that are going on with 
it that i don't understand. maybe someone else knows what's going on, and 
hopefully someone else can benefit from this posting.

i'm running a MacBookPro5,5 (13"), snow leo
> [...@mpop:~]$ uname -a
> Darwin mpop.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 
> PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386
> [...@mpop:~]$ fink -V
> Package manager version: 0.29.10
> Distribution version: selfupdate-rsync Thu Mar 25 23:27:14 2010, 10.6, i386
> ...
> [...@mpop:~]$ xcodebuild -version
> Xcode 3.2.1
> Component versions: DevToolsCore-1614.0; DevToolsSupport-1591.0
> BuildVersion: 10M2003

i ran
> $fink install bundle-kde-ssl-x11

several times, always running into the 'could not resolve inconsistent 
dependencies', running the suggested apt-get command, getting a little farther, 
etc, but then decided to stop being greedy and just get enough to run dolphin 
under kwin, which is all i really wanted. so i managed to get the things i 
needed to compile and install just fine (strategy: if a big package fails, stop 
and install a smaller dependency and then try again!):

> [...@mpop:~]$ fink list -i kde
> Information about 8787 packages read in 0 seconds.
>  i   kde4-buildenv        4.4.0-1         Scripts for simplifying KDE4 builds
>  i   kdebase4-runtime-x1  4.4.1-1         KDE4 - base applications and tools 
> (runtime)
>  i   kdebase4-workspace-  4.4.1-1         KDE4 - base applications and tools
>  i   kdebase4-workspace-  4.4.1-1         KDE4 - base shared libraries
>  i   kdebase4-x11         4.4.1-1         KDE4 - base runtime
>  i   kdebase4-x11-shlibs  4.4.1-1         KDE4 - base shared libraries
>  i   kdelibs4-x11         4.4.1-1         KDE4 - essential libraries
>  i   kdelibs4-x11-dev     4.4.1-1         KDE4 - essential development 
> libraries and headers
>  i   kdelibs4-x11-shlibs  4.4.1-1         KDE4 - essential shared libraries
>  i   kdepimlibs4-x11      4.4.1-1         KDE4 - PIM support libraries
>  i   kdepimlibs4-x11-dev  4.4.1-1         KDE4 - PIM support development 
> libraries and headers
>  i   kdepimlibs4-x11-shl  4.4.1-1         KDE4 - PIM support shared libraries

great! but i ran into some problems running the software. i'd seen elsewhere 
some related but non-identical problems (and one that seems identical: 
http://archive.netbsd.se/?ml=fink-beginners&a=2010-02&m=12474504 ): when 
anything kde is launched from X11, errors abound:

first, it couldn't find a laundry list of mime-types. that was more or less 
easily solved, as described, e.g., here for other systems:
> http://ubuntuforums.org/archive/index.php/t-118485.html
> http://www.linuxquestions.org/questions/mandriva-30/could-not-find-mime-type-applicationoctet-stream-133908/

but, more seriously:
> Could not start process Cannot talk to klauncher: The name org.kde.klauncher 
> was not provided by any .service files.


plasma-desktop would sort of load, but nothing would work, dolphin would load, 
but no file system could be listed, konqueror would load, but no graphics would 
be found, and also no file system could be seen, etc. the xterm output suggests 
that the problem is that the process couldn't hook into the dbus session:

> kdeinit4: preparing to launch /sw/opt/kde4/x11/lib/kde4/libexec/klauncher
> <unknown program name>(1590)/ launch: kdeinit4: launch() setting argv:  
> /sw/opt/kde4/x11/lib/kde4/libexec/klauncher
> klauncher(1590) kdemain: No DBUS session-bus found. Check if you have started 
> the DBUS server. 
> kdeinit4: Communication error with launcher. Exiting!

however, dbus was definitely running:
> [...@mpop:~]$ ps -cej|grep dbus
> messagebus   108     1   108 8c10888    0 Ss     ??    0:00.00 dbus-daemon
> asl        257   184   257 8c11d40    1 S      ??    0:00.40 dbus-daemon


since i had a ~/.xinitrc file left over and moved from back in the Tiger days 
(not so long ago for me), and the whole method of X11 startup has changed since 
then, i thought it might have something to do with that (as suggested in the 
linked fink-beginners archive above). so i dove into the process of changing 
over to the current snow leopard setup that seems to be way too convoluted for 
it's own good. since i couldn't find anything anywhere that clearly went 
through how, i'll post here what i did:

1. comment/get rid of any explicit definition of $DISPLAY in 
~/.{bashrc,profile,bash_profile} or wherever else you might have it
        (this variable now gets set in one script or another)
2. make sure you've run 
        $fink installl xinitrc
3. copy:
        $sudo cp /sw/bin/xinitrc.sh /sw/etc/xinitrc-override
4. go to the bottom of your new xinitrc-override file and comment out the 
following block (you'll need to sudo emacs or vi or whatever again):
> # Start the session or window manager
> #if test x"$xinitrc_sessionmgr" != x; then
> #    :
> #elif type quartz-wm >/dev/null 2>&1; then
> #    xinitrc_sessionmgr="`which quartz-wm`"
> #elif test -x "$x_bindir/twm"; then
> #    xinitrc_sessionmgr="$x_bindir/twm"
> #else
> #    xinitrc_sessionmgr="twm"
> #fi

and add underneath this comment:
xinitrc_sessionmgr=`which kwin` #or /path/to/your/window/manager

was all that necessary? i don't know, but at least i know that the ~/.xinitrc 
setup wasn't part of the problem, as i did all this, and the dbus/klauncher 
problem persisted. FINALLY, i hit upon what the solution was (frustratingly 
simple!):
        if i launched any kde app at all from Terminal.app, everything works!
        if i launched any kde app at all from X11 xterm, the error is there!

i thought for a second that it might be because the Terminal.app session was a 
login shell, but invoking
        $xterm -ls
does NOT solve the issue when launching from xterm. i guess for whatever 
reason, shells in the X11 environment can't hook into a process owned/spawned 
by the aqua environment, or something like that? seems sort of plausible, but 
weird, and i don't understand this at all. i do notice a difference in behavior 
that might be related, in the way xterm -ls and Terminal.app work: when i 
launch xterm -ls, it does not display /etc/motd (which i have also leftover 
from Tiger), but does load /etc/{bashrc,profile} and ~/.{bashrc,profile}. some 
kind of permissions issue? (btw, /etc/motd is def. 644) nah, that's probably 
unrelated.

anyway, now i'm running dolphin happily as my file manager, launching things 
from Terminal.app like a nerd, and everything i want to work, works. i hope 
this info will help out someone else who's running into the same or similar 
problems! i'd really like to know why this solution (workaround?) works, if 
anyone has any insight into it.

thanks for reading

-peterwong
.
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fink-beginners mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.beginners

Reply via email to