GNOME Bugzilla – Bug 669003
CalDAV: Cannot modify calendar object (libical 0.48)
Last modified: 2014-03-25 08:27:07 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=785183 Description of problem: Whenever I try to modify an event, I get: »Cannot modify calendar object: Unexpected HTTP status code 412 returned (Existing event has different ETag)« Version-Release number of selected component (if applicable): Fedora 16, Evolution 3.2.3 How reproducible: Every time, on i686 as well as on x86_64 Steps to Reproduce: 1. Configure Online-Accounts OR add a Google Calendar manually 2. Open Calendar, enter password 3. Try to change or delete existing event 4. Get error message: Cannot modify calendar object: Unexpected HTTP status code 412 returned (Existing event has different ETag) Actual results: Not able to manage already existing events. Expected results: Should be able to manage already existing events. Additional info: I am able to create new events. Don't have a problem changing existing events with Thunderbird/Lightning. Didn't have the problem in evolution two weeks ago.
Created attachment 206460 [details] [review] eds patch for evolution-data-server; Well, not a patch, rather a workaround. This is regression in libical 0.48, it escapes quotes in X properties on set, but doesn't unescape them on get. I wrote a message to libical upstream [1], and here's a workaround for the time being. [1] http://sourceforge.net/mailarchive/forum.php?thread_name=1327947491.31941.3.camel%40localhost&forum_name=freeassociation-devel
Created commit 830fa86 in eds master (3.3.5+)
Thanks for helping. Unfortunately I'm just a damn user, so: What shall I do with that file?
I made an update for Fedora 16 today, which has the patch included. You can grab the evolution-data-server from updates-testing and give it a try. You can also set karma on the update, whether it'll work for you or not. See the downstream bug (comment #0) for more information about the update for Fedora.
Tested the i686 version, and it works, thanks! Will test the x86_64 version at my office in a few hours.
x64_64 also works fine, in my humble opinion the bug is fixed (and I can shutdown GCALDaemon again ;-).
I received a confirmation from the downstream reporter that it works for him too.
*** Bug 669220 has been marked as a duplicate of this bug. ***
This affects the current Ubuntu 12.04 B1 which has the same affected evolution and libical versions. ii libical0 0.48-1 ii evolution 3.2.3-0ubuntu3
Patch applies cleanly on Ubuntu 12.04, resolves the problem. Downstream report: https://bugs.launchpad.net/evolution-data-server/+bug/955707 I would have opened downstream on libical too, but that link in comment 1 is not direct.
Human error on my part, I added the libical downstream too. https://bugs.launchpad.net/libical/+bug/955711
I found another downstream bug I think is related to this ical problem https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/955984 StacktraceTop: icalvalue_get_recur () from /usr/lib/libical.so.0 icalproperty_get_rrule () from /usr/lib/libical.so.0 ?? () from /usr/lib/libical.so.0 Is this a no-brainer duplicate.. or not? The more I align the downstream reports, the faster this patch gets merged.
It looks different, on the first look.
*** Bug 675595 has been marked as a duplicate of this bug. ***
I am using F18 and issue still persist. Can't modify calendar or accept Cannot receive calendar objects: Unexpected HTTP status code 412 returned (Precondition Failed) [bendersky@CXXX ~]$ rpm -qa | grep evolu evolution-3.6.2-3.fc18.x86_64 evolution-data-server-3.6.2-3.fc18.x86_64 [bendersky@CXXX ~]$
Created attachment 234730 [details] evolution screen shot. evolution screen shot.
I am seeing the same thing in F20. $ rpm -qa | grep evolu evolution-ews-3.10.4-1.fc20.x86_64 evolution-data-server-3.10.4-3.fc20.x86_64 evolution-mapi-3.10.4-1.fc20.x86_64 evolution-3.10.4-2.fc20.x86_64
(In reply to comment #17) > I am seeing the same thing in F20. Fedora 20 uses libical 1.0, from which I suppose you face a slightly different issue. Could you catch a CalDAV log, to see what evolution actually tries to do, please? You can catch the log if you run this: $ CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w &>log.txt from a terminal. After that wait few seconds (5-10), then run evolution and reproduce the issue. The log.txt will contain raw communication between evolution and the server. It contains private information, like server addresses and sometimes even passwords, thus please check for these before you upload the log to bugzilla. Personally, I would prefer to open a new bug report for this, because this one was relevant in time of evolution 3.6.x, which is more than a year ago (almost a year and half, because the evolution 3.12.0 had been released only yesterday).