Johannes Meier | 28 Oct 21:16 2014

one-off request for paid support (korganizer + phone)

Hi, I'm at my wit's end with syncevolution-akonadi. Maybe somebody can
configure it for me if I pay them, please?

The goal is to get the phone, the desktop calendars, and a few shared
calendars to sync in all directions.

* Desktop: Ubuntu 14.03LTS Linux. Any necessary package can be installed
(e.g. a syncml server).

* Korganizer/Kontact with 8 local calendars, 1 shared one (Google cal), 5
different subscribed ones, and the default birthday calendar. The logical
union of most of these should be synchronized to the phone. It's enough if
the past 2 weeks and future 6 months get synced because not everything will
fit. (A grand total of some 3000 calendar entries.) Appointments and
contacts are necessary, todo tasks would be nice, but I don't need notes.

* Handset: For now, it's a Sony K510i with a Feisar plugin. The
Sony_Ericsson_K750i template should do the trick. Syncing works with iSync
on Mac OS X 10.5.8. However, I'm fine with buying an inexpensive replacement
(smart)phone as long as it has an actual qwertz keyboard and real keys -
touchscreen doesn't count.

* Restrictions: (a) The phone and the desktop must synchronize without
access to the public internet. Bluetooth is fine (or with a different
handset, wireless LAN). The reason is partly availability on the road,
partly bad experience with things going out of business, partly this:

* Restrictions: (b) Compensation will be paid after syncing works and a
step-by-step setup guide is provided (because all software will eventually
(Continue reading)

Christopher Calver | 28 Oct 19:01 2014

N900/ownCloud - Segmentation Faults

I have been successfully running syncevolution on my N900 (Maemo 5 Version 21.2011.38-1) for several years initially synchronising with Horde3 and then with Radicale. Recently, I wanted to move the synchronisation to ownCloud version 7. I have not managed to get this to work: I have been having endless problems with the Segmentation Fault error, both with configuration as root and configuration as user.

I thought I would clear my N900 and re-install syncevolution taking great care at each step.

To be sure that I eliminate as many problems as possible which architecture/version of syncevolution should I install?

Is an apt-get install with the extras-devel repository active sufficent?

Or should I download the package and dpkg -i from

To clear the previous installation I have run the following commands
# apt-get purge –remove syncevolution
and then run
# find / -name syncevolution
to check there are no files left, OK, followed by
# rm -rf /root/.cache/syncevolution
# rm -rf /root/.config/syncevolution
# rm -rf /home/user/.cache/syncevolution
# rm -rf /home/user/.config/syncevolution

Is this sufficient or do I need to flash the N900?

Thanks  in advance
SyncEvolution mailing list
Daniel CLEMENT | 20 Oct 11:47 2014

FYI: Microsoft drop Nokia Sync


Just a word to confirm what could be suspected from a recent attempt I
made at using the OVI service (AKA Nokia Sync). Like many Nokia
customers, shortly after that, I have received an e-mail from Microsoft
which reads:

[Quote] We are planning to discontinue the Nokia Sync service on 5
December 2014. After 5 December 2014, you will not be able to access
your data through the Nokia Sync service. We strongly encourage you to
export and/or migrate your data from the service before this date.

So... it looks like OVI support can safely be dropped from
Syncevolution :-(

Best regards,

Patrick Ohly | 19 Oct 21:04 2014

Re: Configuring Activesync in SyncEvolution

On Sat, 2014-10-18 at 15:36 +0100, Graham Cobb wrote:
> On 15/09/14 16:19, Patrick Ohly wrote:
> > About
> > ==============
> > 
> > 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! :-)
> The (new in this release, I think) checking for mixing shared/unshared
> properties is causing me some logical confusion.  Here is (the outline
> of) how I used to configure my Exchange server config:
> 1) Remove the existing configurations
> 2) syncevolution --configure --template none backend=eas-contacts
> database=Contacts username=my-account-name  <at> Exchange contacts
> 3) syncevolution --configure --template none username=my-account-name
> password= printChanges=1 loglevel=4 target-config <at> Exchange
> 4) syncevolution --configure sync=two-way uri=contacts loglevel=4
> target-config <at> Exchange contacts
> The second step now gives the error:
> [ERROR] per-peer (unshared) properties not allowed: username
> If I remove the username, it gives the error:
> [ERROR] contacts: backend failed: fetching folder list:
> GDBus.Error:org.meego.activesyncd.Error.AccountNotFound: Failed to find
> account []

That's the expected behavior, and hasn't changed in the release
candidate. The new terminology did not change the implementation, just
some names.

In this case the problem is that " <at> Exchange" refers to a context, not a
sync config, and only sync configs have a username property. You could
use "databaseUsername" instead (however, I am not 100% sure whether the
ActiveSync backend supports that - WebDAV does), if you don't mind
repeating that for each source, ahem, datastore.

Or you do as you said yourself and configure the
"target-config <at> Exchange" sync config. When invoking item operations,
remember to use "target-config <at> Exchange" and not just " <at> Exchange",
because SyncEvolution will not automatically use the "target-config"
sync config to find username/password.

> The only way I can get it to work is if I bring step 3 to be in front of
> step 2.  That works, but feels wrong (it also breaks my scripts in a
> hard to fix way, but that is my problem).

Are you sure it used to work?

I checked with 1.4.1, and it fails the same way.

>   It feels like there should be
> one of two cases:
> i) The context ( <at> Exchange) is associated with a particular account.  In
> that case, the account id should be a property on the context, not on
> some peer.

No, contexts are primarily a collection of sources. These sources can be
used in combination with a sync config which then can have additional
properties (username/password, proxy settings), but that's not required.

> ii) The context ( <at> Exchange) is generic for several activesync accounts
> (different users), in which case the folder mappings cannot be checked
> at the time they are set up.  Not very user friendly.

The context could be used like that, starting with Instead of
"target-config", user "user1", "user2", etc. with different account
settings, then pick those when configuring sources and local sync. The
new thing in is that local sync works with target configs not
name "target-config".


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 | 19 Oct 20:52 2014

Re: SyncEvolution

On Sat, 2014-10-18 at 14:32 +0100, Graham Cobb wrote:
> On 15/09/14 16:19, Patrick Ohly wrote:
> > 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! :-)
> I am trying to update my various configs and check that everything works.
> The first problem isn't really a bug because I know the Debian packaging
> is not a supported feature.  But when I tried to upgrade using "apt-get
> install syncevolution-activesync", apt-get would have been happy to
> install the new syncevolution-activesync without upgrading
> syncevolution-activesync-saucy and syncevolution-bundle as well.  Adding
> syncevolution-kde caused all four packages to be upgraded.
> I think the dependency of syncevolution-activesync on
> "syncevolution-activesync-wheezy | syncevolution-activesync-saucy |
> syncevolution-activesync-trusty" should be versioned to require the same
> version.

I agree, this should be changed. Will do.

> I am also surprised that activesyncd-saucy hasn't been upgraded.  Is
> that because it has not changed?



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.
Gregor Horvath | 9 Oct 07:46 2014

Parse error


I use SyncEvolution 1.2.2 on a N900 version in conjunction with a
Radicale server and Icedove clients on the Desktop.
It seems that syncevolution does not like some entries created from a
Debian Icedove Client.
I get the following error, although this snippet is validating fine

From the syncevolution log:

First ERROR encountered: error code from SyncEvolution fatal error
(local, status 10500):  <at> default/calendar5: parsing ical:
Engine V3.4.0.27//EN BEGIN:VTIMEZONE
SUMMARY:Probe Ringwald
LOCATION:le Festsaal

Do you have an idea what is wrong?


SyncEvolution mailing list
Patrick Ohly | 7 Oct 21:08 2014

Re: GOA credentials not found

On Tue, 2014-10-07 at 09:28 -0700, Todd Wilson wrote:
> On Mon, Oct 6, 2014 at 11:56 PM, Patrick Ohly
<patrick.ohly@...> wrote:
> > > > Nevertheless, can you show the output of:
> > > >
> > > > syncevolution --print-config -q google
> > > > syncevolution --print-config -q target-config <at> google
> > >
> > > [I'm leaving off the blank options to save space and redacting a few
> > > id numbers; let me know if you need more]
> > >
> > > syncURL = local:// <at> google
> > > username = goa:account_...
> >
> > When I asked about "username=goa:..." in your "google" sync config", I
> > meant the "google" config. You said that only
> > google/peers/target-config/config.ini has username=goa:... set, but then
> > why does it show up here?
> >
> > Is it really unset in default/peers/google/config.ini?
> Sorry, I was just looking in google/ and didn't think to look in default/:
> $ cd ~/.config/syncevolution
> $ find . -name config.ini -print | xargs grep goa
> ./default/peers/google/config.ini:username = goa:account_...
> ./google/peers/target-config/config.ini:username = goa:account_...

Do you have an idea how it got there? I don't think previous
SyncEvolution versions worked with such a config.

> > Anyway, removing it in the "google" config should allow you to run syncs
> > again:  syncevolution --configure username= google
> Yes, authentication is successful now, but I'm still having some
> problems with the sync. Perhaps we'll have to go into details off-list
> about the contents of the events,

That would be good. A target-config <at> google log file at loglevel=4 would
be useful.


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.
Todd Wilson | 5 Oct 03:41 2014

GOA credentials not found

I may be overlooking something obvious here, but when using the latest 
version ( on Ubuntu 14.04, my GOA credentials are not being found:

% syncevolution --sync refresh-from-local google
[ERROR] goa:account_nnnn: need username+password as credentials

The account number I'm redacting as "nnnn" does exist (I can see it with 
seahorse) and is authorized.

I've also tried deleting the account in seahorse and Online Accounts, 
starting over with a new account, and replacing the old account number in my 
google target-config with the new number, but I still get the same error.
Patrick Ohly | 15 Sep 17:19 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 (measured with valgrind's callgrind on

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"

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

Some issues accessing Apple iCloud were fixed such that CardDAV works
by just giving SyncEvolution username=foobar@... 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 example.

The EDS memo backend is able to switch between syncing in plain
text and iCalendar 2.0 VJOURNAL automatically.


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

  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

* PIM: handle SuspendPeer() before and after transfer (FDO #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@...), 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

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

  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

* EDS: memo syncing as iCalendar 2.0 (FDO #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

    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:// <at> <context name> was allowed and used
  the "target-config <at> context name" config as target side in the local

  Now "local://config-name <at> context-name" or simply "local://config-name"
  are also allowed. "target-config" is still the fallback if only a
  context is give.

  It also has one more special meaning: "--configure
  target-config <at> google" will pick the "Google" template automatically
  because it knows that the intention is to configure the target side
  of a local sync. It does not know that when using some other name
  for the config, in which case the template (if needed) must be
  specified explicitly.

  The process name in output from the target side now also includes the
  configuration name if it is not the default "target-config".

* Google: remove SyncML template, combine CalDAV/CardDAV

  Google has turned off their SyncML server, so the corresponding
  "Google Contacts" template became useless and needs to be removed. It
  gets replaced by a "Google" template which combines the three
  different URLs currently used by Google for CalDAV/CardDAV.

  This new template can be used to configure a "target-config <at> google"
  with default calendar and address book database already enabled. The
  actual URL of these databases will be determined during the first
  sync using them.

  The template relies on the WebDAV backend's new capability to search
  multiple different entries in the syncURL property for databases. To
  avoid listing each calendar twice (once for the legacy URL, once with
  the new one) when using basic username/password authentication, the
  backend needs a special case for Google and detect that the legacy URL
  does not need to be checked.

* config: allow storing credentials for email address

  When configuring a WebDAV server with username = email address and no
  URL (which is possible if the server supports service discovery via
  the domain in the email address), then storing the credentials in the
  GNOME keyring used to fail with "cannot store password in GNOME
  keyring, not enough attributes".

  That is because GNOME keyring seemed to get confused when a network
  login has no server name and some extra safeguards were added to
  SyncEvolution to avoid this.

  To store the credentials in the case above, the email address now gets
  split into user and domain part and together get used to look up the

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" repository. Add the
following entry to your /apt/source.list:
  deb 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 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 steps.


Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution possible:
Patrick Ohly | 4 Sep 17:20 2014

Re: Google CalDAV sync

On Sun, 2014-08-31 at 15:45 -0700, Todd Wilson wrote:

> On Fri, Jul 11, 2014 at 12:02 PM, Todd Wilson <twilson@...>
> wrote:

>         Thanks for this assessment. I appreciate the effort you've put
>         into getting me to this point. At least I can continue to use
>         SE to back-up my Zimbra calendar, which is what I've been
>         doing. And I'll see if I can run the database tests you asked
>         me for previously.
>                 I reported all of that too Google engineers and was
>                 told that they are
>                 working on it. It might not be fixed next week, but it
>                 shouldn't take
>                 months or years either (as in the past). I'll keep an
>                 eye on this.

I checked again and the biggest issue on the server, not being able to
update individual events in a meeting series, is now fixed. The
remaining issues are lack of support for removing individual events from
such a series (one can only remove the entire series, removing some has
no effect) and all-day recurrence exceptions (RECURRENCE-ID gets mangled
- this case should be rare in practice).

The removal issue does not affect "refresh-from-local" syncs, only
two-way syncs where individual items were removed. So again, this should
not be an issue in practice.

Overall it seems that Google CaldDAV now can also be used in two-way

>         Thanks! If they get the problems fixed that will be great.
>         Also, I'd be very interested in knowing what they think of
>         allowing users to subscribe to password-protected calendars --
>         it seems like it would be easy to do, as easy as respecting
>         username and password fields in the calendar URL and using
>         already-existing features of their HTTP(S) client library. For
>         example, do they have a good reason to refuse to implement
>         this? Is it planned but low priority? Or is it something we
>         might also expect relatively soon?
>                 Please ping me again end of August.

I forgot to check this earlier and ask Google. The calendar team is
active in StackOverflow, so I have asked there:


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.
NeonJohn | 27 Aug 04:58 2014

SyncML update

SyncML is a commercial app for Android that comes as close to the old
Palm Pilot experience as I could ever expect.  I loathe commercial,
closed source software but in this case I had no choice.

So I bought it from the Play store.  As you may recall, it took quit a
bit of work to get my configuration running.  The guy behind the SyncML,
Beat Forster was incredibly helpful in getting his side to work.

My database are large and old, dating back to my first Palm Pilot days.
 Around 800 contacts and 1500 calendar events.  I keep my journal and my
expenses in the calendar so it grows rapidly.

SyncML got the job done but was sloooow.  Over 5 minutes for a sync.
Needless to say I didn't use the AutoSync feature!

An update became available and I let it install.  Everything came to a
halt.  The application seemed to lock up.  After rebooting the phone and
a few other things, I contacted Beat again.

Turns out the upgrade had a major improvement in that it now cleans up
the datasets as much as possible, eliminating duplicates, removing
illegal characters from fields and so on.  The problem was his first
algorithm was sloooow.

Beat suggested that start a sync and just let it run.  I did so.  5
hours later,the cleanup finished.  SyncEvolution had long since timed
out (default is 5 minutes) so the sync didn't complete.  The second time
through it took only about an hour but SyncEvolution had again timed out
so the actual sync didn't happen.

I changed the time-out period to an hour
(~/.config/syncevolution/default/peers/default/config.ini, field name
ReTryDuration) and got a sync to complete.

Thus started about a 2 week cycle of Beat refining the code, me testing,
reloading Evolution databases from backups to duplicate the problems and
so on.

The results are amazing.  A sync takes about 30 seconds.  He's had solid
ware going for several days now. Yesterday I turned on AutoSync and set
the interval to 15 seconds.  So far perfect execution and no dataset
corruption that I can see.

Android has no concept of a to-do list or notes so SyncML has editors
for those built-in.  Very Palm Pilot-like.

So to summarize, if you have large contacts or calendars, do NOT install
the current upgrade.  Wait a few days for the NEXT upgrade to become

This the first commercial software I've ever recommended.  Instead of
screwing around with the FOSS stuff out there (which I spent a lot of
time trying to get to work), just buy the app, install it and forget
about it.

Finally, I want to thank Beat for his outstanding tech support.  He
dropped everything for several days to make this work.  Practically
unheard of these days.

I'm still uncomfortable with non-FOSS software but given this level of
support, I can go with it.



John DeArmond
Tellico Plains, Occupied TN      <-- THE source for induction heaters    <-- email from here <-- Best damned Blog on the net
PGP key: BCB68D77