On 07/12/2011 10:01 AM: Some of what Duncan wrote:
>
> You are very likely correct, as kipi-plugins (here on Gentoo ~amd64
> running the kde overlay) installs these service files:
>
> /usr/share/kde4/services/kipiplugin_acquireimages.desktop
> /usr/share/kde4/services/kipiplugin_advancedslideshow.desktop
> /usr/share/kde4/services/kipiplugin_batchprocessimages.desktop
> /usr/share/kde4/services/kipiplugin_debianscreenshots.desktop
> /usr/share/kde4/services/kipiplugin_dngconverter.desktop
> /usr/share/kde4/services/kipiplugin_facebook.desktop
> /usr/share/kde4/services/kipiplugin_flashexport.desktop
> /usr/share/kde4/services/kipiplugin_flickrexport.desktop
> /usr/share/kde4/services/kipiplugin_galleryexport.desktop
> /usr/share/kde4/services/kipiplugin_gpssync.desktop
> /usr/share/kde4/services/kipiplugin_htmlexport.desktop
> /usr/share/kde4/services/kipiplugin_imageviewer.desktop
> ...
> Try checking your kipi-plugins package to see if it installed them and
> where.
>
> Then try stracing gwenview to see where it's looking for them, with a
> command such as this (-f says follow forks, -eopen says report on file-
> open attempts only, 2>&1 redirects STDERR to STDOUT so it can be grepped,
> ENOENT = error, no entry, can't find the file):
>
> strace -feopen gwenview 2>&1 | grep ENOENT
>
> That's still likely to produce a whole slew of output, but you can
> further pipe it to grep -v to remove stuff that looks uninteresting (-v
> reverses the grep, showing only lines that do NOT contain the search
> term).
>
> Eventually you should be able to figure out where it's looking, and
> create symlinks or some such, as necessary (plus file a bug with slack, I
> imagine).
>
> If the package doesn't include those files at all... well, I guess I
> could try sending a tarball. They're not huge. (Mostly they're name and
> comment lines in dozens of different languages, but there's a few real
> operational lines too. It doesn't appear that they include path or
> version info, so any copy you can find should work, and the symlinks
> should stay working across versions as well, as long as the package
> continues putting them in the same place and the apps continue looking
> for them in the same place.
>
OK - the ...services/kipiplugin_*.desktop files were all there - in the
same directory as you have them.
I then went on to the strace on gwenview and modifying slightly your
suggested command, ran:
strace -feopen gwenview 2>&1 | grep kipi
grepping out just the open files with "kipi" in the filenames...
output was quite simple:
open("/usr/lib/qt/lib/libkipi.so.7", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib/libkipi.so.7", O_RDONLY) = 3
which I took to mean the first search for libkipi.so.7 failed (in the qt
sub-directory) but the second one (in /usr/lib/) worked OK. Check - that
file exists (it's a symlink to /usr/lib/libkipip.so.7.1.0) so that
appears to be OK. However what I notice in this directory is that this
file - libkipi.so.7.1.0 and its symlinks is old (March 2011) and was not
part of the install that my latest slackware package did. There is
another file (with symlinks) called /usr/lib/libkipiplugins.so.1.0.0
which *is* part of the latest install.
I guess I should remove / rename the old files - gwenview may then carry
on looking for the newer files (libkipiplugins rather than libkipi) and
the plugins might start up correctly?
___________________________________________________
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
