Re: [SyncEvolution] Sync broken after upgrade to syncevolution 1.2
by Patrick Ohly
On Fri, 2011-10-21 at 09:17 +1300, Irihapeti wrote:
> On 21/10/11 00:59, Patrick Ohly wrote:
> > But the concatenated XML config only includes VCALENDAR_OUTGOING_SCRIPT.
> > Can you check from where the command above takes 11calendar.xml?
> >
> > Do:
> > strace -e trace=open syncevolution \
> > --daemon=no \
> > 'your config name' 2>&1 | grep 11calendar
> >
> >
>
> Here's the output of the command:
>
> ja@ja-desktop:~$ strace -e trace=open syncevolution \
> > --daemon=no \
> > e63-viruses 2>&1 | grep 11calendar
> open("/usr/share/syncevolution/xml/datatypes/11calendar-profile.xml",
> O_RDONLY|O_LARGEFILE) = 6
> open("/home/ja/.config/syncevolution-xml/scripting/11calendar.xml",
> O_RDONLY|O_LARGEFILE) = 6
>
> I have been installing/upgrading from the debian stable repository for
> the last several upgrades.
>
> The custom file in ~/.config/syncevolution-xml looks like it might be
> the culprit.
Yes, that's it. Your own copy of the file is used instead of the more
recent (and extended) copy from /usr/share. Therefore the new required
macro is missing.
With hindsight I probably should have put the new macro into a separate
file. It is related to calendar data, but not the import/export mangling
done by the other two in 11calendar-profile.xml. A user might
legitimately replace those without caring about the compare script.
However, splitting into more files does not solve the general problem:
if a user replaces .xml files, he basically runs a patched version of
SyncEvolution and needs to take care to stay up-to-date.
For example, right now in master I found and fixed an issue in
11calendar-profile.xml/VCALENDAR_INCOMING_SCRIPT for vCalendar 1.0. This
may or not be relevant for you.
> It relates to a SyncEvolution mailing list thread "empty description set
> to summary", dated 22 December 2010. I set it up myself according to
> your instructions. It's worked with no side-effects with every prior
> release and I'd still like to have the event descriptions left empty if
> that's possible.
If I read that discussion right, then the change that you have in your
copy in your file is also in the 1.2 version of 11calendar.xml, so you
can remove your private copy and still have the desired behavior.
diff -c /home/ja/.config/syncevolution-xml/scripting/11calendar.xml \
/usr/share/syncevolution/xml/datatypes/11calendar-profile.xml
will tell you what the differences are.
--
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.
10 years, 6 months
[SyncEvolution] SyncEvolution 1.2 released
by Patrick Ohly
SyncEvolution 1.2 - now with CalDAV/CardDAV
===========================================
The major new feature of the 1.2 release is support for non-SyncML
protocols in general and CalDAV/CardDAV in particular. ActiveSync
support is in development and will be in 1.3. These protocols are
implemented as backends which are combined with other backends by
SyncEvolution in a so called "local sync". The GTK sync-ui does not
yet support configuring non-SyncML protocols. See the README.rst and
man page for more information on how to use the new feature via the
command line (online at http://syncevolution.org/documentation/syncevolution-usage).
Properties not supported by SyncML servers can now be preserved
locally in two-way synchronization (BMC #15030). This depends on
information about what properties a SyncML server supports ("CtCap"),
which is typically not provided by servers. SyncEvolution contains a
copy of that information for Google Contacts (BMC #15029).
Akonadi backend and KWallet support were merged. They are not included
yet in syncevolution.org binaries. To use them compile from source.
The configuration format was updated to solve a conceptual problem
inherited with the legacy property names: the "type" property had
multiple, sometimes conflicting roles. For example, setting the
preferred data format for sync with one peer might have changed the
backend selection for some other peer (BMC #1023). Now
"backend/databaseFormat/syncFormat/forceSyncFormat" replace
"type". "type" is still accepted by the command line as alias.
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. Release 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.
Other changes
-------------
* Using the --sync-property and --source-property command line options is
optional, just specifying the property assignment is enough.
* syncevo-http-server was enhanced considerably. See http://syncevolution.org/wiki/http-server-howto
* support NetworkManager API >= 0.9 (BMC #19470)
* syncevolution.org binaries: now compatible with Debian Testing/libnotify.so.4 (BMC #22668)
libnotify is not linked directly into syncevo-dbus-server in the
syncevolution.org binaries. Instead libnotify.so.1 till .so.4
(current Debian Testing) are opened opened dynamically and the
necessary functions are looked up via dlsym(). Not finding the
libraries or the functions silently disables this notification
mechanism.
* Sync mode is recorded when running in SyncML server mode (BMC #2786).
* syncevo-dbus-server automatically stops when some of its libraries
are updated and restarts if auto-syncing is on (BMC #14955).
* Added code for Buteo, mKCal and QtContacts in MeeGo.
Buteo and mKCal were removed again from MeeGo, so the code
is obsolete. The QtContacts backend may be still be useful
to access items via that API, but for syncing on MeeGo
the normal EDS backend is used since MeeGo reverted back
to EDS as PIM storage.
* "databasePassword" source property: lookup failure in keyring (BMC #22937)
The databasePassword also wasn't looked up at all when doing item operations
via the command line.
When configuring sources for an HTTP server, the config name typically
is just the context (@foo). When using the config in the HTTP server,
the config name is the peer inside that context (client@foo). Because
the GNOME keyring lookup keys for the "databasePassword" (more
specifically, the object name) contained the full config name which
was different in both cases, looking up the saved password failed.
The solution is to normalize the config name (to accomodate for
different ways of spelling it) and use only the context, with @ as
before. This will break existing setups where the object name in the
keyring (incorrectly) includes the full config name. In that case just
configure the source again to set the password anew.
* Evolution Calendar: fixed detached recurrence support (BMC #22940)
When manipulating a meeting series with more than one detached
recurrence certain sequences of operations could incorrectly fail
with "UID already exists".
* iCalendar 2.0: must set VALUE in EXDATE (part of BMC #22940)
EXDATE has a VALUE parameter, which wasn't defined in the XML
profile. Didn't seem to matter at all in practice, but wasn't
standard-compliant.
* GTK sync-ui: wrap sync service descriptions (BMC #7199)
Descriptions of different sync services are not fully visible unless
word-wrapping gets enabled.
* CalDAV/CardDAV + local storage: avoid empty properties
The main motivation for this change is that a recent Apple Calendar
server rejects vCards with empty BDAY property. Another reason is that
keeping the data as small as possible is desirable by itself.
Sending an empty property serves as a hint for the peer that the
property is supported. This is not necessary when storing an item in a
backend. Therefore this commit disables empty properties for all
backends which do not themselves set the m_backendRule Synthesis info
value.
* Google Contacts: ensure that first/middle/name are set when storing in EDS (BMC #20864)
Evolution and the MeeGo UX assume that first/middle/last name are set.
That is not the case when a contact is created in the Google Contacts
web interface. Such contacts are sent by Google without the N
property.
SyncEvolution now tries to recreate the name components from the FN
string, by splitting at word boundaries and assuming "<first>
<middle> <last>" or "<last>, <first>" format. Obviously this
heuristic fails for some locales.
* Evolution Calendar: fixed error handling for broken TZIDs
* Sony Ericsson: use ISO-8859-1 for all devices (BMC #14414)
Passing invalid UTF-8 strings into libecal caused glib to
abort syncevo-dbus-server.
* auto sync: show all failed syncs except for temporary network errors (BMC #21888)
Notifications were meant to be shown for all errors except temporary
ones. This has never been implemented correctly since the feature was
introduced: instead of hiding known temporary errors, all errors except
500 (fatal error) were suppressed.
* vCard: inline local photo data (BMC #19661)
Some platforms (Maemo, MeeGo) store photos in separate files. Now SyncEvolution
efficiently includes that photo data in the generated vCard right before sending
it to a peer; previously it sent a useless local file:// URI. The Maemo port
has a less efficient workaround for that which now should be obsolete.
* syncevo-dbus-server: online status wrong without Network Manager or ConnMan (BMC #21543)
When neither Network Manager nor ConnMan are running, network presence was "not
online". This prevented running automatic syncs.
For developers:
* modified backend API
- ClientTestConfig modernized
- InsertItemResult::m_merged turned from boolean to enum
* testing and compilation changes; for example, the minimum version of
libsynthesis is now checked at configure time instead of failing at
runtime due to missing features in the Synthesis engine
SyncEvolution 1.1.99.7 -> 1.2, 13.10.2011
=========================================
Some more bug fixes and testing improvements.
* fixed potential invalid memory access in add<->add conflict handling
* fixed memory leak in workaround for EDS bug
* CalDAV/CardDAV: handle ETags without quotation marks (eGroupware)
* updated README: warning about sync direction moved to --sync option
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2011/syncevolution-12-released
Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources
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, then install
"syncevolution-evolution":
deb http://downloads.syncevolution.org/apt unstable main
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 8.04 LTS (Hardy). 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/evolution. 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
10 years, 6 months
[SyncEvolution] configuring local sync + ActiveSync + Evolution
by Patrick Ohly
Hello!
For those who don't know, Srini wrote an Evolution plugin which
automatically configures ActiveSync for email and contacts/calendar. The
latter is based on SyncEvolution.
Right now he is using the SyncEvolution command line. The intention is
to use the D-Bus API instead, because that will allow better control
over error cases and enables more advanced features (controlling
syncing, for example).
Here's the sequence of steps for configuring SyncEvolution for
ActiveSync when using the command line:
1. configure ActiveSync daemon in gconf, using some kind of
<eas_account_id> - email address is common, but not required
2. configure access to server:
syncevolution --configure \
syncURL= \
username=<eas_account_id> \
peerType=ActiveSync \
addressbook/backend=eas-contacts \
calendar/backend=eas-events \
todo/backend=eas-todos \
memo/backend=eas-memos \
target-config@exchange addressbook calendar todo memo
Note 1: the "target-config@exchange" target config must not exist yet,
because otherwise it will be overwritten without warning.
Note 2: the <eas_account_id> cannot be shared between different configs
because it is tied to the state of one account in the ActiveSync server
(sync keys), in contrast to a CalDAV target config, which is stateless.
For the same reason, item operations on that target-config will interfere
with syncing with it (force a slow sync).
A GUI tool either has to check all existing target configs for a collision (hard)
or we impose additional policies for ActiveSync configs. I propose:
- simplify <eas_account_id> such that it consists of characters a-z, 0-9 and
hyphen by lowercasing all characters and replacing other characters with
a hyphen (Patrick.Ohly(a)foo.bar => patrick-ohly-foo-bar)
- use that <simple_eas_account_id> instead of "exchange"
Note 3: the command above uses the default databases. It is possible to
get folder IDs from the activesync daemon and set those with
<source>/database=<folder_id>.
Note 4: todo and memo are configured above although not supported yet.
Note 5: peerType is a hint for UIs that tells them what the other properties
in the config really mean. For example, in this case setting the password
in the config has no effect and must be done elsewhere. This wasn't (and
still isn't) in the original ActiveSync backend README.
I will provide an ActiveSync config template similar to the WebDAV context;
then setting syncURL, peerType and backend properties above can be replaced
with "--template ActiveSync".
3. configure syncing:
syncevolution --configure \
--template SyncEvolution_Client \
syncURL=local://@<simple_eas_account_id> \
username= \
password= \
sync=none \
calendar/sync=two-way \
addressbook/sync=two-way \
<simple_eas_account_id>
Note 1: because only calendar and addressbook really work, only
those are enabled here.
Note 2: the default local backends and databases are used. To lock this
down, use <source>/backend=evolution-contacts/events/tasks/memos for Evolution
and <source>/database=<evolution ID> (for example, local:system or
local:1237386992.13712.0@pohly-MOBL) - warning, I think these IDs are subject
to change in Evolution 3.4. Probably the user will have to fix configs manually,
because I'm not aware of migration support by EDS itself.
Note 3: syncing will not run unless autoSync=1 is set to enable polling.
Srini, how much of this do you have working already? Have you seen a
sync of contacts and calendar running? Do you support removing configs?
Translating this into D-Bus API calls makes the process a bit harder.
One of the obstacles is that a config has to be locked first before
modifying it by obtaining a session. This prevents race conditions
between different clients (less likely) and client and sync daemon (more
likely, in particular with auto syncing enabled). I considered whether
write access should be allowed without that locking, but decided against
it. The consequences are simply too hard to predict. Think removing a
config and its associated databases while a sync using it runs.
Evolution currently uses account settings that can be modified in gconf
at any time, but work is under way to put them into plain files under
the control of a D-Bus service - that's exactly how SyncEvolution always
has worked. SyncEvolution going in the other direction (and thus
suffering from the problems the Evolution devs are currently solving)
just doesn't make sense.
Obtaining a session for config changes is done in three steps
(http://api.syncevolution.org/):
1. session = Server.StartSessionWithFlags(<config name>,
['no-sync'])
2. listen to session.StatusChanged()
3. check session.GetStatus(): if 'idle', it is ready for use; if
still 'queueing' (yes, typo is part of the API - sorry), wait
for StatusChanged('idle') and
Typically a session will be usable right away on an idle
syncevo-dbus-server. If a sync runs, the sync has to complete first,
which should somehow be indicated to the user.
Note that the session is limited to making changes to <config name>.
That is not entirely enforced because all configs use some shared
properties that also appear in other configs. That's not a problem,
because currently no concurrent sessions are supported.
But it makes the ActiveSync configuration awkward, because two sessions
will be needed, one for the target config and one for the sync config,
which requires additional code in the D-Bus client and leads to
additional error states (what if the target-config could be created, but
not the sync config?).
Therefore I suggest to accept that sessions for config changes always
lock the whole config tree, which allows that any config can be changed
in such a session. This is an extension of the current D-Bus API and
thus backwards compatible:
* Session.SetConfig() modifies the config named in StartSession,
as before
* a new Session.SetNamedConfig(<config name>) modifies any config;
it is only allowed in a session which was started with
Server.StartSessionWithFlags(<config name>, ['no-sync']), where
<config name> may be empty - such a session will prevent any
other session from running, while normal sessions may one day
run concurrently (not supported at the moment)
* there is no need for a Session.GetNamedConfig() because
Server.GetConfig() already provides that - should it be added
anyway, for the sake of completeness?
With this revised API and taking into account the policy outlined before
(http://comments.gmane.org/gmane.comp.mobile.syncevolution/2468),
configuring ActiveSync via D-Bus becomes:
A. session = Server.StartSessionWithFlags('', ['no-sync'])
B. listen to session.StatusChanged()
C. wait for session to become 'idle' (GetStatus() or signal)
D. target_config = Server.GetConfig('ActiveSync@<simple_eas_account_id>', template=True)
E. target_config['']['username'] = <eas_account_id>
F. session.SetNamedConfig('target-config@<simple_eas_account_id>', update=False, temporary=False, target_config)
G. sync_config = Server.GetConfig('SyncEvolution_Client', template=True)
H. unset sync_config['']['username'/'password'], if set
I. sync_config['']['ConsumerReady'] = target_config['']['ConsumerReady'] (might not be set)
J. sync_config['']['PeerName'] = some user visible name for the sync config; if nothing
better is available, use <eas_account_id> because otherwise UIs will have to fall back
to the config name, which would be the simplified string in this case
K. sync_config['']['autoSync'] = 1
L. modify sync_config['source/<source>']['sync'] according to the user's choice for
enabling/disabling certain kinds of data, always disable 'memo' and 'todo'
M. session.SetNamedConfig('<simple_eas_account_id>', update=False, temporary=False, sync_config)
Note that this intentionally doesn't mention setting 'backend' on the
'calendar' or 'addressbook' source. That's because these settings are
shared with other sync configs in the default context (chosen implicitly
in step M by not having an @<context> part in the config name). The idea
here was that advanced users can choose their default databases once
(via the command line, GTK sync-ui doesn't support it) and then
configuring further sync configs will automatically use those databases
(because GTK sync-ui will never change the 'backend' property).
It is possible to define the <simple_eas_account_id> sync config inside
its own context (for example,
<simple_eas_account_id>@<simple_eas_account_id>), which would give the
UI full control over the configuration of all sources.
But restoring local databases finds data dumps based on the source name
and its context name. Anything more fancy would suffer from loopholes
(is database="Personal Calendar" with backend=eds-contact in
default/addressbook the same as database=local:system with
backend="Evolution Contacts" in other-context/personal-contacts?). This
means that if multiple sync configs in diffrent contexts access the same
local database, the user has to be more careful about picking the latest
data dump - not at all obvious.
I think I rather prefer a UI design where the user configures his local
database globally, or alternatively a design where each local database
always matches 1:1 with a peer.
I believe the Evolution plugin follows the later approach, and thus
should use <simple_eas_account_id>@<simple_eas_account_id>. Srini, is
that right?
In that case, should that local database be limited to the data that
really can be stored on the peer? This is not something that
SyncEvolution can enforce, though. It would be a lot better to tell the
user right away in the UI for modifying a contact, for example, that he
can only enter a certain set of phone numbers. This problem also occurs
with other Evolution backends.
David, how does the Evolution EWS backend handle this? Does it silently
throw away data or remap it when the EDS vCard doesn't fit into the EWS
data model?
--
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.
10 years, 6 months
[SyncEvolution] SyncEvolution 1.1.99.7 released
by Patrick Ohly
SyncEvolution 1.1.99.6
======================
Mostly bug fixes again. Some are a bit more intrusive, thus another
pre-release.
* syncevolution.org binaries: now compatible with Debian Testing/libnotify.so.4 (BMC #22668)
libnotify is not linked directly into syncevo-dbus-server in the
syncevolution.org binaries. Instead libnotify.so.1 till .so.4
(current Debian Testing) are opened opened dynamically and the
necessary functions are looked up via dlsym(). Not finding the
libraries or the functions silently disables this notification
mechanism.
* calendar sync: better handling for add<->add conflicts (partly fixes BMC #22783)
When both sides of a sync have added the same event, the sync must
determine which one is more recent instead of blindly overwriting
always the same side. Such conflicts are typically rare except for
enterprise scenarios where meeting invitiations are processed
automatically by a groupware (Exchange, Google Calendar/Mail, ...)
and then the attendee status is updated on one side.
SyncEvolution now does the necessary age comparison and preserves the more
recent data for most properties. In some properties the data from both
sides is preserved by concatenating the text (description, location, ...).
It remains to be seen whether that is really desirable. Also, sync statistics
are slightly off: the incoming item is counted as "added" even though it
gets turned into an update.
* item operations: authentication problem for WebDAV when using keyring (BMC #21311)
The password still wasn't looked up in the keyring when using
--import/export/delete-items.
* "databasePassword" source property: lookup failure in keyring (BMC #22937)
The databasePassword also wasn't looked up at all when doing item operations
via the command line.
When configuring sources for an HTTP server, the config name typically
is just the context (@foo). When using the config in the HTTP server,
the config name is the peer inside that context (client@foo). Because
the GNOME keyring lookup keys for the "databasePassword" (more
specifically, the object name) contained the full config name which
was different in both cases, looking up the saved password failed.
The solution is to normalize the config name (to accomodate for
different ways of spelling it) and use only the context, with @ as
before. This will break existing setups where the object name in the
keyring (incorrectly) includes the full config name. In that case just
configure the source again to set the password anew.
* Evolution Calendar: fixed detached recurrence support (BMC #22940)
When manipulating a meeting series with more than one detached
recurrence certain sequences of operations could incorrectly fail
with "UID already exists".
* iCalendar 2.0: must set VALUE in EXDATE (part of BMC #22940)
EXDATE has a VALUE parameter, which wasn't defined in the XML
profile. Didn't seem to matter at all in practice, but wasn't
standard-compliant.
* GTK sync-ui: wrap sync service descriptions (BMC #7199)
Descriptions of different sync services are not fully visible unless
word-wrapping gets enabled.
* source configs: don't check "backend" unless it is needed
When using a config which has sources with a backend type set which is
not currently available, an error was thrown even if those sources
weren't even part of the current operation (for example, syncing
another source which is currently supported).
* config migration: avoid name conflicts and auto syncing of old configs (BMC #22691)
When (auto-)migrating a config, it was possible that a name for the
peer, say foo.old, was chosen for the renamed config although there
was already such a config, for example foo.old in ~/.sync4j. Besides
being confusing for users, this also led to a bug in the code where it
copied from the older config with the foo.old name.
The main problem fixed is the disabling of auto syncing
in the old config. Otherwise it was still used by syncevo-dbus-server
for syncing, which triggered another auto-migration, ad infinitum...
* auto syncing: must check whether enabled when looking at unknown URLs (part of BMC #22691)
"syncURL = insert your URL here" with "autoSync = 0" did lead to auto
sync attempts although it wasn't enabled. A check for "auto syncing
enabled" was missing for the "unknown transport" case.
* CalDAV/CardDAV + local storage: avoid empty properties
The main motivation for this change is that a recent Apple Calendar
server rejects vCards with empty BDAY property. Another reason is that
keeping the data as small as possible is desirable by itself.
Sending an empty property serves as a hint for the peer that the
property is supported. This is not necessary when storing an item in a
backend. Therefore this commit disables empty properties for all
backends which do not themselves set the m_backendRule Synthesis info
value.
* Apple CardDAV: apply PHOTO import/export scripts by default
A recent Apple Calendar server (correctly) rejects the invalid
PHOTO;TYPE=unknown: property in a vCard. This internal representation
must be cleared before serializing the field list.
* for developers: modified backend API
- ClientTestConfig modernized
- InsertItemResult::m_merged turned from boolean to enum
* testing and compilation changes; for example, the minimum version of
libsynthesis is now checked at configure time instead of failing at
runtime due to missing features in the Synthesis engine
Source, Installation, Further information
=========================================
http://syncevolution.org/blogs/pohly/2011/syncevolution-11997-released
Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources
i386, lpia amd64 binaries for Debian-based distributions are
available via the "unstable" syncevolution.org repository. Add the
following entry to your /apt/source.list, then install
"syncevolution-evolution":
deb http://downloads.syncevolution.org/apt unstable main
These binaries include the "sync-ui" GTK GUI and were compiled for
Ubuntu 8.04 LTS (Hardy). 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/evolution. 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
10 years, 7 months
[SyncEvolution] Error 500 sent from server on 'Map' command
by Roger KeIrad
Hi all,
I have been seeing this log for a while and honestly I did not get a
solution for.
*[INFO] addressbook: received 1/1
[INFO] addressbook: added 1, updated 0, removed 0
[INFO] addressbook: slow sync done unsuccessfully
[ERROR] addressbook: fatal error (remote, status 500)
Synchronization failed, see
//.cache/syncevolution/funambol-2011-10-11-02-02/syncevolution-log.html for
details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| slow, 0 KB sent by client, 0 KB received |
| fatal error (remote, status 500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Tue Oct 11 02:02:40 2011, duration 0:07min |
| fatal error (remote, status 500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: fatal error (remote, status 500)*
I analysed logs and I got that a warning from server is sent on command
'Map' and is treated as fatal error (500).
In xml exchange command 'Map' doesn't contain Source URI.
*
<MapItem><Target><LocURI>1</LocURI></Target><Source><LocURI></LocURI></Source></MapItem>
*
This scenario occurs offten when a contact which is created on server side
is synchronsed.
In my code I use updateRevision function to update uid of an item as below
*updateRevision(*m_trackingNode, uid, newuid, modtime);*
Do I miss anything?
Thank you for help.
Best Regards.
Roger
10 years, 7 months
[SyncEvolution] releasing 1.2
by Patrick Ohly
Hello!
I'm currently integrating some more fixes into the 1.2 branch which were
not in 1.1.99.6 (add<->add conflict (BMC #22783), command line and
source passwords (BMC #21311, #22937), fixing some EDS API issues with
regards to multiple detached recurrences (BMC #22940), don't check
"backend" unless it is needed, backend API changes, updated testing).
More details once I have written an updated NEWS entry tomorrow.
I can either publish a 1.1.99.7 release candidate this Friday before
going on a 10 day vacation or call it 1.2 right away.
Are there opinions either way? Anyone willing to give a release
candidate some testing, in particular with an eye towards the more
recent changes? Anyone urgently waiting for the final 1.2?
--
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.
10 years, 7 months
Re: [SyncEvolution] libeasclient + GError codes
by David Woodhouse
Before. I'm partway through switching to gdbus too, which fixes the extra handle for progress indication and will affect how we marshal errors.
--
dwmw2
(Apologies for HTML and top-posting; Android mailer is broken.)
Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mon, 2011-10-10 at 15:03 +0000, Woodhouse, David wrote:
> Yeah, that's how the camel code does it. I think there are ways to
> sanely marshal errors over dbus?
Might be, but I don't know how that would work. Filed as
https://bugs.meego.com/show_bug.cgi?id=23618
This is an API change/extension. Should it be done before releasing the
ActiveSync libs as 1.0 or later?
To me, 1.0 kind of implies that we have the API ironed out for apps to
use it. In this case we are asking apps to use hacks to achieve the
desired result because the API is not quite complete yet. I'd rather
call it 0.9, then do the API clean-up and finally bump to 1.0. Just my 2
cents, of course.
--
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.
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
10 years, 7 months
[SyncEvolution] libeasclient + GError codes
by Patrick Ohly
Hello!
I'd like to add error handling for libeassync GError {domain = 71, code
= 32, message = 0x12ce180 "Sync error: Invalid synchronization key"}. I
started looking for the place where this domain and code are defined.
It seems that it is currently only defined in the daemon side
(eas-connection-errors.h:
EAS_CONNECTION_ERROR/EAS_SYNC_STATUS_INVALIDSYNCKEY). On the client
side, the GError is a generic D-Bus error:
#1 0x00007ffff007903d in g_set_error (err=0x7fffffff7910, domain=71, code=32, format=0x7ffff79c35c3 "%s%c%s")
at ../../../glib/glib/gerror.c:220
#2 0x00007ffff79b4b30 in dbus_set_g_error () from /usr/lib/libdbus-glib-1.so.2
#3 0x00007ffff79b7a9d in ?? () from /usr/lib/libdbus-glib-1.so.2
#4 0x00007ffff79b8683 in dbus_g_proxy_call () from /usr/lib/libdbus-glib-1.so.2
#5 0x00007ffff7bcf302 in eas_sync_handler_get_items (self=0x12b8c00, sync_key_in=0x12d4178 "1309863698",
sync_key_out=0x7fffffff7900, type=EAS_ITEM_CONTACT, folder_id=0x7fffef9ca138 "", items_created=0x7fffffff78f0,
items_updated=0x7fffffff78e0, items_deleted=0x7fffffff78d0, more_available=0x7fffffff790c, error=0x7fffffff7910)
at /home/pohly/src/activesyncd/libeasclient/libeassync.c:258
Shouldn't there be some way of detecting errors inside the daemon based on their error code?
Right now, all I can do (please correct me if I'm wrong) is a string
match against a string which isn't even officially part of the
libeasclient API (not defined in any header file) - that doesn't sound
right to me.
--
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.
10 years, 7 months
[SyncEvolution] command line: listing databases
by Patrick Ohly
Hello!
The current approach of invoking the command line without arguments to
list databases has various shortcomings:
* unusual "syntax"
* cannot limit the output to specific databases
* does not work for CalDAV/CardDAV, which needs credentials and/or
syncURL
Here's a proposal, written as patch for README.rst:
===================================================================
SYNOPSIS
========
-Show available sources:
- syncevolution
+List databases:
+ syncevolution --print-databases [<properties>] [<config> <source>]
Show information about configuration(s):
syncevolution --print-servers|--print-configs|--print-peers
@@ -114,15 +114,29 @@ Sometimes it is also useful to change configuration options of a
context, without modifying a specific peer. This can be done by using
`@default` (or some other context name) without anything before the
`at` sign. The empty string "" is the same as `@default`. ::
- syncevolution
-
-If no arguments are given, then SyncEvolution will list all available
-data sources regardless whether there is a configuration file for them
-or not. The output includes the identifiers which can then be used to
-select those sources in a configuration file. For each source one can
-set a different synchronization mode in its configuration file. ::
+ syncevolution --print-databases [<properties>] [<config> <source>]
+
+If no additional arguments are given, then SyncEvolution will list all
+available backends and the databases that can be accessed through each
+backend. This works without existing configurations. However, some
+backends need additional information (like credentials or URL of a
+remote server) and/or cannot list databases (file backend). This
+additional information can be provided on the command line with
+property assignments (`username=...`) or in an existing configuration.
+The output in these cases explains the required information further.
+
+Otherwise the output starts with a heading that lists the values for
+the `backend` property which select the backend, followed by the databases.
+Each database has a name and a unique ID (in brackets). Typically
+both can be used as value of the 'database' property. One database
+might be marked as `default`. It will be used when `database` is not
+set explicitly.
+
+When selecting an existing source configuration or specifying the `backend`
+property on the command line, only the databases for that backend
+are listed, using the same output format.
=============================================================
Does this make sense?
I have partly implemented that because I wanted to test auto-discovery
of databases in CalDAV at the CalConnect interoperability test event. I
have used it like this to show all address books on a specific server:
syncevolution --print-databases \
syncURL=http://... \
username=... \
password=... \
backend=carddav
I'm undecided whether listing all databases of all sources in a config
should also be supported. Right now, if a config is specified, then a
source also must be given ([<config> <source>]). Would it be useful to
support the [<config> [<source>]] syntax also (= config without source)?
This is for the command line. In the D-Bus API, GetDatabases() already
is defined per source and can be used on a session where temporary
config changes were made, so it should already work without API changes.
Long term the returned information should be made a bit richer and also
include additional information:
* read-only databases => can be mirrored locally, but not be
written to
* large databases (for example, CardDAV gateways) => only access
them in queries, never sync them
Related to this change is the removal of <config> and <source> as
mandatory. Item operations can work without them, if backend and
possibly database are specified as properties on the command line. Not
written up yet, but I'll make the change soon.
--
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.
10 years, 7 months
