The source of SyncEvolution should be compatible with any Evolution release since 2.0. The packages prepared for regular releases >= 0.9 are compiled on a Ubuntu Hardy 8.04 LTS system (32 and 64 bit x86), and tested with different versions of Evolution. The binaries should run on all distributions that are more recent than Ubuntu Hardy and have a compatible Evolution.
|Evolution Release||GNOME||Linux Distributions||Library Dependencies|
|2.6.1||2.14||Ubuntu 6.06 (Dapper)||libedataserver1.2-7, libecal1.2-3, libebook1.2-5|
|2.6.3 (Debian 4.0)||2.14||Debian 4.0 (Etch)||libedataserver1.2-7, libecal1.2-6, libebook1.2-5|
|2.8.x||2.16||Ubuntu 6.10 (Edgy)||libedataserver1.2-7, libecal1.2-7, libebook1.2-9|
|2.10.x||2.18||Ubuntu 7.04 (Feisty)||libedataserver1.2-9, libecal1.2-7, libebook1.2-9|
|2.12.x||2.20||Ubuntu 7.10 (Gutsy)|
|2.22.x||2.22||Ubuntu 8.04 (Hardy)|
|2.24.x||2.24||Ubuntu 8.10 (Intrepid)||libedataserver1.2-11, libecal1.2-7, libebook1.2-9|
|> 2.24||should work as long as EDS remains backwards-compatible; SyncEvolution binaries no longer link directly against specific EDS libraries|
KDE is supported indirectly via the SyncEvolution file backend, which synchronizes items stored as single files inside a directory. That format is supported by KDE PIM. An old blog post contains some information and links about this. The SyncEvolution source code contains a "akonadi" branch with a database backend that talks directly to Akonadi, the PIM storage in KDE 4.x, but it needs a maintainer and more work to be usable. Perhaps a Google Summer of Code 2010 project will enhance it and SyncEvolution's integration into KDE.
When importing or updating a contact from the server, some telephone numbers might only be displayed in the contact summary after editing the contact once. Evolution 2.0.4 till 2.6.3, ContactSync::testMerge test. Starting with SyncEvolution 0.4, this is solved by modifying the contact in the same way as the internal editor does. If it still fails, the server might send phone numbers without setting their type correctly.
End date of recurring events
Older versions of Evolution (like 2.0.4) use an Evolution-specific extension of iCalendar 2.0 to mark the end data of a recurring event. SyncEvolution makes no attempts to translate that into something that servers like eGroupware understand . This will not be added because this problem can be avoided by updating Evolution. Since at least version 2.6.3, Evolution uses the normal end date parameter.
Removing a recurrence not synchronized
The file backend of Evolution Data Server <= 2.27.5 does not increase the LAST-MODIFIED property of a recurring event when removing specific recurrences, therefore SyncEvolution does not recognize the event as modified and thus does not update the server. A fix for this is expected to be included in Evolution 2.28.
Adding timezone to Evolution
Evolution has a problem when SyncEvolution receives a calendar event with a new timezone definition. SyncEvolution adds the definition to the Evolution database, but an already running Evolution crashes, when trying to open the new event. Restarting Evolution solves that problem. The problem was found in Evolution 2.0.4, but has been resolved since.
Creating new address book
In Evolution, an address book has to be viewed once in Evolution after creating it (observed in 2.0.4). Otherwise, accessing it in SyncEvolution fails with:
[ERROR] addressbook: opening address book: EBookStatus returned 19
In an installation of Evolution, the libraries used by SyncEvolution crash unless the gconfd was started earlier, for instance, by logging into GNOME or running the Evolution GUI (observed with 18.104.22.168)