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.

However, KDE support is work in progress. Help by someone in the KDE developer community is needed to finish this feature and support if and when normal users start to use it.

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.

Once installed, run the following command

$ syncevolution --print-databases
...
KDE Address Book = KDE Contacts = kde-contacts:
Database "akonadi" opened using driver "QMYSQL"
   akonadi_vcard_resource_0 (akonadi:?collection=8) <default>

KDE Calendar = kde-calendar:
   akonadi_ical_resource_0 (akonadi:?collection=9) <default>

KDE Task List = KDE Tasks = kde-tasks:
   akonadi_ical_resource_0 (akonadi:?collection=9) <default>

KDE Memos = kde-memos:

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:

$ syncevolution --configure \
                keyring=KDE \
                addressbook/backend=kde-contacts \
                addressbook/database=akonadi:?collection=8 \
                calendar/backend=kde-calendar \
                calendar/database=akonadi:?collection=9 \
                todo/backend=kde-tasks \
                todo/database=akonadi:?collection=9 \
                @default addressbook calendar todo

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:

$ syncevolution --print-items @default addressbook
81
$ syncevolution --export - @default addressbook
BEGIN:VCARD
ADR;TYPE=home:Test Box #1;;Test Drive 1;Test Village;Lower Test County;1234
5;Testovia
ADR:Test Box #3;;Test Drive 3;Test Megacity;Test County;12347;New Testonia
ADR;TYPE=work:Test Box #2;;Test Drive 2;Test Town;Upper Test County;12346;O
ld Testovia
BDAY:2006-01-08
CATEGORIES:TEST
EMAIL:john.doe@other.world
FN:John Doe
N:Doe;John;;;
NICKNAME:user1
NOTE:This is a test case which uses almost all Evolution fields.
ORG:Test Inc.;Testing
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.0//EN
ROLE:professional test case
TEL;TYPE=HOME;TYPE=VOICE:home 2
TEL;TYPE=FAX;TYPE=HOME:homefax 5
TEL;TYPE=CELL:mobile 3
TEL;TYPE=CAR;TYPE=VOICE:car 7
TEL;TYPE=PREF:primary 8
TEL;TYPE=VOICE;TYPE=WORK:business 1
TEL;TYPE=FAX;TYPE=WORK:businessfax 4
TEL;TYPE=PAGER:pager 6
TEL;TYPE=VOICE:primary 8
TITLE:Senior Tester
UID:TDt77SeFdO
URL:http://john.doe.com
VERSION:3.0
X-KADDRESSBOOK-ANNIVERSARY:20060109
X-KA...
Doe Senior
X-KADDRESSBOOK-SPOUSE:Joan Doe
END:VCARD

$ syncevolution --print-items @default calendar
...
$ syncevolution --print-items @default todo
...

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.

KDE Address Book = KDE Contacts = kde-contacts:
[ERROR] stderr: syncevolution(10193)/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"
[ERROR] Couldn't Start Akonadi Server: hence the akonadi backend of syncevolution wont work ..
... and then --print-databases aborts. Fixed in versions >= 1.2.99+20120312, which continue to iterate over other backends.

Database "akonadi" opened using driver "QMYSQL"
is some debug output from the Akonadi libs which shouldn't go to stdout. Only happens when using --daemon=no.

Comments

I have been using syncevolution-kde happily for some time for syncing my local KDE calendar with my account on the Oracle Calendar system used by my workplace. I echo the sentiments of many above when I say how grateful I am for this facility.

In August 2013, I upgraded to KDE SC 4.11 and unfortunately I have not been able to sync since. The first syncevolution error log after the upgrade contained many instances of:

syncevolution(3928)/akonadiserializer (calendar) Akonadi::SerializerPluginKCalCore::deserialize: Failed to parse incidence!

On subsequent attempts the errors have been more like the following:

error code from SyncEvolution fatal error (local, status 10500): calendar: extracting item 20339
StartDataRead last='' resume='' res=10500
DBapi::StartDataRead fatal error: 10500

The system notification is

Work Calendar: Incidence with uid '' not found.

I wonder if this might be because SyncEvolution is using libical0 while Akonadi has moved on to using libical1?

Mixing two different libical versions in the same process is very likely to cause problems. Whether they cause these kind of issues would have to be seen.

What system is this? It would be good to know the library dependencies of libecal and the KDE libs.

Do you think you can compile from source on your system, with only the libical1 development files installed?

Be careful with the libecal backend - better disable it and the ebook backend (--disable-ecal --disable-ebook), because if libecal is linked against libical0, then it will still be brought into the process even if SyncEvolution uses something else.

I'm running Kubuntu 13.04, with additional packages from Kubuntu Backports and the SyncEvolution unstable repository. I don't have libecal installed currently but I see it depends on libc6, libedataserver-1.2-17, libglib2.0-0 and libical0.

libical1 is depended upon by libkcal4 and libkcalcore4, which in turn are depended upon by kdepimlibs5, calligra, korganizer, akonadi-kde-resource-googledata, etc. etc. If you would like more details, please let me know.

Compiling from source is not something I've done much of, but I'm willing to give it a go...

Can you uninstall libical0?

I was about to suggest removing syncecal.so and syncebook.so as a way to avoid loading libical0, but after looking at the source I see that other components will also trigger loading. They do that although they don't need libical0, because it was easier to implement that way. This could be enhanced to be more selective.

I can try and prepare an experimental package where libical really is only loaded if syncecal.so is installed. Could you give that a try?

I tried compiling from source but setting up the dev environment did nasty things to my desktop, for some reason. And when I tried running the newly-compiled binary it failed, but then neither libical showed up in the log, so I don't know that that tells you anything. Therefore I would be most grateful if I could try your experimental package. I don't need libical0 for anything else so yes, there's no problem uninstalling it.

If you don't need the libical0 package, then simply uninstall it. SyncEvolution will continue to run.

Uninstalling has the same effect as the experimental package that I had in mind, so there's no need for that anymore. If it still fails after removing libical0, we need to look for another explanation of the failure.

When I said there's no problem uninstalling it, that was in terms of non-SyncEvolution packages. :-) In the SyncEvolution unstable repository, the syncevolution-kde package depends on syncevolution-bundle which depends on libical0, so (possibly faulty self-compiled packages aside) I can't currently run SyncEvolution without libical0. If you could provide a package without a hard dependency on libical0 for me to test that would be ideal.

Sorry to be a pain.

Try removing libical0 despite the dependency. You might be able to do that with something like "dpkg purge --ignore-depends=syncevolution-bundle libical0".

I need to check why libical0 is listed as hard dependency.

I've successfully synchronized mobile phone via funambol with syncevolution and akonaid, but unfortunately my calender entries do not show up in KOrganizer. The problem is that the entries lack the UID field. Manually adding random UID fields in the file makes the entries show up.

The syncevolution changelog of version 1.3 states that UIDs from funambol are explicitly ignored, so I'm wondering what to here.

Any help greatly appreciated.

I found /usr/share/syncevolution/xml/remoterules/client/03funambol.xml which appears to configure the UID stripping. I removed the file, but new events still arrive without UID. The phone most probably sends them to funambol with a UID, at least I see a UID when inspecting a single event, sent via bluetooth.

In the funambol database (especially table fnbl_calendar) I don't see any UID though (there's not even a colum for it).

Any help still appreciated.

Gordon, as you noticed, Funambol has problems with UIDs. The stripping was added because it was misbehaving in a way which broke clients once more complex meeting series with detached exceptions were involved:

commit 8b8696346660b82da961357e61c2b4d1af51d617 Author: Patrick Ohly Date: Fri Jun 29 16:56:13 2012 +0200

Funambol: ignore UID

Funambol's OneMedia sends UID, but not RECURRENCE-ID. That becomes a
problem when multiple events of the same event series are added to a
backend which follows the iCalendar 2.0 standard (CalDAV, EDS, KDE),
because these events all look like the master event, and there can be
only one of those.

SyncEvolution now strips the UID from all events coming from any
Funambol server (regardless of the version). If a future Funambol
server release adds support for both UID and RECURRENCE-ID, then
SyncEvolution will have to be updated to take advantage of the
improved server. Because the RECURRENCE-ID is also getting
stripped (despite not being set at the moment), SyncEvolution should
continue to work as it does now even if the server changes.

It would have been nice to limit this workaround to affected Funambol
server versions, but an inquiry on the Funambol mailing list didn't
get a reply, therefore SyncEvolution is playing it safe and assumes
that all future Funambol releases will have the same problem.

Storing the data received from Funambol (without UID because the server never sent one) is a different problem. With EDS, the EDS storage itself enforces the requirement that every event must have a UID. With Akonadi, that seems to be something that apps (and thus SyncEvolution) must do themselves.

You might be able to set the UID before writing into Akonadi by modifying CALENDAR_BEFOREWRITE_SCRIPT in scripting/11calendar.xml. There is a newuid() function already, so it might work to add

if (!UID) { UID = newuid(); }

Hi Patrick,

thanks for your explanation. I had seen the newuid() script already, but didn't dare to try it out yet. I will try this tomorrow and hope that it won't cause conflicts during synchronization. AFAIU, it would go that way then: - syncevo receives UID-less calender entry and adds a UID - syncevo sends back the entry so that Funambol has it, too (I hope that the entries are recognized as being the same, here) - next syncs are easy, both have the UID

It would be helpful if there was a loglevel that logged the incoming data, in this case, allowing to check whether the UID gets sent by Funambol or not. I suspect that Funambol does not send any UID at all, but it would be nice to confirm that.

Thanks again Gordon

Use loglevel=4 and you'll get a detailed record of incoming data and its processing, including step-by-step script processing, in the syncevolution-log.html.

The proposed approach will update the item before writing it, without considering the change as something that the server needs to be told about. I'm not sure whether that would be useful in this case anyway, given the lack of UID support in the server.

Receiving an update might need a little bit more care. I think the Synthesis engine will already have loaded the existing local item and merged the server's fields into it by the time that it invokes the "before write script". Whether the local UID field then still exists remains to be seen.

Thank you, it finally works. I'm using newuid() just as you proposed. It took me a while to realize that it actually works, because for some strange reason, my "Personal Calender" in KOrganizer -- actually the only configured calendar -- was disabled, so all my freshly synchronized events didn't show up, without any error message.

So, to sum up, I removed the funambol "remove UID" script and adjusted the 11calendar.xml script to add the new UID.

Can you file a bug in https://bugs.freedesktop.org/enter_bug.cgi?product=SyncEvolution and attach your modified 11calendar.xml there? That will server as reminder to include this in a release.

Regarding removing the "remove UID": why is that necessary? Can you actually send a UID to the server and get it back?

If so, do event exceptions with modified properties work? Try this:

  • create a recurring event
  • change the description of one instance
  • sync to Funambol
  • replace your local data with a refresh-from-remote

The problem in the past was that the Funambol server would send two different VEVENTs with the same UID and no RECURRENCE-ID in the exception; this is invalid and cannot be stored as-is locally.

I haven't checked yet, if removing that uid-removing script was necessary. It's just that I tried that first, because it was the most obvious thing for me, given the information I had.

Your scenario appears to work just fine. When replacing my local data in Kontact, the recurring event is again there and has the changed description. There is no duplicate either. This is with funambol 10.0.0.2.

Pages