On Mon, 2012-07-09 at 13:17 +1200, Jane Atkinson wrote: > On 09/07/12 07:38, Patrick Ohly wrote: > > On Mon, 2012-07-09 at 02:09 +1200, Jane Atkinson wrote: > >> On 09/07/12 01:32, Patrick Ohly wrote: > >>> On Sat, 2012-07-07 at 16:24 +1200, Jane Atkinson wrote: > >>>> Can you quote the output? What kind of changes did you expect > >>>> to > >>> get synced? > >> > >> It's a day or two now since I did this, so it's from memory. I > >> had changed the end time of an event - something I've done > >> regularly in the past with no problems. The messages in the > >> terminal were exactly what I'd expect to see if no changes had > >> been made. > >> > >> Only a calendar.before directory was created - nothing else. And > >> a log file, of course. > > > > Then the sync process crashed without completing normally. > > Otherwise there would be a calendar.after directory. Can you send > > me that syncevolution-log.html file? > > > > Can you reproduce the problem? If yes, then try to capture a stack > > backtrace of the crash, like this: - killall syncevo-dbus-server - > > SYNCEVOLUTION_SYNC_DELAY=60 /usr/libexec/syncevo-dbus-server & - in > > another shell, run the command line - in a third shell, run "gdb -p > > `pidof syncevo-dbus-helper`" followed by "cont" (when debugger has > > attached) and "thread apply all bt" (once/if it crashed) > > > > It's a bit more complicated than I first thought. > > When I originally set up on this installation, I simply copied the > config files from a working install (same machine, different > partition). That config resulted in the logfile I sent earlier.
Copying the entire config tree is problematic if you want to continue using both old and new config. To the phone it will look the same computer. The data storage itself is the same, but additional meta data stored on the computer is not, which will cause problems during incremental syncs. For normal configs, this can be fixed by updating the "deviceId" property after copying a config. However, in this case the data is shared between computers (assuming that the WebDAV server is external) which would continue to cause problems when switching between computers as sync owner (new item on WebDAV will be sent as new by computer A, and again by computer B). > To do the tests you asked for, I thought I'd set up a fresh config > from scratch. No problems while I setup the target-config > > Then: > ~$ syncevolution --configure \ > --template SyncEvolution_Client \ > syncURL=local://@webdav \ > username= \ > password= \ > webdav \ > calendar addressbook > > [INFO] addressbook: looking for databases... > [INFO] addressbook: no backend available > [ERROR] error code from SyncEvolution fatal error (local, status > 10500): addressbook: no backend available > > (If I remove "addressbook" from the last line, I simply get the same > error message regarding "calendar".) That's normal. The "webdav" config here would be for syncing your default local databases, but because the EDS backend isn't working on an installation without Evolution, such a config cannot be created. KDE users have to explicitly configure the @default addressbook/calendar/... source to use Akonadi. You want to configure a phone to sync with WebDAV, so you don't need the "webdav" config. > ~$ syncevolution --configure \ > > syncURL=obex-bt://xxxxxxxxxxx \ --template Nokia_N900 \ > > ja_6120c@webdav > [INFO] addressbook: looking for databases... > [INFO] addressbook: backend failed > [INFO] calendar: looking for databases... > [INFO] calendar: backend failed > [INFO] calendar+todo: looking for databases... > [INFO] calendar+todo: backend failed > [INFO] memo: looking for databases... > [INFO] memo: okay > [INFO] todo: looking for databases... > [INFO] todo: backend failed > > After adding the login and password details to the files, I tried a sync. > > Only the memos (on Radicale) synced. Did you configure the "backend", "database", "databaseUser", "databasePassword" of calendar/addressbook/todo first? > On trying the set of commands you requested I get: > > ~$ SYNCEVOLUTION_SYNC_DELAY=60 /usr/libexec/syncevo-dbus-server & > [1] 5506 > ~$ [WARNING syncevo-dbus-server] libnotify: Failed to connect to proxy > [INFO syncevo-dbus-server] ready to run > > > Next thing was to remove the new config files and put the old ones back. > > On trying to run the set of commands I get: > > (first shell) > ~$ SYNCEVOLUTION_SYNC_DELAY=60 /usr/libexec/syncevo-dbus-server & > [1] 1282 > ~$ [ERROR syncevo-dbus-server] dbus_get_bus_connection() failed - > server already running? > > (second shell) > ~$ syncevolution ja_6120c@webdav > [INFO] Server sending SAN > [INFO] calendar: starting slow sync, two-way (peer is client) > [INFO] todo: starting slow sync, two-way (peer is client) > [INFO] addressbook: starting slow sync, two-way (peer is client) > [INFO] memo: starting slow sync, two-way (peer is client) > [INFO] creating complete data backup of source calendar before sync > (enabled with dumpData and needed for printChanges) > > (third shell) > ~$ gdb -p `pidof syncevo-dbus-helper` > gdb: option '--p' requires an argument > Use `gdb --help' for a complete list of options. You didn't kill an already syncevo-dbus-server, so the one which served the command line's request ran without the artificial 60 second delay, which prevented catching syncevo-dbus-helper before it crashed. The log that you sent me confirms that it crashes on the first use of libneon for the "calendar" source. The following steps might make it easier to get a stack backtrace: $ SYNCEVOLUTION_DEBUG=1 gdb syncevolution gdb> run --daemon=no --print-items ja_6120c@webdav calendar ... gdb> thread apply all bt > Incidentally, I'm beginning to wonder if this has something to do with > DCS, since the only thing that worked wasn't a DCS connection. What is DCS? -- 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
