[SyncEvolution] bridgie syncml server and caldav/card dav server
by Robert Schetterer
Hi, is there a chance to use syncevolution
as a bridge between a syncml server and a caldav/carddav server and vice
versa
i.e horde or funambol server syncml and DAViCal etc
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
10 years
[SyncEvolution] Syncevolution build system conversion
by Krzesimir Nowak
Hi.
My name is Krzesimir Nowak. I work for Openismus GmbH who asked me to
try to convert Syncevolution's build system to a (simpler) non-recursive
Automake build. I now have something that works, with no obvious
regressions.
I've been working in a remote branch (I branched from Chris Kuehl's
dbus-server-reorganization because that already has some improvements
and it looks like it will get into master first).
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
but I have also attached it as one patch, which might be easier to
review.
This should be simpler and more robust (for instance, against weird
linker problems), with less duplication, and it allows faster builds via
make -j.
It also removes the pre/post configure system and the *-gen.am system
which can be unfamiliar to regular users of autotools.
Patrick's minimum requirement was to still have the version number
autogenerated from the git version, and I have managed to keep that.
Patrick also preferred not having to list all the templates and config
files, but I have only partly achieved that.
I think it would be wise to make further step-by-step improvements once
this first step is in master. For instance, see:
https://meego.gitorious.org/~krnowak/meego-middleware/syncevo-autotools-c...
Regards,
Krzesimir
10 years, 3 months
[SyncEvolution] UID matching during add<->add conflict
by Patrick Ohly
Hello!
Suppose the same meeting invitation for event UID=FOO is processed in
both Evolution and Google Calendar. On the Evolution side, the
invitation is accepted. In Google Calendar this is still open.
Both sides now have a new item when syncing takes place.
What happens is that the engine itself doesn't recognize that the two
new items are in fact the same. It asks both sides to store the others
item. The SyncEvolution EDS backend recognizes the UID and updates the
item, but without merging. The PARTSTAT=ACCEPTED is overwritten with
Google's PARTSTAT=NEEDS-ACTION. At the same time, Google's version of
the items similarly overwritten.
After modifying the event series in Evolution it is sent as update to
Google, at which point the correct PARTSTAT is lost everywhere.
Is there some way to force UID comparison for added items even in a
normal, incremental sync?
SyncEvolution already has a comparescript for its calendar types:
INTEGER RES;
if (COMPARISONMODE() != "age" && SESSIONVAR("VCALENDAR_COMPARE_UID") ) {
if (TARGET.UID == REFERENCE.UID &&
TARGET.ORIGSTART == REFERENCE.ORIGSTART) {
RES = 0;
} else {
RES = -999;
}
} else {
RES = COMPAREFIELDS();
}
return RES;
The VCALENDAR_COMPARE_UID session variable would be set in this case.
--
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] Unable to create a new service in sync-ui
by Tino Keitel
Hi,
I tried to test sync-ui for adding a new service but nothing happens
when I click on "Add new service". The only message I see in the
console is this:
"(sync-ui:19005): GLib-CRITICAL **: g_hash_table_unref: assertion `hash_table != NULL' failed"
There are some other console messages, I don't know if they are
related:
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
** (sync-ui:19005): WARNING **: only file:// icon uri is supported:
** image://themedimage/icons/services/everdroid
** (sync-ui:19005): WARNING **: only file:// icon uri is supported:
** image://themedimage/icons/services/egroupware
** (sync-ui:19005): WARNING **: only file:// icon uri is supported:
** image://themedimage/icons/services/funambol
** (sync-ui:19005): WARNING **: only file:// icon uri is supported:
** image://themedimage/icons/services/gmail
** (sync-ui:19005): WARNING **: only file:// icon uri is supported:
** image://themedimage/icons/services/memotoo
** (sync-ui:19005): WARNING **: only file:// icon uri is supported:
** image://themedimage/icons/services/everdroid
** (sync-ui:19005): WARNING **: only file:// icon uri is supported:
** image://themedimage/icons/services/ovi
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
(sync-ui:19005): Gtk-CRITICAL **: IA__gtk_widget_set_sensitive:
assertion `GTK_IS_WIDGET (widget)' failed
Does that ring any bells?
Regards,
Tino
10 years, 8 months
[SyncEvolution] Memotoo refresh + empty data
by Patrick Ohly
Hello Thomas!
Can you remind me how Memotoo handles refresh-from-client and syncs
without data?
According to past discussions and our README.memotoo, Memotoo used to do
a slow sync when it had no data. That broke our testRefreshStatus test.
But now this test seems to run fine.
Instead testDeleteAllRefresh fails now. This test copies some items to
the server, then deletes everything locally and does a
refresh-from-client sync. The expected outcome is that the server
deletes all its items. The actual outcome is that the client is sent all
items on the server.
See http://syncev.meego.com/latest/head-testing-amd64/nightly.html for
examples.
--
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, 8 months
[SyncEvolution] ActiveSync + detached recurrence without parent
by Patrick Ohly
Hello!
Consider the following situation:
1. User A sets up a recurring meeting.
2. He invites user B for one (but not all) recurrences, which
happens to be modified (say, different summary).
3. User B receives the meeting invitation. It gets added to his
Exchange calendar.
4. User A invites him for the recurring meeting.
5. User B receives that meeting invitation.
The key question is: at step 3, is the meeting stored as a detached
recurrences, or whatever the corresponding Exchange semantic is?
If it is not, then how do Outlook/Exchange deal with the second meeting
invitation? If the existing event is not marked as a detached
recurrence, then the invitation looks like an update, which should
overwrite the old data instead of adding the parent event to it.
In SyncEvolution's client-test, this situation is covered by:
CLIENT_TEST_UNIQUE_UID=1 CLIENT_TEST_SERVER=exchange ./client-test Client::Source::eas_event::LinkedItems_0::testLinkedItemsParentChild
Note that you need an up-to-date SyncEvolution and activesyncd source; I
changed the naming recently and fixed some aspects of the LinkedItems
testing.
What I now see is that SyncEvolution sends a VCALENDAR with one VEVENT
which has a RECURRENCE-ID. What comes back is that same event without
RECURRENCE-ID. I suspect that this will cause Evolution to fall into the
trap that I outlined above.
It depends a bit on what kind of meeting invitations are sent: is it one
for the parent, or one for parent and all detached recurrences? I don't
know, and the point is that different programs may deal with this
differently. I don't think the iCalendar 2.0 standard mandates a
particular behavior.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
10 years, 8 months
Re: [SyncEvolution] SyncEvolution on Harmattan
by Roman Morawek
On 05.08.2011 21:15, Ove K?ven wrote:
> I've successfully built a version (without DAV, since libneon is not yet
> available).
I tried calendar and addressbook sync.
1. Caldendar sync:
Works well. It is already in productive use - thanks again!
During syncing, when there are changes on the server that need to be
migrated to the N950, it prints an error message:
"[ERROR] stderr: extendedstorage.cpp: 862 - cannot remove the set of
alarms false QDBusError("", "")"
However, I cannot see any resulting problem. The syncing just seems to
work fine.
If I interpret the error message correctly, syncevolution cannot access
the DBUS (what does it do there?). This may be related to the Harmattan
security framework. You need to add an syncevolution.aegis file into the
debian package to allow this (credential: TrackerReadAccess?,
TrackerWriteAccess?). See also:
http://forum.meego.com/showthread.php?t=3955
http://www.developer.nokia.com/Community/Wiki/Harmattan:Developer_Library...
2. Addressbook sync:
As I try to sync the addressbook, syncevolution hangs. The last line of
the log file (attached) tells "creating
/home/user/.cache/syncevolution/epia-2011-08-07-12-50-a/addressbook.before".
Then nothing more happens and only a kill -9 can stop syncevolution.
Regards,
Roman
10 years, 8 months
[SyncEvolution] Templates and matching scores
by Chris Kühl
Hi,
I've been working on retrieving the immutable vendor and product id
provided by the Bluetooth Device ID profile (DIP). See my
bluetooth-device-id branch[1] for what's been pushed so far.
Being that we now have a means of getting reliable device information
it seems to me that in the cases where this information was
attainable, a matching score is no longer needed. If the fingerprint
matches the product name from the look-up table exactly (and it will
because we've created the lookup table and the template fingerprints)
we suggest just that one template instead of several. If we didn't get
this product name from the look-up table then everything should behave
as normal because we can't trust the user-modifiable device name
string.
Does this sound reasonable or are there other reasons you'd want more
than one template to choose from even when you're sure which device
you're dealing with?
Cheers,
Chris
[1] https://meego.gitorious.org/meego-middleware/syncevolution/commits/blueto...
10 years, 8 months
[SyncEvolution] ActiveSync StandardName/DaylightName
by Patrick Ohly
Hello Andy!
Some questions about the following code:
/**
* Process the VTIMEZONE component during parsing of an iCalendar
*
* @param vtimezone
* Pointer to the iCalendar VTIMEZONE component
* @param appData
* Pointer to the <ApplicationData> element to add parsed elements to
*/
static void _ical2eas_process_vtimezone (icalcomponent* vtimezone, xmlNodePtr appData)
{
if (vtimezone) {
EasTimeZone timezoneStruct;
icalcomponent* subcomponent = NULL;
gchar* timezoneBase64 = NULL;
// Only one property in a VTIMEZONE: the TZID
icalproperty* tzid = icalcomponent_get_first_property (vtimezone, ICAL_TZID_PROPERTY);
if (tzid) {
// Get the ASCII value from the iCal
gchar* tzidValue8 = (gchar*) icalproperty_get_value_as_string (tzid);
// Convert to Unicode, max. 32 chars (including the trailing 0)
gunichar2* tzidValue16 = g_utf8_to_utf16 (tzidValue8, 31, NULL, NULL, NULL);
// Copy this into the EasTimeZone struct as both StandardName and DaylightName
2645 =>>> memcpy (& (timezoneStruct.StandardName), tzidValue16, sizeof (timezoneStruct.StandardName));
memcpy (& (timezoneStruct.DaylightName), tzidValue16, sizeof (timezoneStruct.DaylightName));
g_free (tzidValue8);
g_free (tzidValue16);
}
// Now process the STANDARD and DAYLIGHT subcomponents
for (subcomponent = icalcomponent_get_first_component (vtimezone, ICAL_ANY_COMPONENT);
subcomponent;
subcomponent = icalcomponent_get_next_component (vtimezone, ICAL_ANY_COMPONENT)) {
_ical2eas_process_xstandard_xdaylight (subcomponent, &timezoneStruct, icalcomponent_isa (subcomponent));
}
Isn't the TZNAME property of the STANDARD and DAYLIGHT subcomponent a
better match for the StandardName and DaylightName?
What drew my attention to this is a valgrind warning:
==26768== Invalid read of size 1
==26768== at 0x4C25F98: memcpy (mc_replace_strmem.c:497)
==26768== by 0x7005CB9: _ical2eas_process_vtimezone (eas-cal-info-translator.c:2645)
==26768== by 0x7005F11: eas_cal_info_translator_parse_request (eas-cal-info-translator.c:2709)
==26768== by 0x6FF9603: eas_sync_msg_build_message (eas-sync-msg.c:265)
==26768== by 0x7009E49: eas_add_item_req_Activate (eas-add-item-req.c:207)
==26768== by 0x404304: eas_sync_add_items (eas-sync.c:400)
==26768== by 0x403613: dbus_glib_marshal_eas_sync_VOID__STRING_UINT64_STRING_STRING_BOXED_POINTER (eas-sync-stub.h:149)
==26768== by 0x55F29DA: ??? (in /usr/lib/libdbus-glib-1.so.2.1.0)
==26768== by 0x582578D: ??? (in /lib/libdbus-1.so.3.4.0)
==26768== by 0x581930B: dbus_connection_dispatch (in /lib/libdbus-1.so.3.4.0)
==26768== by 0x55EEBB4: ??? (in /usr/lib/libdbus-glib-1.so.2.1.0)
==26768== by 0x6AE5D3B: g_main_dispatch (gmain.c:2500)
==26768== Address 0xf129d6f is not stack'd, malloc'd or (recently) free'd
That's the memcpy(). I suspect it reads past the end of the allocated
string because of the fixed size, although I find it a bit puzzling that
valgrind does report that explicitly - usually it does.
What's the right way to determine the number of bytes to be copied?
strlen() is guaranteed to work for utf-8, but for utf-16 I am not so
sure.
--
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, 8 months
[SyncEvolution] ActiveSync TZIDs
by Patrick Ohly
Hello Andy!
Why do you check for utc_offset != 0 in the following code (from
eas-cal-info-translator.c):
//
// StartTime
//
else if (g_strcmp0 (name, EAS_ELEMENT_STARTTIME) == 0) {
int utc_offset = 0, isDaylight;
icaltimezone * icaltz;
value = (gchar*) xmlNodeGetContent (n);
dateTime = icaltime_from_string (value);
if (isAllDayEvent) {
// Ensure time is set to 00:00:00 for all-day events
dateTime.is_date = 1;
}
if(vtimezone){
g_debug("got a timezone");
icaltz = icaltimezone_new();
icaltimezone_set_component(icaltz, vtimezone);
utc_offset = icaltimezone_get_utc_offset (icaltz, &dateTime, &isDaylight);
if(utc_offset){
icaltime_adjust (&dateTime, 0, 0, 0, utc_offset);
dateTime.is_utc = 0;
}
}
prop = icalproperty_new_dtstart (dateTime);
if (tzid && strlen (tzid)&& (utc_offset != 0)) { // Note: TZID not specified if it's a UTC time
g_debug("got a tzid, %s", tzid);
param = icalparameter_new_tzid (tzid);
icalproperty_add_parameter (prop, param);
}
Does't that have the effect that time zone information where the offset
is zero for parts of of the year will be dropped if the event start time
falls into that part of the year?
That would be incorrect for Europe/London, for example.
--
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, 8 months
