[kde-linux] Re: Digikam and Gwenview cannot find kipi plugins

[Bogus Zaba]

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?