Patrick Ohly | 17 Apr 14:26 2014

Re: Google CalDAV sync

[Replying to the list with Todd's permission]

On Mon, 2014-04-14 at 17:55 -0700, Todd Wilson wrote:
> Patrick,
> This is my first question about the Google side of my attempted sync
> set-up, so I'm starting a new thread. I'm using
> as a resource. Here are the steps I've taken so far:
> 1. As a precaution, I started up GOA, deleted my Google Account, and
> re-added it, authenticating successfully inside the GOA application.

Which version of GOA, which distro, and what permissions where you asked
to grant?

It is important that "Google Calendar" and (for Google Contacts) "Google
Contacts via CardDAV" appear there. Yes, Google distinguishes between
Google Contacts via their own API and CardDAV.

> 2. I went online to my Google Account and verified, under Recent
> Activity, that I've signed in (Linux). Under Account Permissions, it
> says (among many other things, of course):
(Continue reading)

Daniel CLEMENT | 16 Apr 13:19 2014

FYI: Funambol old sync URL now seems to be rejected

Dear list members,

I just noticed yesterday that syncing with Funambol had began to fail.

I still had the old (default) sync URL ( in
my Syncevolution parameters. It had worked so far.

But it appears that this address is now rejected. This could be
temporary, but I doubt it.

I could solve this by using (found on their
web site).

However, while the latter worked fine in Syncevolution, I was unable to
get it working on my Nokia Symbian phone. But (instead of https://) did work.

Hope this can save Funambol users some hair-scratching. 

Best regards,

Patrick Ohly | 15 Apr 11:36 2014

documentation update, enhanced command line


The "Getting the concepts clear" mail thread and a private email
exchange with Todd identified several shortcomings in the documentation
and/or implementation. This is my attempt to address those. A diff and
the full modified README.rst are attached.

Some of these changes will require changes in the implementation.

In short, what I am trying to achieve is:
      * 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 source configs in
        the same context").
      * An entire section on config properties in the terminology
      * Less focus on conflict resolution, as suggested by Graham.
      * Remove the hard-coded "target-config" name. It still needs to be
        there as fallback for existing configs or users continuing to
        use the current instructions.
      * Fix examples that became invalid when fixing the password
        storage/lookup mechanism for GNOME keyring in 1.4. I noticed
        that the username=email-address part should be handled without
        additional properties.
      * Fix WebDAV with DNS auto-discovery. Few servers support it, so
        this hasn't been noticed before.
      * Fix the implicit command line magic where it does some
        consistency checks when creating new configs. Not exactly sure
(Continue reading)

Patrick Ohly | 14 Apr 12:37 2014

SyncEvolution 1.4.1 released

About SyncEvolution

SyncEvolution synchronizes personal information management (PIM) data
via various protocols (SyncML, CalDAV/CardDAV, ActiveSync). It syncs
contacts, appointments, tasks and memos. It syncs to web services or to
SyncML-capable phones via Bluetooth. 

Binaries are available for Linux desktops (using GNOME Evolution, or
KDE's Akonadi), for Maemo (Nokia N900, N9) and Sailfish OS (Jolla

About 1.4

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.
(Continue reading)

Patrick Ohly | 9 Apr 22:39 2014

Re: Getting the concepts clear (Was: Configuring a target)

[adding the list back - Emile, please remember to do a group-reply]

On Wed, 2014-04-09 at 19:46 +0200, Emiliano Heyns wrote:
> On Apr 9, 2014 5:52 PM, "Patrick Ohly" <patrick.ohly@...> wrote:
> > > So the target-config is considered to live inside the data source?
> >
> > Not inside the data source. It's treated like a sync config and thus
> > lives inside a context. Like a normal sync config it is connected to
> > data source configs via that context.
> So target configs can potentially be applied to any data source with
> which it shares a context.

There is only one "target-config" per context, because the name is
(currently) fixed. As discussed with Graham, this limitation could be
removed in favor of letting users choose their own target config name
with syncURL=local://<target config> <at> <context.

> > > And if the
> > > target-config hosts the sync property, it's also (in addition to
> being a
> > > kind of sync config) a kind of source config it seems. Which
> properties
> > > can a target-config hold?
> >
> > A target-config is exactly like a sync config and can hold all of
> the
> > sync properties. Whether all of them are useful or valid is a
> different
(Continue reading)

Patrick Ohly | 9 Apr 15:08 2014

Re: merging of winning and loosing items

On Wed, 2014-04-09 at 12:55 +0000, Emiliano Heyns wrote:
> On 09/04/2014 14:49:22, "Patrick Ohly" <patrick.ohly@...> wrote:
> >
> >It's hard to do with the existing Synthesis engine (it expects the data
> >stores to really apply changes) and protocols. SyncML has sync anchors
> >and could in theory repeat the last sync, but I suspect that many
> >implementations will not implement that correctly. libsynthesis does 
> >(as
> >far as I know), but SyncEvolution doesn't.
> >
>   How did Google's Wave and products like CouchDB handle such things? As 
> they revolve around sync, this ought to be a huge problem for these.

These are closed systems and thus have full control over all sides of
the sync and the protocol involved. Therefore it is a different problem
whose solution wouldn't work for SyncEvolution.

For example, CouchDB assumes that a DB gets created in one place and
then gets replicated. You cannot take two independent DBs and merge them
(at least as far as I know - I am not a CouchDB expert). The data also
cannot be stored in a different format outside of the DB (in particular
using the existing PIM storage of a certain system).

See also


Best Regards, Patrick Ohly

(Continue reading)

Patrick Ohly | 9 Apr 11:36 2014

merging of winning and loosing items


I'm currently writing tests for handling of conflicts. This wasn't done
earlier because SyncEvolution's test suite primarily targeted syncing
with SyncML servers, and behavior of those was out of control anyway.
With local syncing and/or SyncEvolution as HTTP server that's different.

My main concern at the moment are update/update conflicts where both
sides updated the same common item before syncing. libsynthesis
determines the winning item based on age (REV in vCard, LAST-MODIFIED in
iCalendar). That determines which side's single-value properties are
preserved when merging them isn't possible. I already noticed that I
need tests for both cases, because a particular SyncEvolution bug
( only shows up in
one of the two cases.

How does this apply to arrays? Consider the following scenario: the
client adds a new TEL, the server a new EMAIL (in this order). What I
observe is that the server's item wins, preserving the server's EMAIL,
while the client's TEL array gets overwritten with the server's less
complete TEL array. The new TEL from the client thus gets lost.

That is with the following profile:

      <!-- telephone numbers -->
      <field name="TEL"         array="yes" type="telephone" compare="conflict"/>
      <field name="TEL_FLAGS"   array="yes" type="integer"   compare="conflict"/> <!-- offset 0 -->
      <field name="TEL_LABEL"   array="yes" type="string"    compare="conflict"/> <!-- offset 1 -->
      <field name="TEL_ID"      array="yes" type="integer"   compare="conflict"/> <!-- offset 2 -->
      <field name="TEL_SLOT"    array="yes" type="integer"   compare="never"/>    <!-- offset 3 -->
(Continue reading)

Patrick Ohly | 9 Apr 10:11 2014

Re: Correct incantation for sqlite backend

On Wed, 2014-04-09 at 07:31 +0000, Emiliano Heyns wrote:
> On 09/04/2014 08:30:42, "Patrick Ohly" <patrick.ohly@...> wrote:
> >On Tue, 2014-04-08 at 19:46 +0000, Emiliano Heyns wrote:
> >    Currently inactive::
> >     XMLRPC interface = xmlrpc
> >        Data exchange is done via an XMLRPC interface on the datastore.
> >
> Shame, I had plans for that. Ah well.

You would have to compile from source to use it. I could enable it in builds, but I am not certain how useful it would be.

> Is this the right incantation for caldav at Google?
>   syncevolution --configure \
>     backend=caldav \
>     databaseUser=john.doe@... \
>     databasePassword=foobar \
> database= 
> \
>      <at> google \
>     main-google-calendar

Looks right for the default calendar. For other calendars it is


(Continue reading)

Patrick Ohly | 9 Apr 10:03 2014

Re: Getting the concepts clear (Was: Configuring a target)

On Wed, 2014-04-09 at 07:27 +0000, Emiliano Heyns wrote:
> On 09/04/2014 08:48:27, "Patrick Ohly" <patrick.ohly@...> wrote:
> >>  >> So a "peer" isn't really a SE concept, then?
> >>  >SyncEvolution did not invent the term, yes. It gets defined anyway, 
> >>to
> >>  >make it clear in which meaning it is used.
> >>  OK, then my howto is going to drop the work 'peer' too.
> >
> >Again, I suspect that avoiding the word will not be easy. Sometimes you
> >just have to give that thingie a name that you synchronize with, and
> >always saying "the server, phone, or other computer" gets tiresome.
> This is easier to avoid (so far) in my HOWTO -- the thingie simply gets 
> a very concrete name.

Yes, for a specific HOWTO that's easy. It gets harder when talking about
the abstract concepts.

> >>  Right! So use determines whether it is a sync or a source config! A
> >>  config in and of itself is just a bag of properties!
> >
> >Wait, I was talking about sync and target configs above. You are right,
> >a "config" is just a set of properties, but there is a difference
> >between "source config" and "sync/target config" that goes beyond just
> >differnt usage, because there are two different set of properties that
> >can go into the former (--source-property ?) and the latter
> >(--sync-property ?).
> >
> >This difference is enforced when setting properties. You cannot set a
> >sync property in a source config or vice versa.
(Continue reading)

Emiliano Heyns | 8 Apr 21:46 2014

Correct incantation for sqlite backend

I'm trying to set up a sqlite source config, using
syncevolution --configure --template none backend=sqlite database=file:///home/eas/local/contacts.sqlite <at> Local contacts
When I do this, I get:
[INFO] contacts: looking for databases...
[INFO] contacts: backend failed: error code from SyncEvolution fatal error (local, status 10500): contacts: inactive
[ERROR] error code from SyncEvolution fatal error (local, status 10500): contacts: inactive
Is the sqlite backend not active in 1:1.4.1-2?
SyncEvolution mailing list
Dustin Demuth | 8 Apr 20:01 2014

SSLVerifyHost and SSLVerifyServer for a Source


(how) is it possible to configure the "SSLVerifyHost" and
"SSLVerifyServer" parameters for a Source?

I'd need this to sync my phone (peer) with a webdav (source).
Unfortunately the WebDAV-server certificate does not match it's hostname
right now.

Errors I receive right now:
[ERROR] transport problem: REPORT 'full calendar': Neon error code 1, no
HTTP status: Server certificate verification failed: certificate issued
for a different hostname


Some good thinks, I want to tell:

Syncevolution is a really good piece of software. Versatile, active
development,  vibrant mailing list. I like it.