Re: [SyncEvolution] syncevolution and a radicale caldev server
by Patrick Ohly
On Fri, 2012-02-17 at 15:14 +0100, Gregor Horvath wrote:
> Am Fri, 17 Feb 2012 11:12:52 +0100
> schrieb Patrick Ohly <patrick.ohly(a)intel.com>:
>
> > On Tue, 2012-02-14 at 15:57 +0100, Patrick Ohly wrote:
> > > But as Radicale is an example where multiple databases are possible
> > > (in
> > > contrast to Google), it's worth spelling out explicitly how such a
> > > config can be created:
> >
> > [...]
> >
> > William, did this work?
> >
> > Perhaps you (or someone else) has the time to turn the instructions
> > into a proper HOWTO? I created a place holder Wiki page for it here:
> > http://syncevolution.org/wiki/synchronizing-radicale
> >
> >
William sent me some debug logs, but then ran out of time. So I've
installed Radicale myself and found an issue that'll break
SyncEvolution: items reported by the server include double slashes in
the path.
<multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
<response>
<href>/public_user/calendar/calendar_1//1234567890(a)dummy.ics</href>
^^
SyncEvolution will then use /1234567890(a)dummy.ics as path in future
requests, which Radicale rejects with either 404 or 401 errors.
I'll work around that in SyncEvolution. I'm not sure whether there is a
solution with 1.2.2.
Have you considered Calypso (http://keithp.com/blogs/calypso/)? I don't
know yet whether it works with SyncEvolution; if there is interest, then
I will try it.
> I am trying to do the same thing (with one calender to start with)
> N900 <-> radicale but it did not work, because it seems the Maemo
> calendar is not found:
>
> http://pastebin.com/huMXDsEx
>
> What I am doing wrong?
You have additional spaces after your \ character. The slash must be at
the end of each line.
--
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.
6 years
[SyncEvolution] Calendar entries not syncing when date changed
by Jane Atkinson
>From time to time, I need to change the date, but not the time, of an
appointment. When I do this, the change is not being propagated to the
client. If I change the time of an appointment, the change is propagated
correctly.
I'm running syncevolution 1.3.99.7 on Xubuntu 14.04 (pre-release). The
client is a Nokia E63. The configuration type is webdav. Evolution is
not installed on this system.
I'm not sure exactly when this started happening, but I think it's of
recent origin. No configuration options have been changed for a long time.
Please let me know where to send the logs. Also, any further tests I can do.
Regards
Jane Atkinson
6 years, 11 months
[SyncEvolution] Syncing with webdav in a different evolution database
by Renato Filho
Hi guys,
I wrote a small daemon that integrates syncevolution DBUS and online
accounts. Basically it listen for online account
creation/enable/removal and setup the sync configuration on
syncevolution.
This is working fine sync with default evolution address book, but I
want to create one addressbook for each account, right now I am using
eds api for that (I am not sure if syncevolution does that).
But the problem cames when configuring syncevolution to sync with
different database. I am not sure how to do that right now I am
creating the config in this way:
session = server.StartSessionWithFlags("onlineaccount-1". ["all-configs"])
//config target
config = session.getConfig("WebDAV", true);
config[""]["syncURL"] = "https://www.googleapis.com/.well-known/carddav"
config[""]["username"] = "uoa:1,google-carddav"
config[""]["consumerReady"] = "0"
config[""]["dumpData"] = "0"
config[""]["printChanges"] = "0"
config[""]["PeerName"] = "onlineaccount-1"
session.SetNamedConfig("target-config@onlineaccount-1")
//config sync
config = session->getConfig("SyncEvolution_Client", true)
// config server side
config[""]["syncURL"] = "local://@onlineaccount-1"
config[""]["username"] = ""
config[""]["password"] = ""
config[""]["dumpData"] = "0"
config[""]["printChanges"] = "0"
// remove unecessary sources
delete config["source/calendar"]
delete config["source/todo"]
delete config["source/memo"]
session.saveConfig("onlineaccount-1", config)
session.deatach()
// sync
session = server.StartSession("onlineaccount-1")
session.sync("", ("addressbook", "slow"))
This works fine but stores the contacts on default database in evolution.
I want to change that to store each account in a different database, I
tried several configurations changes but does not works.
I tried to set the sync config database like:
config["source/addressbook"]["backend"] = "addressbook"
config["source/addressbook"]["database"] = "logion(a)gmail.com"
but his cause the default source config
(.config/syncevolution/sources/addressbook.ini) to get update and does
not work for multiple accounts.
I tried add a new source on sync config but the source is not created.
Something like:
config["source/onlineaccount"]["backend"] = "addressbook"
config["source/onlineaccount"]["database"] = "logion(a)gmail.com"
I am really lost here. Looks like I need to create a source and link
that with my server database but I do not know how to do that with
dbus api.
Thanks
Renato
6 years, 12 months
[SyncEvolution] Activesync backend use of username property
by Graham Cobb
Now that I am beginning to understand the use of the context and the
difference between source and sync configs better, I tried issuing the
following command:
syncevolution --configure --template none \
username=my.email(a)example.com backend=eas-events \
database=Calendar @Exchange calendar
I think that ought to have worked, because I am configuring a source
(which could be shared by several peers later).
However, it fails:
[ERROR] error code from SyncEvolution fatal error (local, status 10500):
per-peer (unshared) properties not allowed: username
Of course, the reason is because we are abusing the username, which is a
sync property, to do the job of a source property (to specify the
account for activesyncd). Should we change the eas backend to use (for
example) databaseUser to specify the account?
Or am I still confused (quite likely)? I must admit that I still don't
understand how the special peer "target-config" works!
Graham
PS. I am at MWC next week, so I may have trouble responding to email.
7 years
[SyncEvolution] SyncEvolution 1.4 released
by Patrick Ohly
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 MeeGo and for Maemo (Nokia N900, N9).
About 1.4
=========
The 1.4 release of SyncEvolution replaces 1.3.2 as the stable, supported
release. Changes since that release are summarized in this section. For
changes since the last pre-release see below.
1.4 is the first stable version with the in-vehicle infotainment (IVI)
PIM Manager included. GENIVI Diagnostic Log and Trace (DLT) is also
supported. For more information about this aspect of SyncEvolution, see
the PBAP and PIM entries in the 1.3.99 release notes and
https://syncevolution.org/blogs/pohly/2013/pim-its-all-about-contacts
The biggest change for normal Linux users is Google CalDAV/CardDAV
authentication with OAuth2. These are the open protocol that Google
currently supports and thus the recommended way of syncing with
Google, replacing ActiveSync and SyncML (both no longer available to
all Google customers).
Support for Google CardDAV is new. Like Evolution, SyncEvolution does
not yet support some of the advanced features of the server, in
particular custom labels for phone numbers, emails and
addresses. Likewise, some client properties are not supported by the
server: CALURI, CATEGORIES, FBURL, GEO and ROLE are not supported. Of
ORG, only the first two components are supported. Currently,
properties not supported by one side get lost in a full roundtrip
sync. Instant Messaging information is supported by both sides with
different vCard extensions; the server stores these extensions without
showing the information, while SyncEvolution drops the data sent by
the server.
SyncEvolution depends on external components for OAuth2. It can be
compiled to use gSSO [1] or GNOME Online Accounts [2]. The latter is
enabled in binaries from syncevolution.org. GNOME Online Accounts >=
3.10 works out of the box for CalDAV and CardDAV. 3.8 is guaranteed to
work for CardDAV and may also work for CalDAV, if the Linux
distribution ships a patched version (like Debian Wheezy does). If it
does not, then GNOME Online Accounts 3.8 binary can be patched to also
support CalDAV, see [2]. Anything older than 3.8 does not
work. Support for Ubuntu Online Accounts is available when compiling
from source. For setup instructions see these READMEs.
[1] https://01.org/gsso and
http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backend...
[2] http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backend...
Binary packages of 1.4 on syncevolution.org have enhanced support for
recent distros. They now work with EDS >= 3.6 *and* < 3.6. Distros
with libical1 like Ubuntu Saucy are also supported.
The HTTP server became better at handling message resends when the
server is slow with processing a message. The server is able to keep a
sync session alive while loading the initial data set by sending
acknowledgment replies before the client times out.
Some issues in CalDAV, WebDAV and SyncML were fixed.
Graham R. Cobb contributed several patches for enhancing ActiveSync
support and making it work with Exchange 2010. Guido Günther provided
some patches addressing problems when compiling SyncEvolution for
Maemo.
Details:
--------
* D-Bus server: support DLT (FDO #66769)
Diagnostic Log and Trace (DLT) manages a sequence of log messages,
with remote controllable level of detail. SyncEvolution optionally
(can be chosen at compile time and again at runtime) uses DLT
instead of its own syncevolution-log.html files. See README-DLT.rst
for more information.
To use the feature, configure SyncEvolution with
"--enable-dbus-server=--dlt --no-syslog"
* D-Bus server: fix abort when mixing auto-sync and manual operations (FDO #73562)
When enabling auto-sync for a config and then accessing or syncing the
config manually via the command line tool, the server would abort at
the time when the auto-sync was originally scheduled.
* D-Bus server: accept WBXML with charset in incoming connections
A user reported via email that the Nokia 515 sends
'application/vnd.syncml+wbxml; charset=UTF-8' as type of its messages
this tripped up the syncevo-http-server, leading to:
[ERROR] syncevo-dbus-server: /org/syncevolution/Server: message type
'application/vnd.syncml+wbxml; charset=UTF-8' not supported for starting
a sync
* D-Bus server: command line options for controlling output and startup
The system log is used by default now. New command line options can be
used to change this:
-d, --duration=seconds/'unlimited' Shut down automatically
when idle for this duration (default 300 seconds)
-v, --verbosity=level Choose amount of output, 0 = no output,
1 = errors, 2 = info, 3 = debug; default is 1.
--dbus-verbosity=level Choose amount of output via D-Bus signals, 0 = no output,
1 = errors, 2 = info, 3 = debug; default is 2.
-o, --stdout Enable printing to stdout (result of operations)
and stderr (errors/info/debug).
-s, --no-syslog Disable printing to syslog.
-p, --start-pim Activate the PIM Manager (= unified address book)
immediately.
* D-Bus: missing out parameters in D-Bus introspection XML (FDO #57292)
The problem was in the C++ D-Bus binding. If the method that gets bound
to D-Bus returns a value, that value was ignored in the signature:
int foo() => no out parameter
It works when the method was declared as having a retval:
void foo (int &result) => integer out parameter
This problem existed for both the libdbus and the GIO D-Bus
bindings. In SyncEvolution it affected methods like GetVersions().
* D-Bus server: avoid progress outside of 0-100% range
For example in the new TestLocalCache.testItemDelete100, the
percentage value in the ProgressChanged signal become larger
than 100 and then revert to 100 at the end of the sync.
Seems the underlying calculation is faulty or simply inaccurate.
This is not fixed. Instead the result is just clipped to the valid
range.
* sync: less verbose output, shorter runtime
For each incoming change, one INFO line with "received x[/out of y]"
was printed, immediately followed by another line with total counts
"added x, updated y, removed z". For each outgoing change, a "sent
x[/out of y]" was printed.
In addition, these changes were forwarded to the D-Bus server where a
"percent complete" was calculated and broadcasted to clients. All of
that caused a very high overhead for every single change, even if the
actual logging was off. The syncevo-dbus-server was constantly
consuming CPU time during a sync when it should have been mostly idle.
To avoid this overhead, the updated received/sent numbers that come
from the Synthesis engine are now cached and only processed when done
with a SyncML message or some other event happens (whatever happens
first).
To keep the implementation simple, the "added x, updated y, removed z"
information is ignored completely and no longer appears in the output.
* command line: implement --create/remove-database
Creating a database is only possible with a chosen name. The UID is
chosen automatically by the storage. Only implemented in the EDS
backend.
* command line: execute --export and --print-items while the source is still reading
Instead of reading all item IDs, then iterating over them, process
each new ID as soon as it is available. With sources that support
incremental reading (only the PBAP source at the moment) that provides
output sooner and is a bit more memory efficient.
* command line: recover from slow sync with new sync modes
The error message for an unexpected slow sync still mentioned
the old and obsolete "refresh-from-client/server" sync modes.
Better mention "refresh-from-local/remote".
* command line: show backend error when listing databases fails
The command line swallowed errors thrown by the backend while listing
databases. Instead it just showed "<backend name>: backend failed". The goal
was to not distract users who accidentally access a non-functional backend.
But the result is that operations like --configure or --print-databases could
fail without giving the user any hint about the root cause of the issue.
Now the error explanation in all its gory details is included.
For example, not having activesyncd running leads to:
INFO] eas_contact: backend failed: fetching folder list:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.meego.activesyncd was not provided by any .service files
And running activesyncd without the necessary gconf keys shows up as:
[INFO] eas_contact: backend failed: fetching folder list:
GDBus.Error:org.meego.activesyncd.Error.AccountNotFound: Failed to find
account [syncevolution(a)lists.intel.com]
* password handling: fix usage of GNOME Keyring and KWallet (FDO #66110)
When clients like the GTK sync-ui stored a password, it was always
stored as plain text in the config.ini file by the
syncevo-dbus-server. The necessary code for redirecting the password
storage in a keyring (GNOME or KWallet) simply wasn't called in that
case.
The command line tool, even when using the D-Bus server to run the
operation, had the necessary code active and thus was not affected.
Now all SyncEvolution components use the same default: use safe
password storage if either GNOME Keyring or KWallet were enabled
during compilation, don't use it if not.
Fixing this revealed other problems, like not being able to store
certain passwords that lacked the necessary lookup criteria (like
syncURL and/or username). To address this, the lookup criteria where
extended and a new check was added to avoid accidentally removing
other passwords. As a result, it may be possible that SyncEvolution
no longer finds passwords that were stored with older versions of
SyncEvolution. In such a case the passwords must be set again.
* GNOME: clean up keyring access and require libgnome-keyring >= 2.20
The updated error messages now always include information about the
password and libgnome-keyring error texts.
A workaround is used for the "Error communicating with
gnome-keyring-daemon" problem that started to appear fairly
frequently in the automated testing once the keyring was actually
used. The problem shows up with some additional debug messages:
Gkr: received an invalid, unencryptable, or non-utf8 secret
Gkr: call to daemon returned an invalid response: (null).(null)()
It seems that sometimes setting up a session with GNOME keyring
fails such that all further communication leads to decoding problem.
There is an internal method to reset the session, but it cannot be
called directly. As a workaround, fake the death of the GNOME
keyring daemon and thus trigger a reconnect when retrying the GNOME
keyring access. This is done by sending a D-Bus message, which will
also affect other clients of GNOME keyring, but hopefully without
user-visible effects.
* config: enhanced password handling
It is possible to configure a plain username/password combination
once in SyncEvolution and then use references to it in other
configurations, instead of having to set (and update) the
credentials in different places. This is useful in particular with
WebDAV, where credentials had to be repeated several times (target
config, in each database when used as part of SyncML) or when using
a service which requires several configs (Google via SyncML and
CalDAV).
To use this, create a sync config for a normal peer or a dedicated
config just for the credentials, with "username/password/syncURL"
set. The "syncURL" must be set to something identifying the peer if
GNOME Keyring is used for the password storage.
Then set "username", "databaseUser" and "proxyUser" properties to
"id:<name of config with credentials>" and all read and write access
to those properties will be redirected by SyncEvolution into that
other configuration. This even works in the GTK UI.
For user names which contain colons, the new "user:<user name>" format
must be used. Strings without colons are assumed to be normal user
names, so most old configurations should continue to work.
* signon: new backend using libgsignond-glib + libaccounts-glib
The code works with gSSO (https://01.org/gsso) and Ubuntu Online
Accounts.
* GOA: get OAuth2 tokens out of GNOME Online Accounts
"username = goa:..." selects an account in GOA and retrieves the
OAuth2 token from that.
* WebDAV: support OAuth2
If given an authentication configuration which can handle OAuth2,
then OAuth2 is used instead of plain username/password
authentication.
* WebDAV: support Google CardDAV, break Yahoo
Google CardDAV has one peculiarity: it renames new contacts during PUT without
returning the new path to the client. See also
http://lists.calconnect.org/pipermail/caldeveloper-l/2013-July/000524.html
SyncEvolution already had a workaround for that (PROPGET on old path, extract
new path from response) which happened to work. This workaround was originally
added for Yahoo, which sometimes merges contacts into existing ones. In
contrast to Yahoo, Google really seems to create new items.
Without some server specific hacks, the client cannot tell what happened.
Because Google is currently supported and Yahoo is not, let's change the
hard-coded behavior to "renamed items are new".
* WebDAV: started testing with owndrive.com = OwnCloud
* WebDAV: avoid segfault during collection lookup
Avoid referencing pathProps->second when the set of paths that
PROPFINDs returns is empty. Apparently this can happen in combination
with Calypso.
* CalDAV: more workarounds for Google CalDAV + unique IDs
Google became even more strict about checking REV. Tests which
reused a UID after deleting the original item started to fail sometime
since middle of December 2012.
* CalDAV: work around Google server regression (undeclared namespace prefix in XML)
Google CalDAV for a while (December 2012 till January 2013) sent
invalid XML back when asked to include CardDAV properties in a
PROPFIND. This got rejected in the XML parser, which prevents
syncing calendar data:
Neon error code 1: XML parse error at line 55: undeclared namespace prefix
In the meantime Google fixed the issue in response to a bug report
via email. But the workaround, only asking for the properties which
are really needed, still makes sense and thus is kept.
* WebDAV: auto-discovery fix
With Google Contact + CardDAV the auto-discovery failed after
finding the default address book, without reporting that result.
* WebDAV: don't send Basic Auth via http proactively (FDO #57248)
Sending basic authentication headers via http is insecure. Only do
it proactively when the connection is encrypted and thus protects
the information or when the server explicitly asks for it.
* file backend: sub-second mod time stamps
Change tracking in the file backend used to be based on the
modification time in seconds. When running many syncs quickly (as in
testing), that can lead to changes not being detected when they happen
within a second. Now the file backend also includes the sub-second part of the
modification time stamp, if available.
This change is relevant when upgrading SyncEvolution: most of the
items will be considered "updated" once during the first sync after
the upgrade (or a downgrade) because the revision strings get
calculated differently.
* GTK UI: fixed two crashes - running a sync with no service selected
and a 64 bit pointer problem recently discovered by Tino Keitel when
compiling the Debian package with -fPIE.
* packaging: compatible with EDS up to and including 3.10 and both
libical.so.0 and libical.so.1
The binary packages now contain different versions of syncecal.so
and syncebooks.so to cover different combinations of EDS and libical.
* libical: compatibiliy mode for libical.so.0 and libical.so.1
libical 1.0 broke the ABI, leading to libical.so.1. The only relevant change
for SyncEvolution is the renumbering of ICAL_*_PROPERTY enum values. We can
adapt to that change at runtime, which allows us to compile once with
libical.so.0, then patch executables or use dynamic loading to run with the
more recent libical.so.1 if we add 1 to the known constants.
* packaging: fix rpm (FDO #73347)
After installing the syncevolution.org rpm on OpenSUSE,
SyncEvolution was not starting because its shared libraries were not
found unless "ldconfig" was called manually. Now the package does
that automatically.
* packaging: fix description
The syncevolution-bundle description of both rpm and deb
packagesaccidentally used the same description as
syncevolution-evolution.
* glib: fix double-free of source tags
glib 2.39.0 (aka GNOME 3.10) as found in Ubuntu Trusty introduces
warnings when g_source_remove() is passed an unknown tag. SyncEvolution
did this in two cases: in both, the source callback returned false and thus
caused the source to be removed by the caller. In that case, the explicit
g_source_remove() is redundant and must be avoided.
Such a call is faulty and might accidentally remove a new source with the same
tag (unlikely though, given that tags seem to get assigned incrementally).
The only noticable effect were additional error messages with different
numbers:
[ERROR] GLib: Source ID 9 was not found when attempting to remove it
* EDS: fix compile problem with boost and EDS > 3.36
This fixes the following problem, seen with Boost 1.53.0 on altlinux
when compiling for EDS >= 3.6:
/usr/include/boost/smart_ptr/shared_ptr.hpp: In instantiation of 'typename boost::detail::sp_array_access<T>::type boost::shared_ptr<T>::operator[](std::ptrdiff_t) const [with T = char*; typename boost::detail::sp_array_access<T>::type = void; std::ptrdiff_t = long int]':
src/backends/evolution/EvolutionSyncSource.cpp:163:38: required from here
/usr/include/boost/smart_ptr/shared_ptr.hpp:663:22: error: return-statement with a value, in function returning 'void' [-fpermissive]
make[2]: *** [src/backends/evolution/src_backends_evolution_syncecal_la-EvolutionSyncSource.lo]
* EDS contacts: avoid unnecessary DB writes during slow sync
Traditionally, contacts were modified shortly before writing into EDS
to match with Evolution expectations (must have N, only one CELL TEL,
VOICE flag must be set). During a slow sync, the engine compare the
modified contacts with the unmodified, incoming one. This led to
mismatches and/or merge operations which end up not changing anything
in the DB because the only difference would be removed again before
writing.
* EDS contacts: read-ahead cache
Performance is improved by requesting multiple contacts at once and
overlapping reading with processing. On a fast system (SSD, CPU fast
enough to not be the limiting factor), testpim.py's testSync takes 8
seconds for a "match" sync where 1000 contacts get loaded and compared
against the same set of contacts. Read-ahead with only 1 contact per
query speeds that up to 6.7s due to overlapping IO and
processing. Read-ahead with the default 50 contacts per query takes
5.5s. It does not get much faster with larger queries.
* PBAP: add support for obexd 0.47, 0.48 and Bluez 5
obexd 0.48 is almost the same as obexd 0.47, except that it dropped
the SetFilter and SetFormat methods in favor of passing a Bluex 5-style
filter parameter to PullAll.
* PBAP: various enhancements for efficient caching of contacts
* HTTP server: handle message resends
If a client gave up waiting for the server's response and resent its message
while the server was still processing the message, syncing failed with
"protocol error: already processing a message" raised by the
syncevo-dbus-server because it wasn't prepared to handle that situation.
The right place to handle this is inside the syncevo-http-server, because it
depends on the protocol (HTTP in this case) whether resending is valid or
not. It handles that now by tracking the message that is currently in
processing and matching it against each new message. If it matches, the new
request replaces the obsolete one without sending the message again to
syncevo-dbus-server. When syncevo-dbus-server replies to the old message, the
reply is used to finish the newer request.
* engine: prevent timeouts in HTTP server mode
HTTP SyncML clients give up after a certain timeout (SyncEvolution
after RetryDuration = 5 minutes by default, Nokia e51 after 15
minutes) when the server fails to respond.
This can happen with SyncEvolution as server when it uses a slow
storage with many items, for example via WebDAV. In the case of slow
session startup, multithreading is now used to run the storage
initializing in parallel to sending regular "keep-alive" SyncML
replies to the client.
By default, these replies are sent every 2 minutes. This can be
configured with another extensions of the SyncMLVersion property:
SyncMLVersion = REQUESTMAXTIME=5m
Other modes do not use multithreading by default, but it can be
enabled by setting REQUESTMAXTIME explicitly. It can be disabled
by setting the time to zero.
The new feature depends on a libsynthesis with multithreading enabled
and glib >= 2.32.0, which is necessary to make SyncEvolution itself
thread-safe. With an older glib, multithreading is disabled, but can
be enabled as a stop-gap measure by setting REQUESTMAXTIME explicitly.
* Various testing and stability enhancements. SyncEvolution had to
be made thread-safe for the HTTP timeout prevention.
* Nokia: always add TYPE=INTERNET to EMAIL (FDO #61784)
Without the explicit TYPE=INTERNET, email addresses sent to a Nokia
e51 were not shown by the phone and even got lost eventually (when
syncing back).
This commit ensures that the type is set for all emails sent to any
Nokia phone, because there may be other phones which need it and
phones which don't, shouldn't mind. This was spot-checked with a N97
mini, which works fine with and without the INTERNET type.
This behavior can be disabled again for specific Nokia phones by
adding a remote rule which sets the addInternetEmail session variable
to FALSE again.
Non-Nokia phones can enable the feature in a similar way, by setting
the variable to TRUE.
* SyncML: config option for broken peers
Some peers have problems with meta data (CtCap, old Nokia phones)
and the sync mode extensions required for advertising the restart
capability (Oracle Beehive). The default in SyncEvolution is to
advertise the capability, so manual configuration is necessary when
working with a peer that fails in that mode.
Because the problem occurs when SyncEvolution contacts the peers
before it gets the device information from the peer, dynamic rules
based on the peer identifiers cannot be used. Instead the local config
must already disable these extra features in advance.
The "SyncMLVersion" property gets extended for this. Instead of just
"SyncMLVersion = 1.0" (as before) it now becomes possible to say
"SyncMLVersion = 1.0, noctcap, norestart".
"noctcap" disables sending CtCap. "norestart" disables the sync mode
extensions and thus doing multiple sync cycles in the same session
(used between SyncEvolution instances in some cases to get client and
server into sync in one session).
Both keywords are case-insensitive. There's no error checking for
typos, so beware!
The "SyncMLVersion" property was chosen because it was already in use
for configuring SyncML compatibility aspects and adding a new property
would have been harder.
* ActiveSync: added support for specifying folder names
Previously, the database field was interpreted as a Collection ID. This adds
logic to allow the database to be interpreted as a folder path. The logic is:
1) If the database is an empty string, pass it through (this is the most
common case as it is interpreted as "use the default folder for the
source type").
2) If the database matches a Collection ID, use the ID (this is the same as
the previous behaviour).
3) If the database matches a folder path name, with an optional leading "/",
use the Collection ID for the matching folder.
4) Otherwise, force a FolderSync to get the latest folder changes from the
server and repeat steps 2 and 3
5) If still no match, throw an error.
* ActiveSync: support for listing databases
Now --print-databases scans folders on the ActiveSync server and
shows suitable folders for the ActiveSync backends instead of the
previous, hard-coded help text.
Invoking --print-databases can be used as a workaround for
"SyncFolder error: Invalid synchronization key" errors. A better
solution would be to do that automatically, but there was no time
to implement that. See FDO #61869 and "[SyncEvolution] Activesync server losing state"
http://thread.gmane.org/gmane.comp.mobile.syncevolution/4295
* SyncML: workarounds for broken peers
Some peers have problems with meta data (CtCap, old Nokia phones) and
the sync mode extensions required for advertising the restart
capability (Oracle Beehive).
Because the problem occurs when SyncEvolution contacts the peers
before it gets the device information from the peer, dynamic rules
based on the peer identifiers cannot be used. Instead the local config
must already disable these extra features in advance.
The "SyncMLVersion" property gets extended for this. Instead of just
"SyncMLVersion = 1.0" (as before) it now becomes possible to say
"SyncMLVersion = 1.0, noctcap, norestart".
"noctcap" disables sending CtCap. "norestart" disables the sync mode
extensions and thus doing multiple sync cycles in the same session
(used between SyncEvolution instances in some cases to get client and
server into sync in one session).
Both keywords are case-insensitive. There's no error checking for
typos, so beware!
The "SyncMLVersion" property was chosen because it was already in use
for configuring SyncML compatibility aspects and adding a new property
would have been harder.
* engine: local cache sync mode
This patch introduces support for true one-way syncing ("caching"):
the local datastore is meant to be an exact copy of the data on the
remote side. The assumption is that no modifications are ever made
locally outside of syncing. This is different from one-way sync modes,
which allows local changes and only temporarily disables sending them
to the remote side.
Another goal of the new mode is to avoid data writes as much as
possible.
This new mode only works on the server side of a sync, where the
engine has enough control over the data flow. Setting "sync" to:
- "local-cache-incremental" will do an incremental sync (if possible)
or a slow sync (otherwise). This is usually the right mode to use,
and thus has "local-cache" as alias.
- "local-cache-slow" will always do a slow sync. Useful for
debugging or after (accidentally) making changes on the local side.
An incremental sync will ignore such changes because they are not
meant to happen, aren't checked for to improve performance and
thus will leave client and server out-of-sync!
Both modes are recorded in the sync report of the local side. The
target side is the client and records the normal "two-way" or "slow"
sync modes.
With the current SyncEvolution contact field list, first, middle and
last name are used to find matches for contacts. For events, tasks
and memos, time, summary and description are used.
* Minor memory leak fix when using GDBus GIO: GDBusMethodInfo
Also depends on a glib fix, see https://bugzilla.gnome.org/show_bug.cgi?id=695376
* build fixes
Avoid -lrt in make dependencies. Add missing pcre libs to
syncevo-dbus-server. sqlite backend needs "#include <stdio.h>"
(patch from Mario Kicherer).
* autotools: fix temp file vulnerability during compilation (CVE-2014-1639)
We must use the temporary file that was created for us securily, not
a temp file named after that file. This caused a temp file vulnerability
and the real temporary files were not deleted by the script.
* workarounds for warnings from g++ 4.5
Upgrading from releases <= 1.3.99.4:
------------------------------------
If the value of "username/databaseUser/proxyUser" contains a colon,
the "user:" prefix must be added to the value, to continue treating it
like a plain user name and not some reference to an unknown identity
provider (like "id:", "goa:", "signon:", etc.).
The lookup of passwords in GNOME Keyring was updated slightly in
1.3.99.5. It may be necessary to set passwords anew if the old one is
no longer found.
Upgrading from release 1.2.x:
-----------------------------
The sync format of existing configurations for Mobical (aka Everdroid)
must be updated manually, because the server has encoding problems when
using vCard 3.0 (now the default for Evolution contacts):
syncevolution --configure \
syncFormat=text/x-vcard \
mobical addressbook
The Funambol template explicitly enables usage of the
"refresh-from-server" sync mode to avoid getting throttled with 417
'retry later' errors. The same must be added to existing configs
manually:
syncevolution --configure \
enableRefreshSync=TRUE \
funambol
Upgrading from releases before 1.2:
-----------------------------------
Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. Releases >= 1.2
automatically migrates configurations. The old configurations
will still be available (see "syncevolution --print-configs") but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.
SyncEvolution 1.3.99.7 -> 1.4
=============================
Compared to the pre-release, 1.4 mostly just enhanced the testing.
Compatibility with GNOME 3.10 and a glib-related issue that existed
almost forever without causing obvious problems were
fixed. syncevolution.org binaries now finally work with distros using
libical.so.1 (for example, Ubuntu Saucy and Trusty).
Details:
* autotools: fix temp file vulnerability during compilation (CVE-2014-1639)
We must use the temporary file that was created for us securily, not
a temp file named after that file. This caused a temp file vulnerability
and the real temporary files were not deleted by the script.
* glib: fix double-free of source tags
glib 2.39.0 (aka GNOME 3.10) as found in Ubuntu Trusty introduces
warnings when g_source_remove() is passed an unknown tag. SyncEvolution
did this in two cases: in both, the source callback returned false and thus
caused the source to be removed by the caller. In that case, the explicit
g_source_remove() is redundant and must be avoided.
Such a call is faulty and might accidentally remove a new source with the same
tag (unlikely though, given that tags seem to get assigned incrementally).
The only noticable effect were additional error messages with different
numbers:
[ERROR] GLib: Source ID 9 was not found when attempting to remove it
* libical: compatibiliy mode for libical.so.0 and libical.so.1
libical 1.0 broke the ABI, leading to libical.so.1. The only relevant change
for SyncEvolution is the renumbering of ICAL_*_PROPERTY enum values. We can
adapt to that change at runtime, which allows us to compile once with
libical.so.0, then patch executables or use dynamic loading to run with the
more recent libical.so.1 if we add 1 to the known constants.
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2014/syncevolution-14-released
Source code bundles for users are available in
http://downloads.syncevolution.org/syncevolution/sources
and the original source is in the git repositories
http://cgit.freedesktop.org/SyncEvolution/
i386, lpia and amd64 binaries for Debian-based distributions are
available via the "stable" syncevolution.org repository. Add the
following entry to your /apt/source.list:
deb http://downloads.syncevolution.org/apt stable main
Then install "syncevolution-evolution", "syncevolution-kde" and/or
"syncevolution-activesync".
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 10.04 LTS (Lucid), except for ActiveSync binaries which were
compiled for Debian Wheezy, Ubuntu Saucy and Ubuntu Trusty. The packages
mentioned above are meta-packages which pull in suitable packages
matching the distro during installation.
Older distributions like Debian 4.0 (Etch) can no longer be supported
with precompiled binaries because of missing libraries, but the source
still compiles when not enabling the GUI (the default).
The same binaries are also available as .tar.gz and .rpm archives in
http://downloads.syncevolution.org/syncevolution/. In contrast
to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the
content must be moved to /usr, because several files would not be found
otherwise.
After installation, follow the
http://syncevolution.org/documentation/getting-started steps.
--
Patrick Ohly, on behalf of everyone who has helped
to make SyncEvolution possible:
http://syncevolution.org/about/contributors
7 years
[SyncEvolution] Google Contacts vCard Incompatibility (cardDAV)
by Sunny Sigara
Hi,
I was trying to sync evolution contacts with Google using syncevolution
on saucy.
1) First I created a single contact (i.e. Tony Stark) in evolution. Now
when I try to sync it syncs but not all the vcard fields.
For example, it completely ignores instant messaging fields.
LOG:
@default data changes to be applied during synchronization:
*** @default/gadb ***
after last sync | current data
removed since last sync <
> added since last sync
-------------------------------------------------------------------------------
> BEGIN:VCARD
> N:Stark;Tony
>
EMAIL;TYPE=HOME;X-EVOLUTION-UI-SLOT=2
> :tony.stark@ironman.com
> FN:Tony Stark
> VERSION:3.0
> X-EVOLUTION-FILE-AS:Stark\,
Tony
>
X-JABBER;TYPE=HOME;X-EVOLUTION-UI-SLO
> T=2:tony.stark@jabber.org
>
X-SKYPE;TYPE=HOME;X-EVOLUTION-UI-SLOT
> =1:tony_stark
>
X-TWITTER;TYPE=HOME;X-EVOLUTION-UI-SL
> OT=3:ironman
> END:VCARD
-------------------------------------------------------------------------------
[INFO] @default/gadb: started
[INFO] @default/gadb: sent 1
[INFO @gcon] @gcon/gadb: started
[INFO @gcon] adding "Tony Stark"
[INFO @gcon] @gcon/gadb: received 1/1
[INFO] @default/gadb: normal sync done successfully
[INFO @gcon] @gcon/gadb: normal sync done successfully
Synchronization successful.
2) If I add a msn address in google-contacts & then run the sync, it
creates a duplicate in evolution/eds.
And even the duplicate doesn't have msn instant-messaging address.
LOG:
Data modified @default during synchronization:
*** @default/gadb ***
before sync | after sync
removed during sync <
> added during sync
-------------------------------------------------------------------------------
> BEGIN:VCARD
> N:Stark;Tony
>
EMAIL;TYPE=HOME:tony.stark@ironman.co
> m
> FN:Tony Stark
> VERSION:3.0
> X-EVOLUTION-FILE-AS:Stark\,
Tony
>
X-JABBER;X-EVOLUTION-UI-SLOT=2:tony.s
> tark(a)jabber.org
>
X-SKYPE;X-EVOLUTION-UI-SLOT=1:tony_st
> ark
>
X-TWITTER;TYPE=HOME;X-EVOLUTION-UI-SL
> OT=3:ironman
> END:VCARD
-------------------------------------------------------------------------------
3) If I create a new contact in google then sync, again it doesn't sync
instant messaging-fields.
Contact created in google (exported as vcf):
BEGIN:VCARD
VERSION:3.0
FN:Bruce Banner
N:Banner;Bruce;;;
EMAIL;TYPE=INTERNET;TYPE=HOME:bruce\,banner@gammalab.org
X-JABBER:bruce.banner@jabber.org
X-SKYPE:bruce_banner
TEL;TYPE=CELL:9999555555
END:VCARD
LOG:
Data modified @default during synchronization:
*** @default/gadb ***
before sync | after sync
removed during sync <
> added during sync
-------------------------------------------------------------------------------
> BEGIN:VCARD
> N:Banner;Bruce
>
EMAIL;TYPE=HOME:bruce\,banner@gammala
> b.org
> FN:Bruce Banner
> TEL;TYPE=CELL:9999555555
> VERSION:3.0
> X-EVOLUTION-FILE-AS:Banner\,
Bruce
> item1.X-ABLabel:Other
> item2.X-ABLabel:Other
> END:VCARD
-------------------------------------------------------------------------------
4) If I change anything on "Bruce Banner" locally, log says changes
added but doesn't appear in Google(?).
LOG:
screenshot: http://i.imgur.com/zSnR59w.png
While I don't expect to sync evolution related vcard properties (like
X-Evolution-Callback, X-Evolution-Radio), It should able to
sync normal vcard extensions.
Thanks.
7 years
[SyncEvolution] Syncevlution --import could not import all events for some calendars(?)
by Sunny Sigara
Hello Patrick,
I am trying to import a google holiday calendar with "syncevolution
--import function.
While it can import all events from a evolution-ical file just fine, it
fails to do so for google calendar. I am using syncevolution-1.3.2 on
saucy.
'''
cd ~/Desktop/calendar
wget
https://www.google.com/calendar/ical/en.indian%23holiday%40group.v.calend...
syncevolution --configure backend=evolution-calendar database=Holidays
@default hdcal
syncevolution --import ~/Desktop/calendar/basic.ics @default hdcal
#0: 20140204_60o30d36cgo30c1g60o30dr4ck%40google%2ecom-rid
'''
As it is visible from the output, it could only import one single event.
If I manually import all events using evolution & then export like this:
"syncevolution --export calendar.ics backend=evolution-calendar
database=Holidays"
& then try to import.....it imports all events properly. Only for
google holidays(& some other) calendar it can import only a single
event.
Here is the holiday-ical-file: http://paste.ubuntu.com/6927791/
7 years
[SyncEvolution] ActiveSync binaries (was: Re: Syncing two servers)
by Patrick Ohly
On Mon, 2014-02-03 at 08:09 +0100, Patrick Ohly wrote:
> On Mon, 2014-02-03 at 00:35 +0100, Emiliano Heyns wrote:
> > OK, I just saw 1.3.99.7 roll in (yay!), but when I try to install
> > activesyncd and syncevolution-activesync I get:
> >
> >
> > sudo aptitude install activesyncd syncevolution-activesync
> > The following NEW packages will be installed:
> > activesyncd{b} syncevolution-activesync
> > 0 packages upgraded, 2 newly installed, 0 to remove and 8 not
> > upgraded.
> > Need to get 2,120 kB of archives. After unpacking 8,962 kB will be
> > used.
> > The following packages have unmet dependencies:
> > activesyncd : Depends: libebook-1.2-13 which is a virtual package.
> > Depends: libical0 which is a virtual package.
>
> activesyncd has hard dependencies on specific EDS versions, in this case
> EDS < 3.6. I wasn't planning to change that. What I fixed was the
> installation of SyncEvolution itself, for non-ActiveSync usage.
>
> I guess I could try to compile activesyncd multiple times, on different
> platforms.
SyncEvolution 1.4 will have activesyncd-wheezy/saucy/trusty and
syncevolution-activesync-wheezy/saucy/trusty .deb/.rpm/.tar.gz. In
addition, the apt repo also has meta activesyncd and
syncevolution-activesync packages which causes "apt-get install
activesyncd syncevolution-activesync" to pull in a suitable real
package.
--
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.
7 years
[SyncEvolution] Synching my Nokia N900 does not work
by Jürgen Dankoweit
Hello to the list.
On my Smartphone Nokai N900 I use SyncEvolution 1.3 to sync my calenders
and addressbook.
But it does not work!
Everytime I enter
$ syncevolution --sync slw heimnetz_kal_berr
I get the following output
[INFO] @default/addressbook: inactive
[INFO] @default/contacts: inactive
[INFO] @default/memo: inactive
[INFO] @default/todo: inactive
[INFO @heimnetz_kal_berr] target side of local sync ready
[INFO @heimnetz_kal_berr] @heimnetz_kal_berr/addressbook: inactive
[INFO @heimnetz_kal_berr] @heimnetz_kal_berr/memo: inactive
[INFO @heimnetz_kal_berr] @heimnetz_kal_berr/todo: inactive
[INFO @heimnetz_kal_berr] @heimnetz_kal_berr/calendar: starting normal
sync from client (peer is server)
[INFO] @default/calendar: starting normal sync from client (peer is client)
[INFO] creating complete data backup of source calendar before sync
(enabled with dumpData and needed for printChanges)
@default data changes to be applied during synchronization:
*** @default/calendar ***
Comparison was impossible.
[INFO] @default/calendar: started
[INFO @heimnetz_kal_berr] @heimnetz_kal_berr/calendar: started
[INFO] @default/calendar: normal sync done successfully
[INFO @heimnetz_kal_berr] @heimnetz_kal_berr/calendar: normal sync done
successfully
Synchronization successful.
Changes applied during synchronization (@heimnetz_kal_berr):
+---------------|-----------------------|-----------------------|-CON-+
| | @heimnetz_kal_berr | @default | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| one-way-from-local, 0 KB sent by client, 0 KB received |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Mon Feb 10 15:33:00 2014, duration 0:02min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization successful.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @heimnetz_kal_berr | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| one-way-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 0 before sync, 0 after it |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Mon Feb 10 15:32:58 2014, duration 0:04min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Data modified @default during synchronization:
*** @default/calendar ***
Comparison was impossible.
And the Apache-LOG says:
x.x.x.x - juergen [10/Feb/2014:15:29:32 +0100] "REPORT
/cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303
x.x.x.x - juergen [10/Feb/2014:15:29:32 +0100] "PROPFIND
/cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303
x.x.x.x - juergen [10/Feb/2014:15:31:08 +0100] "REPORT
/cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303
x.x.x.x - juergen [10/Feb/2014:15:31:09 +0100] "PROPFIND
/cal.php/calendars/juergen/berrreisen/ HTTP/1.1" 200 303
My question: Why aren't there any datas transferred? I don't understand it.
Thanks for the answers in advance
Best regards
Juergen
7 years
