[Bug 5609] New: nightly testing: integrate syncevo-dbus-server testing
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=5609
Summary: nightly testing: integrate syncevo-dbus-server testing
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: High
Component: SyncEvolution
AssignedTo: yongsheng.zhu(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
Yongsheng, you were involved in setting up testing of syncevo-dbus-server in
the nightly testing, right?
Can you finish the work done by Junhui by:
- merging the relevant code into the main syncevolution repository,
in test or test/dbus (whatever is more suitable)
- integrating it properly into the cron job
At the moment, the cron job executes ~nightly/nightly.sh, which looks like
this:
rm -fr /tmp/test/*; cd ~/dbus-testing && sh dbus-session.sh python
getResult_send.py > run.log 2>&1
cd ~/syncevolution-testing; runtests all >run.log 2>&1
Doesn't that use the *old* syncevolution from the previous night for D-Bus
testing? That looks wrong.
Another problem is that D-Bus testing should be skipped if the necessary
binaries didn't compile.
--
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.
10 years, 9 months
[Bug 4835] New: N900: fails to synchronize with some kernel versions
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=4835
Summary: N900: fails to synchronize with some kernel versions
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ALL
Status: WAITING FOR UPSTREAM
Severity: major
Priority: High
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: patrick.ohly(a)intel.com
QAContact: jingke.zhang(a)intel.com
CC: jingke.zhang(a)intel.com, syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Depends on: 1371
Estimated Hours: 0.0
This issue seems related to the kernel. SyncEvolution + N900 works on some host
platforms and fails on others with:
# [2010-07-18 21:54:21.915] Connecting Bluetooth device with address
0C:DD:EF:9C:94:8B and channel 25
# [2010-07-18 21:54:22.191] OBEX progress
# [2010-07-18 21:54:22.246] Cancel disconncting process
# [2010-07-18 21:54:22.247] Server Alerted Sync init with SANFormat 12 failed,
trying with legacy format
# [2010-07-18 21:54:22.288] Connecting Bluetooth device with address
0C:DD:EF:9C:94:8B and channel 25
# [2010-07-18 21:54:22.340] OBEX progress
# [2010-07-18 21:54:22.367] Cancel disconncting process
# [2010-07-18 21:54:22.370] TransportException thrown at
> /work/runtests/head/syncevolution/src/syncevo/ObexTransportAgent.cpp:376
# [2010-07-18 21:54:22.371] ObexTransprotAgent: Underlying transport error
This issue is just a reminder that the problem exists. We (= the SyncEvolution
developers) cannot do anything about 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.
10 years, 9 months
[MeeGo Projects - Bug 7091] New: In Direct Sync Settings the checkboxes for send and receive are interchanged
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=7091
Summary: In Direct Sync Settings the checkboxes for send and
receive are interchanged
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: major
Priority: Undecided
Component: GTK UI
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: oliver.joos(a)freenet.ch
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-gtk-ui-bugs(a)meego.bugs
Estimated Hours: 0.0
I use SyncEvolution 1.0.1 on a Notebook running Ubuntu 10.04.
BUG DETAILED DESCRIPTIONS
The settings of a Direct-Sync Service (Bluetooth) shows two checkboxes, one to
"Send changes to MYPHONE" the other to "Receive changes from MYPHONE". The
labels of these two buttons are interchanged.
EXACT STEPS LEADING TO PROBLEM:
1. Start sync-ui
2. Press "Change or edit sync service"
3. Unfold a Direct Sync service
4. Check "Send changes to MYPHONE"
5. "Save and use" this unidirectional service
6. Test the service with "Sync Now"
EXPECTED OUTCOME: Changes in Evolution are transfered to MYPHONE, while changes
in MYPHONE are ignored and not sent to Evolution
ACTUAL OUTCOME: It does the opposite of what the checked checkbox label says.
USER IMPACT: This might cause data loss! E.g when installing a new Linux and
then running a Sync only with "Receive changes from MYPHONE" checked.
REPRODUCIBILITY: always
EXTRA SOFTWARE INSTALLED: none
--
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.
10 years, 9 months
[Bug 2566] New: Evolution contacts loose "Other" email-addresses when synced two-way with a Nokia S60
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=2566
Summary: Evolution contacts loose "Other" email-addresses when
synced two-way with a Nokia S60
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
URL: http://bugzilla.moblin.org/show_bug.cgi?id=10505
OS/Version: ---
Status: ASSIGNED
Severity: enhancement
Priority: Medium
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
Copied from http://bugzilla.moblin.org/show_bug.cgi?id=10505
Description From oliver-joos 2010-05-28 15:24:05 PST (-) [reply]
I use Evolution 2.28.1 on Ubuntu 9.10 and SyncEvolution 1.0beta3, compiled from
sources. I tried to sync contacts with my Nokia N81 (Symbian S60v3).
In Evolution a contact may have upto 4 email-addresses, each of type Home, Work
or Other. Multiple Home or Work addresses are sync'ed ok. But my phone seems to
dispose addresses of type "Other" that come from Evolution! When I then modify
other items of such a contact, then it is sync'ed back to Evolution - without
the "Other" addresses. They get lost on both sides!
The output shows that Evolution addresses of type "Other" seem to have no
"TYPE=" at all. Perhaps Symbian S60v3 does not like that.
EMAIL;TYPE=HOME:my_home@mail.com
EMAIL:my_other@mail.com
I am not sure, but I think I experienced similar problems with "Other" phone
numbers.
--
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.
10 years, 9 months
[Bug 6346] New: command line: different --source-property values for each source (type@addressbook)
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=6346
Summary: command line: different --source-property values for
each source (type@addressbook)
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: enhancement
Priority: Undecided
Component: SyncEvolution
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-default-bugs(a)meego.bugs
Estimated Hours: 0.0
http://syncevolution.org/development/http-server-howto currently lists multiple
different invocations to configure the server:
syncevolution --configure \
--source-property type=file:text/vcard:3.0 \
--source-property uri= \
--source-property evolutionsource=file://${datapath}/addressbook \
${peer} addressbook
syncevolution --configure \
--source-property type=file:text/calendar:2.0 \
--source-property uri= \
--source-property evolutionsource=file://${datapath}/calendar \
${peer} calendar
syncevolution --configure \
--source-property type=file:text/calendar:2.0 \
--source-property uri= \
--source-property evolutionsource=file://${datapath}/todo \
${peer} todo
syncevolution --configure \
--source-property type=file:text/plain:1.0 \
--source-property uri= \
--source-property evolutionsource=file://${datapath}/memo \
${peer} memo
syncevolution --configure \
--source-property type=virtual:text/calendar:2.0 \
--source-property uri= \
--source-property evolutionsource=calendar,todo \
${peer} calendar+todo
This would be much nicer using the following syntax:
syncevolution --configure \
--source-property uri= \
--source-property type@addressbook=file:text/vcard:3.0 \
--source-property evolutionsource@addressbook=file://${datapath}/addressbook
\
--source-property type@calendar=file:text/calendar:2.0 \
--source-property evolutionsource@calendar=file://${datapath}/calendar \
...
${peer}
Usually caveats apply when implementing this:
- deal with @<source> where <source> contains an = sign
- print errors where @<source> does not match an existing or listed source,
to detect typos
--
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.
10 years, 9 months
[Bug 1371] New: SAN fail when syncing with N900 phone
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=1371
Summary: SAN fail when syncing with N900 phone
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: ASSIGNED
Severity: major
Priority: High
Component: SyncEvolution
AssignedTo: syncevolution-bugs(a)meego.bugs
ReportedBy: jingke.zhang(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
This is from http://bugzilla.moblin.org/show_bug.cgi?id=10483
Description From ZhangJingke 2010-04-15 22:39:19 PST (-) [reply]
Created an attachment (id=4684)
--> (http://bugs.meego.com/attachment.cgi?id=4684) [details]
N900 connection failure log
syncevolution 0.9.99.20
Description:
===============
This is a regression. Sync with N900 will meet "SANFormat 12 failed", please
see the attachment.
------- Comment #1 From Chen Congwu 2010-04-15 22:57:08 PST (-) [reply] -------
It might be the phone is not responding for some reason, try reboot it..
------- Comment #2 From ZhangJingke 2010-04-15 23:12:37 PST (-) [reply] -------
(In reply to comment #1)
> It might be the phone is not responding for some reason, try reboot it..
I reboot phone, re-pair N900. Then it still fail with the same reason. :(
------- Comment #3 From Chen Congwu 2010-04-16 00:53:30 PST (-) [reply] -------
(In reply to comment #2)
That's strange, works on my environment..
> (In reply to comment #1)
> > It might be the phone is not responding for some reason, try reboot it..
>
> I reboot phone, re-pair N900. Then it still fail with the same reason. :(
------- Comment #4 From Chen Congwu 2010-04-16 02:17:38 PST (-) [reply] -------
(In reply to comment #2)
The connect system call will fail immediately with error code '104' (that is
'Connection reset by peer'),
that's different when failed with pairing problem, error code '111'
('Connection refused')
Any way, since it failed early enough before involving the Obex library, I
suspect it might be:
1) Phone side mess
2) Bluez library or driver change in the image
Jingke, could you
1) retest with another N900?
2) retest with an older image?
> (In reply to comment #1)
> > It might be the phone is not responding for some reason, try reboot it..
>
> I reboot phone, re-pair N900. Then it still fail with the same reason. :(
------- Comment #5 From ZhangJingke 2010-04-19 20:12:18 PST (-) [reply] -------
(In reply to comment #4)
> (In reply to comment #2)
> The connect system call will fail immediately with error code '104' (that is
> 'Connection reset by peer'),
> that's different when failed with pairing problem, error code '111'
> ('Connection refused')
> Any way, since it failed early enough before involving the Obex library, I
> suspect it might be:
> 1) Phone side mess
> 2) Bluez library or driver change in the image
>
> Jingke, could you
> 1) retest with another N900?
> 2) retest with an older image?
I tried another N900, still the same failure. So, is it the error of "Nokia
N900" template? I am sure N900 could sync in some old image.
------- Comment #6 From Chen Congwu 2010-04-20 00:44:36 PST (-) [reply] -------
(In reply to comment #5)
right, this is a real problem
>
> I tried another N900, still the same failure. So, is it the error of "Nokia
> N900" template? I am sure N900 could sync in some old image.
Actually the failing scenario is as following:
Moblin:
connect() OK
write() OBEX_Connect cmd
read() --104 (Connection reset by peer)
My PC:
connect() OK
write() OBEX_Connect cmd
read() OK
------
see the detailed strace log:
---Moblin---
bind(8, {sa_family=AF_BLUETOOTH, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 10) =
0
fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(8, F_SETFL, O_RDWR) = 0
fstat64(8, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR)
connect(8, {sa_family=AF_BLUETOOTH, sa_data="KO\324:\275\0\31\0\37\0\0\0\0\0"},
10) = 0
time(NULL) = 1271795229
write(8, "\200\0\25\20\0\177\377F\0\16SYNCML-SYNC", 21) = 21
gettimeofday({1271795229, 351568}, {240, 0}) = 0
open("/home/moblin/.cache/syncevolution/nokia
n900-2010-04-20-16-27/syncevolution-log.html", O_WRONLY|O_CREAT|O_APPEND, 0666)
= 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=21384, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb745b000
fstat64(9, {st_mode=S_IFREG|0644, st_size=21384, ...}) = 0
_llseek(9, 21384, [21384], SEEK_SET) = 0
write(9, "<li><i>[2010-04-20 16:27:09.351]"..., 61) = 61
close(9) = 0
munmap(0xb745b000, 4096) = 0
recv(5, 0x88cf218, 1023, MSG_PEEK|MSG_DONTWAIT) = -1 EAGAIN (Resource
temporarily unavailable)
poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN|POLLOUT}], 2, -1) = 1
([{fd=8, revents=POLLOUT}])
time(NULL) = 1271795229
select(9, [8], NULL, NULL, {1, 0}) = 1 (in [8], left {0, 986552})
read(8, 0x88b2ce8, 3) = -1 ECONNRESET (Connection reset by
peer)
-----------
--PC--
bind(8, {sa_family=AF_BLUETOOTH, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 10) =
0
fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(8, F_SETFL, O_RDWR) = 0
fstat64(8, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR)
connect(8, {sa_family=AF_BLUETOOTH, sa_data="KO\324:\275\0\31\0\37\0\0\0\0\0"},
10) = 0
time(NULL) = 1271748604
write(8, "\200\0\25\20\0\177\377F\0\16SYNCML-SYNC", 21) = 21
gettimeofday({1271748604, 731927}, {4294966816, 0}) = 0
open("/home/cchen35/.cache/syncevolution/n900-2010-04-20-15-30/syncevolution-log.html",
O_WRONLY|O_CREAT|O_APPEND, 0666) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=21220, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7851000
fstat64(9, {st_mode=S_IFREG|0644, st_size=21220, ...}) = 0
_llseek(9, 21220, [21220], SEEK_SET) = 0
write(9, "<li><i>[2010-04-20 01:30:04.731]"..., 61) = 61
close(9) = 0
munmap(0xb7851000, 4096) = 0
recv(5, 0x9c61160, 1023, MSG_PEEK|MSG_DONTWAIT) = -1 EAGAIN (Resource
temporarily unavailable)
poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN|POLLOUT}], 2, -1) = 1
([{fd=8, revents=POLLOUT}])
time(NULL) = 1271748604
select(9, [8], NULL, NULL, {1, 0}) = 1 (in [8], left {0, 911726})
read(8, "\240\0\32", 3) = 3
read(8, "\20\0\4\0\313K\315Y\241J\0\16SYNCML-SYNC", 23) = 23
----------
------- Comment #7 From pohly 2010-04-26 06:43:34 PST (-) [reply] -------
Congwu, Jingke, what is the status regarding this issue?
We agreed that this looks like a regression in the underlying Bluetooth
transports (Bluez, kernel). To proof that, we need to find an old image where
this kind of sync still works, then install the same SyncEvolution version on a
recent image and show that it fails. If SyncEvolution is the same in this test
but the OS is not, then it should be investigated by the OS maintainers.
--
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.
10 years, 9 months
[Bug 5819] New: syncevo-dbus-server: does not honor disabling of autosync
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=5819
Summary: syncevo-dbus-server: does not honor disabling of
autosync
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: major
Priority: High
Component: SyncEvolution
AssignedTo: yongsheng.zhu(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
BUILD IMAGE(yyyy-mm-dd): MeeGo 1.0
HARDWARE MODEL (on what HW this bug is uncovered): na
BUG DETAILED DESCRIPTIONS
===========================================================
Enable automatic syncing. To simplify testing, set autoSyncInterval to
something small (1 min). Disable automatic syncing. Automatic syncing
continues.
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. syncevolution --configure --sync-property autoSync=1 --sync-property
autoSyncDelay=0 --sync-property autoSyncInterval=1m <config>
2. wait until syncing starts
3. syncevolution --configure --sync-property autoSync=0 <config>
EXPECTED OUTCOME:
===================
No more automatic syncs.
ACTUAL OUTCOME:
===================
Syncing continues at the selected interval.
Yongsheng, do you have time to look into 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.
10 years, 9 months
[MeeGo Projects - Bug 6898] New: Backend: notebook missing in KCal backend
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=6898
Summary: Backend: notebook missing in KCal backend
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Medium
Component: SyncEvolution
AssignedTo: qiankun.miao(a)intel.com
ReportedBy: qiankun.miao(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
Now, notebook is not available in KCal backend. Notebook can be used to
distinguish different types of calender/todo. It describes an item and allows
operating many items with the same notebook meanwhile. Items can be saved into
different databases according its notebook, which is useful.
--
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.
10 years, 9 months
[Bug 6369] New: Error reporting in HTTP server is sucky (Or: HTTP server ignores LogOutput dbus signals)
by bugzilla＠meego.com
http://bugs.meego.com/show_bug.cgi?id=6369
Summary: Error reporting in HTTP server is sucky (Or: HTTP
server ignores LogOutput dbus signals)
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: matthijs(a)stdin.nl
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-default-bugs(a)meego.bugs
Estimated Hours: 0.0
I've been trying to get the HTTP server running, but I got the following output
after connecting with a client.
matthijs@login:~$ syncevo-http-server http://localhost:9000/sync
POST from 178.226.74.128 config type application/vnd.syncml+wbxml session None
args {} length 1795
requesting new session
SessionChanged: /org/syncevolution/Session/7414306401283853336 1
connection /org/syncevolution/Connection/7414306401283853336 went down
ERROR:dbus.connection:Exception in handler for D-Bus signal:
Traceback (most recent call last):
File "/var/lib/python-support/python2.5/dbus/connection.py", line 214, in
maybe_handle_message
self._handler(*args, **kwargs)
File "/usr/bin/syncevo-http-server", line 68, in abort
self.destruct(http.INTERNAL_SERVER_ERROR, "lost connection to
SyncEvolution")
File "/usr/bin/syncevo-http-server", line 60, in destruct
self.connection.Close(False, message)
File "/var/lib/python-support/python2.5/dbus/proxies.py", line 140, in
__call__
**keywords)
File "/var/lib/python-support/python2.5/dbus/connection.py", line 607, in
call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Close" with
signature "bs" on interface "org.syncevolution.Connection" doesn't exist
This seems like there is something wrong with the dbus interface specs or
something. However, it turns out there is a really simple configuration
problem. Running dbus-monitor shows the real error (the first two signals are
relevant).
signal sender=:1.46 -> dest=(null destination) path=/org/syncevolution/Server;
interface=org.syncevolution.Server; member=LogOutput
object path "/org/syncevolution/Session/7414306401283853336"
string "SHOW"
string "First ERROR encountered: no sources active, check configuration"
signal sender=:1.46 -> dest=(null destination) path=/org/syncevolution/Server;
interface=org.syncevolution.Server; member=LogOutput
object path "/org/syncevolution/Session/7414306401283853336"
string "SHOW"
string "
"
signal sender=:1.46 -> dest=(null destination) path=/org/syncevolution/Server;
interface=org.syncevolution.Server; member=LogOutput
object path "/org/syncevolution/Session/7414306401283853336"
string "DEBUG"
string "done with connection to 'syncevo-server-http.py (HTTP)'
unexpectedly"
signal sender=:1.46 -> dest=(null destination)
path=/org/syncevolution/Connection/7414306401283853336;
interface=org.syncevolution.Connection; member=Abort
signal sender=:1.46 -> dest=(null destination)
path=/org/syncevolution/Session/7414306401283853336;
interface=org.syncevolution.Session; member=StatusChanged
string "done"
uint32 10500
array [
dict entry(
string "addressbook"
struct {
string "none"
string "idle"
uint32 0
}
)
dict entry(
string "calendar"
struct {
string "none"
string "idle"
uint32 0
}
)
dict entry(
string "memo"
struct {
string "none"
string "idle"
uint32 0
}
)
dict entry(
string "todo"
struct {
string "none"
string "idle"
uint32 0
}
)
]
signal sender=:1.46 -> dest=(null destination) path=/org/syncevolution/Server;
interface=org.syncevolution.Server; member=SessionChanged
object path "/org/syncevolution/Session/7414306401283853336"
boolean false
method call sender=:1.51 -> dest=:1.46
path=/org/syncevolution/Connection/7414306401283853336;
interface=org.syncevolution.Connection; member=Close
boolean false
string "lost connection to SyncEvolution"
error sender=:1.46 -> dest=:1.51
error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=17
string "Method "Close" with signature "bs" on interface
"org.syncevolution.Connection" doesn't exist
It seems like the dbus server uses signals to return log lines, but the http
server does not seem to show them, making them lost in the void. This makes
setting up the HTTP server a bit of challenge :-)
--
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.
10 years, 9 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.
10 years, 10 months