My first tests were with a full calendar ical.
I can not transmit logs generated because the 25Mo file contain a lot of personal information which take too long to clean.
However, having looked at myself, I did not find anything in the events attendees and alarms that match what you suspect.
So I reiterated my tests with both calendars empty and it seems that the two-way sync works.

I tested several different case with attendees and alarms, but I could not reproduce the problem.

I continue my tests, and I will inform you if I have something new about it.

However, there is an annoying bug happens. An event created from the google calendar after sync is registered 1 hour before in the calendar ical.
The reverse works.
The log do not display bad information. (The TZ is Europe / Paris is GMT +1)


Le 01/02/13 15:57, Patrick Ohly a écrit :
On Fri, 2013-02-01 at 13:17 +0100, HESPUL - Fabien MICHEL wrote:
Corresponding to each error in syncevolution log, there is this error
in Apple ical server log :
2013-02-01 13:14:41+0100 [-] [caldav-0]  [-]
[twistedcaldav.method.put_common#error] Invalid calendar data:
Calendar data had unfixable problems:
2013-02-01 13:14:41+0100 [-] [caldav-0]       [VALARM] Missing
required property: ATTENDEE
Thanks for digging that out.

It is possible to config syncevolution to make ical server happy ?
There's no readily available configure option, but it should be possible
to massage the data into a format that is suitable, either in C++ or in
the builtin scripting language.

As a first step I need to know exactly what VEVENT the failing PUT
request sent to the iCal server. Can you rerun the sync as
        SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --sync slow loglevel=4 google@ical calendar
and watch out for the failing PUT? It should be included in the output
now.

It is not clear to me why the server expects a VALARM to contain an
ATTENDEE. Hmm, after consulting the spec I see that ATTENDEE is required
for email alarms, like the ones that Google likes to add to events. Most
likely that is what is happening here.

If Google sends a VALARM ACTION=EMAIL without ATTENDEE, then the Google
server is broken because it violates the spec. I suppose SyncEvolution
could fix that by adding all ATTENDEES and the ORGANIZER of the VEVENT
to the VALARM inside it.