I'm not exactly sure when it broke as it was working until very recently. For accept I get errors like: Unable to send item to calendar “<Insert gmail account>”. Cannot receive calendar objects: Invalid object I also sometimes get 403 errors although I currently get that error. evolution-3.26.2-1.fc27.x86_64 evolution-data-server-3.26.2.1-1.fc27.x86_64 evolution-data-server-langpacks-3.26.2.1-1.fc27.noarch evolution-ews-3.26.2-1.fc27.x86_64 evolution-ews-langpacks-3.26.2-1.fc27.noarch evolution-langpacks-3.26.2-1.fc27.noarch gnome-online-accounts-3.26.1-3.fc27.x86_64 gnome-online-miners-3.26.0-1.fc27.x86_64 The account seems fine in gnome online accounts.
Thanks for a bug report. I'd like to know more about the 403 error, it shows up often in the key usage logs, while I wasn't able to recognize why it happened, neither I saw it myself. Accidentally, there had been done some recent fixes in upstream evolution-data-server, which should help at least with some parts of this (because I believe they are related). I'm talking about [1][2][3]. I made a test build with all three patches included at: https://koji.fedoraproject.org/koji/taskinfo?taskID=23283566 It'll help if you could install it, restart evolution-data-server background processes (`evolution --force-shutdown` will do it for you) and then use it for some time. Though that "Invalid object" error looks like an issue with the meeting invitation, for some reason passing garbage, instead of proper iCalendar object, but I can be wrong. [1] https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-26&id=c5462c13f84c696abeb08b8d7307c74efa5d67da [2] https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-26&id=42e54328277d03bf30280bb6a63d09449f850cfc [3] https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-26&id=d49070c1a480fb01519ad56eb5a28d20ad4a7d15
Update installed, will test it and see how it gets on
Still seeing it with the new version. Unable to send item to calendar “<gmail account>". Cannot receive calendar objects: Invalid object The latest is for a new meeting request that is definitely there, if I hit accept it gives the error and checking in the web interface the meeting hasn't updated to indicate my accpetance of the meeting. It's a corp gmail account, not sure if that makes any difference. It seems there might be a, possibly different but related, issue with meetings that are canceled as google might instantly remove them from the remote ical instance.
That "Invalid object" error is confusing. I'm wondering whether it has anything to do with the tzdata binary format change in F27/rawhide, as filled in bug #1514912. There is currently no debugging option to see what is passed to the backend, that can be tracked only with gdb. Could you install debuginfo package for evolution-data-server and evolution, say with a command like this: # dnf install evolution-debuginfo evolution-data-server-debuginfo \ --enablerepo=fedora-debuginfo --enablerepo=updates-debuginfo (make sure the version of the debuginfo matches the version of the binary packages, eventually use `dnf update...` in case you've any of those already installed), then run evolution under gdb like this: $ gdb evolution --ex "b e_dbus_calendar_call_receive_objects_sync" \ --ex r --ex 'printf "%s\n", arg_ics_object' which will ask you first whether you want to make the breakpoint as pending, for which you answer 'y', then it'll run evolution and when you click the Accept/Decline/... of the meeting invitation it will stop in gdb prompt and it should also print the component it is passing to the backend. I'd like to see what the component looks like, but it's possible the code optimizations will "optimize the variable out". In that case it's harder to suggest what to do, maybe try in gdb: (gdb) f 1 (gdb) printf "%s\n", utf8_ical_string (gdb) printf "%s\n", ical_string After that you can "continue" in gdb. If the prints will work, then they'll show raw component information, with details about the meeting, including participants. Make sure you won't expose any private information in public.
I made an official update [1] with upstream fixes. It contains a fix related to calendar part as well, which is not included in the scratch build I referenced in comment #1. [1] https://bodhi.fedoraproject.org/updates/evolution-data-server-3.26.2.1-2.fc27
sorry for the delay on testing this, the end of the year was a little busy and then I was on PTO. Just tested with the following: evolution-3.26.4-1.fc27.x86_64 evolution-langpacks-3.26.4-1.fc27.noarch evolution-ews-3.26.4-1.fc27.x86_64 evolution-data-server-devel-3.26.4-1.fc27.x86_64 evolution-ews-langpacks-3.26.4-1.fc27.noarch evolution-data-server-3.26.4-1.fc27.x86_64 evolution-data-server-langpacks-3.26.4-1.fc27.noarch And I'm still seeing similar on the redhat.com google cal instance. Let me know what other testing I should do. I'll likely move to rawhide in the next few weeks if that is easier
Rawhide is not necessary. I'd like to see (sanitized) output of the gdb commands mentioned at comment #4, which will show what had been passed into the backend.
Created attachment 1400992 [details] gdb output I've attached the gdb output as requested in comment #4.
Thanks for the update. I tried to 'Accept' that event and it had been received by the server when using the current development version of evolution (a week after the 3.27.91 release), but fails with the 3.26.5. I also use different libical, which explains the differences between what the code sent to the server: -> User-Agent: Evolution/3.27.92 +> User-Agent: Evolution/3.26.5 -> LAST-MODIFIED:20180227T112746Z -> X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for LOCATION -> property. Removing entire property: +> LAST-MODIFIED:20180227T112523Z +> LOCATION: -> ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=TENTATIVE:my -> X-MICROSOFT-CDO-REPLYTIME:20180227T112746Z +> ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=TENTATIVE: +> X-MICROSOFT-CDO-REPLYTIME:20180227T112523Z The 3.26.5 receives 404 error, while 3.27.92 receives success. The most interesting is the last hunk, especially the ATTENDEE property, where the development version sent proper email address, while the 3.26.5 provided no mail address. There is still a little issue with this, the mail address should be prefixed with "mailto:", which is not the case here, but that seems to be a minor issue, because the server is willing to accept even the "version" without that prefix. The error returned from the server doesn't give any clue what was wrong, unfortunately: < HTTP/1.1 404 Not Found < ..... < Content-Type: text/xml; charset=UTF-8 < Date: Tue, 27 Feb 2018 11:23:41 GMT < Expires: Tue, 27 Feb 2018 11:23:41 GMT < .... < < <?xml version="1.0" encoding="UTF-8"?> < <D:error xmlns:D="DAV:"/>
After some more debugging I found out that the Google calendar used to return the user email address in the past, but it stopped working properly since ~3.26.0, with the changes around ECalMetaBackend. I fixed it with the below changes, together with issues found on the Evolution side. Created commit c47e229a2 in eds master (3.27.92+) Created commit 720be6155 in evo master (3.27.92+) Created commit 8db3b6723 in evo master (3.27.92+) Created commit f2281b036 in eds gnome-3-26 (3.26.6+) [1] Created commit c9eed48c6 in evo gnome-3-26 (3.26.6+) [2] [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=f2281b036 [2] https://git.gnome.org/browse/evolution/commit/?id=c9eed48c63
So I tried this with 3.26.6 on F-27 and it didn't appear to fix this issue, I've just tried on 3.28 and still get 'Unable to send item to calendar “perobins”. Cannot receive calendar objects: Invalid object' evolution-data-server-langpacks-3.28.0-1.fc28.noarch evolution-3.28.0-1.fc28.x86_64 evolution-langpacks-3.28.0-1.fc28.noarch evolution-data-server-3.28.0-1.fc28.x86_64
Then maybe it's a different issue than which I faced. Could you try the debugging as outlined above, please? Or at least run from a terminal: $ CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w wait a bit, then run evolution and accept/decline/tentative the invitation. The terminal with the calendar factory should contain raw data being sent to the server and the response from the server as well. I'd like to see it, just sanitize any private information from it before adding it here, please.