SyncEvolution 1.4.1 released#

The first bug fix release in the 1.4 series addresses some issues which occurred on some systems. Several issues with Akonadi were fixed.


  • EDS: only load one backend plugin of each kind SyncEvolution was meant to load the syncecal or syncebook shared object which uses the most recent libraries (libical, libecal/libebook) on the system and then stop loooking for alternatives. Due to a string handling bug the check for already backends always found nothing, leading to multiple conflicting backends loaded on some systems (for example, those with libical0 and libical1 installed). If that happened, the backend became unusable.

  • ical: workaround for libical 1.0 builtin timezone change libical 1.0 started to return VTIMEZONE definitions with multiple absolute transition times instead of RRULEs. This causes problems when exchanging data with peers (see In SyncEvolution, this affected sending an event using New Zealand time in vCalendar 1.0 format to a phone, because the internal, out-dated definition of the time zone in libsynthesis was used as fallback when loading RRULE-based timezone definitions from libical failed (see “[SyncEvolution] Some events showing wrong time on phone”). It might also affect exchanging data with CalDAV peers (not tested). The workaround is to include the original code from libical.

  • create XDG_RUNTIME_DIR More recent distros (for example, Ubuntu Saucy) rely on XDG_RUNTIME_DIR. Each time runs, it must ensure that the runtime dir exists and is empty. This was a problem when trying to run activesyncd + SyncEvolution on a headless Ubuntu Saucy server (see [FDO #76273](

  • Akonadi: support KDE Notes, enhanced “database” check The KDE Notes resources store items under a different MIME type than the one used in AKonadi (see “[Kde-pim] note format”). SyncEvolution use the same type as Akonadi and thus did not find existing KDE Notes resources. To support both while KDE and Akonadi transition to the same type, SyncEvolution now looks for notes resources using both MIME types and accepts both kinds of items when reading. When writing, SyncEvolution picks the MIME type that is supported by the resource, which hopefully avoids confusing the KDE app using the resource (untested). As a positive side effect, the “database” value used for opening a resource is now checked more thoroughly. Non-existent resources and the type mismatches like pointing a “kde-contacts” backend to a calendar resource are now detected early.

  • Akonadi: ensure that UID is set ([FDO #74342]( Akonadi resources do not enforce iCalendar 2.0 semantic like “each VEVENT must have a UID” (see “[Kde-pim] iCalendar semantic”). When receiving an event from a peer which itself does not enforce that semantic (Funambol, vCalendar 1.0 based phones), then we need to generate a UID, otherwise KOrganizer will ignore the imported event.

  • Akonadi: avoid threading problem in HTTP server mode ([FDO #75672]( When used as storage in a server, Akonadi got called in a background thread that gets created to handle slow initialization of sources and preventing ensuing timeouts in HTTP clients (probably not needed for Akonadi itself, but may still be useful when combining it with other sources). Akonadi cannot be used like that, leading to false “Akonadi not running” errors or (if one got past that check) failing item operations.

  • autotools: Add QtCore include path to KDEPIM_CFLAGS ([FDO #75670]( This fixes an issue where configure fails to find Akonadi when test programs do not compile because QString is not found.

  • Enhanced testing again: faster execution, less false negatives under load. Re-enabled testing of Akonadi.

Upgrading from releases <=

If the value of “username/databaseUser/proxyUser” contains a colon, the “user:” prefix must be added to the value, to continue treating it like a plain user name and not some reference to an unknown identity provider (like “id:”, “goa:”, “signon:”, etc.). The lookup of passwords in GNOME Keyring was updated slightly in It may be necessary to set passwords anew if the old one is no longer found.

Upgrading from release 1.2.x:#

The sync format of existing configurations for Mobical (aka Everdroid) must be updated manually, because the server has encoding problems when using vCard 3.0 (now the default for Evolution contacts): syncevolution –configure \ syncFormat=text/x-vcard \ mobical addressbook The Funambol template explicitly enables usage of the “refresh-from-server” sync mode to avoid getting throttled with 417 ‘retry later’ errors. The same must be added to existing configs manually: syncevolution –configure \ enableRefreshSync=TRUE \ funambol

Upgrading from releases before 1.2:#

Old configurations can still be read. But writing, as it happens during a sync, must migrate the configuration first. Releases >= 1.2 automatically migrates configurations. The old configurations will still be available (see “syncevolution –print-configs”) but must be renamed manually to use them again under their original names with older SyncEvolution releases.

Source, Installation, Further information#

Source code bundles for users are available in and the original source is in [the git repositories]( i386, lpia and amd64 binaries for Debian-based distributions are available via the “stable” repository. Add the following entry to your /apt/source.list:

  deb stable main Then install “syncevolution-evolution”, “syncevolution-kde” and/or “syncevolution-activesync”. These binaries include the “sync-ui” GTK GUI and were compiled for Ubuntu 10.04 LTS (Lucid), except for ActiveSync binaries which were compiled for Debian Wheezy, Ubuntu Saucy and Ubuntu Trusty. The packages mentioned above are meta-packages which pull in suitable packages matching the distro during installation. Older distributions like Debian 4.0 (Etch) can no longer be supported with precompiled binaries because of missing libraries, but the source still compiles when not enabling the GUI (the default). The same binaries are also available as .tar.gz and .rpm archives in [the download directories]( In contrast to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise. After installation, follow the [getting started](/documentation/getting-started) steps. More specific [HOWTOs](/wiki/howto) can be found in the Wiki.