[SyncEvolution] Re: Small patch for TDE plugins

[deloptes]

Hi,
regarding the tdepim notes issue, there was missing the link to generated
sources. Unfortunately Jolla dropped the notes from Sailfish and I can only
test it on the older N9 that I do not use anymore (except for testing).

Find attached a patch that solves this and also I added another change -
initializing the TDEABC VCardConverter earlier - it can be reused later and
saves time.

happy new year and all the best to you
regards

On Thu, Dec 17, 2020 at 1:21 PM Patrick Ohly  wrote:

> deloptes  writes:
> > deloptes wrote:
> >
> >> Hi Patrik,
> >> as you mentioned you are working on some kind of next release. I wonder
> if
> >> you could add a patch or let me know how I can add it (attached).
> >>
> >> I found out it should not destroy here as it is being (probably) cleaned
> >> up somewhere else. Destroying here crashes.
> >>
> >> I also wonder if we would be able to use openobex2 (1.7) in the new
> >> version.
> >>
> >> thank you in advance
> >>
> >> kind regards
> >
> > Hmm, to me it looks like I attached some nonsense here - sorry for
> > this :)
>
> And sorry for the delay with integrating this ;-) It's now in a branch
> and getting tested (again).
>
> I first ran into some issue with "make dist" which I solved as follows:
>
> commit e489ac358b3f1c40f45d7c3c55a7a9aaea85e41f (HEAD -> master-next, tag:
> syncevolution-2-0-0-pre2, pohly/for-master/master-next,
> master-nightly-before-2020-12-17-04-10, master-nightly)
> Author: Patrick Ohly 
> Date:   Thu Dec 17 03:22:07 2020 -0800
>
> tde: fix "make dist" issue
>
> "make dist" tries to include all source files in the archive, which
> does not work for the generated files.
>
> diff --git a/src/backends/tdepim/tdepim.am b/src/backends/tdepim/tdepim.am
> index 5aace174..4c898944 100644
> --- a/src/backends/tdepim/tdepim.am
> +++ b/src/backends/tdepim/tdepim.am
> @@ -38,8 +38,6 @@ if ENABLE_TDEPIMNOTES
>  src_backends_tdepim_synctdepimnotes_src += \
>src/backends/tdepim/TDEPIMSyncSource.h \
>src/backends/tdepim/TDEPIMSyncSource.cpp \
> -  src/backends/tdepim/KNotesIface_stub.h \
> -  src/backends/tdepim/KNotesIface_stub.cpp \
>src/backends/tdepim/TDEPIMNotesSource.h \
>src/backends/tdepim/TDEPIMNotesSource.cpp
>  endif
> @@ -59,13 +57,25 @@ src/backends/tdepim/KNotesIface_stub.h:
> src/backends/tdepim/KNotesIface.kidl
>
>  src/backends/tdepim/KNotesIface_stub.cpp:
> src/backends/tdepim/KNotesIface_stub.h
>
> -CLEANFILES += src/backends/tdepim/KNotesIface_stub.h \
> +src_backends_tdepim_built_sources =
> +src_backends_tdepim_generated =
> +if ENABLE_TDEPIMNOTES
> +src_backends_tdepim_built_sources += \
> +   src/backends/tdepim/KNotesIface_stub.h \
> src/backends/tdepim/KNotesIface_stub.cpp \
> +
> +src_backends_tdepim_generated += \
> +   $(src_backends_tdepim_built_sources) \
> src/backends/tdepim/KNotesIface.kidl \
> src/backends/tdepim/KNotesIface_skel.cpp \
> src/backends/tdepim/KNotesIface.h
> +endif
> +
> +CLEANFILES += $(src_backends_tdepim_generated)
> +BUILT_SOURCES += $(src_backends_tdepim_built_sources)
>
>  src_backends_tdepim_synctdepimcal_la_SOURCES =
> $(src_backends_tdepim_synctdepimcal_src)
> +nodist_src_backends_tdepim_synctdepimcal_la_SOURCES =
> $(src_backends_tdepim_built_sources)
>  src_backends_tdepim_synctdepimcal_la_LIBADD = $(TDEPIMCAL_LIBS)
> $(SYNCEVOLUTION_LIBS)
>  src_backends_tdepim_synctdepimcal_la_CPPFLAGS = $(TDEPIMCAL_CFLAGS)
> $(src_backends_tdepim_cppflags)
>  src_backends_tdepim_synctdepimcal_la_LDFLAGS = -module -avoid-version -ldl
>
> --
> Best Regards
>
> Patrick Ohly
> Senior Software Engineer
>
> Intel GmbH
> System Software Engineering/Cloud Native
> Usenerstr. 5a   Phone: +49-228-2493652
> 53129 Bonn
> Germany
>


syncevolution-tde.patch.gz
Description: application/gzip
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: Fixing the Maemo backend

[deloptes]

Hi,
Buteo was in MeeGo and is now in Mer which is the base for Sailfish.
MeeGo is Maemo + Mobilin (https://en.wikipedia.org/wiki/Maemo).
I don't think Buteo works on Maemo since Buteo is Qt and I believe Maemo is
GTK.


On Sun, Dec 27, 2020 at 11:42 AM Merlijn Wajer  wrote:

> Hi Patrick,
>
> On 14/10/2020 09:28, 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).
> >
> > BTW, what happened with Buteo? I though that was the sync solution for
> > Maemo.
>
> Sorry for the late reply - it looks like Buteo [1] is used by Meego and
> perhaps Nemo Mobile (and maybe Sailfish), but I don't think it was used
> on Maemo (at least I had not seen it mentioned before).
>
> Thanks for the pointer.
>
> Cheers,
> Merlijn
>
> [1] https://wiki.merproject.org/wiki/Buteo
>
>
> ___
> SyncEvolution mailing list -- syncevolution@syncevolution.org
> To unsubscribe send an email to syncevolution-le...@syncevolution.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release

[deloptes]

Hi,
as a heads up I see
[DEVELOPER 00:00:00] Loading backend library synctdepimnotes failed:
/usr/lib/x86_64-linux-gnu/syncevolution/backends/synctdepimnotes.so:
undefined symbol: _ZN16KNotesIface_stubC1ERK9TQCStringS2_

I am not sure if it is something local or as a result of latest changes.
The issue is I am rebuilding all local packages based on recent git pull of
TDE, but I have not upgraded the test system yet as packages are still
building.
It could be related to some changes in TDE as well. I'll come back to you
as soon as I have upgraded the system and tested.

regards



On Sat, Dec 19, 2020 at 12:40 PM Patrick Ohly 
wrote:

> Hello!
>
> I have tagged and built SyncEvolution 1.99.1, a pre-release of what will
> become 2.0.0. As discussed in
>
> https://lists.01.org/hyperkitty/list/syncevolution@syncevolution.org/thread/I3TDB7HTXJDQACI3Y54QXDEYGFPQLOTW/
> I am simplifying the binaries (no more i386, no KDE).
>
> The new release is available as:
> - source code:
>
> https://downloads.syncevolution.org/syncevolution/sources/syncevolution-1.99.1.tar.gz
>   https://gitlab.freedesktop.org/SyncEvolution/syncevolution
> - tar archive:
>
> https://downloads.syncevolution.org/syncevolution/bundle/amd64-tar-gz/syncevolution-1.99.1-bundle-amd64.tar.gz
> - in the *experimental* apt repo:
>   deb http://downloads.syncevolution.org/apt experimental main
>
> The GPG key for all apt repos were renewed. To get the current signing
> key, use
>sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9
>
> Speaking of signing keys, so far I used an expiry period of one year. Would
> anyone care if I made that longer?
>
> The .deb package installs on Debian Stable and Ubuntu Bionic. It does
> not currently install on Debian Testing and Ubuntu Groovy because
> libcppunit changed its ABI. I intend to address that before 2.0.0. As a
> workaround, one can manually install
> https://packages.debian.org/buster/amd64/libcppunit-1.14-0/download
> manually beforehand (untested!).
>
> I have tested the new binaries with Bluetooth/OBEX and a Nokia N97 and
> CardDAV with Google Contacts. Automated testing is also up again, but
> with less coverage than before (only Memotoo for SyncML, Google
> Contacts, Google Calendar).
>
> Testing is based on containers now. If someone wants to see
> interoperability and/or compilation tested with other platforms (TDE,
> OwnCloud), then a Dockerfile which prepares a suitable environment would
> be a good start for adding that.
>
> --
> Best Regards
>
> Patrick Ohly
> ___
> SyncEvolution mailing list -- syncevolution@syncevolution.org
> To unsubscribe send an email to syncevolution-le...@syncevolution.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: new SyncEvolution binaries, dropping features?

[deloptes]

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/synce

[SyncEvolution] Re: new SyncEvolution binaries, dropping features?

[deloptes]

Hi,
for some reason I am not getting this on the mailing list.

On Thu, Sep 3, 2020 at 12:45 PM Patrick Ohly  wrote:

> 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 found out when I heard Nokia starts selling 3310 again, that it does not
implement syncml anymore. I just did a quick search and found this
http://www.synthesis.ch/dl.php/1526/SyncML_Client_for_Android_en.pdf which
means synthesis finds or fights it way.

I wish I could help more.I have one Nokia 5530 XpressMusic (just checked -
it is ~40€ on ebay) that works well. It might be that older models are
cheaper and work too.
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: new SyncEvolution binaries, dropping features?

[deloptes]

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.


> > regards
> > On Thursday, July 30, 2020, 1:08:31 AM GMT+2, Emanoil Kotsev <
> delop...@yahoo.com> 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.
>
> Can you ensure that you have working setup and then just update the
> SyncEvolution side to openobex 1.7? Does that then start to fail? It's
> not clear to me from the description above whether that is something
> that you have tested.
>
>
Yes I did exactly this - installed openobex2 (1.7) with dev package from
debian, compailed SyncEvolution 1.5.2 or 1.5.3 against it and then it does
not work any more. Then removed openobex2 and installed openobex1 with dev
package, compailed SyncEvolution 1.5.2 or 1.5.3 against it and then it
works again.

Same experience with buteo-syncml. Buteo-syncml with openobex1 works and
with openobex2 does not work.

I wrote once to the maintainer of openobex, but he was sparse to answer
that it means the steps to upgrade from 1.5 to 1.7 were not followed and
send me back to the UPGRADE file.

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?

Thank you and regards
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: new SyncEvolution binaries, dropping features?

[deloptes]

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@syncevolution.org
> To unsubscribe send an email to syncevolution-le...@syncevolution.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: Small patch for TDE plugins

[deloptes]

deloptes wrote:

> Hi Patrik,
> as you mentioned you are working on some kind of next release. I wonder if
> you could add a patch or let me know how I can add it (attached).
> 
> I found out it should not destroy here as it is being (probably) cleaned
> up somewhere else. Destroying here crashes.
> 
> I also wonder if we would be able to use openobex2 (1.7) in the new
> version.
> 
> thank you in advance
> 
> kind regards

Hmm, to me it looks like I attached some nonsense here - sorry for this :)


--- TDEPIMSyncSource.cpp.old	2019-12-02 20:54:48.624268558 +0100
+++ TDEPIMSyncSource.cpp	2019-12-02 20:53:02.907598105 +0100
@@ -65,11 +65,6 @@
 
 TDEPIMSyncSource::~TDEPIMSyncSource()
 {
-	if ( newApp ) {
-		delete tdeappPtr;
-		tdeappPtr = 0;
-	}
-// 	SE_LOG_DEBUG(NULL, "TDE base destroyed OK");
 }
 
 SE_END_CXX

___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Small patch for TDE plugins

[deloptes]

Hi Patrik, 
as you mentioned you are working on some kind of next release. I wonder if
you could add a patch or let me know how I can add it (attached).

I found out it should not destroy here as it is being (probably) cleaned up
somewhere else. Destroying here crashes.

I also wonder if we would be able to use openobex2 (1.7) in the new version.

thank you in advance

kind regards




--- tde/1_git/edeps/syncevolution/src/backends/tdepim/TDEPIMSyncSource.cpp	2019-10-11 22:08:13.461862241 +
+++ tde/2_build/edeps/syncevolution/src/backends/tdepim/TDEPIMSyncSource.cpp	2019-10-11 22:09:26.931864863 +
@@ -65,10 +65,11 @@
 
 TDEPIMSyncSource::~TDEPIMSyncSource()
 {
-//	if (tdeappPtr) {
-//delete tdeappPtr;
-//		tdeappPtr = 0;
-//	}
+/*	if (tdeappPtr) {
+	delete tdeappPtr;
+		tdeappPtr = 0;
+	}
+*/
 // 	SE_LOG_DEBUG(NULL, "TDE base destroyed OK");
 }
 

___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: Sync failure - F31

[deloptes]

Max Pyziur wrote:

> 
> Greetings,
> 
> I'm not sure if this is the first time running sync since upgrading to
> F31.
> 
> But through F30, Sync has worked flawlessly Syncing with memotoo and
> evolution.
> 

I am on debian - don't know F.

> Now, using the gui interface, the following error message appears:
> The sync process died unexpectedly.
> 
> I've tried slow sync, deleting the data on the server via the gui, but
> each time the process dies with some variant of the above message.
> 
> So, I'm looking for some sort of log file to see if there any messages or
> other indications of where the flaw would be.
> 
>

Run it from the command line 

SYCNEVOLUTION_DEBUG=3 syncevolution -r loglevel=6  addressbook

then in your ~/.cache/syncevolution you find the logs

And can you check the openobex version? Here it is not working with anything
recent. I still have libopenobex1 1.5. Changes in 1.7 aka libopenobex2
render it unusable


___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Problem syncing some accounts

[deloptes]

Hi Patrik, all,
I am testing BT sync with Sailfish OS (successor to N9/meego)

There is some strange issue with some Accounts/Contacts.

My problem is that I can not edit/modify the contact on the phone, but
locally it looks fine

What does following mean exactly?

When I modify contact locally and sync

[2019-11-03 11:13:43.425] Created command 'Status' (incoming)
–
[2019-11-03 11:13:43.425] 'processStatus' - Processing incoming Status [--
[++] [->end] [->enclosing]

[2019-11-03 11:13:43.425] Started processing Command 'Status' (incoming
MsgID=3, CmdID=3)
[2019-11-03 11:13:43.425] WARNING: RECEIVED NON-OK STATUS 500 for
command 'Replace' (outgoing MsgID=2, CmdID=5)
[2019-11-03 11:13:43.425] - TargetRef (remoteID) = '140'
[2019-11-03 11:13:43.425] Found matching command 'Replace' for Status
[2019-11-03 11:13:43.425] dsConfirmItemOp completed, syncop=replace,
localID='', remoteID='140', FAILURE, errorstatus=500
[2019-11-03 11:13:43.425] Status: General error 500 (original op was
wants-replace) -> aborting sync with this datastore
–
[2019-11-03 11:13:43.425] 'DSAbort' - Aborting datastore sync,
abortStatusCode=500, localProblem=no, resumable=yes [--][++] [->end]
[->enclosing]
[2019-11-03 11:13:43.425] addressbook: testState=TRUE - expected
state>='sync_set_ready', found state=='sync_gen_done'
[2019-11-03 11:13:43.425] SaveSuspendState not possible (SyncML<1.2
or not supported by DB)
[2019-11-03 11:13:43.425] *** Warning: Datastore flagged
aborted (after 0 sec. request processing, 4 sec. total) with REMOTE Status
500
–[2019-11-03 11:13:43.425] End of 'DSAbort' [->top] [->enclosing]
[2019-11-03 11:13:43.425] Status: processed, removed command 'Replace'
from status wait queue
[2019-11-03 11:13:43.425] Status: command 'Replace' has handled status
and allows to be deleted
[2019-11-03 11:13:43.425] Deleted command 'Replace' (outgoing MsgID=2,
CmdID=5)
[2019-11-03 11:13:43.425] Deleted command 'Status' (incoming MsgID=3,
CmdID=3)

–[2019-11-03 11:13:43.425] End of 'processStatus' [->top] [->enclosing]
[2019-11-03 11:13:43.425] after SessionStep: STEPCMD_OK
[2019-11-03 11:13:43.425] before SessionStep: STEPCMD_STEP
[2019-11-03 11:13:43.425] after SessionStep: STEPCMD_PROGRESS
[2019-11-03 11:13:43.425] addressbook: normal sync done unsuccessfully
[2019-11-03 11:13:43.425] addressbook: fatal error (remote, status 500)
[2019-11-03 11:13:43.425] before SessionStep: STEPCMD_STEP
[2019-11-03 11:13:43.425] after SessionStep: STEPCMD_OK
[2019-11-03 11:13:43.425] before SessionStep: STEPCMD_STEP
[2019-11-03 11:13:43.425] Calling smlProcessData(NEXT_COMMAND)
[2019-11-03 11:13:43.425] Created command 'Status' (incoming)


After this sync is a slow sync - there I find

[2019-11-03 10:52:27.999] Compared [LOC=bUzWoqkqlB,REM=] with
[LOC=,REM=140] (eqMode=3), cmpres=0
[2019-11-03 10:52:27.999] TStdLogicDS::getMatchingItem, found
remoteID='140' is equal in content with localID='bUzWoqkqlB'
[2019-11-03 10:52:27.999] Slow Sync Match detected -
localID='bUzWoqkqlB' matches incoming item
[2019-11-03 10:52:27.999] Compared [LOC=,REM=140] with
[LOC=bUzWoqkqlB,REM=] (eqMode=5), cmpres=-1
[2019-11-03 10:52:27.999] Newer item determined: Server item is newer
and wins
[2019-11-03 10:52:27.999] Trying to merge some data from loosing client
item into winning server item
+
[2019-11-03 10:52:27.999] 'ScriptExecute' - Start executing Script,
name=mergescript [--][++] [->end] [->enclosing]
[2019-11-03 10:52:28.007] mergeWith() final status: thisitem: changed,
otheritem: changed (relevant; eqm_none field changes are not indicated)
[2019-11-03 10:52:28.007] addressbook: testState=TRUE - expected
state>='sync_mode_stable', found state=='sync_set_ready'
[2019-11-03 10:52:28.007] ModifyMap called: aEntryType=normal,
aLocalID='bUzWoqkqlB, aRemoteid='140', aMapflags=0x0, aDelete=0
[2019-11-03 10:52:28.007] - found entry by
entrytype/localID='bUzWoqkqlB' - remoteid='140', mapflags=0x0, changed=0,
deleted=1, added=0, markforresume=0, savedmark=0
[2019-11-03 10:52:28.007] - matching entry found - re-activating deleted
and/or updating contents if needed
[2019-11-03 10:52:28.007] Map entry updated: LocalID='bUzWoqkqlB',
RemoteID='140'
[2019-11-03 10:52:28.007] Server data was updated by record sent by
client, but server updates during non-firsttime slowsyncs are disabled
[2019-11-03 10:52:28.007] Record sent by client was updated, but client
updates during non-firsttime slowsyncs are disabled
[2019-11-03 10:52:28.007] Preventing localID='bUzWoqkqlB' to be sent to
client
[2019-11-03 10:52:28.007] Item with localID='bUzWoqkqlB' will NOT be
sent to client (slowsync match / duplicate prevention)

–[2019-11-03 10:52:28.007] End of 'Process_Item' [->top] [->enclosing]
–
[2019-11-03 10:52:28.007] 'issue' - issuing command, Cmd=Status [--][++]
[->end] [->enclosing]

[2019-11-03 10:52:28.007] Command 

Re: [SyncEvolution] Port to libecal-2.0 and libebook API changes

[deloptes]

Hi,
but shouldn't be somewhere there a libical version check?

On Thu, May 2, 2019 at 2:50 PM Milan Crha  wrote:

> On Wed, 2019-04-24 at 17:49 +0200, Milan Crha wrote:
> > There are going to be made huge libecal API changes...
>
> Hi,
> upstream libical received additional API changes in the libical-glib
> part, which touch also the previous patch. Even it's not released yet I
> prepared those new changes (attached).
> Bye,
> Milan
> ___
> SyncEvolution mailing list
> SyncEvolution@syncevolution.org
> https://lists.syncevolution.org/mailman/listinfo/syncevolution
>
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] Newer phones with syncml support

[deloptes]

Tino Mettler wrote:

> from my POV, SyncML also requires a "home service" to sync with.
> 
> Yes, setting up CalDAV/CardDAV requires some knowledge. I use DAViCal.
> It requires setting up a PostgreSQL database, adjusting the configuration
> for DAViCal and setting up user accounts using the DACiCal web frontend.
> However, it's not that hard at all, and could be streamlined with some
> effort.
> 
> At the end, you get features like shared calendars, auto-discovery of
> all addressbooks/calendars assigned to the users (via bindings), cheap
> background sync over HTTPS without manual interaction and compatibility
> with current smartphone operating systems. It's also a lot easier to
> keep multiple devices (more than two) in sync.
> 
> iOS comes with CalDAV/CardDAV support OOTB.  On Android, third party
> apps are required, as Google internally uses some sort of
> CalDAV/CardDAV but does not expose it to use it with your own server
> AFAICS.

Hi Tino,
thank you for sharing. My problems are that firstly I loose something that
was working good for so many years and is sufficient for my needs. Second I
do not want to access my home network via WLAN and last I do not want to
use WLAN on the phone all the time. You may add the lack of choice that is
gone as well.

But thanks anyway.

regards

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

Re: [SyncEvolution] Newer phones with syncml support

[deloptes]

Daniel CLEMENT wrote:

> Well, PMFJI, but I was in the process of upgrading to Debian 9 Stretch
> when this thread started (I was more or less forced to do that) and I'd
> like to add my own thanks to Patrick Ohly for this great piece of
> software (I wish I could contribute more).
> 
> My good old Nokia E72 is still going strong (and I store some spare). I
> hope I can use it until I retire...
> 

I hope the batteries of the spares will keep up with time as this is what is
making me think of saving SyncML somehow

> Greeting from yet another SyncML user

We'll be perhaps able to save it in Sailfish as there is code already from
MeeGo (which Patrick dislikes IMO), and Sailfish is pretty open in this
regards. However I have my issues with Sailfish and it is not certain they
will manage to survive long term.

regards


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

Re: [SyncEvolution] Newer phones with syncml support

[deloptes]

Patrick Ohly wrote:

> I consider SyncEvolution stable as it is and don't have plans to add
> features. I'll keep maintaining it as long as people use it - which I
> assume people still do (hard to tell with open source, in particular
> when users don't need to download it from syncevolution.org because it
> is in distros).
> 
> Maintenance basically means keeping the website and a build machine for
> testing and build around, should a new release become necessary. I was
> considering a new release a while back (okay, a year ago?) but it never
> became a priority and thus hasn't happened. Modernizing the code to a
> more recent C++ was the main potential change.

This sounds good. In an old fashioned way I wish may God bless you and give
you long live :)

So may be it is worth for us trying to save syncml in the Sailfish OS. The
quality from N9, if can be kept is sufficient for me and for sure for many
others.

Another option would be to use this synchronization interface in obexd, I
posted before - but I guess it would need much more work - time that we do
not have, I guess.

Thank you Patrick!

regards

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

Re: [SyncEvolution] Newer phones with syncml support

[deloptes]

Andrey Butirsky wrote:

> Hi,
> personally, I don't understand too why we have to give up that easily.
> 
> There is no real alternative indeed, and having to keep all the contacts
> in clear text on server at BB service, or organize "home services" for
> that is just a ridiculous..
> 
This is from my discussion on buteo

https://lists.sailfishos.org/pipermail/devel/2017-October/008070.html

I never found time to look further into this and Sailfish changed versions
in between, but I guess it should be still possible to do it and perhaps
I'll try when I find some time during this year.

Interesting to know what is the status of syncevolution and what Patrick is
planning to do with it in the future.

I think this is the only way left to keep this excellent software alive.

regards


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

Re: [SyncEvolution] Newer phones with syncml support

[deloptes]

Andrey Butirsky wrote:

> Do you mean WAN maybe?
WAN means wide area network - it is not for me - I mean WLAN (wireless local
area network) - the wireless router - it is infront of the firewall and I
have to reconfigure all of that to get from there into the intranet - note
intrAnet - not the internet.

regards


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

Re: [SyncEvolution] Newer phones with syncml support

[deloptes]

Andrey Butirsky wrote:

> Hi,
> personally, I don't understand too why we have to give up that easily.
> 
> There is no real alternative indeed, and having to keep all the contacts
> in clear text on server at BB service, or organize "home services" for
> that is just a ridiculous..

Yes my WLAN is disconnected from the intranet for good reason.

I read recently the specs of obexd that is under kernel custody and it says
there, that it supports synchronization -
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/obex-api.txt

Unfortunately I do not know (yet) if obex in Sailfish (kernel 3.10) supports
this, but it looks like if interface service is there, it could work.

I am also not sure what you can do to make phone OS manufacturers include
support for syncml or anything not WLAN dependent, otherwise I share your
opinion - we are left without choice, without alternative.

regards


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

Re: [SyncEvolution] Newer phones with syncml support

[deloptes]

deloptes wrote:

> Hi,
> 
> if this is still alive and someone is reading - do you know any recent
> phones that implement syncml. I need to replace the phone, but couldn't
> find out which newer one would support syncml. Nokia seems to have dropped
> it and for many phones there is no documentation. Android and iOS is a no
> go anyway.
> 
> thanks in advance

Ah good, good to know that you are still around. So basically we just
say "welcome to idiocracy".

I was thinking to resurrect buteo or whatever was supposed to run in MeeGo
and was obliterated in Sailfish. Then I was thinking to dump Sailfish as
they moved to bluez5 and can not make it to work with my car audio. Finally
the audio jack broke and I can not use it in the car by any means. I wanted
to go back to simple phone with bluez2,3 or 4, but found out that no one
implements SyncML anymore  so I ended up asking.
Thanks for frank answer. I still think that it was very good thing and I am
not sure if we have to give up that easy. I may look again at the buteo
code for Sailfish, but I have general problem with Sailfish in terms of
devices - Jolla somehow thinks they have to support always bigger and
bigger devices  no idea what to do. Perhaps I'll look for some
opensource solution for more simple phone ... chances not bigger. Window
seems to be closing again, where one could easily keep contacts in sync
without being big brothered.

thanks and regards

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

[SyncEvolution] Newer phones with syncml support

[deloptes]

Hi,

if this is still alive and someone is reading - do you know any recent
phones that implement syncml. I need to replace the phone, but couldn't
find out which newer one would support syncml. Nokia seems to have dropped
it and for many phones there is no documentation. Android and iOS is a no
go anyway.

thanks in advance

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

Re: [SyncEvolution] KDE5 support

[deloptes]

Tino Mettler wrote:

> I think this requires TDE packages in Debian, right?

Yes, TDE comes on top of debian as desktop from third party repo.
Sorry for jumping in OT here, I wanted to discuss the above anyway with you.

Preferably I would download debian src package, rebuild and install.
I think the problem were the dependencies so that I have to remove all
syncevolution and install the one compiled with tde plugins and set it on
hold. It would be nice if I could build the plugins as package and install
them on top of debians syncevolution, but I am really not sure if it would
work.
Perhaps it needs more brainstorming. 

regards




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

Re: [SyncEvolution] KDE5 support

[deloptes]

Tino Mettler wrote:

> at least I got a bug report in the past to provide a way to install
> syncevolution without Gnome, so I intruduced the syncevolution-libs-kde
> package.
> 
> So if anybody reading this wants to have that package available in
> Debian Buster, feel free to send patches.

I asked once if it would be possible to get optional syncevolution-libs-tde
(which would be the TDE - old KDE3). I already forgot what was the plan - I
think it was to use syncevolution source add our (TDE's) debian scripts,
but if it could go into the main source, it would be easier to maintain.

What's the deadline for Buster anyway?

thanks

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

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

[deloptes]

Patrick Ohly wrote:

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

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

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

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

It might be worth I try this next. 

regards

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

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

[deloptes]

Hi,

Patrick Ohly wrote:

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

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

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

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

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

It reminds me of Don Quixote :)

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

thanks and regards




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

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

[deloptes]

Hi thanks

Patrick Ohly wrote:

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

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

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

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

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

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

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

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

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

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

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

thanks and regards

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

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

[deloptes]

Patrick Ohly wrote:

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

Hi Patrick,

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

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

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

thanks and regards


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

[...]

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

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

[deloptes]

Patrick Ohly wrote:

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

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

According to last error message the error is thrown here

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

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

Synchronization failed

regards

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

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

[deloptes]

Patrick Ohly wrote:

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

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

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


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


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

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

[deloptes]

Patrick Ohly wrote:

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

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

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

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


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

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

thanks

regards

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

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

[deloptes]

I'm not sure I did all correctly

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

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



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

In GDB

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


Thanks in advance for taking your time

regards


On Tue, Sep 5, 2017 at 11:12 AM, Patrick Ohly <patrick.o...@intel.com>
wrote:

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

Re: [SyncEvolution] Sync on Debian Stretch

[deloptes]

Patrick Ohly wrote:

> So have you built 1.5.2 with libopenobex2 from Debian Stretch and it
> failed? With which phone?
> 

yes - built 1.5.2 with libopenobex2 from Debian Stretch.
phone is Nokia N9
I can't recall now but I think I tested also with older Nokia 5530
Desktop is Trinity - former KDE3

> I'm just asking for the sake of completeness. I probably won't have
> your exact phone either :-/
> 

sure

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

I may try test this next and post the output.

thanks and regards

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

Re: [SyncEvolution] Sync on Debian Stretch

[deloptes]

Patrick Ohly wrote:

> Have you gotten around to testing this combination?
> 
> I just tried with SyncEvolution master (= 1.5.2), libopenobex2 from
> Debian Stretch (= 1.7.2-1), and a Nokia N97 mini. No problem here.
> 
> FWIW, the binaries from syncevolution.org shouldn't be affected,
> because for the 1.5.2 release I had started linking libopenobex.a from
> Ubuntu Trusty directly into the binaries. That's of course not a
> solution for binaries compiled from source.

Hi
I have no Nokia N97 mini and for the Trinity Desktop I have to compile from
source.
I am not sure if you are asking me, but as it is posted in this thread, I
just assume it.
On top I use Debian Stretch - the problem reported originally is based on
it.

regards

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

Re: [SyncEvolution] Sync on Debian Stretch

[deloptes]

Patrick Ohly wrote:

> Thanks for root causing this.
> 
> Unfortunately I have no idea what changed in libopenobex. I also
> haven't written the code which uses it, so I'd be in for some amount of
> reverse-engineering before I might be able to fix it :-/

No prob. If you need input and testing let me know. I don't have any
idea/knowledge how I can test it. I'll just look into if 1.5.2 works with
libopenobex1. If so it will be much easier. 

As reported originally it dies with error "OBEX Request 3 got a failed
response Unknown response" etc.

I'm facing some issues with the kgpg app I use as things changed from gpg v1
in jessie to gpg v2 in stretch and as I have working syncevolution I'll be
chasing this next :/

Progress keeps us all busy.

regards

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

Re: [SyncEvolution] Sync on Debian Stretch

[deloptes]

Tino Mettler wrote:

> it was not meant as a permanent solution, but to help finding the root
> cause of the problem.

Thanks I will report when 1.5.2 testing done. 

regards


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

Re: [SyncEvolution] Sync on Debian Stretch

[deloptes]

Tino Mettler wrote:

> you could build libopenobex1 for Stretch and build Syncevolution from
> Stretch against libopenobex1 to see if it really makes a difference.

Hi Tino,
thanks for the response. My last msg (perhaps you did not see it) reported
exactly that. Because of lack of time, I build libopenobex1 on stretch and
syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf, which I new was
working. And indeed it worked.

I will try with 1.5.2 (from the debian sources) with libopenobex1. I think
this will work also, because it looks like the problem is coming from the
obex lib.

There is however a problem with libopenobex1 and perhaps I need to customize
the way it gets installed and the dependencies, because it conflicts with
libopenobex2 and drops all obex related apps like obexfs, which I am
interested in. So for now it is acceptable solution, but it needs to be
addressed for a permanent solution

Thanks and regards

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

Re: [SyncEvolution] Sync on Debian Stretch

[deloptes]

deloptes wrote:

> So could be the problem in libopenobex2?

syncevolution 1.5.1 with libopenobex1 works as before


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

[SyncEvolution] Sync on Debian Stretch

[deloptes]

Hi,

I got Debian Stretch on a new computer and tried SyncEvolution, but I am
getting an err message I can not deal with (see below).

As usual I'll be very thankful to you for any idea where to look at or what
I need to do to fix it.

To complete the picture I built and installed in custom dir from source on
jessie and I used debuild to build packages from 1.5.2_2 the debian source
on stretch. On jessie I have 1.5.1 as 1.5.2 failed because of libopenobex2
(AFAIR).
So could be the problem in libopenobex2?

regards

Before (on Jessie) I got this:

[2017-07-05 23:44:24.466] Connecting Bluetooth device with address
xx and channel 25
[2017-07-05 23:44:24.573] OBEX_EV_PROGRESS
[2017-07-05 23:44:24.573] ObexTransportAgent::wait(): iteration
[2017-07-05 23:44:25.167] OBEX_EV_REQDONE
[2017-07-05 23:44:25.167] OBEX Transport: get header who from connect
response with value SYNCML-SYNC
[2017-07-05 23:44:25.167] ObexTransportAgent::wait(): is ready
[2017-07-05 23:44:25.167] Server sending SAN
[2017-07-05 23:44:25.167] ObexTransport send is called (46 bytes)
[2017-07-05 23:44:25.167] OBEX_EV_PROGRESS
[2017-07-05 23:44:25.167] ObexTransportAgent::wait(reply)
[2017-07-05 23:44:25.167] ObexTransportAgent::wait(): iteration
[2017-07-05 23:44:25.199] OBEX_EV_REQDONE
[2017-07-05 23:44:25.199] ObexTransport send completed
[2017-07-05 23:44:25.199] ObexTransportAgent::wait(): is ready
[2017-07-05 23:44:25.199] OBEX_EV_PROGRESS
[2017-07-05 23:44:25.938] OBEX_EV_REQDONE
[2017-07-05 23:44:25.946] Module_DeleteContext 'session'
...
sync goes on

Now on Stretch I have this:

[2017-07-25 23:00:07.630] Connecting Bluetooth device with address
xx and channel 25
[2017-07-25 23:00:07.789] ObexTransportAgent::wait(): iteration
[2017-07-25 23:00:07.789] OBEX_EV_PROGRESS
[2017-07-25 23:00:07.789] ObexTransportAgent::wait(): iteration
[2017-07-25 23:00:08.271] OBEX_EV_REQDONE
[2017-07-25 23:00:08.272] OBEX Transport: get header who from connect
response with value SYNCML-SYNC
[2017-07-25 23:00:08.272] ObexTransportAgent::wait(): is ready
[2017-07-25 23:00:08.272] Server sending SAN
[2017-07-25 23:00:08.272] ObexTransport send is called (46 bytes)
[2017-07-25 23:00:08.272] ObexTransportAgent::wait(reply)
[2017-07-25 23:00:08.272] ObexTransportAgent::wait(): iteration
[2017-07-25 23:00:08.272] OBEX_EV_PROGRESS
[2017-07-25 23:00:08.272] ObexTransportAgent::wait(): iteration
[2017-07-25 23:00:08.304] OBEX_EV_REQDONE
[2017-07-25 23:00:08.304] ObexTransport send completed
[2017-07-25 23:00:08.304] ObexTransportAgent::wait(): is ready
[2017-07-25 23:00:08.304] OBEX_EV_PROGRESS
[2017-07-25 23:00:08.315] OBEX_EV_REQDONE
[2017-07-25 23:00:08.315] OBEX Request 3 got a failed response Unknown
response
[2017-07-25 23:00:08.316] Server Alerted Sync init with SANFormat 12 failed,
trying with legacy format
[2017-07-25 23:00:08.316] starting SAN 11 auth 1B2M2Y8AsgTpgAmY7PhCfg==
nonce SyncEvolution session 1 server PC Suite
[2017-07-25 23:00:08.316] SAN datastore addressbook uri Contacts type
text/x-vcard
[2017-07-25 23:00:08.316] SAN with overall sync mode 206

sync breaks here

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

Re: [SyncEvolution] strange problem with debian packages

[deloptes]

Tino Mettler wrote:

> instead of downgrading the libsynthesis dependency in the syncevolution
> package so that it installs in jessie, you should have just built a
> backport of libsynthesis for jessie.

Thanks Tino, this is my plan B. I've seen though other dependencies (AFAIR
obex1 vs obex2) ... we'll see.

Thank you guys for helping me.

regards

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

Re: [SyncEvolution] strange problem with debian packages

[deloptes]

Patrick Ohly wrote:

> strings /usr/lib/libsynthesis.so.0 | grep 'RELAXEDCOMPARE'

Patrick thank you!

So this might explain the issue because when compiling and deploying to
custom, I use the bundled synthesis and for debian package I use the one
provided by debian.
The one in jessie is 
ii  libsynthesis0:amd64   3.4.0.47.4-2+b1
but
strings /usr/lib/x86_64-linux-gnu/libsynthesis.so.0 | grep 'RELAXEDCOMPARE'
returns nothing.

I'll look into this direction. Thanks a lot!

regards

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

[SyncEvolution] strange problem with debian packages

[deloptes]

Hi,
I build debian packages from syncevolution-1.5.2 for the Trinity desktop.
However when I isntall the packages and try run a test sync I get following
error

SYNCEVOLUTION_DEBUG=3 syncevolution -r loglevel=6 nokia_N5530 addressbook
[DEBUG 00:00:00] SuspendFlags: (re)activating, currently inactive
[DEBUG 00:00:00] SuspendFlags: activating signal handler(s) with fds 8->7
[DEBUG 00:00:00] SuspendFlags: catch signal 2
[DEBUG 00:00:00] SuspendFlags: catch signal 15
Fatal: Undefined function 'RELAXEDCOMPARE' in script at line 58
Fatal error 20010, no valid configuration could be read from XML file
[ERROR 00:00:01] internal error, invalid XML configuration (without
datastores):

When I compile and install in a custom directory the same code works.
Do you have an idea where I had to look for the root cause?

Trinity is deployed in /opt/trinity, so this is my --prefix. Only dbus and
systemd related files are installed in the respective locations.

regards



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

Re: [SyncEvolution] [INFO] SoupTransport Failure

[deloptes]

Eric O'Connor wrote:

> ➤ syncevolution --sync two-way zoho-backend addressbook
> [INFO] calendar: inactive
> [INFO] memo: inactive
> [INFO] todo: inactive
> [INFO] Server sending SAN
> [ERROR syncevo-dbus-server] child process quit because of signal 11
> [ERROR] The connection is closed

SAN is server access notification
https://en.wikipedia.org/wiki/SyncML

I think your config is not good, but I have not idea how a carddav/caldav
setup should look like. sorry. I think you have to wait for someone more
experienced to assist, or go through the syncevolution guide again.

One is for sure, if you have a problem enable debugging. I run the syncs
usually so:
SYCNEVOLUTION_DEBUG=3 syncevolution -r loglevel=4 nokia_N9 addressbook
calendar+todo memo

Again big thanks to Patrik.

You can then find the logs in ~/.cache/syncevolution/

regards


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

Re: [SyncEvolution] [INFO] SoupTransport Failure

[deloptes]

Eric O'Connor wrote:

>> Which documentation did you follow to get started?
> 
> I'm going off of the man page for syncevolution.
> 
>> It takes two commands to set up CardDAV syncing: once for the target
> side (where CardDAV is used as storage) and once for the local side
> (with EDS, Akonadi or plain files as local storage).
> 
> How do you "link" the two? I now have a carddav config "remote", and an
> evolution config "local", but how do I run the "remote" <-> "local"
> combined config?
> 
> I think I need to do this manually, because I don't see a template for
> Evolution mail.
> 
> I don't understand where in the man page it tells me how to do that.
> 
> I now am getting:
> 
> ➤ syncevolution --run ev-local-addr
> ...
> [INFO] @default/addressbook: using configured database=zoho-backend
> [ERROR] sending message to child failed:
> org.syncevolution.gdbuscxx.Exception: 1483751134.3343.16@tara/addressbo
> ok: datastore not configured
> ...
> 
> with the configurations:
> 
> ➤ syncevolution --configure backend=carddav
> username='e...@oco.nnor.org' password='' syncURL='https://conta
> cts.zoho.com' zoho-backend addressbook
> ➤ syncevolution --configure syncURL='local://1483751134.3343.16@tara'
> database=zoho-backend peerIsClient=1 ev-local-addr addressbook
> 
> I don't understand why I would be getting this message, because I
> configure the evolution addressbook in the second line.
> 
> Thanks,
> Eric
> 
> 
> -Original Message-
> 
> Date: Mon, 09 Jan 2017 16:20:34 +0100
> Subject: Re: [SyncEvolution] [INFO] SoupTransport Failure
> Cc: syncevolution@syncevolution.org
> To: Eric O'Connor 
> From: Patrick Ohly 
> On Fri, 2017-01-06 at 19:30 -0700, Eric O'Connor wrote:
>> I'm using the same username/password as I use successfully on my
>> iPhone, and I can run the --print-items and get a list of vcf items.
>> 
>> 
>> $ syncevolution --configure syncURL='https://contacts.zoho.com/cardda
>> v/
>> e...@oco.nnor.org/default/' backend=carddav username='e...@oco.nnor.o
>> rg
>> ' password='' sync=slow database='1483751134.3343.16@tara'
>> eric-contacts9 addressbook
>> 
>> $ syncevolution --run eric-contacts9
>> ...
>> [INFO] SoupTransport Failure: https://contacts.zoho.com/carddav/eric@
>> oc
>> o.nnor.org/default/ via libsoup: Unauthorized
>> [INFO] Transport giving up after 0 retries and 0:00min
> 
> It takes two commands to set up CardDAV syncing: once for the target
> side (where CardDAV is used as storage) and once for the local side
> (with EDS, Akonadi or plain files as local storage).
> 
>> Perhaps one issue is that I don't really understand how syncevolution
>> works. I think I want to sync between my webdav "backend", and my
>> local
>> evolution "datastore", using the carddav "backend".
> 
> You need two datastores for that and thus two backends, not just one.
> 
>> I guess when I do --print-databases, I refer to them using the thing
>> in
>> between parenthesis?
>> 
>> What is SyncML? I just want to sync Caldav/Carddav. Do I need to
>> learn
>> about SyncML?
> 
> Not really - how SyncML works is an implementation detail. It's just
> the
> general concept (configure two sides, hook them up) which needs to be
> understood.
> 
> Which documentation did you follow to get started?
> 
> The README.rst explains the general concept in the "Synchronization
> beyond SyncML" section and "CalDAV and CardDAV" how to use that for
> CardDAV.
> 
> The same content is also on syncevolution.org together with specific
> HOWTO articles about other setups. Unfortunately the rendering there
> got
> broken in several places when moving to a new Drupal version. I'm not
> sure yet what to do about that - abandon Drupal, fix its setup (a bit
> out of my league), or fix each broken page - all not very attractive :-
> /
> 

I write this in the hope I can help, as it took me also a while to get a
working configuration with remote and local part. Luckilly Patrik Ohly was
so kind to help me out and for me it looks like following

echo "configure local source"
syncevolution --configure \
addressbook/backend=tdepim-contacts \
addressbook/database="xnCa15vsal" \
addressbook/databaseFormat="text/vcard" \
calendar/backend=tdepim-calendar \
calendar/database="kOBU23vG42" \
calendar/databaseFormat="text/calendar" \
todo/backend=tdepim-tasks \
todo/database="k44UWNvG42" \
todo/databaseFormat="text/calendar" \
  memo/backend=tdepim-notes \
  memo/database=tdenotes \
  memo/databaseFormat="text/plain" \
   @default addressbook calendar todo memo

echo "configure remote source"
syncevolution --configure \
   --template ${template} \
   peerIsClient=1 \
   dumpData=0 \
   printChanges=0 \
   syncURL=obex-bt://${deviceAddress} \
   calendar/uri="PC-SYNC" \
   

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Tino Mettler wrote:

> On Mon, Nov 21, 2016 at 08:00:33 +0100, deloptes wrote:
> 
> 
>> devices for me and the question is can be done something for SailFish and
>> what, so that I can use SyncEvolution with it via bluetooth. If you know
> 
> Hi,
> 
> is Bluetooth the only option for you? It looks like Sailfish can sync via
> CalDAV/CardDAV OOTB.
> 
Hi,
yes I would prefer bluetooth as I do not use wireless, or at least avoid
using it.
+ I don't have Cal/CardDav server setup. Can SyncEvolution offer Cal/CardDav
functionality as server? It could be interim solution.

regards


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

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Hi Patrick, Graham, all,

Patrick Ohly wrote:

> On Tue, 2016-11-15 at 23:04 +0100, deloptes wrote:
>> Patrick Ohly wrote:
>> > During all that time, SyncEvolution has had a functional SyncML
>> > implementation and backends for the PIM storage in MeeGo...
>> 
>> Here is what they said:
>> 
>> Sync via Bluetooth isn't well supported at the moment. We allow importing
>> contacts from another device, and adding capability to import calendars
>> via Bluetooth is work-in-progress (see
>> https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1
>> and MER#1222 for that), but true synchronisation via Bluetooth is
>> significantly more difficult to achieve with the current stack.
> 
> Reminds me of the discussions we had about comparing Bueto with
> SyncEvolution. SyncEvolution always had a strong focus on actually
> making syncing work (and yes, that gets ugly sometimes), while Buteo was
> a "cleanly designed" framework which avoided doing any of the hard work
> and delegated that to "plugins". In other words, it didn't actually
> solve the problems. Too late to say "told you so" now, there's literally
> no-one left from those discussions and it wouldn't matter anyway.
> 
>> I guess I have to wait, or get involved. I asked why not use
>> syncevolution? but still it would need a backend ... I don't know when
>> I'll be able to have a look into the sdk and mer
> 
> I don't know how much current PIM storage in SailFish OS has diverged
> from MeeGo; for MeeGo, kcalextended and qtcontacts were the relevant
> backends.
> 

the discussion is very interesting. However I am very pragmatic and I would
bring you back to the original topic. It should work at least for N=2
devices for me and the question is can be done something for SailFish and
what, so that I can use SyncEvolution with it via bluetooth. If you know
more than me, can you share or draft a plan what should be done.

Thanks

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

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Graham Cobb wrote:

> On 16/11/16 07:16, Patrick Ohly wrote:
>> Reminds me of the discussions we had about comparing Bueto with
>> SyncEvolution. SyncEvolution always had a strong focus on actually
>> making syncing work (and yes, that gets ugly sometimes), while Buteo was
>> a "cleanly designed" framework which avoided doing any of the hard work
>> and delegated that to "plugins". In other words, it didn't actually
>> solve the problems. Too late to say "told you so" now, there's literally
>> no-one left from those discussions and it wouldn't matter anyway.
> 
> Some of us who remember the discussions are still around! But we never
> understood the decisions anyway. I will admit that I have given up on
> syncing to my Jolla phone for now, even though it is my day-to-day phone.
> 
> If anyone has any ideas on how to actually make it work I would be happy
> to join in.

And another one http://neo900.org/ you never knew it existed

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

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Graham Cobb wrote:

> I am sure I used to have a version of SyncEvo on my Jolla, due to the
> kindness of someone on the list who built it. I seem to remember it
> worked sort of -- was it for calendar or contacts?  Anyway it stopped
> working (did Jolla change the underlying data store or something?  I
> can't remember). I haven't bothered recently and have never even looked
> for it to try to install on my Jolla C.
> 

I just got this phone last week, so no idea and ATM I am preoccupied, but I
am curious to see what the sdk and emulator can do.
I read that there was syncevolution 1.3 for jolla, but no confirmation that
it works, so now we know that it does not work anymore.

>> For the time being I read the only supported way is via Cal/CardDav ...
>> and people reported to be using own service ... which s*cks ...
> 
> I do sync with my personal owncloud instance so I have calendar and
> contacts in Cal/CardDav form.  I have not got around to trying the
> Sailfish Cal/CardDav support to see if it works with owncloud but plan
> to when I have time.
> 
doesn't syncevolution support a cal/carddav server ... or just a client?

regards

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

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Graham Cobb wrote:

> Oooh, a bit of a low blow :-)
> 
> I certainly learnt a lot from spending quite a lot of effort trying to
> make OpenSync work!  The main one (and the main reason I am here) is
> that sync is **really** hard to do in the general case.
> 
> Syncevolution does a great job on two-way sync but it would be really
> good to solve the multi-way problem one day :-) But that would require
> some significant work by a team who are willing to look at and learn
> from all the previous attempts. I sometimes wish Philippe Kahn had not
> lost interest in sync.

Hi Graham,
they confirmed it is not working on SailFish - who knows when they will
implement it and how it will be implemented ... given the comments
above ...
Perhaps we have to work closer with the Jolla team on it. Or ... get proper
SyncEvolution backend for SailFish.
I'm just wondering what happened to the MeeGo part and why it was not
adopted by SailFish ... but  anyway.
From what I learned with the whole backend exercise for TDE/KDE3, the best
is to do the work yourself ...

For the time being I read the only supported way is via Cal/CardDav ... and
people reported to be using own service ... which s*cks ...
I have put on the todo list to have a look into the SDK - no idea when, but
it is tempting

regards

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

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Patrick Ohly wrote:

> Huh? Then how did you sync between your N9 and the Sail Fish OS phone?
> Why does it advertise SyncML support via Bluetooth?
> 
> I thought Sail Fish OS had continued to use Buteo as its sync solution
> because that's what they got from MeeGo, and there was a SyncML
> implementation for that (most recent repo probably
> https://github.com/kavuri/buteo-syncml). If that's the code, then it has
> been "in progress" for several years now.
> 

I had the same impression.

> During all that time, SyncEvolution has had a functional SyncML
> implementation and backends for the PIM storage in MeeGo...

Here is what they said:

Sync via Bluetooth isn't well supported at the moment. We allow importing
contacts from another device, and adding capability to import calendars via
Bluetooth is work-in-progress (see
https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 and
MER#1222 for that), but true synchronisation via Bluetooth is significantly
more difficult to achieve with the current stack.

https://together.jolla.com/question/46789/when-can-we-get-pim-functionality-on-par-with-n9/?comment=151330#comment-151330

I guess I have to wait, or get involved. I asked why not use syncevolution?
but still it would need a backend ... I don't know when I'll be able to
have a look into the sdk and mer

regards

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

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

deloptes wrote:

> I'll try to find information how this version is supposed to work. Perhaps
> it is missing a service in the background.

Jolla/Sailfish OS does not have syncml implemented (yet). Work is in
progress, was the answer.

thanks and regards

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

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Patrick Ohly wrote:

>> This is what I did - it loops in ObexTransportAgent::wait(): iteration
>> for quite some time, but I guess I have to remove PC suite parameter and
>> who knows what I also have to modify.
> 
> That doesn't look good :-(
> 
> Is the phone still supported? Is it possible to see logs from the phone
> side or get someone to describe how the phone is supposed to be used for
> syncing via SyncML?
> 

Actually it is pretty new. After making sync possible with TDE and N9 I am
pretty happy, so now is the time to plan for the future. It is produced by
Intex and sold since earlier this year. I thought it will be a nice try
since the price is not that high.

I still don't know whos in charge on Jolla side ... but I was able to sync
the contacts from N9 to Intex Aqua Fish via bluetooth. I don't know how it
did it in the background

>> >> I tried phone-setup, but the python script dies with an error.
>> > 
>> > Which one?
>> > 
>> > The script hasn't been used much, I suspect. The only remaining phones
>> > with SyncML support were Nokia, and those typically all used the same
>> > settings.
>> 
>> syncevo-phone-config
>> 
>> syncevo-phone-config --bt-address
>> 94:XX:XX:XX:XX:8D --advanced --create-config=aquafish
>> Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data
>> and test results inside /tmp/syncevo-phone-config1_7yeN/cache
>> Starting test for 1188 configurations...
>> Start 1/1188 test
>> [DEBUG 00:00:00] checking password property 'databasePassword' in
>> datastore 'addressbook' of config 'test-phone' with user identity ''
>> [ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the
>> alias and pick a specific backend instead directly
> 
> That error comes from not knowing whether the Evolution or TDE backend
> is supposed to be used by the script. After a quick look at the script
> it seems that this cannot be specified. For you, the easiest solution
> probably is to disable the Evolution backends when compiling
> SyncEvolution.

these are the options I compiled with

--enable-maintainer-mode \
--enable-shared \
--enable-gui \
--enable-gtk=3 \
--enable-core \
--enable-bluetooth \
--enable-tdepimabc \
--enable-tdepimcal \
--enable-tdepimnotes \
--enable-tdewallet \
--enable-sqlite \
--enable-file \
--enable-dav \
--without-gio-gdbus \
--disable-ssl-certificate-check \
--disable-akonadi \
--disable-ebook \
--disable-ecal \
--disable-goa \
--disable-kcalextended \
--disable-kwallet \
--disable-maemocal \
--disable-oauth2 \
--disable-qtcontacts \
--disable-gsso \
--disable-uoa \
--disable-sign

I'll try to find information how this version is supposed to work. Perhaps
it is missing a service in the background.

regards

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

Re: [SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Patrick Ohly wrote:

>> How can I get a working template/config for the device
> 
> I would start with the Nokia template.
> 

This is what I did - it loops in ObexTransportAgent::wait(): iteration for
quite some time, but I guess I have to remove PC suite parameter and who
knows what I also have to modify.

>> I tried phone-setup, but the python script dies with an error.
> 
> Which one?
> 
> The script hasn't been used much, I suspect. The only remaining phones
> with SyncML support were Nokia, and those typically all used the same
> settings.

syncevo-phone-config

syncevo-phone-config --bt-address
94:XX:XX:XX:XX:8D --advanced --create-config=aquafish
Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data and
test results inside /tmp/syncevo-phone-config1_7yeN/cache
Starting test for 1188 configurations...
Start 1/1188 test
[DEBUG 00:00:00] checking password property 'databasePassword' in
datastore 'addressbook' of config 'test-phone' with user identity ''
[ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the
alias and pick a specific backend instead directly
Traceback (most recent call last):
  File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 728, in

main()
  File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 725, in
main
config.run()
  File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 557, in
run
(status, interrupt) = self.testWithCurrentConfiguration ()
  File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 438, in
testWithCurrentConfiguration
runCommand ("%s -c --template 'SyncEvolution Client' --sync-property
peerIsClient=1 %s" % (syncevoTest, configName))
  File "/home/emanoil/test-syncevo/bin/syncevo-phone-config", line 271, in
runCommand
raise Exception("%s: failed (return code %d)" % (cmd, result>>8))
Exception: XDG_CACHE_HOME=/tmp/syncevo-phone-config1_7yeN/cache
XDG_CONFIG_HOME=/tmp/syncevo-phone-config1_7yeN/config 
syncevolution --daemon=no -c --template 'SyncEvolution
Client' --sync-property peerIsClient=1 test-phone >/dev/null: failed
(return code 1)

I think there was a way to send the SAN or whatever command to get the
config ...

If you have time and help a bit, it would be great advantage for the whole
community

regards


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

[SyncEvolution] Sync with SailFish OS via Bluetooth

[deloptes]

Hi,
I am wondering if it is possible to sync Intex Aqua Fish with SailFish OS
via SyncEvolution.


sdp browse

Service Name: SyncML Client
Service RecHandle: 0x10008
Service Class ID List:
  UUID 128: 0002--1000-8000-0002ee02
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
Channel: 25
  "OBEX" (0x0008)
Profile Descriptor List:
  "" (0x0002--1000-8000-0002ee02)
Version: 0x0100

Service Name: SyncML Server
Service RecHandle: 0x10009
Service Class ID List:
  UUID 128: 0001--1000-8000-0002ee01
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
Channel: 26
  "OBEX" (0x0008)
Profile Descriptor List:
  "" (0x0001--1000-8000-0002ee01)
Version: 0x0100

How can I get a working template/config for the device

I tried phone-setup, but the python script dies with an error.
I read that someone was using syncevolution for arm - but the version there
mentioned (post from 2014 about Jolla phone) was 1.3.x

Thank in advance

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

Re: [SyncEvolution] Problem syncing with two profiles

[deloptes]

Patrick Ohly wrote:

> So switching between home and office triggers a slow sync? I wonder
> whether the phone sees different deviceIds for the SyncEvolution side in
> that case.
> 
> There are two settings in SyncEvolution for this. From a config for the
> Nokia N97:
> 
> # the identifier sent to the remote peer for a server initiated sync.
> # if not set, deviceId will be used instead
> remoteIdentifier = PC Suite
> 

Yes this is true. I use actually the Nokia_N900 template

> # The SyncML server gets this string and will use it to keep track of
> # changes that still need to be synchronized with this particular
> # client; it must be set to something unique (like the pseudo-random
> # string created automatically for new configurations) among all clients
> # accessing the same server.
> # myFUNAMBOL also requires that the string starts with sc-pim-
> # deviceId =
> 
> We do server initiated syncs with phones, so "PC Suite" is sent to the
> phone in the initial message. If I remember correctly, that had to be
> that fixed string, at least with some Nokia phones.
> 
> Note that there's no unique deviceId here, which means that different
> computers will all look alike to the phone, which then notices a
> mismatch of sync anchors when moving between computers and thus forces a
> slow sync.
> 
> Hrm, there's a nice fat TODO in src/syncevo/SyncContext.cpp about this:
> 
> if (m_serverMode) {
> // TODO: set the device ID for an OBEX server
> } else {
> substTag(xml, "fakedeviceid", getDevID());
> }
> 
> I don't remember why that if() check is there, and why
> SyncConfig::createPeerTemplate()'s
> config->setDevID(string("syncevolution-") + UUID()) is not used to set a
> unique deviceId when configuring phones.
> 
> Answering that would require some further code archeology and
> experimenting; not sure when I will have time for that. Perhaps you can
> check?
> 
> Here's an example of a sync with a SyncML server:
> 
>
http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_001_outgoing.xml
>
syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65syncevolut...@lists.intel.com
> 
> The server then replies with:
>
http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_002_incoming.xml
>
syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65syncevolut...@lists.intel.com
> http://www.plan44.ch/fsync_nightly
> 
> Perhaps that's the reason for the if() check: a HTTP server might
> require a different LocURI (?) than an OBEX server, and the code does
> not immediately know what it is (depends on the transport).

I don't see it in the sync via bluetooth. I see in the html log

device ID: syncevolution-33702b00-09b0-4a05-8eb0-4057b41667a6
device ID: syncevolution-5c646a89-d7bb-4338-b5b5-3e6f4eb6e1f9

In the xml I see only the Nokia/Phone ID


IMEI:/LocURI>



./devinf12



./contacts


I was also thinking that based on the device ID it might be deciding to
compare all items, which perhaps makes also sense. I'm not sure.

regards

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

Re: [SyncEvolution] Problem syncing with two profiles

[deloptes]

deloptes wrote:

> Patrick Ohly wrote:
> 
>> Sync with what? Mobile phone?
>> 
> 
> Yes! I use Nokia N9.
> 
 
>> There was a bug that affected some phones such that the sync itself
>> completed, but the OBEX connection was closed prematurely, causing some
>> phones to believe that an error occurred. But that should be fixed in
>> master.
> 
> Perhaps I use loglevel=10 ?
> 
> regards

FYI: I tried now without refresh-from-remote. I synced last time in the
office and now first time at home. It went into slow sync immediately with
following result. The next sync was normal.

[INFO] addressbook: slow sync done successfully
[INFO] calendar: slow sync done successfully
[INFO] memo: slow sync done successfully
[INFO] todo: slow sync done successfully

Synchronization successful.

Changes applied during synchronization:
+---|---|---|-CON-+
|   | LOCAL |REMOTE | FLI |
|Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---+-+-+-+-+-+-+-+-+-+
|   addressbook |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  7  |
|   slow, 0 KB sent by client, 403 KB received|
|   5 client item(s) discarded|
|   2 server item(s) discarded|
|   0 item(s) duplicated  |
|   211 item(s) matched   |
+---+-+-+-+-+-+-+-+-+-+
|  calendar |  6  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  3  |
|  slow, 2 KB sent by client, 39 KB received  |
|  1 client item(s) discarded |
|  2 server item(s) discarded |
|  0 item(s) duplicated   |
|  40 item(s) matched |
+---+-+-+-+-+-+-+-+-+-+
|  memo |  1  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
|  slow, 0 KB sent by client, 18 KB received  |
|  88 item(s) matched |
+---+-+-+-+-+-+-+-+-+-+
|  todo |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  1  |
|  slow, 0 KB sent by client, 0 KB received   |
|  0 client item(s) discarded |
|  1 server item(s) discarded |
|  0 item(s) duplicated   |
|  20 item(s) matched |
+---+-+-+-+-+-+-+-+-+-+
|   start Thu 10 Nov 2016 10:30:56 PM CET, duration 0:37min   |
|   synchronization completed successfully|
+---+-+-+-+-+-+-+-+-+-+
[ERROR] GLib: Source ID 4 was not found when attempting to remove it


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

Re: [SyncEvolution] Problem syncing with two profiles

[deloptes]

Patrick Ohly wrote:

> Sync with what? Mobile phone?
> 

Yes! I use Nokia N9.

>> My question is why it does slow sync in 2.2? What could be the reason?
> 
> This should only happen if something went wrong. The latest
> syncevolution-log.html should tell whether it was the local (=
> SyncEvolution) or the remote (= phone) side which decided to do a slow
> sync.
> 

I was using syncevolution-1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa

> Then one has to check whether the previous sync completed normally.
> 

The previous sync (refresh-from-remote) finished without error. I will
retest tomorrow and inspect the log more carefully but I did not see any
sign of problem

> There was a bug that affected some phones such that the sync itself
> completed, but the OBEX connection was closed prematurely, causing some
> phones to believe that an error occurred. But that should be fixed in
> master.

Perhaps I use loglevel=10 ?

regards




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

[SyncEvolution] Problem syncing with two profiles

[deloptes]

Hi,
sorry to bother again, but I observed an issue performing following use
case:

1. Sync at home with my user profile A (it says normal sync)
2. Sync in the office with my user profile B
2.1 do refresh-from-remote
2.2 do a sync after some time (it says slow sync)

My question is why it does slow sync in 2.2? What could be the reason?

Thanks

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

Re: [SyncEvolution] Building a debian package for the backend

[deloptes]

Tino Mettler wrote:

> On Mon, Nov 07, 2016 at 00:13:51 +0100, deloptes wrote:
>> Hi,
>> perhaps this question should be addressed to Tino.
>> 
>> I am wondering how I can build the TDE backend in a debian package.
>> Is it possible to build and distribute this package only?
> 
> Hi,
> 


Hi and thank you for coming back to me on this subject.
Let me explain what I need, because I am not sure that I understand
correctly your answer.

We have the deb packages build and offered recently, but we don't have the
TDE packages( pim + wallet ). Who's suppose to build them together with the
other packages?
I don't think I can or should rebuild all packages for trinity desktop just
to have support for two extra backends.

> just add a TDE package for the backend libs, as already done for Gnome
> and KDE. Builing only the TDE libs package won't be that easy, but it's
> also somewhat pointless I think as you need the internal libs that are
> create during build.
> 

Do you mean add to Debian/RH etc the file to build the packages? Not sure
what you mean.

I mean I can use the source to build syncevolution with tdepim and
tdewallet, but I can not afford it to build all other packages (that are
already build anyway like activesync or evolution)

And what I am missing is the debian directory for the new 1.5.2. Where can
this be found (for jessie,testing and sid)

thanks



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

[SyncEvolution] Building a debian package for the backend

[deloptes]

Hi,
perhaps this question should be addressed to Tino.

I am wondering how I can build the TDE backend in a debian package.
Is it possible to build and distribute this package only?

It is regarding a long term plan to provide TDE ready to install packages. I
think RH and Deb are mostly used.

Thanks in advance

regards

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

Re: [SyncEvolution] Release preparations for 1.5.2

[deloptes]

Patrick Ohly wrote:

> Thanks. I've merged the patches and will prepare a final release
> candidate now. The nightly build machine needs to go through some
> maintenance soon, so I might have to finish 1.5.2 this weekend.
> 
> In the future, can you commit the changes in your local git repo with a
> suitable commit message and then export them with "git format-patch"?
> Alternatively I could also revive the github mirror of the repos and you
> could do a pull request.

Thank you, Patrick! I will love to do so in the future. I used git diff to
create the patches.

Thanks a lot for the valuable help. I can't stop telling this :)

regards

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

Re: [SyncEvolution] Release preparations for 1.5.2

[deloptes]

Patrick Ohly wrote:

> On Thu, 2016-09-29 at 14:45 +0200, Patrick Ohly wrote:
>> I've finished preparing source code and binaries for a 1.5.2 release of
>> SyncEvolution. The source code has not been tagged yet, only the master
>> branches of syncevolution, libsynthesis and activesyncd were updated.
>> activesyncd continues to receive some SyncEvolution specific patches
>> (the "folder sync hacks" from Graham) which are not upstream.
>> 
>> The binaries are available in the "experimental" apt repo
>> (http://downloads.syncevolution.org/apt/ with "experimental" as release
>> name) or as individual .tar.gz files in
>> http://downloads.syncevolution.org/syncevolution. Look for version
>>1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa
> 
> I've update the "experimental" and "unstable" repo and published
> versions 1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf (SyncEvolution) and
> 0.92+20161014+SE+8918ba1 (activesyncd).
> 
> If you pull from "experimental", then please replace with "unstable":
> the idea is that only I update from "experimental" and that "unstable"
> will get the same update after some sanity checking. I didn't follow
> that when announcing the version above, so if you now follow
> "experimental", then please replace by "unstable".
> 
> Graham, the new update should fix the problems you had with libical and
> GSetting schemas in activesyncd. I still haven't re-enabled testing of
> ActiveSync myself, though.
> 
> deloptes, your TDE backends are included, albeit with some changes to
> make them compile when disabled. Please check that this works as
> intended for you.
> 

No functional issues on tdepim backend found. Tested with Nokia N9 and Nokia
5530

regards

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

Re: [SyncEvolution] Release preparations for 1.5.2

[deloptes]

I splitted both (tde and tdepim)

tde.patch is to prevent the wallet backend from crashing syncevolution when
enabled. Again tdewallet backend is not tested by any means as I am not
using it.

tdepim.patch is to make the notes backend build.

Unfortunately I was still not able to perform an e2e test with this version.
I am looking forward to do it next. Again I do not expect any functional
issues as I am using the code from the previous version on daily bases.

I hope this helps
regards




diff --git a/tmp/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tde/TDEPlatform.cpp b/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tde/TDEPlatform.cpp
index d262f57..bf459b1 100644
--- a/tmp/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tde/TDEPlatform.cpp
+++ b/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tde/TDEPlatform.cpp
@@ -37,12 +37,13 @@
 #include 
 #include 
 
+
+#include 
+#include 
 #include 
 #include 
 #include 
 
-#include 
-
 #include 
 SE_BEGIN_CXX
 
@@ -51,22 +52,18 @@ SE_BEGIN_CXX
 
 void TDEInitMainSlot(const char *appname)
 {
-	
-	int argc = 1;
-	static char *argv[] = { const_cast(appname), NULL };
 
-	TDEAboutData aboutData( "syncevotdewlt", // internal program name
-		"SyncEvolution-TDEPIM-plugin",  // displayable program name.
-		"0.1",   // version string
-		"SyncEvolution TDEPIM plugin",// short porgram description
-		TDEAboutData::License_GPL, // license type
-		"(c) 2016, emanoil.kot...@fincom.at" // copyright statement
-	);
+	//connect to dcop
+	DCOPClient *kn_dcop = TDEApplication::kApplication()->dcopClient();
+	if (!kn_dcop)
+		Exception::throwError(SE_HERE, "internal init error, unable to make new dcop instance for tdenotes");
 
-	TDECmdLineArgs::init(argc, argv, );
-	
-	TDEApplication syncevotdewallet( "syncevolution-tdewallet" );
-	syncevotdewlt.dcopClient()->registerAs(syncevotdewallet.name());
+	TQString appId = kn_dcop->registerAs("syncevolution-tdewallet");
+
+/*	SyncSourceLogging::init(InitList("SUMMARY") + "LOCATION",
+" ",
+m_operations);
+*/
 	
 }
 
@@ -125,7 +122,8 @@ bool TDEWalletLoadPasswordSlot(const InitStateTri ,
 		TQString(key.authtype.c_str())+','+
 		TQString::number(key.port);
 	
-	TQString wallet_name = TDEWallet::Wallet::NetworkWallet();
+//	TQString wallet_name = TDEWallet::Wallet::NetworkWallet();
+	TQString wallet_name = TDEWallet::Wallet::LocalWallet();
 	
 	const TQString folder("Syncevolution");
 	

diff --git a/tmp/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tdepim/TDEPIMNotesSource.h b/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tdepim/TDEPIMNotesSource.h
index 3276924..632a89d 100644
--- a/tmp/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tdepim/TDEPIMNotesSource.h
+++ b/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tdepim/TDEPIMNotesSource.h
@@ -27,13 +27,13 @@
 #include "config.h"
 
 #include 
-SE_BEGIN_CXX
 
 #ifdef ENABLE_TDEPIMNOTES
 
 #include "KNotesIface_stub.h"
 #include 
 
+SE_BEGIN_CXX
 /**
  * Implements access to TDE memo lists (stored as knotes items),
  * exporting/importing the memos in plain UTF-8 text. 

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

Re: [SyncEvolution] Release preparations for 1.5.2

[deloptes]

Patrick Ohly wrote:

> deloptes, your TDE backends are included, albeit with some changes to
> make them compile when disabled. Please check that this works as
> intended for you.

Two minor problems. After applying the changes (see attached patch) it
builds fine. I do not expect functional issues, but I'll test tomorrow and
report back if any.
The TDE wallet backend is not tested. in fact it crashes syncevolution when
build. Perhaps we should either mention this or remove it for the time
being. I am just not able to do some meaningful testing on it ATM. I let
you decide what is the best to do.

regards
diff --git a/tmp/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tde/TDEPlatform.cpp b/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tde/TDEPlatform.cpp
index d262f57..c34cb40 100644
--- a/tmp/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tde/TDEPlatform.cpp
+++ b/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tde/TDEPlatform.cpp
@@ -66,7 +66,7 @@ void TDEInitMainSlot(const char *appname)
 	TDECmdLineArgs::init(argc, argv, );
 	
 	TDEApplication syncevotdewallet( "syncevolution-tdewallet" );
-	syncevotdewlt.dcopClient()->registerAs(syncevotdewallet.name());
+	syncevotdewallet.dcopClient()->registerAs(syncevotdewallet.name());
 	
 }
 
diff --git a/tmp/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tdepim/TDEPIMNotesSource.h b/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tdepim/TDEPIMNotesSource.h
index 3276924..632a89d 100644
--- a/tmp/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tdepim/TDEPIMNotesSource.h
+++ b/syncevolution-1.5.1+20161014+SE+46a81a3+SYSYNC+7c9a4bf/src/backends/tdepim/TDEPIMNotesSource.h
@@ -27,13 +27,13 @@
 #include "config.h"
 
 #include 
-SE_BEGIN_CXX
 
 #ifdef ENABLE_TDEPIMNOTES
 
 #include "KNotesIface_stub.h"
 #include 
 
+SE_BEGIN_CXX
 /**
  * Implements access to TDE memo lists (stored as knotes items),
  * exporting/importing the memos in plain UTF-8 text. 

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

Re: [SyncEvolution] Release preparations for 1.5.2

[deloptes]

Patrick Ohly wrote:

> deloptes, your TDE backends are included, albeit with some changes to
> make them compile when disabled. Please check that this works as
> intended for you.

Hi Patrick,
I let it compile yesterday on a test vm and got following error

src/backends/tde/TDEPlatform.cpp: In function 'void
SyncEvo::TDEInitMainSlot(const char*)':
src/backends/tde/TDEPlatform.cpp:69:2: error: 'syncevotdewlt' was not
declared in this scope
  syncevotdewlt.dcopClient()->registerAs(syncevotdewallet.name());
  ^
Makefile:8046: recipe for
target 'src/backends/tde/src_backends_tde_platformtde_la-TDEPlatform.lo'
failed

I am not able to look into it now - perhaps in the evening.

Can I rebuild the debian package out of the source somehow  this would be
really great? I think this would be the next step for me.

regards

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

Re: [SyncEvolution] [SOLVED] Explicit type 'text/x-vcalendar' specified in command or item meta

[deloptes]

The problem is solved by the agreed solution.
The second problem with the escaped ',' and '\n' also solved (it was
introduced at my end while trying to resolve the former issue).

Thanks and regards

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

Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[deloptes]

Patrick Ohly wrote:

> I don't like magic - at least not in software engineering ;-}
> 
> So let's try to understand this a bit better. Compared to my proposed
> patch, you added "p=nextunfolded(p,aMimeMode,true)" before the
> "continue".
> 
> Without it, we enter the next loop iteration:
> 
> c=*p; // c should be = now

Yes exactly.

> if (isEndOfLineOrText(c) || (!escaped && aStructSep!=0 && (c==aStructSep
> || c==aAltSep))) break; // We haven't changed any of these, so it should
> continue. escaped=(!escaped) && (c=='\\'); // No change either. if
> (c=='=') { s=nextunfolded(p,aMimeMode,true); // Hmm, not quite the same...
> 

yes this is testing from position of p forward, without modifying p.

> Okay, I think I understand. The loop expects to start after skipping
> over line folding, so when we enter it pointing towards the soft line
> break =, it does the wrong thing. The additional nextunfolded() avoids
> that.

Yes this is also my understanding of that.

The last problem I have with all of that is double escaped '\n' and ','.

I'll try to find out where exactly it does this. It might be in the sysync
parser, but also in libkcal.

Thanks for the help.

regards

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

Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[deloptes]

Patrick Ohly wrote:

> +        // The Nokia N9 vCalendar implementation sends ==0A=0D= at the
> end of +        // the line when it should send just the =. Apparently the
> CRLF octets +        // get inserted before quoted-printable encoding and
> then get encoded. +        // Such a sequence is invalid because = cannot
> be used literally +        // and must be followed by characters
> representing the hex value, +        // i.e. == is already invalid.
> +        //
> +        // We must skip over the entire sequence and continue at the last
> +        // = in ==0A=0D=, otherwise the code below would insert
> additional +        // characters into the decoded text.

This seems to magically work

@@ -1937,6 +1938,23 @@ static void decodeValue(
 uInt16 code;
 const char *s;
 char hex[2];
+
+   // The Nokia N9 vCalendar implementation sends ==0D=0A= at the end
of
+   // the line when it should send just the =. Apparently the CRLF
octets
+   // get inserted before quoted-printable encoding and then get
encoded.
+   // Such a sequence is invalid because = cannot be used literally
+   // and must be followed by characters representing the hex value,
+   // i.e. == is already invalid.
+   //
+   // We must skip over the entire sequence and continue at the last
+   // = in ==0D=0A=, otherwise the code below would insert additional
+   // characters into the decoded text.
+if (strncmp(p,"==0D=0A=",8)==0) {
+  p += strlen("==0D=0A")-1;
+  // put the cursor at the next useful =
+  p=nextunfolded(p,aMimeMode,true);
+  continue;
+}
 s=nextunfolded(p,aMimeMode,true);
 if (*s==0) break; // end of string
 hex[0]=*s; // first digit



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

Re: [SyncEvolution] Release preparations for 1.5.2

[deloptes]

Tino Mettler wrote:

> "3.4.0.47.5+syncevolution-1.5.1-2" might scare off some people.

I would skip "syncevolution" and go for "3.4.0.47.5+1.5.1-2"
It's just a convention, so important is, that it's written somewhere what it
means.

regards

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

Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[deloptes]

Thank you for the extended explanations in your reply.

Patrick Ohly wrote:

[old content removed for visibility]

> 
>> Alternatively can we enforce text/calendar instead of text/x-vcalendar?
>> I tried setting this in the ini file
>> .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini
>> but the engine refused with error.
> 
> Was it a local error or did it occur after contacting the phone?
> Probably the latter.
> 

I think it was a 10500 error.

>> I am not even sure that this is OK to
>> modify the file and expect to work.
> 
> The Synthesis engine is able to exchange data in different formats and
> the configuration options control that aspect. However, the peer it
> talks to must support the same formats, which is not possible in this
> case: in it's DevInf, the N9 only reports "type=text/x-vcalendar,
> version=1.0" for its ./calendar data store.
> 
> The expected error then is something about "no common format" (not sure
> what the wording is).
> 

So once again, please confirm. The configured "type=text/x-vcalendar" in 
.config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini
does not enforce the phone to respond, rather it is based on the
capability - correct?

>> However if you compare both approaches versit vs.
>> sysync, i would have preferred to have the versit code as a base line.
>> Anyway talking about this leads to nothing. We could only try to correct
>> the problems we face.
> 
> Agreed.
> 
>> > And one more point: the N9 uses KCalExtended (or something derived from
>> > it, I lost track of the official name) as calendar storage, which
>> > probably uses the same code that you present as the better alternative.
>> > Isn't that the code then which sends the data with a broken encoding?
>> > 
>> 
>> Yes I think so and this leads me to the question if it is possible to
>> enforce text/calendar (iCal) and not as it is per default in the
>> Nokia_N900 template text/x-vcalendar (vCal).
>> If this is doable I can understand why only I complain, besides the fact
>> that I use English/German/Bulgarian/Russian and my wife Italian.
> 
> It's also possible that N9/N900 users never used the direct syncing of
> calendar data over Bluetooth. I think using SyncEvolution on the phone
> to sync with some CalDAV server was more popular.
> 
> vCalendar is a very limited format and only poorly supports modern
> concepts (meeting series, exceptions, time zones). Shoehorning iCalendar
> 2.0 data into vCalendar 1.0 is problematic.
> 

It looks to me that indeed it only supports "type=text/x-vcalendar",
although I would expect text/calendar by KCalExtended. I think I have
somewhere sources - I'll try to dig a bit.

>> Another option would be to set up some cleanup before passing the data to
>> the parser. This would be a simple rule replacing ==0D=0A= with a simple
>> =. I have never had a chance to look into the scripting options offered
>> by syncevolution - is it thinkable/doable?
> 
> This might indeed be the best option. Let me check this in more detail.
> 

I thought it might be added by sysync after opening the wbxml or whatever.
But if you say it is unmodified as sent by the phone, I'll buy it.
I have not looked into the scripting options before/after etc., but it looks
like an option for a work around.

>> Sorry for bothering that much about it. I just have a feeling there is a
>> spell over my attempt to sync in the past 10 years, first with opensync
>> and now with Syncevolution, I always hit the wall in some way.
> 
> I won't comment on OpenSync here. You probably know already why it
> didn't work for you and in what state the project has been since they
> dropped MultiSync and tried again.
> 
> Regarding SyncEvolution: you missed the time when it was under much more
> active development. Intel really helped move the project along for a
> while (additional developers, QA) and still does to a limited extend
> (hosting, a little bit of my time), but mostly the project is now in
> maintenance.
> 

Since we discussed the topic in 2011, I was dragged in a couple of big
projects ... also a big private project called family+child took place :)
It also became clear that I will not use the newer KDE and I was hoping that
someone else will do the "dirty" work and write the plugins for TDE/KDE3 :)

Anyway, I don't know what interest Intel or Canonical have in this project.
It looks like a very good work so far and I hope whoever works on this
further will maintain this level. Even this parser seem to work well if it
gets the right data, no matter how ugly it looks. 

Last but not least, you are also really nice and helpful.

Thanks

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

Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[deloptes]

Patrick Ohly wrote:

[old content removed for visibility]
> 
> If I understand this right (disclaimer: I'm not intimately familiar with
> the specs anymore, and have had no time to read up on them), it is the
> phone which is sending bogus data, right?
> 
> Your explanation in https://bugs.freedesktop.org/show_bug.cgi?id=98019
> shows the broken data after "Parsing", which is the raw data as sent by
> the phone.
> 
> Perhaps it is indeed specific to your phone? Not sure about other N9
> owners.
> 

I am not sure about it. How can I see what is in the message coming from the
phone? Is syncevolution-log_trm002_003_incoming.xml (attached to the log)
the internal message or the one sent by the phone?
Alternatively can we enforce text/calendar instead of text/x-vcalendar?
I tried setting this in the ini file
.config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini
but the engine refused with error. I am not even sure that this is OK to
modify the file and expect to work.


>> I was expecting to find something like the versit parser, which I think
>> is really nice in KDE3/TDE[1], but I found here something self written,
>> not based on grammar ... and giving me a lot of headache.
>> Very very sad story!
> 
> Before you get worked up too much about this: remember that this parser
> has to support plenty of different formats (not just the modern
> revisions of the standard with sane rules for encoding, but also old
> ones, like vCalendar, which are terribly inconsistent), and data from
> peers which don't follow the standard. Having to support such a mess is
> not leading to nice code.
> 

Yes, I understand this! However if you compare both approaches versit vs.
sysync, i would have preferred to have the versit code as a base line.
Anyway talking about this leads to nothing. We could only try to correct
the problems we face.

> And one more point: the N9 uses KCalExtended (or something derived from
> it, I lost track of the official name) as calendar storage, which
> probably uses the same code that you present as the better alternative.
> Isn't that the code then which sends the data with a broken encoding?
> 

Yes I think so and this leads me to the question if it is possible to
enforce text/calendar (iCal) and not as it is per default in the Nokia_N900
template text/x-vcalendar (vCal).
If this is doable I can understand why only I complain, besides the fact
that I use English/German/Bulgarian/Russian and my wife Italian.

Another option would be to set up some cleanup before passing the data to
the parser. This would be a simple rule replacing ==0D=0A= with a simple =.
I have never had a chance to look into the scripting options offered by
syncevolution - is it thinkable/doable?

>> The diff is the closest I could get to make it work acceptable for me -
>> it at least does not mangles the text.
>> 
>> [1] https://git.trinitydesktop.org/cgit/tdepim/tree/libkcal/versit
>> 
>> I hope it helps come to some solution.
> 
> I fear I need to sit down and study this more before I can do anything
> about this. Please don't hold your breath.
> 

No, it is just a reference. You have the RFC, the yacc grammar and the
parser code. You can just go through the readme to get an idea. If this was
the base for the sysync parser, things would be much easier.

Sorry for bothering that much about it. I just have a feeling there is a
spell over my attempt to sync in the past 10 years, first with opensync and
now with Syncevolution, I always hit the wall in some way.
I now changed the code as posted in the diff, to at least have some readable
text, however I noticed that ',' is displayed as '\,' and new line chars
are also double escaped, but I don't want to dig into it right now.
I understand that this is not the correct way or place to handle this, so
this diff is not a patch, but to show where it breaks.

And thank you for the good help so far.

regards

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

Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[deloptes]

Patrick Ohly wrote:

> On Tue, 2016-09-27 at 08:57 +0200, deloptes wrote:
>> Patrick Ohly wrote:
>> 
>> > On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote:
>> 
>> >> 
>> >> Hi,
>> >> I hope you have not forgotten about this problem. Please look into my
>> >> last message and let me know if I can do something more. If it is the
>> >> same issue as the TDE/libkcal one, the fix should be really simple.
>> > 
>> > There was a misunderstanding: I need you to re-run the sync as
>> > explained above (loglevel=4 as command line parameter), and *then* the
>> > resulting log html file will have more information. The one you sent
>> > doesn't include information about the detailed item conversion.
>> > 
>> 
>> Might be my bad - sorry.
>> 
>> Here
>> [2016-09-27 08:51:45.496] Created new item of datatype 'vCalendar10',
>> localID='' remoteID='526'
>> 
>>
DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=D0=A2=D0=B5=D1=81=D1=82
>> =D0=B4=D1=8A=D0=BB=D0=B3=D0=BE =D0=BE=D0=BF=D0==0D=0A=
>> =B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B7=D0=B0
>> =D0=B7=D0=B0=D0=B4=D0=B0==0D=0A=
>> 
>> Note ==0D=0A=
>> 
>> It is also visible in syncevolution-log_trm002_003_incoming.xml
> 
> Sorry, I'm still confused about what the actual, unmodified incoming
> data is. Can you attach the entire log file?
> 
> I doubt that I will have time to fix this, but at least I should be able
> to reproduce it and point you into the right direction in the code.
> 


Looking into the synthesis quoted-printable parser  it's really a
brainf**k. I'm just wondering if I am the only one on this planet to have
such issues doing a sync with UTF-8 encoded text.

I was expecting to find something like the versit parser, which I think is
really nice in KDE3/TDE[1], but I found here something self written, not
based on grammar ... and giving me a lot of headache.
Very very sad story!

The diff is the closest I could get to make it work acceptable for me - it
at least does not mangles the text.

[1] https://git.trinitydesktop.org/cgit/tdepim/tree/libkcal/versit

I hope it helps come to some solution.

regards


--- syncevolution-1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa/src/synthesis/src/sysync/mimedirprofile.cpp	2016-09-20 13:47:49.0 +0200
+++ ../syncevolution-1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa/src/synthesis/src/sysync/mimedirprofile.cpp	2016-10-02 00:21:19.632479707 +0200
@@ -1939,6 +1939,7 @@
 char hex[2];
 s=nextunfolded(p,aMimeMode,true);
 if (*s==0) break; // end of string
+if (*s=='=') { p=s; continue; } // EKO workarround ==0D=0A=
 hex[0]=*s; // first digit
 s=nextunfolded(s,aMimeMode,true);
 if (*s==0) break; // end of string
@@ -1947,12 +1948,14 @@
   p=s; // continue with next char after second digit
   c=code; // decoded char
   if (c=='\x0D') {
-c='\n'; // convert to newline
+//c='\n'; // convert to newline - EKO: this creates a lot of mess
+p = nextunfolded(p,aMimeMode,true); // move forward
 lastWasQPCR = true; // remember
+continue; // EKO: start new iteration
   }
-  else if (c=='\x0A') {
+  if (c=='\x0A') {
 if (lastWasQPCR) {
-  // if last was CR, ignore LF (CR already has generated a newline)
+  // if last was CR, ignore LF (newline will be generated below)
   p = nextunfolded(p,aMimeMode,true); // but skip it for now.
   lastWasQPCR = false;
   continue; // ignore LF
@@ -1960,8 +1963,8 @@
 // LF not preceeded by CR is a newline
 c='\n'; // convert to newline
   }
-  else {
-// neither CR nor LF
+  if (lastWasQPCR) {
+c='\n'; // EKO: take care of CR on mac or similar
 lastWasQPCR = false;
   }
 }

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

Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[deloptes]

Patrick Ohly wrote:

> On Tue, 2016-09-27 at 08:57 +0200, deloptes wrote:
>> Patrick Ohly wrote:
>> 
>> > On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote:
>> 
>> >> 
>> >> Hi,
>> >> I hope you have not forgotten about this problem. Please look into my
>> >> last message and let me know if I can do something more. If it is the
>> >> same issue as the TDE/libkcal one, the fix should be really simple.
>> > 
>> > There was a misunderstanding: I need you to re-run the sync as
>> > explained above (loglevel=4 as command line parameter), and *then* the
>> > resulting log html file will have more information. The one you sent
>> > doesn't include information about the detailed item conversion.
>> > 
>> 
>> Might be my bad - sorry.
>> 
>> Here
>> [2016-09-27 08:51:45.496] Created new item of datatype 'vCalendar10',
>> localID='' remoteID='526'
>> 
>>
DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=D0=A2=D0=B5=D1=81=D1=82
>> =D0=B4=D1=8A=D0=BB=D0=B3=D0=BE =D0=BE=D0=BF=D0==0D=0A=
>> =B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B7=D0=B0
>> =D0=B7=D0=B0=D0=B4=D0=B0==0D=0A=
>> 
>> Note ==0D=0A=
>> 
>> It is also visible in syncevolution-log_trm002_003_incoming.xml
> 
> Sorry, I'm still confused about what the actual, unmodified incoming
> data is. Can you attach the entire log file?
> 
> I doubt that I will have time to fix this, but at least I should be able
> to reproduce it and point you into the right direction in the code.
> 

I am not sure how to get the raw message that comes from the phone. It might
be specific to N9 and Cyrillic UTF8

I tracked the issue down to  src/synthesis/src/sysync/mimedirprofile.cpp

static void decodeValue

I add a look ahead for the case '=' followed by '=' and '0D', which solves
the problem.

I still have a problem with new lines '\n'. The '\' is escaped and I see it
in the text, so from
aasdföä\nTest
it does
aasdföä\\nTest

I'm not sure if it is the right place to do it as those =0D=0A are scattered
all over the place.

According specs "quoted-printable" line ends with '=\r\n' in my case we
see '=' left over '\r\n' converted into '=0D=0A' and '=' added. I guess
simple '\n' terminates the line.

Is it possible that '\r\n' is converted into '=0D=0A=' before decodeValue is
called?

I think this is an odd bug, but I'm not sure how to proceed with it

thanks

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

Re: [SyncEvolution] Release preparations for 1.5.2

[deloptes]

Patrick Ohly wrote:

> On Thu, 2016-09-29 at 23:50 +0200, deloptes wrote:
>> Patrick Ohly wrote:
>> 
>> > The binaries are available in the "experimental" apt repo
>> > (http://downloads.syncevolution.org/apt/ with "experimental" as release
>> > name) or as individual .tar.gz files in
>> > http://downloads.syncevolution.org/syncevolution. Look for version
>> > 1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa
>> 
>> downloaded the source, added my backends but nothing builds.
> 
> Did you run "./autogen.sh"?
> 
> Adding your source is on the TODO list for the release.
> 

OK, I am stupid :)

thanks - running autogen.sh included the backends.


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

Re: [SyncEvolution] Release preparations for 1.5.2

[deloptes]

Patrick Ohly wrote:

> The binaries are available in the "experimental" apt repo
> (http://downloads.syncevolution.org/apt/ with "experimental" as release
> name) or as individual .tar.gz files in
> http://downloads.syncevolution.org/syncevolution. Look for version
> 1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa

downloaded the source, added my backends but nothing builds. Am I stupid? In
1.5.1 it was sufficient to add the directory/ies to the tree to build
AFAIR.

regards

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

Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[deloptes]

Patrick Ohly wrote:

> On Wed, 2016-09-14 at 01:41 +0200, deloptes wrote:
>> Hi,
>> I added a line to dump the incoming item/payload in the backend. I
>> couldn't see what was sent when using SYNCEVOLUTION_DEBUG=4.
> 
> You need to set the "loglevel" property, not the env variable. I.e. run
> with:
> syncevolution --run loglevel=4 my-config-name
> 
> Then look at the syncevolution-log.html file under
> ~/.cache/syncevolution.
> 
> Click on the "expand all" at the top of the file to unfold everything
> (otherwise searching via the web browser will skip over folded
> sections).
> 
>> I fixed similar issue related to vcal v1 in TDE/libkcal in the vcc.y/cpp
>> file[2] today, while trying to reproduce and looking into the v1 parser.
>> This here looks very very similar to what I fixed, so how is the
>> converter in the engine handling the v1 quoted printable with charset:
>> utf-8. It looks like the versit parser does not honor white space in the
>> beginning of the line for the quoted-printable encoding [3].
> 
> libsynthesis has its own parser. Looking at the full log should tell us
> more about what it needs to parse.
> 

Hi,
I hope you have not forgotten about this problem. Please look into my last
message and let me know if I can do something more. If it is the same issue
as the TDE/libkcal one, the fix should be really simple.

thanks

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

Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[deloptes]

Hi,
I added a line to dump the incoming item/payload in the backend. I couldn't
see what was sent when using SYNCEVOLUTION_DEBUG=4.

TrackingSyncSource::InsertItemResult TDEPIMCalendarSource::insertItem(const
std::string , const std::string , bool raw)
{
SE_LOG_DEBUG(getDisplayName(), "Item payload: ( %s )", item.data() );

It looks like the item is already broken, when passed to the backend[1].

I fixed similar issue related to vcal v1 in TDE/libkcal in the vcc.y/cpp
file[2] today, while trying to reproduce and looking into the v1 parser.
This here looks very very similar to what I fixed, so how is the converter
in the engine handling the v1 quoted printable with charset: utf-8. It
looks like the versit parser does not honor white space in the beginning of
the line for the quoted-printable encoding [3].

The test text says: "This is a test for a very long summary in Cyrillic 2"
and it should look like this: "Това е тест за много дълго заглавие на
кирилица 2"

Help is highly appreciated.

Should I file a bug somewhere, let me know and thanks in advance again.

Thank you in advance

regards


[1]
[2016-09-14 00:50:08.326] Executing Script 'beforewritescript'
[2016-09-14 00:50:08.326] calendar: updating "Това е тест за �= 
�ного дълго за= 
главие на кир�= 
�лица 2"
[2016-09-14 00:50:08.326] calendar: Item payload: ( BEGIN:VCALENDAR 
VERSION:2.0 
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN 
BEGIN:VEVENT 
LAST-MODIFIED:20160913T225045Z 
DTSTAMP:20160914T005008Z 
CREATED:20160913T212613Z 
UID:libkcal-442883373.612 
SEQUENCE:7 
CLASS:PUBLIC 
TRANSP:OPAQUE 
PRIORITY:0 
SUMMARY:Това е тест за �=\n�ного дълго за=\nглавие на кир�=\n�лица 2 
DTSTART:20160914T103000Z 
DTEND:20160914T104500Z 
END:VEVENT 
END:VCALENDAR 
 )
[2016-09-14 00:50:08.326] calendar: Item deleted for merge: (
libkcal-442883373.612 )
[2016-09-14 00:50:08.606] calendar: Item saved: ( libkcal-442883373.612 )
[2016-09-14 00:50:08.606] calendar: Item ( libkcal-442883373.612 :
20160913T225045Z ) done.
[2016-09-14 00:50:08.606] calendar: aID=(libkcal-442883373.612,) res=0


[2] https://bugs.trinitydesktop.org/show_bug.cgi?id=2688
[3] https://www.scribd.com/document/31243097/vCalendar-V1-0-Specifications

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

Re: [SyncEvolution] Explicit type 'text/x-vcalendar' specified in command or item meta

[deloptes]

Patrick Ohly wrote:

> On Tue, 2016-09-13 at 00:26 +0200, deloptes wrote:
>> Hi,
>> sorry for bothering further but I am wondering why I see this when in
>> slow sync but not in normal mode.
> 
> You should see it also in normal mode when creating a new calendar entry
> on the phone.
> 
>> [2016-09-09 17:12:34.846] Explicit type 'text/x-vcalendar' specified in
>> command or item meta
>> [2016-09-09 17:12:34.846] Version '1.0' obtained from item data
>> 
>> Does this mean that (if I recall correctly) the item pushed to the
>> backend is v1.0 calendar?
> 
> No, that's a log entry about the data as it comes from the peer,
> probably a phone in this case. Run with a higher log level (starting
> with 4, if I remember correctly) and you will see the actual data
> getting dumped, with "Parsing" for the original data and "Generated"
> after re-encoding.
> 
>> If yes how can I tell (enforce) the engine to send v2.0?
> 
> It will already do the conversion to 2.0. The "generated" item is what
> it will store in the local database.
> 

Thanks for the response. I trust you - I was thinking it is saying what it
would send to the backend.
The problem I have is that there is a bug in TDM vcal converter, that breaks
non ascii chars when converting from quated-printable to utf8. I think I
observe this problem only when in slow sync mode, but it could be also
something else.
However it makes me think that with high probability the item is not
converted to v2 (ical) format before it gets send to the backend.

I'll try testing this with higher debug as suggested.

thanks

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

[SyncEvolution] Explicit type 'text/x-vcalendar' specified in command or item meta

[deloptes]

Hi,
sorry for bothering further but I am wondering why I see this when in slow
sync but not in normal mode.

[2016-09-09 17:12:34.846] Explicit type 'text/x-vcalendar' specified in
command or item meta
[2016-09-09 17:12:34.846] Version '1.0' obtained from item data

Does this mean that (if I recall correctly) the item pushed to the backend
is v1.0 calendar?
If yes how can I tell (enforce) the engine to send v2.0?

Thanks.


The full context is this:
[2016-09-09 17:12:34.846] 'processCmd' - Processing incoming command,
Cmd=Add, IncomingMsgID=3, CmdID=10 [--][++] [->end] [->enclosing]
[2016-09-09 17:12:34.846] command started processing
[2016-09-09 17:12:34.846] Created command 'Status' (outgoing)
[2016-09-09 17:12:34.846] Item (syncop: add) started processing,
remoteID='502', localID=''
[2016-09-09 17:12:34.846] processSyncOpItem: setting fLocalSyncDatastoreP
[2016-09-09 17:12:34.846] Remote sent add-operation:
[2016-09-09 17:12:34.846] - Source: remoteID ='502', remoteName=''
[2016-09-09 17:12:34.846] - Target: localID ='', remoteName=''
[2016-09-09 17:12:34.846] Explicit type 'text/x-vcalendar' specified in
command or item meta
[2016-09-09 17:12:34.846] Version '1.0' obtained from item data
–
[2016-09-09 17:12:34.846] 'Item_Parse' - parsing SyncML item, SyncOp=add,
format=plain-text, RemoteID=502 [--][++] [->end] [->enclosing]
–[2016-09-09 17:12:34.846] End of 'Item_Parse' [->top] [->enclosing]
–
[2016-09-09 17:12:34.846] 'Process_Item' - processing remote item,
SyncOp=add, RemoteID=502 [--][++] [->end] [->enclosing]
–
[2016-09-09 17:12:34.846] 'SuperProcessItem' - Processing incoming item in
superdatastore, datastore=calendar+todo, SyncOp=add, RemoteID=502 [--][++]
[->end] [->enclosing]
[2016-09-09 17:12:34.846] Checkin subdatastore filters to find where it
belongs
[2016-09-09 17:12:34.846] Found item belongs to
subdatastore 'calendar+todo@calendar'
[2016-09-09 17:12:34.846] add item operation received
[2016-09-09 17:12:34.846] No matching item found - add it to local database
[2016-09-09 17:12:34.846] startDataWrite called, status=0
[2016-09-09 17:12:34.846] TStdLogicDS::logicProcessRemoteItem 0x214a540
starting, SyncOp=add, RemoteID='502', LocalID=''
[2016-09-09 17:12:34.846] TCustomImplDS::implProcessItem 0x214a540 starting,
SyncOp=add, RemoteID='502', LocalID=''
[2016-09-09 17:12:34.846] Executing Script 'beforewritescript'
[2016-09-09 17:12:34.847] calendar: adding "CCC zum Thema "IT aus Europa?
Chancen und Nischen zwischen den IT-Gro�= 
�mächten USA und Asien!" Flughafen Wien"
[2016-09-09 17:12:35.172] calendar: Item saved: ( libkcal-1126788650.788 )
[2016-09-09 17:12:35.172] calendar: Item ( libkcal-1126788650.788 :
20160826T202938Z ) done.
[2016-09-09 17:12:35.172] calendar: InsertItemAsKey res=0
[2016-09-09 17:12:35.172] - Operation add performed (regular), Remote ID=502
Local ID=libkcal-1126788650.788, status=201
–[2016-09-09 17:12:35.172] End of 'SuperProcessItem' [->top] [->enclosing]
–[2016-09-09 17:12:35.172] End of 'Process_Item' [->top] [->enclosing]
–
[2016-09-09 17:12:35.172] 'issue' - issuing command, Cmd=Status [--][++]
[->end] [->enclosing]
[2016-09-09 17:12:35.172] Status Code 201 issued for Cmd=Add, (incoming
MsgID=3, CmdID=10)
[2016-09-09 17:12:35.172] - SourceRef (remoteID) = '502'
[2016-09-09 17:12:35.172] Status: issued as (outgoing MsgID=3, CmdID=10),
not waiting for status
[2016-09-09 17:12:35.172] Deleted command 'Status' (outgoing MsgID=3,
CmdID=10)
[2016-09-09 17:12:35.172] Outgoing Message size is now 544 bytes
–[2016-09-09 17:12:35.172] End of 'issue' [->top] [->enclosing]
[2016-09-09 17:12:35.172] Deleted command 'Add' (incoming MsgID=3, CmdID=10)

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

Re: [SyncEvolution] survey: providing SyncEvolution binaries - dropping Akonadi support?

[deloptes]

Patrick Ohly wrote:

> On Wed, 2016-08-31 at 23:12 +0200, Tino Mettler wrote:
>> On Mon, Aug 22, 2016 at 15:22:31 +0200, Patrick Ohly wrote:
>> > One exception
>> > is perhaps Debian Stable, which only has an old version (1.4.99). But
>> > even that isn't too bad.
>> 
>> Hi Patrick,
>> 
>> I could check if a backport of 1.5.1 for Stable is trivial. Users
>> would have to manually add the backports repository, but installing
>> binaries from syncevolution.org requires some manual steps, too.
> 
> After fiddling with the build system I think I have Debian Jessie and
> Testing/Stretch covered. So thanks for the offer, but unless someone
> wants to have "official" Debian packages backported, there's no need.
> 
> I'm still not sure what binaries and features users really need
> nowadays. While testing, I noticed that Akonadi has issues on Debian
> Stretch (https://bugs.freedesktop.org/show_bug.cgi?id=97609). To move
> forward with that, I would have to write a simpler reproducer, then file
> a bug against Debian and/or Akonadi.
> 
> Tino, can you reproduce the same with the Debian packages
>
(https://packages.debian.org/stretch/amd64/syncevolution-libs-kde/filelist)?
> 
> It could be specific to my test environment (X11 provided by VNC only
> because Akonadi no longer runs headless, no KDE session).
> 
> Is anyone still using SyncEvolution with Akonadi?
> 

This might be useful for you. I just replaced opensync with syncevolution.
Wou'll need probably some adjustments

export LC_ALL=de_DE.UTF-8
KDEDIR=/usr
SYNCEVOLUTION=/opt/testing/syncevolution
KDEDIRS=$SYNCEVOLUTION:$KDEDIR
AKTESTHOME=$HOME/kde-testdir
KDEHOME=$AKTESTHOME/.kde
KDETMP=$AKTESTHOME/kdetmp
KDEVARTMP=$AKTESTHOME/kdevartmp
PATH=$SYNCEVOLUTION/bin:$KDEDIR/bin:$PATH
LD_LIBRARY_PATH=$SYNCEVOLUTION/lib:$KDEDIR/lib:$LD_LIBRARY_PATH
PKG_CONFIG_PATH=/opt/testing/syncevolution/lib/pkgconfig

export KDEDIRS PATH LD_LIBRARY_PATH AKTESTHOME KDEHOME KDETMP KDEVARTMP
PKG_CONFIG_PATH

XDG_DATA_DIRS=$SYNCEVOLUTION/share:$KDEDIR/share:/usr/local/share:/usr/share
export XDG_DATA_DIRS

XDG_DATA_HOME=$AKTESTHOME/.local/share
XDG_CONFIG_HOME=$AKTESTHOME/.config
export XDG_DATA_HOME XDG_CONFIG_HOME

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

Re: [SyncEvolution] survey: providing SyncEvolution binaries - dropping Akonadi support?

[deloptes]

Patrick Ohly wrote:

> It could be specific to my test environment (X11 provided by VNC only
> because Akonadi no longer runs headless, no KDE session).

I think I still have some useful scripts (.profile) to run Akonadi from the
command line after ssh -X.
If interested let me know - I'll have a look.

I'm interested in getting the libraries for debian jessie or strech/sid so
that I may rebuild for TDE.

I have heard nothing from Tino if the issues with jessie were solved. If you
could provide the dependencies and debian related src files it would be
great.
I've been too busy recently, but I'll drop the code as soon as I can next.

regards

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

Re: [SyncEvolution] syncevolution debug help needed

[deloptes]

Patrick Ohly wrote:

> On Thu, 2016-08-25 at 08:50 +0200, deloptes wrote:
>> Patrick Ohly wrote:
>> >> The story about ITEM_NEEDS_MERGE however is still a bit unclear to me.
>> >> Is it a suggestion - at least I understand it as such?
>> > 
>> > It's a bit more than a suggestion. It's a request to the engine to do
>> > the merge. What happens is:
>> >  1. add new item -> ITEM_NEEDS_MERGE without changing the database
>> >  2. read old item with luid as provided with ITEM_NEEDS_MERGE
>> >  3. update old item with merged data
>> > 
>> 
>> So in this case I should not DEL+ADD in the backend, but just notify with
>> ITEM_NEEDS_MERGE? Correct?
> 
> Correct.
> 

I think it's good to go now. I did not excessively tested it, but following
your advise I changed the relevant places. I'm just not confident what it
should return - in terms of id and revision, but what I tested performed
without issues.

It would be nice if I can upload the code to where it belongs and we get
opportunity to build packages from the source for our desktop as well.

regards

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

Re: [SyncEvolution] syncevolution debug help needed

[deloptes]

Patrick Ohly wrote:

> On Wed, 2016-08-24 at 01:22 +0200, deloptes wrote:
>> IMO it would be best to push into syncevolution tree and TDE could apply
>> own debian rules for building a package which would replace the debian
>> native package offering tdepim.
>> Does someone has better ideas?
> 
> Sounds like the right approach. I can't promise that I will do anything
> with the new backend code (like at least compile-testing it when making
> changes) because I'm not sure how much work it would be to make the
> dependencies available on my build host, but at least the code would be
> available for those who want to use it.
> 

Last part is nice to have, so that it goes into the distros. I had some
discussion with Tino here regarding debian package builds.
As I am using debian it would be easy to get a package if the code is in
there and just rebuild for trinity desktop.

>> The story about ITEM_NEEDS_MERGE however is still a bit unclear to me. Is
>> it a suggestion - at least I understand it as such?
> 
> It's a bit more than a suggestion. It's a request to the engine to do
> the merge. What happens is:
>  1. add new item -> ITEM_NEEDS_MERGE without changing the database
>  2. read old item with luid as provided with ITEM_NEEDS_MERGE
>  3. update old item with merged data
> 

So in this case I should not DEL+ADD in the backend, but just notify with
ITEM_NEEDS_MERGE? Correct? (Sorry I did not have time to look in the other
backends how this is exactly implemented).

thanks and regards


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

Re: [SyncEvolution] syncevolution debug help needed

[deloptes]

Patric,
thanks a lot! This was a great explanation (as usual). I will rework the
relevant parts when there is some time available soon (I think I will have
to only replace ITEM_REPLACED with ITEM_OKAY in the contacts backend and
ITEM_NEEDS_MERGE in the calendar/todo backend).

Patrick Ohly wrote:

> On Tue, 2016-08-23 at 00:29 +0200, deloptes wrote:
>> Patrick Ohly wrote:
>> 
>> > Is the full code available somewhere?
>> > 
>> 
>> No, I still don't know what to do with it and I'm not sure in which form
>> I should upload it. Uploading it means maintain it ... etc. I was
>> thinking to upload it to the trinity desktop, but still it is not clear
>> how it would fit with the different distros. Another option would be to
>> add it to syncevolution - perhaps it is even more proper ... anyway short
>> answer is no - I could pass a zip file of it .. it's really not much
>> code. The last but not least is I do not feel confident because of this
>> issue and do not want to "release" is until it is solved.
> 
> Fair enough. The common wisdom is to "release early, release often", but
> in this case I agree that it is better to ensure that there is no data
> loss before making it available to others.
> 

The question is where. We've fixed some UTF related parts of the TDE code,
which was bugging me since the time of opensync and smart phones started
supporting UTF or something more than iso8859.
Slowly it gets mature. I had a wish to implement support for vcal but gave
it up as testing showed there are some issues with handling vcal in the TDE
lib. I still suspect some issues there perhaps UTF related, but no time to
work on this recently.
So while the backend gets mature there are some challenges on the opposite
side, but it is still good to have a plan what to do next.

IMO it would be best to push into syncevolution tree and TDE could apply own
debian rules for building a package which would replace the debian native
package offering tdepim.
Does someone has better ideas?

>> So it looks like I misunderstood the  ITEM_REPLACED meaning? Could you
>> please confirm once again. I have been struggling with these part of the
>> code for some time already.
>> 
>> My questions
>> 1. even when update is implemented as del+add and the item has the old ID
>> it should return ITEM_OKAY?
> 
> Yes.
> 
>> 2. does ITEM_REPLACED means that item has new ID and is to replace the
>> old item with the old ID?
> 
> ITEM_REPLACED, ITEM_MERGED and ITEM_NEEDS_MERGE all are to be used only
> when adding a new item, i.e. uid is empty. In this case, the engine
> doesn't know about the existing item in the database and the backend has
> to tell the engine about it.
> 
> ITEM_NEEDS_MERGE is probably best for handling this situation because
> merely replacing the existing item (ITEM_REPLACED) can loose data and
> merging in the backend (ITEM_MERGED) is more work to implement.
> 
>> Strange is only that I have such issues with calendar+todo only and a
>> fact is that it messes totally up in slow sync.
> 
> Not sure either. Perhaps it is because calendar items have a UID and
> thus additional constraints that don't apply to contacts. ITEM_REPLACED,
> ITEM_MERGED and ITEM_NEEDS_MERGE should never be needed for contacts,
> because a contact backend typically will never be able to detect when a
> new contact that is to be added already exists.
> 

The story about ITEM_NEEDS_MERGE however is still a bit unclear to me. Is it
a suggestion - at least I understand it as such?
I think I lack understanding about it and will look into some of the other
backends to get better insight.
I see
return InsertItemResult(luid, "", ITEM_NEEDS_MERGE);
in 
./src/backends/webdav/WebDAVSource.cpp 
and 
./src/backends/webdav/CalDAVSource.cpp

and there is no delete or add around. It means we find out there is item
with such ID and do nothing - just curious what happens next in theory.

I'll ask here if I need some assistance. Ideas and enlightening is always
welcome of course.

regards



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

[SyncEvolution] syncevolution debug help needed

[deloptes]

Hi,
from time to time I'm getting in following situation.
Do you have some hint how I can understand what is wrong here. It works
fine, but at once I start getting those messages. The following output was
created with SYNCEVOLUTION_DEBUG=3 syncevolution nokia_N9 calendar+todo 

Thanks in advance

[2016-07-28 18:49:04.473] Created command 'Add' (incoming)
[2016-07-28 18:49:04.473] Started processing Command 'Add' (incoming
MsgID=3, CmdID=5)
–
[2016-07-28 18:49:04.473] 'processCmd' - Processing incoming command,
Cmd=Add, IncomingMsgID=3, CmdID=5 [--][++] [->end] [->enclosing]
[2016-07-28 18:49:04.473] command started processing
[2016-07-28 18:49:04.473] Created command 'Status' (outgoing)
[2016-07-28 18:49:04.473] Item (syncop: add) started processing,
remoteID='496', localID=''
[2016-07-28 18:49:04.473] processSyncOpItem: setting fLocalSyncDatastoreP
[2016-07-28 18:49:04.473] Remote sent add-operation:
[2016-07-28 18:49:04.473] - Source: remoteID ='496', remoteName=''
[2016-07-28 18:49:04.473] - Target: localID ='', remoteName=''
[2016-07-28 18:49:04.473] Explicit type 'text/x-vcalendar' specified in
command or item meta
[2016-07-28 18:49:04.473] Version '1.0' obtained from item data
–
[2016-07-28 18:49:04.473] 'Item_Parse' - parsing SyncML item, SyncOp=add,
format=plain-text, RemoteID=496 [--][++] [->end] [->enclosing]
–[2016-07-28 18:49:04.473] End of 'Item_Parse' [->top] [->enclosing]
–
[2016-07-28 18:49:04.473] 'Process_Item' - processing remote item,
SyncOp=add, RemoteID=496 [--][++] [->end] [->enclosing]
–
[2016-07-28 18:49:04.473] 'SuperProcessItem' - Processing incoming item in
superdatastore, datastore=calendar+todo, SyncOp=add, RemoteID=496 [--][++]
[->end] [->enclosing]
[2016-07-28 18:49:04.473] Checkin subdatastore filters to find where it
belongs
[2016-07-28 18:49:04.473] Found item belongs to
subdatastore 'calendar+todo@todo'
[2016-07-28 18:49:04.473] add item operation received
[2016-07-28 18:49:04.473] startDataWrite called, status=0
[2016-07-28 18:49:04.473] TStdLogicDS::logicProcessRemoteItem 0x27e1620
starting, SyncOp=add, RemoteID='496', LocalID=''
[2016-07-28 18:49:04.473] TCustomImplDS::implProcessItem 0x27e1620 starting,
SyncOp=add, RemoteID='496', LocalID=''
[2016-07-28 18:49:04.473] to-be-added item already exists -> trying replace
(=conflict resolved by client winning)
[2016-07-28 18:49:04.473] TCustomImplDS::implProcessItem 0x27e1620 starting,
SyncOp=replace, RemoteID='496', LocalID=''
[2016-07-28 18:49:04.473] Executing Script 'beforewritescript'
[2016-07-28 18:49:04.473] todo: updating "Juli call ptotesi gel"
[2016-07-28 18:49:04.473] todo: Item delete: (
00287b7f-207e-476b-96ad-6d0758d563e1 )
[2016-07-28 18:49:04.764] todo: Item saved: (
00287b7f-207e-476b-96ad-6d0758d563e1 )
[2016-07-28 18:49:04.764] todo: Item (
00287b7f-207e-476b-96ad-6d0758d563e1 : 20160704T075430Z ) done.
[2016-07-28 18:49:04.764] todo: aID=(00287b7f-207e-476b-96ad-6d0758d563e1,)
res=208
[2016-07-28 18:49:04.764] - Operation replace failed with SyncML status=208
–[2016-07-28 18:49:04.764] End of 'SuperProcessItem' [->top] [->enclosing]
–[2016-07-28 18:49:04.764] End of 'Process_Item' [->top] [->enclosing]
[2016-07-28 18:49:04.764] processSyncOpItem: Irregularity while processing
item, status=208
[2016-07-28 18:49:04.764] Irregularity in execution of item, status=208
–
[2016-07-28 18:49:04.764] 'issue' - issuing command, Cmd=Status [--][++]
[->end] [->enclosing]
[2016-07-28 18:49:04.764] Status Code 208 issued for Cmd=Add, (incoming
MsgID=3, CmdID=5)
[2016-07-28 18:49:04.764] - SourceRef (remoteID) = '496'
[2016-07-28 18:49:04.764] Status: issued as (outgoing MsgID=3, CmdID=5), not
waiting for status
[2016-07-28 18:49:04.764] Deleted command 'Status' (outgoing MsgID=3,
CmdID=5)
[2016-07-28 18:49:04.764] Outgoing Message size is now 352 bytes
–[2016-07-28 18:49:04.764] End of 'issue' [->top] [->enclosing]
[2016-07-28 18:49:04.764] Deleted command 'Add' (incoming MsgID=3, CmdID=5)
–[2016-07-28 18:49:04.764] End of 'processCmd' [->top] [->enclosing]

or


[2016-07-28 18:49:03.705] Started processing Command 'Add' (incoming
MsgID=2, CmdID=22)
–
[2016-07-28 18:49:03.705] 'processCmd' - Processing incoming command,
Cmd=Add, IncomingMsgID=2, CmdID=22 [--][++] [->end] [->enclosing]
[2016-07-28 18:49:03.705] command started processing
[2016-07-28 18:49:03.705] Created command 'Status' (outgoing)
[2016-07-28 18:49:03.705] Item (syncop: add) started processing,
remoteID='482', localID=''
[2016-07-28 18:49:03.705] processSyncOpItem: setting fLocalSyncDatastoreP
[2016-07-28 18:49:03.705] Remote sent add-operation:
[2016-07-28 18:49:03.705] - Source: remoteID ='482', remoteName=''
[2016-07-28 18:49:03.705] - Target: localID ='', remoteName=''
[2016-07-28 18:49:03.705] Explicit type 'text/x-vcalendar' specified in
command or item meta
[2016-07-28 18:49:03.705] Version '1.0' obtained from item data
–
[2016-07-28 18:49:03.705] 'Item_Parse' - parsing SyncML item, SyncOp=add,
format=plain-text, RemoteID=482 [--][++] [->end] 

Re: [SyncEvolution] Debian building packages for syncevolution 1.5.1 and TDE backends

[deloptes]

Patrick Ohly wrote:

> On Tue, 2016-06-28 at 00:26 +0200, deloptes wrote:
>> I noticed there is no package for stretch - for jessie and sid there is
>> one - what are the plans or what is the story?
>> This is also version 1.4.99 - why not 1.5.1 (I mean at least sid)?
>> 
>> https://packages.debian.org/sid/syncevolution
> 
> I think it had to be removed because it no longer compiled in stretch.
> 1.5.1 needs to be uploaded, then it can migrate to stretch again.
> 

Thank you Patric, I just realized why
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824426 ,
perhaps I should try with the git code of syncevolution.

>> I also did not understand how I can get the TDE backends into the
>> syncevolution code tree, or what you would advise to do with backends
>> that target specific desktop environment (TDE)?
> 
> I think it would be best to include it in the upstream release. Then it
> is easier for distros to enable it, if they want. OTOH, if a distro
> wants, they can already now grab the SyncEvolution source, add the
> backend directory from a separate archive or location, and compile both
> together.
> 
> But there's one unsolved problem either way: distros most likely use the
> glib D-Bus bindings. It is the more modern solution. When enabling the
> TDE backend, distros would have to use the same workaround as you did
> and switch back to the libdbus-based bindings. Not sure whether that's a
> viable long term solution.
> 

I don't know who to ask but I'll discuss this with the TDE people, thanks.
This dbus issue is on the todo list as well.

>> There are couple of options and I have no idea what is the best way. The
>> TDE team could provide packages, or it could go through the supported
>> distros. What would you advise?
>>
>> Here is reference to TDE: http://www.trinitydesktop.org/
> 
> Are there distros which include TDE or is the normal approach to use the
> packages prepared by the TDE team for certain distros?
> 
> If TDE is not included in a distro and SyncEvolution is, then the distro
> can't compile the TDE backend. In that case the TDE team could try to
> compile the backend against the SyncEvolution version provided by the
> distro, but that's tricky - I'm not even sure whether distros install
> all the header files, and a custom makefile would have to be written for
> the backend.
> 
TDE is not included in a distro. It is installed on top, being independent
from other desktops shipped with the distro.
This makes the case even more complicated, because if in example Debian
ships syncevolution with evolution and akonadi/kde backend, TDE should
demand from Debian compiling with tdepim support or provide own (TDE)
packages that would add tdepim backend (as you describe below). Same for
SuSE etc ...

> Another alternative would be to provide SyncEvolution packages as part
> of TDE, overriding the ones provided by the distro. That's also not a
> good solution and something that I am currently struggling with in the
> project, because for example, Ubuntu has non-upstream patches and
> SyncEvolution must be compiled exactly as chosen by Ubuntu, otherwise
> the replacement would not work as the original, distro-provided
> packages.
> 

I understand, thanks again. I think perhaps it's best to merge syncevolution
and plugins in TDE and build own packages for now. If you add the code to
syncevolution and it goes around several distros, it would be harder to
update and I have still few places for improvement, though overall I did
not have any issue in the past few months.

thanks and regards

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

Re: [SyncEvolution] Debian building packages for syncevolution 1.5.1 and TDE backends

[deloptes]

Tino Mettler wrote:

> On Mon, Jun 13, 2016 at 16:13:44 +0200, deloptes wrote:
>> OK, Thank you Tino,
>> I have the feeling you are right. I'll try to build the debian packages
>> on the test env, where I will need to install the evolution and kde libs
>> as well, so that I'll be able to build all available/suggested backends.
>> 
>> What about merging the code into the syncevolution git tree?
>> What is the "official" procedure?
> 
> Hi,
> 
> that question is better sent to the syncevolution mailing list, as I'm
> only the Debian maintainer.
> 
> Regards,
> Tino

Hi again,

I noticed there is no package for stretch - for jessie and sid there is
one - what are the plans or what is the story?
This is also version 1.4.99 - why not 1.5.1 (I mean at least sid)?

https://packages.debian.org/sid/syncevolution

I also did not understand how I can get the TDE backends into the
syncevolution code tree, or what you would advise to do with backends that
target specific desktop environment (TDE)?
There are couple of options and I have no idea what is the best way. The TDE
team could provide packages, or it could go through the supported distros.
What would you advise?

Here is reference to TDE: http://www.trinitydesktop.org/

Thanks in advance

regards

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

[SyncEvolution] Debian building packages for syncevolution 1.5.1 and TDE backends

[deloptes]

Hi again,

1.
the second part of my question is/was what to do with the source code and
what would be the best approach?
I think the code should go into syncevolution repository. TDE packages would
be provided then by TDE.
Is it correct assumption and if yes what is the way for doing it?

2.
Now following your advise I updated the package files, but it failed to
build anyway

here is the config (I copy pasted from my test scripts into debian/rules)
and the errors I got.
I don't get those errors when I compile using automake. I assume this is
something to do with dpkg building shared, but I'll be glad if you could
help

dh_auto_configure -- --prefix=/usr \
--sysconfdir=/etc \
--libexecdir=/usr/lib/x86_64-linux-gnu/syncevolution \
--enable-gui \
--with-rst2man --with-rst2html \
--enable-maintainer-mode \
--enable-core \
--enable-bluetooth \
--enable-tdepimabc \
--enable-tdepimcal \
--enable-tdepimnotes \
--disable-tdewallet \
--enable-sqlite \
--enable-file \
--enable-dav \
--without-gio-gdbus \
--disable-ssl-certificate-check \
--disable-akonadi \
--disable-ebook \
--disable-ecal \
--disable-goa \
--disable-kcalextended \
--disable-kwallet \
--disable-maemocal \
--disable-oauth2 \
--disable-qtcontacts \
--disable-gsso \
--disable-uoa \
--disable-sign


dpkg-buildpackage -rfakeroot -b -d -us -uc
or
dpkg-buildpackage -rfakeroot -b -d -us -uc -aamd64

/usr/bin/ld: 
/opt/software/SyncEvolution/syncevolution-1.5.1/src/build-synthesis/src/.libs/libsynthesissdk.a(libsynthesissdk_la-SDK_util.o):
relocation R_X86_64_PC32 against symbol `StrAllocN' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:5931: recipe for target 'src/syncevo/libsyncevolution.la' failed
make[3]: *** [src/syncevo/libsyncevolution.la] Error 1
make[3]: Leaving
directory '/opt/software_x64/SyncEvolution/syncevolution-1.5.1'
Makefile:11453: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving
directory '/opt/software_x64/SyncEvolution/syncevolution-1.5.1'
Makefile:4473: recipe for target 'all' failed
make[1]: *** [all] Error 2
rm src/dbus/glib/stamp-syncevo-session-bindings.h
src/dbus/glib/stamp-syncevo-session-glue.h
src/dbus/glib/stamp-syncevo-connection-bindings.h
src/dbus/glib/stamp-syncevo-server-glue.h
src/dbus/glib/stamp-syncevo-server-bindings.h
src/dbus/glib/stamp-syncevo-connection-glue.h
make[1]: Leaving
directory '/opt/software_x64/SyncEvolution/syncevolution-1.5.1'
dh_auto_build: make -j1 returned exit code 2
debian/rules:18: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
status 2


perhaps this helps too

grep PIC config.log
configure:9618: checking for gcc option to produce PIC
configure:9625: result: -fPIC -DPIC
configure:9633: checking if gcc PIC flag -fPIC -DPIC works
configure:9651:
gcc -c -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
-Wall -pedantic -D_FORTIFY_SOURCE=2 -fPIC -DPIC -DPIC
conftest.c >&5
configure:11095: gcc -shared  -fPIC -DPIC
conftest.o  -v -Wl,-soname -Wl,conftest -o conftest 2\>\&1
\| /bin/grep  -lc  \>/dev/null 2\>\&1
configure:15166: checking for g++ option to produce PIC
configure:15173: result: -fPIC -DPIC
configure:15181: checking if g++ PIC flag -fPIC -DPIC works
configure:15199:
g++ -c -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
-D_FORTIFY_SOURCE=2 -fPIC -DPIC -DPIC
conftest.cpp >&5
lt_cv_prog_compiler_pic='-fPIC -DPIC'
lt_cv_prog_compiler_pic_CXX='-fPIC -DPIC'


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

Re: [SyncEvolution] syncevolution 1.5.1 and TDE backends

[deloptes]

Tino Mettler wrote:

> I don't get the real question. If you added your own backend and want
> to know how to add it to the Debian packaging, you could
> use the KDE backend (in the syncevolution-libs-kde package) as an example:
> 
> 1. add a syncevolution-libs-tde backend package to debian/control (use
> the syncevolution-libs-kde part as a template)
> 
> 2. add a file debian/syncevolution-libs-tde.install (use
> debian/syncevolution-libs-kde.install as a template) and insert the
> backend libs for your TDE backend
> 
> If you have other questions regarding usage of the Debian packaging,
> just ask.
> 
> Regards,
> Tino

Thanks Tino,
this was exactly the answer I was looking for. I don't like reinventing the
wheel. You saved me some precious time.

regards

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

[SyncEvolution] syncevolution 1.5.1 and TDE backends

[deloptes]

Tino Mettler wrote:

> On Wed, Jun 01, 2016 at 14:29:09 +0200, Patrick Ohly wrote:
> 
> [...]
> 
>> Tino, how's your update of the Debian package to the latest version
>> going? I saw that Debian Testing doesn't have any SyncEvolution version
>> anymore.
> 
> Hi,
> 
> I submitted a 1.5.1 package to my sponsor, but he had no time to upload
> it until now.
> 
> Meanwhile, I put 1.5.1 packages for Debian Sid built by myself here:
> 
> http://tikei.de/debian/syncevolution/
> 
> If there are any problems with these (like depends on outdated
> libraries), just let me now and I will rebuild them.
> 
> If they won't work with stretch, just send me a note and I'll upload
> packages for stretch.
> 
> Regards,
> Tino

Hi,
I want to use this opportunity to ask a question I wanted to ask for some
time now.

I was working on a TDE (Tinity Desktop Env) backends in the past few months
and I tried recently to build packages for debian, but failed miserably.
I was wondering how I could go ahead with the code now. I would consider the
backend as working (I need to improve/change few things in the feature).
I am not able to test the wallet because I don't have any account, so the
wallet backend code is not tested. The rest is working without major
issues.

Can you share some ideas please?

Thanks in advance

regards


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

[SyncEvolution] Calendar+Todo and Memo

[deloptes]

Hi all,

I apologize for disturbing you once again, however I found out that the
older Nokia 5530 has Calendar+Todo and Memo in one.
So when I use following configuration I get everything to the TDE Calendar
when just syncing the calendar part. This is great, however I can not push
back Todo or Memo items for obvious reasons.

How can I modify the configuration such that I am able to use all of it. I
read about the virtual, but could not come up with a decision what I should
put where in the config.

syncevolution --configure \
 --template ${template} \
syncURL=obex-bt://${deviceAddress} \
  peerIsClient=1 \
  dumpData=0 \
  printChanges=0 \
addressbook/backend=tdepim-contacts \
addressbook/database="kxXrRFzP9c" \
addressbook/databaseFormat="text/vcard" \
calendar/uri="Calendar" \
calendar/backend=tdepim-calendar \
calendar/database="ZsPZokpoTg" \
calendar/databaseFormat="text/calendar" \
todo/backend=tdepim-tasks \
todo/database="ZsPZokpoTg" \
todo/databaseFormat="text/calendar" \
memo/backend=tdepim-memos \
memo/database="ZsPZokpoTg" \
memo/databaseFormat="text/calendar" \
${server} addressbook calendar todo memo

*template is N900

The plugins work great so far address book and calendar sync up well with
this Nokia 5530. I'm getting confidence to try it out on the N9 next.

Thanks for your support so far.

regards

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

Re: [SyncEvolution] Char encoding in syncevo config

[deloptes]

Looking further into it I solved the issue by passing c_str() to parseVCard

TDEABC::Addressee addressee = converter.parseVCard(item.c_str());

works OK

and when reading an item the same, after converting the TQString into
std::string, passing the c_str() to the item object
item.assign(data_str.c_str());

works OK

so in both directions now encoding is preserved.

thanks for the hints and advises, without your help I wouldn't have solved
it so fast.


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

Re: [SyncEvolution] Char encoding in syncevo config [identified]

[deloptes]

Hi Patrick,

thanks again for the input. It seems to be a bug in the vCard to addressee
converter in TDE.

regards

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

Re: [SyncEvolution] Char encoding in syncevo config

[deloptes]

Patrick Ohly wrote:

> On Thu, 2016-03-24 at 00:13 +0100, deloptes wrote:
>> Patrick Ohly wrote:
>> 
>> > On Wed, 2016-03-23 at 08:39 +0100, deloptes wrote:
>> > When you receive vCards from those phones and they contain data in
>> > ISO-8859-15, does the vCard contain a CHARSET parameter on the property
>> > with the non-ASCII content?
>> 
>> My assumption was wrong that it was not UTF (may be). It says quoted
>> printable/utf-8. Could be that the UTF there is misleading?
> 
> N;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:H=C3=B6sch seems to decode
> fine to "Hösch", so it should be correct.
> 

yes indeed

>> > It is possible to override the default charset for specific phones. See
>> > "11.36.19 " in
>> > libsynthesis/doc/SySync_config_reference.pdf
>> > 
>> > There is an example of that in
>> >
syncevolution/src/syncevo/configs/remoterules/server/00_sony_ericsson.xml
>> > 
>> > You can add similar .xml fragments for your phones, using manufacturer
>> > and model tags to limit the effect to certain phones.
>> > 
>> 
>> I attach here some snippets from the log. I see the data properly
>> converted/mapped to the internal fields, only I don't know at which stage
>> it is done.
> 
> In the Synthesis vCard parser. It knows about ENCODING and CHARSET
> parameters. I'm not exactly sure where in the source, though.
> 
>>  The result however in the Addressbook is not readable (for the
>> cyrillic) and mangled for the ö.
> 
> What's mangled about the ö? The name "Hösch" looks okay to me, at least
> in the internal representation. I can't read cyrillic, so no idea
> whether that example is okay.
> 

What I mean that I see the Cyrillic as ? and the ö as two squares. The
first happens according my experience when you convert to ASCII and the
latter when you do utf to utf - anyway this is not that important.
Important is that it is broken and most probably not in syncevolution.

> If it is wrong after storing in your local database, then you need to
> dig further in the processing pipeline. The internal representation will
> get re-encoded again as vCard for storage, and that string then gets
> passed to your backend.
> 

I now also think the problem is somewhere deeper. From what I see the vCard
passed to the backend looks properly encoded. I'll try to get it printed
out to check how it looks like when we receive it and after we've saved it
in the address book.

thank you for looking into it

regards

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

Re: [SyncEvolution] Char encoding in syncevo config

[deloptes]

Patrick Ohly wrote:

> On Wed, 2016-03-23 at 08:39 +0100, deloptes wrote:

I forgot to attach the portions from syncevo logs



[2016-03-23 01:01:44.853] Explicit type 'text/x-vcalendar' specified in command 
or item meta
[2016-03-23 01:01:44.853] Version '1.0' obtained from item data
–
[2016-03-23 01:01:44.853] 'Item_Parse' - parsing SyncML item, SyncOp=add, 
format=plain-text, RemoteID=10 [--][++] [->end] [->enclosing]
[2016-03-23 01:01:44.853] Created new item of datatype 'vCalendar10', 
localID='' remoteID='10'
[2016-03-23 01:01:44.853] Parsing: 
[2016-03-23 01:01:44.853] 
BEGIN:VCALENDAR
VERSION:1.0
BEGIN:VEVENT
UID;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:23072010191708845500=CE=B3
SUMMARY:rd
DTSTART:20041124T00
DTEND:20041124T00
CLASS:PUBLIC
SEQUENCE:0
RRULE:YM1 11 21001124T00
AALARM;TYPE=X-EPOCSOUND;ENCODING=QUOTED-PRINTABLE:20041124T093000;;;z:=5Csystem=5CSystemSounds=5Calarm.wav
LAST-MODIFIED:20101202T132409Z
PRIORITY:0
END:VEVENT
END:VCALENDAR





[2016-03-23 23:24:05.510] Explicit type 'text/x-vcard' specified in command or 
item meta
[2016-03-23 23:24:05.510] Version '2.1' obtained from item data
–
[2016-03-23 23:24:05.510] 'Item_Parse' - parsing SyncML item, SyncOp=add, 
format=plain-text, RemoteID=753 [--][++] [->end] [->enclosing]
[2016-03-23 23:24:05.510] Created new item of datatype 'vCard21', localID='' 
remoteID='753'
[2016-03-23 23:24:05.510] Parsing: 
[2016-03-23 23:24:05.510] 
BEGIN:VCARD
VERSION:2.1
REV:20101002T211708Z
N;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:H=C3=B6sch
TEL;CELL:00436769226242
END:VCARD
[2016-03-23 23:24:05.510] Successfully parsed: 
[2016-03-23 23:24:05.510] Item LocalID='', RemoteID='753', operation=add, size: 
[maxlocal,maxremote,actual]
[2016-03-23 23:24:05.511] 
-  0 :integer SYNCLVL [ n/a,   0, 0] : 
-  1 :  timestamp REV [  -1,   0, 0] : 2010-10-02T21:17:08Z 
(TZ: UTC)
-  2 : string UID [ n/a,   0, 0] : 
-  3 : string GROUP_TAG   [ n/a,   0, 0] : 
 -- element0 : 
-  4 : string N_LAST  [  -1,   0, 9] : "Hösch"





[2016-03-23 23:23:54.139] Explicit type 'text/x-vcard' specified in command or 
item meta
[2016-03-23 23:23:54.139] Version '2.1' obtained from item data
–
[2016-03-23 23:23:54.139] 'Item_Parse' - parsing SyncML item, SyncOp=add, 
format=plain-text, RemoteID=416 [--][++] [->end] [->enclosing]
[2016-03-23 23:23:54.139] Created new item of datatype 'vCard21', localID='' 
remoteID='416'
[2016-03-23 23:23:54.140] Parsing: 
[2016-03-23 23:23:54.140] 
BEGIN:VCARD
VERSION:2.1
REV:20100725T123716Z
N;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=
=D0=95=D1=80=D0=B5=D0=B2=D0=B8=D0=BD=D0=BE=D0=B2;=D0=9A=D0=B0=D0=BB=D0=BE=
=D1=8F=D0=BD;;;
FN;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=
=D0=9A=D0=B0=D0=BB=D0=BE=D1=8F=D0=BD=20=D0=95=D1=80=D0=B5=D0=B2=D0=B8=D0=
=BD=D0=BE=D0=B2
ADR;HOME;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=
;;32=20Bellefields=20Road=0D=0ALondon=20SW99UQ=0D=0A=D0=90=D0=BD=D0=
=B3=D0=BB=D0=B8=D1=8F
BDAY:19750130
NOTE;ENCODING=QUOTED-PRINTABLE:Konto:=2000915098966=0D=0ABLZ=2012000=20BA-CA
TEL;CELL:004369911862293
END:VCARD
[2016-03-23 23:23:54.140] Successfully parsed: 
[2016-03-23 23:23:54.140] Item LocalID='', RemoteID='416', operation=add, size: 
[maxlocal,maxremote,actual]
[2016-03-23 23:23:54.140] 
-  0 :integer SYNCLVL [ n/a,   0, 0] : 
-  1 :  timestamp REV [  -1,   0, 0] : 2010-07-25T12:37:16Z 
(TZ: UTC)
-  2 : string UID [ n/a,   0, 0] : 
-  3 : string GROUP_TAG   [ n/a,   0, 0] : 
 -- element0 : 
 -- element1 : 
-  4 : string N_LAST  [  -1,   0,16] : "Еревинов"
-  5 : string N_FIRST [  -1,   0,12] : "Калоян"
-  6 : string N_MIDDLE[  -1,   0, 0] : 
-  7 : string N_PREFIX[  -1,   0, 0] : 
-  8 : string N_SUFFIX[  -1,   0, 0] : 
-  9 : string NICKNAME[ n/a,   0, 0] : 
- 10 : string TITLE   [  -1,   0, 0] : 
- 11 : string FN  [  -1,   0,29] : "Калоян 
Еревинов"

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

Re: [SyncEvolution] Char encoding in syncevo config

[deloptes]

Patrick Ohly wrote:

> On Wed, 2016-03-23 at 08:39 +0100, deloptes wrote:
>> Hi all,
>> 
>> I might be too frustrated recently and might have overseen something, but
>> is there a way to set up specific char encoding in SyncEvolution
>> configuration?
>> 
>> The reason is that I have few old phones in Latin1/ISO-8859-15 and a
>> newer N9 using UTF-8
>> While N9 works fine, I get mangled ö/ä/ü in the contacts from the older
>> phones.
>> I'm just thinking how can I solve this.
> 
> The older phones presumably use vCard 2.1? 3.0 always uses UTF-8.

Yes it is vCard 2.1.

> 
> When you receive vCards from those phones and they contain data in
> ISO-8859-15, does the vCard contain a CHARSET parameter on the property
> with the non-ASCII content?

My assumption was wrong that it was not UTF (may be). It says quoted
printable/utf-8. Could be that the UTF there is misleading?

> 
> It is possible to override the default charset for specific phones. See
> "11.36.19 " in
> libsynthesis/doc/SySync_config_reference.pdf
> 
> There is an example of that in
> syncevolution/src/syncevo/configs/remoterules/server/00_sony_ericsson.xml
> 
> You can add similar .xml fragments for your phones, using manufacturer
> and model tags to limit the effect to certain phones.
> 

I attach here some snippets from the log. I see the data properly
converted/mapped to the internal fields, only I don't know at which stage
it is done. The result however in the Addressbook is not readable (for the
cyrillic) and mangled for the ö.

I'll have a look next week as the time window for private work gets closed
now.

Thanks in advance



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

[SyncEvolution] Char encoding in syncevo config

[deloptes]

Hi all,

I might be too frustrated recently and might have overseen something, but is
there a way to set up specific char encoding in SyncEvolution
configuration?

The reason is that I have few old phones in Latin1/ISO-8859-15 and a newer
N9 using UTF-8
While N9 works fine, I get mangled ö/ä/ü in the contacts from the older
phones. 
I'm just thinking how can I solve this.

regards

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

Re: [SyncEvolution] Help needed

[deloptes]

Thank you once again,

Patrick Ohly wrote:

> On Mon, 2016-02-29 at 01:34 +0100, deloptes wrote:
>> >> 
>> >> So in the LocalTransportAgent
>> >> 
>> >> we have
>> >> 
>> >> while (! m_reportSent  && m_parent && s.getState() ==
>> >> SuspendFlags::NORMAL ) {
>> >>step("waiting for parent's ACK for sync report");
>> >> }
>> >> 
>> >> which never completes.
>> > 
>> > Yes, that's where the "waiting for parent's ACK for sync report" comes
>> > from that we've seen earlier in a stack backtrace.
>> > 
>> 
>> Right before the loop it says
>> m_parent->m_storeSyncReport.start(report,
>> boost::bind(::syncReportReceived, this, _1));
>> 
>> but I do not see "sending sync report to parent" in the log
>> It looks like it never gets called or something else, so m_reportSent
>> stays false and the loop never ends. I am afraid I was wrong about this
>> previous time , or perhaps confused.
> 
> Does the parent receive the sync report? There should be a "got child
> sync report" message from LocalTransportAgent::storeSyncReport().

I'm not sure. I guess we are trying to find out. In my opinion no.

> 
> This looks like a low-level D-Bus communication problem between child
> and parent. Why that happens is a complete mystery.

Yes - mystery - my whole life has been such one :)

> 
> Did you compile with glib dbus or libdbus? Probably glib dbus, it is the
> default. Then you can enable additional debug output for that internal
> D-Bus communication with:
> G_DBUS_DEBUG=call,return,payload
> 
> Always combine that with SYNCEVOLUTION_DEBUG=1.
> 
> Watch out for a method-call to "StoreSyncReport". It should appear
> twice: once when getting send by the child, once when received by the
> parent. For that message, a corresponding method-return message should
> be sent by parent to child, again being logged twice.

This is there once (but better have a look yourself, please). I attach gz.
There is also 'method-return' and there it stops

> 
> This return message should trigger the
> LocalTransportAgentChild::syncReportReceived callback.

... but this never happens

> 
>> After I terminate I do not see this in the logs. I see "waiting for
>> parent's ACK for sync report" only in the backtrace.
>> I also do not see "child sending sync report" in the log.
>> 
>> Do you mean I should upload/attach some log (the html ones?)
> 
> I meant the text output from "SYNCEVOLUTION_DEBUG=1 syncevolution
> --daemon=no loglevel=10 ..." - the one which has the SE_LOG_DEBUG()
> output.
> 
>> > Which close() function?
>> > 
>> 
>> I mean "TrackingSyncSource::close()" implemented in the plugin.
>> 
>> If I understand correctly I should put there the logic for saving
>> changes. In open() I set the resource/database and request a ticket,
>> which would close saving all changes if only close() would have been
>> called. In the log/dbg I see open finishing but no trace of close().
>> This could be related to the above problem as well, but please confirm
>> that I understand the usage properly.
> 
> You are right. However, close() is typically called very late. It might
> be better to ensure earlier that requested changes really get written
> persistently. There's a TrackingSyncSource::flush() method for that.
> 
> /**
>  * optional: write all changes, throw error if that fails
>  *
>  * This is called while the sync is still active whereas
>  * close() is called afterwards. Reporting problems
>  * as early as possible may be useful at some point,
>  * but currently doesn't make a relevant difference.
>  */
> virtual void flush() {}
> 
> /**
>  * closes the data source so that it can be reopened
>  *
>  * Just as open() it should not affect the state of
>  * the database unless some previous action requires
>  * it.
>  */
> virtual void close() = 0;
> 

I have seen the flush function, however the tde/kde3 logic is such that it
would cleanup the pointers when ticket gets saved and in my opinion the
best is to do it in close() as opposed to open(). If all works fine it
would be sufficient, but thank you for the advise anyway.

I also added some from the html log at the end of the file with
corresponding source.
Both sides say:
"Never received status for command 'SyncHdr', (outgoing MsgID=4, CmdID=0)"
"Never received status for command 'SyncHdr', (outgoing MsgID=3, CmdID=0)"

Is this OK? It leads to  TSyncSession::InternalResetSessionEx

// reset session to inital state (new)
..

regards



syncevo_dbus.log.gz
Description: application/gzip
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] Help needed

[deloptes]

Thanks for finding time for that as well. Appreciated!

Patrick Ohly wrote:

> On Sat, 2016-02-20 at 13:32 +0100, deloptes wrote:
>> Hi Patrick, all,
>> 
>> a stupid shortcut activation got the previous mail sent incomplete.
>> 
>> So in the LocalTransportAgent
>> 
>> we have
>> 
>> while (! m_reportSent  && m_parent && s.getState() ==
>> SuspendFlags::NORMAL ) {
>>step("waiting for parent's ACK for sync report");
>> }
>> 
>> which never completes.
> 
> Yes, that's where the "waiting for parent's ACK for sync report" comes
> from that we've seen earlier in a stack backtrace.
> 

Right before the loop it says
m_parent->m_storeSyncReport.start(report,   
  
boost::bind(::syncReportReceived, this, _1));

but I do not see "sending sync report to parent" in the log
It looks like it never gets called or something else, so m_reportSent stays
false and the loop never ends. I am afraid I was wrong about this previous
time , or perhaps confused.

> 
> The sync may complete, but there's no guarantee anymore that the sending
> of the report really works, because the client may proceed before the
> parent got the report (IO not flushed).

> 
> Yes, it would be interesting to learn more about the state of the
> process when it gets stuck. Even just the full log may be useful, in
> particular the ordering of the "waiting for parent's ACK for sync
> report" entries and the "sending sync report to parent: done" (assuming
> it succeeds). See syncReportReceived() and the lines above it where it
> is used as an asynchronous completion callback.

After I terminate I do not see this in the logs. I see "waiting for parent's
ACK for sync report" only in the backtrace.
I also do not see "child sending sync report" in the log.

Do you mean I should upload/attach some log (the html ones?)

> 
> Looking at step() itself once more I am no longer sure whether it is
> really as atomic as it needs to be. The SE_LOG_DEBUG() might involve
> operations which clear the pending events such that the
> g_main_context_iteration() gets stuck.
> 
> If you remove that one SE_LOG_DEBUG() in step(), does that help?

No.

> 
> 
> Which close() function?
> 

I mean "TrackingSyncSource::close()" implemented in the plugin. 

If I understand correctly I should put there the logic for saving changes.
In open() I set the resource/database and request a ticket, which would
close saving all changes if only close() would have been called.
In the log/dbg I see open finishing but no trace of close().
This could be related to the above problem as well, but please confirm that
I understand the usage properly.

thanks again and regards


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

Re: [SyncEvolution] Help needed

[deloptes]

Hi Patrick, all,

a stupid shortcut activation got the previous mail sent incomplete.

So in the LocalTransportAgent

we have

while (! m_reportSent  && m_parent && s.getState() ==
SuspendFlags::NORMAL ) {
   step("waiting for parent's ACK for sync report");
}

which never completes.

If I however execute this one by changing 

if (! m_reportSent  && m_parent && s.getState() ==
SuspendFlags::NORMAL ) {
   step("waiting for parent's ACK for sync report");
}

it completes.
m_reportSent  should be fine. I did not go further, but I think it has to do
with the step() and m_parent / s.getState and probably the threading. If I
find something I'll post here.

The plugin runs in the snycevo-local-sync forked process. I noticed in the
above use case the close() function is not called and I don't see anywhere
(also in the html log) that it would destroy the object properly.
In the log it says however
"child process has quit with status 0"

Does it means that m_parent is not closing properly?
What is expected to happen here in this step?

thank you in advance

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

[SyncEvolution] Help needed

[deloptes]

Hi Patrick, all,

I found in the code


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

Re: [SyncEvolution] TDEPIM sync questions

[deloptes]

Patrick Ohly wrote:

> Hmm. At least that gives you something to compare the debug output
> against. I'm afraid I'm out of further ideas.

What is expected to happen when it hangs - when does this ACK is sent?

I see shutdown() is called and it is waiting to shut down. What does this
shutdown() causes - I don't feel like studing the code at the moment, but
at the end perhaps this should happen.
As I said before, all the relevant places have some TODOs that sound
related.

ideas are welcome

regards

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