6:41 p.m.
I may be overlooking something obvious here, but when using the latest
version (1.4.99.4-1) on Ubuntu 14.04, my GOA credentials are not being found:
% syncevolution --sync refresh-from-local google
[ERROR] goa:account_nnnn: need username+password as credentials
The account number I'm redacting as "nnnn" does exist (I can see it with
seahorse) and is authorized.
I've also tried deleting the account in seahorse and Online Accounts,
starting over with a new account, and replacing the old account number in my
google target-config with the new number, but I still get the same error.
12:23 p.m.
On Sun, 2014-10-05 at 01:41 +0000, Todd Wilson wrote:
I may be overlooking something obvious here, but when using the
latest
version (1.4.99.4-1) on Ubuntu 14.04, my GOA credentials are not being found:
% syncevolution --sync refresh-from-local google
[ERROR] goa:account_nnnn: need username+password as credentials
The account number I'm redacting as "nnnn" does exist (I can see it with
seahorse) and is authorized.
This is something different. GOA credentials are found, but in addition,
a method in SyncEvolution ("IdentityProviderCredentials()") is called to
retrieve username and password for the account, which can't work.
The method shouldn't be called. I'm not sure where it gets called either
and cannot reproduce it here. Can you help to locate the call?
Run like this:
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync refresh-from-local
google
# b IdentityProviderCredentials
# run
...
# where
This assumes that the local side runs into the problem. That's not
guaranteed. It could also be the side where WebDAV is active. To find
that, use:
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync refresh-from-local
printChanges=0 google
# set follow-fork-mode child
# b IdentityProviderCredentials
# run
...
# where
--
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.
2:26 p.m.
It looks like the breakpoints weren't hit in either case (account #
replaced by nnnn):
$ SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync
refresh-from-local google
[...]
Reading symbols from syncevolution...done.
(gdb) b IdentityProviderCredentials
Function "IdentityProviderCredentials" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (IdentityProviderCredentials) pending.
(gdb) run
Starting program: /usr/bin/syncevolution --daemon=no --sync
refresh-from-local google
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[DEBUG 00:00:00] log path -> /home/twilson/.cache/syncevolution, <okay>
[DEBUG 00:00:00] checking log dir /home/twilson/.cache/syncevolution
[DEBUG 00:00:00] logfile:
/home/twilson/.cache/syncevolution/google-2014-10-05-14-12/syncevolution-log.html
[ERROR] goa:account_nnnn: need username+password as credentials
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed, see
/home/twilson/.cache/syncevolution/google-2014-10-05-14-12/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @google | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Oct 5 14:12:48 2014, duration 0:00min |
| fatal error (local, status 10500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: goa:account_nnnn: need username+password as credentials
[Inferior 1 (process 9427) exited with code 01]
(gdb) where
No stack.
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync
refresh-from-local printChanges=0 google
[...]
Reading symbols from syncevolution...done.
(gdb) set follow-fork-mode child
(gdb) b IdentityProviderCredentials
Function "IdentityProviderCredentials" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (IdentityProviderCredentials) pending.
(gdb) run
Starting program: /usr/bin/syncevolution --daemon=no --sync
refresh-from-local printChanges=0 google
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[DEBUG 00:00:00] log path -> /home/twilson/.cache/syncevolution, <okay>
[DEBUG 00:00:00] checking log dir /home/twilson/.cache/syncevolution
[DEBUG 00:00:00] logfile:
/home/twilson/.cache/syncevolution/google-2014-10-05-14-18/syncevolution-log.html
[ERROR] goa:account_nnnn: need username+password as credentials
[INFO] creating complete data backup after sync (because it was
enabled with dumpData)
Synchronization failed, see
/home/twilson/.cache/syncevolution/google-2014-10-05-14-18/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @google | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Oct 5 14:18:17 2014, duration 0:00min |
| fatal error (local, status 10500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: goa:account_nnnn: need username+password as credentials
[Inferior 1 (process 9523) exited with code 01]
(gdb) where
No stack.
Todd Wilson, PhD
Department of Computer Science
California State University, Fresno
On Sun, Oct 5, 2014 at 12:23 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Sun, 2014-10-05 at 01:41 +0000, Todd Wilson wrote:
> I may be overlooking something obvious here, but when using the latest
> version (1.4.99.4-1) on Ubuntu 14.04, my GOA credentials are not being found:
>
> % syncevolution --sync refresh-from-local google
> [ERROR] goa:account_nnnn: need username+password as credentials
>
> The account number I'm redacting as "nnnn" does exist (I can see it
with
> seahorse) and is authorized.
This is something different. GOA credentials are found, but in addition,
a method in SyncEvolution ("IdentityProviderCredentials()") is called to
retrieve username and password for the account, which can't work.
The method shouldn't be called. I'm not sure where it gets called either
and cannot reproduce it here. Can you help to locate the call?
Run like this:
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync refresh-from-local
google
# b IdentityProviderCredentials
# run
...
# where
This assumes that the local side runs into the problem. That's not
guaranteed. It could also be the side where WebDAV is active. To find
that, use:
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync refresh-from-local
printChanges=0 google
# set follow-fork-mode child
# b IdentityProviderCredentials
# run
...
# where
--
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.
11:33 p.m.
On Sun, 2014-10-05 at 14:26 -0700, Todd Wilson wrote:
It looks like the breakpoints weren't hit in either case (account
#
replaced by nnnn):
My bad, I forgot the "SyncEvo" namespace -> "b
SyncEvo::IdentityProviderCredentials". Never mind.
$ SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync
refresh-from-local google
[...]
Reading symbols from syncevolution...done.
(gdb) b IdentityProviderCredentials
Function "IdentityProviderCredentials" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (IdentityProviderCredentials) pending.
(gdb) run
Starting program: /usr/bin/syncevolution --daemon=no --sync
refresh-from-local google
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[DEBUG 00:00:00] log path -> /home/twilson/.cache/syncevolution, <okay>
[DEBUG 00:00:00] checking log dir /home/twilson/.cache/syncevolution
[DEBUG 00:00:00] logfile:
/home/twilson/.cache/syncevolution/google-2014-10-05-14-12/syncevolution-log.html
[ERROR] goa:account_nnnn: need username+password as credentials
[INFO] creating complete data backup after sync (enabled with dumpData
and needed for printChanges)
Synchronization failed, see
/home/twilson/.cache/syncevolution/google-2014-10-05-14-12/syncevolution-log.html
for details.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | @default | @google | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Sun Oct 5 14:12:48 2014, duration 0:00min |
| fatal error (local, status 10500) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: goa:account_nnnn: need username+password as credentials
The output narrows it down already a bit.
Did you somehow end up with "username=goa:..." in your "google" sync
config? Can you reproduce how this happened? The username there can and
should be empty, because you are running a local sync which doesn't need
one.
But the code preparing the sync isn't aware of that and tries to
retrieve username/password combination if the username property is set.
I can reproduce that after changing my test config accordingly.
It will be easy to avoid the call to IdentityProviderCredentials() in
this case such that the "username" property gets ignored completely.
Would that be better? Or should a non-empty value be considered an
error? With which error message?
--
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.
10:44 a.m.
"username=goa:..." is in google/peers/target-config/config.ini and not
in any of the other config.ini files. I'm pretty sure I set this
explicitly in my initial --configure back several version ago, which
looked something like
syncevolution --configure --template webdav username=goa:account_...
calendar/backend=caldav
calendar/database="https://www.google.com:443/calendar/dav/...@group.calendar.google.com/events/?SyncEvolution=Google"
syncURL=https://apidata.googleusercontent.com/caldav/v2
target-config@google calendar
As for your question about the error message, I would opt for an
approach that attempts to maintain the semantic integrity of the
configuration files. If that value in the username field semantically
shouldn't be there, then I think at least a warning would be given.
Stronger options would be (1) to give the user an option (via a
prompt) to remove the value from the configuration, or even (2)
silently remove it automatically. It should be ignored only if it is
semantically consistent for it to be there.
--Todd
Todd Wilson, PhD
Department of Computer Science
California State University, Fresno
On Sun, Oct 5, 2014 at 11:33 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Sun, 2014-10-05 at 14:26 -0700, Todd Wilson wrote:
> It looks like the breakpoints weren't hit in either case (account #
> replaced by nnnn):
My bad, I forgot the "SyncEvo" namespace -> "b
SyncEvo::IdentityProviderCredentials". Never mind.
> $ SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync
> refresh-from-local google
> [...]
> Reading symbols from syncevolution...done.
> (gdb) b IdentityProviderCredentials
> Function "IdentityProviderCredentials" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 1 (IdentityProviderCredentials) pending.
> (gdb) run
> Starting program: /usr/bin/syncevolution --daemon=no --sync
> refresh-from-local google
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [DEBUG 00:00:00] log path -> /home/twilson/.cache/syncevolution, <okay>
> [DEBUG 00:00:00] checking log dir /home/twilson/.cache/syncevolution
> [DEBUG 00:00:00] logfile:
> /home/twilson/.cache/syncevolution/google-2014-10-05-14-12/syncevolution-log.html
> [ERROR] goa:account_nnnn: need username+password as credentials
> [INFO] creating complete data backup after sync (enabled with dumpData
> and needed for printChanges)
>
> Synchronization failed, see
> /home/twilson/.cache/syncevolution/google-2014-10-05-14-12/syncevolution-log.html
> for details.
>
> Changes applied during synchronization:
> +---------------|-----------------------|-----------------------|-CON-+
> | | @default | @google | FLI |
> | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
> +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> | start Sun Oct 5 14:12:48 2014, duration 0:00min |
> | fatal error (local, status 10500) |
> +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
> First ERROR encountered: goa:account_nnnn: need username+password as credentials
The output narrows it down already a bit.
Did you somehow end up with "username=goa:..." in your "google" sync
config? Can you reproduce how this happened? The username there can and
should be empty, because you are running a local sync which doesn't need
one.
But the code preparing the sync isn't aware of that and tries to
retrieve username/password combination if the username property is set.
I can reproduce that after changing my test config accordingly.
It will be easy to avoid the call to IdentityProviderCredentials() in
this case such that the "username" property gets ignored completely.
Would that be better? Or should a non-empty value be considered an
error? With which error message?
--
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.
11:11 a.m.
On Mon, 2014-10-06 at 10:44 -0700, Todd Wilson wrote:
"username=goa:..." is in
google/peers/target-config/config.ini and not
in any of the other config.ini files.
Nevertheless, can you show the output of:
syncevolution --print-config -q google
syncevolution --print-config -q target-config@google
In addition, repeat the exercise with locating the error. This time,
let's catch both throws and the function:
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync
refresh-from-local google
# b SyncEvo::IdentityProviderCredentials
# catch throw
# run
...
# where / cont
As for your question about the error message, I would opt for an
approach that attempts to maintain the semantic integrity of the
configuration files. If that value in the username field semantically
shouldn't be there, then I think at least a warning would be given.
You are right, warnings are under-utilized. That would be a good option.
Stronger options would be (1) to give the user an option (via a
prompt) to remove the value from the configuration, or even (2)
silently remove it automatically. It should be ignored only if it is
semantically consistent for it to be there.
Editing the config is hard. The command line tool is only one of several
ways how the user might run a sync, so any solution that only works for
the command line (and only when run interactively) would be incomplete.
OTOH, only users of the command line are likely to end up with wrong
configs.
I don't like rewriting the config without user confirmation. There's
always the possibility that the user wanted it to be that way and an
automatism makes things worse.
--
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.
5:24 p.m.
On Mon, Oct 6, 2014 at 11:11 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mon, 2014-10-06 at 10:44 -0700, Todd Wilson wrote:
> "username=goa:..." is in google/peers/target-config/config.ini and not
> in any of the other config.ini files.
Nevertheless, can you show the output of:
syncevolution --print-config -q google
syncevolution --print-config -q target-config@google
[I'm leaving off the blank options to save space and redacting a few
id numbers; let me know if you need more]
syncURL = local://@google
username = goa:account_...
password =
PeerIsClient = 1
deviceId = syncevolution-...
remoteDeviceId = syncevolution-... [different from previous line]
IconURI = image://themedimage/icons/services/syncevolution
ConsumerReady = 1
[addressbook]
sync = disabled
uri = addressbook
backend = addressbook
[calendar]
sync = two-way
uri = calendar
backend = file
database = file:///home/twilson/.local/cal-sync
databaseFormat = text/calendar
[memo]
sync = disabled
uri = memo
backend = memo
[todo]
sync = disabled
uri = todo
backend = todo
--------------------------------
syncURL = https://apidata.googleusercontent.com/caldav/v2
username = goa:account_... [same as username above]
printChanges = 0
dumpData = 0
deviceId = syncevolution-... [same as deviceID above]
IconURI = image://themedimage/icons/services/webdav
ConsumerReady = 1
peerType = WebDAV
[addressbook]
sync = disabled
backend = CardDAV
database =
https://www.google.com:443/calendar/dav/...@group.calendar.google.com/eve...
[calendar]
sync = disabled
backend = CalDAV
database =
https://www.google.com:443/calendar/dav/...%40group.calendar.google.com/e...
[memo]
sync = disabled
backend = CalDAVJournal
database =
https://www.google.com:443/calendar/dav/...@group.calendar.google.com/eve...
[syncurl=https:]
database =
https://www.google.com:443/calendar/dav/...@group.calendar.google.com/eve...
[todo]
sync = disabled
backend = CalDAVTodo
database =
https://www.google.com:443/calendar/dav/...@group.calendar.google.com/eve...
In addition, repeat the exercise with locating the error. This time,
let's catch both throws and the function:
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --sync
refresh-from-local google
# b SyncEvo::IdentityProviderCredentials
# catch throw
# run
...
# where / cont
I'm sending the output in a separate private email.
--Todd
11:56 p.m.
On Mon, 2014-10-06 at 17:24 -0700, Todd Wilson wrote:
On Mon, Oct 6, 2014 at 11:11 AM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Mon, 2014-10-06 at 10:44 -0700, Todd Wilson wrote:
>> "username=goa:..." is in google/peers/target-config/config.ini and
not
>> in any of the other config.ini files.
>
> Nevertheless, can you show the output of:
>
> syncevolution --print-config -q google
> syncevolution --print-config -q target-config@google
[I'm leaving off the blank options to save space and redacting a few
id numbers; let me know if you need more]
syncURL = local://@google
username = goa:account_...
When I asked about "username=goa:..." in your "google" sync
config", I
meant the "google" config. You said that only
google/peers/target-config/config.ini has username=goa:... set, but then
why does it show up here?
Is it really unset in default/peers/google/config.ini?
Anyway, removing it in the "google" config should allow you to run syncs
again:
syncevolution --configure username= google
I'm sending the output in a separate private email.
That confirms my theory and matches what I was able to reproduce myself
earlier.
--
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.
9:28 a.m.
On Mon, Oct 6, 2014 at 11:56 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > Nevertheless, can you show the output of:
> >
> > syncevolution --print-config -q google
> > syncevolution --print-config -q target-config@google
>
> [I'm leaving off the blank options to save space and redacting a few
> id numbers; let me know if you need more]
>
> syncURL = local://@google
> username = goa:account_...
When I asked about "username=goa:..." in your "google" sync
config", I
meant the "google" config. You said that only
google/peers/target-config/config.ini has username=goa:... set, but then
why does it show up here?
Is it really unset in default/peers/google/config.ini?
Sorry, I was just looking in google/ and didn't think to look in default/:
$ cd ~/.config/syncevolution
$ find . -name config.ini -print | xargs grep goa
./default/peers/google/config.ini:username = goa:account_...
./google/peers/target-config/config.ini:username = goa:account_...
Anyway, removing it in the "google" config should allow you
to run syncs
again: syncevolution --configure username= google
Yes, authentication is successful now, but I'm still having some
problems with the sync. Perhaps we'll have to go into details off-list
about the contents of the events, but here is a selection of some of
the maybe relevant lines that were printed on a non-debug run:
[INFO @google] @google/calendar: starting first time sync from server
(peer is server)
[INFO @google] @google/calendar: deleting 1/1
[INFO] @default/calendar: starting first time sync, two-way (peer is client)
[INFO] @default/calendar: started
[INFO] @default/calendar: sent 99/656
[INFO @google] @google/calendar: started
[INFO @google] adding "....." [one of 98 such lines, interspersed with
two instances of:]
[ERROR @google] error code from SyncEvolution object not found
(remote, status 404): PUT: bad HTTP status: <status 1.1, code 404,
class 4, Not Found>
... and ending with:
[INFO @google] @google/calendar: received 98/755
[INFO] @default/calendar: first time sync done unsuccessfully
[INFO] @default/calendar: 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-10-07-09-06/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: 755 before sync, 755 after it |
| object not found (remote, status 404) |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Tue Oct 7 09:06:27 2014, duration 1:09min |
| 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
> I'm sending the output in a separate private email.
That confirms my theory and matches what I was able to reproduce myself
earlier.
Glad I was able to help.
--Todd
12:08 p.m.
On Tue, 2014-10-07 at 09:28 -0700, Todd Wilson wrote:
On Mon, Oct 6, 2014 at 11:56 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> > > Nevertheless, can you show the output of:
> > >
> > > syncevolution --print-config -q google
> > > syncevolution --print-config -q target-config@google
> >
> > [I'm leaving off the blank options to save space and redacting a few
> > id numbers; let me know if you need more]
> >
> > syncURL = local://@google
> > username = goa:account_...
>
> When I asked about "username=goa:..." in your "google" sync
config", I
> meant the "google" config. You said that only
> google/peers/target-config/config.ini has username=goa:... set, but then
> why does it show up here?
>
> Is it really unset in default/peers/google/config.ini?
Sorry, I was just looking in google/ and didn't think to look in default/:
$ cd ~/.config/syncevolution
$ find . -name config.ini -print | xargs grep goa
./default/peers/google/config.ini:username = goa:account_...
./google/peers/target-config/config.ini:username = goa:account_...
Do you have an idea how it got there? I don't think previous
SyncEvolution versions worked with such a config.
> Anyway, removing it in the "google" config should
allow you to run syncs
> again: syncevolution --configure username= google
Yes, authentication is successful now, but I'm still having some
problems with the sync. Perhaps we'll have to go into details off-list
about the contents of the events,
That would be good. A target-config@google log file at loglevel=4 would
be useful.
--
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.
3:51 p.m.
On Tue, Oct 7, 2014 at 12:08 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> Sorry, I was just looking in google/ and didn't think to look
in default/:
>
> $ cd ~/.config/syncevolution
> $ find . -name config.ini -print | xargs grep goa
> ./default/peers/google/config.ini:username = goa:account_...
> ./google/peers/target-config/config.ini:username = goa:account_...
Do you have an idea how it got there? I don't think previous
SyncEvolution versions worked with such a config.
I'm not sure, but my guess is that it was the direct result of an
earlier, misguided attempt to correct a problem with my configuration,
maybe even by directly editing a configuration file.
> > Anyway, removing it in the "google" config should
allow you to run syncs
> > again: syncevolution --configure username= google
>
> Yes, authentication is successful now, but I'm still having some
> problems with the sync. Perhaps we'll have to go into details off-list
> about the contents of the events,
That would be good. A target-config@google log file at loglevel=4 would
be useful.
Coming soon by private email.
--Todd
2:20 a.m.
New subject: [SyncEvolution] Google CalDAV: recreate meeting / refresh-from-local (was: Re: GOA credentials not found)
On Tue, 2014-10-07 at 15:51 -0700, Todd Wilson wrote:
>> > Anyway, removing it in the "google" config
should allow you to run syncs
>> > again: syncevolution --configure username= google
>>
>> Yes, authentication is successful now, but I'm still having some
>> problems with the sync. Perhaps we'll have to go into details off-list
>> about the contents of the events,
>
> That would be good. A target-config@google log file at loglevel=4 would
> be useful.
Coming soon by private email.
I've looked at the logs and it seems that it affects only meetings. I
could reproduce the problem. IMHO it is a problem in the Google Calendar
server: once a meeting got created, the server remembers it forever. A
DELETE via CalDAV merely removes the event from the user's calendar.
Then later the PUT fails because it conflicts with the copy that Google
still has somewhere.
I've opened a StackOverflow entry for this:
http://stackoverflow.com/questions/26253250/google-caldav-recreate-meeting
--
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.
10:53 a.m.
New subject: [SyncEvolution] Google CalDAV: recreate meeting / refresh-from-local (was: Re: GOA credentials not found)
On Wed, Oct 8, 2014 at 2:20 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> >> Yes, authentication is successful now, but I'm still having some
> >> problems with the sync. Perhaps we'll have to go into details off-list
> >> about the contents of the events,
> >
> > That would be good. A target-config@google log file at loglevel=4
would
> > be useful.
>
> Coming soon by private email.
I've looked at the logs and it seems that it affects only meetings. I
could reproduce the problem. IMHO it is a problem in the Google Calendar
server: once a meeting got created, the server remembers it forever. A
DELETE via CalDAV merely removes the event from the user's calendar.
Then later the PUT fails because it conflicts with the copy that Google
still has somewhere.
I've opened a StackOverflow entry for this:
http://stackoverflow.com/questions/26253250/google-caldav-recreate-meeting
Thanks for troubleshooting the problem, which makes sense. In the calendar
from which these events are coming (Zimbra), they have a status that is
different from other events: because they are organized by someone else, I
can't modify them unless I first make a local copy and then modify the
copy. Perhaps the logic on Google's server is attempting to keep the same
distinction.
I'll follow your StackOverflow question and see what they come up with.
--Todd
2060
days inactive
2063
days old
syncevolution@synevolution.org
12 comments
2 participants
participants (2)
-
Patrick Ohly -
Todd Wilson