9:57 p.m.
Hi,
On my debian testing machines I am trying to realize syncevolution by
implementing the http-server howto of the development-pages:
On the server I Issue the commands:
syncevo-dbus-server &
and
/usr/bin/syncevo-http-server http://192.168.6.2:9000/syncevolution
(All sources are files configured according to the method I described in my post
at march 23rd)
When I enter the address " http://192.168.6.2:9000/syncevolution" in browsers
on both the server(192.168.6.2) and client machine(192.168.6.3) a page
containing the comforting phrase
"SyncEvolution SyncML Server"
appears.
When I try to connect (and synchronise) from the client machine, using
"syncevolution servername"
the connection fails at an early stage with an error:
"could not allocate SoupMessage"
and not even any reaction on the prompt of the server machine where the
syncevo-http-server-process is running (e.g. to verify the ID mentioned in
steps 8-10 of the HOWTO)
Any idea what might be wrong or what I should investigate further to get
things working?
PS. I want to get this working because:
The Bluetooth-obex solution between the ics-file on computer and N900 is
failing lately: I cannot get it working from the preferred OS again. From the
syncevolution pages I got the impression that this is due to a known and
bug in the BT-NokiaSyncMLserver system outside the scope of syncevolution?
Also a HTTP route feels more reliable and versatile than BT.
Regards, Hans de Jonge
1:07 p.m.
On So, 2011-05-15 at 21:57 +0100, Hans de Jonge wrote:
When I try to connect (and synchronise) from the client machine,
using
"syncevolution servername"
the connection fails at an early stage with an error:
"could not allocate SoupMessage"
That means that something is wrong on the client side. Does this run on
the Debian testing machine or some other platform?
Which SyncEvolution binary are you using?
What is the syncURL for "servername"?
--
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.
3:53 p.m.
Op dinsdag 17 mei 2011 14:07:31 schreef u:
On So, 2011-05-15 at 21:57 +0100, Hans de Jonge wrote:
> When I try to connect (and synchronise) from the client machine, using
> "syncevolution servername"
> the connection fails at an early stage with an error:
> "could not allocate SoupMessage"
That means that something is wrong on the client side. Does this run on
the Debian testing machine or some other platform?
Which SyncEvolution binary are you using?
What is the syncURL for "servername"?
Hi Patrick,
Thanks for your reply
Here some more configuration information, I hope this helps.
Yhe Bluetooth comment is a bit OT in this thread, but I added it in case it
might interest you.
Both machines run Debian-testing with
[syncevolution-evolution 1.1.1-2]
And syncevolution-evolution from repo:
[deb http://downloads.syncevolution.org/apt stable main]
[Server]
server-arch = amd64: (bluetooth sync N900 not working)
@server (IP=192.168.6.2): I start
[hansdej]> syncevo-debus-server &
[hansdej]> syncevo-http-server http://192.168.6.2:9000/syncevolution &
syncevolution --print-config -q client |grep -v "^#"
username = hansdej
password = -
PeerIsClient = 1
deviceId = syncevolution-6ff10aa8-8d4e-4e12-9cde-6b517ba531b2
remoteDeviceId = syncevolution-2df101b5-97b4-4917-850c-656dd57815f2
WebURL = http://www.scheduleworld.com
defaultPeer = OtherClientName
[client]
client-arch = i386 (BT sync with N900 is working)
@Client(client-IP=192.168.6.3):
[hansdej]>syncevolution --print-config -q server|grep -v "^#"
syncURL = http://192.168.6.2:9000/syncevolution
username = hansdej
password = -
PeerIsClient = 1
PeerName = server
deviceId = syncevolution-2df101b5-97b4-4917-850c-656dd57815f2
remoteDeviceId = syncevolution-6ff10aa8-8d4e-4e12-9cde-6b517ba531b2
WebURL = http://www.scheduleworld.com
Some additional info from the binaries:
@server:
[hansdej]> syncevolution --version
SyncEvolution 1.1.1
using libedataserver-1.2.so.14 - might not be compatible!
using libebook-1.2.so.10 - might not be compatible!
using libecal-1.2.so.8 - might not be compatible!
using libecal-1.2.so.8 - might not be compatible!
using libbluetooth.so.3
Loading backend libr[...]ends/syncqtcontacts.so
Loading backend libr[...]ends/syncaddressbook.so
Loading backend libr[...]ends/syncecal.so
Loading backend libr[...]ends/syncfile.so
Loading backend libr[...]ends/syncebook.so
Loading backend libr[...]ends/syncxmlrpc.so
Loading backend libr[...]ends/syncsqlite.so
Loading backend libr[...]ends/synckcalextended.so
Loading backend libr[...]ends/syncmaemocal.so
@client:
syncevolution --version
SyncEvolution 1.1.1
using libedataserver-1.2.so.13 - might not be compatible!
using libebook-1.2.so.9
using libecal-1.2.so.7
using libecal-1.2.so.7
using libbluetooth.so.3
Loading backend libr[...]ends/syncxmlrpc.so
Loading backend libr[...]ends/syncmaemocal.so
Loading backend libr[...]ends/syncqtcontacts.so
Loading backend libr[...]ends/syncaddressbook.so
Loading backend libr[...]ends/syncecal.so
Loading backend libr[...]ends/syncsqlite.so
Loading backend libr[...]ends/synckcalextended.so
Loading backend libr[...]ends/syncfile.so
Loading backend libr[...]ends/syncebook.so
4:26 p.m.
On Di, 2011-05-17 at 15:53 +0100, Hans de Jonge wrote:
[client]
client-arch = i386 (BT sync with N900 is working)
@Client(client-IP=192.168.6.3):
[hansdej]>syncevolution --print-config -q server|grep -v "^#"
syncURL = http://192.168.6.2:9000/syncevolution
username = hansdej
password = -
PeerIsClient = 1
That should be zero. The peer is a SyncML server.
PeerName = server
deviceId = syncevolution-2df101b5-97b4-4917-850c-656dd57815f2
remoteDeviceId =
syncevolution-6ff10aa8-8d4e-4e12-9cde-6b517ba531b2
WebURL = http://www.scheduleworld.com
I don't know whether that is a relevant difference. If the problem
persists after fixing the config, then please try running like this:
SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no server
That might show some debug messages from libsoup that SyncEvolution
normally hides.
--
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.
10:04 p.m.
Op dinsdag 17 mei 2011 17:26:36 schreef Patrick Ohly:
On Di, 2011-05-17 at 15:53 +0100, Hans de Jonge wrote:
> [client]
> client-arch = i386 (BT sync with N900 is working)
>
> @Client(client-IP=192.168.6.3):
> [hansdej]>syncevolution --print-config -q server|grep -v "^#"
> syncURL = http://192.168.6.2:9000/syncevolution
> username = hansdej
> password = -
> PeerIsClient = 1
That should be zero. The peer is a SyncML server.
Aha, that fixed the SoupMessage error and I got some synchronisation indeed:
Thanks
I am left with a "why" wondering:
In previous experience with the builtin N900 SyncML-Server synchronisation
worked with this parameter like this. I found this a bit couterintuitive
indeed, but it worked and I had accepted as a fait-accompli, Hence I did not
spot it here until you pointed it out. Is this a libsoup specific option and
hence works differently with the Builtin N900 SyncML-server?
regards, Hans de Jonge
8:37 a.m.
On Mi, 2011-05-18 at 22:04 +0100, Hans de Jonge wrote:
Op dinsdag 17 mei 2011 17:26:36 schreef Patrick Ohly:
> On Di, 2011-05-17 at 15:53 +0100, Hans de Jonge wrote:
> > [client]
> > client-arch = i386 (BT sync with N900 is working)
> >
> > @Client(client-IP=192.168.6.3):
> > [hansdej]>syncevolution --print-config -q server|grep -v
"^#"
> > syncURL = http://192.168.6.2:9000/syncevolution
> > username = hansdej
> > password = -
> > PeerIsClient = 1
>
> That should be zero. The peer is a SyncML server.
Aha, that fixed the SoupMessage error and I got some synchronisation indeed:
Thanks
I am left with a "why" wondering:
In previous experience with the builtin N900 SyncML-Server synchronisation
worked with this parameter like this. I found this a bit couterintuitive
indeed, but it worked and I had accepted as a fait-accompli, Hence I did not
spot it here until you pointed it out. Is this a libsoup specific option and
hence works differently with the Builtin N900 SyncML-server?
No, this has nothing to do with libsoup.
The setting merely tells SyncEvolution whether it has to act as SyncML
server or client. When talking to a Bluetooth device (like the N900),
SyncEvolution is the server. There is no SyncML server on the N900 in
this use case. When talking to a SyncML server over HTTP, SyncEvolution
is the client.
--
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.
4110
days inactive
4114
days old
syncevolution@synevolution.org
5 comments
2 participants
participants (2)
-
Hans de Jonge -
Patrick Ohly