Re: [SyncEvolution] Syncevolution-bundle dependencies

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?

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP+pJyAAoJEERzSJEx033jnj8H/00rJ6dGP88fTVFAHhbxEpYp UprkFDdJLeDtIktrrAtcyNk81JcGgNsmZXaVxsJ8U0esTzfdgGhcENh+8IW0wiL4 fIIk7WbW8LFEL5jy59khco8+SlMPFPm5pWVRT+HUiHYx1EknXusut6WCKdJMtkv1 SFyPPZlu+/8AnUuZH8DaI40uzKHjngWUo2uP69P+ER7fyGU28HPZybDIV7gZr3xE m56xadrDp2QHnflz2opfBdSf5RfiiteR04ejnr2PpiFsTx7W7Ubn9zftPGwxUn9k p2aWNseAncyoaCyIamsdNb6bgwsyzgtfi2ZdVa9xlDJAI4uaR9iF4rykDTSiIkA= =a35j -----END PGP SIGNATURE-----