Since a few days, events aren't showing up in KOrganizer anymore. An inspection in the resource logs shows lots of parsing errors: kontact(9203)/akonadiserializer (calendar) Akonadi::SerializerPluginKCalCore::deserialize: Failed to parse incidence! Item id = 96004 Storage collection id 271 parentCollectionId = 271 kontact(9203)/akonadiserializer (calendar) Akonadi::SerializerPluginKCalCore::deserialize: "BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19700101T000000Z CREATED:20060517T101820Z UID: _dhkm4qr3c5m2qchg6cpjie1o6gqjgbhl64og_ccn76tr5ctjmasi0ctmm2qbc5phmur8 LAST-MODIFIED:19700101T000000Z DESCRIPTION:<anonymized> SUMMARY:<anonymized> STATUS:TENTATIVE DTSTART;VALUE=DATE:20060522 DTEND;VALUE=DATE:20060523 TRANSP:OPAQUE END:VEVENT Alternatively, with more recent events (the one above is very old): kontact(9203)/libakonadi Akonadi::ItemSerializer::deserialize: Unable to deserialize payload part: "RFC822" kontact(9203)/libakonadi Akonadi::ItemSerializer::deserialize: Payload data was: "BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:20121023T160937Z CREATED:20121023T160937Z UID:7m9qn43g19d5h29kjge65qgbj8 LAST-MODIFIED:20121023T160937Z SUMMARY:<anonymized> STATUS:CONFIRMED DTSTART:20121024T090000 DTEND:20121024T100000 TRANSP:OPAQUE END:VEVENT Reproducible: Always Steps to Reproduce: 1. Add a new calendar resource (I used a DAV resource with an OwnCloud 5.0 server) 2. Synchronize the resource Actual Results: Entries are not parsed, events do not show up in applications Expected Results: Entries should be parsed and show up Tested with an ownCloud 5.0 server over CalDAV.
Do regular ical calendar files work for you ?
your payload seems to be missing END:VCALENDAR Maybe the new ical library is more picky.
Did you paste everything ? Check for a END:VCALENDAR line this is weird.
Yes, my bad. There are "END:VCALENDAR lines" like this: kontact(9203)/libakonadi Akonadi::ItemSerializer::deserialize: Unable to deserialize payload part: "RFC822" kontact(9203)/libakonadi Akonadi::ItemSerializer::deserialize: Payload data was: "BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19700101T000000Z CREATED:20060517T101820Z UID: _dhkm4qr3c5m2qc9k6csj8d1i60sj8bhj6oog_ccn76tr5ctjmasi0ctmm2qbc5phmur8 LAST-MODIFIED:19700101T000000Z DESCRIPTION:<anonymized> SUMMARY:<anonymized> STATUS:TENTATIVE DTSTART;VALUE=DATE:20060518 DTEND;VALUE=DATE:20060519 TRANSP:OPAQUE END:VEVENT END:VCALENDAR"
I just checked with a freshly created calendar resource on local file: the same issue appears if I try to create or read an event there (with the added effect that the event is saved to the file as well).
Could you share a complete test event that triggers this bug?
In data martedì 4 giugno 2013 14:47:31, hai scritto: > --- Comment #6 from Grégory Oestreicher <greg@kamago.net> --- > Could you share a complete test event that triggers this bug? Sure, I can. What do I need to provide? The whole VCALENDAR entry of a test event?
(In reply to comment #7) > Sure, I can. What do I need to provide? The whole VCALENDAR entry of a test > event? Yes please. Just create an event that doesn't contain any private / confidential information and that triggers this bug.
Created attachment 80295 [details] Example event This is likely not valid, since I can't even create new events since this bug always happens. It's a paste from the payload data outputted when parsing fails.
Created attachment 80297 [details] Generated event in ownCloud I managed to generate an event in ownCloud, so this should be a more reliable test case.
This behavior occurs when using libical 1.0. I'll try to test with an older version.
From a discussion on IRC, Allen was also able to reproduce this issue with libical 1.0, so it may be a regression with that specific version. Marking as CONFIRMED.
I built my libical 1.0, kdepimlibs, kdepim and kdepim-runtime from scratch and now I see my calendar incidences again. so see if rebuilding those helps you.
It turned out that libical 1.0 was still compiled using autotools while it should have been CMake. After a rebuild of libical + kdepim (this time using CMake) everything is well. Marking bug as WORKSFORME. Allen: perhaps it is better to put an even stronger emphasis on *not* using autotools for building libical 1.0.