On Thu, 2012-11-22 at 14:31 +0100, [email protected] wrote: > On Thu, Nov 22, 2012 at 14:29:21 +0100, [email protected] > wrote: > > [...] > > > The stack of syncevo-dbus-helper looks like this: > > > > #0 0x00007f576b1a1e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6 > > #1 0x00007f57685b7d30 in ?? () from > > #/lib/x86_64-linux-gnu/libdbus-1.so.3 > > #2 0x00007f57685b6bfd in ?? () from > > #/lib/x86_64-linux-gnu/libdbus-1.so.3 > > #3 0x00007f57685a1904 in ?? () from > > #/lib/x86_64-linux-gnu/libdbus-1.so.3 > > #4 0x00007f57685a29fa in ?? () from > > #/lib/x86_64-linux-gnu/libdbus-1.so.3 > > #5 0x00007f57660675aa in ?? () > > from /usr/lib/x86_64-linux-gnu/libgnome-keyring.so.0 > > #6 0x00007f576628e787 in SyncEvo::GNOMESavePasswordSlot (keyring=..., > > passwordName=..., password=..., key=...) > > at src/backends/gnome/GNOMEPlatform.cpp:118 > > > > So maybe it prompts for some password. I'll see if I get home. :-) > > Setting keyring=no in the global config fixes this issue.
Yes, it probably got stuck waiting for user input. The libgnome-keyring calls are all blocking. SyncEvolution needs more INFO messages. It avoided them traditionally because before 1.3, INFO messages became part of the output - not what you want when dumping items to stdout. Since 1.3, the INFO goes to stderr and thus it became possible to have more of it. That just hasn't been added yet. -- 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] http://lists.syncevolution.org/listinfo/syncevolution
