Gonzalo Diethelm wrote:
On Tue, 2005-03-22 at 19:29 +0100, Armin Bauer wrote:
there is no mechanism besides export MULTISYNC_DEBUG=1 The absence of good debugging support is also a reason for abondining multisync 0.8X, its almost impossible to find bugs.
yes, evo2's api uses rpc to communicate with the e-d-s. you can trace the opening etc by killing the evolution data server: /usr/lib/evolution/2.0/killev and then start it manually: strace evolution-data-server.
I did that and at least found out what the data server is disliking: the error it prints out is the following (with slight editing of mine):
~/.evolution/calendar/local/system/calendar.ics-msyncid2.db:29: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xE9 0x20 0x45 0x6A SUMMARY:Comit\uffff Ejecutivo cajas ^
An "od -cx" dump of a file containing just that one line is:
0000000 S U M M A R Y : C o m i t 351 E 5553 4d4d 5241 3a59 6f43 696d e974 4520 0000020 j e c u t i v o c a j a s \n \0 656a 7563 6974 6f76 6320 6a61 7361 000a
This is weird: the only time multisync works is the first time, when the calendar.ics-msyncid2.db file does not exist; in that case, the file gets created (I suppose by the evolution data server). But then, the next time I run multisync, the data server is unable to process the very file it created before!
Anybody has seen this? Any clues for a quick fix in multisync 0.8?
Where does this \u come from? is it in one of the vcards when you do the first sync?
Thanks and best regards.
signature.asc
Description: OpenPGP digital signature
