From mcrha at redhat.com Thu Nov 16 11:45:01 2017 From: mcrha at redhat.com (Milan Crha) Date: Thu, 16 Nov 2017 12:45:01 +0100 Subject: [SyncEvolution] [Patch] Fails to build with libical 3.0.0 Message-ID: <0acbd759c2e7dac518852238be71c3dbb1761247.camel@redhat.com> Hi, syncevolution 1.5.2 fails to build with libical 3.0.0. I attached a patch which makes it build. Let me know if anything is wrong, please. Thanks and bye, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: syncevolution-1.5.2-libical3.patch Type: text/x-patch Size: 7380 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Thu Nov 2 21:27:44 2017 From: deloptes at gmail.com (deloptes) Date: Thu, 2 Nov 2017 22:27:44 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> Message-ID: 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: obex_client_response_rx(): Done! Rsp=53! [2017-11-02 22:21:58.124] OBEX_EV_REQDONE [2017-11-02 22:21:58.124] OBEX Request 3 got a failed response _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Nov 6 09:58:32 2017 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 06 Nov 2017 10:58:32 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> Message-ID: <1509962312.22094.2.camel@intel.com> 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. From deloptes at gmail.com Mon Nov 6 23:30:08 2017 From: deloptes at gmail.com (deloptes) Date: Tue, 7 Nov 2017 00:30:08 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> <1509962312.22094.2.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Nov 7 07:42:49 2017 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 07 Nov 2017 08:42:49 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> <1509962312.22094.2.camel@intel.com> Message-ID: <1510040569.22094.12.camel@intel.com> 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. From deloptes at gmail.com Sun Nov 12 23:12:53 2017 From: deloptes at gmail.com (deloptes) Date: Mon, 13 Nov 2017 00:12:53 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> <1509962312.22094.2.camel@intel.com> <1510040569.22094.12.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Wed Nov 15 12:48:28 2017 From: deloptes at gmail.com (deloptes) Date: Wed, 15 Nov 2017 13:48:28 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> <1509962312.22094.2.camel@intel.com> <1510040569.22094.12.camel@intel.com> Message-ID: Hi Patrick, I finally got a response from openobex and the secret was in the UPGRADING document. 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. Upgrading to version 1.6 ------------------------ The function OBEX_UnicodeToAscii() and its counterpart OBEX_AsciiToUnicode() are gone. Please use the more complete functionality from your toolkit. If you use one of the functions InOBEX_ServerRegister() and InOBEX_TransportConnect(), please change to TcpOBEX_ServerRegister() and TcpOBEX_TransportConnect(). The functions OBEX_GetCustomData() and OBEX_SetCustomData() will really only work with OBEX_TRANS_CUSTOM. Also, obex_t and obex_object_t changed the declared type. If you pass it around, make sure to use them as pointer. To use the bluetooth function, include the bluetooth headers of your system before including openobex/obex.h or define bt_addr_t to the proper type. The function OBEX_FindInterfaces is replaced by the functions OBEX_EnumerateInterfaces() and OBEX_GetInterfaceByIndex(). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Nov 15 13:40:57 2017 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 15 Nov 2017 14:40:57 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> <1509962312.22094.2.camel@intel.com> <1510040569.22094.12.camel@intel.com> Message-ID: <1510753257.5979.14.camel@intel.com> 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? > 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? -- 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. From deloptes at gmail.com Wed Nov 15 18:36:02 2017 From: deloptes at gmail.com (deloptes) Date: Wed, 15 Nov 2017 19:36:02 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> <1509962312.22094.2.camel@intel.com> <1510040569.22094.12.camel@intel.com> <1510753257.5979.14.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Nov 15 20:01:36 2017 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 15 Nov 2017 21:01:36 +0100 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> <1507398050.25153.33.camel@intel.com> <1509962312.22094.2.camel@intel.com> <1510040569.22094.12.camel@intel.com> <1510753257.5979.14.camel@intel.com> Message-ID: <1510776096.5979.23.camel@intel.com> 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. From dclement1 at laposte.net Sat Nov 11 10:43:42 2017 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Sat, 11 Nov 2017 11:43:42 +0100 Subject: [SyncEvolution] Onemediahub changed name Message-ID: <1510397022.4280.22.camel@laposte.net> Hello, Just FYI, I have learned recently that Onemediahub (formerly Funambol) have changed their name (once again). They are now "Zefiro". I have a Onemediahub account which I use as a backup. As far as I can tell, the credentials and sync url are still valid for Zefiro. Best regards, -- Daniel CLEMENT _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution