[Most of the text below was written in December 2019, but than unintentionally sent to an internal mailing list - no surprise that I never got any response!] Hello! Over the Christmas holidays I worked on building a new SyncEvolution release. My current goal is to build for Ubuntu Bionic (most recent LTS) and support those binaries on all more recent Debian and Ubuntu releases. If possible, I'd like to drop unused features if they require extra effort. This mostly depends if someone still needs them. Let me list some features that I'd like to remove. If you still need them, please respond here: * At the top of that list is ActiveSync support. activesyncd no longer builds on Debian Stretch because it depends on libgnome-keyring, which was removed. It probably can be ported to libsecret, but that's extra work. * x86 (i.e. 32 bit) binaries - it doubles the testing effort. * RPMs - they never had proper dependencies and I am not sure whether they ever worked at all. * Akonadi support and KDE in general. I first encountered problem with Akonadi in Debian Stretch and reported it here with a stand-alone reproducer: https://bugs.kde.org/show_bug.cgi?id=369203 But as pointed out in that issue, the API that SyncEvolution uses is no longer supported and thus SyncEvolution would have to be ported to the current API, whatever that is - I haven't investigated that. * Port to Python 3 and stop supporting Python 2. Regarding the source code, I'd like merge all pending patches. This obviously includes all the changes that are required to build on more recent Linux distros, but also the C++ modernization that I started a while back. The result will be more than just a simple bug fix release, but also not something that has any new user-visible features. I'm not entirely happy with that, but I also don't want to be stuck completely in pure maintenance mode. I got testing on the newer Linux distros working with the updated code base already beginning of this year, but then got stuck because of a regression and lack of time to dig into that. Since then, the apt repo keys expired and I haven't renewed them because the binaries probably wouldn't work anyway. I suppose users would like to see binaries again, primarily because SyncEvolution fell out of Debian/Ubuntu? -- Best Regards Patrick Ohly _______________________________________________ SyncEvolution mailing list -- syncevolution(a)syncevolution.org To unsubscribe send an email to syncevolution-leave(a)syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Hi Patrick, glad to hear such good news from you - really appreciate your work. I am actively using SyncEvolution on Debian Buster with TDE and with Sailfish OS phone. I was wondering about openobex-1.7 (aka libopenobex2) - is it possible to get it working with it? It seems to be the new default in debian, but is not working with SyncEvolution and you did not mention it.

Hi, It is the file UPGRADING.txt in openobex not the README Upgrading to version 1.7Upgrading to version 1.6

regards On Thursday, July 30, 2020, 1:08:31 AM GMT+2, Emanoil Kotsev <deloptes(a)yahoo.com&gt; wrote: Hi,strange I do not see this on the ML. I don't know how to debug this. The problem is that openobex changed - if you look in the README it says what needs to be done to upgrade from 1.5 to 1.7.I did not have time and ability to go deeper into openobex. The problem is that  after SAN is sent it (syncevolution) hangs waiting for PUT or whatever and does not move forward. I tried few weeks ago building bueto-syncml for the (now) Sailfish OS with openobex 1.7 and I had syncevolution 1.5.3 with openobex 1.5 on the PC, but it hangs on the phone the same way it hangs on the PC if it is build against openobex 1.7. I couldn't find out, how I can get log from the plugin there as it is started in a thread an nothing logs.

On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly <patrick.ohly(a)intel.com&gt; wrote: > Emanoil Kotsev <deloptes(a)yahoo.com&gt; writes: > > Hi, > > It is the file UPGRADING.txt in openobex not the README > > Upgrading to version 1.7Upgrading to version 1.6 > > 1.7 is ancient (released 2016). I remember reading about "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" > (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt). > If I remember correctly, my conclusion was that SyncEvolution does that, > but I am not sure anymore. > > I am also not sure where and how this has to be done. I think I have looked into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(), but I am not quite sure at all. It could be also something completely different.

In theory it should be possible that one end is using openobex-1.5 and the other 1.7 - the protocol is the same, so I do change only openobex on one end at a time. I don't know if I change on both ends it would start working. Do you think it is worth trying?

Patrick Ohly <patrick.ohly(a)intel.com&gt; writes: > deloptes <deloptes(a)gmail.com&gt; writes: >> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly <patrick.ohly(a)intel.com&gt; wrote: >> >>> Emanoil Kotsev <deloptes(a)yahoo.com&gt; writes: >>> > Hi, >>> > It is the file UPGRADING.txt in openobex not the README >>> > Upgrading to version 1.7Upgrading to version 1.6 >>> >>> 1.7 is ancient (released 2016). I remember reading about "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" >>> (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt). >>> If I remember correctly, my conclusion was that SyncEvolution does that, >>> but I am not sure anymore. >>> >>> >> I am also not sure where and how this has to be done. I think I have looked >> into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(), >> but I am not quite sure at all. It could be also something completely >> different. > > Perhaps calling OBEX_HandleInput unconditionally after OBEX_Request is > really missing. I don't know exactly whether it now gets called only > when the fd is ready. I wanted to try that out, but it turns out that all of my SyncML-capable phones are dead, i.e. I can no longer test the SyncML over OBEX code. I already bought a cheap used one via eBay, but that also was dead. I'll try with another one...

Patrick Ohly <patrick.ohly(a)intel.com&gt; writes: > Patrick Ohly <patrick.ohly(a)intel.com&gt; writes: > >> deloptes <deloptes(a)gmail.com&gt; writes: >>> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly <patrick.ohly(a)intel.com&gt; wrote: >>> >>>> Emanoil Kotsev <deloptes(a)yahoo.com&gt; writes: >>>> > Hi, >>>> > It is the file UPGRADING.txt in openobex not the README >>>> > Upgrading to version 1.7Upgrading to version 1.6 >>>> >>>> 1.7 is ancient (released 2016). I remember reading about "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" >>>> (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt). >>>> If I remember correctly, my conclusion was that SyncEvolution does that, >>>> but I am not sure anymore. >>>> >>>> >>> I am also not sure where and how this has to be done. I think I have looked >>> into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(), >>> but I am not quite sure at all. It could be also something completely >>> different. >> >> Perhaps calling OBEX_HandleInput unconditionally after OBEX_Request is >> really missing. I don't know exactly whether it now gets called only >> when the fd is ready. > > I wanted to try that out, but it turns out that all of my SyncML-capable > phones are dead, i.e. I can no longer test the SyncML over OBEX code. I > already bought a cheap used one via eBay, but that also was dead. I'll > try with another one... I now have a phone again and can reproduce the issue. But some additional debug output shows that OBEX_HandleInput is called after OBEX_Request: [DEVELOPER 00:00:02] OBEX Transport: get header who from connect response with value SYNCML-SYNC [DEVELOPER 00:00:02] ObexTransportAgent::wait(): is ready [ERROR 00:00:02] GLib: Source ID 2 was not found when attempting to remove it [INFO 00:00:02] Server sending SAN [DEVELOPER 00:00:02] ObexTransport send is called (116 bytes) [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_Request for OBEX_CMD_PUT [DEVELOPER 00:00:02] ObexTransportAgent::wait(reply) [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_HandleInput [DEVELOPER 00:00:02] OBEX_EV_PROGRESS [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_HandleInput ^C [DEVELOPER 00:00:05] ObexTransportAgent::wait(): iteration [DEBUG 00:00:05] SuspendFlags: read 7 from fd 5 [DEBUG 00:00:05] reveived signal 2 [DEBUG 00:00:05] CancelTransport: cancelling because of SuspendFlags::ABORT [DEVELOPER 00:00:05] ObexTransportAgent::shutdown() [DEVELOPER 00:00:05] ObexTransportAgent::wait(no reply) [DEVELOPER 00:00:05] ObexTransportAgent::wait(): iteration [DEVELOPER 00:00:05] ObexTransportAgent: OBEX_HandleInput *** buffer overflow detected ***: install_new_openobex/bin/syncevolution terminated The buffer overflow is happening inside the new libopenobex after SyncEvolution called OBEX_CancelRequest and while SyncEvolution is waiting for the pending command to finish. This does not happen with the old libopenobex. That aside, the key point is that it's not getting stuck because of the issue mentioned in the openobex 1.7 release notes. Wireshark also shows that some data goes out. Unfortunately it stop decoding data at the RFCOMM level, so it's not immediately obvious what's going on for OBEX. The next step was to try with an older libopenobex. I force-installed an old libopenobex1-dev and libopenobex; that didn't install cleanly, but the files seemed to be in place and it was possible to link against them. However, the resulting binary then got stuck the same way (but allowed to abort cleanly). I also tried running the last stable release inside Docker: docker run --rm -ti --net=host --privileged --volume \ /home/pohly/.config:/config \ --volume \ /tmp/syncevolution-bundle_1.5.3-2_amd64.deb:/tmp/syncevolution-bundle_1.5.3-2_amd64.deb \ --volume /dev:/dev --volume /sys:/sys debian:stretch And inside it: apt-get update && apt-get install /tmp/syncevolution-bundle_1.5.3-2_amd64.deb -f XDG_CONFIG_HOME=/config SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --sync refresh-from-remote --sync-property loglevel=10 NokiaPhone But that segfaults while preparing the SAN, i.e. even earlier. ==2063== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==2063== Bad permissions for mapped region at address 0x7F0E358 ==2063== at 0x7F0E358: ??? (in /usr/lib/libsmltk.so.0.6.0) ==2063== by 0x56A87B5: sysync::newPCDataStringX(unsigned char const*, bool, int) (sysync_utils.cpp:2992) ==2063== by 0x56A64AD: sysync::SanPackage::GetPackageLegacy(void*&, unsigned long&, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, int, bool) (san.cpp:757) ==2063== by 0x56224C6: SyncEvo::SyncContext::sendSAN(unsigned short) (SyncContext.cpp:3642) ==2063== by 0x562A6A2: SyncEvo::SyncContext::doSync() (SyncContext.cpp:3829) ==2063== by 0x5631338: SyncEvo::SyncContext::sync(SyncEvo::SyncReport*) (SyncContext.cpp:3446) ==2063== by 0x55AB3D6: SyncEvo::Cmdline::run() (Cmdline.cpp:1726) ==2063== by 0x416823: main (syncevolution.cpp:533) I've never used this particular config before; it's possible that I screwed it up when preparing for syncing with the new phone. But that shouldn't lead to a segfault. I'll have to try next with the old release compiled from source to debug that. -- Best Regards Patrick Ohly

deloptes <deloptes(a)gmail.com&gt; writes: > Hi Patrick, > I am afraid I do not have your skills, but I am very thankful that you take > your time to investigate. > As mentioned before I always compile the old version from source (creating > debian packages for the desktop and rpm for the phone) > , then compiling the rest linked to the openobex library and it works like > it was working 10y ago. Unfortunately I cannot reproduce that. SyncEvolution 1.5.3 compiled anew against libopenobex1 also gets stuck with thew new phone after sending the second SAN message, i.e. the same symptom as with libopenobex2. It's a bit random - once I saw a permission denied error for that SAN, but most of the time it's just stuck. I'm now trying to get the dead N97 working again. I've ordered a new battery, perhaps then it'll start again.

On 24/07/2020 20:38, Patrick Ohly wrote: * At the top of that list is ActiveSync support. activesyncd no longer > builds on Debian Stretch because it depends on libgnome-keyring, which > was removed. It probably can be ported to libsecret, but that's > extra work. I no longer need ActiveSync myself (my employer banned it a while ago and, more recently, I have retired anyway). I feel it is a shame to let it die and could probably be persuaded to do some work on it if someone actually wanted it and could provide me with access to systems to develop and test.

> I suppose users would like to see binaries again, primarily because > SyncEvolution fell out of Debian/Ubuntu? Now that I am retired, I am not sure what my usage will be. My (new) master for contacts and calendar is in Owncloud/Nextcloud (mainly using Thunderbird as UI), however I haven't decided how I will keep various other devices synced (particularly Sailfish, if I continue to use that). I would find it convenient to have Debian binaries although I don't know if I will need them long term. I am disappointed, having worked on PIM sync for many years, that the world seems to be willing to settle for very limited and mostly locked up services from Microsoft, Apple or Android.