[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Strange goings on with Juk (FC3, KDE Branch 3.5)
From:       Michael Pyne <pynm0001 () unf ! edu>
Date:       2005-09-29 23:56:56
Message-ID: 200509292000.39696.pynm0001 () unf ! edu
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 29 September 2005 00:42, Steven P. Ulrick wrote:
> After all of that, with me not doing anything that I know of, I began
> to be able to use both versions of Juk that I have installed.  They are
> located at "/usr/bin/" and "/usr/local/kde-svn/bin/"  This is the first
> odd thing: when I click one of the Juk icons on my desktop (all Juk
> icons are for the version that is in the "/usr/local/kde-svn/" path.
> This is the KDE that I export to in my "~/.bash_profile")  the version
> that comes up is the "/usr/bin/" version, version 2.2.1.  Also, "Help |
> About Juk" says that it is using 3.4.91.  I don't know for sure, but I
> THINK that that might not be so odd.  But why would "/usr/bin/juk"
> start up, when that is not the one that the icons point to?
> Stranger still, when I would run "/usr/bin/juk" from a command line,
> the version that came up was 2.3!  That is the branch 3.5 version,
> which is installed at "/usr/local/kde-svn/bin/juk"  "/usr/bin/juk" is
> the latest stable Juk, NOT the branch 3.5 version.  So it seems kind of
> odd that when Juk finally started working for me (don't know why, it
> just started working) I would consistently get the wrong version of
> Juk.

That's very odd.  It sounds as if somehow /usr/bin/juk actually *is* 2.3, and 
the one in /usr/local is 2.2.1 somehow.  Can you compare the dates on the 
files to see which is newer?

> I think that the commands that I use in my "~/.bash_profile" to set my
> Branch 3.5 KDE install to be the one I log in to could be of help to
> you:
>      21 QTDIR=/usr/local/qt-src
>      22 PATH=$QTDIR/bin:$PATH
>      23 MANPATH=$QTDIR/doc/man:$MANPATH
>      24 LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
>      25 export QTDIR PATH MANPATH LD_LIBRARY_PATH
>      26
>      27 KDEDIR=/usr/local/kde-svn
>      28 PATH=$KDEDIR/bin:$PATH
>      29 LD_LIBRARY_PATH=$KDEDIR/lib:$LD_LIBRARY_PATH
>      30 LIBRARY_PATH=$LD_LIBRARY_PATH
>      31 export KDEDIR PATH LD_LIBRARY_PATH LIBRARY_PATH

You may also want to export KDEDIRS=/usr/local/kde-svn to make sure that any 
such setting from /etc/profile is cleared out as well.  KDEDIRS is actually 
the preferred form as well.

> This has always worked before.  Also, Juk is the only application that
> I have found so far that is acting like this.

JuK has rather eccentric library dependencies as well, and is usually the 
"canary" that indicates a library flaw where other programs seem to operate.  
For instance, upgrading arts or juk to version that pulls in a different 
libstdc++ but forgetting to also upgrade musicbrainz or libtunepimp will 
often cause problems that affect only JuK.

If you happen to have GStreamer support installed into JuK you may want to try 
using its output instead of aRts and see if that fixes the crashes.  You'll 
have to manually edit $KDEHOME/share/config/jukrc.  In the [Settings] group, 
set the option MediaSystem=1 (1 is for gstreamer).  If the option isn't 
already there, go ahead and add it.  Save the file and then try running JuK 
again to see if it still crashes.

If you (or your packager) didn't compile gstreamer support into JuK then that 
won't work though.  :-(

Regards,
 - Michael Pyne

[Attachment #5 (application/pgp-signature)]

 =

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<


[prev in list] [next in list] [prev in thread] [next in thread]