Posted in 2014
SyncEvolution 1.5 released
- 04 November 2014
About 1.5 ========= This version is the new stable, supported version of SyncEvolution. Compared to the last 1.4.99.4 pre-release only minor changes were done (see below). This section summarizes the changes since the last stable release, 1.4.1. Based on community feedback and discussions, the terminology used in SyncEvolution for configuration, local sync and database access was revised. Some usability issues with setting up access to databases were addressed. Interoperability with WebDAV servers and in particular Google Contacts was enhanced considerably. Access to iCloud contacts was reported as working when using username=foobar@icloud.com and password, but is not formally tested. Syncing with iCloud calendars ran into a server limitation (reported as 17001498 “CalDAV REPORT drops calendar data”) and needs further work ([FDO #72133](https://bugs.freedesktop.org/show_bug.cgi?id=72133)). Contact data gets converted to and from the format typically used by CardDAV servers, so now anniversary, spouse, manager, assistant and instant message information are exchanged properly. Custom labels get stored in EDS as extensions and no longer get lost when updating some other aspects of a contact. However, Evolution does not show custom labels and removes them when editing a property which has a custom label ([BGO #730636](https://bugzilla.gnome.org/show_bug.cgi?id=730636)). Scanning for CardDAV/CalDAV resources was enhanced. It now finds additional calendars with Google CalDAV. For Google, the obsolete SyncML config template was removed and CalDAV/CardDAV were merged into a single “Google” template. Using Google Calendar/Contacts with OAuth2 authentication on a headless server becomes a bit easier: it is possible to set up access on one system with a GUI using either gSSO or GNOME Online Accounts, then take the OAuth2 refresh token and use it in SyncEvolution on a different system. See [the oauth2 backend README](http://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/src/backends/oauth2/README) for details. syncevolution.org binaries do not include this feature. The PIM Manager API also supports Google Contact syncing. Some problems with suspending a PBAP sync were fixed. Suspend/abort can be tested with the sync.py example. Performance is better for local syncs and PBAP caching. The most common case, a two-way sync with no changes on either side, no longer rewrites any meta data files. CPU consumption during local sync was reduced to one third by exchanging messages via shared memory instead of internal D-Bus. Redundant vCard decode/encode on the sending side of PBAP and too agressive flushing of meta data during a normal sync were removed. The EDS memo backend is able to switch between syncing in plain text and iCalendar 2.0 VJOURNAL automatically. Graham Cobb fixed some all-day conversion issues in activesyncd. The updated version is part of the 1.5 release on syncevolution.org. Details: * source -> datastore rename, improved terminology The word “source” implies reading, while in fact access is read/write. “datastore” avoids that misconception. Writing it in one word emphasizes that it is single entity. While renaming, also remove references to explicit –*-property parameters. The only necessary use today is “–sync-property ?” and “–datastore-property ?”. –datastore-property was used instead of the short –store-property because “store” might be mistaken for the verb. It doesn’t matter that it is longer because it doesn’t get typed often. –source-property must remain valid for backward compatility. As many user-visible instances of “source” as possible got replaced in text strings by the newer term “datastore”. Debug messages were left unchanged unless some regex happened to match it. The source code will continue to use the old variable and class names based on “source”. Various documentation enhancements: Better explain what local sync is and how it involves two sync configs. “originating config” gets introduces instead of just “sync config”. Better explain the relationship between contexts, sync configs, and source configs (“a sync config can use the datastore configs in the same context”). An entire section on config properties in the terminology section. “item” added (Todd Wilson correctly pointed out that it was missing). Less focus on conflict resolution, as suggested by Graham Cobb. Fix examples that became invalid when fixing the password storage/lookup mechanism for GNOME keyring in 1.4. The “command line conventions”, “Synchronization beyond SyncML” and “CalDAV and CardDAV” sections were updated. It’s possible that the other sections also contain slightly incorrect usage of the terminology or are simply out-dated. * local sync: allow config name in syncURL=local:// Previously, only syncURL=local://@
SyncEvolution 1.4.99.4 released
- 15 September 2014
This is the first release candidate for 1.5. No further changes are planned except for fixing yet-to-be-discovered bugs - so find them now! :-) One focus in this release was on minimizing CPU consumption and disk writes. The most common case, a two-way sync with no changes on either side, no longer rewrites any meta data files. CPU consumption during local sync was reduced to one third by exchanging messages via shared memory instead of internal D-Bus. Redundant vCard decode/encode on the sending side of PBAP and too agressive flushing of meta data during a normal sync were removed. Altogether, sending 1000 contacts with photo data in a refresh-from-server local sync takes only one sixth of the CPU cycles compared to 1.3.99.3 (measured with valgrind’s callgrind on x86_64). Based on community feedback and discussions, the terminology used in SyncEvolution for configuration, local sync and database access was revised. Some usability issues with setting up access to databases were addressed. For Google, the obsolete SyncML config template was removed and CalDAV/CardDAV were merged into a single “Google” template. Using Google Calendar/Contacts with OAuth2 authentication on a headless server becomes a bit easier: it is possible to set up access on one system with a GUI using either gSSO or GNOME Online Accounts, then take the OAuth2 refresh token and use it in SyncEvolution on a different system. See the [new OAuth2 backend README](http://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/src/backends/oauth2/README). Some issues accessing Apple iCloud were fixed such that CardDAV works by just giving SyncEvolution username=foobar@icloud.com and password. No throrough testing was done, so iCloud support is still experimental. The PIM Manager API also supports Google Contact syncing. Some problems with suspending a PBAP sync were fixed. Suspend/abort can be tested with the sync.py example. The EDS memo backend is able to switch between syncing in plain text and iCalendar 2.0 VJOURNAL automatically. Details: ——— * oauth2: new backend using libsoup/libcurl New backend implements identity provider for obtaining OAuth2 access token for systems without HMI support. Access token is obtained by making direct HTTP request to OAuth2 server and using refresh token obtained by user in some other way. New provider automatically updates stored refresh token when OAuth2 server is issuing new one. * PBAP: use raw text items This avoids the redundant parse/generate step on the sending side of the PBAP sync. * datatypes: raw text items with minimal conversion ([FDO #52791](https://bugs.freedesktop.org/show_bug.cgi?id=52791)) When using “raw/text/calendar” or “raw/text/vcard” as SyncEvolution “databaseFormat”, all parsing and conversion is skipped. The backend’s data is identical to the item data in the engine. Finding duplicates in a slow sync is very limited when using these types because the entire item data must match exactly. This is useful for the file backend when the goal is to store an exact copy of what a peer has or for limited, read-only backends (PBAP). The downside of using the raw types is that the peer is not given accurate information about which vCard or iCalendar properties are supported, which may cause some peers to not send all data. * engine: flush map items less frequently The Synthesis API does not say explicitly, but in practice all map items get updated in a tight loop. Rewriting the m_mappingNode (case insensitive string comparisons) and serialization to disk (std::ostrstream) consume a significant amount of CPU cycles and cause extra disk writes that can be avoided by making some assumptions about the sequence of API calls and flushing only once. * SoupTransport: drop CA file check It used to be necessary to specify a CA file for libsoup to enable SSL certificate checking. Nowadays libsoup uses the default CA store unless told otherwise, so the check in SyncEvolution became obsolete. However, now there is a certain risk that no SSL checking is done although the user asked for it (when libsoup is not recent enough or compiled correctly). * local sync: exchange SyncML messages via shared memory Encoding/decoding of the uint8_t array in D-Bus took a surprisingly large amount of CPU cycles relative to the rest of the SyncML message processing. Now the actual data resides in memory-mapped temporary files and the D-Bus messages only contain offset and size inside these files. Both sides use memory mapping to read and write directly. For caching 1000 contacts with photos on a fast laptop, total sync time roughly drops from 6s to 3s. To eliminate memory copies, memory handling in libsynthesis or rather, libsmltk is tweaked such that it allocates the buffer used for SyncML message data in the shared memory buffer directly. This relies on knowledge of libsmltk internals, but those shouldn’t change and if they do, SyncEvolution will notice (“unexpected send buffer”). * local sync: avoid updating meta data when nothing changed The sync meta data (sync anchors, client change log) get updated after a sync even if nothing changed and the existing meta data could be used again. This can be skipped for local sync, because then SyncEvolution can ensure that both sides skip updating the meta data. With a remote SyncML server that is not possible and thus SyncEvolution has to update its data. This optimization is only used for local syncs with one source. It is based on the observation that when the server side calls SaveAdminData, the client has sent its last message and the sync is complete. At that point, SyncEvolution can check whether anything has changed and if not, skip saving the server’s admin data and stop the sync without sending the real reply to the client. Instead the client gets an empty message with “quitsync” as content type. Then it takes shortcuts to close down without finalizing the sync engine, because that would trigger writing of meta data changes. The server continues its shutdown normally. This optimization is limited to syncs with a single source, because the assumption about when aborting is possible is harder to verify when multiple sources are involved. * PIM: include CardDAV in CreatePeer() This adds “protocol: CardDAV” as a valid value, with corresponding changes to the interpretation of some existing properties and some new ones. The API itself is not changed. Suspending a CardDAV sync is possible. This freezes the internal SyncML message exchange, so data exchange with the CardDAV server may continue for a while after SuspendPeer(). Photo data is always downloaded immediately. The “pbap-sync” flag in SyncPeerWithFlags() has no effect. Syncing can be configured to be one-way (local side is read-only cache) or two-way (local side is read/write). Meta data must be written either way, to speed up caching or allow two-way syncing. The most common case (no changes on either side) will have to be optimized such that existing meta data is not touched and thus no disk writes occur. * PIM: handle SuspendPeer() before and after transfer ([FDO #82863](https://bugs.freedesktop.org/show_bug.cgi?id=82863)) A SuspendPeer() only succeeded while the underlying Bluetooth transfer was active. Outside of that, Bluez errors caused SyncEvolution to attempt a cancelation of the transfer and stopped the sync. When the transfer was still queueing, obexd returns org.bluez.obex.Error.NotInProgress. This is difficult to handle for SyncEvolution: it cannot prevent the transfer from starting and has to let it become active before it can suspend the transfer. Canceling would lead to difficult to handle error cases (like partially parsed data) and therefore is not done. The Bluez team was asked to implement suspending of queued transfers (see “org.bluez.obex.Transfer1 Suspend/Resume in queued state” on linux-bluetooth@vger.kernel.org), so this case might not happen anymore with future Bluez. When the transfer completes before obexd processes the Suspend(), org.freedesktop.DBus.Error.UnknownObject gets returned by obexd. SyncEvolution can ignore errors which occur after the active transfer completed. In addition, it should prevent starting the next one. This may be relevant for transfer in chunks, although the sync engine will also stop asking for data and thus typically no new transfer gets triggered anyway. * PIM: add suspend/resume/abort to sync.py CTRL-C while waiting for the end of a sync causes an interactive prompt to appear where one can choose been suspend/resume/abort and continuing to wait. CTRL-C again in the prompt aborts the script. * PIM: fix sync.py –sync-flags The help text used single quotes for the JSON example instead of the required double quotes. Running without –sync-flags was broken because of trying to parse the empty string as JSON. * command line: revise usability checking of datastores When configuring a new sync config, the command line checks whether a datastore is usable before enabling it. If no datastores were listed explicitly, only the usable ones get enabled. If unusable datastores were explicitly listed, the entire configure operation fails. This check was based on listing databases, which turned out to be too unspecific for the WebDAV backend: when “database” was set to some URL which is good enough to list databases, but not a database URL itself, the sources where configured with that bad URL. Now a new SyncSource::isUsable() operation is used, which by default just falls back to calling the existing Operations::m_isEmpty. In practice, all sources either check their config in open() or the m_isEmpty operation, so the source is usable if no error is enountered. For WebDAV, the usability check is skipped because it would require contacting a remote server, which is both confusing (why does a local configure operation need the server?) and could fail even for valid configs (server temporarily down). The check was incomplete anyway because listing databases gave a fixed help text response when no credentials were given. For usability checking that should have resulted in “not usable” and didn’t. The output during the check was confusing: it always said “listing databases” without giving a reason why that was done. The intention was to give some feedback while a potentially expensive operation ran. Now the isUsable() method itself prints “checking usability” if (and only if!) such a check is really done. Sometimes datastores were checked even when they were about to be configure as “disabled” already. Now checking such datastores is skipped. * EDS: memo syncing as iCalendar 2.0 ([FDO #52714](https://bugs.freedesktop.org/show_bug.cgi?id=52714)) When syncing memos with a peer which also supports iCalendar 2.0 as data format, the engine will now pick iCalendar 2.0 instead of converting to/from plain text. The advantage is that some additional properties like start date and categories can also be synchronized. The code is a lot simpler, too, because the EDS specific iCalendar 2.0 <-> text conversion code can be removed. * datatypes: text/calendar+plain revised heuristic When sending a VEVENT, DESCRIPTION was set to the SUMMARY if empty. This may have been necessary for some peers, but for notes (= VJOURNAL) we don’t know that (hasn’t been used in the past) and don’t want to alter the item unnecessarily, so skip that part and allow empty DESCRIPTION. When receiving a plain text note, the “text/calendar+plain” type used to store the first line as summary and the rest as description. This may be correct in some cases and wrong in others. The EDS backend implemented a different heuristic: there the first line is copied into the summary and stays in the description. This makes a bit more sense (the description alone is always enough to understand the note). Therefore and to avoid behavioral changes for EDS users when switching the EDS backend to use text/calendar+plain, the engine now uses the same approach. * source -> datastore rename, improved terminology The word “source” implies reading, while in fact access is read/write. “datastore” avoids that misconception. Writing it in one word emphasizes that it is single entity. While renaming, also remove references to explicit –*-property parameters. The only necessary use today is “–sync-property ?” and “–datastore-property ?”. –datastore-property was used instead of the short –store-property because “store” might be mistaken for the verb. It doesn’t matter that it is longer because it doesn’t get typed often. –source-property must remain valid for backward compatility. As many user-visible instances of “source” as possible got replaced in text strings by the newer term “datastore”. Debug messages were left unchanged unless some regex happened to match it. The source code will continue to use the old variable and class names based on “source”. Various documentation enhancements: Better explain what local sync is and how it involves two sync configs. “originating config” gets introduces instead of just “sync config”. Better explain the relationship between contexts, sync configs, and source configs (“a sync config can use the datastore configs in the same context”). An entire section on config properties in the terminology section. “item” added (Todd Wilson correctly pointed out that it was missing). Less focus on conflict resolution, as suggested by Graham Cobb. Fix examples that became invalid when fixing the password storage/lookup mechanism for GNOME keyring in 1.4. The “command line conventions”, “Synchronization beyond SyncML” and “CalDAV and CardDAV” sections were updated. It’s possible that the other sections also contain slightly incorrect usage of the terminology or are simply out-dated. * local sync: allow config name in syncURL=local:// Previously, only syncURL=local://@
deb http://downloads.syncevolution.org/apt unstable 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. A backend for Ubuntu Online Accounts was compiled on Ubuntu Saucy. 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](http://downloads.syncevolution.org/syncevolution/). 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.
SyncEvolution 1.4.99.3 released
- 24 July 2014
This release enhances CalDAV/CardDAV and PBAP syncing and fixes some problems. The enhanced conflict handling introduced 1.4.99.2 was unintentionally limited to syncs with EDS on the server side; it is now also available for example in WebDAV<->SyncML bridge setups. Details: * CardDAV: implement read-ahead Instead of downloading contacts one-by-one with GET, SyncEvolution now looks at contacts that are most likely going to be needed soon and gets all of them at once with addressbook-multiget REPORT. The number of contacts per REPORT is 50 by default, configurable by setting the SYNCEVOLUTION_CARDDAV_BATCH_SIZE env variable. This has two advantages: - It avoids round-trips to the server and thus speeds up a large download (100 small contacts with individual GETs took 28s on a fast connection, 3s with two REPORTs). - It reduces the overall number of requests. Google CardDAV is known to start issuing intermittent 401 authentication errors when the number of contacts retrieved via GET is too large. Perhaps this can be avoided with addressbook-multiget. * Google Calendar: remove child hack, improve alarm hack ([FDO #63881](https://bugs.freedesktop.org/show_bug.cgi?id=63881)) Google recently enhanced support for RECURRENCE-ID, so SyncEvolution no longer needs to replace the property when uploading a single detached event with RECURRENCE-ID. However, several things are still broken in the server, with no workaround in SyncEvolution: - Removing individual events gets ignored by the server; a full “wipe out server data” might work (untested). - When updating the parent event, all child events also get updated even though they were included unchanged in the data sent by SyncEvolution. - The RECURRENCE-ID of a child event of an all-day recurring event does not get stored properly. - The update hack seems to fail for complex meetings: uploading them once and then deleting them seems to make uploading them again impossible. All of these issues were reported to Google and are worked on there, so perhaps the situation will improve. In the meantime, syncing with Google CalDAV should better be limited to: - Downloading a Google calendar in one-way mode. - Two-way syncing of simple calendars without complex meeting serieses. While updating the Google workarounds, the alarm hack (sending a new event without alarms twice to avoid the automatic server side alarm) was simplified. Now the new event gets sent only once with a pseudo-alarm. * ephemeral sync: don’t write binfile client files ([FDO #55921](https://bugs.freedesktop.org/show_bug.cgi?id=55921)) When doing PBAP caching, we don’t want any meta data written because the next sync would not use it anyway. With the latest libsynthesis we can configure “/dev/null” as datadir for the client’s binfiles and libsynthesis will avoid writing them. The PIM manager uses this for PBAP syncing automatically. For testing it can be enabled by setting the SYNCEVOLUTION_EPHEMERAL env variable. * PBAP: avoid empty field filter Empty field filter is supposed to mean “return all supported fields”. This used to work and stopped working with Android phones after an update to 4.3 (seen on Galaxy S3); now the phone only returns the mandatory TEL, FN, N fields. The workaround is to replace the empty filter list with the list of known and supported properties. This means we only pull data we really need, but it also means we won’t get to see any additional properties that the phone might support. * PBAP: transfer in chunks ([FDO #77272](https://bugs.freedesktop.org/show_bug.cgi?id=77272)) If enabled via env variables, PullAll transfers will be limited to a certain numbers contacts at different offsets until all data got pulled. See PBAP README for details. When transfering in chunks, the enumeration of contacts for the engine no longer matches the PBAP enumeration. Debug output uses “offset #x” for PBAP and “ID y” for the engine. * PBAP: remove transfer via pipe Using a pipe was never fully supported by obexd (blocks obexd). Transfering in suitably sized chunks ([FDO #77272](https://bugs.freedesktop.org/show_bug.cgi?id=77272)) will be a more obexd friendly solution with a similar effect (not having to buffer the entire address book in memory). * engine: enable batching by default ([FDO #52669](https://bugs.freedesktop.org/show_bug.cgi?id=52669)) This reverts commit c435e937cd406e904c437eec51a32a6ec6163102. Commit 7b636720a in libsynthesis fixes an unitialized memory read in the asynchronous item update code path. Testing confirms that we can now used batched writes reliably with EDS (the only backend currently supporting asynchronous writes + batching), so this change enables it again also for local and SyncEvolution<->SyncEvolution sync (with asynchronous execution of contact add/update overlapped with SyncML message exchanges) and other SyncML syncs (with changes combined into batches and executed at the end of each message). * datatypes: fix contact caching Adding grouping to the contact datatype in 1.4.99.2 broke PBAP caching: when sending an empty URL, for example, during the sync, the parsed contact had different field arrays than the locally stored contact, because the latter was saved without the empty URL. This caused the field-based comparison to detect a difference even when the final, reencoded contact wasn’t different at all. To solve this, syncing now uses the same “don’t send empty properties” configuration as local storages. Testing shows that this resolves the difference for EDS. A more resilient solution would be to add a check based on the encoded data, but that’s more costly performance wise. * datatypes: fix vCard handling The new “preserve repeating properties during conflict resolution” feature from 1.4.99.2 was only active when using EDS as storage. The relevant merge script must be applied to all datatypes, not just the EDS flavor. The feature was also unintentionally active when running in caching mode. This caused two problems: - The cached item was updated even though only the ordering of repeating properties had been modified during merging. - The merged item was sent back to the client side, which was undesirable (caching is supposed to be one-way) or even impossible (PBAP is read-only, causing sync failures eith error 20030). We must check for caching mode and disable merging when it is active. We also must not tell the engine that we updated the photo property in the winning item, because then that item would get sent to the read-only side of the sync. Perhaps a better solution would be to actually tell the engine that the remote side is read-only when we activate caching mode. * datatypes: avoid PHOTO corruption during merge ([FDO #77065](https://bugs.freedesktop.org/show_bug.cgi?id=77065)) When handling an update/update conflict (both sides of the sync have an updated contact) and photo data was moved into a local file by EDS, the engine merged the file path and the photo data together and thus corrupted the photo. The engine does not know about the special role of the photo property. This needs to be handled by the merge script, and that script did not cover this particular situation. Now the loosing side is cleared, causing the engine to then copy the winning side over into the loosing one. Found by Renato Filho/Canonical when testing SyncEvolution for Ubuntu 14.04. * PBAP syncing: updated photo not always stored Because photo data was treated like a C string, changes after any embedded null byte were ignored during a comparison. * PIM: fix phone number normalization The parsed number always has a country code, whereas SyncEvolution expected it to be zero for strings without an explicit country code. This caused a caller ID lookup of numbers like “089788899” in DE to find only telephone numbers in the current default country, instead of being more permissive and also finding “+189788899”. The corresponding unit test was broken and checked for the wrong result. Found while investigating an unrelated test failure when updating libphonenumber. * Various compiler problems and warnings fixed; compiles with –with-warnings=fatal on current Debian Testing and Ubuntu Trusty ([FDO #79316](https://bugs.freedesktop.org/show_bug.cgi?id=79316)). Upgrading from releases <= 1.3.99.4: ———————————— 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 1.3.99.5. 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 http://downloads.syncevolution.org/syncevolution/sources and the original source is in [the git repositories](http://cgit.freedesktop.org/SyncEvolution/). 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:
deb http://downloads.syncevolution.org/apt unstable 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. A backend for Ubuntu Online Accounts was compiled on Ubuntu Saucy. 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](http://downloads.syncevolution.org/syncevolution/). 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.
Tizen Dev Conf: PIM in IVI - Contacts, your phone, your car
- 18 June 2014
Here’s a copy of the slides that I presented at the Tizen Developer Conference 2014 in San Francisco. Compared to the previous talk at the Automotive Linux Summit in Edinburgh, you’ll find Tizen-specific instructions for getting started and information about the new OAuth2 (or, as a fallback, password based) Google Contact sync. *[Update]*: a copy of the slides and an audio recording of the talk are now also on the [conference web site](https://www.tizen.org/events/tizen-developer-conference/2014/conference-schedule) (search for “PIM in IVI - Contacts, your phone, your car”).
SyncEvolution 1.4.99.2 released
- 26 May 2014
1.4.99.2 is a new development snapshot. It enhances interoperability with CardDAV servers and in particular Google Contacts considerably. Contact data gets converted to and from the format typically used by CardDAV servers, so now anniversary, spouse, manager, assistant and instant message information are exchanged properly. Categories are not supported by Google CardDAV and thus still get lost. Custom labels get stored in EDS as extensions and no longer get lost when updating some other aspects of a contact. However, Evolution does not show custom labels and removes them when editing a property which has a custom label (BGO #730636). Scanning for CardDAV/CalDAV resources was enhanced. It now finds additional calendars with Google CalDAV and works with iCloud. However, syncing with iCloud ran into a server bug (reported as 17001498 “CalDAV REPORT drops calendar data”) and needs further work. The Ubuntu Online Accounts backend was added to syncevolution.org binaries, targeting Ubuntu Saucy and later. Details: * vcard profile: avoid data loss during merging When resolving a merge conflict, repeating properties were taken wholesale from the winning side (for example, all email addresses). If a new email address had been added on the loosing side, it got lost. Arguably it is better to preserve as much data as possible during a conflict. SyncEvolution now does that in a merge script by checking which properties in the loosing side do not exist in the winning side and copying those entries. Typically only the main value (email address, phone number) is checked and not the additional meta data (like the type). Otherwise minor differences (for example, both sides have same email address, but with different types) would lead to duplicates. Only addresses are treated differently: for them all attributes (street, country, city, etc.) are compared, because there is no single main value. * engine: UID support in contact data Before, the UID property in a vCard was ignored by the engine. Backends were responsible for ensuring that the property is set if required by the underlying storage. This turned out to be handled incompletely in the WebDAV backend. This change moves this into the engine: - UID is now field. It does not get used for matching because the engine cannot rely on it being stored by both sides. - It gets parsed if present, but only generated if explicitly enabled (because that is the traditional behavior). - It is never shown in the DevInf’s CtCap because the Synthesis engine would always show it regardless whether a rule enabled the property. That’s because rules normally only get triggered after exchanging DevInf and thus DevInf has to be rule-independent. We don’t want it shown because then merging the incoming item during a local sync would use the incoming UID, even if it is empty. - Before writing, ensure that UID is set. When updating an existing item, the Synthesis engine reads the existing item, preserves the existing UID unless the peer claims to support UID, and then updates with the existing UID. This works for local sync (where SyncEvolution never claims to support UID when talking to the other side). It will break with peers which have UID in their CtCap although they rewrite the UID and backends whose underlying storage cannot handle UID changes during an update (for example, CardDAV). * CardDAV: use Apple/Google/CardDAV vCard flavor In principle, CardDAV servers support arbitrary vCard 3.0 data. Extensions can be different and need to be preserved. However, when multiple different clients or the server’s Web UI interpret the vCards, they need to agree on the semantic of these vCard extensions. In practice, CardDAV was pushed by Apple and Apple clients are probably the most common clients of CardDAV services. When the Google Contacts Web UI creates or edits a contact, Google CardDAV will send that data using the vCard flavor used by Apple. Therefore it makes sense to exchange contacts with *all* CardDAV servers using that format. This format could be made configurable in SyncEvolution on a case-by-case basis; at the moment, it is hard-coded. During syncing, SyncEvolution takes care to translate between the vCard flavor used internally (based on Evolution) and the CardDAV vCard flavor. This mapping includes: X-AIM/JABBER/… <-> IMPP + X-SERVICE-TYPE Any IMPP property declared as X-SERVICE-TYPE=AIM will get mapped to X-AIM. Same for others. Some IMPP service types have no known X- property extension; they are stored in EDS as IMPP. X- property extensions without a known X-SERVICE-TYPE (for example, GaduGadu and Groupwise) are stored with X-SERVICE-TYPE values chosen by SyncEvolution so that Google CardDAV preserves them (GroupWise with mixed case got translated by Google into Groupwise, so the latter is used). Google always sends an X-ABLabel:Other for IMPP. This is ignored because the service type overrides it. The value itself also gets transformed during the mapping. IMPP uses an URI as value, with a chat protocol (like “aim” or “xmpp”) and some protocol specific identifier. For each X- extension the protocol is determined by the property name and the value is the protocol specific identifier without URL encoding. X-SPOUSE/MANAGER/ASSISTANT <-> X-ABRELATEDNAMES + X-ABLabel The mapping is based on the X-ABLabel property attached to the X-ABRELATEDNAMES property. This depends on the English words “Spouse”, “Manager”, “Assistant” that Google CardDAV and Apple devices seem to use regardless of the configured language. As with IMPP, only the subset of related names which have a corresponding X- property extension get mapped. The rest is stored in EDS using the X-ABRELATEDNAMES property. X-ANNIVERSARY <-> X-ABDATE Same here, with X-ABLabel:Anniversary as the special case which gets mapped. X-ABLabel parameter <-> property CardDAV vCards have labels attached to arbitrary other properties (TEL, ADR, X-ABDATE, X-ABRELATEDNAMES, …) via vCard group tags: item1.X-ABDATE:2010-01-01 item1.X-ABLabel:Anniversary The advantage is that property values can contain arbitrary characters, including line breaks and double quotation marks, which is not possible in property parameters. Neither EDS nor KDE (judging from the lack of responses on the KDE-PIM mailing list) support custom labels. SyncEvolution could have used grouping as it is done in CardDAV, but grouping is not used much (not at all?) by the UIs working with the vCards in EDS and KDE. It seemed easier to use a new X-ABLabel parameter. Characters which cannot be stored in a parameter get converted (double space to single space, line break to space, etc.) during syncing. In practice, these characters don’t appear in X-ABLabel properties anyway because neither Apple nor Google UIs allow entering them for custom labels. The “Other” label is used by Google even in case where it adds no information. For example, all XMPP properties have an associated X-ABLabel=Other although the Web UI does not provide a means to edit or show such a label. Editing the text before the value in the UI changes the X-SERVICE-TYPE parameter value, not the X-ABLabel as for other fields. Therefore the “Other” label is ignored by removing it during syncing. X-EVOLUTION-UI-SLOT (the parameter used in Evolution to determine the order of properties in the UI) gets stored in CardDAV. The only exception is Google CardDAV which got confused when an IMPP property had both X-SERVICE-TYPE and X-EVOLUTION-UI-SLOT parameters set. For Google, X-EVOLUTION-UI-SLOT is only sent on other properties and thus ordering of chat information can get lost when syncing with Google. * synccompare: support grouping and quoted parameter strings Grouped properties are sorted first according to the actual property name, then related properties are moved to the place where their group tag appears first. The first grouped property gets a “- ” prefix, all following ones are just indended with ” “. The actual group tag is not part of the normalized output, because its value is irrelevant: BDAY:19701230 - EMAIL:john@custom.com X-ABLabel:custom-label2 … FN:Mr. John 1 Doe Sr. - IMPP;X-SERVICE-TYPE=AIM:aim:aim X-ABLabel:Other … - X-ABDATE:19710101 X-ABLabel:Anniversary Redundant tags (those set for only a single property, X-ABLabel:Other) get removed as part of normalizing an item. * WebDAV: use server’s order when listing collections When doing a recursive scan of the home set, preserve the order of entries as reported by the server and check the first one first. The server knows better which entries are more relevant for the user (and thus should be the default) or may have some other relevant order. Previously, SyncEvolution replaced that order with sorting by URL, which led to a predictable, but rather meaningless order. For example, Google lists the users own calendar first, followed by the shared calendars sorted alphabetical by their name. Now SyncEvolution picks the main calendar as default correctly when scanning from https://www.google.com/calendar/dav/. * WebDAV: improved database search (Google, Zimbra) Zimbra has a principal URL that also serves as home set. When using it as start URL, SyncEvolution only looked the URL once, without listing its content, and thus did not find the databases. When following the Zimbra principal URL indirectly, SyncEvolution did check all of the collections there recursively. Unfortunately that also includes many mail folders, causing the scan to abort after checking 1000 collections (an internal safe guard). The solution for both includes tracking what to do with a URL. For the initial URL, only meta data about the URL itself gets checked. Recursive scanning is only done for the home set. If that home set contains many collections, scanning is still slow and may run into the internal safe guard limit. This cannot be avoided because the CalDAV spec explicitly states that the home set may contain normal collections which contain other collections, so a client has to do the recursive scan. When looking at a specific calendar, Google CalDAV does not report what the current principal or the home set is and therefore SyncEvolution stopped after finding just the initial calendar. Now it detects the lack of meta information and adds all parents also as candidates that need to be looked at. The downside of this is that it doesn’t know anything about which parents are relevant, so it ends up checking https://www.google.com/calendar/ and https://www.google.com/. In both cases Basic Auth gets rejected with a temporary redirect to the Google login page, which is something that SyncEvolution must ignore immediately during scanning without applying the resend workaround for “temporary rejection of valid credentials” that can happen for valid Google CalDAV URLs. * WebDAV: enhanced database search (Google Calendar) Additional databases where not found for several reasons. SyncEvolution ignored all shared calendars (http://calendarserver.org/ns/shared) and Google marks the additional calendars that way. The other problem was that the check for leaf collections (= collections which cannot contain other desired collections) incorrectly excluded those collections instead of only preventing listing of their content. With this change, https://www.google.com/calendar/dav/?SyncEvolution=Google can be used as starting point for Google Calendar. * WebDAV: fix database scan on iCloud The calendar home set URL on iCloud (the one ending in /calendars/) is declared as containing calendar data. That was enough for SyncEvolution to accept it incorrectly as calendar. However, the home set only contains calendar data indirectly. * WebDAV: support redirects between hosts and DNS SRV lookup based on URL When finding a new URL, we must be prepared to reinitialize the Neon session with the new host settings. iCloud does not have .well-known support on its www.icloud.com server. To support lookup with a non-icloudd.com email address, we must do DNS SRV lookup when access to .well-known URLs fails. We do this without a www prefix on the host first, because that is what happens to work for icloud.com. With these changes it becomes possible to do database scans on Apple iCloud, using syncURL=https://www.icloud.com or syncURL=https://icloud.com. Giving the syncURL like this is only necessary for a username that does not end in @icloud.com. When the syncURL is not set, the domain for DNS SRV lookup is taken from the username. * WebDAV: more efficient item creation PUT has the disadvantage that a client needs to choose a name and then figure out what the real name on the server is. With Google CardDAV that requires sending another request and only works because the server happens to remember the original name (which is not guaranteed!). POST works for new items without a name and happens to be implemented by Google such that the response already includes all required information (new name and revision string). POST is checked for as described in RFC 5995 once before creating a new item. Servers which don’t support it continue to get a PUT. * WebDAV: send “User-Agent: SyncEvolution” Apple iCloud servers reject requests unless they contain a User-Agent header. The exact value doesn’t seem to matter. Making the string configurable might be better, but can still be done later when it is more certain whether and for what it is needed. * WebDAV: refactor and fix DNS SRV lookup The syncevo-webdav-lookup script was not packaged. It did not report “not found” DNS results correctly and the caller did not check for this either, so when looking up the information for a domain which does not have DNS SRV entries, SyncEvolution ended up retrying for while as if there had been a temporary lookup problem. * signon: make Accounts optional The new “signon” provider only depends on lib[g]signon-glib. It uses gSSO if found, else UOA. Instead of pulling parameters and the identity via libaccounts-glib, the user of SyncEvolution now has to ensure that the identity exists and pass all relevant parameters in the “signon:” username. * gSSO: adapt to gSSO >= 2.0 * config templates: Funambol URLs Funambol turned of the URL redirect from my.funambol.com to onemedia.com. The Funambol template now uses the current URL. Users with existing Funambol configs must updated the syncURL property manually to https://onemediahub.com/sync Kudos to Daniel Clement for reporting the change. * command line: fix –update from directory The “–update
SyncEvolution 1.4.1 released
- 14 April 2014
The first bug fix release in the 1.4 series addresses some issues which occurred on some systems. Several issues with Akonadi were fixed. Details: ——— * 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 https://sourceforge.net/p/freeassociation/bugs/95/). 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. * dbus-session.sh: create XDG_RUNTIME_DIR More recent distros (for example, Ubuntu Saucy) rely on XDG_RUNTIME_DIR. Each time dbus-session.sh 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](https://bugs.freedesktop.org/show_bug.cgi?id=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](https://bugs.freedesktop.org/show_bug.cgi?id=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](https://bugs.freedesktop.org/show_bug.cgi?id=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](https://bugs.freedesktop.org/show_bug.cgi?id=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 <= 1.3.99.4: ———————————— 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 1.3.99.5. 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 http://downloads.syncevolution.org/syncevolution/sources and the original source is in [the git repositories](http://cgit.freedesktop.org/SyncEvolution/). i386, lpia and amd64 binaries for Debian-based distributions are available via the “stable” syncevolution.org repository. Add the following entry to your /apt/source.list:
deb http://downloads.syncevolution.org/apt 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](http://downloads.syncevolution.org/syncevolution/). 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.
SyncEvolution 1.4 released
- 18 February 2014
The 1.4 release of SyncEvolution replaces 1.3.2 as the stable, supported release. 1.4 is the first stable version with the in-vehicle infotainment (IVI) PIM Manager included. GENIVI Diagnostic Log and Trace (DLT) is also supported. For more information about this aspect of SyncEvolution, see the PBAP and PIM entries in the [1.3.99 release notes](http://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/NEWS?id=syncevolution-1-3-99-7) and these [Automotive Linux Summit slides](https://syncevolution.org/blogs/pohly/2013/pim-its-all-about-contacts). The biggest change for normal Linux users is Google CalDAV/CardDAV authentication with OAuth2. These are the open protocol that Google currently supports and thus the recommended way of syncing with Google, replacing ActiveSync and SyncML (both no longer available to all Google customers). Support for Google CardDAV is new. Like Evolution, SyncEvolution does not yet support some of the advanced features of the server, in particular custom labels for phone numbers, emails and addresses. Likewise, some client properties are not supported by the server: CALURI, CATEGORIES, FBURL, GEO and ROLE are not supported. Of ORG, only the first two components are supported. Currently, properties not supported by one side get lost in a full roundtrip sync. Instant Messaging information is supported by both sides with different vCard extensions; the server stores these extensions without showing the information, while SyncEvolution drops the data sent by the server. SyncEvolution depends on external components for OAuth2. It can be compiled to use [gSSO](https://01.org/gsso) or GNOME Online Accounts. The latter is enabled in binaries from syncevolution.org. GNOME Online Accounts >= 3.10 works out of the box for CalDAV and CardDAV. 3.8 is guaranteed to work for CalDAV and may also work for CardDAV, if the Linux distribution ships a patched version (like Debian Testing/Jessie does). If it does not, then GNOME Online Accounts 3.8 binary can be patched to also support CardDAV, see the GOA README. Anything older than 3.8 does not work. Support for Ubuntu Online Accounts is available when compiling from source. For setup instructions see the [GOA](http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backends/goa/README) and [signon](http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backends/signon/README) READMEs. Binary packages of 1.4 on syncevolution.org have enhanced support for recent distros. They now work with EDS >= 3.6 *and* < 3.6. Distros with libical1 like Ubuntu Saucy are also supported. The HTTP server became better at handling message resends when the server is slow with processing a message. The server is able to keep a sync session alive while loading the initial data set by sending acknowledgment replies before the client times out. Some issues in CalDAV, WebDAV and SyncML were fixed. Graham R. Cobb contributed several patches for enhancing ActiveSync support and making it work with Exchange 2010. Guido Günther provided some patches addressing problems when compiling SyncEvolution for Maemo. Details: ——– * D-Bus server: support DLT ([FDO #66769](https://bugs.freedesktop.org/show_bug.cgi?id=66769)) Diagnostic Log and Trace (DLT) manages a sequence of log messages, with remote controllable level of detail. SyncEvolution optionally (can be chosen at compile time and again at runtime) uses DLT instead of its own syncevolution-log.html files. See README-DLT.rst for more information. To use the feature, configure SyncEvolution with “–enable-dbus-server=–dlt –no-syslog” * D-Bus server: fix abort when mixing auto-sync and manual operations ([FDO #73562](https://bugs.freedesktop.org/show_bug.cgi?id=73562)) When enabling auto-sync for a config and then accessing or syncing the config manually via the command line tool, the server would abort at the time when the auto-sync was originally scheduled. * D-Bus server: accept WBXML with charset in incoming connections A user reported via email that the Nokia 515 sends ‘application/vnd.syncml+wbxml; charset=UTF-8’ as type of its messages this tripped up the syncevo-http-server, leading to: [ERROR] syncevo-dbus-server: /org/syncevolution/Server: message type ‘application/vnd.syncml+wbxml; charset=UTF-8’ not supported for starting a sync * D-Bus server: command line options for controlling output and startup The system log is used by default now. New command line options can be used to change this:
-d, --duration=seconds/'unlimited' Shut down automatically when idle for this duration (default 300 seconds) -v, --verbosity=level Choose amount of output, 0 = no output, 1 = errors, 2 = info, 3 = debug; default is 1. --dbus-verbosity=level Choose amount of output via D-Bus signals, 0 = no output, 1 = errors, 2 = info, 3 = debug; default is 2. -o, --stdout Enable printing to stdout (result of operations) and stderr (errors/info/debug). -s, --no-syslog Disable printing to syslog. -p, --start-pim Activate the PIM Manager (= unified address book) immediately. * D-Bus: missing out parameters in D-Bus introspection XML ([FDO #57292](https://bugs.freedesktop.org/show_bug.cgi?id=57292)) The problem was in the C++ D-Bus binding. If the method that gets bound to D-Bus returns a value, that value was ignored in the signature: int foo() => no out parameter It works when the method was declared as having a retval: void foo (int &result) => integer out parameter This problem existed for both the libdbus and the GIO D-Bus bindings. In SyncEvolution it affected methods like GetVersions(). * D-Bus server: avoid progress outside of 0-100% range For example in the new TestLocalCache.testItemDelete100, the percentage value in the ProgressChanged signal become larger than 100 and then revert to 100 at the end of the sync. Seems the underlying calculation is faulty or simply inaccurate. This is not fixed. Instead the result is just clipped to the valid range. * sync: less verbose output, shorter runtime For each incoming change, one INFO line with “received x[/out of y]” was printed, immediately followed by another line with total counts “added x, updated y, removed z”. For each outgoing change, a “sent x[/out of y]” was printed. In addition, these changes were forwarded to the D-Bus server where a “percent complete” was calculated and broadcasted to clients. All of that caused a very high overhead for every single change, even if the actual logging was off. The syncevo-dbus-server was constantly consuming CPU time during a sync when it should have been mostly idle. To avoid this overhead, the updated received/sent numbers that come from the Synthesis engine are now cached and only processed when done with a SyncML message or some other event happens (whatever happens first). To keep the implementation simple, the “added x, updated y, removed z” information is ignored completely and no longer appears in the output. * command line: implement –create/remove-database Creating a database is only possible with a chosen name. The UID is chosen automatically by the storage. Only implemented in the EDS backend. * command line: execute –export and –print-items while the source is still reading Instead of reading all item IDs, then iterating over them, process each new ID as soon as it is available. With sources that support incremental reading (only the PBAP source at the moment) that provides output sooner and is a bit more memory efficient. * command line: recover from slow sync with new sync modes The error message for an unexpected slow sync still mentioned the old and obsolete “refresh-from-client/server” sync modes. Better mention “refresh-from-local/remote”. * command line: show backend error when listing databases fails The command line swallowed errors thrown by the backend while listing databases. Instead it just showed “ deb http://downloads.syncevolution.org/apt 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](http://downloads.syncevolution.org/syncevolution/). 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.
SyncEvolution 1.3.99.7 released
- 23 January 2014
This the final release candidate for 1.4. No further changes planned unless new problems are found. Details: * SSO: support Ubuntu Online Accounts When compiling from source on recent Ubuntu it becomes possible to use Ubuntu Online Accounts for authenticating against Google’s CalDAV and CardDAV servers. * D-Bus server: fix abort when mixing auto-sync and manual operations ([FDO #73562](https://bugs.freedesktop.org/show_bug.cgi?id=73562)) When enabling auto-sync for a config and then accessing or syncing the config manually via the command line tool, the server would abort at the time when the auto-sync was originally scheduled. * D-Bus server: accept WBXML with charset in incoming connections A user reported via email that the Nokia 515 sends ‘application/vnd.syncml+wbxml; charset=UTF-8’ as type of its messages. This tripped up the syncevo-http-server, leading to: [ERROR] syncevo-dbus-server: /org/syncevolution/Server: message type ‘application/vnd.syncml+wbxml; charset=UTf-8’ not supported for starting a sync We need to strip the ‘; charset=UTF-8’ suffix also when checking for WBXML. * packaging: compatible with EDS up to and including 3.10 The packages now contain three versions of syncecal.so: - one for EDS < 3.6 - one for EDS >= 3.6 < 3.10 - one for EDS >= 3.10 with the libecal-1.2 soname patched The third flavor became necessary because EDS 3.10 accidentally changed the soname. The API and ABI actually is the same. Package meta-data was fixed to reflect the extended range of compatible EDS libraries, so syncevolution-evolution can be installed again with recent EDS. * packaging: update syncevolution-kde dependencies kdebase-runtime became kde-runtime in Debian Wheezy. Accept both as prerequisite of syncevolution-kde to allow installation on newer distros without pulling in the transitional kdebase-runtime package. * packaging: fix rpm ([FDO #73347](https://bugs.freedesktop.org/show_bug.cgi?id=73347)) After installing the syncevolution.org rpm on OpenSUSE, SyncEvolution was not starting because its shared libraries were not found unless “ldconfig” was called manually. Now the package does that automatically. * packaging: fix description The syncevolution-bundle description of both rpm and deb packagesaccidentally used the same description as syncevolution-evolution. * test improvements, integration of cppcheck and clang’s scan-build 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 http://downloads.syncevolution.org/syncevolution/sources and the original source is [the git repositories](http://cgit.freedesktop.org/SyncEvolution/). 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:
deb http://downloads.syncevolution.org/apt unstable 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 “syncevolution-activesync” which depends on libraries in Debian Squeeze, for example EDS 3.4. 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/). 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.