7:06 p.m.
Hi,
I am currently experiencing difficulties using syncevolution 1.0beta2
and Evolution. When getting items from Scheduleworld, timezone
information is obviously lost. I am syncing two computers, one using SE
0.9.2, one using SE 1.0beta2. If I didn’t overlook something, it works
ok from 1.0beta2 → Scheduleworld → 0.9.2. But when getting items back
0.9.2 → Scheduleworld → 1.0beta2, calendar events are added using a Z
timezone.
In both cases, SE is from the syncevolution.org debian repository,
running Ubuntu 9.10/10.04 (same with both versions).
If I should provide more information, please tell me what you need and
how I should provide it.
Cheers,
Frederik
7:26 p.m.
On Tue, 2010-04-27 at 20:06 +0100, Frederik Elwert wrote:
I am currently experiencing difficulties using syncevolution
1.0beta2
and Evolution. When getting items from Scheduleworld, timezone
information is obviously lost. I am syncing two computers, one using SE
0.9.2, one using SE 1.0beta2. If I didn’t overlook something, it works
ok from 1.0beta2 → Scheduleworld → 0.9.2. But when getting items back
0.9.2 → Scheduleworld → 1.0beta2, calendar events are added using a Z
timezone.
In both cases, SE is from the syncevolution.org debian repository,
running Ubuntu 9.10/10.04 (same with both versions).
If I should provide more information, please tell me what you need and
how I should provide it.
Please provide log files at loglevel=4 for both directions (to
ScheduleWorld, from ScheduleWorld). The relevant piece is always the
treatment of the item data, which will be visible in the logs. Doing it
with one test event which shows the problem is sufficient.
--
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.
8:12 p.m.
Am Dienstag, den 27.04.2010, 21:26 +0200 schrieb Patrick Ohly:
Please provide log files at loglevel=4 for both directions (to
ScheduleWorld, from ScheduleWorld). The relevant piece is always the
treatment of the item data, which will be visible in the logs. Doing it
with one test event which shows the problem is sufficient.
As always, I’m not able to reproduce this with a test event. But I have
really plenty of events where this occured.
I now set loglevel to 4 in the configs and will wait until I stuble
across this again.
Cheers,
Frederik
12:58 p.m.
On Wed, 2010-04-28 at 21:12 +0100, Frederik Elwert wrote:
Am Dienstag, den 27.04.2010, 21:26 +0200 schrieb Patrick Ohly:
> Please provide log files at loglevel=4 for both directions (to
> ScheduleWorld, from ScheduleWorld). The relevant piece is always the
> treatment of the item data, which will be visible in the logs. Doing it
> with one test event which shows the problem is sufficient.
As always, I’m not able to reproduce this with a test event. But I have
really plenty of events where this occured.
I now set loglevel to 4 in the configs and will wait until I stuble
across this again.
The log that you sent me privately shows that this is mostly likely the
same issue as seen before for Outlook events:
http://bugs.meego.com/show_bug.cgi?id=1332
But in this case the timezone is using "Europe/Berlin". I thought we had
special code to detect this. Need to check this.
--
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.
5:46 p.m.
On Tue, 2010-05-04 at 13:58 +0100, Patrick Ohly wrote:
The log that you sent me privately shows that this is mostly likely
the
same issue as seen before for Outlook events:
http://bugs.meego.com/show_bug.cgi?id=1332
But in this case the timezone is using "Europe/Berlin". I thought we had
special code to detect this. Need to check this.
On which distro does the problem occur? You mentioned two different
Ubuntu releases. Which Evolution version do you use on the affected
platform?
I'm asking because it works for me here (Debian Testing with
self-compiled Evolution 2.28.x).
--
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.
9:14 p.m.
Am Dienstag, den 04.05.2010, 19:46 +0200 schrieb Patrick Ohly:
On which distro does the problem occur? You mentioned two different
Ubuntu releases. Which Evolution version do you use on the affected
platform?
I'm asking because it works for me here (Debian Testing with
self-compiled Evolution 2.28.x).
I upgraded both machines to Ubuntu Lucid with Evolution 2.28.3.
$ syncevolution --version
SyncEvolution 1.0beta2a
using libedataserver-1.2.so.11
using libebook-1.2.so.9
using libecal-1.2.so.7
using libecal-1.2.so.7
using libbluetooth.so.3
On the other machine (which originally sent the items to Scheduleworld),
I’m still using SyncEvolution 0.9.x. Could that cause the trouble?
Regards,
Frederik
8:10 a.m.
On Tue, 2010-05-04 at 22:14 +0100, Frederik Elwert wrote:
Am Dienstag, den 04.05.2010, 19:46 +0200 schrieb Patrick Ohly:
> On which distro does the problem occur? You mentioned two different
> Ubuntu releases. Which Evolution version do you use on the affected
> platform?
>
> I'm asking because it works for me here (Debian Testing with
> self-compiled Evolution 2.28.x).
I upgraded both machines to Ubuntu Lucid with Evolution 2.28.3.
$ syncevolution --version
SyncEvolution 1.0beta2a
using libedataserver-1.2.so.11
using libebook-1.2.so.9
using libecal-1.2.so.7
using libecal-1.2.so.7
using libbluetooth.so.3
On the other machine (which originally sent the items to Scheduleworld),
I’m still using SyncEvolution 0.9.x. Could that cause the trouble?
No, the problem is on the receiving end.
I have added more debug logging to the code. Would you mind trying out
1.0beta3+20100505+SE+913db88+SYSYNC+0328b9e from
http://downloads.syncevolution.org/tmp/ ?
I'll need a log file again which contains such an event being sent by
the server. Editing it on ScheduleWorld before the sync should do the
trick.
The amd64 version is available, i386 is still being compiled. I'll
upload it later.
--
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.
4:33 p.m.
Am Mittwoch, den 05.05.2010, 10:10 +0200 schrieb Patrick Ohly:
I have added more debug logging to the code. Would you mind trying
out
1.0beta3+20100505+SE+913db88+SYSYNC+0328b9e from
http://downloads.syncevolution.org/tmp/ ?
I can test this out, no problem. Will there be a i386 deb? Or should I
copy the files directly?
Regards,
Frederik
5:25 p.m.
On Thu, 2010-05-06 at 17:33 +0100, Frederik Elwert wrote:
Am Mittwoch, den 05.05.2010, 10:10 +0200 schrieb Patrick Ohly:
> I have added more debug logging to the code. Would you mind trying out
> 1.0beta3+20100505+SE+913db88+SYSYNC+0328b9e from
> http://downloads.syncevolution.org/tmp/ ?
I can test this out, no problem. Will there be a i386 deb? Or should I
copy the files directly?
There should have been one already, but the upload stalled and timed
out. I'm trying again now. The i386 build is slightly more recent
because of that.
--
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.
3:42 p.m.
Hello Patrick,
Am Mittwoch, den 05.05.2010, 10:10 +0200 schrieb Patrick Ohly:
I'll need a log file again which contains such an event being
sent by
the server. Editing it on ScheduleWorld before the sync should do the
trick.
After editing the affected events on ScheduleWorld and syncing again,
the timezone information is correct.
I’ll try editing such an event on the other machine, syncing it to SW
and then from there to this machine, but I cannot do this before Monday.
Cheers,
Frederik
12:05 p.m.
On Fri, 2010-05-07 at 16:42 +0100, Frederik Elwert wrote:
Hello Patrick,
Am Mittwoch, den 05.05.2010, 10:10 +0200 schrieb Patrick Ohly:
> I'll need a log file again which contains such an event being sent by
> the server. Editing it on ScheduleWorld before the sync should do the
> trick.
After editing the affected events on ScheduleWorld and syncing again,
the timezone information is correct.
I’ll try editing such an event on the other machine, syncing it to SW
and then from there to this machine, but I cannot do this before Monday.
Do you have more information on this failure?
--
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.
4:13 p.m.
Am Montag, den 17.05.2010, 14:05 +0200 schrieb Patrick Ohly:
Do you have more information on this failure?
Oh, sorry for not responding earlier. I tried it with your debug build,
but after a first successful sync, it kept crashing. I then went back to
beta3, and haven’t noticed the error until today.
Today, I synced some events, and with one, the error re-appeared (but
not with the other). Since I’m currently not using the debug build, I’m
afraid I can’t provide any new debug info. But I’ll try out the debug
build again, hoping that it will work this time.
Cheers,
Frederik
7:25 p.m.
On Mon, 2010-05-17 at 17:13 +0100, Frederik Elwert wrote:
Am Montag, den 17.05.2010, 14:05 +0200 schrieb Patrick Ohly:
> Do you have more information on this failure?
Oh, sorry for not responding earlier. I tried it with your debug build,
but after a first successful sync, it kept crashing.
That's definitely something that I need to know more about, too.
Otherwise we might end up with the same bug in 1.0 final.
--
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.
7:47 p.m.
Am Montag, den 17.05.2010, 21:25 +0200 schrieb Patrick Ohly:
On Mon, 2010-05-17 at 17:13 +0100, Frederik Elwert wrote:
> Oh, sorry for not responding earlier. I tried it with your debug build,
> but after a first successful sync, it kept crashing.
That's definitely something that I need to know more about, too.
Otherwise we might end up with the same bug in 1.0 final.
I tried again with the debug build, but it crashed again.
I’m not too familiar with gdb, but I tried to get a backtrace. If you
need more information, just tell me how to get it.
Cheers,
Frederik
$ gdb /usr/libexec/syncevo-dbus-server
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;...
Reading symbols from /usr/libexec/syncevo-dbus-server...done.
(gdb) run
Starting program: /usr/libexec/syncevo-dbus-server
[Thread debugging using libthread_db enabled]
[INFO] /usr/libexec/syncevo-dbus-server: ready to run
Program received signal SIGSEGV, Segmentation fault.
0x007ffee5 in sysync::loadSystemZoneDefinitions (aGZones=0x814b9dc)
at
/work/runtests/head/libsynthesis/src/platform_adapters/linux/platform_timezones.cpp:162
162 /work/runtests/head/libsynthesis/src/platform_adapters/linux/platform_timezones.cpp:
No such file or directory.
in /work/runtests/head/libsynthesis/src/platform_adapters/linux/platform_timezones.cpp
(gdb) bt
#0 0x007ffee5 in sysync::loadSystemZoneDefinitions (aGZones=0x814b9dc)
at
/work/runtests/head/libsynthesis/src/platform_adapters/linux/platform_timezones.cpp:162
#1 0x00795ffd in sysync::GZones::initialize (this=0x814b9dc)
at /work/runtests/head/libsynthesis/src/sysync/timezones.cpp:100
#2 0x006ed78b in sysync::TSyncAppBase::finishConfig (this=0x814b9d0)
at /work/runtests/head/libsynthesis/src/sysync/syncappbase.cpp:1418
#3 0x006eda2e in sysync::TSyncAppBase::readXMLConfigStream
(this=0x814b9d0,
aReaderFunc=0x6ecef0 <ConstantReader>, aContext=0xbfffe330)
at /work/runtests/head/libsynthesis/src/sysync/syncappbase.cpp:1734
#4 0x006edb14 in sysync::TSyncAppBase::readXMLConfigConstant
(this=0x814b9d0,
aConstantXML=0x8172b7c "<?xml version=\"1.0\"?>\n<!--
SYNTHESIS
SYNCML CLIENT Version 3.2 Configuration file -->\n\n<sysync_config
version=\"1.0\">\n\n <configvar name=\"logpath\" value=
\"$(defout_path)\"/>\n\n <!-- this string is output"...)
at /work/runtests/head/libsynthesis/src/sysync/syncappbase.cpp:1767
#5 0x0077e1c3 in sysync::TEngineInterface::InitEngineXML
(this=0x814b8b0,
aConfigXML=0x8172b7c "<?xml version=\"1.0\"?>\n<!-- SYNTHESIS
SYNCML
CLIENT Version 3.2 Configuration file -->\n\n<sysync_config version=
\"1.0\">\n\n <configvar name=\"logpath\"
value=\"$(defout_path)\"/>\n\n
<!-- this string is output"...)
at /work/runtests/head/libsynthesis/src/sysync/engineinterface.cpp:1190
#6 0x0077998d in sysync::InitEngineXML (aCB=0x814b8b4,
aConfigXML=0x8172b7c "<?xml version=\"1.0\"?>\n<!-- SYNTHESIS
SYNCML
CLIENT Version 3.2 Configuration file -->\n\n<sysync_config version=
\"1.0\">\n\n <conf---Type <return> to continue, or q <return>
to
quit---
igvar name=\"logpath\" value=\"$(defout_path)\"/>\n\n <!-- this
string
is output"...)
at /work/runtests/head/libsynthesis/src/sysync/engineentry.cpp:64
#7 0x0026fe47 in sysync::TEngineModuleBridge::InitEngineXML
(this=0x814c018,
aConfigXML=0x8172b7c "<?xml version=\"1.0\"?>\n<!-- SYNTHESIS
SYNCML
CLIENT Version 3.2 Configuration file -->\n\n<sysync_config version=
\"1.0\">\n\n <configvar name=\"logpath\"
value=\"$(defout_path)\"/>\n\n
<!-- this string is output"...)
at /work/runtests/head/libsynthesis/src/sysync_SDK/Sources/enginemodulebridge.cpp:69
#8 0x00199318 in SyncEvo::SharedEngine::InitEngineXML (this=0x813fa28,
aConfigXML=...)
at /work/runtests/head/syncevolution/src/syncevo/SynthesisEngine.cpp:48
#9 0x001e16ad in SyncEvo::SyncContext::initEngine (this=0x813f958,
logXML=false)
at /work/runtests/head/syncevolution/src/syncevo/SyncContext.cpp:2622
#10 0x001f754c in SyncEvo::SyncContext::sync (this=0x813f958,
report=0xbfffe658)
at /work/runtests/head/syncevolution/src/syncevo/SyncContext.cpp:2709
#11 0x001b8298 in SyncEvo::Cmdline::run (this=0x8146438)
at /work/runtests/head/syncevolution/src/syncevo/Cmdline.cpp:767
#12 0x080cb3b6 in CmdlineWrapper::run (this=0x8146388)
at /work/runtests/head/syncevolution/src/syncevo-dbus-server.cpp:2026
#13 0x080a1aeb in Session::run (this=0x8146198)
---Type <return> to continue, or q <return> to quit---
at /work/runtests/head/syncevolution/src/syncevo-dbus-server.cpp:3343
#14 0x080abb06 in DBusServer::run (this=0xbffff0b0)
at /work/runtests/head/syncevolution/src/syncevo-dbus-server.cpp:4791
#15 0x080b58ef in main (argc=1, argv=0xbffff3d4)
at /work/runtests/head/syncevolution/src/syncevo-dbus-server.cpp:5867
(gdb)
3:44 p.m.
Sorry to bring this up again. Can I provide any additional information?
Or is a new build planned any time soon?
Otherwise, I’d switch back to beta3, to be able to do my everyday syncs.
Cheers,
Frederik
Am Dienstag, den 18.05.2010, 21:47 +0200 schrieb Frederik Elwert:
Am Montag, den 17.05.2010, 21:25 +0200 schrieb Patrick Ohly:
> On Mon, 2010-05-17 at 17:13 +0100, Frederik Elwert wrote:
> > Oh, sorry for not responding earlier. I tried it with your debug build,
> > but after a first successful sync, it kept crashing.
>
> That's definitely something that I need to know more about, too.
> Otherwise we might end up with the same bug in 1.0 final.
I tried again with the debug build, but it crashed again.
I’m not too familiar with gdb, but I tried to get a backtrace. If you
need more information, just tell me how to get it.
8:05 p.m.
On Fri, 2010-05-21 at 16:44 +0100, Frederik Elwert wrote:
Sorry to bring this up again. Can I provide any additional
information?
Or is a new build planned any time soon?
Sorry for the delay, I'm on vacation right now (my wedding ceremony was
yesterday...).
Yes, there's one more thing that you can do: when it crashes, what's at
the end of the log in .cache?
I think it I know why it crashes (null pointer for system time zone
information), I just don't know why it doesn't find any. The log might
explain that.
Otherwise, I’d switch back to beta3, to be able to do my everyday
syncs.
Please, go back. If I need more tests, it'll be with another snapshot.
--
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.
2:24 p.m.
Am Sonntag, den 23.05.2010, 22:05 +0200 schrieb Patrick Ohly:
Yes, there's one more thing that you can do: when it crashes,
what's at
the end of the log in .cache?
I think it I know why it crashes (null pointer for system time zone
information), I just don't know why it doesn't find any. The log might
explain that.
Unfortunately, there is no log in .cache, not even a directory, it
seems. Maybe it crashes before it even has the log file in place?
Cheers,
Frederik
7:30 p.m.
On Mon, 2010-05-24 at 15:24 +0100, Frederik Elwert wrote:
Am Sonntag, den 23.05.2010, 22:05 +0200 schrieb Patrick Ohly:
> Yes, there's one more thing that you can do: when it crashes, what's at
> the end of the log in .cache?
>
> I think it I know why it crashes (null pointer for system time zone
> information), I just don't know why it doesn't find any. The log might
> explain that.
Unfortunately, there is no log in .cache, not even a directory, it
seems. Maybe it crashes before it even has the log file in place?
Perhaps the version that I had compiled didn't have the logging enabled
at that point. Anyway, I think I was able to reproduce and fix the
problem that you were seeing:
commit b4865677f5330b6b844190cacec794f1bfb3d380
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed May 26 18:44:04 2010 +0200
syncevo-dbus-server: first sync was done without libical time zone info (MBC #2435)
If (and only if) compiled with --enable-evolution-compatibility (as
the binaries on syncevolution.org), libical was only pulled into the
syncevo-dbus-server as part of running a sync. That was too late for
libsynthesis, which had already checked for libical earlier in that
sync session.
All following sync sessions then used libical time zone information.
The effect of not having libical time zone information were occasional
mismatches of time zones.
I have compiled another snapshot (version 1.0beta3+20100526+SE+b486567
+SYSYNC+a0b96cb) and made it available here:
http://downloads.syncevolution.org/tmp
If you want, upgrade to that one. Because it you were not able to
reproduce it reliably (no surprise, given that it only occurs when
synchronizing events directly in the first session after starting the
daemon, and then probably only for some time zone definitions) I don't
expect you to confirm that the problem is gone. But if you run that
version *and* it still occurs, then I need log files and will keep
searching.
--
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.
8:56 p.m.
Am Mittwoch, den 26.05.2010, 21:30 +0200 schrieb Patrick Ohly:
I have compiled another snapshot (version
1.0beta3+20100526+SE+b486567
+SYSYNC+a0b96cb) and made it available here:
http://downloads.syncevolution.org/tmp
If you want, upgrade to that one. Because it you were not able to
reproduce it reliably (no surprise, given that it only occurs when
synchronizing events directly in the first session after starting the
daemon, and then probably only for some time zone definitions) I don't
expect you to confirm that the problem is gone. But if you run that
version *and* it still occurs, then I need log files and will keep
searching.
Thank you for the information! I just installed that build and inform
you if I still notice any problems.
Cheers,
Frederik
4421
days inactive
4450
days old
syncevolution@synevolution.org
18 comments
2 participants
participants (2)
-
Frederik Elwert -
Patrick Ohly