GNOME Bugzilla – Bug 661265
Move to Calendar breaks google:// URI
Last modified: 2012-04-05 12:29:21 UTC
I am running Archlinux with the following packages: local/evolution 3.2.0-1 (gnome-extra) Manage your email, contacts and schedule local/evolution-data-server 3.2.0-2 Centralized access to appointments and contacts Please note that the observations below were made with local calendars hidden. Behavior is different if local calendars are shown, or if different actions are combined (like for example hiding/showing and refreshing the calendar). Since the symptoms are so widespread, it is impossible for me to tell if they are caused by many unrelated bugs, or really just one bug. * Observation 1: - The calendar is not updated automatically (updates configured once per minute). - The calendar is not updated manually (using the `Refresh' option). - The calendar is not updated by a restart of evolution. - Using first "Work Offline", then "Work Online", always updates the calendar. - Hiding, then showing the calendar twice always updates the calendar. See also Observation 3. - Hiding, then showing the calendar once, then restarting evolution always updates the calendar. Error message (b) from Observation 3 does not happen in this case. * Observation 2: Right-click calendar -> Properties -> Retrieve List -> Enter Password -> Ok, generates the following output on stdout/stderr: (evolution:29047): e-data-server-ui-WARNING **: Keyring key is unusable: no user or host name This is always reproducible, and evolution asks for the password each time. I seem to have no Google calendar related entries in my keychain. * Observation 3: First hiding, then showing the calendar alternatingly outputs error messages (a) or (b) in ~/.xsession-errors, starting with (a) after a restart: (a) e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) Error opening calendar: Authentication required (b) Error opening calendar: Cannot open calendar: Cannot process, calendar backend is opening Shortly after (b), evolution shows new updates. * Observation 4: Sometimes, evolution outputs the following error. I could not determine when or why this happens: (evolution:1654): libecal-CRITICAL **: e_cal_client_generate_instances_for_object: assertion `e_client_is_opened (E_CLIENT (client))' failed * Observation 5: Start evolution, hide a local calendar (show first if not already shown), create `New Meeting'. Evolution outputs the following error. (evolution:1654): calendar-gui-WARNING **: Default client not loaded Afterward, the calendar ignores every action. `New Appointment' also gives the error and `Refresh' says this: (evolution:3664): calendar-modules-WARNING **: action_calendar_refresh_cb: Failed to refresh 'google', Cannot refresh calendar: Backend is not opened yet This is fixed by a restart. `New Appointment' does not trigger this issue, and both `New Appointment' and `New Meeting' work as expected if no local calendars were hidden before in the same session. Note that it is not a problem if a local calendar is already hidden when evolution starts. * Observation 6: Using the `Move to Calendar' option on an event in a local calendar and moving it to a Google calendar causes the following error: (evolution:3664): libecal-WARNING **: e_cal_client_new: Cannot get calendar from factory: No backend factory for 'google' of 'VEVENT' After that, the calendar is broken until the Google calendar list is reloaded as described in Observation 2. A restart of evolution prints the same error twice, plus: (evolution:4558): calendar-modules-CRITICAL **: e_cal_shell_sidebar_add_source: assertion `client != NULL' failed In this situation, the calendar cannot even be removed any more.
Thanks for a bug report. There are quire many issues mentioned above, but I agree they all seem to be related, thus let's try to sort them out. ad Observation 3,4,5: there were certain issues with opening an EClient and password either was not provided, or was provided an incorrect one. In that cse the backend (the e-calendar-factory part) thinks that it is still opening and reports those errors. It have been fixed within bug #592906, though only for the git master. I'll backport certain parts of the patch to 3.2 branch. ad Observation 1: I believe it's related to the above paragraph. ad Observation 2: sort of expected behaviour, I'm not sure whether it's a regression or not. Maybe can be dealt with separately, as a request to use keyring password, if available. At the moment the password in the "Retrieve list" is not supposed to be saved or used any saved, thus the critical warning is kinda bogus here. ad Observation 6: That's the most strange thing, because error > No backend factory for 'google' of 'VEVENT' is usually shown when load of the backend library fails, since the e-calendar-factory start, not when it's running at the beginning and then suddenly breaks.
(In reply to comment #1) > I'll backport certain parts of the patch to 3.2 branch. Created commit 24a5ae3 [1] in eds gnome-3-2 (3.2.3+) It'll be good if you could retest with that change, whether it'll help also for you. [1] http://git.gnome.org/browse/evolution-data-server/commit/?id=24a5ae3
Looks like in the meantime Arch Linux has upgraded evolution to version 3.2.2. With my current setup I cannot reproduce the behavior described above, with or without your patch. Instead, not much seems to be working at all. I started out trying to create new Appointment entries, but although save and close did not complain, the entries did not show up in the calendar. I figured that maybe the new evolution version cannot deal with the old configuration entries. So I deleted the calendar and the password entry in the keyring. Then I re-added the calendar. But the password does not show up in the keyring. Sometimes evolution says "(evolution:2769): e-data-server-ui-WARNING **: Keyring key is unusable: no user or host name" and when I try to create entries it now says "Cannot create calendar object: Not loaded". Somehow this feels familiar, but I do not recall how I fixed this issue previously. Later I also noticed that the entries that were not showing up before were actually created. This just keeps getting stranger and stranger.
Hi Clemens, is this still an issue in 3.2.3 if Arch Linux provides that now?
Hi André, No change with 3.2.3.
(In reply to comment #5) > Hi André, No change with 3.2.3. According to comment #3, is it "no change" like "it works properly, same as 3.2.2" or rather like "no change, some of the points from comment #0 are reproducible with 3.2.3"? If the later, then a list of which from those points would help here.
Hmm, nothing was working when I wrote comment #5, but now version 3.2.3 mostly works. Here's an update of the original report: * Observation 1: Fixed: - The calendar is updated automatically - Hiding or showing the calendar does not have any side effects any more. Still broken: - The calendar is not updated manually (using the `Refresh' option). - The calendar is not updated by a restart of evolution. (Although I guess that is intentional.) * Observation 2: Can still reproduce. But as per your previous comment this is expected behavior. * Observation 3: Cannot reproduce. * Observation 4: Cannot reproduce. * Observation 5: Cannot reproduce. Instead, I now get whenever I try to create a `New Meeting', and indeed I cannot save a meeting because an organizer is required, but none can be selected from the empty menu. * Observation 6: Can still reproduce. To summarize, the main remaining issues are "Refresh" and "Move calendar".
ad 5 (typo): Instead, I now get (evolution:30616): calendar-gui-WARNING **: No potential organizers! whenever I try to create a `New Meeting', and indeed I cannot save a meeting because an organizer is required, but none can be selected from the empty menu.
(In reply to comment #8) > (evolution:30616): calendar-gui-WARNING **: No potential organizers! It comes from the editor. The calendar part, when creating meetings (or assigned memos/tasks), requires email account due to sending invitations to attendees and so on. The editor picks an address from your default mail account, which cannot be disabled (or it uses address provided by calendar). (In reply to comment #7) > To summarize, the main remaining issues are "Refresh" and "Move calendar". Oh, I'm wrong here, there is no google calendar backend, because evolution 3.2.x uses CalDAV for google calendaring. This means that the google calendar wasn't migrated properly. What is the version you were updating from, please? At least newly created Google calendar should be setup properly and work as expected. That explains both refresh and move calendar failures.
A side note: $ gconftool-2 --get /apps/evolution/calendar/sources | grep google the above will give you a raw data how your google account is configured. It should have set relative_uri, which may start like: relative_uri="https://www.google.com/calendar/feeds/ but it should have also uri set, which begins like uri="caldav://user%40gmail.com@www.google.com/calendar/dav/ I believe the later is missing in your account definition.
I am afraid I do not recall from which version I upgraded to 3.2.0. But I didn't use Evolution before 3.2.0. Also I deleted and re-added the calendar when I already had at least version 3.2.0. The relative_uri starts like yours, but the uri is indeed different from what you expect: $ gconftool-2 --get /apps/evolution/calendar/sources | grep google uri="google://https://www.google.com/calendar/feeds/<email address>/private/full" Right now, the calendar is in a similar state as from Observation 5. I get an error message "Error loading calendar: No backend factory for 'google' of 'VEVENT'" when I start evolution, and any actions involving the google calendar are either ignored or prompt the same error message. Therefore, I cannot even delete the calendar. Okay, just figured out that if I go to properties and Retrieve List, the calendar is working again. So now I removed and re-added it. And indeed I know get the expected uri: $ gconftool-2 --get /apps/evolution/calendar/sources | grep google uri="caldav://<email address>@www.google.com/calendar/dav/<email address>/events" But instead of fixing anything, the calendar is now mostly broken again in a different way. There is no error message when I started evolution, but no calendar events are shown. And if I try to add a new appointment, I get the error "Cannot create calendar object: Not loaded" Just now I killed e-addressbook-factory and e-calendar-factory. After restarting evolution, the calendar seems back online. I can see old and add new events. So now I tried to move an appointment from a local calendar to the google calendar. Nothing happened. But when I try to add a new appointment I now get "Cannot create calendar object: Unexpected HTTP status code 2 returned (Cannot resolve hostname (https)). After restarting evolution, I get "Error loading calendar: No backend for 'google' of 'VEVENT'" again. Going to properties -> Retrieve List fixes this again, as before.
Just tried manual refresh with the new uri, and it still does not work. I verified by adding a new event on my phone, waiting for it to appear in calendar.google.com, and then Refreshing in evolution. Automatic refresh does still work.
Aha, that's interesting that it resets your 'uri' after certain steps. I'll retest here, because if it does that, then it's surely a bug. The other part, with "Refresh called on a CalDAV calendar not working" is reproducible on my side too.
What do you mean, it resets my uri? My interpretation is that for whatever reason I had a stale uri, which I removed and when I re-added the calendar with a new version of evolution, I got the new uri. That's to be expected, no? Here's some more news. After a restart of my system I observe a new and different behavior. Calendar events are not shown, and when I try to add events I get "Cannot create a new event. 'google' is a read-only calendar and cannot be modified. Please select a different calendar from the side bar in the Calendar view." Killing e-calendar-factory fixed that problem. I could not find a trigger for this issue for now. Also, there is a now a calendar named 'Calendar', which I have not added. It seems to have properties similar to the 'google' calendar. It is in the 'Google' category and it has the same username as the 'google' calendar, but some of the other settings are not the same (Color, Mark as default calendar, show reminder notifications). From /apps/evolution/calendar/sources: <group uid="1315090363.26208.15@ecki" name="Google" base_uri="google://" readonly="no"> <source uid="1329466910.9399.1@ecki" name="google" uri="caldav://<username>%40googlemail.com@www.google.com/calendar/dav/<username>@googlemail.com/events" relative_uri="https://www.google.com/calendar/feeds/<username>%40googlemail.com/private/full" color_spec="#3953dcbd2a01"> <properties> <property name="auth" value="1"/> <property name="remember_password" value="true"/> <property name="ssl" value="1"/> <property name="alarm" value="true"/> <property name="refresh" value="30"/> <property name="setup-username" value="<username>@googlemail.com"/> <property name="username" value="<username>@googlemail.com"/> <property name="default" value="true"/> <property name="refresh-type" value="0"/> </properties> </source> <source uid="1329579411.11303.0@ecki" name="Calendar" uri="caldav://<username>%40googlemail.com@www.google.com/calendar/dav/<username>@googlemail.com/events" relative_uri="caldav://<username>%40googlemail.com@www.google.com/calendar/dav/<username>@googlemail.com/events" color_spec="#E2C6E1"> <properties> <property name="username" value="<username>@googlemail.com"/> <property name="setup-username" value="<username>@googlemail.com"/> <property name="ssl" value="1"/> <property name="auth" value="1"/> <property name="goa-account-id" value="account_<some-number>"/> </properties> </source> </group> If I delete 'Calendar', and then try to add new events to the 'google' calendar, I get "Cannot create calendar object: Not loaded". Killing e-calendar-factory also fixes that problem, but the 'Calendar' calendar reappears after each restart of evolution.
The "Calendar" comes from your Gnome Online Accounts, as you have it configured to provide also Google's calendar access. If that's the reason for the URI change, then we are partly there. I didn't get to more testing yet, but I have a patch for the Refresh issue ready (it's a one-liner, there was done incorrect test to skip refreshing).
Here's a fix for the manual refresh issue: http://git.gnome.org/browse/evolution-data-server/commit/?id=3bf185db
Created attachment 208062 [details] [review] Manual Refresh on a CalDAV calendar does not work
Ok, I see why 'Calendar' is re-added on each restart. But the other calendar should not stop working when I remove it. And I still can't follow your reasoning for the URI. Why is the reason for the URI change not simply the fact that I removed and re-added the calendar? The 'Calendar' thing happened only later, after the re-boot. I remember trying to configure the Google account with Gnome some months ago, but then it was only giving me error messages. I backported your Refresh patch to 3.2.3 as per the attachment above and it works for me as well.
I can reproduce the issue with uri in the source definition being changed to > google://https://www.google.com/... when I move one local event to this google calendar. The exact steps are: a) create an event in a local calendar b) right-click above it and choose "Move to Calendar..." c) pick the google calendar from the Google group d) after confirming with OK the source definition has garbled 'uri' parameter Using Drag&Drop doesn't suffer of this. As you wrote in comment #11, it's enough to open properties for the google calendar, Retrieve List and OK, which fixes the uri. I'm using this bug report for this particular issue. The rest, if any lefts after this, should be handled in a separate bug report(s), because it's easier to track them. I'm changing summary of the bug accordingly.
Created attachment 208157 [details] [review] evo patch for evolution; Aah, I got it finally. The "select source" dialog, either with Move to Calendar or Copy to Calendar, forced uri being set, in an incorrect way. Checking how it works the need for it is obsolete now, and I'm wondering whether it was needed ever before.
Created commit 4d81843 in evo master (3.3.91+)
*** Bug 666102 has been marked as a duplicate of this bug. ***