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.
Thanks for a bug report. Does it do that with both nonrecurring and recurring events, or only with recurring events? I think I saw something similar filled upstream too.
Never mind, I can reproduce it too, with current git master and nonrecurring event. There was no upstream bug for this, thus I filled a new one [1]. Please see [1] for any further updates. If possible, please CC yourself there, in case upstream developers will have additional questions. [1] https://bugzilla.gnome.org/show_bug.cgi?id=669003
sometimes I wonder, isn't there any kind of testing going on when updates are released. Sorry, for bitching, but I am also affected from this bug. I am running fc16. yum list installed evolution* Loaded plugins: aliases, downloadonly, fastestmirror, filter-data, keys, langpacks, : list-data, presto, refresh-packagekit, remove-with-leaves, rpm-warm- : cache, show-leaves, tsflags, verify, versionlock Installed Packages evolution.i686 3.2.3-1.fc16 @updates evolution-NetworkManager.i686 3.2.3-1.fc16 @updates evolution-bogofilter.i686 3.2.3-1.fc16 @updates evolution-data-server.i686 3.2.3-1.fc16 @updates evolution-data-server-doc.noarch 3.2.3-1.fc16 @updates evolution-exchange.i686 3.2.3-1.fc16 @updates evolution-help.noarch 3.2.3-1.fc16 @updates evolution-mapi.i686 3.2.3-1.fc16 @updates evolution-pst.i686 3.2.3-1.fc16 @updates evolution-rss.i686 0.2.90-31.20111108git.fc16 @updates evolution-spamassassin.i686 3.2.3-1.fc16
(In reply to comment #3) > sometimes I wonder, isn't there any kind of testing going on when updates are > released. Sorry, for bitching, but I am also affected from this bug. I am > running fc16. Yes, there is some testing, but one cannot catch everything. Note this is not evolution's issue, it comes from libical (see the upstream bug). Either downgrade it and refetch your local cache of the CalDAV calendar you are using (~/.cache/evolution/calendar/...) or, which would be better, I'll add the upstream patch and update eds (it'll take another ~two weeks to have the update in stable).
evolution-data-server-3.2.3-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/evolution-data-server-3.2.3-2.fc16
Hi Milan, thanks for your reply. However, this is basic testing. I suppose that 1. Creating an event 2. Deleting 3. Modifying 4. Moving are to be tested before any update is sent downstream. I understand that this might be an issue in libical, but evolution is a core application of gnome environment and it must perform on a daily basis. People cannot loose time doing bug-testing. I am wondering is the project short-handed? In that case maybe I can lend a hand. Anyway, I hope that the update will fix things. I'll wait for the patch to be pushed downstream and provide feedback.
Any testing is always appreciated. That might be a reason why crit-path packages stay in updates-testing for two weeks. Note this is reproducible with Google and DAViCal servers. Any other CalDAV calendars, which do not return ETag-s quoted, will not suffer of this issue. Also note that this can happen also only by updating libical to 0.48 (and maybe 0.47). If you want exact steps, then I guess (I didn't test, but I see a possibility) it's enough to update libical from 0.46 or earlier to 0.48, make a change in the Google's calendar, thus the next start the whole calendar will be reloaded, which also changes the ETag-s and since then the whole thing will stop working, without touching evolution code at all.
Hi there, I have tested please push downstream , with: 1. Create new appointment 2. Save 3. Open 4. Edit fields 5. save and close Success Also, edited previously problematic appointments.
Thanks for the confirmation.
evolution-data-server-3.2.3-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
This exact problem seems to affect Evolution (3.0.3) in both Fedora 15 and in Fedora Alpha (evo 3.4.0.1) with all the latest updates applied. Could it be considered to apply this same fix to both of these releases of Fedora?
Based on [1] the fix is included in 3.3.5 of evolution-data-server, thus also in 3.4.0 version of it. I'm afraid you are facing of a different issue. [1] https://bugzilla.gnome.org/show_bug.cgi?id=669003#c2
I am using F18 and issue still persist. I put my comments on upstream report. https://bugzilla.gnome.org/show_bug.cgi?id=669003
Created attachment 689850 [details] evolution screen shot. evolution screen shot.