"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/[email protected]/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 <[email protected]> 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. > > > _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
