Bug 243127

Summary: Nepomuk strigi based desktop search no longer working when akonadi is running
Product: nepomuk Reporter: krienke
Component: generalAssignee: Sebastian Trueg <sebastian>
Status: RESOLVED DUPLICATE    
Severity: normal CC: franz.trischberger, trueg
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: relevant part of .xsession-errors

Description krienke 2010-06-29 10:33:00 UTC 
Version:           unspecified (using KDE 4.4.4) 
OS:                Linux

I am runnin KDE 4.4.4 on my opensuse 11.2 box. When I log in and have an empty session everything works fine. I can use dolphin to do a nepomuk strigi search . This works fine. 
Next I manually start akonadi server via KDE menu->"Akonadi setup". The server starts without problems but afterwards the nepomuk/strigi desktop search  using dolphon does no longer work (yields always 0 results) and the nepomok file indexer  (I guess this is strigi, the app with ping and blue circles as an icon, that is still running) reports many error in .xsession-errors:

061520 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
[/usr/bin/nepomukservicestub] "/usr/bin/nepomukservicestub(18496)" Error in thread 140257547061520 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
[/usr/bin/nepomukservicestub] "/usr/bin/nepomukservicestub(18496)" Error in thread 140257547061520 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
knotify(18365) KNotify::event: 47  ref= 0

This does not happen if I do not start akonadi server.  If I have a session that starts kontact which in turn automtically start akonadi, then desktop search does not work at all. So it seems that akonadi and nepomuk and strigi live with each other.

This did not happen with KDE 4.4.3 on the same machine. With KDE 4.4.3 everything was fine.

Any idea?

Reproducible: Always

Steps to Reproduce:
Just login with a KDE session that opens kontact and so starts akonadiserver.
Comment 1 Sebastian Trueg 2011-01-06 20:39:51 UTC 
can this be reproduced with KDE 4.6rc2?
Comment 2 Franz Trischberger 2011-02-18 21:19:45 UTC 
I have the same problem, running kde-4.6.0, kdepim-4.5.94.1, soprano-2.6.0, akonadi-server-1.5.0 (so latest releases)
Here is the content from .xsession-errors after giving a file 5 stars and selecting "3 or higher" in the filter-paneln (Attachement, as too long).

The funny thing: The information for files show every semantic data: keywords, stars etc. are shown correctly, it is just the search that returns no results.

I think this I remember, this appeared after upgrade to kde-4.6.0. As the update made kdepim-4.4.9 crash and behave weird, and the 4.4.10-Update did not really fix this (Kontact just disappearing, closing all children and the mail-composer, no Error-Messages etc) i did the (painful) move to 4.5.94.1. With no change in nepomuksearch returning no results.
Comment 3 Franz Trischberger 2011-02-18 21:24:17 UTC 
Created attachment 57362 [details]
relevant part of .xsession-errors
Comment 4 Franz Trischberger 2011-02-26 19:47:46 UTC 
My problem is solved! It was caused by a conflicting librasqal.so.
I am sure openoffice installed a librasqal.so.1. redland linked against this .so.1. The packagemanager (gentoo/paludis) installed a .so.2 (which redland semms to really need).
I stumbled across this problem while moving from openoffice to libreoffice. libreoffice claimed to not find librasqal.so.1 (so i am sure openoffice installed this, as nothing else changed during upgrade).
So after reinstalling redland, which now links librasqal.so.2, libreoffice built fine and -YEAH!- nepomuksearch finally returns results again!

So solved for me, dont's know if the original problem is also related to this conflict.
Comment 5 Sebastian Trueg 2011-09-26 09:27:02 UTC 

*** This bug has been marked as a duplicate of bug 269442 ***
Comment 6 krienke 2011-09-26 12:43:52 UTC 
In between I am running 4.7.1. The problem reported does no longer exist.