Den 26. juni 2011 20:06, skrev Patrick Ohly:
> On Sun, 2011-06-26 at 18:14 +0200, Ove Kåven wrote:
>> Den 26. juni 2011 16:59, skrev Patrick Ohly:
>>>> 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.
>>
>> I guess it depends on what you mean by "correctly".
>
> So that the app doesn't need to know the default. Figuring this out
> once, in the system libraries (libsoup, libcurl, libneon) seems better
> than expecting all app developers to know where certs are.
Perhaps, but as I said, no "correct" compilation of libneon would do
that, since without patching in new features, it could only be compiled
to look for a file, not to load a whole directory or two.
>> Besides, the ability to override these
>> paths from SyncEvolution would be nice anyway.
>
> The problem is that the Neon API has no easy way to provide a path to
> certs.
I'd write a quick "for (all regular files in dirs) {
ne_ssl_trust_cert(ne_ssl_cert_read(file)); }" patch, but I'm primarily a
C programmer and not sure what the current best-practice C++ way to
iterate over files in a directory is (or to split colon-separated
directory lists).
Otherwise, I suppose I'd have to make the GUI disable SSL checks...
>>> 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.
>>
>> Done.
>
> Thanks. It confirms that sending the artificial UID instead of the one
> originally created on the CalDAV server is the root cause. It causes a
> new item to be created instead of overwriting the existing one.
I think the UID from the ical entry from Maemo's calendar-backend is
exactly the same as the LUID, which is also returned by the
SyncEvolution backend.
> Attached is a patch which might solve the problem. It passes all of my
> tests here, but I don't have a setup where the code is relevant. Please
> let me know if it works for you.
Well, didn't seem to work correctly, I sent logs in separate mail.
Thanks,
Ove
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
