Version: unspecified OS: Linux It is _very_ annoying to see various dialogs (bouncing progress bar, failed self-test) showing up from Akonadi due to starting e.g. KMail. If the user is not demanded, no dialog should appear whatsoever. In case of an error, a more elegant solution should be found to tell the user (e.g. using KNotify). Currently, users are overwhelmed with technical details if e.g. some database error occurs. This adds bad reputation to Akonadi [1, 2], which is quiet unfortunate given its technical brilliance. [1] http://kubuntuforums.net/forums/index.php?topic=3115868.0 [2] http://eyemeansit.wordpress.com/2011/03/03/migrating-from-kmail-to-evolution-or-thunderbird/ Reproducible: Didn't try
I second this. Akonadi is a service destined to do its work solely in background, so please keep it there. If there is something worth logging, do it, but w/o user interaction. A configuration option in aconadicontrol/config file should do. For OpenSuSE 11.4 KDE 4.6 there is another issue. kMail crashes when closing Akonadi's Self-Test popup reproduce: - kill all akonadi processes - start kMail - kMail Window appears as well as a popup with a progress bar "Starting Akonadi Server" - another window "Akonadi Server Self-Test" appears, where one could save a report and/or close the window - when closing this window (via its 'close' button) KMail terminates too
I agree. Akonadi fails to find a running nepomuk service on my computer (because I don't want it). Even if it's not a major problem, it still generates an error log and akonadi's auto-test window is annoying. Moreover, even if akonadi is running, kmail still closes when I click on the close button of akonadi's auto-test window. _VERY_ annoying. Useless service should not be mandatory services on a computer. But if they fail like that, they should entirely be removed !
Fix backported to 4.4 branch.
Thanks for the fix. Can you point us to the commit so that the distribution include the fix until a newer KDEPIM version comes out?
This looks like it, http://commits.kde.org/kdepim/cfa404b7188e4c26bddbc9579728f6d25f8cd214
Yep, that's the right commit. We've got it going into kubuntu natty already tomorrow and will test it there. I'll see if winterz will do some notification about it to the packagers list I guess.
I can poke kde-packagers
This backport seems to have completely broken kdepim, at least when launched outside of KDE and akonadi is started on demand. Rex has released kdepim 4.4.10-3 with this fix for Fedora and now kontact is completely unusable: 1. akonadi is reported to start but it goes so fast that I get suspicious it is really launched. 2. after that nepomucservicestub crashes 3. Kontact hangs at 0% when checking for mail 4. File -> exit doesn't exit kontact so it cannot be launched again 5. when I kill kontact and restart it, *then* IMAP works. So obviously it only works if akonadi is already running from the first attempt.
Which version of KDE is it? I saw the nepomucservicestub crash on kubuntu too. It's caused by deleting an uninitialized pointer which is fixed in 4.6.2. For the launch related stuff, what kinds of accounts do you use? Some groupware stuff? Plain imap? Do other users see the same issue?
(In reply to comment #9) > Which version of KDE is it? I saw the nepomucservicestub crash on kubuntu too. > It's caused by deleting an uninitialized pointer which is fixed in 4.6.2. Fedora 14 is still on KE 4.6.1. > For the launch related stuff, what kinds of accounts do you use? Some groupware > stuff? Plain imap? Yes, I have configured a Kolab server as single account.
BTW: the nepumic(In reply to comment #9) > Which version of KDE is it? I saw the nepomucservicestub crash on kubuntu too. Bug 270427 contains mine. Is this the one you are talking about?
The nepomuk fix is c1e733f5f715fe058c48fcc94bb5f67f4ae9cfc6 in the kde-runtime repo. If Fedora is on KDE 4.6.1 then you should put the patch in the package. For the crash with the kolab stuff, the fix is kdepim 4.6. In kdepim 4.4 there are synchronous calls to Akonadi to start it and get data. That is a broken concept. The synchronous Control::start is in kdepim44/runtime/resources/kresources/shared. The workaround for 4.4 would be to not start the server synch, and modify the resources to return an empty set of data if the server is not started yet. I will be afk for next week, but if you want to work on it you might get help on kde-pim@.
(In reply to comment #12) > The nepomuk fix is c1e733f5f715fe058c48fcc94bb5f67f4ae9cfc6 in the kde-runtime > repo. If Fedora is on KDE 4.6.1 then you should put the patch in the package. The patch is in the package. I filed a bug against our kdepim-4.4.10-2 package because akonadi no longer started after the KDE 4.6.1 update and I had to delete ~/.config/akonadi and ~/.local/share/akonadi. Rex issued a 4.4.10-3 with your patch and this version does not work at all. > For the crash with the kolab stuff, the fix is kdepim 4.6. In kdepim 4.4 there > are synchronous calls to Akonadi to start it and get data. That is a broken > concept. Nevertheless it worked quite well in our kdepim 4.4.10-1 package which was compiled against KDE 4.5.x and akonadi 1.4. Yes, there was the annoying startup dialog, but other than that it worked very reliable.
@Christoph I have just tried to reproduce this on one of my kubuntu natty systems (KDE 4.6.2 with kdepim 4.4.10). My kolab account worked just fine. Can you tell me if there is anything particular about your configuration?
What do you consider "particular"? I don't think there is anything special with my setup and we have reports about problems also from non-Kolab users. While you are running 4.6.2 I am still having 4.6.1. The only thing I consider special is that I'm not running KDE but Xfce and akonadi gets started on demand when I start kontact.
Git commit 0b44b1aa3d66f974e3d255c6e027947f1375b685 by Stephen Kelly. Committed on 25/04/2011 at 22:09. Pushed by skelly into branch '4.4'. Only start akonadi asynchronously on KDE 4.6.2. Revises cfa404b7188e4c26bddbc9579728f6d25f8cd214 to hopefully fix the bug seen on fedora. Please re-test this on 4.6.2 on fedora too. Unfortunately that's the best I can do because I can't reproduce the issue. BUG: 268120 M +1 -1 kaddressbook/main.cpp M +1 -1 kmail/kmmainwidget.cpp M +1 -1 kmail/main.cpp M +1 -1 kontact/src/main.cpp http://commits.kde.org/kdepim/0b44b1aa3d66f974e3d255c6e027947f1375b685
(In reply to comment #14) > @Christoph I have just tried to reproduce this on one of my kubuntu natty > systems (KDE 4.6.2 with kdepim 4.4.10). My kolab account worked just fine. Can > you tell me if there is anything particular about your configuration? Did you test with a Kolab address book, both shared and private? It's definitely the address book that is causing the problems. It was configured by adding a 'KDE Address Book (traditional)' and then adding 'IMAP Address book via KMail'. (In reply to comment #16) > Git commit 0b44b1aa3d66f974e3d255c6e027947f1375b685 by Stephen Kelly. > Please re-test this on 4.6.2 on fedora too. Rex, can you build a package with this patch?
sure, f14: http://koji.fedoraproject.org/koji/taskinfo?taskID=3026518 f15: http://koji.fedoraproject.org/koji/taskinfo?taskID=3026516 (these will land in kde-testing repos soonish)
(In reply to comment #16) > Please re-test this on 4.6.2 on fedora too. Unfortunately it doesn't. Just like the previous fix to start akonadi asynchronously it renders kontact completely useless. The Kolab address book works but I can receive mail from IMAP. > Unfortunately that's the > best I can do because I can't reproduce the issue. Did you test the update outside of KDE?
My workaround now is a wrapper that first runs "akonadicontrol start" before launching kontact.
Ping? Starting on demand is more broken than before with these changes. Has anybody actually tested this outside of KDE where it is actually started *on demand*?
I have only tested it in a KDE environment. I don't see how it is possible for this patch to be causing you issues. The changes are only defined in when KDE >= 4.6.2 but you said you have 4.6.1. Are your packages compiled against 4.6.2? Are you able to build your own package, and try reverting the patches to see where the issue is?
Yes, meanwhile Fedora updated to KDE 4.6.2. With KDE 4.6.0 and kdepim 4.4.10 I had the annoying dialog, but at least Kontact found the running akonadi instance. With 4.6.1 or 4.6.2 and kdepim 4.1.11 Kontact starts without the dialog, but is not functional. This problem first appeared when Rex applied the backported change from comment #5 in our kdepim-4.4.10-3 package. I will look into building a package with a reverted patch, but I don't think I will find the time this week.