From patrick.ohly at intel.com Wed Sep 7 09:37:53 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 07 Sep 2016 11:37:53 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries - dropping Akonadi support? In-Reply-To: <20160831211217.nhqooolxbpplwtaz@mac.home> References: <1471872151.24499.9.camel@intel.com> <20160831211217.nhqooolxbpplwtaz@mac.home> Message-ID: <1473241073.16248.7.camel@intel.com> 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? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Wed Sep 7 23:00:19 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 8 Sep 2016 01:00:19 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries - dropping Akonadi support? References: <1471872151.24499.9.camel@intel.com> <20160831211217.nhqooolxbpplwtaz@mac.home> <1473241073.16248.7.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Thu Sep 8 16:44:09 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 8 Sep 2016 18:44:09 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries - dropping Akonadi support? References: <1471872151.24499.9.camel@intel.com> <20160831211217.nhqooolxbpplwtaz@mac.home> <1473241073.16248.7.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Sep 8 16:57:56 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 08 Sep 2016 18:57:56 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries - dropping Akonadi support? In-Reply-To: References: <1471872151.24499.9.camel@intel.com> <20160831211217.nhqooolxbpplwtaz@mac.home> <1473241073.16248.7.camel@intel.com> Message-ID: <1473353876.29926.3.camel@intel.com> On Thu, 2016-09-08 at 18:44 +0200, deloptes wrote: > 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: > > 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 [...] Which version of Akonadi does this work with? I have a working solution for Akonadi 13.0 in Debian Jessie, but that no longer works for Akonadi 16.0 in Debian 16.0 in Debian Stretch. One difference is that the newer Akonadi, or rather the libs it is linked against, depend on being able to connect to X11. That wasn't the case before. I'm providing that now and the akonadi server starts okay (akonadiconsole works), so I think that's covered. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Thu Sep 8 19:03:23 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 8 Sep 2016 21:03:23 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries - dropping Akonadi support? References: <1471872151.24499.9.camel@intel.com> <20160831211217.nhqooolxbpplwtaz@mac.home> <1473241073.16248.7.camel@intel.com> <1473353876.29926.3.camel@intel.com> Message-ID: Patrick Ohly wrote: > > Which version of Akonadi does this work with? Last time I tried it it was jessie > > I have a working solution for Akonadi 13.0 in Debian Jessie, but that no > longer works for Akonadi 16.0 in Debian 16.0 in Debian Stretch. > > One difference is that the newer Akonadi, or rather the libs it is > linked against, depend on being able to connect to X11. That wasn't the > case before. I'm providing that now and the akonadi server starts okay > (akonadiconsole works), so I think that's covered. > But ssh -X should solve it in the case. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Sep 8 20:39:25 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 08 Sep 2016 22:39:25 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries - dropping Akonadi support? In-Reply-To: References: <1471872151.24499.9.camel@intel.com> <20160831211217.nhqooolxbpplwtaz@mac.home> <1473241073.16248.7.camel@intel.com> <1473353876.29926.3.camel@intel.com> Message-ID: <1473367165.29926.4.camel@intel.com> On Thu, 2016-09-08 at 21:03 +0200, deloptes wrote: > Patrick Ohly wrote: > > I have a working solution for Akonadi 13.0 in Debian Jessie, but that no > > longer works for Akonadi 16.0 in Debian 16.0 in Debian Stretch. > > > > One difference is that the newer Akonadi, or rather the libs it is > > linked against, depend on being able to connect to X11. That wasn't the > > case before. I'm providing that now and the akonadi server starts okay > > (akonadiconsole works), so I think that's covered. > > > > But ssh -X should solve it in the case. Yes, but it no longer seems to be enough, or something is simply broken in the more recent Akonadi. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From g+syncevolution at cobb.uk.net Thu Sep 8 22:35:11 2016 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Thu, 8 Sep 2016 23:35:11 +0100 Subject: [SyncEvolution] survey: providing SyncEvolution binaries In-Reply-To: <1471872151.24499.9.camel@intel.com> References: <1471872151.24499.9.camel@intel.com> Message-ID: On 22/08/16 14:22, Patrick Ohly wrote: > So let me ask: which distro do you need syncevolution.org binaries for? > Why? I meant to reply to this before. May not be needed now as you seem to have decided to build for Jessie and Stretch anyway... I find it useful to have precompiled binaries for Debian stable (my production system) and Debian testing (my development system). Of course, Tino provides packages but I have sometimes found it useful to be able to use your latest build before they have appeared in the distribution. I build my own versions when I am doing development. But I still find it convenient to have a "standard" version installed so I can compare behaviour :-) And just knowing that it is building for you is very helpful when it isn't building for me! So, I could certainly live without your builds -- Tino's packages would normally meet my needs and I could always build if I needed to. But I do use your versions and appreciate having them available. Graham From patrick.ohly at intel.com Fri Sep 9 10:40:19 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 09 Sep 2016 12:40:19 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries In-Reply-To: References: <1471872151.24499.9.camel@intel.com> Message-ID: <1473417619.14984.2.camel@intel.com> On Thu, 2016-09-08 at 23:35 +0100, Graham Cobb wrote: > On 22/08/16 14:22, Patrick Ohly wrote: > > So let me ask: which distro do you need syncevolution.org binaries for? > > Why? > > I meant to reply to this before. May not be needed now as you seem to > have decided to build for Jessie and Stretch anyway... Not at all, it is a useful data point and in fact, it reminds me that I need to enable also building activesyncd for Stretch. > I find it useful to have precompiled binaries for Debian stable (my > production system) and Debian testing (my development system). I'm using the binaries for Debian stable myself, so I know what you mean and certainly want to keep those around. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From tino.keitel+syncevolution at tikei.de Tue Sep 13 18:58:14 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Tue, 13 Sep 2016 20:58:14 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries In-Reply-To: <1471872151.24499.9.camel@intel.com> References: <1471872151.24499.9.camel@intel.com> Message-ID: <20160913185814.l2effqh3bcdkya5j@mac.home> On Mon, Aug 22, 2016 at 15:22:31 +0200, Patrick Ohly wrote: > Debian Stable, which only has an old version (1.4.99). Hi, I just remembered that one reason for that somewhat ugly version in Jessie was that the 1.5 release came slightly after the freeze for Jessie. So FYI the current roadmap for Stretch says "Q3 2016: Please finish up things for Stretch" with the first freeze (for library transitions) scheduled for November 5th. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Wed Sep 21 08:18:05 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Wed, 21 Sep 2016 10:18:05 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries In-Reply-To: <20160913185814.l2effqh3bcdkya5j@mac.home> References: <1471872151.24499.9.camel@intel.com> <20160913185814.l2effqh3bcdkya5j@mac.home> Message-ID: <20160921081805.GA10850@eazy.amigager.de> On Tue, Sep 13, 2016 at 20:58:14 +0200, Tino Mettler wrote: > On Mon, Aug 22, 2016 at 15:22:31 +0200, Patrick Ohly wrote: > > Debian Stable, which only has an old version (1.4.99). > > Hi, > > I just remembered that one reason for that somewhat ugly version in > Jessie was that the 1.5 release came slightly after the freeze for > Jessie. So FYI the current roadmap for Stretch says "Q3 2016: Please finish up things for > Stretch" with the first freeze (for library transitions) scheduled for > November 5th. Hi Patrick, may I assume that nothing release-ish is scheduled for the next few months? Otherwise it would be nice to be as recent as possible regarding the version in Debian when the freeze starts. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Sep 21 09:09:43 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 21 Sep 2016 11:09:43 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries In-Reply-To: <20160921081805.GA10850@eazy.amigager.de> References: <1471872151.24499.9.camel@intel.com> <20160913185814.l2effqh3bcdkya5j@mac.home> <20160921081805.GA10850@eazy.amigager.de> Message-ID: <1474448983.8363.18.camel@intel.com> On Wed, 2016-09-21 at 10:18 +0200, Tino Mettler wrote: > may I assume that nothing release-ish is scheduled for the next few > months? Otherwise it would be nice to be as recent as possible > regarding the version in Debian when the freeze starts. Quite the opposite, I am determined to finally get a 1.5.2 out ;-} I might have some pre-release binaries for testing this week or early next week. Thanks for reminding me about the Stretch release deadline. This is indeed valuable information. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From tino.keitel+syncevolution at tikei.de Wed Sep 21 12:05:27 2016 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Wed, 21 Sep 2016 14:05:27 +0200 Subject: [SyncEvolution] survey: providing SyncEvolution binaries In-Reply-To: <1474448983.8363.18.camel@intel.com> References: <1471872151.24499.9.camel@intel.com> <20160913185814.l2effqh3bcdkya5j@mac.home> <20160921081805.GA10850@eazy.amigager.de> <1474448983.8363.18.camel@intel.com> Message-ID: <20160921120527.GA9214@eazy.amigager.de> On Wed, Sep 21, 2016 at 11:09:43 +0200, Patrick Ohly wrote: > On Wed, 2016-09-21 at 10:18 +0200, Tino Mettler wrote: > > may I assume that nothing release-ish is scheduled for the next few > > months? Otherwise it would be nice to be as recent as possible > > regarding the version in Debian when the freeze starts. > > Quite the opposite, I am determined to finally get a 1.5.2 out ;-} > I might have some pre-release binaries for testing this week or early > next week. Hi, I would like to know about the relevant git tags for syncevolution and libsynthesis when this happens, and also when the tags are moved due to late changes (which at least happened in the past). Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Thu Sep 29 12:45:00 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 29 Sep 2016 14:45:00 +0200 Subject: Release preparations for 1.5.2 Message-ID: <1475153100.11658.12.camel@intel.com> Hello! 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 Before I tag and release this as 1.5.2, it would be great to get some feedback that this release doesn't cause regressions. In particular, syncing with phones over Bluetooth needs some testing because there has been one change that I couldn't fully test myself (only seems to make a difference with some phones). Note that this release no longer has .rpm archives, mostly due to some technical problems creating them and because it is uncertain whether anyone uses them. So if you are a SyncEvolution user on rpm-based distros and you need those rpms, then I'd like to hear from you. In the meantime, do the binaries included in the .tar.gz files work on your distro? Regarding changes, here's the current draft of the NEWS entry: SyncEvolution 1.5.1 -> 1.5.2, xxxxxxxxxx ======================================== Maintenance release. syncevolution.org binaries are now getting compiled for distros >= Ubuntu Trusty 14.04 LTS, which allowed removing several hacks that were needed when building binaries that also had to run on older distros. Compilation from source for old distros should still work as before, but is not getting tested anymore. Compile problems with recent libraries (libical v2) and tools (GCC v6) were resolved. Syncing via Bluetooth with certain phones now should work reliably in incremental mode. Details: * ObexTransportAgent.cpp: properly shut down connection (FDO #91485) Apparently there's a race condition in the OBEX transport that causes the connection to phones via Bluetooth to be shut down prematurely. Some phones react by doing a slow sync instead of an incremental sync the next time. * support non-readable parent directories (FDO #91000) The previous mkdir_p() walked down top to bottom and checked each path entry as it went along. That approach failed unnecessarily when some existing parent directory could not be read (non-readable /home, for example). * avoid using dbus-launch (Debian #836399) dbus-launch is considered deprecated because of the X11 dependency. See https://lists.debian.org/debian-devel/2016/08/msg00554.html "Mass bug filing: use and misuse of dbus-launch (dbus-x11)" The dbus-session.sh script still needs to start the D-Bus daemon when used in the nightly testing, so the code now does it by invoking the dbus-daemon directly. syncevo-http-server still has some usage of dbus-launch left, but that's strictly for systems which don't have the more modern D-Bus. * syncevo-dbus-server integrates better with systemd (FDO #92164) A .service file allows the D-Bus daemon to start the service via systemd, thus ensuring that the process environment is correct. Patch from Simon McVittie. Auto-starting as part of the desktop login uses D-Bus activation if the "dbus-send" tool is installed. * syncevolution.org: compile on Ubuntu Trusty, libical v1/v2 compatibility syncevolution.org binaries are now getting compiled on Ubuntu Trusty and thus no longer support distros with older EDS. The code should still compile against older EDS (for example, for Maemo), but that is not getting tested anymore. This allows removing the dynamic linker hacks related to older libraries, which was only used in those binaries. Instead, backends using libical or EDS get compiled on Ubuntu Trusty and then the soname of those libs get patched to make the backend module usable in combination with a different set of libs. That patching is part of a script maintained in the syncevolution.org build infrastructure. This approach was already used before to generate different EDS backends for EDS versions with the newer EClient API, because that turned out to be easier than the dynamic loading approach. It works because none of the methods used by SyncEvolution changed their ABI, only some other parts of the libraries did. Should there ever be a situation again that cannot be handled like this, then backends also get compiled on different distros than Ubuntu Trusty (for example, the ActiveSync backend for Debian Stretch is built on Debian Stretch). libical still requires one special hack: system time zone loading in libical v1 (and only in that version, v2 has builtin support again) must be overridden such that time zones are generated with rules instead of transitions because that is more compatible with the peers that SyncEvolution exchanges data with. That hack now relies on overriding the two relevant functions inside the main binaries (has to be there, otherwise libical still ends up calling its own internal implementation). The overriding code is in libsyncevo-icaltz-util.so.0 and depends on libical.so.1. If libsyncevo-icaltz-util.so.0 can be loaded, the wrappers in the main binary use it, otherwise they fall through to the code from the current libical.so, which then should be libical.so.2 or more recent. This hack is active by default when libical v1 is detected during configuration. * optionally show debug output in --version output SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --version now dumps also the debug information gathered by the binary compatibility code. It was only available in sync logs before. * various build fixes for libical v2, GCC v6/C++14 -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Thu Sep 29 21:50:03 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 29 Sep 2016 23:50:03 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Sep 30 06:02:32 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 30 Sep 2016 08:02:32 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: References: <1475153100.11658.12.camel@intel.com> Message-ID: <1475215352.13953.3.camel@intel.com> 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Fri Sep 30 06:10:57 2016 From: deloptes at gmail.com (deloptes) Date: Fri, 30 Sep 2016 08:10:57 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> <1475215352.13953.3.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From mcrha at redhat.com Fri Sep 30 11:23:18 2016 From: mcrha at redhat.com (Milan Crha) Date: Fri, 30 Sep 2016 13:23:18 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475153100.11658.12.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> Message-ID: <1475234598.2147.2.camel@redhat.com> On Thu, 2016-09-29 at 14:45 +0200, Patrick Ohly wrote: > Before I tag and release this as 1.5.2, it would be great to get some > feedback that this release doesn't cause regressions. Hi, I cannot speak for runtime, but I was able to build the tarballs in Fedora rawhide without any issue, more than that, I could remove the gcc6 patch which Fedora uses. Thus looks fine here from the build point of view. Bye, Milan _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Fri Sep 30 11:37:30 2016 From: deloptes at gmail.com (deloptes) Date: Fri, 30 Sep 2016 13:37:30 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 References: <1475153100.11658.12.camel@intel.com> Message-ID: Patrick Ohly wrote: > http://downloads.syncevolution.org/syncevolution. Look for version > 1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa > > Before I tag and release this as 1.5.2, it would be great to get some > feedback that this release doesn't cause regressions. In particular, > syncing with phones over Bluetooth needs some testing because there has > been one change that I couldn't fully test myself (only seems to make a > difference with some phones). Debian Jessie with TDE worked great with Nokia N9 via bluetooth. I will test with 5530 over the weekend. If you have some description how this bluetooth issue can be reproduced, I could do some more specific testing as I am using syncevolution only with bluetooth. I've been seeing 415 error in slow sync, but never got time to look into it in detail - what is exactly 415. Might be result of the NEEDS_MERGE issue we discussed before. regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Sep 30 12:01:01 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 30 Sep 2016 14:01:01 +0200 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: References: <1475153100.11658.12.camel@intel.com> Message-ID: <1475236861.13953.8.camel@intel.com> On Fri, 2016-09-30 at 13:37 +0200, deloptes wrote: > Patrick Ohly wrote: > > > http://downloads.syncevolution.org/syncevolution. Look for version > > 1.5.1+20160926+SE+8fccc44+unclean+SYSYNC+59b55aa > > > > Before I tag and release this as 1.5.2, it would be great to get some > > feedback that this release doesn't cause regressions. In particular, > > syncing with phones over Bluetooth needs some testing because there has > > been one change that I couldn't fully test myself (only seems to make a > > difference with some phones). > > Debian Jessie with TDE worked great with Nokia N9 via bluetooth. > I will test with 5530 over the weekend. > > If you have some description how this bluetooth issue can be reproduced, I > could do some more specific testing as I am using syncevolution only with > bluetooth. See https://bugs.freedesktop.org/show_bug.cgi?id=91485 It seems to depend both on timing (sleeping helped) and the specific phone (my Nokia phone didn't care either way). Perhaps that explains why there haven't been more complaints about unexpected slow syncs with phones. Because the issue probably can't be reproduced except by the original reporter (who's gone silent), I'm mostly interested in confirmation from other users that the fix doesn't introduce any regressions. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From james at laird-wah.net Fri Sep 30 12:14:07 2016 From: james at laird-wah.net (James Laird-Wah) Date: Fri, 30 Sep 2016 22:14:07 +1000 Subject: [SyncEvolution] Release preparations for 1.5.2 In-Reply-To: <1475236861.13953.8.camel@intel.com> References: <1475153100.11658.12.camel@intel.com> <1475236861.13953.8.camel@intel.com> Message-ID: On 30 September 2016 10:01:01 PM AEST, Patrick Ohly wrote: >Because the issue probably can't be reproduced except by the original >reporter (who's gone silent), I'm mostly interested in confirmation >from >other users that the fix doesn't introduce any regressions. My apologies for not responding to the freedesktop bug update. I no longer have that phone in my possession, so I'm not able to test. Thank you very much for following this to the end; I hope it benefits some others. - James From deloptes at gmail.com Mon Sep 12 22:26:06 2016 From: deloptes at gmail.com (deloptes) Date: Tue, 13 Sep 2016 00:26:06 +0200 Subject: [SyncEvolution] Explicit type 'text/x-vcalendar' specified in command or item meta Message-ID: 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 at 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Sep 13 06:42:33 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 13 Sep 2016 08:42:33 +0200 Subject: [SyncEvolution] Explicit type 'text/x-vcalendar' specified in command or item meta In-Reply-To: References: Message-ID: <1473748953.498.15.camel@intel.com> 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Tue Sep 13 07:03:23 2016 From: deloptes at gmail.com (deloptes) Date: Tue, 13 Sep 2016 09:03:23 +0200 Subject: [SyncEvolution] Explicit type 'text/x-vcalendar' specified in command or item meta References: <1473748953.498.15.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Tue Sep 13 23:41:49 2016 From: deloptes at gmail.com (deloptes) Date: Wed, 14 Sep 2016 01:41:49 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> Message-ID: 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 &luid, const std::string &item, 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Sep 14 06:21:22 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 14 Sep 2016 08:21:22 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> Message-ID: <1473834082.6143.4.camel@intel.com> 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 --sync 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Wed Sep 14 06:21:43 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 14 Sep 2016 08:21:43 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> Message-ID: <1473834103.6143.5.camel@intel.com> 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Mon Sep 26 21:01:08 2016 From: deloptes at gmail.com (deloptes) Date: Mon, 26 Sep 2016 23:01:08 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Sep 27 06:08:04 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 27 Sep 2016 08:08:04 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> Message-ID: <1474956484.31518.1.camel@intel.com> On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote: > 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. 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Tue Sep 27 06:57:58 2016 From: deloptes at gmail.com (deloptes) Date: Tue, 27 Sep 2016 08:57:58 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> Message-ID: 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 Thanks _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Sep 28 09:24:14 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 28 Sep 2016 11:24:14 +0200 Subject: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta) In-Reply-To: References: <1473748953.498.15.camel@intel.com> <1473834103.6143.5.camel@intel.com> <1474956484.31518.1.camel@intel.com> Message-ID: <1475054654.7488.16.camel@intel.com> 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From renato.filho at canonical.com Tue Sep 27 21:56:46 2016 From: renato.filho at canonical.com (Renato Filho) Date: Tue, 27 Sep 2016 18:56:46 -0300 Subject: [SyncEvolution] Events updated with all contacts as attendee Message-ID: Hi All, During the last weeks we received some reports of people that complain that some random events that was not edited or create recently got modified, and all the contacts of the event owner got added into the attendee list of this event. Do you guys have noticed some similar? Any idea what could cause that? How this could be possible? BR Renato _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Sep 28 06:09:38 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 28 Sep 2016 08:09:38 +0200 Subject: [SyncEvolution] Events updated with all contacts as attendee In-Reply-To: References: Message-ID: <1475042978.7488.13.camel@intel.com> On Tue, 2016-09-27 at 18:56 -0300, Renato Filho wrote: > Hi All, > > During the last weeks we received some reports of people that complain > that some random events that was not edited or create recently got > modified, and all the contacts of the event owner got added into the > attendee list of this event. > > Do you guys have noticed some similar? Any idea what could cause that? > How this could be possible? I've not heard of this before. Where are the events stored, i.e. which server? I can say for sure that SyncEvolution strictly separates calendar and contact synchronization: the SyncEvolution code dealing with events does not know anything about "the contacts of the event owner" (or any contacts at all) and therefore cannot break an event in the way that you described. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From renato.filho at canonical.com Wed Sep 28 12:18:45 2016 From: renato.filho at canonical.com (Renato Filho) Date: Wed, 28 Sep 2016 09:18:45 -0300 Subject: [SyncEvolution] Events updated with all contacts as attendee In-Reply-To: <1475042978.7488.13.camel@intel.com> References: <1475042978.7488.13.camel@intel.com> Message-ID: Hi Patrick, The events are stored on google, and for some reason all the contacts (not local contacts) that the user have ever sent a e-mail is added on the event as attendee. The users reported that the event description had changed too with description from other event. I am guessing that the event is getting corrupted during the sync and for some reason google is adding all contacts into the event. 2016-09-28 3:09 GMT-03:00 Patrick Ohly : > On Tue, 2016-09-27 at 18:56 -0300, Renato Filho wrote: >> Hi All, >> >> During the last weeks we received some reports of people that complain >> that some random events that was not edited or create recently got >> modified, and all the contacts of the event owner got added into the >> attendee list of this event. >> >> Do you guys have noticed some similar? Any idea what could cause that? >> How this could be possible? > > I've not heard of this before. Where are the events stored, i.e. which > server? > > I can say for sure that SyncEvolution strictly separates calendar and > contact synchronization: the SyncEvolution code dealing with events does > not know anything about "the contacts of the event owner" (or any > contacts at all) and therefore cannot break an event in the way that you > described. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > > From patrick.ohly at intel.com Wed Sep 21 08:09:20 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 21 Sep 2016 10:09:20 +0200 Subject: [SyncEvolution] Syncevolution --print-databases - Akonadi stuck In-Reply-To: <1454397541.14370.13.camel@intel.com> References: <1627825.lz3JYRGpPR@delle5450> <1451764135.23712.21.camel@intel.com> <3863546.ztQrUHjVRk@domowy> <1918523.tfbDFjU8S3@domowy> <1454397541.14370.13.camel@intel.com> Message-ID: <1474445360.8363.14.camel@intel.com> On Tue, 2016-02-02 at 08:19 +0100, Patrick Ohly wrote: > On Fri, 2016-01-29 at 00:10 +0100, Janusz wrote: > > Any chance to get it working ? > > Not yet. I started, but there's been so much ABI breakage in recent > distros that I'm not yet sure how to handle it. I've finally (at last - sorry for the long time that it took!) updated the automatic testing to be based on more recent distros. > > Should I do more tests ? > > No, I can test myself now. And I can reproduce the problem: https://bugs.freedesktop.org/show_bug.cgi?id=97609 Unfortunately I have no idea what's causing it. Looks like a bug in the Akonadi client libraries to me. The next step would be to write a simpler, stand-alone test program which demonstrates the problem and get help from the KDE developers. Janusz, are you still interested in a solution? Just bringing it up with the KDE folks would already help. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From janumix at poczta.fm Wed Sep 21 11:09:53 2016 From: janumix at poczta.fm (Janusz) Date: Wed, 21 Sep 2016 13:09:53 +0200 Subject: [SyncEvolution] Syncevolution --print-databases - Akonadi stuck In-Reply-To: <1474445360.8363.14.camel@intel.com> References: <1627825.lz3JYRGpPR@delle5450> <1454397541.14370.13.camel@intel.com> <1474445360.8363.14.camel@intel.com> Message-ID: <8678245.NQZRTFWsQd@delle5450> Dnia ?roda, 21 wrze?nia 2016 10:09:20 CEST Patrick Ohly: > On Tue, 2016-02-02 at 08:19 +0100, Patrick Ohly wrote: > > On Fri, 2016-01-29 at 00:10 +0100, Janusz wrote: > > > Any chance to get it working ? > > > > Not yet. I started, but there's been so much ABI breakage in recent > > distros that I'm not yet sure how to handle it. > > I've finally (at last - sorry for the long time that it took!) updated > the automatic testing to be based on more recent distros. > > > > Should I do more tests ? > > > > No, I can test myself now. > > And I can reproduce the problem: > https://bugs.freedesktop.org/show_bug.cgi?id=97609 > > Unfortunately I have no idea what's causing it. Looks like a bug in the > Akonadi client libraries to me. > > The next step would be to write a simpler, stand-alone test program > which demonstrates the problem and get help from the KDE developers. > Janusz, are you still interested in a solution? Just bringing it up with > the KDE folks would already help. Hi Patrick Nice to see that ! Honestly not so much - I already put on ownClud+CardDAV client, however I'm still able to test syncevolution on demand (but not do any coding). I'll stay tuned if you need some checking. BR Janusz From patrick.ohly at intel.com Thu Sep 22 18:15:12 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 22 Sep 2016 20:15:12 +0200 Subject: [SyncEvolution] Syncevolution --print-databases - Akonadi stuck In-Reply-To: <8678245.NQZRTFWsQd@delle5450> References: <1627825.lz3JYRGpPR@delle5450> <1454397541.14370.13.camel@intel.com> <1474445360.8363.14.camel@intel.com> <8678245.NQZRTFWsQd@delle5450> Message-ID: <1474568112.16834.102.camel@intel.com> On Wed, 2016-09-21 at 13:09 +0200, Janusz wrote: > Dnia ?roda, 21 wrze?nia 2016 10:09:20 CEST Patrick Ohly: > > And I can reproduce the problem: > > https://bugs.freedesktop.org/show_bug.cgi?id=97609 > > > > Unfortunately I have no idea what's causing it. Looks like a bug in the > > Akonadi client libraries to me. > > > > The next step would be to write a simpler, stand-alone test program > > which demonstrates the problem and get help from the KDE developers. > > Janusz, are you still interested in a solution? Just bringing it up with > > the KDE folks would already help. > > Hi Patrick > > Nice to see that ! > Honestly not so much - I already put on ownClud+CardDAV client, however I'm > still able to test syncevolution on demand (but not do any coding). > I'll stay tuned if you need some checking. I've reported it upstream to the KDE folks at https://bugs.kde.org/show_bug.cgi?id=369203 with a stand-alone test program. Unless they have questions, there's nothing that we need to do for the time being. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From janumix at poczta.fm Fri Sep 23 12:34:12 2016 From: janumix at poczta.fm (Janusz) Date: Fri, 23 Sep 2016 14:34:12 +0200 Subject: [SyncEvolution] Syncevolution --print-databases - Akonadi stuck In-Reply-To: <1474568112.16834.102.camel@intel.com> References: <1627825.lz3JYRGpPR@delle5450> <8678245.NQZRTFWsQd@delle5450> <1474568112.16834.102.camel@intel.com> Message-ID: <3499367.1eFLE2gOG9@delle5450> > On Wed, 2016-09-21 at 13:09 +0200, Janusz wrote: > > Dnia ?roda, 21 wrze?nia 2016 10:09:20 CEST Patrick Ohly: > > > And I can reproduce the problem: > > > https://bugs.freedesktop.org/show_bug.cgi?id=97609 > > > > > > Unfortunately I have no idea what's causing it. Looks like a bug in the > > > Akonadi client libraries to me. > > > > > > The next step would be to write a simpler, stand-alone test program > > > which demonstrates the problem and get help from the KDE developers. > > > Janusz, are you still interested in a solution? Just bringing it up with > > > the KDE folks would already help. > > > > Hi Patrick > > > > Nice to see that ! > > Honestly not so much - I already put on ownClud+CardDAV client, however > > I'm > > still able to test syncevolution on demand (but not do any coding). > > I'll stay tuned if you need some checking. > > I've reported it upstream to the KDE folks at > https://bugs.kde.org/show_bug.cgi?id=369203 with a stand-alone test > program. Unless they have questions, there's nothing that we need to do > for the time being. Thank for support. As soon as they fix it I could test it. I'll stay tuned. From patrick.ohly at intel.com Fri Sep 9 10:50:51 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 09 Sep 2016 12:50:51 +0200 Subject: [SyncEvolution] Build failure with gcc 6 In-Reply-To: <1467808928.6818.24.camel@intel.com> References: <20160706122740.GA26454@mac.home> <1467808928.6818.24.camel@intel.com> Message-ID: <1473418251.14984.4.camel@intel.com> On Wed, 2016-07-06 at 14:42 +0200, Patrick Ohly wrote: > On Wed, 2016-07-06 at 14:27 +0200, Tino Mettler wrote: > > Hi Patrick, > > > > 1.5.1 fails to build with GCC 6 [1], which makes it unsuitable for > > Debian testing in the current state. From looking at the > > freedesktop.org git web interface, I don't see any branches with newer > > code that was fixed regarding this issue. Do you have any plans for > > this? > > Isn't it possible to compile when asking explicitly for an older C++ > version than the one used by g++ by default? > > I was aware of the need for changes to compile with default options, but > haven't had time for that yet. The next release will build also when compiling it as C++11. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Fri Sep 9 09:34:36 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 09 Sep 2016 11:34:36 +0200 Subject: davical: backslash escaping sometimes broken in vCard Message-ID: <1473413676.14707.2.camel@intel.com> Package: davical Version: 1.1.4-3 Severity: normal Dear DAViCal maintainers, I've recently updated the SyncEvolution test setup such that it runs tests against DAVICal 1.1.4-3 from Debian Testing and noticed a problem that I had not seen before: when storing certain vCards on the server and retrieving them again, backslashes in the NOTE property (and perhaps elsewhere) are getting modified incorrectly. This only happens for vCards which have no REV property. Normally SyncEvolution includes a REV property when syncing, so this might only affect testing and perhaps some users who use the command line to import contacts into DAViCal directly. I'm more concerned about not-yet-known cases where this decoding/encoding on the server-side happens. testcases/carddav.vcf | Client_Source_davical_carddav_testImport.B.test.dat only in left file < > only in right file ------------------------------------------------------------------------------- BEGIN:VCARD BEGIN:VCARD N:2;;;user N:2;;;user FN:user 2 FN:user 2 NOTE:This user tests some of the adva NOTE:This user tests some of the adva nced aspects of vcards:\n- non-ASCII nced aspects of vcards:\n- non-ASCII characters (with umlauts in the name) characters (with umlauts in the name) \n- line break (in this note and the \n- line break (in this note and the mailing address)\n- long lines (in th mailing address)\n- long lines (in th is note)\n- special characters (in th is note)\n- special characters (in th is note)\n- tabs (in this note)\n\nVe is note)\n- tabs (in this note)\n\nVe ry long line\, very very long this ti ry long line\, very very long this ti me... still not finished... blah blah me... still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 8 9 10 blah blah blah 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \\\n\nThe | :\nsemicolon \;\nbackslash \\n\nThe s same\, in the middle of a line:\ncomm | ame\, in the middle of a line:\ncomma a \, comma\ncolon : colon\nsemicolon | \, comma\ncolon : colon\nsemicolon \ \; semicolon\nbackslash \\ backslash\ | ; semicolon\nbackslash \ backslash\n\ n\nA tab tab done\n line starts with | nA tab tab done\n line starts with t tab | ab VERSION:3.0 VERSION:3.0 END:VCARD END:VCARD ------------------------------------------------------------------------------- Note that the \\ gets replaced with a single \. My two testcases are: BEGIN:VCARD VERSION:3.0 UID:unique-id-user2 NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCII c haracters (with umlauts in the name)\n- line break (in this note and the mailing address)\n- long lines (in this note)\n- special characters (in this note)\n- tabs (in this note)\n\nVery long line\, very very long th is time... still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \\\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col on\nsemicolon \; semicolon\nbackslash \\ backslash\n\nA tab tab done\n line starts with tab FN:user 2 N:2;;;user; END:VCARD BEGIN:VCARD VERSION:3.0 REV:20160908T170847Z UID:syuid288166.212340157754280 N:1;;;user; FN:user 1 NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCII c haracters (with umlauts in the name)\n- line break (in this note and the ma iling address)\n- long lines (in this note)\n- special characters (in this note)\n- tabs (in this note)\n\nVery long line\, very very long this time.. . still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \\\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : colon\nsemicolon \; semi colon\nbackslash \\ backslash\n\nA tab tab done\n line starts with tab END:VCARD Content of NOTE gets mangled for the first vCard, but not the second. Here's the relevant excerpt of the CardDAV communication: [DEVELOPER 00:00:01] stderr: POST /davical/caldav.php/tester2/Test_davical_carddav_1/?add_member HTTP/1.1 [DEVELOPER 00:00:01] stderr: Connection: TE [DEVELOPER 00:00:01] stderr: TE: trailers [DEVELOPER 00:00:01] stderr: Host: localhost:9009 [DEVELOPER 00:00:01] stderr: Content-Length: 704 [DEVELOPER 00:00:01] stderr: Content-Type: text/vcard; charset=utf-8 [DEVELOPER 00:00:01] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:01] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: Sending request-line and headers: [DEVELOPER 00:00:01] stderr: Sending request body: [DEVELOPER 00:00:01] stderr: Body block (704 bytes): [DEVELOPER 00:00:01] stderr: [BEGIN:VCARD [DEVELOPER 00:00:01] stderr: VERSION:3.0 [DEVELOPER 00:00:01] stderr: UID:unique-id-user2 [DEVELOPER 00:00:01] stderr: NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCII c [DEVELOPER 00:00:01] stderr: haracters (with umlauts in the name)\n- line break (in this note and the [DEVELOPER 00:00:01] stderr: mailing address)\n- long lines (in this note)\n- special characters (in [DEVELOPER 00:00:01] stderr: this note)\n- tabs (in this note)\n\nVery long line\, very very long th [DEVELOPER 00:00:01] stderr: is time... still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 [DEVELOPER 00:00:01] stderr: 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash [DEVELOPER 00:00:01] stderr: \\\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col [DEVELOPER 00:00:01] stderr: on\nsemicolon \; semicolon\nbackslash \\ backslash\n\nA tab tab done\n [DEVELOPER 00:00:01] stderr: line starts with tab [DEVELOPER 00:00:01] stderr: FN:user 2 [DEVELOPER 00:00:01] stderr: N:2;;;user; [DEVELOPER 00:00:01] stderr: END:VCARD [DEVELOPER 00:00:01] stderr: ] [DEVELOPER 00:00:01] stderr: Request sent; retry is 1. [DEVELOPER 00:00:01] stderr: [status-line] < HTTP/1.1 201 Created [DEVELOPER 00:00:01] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:01] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:01] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:01] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:01] stderr: [hdr] Location: http://localhost:9009/davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf [DEVELOPER 00:00:01] stderr: Header Name: [location], Value: [http://localhost:9009/davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf] [DEVELOPER 00:00:01] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:01] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:01] stderr: [hdr] Content-type: text/plain; charset="utf-8" [DEVELOPER 00:00:01] stderr: Header Name: [content-type], Value: [text/plain; charset="utf-8"] [DEVELOPER 00:00:01] stderr: [hdr] Content-Length: 0 [DEVELOPER 00:00:01] stderr: Header Name: [content-length], Value: [0] [DEVELOPER 00:00:01] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:26 GMT [DEVELOPER 00:00:01] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:26 GMT] [DEVELOPER 00:00:01] stderr: [hdr] [DEVELOPER 00:00:01] stderr: End of headers. [DEVELOPER 00:00:01] stderr: Running post_headers hooks [DEVELOPER 00:00:01] stderr: Running post_send hooks [DEVELOPER 00:00:01] stderr: ah_post_send (#0), code is 201 (want 401), WWW-Authenticate is (none) [DEVELOPER 00:00:01] stderr: Request ends, status 201 class 2xx, error line: [DEVELOPER 00:00:01] stderr: 201 Created [DEBUG 00:00:01] add item status: [DEBUG 00:00:01] new item mapped to unique-id-user2.vcf [DEVELOPER 00:00:01] stderr: Running destroy hooks. [DEVELOPER 00:00:01] stderr: Request ends. [DEBUG 00:00:01] starting PROPFIND, credentials unverified, deadline in 120.0s [DEVELOPER 00:00:01] stderr: ah_create, for WWW-Authenticate [DEVELOPER 00:00:01] stderr: Running pre_send hooks [DEVELOPER 00:00:01] stderr: auth: Sending 'Basic' response. [DEVELOPER 00:00:01] stderr: Sending request headers: [DEVELOPER 00:00:01] stderr: PROPFIND /davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf HTTP/1.1 [DEVELOPER 00:00:01] stderr: Connection: TE [DEVELOPER 00:00:01] stderr: TE: trailers [DEVELOPER 00:00:01] stderr: Host: localhost:9009 [DEVELOPER 00:00:01] stderr: Depth: 0 [DEVELOPER 00:00:01] stderr: Content-Length: 141 [DEVELOPER 00:00:01] stderr: Content-Type: application/xml [DEVELOPER 00:00:01] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:01] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: Sending request-line and headers: [DEVELOPER 00:00:01] stderr: Sending request body: [DEVELOPER 00:00:01] stderr: Body block (141 bytes): [DEVELOPER 00:00:01] stderr: [ [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: ] [DEVELOPER 00:00:01] stderr: Request sent; retry is 1. [DEVELOPER 00:00:01] stderr: [status-line] < HTTP/1.1 207 Multi-status [DEVELOPER 00:00:01] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:01] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:01] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:01] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:01] stderr: [hdr] ETag: "4edfcd770d60600fc5ca057f62567d8c" [DEVELOPER 00:00:01] stderr: Header Name: [etag], Value: ["4edfcd770d60600fc5ca057f62567d8c"] [DEVELOPER 00:00:01] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:01] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:01] stderr: [hdr] Content-type: text/xml; charset="utf-8" [DEVELOPER 00:00:01] stderr: Header Name: [content-type], Value: [text/xml; charset="utf-8"] [DEVELOPER 00:00:01] stderr: [hdr] Content-Length: 355 [DEVELOPER 00:00:01] stderr: Header Name: [content-length], Value: [355] [DEVELOPER 00:00:01] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:26 GMT [DEVELOPER 00:00:01] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:26 GMT] [DEVELOPER 00:00:01] stderr: [hdr] [DEVELOPER 00:00:01] stderr: End of headers. [DEVELOPER 00:00:01] stderr: Running post_headers hooks [DEVELOPER 00:00:01] stderr: Reading 355 bytes of response body. [DEVELOPER 00:00:01] stderr: Got 355 bytes. [DEVELOPER 00:00:01] stderr: Read block (355 bytes): [DEVELOPER 00:00:01] stderr: [ [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: "85c7cfd93c7303d3b938c87edcd27102" [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: HTTP/1.1 200 OK [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: ] [DEBUG 00:00:01] item unique-id-user2.vcf = rev 85c7cfd93c7303d3b938c87edcd27102 ... [DEVELOPER 00:00:01] stderr: POST /davical/caldav.php/tester2/Test_davical_carddav_1/?add_member HTTP/1.1 [DEVELOPER 00:00:01] stderr: Connection: TE [DEVELOPER 00:00:01] stderr: TE: trailers [DEVELOPER 00:00:01] stderr: Host: localhost:9009 [DEVELOPER 00:00:01] stderr: Content-Length: 735 [DEVELOPER 00:00:01] stderr: Content-Type: text/vcard; charset=utf-8 [DEVELOPER 00:00:01] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:01] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: Sending request-line and headers: [DEVELOPER 00:00:01] stderr: Sending request body: [DEVELOPER 00:00:01] stderr: Body block (735 bytes): [DEVELOPER 00:00:01] stderr: [BEGIN:VCARD [DEVELOPER 00:00:01] stderr: VERSION:3.0 [DEVELOPER 00:00:01] stderr: REV:20160908T170847Z [DEVELOPER 00:00:01] stderr: UID:syuid288166.212340157754280 [DEVELOPER 00:00:01] stderr: N:1;;;user; [DEVELOPER 00:00:01] stderr: FN:user 1 [DEVELOPER 00:00:01] stderr: NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCII c [DEVELOPER 00:00:01] stderr: haracters (with umlauts in the name)\n- line break (in this note and the ma [DEVELOPER 00:00:01] stderr: iling address)\n- long lines (in this note)\n- special characters (in this [DEVELOPER 00:00:01] stderr: note)\n- tabs (in this note)\n\nVery long line\, very very long this time.. [DEVELOPER 00:00:01] stderr: . still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 8 9 10 11 12 [DEVELOPER 00:00:01] stderr: 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \\\n\nThe same\, [DEVELOPER 00:00:01] stderr: in the middle of a line:\ncomma \, comma\ncolon : colon\nsemicolon \; semi [DEVELOPER 00:00:01] stderr: colon\nbackslash \\ backslash\n\nA tab tab done\n line starts with tab [DEVELOPER 00:00:01] stderr: END:VCARD [DEVELOPER 00:00:01] stderr: ] [DEVELOPER 00:00:01] stderr: Request sent; retry is 1. [DEVELOPER 00:00:01] stderr: [status-line] < HTTP/1.1 201 Created [DEVELOPER 00:00:01] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:01] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:01] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:01] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:01] stderr: [hdr] Location: http://localhost:9009/davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf [DEVELOPER 00:00:01] stderr: Header Name: [location], Value: [http://localhost:9009/davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf] [DEVELOPER 00:00:01] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:01] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:01] stderr: [hdr] Content-type: text/plain; charset="utf-8" [DEVELOPER 00:00:01] stderr: Header Name: [content-type], Value: [text/plain; charset="utf-8"] [DEVELOPER 00:00:01] stderr: [hdr] Content-Length: 0 [DEVELOPER 00:00:01] stderr: Header Name: [content-length], Value: [0] [DEVELOPER 00:00:01] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:26 GMT [DEVELOPER 00:00:01] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:26 GMT] [DEVELOPER 00:00:01] stderr: [hdr] [DEVELOPER 00:00:01] stderr: End of headers. [DEVELOPER 00:00:01] stderr: Running post_headers hooks [DEVELOPER 00:00:01] stderr: Running post_send hooks [DEVELOPER 00:00:01] stderr: ah_post_send (#0), code is 201 (want 401), WWW-Authenticate is (none) [DEVELOPER 00:00:01] stderr: Request ends, status 201 class 2xx, error line: [DEVELOPER 00:00:01] stderr: 201 Created [DEBUG 00:00:01] add item status: [DEBUG 00:00:01] new item mapped to syuid288166.212340157754280.vcf [DEVELOPER 00:00:01] stderr: Running destroy hooks. [DEVELOPER 00:00:01] stderr: Request ends. [DEBUG 00:00:01] starting PROPFIND, credentials unverified, deadline in 120.0s [DEVELOPER 00:00:01] stderr: ah_create, for WWW-Authenticate [DEVELOPER 00:00:01] stderr: Running pre_send hooks [DEVELOPER 00:00:01] stderr: auth: Sending 'Basic' response. [DEVELOPER 00:00:01] stderr: Sending request headers: [DEVELOPER 00:00:01] stderr: PROPFIND /davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf HTTP/1.1 [DEVELOPER 00:00:01] stderr: Connection: TE [DEVELOPER 00:00:01] stderr: TE: trailers [DEVELOPER 00:00:01] stderr: Host: localhost:9009 [DEVELOPER 00:00:01] stderr: Depth: 0 [DEVELOPER 00:00:01] stderr: Content-Length: 141 [DEVELOPER 00:00:01] stderr: Content-Type: application/xml [DEVELOPER 00:00:01] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:01] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: Sending request-line and headers: [DEVELOPER 00:00:01] stderr: Sending request body: [DEVELOPER 00:00:01] stderr: Body block (141 bytes): [DEVELOPER 00:00:01] stderr: [ [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: ] [DEVELOPER 00:00:01] stderr: Request sent; retry is 1. [DEVELOPER 00:00:01] stderr: [status-line] < HTTP/1.1 207 Multi-status [DEVELOPER 00:00:01] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:01] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:01] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:01] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:01] stderr: [hdr] ETag: "db267ae6bb49f9157e13f8b3aadcd84e" [DEVELOPER 00:00:01] stderr: Header Name: [etag], Value: ["db267ae6bb49f9157e13f8b3aadcd84e"] [DEVELOPER 00:00:01] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:01] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:01] stderr: [hdr] Content-type: text/xml; charset="utf-8" [DEVELOPER 00:00:01] stderr: Header Name: [content-type], Value: [text/xml; charset="utf-8"] [DEVELOPER 00:00:01] stderr: [hdr] Content-Length: 367 [DEVELOPER 00:00:01] stderr: Header Name: [content-length], Value: [367] [DEVELOPER 00:00:01] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:26 GMT [DEVELOPER 00:00:01] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:26 GMT] [DEVELOPER 00:00:01] stderr: [hdr] [DEVELOPER 00:00:01] stderr: End of headers. [DEVELOPER 00:00:01] stderr: Running post_headers hooks [DEVELOPER 00:00:01] stderr: Reading 367 bytes of response body. [DEVELOPER 00:00:01] stderr: Got 367 bytes. [DEVELOPER 00:00:01] stderr: Read block (367 bytes): [DEVELOPER 00:00:01] stderr: [ [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: "ee702bdc6e7e255fd9989bbf0632bc6c" [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: HTTP/1.1 200 OK [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: ] [DEBUG 00:00:01] item syuid288166.212340157754280.vcf = rev ee702bdc6e7e255fd9989bbf0632bc6c ... [DEVELOPER 00:00:02] stderr: REPORT /davical/caldav.php/tester2/Test_davical_carddav_1/ HTTP/1.1 [DEVELOPER 00:00:02] stderr: Connection: TE [DEVELOPER 00:00:02] stderr: TE: trailers [DEVELOPER 00:00:02] stderr: Host: localhost:9009 [DEVELOPER 00:00:02] stderr: Content-Length: 384 [DEVELOPER 00:00:02] stderr: Depth: 0 [DEVELOPER 00:00:02] stderr: Content-Type: application/xml; charset="utf-8" [DEVELOPER 00:00:02] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:02] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: Sending request-line and headers: [DEVELOPER 00:00:02] stderr: Sending request body: [DEVELOPER 00:00:02] stderr: Body block (384 bytes): [DEVELOPER 00:00:02] stderr: [ [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf [DEVELOPER 00:00:02] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf [DEVELOPER 00:00:02] stderr: ] [DEVELOPER 00:00:02] stderr: Request sent; retry is 1. [DEVELOPER 00:00:02] stderr: [status-line] < HTTP/1.1 207 Multi-status [DEVELOPER 00:00:02] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:02] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:02] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:02] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:02] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:02] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:02] stderr: [hdr] ETag: "71ac67ebaf38ed5fb164ee1696038ded" [DEVELOPER 00:00:02] stderr: Header Name: [etag], Value: ["71ac67ebaf38ed5fb164ee1696038ded"] [DEVELOPER 00:00:02] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:02] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:02] stderr: [hdr] Content-type: text/xml; charset="utf-8" [DEVELOPER 00:00:02] stderr: Header Name: [content-type], Value: [text/xml; charset="utf-8"] [DEVELOPER 00:00:02] stderr: [hdr] Content-Length: 2205 [DEVELOPER 00:00:02] stderr: Header Name: [content-length], Value: [2205] [DEVELOPER 00:00:02] stderr: [hdr] Connection: close [DEVELOPER 00:00:02] stderr: Header Name: [connection], Value: [close] [DEVELOPER 00:00:02] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:27 GMT [DEVELOPER 00:00:02] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:27 GMT] [DEVELOPER 00:00:02] stderr: [hdr] [DEVELOPER 00:00:02] stderr: End of headers. [DEVELOPER 00:00:02] stderr: Running post_headers hooks [DEVELOPER 00:00:02] stderr: Reading 2205 bytes of response body. [DEVELOPER 00:00:02] stderr: Got 2205 bytes. [DEVELOPER 00:00:02] stderr: Read block (2205 bytes): [DEVELOPER 00:00:02] stderr: [ [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: "85c7cfd93c7303d3b938c87edcd27102" [DEVELOPER 00:00:02] stderr: BEGIN:VCARD [DEVELOPER 00:00:02] stderr: VERSION:3.0 [DEVELOPER 00:00:02] stderr: UID:unique-id-user2 [DEVELOPER 00:00:02] stderr: NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCI [DEVELOPER 00:00:02] stderr: I characters (with umlauts in the name)\n- line break (in this note and [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: the mailing address)\n- long lines (in this note)\n- special characters [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: (in this note)\n- tabs (in this note)\n\nVery long line\, very very lon [DEVELOPER 00:00:02] stderr: g [DEVELOPER 00:00:02] stderr: this time... still not finished... blah blah blah blah blah 1 2 3 4 5 [DEVELOPER 00:00:02] stderr: 6 [DEVELOPER 00:00:02] stderr: 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbacksla [DEVELOPER 00:00:02] stderr: s [DEVELOPER 00:00:02] stderr: h \\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col [DEVELOPER 00:00:02] stderr: o [DEVELOPER 00:00:02] stderr: n\nsemicolon \; semicolon\nbackslash \ backslash\n\nA tab tab done\n l [DEVELOPER 00:00:02] stderr: i [DEVELOPER 00:00:02] stderr: ne starts with tab [DEVELOPER 00:00:02] stderr: FN:user 2 [DEVELOPER 00:00:02] stderr: N:2;;;user; [DEVELOPER 00:00:02] stderr: REV:20160909T081426Z [DEVELOPER 00:00:02] stderr: END:VCARD [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: HTTP/1.1 200 OK [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: "ee702bdc6e7e255fd9989bbf0632bc6c" [DEVELOPER 00:00:02] stderr: BEGIN:VCARD [DEVELOPER 00:00:02] stderr: VERSION:3.0 [DEVELOPER 00:00:02] stderr: REV:20160908T170847Z [DEVELOPER 00:00:02] stderr: UID:syuid288166.212340157754280 [DEVELOPER 00:00:02] stderr: N:1;;;user; [DEVELOPER 00:00:02] stderr: FN:user 1 [DEVELOPER 00:00:02] stderr: NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCI [DEVELOPER 00:00:02] stderr: I characters (with umlauts in the name)\n- line break (in this note and [DEVELOPER 00:00:02] stderr: the mailing address)\n- long lines (in this note)\n- special characters [DEVELOPER 00:00:02] stderr: (in this note)\n- tabs (in this note)\n\nVery long line\, very very long [DEVELOPER 00:00:02] stderr: this time... still not finished... blah blah blah blah blah 1 2 3 4 5 6 [DEVELOPER 00:00:02] stderr: 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslas [DEVELOPER 00:00:02] stderr: h \\\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col [DEVELOPER 00:00:02] stderr: on\nsemicolon \; semicolon\nbackslash \\ backslash\n\nA tab tab done\n [DEVELOPER 00:00:02] stderr: line starts with tab [DEVELOPER 00:00:02] stderr: END:VCARD [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: HTTP/1.1 200 OK [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: ] -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.1.27-27-xen (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages davical depends on: ii libawl-php 0.56-2 ii libdbd-pg-perl 3.5.3-1+b1 ii libyaml-perl 1.18-1 ii perl 5.22.2-3 ii php7.0 [php] 7.0.9-2 ii php7.0-cli [php-cli] 7.0.10-1 ii php7.0-pgsql [php-pgsql] 7.0.10-1 ii php7.0-xml [php-xml] 7.0.10-1 ii postgresql-client-9.5 [postgresql-client] 9.5.4-1 Versions of packages davical recommends: ii php7.0-curl [php-curl] 7.0.10-1 ii postgresql 9.5+175 Versions of packages davical suggests: pn php-ldap | php5-ldap -- no debconf information From patrick.ohly at intel.com Fri Sep 9 09:17:02 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 09 Sep 2016 11:17:02 +0200 Subject: davical: backslash escaping sometimes broken in vCard Message-ID: <1473412622.13122.7.camel@intel.com> Dear DAViCal maintainers, I've recently updated the SyncEvolution test setup such that it runs tests against DAVICal 1.1.4-3 from Debian Testing and noticed a problem that I have not seen before: when storing certain vCards on the server and retrieving them again, backslashes in the NOTE property (and perhaps elsewhere) are getting modified incorrectly. This only happens for vCards which have no REV property. Normally SyncEvolution includes a REV property when syncing, so this might only affect testing and perhaps some users who use the command line to import contacts into DAViCal directly. I'm more concerned about not-yet-known cases where this decoding/encoding on the server-side happens. testcases/carddav.vcf | Client_Source_davical_carddav_testImport.B.test.dat only in left file < > only in right file ------------------------------------------------------------------------------- BEGIN:VCARD BEGIN:VCARD N:2;;;user N:2;;;user FN:user 2 FN:user 2 NOTE:This user tests some of the adva NOTE:This user tests some of the adva nced aspects of vcards:\n- non-ASCII nced aspects of vcards:\n- non-ASCII characters (with umlauts in the name) characters (with umlauts in the name) \n- line break (in this note and the \n- line break (in this note and the mailing address)\n- long lines (in th mailing address)\n- long lines (in th is note)\n- special characters (in th is note)\n- special characters (in th is note)\n- tabs (in this note)\n\nVe is note)\n- tabs (in this note)\n\nVe ry long line\, very very long this ti ry long line\, very very long this ti me... still not finished... blah blah me... still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 8 9 10 blah blah blah 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \\\n\nThe | :\nsemicolon \;\nbackslash \\n\nThe s same\, in the middle of a line:\ncomm | ame\, in the middle of a line:\ncomma a \, comma\ncolon : colon\nsemicolon | \, comma\ncolon : colon\nsemicolon \ \; semicolon\nbackslash \\ backslash\ | ; semicolon\nbackslash \ backslash\n\ n\nA tab tab done\n line starts with | nA tab tab done\n line starts with t tab | ab VERSION:3.0 VERSION:3.0 END:VCARD END:VCARD ------------------------------------------------------------------------------- Note that the \\ gets replaced with a single \. My two testcases are: BEGIN:VCARD VERSION:3.0 UID:unique-id-user2 NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCII c haracters (with umlauts in the name)\n- line break (in this note and the mailing address)\n- long lines (in this note)\n- special characters (in this note)\n- tabs (in this note)\n\nVery long line\, very very long th is time... still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \\\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col on\nsemicolon \; semicolon\nbackslash \\ backslash\n\nA tab tab done\n line starts with tab FN:user 2 N:2;;;user; END:VCARD BEGIN:VCARD VERSION:3.0 REV:20160908T170847Z UID:syuid288166.212340157754280 N:1;;;user; FN:user 1 NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCII c haracters (with umlauts in the name)\n- line break (in this note and the ma iling address)\n- long lines (in this note)\n- special characters (in this note)\n- tabs (in this note)\n\nVery long line\, very very long this time.. . still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \\\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : colon\nsemicolon \; semi colon\nbackslash \\ backslash\n\nA tab tab done\n line starts with tab END:VCARD Content of NOTE gets mangled for the first vCard, but not the second. Here's the relevant excerpt of the CardDAV communication: [DEVELOPER 00:00:01] stderr: POST /davical/caldav.php/tester2/Test_davical_carddav_1/?add_member HTTP/1.1 [DEVELOPER 00:00:01] stderr: Connection: TE [DEVELOPER 00:00:01] stderr: TE: trailers [DEVELOPER 00:00:01] stderr: Host: localhost:9009 [DEVELOPER 00:00:01] stderr: Content-Length: 704 [DEVELOPER 00:00:01] stderr: Content-Type: text/vcard; charset=utf-8 [DEVELOPER 00:00:01] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:01] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: Sending request-line and headers: [DEVELOPER 00:00:01] stderr: Sending request body: [DEVELOPER 00:00:01] stderr: Body block (704 bytes): [DEVELOPER 00:00:01] stderr: [BEGIN:VCARD [DEVELOPER 00:00:01] stderr: VERSION:3.0 [DEVELOPER 00:00:01] stderr: UID:unique-id-user2 [DEVELOPER 00:00:01] stderr: NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCII c [DEVELOPER 00:00:01] stderr: haracters (with umlauts in the name)\n- line break (in this note and the [DEVELOPER 00:00:01] stderr: mailing address)\n- long lines (in this note)\n- special characters (in [DEVELOPER 00:00:01] stderr: this note)\n- tabs (in this note)\n\nVery long line\, very very long th [DEVELOPER 00:00:01] stderr: is time... still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 [DEVELOPER 00:00:01] stderr: 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash [DEVELOPER 00:00:01] stderr: \\\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col [DEVELOPER 00:00:01] stderr: on\nsemicolon \; semicolon\nbackslash \\ backslash\n\nA tab tab done\n [DEVELOPER 00:00:01] stderr: line starts with tab [DEVELOPER 00:00:01] stderr: FN:user 2 [DEVELOPER 00:00:01] stderr: N:2;;;user; [DEVELOPER 00:00:01] stderr: END:VCARD [DEVELOPER 00:00:01] stderr: ] [DEVELOPER 00:00:01] stderr: Request sent; retry is 1. [DEVELOPER 00:00:01] stderr: [status-line] < HTTP/1.1 201 Created [DEVELOPER 00:00:01] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:01] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:01] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:01] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:01] stderr: [hdr] Location: http://localhost:9009/davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf [DEVELOPER 00:00:01] stderr: Header Name: [location], Value: [http://localhost:9009/davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf] [DEVELOPER 00:00:01] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:01] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:01] stderr: [hdr] Content-type: text/plain; charset="utf-8" [DEVELOPER 00:00:01] stderr: Header Name: [content-type], Value: [text/plain; charset="utf-8"] [DEVELOPER 00:00:01] stderr: [hdr] Content-Length: 0 [DEVELOPER 00:00:01] stderr: Header Name: [content-length], Value: [0] [DEVELOPER 00:00:01] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:26 GMT [DEVELOPER 00:00:01] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:26 GMT] [DEVELOPER 00:00:01] stderr: [hdr] [DEVELOPER 00:00:01] stderr: End of headers. [DEVELOPER 00:00:01] stderr: Running post_headers hooks [DEVELOPER 00:00:01] stderr: Running post_send hooks [DEVELOPER 00:00:01] stderr: ah_post_send (#0), code is 201 (want 401), WWW-Authenticate is (none) [DEVELOPER 00:00:01] stderr: Request ends, status 201 class 2xx, error line: [DEVELOPER 00:00:01] stderr: 201 Created [DEBUG 00:00:01] add item status: [DEBUG 00:00:01] new item mapped to unique-id-user2.vcf [DEVELOPER 00:00:01] stderr: Running destroy hooks. [DEVELOPER 00:00:01] stderr: Request ends. [DEBUG 00:00:01] starting PROPFIND, credentials unverified, deadline in 120.0s [DEVELOPER 00:00:01] stderr: ah_create, for WWW-Authenticate [DEVELOPER 00:00:01] stderr: Running pre_send hooks [DEVELOPER 00:00:01] stderr: auth: Sending 'Basic' response. [DEVELOPER 00:00:01] stderr: Sending request headers: [DEVELOPER 00:00:01] stderr: PROPFIND /davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf HTTP/1.1 [DEVELOPER 00:00:01] stderr: Connection: TE [DEVELOPER 00:00:01] stderr: TE: trailers [DEVELOPER 00:00:01] stderr: Host: localhost:9009 [DEVELOPER 00:00:01] stderr: Depth: 0 [DEVELOPER 00:00:01] stderr: Content-Length: 141 [DEVELOPER 00:00:01] stderr: Content-Type: application/xml [DEVELOPER 00:00:01] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:01] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: Sending request-line and headers: [DEVELOPER 00:00:01] stderr: Sending request body: [DEVELOPER 00:00:01] stderr: Body block (141 bytes): [DEVELOPER 00:00:01] stderr: [ [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: ] [DEVELOPER 00:00:01] stderr: Request sent; retry is 1. [DEVELOPER 00:00:01] stderr: [status-line] < HTTP/1.1 207 Multi-status [DEVELOPER 00:00:01] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:01] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:01] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:01] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:01] stderr: [hdr] ETag: "4edfcd770d60600fc5ca057f62567d8c" [DEVELOPER 00:00:01] stderr: Header Name: [etag], Value: ["4edfcd770d60600fc5ca057f62567d8c"] [DEVELOPER 00:00:01] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:01] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:01] stderr: [hdr] Content-type: text/xml; charset="utf-8" [DEVELOPER 00:00:01] stderr: Header Name: [content-type], Value: [text/xml; charset="utf-8"] [DEVELOPER 00:00:01] stderr: [hdr] Content-Length: 355 [DEVELOPER 00:00:01] stderr: Header Name: [content-length], Value: [355] [DEVELOPER 00:00:01] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:26 GMT [DEVELOPER 00:00:01] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:26 GMT] [DEVELOPER 00:00:01] stderr: [hdr] [DEVELOPER 00:00:01] stderr: End of headers. [DEVELOPER 00:00:01] stderr: Running post_headers hooks [DEVELOPER 00:00:01] stderr: Reading 355 bytes of response body. [DEVELOPER 00:00:01] stderr: Got 355 bytes. [DEVELOPER 00:00:01] stderr: Read block (355 bytes): [DEVELOPER 00:00:01] stderr: [ [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: "85c7cfd93c7303d3b938c87edcd27102" [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: HTTP/1.1 200 OK [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: ] [DEBUG 00:00:01] item unique-id-user2.vcf = rev 85c7cfd93c7303d3b938c87edcd27102 ... [DEVELOPER 00:00:01] stderr: POST /davical/caldav.php/tester2/Test_davical_carddav_1/?add_member HTTP/1.1 [DEVELOPER 00:00:01] stderr: Connection: TE [DEVELOPER 00:00:01] stderr: TE: trailers [DEVELOPER 00:00:01] stderr: Host: localhost:9009 [DEVELOPER 00:00:01] stderr: Content-Length: 735 [DEVELOPER 00:00:01] stderr: Content-Type: text/vcard; charset=utf-8 [DEVELOPER 00:00:01] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:01] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: Sending request-line and headers: [DEVELOPER 00:00:01] stderr: Sending request body: [DEVELOPER 00:00:01] stderr: Body block (735 bytes): [DEVELOPER 00:00:01] stderr: [BEGIN:VCARD [DEVELOPER 00:00:01] stderr: VERSION:3.0 [DEVELOPER 00:00:01] stderr: REV:20160908T170847Z [DEVELOPER 00:00:01] stderr: UID:syuid288166.212340157754280 [DEVELOPER 00:00:01] stderr: N:1;;;user; [DEVELOPER 00:00:01] stderr: FN:user 1 [DEVELOPER 00:00:01] stderr: NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCII c [DEVELOPER 00:00:01] stderr: haracters (with umlauts in the name)\n- line break (in this note and the ma [DEVELOPER 00:00:01] stderr: iling address)\n- long lines (in this note)\n- special characters (in this [DEVELOPER 00:00:01] stderr: note)\n- tabs (in this note)\n\nVery long line\, very very long this time.. [DEVELOPER 00:00:01] stderr: . still not finished... blah blah blah blah blah 1 2 3 4 5 6 7 8 9 10 11 12 [DEVELOPER 00:00:01] stderr: 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \\\n\nThe same\, [DEVELOPER 00:00:01] stderr: in the middle of a line:\ncomma \, comma\ncolon : colon\nsemicolon \; semi [DEVELOPER 00:00:01] stderr: colon\nbackslash \\ backslash\n\nA tab tab done\n line starts with tab [DEVELOPER 00:00:01] stderr: END:VCARD [DEVELOPER 00:00:01] stderr: ] [DEVELOPER 00:00:01] stderr: Request sent; retry is 1. [DEVELOPER 00:00:01] stderr: [status-line] < HTTP/1.1 201 Created [DEVELOPER 00:00:01] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:01] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:01] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:01] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:01] stderr: [hdr] Location: http://localhost:9009/davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf [DEVELOPER 00:00:01] stderr: Header Name: [location], Value: [http://localhost:9009/davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf] [DEVELOPER 00:00:01] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:01] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:01] stderr: [hdr] Content-type: text/plain; charset="utf-8" [DEVELOPER 00:00:01] stderr: Header Name: [content-type], Value: [text/plain; charset="utf-8"] [DEVELOPER 00:00:01] stderr: [hdr] Content-Length: 0 [DEVELOPER 00:00:01] stderr: Header Name: [content-length], Value: [0] [DEVELOPER 00:00:01] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:26 GMT [DEVELOPER 00:00:01] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:26 GMT] [DEVELOPER 00:00:01] stderr: [hdr] [DEVELOPER 00:00:01] stderr: End of headers. [DEVELOPER 00:00:01] stderr: Running post_headers hooks [DEVELOPER 00:00:01] stderr: Running post_send hooks [DEVELOPER 00:00:01] stderr: ah_post_send (#0), code is 201 (want 401), WWW-Authenticate is (none) [DEVELOPER 00:00:01] stderr: Request ends, status 201 class 2xx, error line: [DEVELOPER 00:00:01] stderr: 201 Created [DEBUG 00:00:01] add item status: [DEBUG 00:00:01] new item mapped to syuid288166.212340157754280.vcf [DEVELOPER 00:00:01] stderr: Running destroy hooks. [DEVELOPER 00:00:01] stderr: Request ends. [DEBUG 00:00:01] starting PROPFIND, credentials unverified, deadline in 120.0s [DEVELOPER 00:00:01] stderr: ah_create, for WWW-Authenticate [DEVELOPER 00:00:01] stderr: Running pre_send hooks [DEVELOPER 00:00:01] stderr: auth: Sending 'Basic' response. [DEVELOPER 00:00:01] stderr: Sending request headers: [DEVELOPER 00:00:01] stderr: PROPFIND /davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf HTTP/1.1 [DEVELOPER 00:00:01] stderr: Connection: TE [DEVELOPER 00:00:01] stderr: TE: trailers [DEVELOPER 00:00:01] stderr: Host: localhost:9009 [DEVELOPER 00:00:01] stderr: Depth: 0 [DEVELOPER 00:00:01] stderr: Content-Length: 141 [DEVELOPER 00:00:01] stderr: Content-Type: application/xml [DEVELOPER 00:00:01] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:01] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: Sending request-line and headers: [DEVELOPER 00:00:01] stderr: Sending request body: [DEVELOPER 00:00:01] stderr: Body block (141 bytes): [DEVELOPER 00:00:01] stderr: [ [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: ] [DEVELOPER 00:00:01] stderr: Request sent; retry is 1. [DEVELOPER 00:00:01] stderr: [status-line] < HTTP/1.1 207 Multi-status [DEVELOPER 00:00:01] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:01] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:01] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:01] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:01] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:01] stderr: [hdr] ETag: "db267ae6bb49f9157e13f8b3aadcd84e" [DEVELOPER 00:00:01] stderr: Header Name: [etag], Value: ["db267ae6bb49f9157e13f8b3aadcd84e"] [DEVELOPER 00:00:01] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:01] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:01] stderr: [hdr] Content-type: text/xml; charset="utf-8" [DEVELOPER 00:00:01] stderr: Header Name: [content-type], Value: [text/xml; charset="utf-8"] [DEVELOPER 00:00:01] stderr: [hdr] Content-Length: 367 [DEVELOPER 00:00:01] stderr: Header Name: [content-length], Value: [367] [DEVELOPER 00:00:01] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:26 GMT [DEVELOPER 00:00:01] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:26 GMT] [DEVELOPER 00:00:01] stderr: [hdr] [DEVELOPER 00:00:01] stderr: End of headers. [DEVELOPER 00:00:01] stderr: Running post_headers hooks [DEVELOPER 00:00:01] stderr: Reading 367 bytes of response body. [DEVELOPER 00:00:01] stderr: Got 367 bytes. [DEVELOPER 00:00:01] stderr: Read block (367 bytes): [DEVELOPER 00:00:01] stderr: [ [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: "ee702bdc6e7e255fd9989bbf0632bc6c" [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: HTTP/1.1 200 OK [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: [DEVELOPER 00:00:01] stderr: ] [DEBUG 00:00:01] item syuid288166.212340157754280.vcf = rev ee702bdc6e7e255fd9989bbf0632bc6c ... [DEVELOPER 00:00:02] stderr: REPORT /davical/caldav.php/tester2/Test_davical_carddav_1/ HTTP/1.1 [DEVELOPER 00:00:02] stderr: Connection: TE [DEVELOPER 00:00:02] stderr: TE: trailers [DEVELOPER 00:00:02] stderr: Host: localhost:9009 [DEVELOPER 00:00:02] stderr: Content-Length: 384 [DEVELOPER 00:00:02] stderr: Depth: 0 [DEVELOPER 00:00:02] stderr: Content-Type: application/xml; charset="utf-8" [DEVELOPER 00:00:02] stderr: Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [DEVELOPER 00:00:02] stderr: User-Agent: SyncEvolution [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: Sending request-line and headers: [DEVELOPER 00:00:02] stderr: Sending request body: [DEVELOPER 00:00:02] stderr: Body block (384 bytes): [DEVELOPER 00:00:02] stderr: [ [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf [DEVELOPER 00:00:02] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf [DEVELOPER 00:00:02] stderr: ] [DEVELOPER 00:00:02] stderr: Request sent; retry is 1. [DEVELOPER 00:00:02] stderr: [status-line] < HTTP/1.1 207 Multi-status [DEVELOPER 00:00:02] stderr: [hdr] Server: 1.1 [DEVELOPER 00:00:02] stderr: Header Name: [server], Value: [1.1] [DEVELOPER 00:00:02] stderr: [hdr] DAV: 1, 2, 3, access-control, calendar-access, calendar-schedule [DEVELOPER 00:00:02] stderr: Header Name: [dav], Value: [1, 2, 3, access-control, calendar-access, calendar-schedule] [DEVELOPER 00:00:02] stderr: [hdr] DAV: extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy [DEVELOPER 00:00:02] stderr: Header Name: [dav], Value: [extended-mkcol, bind, addressbook, calendar-auto-schedule, calendar-proxy] [DEVELOPER 00:00:02] stderr: [hdr] ETag: "71ac67ebaf38ed5fb164ee1696038ded" [DEVELOPER 00:00:02] stderr: Header Name: [etag], Value: ["71ac67ebaf38ed5fb164ee1696038ded"] [DEVELOPER 00:00:02] stderr: [hdr] X-DAViCal-Version: DAViCal/1.1.4; DB/1.2.12 [DEVELOPER 00:00:02] stderr: Header Name: [x-davical-version], Value: [DAViCal/1.1.4; DB/1.2.12] [DEVELOPER 00:00:02] stderr: [hdr] Content-type: text/xml; charset="utf-8" [DEVELOPER 00:00:02] stderr: Header Name: [content-type], Value: [text/xml; charset="utf-8"] [DEVELOPER 00:00:02] stderr: [hdr] Content-Length: 2205 [DEVELOPER 00:00:02] stderr: Header Name: [content-length], Value: [2205] [DEVELOPER 00:00:02] stderr: [hdr] Connection: close [DEVELOPER 00:00:02] stderr: Header Name: [connection], Value: [close] [DEVELOPER 00:00:02] stderr: [hdr] Date: Fri, 09 Sep 2016 08:14:27 GMT [DEVELOPER 00:00:02] stderr: Header Name: [date], Value: [Fri, 09 Sep 2016 08:14:27 GMT] [DEVELOPER 00:00:02] stderr: [hdr] [DEVELOPER 00:00:02] stderr: End of headers. [DEVELOPER 00:00:02] stderr: Running post_headers hooks [DEVELOPER 00:00:02] stderr: Reading 2205 bytes of response body. [DEVELOPER 00:00:02] stderr: Got 2205 bytes. [DEVELOPER 00:00:02] stderr: Read block (2205 bytes): [DEVELOPER 00:00:02] stderr: [ [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/unique-id-user2.vcf [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: "85c7cfd93c7303d3b938c87edcd27102" [DEVELOPER 00:00:02] stderr: BEGIN:VCARD [DEVELOPER 00:00:02] stderr: VERSION:3.0 [DEVELOPER 00:00:02] stderr: UID:unique-id-user2 [DEVELOPER 00:00:02] stderr: NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCI [DEVELOPER 00:00:02] stderr: I characters (with umlauts in the name)\n- line break (in this note and [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: the mailing address)\n- long lines (in this note)\n- special characters [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: (in this note)\n- tabs (in this note)\n\nVery long line\, very very lon [DEVELOPER 00:00:02] stderr: g [DEVELOPER 00:00:02] stderr: this time... still not finished... blah blah blah blah blah 1 2 3 4 5 [DEVELOPER 00:00:02] stderr: 6 [DEVELOPER 00:00:02] stderr: 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbacksla [DEVELOPER 00:00:02] stderr: s [DEVELOPER 00:00:02] stderr: h \\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col [DEVELOPER 00:00:02] stderr: o [DEVELOPER 00:00:02] stderr: n\nsemicolon \; semicolon\nbackslash \ backslash\n\nA tab tab done\n l [DEVELOPER 00:00:02] stderr: i [DEVELOPER 00:00:02] stderr: ne starts with tab [DEVELOPER 00:00:02] stderr: FN:user 2 [DEVELOPER 00:00:02] stderr: N:2;;;user; [DEVELOPER 00:00:02] stderr: REV:20160909T081426Z [DEVELOPER 00:00:02] stderr: END:VCARD [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: HTTP/1.1 200 OK [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: /davical/caldav.php/tester2/Test_davical_carddav_1/syuid288166.212340157754280.vcf [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: "ee702bdc6e7e255fd9989bbf0632bc6c" [DEVELOPER 00:00:02] stderr: BEGIN:VCARD [DEVELOPER 00:00:02] stderr: VERSION:3.0 [DEVELOPER 00:00:02] stderr: REV:20160908T170847Z [DEVELOPER 00:00:02] stderr: UID:syuid288166.212340157754280 [DEVELOPER 00:00:02] stderr: N:1;;;user; [DEVELOPER 00:00:02] stderr: FN:user 1 [DEVELOPER 00:00:02] stderr: NOTE:This user tests some of the advanced aspects of vcards:\n- non-ASCI [DEVELOPER 00:00:02] stderr: I characters (with umlauts in the name)\n- line break (in this note and [DEVELOPER 00:00:02] stderr: the mailing address)\n- long lines (in this note)\n- special characters [DEVELOPER 00:00:02] stderr: (in this note)\n- tabs (in this note)\n\nVery long line\, very very long [DEVELOPER 00:00:02] stderr: this time... still not finished... blah blah blah blah blah 1 2 3 4 5 6 [DEVELOPER 00:00:02] stderr: 7 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslas [DEVELOPER 00:00:02] stderr: h \\\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col [DEVELOPER 00:00:02] stderr: on\nsemicolon \; semicolon\nbackslash \\ backslash\n\nA tab tab done\n [DEVELOPER 00:00:02] stderr: line starts with tab [DEVELOPER 00:00:02] stderr: END:VCARD [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: HTTP/1.1 200 OK [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: [DEVELOPER 00:00:02] stderr: ] -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Fri Sep 9 07:34:22 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 09 Sep 2016 09:34:22 +0200 Subject: CardDAV GEO encoding issue in OwnDrive/OwnCloud Message-ID: <1473406462.29926.14.camel@intel.com> Hello! As discussed in a private mail thread a while ago (three years ago, to the day - how time flies), I'm testing SyncEvolution against owndrive.com and report problems by sending emails like this one here. One problem I noticed this week is that the GEO property in vCards gets mangled by the server. I've not tested for a while, so I can't say when this problem first appeared. PUT /remote.php/carddav/addressbooks/pohly/contacts/syuid817417.212340052360009.vcf HTTP/1.1 ... GEO:30.12;-130.34 ... It comes back as: BEGIN:VCARD VERSION:3.0 PRODID:-//ownCloud//NONSGML Contacts 0.5.0.0//EN ... GEO:30.12\;-130.34 GEO is a "A single structured value consisting of two float values separated by the SEMI-COLON character (ASCII decimal 59)." (https://tools.ietf.org/html/rfc2426#section-3.4.2), so escaping the semi-colon like this is wrong. I've not tested for a while, so I can't say when this problem first appeared. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From deloptes at gmail.com Thu Sep 1 20:11:30 2016 From: deloptes at gmail.com (deloptes) Date: Thu, 1 Sep 2016 22:11:30 +0200 Subject: [SyncEvolution] syncevolution debug help needed References: <1469786988.23795.18.camel@intel.com> <1471874545.24499.16.camel@intel.com> <1471935212.24499.28.camel@intel.com> <1472022558.20290.4.camel@intel.com> <1472115147.396.6.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Sep 5 10:30:21 2016 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 05 Sep 2016 12:30:21 +0200 Subject: [SyncEvolution] syncevolution debug help needed In-Reply-To: References: <1469786988.23795.18.camel@intel.com> <1471874545.24499.16.camel@intel.com> <1471935212.24499.28.camel@intel.com> <1472022558.20290.4.camel@intel.com> <1472115147.396.6.camel@intel.com> Message-ID: <1473071421.20168.27.camel@intel.com> On Thu, 2016-09-01 at 22:11 +0200, deloptes wrote: > 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. If you submit the code (attachment to a new issue in https://bugs.freedesktop.org preferred), then I will include it. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.