SyncEvolution 1.2.99.2 released#
Next step towards SyncEvolution 1.3. It adds a workaround for Funambol’s OneMedia and fixes an old bug which became more severe in 1.2.99.1. Also has some usability improvements for CalDAV/CardDAV. Hopefully it will not take long to stabilize the code, so test it now while it is still hot :-)
Details:
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.
WebDAV: fixed data corruption issue when uploading item with long UID In some cases data with a very long UID wasn’t handled correctly, causing the out-going data to be malformed and probably causing a rejection by the server. The root cause is incorrect string handling. In releases before 1.2.99.1, only the –import operation of contacts into CardDAV were affected. In 1.2.99.1, the same code also got used for calendar items and then could also affect syncing.
engine: add DTSTAMP+LAST-MODIFIED before writing calendar items When writing calendar items into a backend storage as iCalendar 2.0 or vCalendar 1.0, they should have DTSTAMP and LAST-MODIFIED values. DTSTAMP is expected by some CalDAV servers (like Apple). LAST-MODIFIED is usually added by the storage, but not always. In the text/plain -> syncevolution -> text/calendar -> Radicale -> EDS -> syncevolution chain the LAST-MODIFIED was not added by Radicale, which caused problems for change tracking in an EDS-based SyncEvolution. Also necessary when importing from a phone using vCalendar without DTSTAMP directly into CalDAV.
Google Calendar: updated URL redirect handling Google Calendar sometimes returns redirect requests to human-readable web sites (an “unavailable” page, a login form). This is of course bogus when the client is an automated CalDAV client. The “unavailable.html” case was already handled. Made it a bit more flexible to also catch possible variations of it (additional parameters, https instead of http). Added the https://accounts.google.com/ServiceLogin case. Not sure whether retrying will help in that case, but there’s not much else that SyncEvolution can do.
CalDAV + VJOURNAL: handle UID conflicts When asked to insert a VJOURNAL which already existed (= same UID), CalDAV servers respond with a 412 “Precondition failed” error. This needs to be detected and translated into an “item needs to be merged” result so that the engine can load the existing item, merge the data, and then write back.
WebDAV: –status for WebDAV source aborted The command line –status operation did not complete when applied to a CalDAV/CardDAV source. Instead it aborted because the operation took a code path where the backend was not fully initialized.
CalDAV/CardDAV sync: improved target side output Added a “target side of local sync ready” INFO message to introduce the output which has the target context in the [INFO] tag. The sync report from the target side now has the target context embedded in brackets after the “Changes applied during synchronization” header, to avoid ambiguities. Sometimes the backend has to resend requests because of temporary issues. If the problem turned out to be permanent, there was a long period of time, retryDuration=5 minutes to be precice, in which no visible progress happened. Now SyncEvolution’s WebDAV backend will print a message like this before going to sleep until it is time to retry: [INFO @googlecalendar] operation temporarily (?) failed, going to retry in 5.0s before giving up in 18.4s: PROPFIND: Neon error code 1: 401 Unauthorized The uncertainty comes from several factors. In this example, the 401 might indicate a permanent problem (wrong credentials), or it could be Google reporting a temporary authorization problem which is (probably) meant to slow down the client while it asks the user to re-enter the password. SyncEvolution only asks for passwords once, so it tries again with the same password if it was successful with it in the past. Otherwise it gives up immediately. Another dubious example are name server lookup errors. They can be permanent (wrong host name) or temporary (name server down). SyncEvolution errs on the side of retrying, to avoid interrupting an operation which still has a chance to continue. Output from the target side of a local sync was passed through stderr redirection as chunks of text to the frontends. This had several drawbacks: - forwarding only happened when the local sync parent was processing the output redirection, which (due to limitations of the implementation) only happens when it needs to print something itself - debug messages were not forwarded - message boundaries might have been lost In particular the new INFO messages are relevant while the sync runs and need to be shown immediately.
command line: fixed password + property lookup during –print-databases –print-databases for an existing configuration did not look up passwords stored in a keyring, causing the operation to fail for backends like CalDAV/CardDAV where credentials are required. Overriding source properties in that case also only worked when using the unqualified property name (“databasePassword=foo”) but not when using the source name as prefix (“calendar/databasePassword=foo”). * Developers: Implementing the improved local sync output required extending the D-Bus API. The Server.LogOutput signal now has an additional “process name” parameter. Normally it is empty. For messages originating from the target side, it carries that extra target context string. This D-Bus API change is backward compatible. Older clients can still subscribe to and decode the LogOutput messages, they’ll simply ignore the extra parameter. Newer clients expecting that extra parameter won’t work with an older D-Bus daemon: they’ll fail to decode the D-Bus message.
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 snapshots are in http://downloads.syncevolution.org/syncevolution/sources i386, lpia and amd64 binaries for Debian-based distributions are available via the “unstable” syncevolution.org repository. Add the following entry to your /apt/source.list, then install “syncevolution-evolution”:
deb http://downloads.syncevolution.org/apt unstable main These binaries include the “sync-ui” GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy). 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](http://downloads.syncevolution.org/syncevolution/evolution). In contrast to 0.8.x archives, the new .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.