12:25 p.m.
I'm sorry I can not be more descriptive - I have devoted considerable
time to this potential bug.
If I had managed to find a reproducible set of steps, I would not be
writing here - I would instead be filing a nice detailed Bugzilla bug.
Background:
I wish to use the HTTP server running on my desktop to sync
evolution with an N900. I have been testing in a virtual environment
before trusting the setup with real data on real devices.
The testing:
I am currently testing Contact migration. I expect simple
add/update/remove and conflict handling will work fine so chose to start
with testing the IM fields. There is an existing bug related to
some of the non-standard fields used by Maemo to track bindings between
IM contacts and people contacts For what it's worth, I don't think that
bug is still a bug from what I can tell - I plan to review it and test
it more though.
Environment
(All of this running on a virtual machine to emulate my real
environment)
client: scratchbox N900 with Maemo 5 SDK from March 2010
syncevolution 0.9 (latest available from repository)
server: HTTP server version of sync evolution - latest one from git
peer: desktop Linux Ubuntu 9.04
syncevolution version 1.0beta2 compiled by me
Evolution version 2.26.1
Question:
The wiki (http://syncevolution.org/wiki/linux-desktop) says
syncevolution SHOULD work with Evolution 2.24 and later....
Has anyone tried it with version 2.26.x ?
The reason I ask is, the symptoms I'm seeing almost seem like they could
be caused by a bug in the evolution ui losing it's link to the evolution
data server.
Symptoms
After a series of operations on contacts on the N900 side
with a sync in between each, to confirm the expected results,
evolution will decide to stop showing updates.
(I leave evolution running and the contact area open - the usual
behavior is that evolution updates the display when the sync
completes)
When this happens, sometimes shutting down evolution and restarting it
will cause the most recent change to be displayed. Other times
shutting down evolution AND running killev followed by restarting
evolution is necessary. In all cases no changes are lost, all edits
and changes seem to be made. In fact if one puts off restarting
evolution and the data server, you can see the changes accumulating
as the debug info is displayed on the console. The gui on the N900
side seems quite happy and thinks the sync went fine but every time
it's run you see the previous run's changes plus the new changes since
the last sync show on the console.
Anyone have any ideas?
My current thought is to try upgrading evolution (and of course it's
data server) to the latest (version 2.6.30)...this might pose other
problems if (as the wiki mentions) the EDS is no longer backward
compatible....
9:46 p.m.
On Sun, 2010-05-09 at 03:25 +0100, Jeff wrote:
I am currently testing Contact migration. I expect simple
add/update/remove and conflict handling will work fine so chose to start
with testing the IM fields. There is an existing bug related to
some of the non-standard fields used by Maemo to track bindings between
IM contacts and people contacts For what it's worth, I don't think that
bug is still a bug from what I can tell - I plan to review it and test
it more though.
I'm not sure whether this bug is still relevant in the N900.
Question:
The wiki (http://syncevolution.org/wiki/linux-desktop) says
syncevolution SHOULD work with Evolution 2.24 and later....
Has anyone tried it with version 2.26.x ?
I'm only using it with 2.28.
The reason I ask is, the symptoms I'm seeing almost seem like
they could
be caused by a bug in the evolution ui losing it's link to the evolution
data server.
That is mostly likely the reason, given that restarting Evolution fixes
the problem.
My current thought is to try upgrading evolution (and of course
it's
data server) to the latest (version 2.6.30)...this might pose other
problems if (as the wiki mentions) the EDS is no longer backward
compatible....
There haven't been relevant changes recently, so migrating should be
safe. But note that you may not be able to fall back unless you copy
your .evolution directory first and restore it before falling back.
--
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.
Good to hear you agree with my assessment - I will try upgrading
evolution in the virtual machine and re-test. No debian upgrade package
exists for this distro of Ubuntu so it will probably mean either a
build from source of evolution or setting up a virtual machine and whole
test environment with a newer Linux distro - perhaps the recent Ubuntu
release.
On Sun, 2010-05-09 at 13:46 +0200, Patrick Ohly wrote:
On Sun, 2010-05-09 at 03:25 +0100, Jeff wrote:
> I am currently testing Contact migration. I expect simple
> add/update/remove and conflict handling will work fine so chose to start
> with testing the IM fields. There is an existing bug related to
> some of the non-standard fields used by Maemo to track bindings between
> IM contacts and people contacts For what it's worth, I don't think that
> bug is still a bug from what I can tell - I plan to review it and test
> it more though.
I'm not sure whether this bug is still relevant in the N900.
> Question:
>
> The wiki (http://syncevolution.org/wiki/linux-desktop) says
> syncevolution SHOULD work with Evolution 2.24 and later....
>
> Has anyone tried it with version 2.26.x ?
I'm only using it with 2.28.
> The reason I ask is, the symptoms I'm seeing almost seem like they could
> be caused by a bug in the evolution ui losing it's link to the evolution
> data server.
That is mostly likely the reason, given that restarting Evolution fixes
the problem.
> My current thought is to try upgrading evolution (and of course it's
> data server) to the latest (version 2.6.30)...this might pose other
> problems if (as the wiki mentions) the EDS is no longer backward
> compatible....
There haven't been relevant changes recently, so migrating should be
safe. But note that you may not be able to fall back unless you copy
your .evolution directory first and restore it before falling back.
1:24 a.m.
Update: In short, I'm still seeing this problem - perhaps I have
something configured wrong?
Since Patrick indicated he has been testing with a newer version of
evolution (slightly) and not seen this issue, I thought I would test
with a newer version.
New test setup:
Virtual machine running latest Ubuntu (10.04)
Inside the VM - running
Maemo SDK (March 22) Release including scratchbox etc
Syncevolution on desktop (VM) version 1.0beta3 compiled
from scratch
with just --disable-shared and --enable-dbus-service
I did NOT use --disable-ebook and --disable-ecal
(I wish to sync directly with evolution)
Syncevolution 0.9 on Maemo SDK N900 side (from repository)
I did some quick smoke tests on this environment and confirmed that
sync in both directions for todo, memos, contact and calendar appears to
be working.
The testing I'm doing write now is very nary and relates to confirming
that IM contact info is preserved and managed as expected when IM
accounts are created/removed on the N900. So far these tests have only
involved AIM and Yahoo IM accounts (so it's possible issues that come up
are unique to these fields..by chance)
For the smoke tests I have tested both syncs involving initial person
contact creation on the desktop and on the N900. Seems to work fine..
The process that failed most recently was pretty simple and puzzles
me...(which is why despite successful syncs in the past I wonder if
there is still something wrong in my configuration files)
I did notice I have no evolution source lines in my config - as I
understand it, for a direct sync I don't need them...
Here is what I did (the entire brief session yesterday)
Startup VM
Run script to start syncevo-dbus and sync-httpserver
Startup Maemo SDK N900 emulation
N900 side: delete and re-create IM accounts
(seems to be only way to control online/offline state
of IM inside the N900 emulator)
Desktop side: create contact called "Omar LastName"
N900 side: Sync using N900 gui
N900 side: Confirm contact visible on N900, it was
N900 side: Merge Omar contact with an AOL AIM IM contact
N900 side: Sync using N900 gui
Desktop side: Look at Omar contact and notice that the IM info was not
not updated
Desktop side: Restart evolution without using killev to kill EDS, still
still not visible
Desktop side: Restart evolution by shutting it down, killev,
launching again
Notice: AIM contact field is now visble and up-to-date
While looking at the logs for the two syncs I noticed a few things - not
sure which (if any) are significant in this case.
+ The first sync correctly had detailed information on the new contact
(I only entered first and last name) and about the sync process - looked
fine
+ The second sync contained no sync details (perhaps it didn't think
anything changed?...yet EDS did receive the info ....)
addressbook.before.ini and addressbook.after.ini
Noted: files appear identical
Noted: the rev field for some items has the form
20100516T214422Z and for others looks like this
2010-05-22T01:56:27Z
Q: Is that ok? Seems to me rev strings should be
consistent format. DO I have a locale issue
perhaps? (the N900 emulator uses UK locale
because it's the only one that seems to work
the desktop in the VM is USA locale) The N900
applet shows the same as desktop so time is correct
but could perhaps be some other locale issue?
Q: These probably should have changed...
So I wonder why it didn't think any items changed
Looked at the incoming and outgoing files...don't mean much to me
nothing popped out...
Examined main.html syncevolution log and noted the following lines
# [2010-05-21 21:57:59.124] addressbook: testState=FALSE - expected
state>='sync_set_ready', found state=='idle'
# [2010-05-21 21:57:59.124] todo: testState=FALSE - expected
state>='sync_set_ready', found state=='idle'
# [2010-05-21 21:57:59.124] memo: testState=FALSE - expected
state>='sync_set_ready', found state=='idle'
# [2010-05-21 21:57:59.124] calendar: testState=FALSE - expected
state>='sync_set_ready', found state=='idle'
Q: Is this normal, or does it perhaps mean I have not
configured something properly?
I have set loglevel to 4 and can send the desktop logs, if needed, but
would rather not as I am testing with my actual contact data.
If needed, perhaps I could send them direct to Patrick rather than
attaching them to a bug.
This still feels like a configuration issue but most syncs seem fine...
Any ideas?
On Sun, 2010-05-09 at 13:46 +0200, Patrick Ohly wrote:
On Sun, 2010-05-09 at 03:25 +0100, Jeff wrote:
> I am currently testing Contact migration. I expect simple
> add/update/remove and conflict handling will work fine so chose to start
> with testing the IM fields. There is an existing bug related to
> some of the non-standard fields used by Maemo to track bindings between
> IM contacts and people contacts For what it's worth, I don't think that
> bug is still a bug from what I can tell - I plan to review it and test
> it more though.
I'm not sure whether this bug is still relevant in the N900.
> Question:
>
> The wiki (http://syncevolution.org/wiki/linux-desktop) says
> syncevolution SHOULD work with Evolution 2.24 and later....
>
> Has anyone tried it with version 2.26.x ?
I'm only using it with 2.28.
> The reason I ask is, the symptoms I'm seeing almost seem like they could
> be caused by a bug in the evolution ui losing it's link to the evolution
> data server.
That is mostly likely the reason, given that restarting Evolution fixes
the problem.
> My current thought is to try upgrading evolution (and of course it's
> data server) to the latest (version 2.6.30)...this might pose other
> problems if (as the wiki mentions) the EDS is no longer backward
> compatible....
There haven't been relevant changes recently, so migrating should be
safe. But note that you may not be able to fall back unless you copy
your .evolution directory first and restore it before falling back.
1:33 a.m.
Forgot to mention evolution version.
Ubuntu 10.04 is using evolution version 2.28.3
PS. you won't see my mistake - managed to cancel it before it reached the moderator
for the list.
On Sat, 2010-05-22 at 11:24 -0400, Jeff wrote:
Update: In short, I'm still seeing this problem - perhaps I have
something configured wrong?
Since Patrick indicated he has been testing with a newer version of
evolution (slightly) and not seen this issue, I thought I would test
with a newer version.
New test setup:
Virtual machine running latest Ubuntu (10.04)
Inside the VM - running
Maemo SDK (March 22) Release including scratchbox etc
Syncevolution on desktop (VM) version 1.0beta3 compiled
from scratch
with just --disable-shared and --enable-dbus-service
I did NOT use --disable-ebook and --disable-ecal
(I wish to sync directly with evolution)
Syncevolution 0.9 on Maemo SDK N900 side (from repository)
I did some quick smoke tests on this environment and confirmed that
sync in both directions for todo, memos, contact and calendar appears to
be working.
The testing I'm doing write now is very nary and relates to confirming
that IM contact info is preserved and managed as expected when IM
accounts are created/removed on the N900. So far these tests have only
involved AIM and Yahoo IM accounts (so it's possible issues that come up
are unique to these fields..by chance)
For the smoke tests I have tested both syncs involving initial person
contact creation on the desktop and on the N900. Seems to work fine..
The process that failed most recently was pretty simple and puzzles
me...(which is why despite successful syncs in the past I wonder if
there is still something wrong in my configuration files)
I did notice I have no evolution source lines in my config - as I
understand it, for a direct sync I don't need them...
Here is what I did (the entire brief session yesterday)
Startup VM
Run script to start syncevo-dbus and sync-httpserver
Startup Maemo SDK N900 emulation
N900 side: delete and re-create IM accounts
(seems to be only way to control online/offline state
of IM inside the N900 emulator)
Desktop side: create contact called "Omar LastName"
N900 side: Sync using N900 gui
N900 side: Confirm contact visible on N900, it was
N900 side: Merge Omar contact with an AOL AIM IM contact
N900 side: Sync using N900 gui
Desktop side: Look at Omar contact and notice that the IM info was not
not updated
Desktop side: Restart evolution without using killev to kill EDS, still
still not visible
Desktop side: Restart evolution by shutting it down, killev,
launching again
Notice: AIM contact field is now visble and up-to-date
While looking at the logs for the two syncs I noticed a few things - not
sure which (if any) are significant in this case.
+ The first sync correctly had detailed information on the new contact
(I only entered first and last name) and about the sync process - looked
fine
+ The second sync contained no sync details (perhaps it didn't think
anything changed?...yet EDS did receive the info ....)
addressbook.before.ini and addressbook.after.ini
Noted: files appear identical
Noted: the rev field for some items has the form
20100516T214422Z and for others looks like this
2010-05-22T01:56:27Z
Q: Is that ok? Seems to me rev strings should be
consistent format. DO I have a locale issue
perhaps? (the N900 emulator uses UK locale
because it's the only one that seems to work
the desktop in the VM is USA locale) The N900
applet shows the same as desktop so time is correct
but could perhaps be some other locale issue?
Q: These probably should have changed...
So I wonder why it didn't think any items changed
Looked at the incoming and outgoing files...don't mean much to me
nothing popped out...
Examined main.html syncevolution log and noted the following lines
# [2010-05-21 21:57:59.124] addressbook: testState=FALSE - expected
state>='sync_set_ready', found state=='idle'
# [2010-05-21 21:57:59.124] todo: testState=FALSE - expected
state>='sync_set_ready', found state=='idle'
# [2010-05-21 21:57:59.124] memo: testState=FALSE - expected
state>='sync_set_ready', found state=='idle'
# [2010-05-21 21:57:59.124] calendar: testState=FALSE - expected
state>='sync_set_ready', found state=='idle'
Q: Is this normal, or does it perhaps mean I have not
configured something properly?
I have set loglevel to 4 and can send the desktop logs, if needed, but
would rather not as I am testing with my actual contact data.
If needed, perhaps I could send them direct to Patrick rather than
attaching them to a bug.
This still feels like a configuration issue but most syncs seem fine...
Any ideas?
On Sun, 2010-05-09 at 13:46 +0200, Patrick Ohly wrote:
> On Sun, 2010-05-09 at 03:25 +0100, Jeff wrote:
> > I am currently testing Contact migration. I expect simple
> > add/update/remove and conflict handling will work fine so chose to start
> > with testing the IM fields. There is an existing bug related to
> > some of the non-standard fields used by Maemo to track bindings between
> > IM contacts and people contacts For what it's worth, I don't think
that
> > bug is still a bug from what I can tell - I plan to review it and test
> > it more though.
>
> I'm not sure whether this bug is still relevant in the N900.
>
> > Question:
> >
> > The wiki (http://syncevolution.org/wiki/linux-desktop) says
> > syncevolution SHOULD work with Evolution 2.24 and later....
> >
> > Has anyone tried it with version 2.26.x ?
>
> I'm only using it with 2.28.
>
> > The reason I ask is, the symptoms I'm seeing almost seem like they could
> > be caused by a bug in the evolution ui losing it's link to the evolution
> > data server.
>
> That is mostly likely the reason, given that restarting Evolution fixes
> the problem.
>
> > My current thought is to try upgrading evolution (and of course it's
> > data server) to the latest (version 2.6.30)...this might pose other
> > problems if (as the wiki mentions) the EDS is no longer backward
> > compatible....
>
> There haven't been relevant changes recently, so migrating should be
> safe. But note that you may not be able to fall back unless you copy
> your .evolution directory first and restore it before falling back.
>
--
Jeffrey Perry
Sr. Software Engineer
UNIX/Linux, C/Java, Perl/Python/PHP, XML, AJAX
LinkedIn: Jeff Perry
5:34 a.m.
Got it! Very subtle.
Isolated but not yet fully understood - I'd love to know more about the
way evolution works that would explain this behavior.
In addition to setting up a VM for testing, I found it convenient to
setup a reverse SSH tunnel from the VM back to my physical machine)
[On the vm: ssh -R2222:localhost:22 username@myphysicaldesktopip]
This allowed me to use X forwarding to place and size the evolution
window somewhere convenient on my physical desktop display
[from physical desktop ssh -Y -p2222 username@localhost]
Once the ssh connection back to the vm was established I would
launch evolution, wait for it to start then ctrl-z and bg to let it run
in the background. (Interesting to note, not waiting for it to start,
would cause a horrible lock of the X server on my physical machine -
another mystery to me...perhaps someone know the answer to that one too)
This does not work, I thought I was just forwarding X and so DBUS
communications for evolution should not be effected...apparently it's
more complex than that though...
Can anyone help with more insight on what's happening?
Meanwhile...I can get back to some real testing.
--Jeff
On Sun, 2010-05-09 at 13:46 +0200, Patrick Ohly wrote:
On Sun, 2010-05-09 at 03:25 +0100, Jeff wrote:
> I am currently testing Contact migration. I expect simple
> add/update/remove and conflict handling will work fine so chose to start
> with testing the IM fields. There is an existing bug related to
> some of the non-standard fields used by Maemo to track bindings between
> IM contacts and people contacts For what it's worth, I don't think that
> bug is still a bug from what I can tell - I plan to review it and test
> it more though.
I'm not sure whether this bug is still relevant in the N900.
> Question:
>
> The wiki (http://syncevolution.org/wiki/linux-desktop) says
> syncevolution SHOULD work with Evolution 2.24 and later....
>
> Has anyone tried it with version 2.26.x ?
I'm only using it with 2.28.
> The reason I ask is, the symptoms I'm seeing almost seem like they could
> be caused by a bug in the evolution ui losing it's link to the evolution
> data server.
That is mostly likely the reason, given that restarting Evolution fixes
the problem.
> My current thought is to try upgrading evolution (and of course it's
> data server) to the latest (version 2.6.30)...this might pose other
> problems if (as the wiki mentions) the EDS is no longer backward
> compatible....
There haven't been relevant changes recently, so migrating should be
safe. But note that you may not be able to fall back unless you copy
your .evolution directory first and restore it before falling back.
6:14 p.m.
On Sat, 2010-05-22 at 20:34 +0100, Jeff wrote:
This does not work, I thought I was just forwarding X and so DBUS
communications for evolution should not be effected...apparently it's
more complex than that though...
D-Bus depends on X for some of its operations, in particular
boot-strapping the D-Bus session. If you ssh into a machine, you end up
with your own private D-Bus session and private evolution-data-server
daemon. If you have another D-Bus session active accessing the same home
directory, this is probably leading to race conditions
regarding .evolution file access and all kinds of nasty problems.
If you need to do something like this, then better ensure that all your
processes in the machine you log into run inside the session started by
ssh.
--
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.
1:17 a.m.
Thanks Patrick!
That explains it perfectly.
I didn't know that DBUS needed X for setup.
On Wed, 2010-05-26 at 10:14 +0200, Patrick Ohly wrote:
On Sat, 2010-05-22 at 20:34 +0100, Jeff wrote:
> This does not work, I thought I was just forwarding X and so DBUS
> communications for evolution should not be effected...apparently it's
> more complex than that though...
D-Bus depends on X for some of its operations, in particular
boot-strapping the D-Bus session. If you ssh into a machine, you end up
with your own private D-Bus session and private evolution-data-server
daemon. If you have another D-Bus session active accessing the same home
directory, this is probably leading to race conditions
regarding .evolution file access and all kinds of nasty problems.
If you need to do something like this, then better ensure that all your
processes in the machine you log into run inside the session started by
ssh.
4498
days inactive
4515
days old
syncevolution@synevolution.org
7 comments
2 participants
participants (2)
-
Jeff -
Patrick Ohly