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