Gregor Horvath | 12 Dec 12:49 2014

N900 / Radicale multiget 410 error


I get the following error in the log for one calender, the other ones
work with the same Europe/Vienna Timezones:

First ERROR encountered: error code from SyncEvolution command gone
(remote, status 410): GET item Europe/Vienna not returned by 'multiget
new/updated items': bad HTTP status: <status 1.1, code 410, class 4,

$ syncevolution --version
SyncEvolution 1.3+20120925+SE+899a952+unclean (pre-release)

I read that there is some workaround in syncevolution because radicale
does not support multiget: 

But it seems not to work in this case.
Any hints?
Can multiget be turned off in the configuration?

Best regards

(Continue reading)

Tino Mettler | 4 Dec 17:14 2014

User TLS instead of SSLv3 in syncevolution-http-server


the attached patch switches the syncevo-http-server script from using
SSLv3 to TLS. This avoids the potential security risk that arises with
SSLv3 and also fixes connections problems with clients not supporting
SSLv3 anymore. The latter is the case with syncevolution in Debian
Jessie, as it uses gnutls with disabled SSLv3 support.

SyncEvolution mailing list
Patrick Ohly | 11 Nov 11:47 2014

signing apt repos


I've set up signing of the repos. The key that I am
using is not signed by anyone, so one has to trust that the initial
download and fingerprint have not been tampered with. At least once that
is done and worked, further manipulations will raise alarms.

To ensure that apt trusts the new key, use (as root):
  apt-key adv --keyserver --recv-keys B2EC3981

To verify the key, compare the fingerprint:

  apt-key finger
pub   4096R/B2EC3981 2014-11-11
      Key fingerprint = 5B77 1F15 FA70 1B73 A7DE  180D AE84 A13C B2EC 3981
uid                  SyncEvolution <syncevolution@...>
sub   4096R/2A54FB85 2014-11-11
sub   4096R/5E4ABB95 2014-11-11 [expires: 2015-11-11]

Note that I chose to set an expiry date one year from now for the
sub-key that actually gets used to sign the repos. My current
understanding is that one year from now I will have to create a new
sub-key, re-sign the repos and all users must refresh the key from the
key server. Is that too much trouble? Should I rather replace the
sub-key with a permanent one now, before many users add the expiring


(Continue reading)

Graham Cobb | 10 Nov 11:49 2014

"First Monday of the month" event problems

I have noticed (bug #86102) that activesyncd is creating the wrong RRULE
for recurrences of the form "nth some-weekday".  Without having looked
at the code yet (just the logs) this looks like an activesyncd problem.

But it looks like (bug #70693) even if I fix that, that the event still
won't get synced correctly.  Is #70693 still unfixed?

Patrick Ohly | 4 Nov 15:18 2014

SyncEvolution 1.5 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.5

This version is the new stable, supported version of SyncEvolution.
Compared to the last 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@... and password, but is not
formally tested. Syncing with iCloud calendars ran into a server
limitation (reported as 17001498 "CalDAV REPORT drops calendar data")
(Continue reading)

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