Search form

KDE + Akonadi

Overview

This page describes how KDE users can use SyncEvolution to synchronize their PIM data without depending on Evolution or Evolution Data Server (EDS). The design of SyncEvolution explicitly allows to read/write data from different storages via backends, and one such backend uses the the Akonadi API.

The core SyncEvolution code also runs well in KDE. However, usage of KWallet instead of GNOME keyring has to be enabled explicitly when SyncEvolution's modules for both are are installed, because SyncEvolution cannot determine automatically whether the user runs KDE or GNOME. The only remaining dependency on GNOME is libsoup-gnome, which works in KDE but depends on GNOME settings to detect the system's proxy settings. If this is a problem, then proxy settings can also be changed in the SyncEvolution configuration itself.

Installation

Install any of the 1.2.99.x pre-releases of SyncEvolution 1.3 from the downloads directories (.tar.gz, .rpm) or from the unstable apt repositories (replace "stable" with "unstable"). Install the syncevolution-kde packages. This will pull in the core syncevolution-bundle, which contains all the real files.

Alternatively one can compile from source (master branches of SyncEvolution and libsynthesis) with --enable-kwallet and --enable-akonadi. To avoid the dependency on EDS, use --disable-ecal and --disable-ebook.

Configuration

Automatically detecting that the user wants to use Akonadi instead of EDS and which databases to use by default in Akonadi is not implemented. Therefore a KDE user has to tell SyncEvolution about that as a first. Once that part is configured, all further steps are the same as for Evolution users. See the HOWTOs to get an idea of what can be done with SyncEvolution.

Memos don't seem to have any database unless created manually somehow in KDE. There's some code in the SyncEvolution Akonadi backend for memos, but is uncertain how complete the support is.

Pick the Akonadi URI of each database that you want to synchronize and configure the @default context so that those databases are used. At the same time ensure that KWallet is used for passwords from now on:

Now any configuration for a SyncML peer (server or phone) or setup of CalDAV/CardDAV/ActiveSync syncing in the @default context will use these settings. As the name implies, the @default context is used implicitly unless specified otherwise. In particular, the GTK based sync-ui uses it, so until the Qt UI is ready, the GUI included in the SyncEvolution binaries can be used as fallback.

Troubleshooting

Once the @default context is configured, it should be possible to access all of the data in the four data default databases:

Note that SyncEvolution does not try to start Akonadi daemons if they are not running yet. A D-Bus session with those daemons already running is required. See akonadictl. Previous releases tried to start Akonadi, but that occasionally had problems and wouldn't be right if the user doesn't want to use Akonadi, for example in --print-databases.

To debug problems between SyncEvolution and Akonadi daemons, run SyncEvolution like this:

$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no ...

dbus-monitor may also show something interesting.

Know Issues

[ERROR] stderr: syncevolution(9962)/libakonadi Akonadi::AgentManagerPrivate::createDBusInterface: AgentManager failed to get a valid AgentManager DBus interface. Error is: 1 "org.freedesktop.DBus.Error.NameHasNoOwner" "Could not get owner of name 'org.freedesktop.Akonadi.Control': no such name"

is printed when Akonadi is not yet running. It seems to get started okay despite that error message - sometimes.

peter@dv-460mt:~$ sudo aptitude install syncevolution-evolution
[sudo] password for peter:
The following NEW packages will be installed:
syncevolution-evolution{b}
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.7 MB of archives. After unpacking 43.2 MB will be used.
The following packages have unmet dependencies:
syncevolution-evolution: Conflicts: libsmltk0 but 3.4.0.16.1-1 is installed.
Conflicts: libsynthesis0 but 3.4.0.16.1-1 is installed.
The following actions will resolve these dependencies:

libsmltk0 and libsynthesis0 are libraries used by SyncEvolution. In Ubuntu and Debian, they are packaged separarately, whereas syncevolution-evolution .deb contains them.

The right way to resolve this is to uninstall libsmltk0, libsynthesis0 and syncevolution, then install syncevolution-evolution. In my experience, that happens automatically as part of "aptitude install syncevolution-evolution".

The following NEW packages will be installed: libsmltk0{a} libsyncevolution0{a} libsynthesis0{a} syncevolution syncevolution-common{a} syncevolution-libs{a} 0 packages upgraded, 6 newly installed, 0 to remove and 293 not upgraded.Need to get 2.017 kB of archives. After unpacking 6.132 kB will be used.The following packages have unmet dependencies: syncevolution-evolution: Conflicts: libsmltk0 but 3.4.0.16.6-1 is to be installed. Conflicts: libsyncevolution0 but 1.2.2-1 is to be installed. Conflicts: libsynthesis0 but 3.4.0.16.6-1 is to be installed. Conflicts: syncevolution but 1.2.2-1 is to be installed.The following actions will resolve these dependencies:

Remove the following packages:1) syncevolution-evolution

Accept this solution? [Y/n/q/?] ...The following packages have unmet dependencies: syncevolution-evolution: Conflicts: libsmltk0 but 3.4.0.16.6-1 is installed. Conflicts: libsyncevolution0 but 1.2.2-1 is installed. Conflicts: libsynthesis0 but 3.4.0.16.6-1 is installed. Conflicts: syncevolution but 1.2.2-1 is installed.The following actions will resolve these dependencies:

What I don't understand is proposal to uninstall all of those packages on your system. They shouldn't depend on any of these libs. Are you sure that your system is up-to-date? If not, then perhaps aptitude is trying to do some package changes entirely unrelated to installing syncevolution-evolution.

When I uninstalled syncevolution, the packages libsmltk0, libsynthesis0 were left, so I unistalled them as advised manually then installation went smoothly as follows:

peter@dv-460mt:~$ sudo aptitude install syncevolution-evolution
The following NEW packages will be installed:
syncevolution-evolution
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.7 MB of archives. After unpacking 43.2 MB will be used.
WARNING: untrusted versions of the following packages will be installed!

Untrusted packages could compromise your system's security.
You should only proceed with the installation if you are certain that
this is what you want to do.

Sounds like "syncevolution-evolution" needs to conflict with all of the split packages. I'll add that as part of reorganizing the package names.

My plan is to introduce a "syncevolution-bundle" package which contains everything shipped by syncevolution.org, then have "syncevolution-evolution" and "syncevolution-kde" with no content and just a dependency on "syncevolution-bundle". That makes it possible for current users to upgrade to the next version seamlessly. It also leaves the possibility open to have real, separate builds of SyncEvolution for the different desktops.

Oops, I just noticed that I only uploaded to "experimental", instead of "unstable" as described in the Wiki page.

"experimental" is what I use myself before pushing to repos also used by normal users. The pre-release seems to be stable enough, so I have promoted it to "unstable". Please do an "aptitude update && aptitude upgrade".

How useful do you find the KCrash handler? SyncEvolution "accidentally" inherited that feature when adding KWallet support. You should be able to submit the bug report via email, just mail it to syncevolution@syncevolution.org, as suggested by the dialogs.

it's not the complete backtrace. while the backtrace is generated, #1 to #5 can be seen within a very short period of time. But it immediately disappears, the backtrace finishes and comes up with #6 to #8 only as already shown above.

How useful is it? I don't know because I'm not deep into that stuff, sorry :-)
But it rates the backtrace info to be worthless and I can't find debug symbols for the package.

I am not familiar with KCrash either. It seems it automagically removed the initial part of the backtrace because it was inside KCrash's own error handler and thus unrelated to the crash. That's neat, albeit a bit surprising for someone who doesn't know how KCrash works.

The real problem is in the line #5 quoted earlier. That's a bit puzzling, because the code around line #6 should have done the necessary NULL pointer check.

The report would have been useful. That KCrash cannot find debug packages is okay, debug information is part of the main package itself. I don't know KCrash well enough, so I don't know how it arrived at the conclusion that the report was not useful. IMHO any kind of backtrace is useful - well, at least much better than what I used to get earlier, when users had to know how to run the executable under gdb :-)

Just wanted to tell you that I was able to sync my Nokia 2700 contacts and calendar now with Akonadi using your description and finding the appropriate databases with --print-databases backend=XXX. Afterwards I was syncing using the GTK-GUI.
Thank you very much for that, great job!

I've installed the 1.2.99.x pre-release of syncevolution in ubuntu via apt and in opensuse. Synchronization with akonadi works fine, but the password is stored in the gnome keyring, even the KDE_FULL_SESSION variable is set. Is the kwallet support disabled in the binaries?

I have removed my previous installation and config files then installed only syncevolution-bundle and syncevolution-kde and then successfully followed the instructions above to apparently successfully configure.

I then run sync and get an invitation to select a sync service. I select my nokia 2630 then attempt to sync. A syncing message comes up on the phone but it gets stuck at this point!!!!

Should I have syncevolution-libs installed or anything else? I've tried but dependensies won't let me.

I compiled syncevolution 1.2.2 with --enable-akonadi, configured as described above and successfully synced with my egroupware server (By the way, I got akonadi database list by syncevolution without any parameters).
But now I can get task from server, but can't send to server a new task or changes in task.

SyncEvolution 1.2.2 already had very similar KDE support, so when compiling from source it is possible to use the older release. Printing databases was done differently, as you noticed. But it would be better to test with the latest sources when using KDE, because only that will detect regressions before they enter 1.3. It's also where problems will be fixed.

Please try with the latest source. I suspect that it'll have similar issues, but I'd like to be sure before investigating further. Please also include information about your version of Akonadi and KDE. The KDE PIM team reports that a lot of problems were fixed in KDE 4.8, so it might be worth trying that, too.

The server is a free Funambol server running on the local network. It syncs like a charm, with Evolution trough SyncEvolution (installed from the distribution packages) running another Ubuntu 12.04 system. The server also syncs with an Android device using FunV10. So the server is not the problem.

The "Internal Server Error" is a HTTP error code, sent by the HTTP server. I don't know why it works with one client and not with another. Could it be that one client uses IPv4 and the other IPv6?

The Wiki page about KDE is not a good place to ask such unrelated questions. It's also easy to overlook. Would you mind posting on the mailing list? You can use gmane if you prefer a web interface. See https://syncevolution.org/support

Both tests on Ubuntu 12.04 were made on a common system, a fork of the same clean installed virtual machine. The Evolution+SyncEvolution branch works. The KDE+SyncEvolution branch fails. Since both are supposed to interact with the server through SyncEvolution and the same code of libsoup-gnome, is it absolutely unrealistic to suspect the client side (integration with libsoub or keyring of the kde-compliant version, for instance) ? In each case, the http server is the same. The "http error 500" also means the client asked the server to access a denied ressource...

About integration of SyncEvolution with KDE, the GTK sync-ui doesn't use the KDE Wallet. So i wonder how can SyncEvolution get the confidential passwords from the KDE Wallet if GTK sync-ui is "used as fallback" ? For my tests, I edited the peer configuration file and replaced "-" by the textual password (but stil had the problem). I also tried to set the password through the SyncEvolution CLI but got an error message :

Gkr: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files
[ERROR] error code from SyncEvolution fatal error (local, status 10500): Try to save password in gnome-keyring but get an error. Error communicating with gnome-keyring-daemon

Is the packaged version integrated with KDE Wallet ? Did someone succeed using the packaged version with Ubuntu 12.04 ?

In your initial report you said that it worked "on another Ubuntu 12.04 system". To me that difference seemed like a more likely explanation than the difference in binaries. Of course something on the client side is different and thus causing the problem, but as the server does reply (at least that's what I can tell so far from the error messages quoted), it would be useful to look at server logs to determine how the clients behave differently.

Alternatively, you could capture Ethernet logs with Wireshark or, perhaps easier, run SyncEvolution in debug mode.

Can you compare the working against the failing version on the same OS installation when using the following command?

If that doesn't show anything network related, then Wireshark would be the next step.

Regarding KWallet vs. GNOME keyring: the GTK UI does not use either of these directly. Passwords are stored and retrieved there by the syncevo-dbus-server transparently or (with --keyring) by syncevolution.

The failure with "org.freedesktop.secrets was not provided by any .service files" implies that GNOME keyring wasn't running in the D-Bus session. Did you try to use GNOME keyring or KWallet? In other words, what kind of user session was the command run in?

If you were trying to use KWallet, was KDE_FULL_SESSION set in your environment?

I ran "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --sync two-way" and got exactly the same error messages I quoted in my first message.

I installed Wireshark. Thought I'm not used to it, I think I could capture the transactions related to the sync. Searching through the data grabbed, I'm surprised there is no evidence of the account password exchange. I looked for it in clear text and MD5 encoding and could not find it. It may suggest an authentication issue ? I easily found data expected to be transfered such at the account login

The GTK UI is not stable. I have eratic problems using it. Now, i can't save my configuration due to keyring access :

** (sync-ui:3083): WARNING **: Error in Session.SetConfig: Try to save password in gnome-keyring but get an error. Error communicating with gnome-keyring-daemon

though i succeeded using it some time ago... The password was saved in the gnome keyring, I suppose, for there was no Kwallet instance yet.

I only open KDE sessions since I didn't install the packages needed to open a Gnome session. KDE_FULL_SESSION is set to TRUE in my environment.

I've installed KDE on my system. Previously I only some bits and pieces of it installed (like KWallet and Akonadi), but obviously the limited kind of testing that I had done with that wasn't enough. I was hoping that a KDE developer would help with that, but no luck so far (hint, hint, ...).

Anyway, with a KDE session started normally I can reproduce that KWallet is not used. The reason is that "syncevo-dbus-server" doesn't have KDE_FULL_SESSION set and thus doesn't recognize that it is meant to use KWallet.

The command line without daemon and with keyring support (--daemon=no --keyring) accesses the KWallet, as intended.

That means that a different way of distinguishing between GNOME and KDE users is needed. I'm not sure how to do that.

On my system, both GNOME keyring and KWallet are now installed. So a check "is installed" doesn't tell SyncEvolution what the user wants to use.

"is working" also cannot be used. Trying to use either one or the other auto-starts the daemon, which involves popping up dialogs about keyring unlocking (GNOME) or configuring the wallet (KDE). Depending on what SyncEvolution tries to use first, either GNOME or KDE users will be unhappy.

Any bright ideas for an automatism?

Manually configuring SyncEvolution would work. Something like a global "desktop" option in ~/.config/syncevolution/config.ini with values "KDE", "GNOME", etc. If unset, an automatism would be used which for the time being (lacking a better idea) uses GNOME.

Akonadi sources already have to be configured manually, so it wouldn't be much extra work for KDE users.

Release 1.2.99+20120530+SE+48b6fef+SYSYNC+2d7d1b2 contains the fix for the Funambol incompatibility and introduces a keyring config property. From the NEWS file:

Automatically detecting KDE users is not possible at the
moment. Instead KDE users have to manually set the new "keyring"
global config property to "KDE" (case insensitive) if the
SyncEvolution installation supports both, because GNOME Keyring is the
default to avoid surprises for traditional users. If only KWallet
support is enabled, then this is not necessary.

"GNOME" and "true/false/1/0/yes/no" can also be set. This has the
advantage that keyring usage can be enabled permanently for the
command line in --daemon=no mode; normally keyrings are not used in
that mode because accessing them can bring up UI dialogs.

It also becomes possible to disable keyring usage in syncevo-dbus-server,
something which couldn't be done before.

The --keyring command line option is still supported, as an alias for
"[--sync-property] keyring=value". The default value for --keyring
is true, to match the traditional behavior. In contrast to other sync
properties, setting "keyring" does not require an explicit --run
parameter. Again this is done to mirror traditional usage.

I gave a try to the new binaries on Kubuntu 10.04. Syncs with no problem with my Funambol (10, free) server.

I noticed an unexpected behaviour, syncing the contacts. The first normal sync after the refresh-from-server updates all the contacts on the server. I could not see what was really updated. Just checked it didn't produce duplicates and the major information was still unaltered (didn't check all the fields). All seems to be ok. The same "refresh-back" didn't happen with the appointments. This behaviour may be a consequence of how Akonadi interacts with Kontact ?

I didn't succeed using Kwallet as a default keyring but I guess it is due to my poor knowledge of syncevolution CLI options ;) All I can say is that syncing or using the sync-ui after having set "syncevolution --configure keyring=KDE @default" still uses the gnome-keyring). Reading carefully the documentation and understanding what "traditional behaviour", "default [not] keyring", "syncevo-dbus-server", "only Kwallet support" mean may help me :)

The updating of contacts after a refresh-from-server is indeed unexpected. I don't see that happening here. Sorry, analyzing this exceeds the time that I have for KDE support.

The "syncevolution --configure keyring=KDE @default" command doesn't work because the command line doesn't understand that a single global option is meant to be set. Gah, should have tested it. What did work for me is "syncevolution --configure keyring=KDE username=xxx password=yyy memotoo", in other words, including the keyring option at a point when some other config is getting modified. It can also be included in the line which configures the Akonadi sources. I've tested that and changed the Wiki page accordingly.

The unexpected "refresh-back" may be a 10.04 issue. I tried the last binaries on Kubuntu 12.04 and didn't see it. Even better, some field labels that had disapeared in the regurlar version of Kontact for 10.04 are back ; for instance, "home/voice" and "work/voice" were labelled "other".

I hope some KDE developpers will take over. Akonadi is (was ?) such a key feature of KDE 4 that I was staggered it still didn't provide native syncML support. Now that you've pushed syncevolution so far into the KDE direction, I hope they will contribute to the project and add the final integration.

Hi I have an issue, if somebody can help me:
I want to:
sync contact, calendar and task from Kubuntu 12.04 KDE 4.9 32 bit (with akonadi) to a N900 over bluetooth
Syncevolution to be runned from the Kubuntu PC.
Packages version : SyncEvolution 1.2.99.4 (pre-release)

To do this I have prepared a script that should configure it, but I must be missing something. Maybe I don't get the context and config notion right.

What I don't understand especially is:
1) why it says there is no backend availabel for addressbook
2) why ity says there is no configuration called "my_n900" while the --print-configs just before seems to suggest there is

THE OUTPUT OF THIS SCRIPT IN THE CONSOLEmax@netbook:~$ ./sync_feu.sh
CalDAV:
select database via absolute URL, set username/password to scan, set syncURL to base URL if server does not support auto-discovery ()

CalDAVTodo:
select database via absolute URL, set username/password to scan, set syncURL to base URL if server does not support auto-discovery ()

CalDAVJournal:
select database via absolute URL, set username/password to scan, set syncURL to base URL if server does not support auto-discovery ()

CardDAV:
select database via absolute URL, set username/password to scan, set syncURL to base URL if server does not support auto-discovery ()

Evolution Address Book = Evolution Contacts = evolution-contacts:
not enabled during compilation or not usable in the current environment

Evolution Calendar = evolution-calendar:
not enabled during compilation or not usable in the current environment

Evolution Task List = Evolution Tasks = evolution-tasks:
not enabled during compilation or not usable in the current environment

Evolution Memos = evolution-memos:
not enabled during compilation or not usable in the current environment

This "22001 error" appeared after I moved my system from Ubuntu 10.04 to Debian 7 and installed the last (1:1.3-2) version of syncevolution-bundle, from the unstable branch of the repository. I guess the Warning and the error are related because I already had this kind of messages before, but on the contacts. It was due to an "empty" contact I created in Kontact. Deleting the contact eliminated both the warning and the error message.

But I don't remember myself creating 3 new empty appointments in Korganizer since the last sync... Is it due to a stronger checking by syncevolution ? Is it a bug ? Is it an artifact produced by Korganizer/Akonadi when i upgraded from Ubuntu to Debian ?

I am trying to follow the instructions of the current wiki to sync PI-data between KDE Kontact and a Nokia N9 device. I tried several times without success to sync via Bluetooh. Specifically, after installing syncevolution-kde

syncevolution --version
SyncEvolution 1.3.1
...

syncevolution --print-databases returns all of my "sources" as seen in Kontact: kde-contacts as akonadi:?collection=SomeNumber and the same for kde-calendar, kde-tasks and kde-memos)

syncevolution --configure keyring=KDE ... using the correct database=akonadi:?collection=SomeNumber description for each "source"

syncevolution --print-items @default addressbook returns 397 different numbers (I guess, one for each contact stored in the addressbook).

So far so good. Afterwards, trying to sync (either via CLI or the Sync GUI) a dialog asking for a password appears. Where and how should this password be configured?

I also tried to extract a template by executing syncevo-phone-config --bt-address ##:##:##:##:##:## --advanced --create-config=Nokia_N9

Today, after upgrading to KDE 4.9.3 (my distro is Kubuntu 12.04), syncevolution (package syncevolution-kde, version 1.3.1) stopped working. It hanged at every synchronization for hours without any progress. After several trials I decided to completely remove (purge) syncevolution and reinstall it from the repositories (same version, of course).
This solved the issue. Now it works perfectly again. I sync two NOKIA phones (C6 and 6620) with my notebook (Kubuntu 12.04) and my desktop (Ubuntu 10.04).

Just wanted to let you know.

Please continue your great and indispensable work. Thank you from your users!

first of all I also would like to thank you for your great work here which fills a big gap in KDE PIM.

Recently I set up an ownCloud server on my NAS and connected it to my KDE via Akonadi's DAV groupware resources service. After trying to set up sync I was following the default procedures. Unfortunatley syncevolution --print-databases only comes up with the corresponding calendar and addressbook resources from my DAVgroupware but does not find something for todo (which should also be calendar). Consequently I get the following error message after the configuration instruction: [ERROR] error code from SyncEvolution fatal error (local, status 10500): todo: no database to synchronize

I am using syncevolution 1.3.2 and KDE 4.9.3 (Kubuntu 12.10).

Is this problem even regarding syncevolution or is it a implementation failure inside Akonadi?
Nevertheless, would there be any workaround to also sync todos?