9:10 a.m.
Hello,
as promised, I'm trying ([0]) to get libsynthesis 3.2.0.31+ds2-2 in
Ubuntu Lucid, but in the meanwhile I write you regarding the problem
that I mention in the end of [1]: in brief, on most syncronizations (for
instance, if I start evolution the first time for a given user, sync and
just sync again) syncevolution hangs (it print _nothing_ to the
terminal) and evolution-data-server-2.28 consumes all available CPU
cycles.
I thought this is a problem on the Evolution side, and that it will be
fixed in the two months that still separe us from the release... but I'd
like to know if this is something you know of, in particular because it
happens with libsynthesis 3.2.0.31+ds1-2 and 3.2.0.31+ds2-2, but not
with the syncevolution-evolution 0.9.2+1.0beta2a-2.
thanks
Pietro
[0]: https://bugs.launchpad.net/ubuntu/+source/libsynthesis/+bug/528326
[1]:
https://bugs.launchpad.net/ubuntu/+source/libsynthesis/+bug/528326/commen...
12:31 p.m.
as promised, I'm trying ([0]) to get libsynthesis 3.2.0.31+ds2-2
in
Ubuntu Lucid, but in the meanwhile I write you regarding the problem
that I mention in the end of [1]: in brief, on most syncronizations (for
instance, if I start evolution the first time for a given user, sync and
just sync again) syncevolution hangs (it print _nothing_ to the
terminal) and evolution-data-server-2.28 consumes all available CPU
cycles.
Hi Pietro;
I don't have that experience on debian unstable or testing. Maybe I am
not stressing the system as much as you are (I use only contacts, for
example).
I have some work-in-progress debian packaging of libsynthesis 3.4.0.5
git://git.debian.org/git/collab-maint/libsynthesis.git
and syncevolution 1.0 beta 2a
git://alioth.debian.org/git/collab-maint/syncevolution.git
At the moment I'm still tracking down an issue with the (generated)
dependencies in syncevolution, but it works fine for me if you install
the latest syncevolution and libsynthesis together.
d
5:32 p.m.
On Mon, 2010-03-01 at 22:10 +0000, Pietro Battiston wrote:
Hello,
as promised, I'm trying ([0]) to get libsynthesis 3.2.0.31+ds2-2 in
Ubuntu Lucid, but in the meanwhile I write you regarding the problem
that I mention in the end of [1]: in brief, on most syncronizations (for
instance, if I start evolution the first time for a given user, sync and
just sync again) syncevolution hangs (it print _nothing_ to the
terminal) and evolution-data-server-2.28 consumes all available CPU
cycles.
Sorry, this is not a known problem.
When you say "syncevolution", do you mean the command line tool?
When you attach gdb to both the syncevolution process and EDS, what do
the stack back traces tell you?
--
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:41 a.m.
Il giorno mar, 02/03/2010 alle 07.32 +0100, Patrick Ohly ha scritto:
On Mon, 2010-03-01 at 22:10 +0000, Pietro Battiston wrote:
> Hello,
> as promised, I'm trying ([0]) to get libsynthesis 3.2.0.31+ds2-2 in
> Ubuntu Lucid, but in the meanwhile I write you regarding the problem
> that I mention in the end of [1]: in brief, on most syncronizations (for
> instance, if I start evolution the first time for a given user, sync and
> just sync again) syncevolution hangs (it print _nothing_ to the
> terminal) and evolution-data-server-2.28 consumes all available CPU
> cycles.
Sorry, this is not a known problem.
When you say "syncevolution", do you mean the command line tool?
Yes: and I had forgot to mention that the version present in Karmic is
0.9.1+ds1-1 . However...
When you attach gdb to both the syncevolution process and EDS, what
do
the stack back traces tell you?
... today I installed an update of the evolution-* packages
( 2.28.3-0ubuntu2 ) and the problem disappeared.
sorry for the noise
Pietro
10:27 a.m.
Il giorno lun, 01/03/2010 alle 23.10 +0100, Pietro Battiston ha scritto:
Hello,
as promised, I'm trying ([0]) to get libsynthesis 3.2.0.31+ds2-2 in
Ubuntu Lucid
Apparently, I was _too_ good at it, since instead 3.4.0.5+ds1-1 was
adopted... (see [0] for details).
What hence I'm asking is: do you think there is any particular reason
why this brand new libsynthesis should have incompatibilities with an
older (0.9.1+ds1-1) version of syncevolution?
Tomorrow, I'll try to find the time to test personally the combination,
I'm asking just in case you already know that the thing won't work,
since in that case the sooner Ubuntu devs act, the better.
Thanks
Pietro
11:10 a.m.
On Mon, 2010-03-08 at 15:27 -0800, Pietro Battiston wrote:
What hence I'm asking is: do you think there is any particular
reason
why this brand new libsynthesis should have incompatibilities with an
older (0.9.1+ds1-1) version of syncevolution?
I can't think of any such reason.
Tomorrow, I'll try to find the time to test personally the
combination,
I'm asking just in case you already know that the thing won't work,
since in that case the sooner Ubuntu devs act, the better.
That would be good, because we typically don't test such combinations
ourselves.
--
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.
12:22 a.m.
On Mon, 2010-03-08 at 15:27 -0800, Pietro Battiston wrote:
What hence I'm asking is: do you think there is any particular
reason
why this brand new libsynthesis should have incompatibilities with an
older (0.9.1+ds1-1) version of syncevolution?
When I tried downgrading syncevolution w/o downgrading libsynthesis, I got
,----
| Fatal: Cannot connect to datastore implementation module specified in
<plugin_module>
| Fatal error 20010, no valid configuration could be read from XML file
| [ERROR] Synthesis XML config parser error
`----
The log in ~/.cache looks like
[2010-03-09 09:02:55.099] SyncML server account: XXXX
[2010-03-09 09:02:55.099] client: SyncEvolution 0.9.1 for desktop
[2010-03-09 09:02:55.099] device ID: XXXXXXXXXXXXXXXXXXXXXXXXXXX
[2010-03-09 09:03:00.381] creating
/home/bremner/.cache/syncevolution/scheduleworld-2010-03-09-09-02/addressbook.before
[2010-03-09
09:03:01.470] /home/bremner/.cache/syncevolution/scheduleworld-2010-03-09-09-02/addressbook.before
created
[2010-03-09 09:03:01.471] creating
/home/bremner/.cache/syncevolution/scheduleworld-2010-03-09-09-02/memo.before
[2010-03-09
09:03:01.471] /home/bremner/.cache/syncevolution/scheduleworld-2010-03-09-09-02/memo.before
created
[2010-03-09 09:03:01.472] creating
/home/bremner/.cache/syncevolution/scheduleworld-2010-03-09-09-02/todo.before
[2010-03-09
09:03:01.472] /home/bremner/.cache/syncevolution/scheduleworld-2010-03-09-09-02/todo.before
created
[2010-03-09 09:03:01.472] creating
/home/bremner/.cache/syncevolution/scheduleworld-2010-03-09-09-02/calendar.before
[2010-03-09
09:03:01.474] /home/bremner/.cache/syncevolution/scheduleworld-2010-03-09-09-02/calendar.before
created
[2010-03-09 09:03:03.030] Synthesis XML config parser error
I haven't explicitly invoked syncevolution --migrate, but I don't know
what leftover state there is from the 1.0beta2 install. Probably a
better test is to delete/move-aside .config/syncevolution and start
again. I don't have to time to test that now.
d
2:58 a.m.
On Tue, 2010-03-09 at 13:22 +0000, David Bremner wrote:
On Mon, 2010-03-08 at 15:27 -0800, Pietro Battiston wrote:
> What hence I'm asking is: do you think there is any particular reason
> why this brand new libsynthesis should have incompatibilities with an
> older (0.9.1+ds1-1) version of syncevolution?
When I tried downgrading syncevolution w/o downgrading libsynthesis, I got
,----
| Fatal: Cannot connect to datastore implementation module specified in
<plugin_module>
| Fatal error 20010, no valid configuration could be read from XML file
| [ERROR] Synthesis XML config parser error
`----
I can reproduce it, but not explain it. I traced it down to the new
engine expecting the "ReadBlob" function to be provided (which it isn't)
despite SyncEvolution saying that it doesn't support it
("plugin_datablob:no").
I haven't explicitly invoked syncevolution --migrate, but I
don't know
what leftover state there is from the 1.0beta2 install. Probably a
better test is to delete/move-aside .config/syncevolution and start
again. I don't have to time to test that now.
That won't help, I'm afraid.
I'm running out of time now. The next step would be to find the oldest
libsynthesis that still works with 0.9.1. But I wonder whether that is
really useful?
--
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:23 a.m.
On Tue, 2010-03-09 at 15:58 +0000, Patrick Ohly wrote:
On Tue, 2010-03-09 at 13:22 +0000, David Bremner wrote:
> On Mon, 2010-03-08 at 15:27 -0800, Pietro Battiston wrote:
> > What hence I'm asking is: do you think there is any particular reason
> > why this brand new libsynthesis should have incompatibilities with an
> > older (0.9.1+ds1-1) version of syncevolution?
>
> When I tried downgrading syncevolution w/o downgrading libsynthesis, I got
>
> ,----
> | Fatal: Cannot connect to datastore implementation module specified in
<plugin_module>
> | Fatal error 20010, no valid configuration could be read from XML file
> | [ERROR] Synthesis XML config parser error
> `----
I can reproduce it, but not explain it. I traced it down to the new
engine expecting the "ReadBlob" function to be provided (which it isn't)
despite SyncEvolution saying that it doesn't support it
("plugin_datablob:no").
The root cause is in this commit:
commit d9b59bad47fedba0a74240c394c2f7f3dc9b4f7f
Author: Beat Forster <elisabethegli(a)beat-forsters-macbook-pro.local>
Date: Thu Dec 3 19:03:07 2009 +0100
JNI/Java: Several bug fixes and enhancements - Preparing com/sysync package
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 833) cAppCharP
vda= Plugin_DS_Admin;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 834) if (!Supported(
VP_InsertMapItem )) vda= Plugin_DS_Admin_OLD;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 835) cAppCharP
vdd= Plugin_DS_Data;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 836) if (!Supported( VP_FLI_DSS
)) vdd= Plugin_DS_Data_OLD2;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 837) if (!Supported( VP_ResumeToken
)) vdd= Plugin_DS_Data_OLD1;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 838) cAppCharP
vdb= Plugin_DS_Blob;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 839) if (!Supported(
VP_BLOB_JSignature )) vdb= Plugin_DS_Blob_OLD2; // new BLOB signature
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 840) if (!Supported( VP_DeleteBlob
)) vdb= Plugin_DS_Blob_OLD1;
I end up with vdb = Plugin_DS_Blob_OLD2 = "plugin_datablob_OLD2". This
is later checked in FlagOK(). Because there is no explicit
"plugin_datablob_OLD2=no" in SyncEvolution, the Synthesis engine tries
to find the ReadBlob function and fails.
I'm not sure what a proper solution is. It seems to me that instead of
renaming the "plugin_datablob" string by appending "_OLD2", the
engine
should have introduced a "plugin_datablob_NEW" version.
I'm running out of time now. The next step would be to find the
oldest
libsynthesis that still works with 0.9.1. But I wonder whether that is
really useful?
Attached is a minimal patch which makes the most recent libsynthesis
(and thus 3.4.0.5+ds1-1) work again with SyncEvolution 0.9.1. I suspect
that it might break SyncEvolution 1.0 which does support blobs
(presumably using the current blob API), but that is a problem that we
can deal with later.
Pietro, is this something that could be added to the Ubuntu .deb of
libsynthesis as a quick fix? The only alternatives that I see are:
* fall back to libsynthesis_3.2.0.35
* recompile 0.9.1 with libsynthesissdk.a from 3.2.0.45 (untested!)
* upgrade SyncEvolution to 1.0 beta
1.0 beta works because the if (!Supported()) checks result in false and
thus vdb remains at "plugin_datablob". I suspect that this might also
work when compiling 0.9.1 with a more recent libsynthesissdk.a.
--
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:41 a.m.
Il giorno mar, 09/03/2010 alle 09.23 -0800, Patrick Ohly ha scritto:
On Tue, 2010-03-09 at 15:58 +0000, Patrick Ohly wrote:
> On Tue, 2010-03-09 at 13:22 +0000, David Bremner wrote:
> > On Mon, 2010-03-08 at 15:27 -0800, Pietro Battiston wrote:
> > > What hence I'm asking is: do you think there is any particular
reason
> > > why this brand new libsynthesis should have incompatibilities with an
> > > older (0.9.1+ds1-1) version of syncevolution?
> >
> > When I tried downgrading syncevolution w/o downgrading libsynthesis, I got
> >
> > ,----
> > | Fatal: Cannot connect to datastore implementation module specified in
<plugin_module>
> > | Fatal error 20010, no valid configuration could be read from XML file
> > | [ERROR] Synthesis XML config parser error
> > `----
>
> I can reproduce it, but not explain it. I traced it down to the new
> engine expecting the "ReadBlob" function to be provided (which it
isn't)
> despite SyncEvolution saying that it doesn't support it
> ("plugin_datablob:no").
The root cause is in this commit:
commit d9b59bad47fedba0a74240c394c2f7f3dc9b4f7f
Author: Beat Forster <elisabethegli(a)beat-forsters-macbook-pro.local>
Date: Thu Dec 3 19:03:07 2009 +0100
JNI/Java: Several bug fixes and enhancements - Preparing com/sysync package
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 833) cAppCharP
vda= Plugin_DS_Admin;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 834) if (!Supported(
VP_InsertMapItem )) vda= Plugin_DS_Admin_OLD;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 835) cAppCharP
vdd= Plugin_DS_Data;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 836) if (!Supported( VP_FLI_DSS
)) vdd= Plugin_DS_Data_OLD2;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 837) if (!Supported( VP_ResumeToken
)) vdd= Plugin_DS_Data_OLD1;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 838) cAppCharP
vdb= Plugin_DS_Blob;
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 839) if (!Supported(
VP_BLOB_JSignature )) vdb= Plugin_DS_Blob_OLD2; // new BLOB signature
d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 840) if (!Supported( VP_DeleteBlob
)) vdb= Plugin_DS_Blob_OLD1;
I end up with vdb = Plugin_DS_Blob_OLD2 = "plugin_datablob_OLD2". This
is later checked in FlagOK(). Because there is no explicit
"plugin_datablob_OLD2=no" in SyncEvolution, the Synthesis engine tries
to find the ReadBlob function and fails.
I'm not sure what a proper solution is. It seems to me that instead of
renaming the "plugin_datablob" string by appending "_OLD2", the
engine
should have introduced a "plugin_datablob_NEW" version.
> I'm running out of time now. The next step would be to find the oldest
> libsynthesis that still works with 0.9.1. But I wonder whether that is
> really useful?
Attached is a minimal patch which makes the most recent libsynthesis
(and thus 3.4.0.5+ds1-1) work again with SyncEvolution 0.9.1. I suspect
that it might break SyncEvolution 1.0 which does support blobs
(presumably using the current blob API), but that is a problem that we
can deal with later.
Pietro, is this something that could be added to the Ubuntu .deb of
libsynthesis as a quick fix? The only alternatives that I see are:
* fall back to libsynthesis_3.2.0.35
* recompile 0.9.1 with libsynthesissdk.a from 3.2.0.45 (untested!)
* upgrade SyncEvolution to 1.0 beta
1.0 beta works because the if (!Supported()) checks result in false and
thus vdb remains at "plugin_datablob". I suspect that this might also
work when compiling 0.9.1 with a more recent libsynthesissdk.a.
Thank you very much for your attention... I will certainly test the
patch, once you do attach it, and then ask to the Ubuntu developers what
option they prefer!
Pietro
6:01 a.m.
Il giorno mar, 09/03/2010 alle 18.41 +0100, Pietro Battiston ha scritto:
Il giorno mar, 09/03/2010 alle 09.23 -0800, Patrick Ohly ha scritto:
> On Tue, 2010-03-09 at 15:58 +0000, Patrick Ohly wrote:
> > On Tue, 2010-03-09 at 13:22 +0000, David Bremner wrote:
> > > On Mon, 2010-03-08 at 15:27 -0800, Pietro Battiston wrote:
> > > > What hence I'm asking is: do you think there is any particular
reason
> > > > why this brand new libsynthesis should have incompatibilities with
an
> > > > older (0.9.1+ds1-1) version of syncevolution?
> > >
> > > When I tried downgrading syncevolution w/o downgrading libsynthesis, I got
> > >
> > > ,----
> > > | Fatal: Cannot connect to datastore implementation module specified in
<plugin_module>
> > > | Fatal error 20010, no valid configuration could be read from XML file
> > > | [ERROR] Synthesis XML config parser error
> > > `----
> >
> > I can reproduce it, but not explain it. I traced it down to the new
> > engine expecting the "ReadBlob" function to be provided (which it
isn't)
> > despite SyncEvolution saying that it doesn't support it
> > ("plugin_datablob:no").
>
> The root cause is in this commit:
>
> commit d9b59bad47fedba0a74240c394c2f7f3dc9b4f7f
> Author: Beat Forster <elisabethegli(a)beat-forsters-macbook-pro.local>
> Date: Thu Dec 3 19:03:07 2009 +0100
>
> JNI/Java: Several bug fixes and enhancements - Preparing com/sysync package
>
>
> d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 833) cAppCharP
vda= Plugin_DS_Admin;
> d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 834) if (!Supported(
VP_InsertMapItem )) vda= Plugin_DS_Admin_OLD;
> d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 835) cAppCharP
vdd= Plugin_DS_Data;
> d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 836) if (!Supported(
VP_FLI_DSS )) vdd= Plugin_DS_Data_OLD2;
> d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 837) if (!Supported(
VP_ResumeToken )) vdd= Plugin_DS_Data_OLD1;
> d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 838) cAppCharP
vdb= Plugin_DS_Blob;
> d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 839) if (!Supported(
VP_BLOB_JSignature )) vdb= Plugin_DS_Blob_OLD2; // new BLOB signature
> d9b59bad (Beat Forster 2009-12-03 19:03:07 +0100 840) if (!Supported(
VP_DeleteBlob )) vdb= Plugin_DS_Blob_OLD1;
>
> I end up with vdb = Plugin_DS_Blob_OLD2 = "plugin_datablob_OLD2". This
> is later checked in FlagOK(). Because there is no explicit
> "plugin_datablob_OLD2=no" in SyncEvolution, the Synthesis engine tries
> to find the ReadBlob function and fails.
>
> I'm not sure what a proper solution is. It seems to me that instead of
> renaming the "plugin_datablob" string by appending "_OLD2", the
engine
> should have introduced a "plugin_datablob_NEW" version.
>
> > I'm running out of time now. The next step would be to find the oldest
> > libsynthesis that still works with 0.9.1. But I wonder whether that is
> > really useful?
>
> Attached is a minimal patch which makes the most recent libsynthesis
> (and thus 3.4.0.5+ds1-1) work again with SyncEvolution 0.9.1. I suspect
> that it might break SyncEvolution 1.0 which does support blobs
> (presumably using the current blob API), but that is a problem that we
> can deal with later.
>
> Pietro, is this something that could be added to the Ubuntu .deb of
> libsynthesis as a quick fix? The only alternatives that I see are:
> * fall back to libsynthesis_3.2.0.35
> * recompile 0.9.1 with libsynthesissdk.a from 3.2.0.45 (untested!)
> * upgrade SyncEvolution to 1.0 beta
>
> 1.0 beta works because the if (!Supported()) checks result in false and
> thus vdb remains at "plugin_datablob". I suspect that this might also
> work when compiling 0.9.1 with a more recent libsynthesissdk.a.
>
Thank you very much for your attention... I will certainly test the
patch, once you do attach it, and then ask to the Ubuntu developers what
option they prefer!
(to avoid misunderstanding: once _you_ attach the patch; and then _I_
will happily contact Ubuntu developers)
Pietro
6:22 a.m.
On Tue, 2010-03-09 at 17:41 +0000, Pietro Battiston wrote:
Il giorno mar, 09/03/2010 alle 09.23 -0800, Patrick Ohly ha scritto:
> Pietro, is this something that could be added to the Ubuntu .deb of
> libsynthesis as a quick fix? The only alternatives that I see are:
> * fall back to libsynthesis_3.2.0.35
> * recompile 0.9.1 with libsynthesissdk.a from 3.2.0.45 (untested!)
> * upgrade SyncEvolution to 1.0 beta
>
> 1.0 beta works because the if (!Supported()) checks result in false and
> thus vdb remains at "plugin_datablob". I suspect that this might also
> work when compiling 0.9.1 with a more recent libsynthesissdk.a.
>
Thank you very much for your attention... I will certainly test the
patch, once you do attach it,
Argh ;-} Here it is.
--
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.
4576
days inactive
4584
days old
syncevolution@synevolution.org
11 comments
3 participants
participants (3)
-
David Bremner -
Patrick Ohly -
Pietro Battiston