On Mon, 2010-05-10 at 14:27 +0100, Alec Leamas wrote: > I'm a newbie having a somewhat working setup where my phone and some > laptops are synchronized to my home server using the http server. The > problem is the home server itself. > > The syncevolution server side uses a file backend.
You know that this is not absolutely required? The server will use the normal Evolution backends if you drop the "--evolution-source" parameter in the HOWTO: http://syncevolution.org/development/http-server-howto > So what I want to do > is to synchronize an evolution datasource against a file backend on the > same machine. I have created a client configuration for the server which > is a clone of the working client setups. Trying to sync, I get various > errors depending on using the 'daemon=no' option or not. You definitely need --daemon=no. Otherwise you cannot have a client and server sync session in the same user account on the same machine. But with a proper setup and --daemon=no it should work. Can you quote the output of "--print-config -q" for the client and server config involved in this local sync? > Occasionally, > using 'daemon=no' makes the sync works almost completely, but it still > fails in the very end. > > A log is available on ftp://mumin.dnsalias.net/pub/local-sync-log.html. > Part of this is an embedded html file which seems to contain some > clues, at ftp://mumin.dnsalias.net/pub/local-sync-log.html. Is this the client side of the sync? In any case, at some point the peer starts sending empty VCALENDAR items: [2010-05-10 15:03:03.100] BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.6//EN END:VCALENDAR This leads to failures like "calendar: extracting event". The original error is on the other side. Do you see something in the log of that side or the data it accesses which explains the origin of this item? -- 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
