12:26 p.m.
[Replying to the list with Todd's permission]
On Mon, 2014-04-14 at 17:55 -0700, Todd Wilson wrote:
Patrick,
This is my first question about the Google side of my attempted sync
set-up, so I'm starting a new thread. I'm using
http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backend...
as a resource. Here are the steps I've taken so far:
1. As a precaution, I started up GOA, deleted my Google Account, and
re-added it, authenticating successfully inside the GOA application.
Which version of GOA, which distro, and what permissions where you asked
to grant?
It is important that "Google Calendar" and (for Google Contacts) "Google
Contacts via CardDAV" appear there. Yes, Google distinguishes between
Google Contacts via their own API and CardDAV.
2. I went online to my Google Account and verified, under Recent
Activity, that I've signed in (Linux). Under Account Permissions, it
says (among many other things, of course):
* Ubuntu: Has full access to your Google Account (Auth date:
aaaa/2014)
* Ubuntu: Has access to Google Drive, Google Talk, Picasa Web
Albums, basic account info (Auth date: yyyy/2013)
* GNOME: Has access to Gmail, Google Calendar, Google Contacts,
Google Docs, Google Drive, basic account info (Auth date:
xxxx/2011)
I'm not sure why these old connections are there, or why the most
recent connection wasn't dated today because of what I did in Step 1.
Not sure either.
3. I checked with seahorse and found an entry "GOA google
credentials
for identity account_1322264161" (Gnome Online Accounts password). I
also found "Network passwords" for "xxxxx(a)zimbra.yyyyyy/dav/twilson"
and "xxxxx(a)zimbra.yyyyyy/dav/twilson/Calendar". Are those the entries
created by syncevolution in my Zimbra sync? Do I need both?
Probably yes. If you look at the details of these network passwords,
you'll see that SyncEvolution includes the full path as "server" key, so
the two entries really are different. Whether they are still in use is a
different question.
Here's what it has stored for me for Google CalDAV:
server: www.google.com/calendar/dav/%u/user/?SyncEvolution=Google
user: patrick.ohly(a)googlemail.com
The "server" and "user" values are used to find the stored
"password"
value. I've not found good instructions for choosing keys. Make them too
specific and you end up with more entries than necessary and the user
has to fix them multiple times when changing the password on the server.
Make them too unspecific and different passwords will conflict with each
other. For example, an HTTP server might require different passwords for
different paths, which is why SyncEvolution includes the path in the
key.
4. Using the account information I got from Step 3, I entered the
command
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases
backend=caldav username=account_xxxxxxx
^^^^^^^^^^^^^^^^^^^^^^^^^^^
You need to tell SyncEvolution that you want to use GOA. This has to be
username=goa:account_xxxxxx.
5. In seahorse again, I can look at the password for
account_1322264161 and it looks like
{'access_token', <'...'>,
'access_token_secret':<'...'>}
with no resemblance to my password, so I can't check to see if it's
stored correctly, but I assume it is since there was no error where I
created the account and Google says I'm logged in.
This is indeed normal. One of the advantages of OAuth is that the actual
password for the login doesn't need to be stored. The password allows
the application to do anything it wants with your Google account. The
OAuth tokens restrict access to those services that were requested and
granted.
6. I ran the command from Step 4 again with loglevel=4. I won't
flood
this email with the output (unless you want to see it), but I note
that the 403 was accompanied by a response body that included
<error>
<domain>usageLimits</domain>
<code>dailyLimitExceededUnreg</code>
<internalReason>Daily Limit for Unauthenticated Use
Exceeded. Continued use requires signup.</internalReason>
<extendedHelp>https://code.google.com/apis/console</extendedHelp>
</error>
and the 401 was accompanied by a response body that included
<error>
<domain>GData</domain>
<code>authError</code>
<location type="header">Authorization</location>
<internalReason>HTTP Basic Authentication is not supported
for this API</internalReason>
</error>
This confirms that SyncEvolution was attempting normal HTTP Basic Auth
with a blank password, which would have been wrong, even if it had been
supported for this particular path (which it isn't).
As reported recently on the list, the old CalDAV URL still works with
Basic Auth, but that will be turned off eventually.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
8:24 p.m.
New subject: [SyncEvolution] Google CalDAV sync
On Thu, Apr 17, 2014 at 5:26 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> 1. As a precaution, I started up GOA, deleted my Google Account,
and
> re-added it, authenticating successfully inside the GOA application.
Which version of GOA, which distro, and what permissions where you asked
to grant?
It is important that "Google Calendar" and (for Google Contacts) "Google
Contacts via CardDAV" appear there. Yes, Google distinguishes between
Google Contacts via their own API and CardDAV.
OK, one problem was that, even though I had GOA installed on my Ubuntu
system, the "Online Accounts" icon in the Control Center was taking me
to "Ubuntu Online Accounts", with no indication that this was the case
-- everything was just "Online Accounts". When I used this, as before,
to create a Google account and authenticate with Google, the
permissions dialog was:
Ubuntu would like to:
- Have offline access
and that was it. Some web searching turned up an alternative way of
starting the Control Center:
XDG_CURRENT_DESKTOP=GNOME gnome-control-center
which presents two "Online Accounts" icons. When I opened the other
one, created a Google account, and authenticated, the permissions
dialog was
GNOME would like to
- View and manage your mail
- Know who you are on Google
- View your email address
- Manage your calendars
- View and manage your spreadsheets in Google Drive
- View and manage any of your documents and files in Google Drive
- Manage your contacts
- View and send chat messages
- View and manage your contacts using the CardDAV protocol
Wow! Anyway, the two permissions you mentioned (calendar, contacts
using CardDAV) were there. After allowing access, I turned off the
toggles for Mail, Chat, and Documents, leaving only Calendar and
Contacts.
Back in seahorse, I see "GOA google credentials for identity
account_nnn" twice, now, with two different values of nnn. Looking at
the properties of these keys produces the same top-level result:
Use: Saved password or login
Type: Password
but I notice that the UOA password has password keys
access_token, access_token_secret
as reported before, whereas the GOA password has password keys
authorization_code, access_token, access_token_expires_at, refresh_token.
> 3. I checked with seahorse and found an entry "GOA google
credentials
> for identity account_1322264161" (Gnome Online Accounts password). I
> also found "Network passwords" for
"xxxxx(a)zimbra.yyyyyy/dav/twilson"
> and "xxxxx(a)zimbra.yyyyyy/dav/twilson/Calendar". Are those the entries
> created by syncevolution in my Zimbra sync? Do I need both?
Probably yes. If you look at the details of these network passwords,
you'll see that SyncEvolution includes the full path as "server" key, so
the two entries really are different. Whether they are still in use is a
different question.
OK, I see what you're referring to here in these keyring entries.
Here's what it has stored for me for Google CalDAV:
server: www.google.com/calendar/dav/%u/user/?SyncEvolution=Google
user: patrick.ohly(a)googlemail.com
The "server" and "user" values are used to find the stored
"password"
value. I've not found good instructions for choosing keys. Make them too
specific and you end up with more entries than necessary and the user
has to fix them multiple times when changing the password on the server.
Make them too unspecific and different passwords will conflict with each
other. For example, an HTTP server might require different passwords for
different paths, which is why SyncEvolution includes the path in the
key.
I don't see anything like this. I only have the "GOA google
credentials for identity account_nnn" entries mentioned above, nothing
to do with CalDAV. Where are you seeing this?
> 4. Using the account information I got from Step 3, I entered
the
> command
> $ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases
> backend=caldav username=account_xxxxxxx
^^^^^^^^^^^^^^^^^^^^^^^^^^^
You need to tell SyncEvolution that you want to use GOA. This has to be
username=goa:account_xxxxxx.
Now trying this again with the goa: username and my GOA account_nnn, I
see, at the end,
caldav:
Personal
(https://apidata.googleusercontent.com:443/caldav/v2/xxxx%40gmail.com/events/)
<default>
However, when I go to Google Calendar, create the new calendar that I
want to use to sync with Zimbra, and then repeat the
--print-databases, it again only finds Personal. Does this mean that
Google is only allowing CalDAV on your Personal calendar, or is there
something else I have to do to find this other calendar?
--Todd
5:19 a.m.
New subject: [SyncEvolution] Google CalDAV sync
The print-databases for caldav doesn't work. You can see the correct caldav
URL in the properties of the calendar in the calendar settings inside gcal.
On Apr 17, 2014 10:25 PM, "Todd Wilson" <twilson(a)csufresno.edu> wrote:
On Thu, Apr 17, 2014 at 5:26 AM, Patrick Ohly
<patrick.ohly(a)intel.com>
wrote:
> > 1. As a precaution, I started up GOA, deleted my Google Account, and
> > re-added it, authenticating successfully inside the GOA application.
>
> Which version of GOA, which distro, and what permissions where you asked
> to grant?
>
> It is important that "Google Calendar" and (for Google Contacts)
"Google
> Contacts via CardDAV" appear there. Yes, Google distinguishes between
> Google Contacts via their own API and CardDAV.
OK, one problem was that, even though I had GOA installed on my Ubuntu
system, the "Online Accounts" icon in the Control Center was taking me
to "Ubuntu Online Accounts", with no indication that this was the case
-- everything was just "Online Accounts". When I used this, as before,
to create a Google account and authenticate with Google, the
permissions dialog was:
Ubuntu would like to:
- Have offline access
and that was it. Some web searching turned up an alternative way of
starting the Control Center:
XDG_CURRENT_DESKTOP=GNOME gnome-control-center
which presents two "Online Accounts" icons. When I opened the other
one, created a Google account, and authenticated, the permissions
dialog was
GNOME would like to
- View and manage your mail
- Know who you are on Google
- View your email address
- Manage your calendars
- View and manage your spreadsheets in Google Drive
- View and manage any of your documents and files in Google Drive
- Manage your contacts
- View and send chat messages
- View and manage your contacts using the CardDAV protocol
Wow! Anyway, the two permissions you mentioned (calendar, contacts
using CardDAV) were there. After allowing access, I turned off the
toggles for Mail, Chat, and Documents, leaving only Calendar and
Contacts.
Back in seahorse, I see "GOA google credentials for identity
account_nnn" twice, now, with two different values of nnn. Looking at
the properties of these keys produces the same top-level result:
Use: Saved password or login
Type: Password
but I notice that the UOA password has password keys
access_token, access_token_secret
as reported before, whereas the GOA password has password keys
authorization_code, access_token, access_token_expires_at,
refresh_token.
> > 3. I checked with seahorse and found an entry "GOA google credentials
> > for identity account_1322264161" (Gnome Online Accounts password). I
> > also found "Network passwords" for
"xxxxx(a)zimbra.yyyyyy/dav/twilson"
> > and "xxxxx(a)zimbra.yyyyyy/dav/twilson/Calendar". Are those the
entries
> > created by syncevolution in my Zimbra sync? Do I need both?
>
> Probably yes. If you look at the details of these network passwords,
> you'll see that SyncEvolution includes the full path as "server" key,
so
> the two entries really are different. Whether they are still in use is a
> different question.
OK, I see what you're referring to here in these keyring entries.
> Here's what it has stored for me for Google CalDAV:
>
> server: www.google.com/calendar/dav/%u/user/?SyncEvolution=Google
> user: patrick.ohly(a)googlemail.com
>
> The "server" and "user" values are used to find the stored
"password"
> value. I've not found good instructions for choosing keys. Make them too
> specific and you end up with more entries than necessary and the user
> has to fix them multiple times when changing the password on the server.
> Make them too unspecific and different passwords will conflict with each
> other. For example, an HTTP server might require different passwords for
> different paths, which is why SyncEvolution includes the path in the
> key.
I don't see anything like this. I only have the "GOA google
credentials for identity account_nnn" entries mentioned above, nothing
to do with CalDAV. Where are you seeing this?
> > 4. Using the account information I got from Step 3, I entered the
> > command
> > $ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases
> > backend=caldav username=account_xxxxxxx
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> You need to tell SyncEvolution that you want to use GOA. This has to be
> username=goa:account_xxxxxx.
Now trying this again with the goa: username and my GOA account_nnn, I
see, at the end,
caldav:
Personal (
https://apidata.googleusercontent.com:443/caldav/v2/xxxx%40gmail.com/events/
)
<default>
However, when I go to Google Calendar, create the new calendar that I
want to use to sync with Zimbra, and then repeat the
--print-databases, it again only finds Personal. Does this mean that
Google is only allowing CalDAV on your Personal calendar, or is there
something else I have to do to find this other calendar?
--Todd
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
6:57 a.m.
New subject: [SyncEvolution] Google CalDAV sync
On Thu, Apr 17, 2014 at 10:19 PM, Emiliano Heyns <
emiliano.heyns(a)iris-advies.com> wrote:
The print-databases for caldav doesn't work. You can see the
correct
caldav URL in the properties of the calendar in the calendar settings
inside gcal.
I looked for it once before and looked again after I read this statement,
but didn't see it there. In the settings page for the calendar I created, I
have addresses for
- Calendar Address (XML, ICAL, HTML)
- Private Address (XML, ICAL)
but nothing about CalDAV, and no URLs that appear to be dav URLs. Could you
be more specific?
--Todd
11:58 a.m.
New subject: [SyncEvolution] Google CalDAV sync
On Thu, 2014-04-17 at 23:57 -0700, Todd Wilson wrote:
On Thu, Apr 17, 2014 at 10:19 PM, Emiliano Heyns
<emiliano.heyns(a)iris-advies.com> wrote:
The print-databases for caldav doesn't work. You can see the
correct caldav URL in the properties of the calendar in the
calendar settings inside gcal.
I looked for it once before and looked again after I read this
statement, but didn't see it there. In the settings page for the
calendar I created, I have addresses for
* Calendar Address (XML, ICAL, HTML)
* Private Address (XML, ICAL)
but nothing about CalDAV, and no URLs that appear to be dav URLs.
There is a "calendar ID". Use that in the URL of the form:
https://www.google.com:443/calendar/dav/<calendar ID>/events/?SyncEvolution=Google
The problem with --print-databases and Google CalDAV is already fixed. I
think Google did not implement support for calendar discovery initially,
and when they did, it required some more changes in SyncEvolution.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7:08 p.m.
New subject: [SyncEvolution] Google CalDAV sync
On Fri, Apr 18, 2014 at 4:58 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
There is a "calendar ID". Use that in the URL of the form:
https://www.google.com:443/calendar/dav/<calendar ID>/events/?SyncEvolution=Google
The problem with --print-databases and Google CalDAV is already fixed. I
think Google did not implement support for calendar discovery initially,
and when they did, it required some more changes in SyncEvolution.
OK, after using my calendar ID, which had the form
<random string>(a)group.calendar.google.com
in the configuration, I was able to set up the target-config and print
items from the calendar (after adding a couple of test items). When I
went to push the local copy of my zimbra calendar (@default context,
file backend) to the Google calendar, all seemed to be going well for
a while, until the sync failed:
$ syncevolution --sync refresh-from-local google
[INFO] @default/addressbook: inactive
[INFO] @default/memo: inactive
[INFO] @default/todo: inactive
[INFO @google] target side of local sync ready
[INFO @google] @google/addressbook: inactive
[INFO @google] @google/memo: inactive
[INFO @google] @google/syncurl=https:: inactive
[INFO @google] @google/todo: inactive
[INFO @google] @google/calendar: starting first time sync from server
(peer is server)
[INFO @google] @google/calendar: deleting 0
[INFO] @default/calendar: starting first time sync, two-way (peer is client)
[INFO] creating complete data backup of source calendar before sync
(enabled with dumpData and needed for printChanges)
@default data changes to be applied during synchronization:
*** @default/calendar ***
Comparison was impossible.
[INFO] @default/calendar: started
[INFO] @default/calendar: sent 106/563
[INFO @google] @google/calendar: started
[INFO @google] adding "..."
.... 112 more "adding" lines like this last one, with my event
titles in quotes ....
[INFO @google] @google/calendar: received 105/669
[INFO] @default/calendar: first time sync done unsuccessfully
[INFO] server database not found, check URI 'calendar'
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed, see
/home/twilson/.cache/syncevolution/google-2014-04-19-11-41/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @google | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-local, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 669 before sync, 669 after it |
| object not found (remote, status 404) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sat Apr 19 11:41:16 2014, duration 1:45min |
| object not found (remote, status 404) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: error code from SyncEvolution object not
found (remote, status 404): PUT: bad HTTP status: <status 1.1, code
404, class 4, Not Found>
Data modified @default during synchronization:
*** @default/calendar ***
no changes
Any explanation for what happened, and what I should do next?
9:27 p.m.
New subject: [SyncEvolution] Google CalDAV sync
Any suggestions on this message of a week ago? Another run today
produced a similar result:
[INFO] @default/calendar: started
[INFO] @default/calendar: sent 106/563
[INFO @google] @google/calendar: started
[INFO @google] adding "..."
... a number of similar lines, interrupted occasionally with lines like
[ERROR @google] error code from SyncEvolution access denied (remote,
status 403): PUT: bad HTTP status: <status 1.1, code 403, class 4,
Forbidden>
... and then ending with
[INFO @google] @google/calendar: received 105/669
[INFO] @default/calendar: first time sync done unsuccessfully
[INFO] log in succeeded, but server refuses access - contact server operator
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed, see
/home/twilson/.cache/syncevolution/google-2014-04-27-14-14/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @google | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-local, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 669 before sync, 669 after it |
| access denied (remote, status 403) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Apr 27 14:14:25 2014, duration 2:23min |
| access denied (remote, status 403) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: error code from SyncEvolution access denied
(remote, status 403): PUT: bad HTTP status: <status 1.1, code 403,
class 4, Forbidden>
Data modified @default during synchronization:
*** @default/calendar ***
no changes
I can send the syncevolution-log.html file privately, if you like. Thanks,
--Todd
Todd Wilson, PhD
Department of Computer Science
California State University, Fresno
On Sat, Apr 19, 2014 at 12:08 PM, Todd Wilson <twilson(a)csufresno.edu> wrote:
On Fri, Apr 18, 2014 at 4:58 AM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> There is a "calendar ID". Use that in the URL of the form:
>
> https://www.google.com:443/calendar/dav/<calendar
ID>/events/?SyncEvolution=Google
>
> The problem with --print-databases and Google CalDAV is already fixed. I
> think Google did not implement support for calendar discovery initially,
> and when they did, it required some more changes in SyncEvolution.
OK, after using my calendar ID, which had the form
<random string>(a)group.calendar.google.com
in the configuration, I was able to set up the target-config and print
items from the calendar (after adding a couple of test items). When I
went to push the local copy of my zimbra calendar (@default context,
file backend) to the Google calendar, all seemed to be going well for
a while, until the sync failed:
$ syncevolution --sync refresh-from-local google
[INFO] @default/addressbook: inactive
[INFO] @default/memo: inactive
[INFO] @default/todo: inactive
[INFO @google] target side of local sync ready
[INFO @google] @google/addressbook: inactive
[INFO @google] @google/memo: inactive
[INFO @google] @google/syncurl=https:: inactive
[INFO @google] @google/todo: inactive
[INFO @google] @google/calendar: starting first time sync from server
(peer is server)
[INFO @google] @google/calendar: deleting 0
[INFO] @default/calendar: starting first time sync, two-way (peer is client)
[INFO] creating complete data backup of source calendar before sync
(enabled with dumpData and needed for printChanges)
@default data changes to be applied during synchronization:
*** @default/calendar ***
Comparison was impossible.
[INFO] @default/calendar: started
[INFO] @default/calendar: sent 106/563
[INFO @google] @google/calendar: started
[INFO @google] adding "..."
.... 112 more "adding" lines like this last one, with my event
titles in quotes ....
[INFO @google] @google/calendar: received 105/669
[INFO] @default/calendar: first time sync done unsuccessfully
[INFO] server database not found, check URI 'calendar'
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed, see
/home/twilson/.cache/syncevolution/google-2014-04-19-11-41/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @google | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-local, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 669 before sync, 669 after it |
| object not found (remote, status 404) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sat Apr 19 11:41:16 2014, duration 1:45min |
| object not found (remote, status 404) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: error code from SyncEvolution object not
found (remote, status 404): PUT: bad HTTP status: <status 1.1, code
404, class 4, Not Found>
Data modified @default during synchronization:
*** @default/calendar ***
no changes
Any explanation for what happened, and what I should do next?
6:19 a.m.
New subject: [SyncEvolution] Google CalDAV sync
On Sat, 2014-04-19 at 12:08 -0700, Todd Wilson wrote:
On Fri, Apr 18, 2014 at 4:58 AM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> There is a "calendar ID". Use that in the URL of the form:
>
> https://www.google.com:443/calendar/dav/<calendar
ID>/events/?SyncEvolution=Google
>
> The problem with --print-databases and Google CalDAV is already fixed. I
> think Google did not implement support for calendar discovery initially,
> and when they did, it required some more changes in SyncEvolution.
OK, after using my calendar ID, which had the form
<random string>(a)group.calendar.google.com
in the configuration, I was able to set up the target-config and print
items from the calendar (after adding a couple of test items). When I
went to push the local copy of my zimbra calendar (@default context,
file backend) to the Google calendar, all seemed to be going well for
a while, until the sync failed:
$ syncevolution --sync refresh-from-local google
[INFO] @default/addressbook: inactive
[INFO] @default/memo: inactive
[INFO] @default/todo: inactive
[INFO @google] target side of local sync ready
[INFO @google] @google/addressbook: inactive
[INFO @google] @google/memo: inactive
[INFO @google] @google/syncurl=https:: inactive
[INFO @google] @google/todo: inactive
[INFO @google] @google/calendar: starting first time sync from server
(peer is server)
[INFO @google] @google/calendar: deleting 0
[INFO] @default/calendar: starting first time sync, two-way (peer is client)
[INFO] creating complete data backup of source calendar before sync
(enabled with dumpData and needed for printChanges)
@default data changes to be applied during synchronization:
*** @default/calendar ***
Comparison was impossible.
[INFO] @default/calendar: started
[INFO] @default/calendar: sent 106/563
[INFO @google] @google/calendar: started
[INFO @google] adding "..."
.... 112 more "adding" lines like this last one, with my event
titles in quotes ....
[INFO @google] @google/calendar: received 105/669
[INFO] @default/calendar: first time sync done unsuccessfully
[INFO] server database not found, check URI 'calendar'
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed, see
/home/twilson/.cache/syncevolution/google-2014-04-19-11-41/syncevolution-log.html
for details.
The more interesting log will be the one for target-config@google. Make
sure that you run at loglevel=4.
Any explanation for what happened, and what I should do next?
Hard to tell without the log file. Can you reproduce this and send me
the log file privately?
If you are concerned about privacy, then you'll have to start looking at
the log file yourself and identify the item which fails to get stored on
the server.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7:15 p.m.
New subject: [SyncEvolution] Google CalDAV sync
On Thu, 2014-04-17 at 13:24 -0700, Todd Wilson wrote:
On Thu, Apr 17, 2014 at 5:26 AM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> Here's what it has stored for me for Google CalDAV:
>
> server: www.google.com/calendar/dav/%u/user/?SyncEvolution=Google
> user: patrick.ohly(a)googlemail.com
>
> The "server" and "user" values are used to find the stored
"password"
> value. I've not found good instructions for choosing keys. Make them too
> specific and you end up with more entries than necessary and the user
> has to fix them multiple times when changing the password on the server.
> Make them too unspecific and different passwords will conflict with each
> other. For example, an HTTP server might require different passwords for
> different paths, which is why SyncEvolution includes the path in the
> key.
I don't see anything like this. I only have the "GOA google
credentials for identity account_nnn" entries mentioned above, nothing
to do with CalDAV. Where are you seeing this?
I looked at one of the network passwords created by SyncEvolution. In
your keyring, that would be "xxxxx(a)zimbra.yyyyyy/dav/twilson"
and "xxxxx(a)zimbra.yyyyyy/dav/twilson/Calendar".
I have that for Google Calendar because I was accessing it via
traditional Basic Authentication, not via OAuth2.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
2704
days inactive
2715
days old
syncevolution@synevolution.org
8 comments
3 participants
participants (3)
-
Emiliano Heyns -
Patrick Ohly -
Todd Wilson