From patrick.ohly at intel.com Fri Jul 24 19:38:01 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 24 Jul 2020 21:38:01 +0200 Subject: [SyncEvolution] new SyncEvolution binaries, dropping features? Message-ID: [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 at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s From deloptes at gmail.com Fri Jul 24 20:15:00 2020 From: deloptes at gmail.com (deloptes) Date: Fri, 24 Jul 2020 22:15:00 +0200 Subject: [SyncEvolution] new SyncEvolution binaries, dropping features? In-Reply-To: References: Message-ID: 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. Thank you BR On Fri, Jul 24, 2020 at 9:38 PM Patrick Ohly wrote: > [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 at syncevolution.org > To unsubscribe send an email to syncevolution-leave at syncevolution.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Sat Jul 25 20:00:05 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 25 Jul 2020 22:00:05 +0200 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: References: Message-ID: deloptes writes: > 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. I'm currently building against libopenobex2-dev on Ubuntu Bionic, and that at least seems to work fine without changes to the SyncEvolution source code. However, I haven't tested syncing via OBEX with the resulting binaries. When you say "is not working", what problems do you see? -- Best Regards Patrick Ohly _______________________________________________ SyncEvolution mailing list -- syncevolution at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s From deloptes at yahoo.com Wed Jul 29 23:08:31 2020 From: deloptes at yahoo.com (Emanoil Kotsev) Date: Wed, 29 Jul 2020 23:08:31 +0000 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: References: Message-ID: <865359074.6474507.1596064111409@mail.yahoo.com> 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. So yes, it builds against openobex-1.7, but it is not working at all. If you could help, it would be great.I was thinking to get one older notebook for testing, but the obex and syncevolution code was too much for me and the time I have too little. If you need a tester however, I am available and I could setup the test pc. The phones are ready N9, Sailfish and older Symbian 5530.All of them work perfectly well with Syncevolution 1.5 and openobex 1.5. Thanks BR On Saturday, July 25, 2020, 10:00:21 PM GMT+2, Patrick Ohly wrote: deloptes writes: > 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. I'm currently building against libopenobex2-dev on Ubuntu Bionic, and that at least seems to work fine without changes to the SyncEvolution source code. However, I haven't tested syncing via OBEX with the resulting binaries. When you say "is not working", what problems do you see? -- Best Regards Patrick Ohly _______________________________________________ SyncEvolution mailing list -- syncevolution at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -------------- next part -------------- An HTML attachment was scrubbed... URL: From deloptes at yahoo.com Fri Jul 31 06:37:32 2020 From: deloptes at yahoo.com (Emanoil Kotsev) Date: Fri, 31 Jul 2020 06:37:32 +0000 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: <865359074.6474507.1596064111409@mail.yahoo.com> References: <865359074.6474507.1596064111409@mail.yahoo.com> Message-ID: <1999128678.6936493.1596177452997@mail.yahoo.com> 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 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. So yes, it builds against openobex-1.7, but it is not working at all. If you could help, it would be great.I was thinking to get one older notebook for testing, but the obex and syncevolution code was too much for me and the time I have too little. If you need a tester however, I am available and I could setup the test pc. The phones are ready N9, Sailfish and older Symbian 5530.All of them work perfectly well with Syncevolution 1.5 and openobex 1.5. Thanks BR On Saturday, July 25, 2020, 10:00:21 PM GMT+2, Patrick Ohly wrote: deloptes writes: > 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. I'm currently building against libopenobex2-dev on Ubuntu Bionic, and that at least seems to work fine without changes to the SyncEvolution source code. However, I haven't tested syncing via OBEX with the resulting binaries. When you say "is not working", what problems do you see? -- Best Regards Patrick Ohly _______________________________________________ SyncEvolution mailing list -- syncevolution at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -------------- next part -------------- An HTML attachment was scrubbed... URL: From g+syncevolution at cobb.uk.net Fri Jul 24 21:20:26 2020 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Fri, 24 Jul 2020 22:20:26 +0100 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: References: Message-ID: <8d8f27c2-15c1-a2b0-0a4b-07ad59df5e1e@cobb.uk.net> On 24/07/2020 20:38, Patrick Ohly wrote: > [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. 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. But if no one wants to use it, there is no point. > * 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. I gave up on the KDE PIM tools (and associated data) some time ago so I am no longer using this. > > * 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? 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. _______________________________________________ SyncEvolution mailing list -- syncevolution at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s From patrick.ohly at intel.com Sat Jul 25 20:06:11 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 25 Jul 2020 22:06:11 +0200 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: <8d8f27c2-15c1-a2b0-0a4b-07ad59df5e1e@cobb.uk.net> References: <8d8f27c2-15c1-a2b0-0a4b-07ad59df5e1e@cobb.uk.net> Message-ID: Graham Cobb writes: > 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 was paying for one of the hosted Exchange services for a while to have something to test against. Costs were okayish, but as I wasn't really doing much with it and it became more expensive once the initial trial period was over, I canceled that. As you said, unless someone really uses it, it makes no sense to put work and real money into ActiveSync support. >> 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. I know what you mean :-( There still seem to be people who care, but their number is shrinking. -- Best Regards Patrick Ohly _______________________________________________ SyncEvolution mailing list -- syncevolution at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s From mcrha at redhat.com Fri Jul 3 15:34:29 2020 From: mcrha at redhat.com (Milan Crha) Date: Fri, 3 Jul 2020 17:34:29 +0200 Subject: [SyncEvolution] Fails to build with boost 1.73.0 Message-ID: Hi, I'm rebuilding SyncEvolution 1.5.3 under Fedora Rawhide (to be Fedora 33), which has boost 1.73.0 and this boost version has changed behavior of the bind.hpp, as shown in the build log: In file included from /usr/include/boost/bind.hpp:30, from ./src/syncevo/GLibSupport.h:41, from src/syncevo/ForkExec.h:30, from src/syncevo/ForkExec.cpp:20: /usr/include/boost/bind.hpp:36:1: note: '#pragma message: The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated. Please use + using namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.' 36 | BOOST_PRAGMA_MESSAGE( The above is only a message, which leads to a build break later in the sources: src/syncevo/Cmdline.cpp: In member function 'bool SyncEvo::Cmdline::run()': src/syncevo/Cmdline.cpp:1426:65: error: '_1' was not declared in this scope 1426 | processLUIDs(source, boost::bind(ShowLUID, logging, _1)); Declaring the BOOST_BIND_GLOBAL_PLACEHOLDERS mutes the message, but it doesn't fix the build. I'd propose a patch, but I do not know a single bit of the boost library. I'm sorry. Bye, Milan _______________________________________________ SyncEvolution mailing list -- syncevolution at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s From mcrha at redhat.com Tue Jul 7 12:23:45 2020 From: mcrha at redhat.com (Milan Crha) Date: Tue, 7 Jul 2020 14:23:45 +0200 Subject: [SyncEvolution] Re: Fails to build with boost 1.73.0 In-Reply-To: References: Message-ID: <83b647961fd1193536a5e5f3e4c6948120b6c7c8.camel@redhat.com> On Fri, 2020-07-03 at 17:34 +0200, Milan Crha wrote: > I'd propose a patch, but I do not know a single bit of the boost > library. Hi, it turned out to be a semi-mechanical replace. See the attached bind.patch. As a bonus, there were these warnings [-Wcatch-value=]: src/syncevo/SyncContext.cpp: In member function 'SyncEvo::SyncMLStatus SyncEvo::SyncContext::doSync()': src/syncevo/SyncContext.cpp:3816:37: warning: catching polymorphic type 'class SyncEvo::TransportException' by value [-Wcatch-value=] 3816 | } catch (TransportException e) { src/syncevo/SyncContext.cpp: In member function 'bool SyncEvo::SyncContext::checkForScriptAbort(SyncEvo::SharedSession)': src/syncevo/SyncContext.cpp:4647:14: warning: catching polymorphic type 'class SyncEvo::NoSuchKey' by value [-Wcatch-value=] 4647 | } catch (NoSuchKey) { src/syncevo/SyncContext.cpp:4651:14: warning: catching polymorphic type 'class SyncEvo::BadSynthesisResult' by value [-Wcatch-value=] 4651 | } catch (BadSynthesisResult) { for which is attached the catch-value.patch. Bye, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: bind.patch Type: text/x-patch Size: 18953 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: catch-value.patch Type: text/x-patch Size: 1162 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list -- syncevolution at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s From patrick.ohly at gmx.de Tue Jul 7 15:50:06 2020 From: patrick.ohly at gmx.de (Patrick Ohly) Date: Tue, 7 Jul 2020 17:50:06 +0200 Subject: [SyncEvolution] Re: Fails to build with boost 1.73.0 In-Reply-To: <83b647961fd1193536a5e5f3e4c6948120b6c7c8.camel@redhat.com> References: <83b647961fd1193536a5e5f3e4c6948120b6c7c8.camel@redhat.com> Message-ID: Milan Crha writes: > On Fri, 2020-07-03 at 17:34 +0200, Milan Crha wrote: > >> I'd propose a patch, but I do not know a single bit of the boost >> library. > > Hi, > it turned out to be a semi-mechanical replace. See the attached > bind.patch. Thanks, that looks reasonable. I really should continue my upstream work on preparing the next release with all of these patches :-/ Bye, Patrick _______________________________________________ SyncEvolution mailing list -- syncevolution at syncevolution.org To unsubscribe send an email to syncevolution-leave at syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s