-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/07/12 19:22, Patrick Ohly wrote: > 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. > Good point. I'll discard the copied config directories.
> 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. So I can use a "default" config here. Does that mean that sync-ui can be used for running refresh-from-local and slow-sync if needed? Or is that only for Evolution-based configurations? > >> ~$ 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? > Yes I configured those before trying to sync anything. >> 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 > I'll try running these new commands shortly. >> 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? > Sorry, Darwin CalendarServer. The Radicale backend was OK for syncing but the CalendarServer backend (addressbook, todo, calendar) isn't working in this case. Jane Atkinson -----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----- _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
