I've built SyncEvolution 1.1.99.6 for Harmattan, and put it up on
http://people.debian.org/~ovek/harmattan/ as before. I've tried to add a
simple Aegis manifest file that requests access to the calendar and
contacts databases.
Since I now have a N950 (thanks for the support, Roman), I've managed to
run some simple tests. After I added the Aegis manifest, it no longer
seems to hang when trying to access the contact database. Not sure if
Roman's alarm thing is also fixed, since I didn't see that problem myself.
However, there's still some problems...
Patrick, what do you make of this "permanent" contact?
~ $ syncevolution --export - goosync addressbook 874
BEGIN:VCARD
VERSION:3.0
X-SYNCEVO-QTCONTACTS:Relevance^Relevance^VARIANT^0000000600412e848000000000
REV:2011-03-18T10:08:51
N:;;;;
END:VCARD
This empty "contact" seems to be permanent, possibly an artifact of the
database itself. It was there from the start (the database was otherwise
empty), and is not visible in the Contacts UI. It cannot be deleted.
This causes a refresh-from-server to fail (and maybe hang for some
reason later on), like this:
[INFO] addressbook: deleting <874>
[ERROR] addressbook: error code from SyncEvolution fatal error (local,
status 10500): addressbook: remove contact: failed with error 7, entry
#0 failed with error 7
For comparison, a "real" entry:
~ $ syncevolution --export - goosync addressbook 101810
BEGIN:VCARD
VERSION:3.0
UID:2dba9d05-9603-40be-a8b5-e899f6c0ba4c
N:;Politi;;;
FN:Politi
X-SYNCEVO-QTCONTACTS:Relevance^Relevance^VARIANT^0000000600412e848000000000
X-SYNCEVO-QTCONTACTS:SyncTarget^SyncTarget^STRING^addressbook
REV:2011-09-05T01:36:22
TEL;TYPE=VOICE:112
END:VCARD
Since you presumably wrote the QtContacts backend, any ideas on where
that dummy contact might come from, and how to suppress it, so that
refresh-from-server could be made to work (and slow syncs won't transmit
an empty contact all the time)?