On Sun, 2011-06-26 at 04:26 +0200, Ove Kåven wrote:
OK, first, I've noticed the http://syncevolution.org/about
somehow the Maemo backend is listed with "unknown". I could perhaps clarify:
Maemo 5 Calendar Backend
Data types: events, tasks, memos
Storage: calendar-backend internal storage (SQLite)
Change tracking: modification time
(The calendar-backend storage is not icalendar, there's just a class to
convert from/to ical/vcal, and that converter implementation is not all
Thanks for the update, applied.
So, anyway, I've built that syncevolution snapshot. I've
noted that now,
--disable-ssl-certificate-check doesn't do anything anymore.
True. It used to insert SSLVerifyServer=0 into the configuration
templates. When these templates were moved out of the source code (where
a simple ifdef was enough) into files (where a more complicated patching
during "make install" would be needed), I dropped support for the
configure option. I didn't know that the Maemo 5 port depends on it.
Maybe I can
find the correct Maemo certificate path and give its path to configure
That would be the better solution, if it solves the problem.
Alternatively you could add the SSLVerify=0 in your frontend when
but it also seems to me that webdav/NeonCXX.cpp
probably wouldn't honor those paths if I did.
ne_ssl_trust_default_ca() is called by SyncEvolution. If libeon itself
was compiled correctly, then it should find and use the default
certificates. Overriding the path is indeed not supported. Disabling SSL
verification is, so that would be the low road that you could take.
But more serious, maybe, is a problem with WebDAV sync. I did an
sync against google calendar, which downloaded a lot of events. Right
after that, I tried a normal sync, and that failed.
"updating item: real luid 1014.ics does not match old luid
Can you send me the logs of downloading an event and updating it? Run
with loglevel=4 and send the "source-config" logs, those are the ones
showing the communication with the CalDAV server.
Perhaps it is of relevance that calendar-backend claims the ical
field for its own purposes. It is generated when a calendar entry is
inserted. You can't override the UID without hacks (any existing UID in
the ical text is ignored), and there probably wouldn't be much point in
trying anyway, since it is just an integer in the SQLite database, not a
That might indeed be a problem. It might be possible to fix it, I need
to look at the logs and think a bit about where the right UID can be
All this doesn't seem to have been much of a problem with
normal SyncML sync, though...?
SyncML doesn't care about the UID at all whereas in CalDAV, iCalendar
2.0 including the UID semantic (globally unique and preserved) is
mandatory. It would be SyncEvolution's job to fix that for local
backends which don't support it.
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.