[Bug 4635] New: Google: MaxObjSize is not working in syncing with google
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4635
Summary: Google: MaxObjSize is not working in syncing with
google
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: guannan.ou(a)intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: shuang.wan(a)intel.com, syncevolution(a)lists.intel.com,
congwu.chen(a)intel.com
-------------------------------
Summary
-------------------------------
MaxObjSize is not working in syncing with google.
-------------------------------
Reproduce Step
-------------------------------
<1> syncevolution -c -y MaxObjSize=10 -l google google_1
<2> fill in a contact with large text information.
<3> two-way sync.
Large text information can be synced to goole. While same large text
information can not be synced to funambol after set MaxObjSize to 10 bytes.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months
[Bug 4596] New: ScheduleWorld: slow sync of memos duplicates all items (Client::Sync::text::testManyItems)
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4596
Summary: ScheduleWorld: slow sync of memos duplicates all items
(Client::Sync::text::testManyItems)
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: Waiting for upstream
Severity: normal
Priority: Undecided
Component: SyncML
AssignedTo: mark(a)ScheduleWorld.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: shuang.wan(a)intel.com, syncevolution(a)lists.intel.com
Found when running Client::Sync::text::testManyItems of the current 0.9
development cycle:
CLIENT_TEST_NUM_ITEMS=1 CLIENT_TEST_SERVER=scheduleworld
CLIENT_TEST_EVOLUTION_PREFIX=file:///tmp/test_ ./client-test
Client::Sync::text::testManyItems
Client_Sync_text_testManyItems.send.client.A/sysynclib_linux.html sends:
000 Summary
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...
xxxxxxxxxxxxxxxxx
xBody text
Client_Sync_text_testManyItems.twinning.client.A/sysynclib_linux.html sends the
same item during a slow sync and receives it back as "Add" => duplicated.
Only one item exists on the server during this test due to
CLIENT_TEST_NUM_ITEMS=1.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months
[Bug 4369] Scheduleworld and Funambol is different in two-way syncing policy
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4369
--- Comment #6 from pohly <patrick.ohly(a)intel.com> 2009-07-31 00:07:05 ---
(In reply to comment #5)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > You're correct. I think you're asking me to verify this. So:
> > >
> > > ScheduleWorld is configured to be 'client wins'.
> >
> > I don't think that this is a useful policy for delete/update conflicts because
> > data can get lost. I have added it as a caveat to the new
> > test/README.scheduleworld document:
> >
> > ScheduleWorld resolves conflicts where the client deleted an item that
> > was updated on the server by deleting the item on the server (Bugzilla
> > #4369). Advice: copy items instead of updating them if they were
> > deleted elsewhere, otherwise the updated item may get lost later on.
> >
> > If you think changing the policy would be useful, then let's reopen this issue.
>
> I think it would be fair to also state the reverse for servers configured for
> 'server wins'. F.E. the server has the 'delete' and the client has the update;
> the client will lose the update on the next sync.
That's correct. "sever wins" for a client update/server delete conflict also
looses data.
Mark, you seem to think that only "server wins" and "client wins" are possible
choices in this case. But there's a third one: the right conflict resolution
IMHO would be to keep the updated item.
> I'm assuming other servers
> that use 'server wins' do this. Am I wrong?
I hope they don't. Do you know of a server who does it like that?
I have checked with Synthesis and Funambol. Both preserve the updated item in
both cases, exactly as I would expect it. I have updated the
README.scheduleworld to document this new information and enhanced the advice:
ScheduleWorld resolves conflicts where the client deleted an item that
was updated on the server by deleting the item on the server (Bugzilla
#4369). Other servers always preserve the updated item in an update/delete
conflict, regardless which side has the update.
Advice: always sync before making changes. If it is too late for that,
copy items instead of updating them if they were deleted elsewhere,
otherwise the updated item may get lost later on.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months
[Bug 4369] Scheduleworld and Funambol is different in two-way syncing policy
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4369
--- Comment #5 from MarkSwanson <mark(a)ScheduleWorld.com> 2009-07-30 12:23:41 ---
(In reply to comment #3)
> (In reply to comment #2)
> > You're correct. I think you're asking me to verify this. So:
> >
> > ScheduleWorld is configured to be 'client wins'.
>
> I don't think that this is a useful policy for delete/update conflicts because
> data can get lost. I have added it as a caveat to the new
> test/README.scheduleworld document:
>
> ScheduleWorld resolves conflicts where the client deleted an item that
> was updated on the server by deleting the item on the server (Bugzilla
> #4369). Advice: copy items instead of updating them if they were
> deleted elsewhere, otherwise the updated item may get lost later on.
>
> If you think changing the policy would be useful, then let's reopen this issue.
I think it would be fair to also state the reverse for servers configured for
'server wins'. F.E. the server has the 'delete' and the client has the update;
the client will lose the update on the next sync. I'm assuming other servers
that use 'server wins' do this. Am I wrong?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months
[Bug 4754] New: non-Moblin binary packages: don't include development files
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4754
Summary: non-Moblin binary packages: don't include development
files
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Generic
OS/Version: Other
Status: ASSIGNED
Severity: major
Priority: P1
Component: * Feature Request
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Some development files are already filtered out (include), but some are still
included, like .la and sdk libs. This interferes with compilation that uses
--with-synthesis-src because the incomplete .la files in /usr/lib are found
first.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months
[Bug 3314] refresh-from-server: statistics for deleted items
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=3314
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #3 from pohly <patrick.ohly(a)intel.com> 2009-07-30 08:27:01 ---
The discussion with Synthesis showed that they see the item statistics as
something that covers changes requested by one or the other peer. That make
sense in some way, for example is it impossible to determine how many items
were deleted on the server during a refresh-from-client.
But for local changes I still think that it makes more sense to mention locally
deleted items that were deleted as part of a refresh-from-server, simply so
that the numbers add up.
Therefore I added counting of locally deleted items to SyncEvolution and use
that number in the core stats and in the GUI instead of the one provided by
Synthesis. This is only done for refresh-from-server syncs.
A new test was also added which checks those statistics
(testComplexRefreshFromServerSemantic).
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months
[Bug 4921] New: syncevo-dbus-server: glib CRITICAL + crash in syncevo_report_array_new()
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4921
Summary: syncevo-dbus-server: glib CRITICAL + crash in
syncevo_report_array_new()
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Generic
OS/Version: Other
Status: ASSIGNED
Severity: major
Priority: P1
Component: GTK UI
AssignedTo: jku(a)linux.intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: shuang.wan(a)intel.com, syncevolution(a)lists.intel.com
It happens whenever I want to use a self-compiled syncevo-dbus-server on my
Ubuntu Jaunty machine. Below is what I have from debugging this so far. It's a
bit mysterious. The binary compiled on Ubuntu Hardy works fine on my machine.
If I run syncevo-dbus-server under valgrind, it prints several more GLib-Object
error messages, but runs without crashing and *without* valgrind error
messages.
Error message, repeated four times before crashing:
(process:16854): GLib-CRITICAL **: g_string_append: assertion `val != NULL'
failed
Call stack:
#0 IA__g_log (log_domain=0x7f3d3290a586 "GLib",
log_level=G_LOG_LEVEL_CRITICAL, format=0x7f3d32912d2d "%s: assertion `%s'
failed")
at /build/buildd/glib2.0-2.20.1/glib/gmessages.c:522
#1 0x00007f3d328f5cba in IA__g_string_append (string=0xce2260, val=<value
optimized out>) at /build/buildd/glib2.0-2.20.1/glib/gstring.c:813
#2 0x00007f3d343a6eee in ?? () from /usr/lib/libdbus-glib-1.so.2
#3 0x00007f3d343a7144 in dbus_g_type_get_struct () from
/usr/lib/libdbus-glib-1.so.2
#4 0x00000000004f854e in syncevo_report_array_new (end_time=1248948991,
reports=0xcde430)
at /mnt/eeepc/syncevolution/syncevolution/src/syncevo-dbus-server.cpp:383
Caller:
#4 0x00000000004f854e in syncevo_report_array_new (end_time=1248948991,
reports=0xcde430)
at /mnt/eeepc/syncevolution/syncevolution/src/syncevo-dbus-server.cpp:383
383 g_value_init (&val, SYNCEVO_REPORT_ARRAY_TYPE);
Current language: auto; currently c++
(gdb) p val
$2 = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0,
v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {
v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 =
0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
Types:
#define SYNCEVO_REPORT_TYPE (dbus_g_type_get_struct ("GValueArray",
G_TYPE_STRING, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT,
G_TYPE_INT, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT, G_TYPE_INT,
G_TYPE_INT, G_TYPE_INT, G_TYPE_INVALID))
typedef GValueArray SyncevoReport;
#define SYNCEVO_REPORT_ARRAY_TYPE (dbus_g_type_get_struct ("GValueArray",
G_TYPE_INT, dbus_g_type_get_collection ("GPtrArray", SYNCEVO_REPORT_TYPE)))
Segfault (related? Same function!):
Program received signal SIGSEGV, Segmentation fault.
type_get_qdata_L (node=<value optimized out>, quark=1) at
/build/buildd/glib2.0-2.20.1/gobject/gtype.c:3370
3370 /build/buildd/glib2.0-2.20.1/gobject/gtype.c: No such file or
directory.
in /build/buildd/glib2.0-2.20.1/gobject/gtype.c
(gdb) where
Reading in symbols for /build/buildd/glib2.0-2.20.1/gobject/gvalue.c...done.
#0 type_get_qdata_L (node=<value optimized out>, quark=1) at
/build/buildd/glib2.0-2.20.1/gobject/gtype.c:3370
#1 0x00007f3d33b0ce38 in IA__g_type_check_is_value_type (type=<value optimized
out>) at /build/buildd/glib2.0-2.20.1/gobject/gtype.c:3836
#2 0x00007f3d33b136fa in IA__g_value_init (value=0x7fff3c7ced70,
g_type=139900809550432) at /build/buildd/glib2.0-2.20.1/gobject/gvalue.c:173
#3 0x00007f3d343a8f52 in ?? () from /usr/lib/libdbus-glib-1.so.2
#4 0x00000000004f8609 in syncevo_report_array_new (end_time=1248948991,
reports=0xcde430)
at /mnt/eeepc/syncevolution/syncevolution/src/syncevo-dbus-server.cpp:384
#5 0x00000000004f9711 in syncevo_get_sync_reports (obj=0xc58400,
server=0xcb87e0 "scheduleworld_1", count=1, reports=0xcd0000,
error=0x7fff3c7cf810)
at /mnt/eeepc/syncevolution/syncevolution/src/syncevo-dbus-server.cpp:1059
#6 0x00000000004fdb92 in
dbus_glib_marshal_syncevo_BOOLEAN__STRING_INT_POINTER_POINTER
(closure=0x7fff3c7cf6c0, return_value=0x7fff3c7cf7c0,
n_param_values=5, param_values=0xc62400, invocation_hint=0x0,
marshal_data=0x4f9101) at dbus/interfaces/syncevo-dbus-glue.h:200
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months
[Bug 3009] interoperability with mobical.net
by bugzilla＠moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=3009
--- Comment #31 from pohly <patrick.ohly(a)intel.com> 2009-07-30 04:19:52 ---
(In reply to comment #30)
> (In reply to comment #28)
> > (In reply to comment #27)
> > > 4 'EXDATE': It has the same interpretation as scheduleworld but different
> > > from evolution for a specified time.
> >
> > Bug #4457, right?
> >
> > Given that we now have two servers with this behavior and ScheduleWorld is slow
> > with changing their server, perhaps we should really implement a workaround for
> > this in the Synthesis incoming script.
> Patrick, I found you have fixed bug $4457.
> Could it solve below 2 issues?
>
> 1.
> client server
> BEGIN:VCALENDAR BEGIN:VCALENDAR
> VERSION:2.0 VERSION:2.0
> BEGIN:VEVENT BEGIN:VEVENT
> SUMMARY:all day event SUMMARY:all day event
> DESCRIPTION:all day event DESCRIPTION:all day event
> DTEND;VALUE=DATE:20060407 | DTEND:20060406T225959Z
> DTSTART;VALUE=DATE:20060406 | DTSTART:20060405T230000Z
> END:VEVENT END:VEVENT
> END:VCALENDAR END:VCALENDAR
This is the problem that Dries mentioned at the beginning of this issue
(comment #7).
> The reason why 'DTSTART' and 'DTEND' has the time of '23:00' in the server's
> side is because the account's timezone is GMT +1:00
I think right fix is for the server a) to represent all-day events in iCalendar
2.0 as VALUE=DATE (avoids any kind of guessing on the client side) or if that
isn't possible, b) use floating time instead of UTC.
I haven't thought much about it, but perhaps we can relax the all-day detection
in the incoming script so that it detects UTC, adds the device's current GMT
offset, and only then compares against 00:00-23:59.
> 2.
> BEGIN:VCALENDAR BEGIN:VCALENDAR
> VERSION:2.0 VERSION:2.0
> BEGIN:VEVENT BEGIN:VEVENT
> SUMMARY:recurrence\, daily\, with e SUMMARY:recurrence\, daily\, with e
> xceptions xceptions
> DESCRIPTION:recurrs seven times\, e DESCRIPTION:recurrs seven times\, e
> xcluding (but counting) Friday and xcluding (but counting) Friday and
> Saturday Saturday
> DTEND:20060406T190000Z DTEND:20060406T190000Z
> DTSTART:20060406T183000Z DTSTART:20060406T183000Z
> EXDATE:20060407 | EXDATE:20060407T000000Z
> EXDATE:20060408 | EXDATE:20060408T000000Z
> RRULE:FREQ=DAILY;UNTIL=20060412T183 RRULE:FREQ=DAILY;UNTIL=20060412T183
> 000Z 000Z
> END:VEVENT END:VEVENT
> END:VCALENDAR END:VCALENDAR
No, this won't be fixed by my patch for the incoming script. First, it is not
applied to UTC events, like this one. Lukas argued that this additional check
is unnecessary, so we could change this. Second, more important, it does not
convert back from date+time (20060407T000000Z) to date (20060407).
It's interesting that Evolution at some point must have created EXDATE with
VALUE=DATE. I think the current version creates DATE-TIME and expects the time
to match, if one is given (#4457).
Can you check whether the time is really relevant for daily, weekly, yearly
recurrence? In other words, does Evolution properly skip occurrences in EXDATE
VALUE=DATE?
Then we might work around the issue above by stripping the time from EXDATEs.
For hourly recurrence it must be preserved and we need to convert to the
DTSTART timezone, as currently done as part of #4457.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11 years, 5 months