Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-11-15 Thread Patrick Ohly 
On Wed, 2017-11-15 at 19:36 +0100, deloptes wrote:
> Patrick Ohly wrote:
> > On Wed, 2017-11-15 at 13:48 +0100, deloptes wrote:
> > > I don't have the time now to deal with it, so it is just FYI. I
> > > hope
> > > we can follow up on that next.
> > > 
> > > regards
> > > 
> > > 
> > > https://gitlab.com/openobex/mainline/blob/master/UPGRADING.txt
> > > 
> > > Upgrade guide from previous version of openobex
> > > ===
> > > 
> > > Upgrading to version 1.7
> > > 
> > > 
> > > When using an event loop that triggers on incoming data, you must
> > > call
> > > OBEX_HandleInput() after each call to OBEX_Request()
> > > to actually send the
> > > request.
> > 
> > There is a OBEX_HandleInput() call which triggers on incoming data.
> > Is
> > that comment meant to say that each OBEX_Request() must be followed
> > by
> > a OBEX_HandleInput() *immediately*, without waiting for anything?
> > 
> 
> I don't know anything else except what I forwarded, but BTW do you
> mean the 1.6 modifications were adopted?

No, I meant that perhaps SyncEvolution does (and always has done)
what's necessary. I'm not sure what exactly the required behavior is,
even with the comment in the UPGRADING.txt.

What you can try is finding all OBEX_Request() calls and add a
OBEX_HandleInput() directly after them.

-- 
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-11-15 Thread deloptes 
Patrick Ohly wrote:

> On Wed, 2017-11-15 at 13:48 +0100, deloptes wrote:
>> Hi Patrick,
>> 
>> I finally got a response from openobex and the secret was in the
>> UPGRADING document.
> 
> Is that response somewhere public?
> 

Well their site is down, sourforge is outdated, I found only the gitlab 1.7 
version, but no extra information except as it looks like in the code

>> I don't have the time now to deal with it, so it is just FYI. I hope
>> we can follow up on that next.
>> 
>> regards
>> 
>> 
>> https://gitlab.com/openobex/mainline/blob/master/UPGRADING.txt
>> 
>> Upgrade guide from previous version of openobex
>> ===
>> 
>> Upgrading to version 1.7
>> 
>> 
>> When using an event loop that triggers on incoming data, you must
>> call
>> OBEX_HandleInput() after each call to OBEX_Request()
>> to actually send the
>> request.
> 
> There is a OBEX_HandleInput() call which triggers on incoming data. Is
> that comment meant to say that each OBEX_Request() must be followed by
> a OBEX_HandleInput() *immediately*, without waiting for anything?
> 

I don't know anything else except what I forwarded, but BTW do you mean the 
1.6 modifications were adopted?

It might be worth I try this next. 

regards

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-11-12 Thread deloptes 
Hi,

Patrick Ohly wrote:

> I haven't seen that email, but perhaps I just missed it. Please send
> again and let me know here what the subject is.

I sent now from my yahoo mail. I couldn't see anything interesting there,
but I am also not an expert.

I couldn't do much this week, I just found out that openobex is becoming
orphan as I couldn't find out who is responsible for it or where is the bug
site for that new 1.7.x branch hosted on gitlab. Many of the mail addresses
do not exist, the rest perhaps does not care, but I didn't have much time
to spend on that.

Even worse, most of the time I had, I did spend looking into Sailfish bluez.
It looks like the latest version of SailfishOS adopted bluez5 and in bluez5
they dropped HFT, so neither HFT in car possible, nor SyncML available.
Everything is degrading over time, reminding me how I missed my Palm III
and V devices until I had the time to write those plugins for and debug all
the problems in TDE.

Finally I patched buteo-syncml-plugins with calendar patch for syncml
support, but I'll need to find out a way to expose it next as it did not
work by default.

It reminds me of Don Quixote :)

Anyway I keep telling myself to never give up - I'm just wondering if there
are other people like me out there, or I am the crazy one and most of all
what all developers on this earth are doing, except breaking things :).

thanks and regards




___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-11-06 Thread Patrick Ohly 
On Tue, 2017-11-07 at 00:30 +0100, deloptes wrote:
> On Thu, 2017-11-02 at 22:27 +0100, deloptes wrote:
> > > Patrick Ohly wrote:
> > > 
> > > > On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote:
> > > > > Patrick Ohly wrote:
> > > > > 
> > > > > > Perhaps send it to me privately? I'm not sure whether I'll
> > > > > > find
> > > > > > anything either, though.
> > > > > 
> > > > > Can't we add some debug code in syncevo or obex to get the
> > > > > type
> > > > > of
> > > > > event is causing the trouble?
> > > > > The message I get after including libsynthesis in syncevo is
> > > > > a
> > > > > bit
> > > > > different (more complete)
> > > > 
> > > > But the initial error is still the same "OBEX Request 3 got a
> > > > failed
> > > > response Unknown response".
> > > > 
> > > > If you can't track down the "Unknown response" interactively in
> > > > a
> > > > debugger, then you can of course also add more debug output.
> > > > 
> > > > 
> > > 
> > > Hi Patrick,
> > > 
> > > rsp has value 83 (0x53 == OBEX_RSP_SERVICE_UNAVAILABLE) when it
> > > complains "OBEX Request 3 got a failed response Unknown response"
> > 
> > obex_response_to_string(int rsp) in libopenobex lib/main.c is
> > incomplete and lacks an entry for that code.
> > 
> 
> this is true, the implicit question was if I can dig further.

It would be interesting to find out where that rsp comes from. There's
nothing in the source code which sets it, so I suppose it comes
straight from the phone, which would imply that it is in the traffic
dump.

> > > Interestingly it gets this twice. The first time when SANFormat12
> > > fails and it goes into legacy
> > 
> > Looks like a generic issue, independent of the actual message
> > content.
> > 
> 
> yes not related but the fall back mechanism covers it. Not sure
> however if
> going to SAN 1.1 is desired. I thought always 1.2 is supported by
> both

It definitely shouldn't fall back.

> > You haven't sent me the Wireshark traffic dumps, have you? The next
> > step would be to do a side-by-side comparison of the packets of a
> > successful sync and a failed sync and determine where they diverge.
> > 
> 
> I tried to your gmx account, if you still use it, from my other
> account. If I have to use the intel one let me know

I haven't seen that email, but perhaps I just missed it. Please send
again and let me know here what the subject is.

-- 
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-11-06 Thread deloptes 

Hi thanks

Patrick Ohly wrote:

> On Thu, 2017-11-02 at 22:27 +0100, deloptes wrote:
>> Patrick Ohly wrote:
>> 
>> > On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote:
>> > > Patrick Ohly wrote:
>> > > 
>> > > > Perhaps send it to me privately? I'm not sure whether I'll find
>> > > > anything either, though.
>> > > 
>> > > Can't we add some debug code in syncevo or obex to get the type
>> > > of
>> > > event is causing the trouble?
>> > > The message I get after including libsynthesis in syncevo is a
>> > > bit
>> > > different (more complete)
>> > 
>> > But the initial error is still the same "OBEX Request 3 got a
>> > failed
>> > response Unknown response".
>> > 
>> > If you can't track down the "Unknown response" interactively in a
>> > debugger, then you can of course also add more debug output.
>> > 
>> > 
>> 
>> Hi Patrick,
>> 
>> rsp has value 83 (0x53 == OBEX_RSP_SERVICE_UNAVAILABLE) when it
>> complains "OBEX Request 3 got a failed response Unknown response"
> 
> obex_response_to_string(int rsp) in libopenobex lib/main.c is
> incomplete and lacks an entry for that code.
> 

this is true, the implicit question was if I can dig further.

>> Interestingly it gets this twice. The first time when SANFormat12
>> fails and it goes into legacy
> 
> Looks like a generic issue, independent of the actual message content.
> 

yes not related but the fall back mechanism covers it. Not sure however if
going to SAN 1.1 is desired. I thought always 1.2 is supported by both

>> The second time when it dies in my case.
>> What can I do next?
> 
> Can you file a bug about that against libopenobex? I suppose
> https://sourceforge.net/p/openobex/bugs/ is still the bug tracker of
> the project.
> 

FYI
Not sure if this is still the projects home page. openobex.org is not
responding. Last activity on sourceforge is from 2014. There is a repo on 
gitlab (https://gitlab.com/openobex/mainline)

I think I'll have to find out whats going on with openobex :)

> You haven't sent me the Wireshark traffic dumps, have you? The next
> step would be to do a side-by-side comparison of the packets of a
> successful sync and a failed sync and determine where they diverge.
> 

I tried to your gmx account, if you still use it, from my other account. If
I have to use the intel one let me know

> Alternatively, the OBEX transport could be re-written so that it uses
> obexd. libopenobex has been legacy code now for a long time. But I am
> not sure whether obexd really supports SyncML. Looking at https://git.k
> ernel.org/pub/scm/bluetooth/bluez.git/tree/doc/obex-api.txt seems to
> imply that it only supports certain well-known protocols (PBAP, for
> example) and not SyncML.
> 

I was looking into it yesterday briefly, cause I want to know how I can get
SyncML in the SailfishOS enabled. when I do sdp browse it does not show any
sign of it, but I am not very smart at that level yet. It is getting too
deep for the time I can spend.
Any way paths crossing ... here in journey of fun :)

thanks and regards

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-11-06 Thread Patrick Ohly 
On Thu, 2017-11-02 at 22:27 +0100, deloptes wrote:
> Patrick Ohly wrote:
> 
> > On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote:
> > > Patrick Ohly wrote:
> > > 
> > > > Perhaps send it to me privately? I'm not sure whether I'll find
> > > > anything either, though.
> > > 
> > > Can't we add some debug code in syncevo or obex to get the type
> > > of
> > > event is causing the trouble?
> > > The message I get after including libsynthesis in syncevo is a
> > > bit
> > > different (more complete)
> > 
> > But the initial error is still the same "OBEX Request 3 got a
> > failed
> > response Unknown response".
> > 
> > If you can't track down the "Unknown response" interactively in a
> > debugger, then you can of course also add more debug output.
> > 
> > 
> 
> Hi Patrick,
> 
> rsp has value 83 (0x53 == OBEX_RSP_SERVICE_UNAVAILABLE) when it
> complains "OBEX Request 3 got a failed response Unknown response"

obex_response_to_string(int rsp) in libopenobex lib/main.c is
incomplete and lacks an entry for that code.

> Interestingly it gets this twice. The first time when SANFormat12
> fails and it goes into legacy

Looks like a generic issue, independent of the actual message content.

> The second time when it dies in my case.
> What can I do next?

Can you file a bug about that against libopenobex? I suppose 
https://sourceforge.net/p/openobex/bugs/ is still the bug tracker of
the project.

You haven't sent me the Wireshark traffic dumps, have you? The next
step would be to do a side-by-side comparison of the packets of a
successful sync and a failed sync and determine where they diverge.

Alternatively, the OBEX transport could be re-written so that it uses
obexd. libopenobex has been legacy code now for a long time. But I am
not sure whether obexd really supports SyncML. Looking at https://git.k
ernel.org/pub/scm/bluetooth/bluez.git/tree/doc/obex-api.txt seems to
imply that it only supports certain well-known protocols (PBAP, for
example) and not SyncML.

-- 
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-11-02 Thread deloptes 
Patrick Ohly wrote:

> On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote:
>> Patrick Ohly wrote:
>> 
>> > Perhaps send it to me privately? I'm not sure whether I'll find
>> > anything either, though.
>> 
>> Can't we add some debug code in syncevo or obex to get the type of
>> event is causing the trouble?
>> The message I get after including libsynthesis in syncevo is a bit
>> different (more complete)
> 
> But the initial error is still the same "OBEX Request 3 got a failed
> response Unknown response".
> 
> If you can't track down the "Unknown response" interactively in a
> debugger, then you can of course also add more debug output.
> 
> 

Hi Patrick,

rsp has value 83 (0x53 == OBEX_RSP_SERVICE_UNAVAILABLE) when it
complains "OBEX Request 3 got a failed response Unknown response"

Interestingly it gets this twice. The first time when SANFormat12 fails and
it goes into legacy

The second time when it dies in my case.
What can I do next?

thanks and regards


[2017-11-02 22:21:57.555] OBEX_EV_PROGRESS
[2017-11-02 22:21:57.555] ObexTransportAgent::wait(): iteration
[2017-11-02 22:21:57.589] stderr: obex_data_indication(): Got 0 bytes msg
len=3
[2017-11-02 22:21:57.589] stderr: obex_client_response_rx(): Done! Rsp=20!
[2017-11-02 22:21:57.589] OBEX_EV_REQDONE
[2017-11-02 22:21:57.589] ObexTransport send completed
[2017-11-02 22:21:57.589] ObexTransportAgent::wait(): is ready
[2017-11-02 22:21:57.589] stderr: obex_object_addheader(): 4BQ header 1
[2017-11-02 22:21:57.589] stderr: obex_object_addheader(): BS header size 29
[2017-11-02 22:21:57.589] stderr: fdobex_write(): sending 40 bytes
[2017-11-02 22:21:57.589] OBEX_EV_PROGRESS
[2017-11-02 22:21:57.600] stderr: obex_data_indication(): Got 0 bytes msg
len=3
[2017-11-02 22:21:57.600] stderr: obex_client_response_rx(): Done! Rsp=53!
[2017-11-02 22:21:57.600] OBEX_EV_REQDONE
[2017-11-02 22:21:57.600] OBEX Request 3 got a failed response Service
unavailable
[2017-11-02 22:21:57.600] Server Alerted Sync init with SANFormat 12 failed,
trying with legacy format
[2017-11-02 22:21:57.600] starting SAN 11 auth 1B2M2Y8AsgTpgAmY7PhCfg==
nonce SyncEvolution session 1 server PC Suite
[2017-11-02 22:21:57.601] SAN datastore addressbook uri Contacts type
text/x-vcard
[2017-11-02 22:21:57.601] SAN with overall sync mode 206
[2017-11-02 22:21:57.601] ObexTransportAgent::wait(no reply)
[2017-11-02 22:21:57.601] ObexTransportAgent::wait(): iteration
[2017-11-02 22:21:57.624] ObexTransportAgent::wait(): iteration

[...]

[2017-11-02 22:21:57.720] stderr: obex_object_addheader(): BS header size 11
[2017-11-02 22:21:57.720] ObexTransportAgent::wait(): iteration
[2017-11-02 22:21:57.720] stderr: fdobex_write(): sending 21 bytes
[2017-11-02 22:21:57.720] OBEX_EV_PROGRESS
[2017-11-02 22:21:57.720] ObexTransportAgent::wait(): iteration
[2017-11-02 22:21:58.080] stderr: obex_data_indication(): Got 23 bytes msg
len=26
[2017-11-02 22:21:58.080] stderr: obex_client_response_rx(): We expect a
connect-rsp
[2017-11-02 22:21:58.080] stderr: obex_client_response_rx(): We expect a
connect-rsp
[2017-11-02 22:21:58.080] stderr: obex_parse_connectframe(): version=10
[2017-11-02 22:21:58.080] stderr: obex_parse_connectframe(): requested
MTU=16384, used MTU=16384
[2017-11-02 22:21:58.080] stderr: obex_client_response_rx(): Done! Rsp=20!
[2017-11-02 22:21:58.080] OBEX_EV_REQDONE
[2017-11-02 22:21:58.080] OBEX Transport: get header who from connect
response with value SYNCML-SYNC
[2017-11-02 22:21:58.080] ObexTransportAgent::wait(): is ready
[2017-11-02 22:21:58.080] GLib: Source ID 2 was not found when attempting to
remove it
[2017-11-02 22:21:58.080] Server sending SAN
[2017-11-02 22:21:58.080] ObexTransport send is called (116 bytes)
[2017-11-02 22:21:58.080] stderr: obex_object_addheader(): 4BQ header 1
[2017-11-02 22:21:58.080] stderr: obex_object_addheader(): BS header size 29
[2017-11-02 22:21:58.080] stderr: obex_object_addheader(): 4BQ header 116
[2017-11-02 22:21:58.080] stderr: obex_object_addheader(): BS header size
116
[2017-11-02 22:21:58.080] ObexTransportAgent::wait(reply)
[2017-11-02 22:21:58.080] ObexTransportAgent::wait(): iteration
[2017-11-02 22:21:58.080] stderr: fdobex_write(): sending 164 bytes
[2017-11-02 22:21:58.080] OBEX_EV_PROGRESS
[2017-11-02 22:21:58.080] ObexTransportAgent::wait(): iteration
[2017-11-02 22:21:58.112] stderr: obex_data_indication(): Got 0 bytes msg
len=3
[2017-11-02 22:21:58.112] stderr: obex_client_response_rx(): Done! Rsp=20!
[2017-11-02 22:21:58.112] OBEX_EV_REQDONE
[2017-11-02 22:21:58.112] ObexTransport send completed
[2017-11-02 22:21:58.112] ObexTransportAgent::wait(): is ready
[2017-11-02 22:21:58.112] stderr: obex_object_addheader(): 4BQ header 1
[2017-11-02 22:21:58.112] stderr: obex_object_addheader(): BS header size 29
[2017-11-02 22:21:58.112] stderr: fdobex_write(): sending 40 bytes
[2017-11-02 22:21:58.112] OBEX_EV_PROGRESS
[2017-11-02 22:21:58.124] stderr: obex_data_indication(): Got 0 bytes msg
len=3
[2017-11-02 22:21:58.124] stderr:

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-10-07 Thread Patrick Ohly 
On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote:
> Patrick Ohly wrote:
> 
> > Perhaps send it to me privately? I'm not sure whether I'll find
> > anything either, though.
> 
> Can't we add some debug code in syncevo or obex to get the type of
> event is causing the trouble?
> The message I get after including libsynthesis in syncevo is a bit
> different (more complete)

But the initial error is still the same "OBEX Request 3 got a failed
response Unknown response".

If you can't track down the "Unknown response" interactively in a
debugger, then you can of course also add more debug output.


-- 
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-10-07 Thread deloptes 
Patrick Ohly wrote:

> Perhaps send it to me privately? I'm not sure whether I'll find
> anything either, though.

Can't we add some debug code in syncevo or obex to get the type of event is
causing the trouble?
The message I get after including libsynthesis in syncevo is a bit different
(more complete)

According to last error message the error is thrown here

while (!m_obexReady) {
g_main_context_iteration (m_context, TRUE);
if (m_status == FAILED) {
SE_THROW_EXCEPTION (TransportException,
"ObexTransprotAgent: Underlying transport error");
}
}

sync_debug/syncevolution_1.5.2$
SYCNEVOLUTION_DEBUG=10 ./src/syncevolution -r loglevel=6 nokia_N9
addressbook
[INFO] calendar: inactive
[INFO] calendar+todo: inactive
[INFO] memo: inactive
[INFO] todo: inactive
[INFO] Server sending SAN
[ERROR] OBEX Request 3 got a failed response Unknown response
[ERROR] GLib: Source ID 2 was not found when attempting to remove it
[INFO] Server sending SAN
[ERROR] OBEX Request 3 got a failed response Unknown response
[ERROR] transport problem: ObexTransprotAgent: Underlying transport error

Synchronization failed

regards

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-10-07 Thread Patrick Ohly 
On Fri, 2017-10-06 at 23:01 +0200, deloptes wrote:
> Patrick Ohly wrote:
> Please note that the reference used with obex1.5 is not build this
> way. Let
> me know if I have to do the same with obex1.5

That would only be necessary if we wanted to debug obex1.5 at the
source level. This doesn't seem necessary yet.

> I did include libsynthesis in syncevolution with obex1.7 and got the
> wireshark capture, but I can understand almost nothing out of it.
> May I attach the captured traffic? My concern is that IMEI of the
> phone is
> in the packets.

Perhaps send it to me privately? I'm not sure whether I'll find
anything either, though.

-- 
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-10-06 Thread deloptes 
Patrick Ohly wrote:

> Typically, during my development work I build with
> --disable-shared --enable-static and --with-synthesis-
> src=.../libsynthesis where "libsynthesis" is the source dir of
> libsynthesis.
> 
> That way, I get a single executable that has the right compile flags
> and all code included, i.e. I can set breakpoints right away without
> having to wait for shared libraries to get loaded. It also avoids
> problems with picking up system shared libraries.

I think you are more experienced :) at least I understand what you mean.
Please note that the reference used with obex1.5 is not build this way. Let
me know if I have to do the same with obex1.5
I did include libsynthesis in syncevolution with obex1.7 and got the
wireshark capture, but I can understand almost nothing out of it.
May I attach the captured traffic? My concern is that IMEI of the phone is
in the packets.

Here is a brief - the difference starts around packet 92
obex1.5
89  4.306562localhost ()TexasIns_90:56:e3 (Nokia N9 16GB)   
RFCOMM  53  Sent
UIH Channel=25 
90  4.314413controller  hostHCI_EVT 8   Rcvd Number of 
Completed Packets
91  5.129409TexasIns_90:56:e3 (Nokia N9 16GB)   localhost ()
HCI_ACL 517 Rcvd 
[Reassembled in #92]
92  5.130029TexasIns_90:56:e3 (Nokia N9 16GB)   localhost ()
RFCOMM  510 Rcvd
UIH Channel=25 
93  5.133153TexasIns_90:56:e3 (Nokia N9 16GB)   localhost ()
HCI_ACL 517 Rcvd 
[Reassembled in #94]
94  5.133650TexasIns_90:56:e3 (Nokia N9 16GB)   localhost ()
RFCOMM  510 Rcvd
UIH Channel=25 
95  5.136777TexasIns_90:56:e3 (Nokia N9 16GB)   localhost ()
HCI_ACL 517 Rcvd 
[Reassembled in #96]


obex1.7
89  3.817533localhost ()TexasIns_90:56:e3 (Nokia N9 16GB)   
RFCOMM  53  Sent
UIH Channel=25 
90  3.828868controller  hostHCI_EVT 8   Rcvd Number of 
Completed Packets
91  3.833241TexasIns_90:56:e3 (Nokia N9 16GB)   localhost ()
RFCOMM  16  Rcvd
UIH Channel=25
92  3.877417localhost ()TexasIns_90:56:e3 (Nokia N9 16GB)   
RFCOMM  13  Sent
DISC Channel=25 
93  3.897865controller  hostHCI_EVT 8   Rcvd Number of 
Completed Packets
94  3.900738TexasIns_90:56:e3 (Nokia N9 16GB)   localhost ()
RFCOMM  13  Rcvd UA
Channel=25 
95  3.900756localhost ()TexasIns_90:56:e3 (Nokia N9 16GB)   
RFCOMM  13  Sent
DISC Channel=0 


___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-10-04 Thread Patrick Ohly 
On Tue, 2017-10-03 at 10:35 +0200, deloptes wrote:
> Patrick Ohly wrote:
> 
> > Interesting :-/ Perhaps try running under valgrind to root-cause
> > this
> > issue?
> > 
> 
> I was thinking the memory errors in valgrind were related to the
> tdepim
> code, but it looks like it fails in the sync process when tdepim
> crashes.

Yes, the TDECrash::defaultCrashHandler is catching some problem and
then itself causing valgrind errors. Is there some way to disable the
handler?

The actual problem seems to be in /usr/lib/x86_64-linux-
gnu/libsmltk.so.0.6.0. Having that with debug information would be
useful.

Typically, during my development work I build with
--disable-shared --enable-static and --with-synthesis-
src=.../libsynthesis where "libsynthesis" is the source dir of
libsynthesis.

That way, I get a single executable that has the right compile flags
and all code included, i.e. I can set breakpoints right away without
having to wait for shared libraries to get loaded. It also avoids
problems with picking up system shared libraries.

-- 
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-10-01 Thread Patrick Ohly 
On Sat, 2017-09-30 at 21:17 +0200, Patrick Ohly wrote:
> So that's still the same error. The question now is, where does this
> "Unknown response" come from? What is the actual response code and
> where was it set?

Another way to approach this might be to take network traffic dumps
with wireshark of the Bluetooth communication with old and new
libopenobex, then compare packets. There shouldn't be that many of them
yet, at least when it fails.

-- 
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-09-30 Thread deloptes 
Patrick Ohly wrote:

> On Fri, 2017-09-29 at 22:22 +0200, deloptes wrote:
>> I'm not sure I did all correctly
>> 
>> export LD_LIBRARY_PATH=/data-backup/DEVELOPMENT/Projects/tde-
>> sup/sync_debug/openobex-1.7.2-Source/debian/build/lib
> 
> Looks like you are building libopenobex via the Debian packaging.
> That's just unnecessarily complex and might have undesired effects like
> stripping the lib during a build.
> 

I am not building the whole package, but notice taken, I now build the
classic way.

> It's enough to checkout the source, apply my patch, then configure with
> "CFLAGS=-g" and "make" (no need for "make install" or anything like
> that).
> 
> Anyway, you can check with "list obex_hdr_it_equals" under gdb (after
> loading the lib, for example after that segfault or after a "breakpoint
> main") whether you have debug information in the lib, and whether the
> listed source has my patch.
> 
>> SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no -r loglevel=6
>> nokia_N9
>> addressbook
>> 
>> 
>> 
>> DEBUG 00:00:02] ready to sync
>> [DEBUG 00:00:02] starting SAN 12 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce
>> SyncEvolution session 1 server PC Suite
>> [DEBUG 00:00:02] SAN datastore addressbook uri Contacts type 7 mode
>> 206
>> [DEVELOPER 00:00:02] ObexTransportAgent::wait(no reply)
>> [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration
>> ...
>> [same removed]
>> ...
>> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
>> [DEVELOPER 00:00:04] Connecting Bluetooth device with address
>> 40:98:4E:90:56:E3 and channel 25
>> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
>> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
>> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
>> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
>> [DEVELOPER 00:00:04] OBEX Transport: get header who from connect
>> response with value SYNCML-SYNC
>> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready
>> [INFO 00:00:04] Server sending SAN
>> [DEVELOPER 00:00:04] ObexTransport send is called (46 bytes)
>> [DEVELOPER 00:00:04] ObexTransportAgent::wait(reply)
>> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
>> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
>> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
>> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
>> [DEVELOPER 00:00:04] ObexTransport send completed
>> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready
>> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
>> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
>> [ERROR 00:00:04] OBEX Request 3 got a failed response Unknown
>> response
> 
> So that's still the same error. The question now is, where does this
> "Unknown response" come from? What is the actual response code and
> where was it set?
> 
> I'm afraid that will require a lot of digging in the libopenobex
> sources. I don't have a clue what to look for, therefore I cannot
> provide further guidance.
> 

Yes, I will double check all details and will try to get more useful
information


>> [DEBUG 00:00:04] Server Alerted Sync init with SANFormat 12 failed,
>> trying with legacy format
>> [DEBUG 00:00:04] starting SAN 11 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce
>> SyncEvolution session 1 server PC Suite
>> [DEBUG 00:00:04] SAN datastore addressbook uri Contacts type text/x-
>> vcard
>> [DEBUG 00:00:04] SAN with overall sync mode 206
>> [kcrash] TDECrash: Application 'SyncEvolution' crashing...
>> Segmentation fault
>> 
>> In GDB
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x72614358 in smlLibMemcpy () from /usr/lib/x86_64-linux-
>> gnu/libsmltk.so.0
>> (gdb)
> 
> Interesting :-/ Perhaps try running under valgrind to root-cause this
> issue?
> 

I did - there are 2 pointer errors from the tdepim plugins. I will try to
fix them and will come back again when I have something useful.
It works great with obex 1.5. So it is not urgent but anyway it is not a
really usable for the public.

thanks

regards

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-09-30 Thread Patrick Ohly 
On Fri, 2017-09-29 at 22:22 +0200, deloptes wrote:
> I'm not sure I did all correctly
> 
> export LD_LIBRARY_PATH=/data-backup/DEVELOPMENT/Projects/tde-
> sup/sync_debug/openobex-1.7.2-Source/debian/build/lib

Looks like you are building libopenobex via the Debian packaging.
That's just unnecessarily complex and might have undesired effects like
stripping the lib during a build.

It's enough to checkout the source, apply my patch, then configure with
"CFLAGS=-g" and "make" (no need for "make install" or anything like
that).

Anyway, you can check with "list obex_hdr_it_equals" under gdb (after
loading the lib, for example after that segfault or after a "breakpoint
main") whether you have debug information in the lib, and whether the
listed source has my patch.

> SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no -r loglevel=6
> nokia_N9
> addressbook  
>  
> 
> 
> DEBUG 00:00:02] ready to sync
> [DEBUG 00:00:02] starting SAN 12 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce
> SyncEvolution session 1 server PC Suite
> [DEBUG 00:00:02] SAN datastore addressbook uri Contacts type 7 mode
> 206
> [DEVELOPER 00:00:02] ObexTransportAgent::wait(no reply)
> [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration
> ...
> [same removed]
> ...
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] Connecting Bluetooth device with address
> 40:98:4E:90:56:E3 and channel 25
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
> [DEVELOPER 00:00:04] OBEX Transport: get header who from connect
> response with value SYNCML-SYNC
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready
> [INFO 00:00:04] Server sending SAN
> [DEVELOPER 00:00:04] ObexTransport send is called (46 bytes)
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(reply)
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
> [DEVELOPER 00:00:04] ObexTransport send completed
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready
> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
> [ERROR 00:00:04] OBEX Request 3 got a failed response Unknown
> response

So that's still the same error. The question now is, where does this
"Unknown response" come from? What is the actual response code and
where was it set?

I'm afraid that will require a lot of digging in the libopenobex
sources. I don't have a clue what to look for, therefore I cannot
provide further guidance.

> [DEBUG 00:00:04] Server Alerted Sync init with SANFormat 12 failed,
> trying with legacy format
> [DEBUG 00:00:04] starting SAN 11 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce
> SyncEvolution session 1 server PC Suite
> [DEBUG 00:00:04] SAN datastore addressbook uri Contacts type text/x-
> vcard
> [DEBUG 00:00:04] SAN with overall sync mode 206
> [kcrash] TDECrash: Application 'SyncEvolution' crashing...
> Segmentation fault
> 
> In GDB
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x72614358 in smlLibMemcpy () from /usr/lib/x86_64-linux-
> gnu/libsmltk.so.0
> (gdb)   

Interesting :-/ Perhaps try running under valgrind to root-cause this
issue?

-- 
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
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-09-29 Thread deloptes 
I'm not sure I did all correctly

export
LD_LIBRARY_PATH=/data-backup/DEVELOPMENT/Projects/tde-sup/sync_debug/openobex-1.7.2-Source/debian/build/lib

SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no -r loglevel=6
nokia_N9
addressbook



DEBUG 00:00:02] ready to sync
[DEBUG 00:00:02] starting SAN 12 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce
SyncEvolution session 1 server PC Suite
[DEBUG 00:00:02] SAN datastore addressbook uri Contacts type 7 mode 206
[DEVELOPER 00:00:02] ObexTransportAgent::wait(no reply)
[DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration
...
[same removed]
...
[DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
[DEVELOPER 00:00:04] Connecting Bluetooth device with address
40:98:4E:90:56:E3 and channel 25
[DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
[DEVELOPER 00:00:04] OBEX_EV_PROGRESS
[DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
[DEVELOPER 00:00:04] OBEX_EV_REQDONE
[DEVELOPER 00:00:04] OBEX Transport: get header who from connect response
with value SYNCML-SYNC
[DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready
[INFO 00:00:04] Server sending SAN
[DEVELOPER 00:00:04] ObexTransport send is called (46 bytes)
[DEVELOPER 00:00:04] ObexTransportAgent::wait(reply)
[DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
[DEVELOPER 00:00:04] OBEX_EV_PROGRESS
[DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
[DEVELOPER 00:00:04] OBEX_EV_REQDONE
[DEVELOPER 00:00:04] ObexTransport send completed
[DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready
[DEVELOPER 00:00:04] OBEX_EV_PROGRESS
[DEVELOPER 00:00:04] OBEX_EV_REQDONE
[ERROR 00:00:04] OBEX Request 3 got a failed response Unknown response
[DEBUG 00:00:04] Server Alerted Sync init with SANFormat 12 failed, trying
with legacy format
[DEBUG 00:00:04] starting SAN 11 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce
SyncEvolution session 1 server PC Suite
[DEBUG 00:00:04] SAN datastore addressbook uri Contacts type text/x-vcard
[DEBUG 00:00:04] SAN with overall sync mode 206
[kcrash] TDECrash: Application 'SyncEvolution' crashing...
Segmentation fault

In GDB

Program received signal SIGSEGV, Segmentation fault.
0x72614358 in smlLibMemcpy () from
/usr/lib/x86_64-linux-gnu/libsmltk.so.0
(gdb)


Thanks in advance for taking your time

regards


On Tue, Sep 5, 2017 at 11:12 AM, Patrick Ohly 
wrote:

> On Mon, 2017-09-04 at 20:24 +0200, deloptes wrote:
> > Patrick Ohly wrote:
> >
> > > So have you built 1.5.2 with libopenobex2 from Debian Stretch and
> > > it
> > > failed? With which phone?
> > >
> >
> > yes - built 1.5.2 with libopenobex2 from Debian Stretch.
> > phone is Nokia N9
>
> Unfortunately I indeed don't have that phone.
>
> > > What I did is a "configure --disable-shared --enable-static
> > > CFLAGS=-g
> > > CXXFLAGS=-g ..." and then in the build directory I ran
> > > "SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no nokia-n97-
> > > mini@
> > > devices  addressbook".
> > >
> > > This allows running the command under gdb. The interesting line is
> > > is
> > > the error message in ObexTransportAgent::obex_callback. What value
> > > does
> > > obex_rsp have, and why does OBEX_ResponseToString not know it?
> >
> > I may try test this next and post the output.
>
> Please do.
>
> I continued debugging this a bit further by running syncevolution under
> valgrind. When using libopenobex2, I get:
>
> ==15128== Conditional jump or move depends on uninitialised value(s)
> ==15128==at 0x4C31CD6: __memcmp_sse4_1 (in /usr/lib/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> ==15128==by 0x918502D: obex_hdr_it_equals (obex_hdr.c:298)
> ==15128==by 0x918661A: obex_msg_post_prepare (obex_msg.c:87)
> ==15128==by 0x918661A: obex_msg_prepare (obex_msg.c:117)
> ==15128==by 0x9184096: obex_client_request_tx_prepare
> (obex_client.c:237)
> ==15128==by 0x9183358: OBEX_Request (api.c:512)
> ==15128==by 0x10AF304: SyncEvo::ObexTransportAgent::connectReq()
> (ObexTransportAgent.cpp:237)
>
> I don't get that with the older libopenobex. That further strengthens
> the hypothesis that this is a regression in libopenobex - unless of
> course they changed the API and SyncEvolution now lacks some changes,
> but it doesn't look like that this is the case.
>
> Found it. This patch on top of https://gitlab.com/openobex/mainline
> master (no changes since 1.7.2 one year ago) fixes it:
>
> From b496d1781db9c23c9984fc15108871fe21b5fd0d Mon Sep 17 00:00:00 2001
> From: Patrick Ohly 
> Date: Tue, 5 Sep 2017 10:53:30 +0200
> Subject: [PATCH 1/1] obex_hdr.c: avoid reading uninitialized memory in
>  obex_hdr_it_equals
>
> valgrind correctly reports that the memcmp() in obex_hdr_it_equals()
> depends on uninitialized memory:
>
> ==15128== Conditional jump or move depends on uninitialised value(s)
> ==15128==at 0x4C31CD6: __memcmp_sse4_1 (in /usr/lib/valgrind/vgpreload_
> memcheck-amd64-linux.so)
> ==15128==by 0x918502D: obex_hdr_it_equals

[SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

2017-09-05 Thread Patrick Ohly 
On Mon, 2017-09-04 at 20:24 +0200, deloptes wrote:
> Patrick Ohly wrote:
> 
> > So have you built 1.5.2 with libopenobex2 from Debian Stretch and
> > it
> > failed? With which phone?
> > 
> 
> yes - built 1.5.2 with libopenobex2 from Debian Stretch.
> phone is Nokia N9

Unfortunately I indeed don't have that phone.

> > What I did is a "configure --disable-shared --enable-static
> > CFLAGS=-g
> > CXXFLAGS=-g ..." and then in the build directory I ran
> > "SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no nokia-n97-
> > mini@
> > devices  addressbook".
> > 
> > This allows running the command under gdb. The interesting line is
> > is
> > the error message in ObexTransportAgent::obex_callback. What value
> > does
> > obex_rsp have, and why does OBEX_ResponseToString not know it?
> 
> I may try test this next and post the output.

Please do.

I continued debugging this a bit further by running syncevolution under
valgrind. When using libopenobex2, I get:

==15128== Conditional jump or move depends on uninitialised value(s)
==15128==at 0x4C31CD6: __memcmp_sse4_1 (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15128==by 0x918502D: obex_hdr_it_equals (obex_hdr.c:298)
==15128==by 0x918661A: obex_msg_post_prepare (obex_msg.c:87)
==15128==by 0x918661A: obex_msg_prepare (obex_msg.c:117)
==15128==by 0x9184096: obex_client_request_tx_prepare (obex_client.c:237)
==15128==by 0x9183358: OBEX_Request (api.c:512)
==15128==by 0x10AF304: SyncEvo::ObexTransportAgent::connectReq() 
(ObexTransportAgent.cpp:237)

I don't get that with the older libopenobex. That further strengthens
the hypothesis that this is a regression in libopenobex - unless of
course they changed the API and SyncEvolution now lacks some changes,
but it doesn't look like that this is the case.

Found it. This patch on top of https://gitlab.com/openobex/mainline
master (no changes since 1.7.2 one year ago) fixes it:

From b496d1781db9c23c9984fc15108871fe21b5fd0d Mon Sep 17 00:00:00 2001
From: Patrick Ohly 
Date: Tue, 5 Sep 2017 10:53:30 +0200
Subject: [PATCH 1/1] obex_hdr.c: avoid reading uninitialized memory in
 obex_hdr_it_equals

valgrind correctly reports that the memcmp() in obex_hdr_it_equals()
depends on uninitialized memory:

==15128== Conditional jump or move depends on uninitialised value(s)
==15128==at 0x4C31CD6: __memcmp_sse4_1 (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15128==by 0x918502D: obex_hdr_it_equals (obex_hdr.c:298)
==15128==by 0x918661A: obex_msg_post_prepare (obex_msg.c:87)
==15128==by 0x918661A: obex_msg_prepare (obex_msg.c:117)
==15128==by 0x9184096: obex_client_request_tx_prepare (obex_client.c:237)
==15128==by 0x9183358: OBEX_Request (api.c:512)
==15128==by 0x10AF304: SyncEvo::ObexTransportAgent::connectReq() 
(ObexTransportAgent.cpp:237)
...

That's because on x86-64, the iterator struct contains padding which
does not get initialized by obex_hdr_it_init_from():

(gdb) p sizeof(it)
$13 = 16
(gdb) p sizeof(it.is_valid)
$14 = 4

Instead of fixing all places where an iterator might get set up, it
seems safer to limit the comparison to the individual fields. There
are few enough of them that this should not affect performance.

Signed-off-by: Patrick Ohly 
---
 lib/obex_hdr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/obex_hdr.c b/lib/obex_hdr.c
index 48576a3..a660405 100644
--- a/lib/obex_hdr.c
+++ b/lib/obex_hdr.c
@@ -295,5 +295,5 @@ void obex_hdr_it_next(struct obex_hdr_it *it)
 
 int obex_hdr_it_equals(const struct obex_hdr_it *a, const struct obex_hdr_it 
*b)
 {
-   return a && b && (memcmp(a, b, sizeof(*a)) == 0);
+   return a && b && a->list == b->list && a->is_valid == b->is_valid;
 }
-- 
2.11.0

Deloptes, can you rebuild libopenobex2 with that patch and check
whether it helps? It's enough to do "cmake . && make", then set
LD_LIBRARY_PATH so that it includes the lib directory when invoking
syncevolution, i.e. there's no need to actually install libopenobex.

I do get another valgrind hit in libsynthesis also with the older
libopenobex, but that's later. Here's the fix for that:

From de5f1c80d180c326d02f431c6c3189f1ca9ae6b3 Mon Sep 17 00:00:00 2001
From: Patrick Ohly 
Date: Tue, 5 Sep 2017 11:03:44 +0200
Subject: [PATCH 1/1] xltenc.c: fix integer underflow

"len" is unsigned, so subtracting 2 yields a very high value and then
the comparison against n causes memory to be read beyond the end of
the buffer when the buffer is smaller than 2.

Happens in SyncEvolution when sending a SAN message to a phone via
OBEX. In practice this typically had no effect because the
uninitialized memory is unlikely to contain exactly the sequence of
bytes that was checked for.

==28571== Invalid read of size 1
==28571==at 0x1275989: xltEncPcdata (xltenc.c:1177)
==28571==by 0x1274DAE: xltEncBlock (xltenc.c:1108)
==28571==by 0x1272DCD: