On Wed, 2016-09-14 at 18:46 +0100, Patrick O'Callaghan wrote:
> I then fired up Evo again and created new mail accounts. I noticed
> that after creating my Gmail account (using the Evo wizard with the
> default settings) I was not asked for the password, but the account
> loaded anyway.
Hi,
it found the token in the keyring from the earlier time. Seahorse helps
to find it and eventually delete it, but I do not know whether I would
do it, because your test as a new user does pretty much the same.
> However after a while Evo started saying:
>
> Failed to connect 'Gmail'
> HTTP Error: Unauthorized
The 'after a while' is an important detail for me. Does it also mean
that the email works for say an hour, then it starts failing?
By the
way, is this error returned from the mail part or the calendar part?
You can try to log something from the mail with:
$ CAMEL_DEBUG=imapx:io evolution
Search for the LOGIN command failure, which may eventually show also a
reason given by the Gmail server.
> Furthermore, my Google calendar (which *did* ask for the password
> first time round) simply doesn't load. Sometimes the same error
> message as above, sometimes not, but no calendar entries in either
> case.
To debug the calendar part run:
$ CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w
then wait a bit (few seconds), thus the service is known to D-Bus, and
then open the evolution/calendar. Apart of a raw communication between
the client and the server, it also shows how many items are in the
cache and other CalDAV related information (the lines are usually
prefixed or contain 'CalDAV' string).
The task list backend servicing "Personal" has quit unexpectedly.
Some of your tasks may not be available until Evolution is restarted.Error creating view for the memo list 'Personal'
Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flagUsual procedure after load is that the CalDAV calendar checks for ctag
and if it doesn't match the one stored in
~/.cache/evolution/calendar/...
then it checks for changes, otherwise it does nothing. Could you try to
create an event in your main Google calendar, then right-click the
calendar and pick 'Refresh' from the context menu? The log will show a
PUT request, immediately followed by a GET request, then (as a response
for the Refresh) it will show the ctag check, which should change, due
to added event.
< HTTP/1.1 403 Forbidden < Soup-Debug-Timestamp: 1473937214 < Soup-Debug: SoupMessage 1 (0x7fa2440088e0) < Vary: X-Origin < Content-Type: text/html; charset=UTF-8 < Date: Thu, 15 Sep 2016 11:00:14 GMT < Expires: Thu, 15 Sep 2016 11:00:14 GMT < Cache-Control: private, max-age=0 < X-Content-Type-Options: nosniff < X-Frame-Options: SAMEORIGIN < X-XSS-Protection: 1; mode=block < Server: GSE < Alt-Svc: quic=":443"; ma=2592000; v="36,35,34,33,32" < Accept-Ranges: none < Vary: Origin,Accept-Encoding < Connection: close < < Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup.