Leszek Piątek jr | 15 Jul 17:34 2014

Encoding problems


I'm trying to set up a SyncML server to sync old mobiles through
Zimbra server. I manage to set up such thing using configuration:

syncevolution --configure \
  --template webdav \
  --sync-property syncURL= \
  --sync-property peerIsClient=1 \
  --sync-property remoteDeviceId=${deviceID} \
  --sync-property username=${peer} \
  --sync-property password=${pass} \
  --sync-property keyring=false \
  --source-property sync=two-way \
  --source-property addressbook/database=${URL}/Contacts/ \
  --source-property addressbook/backend=carddav \
  --source-property addressbook/databaseUser=${peer} \
  --source-property addressbook/databasePassword=${pass} \
  --source-property calendar/database=${URL}/Calendar/ \
  --source-property calendar/backend=caldav \
  --source-property calendar/databaseUser=${peer} \
  --source-property calendar/databasePassword=${pass} \
  --source-property memo/database=${URL}/Tasks/ \
  --source-property todo/database=${URL}/Tasks/ \

The problem I get is that all calendar/contact entries written in non
ASCII are changed to underscore "_" sign. Have anyone any idea what
could be wrong?

(Continue reading)

NeonJohn | 14 Jul 20:44 2014

Droid X/syncevolution problems

Back again.  I had everything working using SyncML on the Droid and then
Canonical did an update....  Broke everything.

Ubuntu 14.04LTS on the server side.
SyncEvolution 1.4.1, updated from this page


Incidentally, this procedure does not work for Ubuntu.  What DOES work
is to put the

deb http://downloads.syncevolution.org/apt stable main



And then fire off the Snynaptics package manager.  Do an update and the
new version will appear.  It automatically de-installs the old version.

I used this page


For my initial, first setup.  My version of the configure command is

syncevolution --configure --template SyncEvolution_Client \
            --sync-property remoteDeviceId=f87b7a5a6b3c-A000002278B6A4_pro \
            --sync-property username=fredandjake \
(Continue reading)

Emfox Zhou | 13 Jul 15:18 2014

Problems when auth to google carddav

Hello, I've try to sync google contacts to my debian box.

The syncevolution version is 1.4-1.1, I did according to the manual:

emfox <at> XXXX:~$ syncevolution --configure --template WebDAV username=XXXXX-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org password=XXXX database=https://google.com:443/carddav/v1/principals/XXXX%40gmail.com/lists/default/ target-config <at> webdav
[INFO] addressbook: looking for databases...
[INFO] addressbook: okay
[INFO] calendar: looking for databases...
[INFO] calendar: no database to synchronize
[INFO] memo: looking for databases...
[INFO] memo: no database to synchronize
[INFO] todo: looking for databases...
[INFO] todo: no database to synchronize
emfox <at> XXXX:~$ syncevolution --configure --template SyncEvolution_Client syncURL=local:// <at> webdav sslverifyserver=0 username= password= webdav addressbook
[INFO] addressbook: looking for databases...
[INFO] addressbook: backend failed: error code from SyncEvolution authorization failed (remote, status 401): PROPFIND: Neon error code 3 = NE_AUTH, HTTP status 401: Could not authenticate to server: ignored GoogleLogin challenge
[ERROR] addressbook: backend failed: error code from SyncEvolution authorization failed (remote, status 401): PROPFIND: Neon error code 3 = NE_AUTH, HTTP status 401: Could not authenticate to server: ignored GoogleLogin challenge

I searched the maillist, and realised it may be an ssl issue, so I add the sslverifyserver=0 option.

What could be the problem?

Emfox Zhou

GnuPG Public Key: 0xF7142EC2
SyncEvolution mailing list
Yury Vidineev | 8 Jul 19:45 2014

Will activesyncd work with Exchange 2007?

I'm trying to set up contacts sync with Exchange 2007 as described in this 
manual: https://syncevolution.org/wiki/ms-exchange-and-kde-synchronization

print-databases works as expected:

$ syncevolution --print-databases username=my.email@... backend=eas-

   Contacts (2) <default>

But I can't export any contact (export return nothing):

$ syncevolution --export - target-config <at> Work contacts

$ EAS_DEBUG=3 /usr/libexec/activesyncd
(process:30138:0x10db850): libeas-WARNING **:Found password in GConf, writing 
it to Gnome Keyring
(process:30138:0x10db850): libeas-Message:parent_name[Collection] status = [1]
(process:30138:0x10db850): libeas-WARNING **:Found no <Responses> element or 
<Commands> element>
(process:30138:0x10db850): libeas-WARNING **:folder_sync response XML is empty
(process:30138:0x10db850): libeas-WARNING **:folder_sync response XML is empty

Calendar sync with the same credentials works (well, partially).

$ syncevolution --version
SyncEvolution 1.4.1
using libical.so.1
using libical.so.1
using libbluetooth.so.3

Is there some solution that I can try? Thanks in advance!

P.S. Sorry for my English
NeonJohn | 7 Jul 04:43 2014

Ubunto 12.04 plus Motorola Droid X Help!

Hello List,

John here.  Embedded systems engineer who is going nutz trying to get my
new/old Motorola Droid X to talk to my Ubuntu 12.04 system.

On the Droid side, I purchased the Synthesis SyncML Pro application
after having no luck with the free SyncML clients.  Synthesis is using
its default settings with the server URL set to:

I have set up the server according to the instructions here:


My specific config command is

syncevolution --configure --template SyncEvolution_Client \
            --sync-property remoteDeviceId=fac-A000002278B6A4 \
            --sync-property username=neonjohn \
            --sync-property password=********** \
            --source-property addressbook/uri=contacts \
            --source-property calendar/uri=events \
            --source-property todo/uri=tasks \
            --source-property memo/uri=notes \


syncevo-http-server -d http://localhost:9000/syncevolution

Running, I get the following debug line when executing the above command:

[DEBUG] sync: auto sync: refreshing default
[DEBUG] sync: auto sync: default: auto sync '0', no Bluetooth, no HTTP,
1800 seconds repeat interval, 300 seconds online duration

When I run syncevolution on the command line I get the following

jgd <at> den:~$ syncevolution
   select database via relative URI (<path>)

   select database via relative URI (<path>)

Evolution Address Book = Evolution Contacts = evolution-contacts:
   Personal (local:system) <default>
   Ubuntu One (couchdb://

Evolution Calendar = evolution-calendar:
   Personal (local:system) <default>
   Birthdays & Anniversaries (contacts:///)

Evolution Task List = Evolution Tasks = evolution-tasks:
   Personal (local:system) <default>

Evolution Memos = evolution-memos:
   Personal (local:system) <default>

Show available sources:

The problem is that when I run a sync (currently only with contacts
enabled in Synthesis, I get a 404 error and the debug message is:

[DEBUG] twisted: - - [07/Jul/2014:02:26:36 +0000] "POST
/syncevolutlon HTTP/1.1" 404 153 "-" "SySync Client PocketPC PRO/V3.0.1
V3.4.0.72 Android/2.3.4 Android DROIDX"

Using a packet sniffer, I see that Synthesis sends the following request

0000   78 45 c4 31 37 1b f8 7b 7a 5a 6b 3c 08 00 45 00  xE.17..{zZk<..E.
0010   00 bc 6a da 40 00 40 06 4b 23 c0 a8 01 64 c0 a8  ..j. <at> . <at> .K#...d..
0020   01 8a bc 0b 23 28 eb b4 2c 3b 9d 1f af 60 80 18  ....#(..,;...`..
0030   0b 68 06 0b 00 00 01 01 08 0a 01 a7 4f 54 17 b6  .h..........OT..
0040   95 37 76 6e 64 2e 73 79 6e 63 6d 6c 2d 64 65 76  .7vnd.syncml-dev
0050   69 6e 66 2b 77 62 78 6d 6c 00 01 01 00 00 54 6e  inf+wbxml.....Tn
0060   57 03 2e 2f 64 65 76 69 6e 66 31 32 00 01 01 01  W../devinf12....
0070   01 46 4b 03 33 00 01 4f 03 32 30 31 00 01 54 6e  .FK.3..O.201..Tn
0080   57 03 63 6f 6e 74 61 63 74 73 00 01 01 67 57 03  W.contacts...gW.
0090   2e 2f 63 6f 6e 74 61 63 74 73 00 01 01 5a 00 01  ./contacts...Z..
00a0   45 4f 03 32 30 31 34 30 37 30 37 54 30 32 32 37  EO.20140707T0227
00b0   35 33 5a 00 01 01 55 03 33 30 30 30 30 30 30 30  53Z...U.30000000
00c0   00 01 01 01 01 00 00 12 01 01                    ..........

So it looks like Synthesis is requesting ./contacts.

Syncevolution replies with

0000   f8 7b 7a 5a 6b 3c 78 45 c4 31 37 1b 08 00 45 00  .{zZk<xE.17...E.
0010   01 64 3a 59 40 00 40 06 7a fc c0 a8 01 8a c0 a8  .d:Y <at> . <at> .z.......
0020   01 64 23 28 bc 0b 9d 1f af 60 eb b4 2c c3 80 18  .d#(.....`..,...
0030   05 36 2f 16 00 00 01 01 08 0a 17 b6 95 38 01 a7  .6/..........8..
0040   4f 54 48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e  OTHTTP/1.1 404 N
0050   6f 74 20 46 6f 75 6e 64 0d 0a 44 61 74 65 3a 20  ot Found..Date:
0060   4d 6f 6e 2c 20 30 37 20 4a 75 6c 20 32 30 31 34  Mon, 07 Jul 2014
0070   20 30 32 3a 32 37 3a 32 35 20 47 4d 54 0d 0a 43   02:27:25 GMT..C
0080   6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 31  ontent-Length: 1
0090   35 33 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65  53..Content-Type
00a0   3a 20 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61  : text/html; cha
00b0   72 73 65 74 3d 75 74 66 2d 38 0d 0a 53 65 72 76  rset=utf-8..Serv
00c0   65 72 3a 20 54 77 69 73 74 65 64 57 65 62 2f 31  er: TwistedWeb/1
00d0   31 2e 31 2e 30 0d 0a 0d 0a 0a 3c 68 74 6d 6c 3e  1.1.0.....<html>
00e0   0a 20 20 3c 68 65 61 64 3e 3c 74 69 74 6c 65 3e  .  <head><title>
00f0   34 30 34 20 2d 20 4e 6f 20 53 75 63 68 20 52 65  404 - No Such Re
0100   73 6f 75 72 63 65 3c 2f 74 69 74 6c 65 3e 3c 2f  source</title></
0110   68 65 61 64 3e 0a 20 20 3c 62 6f 64 79 3e 0a 20  head>.  <body>.
0120   20 20 20 3c 68 31 3e 4e 6f 20 53 75 63 68 20 52     <h1>No Such R
0130   65 73 6f 75 72 63 65 3c 2f 68 31 3e 0a 20 20 20  esource</h1>.
0140   20 3c 70 3e 4e 6f 20 73 75 63 68 20 63 68 69 6c   <p>No such chil
0150   64 20 72 65 73 6f 75 72 63 65 2e 3c 2f 70 3e 0a  d resource.</p>.
0160   20 20 3c 2f 62 6f 64 79 3e 0a 3c 2f 68 74 6d 6c    </body>.</html
0170   3e 0a                                            >.

So it looks like SyncEvolution is not finding the Evolution databases.
I suspect the problem is that Canonical moved them from their "standard"
Evolution locations (they're bad about that!) but I can't figure out how
to specify the proper locations.

After spending a couple of days on this I gotta punt and ask for help!

If I get really lucky, someone on this list has already gotten Ubuntu
and SyncEvolution to work properly.  If not, hopefully someone can point
me in the right direction.  At this point I'm stumped.



John DeArmond
Tellico Plains, Occupied TN
http://www.fluxeon.com      <-- THE source for induction heaters
http://www.neon-john.com    <-- email from here
http://www.johndearmond.com <-- Best damned Blog on the net
PGP key: wwwkeys.pgp.net: BCB68D77
Pietro Battiston | 27 Jun 18:08 2014

"backend not supported by any of the backend modules"

Dear list,

since a couple of years I am a happy user of syncevolution under Debian
testing + Synthesis SyncML on my Android device (I only use it for the

However now, when I try to sync, I run as usual

syncevo-http-server http://localhost:9000/syncevolution

... but when I start the sync from the device, I get the following error
in the terminal:

First ERROR encountered: error code from SyncEvolution error parsing
config file (local, status 20010): addressbook: backend not supported by
any of the backend modules (syncxmlrpc, syncsqlite, syncqtcontacts,
syncmaemocal, synckcalextended, syncfile, syncdav, syncakonadi,
syncaddressbook, syncactivesync, platformkde) or not correctly
configured (backend=addressbook databaseFormat= syncFormat=)

The configuration itself hasn't changed in any way except for the
DeviceID which I just updated (because for some reason which is a
mystery to me - but which I don't think has anything to do with the
error I am writing about - my copy of Synthesis was raising an "invalid
license" error, and when I reregistered it, it changed DeviceID).

Since it has been some weeks since I last synced, I'm not able to
recollect exactly which packages I may have upgraded since.

Does anybody have any hint of what is going wrong? Are there known
problems with recent evolution versions? (I am using 3.8.5)

Thanks in advance for any help,

Pietro Battiston
Michael McCrann | 24 Jun 14:41 2014

syncevolution Google contacts failure


I have been syncing successfully from Evolution to Google contacts using sync 

A couple of days ago I tried to sync but it failed on me. This is the command 
I run and the output:  

[michael <at> bigb webapp]$ syncevolution --run -s two-way 'google_contacts'
[INFO] calendar: inactive
[INFO] memo: inactive
[INFO] todo: inactive
[INFO] SoupTransport Failure: https://m.google.com/syncml via libsoup: Not 
[INFO] Transport giving up after 0 retries and 0:01min
[ERROR] transport problem: transport failed, retry period exceeded
[INFO] addressbook: inactive
[ERROR] aborted on behalf of user (local, status 20017)
[INFO] creating complete data backup after sync (enabled with dumpData and 
needed for printChanges)

It doesn't seem to able to find the Google syncml URL.

I also have a sync with OneMediaHub and that is working fine.

Please can anyone tell me how I can fix this issue? 
Nina Steiger | 14 Jun 23:18 2014

Activesync to/from office365.com

Hello all,

I have managed to synchronize our office calendar at outlook.office365.com with 
KDE-korganizer (4.12.4) (syncevolution under debian jessie kde4.13. 
Thank you for your excellent work Patrick.

For some reason it didn't work with kwallet (I was never asked for the 
password), I had to install gnome-keyring.

My question now is: 

Is it possible to sync shared calendars via actice sync?

They have been accessible through davmail (an exchange caldav/carddav gateway 
) by otherUsername@... with the credentials of my account 
myUsername@... (davmail stopped working for me at least at home
some weired redirects to wrong authenticatiion servers after M$ changed their 
office365 version, that's why I am trying syncevolution)

I do not understand how to configure syncevolution with 
myUsername@... and use a different username for the calendar 

syncevolution --print-databases username=myUsername@... \ 		
	backend="ActiveSync Events" 
ActiveSync Events:
   Kalender (9) <default>

only shows one calendar. But I definitely have rights to read calendars from my 

May anyone give me a hint which direction to investigate further?

Thank you for reading 
Khurshid Alam | 27 May 16:55 2014

Re: documentation update, enhanced command line - second attempt

On Sat, May 24, 2014 at 1:37 PM, Emiliano Heyns <emiliano.heyns-K1gFvDpcIh2VEjtw5UbVHw@public.gmane.org> wrote:
Here's the list of changes made since I first proposed the revised README.rst: "datastore" avoids that misconception. "data store" in two words could also have been used; not sure which spelling is better.
I think "datastore" is better. As a single term, is indicates a SyncEvolution concept. As two words, it seems to indicate a more general term that is not so tied to SyncEvolution.

SyncEvolution mailing list
Patrick Ohly | 26 May 11:30 2014

Re: Syncing two servers - Zimbra

On Mon, 2014-04-14 at 09:53 +0200, Patrick Ohly wrote:
> So the root problems are that a) SyncEvolution does a search for
> calendars and b) that this takes a long time with the Zimbra server and
> eventually fails. The exact reason for both remains to be seen.
> When checking the principle URL, it should
> only look for meta information like the calendar-home-set (= the URL
> under which calendars are found).
> There's nothing wrong with having a principal URL that contains
> collections. I've not seen it done like that elsewhere, though, and you
> seem to be first one to test with Zimbra.

The revised WebDAV search in SyncEvolution should take this
into account. I hope that it is now fast with Zimbra, too, but haven't
actually tested it with Zimbra.

Todd, can you give that new version a spin and report back?

I'm not sure whether we really need to change the current --configure
behavior. For now I'd prefer to keep it as it is.


Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
Patrick Ohly | 26 May 11:24 2014


============== 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.


* 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
  - 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

  During syncing, SyncEvolution takes care to translate between the
  vCard flavor used internally (based on Evolution) and the CardDAV
  vCard flavor. This mapping includes:


    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.


    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

    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.


    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:

    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:

  - EMAIL:john@...
  FN:Mr. John 1 Doe Sr.
  - X-ABDATE:19710101

  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

  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  <at> 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 <dir name>" operation was supposed to take the
  item luids from the file names inside the directory. That part
  had not been implemented, turning the operation accidentally
  into an "--import".

  Also missing was the escaping/unescaping of luids. Now the
  same escaping is done as in command line output and command
  line parsing to make the luids safe for use as file name.

* testing: added server-specific tests for CardDAV covering
  remote item formats and edit conflicts.

Upgrading from releases <=

If the value of "username/databaseUser/proxyUser" contains a colon,
the "user:" prefix must be added to the value, to continue treating it
like a plain user name and not some reference to an unknown identity
provider (like "id:", "goa:", "signon:", etc.).

The lookup of passwords in GNOME Keyring was updated slightly in It may be necessary to set passwords anew if the old one is
no longer found.

Upgrading from release 1.2.x:

The sync format of existing configurations for Mobical (aka Everdroid)
must be updated manually, because the server has encoding problems when
using vCard 3.0 (now the default for Evolution contacts):
   syncevolution --configure \
                 syncFormat=text/x-vcard \
                 mobical addressbook

The Funambol template explicitly enables usage of the
"refresh-from-server" sync mode to avoid getting throttled with 417
'retry later' errors. The same must be added to existing configs
   syncevolution --configure \
                 enableRefreshSync=TRUE \

Upgrading from releases before 1.2:

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

Source, Installation, Further information


Source code bundles for users are available in
and the original source is in the git repositories

i386, lpia and amd64 binaries for Debian-based distributions are
available via the "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

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
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

After installation, follow the
http://syncevolution.org/documentation/getting-started steps.


Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution possible: