From merlijn at wizzup.org Sun Oct 4 10:41:26 2020 From: merlijn at wizzup.org (Merlijn Wajer) Date: Sun, 4 Oct 2020 12:41:26 +0200 Subject: [SyncEvolution] Fixing the Maemo backend Message-ID: Hi, I'm interested in getting the Maemo backend up and running again, to be used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable Devuan/Debian). The backend doesn't seem to be enabled by default in Debian, and it also doesn't seem to build, when enabled explicitly. The dbus-1 cflags and libs are missing (I added a call to pkg-config to work around this in the maemo.am). Then, I can see my calendar backends and invoke a sync, but it throws a weird error when I try to sync like this: > user at devuan:~$ syncevolution --sync refresh-from-client radicale calendar This error shows up a lot (but maybe it is not harmful?): > [ERROR] @default/radicalecal: basic_string::replace: __pos (which is 4294967295) > this->size() (which is 11) Here's a slightly more verbose log, with most of my calendar events removed, and two (first and last) left in place, but the description modified. > user at devuan:~$ syncevolution --sync refresh-from-client radicale radicalecal > [WARNING] radicale: ignoring username , it is not needed > [INFO] @default/addressbook: inactive > [INFO] @default/calendar: inactive > [INFO] @default/memo: inactive > [INFO] @default/radicalejournal: inactive > [INFO] @default/radicaletodo: inactive > [INFO] @default/todo: inactive > [WARNING] radicale: ignoring username , it is not needed > [INFO @radicale] target side of local sync ready > [INFO @radicale] @radicale/addressbook: inactive > [INFO @radicale] @radicale/calendar: inactive > [INFO @radicale] @radicale/memo: inactive > [INFO @radicale] @radicale/radicalejournal: inactive > [INFO @radicale] @radicale/radicaletodo: inactive > [INFO @radicale] @radicale/todo: inactive > [INFO @radicale] @radicale/radicalecal: using configured database=http://localhost:5223/merlijn/f5203b02-1985-a468-7a57-4c00a87f0850/ > [INFO @radicale] @radicale/radicalecal: starting first time sync from client (peer is server) > [INFO @radicale] @radicale/radicalecal: sent 190/265 > [INFO] @default/radicalecal: starting first time sync from client (peer is client) > [INFO] creating complete data backup of datastore radicalecal before sync (enabled with dumpData and needed for printChanges) > @default data changes to be applied during synchronization: > *** @default/radicalecal *** > Comparison was impossible. > > [INFO] @default/radicalecal: deleting 0 > [INFO] @default/radicalecal: started > [INFO] @default/radicalecal: adding "specific text removed" > [ERROR] @default/radicalecal: basic_string::replace: __pos (which is 4294967295) > this->size() (which is 11) > [snip] > [INFO] @default/radicalecal: adding "specific text 2 removed" > [ERROR] @default/radicalecal: basic_string::replace: __pos (which is 4294967295) > this->size() (which is 11) > [INFO] @default/radicalecal: received 189 > [INFO @radicale] @radicale/radicalecal: first time sync done unsuccessfully > [ERROR @radicale] @radicale/radicalecal: fatal error (remote, status 500) > > Synchronization failed, see /home/user/.cache/syncevolution/target_+config at radicale-2020-10-04-10-28-c/syncevolution-log.html for details. > > Changes applied during synchronization (@radicale): > +---------------|-----------------------|-----------------------|-CON-+ > | | @radicale | @default | FLI | > | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | radicalecal | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > | refresh-from-local, 0 KB sent by client, 0 KB received | > | fatal error (remote, status 500) | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | start Sun Oct 4 10:28:56 2020, duration 0:04min | > | fatal error (remote, status 500) | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > First ERROR encountered: fatal error (remote, status 500) > [ERROR] error code from SyncEvolution fatal error (remote, status 500): failure on target side @radicale of local sync > [INFO] @default/radicalecal: first time sync done unsuccessfully > [ERROR] @default/radicalecal: aborted on behalf of user (local, status 20017) > [INFO] creating complete data backup after sync (enabled with dumpData and needed for printChanges) > > Synchronization failed, see /home/user/.cache/syncevolution/radicale-2020-10-04-10-28-b/syncevolution-log.html for details. > > Changes applied during synchronization: > +---------------|-----------------------|-----------------------|-CON-+ > | | @default | @radicale | FLI | > | Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | radicalecal | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | > | refresh-from-remote, 0 KB sent by client, 0 KB received | > | item(s) in database backup: 0 before sync, 0 after it | > | fatal error (remote, status 500) | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > | start Sun Oct 4 10:28:56 2020, duration 0:04min | > | fatal error (remote, status 500) | > +---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ > First ERROR encountered: basic_string::replace: __pos (which is 4294967295) > this->size() (which is 11) > > Data modified @default during synchronization: > *** @default/radicalecal *** > no changes The error is quite cryptic, and it's not clear to me what exactly is throwing this error. Any help would be appreciated. I'd happy to help fixing the problem. Would it be helpful if I also included the html log file? For the record, this is how I did the setup (this works on my Nokia N900 with the old Fremantle Maemo): > user at devuan:~$ syncevolution --configure \ >> --template webdav \ >> username=merlijn \ >> password=REMOVED \ >> syncURL=http://localhost:5223/ \ >> target-config at radicale > [INFO] addressbook: configuring datastore with sync mode 'two-way' > [INFO] calendar: configuring datastore with sync mode 'two-way' > [INFO] memo: configuring datastore with sync mode 'two-way' > [INFO] todo: configuring datastore with sync mode 'two-way' > user at devuan:~$ syncevolution --configure \ >> database=http://localhost:5223/merlijn/f5203b02-1985-a468-7a57-4c00a87f0850/ \ >> backend=caldavtodo \ >> target-config at radicale radicaletodo > user at devuan:~$ syncevolution --configure \ >> database=http://localhost:5223/merlijn/f5203b02-1985-a468-7a57-4c00a87f0850/ \ >> backend=caldavjournal \ >> target-config at radicale radicalejournal > user at devuan:~$ syncevolution --configure \ >> database=http://localhost:5223/merlijn/f5203b02-1985-a468-7a57-4c00a87f0850/ \ >> backend=caldav \ >> target-config at radicale radicalecal > user at devuan:~$ syncevolution --configure \ >> --template SyncEvolution_Client \ >> sync=none \ >> syncURL=local://@radicale \ >> username= \ >> password= \ >> radicale > [INFO] addressbook: inactive > [INFO] calendar: inactive > [INFO] memo: inactive > [INFO] todo: inactive > user at devuan:~$ syncevolution --configure \ >> sync=two-way \ >> backend=todo \ >> database= \ >> radicale radicaletodo > user at devuan:~$ syncevolution --configure \ >> sync=two-way \ >> backend=memo \ >> database= \ >> radicale radicalejournal > user at devuan:~$ syncevolution --configure \ >> sync=two-way \ >> backend=calendar \ >> database= \ >> radicale radicalecal > user at devuan:~$ syncevolution --sync refresh-from-client radicale radicalecal Any clues? Cheers, Merlijn _______________________________________________ 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 Sun Oct 4 11:58:41 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 4 Oct 2020 13:58:41 +0200 Subject: [SyncEvolution] Re: Fixing the Maemo backend In-Reply-To: References: Message-ID: Merlijn Wajer writes: > I'm interested in getting the Maemo backend up and running again, to be > used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable > Devuan/Debian). As you noticed, that backend needs a maintainer. I'm currently trying to get an updated SyncEvolution release-ready (using more modern C++, adapted to recent versions of the libraries it depends on). If you care about Maemo to work in that release, then now is a good time to debug this. There is a "for-master/master-next" branch with the revised code, but I am still rebasing that from time to time. > Then, I can see my calendar backends and invoke a sync, but it throws a > weird error when I try to sync like this: > >> user at devuan:~$ syncevolution --sync refresh-from-client radicale calendar > > This error shows up a lot (but maybe it is not harmful?): > >> [ERROR] @default/radicalecal: basic_string::replace: __pos (which is >4294967295) > this->size() (which is 11) This indicates that an invalid string replace was attempted for a C++ string (out-of-bounds index), which got caught by the C++ runtime and turned into an exception. > Here's a slightly more verbose log, with most of my calendar events > removed, and two (first and last) left in place, but the description > modified. > >> user at devuan:~$ syncevolution --sync refresh-from-client radicale radicalecal >> [WARNING] radicale: ignoring username , it is not needed >> [INFO] @default/addressbook: inactive >> [INFO] @default/calendar: inactive >> [INFO] @default/memo: inactive >> [INFO] @default/radicalejournal: inactive >> [INFO] @default/radicaletodo: inactive >> [INFO] @default/todo: inactive >> [WARNING] radicale: ignoring username , it is not needed >> [INFO @radicale] target side of local sync ready >> [INFO @radicale] @radicale/addressbook: inactive >> [INFO @radicale] @radicale/calendar: inactive >> [INFO @radicale] @radicale/memo: inactive >> [INFO @radicale] @radicale/radicalejournal: inactive >> [INFO @radicale] @radicale/radicaletodo: inactive >> [INFO @radicale] @radicale/todo: inactive >> [INFO @radicale] @radicale/radicalecal: using configured database=http://localhost:5223/merlijn/f5203b02-1985-a468-7a57-4c00a87f0850/ >> [INFO @radicale] @radicale/radicalecal: starting first time sync from client (peer is server) >> [INFO @radicale] @radicale/radicalecal: sent 190/265 >> [INFO] @default/radicalecal: starting first time sync from client (peer is client) >> [INFO] creating complete data backup of datastore radicalecal before sync (enabled with dumpData and needed for printChanges) >> @default data changes to be applied during synchronization: >> *** @default/radicalecal *** >> Comparison was impossible. >> >> [INFO] @default/radicalecal: deleting 0 >> [INFO] @default/radicalecal: started >> [INFO] @default/radicalecal: adding "specific text removed" >> [ERROR] @default/radicalecal: basic_string::replace: __pos (which is >> 4294967295) > this->size() (which is 11) There's no strack trace for the exception printed, so it's impossible to determine where it occurs. Try this: SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no \ --sync-property loglevel=10 \ --sync refresh-from-client radicale radicalecal When the exception is thrown, gdb might stop. > Would it be helpful if I also included the html log file? No, that won't have more information about this. -- 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 merlijn at wizzup.org Sun Oct 4 14:23:58 2020 From: merlijn at wizzup.org (Merlijn Wajer) Date: Sun, 4 Oct 2020 16:23:58 +0200 Subject: [SyncEvolution] Re: Fixing the Maemo backend In-Reply-To: References: Message-ID: <0173940d-9e8c-1319-a309-d31792996fa9@wizzup.org> Hi, On 04/10/2020 13:58, Patrick Ohly wrote: > Merlijn Wajer writes: >> I'm interested in getting the Maemo backend up and running again, to be >> used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable >> Devuan/Debian). > > As you noticed, that backend needs a maintainer. I'm currently trying to > get an updated SyncEvolution release-ready (using more modern C++, > adapted to recent versions of the libraries it depends on). If you care > about Maemo to work in that release, then now is a good time to debug > this. Ok, if I can bend it into shape I'm happy to maintain it for now. > There is a "for-master/master-next" branch with the revised code, but I > am still rebasing that from time to time. Check, let me try to get it to work first. >> Then, I can see my calendar backends and invoke a sync, but it throws a >> weird error when I try to sync like this: >> >>> user at devuan:~$ syncevolution --sync refresh-from-client radicale calendar >> >> This error shows up a lot (but maybe it is not harmful?): >> >>> [ERROR] @default/radicalecal: basic_string::replace: __pos (which is >> 4294967295) > this->size() (which is 11) > > This indicates that an invalid string replace was attempted for a C++ > string (out-of-bounds index), which got caught by the C++ runtime and > turned into an exception. Check. > > There's no strack trace for the exception printed, so it's impossible to > determine where it occurs. > > Try this: > > SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no \ > --sync-property loglevel=10 \ > --sync refresh-from-client radicale radicalecal > > When the exception is thrown, gdb might stop. I entered this in gdb before typing 'run': > catch throw .* And then it caught the exception [1]. And it looks like the exception is in "calendar-backend", which is a Maemo component - so the problem might not even be in syncevolution per se. I will dive in, and I will let you know. Thank you for the quick response. Cheers, Merlijn [1] > Thread 1 "syncevolution" hit Catchpoint 1 (exception thrown), 0x00007ffff7367afd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > (gdb) bt > #0 0x00007ffff7367afd in __cxa_throw () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > #1 0x00007ffff7363891 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > #2 0x00007ffff35d6d41 in std::__cxx11::basic_string, std::allocator >::_M_check(unsigned long, char const*) const > (__s=0x7ffff35faf24 "basic_string::replace", __pos=, this=0x7fffffff9d50) at /usr/include/c++/8/bits/basic_string.h:299 > #3 0x00007ffff35d6d41 in std::__cxx11::basic_string, std::allocator >::replace(unsigned long, unsigned long, char const*, unsigned long) (__n2=1, __s=0x7ffff360806b ",", __n1=2, __pos=, this=0x7fffffff9d50) at /usr/include/c++/8/bits/basic_string.h:1932 > #4 0x00007ffff35d6d41 in std::__cxx11::basic_string, std::allocator >::replace(unsigned long, unsigned long, char const*) > (__s=0x7ffff360806b ",", __n1=2, __pos=, this=0x7fffffff9d50) at /usr/include/c++/8/bits/basic_string.h:1955 > #5 0x00007ffff35d6d41 in ICalConverter::icalVcalToLocal(std::__cxx11::basic_string, std::allocator >, FileType, int&) > (this=this at entry=0x555557b23de0, szCont="BEGIN:VCALENDAR\nVERSION:2.0\nPRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN\nBEGIN:VTIMEZONE\nTZID:Amsterdam\nBEGIN:STANDARD\nDTSTART:19671029T030000\nRRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU\n"..., iType=iType at entry=ICAL_TYPE, pErrorCode=@0x7fffffffabdc: 21845) > at ICalConverter.cpp:3940 > #6 0x00007ffff36cdd41 in SyncEvo::MaemoCalendarSource::insertItem(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool) > (this=0x5555579d4560, uid="", item="BEGIN:VCALENDAR\r\nVERSION:2.0\r\nPRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN\r\nBEGIN:VTIMEZONE\r\nTZID:Amsterdam\r\nBEGIN:STANDARD\r\nDTSTART:19671029T030000\r\nRRULE:FREQ=MONTHLY;INTERVAL=12;BYDA"..., raw=) at /usr/include/c++/8/bits/basic_string.h:936 > #7 0x00007ffff7a61cd7 in boost::detail::function::function_obj_invoker0, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool>, boost::_bi::list4, boost::_bi::value, std::allocator > >, boost::_bi::value, std::allocator > >, boost::_bi::value > >, SyncEvo::SyncSourceRaw::InsertItemResult>::invoke(boost::detail::function::function_buffer&) () > at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #8 0x00007ffff7a5fe23 in SyncEvo::TrackingSyncSource::continueInsertItem(boost::function const&, std::__cxx11::basic_string, std::allocator > const&) () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #9 0x00007ffff7a61163 in SyncEvo::TrackingSyncSource::doInsertItem(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool) () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #10 0x00007ffff7a61580 in SyncEvo::TrackingSyncSource::insertItem(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #11 0x00007ffff798f213 in SyncEvo::SyncSourceSerialize::insertItemAsKey(sysync::KeyType*, sysync::ItemIDType*) () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #12 0x00007ffff79a373a in boost::detail::function::function_obj_invoker2 >, boost::_mfi::mf2 >, SyncEvo::SyncSourceSerialize, sysync::KeyType*, sysync::ItemIDType*>, boost::_bi::list3, boost::arg<1>, boost::arg<2> > >, boost::variant >, sysync::KeyType*, sysync::ItemIDType*>::invoke(boost::detail::function::function_buffer&, sysync::KeyType*, sysync::ItemIDType*) () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #13 0x00007ffff79d9927 in SyncEvo::OperationWrapperSwitch > (sysync::KeyType*, sysync::ItemIDType*), 2, boost::variant > >::operator()(sysync::KeyType*, sysync::ItemIDType*) const () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #14 0x00007ffff79c582a in SyncEvolution_InsertItemAsKey () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #15 0x00007ffff662a116 in sysync::TDB_Api::InsertItemAsKey(sysync::KeyType*, char const*, sysync::TDB_Api_ItemID&) > (this=this at entry=0x555557a068a0, aItemKey=aItemKey at entry=0x555557b1fb90, parentID=parentID at entry=0x7ffff67428d5 "", newID=...) > at DB_interfaces/api_db/dbapi.cpp:1924 > #16 0x00007ffff6633080 in sysync::TPluginApiDS::apiAddItem(sysync::TMultiFieldItem&, std::__cxx11::basic_string, std::allocator >&) > (this=0x555557a05860, aItem=..., aLocalID="") at DB_interfaces/api_db/pluginapids.cpp:1384 > #17 0x00007ffff6666533 in sysync::TCustomImplDS::implProcessItem(sysync::TSyncItem*, sysync::TStatusCommand&) > (this=0x555557a05860, aItemP=0x555555637260, aStatusCommand=...) at sysync/customimplds.cpp:2918 > #18 0x00007ffff66bb773 in sysync::TStdLogicDS::logicProcessRemoteItem(sysync::TSyncItem*, sysync::TStatusCommand&, bool&, std::__cxx11::basic_string, std::allocator >*) (this=0x555557a05860, syncitemP=0x555555637260, aStatusCommand=..., aVisibleInSyncset=@0x7fffffffbb1f: true, aGUID=0x0) > at sysync/stdlogicds.cpp:1446 > #19 0x00007ffff668a807 in sysync::TLocalEngineDS::engProcessRemoteItemAsServer(sysync::TSyncItem*, sysync::TStatusCommand&) > (this=, aSyncItemP=0x555555637260, aStatusCommand=...) at sysync/localengineds.cpp:6407 > #20 0x00007ffff66828dc in sysync::TLocalEngineDS::engProcessSyncOpItem(sysync::TSyncOperation, sml_item_s*, sml_metinf_metinf_s*, sysync::TStatusCommand&) > (this=0x555557a05860, aSyncOp=aSyncOp at entry=sysync::sop_add, aItemP=aItemP at entry=0x555557b23b10, aMetaP=aMetaP at entry=0x555557b197c0, aStatusCommand=...) > at sysync/localengineds.cpp:5277 > #21 0x00007ffff66dfdc8 in sysync::TSyncSession::processSyncOpItem(sysync::TSyncOperation, sml_item_s*, sml_metinf_metinf_s*, sysync::TLocalEngineDS*, sysync::TStatusCommand&, bool&) > (this=0x5555579e8d20, aSyncOp=, aItemP=0x555557b23b10, aMetaP=aMetaP at entry=0x555557b197c0, aLocalSyncDatastore=, aStatusCommand=..., aQueueForLater=@0x7fffffffbd3b: false) at sysync/syncsession.cpp:3999 > #22 0x00007ffff66d725e in sysync::TSyncOpCommand::execute() (this=0x555557b00b80) at sysync/synccommand.cpp:2637 > #23 0x00007ffff66e846e in sysync::TSyncSession::process(sysync::TSmlCommand*) (this=this at entry=0x5555579e8d20, aSyncCommandP=0x555557b00b80) > at sysync/syncsession.cpp:2576 > #24 0x00007ffff66e89d5 in sysync::TSyncSession::AddCmd(sml_generic_s*) (this=this at entry=0x5555579e8d20, aContentP=) at sysync/syncsession.cpp:5803 > #25 0x00007ffff66cc1bc in sysync::TSyncAppBase::AddCmd(void*, sml_generic_s*) (this=0x5555555c4670, userData=0x5555579e8d20, aContentP=) > at sysync/syncappbase.cpp:2113 > #26 0x00007ffff6990356 in smlProcessData () at /usr/lib/x86_64-linux-gnu/libsmltk.so.0 > #27 0x00007ffff66c50cd in sysync::TSyncAgent::ServerProcessingStep(unsigned short&, sysync::TEngineProgressType*) > (this=this at entry=0x5555579e8d20, aStepCmd=@0x7fffffffc09a: 102, aInfoP=) at sysync/syncagent.cpp:3289 > #28 0x00007ffff66c6a69 in sysync::TSyncAgent::ServerSessionStep(unsigned short&, sysync::TEngineProgressType*) > (this=this at entry=0x5555579e8d20, aStepCmd=@0x7fffffffc09a: 102, aInfoP=aInfoP at entry=0x7fffffffc230) at sysync/syncagent.cpp:3257 > #29 0x00007ffff66c895f in sysync::TSyncAgent::SessionStep(unsigned short&, sysync::TEngineProgressType*) > (this=this at entry=0x5555579e8d20, aStepCmd=@0x7fffffffc09a: 102, aInfoP=aInfoP at entry=0x7fffffffc230) at sysync/syncagent.cpp:3058 > #30 0x00007ffff6649276 in sysync::TServerEngineInterface::SessionStep(sysync::SessionType*, unsigned short&, sysync::TEngineProgressType*) > (this=, aSessionH=0x5555579e8ab0, aStepCmd=@0x7fffffffc09a: 102, aInfoP=0x7fffffffc230) at Transport_interfaces/engine/enginesessiondispatch.cpp:478 > #31 0x00007ffff790556b in SyncEvo::SharedEngine::SessionStep(boost::shared_ptr const&, unsigned short&, sysync::TEngineProgressType*) () > at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #32 0x00007ffff79f3ba8 in SyncEvo::SyncContext::doSync() () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #33 0x00007ffff79fb713 in SyncEvo::SyncContext::sync(SyncEvo::SyncReport*) () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #34 0x00007ffff7962711 in SyncEvo::Cmdline::run() () at /usr/lib/x86_64-linux-gnu/libsyncevolution.so.0 > #35 0x000055555556d24f in main () -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From merlijn at wizzup.org Sun Oct 4 19:04:57 2020 From: merlijn at wizzup.org (Merlijn Wajer) Date: Sun, 4 Oct 2020 21:04:57 +0200 Subject: [SyncEvolution] Re: Fixing the Maemo backend In-Reply-To: <0173940d-9e8c-1319-a309-d31792996fa9@wizzup.org> References: <0173940d-9e8c-1319-a309-d31792996fa9@wizzup.org> Message-ID: <3f2f953d-7c2b-2ec5-23fb-f1dc64af968b@wizzup.org> Hi, On 04/10/2020 16:23, Merlijn Wajer wrote: > Hi, > > On 04/10/2020 13:58, Patrick Ohly wrote: >> Merlijn Wajer writes: >>> I'm interested in getting the Maemo backend up and running again, to be >>> used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable >>> Devuan/Debian). >> >> As you noticed, that backend needs a maintainer. I'm currently trying to >> get an updated SyncEvolution release-ready (using more modern C++, >> adapted to recent versions of the libraries it depends on). If you care >> about Maemo to work in that release, then now is a good time to debug >> this. > > Ok, if I can bend it into shape I'm happy to maintain it for now. Please let me know if you would like me to pick up some maintenance tasks. As per below, I currently have the code working with the latest syncevolution. >> There is a "for-master/master-next" branch with the revised code, but I >> am still rebasing that from time to time. > > Check, let me try to get it to work first. > >>> Then, I can see my calendar backends and invoke a sync, but it throws a >>> weird error when I try to sync like this: >>> >>>> user at devuan:~$ syncevolution --sync refresh-from-client radicale calendar >>> >>> This error shows up a lot (but maybe it is not harmful?): >>> >>>> [ERROR] @default/radicalecal: basic_string::replace: __pos (which is >>> 4294967295) > this->size() (which is 11) >> >> This indicates that an invalid string replace was attempted for a C++ >> string (out-of-bounds index), which got caught by the C++ runtime and >> turned into an exception. Problem found and fixed. The problem was with calendar-backend, and never even having been run on any 64 bit platform. (It was using 'int', 'unsigned int' instead of string::size_type or 'size_t') I will be performing more cleanups on that codebase. So the problem wasn't in syncevolution at all. That said -- what can I do to get the Maemo backend marked as active again? Cheers, Merlijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From patrick.ohly at intel.com Sun Oct 11 17:50:31 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 11 Oct 2020 19:50:31 +0200 Subject: [SyncEvolution] Re: Fixing the Maemo backend In-Reply-To: <3f2f953d-7c2b-2ec5-23fb-f1dc64af968b@wizzup.org> References: <0173940d-9e8c-1319-a309-d31792996fa9@wizzup.org> <3f2f953d-7c2b-2ec5-23fb-f1dc64af968b@wizzup.org> Message-ID: Merlijn Wajer writes: > Hi, > > On 04/10/2020 16:23, Merlijn Wajer wrote: >> Hi, >> >> On 04/10/2020 13:58, Patrick Ohly wrote: >>> Merlijn Wajer writes: >>>> I'm interested in getting the Maemo backend up and running again, to be >>>> used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable >>>> Devuan/Debian). >>> >>> As you noticed, that backend needs a maintainer. I'm currently trying to >>> get an updated SyncEvolution release-ready (using more modern C++, >>> adapted to recent versions of the libraries it depends on). If you care >>> about Maemo to work in that release, then now is a good time to debug >>> this. >> >> Ok, if I can bend it into shape I'm happy to maintain it for now. > > Please let me know if you would like me to pick up some maintenance > tasks. As per below, I currently have the code working with the latest > syncevolution. Being available to test and fix the code if necessary is a good first step. I can't even compile it myself because I lack a system with the necessary libraries. Is there perhaps a Dockerfile that provides everything that is needed to build for Maemo? I could use that for automatic build and perhaps even functional testing. > So the problem wasn't in syncevolution at all. That said -- what can I > do to get the Maemo backend marked as active again? Marked where? It's not enabled by default in configure because most people won't have the necessary libraries available and probably also don't want to build it. That EDS is enabled by default is partly a historic exception, partly because I suspect that most users are using it. -- 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 merlijn at wizzup.org Mon Oct 12 21:49:37 2020 From: merlijn at wizzup.org (Merlijn Wajer) Date: Mon, 12 Oct 2020 23:49:37 +0200 Subject: [SyncEvolution] Re: Fixing the Maemo backend In-Reply-To: References: <0173940d-9e8c-1319-a309-d31792996fa9@wizzup.org> <3f2f953d-7c2b-2ec5-23fb-f1dc64af968b@wizzup.org> Message-ID: Hi, On 11/10/2020 19:50, Patrick Ohly wrote: >> Please let me know if you would like me to pick up some maintenance >> tasks. As per below, I currently have the code working with the latest >> syncevolution. > > Being available to test and fix the code if necessary is a good first > step. I can't even compile it myself because I lack a system with the > necessary libraries. Understood. I did document how to set up the synchronisation on a Maemo (Leste) system, here: https://leste.maemo.org/Calendar > Is there perhaps a Dockerfile that provides everything that is needed to > build for Maemo? I could use that for automatic build and perhaps even > functional testing. Hm... There isn't one yet, but I could attempt to make one. We do have virtual images that can run in QEMU/Virtualbox, but that probably isn't quite what you are looking for: https://leste.maemo.org/Virtual_Machine I can try to write a Dockerfile in the next day or two. >> So the problem wasn't in syncevolution at all. That said -- what can I >> do to get the Maemo backend marked as active again? > > Marked where? > > It's not enabled by default in configure because most people won't have > the necessary libraries available and probably also don't want to build > it. That EDS is enabled by default is partly a historic exception, > partly because I suspect that most users are using it. Good question. I don't know where I saw that it was inactive, but I recall seeing it somewhere... That said, the backend does currently need minor changes (pkg-config with dbus-1). I'll let you know once I have a Dockerfile. Thanks, Cheers, Merlijn From patrick.ohly at intel.com Wed Oct 14 07:25:55 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 14 Oct 2020 09:25:55 +0200 Subject: [SyncEvolution] Re: Fixing the Maemo backend In-Reply-To: References: <0173940d-9e8c-1319-a309-d31792996fa9@wizzup.org> <3f2f953d-7c2b-2ec5-23fb-f1dc64af968b@wizzup.org> Message-ID: Merlijn Wajer writes: > Hi, >> Is there perhaps a Dockerfile that provides everything that is needed to >> build for Maemo? I could use that for automatic build and perhaps even >> functional testing. > > Hm... There isn't one yet, but I could attempt to make one. We do have > virtual images that can run in QEMU/Virtualbox, but that probably isn't > quite what you are looking for: https://leste.maemo.org/Virtual_Machine > > I can try to write a Dockerfile in the next day or two. If the Maemo backend needs D-Bus, then note that I have a solution for that: https://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/test/dbus-session.sh It can be invoked inside a container and wraps another command (like bash) which then has a D-Bus session. So all that the Dockerfile has to provide is really just the libraries and binaries for Maemo. -- 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 patrick.ohly at intel.com Wed Oct 14 07:28:47 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 14 Oct 2020 09:28:47 +0200 Subject: [SyncEvolution] Re: Fixing the Maemo backend In-Reply-To: References: Message-ID: Merlijn Wajer writes: > I'm interested in getting the Maemo backend up and running again, to be > used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable > Devuan/Debian). BTW, what happened with Buteo? I though that was the sync solution for Maemo. -- 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 patrick.ohly at intel.com Sat Oct 3 15:09:18 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 3 Oct 2020 17:09:18 +0200 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: References: <865359074.6474507.1596064111409@mail.yahoo.com> <1999128678.6936493.1596177452997@mail.yahoo.com> Message-ID: Patrick Ohly writes: > Patrick Ohly writes: > >> deloptes writes: >>> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly wrote: >>> >>>> Emanoil Kotsev 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::allocator > > 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 _______________________________________________ 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 Sat Oct 3 18:39:48 2020 From: deloptes at gmail.com (deloptes) Date: Sat, 3 Oct 2020 20:39:48 +0200 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: References: <865359074.6474507.1596064111409@mail.yahoo.com> <1999128678.6936493.1596177452997@mail.yahoo.com> Message-ID: 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. Thank you once again for the effort. regards On Sat, Oct 3, 2020 at 5:09 PM Patrick Ohly wrote: > Patrick Ohly writes: > > > Patrick Ohly writes: > > > >> deloptes writes: > >>> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly > wrote: > >>> > >>>> Emanoil Kotsev 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::allocator > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Sun Oct 4 12:31:42 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 4 Oct 2020 14:31:42 +0200 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: References: <865359074.6474507.1596064111409@mail.yahoo.com> <1999128678.6936493.1596177452997@mail.yahoo.com> Message-ID: deloptes 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. -- 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 patrick.ohly at intel.com Sun Oct 11 17:20:07 2020 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 11 Oct 2020 19:20:07 +0200 Subject: [SyncEvolution] Re: new SyncEvolution binaries, dropping features? In-Reply-To: References: <865359074.6474507.1596064111409@mail.yahoo.com> <1999128678.6936493.1596177452997@mail.yahoo.com> Message-ID: Patrick Ohly writes: > deloptes 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. Got the new battery, which worked until it also ran out of power. To cut a long story short, it was the charger which didn't work with the phone. After trying with a different one, I could charge both batteries again... So far with the good news. The bad news is that libopenobex2 works fine with that phone, i.e. I cannot reproduce the regression. Deloptes, can you try building the for-master/master-next branch (currently rev 83a31729, but may get rebased again) and sync with that using: SYNCEVOLUTION_DEBUG=10 syncevolution --daemon=no --sync-property loglevel=10 ... 2>&1 | tee sync.log That will print log messages for OBEX_Request and OBEX_HandleInput. Please send me the log file. -- 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