3:59 p.m.
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
pnark49mmvqjnnfbr0btstlpp8(a)google.com.ics"
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.
5:14 p.m.
New subject: [SyncEvolution] More syncevolution issues
Den 26. juni 2011 16:59, skrev Patrick Ohly:
> 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.
The certs are stored in a non-standard place (and I think the
user-installed ones are stored in a different place), and I never got
around to figuring it out before.
> 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". I think the Neon
version I'm using is compiled with the standard Debian OpenSSL CA path.
Unfortunately, that's not where Maemo stores its stuff. Since it's a
community package I could probably get it changed, but switching a
configure option wouldn't be enough (I think neon's --with-ca-bundle
only takes a filename, but Maemo seems to use two *directories* filled
with PEM files for server CAs, plus a third for client certs - also,
there's some trusted platform root cert I'm not sure how works, but I
can probably ignore that one). Besides, the ability to override these
paths from SyncEvolution would be nice anyway.
Overriding the path is indeed not supported. Disabling SSL
verification is, so that would be the low road that you could take.
Yeah, well, I was thinking maybe I should fix it properly this time...
oh well.
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.
7:06 p.m.
New subject: [SyncEvolution] More syncevolution issues
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.
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.
> 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.
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.
--
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.
4:37 p.m.
New subject: [SyncEvolution] More syncevolution issues
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
5:53 p.m.
New subject: [SyncEvolution] More syncevolution issues
On Mon, 2011-06-27 at 17:37 +0200, Ove Kåven wrote:
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:
>> 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).
Isn't there a combined file of all certs already? Debian maintains such
a file as part of installing individual certs.
Otherwise, I suppose I'd have to make the GUI disable SSL
checks...
That might be the best short-term solution.
> 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.
The patch did update the UID, but it set an empty value. This might be
due to a different bug that I introduced recently in the whole
UID/revision string tracking. I'm not at all happy with the solution
that I arrived at now. I'll probably rip it out and replace it with
something simpler. May I ask you to try again in a day or two?
--
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.
9:53 p.m.
New subject: [SyncEvolution] More syncevolution issues
Den 27. juni 2011 18:53, skrev Patrick Ohly:
Isn't there a combined file of all certs already? Debian
maintains such
a file as part of installing individual certs.
No. This isn't Debian, this is heavily customized embedded system, with
quite limited rootfs disk space (256MB). There's no ca-certificates
package, there's just maemosec.
It looks like Nokia have opened the sources to that,
http://gitorious.org/maemo-5-certificate-manager
If you check out that, you'll see in the etc/ directory roughly what the
CA cert store looks like.
In actual deployment there also seems to be a *.0 symlink for every
*.pem file, e.g.
Nokia-N900:/etc/certs/common-ca# ls -l
...
-rw-r--r-- 1 root root 2106 Dec 8 2009
e7cec64ffc166796fa4aa307c104a7cb6adeda47.pem
...
lrwxrwxrwx 1 root root 44 Sep 10 2010 f80cc7f6.0 ->
e7cec64ffc166796fa4aa307c104a7cb6adeda47.pem
...
Perhaps the built-in Maemo apps somehow uses libmaemosec to load all the
needed certs into OpenSSL, instead of using OpenSSL's default paths. It
looks like libmaemosec has an API to create a X509_STORE, which you can
then probably feed to OpenSSL. But it does not appear to bother to
actually physically create a combined CA cert file that OpenSSL could
use by default (possibly due to the limited disk space). Other
third-party programs have apparently also suffered from this stuff:
https://bugs.maemo.org/show_bug.cgi?id=9355
Of course, actually using libmaemosec is no option (curl and neon is
compiled against gnutls, libmaemosec against openssl), which leaves, as
the only apparent alternative, manually loading all the PEM files from
the directories I would specify with --with-ca-certificates.
> Otherwise, I suppose I'd have to make the GUI disable SSL
checks...
That might be the best short-term solution.
>> 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.
The patch did update the UID, but it set an empty value. This might be
due to a different bug that I introduced recently in the whole
UID/revision string tracking. I'm not at all happy with the solution
that I arrived at now. I'll probably rip it out and replace it with
something simpler. May I ask you to try again in a day or two?
Sure.
Ove
3:12 p.m.
New subject: [SyncEvolution] More syncevolution issues
On Mon, 2011-06-27 at 09:53 -0700, Patrick Ohly wrote:
On Mon, 2011-06-27 at 17:37 +0200, Ove Kåven wrote:
> > 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.
The patch did update the UID, but it set an empty value. This might be
due to a different bug that I introduced recently in the whole
UID/revision string tracking. I'm not at all happy with the solution
that I arrived at now. I'll probably rip it out and replace it with
something simpler. May I ask you to try again in a day or two?
Trying again with a recent commit like 62239e5c9 would be worthwhile.
That has all of the enhancements and passed all tests. In the meantime
stabilizing and testing continues, so there's still no 1.2 release
candidate yet. Current focus is on the D-Bus server, which shouldn't
affect you.
--
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.
7:34 a.m.
New subject: [SyncEvolution] More syncevolution issues
On Fr, 2011-07-01 at 21:27 +0200, Ove Kåven wrote:
Den 01. juli 2011 16:12, skrev Patrick Ohly:
> Trying again with a recent commit like 62239e5c9 would be worthwhile.
Hmm. I think that works (so far).
A random thought struck me yesterday: the slow sync matching of calendar
items is based on the assumption that CalDAV server and local backend
support UIDs. This won't work with the Maemo 5 backend. You'll need to
stick with the traditional approach of comparing properties.
I don't have a configuration mechanism in place for this yet. In the
meantime, can you perhaps patch SyncContext.cpp and comment out the
following code on Maemo 5?
// Choosing between comparing UID/RECURRENCE-ID vs. other
// iCalendar 2.0 properties is a hack: in local sync mode, the
// iCalendar 2.0 semantic is always picked.
if (m_serverMode && m_localSync) {
SharedKey sessionKey = m_engine.OpenSessionKey(session);
SharedKey contextKey = m_engine.OpenKeyByPath(sessionKey,
"/sessionvars");
m_engine.SetInt32Value(contextKey,
"VCALENDAR_COMPARE_UID",
true);
}
--
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.
1:04 p.m.
New subject: [SyncEvolution] More syncevolution issues
Den 11. juli 2011 08:34, skrev Patrick Ohly:
On Fr, 2011-07-01 at 21:27 +0200, Ove Kåven wrote:
> Den 01. juli 2011 16:12, skrev Patrick Ohly:
>> Trying again with a recent commit like 62239e5c9 would be worthwhile.
>
> Hmm. I think that works (so far).
A random thought struck me yesterday: the slow sync matching of calendar
items is based on the assumption that CalDAV server and local backend
support UIDs. This won't work with the Maemo 5 backend. You'll need to
stick with the traditional approach of comparing properties.
Well, it still supports LUIDs. I thought a UID<->LUID database would
probably be enough? Or is this in case the calendar has been synced
using a different mechanism than SyncEvolution?
I don't have a configuration mechanism in place for this yet. In
the
meantime, can you perhaps patch SyncContext.cpp and comment out the
following code on Maemo 5?
"Patch and comment out"... is the patch to comment this out, or did you
mean something else by "patch"?
1:30 p.m.
New subject: [SyncEvolution] More syncevolution issues
On Mo, 2011-07-11 at 14:04 +0200, Ove Kåven wrote:
Den 11. juli 2011 08:34, skrev Patrick Ohly:
> On Fr, 2011-07-01 at 21:27 +0200, Ove Kåven wrote:
>> Den 01. juli 2011 16:12, skrev Patrick Ohly:
>>> Trying again with a recent commit like 62239e5c9 would be worthwhile.
>>
>> Hmm. I think that works (so far).
>
> A random thought struck me yesterday: the slow sync matching of calendar
> items is based on the assumption that CalDAV server and local backend
> support UIDs. This won't work with the Maemo 5 backend. You'll need to
> stick with the traditional approach of comparing properties.
Well, it still supports LUIDs. I thought a UID<->LUID database would
probably be enough?
That mapping is lost when doing a slow sync. In that case all that is
available to SyncEvolution is the local data (which no longer has the
UID) and the CalDAV server data (which has it).
The slow sync needs to re-establish the UID<->LUID mapping.
> I don't have a configuration mechanism in place for this
yet. In the
> meantime, can you perhaps patch SyncContext.cpp and comment out the
> following code on Maemo 5?
"Patch and comment out"... is the patch to comment this out, or did you
mean something else by "patch"?
The patch would be to comment this out.
--
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.
12:02 a.m.
New subject: [SyncEvolution] More syncevolution issues
Den 11. juli 2011 14:30, skrev Patrick Ohly:
>> I don't have a configuration mechanism in place for this
yet. In the
>> meantime, can you perhaps patch SyncContext.cpp and comment out the
>> following code on Maemo 5?
>
> "Patch and comment out"... is the patch to comment this out, or did you
> mean something else by "patch"?
The patch would be to comment this out.
OK. I've tried that. (Apparently you released 1.1.99.5 in the meantime
so I updated to that at the same time.) After building that, an
attempted normal sync failed to update some stuff because entries were
not found or something. Presuming that was expected to happen because of
the change in tracking mechanism, I did a refresh-from-the-other-side,
and after that, a couple of further tests (update, insert, and delete)
seemed to work OK. Hopefully that'll continue to be the case...
12:08 p.m.
New subject: [SyncEvolution] More syncevolution issues
On Sa, 2011-07-16 at 01:02 +0200, Ove Kåven wrote:
Den 11. juli 2011 14:30, skrev Patrick Ohly:
>>> I don't have a configuration mechanism in place for this yet. In the
>>> meantime, can you perhaps patch SyncContext.cpp and comment out the
>>> following code on Maemo 5?
>>
>> "Patch and comment out"... is the patch to comment this out, or did
you
>> mean something else by "patch"?
>
> The patch would be to comment this out.
OK. I've tried that. (Apparently you released 1.1.99.5 in the meantime
so I updated to that at the same time.) After building that, an
attempted normal sync failed to update some stuff because entries were
not found or something. Presuming that was expected to happen because of
the change in tracking mechanism,
I think your previous version was already based on that revised tracking
mechanism. If you still have the logs of that failed normal sync, then
I'd like to have a look to determine why it failed.
--
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.
4:50 p.m.
New subject: [SyncEvolution] More syncevolution issues
On Sa, 2011-07-16 at 13:08 +0200, Patrick Ohly wrote:
On Sa, 2011-07-16 at 01:02 +0200, Ove Kåven wrote:
> Den 11. juli 2011 14:30, skrev Patrick Ohly:
> >>> I don't have a configuration mechanism in place for this yet. In
the
> >>> meantime, can you perhaps patch SyncContext.cpp and comment out the
> >>> following code on Maemo 5?
> >>
> >> "Patch and comment out"... is the patch to comment this out, or
did you
> >> mean something else by "patch"?
> >
> > The patch would be to comment this out.
>
> OK. I've tried that. (Apparently you released 1.1.99.5 in the meantime
> so I updated to that at the same time.) After building that, an
> attempted normal sync failed to update some stuff because entries were
> not found or something. Presuming that was expected to happen because of
> the change in tracking mechanism,
I think your previous version was already based on that revised tracking
mechanism. If you still have the logs of that failed normal sync, then
I'd like to have a look to determine why it failed.
Ove sent me the logs. In the one for the sync config I see:
–[2011-07-16 00:39:12.892] 'GetItems' - Read items from DB
implementation, datastore=calendar [--][++] [->end] [->enclosing]
* [2011-07-16 00:39:12.911] ReadItemAsKey aID=(3005,) res=0
* [2011-07-16 00:39:12.911] Executing Script 'afterreadscript'
* [2011-07-16 00:39:12.912] TMimeDirProfileHandler::parseValue:
MIMEStringToField in check mode (no field) failed with val=1.0
* [2011-07-16 00:39:12.912] parseMimeDir: missing 1 of 1 mandatory
properies
* [2011-07-16 00:39:12.912] Failed parsing item
* [2011-07-16 00:39:12.919] ReadItemAsKey aID=(3289,) res=0
* [2011-07-16 00:39:12.919] Executing Script 'afterreadscript'
* [2011-07-16 00:39:12.919] TMimeDirProfileHandler::parseValue:
MIMEStringToField in check mode (no field) failed with val=1.0
* [2011-07-16 00:39:12.920] parseMimeDir: missing 1 of 1 mandatory
properies
* [2011-07-16 00:39:12.920] Failed parsing item
Ove, these are attempts to read items out of the Maemo 5 calendar. Is it
possible that the backend returned empty strings instead of indicating
an error by throwing an exception?
In this case the backend claimed that the items exist with status = 1 =
changed.
--
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.
7:52 p.m.
New subject: [SyncEvolution] More syncevolution issues
Den 18. juli 2011 17:50, skrev Patrick Ohly:
On Sa, 2011-07-16 at 13:08 +0200, Patrick Ohly wrote:
> On Sa, 2011-07-16 at 01:02 +0200, Ove Kåven wrote:
>> Den 11. juli 2011 14:30, skrev Patrick Ohly:
>>>>> I don't have a configuration mechanism in place for this yet. In
the
>>>>> meantime, can you perhaps patch SyncContext.cpp and comment out the
>>>>> following code on Maemo 5?
>>>>
>>>> "Patch and comment out"... is the patch to comment this out, or
did you
>>>> mean something else by "patch"?
>>>
>>> The patch would be to comment this out.
>>
>> OK. I've tried that. (Apparently you released 1.1.99.5 in the meantime
>> so I updated to that at the same time.) After building that, an
>> attempted normal sync failed to update some stuff because entries were
>> not found or something. Presuming that was expected to happen because of
>> the change in tracking mechanism,
>
> I think your previous version was already based on that revised tracking
> mechanism. If you still have the logs of that failed normal sync, then
> I'd like to have a look to determine why it failed.
Ove sent me the logs. In the one for the sync config I see:
–[2011-07-16 00:39:12.892] 'GetItems' - Read items from DB
implementation, datastore=calendar [--][++] [->end] [->enclosing]
* [2011-07-16 00:39:12.911] ReadItemAsKey aID=(3005,) res=0
* [2011-07-16 00:39:12.911] Executing Script 'afterreadscript'
* [2011-07-16 00:39:12.912] TMimeDirProfileHandler::parseValue:
MIMEStringToField in check mode (no field) failed with val=1.0
* [2011-07-16 00:39:12.912] parseMimeDir: missing 1 of 1 mandatory
properies
* [2011-07-16 00:39:12.912] Failed parsing item
* [2011-07-16 00:39:12.919] ReadItemAsKey aID=(3289,) res=0
* [2011-07-16 00:39:12.919] Executing Script 'afterreadscript'
* [2011-07-16 00:39:12.919] TMimeDirProfileHandler::parseValue:
MIMEStringToField in check mode (no field) failed with val=1.0
* [2011-07-16 00:39:12.920] parseMimeDir: missing 1 of 1 mandatory
properies
* [2011-07-16 00:39:12.920] Failed parsing item
Ove, these are attempts to read items out of the Maemo 5 calendar. Is it
possible that the backend returned empty strings instead of indicating
an error by throwing an exception?
Well, given the many known bugs in calendar-backend, anything is
possible - but I doubt it. The logs I sent included the calendar.before/
and calendar.after/ directories, I think? Presumably they contain the
strings that the backend returns. Since the UID field is identical to
the LUID which it's presumably looking for, a quick grep shows that key
3005 is .../calendar.before/16 and key 3289 is .../calendar.before/300
(in the sync config), so there's no obvious retrieval problem.
In this case the backend claimed that the items exist with status = 1
=
changed.
Those events had alarms, but at the point of this sync attempt, they
were apparently gone. It kind of looks like past and stopped alarms
(alarms that have gone off and then stopped/acknowledged by the user)
are removed from the calendar database, thus changing the event.
8:12 p.m.
New subject: [SyncEvolution] More syncevolution issues
On Mo, 2011-07-18 at 20:52 +0200, Ove Kåven wrote:
Den 18. juli 2011 17:50, skrev Patrick Ohly:
> On Sa, 2011-07-16 at 13:08 +0200, Patrick Ohly wrote:
>> On Sa, 2011-07-16 at 01:02 +0200, Ove Kåven wrote:
>>> Den 11. juli 2011 14:30, skrev Patrick Ohly:
>>>>>> I don't have a configuration mechanism in place for this
yet. In the
>>>>>> meantime, can you perhaps patch SyncContext.cpp and comment out
the
>>>>>> following code on Maemo 5?
>>>>>
>>>>> "Patch and comment out"... is the patch to comment this
out, or did you
>>>>> mean something else by "patch"?
>>>>
>>>> The patch would be to comment this out.
>>>
>>> OK. I've tried that. (Apparently you released 1.1.99.5 in the meantime
>>> so I updated to that at the same time.) After building that, an
>>> attempted normal sync failed to update some stuff because entries were
>>> not found or something. Presuming that was expected to happen because of
>>> the change in tracking mechanism,
>>
>> I think your previous version was already based on that revised tracking
>> mechanism. If you still have the logs of that failed normal sync, then
>> I'd like to have a look to determine why it failed.
>
> Ove sent me the logs. In the one for the sync config I see:
>
> –[2011-07-16 00:39:12.892] 'GetItems' - Read items from DB
> implementation, datastore=calendar [--][++] [->end] [->enclosing]
> * [2011-07-16 00:39:12.911] ReadItemAsKey aID=(3005,) res=0
> * [2011-07-16 00:39:12.911] Executing Script 'afterreadscript'
> * [2011-07-16 00:39:12.912] TMimeDirProfileHandler::parseValue:
> MIMEStringToField in check mode (no field) failed with val=1.0
> * [2011-07-16 00:39:12.912] parseMimeDir: missing 1 of 1 mandatory
> properies
> * [2011-07-16 00:39:12.912] Failed parsing item
> * [2011-07-16 00:39:12.919] ReadItemAsKey aID=(3289,) res=0
> * [2011-07-16 00:39:12.919] Executing Script 'afterreadscript'
> * [2011-07-16 00:39:12.919] TMimeDirProfileHandler::parseValue:
> MIMEStringToField in check mode (no field) failed with val=1.0
> * [2011-07-16 00:39:12.920] parseMimeDir: missing 1 of 1 mandatory
> properies
> * [2011-07-16 00:39:12.920] Failed parsing item
>
> Ove, these are attempts to read items out of the Maemo 5 calendar. Is it
> possible that the backend returned empty strings instead of indicating
> an error by throwing an exception?
Well, given the many known bugs in calendar-backend, anything is
possible - but I doubt it. The logs I sent included the calendar.before/
and calendar.after/ directories, I think? Presumably they contain the
strings that the backend returns. Since the UID field is identical to
the LUID which it's presumably looking for, a quick grep shows that key
3005 is .../calendar.before/16 and key 3289 is .../calendar.before/300
(in the sync config), so there's no obvious retrieval problem.
So it was retrieved once, but in a different context. Sorry, I'm out of
ideas. It would be useful to increase the loglevel to 4 in both sync and
target config, because in that case the offending data will be logged.
--
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.
7:53 p.m.
New subject: [SyncEvolution] More syncevolution issues
Den 18. juli 2011 21:12, skrev Patrick Ohly:
So it was retrieved once, but in a different context. Sorry, I'm
out of
ideas. It would be useful to increase the loglevel to 4 in both sync and
target config, because in that case the offending data will be logged.
Well, it worked after that, so getting a more detailed log is probably
not possible. Now I've tried several times with this log level, and I
just cannot reproduce a problem. So far, every sync I've tried succeeds...
3993
days inactive
4020
days old
syncevolution@synevolution.org
16 comments
2 participants
participants (2)
-
Ove Kåven -
Patrick Ohly