After Updating KDE FW to 5.20 and Plasma to 5.6 (with Qt to 5.6 as well) Akonadi "doesn't work"

English Applications
#1

Hello,

Yesterday I updated My Leap 42.1 Installation to KDE Framework 5.20 and Plasma to 5.6, after I found out through forum posts that from now on KDE Framework and Plasma are being built against Qt 5.6, which is not part of the packages in the respective repos any more, but has to be installed separately from one of the many repos containing different states of Qt 5.6 (wouldn’t it be nice if such changes were announced somewhere officially - I heard there were such things called “blogs” - instead of being rather clandestine tips you have to search for in a forum ;)).

Installation worked fine and everything seems to work well - except KDE Kontact which notified me that Akonadi is not “working properly”. Since the configuration has been okay and working fine since about 2 years, I looked for a missing lib or something, but the yast installation tool reported all dependencies as okay.

So Akonadi seems to be partially working (I get what looks like cached data in the applikations within kontact), but no interaction with the programs is possible, and the “Details”-Button shows no reaction at all…

Any ideas???

Thanks a lot!

Jay

#2

I have done the same update and have the same problem. I’m using KDE:/Frameworks5/OpenSUSE_Leap_42.1 and KDE:/QT5/OpenSUSE_Leap_42.1 which another thread said must be used together. I used the switch system packages button in Yast2 to make sure that all the relevant packages came from the relevant repositories. I get the Akonadi doesn’t work screen in KOrganizer and KMail. In addition (oddly) I have a weather widget on my panel which comes up as needing configuration, even though it is configured. Furthermore, “akonadictl status” shows akonadi as running. After “akonadictl stop”, status still shows akonadi server and ctl as running, and “akonadictl restart” just hangs.

Here is the strange thing (and I’ve done a lot of experimentation to show this is true) – if I go into Yast2, search for all akonadi packages and do a forced update and then log out of KDE and log back in, KMail, Korganizer, and the weather widget all open normally. However, my system activities list shows two instatiations of plasmashell one of which has the status “stopped”. This one can be killed with no effect on the system. To get KMail and KOrganizer to work, you must do both steps - logging out and back in without the update or doing the update without logging out and back in doesn’t work. Also, a complete reboot will always cause the system to come up with the Akonadi problem and must be followed by the update, logout, login procedure to get KMail and KOrganizer to work.

Very strange…

#3

I had my Kontact applications installed from the KDE:/Applications repository. I reverted them to the standard ones from the Leap update repository. This seems to have solved the problem – either that or the latest updates to 5.2 and Plasma 5.6 fixed it. Does this work for you, or was the problem solved just through regular updates?

#4

Right now the problem is not solved for me.

How did you do return to the previous version? In the Leap Update Repo is 5.12.2 , in the KDE/Applicatons it’s 5.12.3 and while preparing the update, yast2 asks for all kontact and akonadi apps to be installed. Did you only change the kontact apps (kontact, kmail, kaddressbook, korganizer …)? Or did you also revert the Akonadi-part?

#5

I don’t think the Qt5, Plasma5, or KF5 updates should have any influence on Akonadi working or not (and it does still work fine on my 13.2 system).

But make sure you don’t mix versions.
I.e. kdepim5 (and its applications like kontact5, kmail5, and so on) won’t work with Akonadi4 (package akonadi-runtime, while Akonadi5 is in akonadi-server) and vice-versa.
And make sure you don’t mix versions between the standard Leap repos and KDE:Applications either.

Also, if you ever started Akonadi5, it’s probably not possible to revert to Akonadi4 without wiping the database.
Upgrades are supported, but not downgrades…

PS: That KDE:Frameworks5 requires KDE:Qt5 is nothing new, actually it does since the repos exist. But Leap 42.1 did contain the latest version of Qt5 (5.5.x), so it was not really necessary. This has changed with the upgrade to Qt 5.6.0 though.

And it is documented (meanwhile) at https://en.opensuse.org/SDB:KDE_repositories.
There was one problem though: the Wiki was locked for a while because of spam attacks, so the page couldn’t be updated either…

#6

This happened to me a few times in those same circumstances but as far as I could tell Akonadi was working but Kontact wasn’t finding it. It seems to have righted itself now and it was intermittent anyway.

#7

THanks for your remarks, wolfi323, but I think you missed the point.

I’m not the “newbie” my profile might indicate, I just happen to be able to find out how to solve most of the problems by myself, or live with them. But this one I don’t understand, but seemingly I am not alone in that.
So I don’t “mix versions”, as this is one of the first things you learn. I know quite well the differences between KDEPim 4 and 5 and the respective akonadi versions.
And I am not talking about any kind of “downgrade”.

So please don’t make up a problem where there is none. (Still there is the fact that for someone who was used to the Opensuse practice of bundling KDE with the respective Qt versions in the same repo - as it was always indicated on the KDE repository pages - the change of policy to unbundling them into different repos comes unexpected and surprising, especially if, as there are, various possibly relevant Qt 5.x repos exist. And I know of at least one case - documented in this forum - where the wrong repo was initially indicated. This doesn’t get any better, if the corresponding wiki pages have “meanwhile” been altered to reflect the change. The right time would have been “before”, not “someday”.)

But be that, as it may: I checked again for the repos I had connected and activated (everything okay) and (again) did a change of system-packages to these repos, with a subsequent install of some packages which had nothing to do with KDEPim or Akonadi, so: nothing changed, problem still there.

Since I have all my KDE Applications from the KDE/Applications Repository with Ver. 15.12.3, I don’t want to go back to Leap/Update where there is 15.2.2, and I don’t think mixing these repos is of any good.

peteh100 is right: akonadi is loaded, but (in my case) with the exception of 2 processes (archive_mail_agent & maildir_ressource0) completely inactive, kontact is also loaded but obviously doing nothing. Seems like the two just don’t connect, which is why e.g. kmail does not show my mail-accounts which are (following the list in ksysguar) obviously loaded by akonadi (and fortunately no mails are retrieved, so I still have chance to communicate).

But nothing has “righted itself” by now, and I still don’t understand, what’s going on here.

So still: any ideas (except from: wait, someday it will wok out …;))

Thanks, Jay

#8

I am assuming that I had a mixed library somewhere and that it had to do with something that was updated on March 29 as that is when the problem started for me (possibly one of the libkf5 calendar, notes, and mail libraries which were installed that day). At any rate, when I reverted everything KDEPIM related from 12.3 in the application repository to 12.2 in the main update library, the problem stopped. Today, I changed all my KDE apps to the KDE:/Applications repository by using switch system packages in Yast2 to make sure that nothing was mixed. So now all my apps are 12.3 and I am having no problem at all. I do seem to recall that when the problem started, there may have been a package that resided in both the QT5 or KF5 repository and the apps repository and that I wasn’t sure that I wasn’t using the wrong one, but there is no such package like that today, so I very well might be remembering wrong. At any rate, on Monday everything was working fine. On Tuesday some update caused the problem, yesterday after shifting KOrganizer, KNotes, KMail, and KContact to 12.2 from the main update repository everything worked fine, and today, having made sure that all my applications were coming from the applications directory by doing a switch system packages to the Applications repository, things are still working fine.

As a note, it was clear that Akonadi was running, but that interaction with the programs was blocked. One could see the mail directories and so forth showing up behind the grayed out area of the screen.

#9

Just one thing: if you upgrade to Akonadi5 (and KDEPIM5) in the running session and used Akonadi4 before, the Akonadi4 server is still running (and cannot be quit either any more).
Logging out and in should “fix” that.

Maybe that was the reason why it was intermittent and righted itself out…

Did I?
I just made some general remarks that might have been the cause.

If that’s not the reason in your case, sorry.

I didn’t want to implicate anything about your knowledge…

(Still there is the fact that for someone who was used to the Opensuse practice of bundling KDE with the respective Qt versions in the same repo - as it was always indicated on the KDE repository pages - the change of policy to unbundling them into different repos comes unexpected and surprising, especially if, as there are, various possibly relevant Qt 5.x repos exist. And I know of at least one case - documented in this forum - where the wrong repo was initially indicated. This doesn’t get any better, if the corresponding wiki pages have “meanwhile” been altered to reflect the change. The right time would have been “before”, not “someday”.)

I hope you are aware that you are using untested semi-official repos there, that are provided at a best-effort basis.
You cannot expect everything working all the time, in fact you actually have to expect problems.

If you want a stable system, stay with the standard repos.

And as I wrote: KDE:Frameworks5 is built against KDE:Qt5 since it exists. The case was just different for Leap 42.1 until recently…

But be that, as it may: I checked again for the repos I had connected and activated (everything okay) and (again) did a change of system-packages to these repos, with a subsequent install of some packages which had nothing to do with KDEPim or Akonadi, so: nothing changed, problem still there.

Ok. So you are having kdepim5 and akonadi-server installed?
You failed to answer that. Just a repo switch might not switch all of that properly.

What does “akonadictl --version” say?
Does the problem exist on a fresh user account?

Since I have all my KDE Applications from the KDE/Applications Repository with Ver. 15.12.3, I don’t want to go back to Leap/Update where there is 15.2.2, and I don’t think mixing these repos is of any good.

Yes, and you shouldn’t go back. Although a switch between 15.12.2 and 15.12.3 shouldn’t cause any problem, in both directions.

#10

I’ve had Kontact5 (and all the plugins) together with Akonadi5 for some months now. The problem only arose with that recent update from the Kde repo. I’ve usually fixed it with a reboot and then not opening kontact for a while and as I’m not sure what’s gone wrong and I haven’t reported it as a bug (I wouldn’t be able say any more than it’s not working sometimes)
As I say it seems to be ok now so I’m keeping my fingers crossed.
I also undeerstand your point, wolfi, about using the non-standard repos, although they are usually stable.

#11

Ok, then the reason in your case is definitely not that switch… Just wanted to mention it though.

Regarding Akonadi5, I haven’t experienced such a problem. But then, I’m not using it myself on a regular basis, I’m still in 13.2 with KDEPIM4.
(I have both installed though, using my own repos… :wink: )

The point about updates still applies though.
If you install updates in the running session, strange things can happen (not only with Akonadi, but KDE in general).
In the case of Akonadi, “akonadictl restart” (instead of rebooting) might help though.

I also undeerstand your point, wolfi, about using the non-standard repos, although they are usually stable.

Yeah, they should be stable, we try to do our best… :wink:
But things can happen, when we notice problems we try to fix them as soon as possible though.

#12

I had the experience with logging in and out, but it did not involve any changed/upgraded packages. My experience was - reboot and the problem manifested itself. Log out of KDE, log back in and the problem was “fixed”. Reboot and the problem reappeared and was fixed again by the log out/log in procedure. No package changes were involved. Something was running in the bootup session (which remained in the process list after the logout/login procedure) that was not running in the newly logged in session. Could mixed packages cause the system to boot up with Akonadi4 and then switch in a new session to Akonadi5?

At any rate, the problem is fixed and did have something to do with mixed packages as Wolfi suggested. His presence in these forums has been a life saver for me and I really appreciate it.

#13

Normally not. Akonadi5 should replace Akonadi4, you shouldn’t even be able to have both installed.
That’s if you use the “standard” repos of course (with this I do include KDE:Applications). If you use my repo (i.e. home:wolfi323:branches:KDE:Frameworks5), you can have both installed (that’s the actual purpose of it) and this might indeed be a problem.

But then that should persist when logging out and in as well.

Probably that is/was some timing problem, i.e. something did not start early enough on a cold reboot.
Logging out/in changes the timings, because everything (or some things at least) might already be in the kernel’s disk caches.
But restarting the akonadi server (“akonadictl restart”) should help then too.

#14

Wolfi, sorry if my last post was a bit harsh, I know that moderating a forum (and its users) can be a nuisance sometimes. I’m not of the bullying type, and didn’t want to criticize your general remarks, but I had the experience of moderators who took me for someone with no idea at all what he was talking about … which is - in my view - a bullying story of its own. So please forgive the tone of that last post. Where would users like me be with their problems without your work!

I never had a similar problem with the “unofficial” repos, and in my experience they are (most times) better than the official ones … but that is just me …

So, to you questions: Yes, Its KDEPIM 5.1.3 and Akonadi 5.1.51, which are, as far as I can see the current iterations of both . Or am I mistaken? I had made the transfer to PIM5 and Akonadi months ago (january or so) and both do not work without one another. Its only irritating during the transfer that both are still available alongside one another in the repos.

I have not tested a fresh user account, since everything worked fine until recently :wink: and I didn’t change a thing …

Perhaps I can try a fresh account tomorrow … or is there anything else I could do?

#15

They are at least more up-to-date and always contain the latest versions, so they get fixes sooner…
Though at least upto 15.12.3 (and Plasma 5.5.5, KDE Frameworks 5.20.0), the latest versions have been submitted as official update for Leap 42.1 too. And we do backport fixes too if possible/sensible.

So, to you questions: Yes, Its KDEPIM 5.1.3 and Akonadi 5.1.51, which are, as far as I can see the current iterations of both . Or am I mistaken?

Yes, that are the latest (stable) versions from KDE Applications 15.12.3.

Its only irritating during the transfer that both are still available alongside one another in the repos.

Well, Leap 42.1 came with KDEPIM4 as default, because KDEPIM5 was brand new at that time and not stable enough.
And we cannot remove packages from a released product.

Also, some applications have been removed in KDEPIM5 (kjots, ktimetracker, knode) so an automatic switch might negatively “surprise” people.

42.2 will come with only KDEPIM5 though I suppose.

I have not tested a fresh user account, since everything worked fine until recently :wink: and I didn’t change a thing …

Perhaps I can try a fresh account tomorrow … or is there anything else I could do?

What does “akonadictl status” say? (run it as user)

Have you tried to start the single applications stand-alone? (e.g. korganizer, kaddressbook, kmail)

Does akonadiconsole work?

Have you tried to restart Akonadi?
It might be a good idea to do that in a Konsole and watch the output. Maybe there’s some error message.

#16

Okay … I tried with a fresh user account: Same problem there. akonadi was running, but kontact reported it as “not working properly”. Since there were no email accounts the mail account assisted started, indicating: “Akonadi Server is being started” (while it was already running) which was obviously fruitless, so I shut down the assistant after 5 or 6 minutes. That test was important for me too, because the email, carddav and caldav accounts I had defined in Akonadi are not displayed in the config windows - but thats not because they are gone, and have caused the troubel, but its obviously akonadi thats not displaying them.

So looks very much like a communication problem between Kontact and akonadi.

Just for the record: Akregator is running fine within Kontact (on both, my current and the fresh account).

Output of akonadictl staus:

akonadictl status
Akonadi Control: running
Akonadi Server: running
search paths:  ("lib64", "lib64/qt5/plugins/", "lib64/kf5/", "lib64/kf5/plugins/", "/usr/lib/qt5/plugins/", "/usr
/lib64/qt5/plugins", "/usr/bin")
Akonadi Server Search Support: available (Remote Search)
Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_
contacts_resource, akonadi_davgroupware_resource, akonadi_followupreminder_agent, akonadi_googlecalendar_resource
, akonadi_googlecontacts_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonad
i_indexing_agent, akonadi_invitations_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_knut_r
esource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent
, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, a
konadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlate
r_agent, akonadi_vcard_resource, akonadi_vcarddir_resource

Akonadiconsole needs long for a reaction and the brings up the same message as Kontact: "The Akonadi-Service for personal Information-Management isn’t working properly/correctly " (in german!)

Restarting the Server from Akonadi Console brings up a message “Akonadi-Server is being started” and thats running now for 5 Minutes without anything happening that could be seen in ksysguard.

And this is the output in konsole from starting Akonadi Console and restarting AkonadiServer from within:

akonadiconsole                                                                                                                          
""
connectToServer "/tmp/akonadi-jmbarkei.8CV1R5/akonadiserver.socket"
"AkonadiConsole Browser Widget"
connectToServer "/tmp/akonadi-jmbarkei.8CV1R5/akonadiserver.socket"
Connected to "Akonadi" , using protocol version 52
Server says: "Not Really IMAP server"
Connected to "Akonadi" , using protocol version 52
Server says: "Not Really IMAP server"
org.kde.akonadi.ETM: GEN true true true
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM: GEN true false true
org.kde.akonadi.ETM: collection: QVector()                                                                        
org.kde.akonadi.ETM: GEN true false true                                                                          
org.kde.akonadi.ETM: collection: QVector()                                                                        
org.kde.akonadi.ETM: GEN true false true                                                                          
org.kde.akonadi.ETM: collection: QVector()                                                                        
org.kde.akonadi.ETM: Subtree:  279 QSet(279, 320, 318, 319, 316, 317, 315)                                        
org.kde.akonadi.ETM: Subtree:  7 QSet(7)                                                                          
org.kde.akonadi.ETM: Subtree:  1 QSet(306, 307, 1)                                                                
org.kde.akonadi.ETM: Fetch job took  254 msec                                                                     
org.kde.akonadi.ETM: was collection fetch job: collections: 11                                                    
org.kde.akonadi.ETM: first fetched collection: "Search"                                                           
org.kde.akonadi.ETM: Subtree:  9 QSet(9)                                                                          
org.kde.akonadi.ETM: Subtree:  102 QSet(102)                                                                      
org.kde.akonadi.ETM: Subtree:  103 QSet(103)                                                                      
org.kde.akonadi.ETM: Subtree:  258 QSet(258)                                                                      
org.kde.akonadi.ETM: Subtree:  256 QSet(256)                                                                      
org.kde.akonadi.ETM: Fetch job took  258 msec                                                                     
org.kde.akonadi.ETM: was collection fetch job: collections: 5                                                     
org.kde.akonadi.ETM: first fetched collection: "Notizen"                                                          
org.kde.akonadi.ETM: Subtree:  279 QSet(279, 320, 321, 318, 319, 316, 317, 315)                                   
org.kde.akonadi.ETM: Subtree:  7 QSet(7)                                                                          
org.kde.akonadi.ETM: Subtree:  1 QSet(306, 307, 1)                                                                
org.kde.akonadi.ETM: Subtree:  298 QSet(298)
org.kde.akonadi.ETM: Fetch job took  263 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 13
org.kde.akonadi.ETM: first fetched collection: "Search"
org.kde.akonadi.ETM: Subtree:  9 QSet(9)
org.kde.akonadi.ETM: Subtree:  102 QSet(102)
org.kde.akonadi.ETM: Subtree:  279 QSet(296, 279, 297, 320, 321, 318, 319, 316, 317, 315)
org.kde.akonadi.ETM: Subtree:  103 QSet(103)
org.kde.akonadi.ETM: Subtree:  7 QSet(7)
org.kde.akonadi.ETM: Subtree:  175 QSet(176, 177, 253, 190, 175, 188, 189, 186, 187, 184, 185, 182, 183, 180, 181, 178, 179)
org.kde.akonadi.ETM: Subtree:  4 QSet(254, 252, 250, 251, 70, 248, 71, 249, 69, 66, 64, 65, 78, 79, 192, 76, 77, 75, 72, 80, 37, 34, 35, 32, 33, 46, 47, 44, 42, 43, 172
, 40, 173, 41, 171, 55, 52, 53, 51, 48, 49, 62, 63, 60, 61, 58, 191, 59, 56, 57, 6, 4, 5, 12, 13, 10, 11, 22, 23, 20, 21, 18, 19, 16, 278, 17, 30, 31, 277, 28, 29, 26, 
27, 24, 25, 247)
org.kde.akonadi.ETM: Subtree:  258 QSet(258)
org.kde.akonadi.ETM: Subtree:  256 QSet(256)
org.kde.akonadi.ETM: Subtree:  1 QSet(259, 306, 307, 1)
org.kde.akonadi.ETM: Subtree:  15 QSet(15)
org.kde.akonadi.ETM: Subtree:  298 QSet(298)
org.kde.akonadi.ETM: Fetch job took  278 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 115
org.kde.akonadi.ETM: first fetched collection: "Search"
Starting/Stopping Akonadi (using an event loop).

… and nothing more. A after akonadi restart in the Konsole, there is nothing happening.

And the single applications just display the same message as kontact. … if they come up …

So, what do we know now:

  1. it’s not a problem of configuration (otherwise it would have worked from within the fresh account.
  2. It looks like a problem of communication between Kontact and akonadi but can’t see where it might come from …

Thanks for your time!!

Jay

#17

Yes, Akregator doesn’t use Akonadi.

Output of akonadictl staus:

Looks ok, Akonadi seems to be running.

Akonadiconsole needs long for a reaction and the brings up the same message as Kontact: "The Akonadi-Service for personal Information-Management isn’t working properly/correctly " (in german!)

Why are you explicitly writing “in german!” here? Is that unexpected, i.e. is your system not configured to run in german?

But if akonadiconsole doesn’t work as well, we probably can rule out a kdepim package mixture.

Still, I’d like to check that. (and please don’t feel offended! :wink: )
What does this say?

rpm -qa | grep kdepim

I do think such a problem could happen if some KDE4 resource is installed.

That reminds me of people having problems when baloo-pim (i.e. the KDE4 version) was installed, I remember reports of people having both this and the KF5 version (in akonadi-search) installed.
So please check that and remove baloo-pim if it is installed.

And this is the output in konsole from starting Akonadi Console and restarting AkonadiServer from within:

I see nothing wrong there.

But it proves at least that you have Akonadi5 running (Akonadi4 has protocol version 44… :wink: )

So, what do we know now:

  1. it’s not a problem of configuration (otherwise it would have worked from within the fresh account.

Right. And it’s also not caused by a corrupt database or something like that.

  1. It looks like a problem of communication between Kontact and akonadi but can’t see where it might come from …

Yeah, that’s how it looks like. Or Akonadi hanging and not responding.

#18

Okay, I know that there are some kdepim libs on my system for compatibility reasons, and the command does show this:

> rpm -qa | grep kdepim
**kdepim**libs4-4.14.10-3.7.x86_64
lib**kdepim**-15.12.3-42.2.x86_64
**kdepim**-runtime-15.12.3-27.1.x86_64
lib**kdepim**libs4-4.14.10-3.7.x86_64
**kdepim**-15.12.3-42.2.x86_64

So, as far as I can see, the 4.14.10 KDE4 libs are in here for compatibility and therefore have the “…libs4”-ending. Or am I mistaken?
Moreover: they are there for a long time now, it seems, and never had any influence. Yast2-install reports that removing kdepimlibs4 would break e.g. all of the calligra office suite (in total 21 packages), removing libkdepimlibs4 would affect 173 other KDE Apps, which is nearly the complete KDE Stock, as it seems. So this cant be right somehow … and there seems to be no replacement ( like e.g. later versions (15.12.x or else) …

The “german” remark was only to indicate that I know that my translation of the Akonadi message was possibly faulty; I have just the german version of it …

baloo-pim is not on my system.

Akonadi hanging and not responding is certainly possible, but reproducibly under such different conditions (old and fresh install)??? That seems VERY odd…

Sorry for the late reply, but sometimes …

So what do I do?

#19

They were always called …libs4, just like kdepim4 always was called kdepim4 (to differentiate it from kdepim3 I suppose).
The KDE4 libs should not cause a problem, they are needed by KDE4 applications that are built with Akonadi support.

The “german” remark was only to indicate that I know that my translation of the Akonadi message was possibly faulty; I have just the german version of it …

Ok.

baloo-pim is not on my system.

Good.
Just as a guess, try to uninstall akonadi_search then too. The search/indexing agent always was a possible source of problems…
If it doesn’t help, you can just install it again.

Akonadi hanging and not responding is certainly possible, but reproducibly under such different conditions (old and fresh install)??? That seems VERY odd…

Well, it might be a bug, or some incompatibility (with Qt 5.6 e.g.).
Your problem seems VERY odd anyway, especially if others do not have it.

Your fresh install was using the defaults? Or did you make some specific changes (except switching to KDEPIM5)?

So what do I do?

Good question.
I suppose removing the extra repos and switching everything back to the versions in the standard repos (via “zypper dup” e.g.) should make it work.

But then, the same combination (Qt 5.6.0 from KDE:Qt5, KDE Frameworks 5.20.0 from KDE:Frameworks5, Akonadi and KDEPIM5 from KDE:Applications) fine here on my 13.2 system.
There is one difference though: KDE:Applications is built against KDE:Qt5 for 13.2, but not for Leap, so the Leap packages are actually built against Qt 5.5.1.
Should not cause a problem normally, but who knows…
Although this only affects the kdepim packages and not Akonadi, because Akonadi hasn’t been updated (and therefore being rebuilt) since Qt 5.6.0 has been released I think.

I will probably try it in my Leap VM later, to see whether there is a general problem.

Other things you could try:

  • Stop akonadi explicitly with “akonadictl stop”, does it quit properly? Then restart it again with “akonadictl start”.
    Do the apps work then?

  • The communication with Akonadi is done via DBUS. Can you reach the server when it doesn’t work?
    E.g. try:

qdbus org.freedesktop.Akonadi /notifications subscribers

Does that give some (a lot of) output, or does it hang/timeout?

  • Also to rule out some problem with MySQL/MariaDB (although it doesn’t look like that), try setting “Driver=QSQLITE3” in ~/.config/akonadi/akonadiserverrc (stop Akonadi first with “akonadictl stop” and restart it afterwards with “akonadictl start”).
#20

I tried some things, one might hint to something, but I am not sure:

  • akonadi_search is not on my system, just akonadi-search from akonadi5, and there never was a problem.

  • fresh install was without anything, virgin, so to speak.

  • I tried to move the akonadi/kontact bunch back to the standard repos, but that didn’t change a thing. Moving completely back to standard repos would be the last resort, but I don’t want to do it just now.

  • akonadictl stop leads directly to new prompt, akonadictl start thereafter leads to “Akonadi is already running”, so it seems, like it hangs somehow.

  • then:

qdbus org.freedesktop.Akonadi /notifications subscribers
qdbus: I don't know how to display an argument of type 'ao', run with --literal.
  • I also tried to start kontact from konsole tih the following output (which stopped after the last line), took a while till the program started, I stopeed it then with ctl-c. Maybe this hints somewhere.
> kontact
"KMail Kernel ETM"
""
connectToServer "/tmp/akonadi-jmbarkei.8CV1R5/akonadiserver.socket"
connectToServer "/tmp/akonadi-jmbarkei.8CV1R5/akonadiserver.socket"
Connected to "Akonadi" , using protocol version 52
Server says: "Not Really IMAP server"
Connected to "Akonadi" , using protocol version 52
Server says: "Not Really IMAP server"
org.kde.akonadi.ETM: GEN true false false
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM:  
org.kde.akonadi.ETM: GEN true false true
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM: GEN true false true
org.kde.akonadi.ETM: collection: QVector()
org.kde.akonadi.ETM: GEN true false true
org.kde.akonadi.ETM: collection: QVector()
QObject::connect: No such signal QDBusAbstractInterface::iconChanged(bool,QString,QString)
org.kde.akonadi.ETM: Subtree:  15 QSet(15)
org.kde.akonadi.ETM: Subtree:  1 QSet(1, 259)
org.kde.akonadi.ETM: Subtree:  4 QSet(80, 192, 65, 64, 66, 69, 71, 70, 72, 75, 77, 76, 79, 78, 49, 48, 51, 53, 52, 55, 57, 56, 59, 191, 58, 61, 60, 63, 62, 33, 32, 35, 34, 37, 171, 41, 173, 40, 172, 43, 42, 44, 277, 47, 46, 17, 278, 16, 19, 18, 21, 20, 23, 22, 25, 24,
 27, 26, 29, 28, 31, 30, 5, 4, 6, 11, 10, 13, 12, 247, 249, 248, 251, 250, 252, 254)
org.kde.akonadi.ETM: collection: "theBlueprint.biz"
org.kde.akonadi.ETM: Fetch job took  712 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 79
org.kde.akonadi.ETM: first fetched collection: "Search"
"http://www.kde.org/dotkdeorg.rdf"
"https://www.linux.com/rss/feeds.php"
"http://planetkde.org/rss20.xml"
"http://pim.planetkde.org/rss20.xml"
"http://www.kde.org/dot/kde-apps-content.rdf"
"http://www.kde.org/kde-look-content.rdf"
"http://news.opensuse.org/?feed=rss2"
"http://planet.opensuse.org/en/rss20.xml"
"http://www.heise.de/newsticker/heise.rdf"
"http://www.heise.de/open/news/news.rdf"
"http://www.heise.de/tr/news.rdf"
"http://www.heise.de/tp/news.rdf"
"http://www.spiegel.de/schlagzeilen/eilmeldungen/index.rss"
"http://www.spiegel.de/schlagzeilen/index.rss"
"http://www.spiegel.de/schlagzeilen/tops/index.rss"
"http://www.faz.net/aktuell/?rssview=1"
"http://www.wissenschaft.de/rss/1.0/news.rdf"
"http://tagesspiegel.feedsportal.com/c/33356/f/566373/index.rss"
"http://tagesspiegel.feedsportal.com/c/33356/f/566375/index.rss"
org.kde.akonadi.ETM: collection: "jmbarkei@gmail.com"
org.kde.akonadi.ETM: collection: "Veranstaltungen"
org.kde.akonadi.ETM: Fetch job took  1021 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 12
org.kde.akonadi.ETM: first fetched collection: "Search"
org.kde.akonadi.ETM: Subtree:  1 QSet(1, 307, 306)
org.kde.akonadi.ETM: Subtree:  7 QSet(7)
org.kde.akonadi.ETM: Subtree:  279 QSet(315, 320, 317, 316, 319, 318, 279)
org.kde.akonadi.ETM: Fetch job took  1038 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 11
org.kde.akonadi.ETM: first fetched collection: "Search"
 PLUGIN : identifier "application/octet-stream@QByteArray"
registering Desktop file "/usr/share/akonadi/plugins/serializer//akonadi_serializer_addressee.desktop" for ("text/vcard", "text/directory") @ ("legacy", "default", "KContacts::Addressee")
registering Desktop file "/usr/share/akonadi/plugins/serializer//akonadi_serializer_contactgroup.desktop" for ("application/x-vnd.kde.contactgroup") @ ("legacy", "default", "KContacts::ContactGroup")
registering Desktop file "/usr/share/akonadi/plugins/serializer//akonadi_serializer_kalarm.desktop" for ("application/x-vnd.kde.alarm", "application/x-vnd.kde.alarm.active", "application/x-vnd.kde.alarm.archived", "application/x-vnd.kde.alarm.template") @ ("default", 
"KAlarmCal::KAEvent")
registering Desktop file "/usr/share/akonadi/plugins/serializer//akonadi_serializer_kcalcore.desktop" for ("text/calendar", "application/x-vnd.akonadi.note", "application/x-vnd.kde.notes") @ ("default", "KCalCore::Incidence*")
registering Desktop file "/usr/share/akonadi/plugins/serializer//akonadi_serializer_mail.desktop" for ("message/rfc822", "message/news", "text/x-vnd.akonadi.note") @ ("legacy", "default", "KMime::Message*")
registering Desktop file "/usr/share/akonadi/plugins/serializer//akonadi_serializer_socialfeeditem.desktop" for ("text/x-vnd.akonadi.socialfeeditem") @ ("Akonadi::SocialFeedItem")
ItemSerializerPluginLoader:  found 33 plugins.  

 PLUGIN : identifier "text/vcard@default"
 PLUGIN : identifier "application/x-vnd.kde.alarm.archived@default"
 PLUGIN : identifier "text/vcard@legacy"
 PLUGIN : identifier "application/x-vnd.kde.contactgroup@legacy"
 PLUGIN : identifier "application/x-vnd.kde.alarm.template@default"
 PLUGIN : identifier "text/directory@default"
 PLUGIN : identifier "message/rfc822@default"
 PLUGIN : identifier "message/rfc822@legacy"
 PLUGIN : identifier "text/vcard@KContacts::Addressee"
 PLUGIN : identifier "application/x-vnd.kde.alarm.active@KAlarmCal::KAEvent"
 PLUGIN : identifier "application/x-vnd.kde.alarm@KAlarmCal::KAEvent"
 PLUGIN : identifier "text/x-vnd.akonadi.note@default"
 PLUGIN : identifier "message/rfc822@KMime::Message*"
 PLUGIN : identifier "text/x-vnd.akonadi.note@legacy"
 PLUGIN : identifier "application/x-vnd.kde.alarm.active@default"
 PLUGIN : identifier "text/directory@legacy"
 PLUGIN : identifier "application/x-vnd.kde.alarm.template@KAlarmCal::KAEvent"
 PLUGIN : identifier "text/x-vnd.akonadi.socialfeeditem@Akonadi::SocialFeedItem"
 PLUGIN : identifier "message/news@default"
 PLUGIN : identifier "text/directory@KContacts::Addressee"
 PLUGIN : identifier "text/calendar@default"
 PLUGIN : identifier "application/x-vnd.akonadi.note@default"
 PLUGIN : identifier "text/calendar@KCalCore::Incidence*"
 PLUGIN : identifier "message/news@KMime::Message*"
 PLUGIN : identifier "application/x-vnd.kde.alarm.archived@KAlarmCal::KAEvent"
 PLUGIN : identifier "application/x-vnd.kde.alarm@default"
 PLUGIN : identifier "application/x-vnd.kde.contactgroup@KContacts::ContactGroup"
 PLUGIN : identifier "application/x-vnd.akonadi.note@KCalCore::Incidence*"
 PLUGIN : identifier "application/x-vnd.kde.notes@default"
 PLUGIN : identifier "application/x-vnd.kde.notes@KCalCore::Incidence*"
 PLUGIN : identifier "message/news@legacy"
 PLUGIN : identifier "application/x-vnd.kde.contactgroup@default"
 PLUGIN : identifier "text/x-vnd.akonadi.note@KMime::Message*"
org.kde.akonadi.ETM: Subtree:  256 QSet(256)
org.kde.akonadi.ETM: Subtree:  103 QSet(103)
org.kde.akonadi.ETM: Subtree:  258 QSet(258)
org.kde.akonadi.ETM: Subtree:  102 QSet(102)
org.kde.akonadi.ETM: Subtree:  9 QSet(9)
org.kde.akonadi.ETM: Fetch job took  1071 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 5
org.kde.akonadi.ETM: first fetched collection: "Notizen"
org.kde.akonadi.ETM: Fetch job took  435 msec
org.kde.akonadi.ETM: was item fetch job: items: 1050
log_messagelist: Circular reference loop detected in the message tree
log_messagelist: Circular reference loop detected in the message tree
log_messagelist: Circular reference loop detected in the message tree
log_messagelist: Circular reference loop detected in the message tree
log_messagelist: Circular reference loop detected in the message tree
org.kde.akonadi.ETM: Subtree:  298 QSet(298)
org.kde.akonadi.ETM: Subtree:  1 QSet(1, 307, 306)
org.kde.akonadi.ETM: Subtree:  7 QSet(7)
org.kde.akonadi.ETM: Subtree:  279 QSet(321, 315, 320, 317, 316, 319, 318, 279)
org.kde.akonadi.ETM: Fetch job took  1181 msec
org.kde.akonadi.ETM: was collection fetch job: collections: 13
org.kde.akonadi.ETM: first fetched collection: "Search"
"kontact-1186278907-SearchSession"
connectToServer "/tmp/akonadi-jmbarkei.8CV1R5/akonadiserver.socket"
org.kde.akonadi.ETM: Fetch job took  429 msec
org.kde.akonadi.ETM: was item fetch job: items: 618
Connected to "Akonadi" , using protocol version 52
Server says: "Not Really IMAP server"
org.kde.akonadi.ETM: Fetch job took  485 msec
org.kde.akonadi.ETM: was item fetch job: items: 582
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.kde.org/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.kde.org/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://planetkde.org/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.wissenschaft.de/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.spiegel.de/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.spiegel.de/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://planet.opensuse.org/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.heise.de/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.spiegel.de/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://tagesspiegel.feedsportal.com/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.faz.net/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://pim.planetkde.org/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.heise.de/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.kde.org/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.heise.de/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.heise.de/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://tagesspiegel.feedsportal.com/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://news.opensuse.org/")  failed
log_akregator: Couldn't reach favicon service. Request favicon for  QUrl("http://www.linux.com/")  failed

OKay. That’s it for now …