On Sun, 2011-06-26 at 04:26 +0200, Ove Kåven wrote: > OK, first, I've noticed the http://syncevolution.org/about page where > 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 > that great.)
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 > --with-ca-certificates, That would be the better solution, if it solves the problem. Alternatively you could add the SSLVerify=0 in your frontend when creating configs. > 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 initial > 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 > [email protected]" 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 "UID" > 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 > text field. 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 inserted again. > 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
