[MeeGo Projects - Bug 10265] New: Sync must be executed twice to really transfer calendar events
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=10265
Summary: Sync must be executed twice to really transfer
calendar events
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Handset
Architecture: ARM
Status: NEW
Severity: normal
Priority: Medium
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: meego(a)misc.lka.org.lu
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
BUILD IMAGE(X.X.XX.X.XXXXXXXX.X - (e.g.:
meego-netbook-ia32-1.0.90.0.20100831.1)):
HARDWARE MODEL (on what HW this bug is uncovered):
Nokia N900
BUG DETAILED DESCRIPTIONS
===========================================================
I'm using syncevolution to keep my caldav calendar and my Nokia N900 calendar
in sync. On the PC (caldav) I've got syncevolution 1.1 running as http server,
whereas on the Nokia I have syncevolution 1.0 (no more recent image available)
running as http client.
I've noticed that it always takes two syncs to propagate modifications from
caldav to the N900. The first sync doesn't perform any modifications, but the
second does all right. Workaround is to just call it twice from my script, but
of course, this also takes twice as long
Clocks of both machines are synchronized within a second (... should that even
matter?)
EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
===========================================================
1. Add a new event in the caldav calendar (using thunderbird for instance)
2. Do a sync, sync says 0 modifications done
3. Consult N900 calendar: event not there
4. Do another sync, sync says 1 modification done
5. Consult N900 calendar: event is not present.
EXPECTED OUTCOME:
===================
Event should be visible after first sync
ACTUAL OUTCOME:
===================
Even not visible after first sync. Only appears after another sync
USER IMPACT:
===================
Slower sync due to the need to do it twice. If user unaware of this, could lead
to scheduling conflicts and/or missed meetings.
REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
=====================================
always
EXTRA SOFTWARE INSTALLED:
============================
OTHER COMMENTS:
===================
- Didn't seem to occur with 0.9 version on the N900 that I had earlier.
- For good measure, I quit thunderbird before doing the sync, just to make sure
that it had actually pushed the events to caldav.
- I also made sure to wait a minute between adding the events and doing the
sync, in order to really exclude any clock difference issues.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
11 years, 5 months
[MeeGo Projects - Bug 10131] New: EXDATE ignored by SonyEricsson t700 calendar
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=10131
Summary: EXDATE ignored by SonyEricsson t700 calendar
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: karlrt(a)gmx.net
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
BUILD IMAGE(X.X.XX.X.XXXXXXXX.X - (e.g.:
meego-netbook-ia32-1.0.90.0.20100831.1)):
HARDWARE MODEL (on what HW this bug is uncovered): T700
BUG DETAILED DESCRIPTIONS
===========================================================
EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
===========================================================
1.create reoccuring event (due to bug 10092 without the "until" option, either
indefinitly or repeated n times) with evolution or mobile phone
2.add exeption to one of the events (only works in evolution)
3.sync
EXPECTED OUTCOME:
===================
SE should handle the event correctly: at date of exeption, there should be no
event in the calendar
ACTUAL OUTCOME:
===================
SE ignores the EXDATE values in the ics file: the event shows up at all dates,
even on the specified exeptions
USER IMPACT:
===================
usability to view a calendar on SE gets very low, lots of events are
reoccuring, and the exeptions are often the most important part of it.
REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
=====================================
always
EXTRA SOFTWARE INSTALLED:
============================
OTHER COMMENTS:
===================
The only solution i could think of was to split up the n-repeated event into n
different events so SE could view them correctly.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
11 years, 5 months
[MeeGo Projects - Bug 9600] New: Nokia phones (N97): *updated* calendar events not accepted by phone
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=9600
Summary: Nokia phones (N97): *updated* calendar events not
accepted by phone
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncML
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-syncml-bugs(a)meego.bugs
Estimated Hours: 0.0
Steps to reproduce:
* sync calendar
* update event in Evolution
* sync again
Error encountered:
* bad status ("some changes could not be transferred (local, status 22001)"),
update not transferred to phone
Only occurs for events which contain time zone information. Sending the time
zone information is necessary for recurring events (phone time zone Germany,
event in US: shift from summer to winter time is different).
Originally reported for Nokia 6620 Classic, but also occurs with N97.
Some comments:
* Despite sending with time zone information, the N97 still gets the shift
between summer and winter time wrong:
BEGIN:VCALENDAR
VERSION:1.0
DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;-07;20110313T100000Z;20101=
107T090000Z;;freeassociation.sourceforge.net;Tzfile;America;Los_An=
geles
BEGIN:VEVENT
TZ:-08:00
LAST-MODIFIED:20101102T104802Z
DCREATED:20101102T103104Z
CLASS:PUBLIC
SUMMARY:Los Angeles
DESCRIPTION:modified - again
DTSTART:20101103T133000Z
RRULE:W1 WE 20101117T143000Z
DTEND:20101103T134000Z
AALARM:20101103T131500Z;;;Los Angeles
DALARM:20101103T131500Z;;;Los Angeles
END:VEVENT
END:VCALENDAR
On 2010-11-02, this occurs at 14:30 German time (+8:00 difference). In the
following weeks, it should occur at 15:30 (+9:00 difference), but the phone
continues to show it at 14:30.
* the phone sends time zone information like this:
BEGIN:VCALENDAR
VERSION:1.0
TZ:+01
DAYLIGHT:TRUE;+02;20100328T010000Z;20101031T010000Z;;
BEGIN:VEVENT
SUMMARY:On phone
DTSTART:20101028T060000Z
DTEND:20101028T070000Z
CLASS:PRIVATE
RRULE:W1 TH 20101216T080000
LAST-MODIFIED:20101102T104955Z
PRIORITY:2
END:VEVENT
END:VCALENDAR
Hypothesis: including the zone name and using QUOTED-PRINTABLE breaks parsing
of time zone information, causing both the incorrect displaying of the event
and updating it.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
11 years, 5 months
[MeeGo Projects - Bug 9949] New: UI does not actually connect to Presence signal
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=9949
Summary: UI does not actually connect to Presence signal
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: GTK UI
AssignedTo: jku(a)linux.intel.com
ReportedBy: jku(a)linux.intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-gtk-ui-bugs(a)meego.bugs
Estimated Hours: 0.0
Presence changes are not actually working in the UI (so "sync now" is sensitive
even when offline): there's a typo in the signal name in the g_signal_connect
call.
I'll fix this.
--
Configure bugmail: http://bugs.meego.com/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
[MeeGo Projects - Bug 11044] New: temporary UID mapping
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=11044
Summary: temporary UID mapping
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: major
Priority: High
Component: SyncML
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-syncml-bugs(a)meego.bugs
Estimated Hours: 0.0
This possibly explains random problems when syncing with phones which have a
short maximum ID size. Not entirely sure (no logs of such failures).
------------------------------------------------
From: Patrick Ohly <patrick.ohly(a)intel.com>
To: Lukas Zeller <luz(a)synthesis.ch>
Cc: Synthesis <os-libsynthesis(a)synthesis.ch>
Subject: [os-libsynthesis] temporary UID mapping
Date: Wed, 8 Dec 2010 11:22:22 +0000 (08.12.2010 12:22:22)
Hello!
The Synthesis engine has the feature that its backends are allowed to
use IDs of arbitrary length. The engine will translate into IDs shorter
than the maximum ID size supported by the peer.
TLocalEngineDS::adjustLocalIDforSize() creates these temporary IDs,
using:
fTempGUIDMap.size() + 1
// as list only grows, we have unique tempuids for sure
I'm currently (involuntarily ;-) stress-testing this code by running
SyncEvolution<->SyncEvolution syncs with lots of iCalendar 2.0 items,
which happen to have very long IDs.
I see failures where the server assigns the same temporary ID to
different items in the same sync.
I've added debug logging. It shows that the following happens:
1. fTempGUIDMap is restored from the map file such that it has 105
entries, *but* these are non-contiguous (from #1 to #124).
2. fTempGUIDMap.size() + 1 is #106, which already exists in
fTempGUIDMap.
3. Overwriting that entry does not increase fTempGUIDMap.size().
4. A second item is assigned the same #106 temp ID.
I don't know exactly how I arrived at this state. Is the on-disk dump of
fTempGUIDMap really meant to preserve all temporary IDs in perpetuity? I
don't think so, because that would fill up the disk and there is a
"delete map item" operation.
Unless there is some additional constraint, then the assumption that
"the list only grows" is wrong. I have added a workaround which checks
for ID collisions in TLocalEngineDS::adjustLocalIDforSize(). Is that the
right solution or do I need to search for the reason why the mapping has
gaps?
Also note that I end up with a temporary ID which must have been used
before in an older sync session. Could that be a problem?
--------------------------------------------------------
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
11 years, 5 months
[MeeGo Projects - Bug 7889] New: vCard CELL phone mangling: removal of WORK and HOME flags
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=7889
Summary: vCard CELL phone mangling: removal of WORK and HOME
flags
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
Our Synthesis configuration removes WORK and HOME from CELL numbers if there is
only one such number, because Evolution gets confused by CELL;WORK or
CELL;HOME.
Matthijs Kooijman remarked on this:
------------------------------------
It turns out there is a little script to remove HOME
and WORK tags from cellphone numbers if there is only one cell phone.
However, it actually removes all tags except for CELL, so also PREF.
This patch seems to fix this problem properly:
diff --git a/src/syncevo/configs/scripting/05vcard-evolution.xml
b/src/syncevo/configs/scripting/05vcard-evolution.xml
index be79998..7c04950 100644
--- a/src/syncevo/configs/scripting/05vcard-evolution.xml
+++ b/src/syncevo/configs/scripting/05vcard-evolution.xml
@@ -13,7 +13,8 @@
i = i + 1;
}
if(cell_phones == 1) {
- TEL_FLAGS[wanted] = 0x10;
+ // HOME is 0x1, WORK is 0x2, remove only those flags.
+ TEL_FLAGS[wanted] = TEL_FLAGS[wanted] & ~0x3;
}
// Google sends TYPE=WORK and TYPE=HOME when it means
------------------------------------
If that works for Evolution, then it would be better solution. Need to check.
--
Configure bugmail: http://bugs.meego.com/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 6680] New: Explicit TZID is ignored when importing events.
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=6680
Summary: Explicit TZID is ignored when importing events.
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: Maemo 5
AssignedTo: ovek(a)debian.org
ReportedBy: monkeyiq(a)users.sourceforge.net
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-maemo5-bugs(a)meego.bugs
Estimated Hours: 0.0
BUILD IMAGE(X.X.XX.X.XXXXXXXX.X - (e.g.:
meego-netbook-ia32-1.0.90.0.20100831.1)): PR1.2
HARDWARE MODEL (on what HW this bug is uncovered): n900
BUG DETAILED DESCRIPTIONS
===========================================================
EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
===========================================================
1. Have multiple clients using a syncml server and syncevolution to sync
calendar data
2. Setup n900 and syncevolution --sync refresh-from-server xxx calendar
3. See events which have a timezone have the TZ ignored and become UTC without
any offset applied (ie, 8:00 localtime in GMT+10 becomes 18:00 in GMT+10).
4.
5.
EXPECTED OUTCOME:
===================
The timezone from the TZID, TZNAME, DTSTART should be preserved or when
converting to UTC it should be taken into account. I'm not sure what is
actually dropping the info, it seems that syncevolution knows about the
timezones from the entries (looking at syncevolution-log.html)
ACTUAL OUTCOME:
===================
One the desktop a specific calendar.after
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane
X-LIC-LOCATION:Australia/Brisbane
BEGIN:STANDARD
TZNAME:EST
DTSTART:19700301T020000
TZOFFSETFROM:+1000
TZOFFSETTO:+1000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
...
UID:20100708T090537Z-2014-1006-1-2@myserverer
DTSTAMP:20100708T090537Z
DTSTART;TZID=/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane:
20100911T163000
DTEND;TZID=/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane:
20100911T210000
On the n900 calendar.after using --sync refresh-from-server for the same vevent
file which has no BEGIN:VTIMEZONE.
DTSTART:20100911T163000Z
DTEND:20100911T210000Z
It appears that the DTSTART is preserved as Zulu time without any consideration
of the TZID. This effectively moves entries +10hrs in the calendar on the
device.
USER IMPACT:
===================
Calendar sync is not useful without timezone preservation.
REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
=====================================
always
EXTRA SOFTWARE INSTALLED:
============================
OTHER COMMENTS:
===================
I've tried setting /etc/timezone etc, but it appears that the actual TZ
information is in the data from the syncml server.
>From one of the syncevolution-log.html files, it seems that syncevolution knows
about the timezone:
...
- 18 : timestamp DTSTART [ 0, 0, 0] : 2010-09-11T16:30:00
(imported TZ: /freeassociation.sourceforge.net/Tzfile/Australia/Brisbane)
Is there a way to force syncevolution to convert to UTC and drop the timezone
so that the n900 doesn't get confused?
--
Configure bugmail: http://bugs.meego.com/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
[MeeGo Platform - Bug 8761] New: Syncevolution and daylight savings
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=8761
Summary: Syncevolution and daylight savings
Classification: MeeGo Platform
Product: OS Middleware
Version: 1.1
Platform: All
Architecture: ARM
Status: NEW
Severity: major
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: juergenoschumacher(a)gmx.de
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs
Estimated Hours: 0.0
HARDWARE MODEL (on what HW this bug is uncovered): Ubuntu Linux 10.04,
memotoo.com, Nokia N900
BUG DETAILED DESCRIPTIONS
===========================================================
EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
===========================================================
1. Evolution calender got out of sync; Evolution calender entries were all
doubled after a slow sinc
2. Deleted the calender on the server side at memotoo
3. Deleted the calender in Evolution
4. Restored the calender in Evolution from a backup
5. Performed a new sync with the server at memotoo
6. Most of the entries after the clock change on 31st of October appear to be
shifted by one hour backwards in Evolution
EXPECTED OUTCOME: Correct handling of time-zones while sincronizing
===================
ACTUAL OUTCOME:
===================
USER IMPACT:
===================
REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
=====================================
EXTRA SOFTWARE INSTALLED:
============================
OTHER COMMENTS:
===================
--
Configure bugmail: http://bugs.meego.com/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