On Tue, 2012-08-14 at 21:45 +0200, Ove Kåven wrote:
On 14. aug. 2012 17:47, Justus-bulk(a)Piater.name wrote:
> /home/user $ syncevolution --sync slow client-for-laptop memo
> [INFO] memo: starting first time sync, two-way (peer is server)
> [INFO] memo: sent 1/1
> [INFO] memo: started
> [INFO] memo: adding <???>
> [ERROR] error code from SyncEvolution fatal error (local, status 10500): memo: error
parsing iCalendar 2.0 item
> [INFO] memo: received 1/1
> [ERROR] unexpected reply from server; might be a temporary problem, try again later
> Do I have to specify specific syncFormats on client and/or server?
Hmm. I thought the engine would autodetect this stuff if the backend
says "text/calendar+plain", but I think we might need Patrick Ohly to
explain how these format conversions are supposed to work...
The critical section is this:
* [2012-08-14 16:57:26.458] Executing Script 'beforewritescript'
* [2012-08-14 16:57:26.461] adding <???>
* [2012-08-14 16:57:26.466] icalformat_p.cpp: 2557 - Expected
iCalendar, got vCalendar
* [2012-08-14 16:57:26.467] icalformat.cpp: 186 - Could not populate
* [2012-08-14 16:57:26.467] exception thrown at
* [2012-08-14 16:57:26.468] error code from SyncEvolution fatal error
(local, status 10500): memo: error parsing iCalendar 2.0 item
At the default log level, data conversion is not logged, therefore it is
impossible to tell what the "beforewritescript" did. Normally it sets
the "itemdata" variable to the result of MAKETEXTWITHPROFILE(), where
(in this case) the requested profile results in iCalendar 2.0 data. Then
content of "itemdata" is then passed to the backend.
Justus, can you redo the logs after setting loglevel=4 in your sync
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.