[SyncEvolution] mailing list moved
Hello! As part of moving the SyncEvolution infrastructure away from Intel-hosted services, the mailing list is moving to https://lists.freedesktop.org/mailman/listinfo/syncevolution Please re-subscribe there if you are interested in future discussions and announcements. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: moving SyncEvolution infrastructure
"Patrick Ohly" writes: > My problem right now is that some blog posts, for example in 2011, get > rendered under blogs/pohly but not included in the feed and blog > archive. I've not figured out the reason for that yet. I found that a post had to include at least one section title. Now it works. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: moving SyncEvolution infrastructure
"Patrick Ohly" writes: > Robert K writes: > >>> In fact, this would be a perfect opportunity for someone with spare time >>> to help out. Any volunteers? >> >> Hello Patrick, >> >> I do have some time to help you. >> Please let me know, what should be done. > > Excellent. We first need to figure out where to host the website and > which tools to use for building it, then convert content. That's where > I'll need help. So here's where I am at the moment. I have downloaded Markdown files from the current site and also mirrored the generated HTML. Both is in different branches of my personal freedesktop.org repo. This branch has the Markdown and instructions: https://gitlab.freedesktop.org/pohly/syncevolution/-/tree/gitlab-pages Here's the current site: https://gitlab.freedesktop.org/pohly/syncevolution/-/tree/syncevolution.org Rendered page: https://pohly.pages.freedesktop.org/syncevolution/ So far, I have mostly just automatically moved .md files from "export" (where they are ignored) to the places where syncevolution.org had them. I've done it for "blogs/pohly", but the same command could also move all other files (see commit message). My problem right now is that some blog posts, for example in 2011, get rendered under blogs/pohly but not included in the feed and blog archive. I've not figured out the reason for that yet. The other problem is that the input .md files all need to be edited manually to render more nicely. Some of them are completely broken. Robert, is that something you might be able to help with? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: moving SyncEvolution infrastructure
Robert K writes: >> In fact, this would be a perfect opportunity for someone with spare time >> to help out. Any volunteers? > > Hello Patrick, > > I do have some time to help you. > Please let me know, what should be done. Excellent. We first need to figure out where to host the website and which tools to use for building it, then convert content. That's where I'll need help. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: moving SyncEvolution infrastructure
Milan Crha writes: > On Thu, 2022-03-31 at 13:12 +0200, Patrick Ohly wrote: >> I'm not sure. We can try. I created >> https://groups.google.com/g/syncevolution and sent you an invitation >> to your Red Hat email address. Can you join? > > Hi, > first of all, the invitation was in German, kinda challenging for me > ;) Good feedback! I wasn't asked in which language it should send out the invitation ;-} > After clicking the only blue button there, "Diese Einladung annehmen", > it opened a page, which says "404 Not Found" when I'm not logged to the > Google site. When I am logged to the Google site, I'm told that I just > subscribed to the group. From that I suppose a Google account is needed > to subscribe to the Google group. IMHO that makes freedesktop.org the first choice for the mailing list. I don't want to force people to have a Google account. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: moving SyncEvolution infrastructure
Milan Crha writes: > On Thu, 2022-03-31 at 09:36 +0200, Patrick Ohly wrote: >> Moving it elsewhere is an opportunity to clean this up. I would >> try to keep links valid as much as possible or at least have >> redirects. However, I only intend to copy page content, not comments. >> My plan is to export the original content (usually plain text with >> some Markdown and HTML), clean it up and then run a static page >> generator to recreate the HTML site. > > Hi, > even I do not see it on the gitlab.freedesktop.org instance when not > logged in, the GitLab itself supports Wiki pages, like the GNOME's > instance have it here: > https://gitlab.gnome.org/GNOME/evolution-data-server/-/wikis/home > (there's no wiki page set in this project). A wiki would be a bit different. > The GitLab seems to have a way to provide static pages as well: > https://gitlab.gnome.org/help/user/project/pages/index > https://gitlab.com/pages Good point, I hadn't considered that options. I tried it out and it is enabled on freedesktop.org: https://pohly.pages.freedesktop.org/syncevolution/ > I do not have any opinion on the mailing list part. If a Google group > accepts non-Google addresses then it's probably fine. Otherwise I'd go > with a service not that restricting myself. I'm not sure. We can try. I created https://groups.google.com/g/syncevolution and sent you an invitation to your Red Hat email address. Can you join? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] moving SyncEvolution infrastructure
Hello! Intel has graciously supported SyncEvolution for a long time, even after it became a spare time project again. But now I really should consider how to continue with the project without relying on infrastructure provided by Intel. This includes: - syncevolution.org domain - web hosting (syncevolution.org, downloads.syncevolution.org) - mailing list (syncevolution@syncevolution.org) - mailing list archive (https://lists.syncevolution.org/hyperkitty/list/syncevolution@syncevolution.org) - build server Outside of Intel we already have: - git repo + issue tracker (https://gitlab.freedesktop.org/SyncEvolution) For the mailing list, https://lists.freedesktop.org may be a viable alternative. I have a full copy of old emails that could be imported. This may be more relevant for hosting a public archive of those emails than it is for actual, on-going discussions, though ;-) Will users on this list re-subscribe on another mailing list or should I to try to add current subscribers automatically? Would a Google Groups be better? It looks like I can do most of the setup there myself instead of having to rely on freedesktop.org admins, including sending out invitations to current subscribers. The current content on https://syncevolution.org has aged badly. Not only is some of it stale, rendering also suffered from multiple Drupal updates. Moving it elsewhere is an opportunity to clean this up. I would try to keep links valid as much as possible or at least have redirects. However, I only intend to copy page content, not comments. My plan is to export the original content (usually plain text with some Markdown and HTML), clean it up and then run a static page generator to recreate the HTML site. I have some experience with Sphinx, but not a whole lot. In fact, this would be a perfect opportunity for someone with spare time to help out. Any volunteers? The source code for the web site could be in a new "web" repo. I don't think freedesktop.org supports hosting of static pages, so perhaps GitHub would be a better place for such a "web" repo? Then the rendering can be done by a GitHub action and the result be exposed as a GitHub page. This is a pragmatic compromise between free software purism (GitHub is only a free service, but not free software!) and ease of use. It could also be that it encourages drive-by contributions because the barrier for contributions would be lower, although that doesn't seem that likely. The downloads.syncevolution.org content is something that I would maintain and host myself somewhere. I would also run the builds on my own machine. I'm leaning towards moving the domain to CloudFlare and then configure syncevolution.org so that it becomes a frontend for the web pages and downloads. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Syncing with KeepContacts (onetime MobiCal/Everdroid service)
Max Pyziur writes: > # > > these seem to be the relevant lines from the logfile: > > – > [2022-01-19 17:03:24.293] 'processStatus' - Processing incoming Status > [--][++] [->end] [->enclosing] > > [2022-01-19 17:03:24.293] Started processing Command 'Status' > (incoming MsgID=4, CmdID=5) > [2022-01-19 17:03:24.293] WARNING: RECEIVED NON-OK STATUS 400 for > command 'Add' (outgoing MsgID=4, CmdID=5) > [2022-01-19 17:03:24.293] - SourceRef (localID) = > 'pas-id-0bb48ef3ca252ea80c8d07fd720d9818b357a2e6' > [2022-01-19 17:03:24.293] Found matching command 'Add' for Status > [2022-01-19 17:03:24.293] Status: 400: originator exception As you seem to have KeepContact's attention, perhaps share this log file with them? Further up there's the message that was sent to the server. If you ran with a high enough log level, it will contain your data - this is good for debugging, but beware of your privacy. My guess is that SyncEvolution sends data that the server doesn't like, but that's speculation. KeepContacts should know what this 400 status means. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Syncing with KeepContacts (onetime MobiCal/Everdroid service)
Max Pyziur writes: > Greetings, > > I've been going back and forth with KeepContacts support in order to get > SyncEvolution working with their service. > > We've gotten to the point that a connection can be established, What fixed it? > but now there are other issues that result in a 403 error. > > Specifically, in contacting KeepContacts on this round, the reply is: > "I got word from the developer that your client is trying to do a "SyncML > Alert Code Resume Session (225)" which our server does not support. Can > you see if you can trigger a "Slow Sync, SyncML Alert Code Slow Sync > (201)" instead?" > > I've briefly searched syncevolution's documentation. But if there is > someone who can adivse here more quickly, that would be very helpful. You don't have any valuable data in the server, right? Then you can start from scratch with "--sync refresh-from-local", which will start a new sync session, delete whatever data it finds on the server, and then send the local data. "Resume Session" is used when previous sessions were not terminated properly. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Syncing a New Android phone (Samsung A52) w KeepContacts
Max Pyziur writes: >> this is coming from ./src/syncevo/SoupTransportAgent.cpp in >> void SoupTransportAgent::HandleSessionCallback(SoupSession *session, >> SoupMessage *msg) >> >> what is the linked version of soap you have on your side >> >> $ ldd /usr/bin/syncevolution | grep soup >>libsoup-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 >> (0x7ff3c20f5000) > > Executing this command, the response that is returned is: > libsoup-2.4.so.1 => /lib64/libsoup-2.4.so.1 (0x7fb409adf000) Which Linux distro do you run this on, and which version of libsoup do you have installed? 2.4 is just the soname. For example, Debian Buster has: $ aptitude show libsoup-gnome2.4-1 Package: libsoup-gnome2.4-1 Version: 2.72.0-2 ... This error does look like a low-level HTTPS problem. There is a command line tool for libsoup similar to curl, but it doesn't seem to be packaged. But it can be built from source easily: curl -L https://salsa.debian.org/gnome-team/libsoup/-/raw/debian/master/examples/get.c?inline=false >get.c gcc -o get get.c `pkg-config --cflags --libs libsoup-2.4` ./get --debug https://www.keepcontacts.com/sync/server > GET /sync/server HTTP/1.1 > Soup-Debug-Timestamp: 1641973484 > Soup-Debug: SoupSession 1 (0x558f081a8100), SoupMessage 1 (0x558f081b30a0), > SoupSocket 1 (0x558f084fa8b0) > Host: www.keepcontacts.com > Accept-Encoding: gzip, deflate > User-Agent: get libsoup/2.72.0 > Accept-Language: en-us, en;q=0.9, en;q=0.8 > Connection: Keep-Alive < HTTP/1.1 404 Not Found < Soup-Debug-Timestamp: 1641973484 < Soup-Debug: SoupMessage 1 (0x558f081b30a0) < Date: Wed, 12 Jan 2022 07:44:44 GMT < Server: Apache < X-Frame-Options: DENY < X-Content-Type-Options: nosniff < Strict-Transport-Security: max-age=63072000; includeSubdomains; < X-Permitted-Cross-Domain-Policies: none < Content-Length: 0 < X-XSS-Protection: 1; mode=block < Keep-Alive: timeout=15, max=100 < Connection: Keep-Alive The 404 error is okay. SyncEvolution itself will do a POST, which may lead to a different outcome. The important point is that TLS works. Do you get the same result? You may have to install libsoup2.4-dev (Debian, Ubuntu) or some similar package. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Syncing a New Android phone (Samsung A52) w KeepContacts
Max Pyziur writes: > On Tue, 11 Jan 2022, Patrick Ohly wrote: > >> Max Pyziur writes: >>> I have replicated it below (earlier email), and have tried syncing via >>> SyncEvolution with KeepContacts. However, no KeepContacts connection is >>> made with SyncEvolution. >> >> What error do you get? Do you have >> https://www.keepcontacts.com/sync/server as your syncURL? > > I'm using the GUI; the error message that comes back is: > "We were unable to connect to the server. The problem could be temporary > or there could be something wrong with the settings." > > Are there log files that I can review somewhere? Yes, under ~/.cache/syncevolution. > Or alternatively, is there a CLI command that I can issue, and, in that > way, capture whatever error messages (the one above, and hopefully more > informative ones) are generated? What is your configuration called? If it is "keepcontacts", then you can sync with: syncevolution --run keepcontacts If unsure what the configuration is called, use: syncevolution --print-configs You can check the syncURL with: syncevolution --print-config keepcontacts | grep ^syncURL -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Syncing a New Android phone (Samsung A52) w KeepContacts
Max Pyziur writes: > Greetings, > > Apologies for yanking my own thread here. I just want to have my another > option open. > > I have contacted Support at KeepContacts regarding the recommended > SyncEvolution configuration. > > They said that it should be exactly the same as Mobical (note that Mobical > is part of the packaged configurations in SyncEvolution; during an interim > period MobiCal became Everdroid; by 2015 it became KeepContacts). > > I have replicated it below (earlier email), and have tried syncing via > SyncEvolution with KeepContacts. However, no KeepContacts connection is > made with SyncEvolution. What error do you get? Do you have https://www.keepcontacts.com/sync/server as your syncURL? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Syncing an Android Phone - Memotoo
Max Pyziur writes: > I've been using Syncevolution to sync with my Memotoo account for a > considerable period of time. > > In turn, I use a MemoToo app to sync with my Android phone (Samsung 7). > > Sometime in the last year or so, Google Play removed the Memotoo app > citing information security concerns. Is that a concern for the user (app has vulnerabilities) or for Google (a user isn't using his Android device and address book as intended)? Sorry, couldn't resist. > I have continued to use the app that was installed on my phone w no > seeming problem. > > However now, I'm required to upgrade because the Samsung 7 phone has no 5G > network compatibility. > > I would like to continue to use Evolution, syncingin it with Memotoo, and > then updating my phone's contact list. > > To this end, I have contacted Memotoo about the issue (no reply yet), and > was looking for recommendations from the Syncevolution email list. There is CardDAV-Sync, but I don't know how well it works with MemoToo. Bye, Patrick ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] SyncEvolution 2.0.0 released
About SyncEvolution === SyncEvolution synchronizes personal information management (PIM) data via various protocols (SyncML, CalDAV/CardDAV). It syncs contacts, appointments, tasks and memos. It syncs to web services or to SyncML-capable phones via Bluetooth. Binaries are available for Linux desktops (using GNOME Evolution or plain files for storing PIM data). The source code also supports the Trinity Desktop Environment (TDE). About 2.0.0 === This release modernizes the code base and removes usage of out-dated libraries and APIs. All Python scripts require Python 3. The major version bump reflects that this release is not just a minor bug fix. However, no new features were added. Binaries on syncevolution.org get built for distros >= Ubuntu Bionic and Debian Buster. Testing is now based on Docker containers instead of a custom schroot solution, so adding testing against other distros will be easier in the future. Compilation on Fedora Rawhide was already added. Some features are no longer built and thus untested: - ActiveSync - KDE The code is still there, but needs help from interested developers to ensure that it really works. It may get removed in a future version if there is no interest. Source, Installation, Further information = https://syncevolution.org/blogs/pohly/2021/syncevolution-200 Source code bundles for users are available in https://downloads.syncevolution.org/syncevolution/sources/ and the original source is in the git repositories https://gitlab.freedesktop.org/SyncEvolution amd64 binaries for Debian-based distributions are available via the "stable" syncevolution.org repository. Add the following entry to your /etc/apt/source.list: deb https://downloads.syncevolution.org/apt stable main The GPG key for the repository needs to be imported as root with: apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9 The signing key was renewed for this release. If the key was already added earlier, refresh it with: apt-key adv --keyserver keyserver.ubuntu.com --refresh-keys 43D03AD9 Then install "syncevolution-evolution" (with Evolution dependencies) or "syncevolution" (just the core functionality). After installation, follow the http://syncevolution.org/documentation/getting-started steps. More specific HOWTOs can be found in the Wiki: https://syncevolution.org/wiki/howto -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release - 1.99.2
Milan Crha writes: > On Tue, 2021-02-09 at 18:28 +0100, Milan Crha wrote: >> I opened this new bug: >> https://bugzilla.redhat.com/show_bug.cgi?id=1926932 > > Hi, > there is written the cause of the failure: > https://bugzilla.redhat.com/show_bug.cgi?id=1926932#c4 > > To cite Jakub: > > So, seems this has nothing to do with LTO, and is related to the > extern template class std::basic_string; > extern template class std::vector; > extern template class std::list; > lines in src/syncevo/util.h , removing them makes the problem go away. > > Could you try whether it'll work properly for you too, when you remove > those lines, please? This was meant to be a size optimization. The commit itself is almost three years old and I don't remember anymore why exactly it works (or should work), but my former self left a comment in the commit message: C++: instantiate some templates once in libsyncevolution This saves some space (total number of blocks for SyncEvolution object files when building statically down from 421588 to 413300) and presumably also build times (not measured). However, it did not work for all templates, leading to link errors when trying to add std::map and std::pair of strings. It probably also does not make sense for templates where only some functionality is used. It still works for me, but it seems that it's fragile. I'll remove it. Thanks for tracking this down. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release - 1.99.2
Patrick Ohly writes: > The newer compiler and libs resulted in some warnings which I have > addressed. Let me put that into another pre-release and if that the > still fails in Koji, we need to dig deeper. I have published 1.99.2: https://downloads.syncevolution.org/syncevolution/sources/syncevolution-1.99.2.tar.gz As before, it is also available as deb via the "experimental" channel. Those packages no longer depends on an old libcppunit. Milan, can you perhaps try those sources without akonadi? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release
Milan Crha writes: > On Sat, 2021-01-30 at 14:20 +0100, Patrick Ohly wrote: >> Do you have a more recent build log with the failure? > > Hi, > sure, I re-ran the build here: > https://koji.fedoraproject.org/koji/taskinfo?taskID=61020990 > > On Sat, 2021-01-30 at 18:23 +0100, Patrick Ohly wrote: >> /usr/bin/ld: cannot find -lkdeui >> /usr/bin/ld: cannot find -lkdecore > > Fedora carries a patch for it: > https://src.fedoraproject.org/rpms/syncevolution/blob/master/f/syncevolution-1.4.1-akonadi.patch I'll commit that. >> Perhaps also remove KDE support from the Fedora .spec file? > > Right, I can probably do it. I only do not know how many users are > actually using it. Probably not that many. If there are some, then removing the feature and waiting for the outcry may be the only way to find them :-/ I already asked here, without any responses. > If you know there are issues with it, then the best > would be, probably, to drop the code from the sources, otherwise I'm > afraid the users might eventually request to enable it in the package. If a user wants it, then I'd be more motivated to actually support it. I'd prefer to keep it in the source for now, just in case that someone capable enough wants to try it out by compiling from source. Regarding the link error: I tried to reproduce by building exactly with the same configure options in a Rawhide docker container, but for me it worked: https://nightly.syncevolution.org/latest/fedoraw-rawhide/nightly.html The newer compiler and libs resulted in some warnings which I have addressed. Let me put that into another pre-release and if that the still fails in Koji, we need to dig deeper. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release
Patrick Ohly writes: > Milan Crha writes: >> On Sat, 2020-12-19 at 12:40 +0100, Patrick Ohly wrote: >>> I have tagged and built SyncEvolution 1.99.1, a pre-release of what >>> will become 2.0.0. >> >> Hi, >> I gave it a try under Fedora Rawhide and after removing unneeded >> downstream patches and updating one due to the boost changes (see the >> attached patch) I get a linker error (see the very end of the log): >> https://kojipkgs.fedoraproject.org//work/tasks/2132/58912132/build.log > > Unfortunately I looked at this too late and now the link isn't working > anymore. Do you have a more recent build log with the failure? > > I also tried to reproduce this and (at the same time) prevent future > regressions by building on rawhide inside a Docker container. However, > that currently fails because rawhide containers don't work on current > runc runtimes (https://bugzilla.redhat.com/show_bug.cgi?id=1900021). I was able to work around that by disabling the seccomp filter in the "docker run" invocation. I fixed a few compiler warnings related to C++17 and GObject deprecations and now it fails to link with: libtool: link: g++ -Wl,--as-needed -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/11/crtbeginS.o src/backends/akonadi/.libs/syncakonadi_la-akonadisyncsource.o -Wl,-rpath -Wl,/srv/runtests/docker/2021-01-30-06-46-fedora-rawhide-fedoraw-rawhide/tmp/build/src/syncevo/.libs -Wl,-rpath -Wl,/usr/lib64 -L/usr/lib64/ -lakonadi-kde -lQtDBus -lQtXml -lQtCore -lkdeui -lkdecore src/syncevo/.libs/libsyncevolution.so -lrt -L. -L/usr/lib/gcc/x86_64-redhat-linux/11 -L/usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/11/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/11/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/crtn.o -Wl,--as-needed -g -O2 -Wl,--as-needed -pthread -Wl,-soname -Wl,syncakonadi.so -o src/backends/akonadi/.libs/syncakonadi.so /usr/bin/ld: cannot find -lkdeui /usr/bin/ld: cannot find -lkdecore That's with --enable-akonadi, something that I wanted to stop testing because there are known issues with it even when it compiles. Perhaps also remove KDE support from the Fedora .spec file? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release
Robert K writes: > Hello Patrick, > > I did a second test, and it was also not successfull. > > What I did today on a Linux Mint 19.3 well running system: > (1) Timeshift snapshot > (2) Download and extract "syncevolution-1.99.1-bundle-amd64.tar.gz" > (3) sudo cp -a usr/* /usr > (4) Reboot > (5) Try to start syncevo-http-server end up in this: > > robert@T550:~$ syncevo-http-server http://localhost:9000/syncevolution > Traceback (most recent call last): > File "/usr/bin/syncevo-http-server", line 8, in > from twisted.internet import gireactor # for non-GUI apps > ModuleNotFoundError: No module named 'twisted' The script is now using Python3. You have to install python3-twisted instead of python-twisted. This is not covered by package dependencies because not everyone will need this. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Invalid signature for SyncEvolution 1.5.3 repo
Graham Cobb writes: > On 28/02/2019 21:15, Patrick Ohly wrote: >> Long story short, it should work again. Remember that as users you still >> need to renew the signing key with: >> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9 > > Thanks Patrick, that works now. > > Now I have a different problem: using the 1.5.3 packages I can't get > syncevolution to recognise the webdav backends (caldav or carddav). > > After some debugging, it seems there is a missing dependency on > libneon27-gnutls. Installing that allows the webdav backends to be > recognised (syncdav.so requires libneon-gnutls.so.27). I realized that I never replied to this. That the "syncevolution-bundle" doesn't have dependencies for *any* of the backends is actually intentional. It makes it possible to put everything into one .deb without forcing users to install all dependencies, even for those backends that they don't use. For Evolution, "syncevolution-evolution" is a meta package which adds the extra dependencies for EDS. I could of course split up into "proper" packages (main, one per backend), but that would be more complex. Ideally, distros package SyncEvolution properly. "SYNCEVOLUTION_DEBUG=10 syncevolution --version" prints additional information about which backends could (or couldn't) be loaded: SYNCEVOLUTION_DEBUG=10 syncevolution --version ... Loaded backend library syncfile Loading backend library syncecal_2 failed: libecal-2.0.so.1: cannot open shared object file: No such file or directory Loading backend library syncecal_1 failed: libecal-2.0.so.1: cannot open shared object file: No such file or directory Loaded backend library syncecal Loading backend library syncebook_2 failed: libebook-1.2.so.20: cannot open shared object file: No such file or directory Loading backend library syncebook_1 failed: libebook-1.2.so.20: cannot open shared object file: No such file or directory Loaded backend library syncebook ... This is normal because the EDS backends needs to be compiled multiple times for different EDS releases. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] SyncEvolution 2.0.0 pre-release
Hello! I have tagged and built SyncEvolution 1.99.1, a pre-release of what will become 2.0.0. As discussed in https://lists.01.org/hyperkitty/list/syncevolution@syncevolution.org/thread/I3TDB7HTXJDQACI3Y54QXDEYGFPQLOTW/ I am simplifying the binaries (no more i386, no KDE). The new release is available as: - source code: https://downloads.syncevolution.org/syncevolution/sources/syncevolution-1.99.1.tar.gz https://gitlab.freedesktop.org/SyncEvolution/syncevolution - tar archive: https://downloads.syncevolution.org/syncevolution/bundle/amd64-tar-gz/syncevolution-1.99.1-bundle-amd64.tar.gz - in the *experimental* apt repo: deb http://downloads.syncevolution.org/apt experimental main The GPG key for all apt repos were renewed. To get the current signing key, use sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9 Speaking of signing keys, so far I used an expiry period of one year. Would anyone care if I made that longer? The .deb package installs on Debian Stable and Ubuntu Bionic. It does not currently install on Debian Testing and Ubuntu Groovy because libcppunit changed its ABI. I intend to address that before 2.0.0. As a workaround, one can manually install https://packages.debian.org/buster/amd64/libcppunit-1.14-0/download manually beforehand (untested!). I have tested the new binaries with Bluetooth/OBEX and a Nokia N97 and CardDAV with Google Contacts. Automated testing is also up again, but with less coverage than before (only Memotoo for SyncML, Google Contacts, Google Calendar). Testing is based on containers now. If someone wants to see interoperability and/or compilation tested with other platforms (TDE, OwnCloud), then a Dockerfile which prepares a suitable environment would be a good start for adding that. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Small patch for TDE plugins
deloptes writes: > deloptes wrote: > >> Hi Patrik, >> as you mentioned you are working on some kind of next release. I wonder if >> you could add a patch or let me know how I can add it (attached). >> >> I found out it should not destroy here as it is being (probably) cleaned >> up somewhere else. Destroying here crashes. >> >> I also wonder if we would be able to use openobex2 (1.7) in the new >> version. >> >> thank you in advance >> >> kind regards > > Hmm, to me it looks like I attached some nonsense here - sorry for > this :) And sorry for the delay with integrating this ;-) It's now in a branch and getting tested (again). I first ran into some issue with "make dist" which I solved as follows: commit e489ac358b3f1c40f45d7c3c55a7a9aaea85e41f (HEAD -> master-next, tag: syncevolution-2-0-0-pre2, pohly/for-master/master-next, master-nightly-before-2020-12-17-04-10, master-nightly) Author: Patrick Ohly Date: Thu Dec 17 03:22:07 2020 -0800 tde: fix "make dist" issue "make dist" tries to include all source files in the archive, which does not work for the generated files. diff --git a/src/backends/tdepim/tdepim.am b/src/backends/tdepim/tdepim.am index 5aace174..4c898944 100644 --- a/src/backends/tdepim/tdepim.am +++ b/src/backends/tdepim/tdepim.am @@ -38,8 +38,6 @@ if ENABLE_TDEPIMNOTES src_backends_tdepim_synctdepimnotes_src += \ src/backends/tdepim/TDEPIMSyncSource.h \ src/backends/tdepim/TDEPIMSyncSource.cpp \ - src/backends/tdepim/KNotesIface_stub.h \ - src/backends/tdepim/KNotesIface_stub.cpp \ src/backends/tdepim/TDEPIMNotesSource.h \ src/backends/tdepim/TDEPIMNotesSource.cpp endif @@ -59,13 +57,25 @@ src/backends/tdepim/KNotesIface_stub.h: src/backends/tdepim/KNotesIface.kidl src/backends/tdepim/KNotesIface_stub.cpp: src/backends/tdepim/KNotesIface_stub.h -CLEANFILES += src/backends/tdepim/KNotesIface_stub.h \ +src_backends_tdepim_built_sources = +src_backends_tdepim_generated = +if ENABLE_TDEPIMNOTES +src_backends_tdepim_built_sources += \ + src/backends/tdepim/KNotesIface_stub.h \ src/backends/tdepim/KNotesIface_stub.cpp \ + +src_backends_tdepim_generated += \ + $(src_backends_tdepim_built_sources) \ src/backends/tdepim/KNotesIface.kidl \ src/backends/tdepim/KNotesIface_skel.cpp \ src/backends/tdepim/KNotesIface.h +endif + +CLEANFILES += $(src_backends_tdepim_generated) +BUILT_SOURCES += $(src_backends_tdepim_built_sources) src_backends_tdepim_synctdepimcal_la_SOURCES = $(src_backends_tdepim_synctdepimcal_src) +nodist_src_backends_tdepim_synctdepimcal_la_SOURCES = $(src_backends_tdepim_built_sources) src_backends_tdepim_synctdepimcal_la_LIBADD = $(TDEPIMCAL_LIBS) $(SYNCEVOLUTION_LIBS) src_backends_tdepim_synctdepimcal_la_CPPFLAGS = $(TDEPIMCAL_CFLAGS) $(src_backends_tdepim_cppflags) src_backends_tdepim_synctdepimcal_la_LDFLAGS = -module -avoid-version -ldl -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH System Software Engineering/Cloud Native Usenerstr. 5a Phone: +49-228-2493652 53129 Bonn Germany ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Fixing the Maemo backend
Merlijn Wajer writes: > I'm interested in getting the Maemo backend up and running again, to be > used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable > Devuan/Debian). BTW, what happened with Buteo? I though that was the sync solution for Maemo. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Fixing the Maemo backend
Merlijn Wajer writes: > Hi, >> Is there perhaps a Dockerfile that provides everything that is needed to >> build for Maemo? I could use that for automatic build and perhaps even >> functional testing. > > Hm... There isn't one yet, but I could attempt to make one. We do have > virtual images that can run in QEMU/Virtualbox, but that probably isn't > quite what you are looking for: https://leste.maemo.org/Virtual_Machine > > I can try to write a Dockerfile in the next day or two. If the Maemo backend needs D-Bus, then note that I have a solution for that: https://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/test/dbus-session.sh It can be invoked inside a container and wraps another command (like bash) which then has a D-Bus session. So all that the Dockerfile has to provide is really just the libraries and binaries for Maemo. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Fixing the Maemo backend
Merlijn Wajer writes: > Hi, > > On 04/10/2020 16:23, Merlijn Wajer wrote: >> Hi, >> >> On 04/10/2020 13:58, Patrick Ohly wrote: >>> Merlijn Wajer writes: >>>> I'm interested in getting the Maemo backend up and running again, to be >>>> used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable >>>> Devuan/Debian). >>> >>> As you noticed, that backend needs a maintainer. I'm currently trying to >>> get an updated SyncEvolution release-ready (using more modern C++, >>> adapted to recent versions of the libraries it depends on). If you care >>> about Maemo to work in that release, then now is a good time to debug >>> this. >> >> Ok, if I can bend it into shape I'm happy to maintain it for now. > > Please let me know if you would like me to pick up some maintenance > tasks. As per below, I currently have the code working with the latest > syncevolution. Being available to test and fix the code if necessary is a good first step. I can't even compile it myself because I lack a system with the necessary libraries. Is there perhaps a Dockerfile that provides everything that is needed to build for Maemo? I could use that for automatic build and perhaps even functional testing. > So the problem wasn't in syncevolution at all. That said -- what can I > do to get the Maemo backend marked as active again? Marked where? It's not enabled by default in configure because most people won't have the necessary libraries available and probably also don't want to build it. That EDS is enabled by default is partly a historic exception, partly because I suspect that most users are using it. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
Patrick Ohly writes: > deloptes writes: > >> Hi Patrick, >> I am afraid I do not have your skills, but I am very thankful that you take >> your time to investigate. >> As mentioned before I always compile the old version from source (creating >> debian packages for the desktop and rpm for the phone) >> , then compiling the rest linked to the openobex library and it works like >> it was working 10y ago. > > Unfortunately I cannot reproduce that. SyncEvolution 1.5.3 compiled anew > against libopenobex1 also gets stuck with thew new phone after sending > the second SAN message, i.e. the same symptom as with libopenobex2. > > It's a bit random - once I saw a permission denied error for that SAN, > but most of the time it's just stuck. > > I'm now trying to get the dead N97 working again. I've ordered a new > battery, perhaps then it'll start again. Got the new battery, which worked until it also ran out of power. To cut a long story short, it was the charger which didn't work with the phone. After trying with a different one, I could charge both batteries again... So far with the good news. The bad news is that libopenobex2 works fine with that phone, i.e. I cannot reproduce the regression. Deloptes, can you try building the for-master/master-next branch (currently rev 83a31729, but may get rebased again) and sync with that using: SYNCEVOLUTION_DEBUG=10 syncevolution --daemon=no --sync-property loglevel=10 ... 2>&1 | tee sync.log That will print log messages for OBEX_Request and OBEX_HandleInput. Please send me the log file. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
deloptes writes: > Hi Patrick, > I am afraid I do not have your skills, but I am very thankful that you take > your time to investigate. > As mentioned before I always compile the old version from source (creating > debian packages for the desktop and rpm for the phone) > , then compiling the rest linked to the openobex library and it works like > it was working 10y ago. Unfortunately I cannot reproduce that. SyncEvolution 1.5.3 compiled anew against libopenobex1 also gets stuck with thew new phone after sending the second SAN message, i.e. the same symptom as with libopenobex2. It's a bit random - once I saw a permission denied error for that SAN, but most of the time it's just stuck. I'm now trying to get the dead N97 working again. I've ordered a new battery, perhaps then it'll start again. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Fixing the Maemo backend
Merlijn Wajer writes:
> I'm interested in getting the Maemo backend up and running again, to be
> used in 'Maemo Leste' (Maemo 5, 100% open source, based on stable
> Devuan/Debian).
As you noticed, that backend needs a maintainer. I'm currently trying to
get an updated SyncEvolution release-ready (using more modern C++,
adapted to recent versions of the libraries it depends on). If you care
about Maemo to work in that release, then now is a good time to debug
this.
There is a "for-master/master-next" branch with the revised code, but I
am still rebasing that from time to time.
> Then, I can see my calendar backends and invoke a sync, but it throws a
> weird error when I try to sync like this:
>
>> user@devuan:~$ syncevolution --sync refresh-from-client radicale calendar
>
> This error shows up a lot (but maybe it is not harmful?):
>
>> [ERROR] @default/radicalecal: basic_string::replace: __pos (which is
>4294967295) > this->size() (which is 11)
This indicates that an invalid string replace was attempted for a C++
string (out-of-bounds index), which got caught by the C++ runtime and
turned into an exception.
> Here's a slightly more verbose log, with most of my calendar events
> removed, and two (first and last) left in place, but the description
> modified.
>
>> user@devuan:~$ syncevolution --sync refresh-from-client radicale radicalecal
>> [WARNING] radicale: ignoring username , it is not needed
>> [INFO] @default/addressbook: inactive
>> [INFO] @default/calendar: inactive
>> [INFO] @default/memo: inactive
>> [INFO] @default/radicalejournal: inactive
>> [INFO] @default/radicaletodo: inactive
>> [INFO] @default/todo: inactive
>> [WARNING] radicale: ignoring username , it is not needed
>> [INFO @radicale] target side of local sync ready
>> [INFO @radicale] @radicale/addressbook: inactive
>> [INFO @radicale] @radicale/calendar: inactive
>> [INFO @radicale] @radicale/memo: inactive
>> [INFO @radicale] @radicale/radicalejournal: inactive
>> [INFO @radicale] @radicale/radicaletodo: inactive
>> [INFO @radicale] @radicale/todo: inactive
>> [INFO @radicale] @radicale/radicalecal: using configured
>> database=http://localhost:5223/merlijn/f5203b02-1985-a468-7a57-4c00a87f0850/
>> [INFO @radicale] @radicale/radicalecal: starting first time sync from client
>> (peer is server)
>> [INFO @radicale] @radicale/radicalecal: sent 190/265
>> [INFO] @default/radicalecal: starting first time sync from client (peer is
>> client)
>> [INFO] creating complete data backup of datastore radicalecal before sync
>> (enabled with dumpData and needed for printChanges)
>> @default data changes to be applied during synchronization:
>> *** @default/radicalecal ***
>> Comparison was impossible.
>>
>> [INFO] @default/radicalecal: deleting 0
>> [INFO] @default/radicalecal: started
>> [INFO] @default/radicalecal: adding "specific text removed"
>> [ERROR] @default/radicalecal: basic_string::replace: __pos (which is
>> 4294967295) > this->size() (which is 11)
There's no strack trace for the exception printed, so it's impossible to
determine where it occurs.
Try this:
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no \
--sync-property loglevel=10 \
--sync refresh-from-client radicale radicalecal
When the exception is thrown, gdb might stop.
> Would it be helpful if I also included the html log file?
No, that won't have more information about this.
--
Best Regards
Patrick Ohly
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
Patrick Ohly writes: > Patrick Ohly writes: > >> deloptes writes: >>> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly wrote: >>> >>>> Emanoil Kotsev writes: >>>> > Hi, >>>> > It is the file UPGRADING.txt in openobex not the README >>>> > Upgrading to version 1.7Upgrading to version 1.6 >>>> >>>> 1.7 is ancient (released 2016). I remember reading about "When using an >>>> event loop that triggers on incoming data, you must call >>>> OBEX_HandleInput() after each call to OBEX_Request() to actually send >>>> the request" >>>> (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt). >>>> If I remember correctly, my conclusion was that SyncEvolution does that, >>>> but I am not sure anymore. >>>> >>>> >>> I am also not sure where and how this has to be done. I think I have looked >>> into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(), >>> but I am not quite sure at all. It could be also something completely >>> different. >> >> Perhaps calling OBEX_HandleInput unconditionally after OBEX_Request is >> really missing. I don't know exactly whether it now gets called only >> when the fd is ready. > > I wanted to try that out, but it turns out that all of my SyncML-capable > phones are dead, i.e. I can no longer test the SyncML over OBEX code. I > already bought a cheap used one via eBay, but that also was dead. I'll > try with another one... I now have a phone again and can reproduce the issue. But some additional debug output shows that OBEX_HandleInput is called after OBEX_Request: [DEVELOPER 00:00:02] OBEX Transport: get header who from connect response with value SYNCML-SYNC [DEVELOPER 00:00:02] ObexTransportAgent::wait(): is ready [ERROR 00:00:02] GLib: Source ID 2 was not found when attempting to remove it [INFO 00:00:02] Server sending SAN [DEVELOPER 00:00:02] ObexTransport send is called (116 bytes) [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_Request for OBEX_CMD_PUT [DEVELOPER 00:00:02] ObexTransportAgent::wait(reply) [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_HandleInput [DEVELOPER 00:00:02] OBEX_EV_PROGRESS [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_HandleInput ^C [DEVELOPER 00:00:05] ObexTransportAgent::wait(): iteration [DEBUG 00:00:05] SuspendFlags: read 7 from fd 5 [DEBUG 00:00:05] reveived signal 2 [DEBUG 00:00:05] CancelTransport: cancelling because of SuspendFlags::ABORT [DEVELOPER 00:00:05] ObexTransportAgent::shutdown() [DEVELOPER 00:00:05] ObexTransportAgent::wait(no reply) [DEVELOPER 00:00:05] ObexTransportAgent::wait(): iteration [DEVELOPER 00:00:05] ObexTransportAgent: OBEX_HandleInput *** buffer overflow detected ***: install_new_openobex/bin/syncevolution terminated The buffer overflow is happening inside the new libopenobex after SyncEvolution called OBEX_CancelRequest and while SyncEvolution is waiting for the pending command to finish. This does not happen with the old libopenobex. That aside, the key point is that it's not getting stuck because of the issue mentioned in the openobex 1.7 release notes. Wireshark also shows that some data goes out. Unfortunately it stop decoding data at the RFCOMM level, so it's not immediately obvious what's going on for OBEX. The next step was to try with an older libopenobex. I force-installed an old libopenobex1-dev and libopenobex; that didn't install cleanly, but the files seemed to be in place and it was possible to link against them. However, the resulting binary then got stuck the same way (but allowed to abort cleanly). I also tried running the last stable release inside Docker: docker run --rm -ti --net=host --privileged --volume \ /home/pohly/.config:/config \ --volume \ /tmp/syncevolution-bundle_1.5.3-2_amd64.deb:/tmp/syncevolution-bundle_1.5.3-2_amd64.deb \ --volume /dev:/dev --volume /sys:/sys debian:stretch And inside it: apt-get update && apt-get install /tmp/syncevolution-bundle_1.5.3-2_amd64.deb -f XDG_CONFIG_HOME=/config SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --sync refresh-from-remote --sync-property loglevel=10 NokiaPhone But that segfaults while preparing the SAN, i.e. even earlier. ==2063== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==2063== Bad permissions for mapped region at address 0x7F0E358 ==2063==at 0x7F0E358: ??? (in /usr/lib/libsmltk.so.0.6.0) ==2063==by 0x56A87B5: sysync::newPCDataStringX(unsigned char const*, bool, int) (sysync_utils.cpp:2992) ==2063==by 0x56A64AD: sysync::SanPackage::GetPackageLegacy(void*&, unsigned long&, std::vector, std::allocator > > c
[SyncEvolution] Re: New to Syncevolution
Paul van der Vlis writes: > But, Syncevolution is removed from Debian, Mobian is Debian testing > based. But it's still on https://snapshots.debian.org : > https://snapshot.debian.org/package/syncevolution/1.5.3-2/ That only works with older Evolution releases. I'm working on a new release with support for more recent system libraries. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
Patrick Ohly writes: > deloptes writes: >> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly wrote: >> >>> Emanoil Kotsev writes: >>> > Hi, >>> > It is the file UPGRADING.txt in openobex not the README >>> > Upgrading to version 1.7Upgrading to version 1.6 >>> >>> 1.7 is ancient (released 2016). I remember reading about "When using an >>> event loop that triggers on incoming data, you must call >>> OBEX_HandleInput() after each call to OBEX_Request() to actually send >>> the request" >>> (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt). >>> If I remember correctly, my conclusion was that SyncEvolution does that, >>> but I am not sure anymore. >>> >>> >> I am also not sure where and how this has to be done. I think I have looked >> into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(), >> but I am not quite sure at all. It could be also something completely >> different. > > Perhaps calling OBEX_HandleInput unconditionally after OBEX_Request is > really missing. I don't know exactly whether it now gets called only > when the fd is ready. I wanted to try that out, but it turns out that all of my SyncML-capable phones are dead, i.e. I can no longer test the SyncML over OBEX code. I already bought a cheap used one via eBay, but that also was dead. I'll try with another one... -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
deloptes writes: > On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly wrote: > >> Emanoil Kotsev writes: >> > Hi, >> > It is the file UPGRADING.txt in openobex not the README >> > Upgrading to version 1.7Upgrading to version 1.6 >> >> 1.7 is ancient (released 2016). I remember reading about "When using an >> event loop that triggers on incoming data, you must call >> OBEX_HandleInput() after each call to OBEX_Request() to actually send >> the request" >> (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt). >> If I remember correctly, my conclusion was that SyncEvolution does that, >> but I am not sure anymore. >> >> > I am also not sure where and how this has to be done. I think I have looked > into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(), > but I am not quite sure at all. It could be also something completely > different. Perhaps calling OBEX_HandleInput unconditionally after OBEX_Request is really missing. I don't know exactly whether it now gets called only when the fd is ready. > In theory it should be possible that one end is using openobex-1.5 and the > other 1.7 - the protocol is the same, so I do change only openobex on one > end at a time. I don't know if I change on both ends it would start > working. Do you think it is worth trying? No, changing only one side is the right approach. I also doubt that updating both sides will magically solve it - that would imply that openobex is no longer compatible with other OBEX implementations. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
Emanoil Kotsev writes: > Hi, > It is the file UPGRADING.txt in openobex not the README > Upgrading to version 1.7Upgrading to version 1.6 1.7 is ancient (released 2016). I remember reading about "When using an event loop that triggers on incoming data, you must call OBEX_HandleInput() after each call to OBEX_Request() to actually send the request" (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt). If I remember correctly, my conclusion was that SyncEvolution does that, but I am not sure anymore. > regards > On Thursday, July 30, 2020, 1:08:31 AM GMT+2, Emanoil Kotsev > wrote: > > Hi,strange I do not see this on the ML. > I don't know how to debug this. The problem is that openobex changed - if you > look in the README it says what needs to be done to upgrade from 1.5 to 1.7.I > did not have time and ability to go deeper into openobex. > The problem is that after SAN is sent it (syncevolution) hangs waiting for > PUT or whatever and does not move forward. > > I tried few weeks ago building bueto-syncml for the (now) Sailfish OS > with openobex 1.7 and I had syncevolution 1.5.3 with openobex 1.5 on > the PC, but it hangs on the phone the same way it hangs on the PC if > it is build against openobex 1.7. I couldn't find out, how I can get > log from the plugin there as it is started in a thread an nothing > logs. Can you ensure that you have working setup and then just update the SyncEvolution side to openobex 1.7? Does that then start to fail? It's not clear to me from the description above whether that is something that you have tested. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
Graham Cobb writes: > On 24/07/2020 20:38, Patrick Ohly wrote: > * At the top of that list is ActiveSync support. activesyncd no longer >> builds on Debian Stretch because it depends on libgnome-keyring, which >> was removed. It probably can be ported to libsecret, but that's >> extra work. > > I no longer need ActiveSync myself (my employer banned it a while ago > and, more recently, I have retired anyway). I feel it is a shame to let > it die and could probably be persuaded to do some work on it if someone > actually wanted it and could provide me with access to systems to > develop and test. I was paying for one of the hosted Exchange services for a while to have something to test against. Costs were okayish, but as I wasn't really doing much with it and it became more expensive once the initial trial period was over, I canceled that. As you said, unless someone really uses it, it makes no sense to put work and real money into ActiveSync support. >> I suppose users would like to see binaries again, primarily because >> SyncEvolution fell out of Debian/Ubuntu? > > Now that I am retired, I am not sure what my usage will be. My (new) > master for contacts and calendar is in Owncloud/Nextcloud (mainly using > Thunderbird as UI), however I haven't decided how I will keep various > other devices synced (particularly Sailfish, if I continue to use that). > > I would find it convenient to have Debian binaries although I don't know > if I will need them long term. > > I am disappointed, having worked on PIM sync for many years, that the > world seems to be willing to settle for very limited and mostly locked > up services from Microsoft, Apple or Android. I know what you mean :-( There still seem to be people who care, but their number is shrinking. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: new SyncEvolution binaries, dropping features?
deloptes writes: > Hi Patrick, > glad to hear such good news from you - really appreciate your work. > I am actively using SyncEvolution on Debian Buster with TDE and with > Sailfish OS phone. > > I was wondering about openobex-1.7 (aka libopenobex2) - is it possible to > get it working with it? > It seems to be the new default in debian, but is not working with > SyncEvolution and you did not mention it. I'm currently building against libopenobex2-dev on Ubuntu Bionic, and that at least seems to work fine without changes to the SyncEvolution source code. However, I haven't tested syncing via OBEX with the resulting binaries. When you say "is not working", what problems do you see? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] new SyncEvolution binaries, dropping features?
[Most of the text below was written in December 2019, but than unintentionally sent to an internal mailing list - no surprise that I never got any response!] Hello! Over the Christmas holidays I worked on building a new SyncEvolution release. My current goal is to build for Ubuntu Bionic (most recent LTS) and support those binaries on all more recent Debian and Ubuntu releases. If possible, I'd like to drop unused features if they require extra effort. This mostly depends if someone still needs them. Let me list some features that I'd like to remove. If you still need them, please respond here: * At the top of that list is ActiveSync support. activesyncd no longer builds on Debian Stretch because it depends on libgnome-keyring, which was removed. It probably can be ported to libsecret, but that's extra work. * x86 (i.e. 32 bit) binaries - it doubles the testing effort. * RPMs - they never had proper dependencies and I am not sure whether they ever worked at all. * Akonadi support and KDE in general. I first encountered problem with Akonadi in Debian Stretch and reported it here with a stand-alone reproducer: https://bugs.kde.org/show_bug.cgi?id=369203 But as pointed out in that issue, the API that SyncEvolution uses is no longer supported and thus SyncEvolution would have to be ported to the current API, whatever that is - I haven't investigated that. * Port to Python 3 and stop supporting Python 2. Regarding the source code, I'd like merge all pending patches. This obviously includes all the changes that are required to build on more recent Linux distros, but also the C++ modernization that I started a while back. The result will be more than just a simple bug fix release, but also not something that has any new user-visible features. I'm not entirely happy with that, but I also don't want to be stuck completely in pure maintenance mode. I got testing on the newer Linux distros working with the updated code base already beginning of this year, but then got stuck because of a regression and lack of time to dig into that. Since then, the apt repo keys expired and I haven't renewed them because the binaries probably wouldn't work anyway. I suppose users would like to see binaries again, primarily because SyncEvolution fell out of Debian/Ubuntu? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Fails to build with boost 1.73.0
Milan Crha writes: > On Fri, 2020-07-03 at 17:34 +0200, Milan Crha wrote: > >> I'd propose a patch, but I do not know a single bit of the boost >> library. > > Hi, > it turned out to be a semi-mechanical replace. See the attached > bind.patch. Thanks, that looks reasonable. I really should continue my upstream work on preparing the next release with all of these patches :-/ Bye, Patrick ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: syncevolution funambol: Not working after upgrade to newest Debian Testing Version
Roth writes: > Hello Patrick, > > I can't syncronize any more. After 7 years of successful sync via > Funambol server, it is not working. > > This is the error: > > First ERROR encountered: error code from SyncEvolution error parsing > config file (local, status 20010): calmobile: backend not supported by > any of the backend modules (syncxmlrpc, synctdepimnotes, synctdepimcal, > synctdepimabc, syncsqlite, syncqtcontacts, syncpbap, syncmaemocal, > synckcalextended, syncfile, syncdav, provideroauth2, providergoa, > platformtde, platformkde, platformgnome) or not correctly configured > (backend=calendar databaseFormat= syncFormat=text/calendar Which SyncEvolution binaries are you using? The ones from syncevolution.org don't work on Debian testing because Evolution Data Store (EDS) changed its API. I need to update them and do a new release which Tino then hopefully can get into Debian again. It was removed because of the Python2 dependency. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Sync failure - F31
writes: > I have to correct my typing from yesterday. > > The item to deactivate is calendar not memo > > and i have activated > calendar and todo as single items You are synchronizing against Funambol, according to your command line from the previous email, right? The default for Funambol is to have separate stores for calendar, tasks and memos (https://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/src/templates/servers/Funambol.ini). Are you saying that you configured that differently and that is no longer working? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Sync failure - F31
Max Pyziur writes: > On Tue, 5 Nov 2019, deloptes wrote: > >> Max Pyziur wrote: >> >>> >>> Greetings, >>> >>> I'm not sure if this is the first time running sync since upgrading to >>> F31. >>> >>> But through F30, Sync has worked flawlessly Syncing with memotoo and >>> evolution. I'm behind on updating SyncEvolution, sorry for that. I have to do a new release which is based on and tested with the current set of libraries available in modern distros. Milan does an excellent job with keeping the packages building, but this can't replace upstream testing. >> I am on debian - don't know F. >> >>> Now, using the gui interface, the following error message appears: >>> The sync process died unexpectedly. >>> >>> I've tried slow sync, deleting the data on the server via the gui, but >>> each time the process dies with some variant of the above message. >>> >>> So, I'm looking for some sort of log file to see if there any messages or >>> other indications of where the flaw would be. >>> >>> >> >> Run it from the command line >> >> SYCNEVOLUTION_DEBUG=3 syncevolution -r loglevel=6 addressbook >> >> then in your ~/.cache/syncevolution you find the logs > > Much thanks for your quick reply. > > What parameters and syntax are required for ? is the name of your configuration. See "syncevolution --print-configs". -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Usenerstr. 5a Phone: +49-228-2493652 53129 Bonn Germany ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[SyncEvolution] Re: Problem syncing some accounts
deloptes writes: > Hi Patrik, all, > I am testing BT sync with Sailfish OS (successor to N9/meego) > > There is some strange issue with some Accounts/Contacts. > > My problem is that I can not edit/modify the contact on the phone, but > locally it looks fine > > What does following mean exactly? > > When I modify contact locally and sync > > [2019-11-03 11:13:43.425] Created command 'Status' (incoming) > – > [2019-11-03 11:13:43.425] 'processStatus' - Processing incoming Status [-- > [++] [->end] [->enclosing] > > [2019-11-03 11:13:43.425] Started processing Command 'Status' (incoming > MsgID=3, CmdID=3) > [2019-11-03 11:13:43.425] WARNING: RECEIVED NON-OK STATUS 500 for > command 'Replace' (outgoing MsgID=2, CmdID=5) > [2019-11-03 11:13:43.425] - TargetRef (remoteID) = '140' > [2019-11-03 11:13:43.425] Found matching command 'Replace' for Status > [2019-11-03 11:13:43.425] dsConfirmItemOp completed, syncop=replace, > localID='', remoteID='140', FAILURE, errorstatus=500 > [2019-11-03 11:13:43.425] Status: General error 500 (original op was > wants-replace) -> aborting sync with this datastore This is for a contact modified locally (= your computer?) and then sent to the phone, right? It's impossible to tell from the information found here why the phone refused to update the contact. You'll have to look at sync logs on the phone to determine the reason for the 500 error. Or do trial-and-error runs where you make some educated guess about which change is causing the issue and then trying just that in isolation. -- Best Regards Patrick Ohly ___ SyncEvolution mailing list -- syncevolution@syncevolution.org To unsubscribe send an email to syncevolution-le...@syncevolution.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Re: [SyncEvolution] SyncEvolution 1.5.1 released
Roth writes: > Hello, > since two weeks, I guess it is since I've updated syncevolution I > experience problems connecting the server (see logfile).I get a 511 > error. > I'm using Debian Testing with syncevolution 1.5.3-2 > Any hint is very appreciated. The log shows that you connect to Funambol and that the server returns this 511 error. I've not tested against that server (or any server, to be honest) in a while, so I can't say whether that is a regression at their end. It might also be specific to the one item that SyncEvolution is trying to store on the server. The log itself doesn't show what item that is. You can try to run at a higher log level and then perhaps temporarily remove that item locally. If it was because of that item, then the sync might complete. Bye, Patrick ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Invalid signature for SyncEvolution 1.5.3 repo
Graham Cobb writes: > I wanted to try out syncevolution with the Windows 10 Debian environment. > > I tried following the instructions at > https://syncevolution.org/blogs/pohly/2018/syncevolution-153, including > using apt-key to import the signing key. That stage went fine, but I got > the following error from apt-get update: > > Err:5 https://download.01.org/syncevolution/apt stable InRelease > The following signatures were invalid: EXPKEYSIG 9B911472715D06C6 > SyncEvolution > Reading package lists... Done > W: GPG error: https://download.01.org/syncevolution/apt stable > InRelease: The following signatures were invalid: EXPKEYSIG > 9B911472715D06C6 SyncEvolution > E: The repository 'https://download.01.org/syncevolution/apt stable > InRelease' is not signed. Consider this my yearly test whether someone is still using the repo ;-} But seriously, sorry for this. I have a yearly reminder for key renewal, but managed to not renew the renewal reminder when I updated the keys last year. I had noticed the issue myself but then didn't have time to deal with it right away. This is all a bit complicated and although I have the steps written down, each year there are new surprises. This year it was that the newly signed repo was still getting rejected. I had to switch to a newer hashing algorithm. Long story short, it should work again. Remember that as users you still need to renew the signing key with: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9 I am wondering whether the one year time limit for the signing key is really worth the effort... Bye, Patrick ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Newer phones with syncml support
deloptes writes: > Another option would be to use this synchronization interface in obexd, I > posted before - but I guess it would need much more work - time that we do > not have, I guess. The OBEX synchronization support is an incomplete replacement for SyncML. I looked at it when I was doing PBAB support and my conclusion at the time was that it is not suitable for incremental sync, so I never bothered with trying to use it. But I don't remember what the exact issues were - something about long-lived identifiers for items, I believe. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Newer phones with syncml support
deloptes writes: > Interesting to know what is the status of syncevolution and what Patrick is > planning to do with it in the future. I consider SyncEvolution stable as it is and don't have plans to add features. I'll keep maintaining it as long as people use it - which I assume people still do (hard to tell with open source, in particular when users don't need to download it from syncevolution.org because it is in distros). Maintenance basically means keeping the website and a build machine for testing and build around, should a new release become necessary. I was considering a new release a while back (okay, a year ago?) but it never became a priority and thus hasn't happened. Modernizing the code to a more recent C++ was the main potential change. Bye, Patrick ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Newer phones with syncml support
deloptes writes: > if this is still alive and someone is reading - do you know any recent > phones that implement syncml. I'm still here. SyncML however looks pretty much dead. Your best bet is probably a (local?) CalDAV/CardDAV server and a phone that supports that. I don't have specific recommendations, though. Bye, Patrick ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Detect python binary name in build time
Milan Crha writes: > Hello, > there is some effort to rename 'python' to 'python2' in the > distributions, but SyncEvolution still uses 'python' (without the > version number) in its scripts. I made a change for Fedora to detect > the installed python 2 binary name and use it in the scripts. > > I know, an ideal solution would be to port to python3 at the same time, > but it's out of my knowledge, I do not speak pythonish and simple > change to /usr/bin/python3 makes the provided scripts not to run with a > runtime error about syntax and such, thus I decided to offer at least > this change to you. Maybe I'll convince someone with python knowledge > to port the scripts to python3, in which case I'd return back to you > with a follow up change, if you are interested. I'm definitely interested. The Arch maintainer filed an issue for the same problem and attached his own patch here: https://bugs.freedesktop.org/show_bug.cgi?id=107014 But as you said, the real solution has to be a port to Python3. Would it be okay to drop Python2 support entirely? Doing so in a 1.5.x maintenance release sounds too intrusive. Should I target a 1.6.0 release with Python3 as dependency and also include my "cxx-future" branch, where I require C++11? -- Best Regards Patrick Ohly ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Syncevolution chokes on one calendar entry, doesn't say which, doesn't allow to skip, doesn't show actual server's complaint
On Mon, 2018-02-12 at 10:35 +0100, Alain Knaff wrote: > Hi, > > When trying to use synccalendar, I occasionally get the following: > > [INFO @aev] operation temporarily (?) failed, going to retry in 5.0s > before giving up in 298.7s: REPORT 'check for items': bad HTTP > status: > > And then repeats the message with ever growing delays. 503 indicates a temporary error, so the WebDAV layer is correctly retrying it for a while. If that problem persists for certain operations, then the server operator and/or developer needs to investigate that. > Apparently, sync-evolution or the server doesn't like a certain > calendar > entry, and rather than move on to the next, just gets stuck on it. Primarily this is the server. It could of course also be caused by bad data being sent by SyncEvolution, but then the server should outright reject it instead of reporting a temporary error. > Sometimes killing syncevolution, and then starting it again fixes > the > issue, and sometimes not. Btw, to kill syncevolution, just using > Ctrl-C > doesn't do the job, you've actually got to use the kill command from > another terminal session, or use Ctrl-Z and then kill. You should get a message that you need to use Ctrl-C twice to abort immediately. Otherwise it tries to suspend the sync, which is less intrusive and may allow resuming it the next time. But I just tried that and noticed that there is no such message. I'm testing a fix. Ctrl-C twice however should work. > May I suggest three small changes to make this issue much less > painful: > > 1. When such a thing occurs, actually say *which* calendar entry > causes > this. For most practical cases date, time and title should be enough > to > uniquely identify the entry and allow the user to "manually" transfer > it > (i.e. manually delete it on phone, manually change/create it on > server, > and sync it back), or even to allow him to understand what is > causing > this. This isn't as easy to implement as it seems. The layer which runs into the temporary error has no idea what item it is dealing with, and in some cases the "offending" calendar entry might not even be in the operation (for example, a PUT which removes some item from a larger set). Once the operation times out, the upper layers should print a proper ERROR message about the failed items. As the error in your case isn't really "temporary" and retrying the request doesn't make it go away, you might want to reduce the RetryDuration in your target configuration (the WebDAV side). > 2. The message just echoes the HTTP Status line, and not the rest of > the > contents of the server's error page. Maybe the server (MS Exchange > via > davmail) does indeed explain what's the issue with that calendar > entry? > Bad status? Bad Reminder options? etc.? Impossible to know easily, > as > nowadays most server use HTTPs and so even tcpdump wouldn't be any > help. How should SyncEvolution render the error response? Quite often it is HTML. There's also the risk of spewing a lot of text to the console. The INFO message is intentionally a single line. If someone wants to know more, they should run with a high log level (like 10) and look at the HTML log file for a failed sync to learn more about the individual HTTP requests. > 3. Rather than just retrying forever, syncevolution should skip over > the > entry, move on to the next, and repeat in the final summary message > that > such-and-such entry was skipped (and identify the entry as described > in > point 1) It shouldn't retry forever. The default is 5 minutes. Remember that this is for the case where the server really is loaded. Giving up a sync too soon would just make the situation worse because the next sync then might have to be done in slow mode, so IMHO it makes sense to try for a while. > Other question: I run syncevolution on a BQ Aquaris E5 phone with > Ubuntu > Touch. Ubuntu no longer supports touch, however, and apt-get upgrade > has > stopped working for a while. So I'm stuck at version > 1.5.1+15.04.20160706-0ubuntu1 > > However, UBports has taken up this task, and I suppose they've got a > repository somewhere from which to get updates from them. > Unfortunately > there site is silent on that issue, and only describes how to > install > ubports from scratch on a new device, and not how to upgrade an > existing > Ubuntu touch device. Do you by chance know what to enter into > /etc/apt/sources.list to get updates from UBports rather than from > Ubuntu? Sorry, I'm not familiar with Ubuntu phones (never had one). > Third question: due to this whole dropped support issue, I'm in the > market for a new phone, and it will either be stock Android or > Lineage > OS (due to current lack of othe
Re: [SyncEvolution] SSL related regression in 1.5.3
On Mon, 2018-01-22 at 22:07 +0100, Tino Mettler wrote:
> On Wed, Jan 17, 2018 at 10:51:56 +0100, Patrick Ohly wrote:
> > Yes, that's it: https://developer.gnome.org/libsoup/stable/libsoup-
> > sess
> > ion-porting.html mentions that the default has changed.
> >
> > So this might work:
> >
> >
> > // use CA certificates if available and needed,
> > // otherwise let soup use system default certificates
> > if (m_verifySSL) {
> > if (!m_cacerts.empty()) {
> > g_object_set(m_session.get(), SOUP_SESSION_SSL_CA_FILE,
> > m_cacerts.c_str(), NULL);
> > }
> > } else {
> > // Checking enabled by default, disable it.
> > g_object_set(m_session.get(), SOUP_SESSION_SSL_STRICT,
> > false,
> > NULL);
> > }
>
> Hi,
>
> it worked for me. I included this patch in the 1.5.3 package that I
> intend to upload this week.
Thanks for testing. I'll do a 1.5.4 with the same fix, but better don't
wait for 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.
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SSL related regression in 1.5.3
On Wed, 2018-01-17 at 09:19 +0100, Tino Mettler wrote:
> On Sun, Jan 14, 2018 at 21:37:36 +0100, Tino Mettler wrote:
>
> [...]
>
> > From my point of view, people using HTTPS this way (both set to 0)
> > should just fix their setup, but I don't know if someone really is
> > required to use such SSL settings. The description in the sample
> > config reads as if "SSLVerifyHost" is disabled when setting
> > "SSLVerifyServer" to 0.
>
> Hi Patrick,
>
> are you aware of possible setups that might require both config
> variables set to 0?
Only for testing, for example a server that runs with a self-signed
certificate that was created for a different domain than the one
currently used by the server. It's probably worthwhile to enable this
again.
I still need to look into it when I have the time. I'm not sure how it
worked before: SoupTransportAgent::send() only sets the CA cert file
when SSL checking is enabled (= either of the two options on). It
doesn't (and never has) disabled SSL checking, so if that now happens
to be enabled by default, then that's the problem.
Yes, that's it: https://developer.gnome.org/libsoup/stable/libsoup-sess
ion-porting.html mentions that the default has changed.
So this might work:
// use CA certificates if available and needed,
// otherwise let soup use system default certificates
if (m_verifySSL) {
if (!m_cacerts.empty()) {
g_object_set(m_session.get(), SOUP_SESSION_SSL_CA_FILE,
m_cacerts.c_str(), NULL);
}
} else {
// Checking enabled by default, disable it.
g_object_set(m_session.get(), SOUP_SESSION_SSL_STRICT, false,
NULL);
}
--
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.
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] SyncEvolution 1.5.3 released
About SyncEvolution === SyncEvolution synchronizes personal information management (PIM) data via various protocols (SyncML, CalDAV/CardDAV, ActiveSync). It syncs contacts, appointments, tasks and memos. It syncs to web services or to SyncML-capable phones via Bluetooth. Binaries are available for Linux desktops (using GNOME Evolution, or KDE's Akonadi) and the source code also supports the Trinity Desktop Environment (TDE). About 1.5.3 === Maintenance release. syncevolution.org binaries are now getting compiled for distros >= Ubuntu Xenial 16.04 LTS. Usage of deprecated libraries (GNOME keyring) and APIs (SoupAsyncSession) was replaced. libical v3 is supported. The code now compiles more cleanly with recent compilers and depends on C++11 support. Details: * EDS: more generic open retry handling Recent EDS started to exhibit race conditions when opening a database (for example, https://bugzilla.gnome.org/show_bug.cgi?id=791306). Opening was already tried again for a certain known error in some old EDS version. Now it is tried five times with a delay of one second for all errors. * SoupTransportAgent: require libsoup 2.42, no deprecated methods This allows us to get rid of deprecated function calls. We no longer need to set a default proxy either, the newer libsoup does that itself by default. * C++: replace auto_ptr with unique_ptr, require C++11 auto_ptr has been deprecated for a while now. unique_ptr can be taken for granted now, so use that instead. * testing: work around Google CalDAV RECURRENCE-ID Stand-alone events with RECURRENCE-ID get mangled by the server: it converts the RECURRENCE-ID time to UTC. Reported in: https://stackoverflow.com/questions/47811670/detached-recurrence-without-parent-event * GNOME: replace gnome-keyring with libsecret (FDO #104219) The GNOME keyring library has been obsoleted for a long time now, long enough that the replacement libsecret is available on all supported distros. Therefore we can switch unconditionally. * libical: support libical v3 (FDO #104220) libical v3 removes some deprecated functions (like icaltime_from_timet) and removes the "is_utc" member from icaltimetype. The replacement code works with old and new libical and thus needs no ifdefs. Original author: Milan Crha * syncevolution.org: fixed packaging (FDO #98014, FDO #100549) The activesyncd package missing dependencies on libgnome-keyring0 and libglib2.0-bin and therefore failed to work when installed on a minimal system without those. * various build and test fixes/workarounds Source, Installation, Further information = http://syncevolution.org/blogs/pohly/2018/syncevolution-153-released Source code bundles for users are available in https://download.01.org/syncevolution/syncevolution/sources and the original source is in the git repositories http://cgit.freedesktop.org/SyncEvolution/ i386 and amd64 binaries for Debian-based distributions are available via the "stable" syncevolution.org repository. Add the following entry to your /etc/apt/source.list: deb https://download.01.org/syncevolution/apt stable main The GPG key for the repository needs to be imported as root with: apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9 The signing key was renewed for this release. If the key was already added earlier, refresh it with: apt-key adv --keyserver keyserver.ubuntu.com --refresh-keys 43D03AD9 Then install "syncevolution-evolution", "syncevolution-kde" and/or "syncevolution-activesync". These binaries include the "sync-ui" GTK GUI and were compiled for Ubuntu 16.04 LTS (Xenial) and should be compatible also with more recent distros. ActiveSync binaries were compiled for Debian Stretch, the upcoming Debian Buster (based on current Testing), and Ubuntu Xenial. The packages mentioned above are meta-packages which pull in suitable packages matching the distro during installation. Older distributions can no longer be supported with precompiled binaries because of missing or incompatible libraries, but the source should still compile on older distros. The same binaries are also available as .tar.gz archives in https://download.01.org/syncevolution/syncevolution/. In contrast to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise. When using activesyncd, run "glib-compile-schemas /usr/share/glib-2.0/schemas" as root after unpacking the archive. rpm packages are no longer provided due to lack of demand; SyncEvolution is provided by Fedora as a distro package. After installation, follow the http://syncevolution.org/documentation/getting-started steps. More specific HOWTOs can be found in the Wiki: https://syncevolution.org/wiki/howto -- Best Regards, Patrick Ohly
Re: [SyncEvolution] KDE5 support
On Thu, 2018-01-04 at 13:10 +0100, Tino Mettler wrote: > Hi Patrick, > > the Debian project plans to remove QT4 from the next stable release > (Buster). This means that the Akonadi backend needs to be ported to > KDE5 so it can be shipped with Buster. Do you have any plans for > this? No. I don't know if the Akonadi backend is really used, so my motivation to put further effort into it is low. My suggestion is to simply disable it in the Debian package. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Sync now" button in sync-ui is disabled
On Wed, 2018-01-03 at 20:30 +0100, Tino Mettler wrote: > On Wed, Jan 03, 2018 at 14:35:07 +0100, Tino Mettler wrote: > > > I guess this is caused by the fact that I don't use network manager > > for > > my network setup. > > Yes, it is. systemctl stop NetworkManager solved the issue. I was wondering about the "don't use network manager" part. If NetworkManager is not found, syncevo-dbus-server should fall back to the assumption that the system is online, which is indeed what you get after stopping NetworkManager. So the problem was that NetworkManager was running, but considered itself offline. Perhaps I (someone?) should rip out both the ConnMan and NetworkManager code and replace it with GNetworkMonitor. No idea whether that would have worked better in your setup, though. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Sync now" button in sync-ui is disabled
On Wed, 2018-01-03 at 11:16 +0100, Tino Mettler wrote: > On Tue, Jan 02, 2018 at 23:02:48 +0100, Patrick Ohly wrote: > > > Run dbus-monitor and look at the communication between sync-ui and > > syncevo-dbus-server. Does it show anything unusual? > > Do you mean something like "dbus-monitor > path=/org/syncevolution/Server"? That's too specific, because it only shows method calls. Responses don't use the path and then don't get logged. I usually do "dbus-monitor >/tmp/log" and then search that file. > That shows nothing unusual AFAICS. What about the GetPresence method call and the Presence signal? The log should show something like this: method call time=1514975407.648536 sender=:1.2726 -> destination=:1.2717 serial=31 path=/org/syncevolution/Server; interface=org.syncevolution.Server; member=CheckPresence string "google-private@personal" ... method return time=1514975407.684826 sender=:1.2717 -> destination=:1.2726 serial=161 reply_serial=31 string "" array [ string "local://@google-private" ] If the array is empty, then the service is considered unreachable. For SyncML, syncevo-dbus-server monitors network status via ConnMan or NetworkManager. Perhaps that isn't working anymore. See src/dbus/server/connman-client.cpp and src/dbus/server/network-manager- client.cpp. > > I also did some work on SyncEvolution to get it working better on > > recent distros (i.e. replace libraries and methods with > > contemporary > > ones). It's finally starting to pass testing without issues, so I > > could > > do a new release now. > > What git branch is that? Maybe I can use this to build some test > packages. It's the "for-master/master-next" branch in SyncEvolution and "for- master/cxx" for libsynthesis. I've also (tentatively) set the 1.5.3 version tags. If testing goes well, I will push that as the new master and publish the resulting binaries. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Sync now" button in sync-ui is disabled
On Tue, 2018-01-02 at 22:41 +0100, Tino Mettler wrote: > Hi Patrick, > > I did some updates to the Debian packages but some final testing > revealed that the "Sync now" button in sync-ui is disabled. Syncing > via command line works fine. > > The changes to the old packages are commit > 8765654ff355aed3b982bd965e98c00dfd19d1c3 > (libical: support libical v3) in libsynthesis and > ebf34f9ffe8bf575e1a20beb069ef287366d8ed8 > (GNOME: replace gnome-keyring with libsecret) as well as > f94ea6df6847d045db7a45fe8b4cfa0b344dfc58 > (libical: support libical v3) in syncevolution. > > I have to admit that I don't use sync-ui myself but only check if it > works when preparing an update, so I can not tell when it really > stopped working. Due to the libical3 transition I can't really check > if > this also happens with the old package. Any hints how I can debug > this? Run dbus-monitor and look at the communication between sync-ui and syncevo-dbus-server. Does it show anything unusual? I also did some work on SyncEvolution to get it working better on recent distros (i.e. replace libraries and methods with contemporary ones). It's finally starting to pass testing without issues, so I could do a new release now. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] [Patch] Fails to build with libical 3.0.0
On Thu, 2017-12-14 at 15:59 +0100, Patrick Ohly wrote: > On Thu, 2017-11-16 at 12:45 +0100, Milan Crha wrote: > > - itime = icaltime_from_timet (now, 0); > > + itime = icaltime_from_timet_with_zone (now, 0, > > NULL); > > Upstream replaced icaltime_from_timed(x, 0) > with > icaltime_from_timet_with_zone(x, 0, icaltimezone_get_utc_timezone()). > Is that perhaps also what should be done in SyncEvolution? No, internally icaltime_from_timed(x, 0) was implemented as icaltime_from_timet_with_zone(x, 0, NULL), just like your patch does, s that should be fine. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] [Patch] Fails to build with libical 3.0.0
On Thu, 2017-11-16 at 12:45 +0100, Milan Crha wrote: > - itime = icaltime_from_timet (now, 0); > + itime = icaltime_from_timet_with_zone (now, 0, > NULL); Upstream replaced icaltime_from_timed(x, 0) with icaltime_from_timet_with_zone(x, 0, icaltimezone_get_utc_timezone()). Is that perhaps also what should be done in SyncEvolution? I haven't tested whether it makes a difference yet. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] [Patch] Fails to build with libical 3.0.0
On Thu, 2017-11-16 at 12:45 +0100, Milan Crha wrote: > Hi, > syncevolution 1.5.2 fails to build with libical 3.0.0. > I attached a patch which makes it build. Let me know if anything is > wrong, please. I've not forgotten about this. Thanks for the patch, I'll try it with libical 3.0. The actual upstream patch inevitably will have to be more complex (= more ifdefs), because SyncEvolution still needs to compile for distros with older libical versions. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Wed, 2017-11-15 at 19:36 +0100, deloptes wrote: > Patrick Ohly wrote: > > On Wed, 2017-11-15 at 13:48 +0100, deloptes wrote: > > > I don't have the time now to deal with it, so it is just FYI. I > > > hope > > > we can follow up on that next. > > > > > > regards > > > > > > > > > https://gitlab.com/openobex/mainline/blob/master/UPGRADING.txt > > > > > > Upgrade guide from previous version of openobex > > > === > > > > > > Upgrading to version 1.7 > > > > > > > > > When using an event loop that triggers on incoming data, you must > > > call > > > OBEX_HandleInput() after each call to OBEX_Request() > > > to actually send the > > > request. > > > > There is a OBEX_HandleInput() call which triggers on incoming data. > > Is > > that comment meant to say that each OBEX_Request() must be followed > > by > > a OBEX_HandleInput() *immediately*, without waiting for anything? > > > > I don't know anything else except what I forwarded, but BTW do you > mean the 1.6 modifications were adopted? No, I meant that perhaps SyncEvolution does (and always has done) what's necessary. I'm not sure what exactly the required behavior is, even with the comment in the UPGRADING.txt. What you can try is finding all OBEX_Request() calls and add a OBEX_HandleInput() directly after them. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Tue, 2017-11-07 at 00:30 +0100, deloptes wrote: > On Thu, 2017-11-02 at 22:27 +0100, deloptes wrote: > > > Patrick Ohly wrote: > > > > > > > On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote: > > > > > Patrick Ohly wrote: > > > > > > > > > > > Perhaps send it to me privately? I'm not sure whether I'll > > > > > > find > > > > > > anything either, though. > > > > > > > > > > Can't we add some debug code in syncevo or obex to get the > > > > > type > > > > > of > > > > > event is causing the trouble? > > > > > The message I get after including libsynthesis in syncevo is > > > > > a > > > > > bit > > > > > different (more complete) > > > > > > > > But the initial error is still the same "OBEX Request 3 got a > > > > failed > > > > response Unknown response". > > > > > > > > If you can't track down the "Unknown response" interactively in > > > > a > > > > debugger, then you can of course also add more debug output. > > > > > > > > > > > > > > Hi Patrick, > > > > > > rsp has value 83 (0x53 == OBEX_RSP_SERVICE_UNAVAILABLE) when it > > > complains "OBEX Request 3 got a failed response Unknown response" > > > > obex_response_to_string(int rsp) in libopenobex lib/main.c is > > incomplete and lacks an entry for that code. > > > > this is true, the implicit question was if I can dig further. It would be interesting to find out where that rsp comes from. There's nothing in the source code which sets it, so I suppose it comes straight from the phone, which would imply that it is in the traffic dump. > > > Interestingly it gets this twice. The first time when SANFormat12 > > > fails and it goes into legacy > > > > Looks like a generic issue, independent of the actual message > > content. > > > > yes not related but the fall back mechanism covers it. Not sure > however if > going to SAN 1.1 is desired. I thought always 1.2 is supported by > both It definitely shouldn't fall back. > > You haven't sent me the Wireshark traffic dumps, have you? The next > > step would be to do a side-by-side comparison of the packets of a > > successful sync and a failed sync and determine where they diverge. > > > > I tried to your gmx account, if you still use it, from my other > account. If I have to use the intel one let me know I haven't seen that email, but perhaps I just missed it. Please send again and let me know here what the subject is. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Thu, 2017-11-02 at 22:27 +0100, deloptes wrote: > Patrick Ohly wrote: > > > On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote: > > > Patrick Ohly wrote: > > > > > > > Perhaps send it to me privately? I'm not sure whether I'll find > > > > anything either, though. > > > > > > Can't we add some debug code in syncevo or obex to get the type > > > of > > > event is causing the trouble? > > > The message I get after including libsynthesis in syncevo is a > > > bit > > > different (more complete) > > > > But the initial error is still the same "OBEX Request 3 got a > > failed > > response Unknown response". > > > > If you can't track down the "Unknown response" interactively in a > > debugger, then you can of course also add more debug output. > > > > > > Hi Patrick, > > rsp has value 83 (0x53 == OBEX_RSP_SERVICE_UNAVAILABLE) when it > complains "OBEX Request 3 got a failed response Unknown response" obex_response_to_string(int rsp) in libopenobex lib/main.c is incomplete and lacks an entry for that code. > Interestingly it gets this twice. The first time when SANFormat12 > fails and it goes into legacy Looks like a generic issue, independent of the actual message content. > The second time when it dies in my case. > What can I do next? Can you file a bug about that against libopenobex? I suppose https://sourceforge.net/p/openobex/bugs/ is still the bug tracker of the project. You haven't sent me the Wireshark traffic dumps, have you? The next step would be to do a side-by-side comparison of the packets of a successful sync and a failed sync and determine where they diverge. Alternatively, the OBEX transport could be re-written so that it uses obexd. libopenobex has been legacy code now for a long time. But I am not sure whether obexd really supports SyncML. Looking at https://git.k ernel.org/pub/scm/bluetooth/bluez.git/tree/doc/obex-api.txt seems to imply that it only supports certain well-known protocols (PBAP, for example) and not SyncML. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote: > Patrick Ohly wrote: > > > Perhaps send it to me privately? I'm not sure whether I'll find > > anything either, though. > > Can't we add some debug code in syncevo or obex to get the type of > event is causing the trouble? > The message I get after including libsynthesis in syncevo is a bit > different (more complete) But the initial error is still the same "OBEX Request 3 got a failed response Unknown response". If you can't track down the "Unknown response" interactively in a debugger, then you can of course also add more debug output. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Fri, 2017-10-06 at 23:01 +0200, deloptes wrote: > Patrick Ohly wrote: > Please note that the reference used with obex1.5 is not build this > way. Let > me know if I have to do the same with obex1.5 That would only be necessary if we wanted to debug obex1.5 at the source level. This doesn't seem necessary yet. > I did include libsynthesis in syncevolution with obex1.7 and got the > wireshark capture, but I can understand almost nothing out of it. > May I attach the captured traffic? My concern is that IMEI of the > phone is > in the packets. Perhaps send it to me privately? I'm not sure whether I'll find anything either, though. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Tue, 2017-10-03 at 10:35 +0200, deloptes wrote: > Patrick Ohly wrote: > > > Interesting :-/ Perhaps try running under valgrind to root-cause > > this > > issue? > > > > I was thinking the memory errors in valgrind were related to the > tdepim > code, but it looks like it fails in the sync process when tdepim > crashes. Yes, the TDECrash::defaultCrashHandler is catching some problem and then itself causing valgrind errors. Is there some way to disable the handler? The actual problem seems to be in /usr/lib/x86_64-linux- gnu/libsmltk.so.0.6.0. Having that with debug information would be useful. Typically, during my development work I build with --disable-shared --enable-static and --with-synthesis- src=.../libsynthesis where "libsynthesis" is the source dir of libsynthesis. That way, I get a single executable that has the right compile flags and all code included, i.e. I can set breakpoints right away without having to wait for shared libraries to get loaded. It also avoids problems with picking up system shared libraries. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Sat, 2017-09-30 at 21:17 +0200, Patrick Ohly wrote: > So that's still the same error. The question now is, where does this > "Unknown response" come from? What is the actual response code and > where was it set? Another way to approach this might be to take network traffic dumps with wireshark of the Bluetooth communication with old and new libopenobex, then compare packets. There shouldn't be that many of them yet, at least when it fails. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Fri, 2017-09-29 at 22:22 +0200, deloptes wrote: > I'm not sure I did all correctly > > export LD_LIBRARY_PATH=/data-backup/DEVELOPMENT/Projects/tde- > sup/sync_debug/openobex-1.7.2-Source/debian/build/lib Looks like you are building libopenobex via the Debian packaging. That's just unnecessarily complex and might have undesired effects like stripping the lib during a build. It's enough to checkout the source, apply my patch, then configure with "CFLAGS=-g" and "make" (no need for "make install" or anything like that). Anyway, you can check with "list obex_hdr_it_equals" under gdb (after loading the lib, for example after that segfault or after a "breakpoint main") whether you have debug information in the lib, and whether the listed source has my patch. > SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no -r loglevel=6 > nokia_N9 > addressbook > > > > DEBUG 00:00:02] ready to sync > [DEBUG 00:00:02] starting SAN 12 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce > SyncEvolution session 1 server PC Suite > [DEBUG 00:00:02] SAN datastore addressbook uri Contacts type 7 mode > 206 > [DEVELOPER 00:00:02] ObexTransportAgent::wait(no reply) > [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration > ... > [same removed] > ... > [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration > [DEVELOPER 00:00:04] Connecting Bluetooth device with address > 40:98:4E:90:56:E3 and channel 25 > [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration > [DEVELOPER 00:00:04] OBEX_EV_PROGRESS > [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration > [DEVELOPER 00:00:04] OBEX_EV_REQDONE > [DEVELOPER 00:00:04] OBEX Transport: get header who from connect > response with value SYNCML-SYNC > [DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready > [INFO 00:00:04] Server sending SAN > [DEVELOPER 00:00:04] ObexTransport send is called (46 bytes) > [DEVELOPER 00:00:04] ObexTransportAgent::wait(reply) > [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration > [DEVELOPER 00:00:04] OBEX_EV_PROGRESS > [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration > [DEVELOPER 00:00:04] OBEX_EV_REQDONE > [DEVELOPER 00:00:04] ObexTransport send completed > [DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready > [DEVELOPER 00:00:04] OBEX_EV_PROGRESS > [DEVELOPER 00:00:04] OBEX_EV_REQDONE > [ERROR 00:00:04] OBEX Request 3 got a failed response Unknown > response So that's still the same error. The question now is, where does this "Unknown response" come from? What is the actual response code and where was it set? I'm afraid that will require a lot of digging in the libopenobex sources. I don't have a clue what to look for, therefore I cannot provide further guidance. > [DEBUG 00:00:04] Server Alerted Sync init with SANFormat 12 failed, > trying with legacy format > [DEBUG 00:00:04] starting SAN 11 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce > SyncEvolution session 1 server PC Suite > [DEBUG 00:00:04] SAN datastore addressbook uri Contacts type text/x- > vcard > [DEBUG 00:00:04] SAN with overall sync mode 206 > [kcrash] TDECrash: Application 'SyncEvolution' crashing... > Segmentation fault > > In GDB > > Program received signal SIGSEGV, Segmentation fault. > 0x72614358 in smlLibMemcpy () from /usr/lib/x86_64-linux- > gnu/libsmltk.so.0 > (gdb) Interesting :-/ Perhaps try running under valgrind to root-cause this issue? -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)
On Mon, 2017-09-04 at 20:24 +0200, deloptes wrote:
> Patrick Ohly wrote:
>
> > So have you built 1.5.2 with libopenobex2 from Debian Stretch and
> > it
> > failed? With which phone?
> >
>
> yes - built 1.5.2 with libopenobex2 from Debian Stretch.
> phone is Nokia N9
Unfortunately I indeed don't have that phone.
> > What I did is a "configure --disable-shared --enable-static
> > CFLAGS=-g
> > CXXFLAGS=-g ..." and then in the build directory I ran
> > "SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no nokia-n97-
> > mini@
> > devices addressbook".
> >
> > This allows running the command under gdb. The interesting line is
> > is
> > the error message in ObexTransportAgent::obex_callback. What value
> > does
> > obex_rsp have, and why does OBEX_ResponseToString not know it?
>
> I may try test this next and post the output.
Please do.
I continued debugging this a bit further by running syncevolution under
valgrind. When using libopenobex2, I get:
==15128== Conditional jump or move depends on uninitialised value(s)
==15128==at 0x4C31CD6: __memcmp_sse4_1 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15128==by 0x918502D: obex_hdr_it_equals (obex_hdr.c:298)
==15128==by 0x918661A: obex_msg_post_prepare (obex_msg.c:87)
==15128==by 0x918661A: obex_msg_prepare (obex_msg.c:117)
==15128==by 0x9184096: obex_client_request_tx_prepare (obex_client.c:237)
==15128==by 0x9183358: OBEX_Request (api.c:512)
==15128==by 0x10AF304: SyncEvo::ObexTransportAgent::connectReq()
(ObexTransportAgent.cpp:237)
I don't get that with the older libopenobex. That further strengthens
the hypothesis that this is a regression in libopenobex - unless of
course they changed the API and SyncEvolution now lacks some changes,
but it doesn't look like that this is the case.
Found it. This patch on top of https://gitlab.com/openobex/mainline
master (no changes since 1.7.2 one year ago) fixes it:
From b496d1781db9c23c9984fc15108871fe21b5fd0d Mon Sep 17 00:00:00 2001
From: Patrick Ohly <patrick.o...@intel.com>
Date: Tue, 5 Sep 2017 10:53:30 +0200
Subject: [PATCH 1/1] obex_hdr.c: avoid reading uninitialized memory in
obex_hdr_it_equals
valgrind correctly reports that the memcmp() in obex_hdr_it_equals()
depends on uninitialized memory:
==15128== Conditional jump or move depends on uninitialised value(s)
==15128==at 0x4C31CD6: __memcmp_sse4_1 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15128==by 0x918502D: obex_hdr_it_equals (obex_hdr.c:298)
==15128==by 0x918661A: obex_msg_post_prepare (obex_msg.c:87)
==15128==by 0x918661A: obex_msg_prepare (obex_msg.c:117)
==15128==by 0x9184096: obex_client_request_tx_prepare (obex_client.c:237)
==15128==by 0x9183358: OBEX_Request (api.c:512)
==15128==by 0x10AF304: SyncEvo::ObexTransportAgent::connectReq()
(ObexTransportAgent.cpp:237)
...
That's because on x86-64, the iterator struct contains padding which
does not get initialized by obex_hdr_it_init_from():
(gdb) p sizeof(it)
$13 = 16
(gdb) p sizeof(it.is_valid)
$14 = 4
Instead of fixing all places where an iterator might get set up, it
seems safer to limit the comparison to the individual fields. There
are few enough of them that this should not affect performance.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
lib/obex_hdr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/obex_hdr.c b/lib/obex_hdr.c
index 48576a3..a660405 100644
--- a/lib/obex_hdr.c
+++ b/lib/obex_hdr.c
@@ -295,5 +295,5 @@ void obex_hdr_it_next(struct obex_hdr_it *it)
int obex_hdr_it_equals(const struct obex_hdr_it *a, const struct obex_hdr_it
*b)
{
- return a && b && (memcmp(a, b, sizeof(*a)) == 0);
+ return a && b && a->list == b->list && a->is_valid == b->is_valid;
}
--
2.11.0
Deloptes, can you rebuild libopenobex2 with that patch and check
whether it helps? It's enough to do "cmake . && make", then set
LD_LIBRARY_PATH so that it includes the lib directory when invoking
syncevolution, i.e. there's no need to actually install libopenobex.
I do get another valgrind hit in libsynthesis also with the older
libopenobex, but that's later. Here's the fix for that:
From de5f1c80d180c326d02f431c6c3189f1ca9ae6b3 Mon Sep 17 00:00:00 2001
From: Patrick Ohly <patrick.o...@intel.com>
Date: Tue, 5 Sep 2017 11:03:44 +0200
Subject: [PATCH 1/1] xltenc.c: fix integer underflow
"len" is unsigned, so subtracting 2 yields a very high value and then
the comparison against n causes memory to be read beyond the end of
the buffer when the buffer is smaller than 2.
Happens in SyncEvolution when sending a SAN message to a phone via
OBEX. In practice this typically had no effect because the
uninitialized memory is unlikel
Re: [SyncEvolution] Sync on Debian Stretch
On Mon, 2017-09-04 at 19:11 +0200, deloptes wrote: > Patrick Ohly wrote: > > > Have you gotten around to testing this combination? > > > > I just tried with SyncEvolution master (= 1.5.2), libopenobex2 from > > Debian Stretch (= 1.7.2-1), and a Nokia N97 mini. No problem here. > > > > FWIW, the binaries from syncevolution.org shouldn't be affected, > > because for the 1.5.2 release I had started linking libopenobex.a > > from > > Ubuntu Trusty directly into the binaries. That's of course not a > > solution for binaries compiled from source. > > Hi > I have no Nokia N97 mini and for the Trinity Desktop I have to > compile from > source. > I am not sure if you are asking me, but as it is posted in this > thread, I > just assume it. > On top I use Debian Stretch - the problem reported originally is > based on it. So have you built 1.5.2 with libopenobex2 from Debian Stretch and it failed? With which phone? I'm just asking for the sake of completeness. I probably won't have your exact phone either :-/ What I did is a "configure --disable-shared --enable-static CFLAGS=-g CXXFLAGS=-g ..." and then in the build directory I ran "SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no nokia-n97-mini@ devices addressbook". This allows running the command under gdb. The interesting line is is the error message in ObexTransportAgent::obex_callback. What value does obex_rsp have, and why does OBEX_ResponseToString not know it? -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync on Debian Stretch
On Thu, 2017-07-27 at 14:23 +0200, deloptes wrote: > I'll just look into if 1.5.2 works with > libopenobex1. If so it will be much easier. Have you gotten around to testing this combination? I just tried with SyncEvolution master (= 1.5.2), libopenobex2 from Debian Stretch (= 1.7.2-1), and a Nokia N97 mini. No problem here. FWIW, the binaries from syncevolution.org shouldn't be affected, because for the 1.5.2 release I had started linking libopenobex.a from Ubuntu Trusty directly into the binaries. That's of course not a solution for binaries compiled from source. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync on Debian Stretch
On Thu, 2017-07-27 at 14:23 +0200, deloptes wrote: > As reported originally it dies with error "OBEX Request 3 got a > failed response Unknown response" etc. One would need to dig into the source of ObexTransportAgent.cpp and libopenobex2 to determine what that unknown response is and why it occurs. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync on Debian Stretch
On Thu, 2017-07-27 at 10:16 +0200, deloptes wrote: > I think this will work also, because it looks like the problem is > coming from the obex lib. Thanks for root causing this. Unfortunately I have no idea what changed in libopenobex. I also haven't written the code which uses it, so I'd be in for some amount of reverse-engineering before I might be able to fix it :-/ -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Comparison was impossible"
-from-remote, that is > supposed to completely reset the local problem on the phone, and surprise: > > $ syncevolution --sync refresh-from-remote owncloud contacts > [WARNING] owncloud: ignoring username , it is not needed > [INFO] @default/9frfrenchholiday: inactive > [INFO] @default/9rd2q8ps5e2r48skvidunfkoms8: inactive > [INFO] @default/addressbook: inactive > [INFO] @default/calendar: inactive > [INFO] @default/memo: inactive > [INFO] @default/todo: inactive > [WARNING] owncloud: ignoring username , it is not needed > [INFO @owncloud] target side of local sync ready > [INFO @owncloud] @owncloud/addressbook: inactive > [INFO @owncloud] @owncloud/calendar: inactive > [INFO @owncloud] @owncloud/memo: inactive > [INFO @owncloud] @owncloud/todo: inactive > [INFO @owncloud] @owncloud/contacts: using configured > database=[censored]/remote.php/carddav/addressbooks/Vincent/contacts > [INFO @owncloud] @owncloud/contacts: starting first time sync from > client (peer is server) > [INFO @owncloud] @owncloud/contacts: sent 141/141 > [INFO] @default/contacts: starting slow sync from client (peer is client) > [INFO] creating complete data backup of datastore contacts before sync > (enabled with dumpData and needed for printChanges) > @default data changes to be applied during synchronization: > *** @default/contacts *** > Comparison was impossible. > > [INFO] @default/contacts: deleting "AAA AAA" > [...] > [INFO] @default/contacts: adding "AAA AAA" > [...] > [INFO] @default/contacts: received 141 > [INFO @owncloud] @owncloud/contacts: started > [INFO] @default/contacts: slow sync done successfully > [INFO @owncloud] @owncloud/contacts: first time sync done successfully > > Synchronization successful. > > Changes applied during synchronization (@owncloud): > +---|---|---|-CON-+ > | | @owncloud | @default| FLI | > |Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | > +---+-+-+-+-+-+-+-+-+-+ > | contacts | 0 | 0 | 0 | 0 | 141 | 0 | 0 | 0 | 0 | > | refresh-from-local, 44 KB sent by client, 0 KB received| > +---+-+-+-+-+-+-+-+-+-+ > | start Sun May 14 20:51:55 2017, duration 0:28min | > | synchronization completed successfully| > +---+-+-+-+-+-+-+-+-+-+ > [INFO] creating complete data backup after sync (enabled with dumpData > and needed for printChanges) > > Synchronization successful. > > Changes applied during synchronization: > +---|---|---|-CON-+ > | | @default| @owncloud | FLI | > |Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS | > +---+-+-+-+-+-+-+-+-+-+ > | contacts | 141 | 0 | 141 | 0 | 0 | 0 | 0 | 0 | 0 | > | refresh-from-remote, 0 KB sent by client, 44 KB received | > | item(s) in database backup: 141 before sync, 141 after it | > +---+-+-+-+-+-+-+-+-+-+ > | start Sun May 14 20:51:54 2017, duration 0:30min | > | synchronization completed successfully| > +---+-+-+-+-+-+-+-+-+-+ > > Data modified @default during synchronization: > *** @default/contacts *** > Comparison was impossible. > > > > > The AAA contact can't be seen in the Contact app at this time! Even if > you previous command reveal it in the database: > $ syncevolution --print-items owncloud contacts > pas-id-5918A7640233: AAA AAA > [...] So presumably the X-DELETED-AT was preserved on the server (you can check by dumping it again). The server still shows the contact (because it doesn't know what that property means), but the phone hides it (because it knows the property). -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Comparison was impossible"
On Sat, 2017-05-13 at 14:33 +0200, Vincent Lambert wrote: > Le 12/05/2017 à 09:13, Patrick Ohly a écrit : > > On Thu, 2017-05-11 at 15:45 +0200, Vincent wrote: > >> - Mail original - > >>> De: "Patrick Ohly" <patrick.o...@intel.com> > >>> À: "Vincent" <vincent.lambe...@free.fr> > >>> Cc: syncevolution@syncevolution.org > >>> Envoyé: Jeudi 11 Mai 2017 10:31:28 > >>> Objet: Re: [SyncEvolution] "Comparison was impossible" > >>> > >>> Have you seen my latest reply in the mail thread? You didn't respond > >>> to > >>> that, so perhaps it got lost. I'm attaching it again. > >>> > >> > >> Yes I just anwsered you in the next message, here is the message: > > That mail didn't reach the list. > > > >> I first did a refresh-from-remote sync, but if I delete a > >> contact from my phone, a regular sync didn't delete it on the server. So > >> I tried with a complete reset of my config and database. I've deleted > >> all my contacts from the graphical app and did the slow sync. I have > >> always the same problem =( > > I lost track of what "the same problem" is. Are we still talking about > > the "Comparison was impossible" part or something else? > I understood that "Comparison was impossible" if often present in the > logs, so my main problem is I can't delete a contact on my phone, sync, > and get it deleted on the server, effectively after the > refresh-from-remote sync you recommanded. > > >> [INFO] @default/contacts: started > >> [INFO] @default/contacts: sent 1 > >> [INFO @owncloud] @owncloud/contacts: started > >> [INFO @owncloud] @owncloud/contacts: updating "Chloé" > >> [INFO @owncloud] @owncloud/contacts: received 1/1 > >> [INFO] @default/contacts: normal sync done successfully > >> [INFO @owncloud] @owncloud/contacts: normal sync done successfully > > So "Chloé" was considered "modified" locally and thus updated on the > > OwnCloud side. Directly after a "refresh from remote" that indeed > > shouldn't happen. > > Yes, I think that is correct. I don't know why syncevolution behave like > that. So the "Chloe" contact was the one you deleted after the "refresh-from-remote" sync? I bet it wasn't actually deleted when you marked it as deleted on the phone. Let's verify that hypothesis. Use "syncevolution --print-items @default contacts". It'll give you an ID string for each contact. Then use "syncevolution --export - @default contacts " to dump the contact to your console. Example (for my local setup, with "addressbook" instead of "contacts"): $ syncevolution --print-items @default addressbook pas-id-5406E787: John Doe $ syncevolution --export - @default addressbook pas-id-5406E7870000 BEGIN:VCARD VERSION:3.0 UID:pas-id-5406E787 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN REV:2014-09-03T12:03:08Z(1) N:Doe;John;;; FN:John Doe X-EVOLUTION-FILE-AS:Doe\, John END:VCARD Is there anything in your "Chloe" contact that might mark it as "deleted"? If unsure, then dump it directly after the refresh-from-remote and again after deleting it in the UI. If you can still dump it after deleting, then it definitely wasn't deleted for real. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Comparison was impossible"
On Thu, 2017-05-11 at 15:45 +0200, Vincent wrote: > > - Mail original - > > De: "Patrick Ohly" <patrick.o...@intel.com> > > À: "Vincent" <vincent.lambe...@free.fr> > > Cc: syncevolution@syncevolution.org > > Envoyé: Jeudi 11 Mai 2017 10:31:28 > > Objet: Re: [SyncEvolution] "Comparison was impossible" > > > > Have you seen my latest reply in the mail thread? You didn't respond > > to > > that, so perhaps it got lost. I'm attaching it again. > > > > > Yes I just anwsered you in the next message, here is the message: That mail didn't reach the list. > I first did a refresh-from-remote sync, but if I delete a > contact from my phone, a regular sync didn't delete it on the server. So > I tried with a complete reset of my config and database. I've deleted > all my contacts from the graphical app and did the slow sync. I have > always the same problem =( I lost track of what "the same problem" is. Are we still talking about the "Comparison was impossible" part or something else? > [INFO] @default/contacts: started > [INFO] @default/contacts: sent 1 > [INFO @owncloud] @owncloud/contacts: started > [INFO @owncloud] @owncloud/contacts: updating "Chloé" > [INFO @owncloud] @owncloud/contacts: received 1/1 > [INFO] @default/contacts: normal sync done successfully > [INFO @owncloud] @owncloud/contacts: normal sync done successfully So "Chloé" was considered "modified" locally and thus updated on the OwnCloud side. Directly after a "refresh from remote" that indeed shouldn't happen. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Comparison was impossible"
On Thu, 2017-05-11 at 09:12 +0200, Vincent wrote: > Do you have any idea? =/ Have you seen my latest reply in the mail thread? You didn't respond to that, so perhaps it got lost. I'm attaching it again. -- 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. --- Begin Message --- On Mon, 2017-05-01 at 17:15 +0200, Vincent Lambert wrote: > Le 28/04/2017 à 11:36, Patrick Ohly a écrit : > > On Fri, 2017-04-28 at 10:18 +0100, Graham Cobb wrote: > > > On 28/04/17 10:05, Patrick Ohly wrote: > > > > On Fri, 2017-04-28 at 10:31 +0200, Vincent wrote: > > > > > Could you tell me more about synccompare? > > > > In the syncevolution.org packages, it is under /usr/bin/synccompare. > > > > It's a perl script that takes two database dumps and compares them, > > > > similar to a diff between text files. > > > I find it to be of variable usefulness. It is great when it works, but > > > in my experience it scales horribly. > > I just use it on a laptop and it works for me, but I agree that it's > > mostly a hack originating in the automated testing. There's even a bug > > open for rewriting it... > > > > > I think I always see "comparison was impossible" with refreshes. I > > > assumed that is because the databases are deleted or something (although > > > thinking about it further I am not sure that is a reasonable expectation). > > There should be "before" and "after" dumps also for refreshes, so this > > has to be something else. > > > > So what is the goal of this command? It's purely informational. It's not needed for the sync to work. > I deleted the two related to my configuration, restarted to clear the > sessions and then added again my notes taken from there > http://influence-pc.fr/03-07-2015-synchroniser-ses-contacts-et-calendrier-dubuntu-phone-via-owncloud-cosy-cloud > (was working from past 2 years) so just after the first "sync slow" here is > what I can see: So was this a slow sync or a refresh-from-remote sync? > Changes applied during synchronization: > +---|---|---|-CON-+ > | | @default| @owncloud | FLI > | > |Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS > | > +---+-+-+-+-+-+-+-+-+-+ > | contacts | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 > | > | slow, 0 KB sent by client, 44 KB received > | > | 140 item(s) matched > | > | item(s) in database backup: 140 before sync, 140 after it > | > +---+-+-+-+-+-+-+-+-+-+ > | start Mon May 1 16:47:48 2017, duration 0:13min > | > | synchronization completed successfully > | > +---+-+-+-+-+-+-+-+-+-+ > > Data modified @default during synchronization: > *** @default/contacts *** > Comparison was impossible. > > > Even if I delete the config, the backup database still contain > entries! Not the *backup* database. Your local *system* database still has these 140 contacts. Removing the SyncEvolution configuration does not clean that database, because it exists independently from SyncEvolution. So for a slow sync, the behavior quoted above is as expected. A "--sync refresh-from-remote" would tell SyncEvolution to erase the local contacts before the sync, so all of them then should show up as "new" on the local side. -- 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. --- End Message --- ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Comparison was impossible" "
On Mon, 2017-05-01 at 17:15 +0200, Vincent Lambert wrote: > Le 28/04/2017 à 11:36, Patrick Ohly a écrit : > > On Fri, 2017-04-28 at 10:18 +0100, Graham Cobb wrote: > > > On 28/04/17 10:05, Patrick Ohly wrote: > > > > On Fri, 2017-04-28 at 10:31 +0200, Vincent wrote: > > > > > Could you tell me more about synccompare? > > > > In the syncevolution.org packages, it is under /usr/bin/synccompare. > > > > It's a perl script that takes two database dumps and compares them, > > > > similar to a diff between text files. > > > I find it to be of variable usefulness. It is great when it works, but > > > in my experience it scales horribly. > > I just use it on a laptop and it works for me, but I agree that it's > > mostly a hack originating in the automated testing. There's even a bug > > open for rewriting it... > > > > > I think I always see "comparison was impossible" with refreshes. I > > > assumed that is because the databases are deleted or something (although > > > thinking about it further I am not sure that is a reasonable expectation). > > There should be "before" and "after" dumps also for refreshes, so this > > has to be something else. > > > > So what is the goal of this command? It's purely informational. It's not needed for the sync to work. > I deleted the two related to my configuration, restarted to clear the > sessions and then added again my notes taken from there > http://influence-pc.fr/03-07-2015-synchroniser-ses-contacts-et-calendrier-dubuntu-phone-via-owncloud-cosy-cloud > (was working from past 2 years) so just after the first "sync slow" here is > what I can see: So was this a slow sync or a refresh-from-remote sync? > Changes applied during synchronization: > +---|---|---|-CON-+ > | | @default| @owncloud | FLI > | > |Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS > | > +---+-+-+-+-+-+-+-+-+-+ > | contacts | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 > | > | slow, 0 KB sent by client, 44 KB received > | > | 140 item(s) matched > | > | item(s) in database backup: 140 before sync, 140 after it > | > +---+-+-+-+-+-+-+-+-+-+ > | start Mon May 1 16:47:48 2017, duration 0:13min > | > | synchronization completed successfully > | > +---+-+-+-+-+-+-+-+-+-+ > > Data modified @default during synchronization: > *** @default/contacts *** > Comparison was impossible. > > > Even if I delete the config, the backup database still contain > entries! Not the *backup* database. Your local *system* database still has these 140 contacts. Removing the SyncEvolution configuration does not clean that database, because it exists independently from SyncEvolution. So for a slow sync, the behavior quoted above is as expected. A "--sync refresh-from-remote" would tell SyncEvolution to erase the local contacts before the sync, so all of them then should show up as "new" on the local side. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Comparison was impossible" "
On Fri, 2017-04-28 at 10:18 +0100, Graham Cobb wrote: > On 28/04/17 10:05, Patrick Ohly wrote: > > On Fri, 2017-04-28 at 10:31 +0200, Vincent wrote: > >> Could you tell me more about synccompare? > > > > In the syncevolution.org packages, it is under /usr/bin/synccompare. > > It's a perl script that takes two database dumps and compares them, > > similar to a diff between text files. > > I find it to be of variable usefulness. It is great when it works, but > in my experience it scales horribly. I just use it on a laptop and it works for me, but I agree that it's mostly a hack originating in the automated testing. There's even a bug open for rewriting it... > I think I always see "comparison was impossible" with refreshes. I > assumed that is because the databases are deleted or something (although > thinking about it further I am not sure that is a reasonable expectation). There should be "before" and "after" dumps also for refreshes, so this has to be something else. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] "Comparison was impossible" "
On Thu, 2017-04-20 at 11:39 +0200, Vincent Lambert wrote: > Since this step, I'm not able anymore to delete contact from my phone > and make it sync on the server (to delete the contact on the server > itself), instead the contact is just "cleared" (any information > disappear but the contact is still here and keep firstname and > lastname). I can sync contact created on the server on my phone and > send contacts created on my phone on the server. > > > It seems the backup database is corrupted but I'm not able to reset > completely my config. I just wanted to start by zero but I can't find > any way to do this. :'( A --sync refresh-from-remote should reset your local data. It ignores any existing items in the local database and also generates a new local backup. Have you done that? I'm not sure why you get the "comparison impossible" message. Perhaps synccompare is not installed or not usable (it needs Perl). -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Recent sync problem
On Mon, 2017-04-10 at 09:29 +0200, Daniel CLEMENT wrote: > Hello, > > My syncing (with Memotoo) has been running smoothly for quite a while, > but just this weekend errors have appeared. > > It looks as if every second sync attempt wants a slow sync. The slow > sync is successful, and the subsequent normal sync also works. But at > the next attempt I'm back to the same problem. > > Only my main PC (Linux Mint Debian Jessie) has this problem, another one > with the very same config (in principle) syncs flawlessly. Just to rule out the obvious, these two configurations do not share the same local device ID? > I'd be tempted to "refresh from server"; is that the right thing to do? Might be worth a try. Somehow thw slow syncing didn't finish properly, because the output you quoted showed that it tries to resume (which the server probably doesn't support). I ran the automated testing against Memotoo today and found no issues. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] strange problem with debian packages
On Mon, 2017-01-30 at 19:27 +0100, deloptes wrote: > Hi, > I build debian packages from syncevolution-1.5.2 for the Trinity desktop. > However when I isntall the packages and try run a test sync I get following > error > > SYNCEVOLUTION_DEBUG=3 syncevolution -r loglevel=6 nokia_N5530 addressbook > [DEBUG 00:00:00] SuspendFlags: (re)activating, currently inactive > [DEBUG 00:00:00] SuspendFlags: activating signal handler(s) with fds 8->7 > [DEBUG 00:00:00] SuspendFlags: catch signal 2 > [DEBUG 00:00:00] SuspendFlags: catch signal 15 > Fatal: Undefined function 'RELAXEDCOMPARE' in script at line 58 > Fatal error 20010, no valid configuration could be read from XML file > [ERROR 00:00:01] internal error, invalid XML configuration (without > datastores): > > When I compile and install in a custom directory the same code works. > Do you have an idea where I had to look for the root cause? 'RELAXEDCOMPARE' is provided by src/sysync/multifielditemtype.cpp in libsynthesis. In the case where it fails you need to check which libsynthesis was getting used and why it doesn't provide that function. $ strings /usr/lib/libsynthesis.so.0 | grep 'RELAXEDCOMPARE' RELAXEDCOMPARE -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] [INFO] SoupTransport Failure
On Sat, 2017-01-14 at 22:59 -0700, Eric O'Connor wrote: > Thank you, all. I now have a configuration working. > > My particular style of daftness was not realizing that > "syncURL=local://@webdav" refers to a different config than any of: > "zoho-addr", "zoho@webdav", or "target-config@zoho", and so of course > there was no datastore configured. > > This is all clearly explained in "SYNCHRONIZATION BEYOND SYNCML", line > 932 of the manual. Glad to hear that you got it working. I was wondering about how this should be explained better in the documentation, but I guess it is okay after all. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] [INFO] SoupTransport Failure
On Fri, 2017-01-13 at 16:19 -0700, Eric O'Connor wrote: > > Which documentation did you follow to get started? > > I'm going off of the man page for syncevolution. > > > It takes two commands to set up CardDAV syncing: once for the target > side (where CardDAV is used as storage) and once for the local side > (with EDS, Akonadi or plain files as local storage). > > How do you "link" the two? With syncURL=local://@webdav. > I now have a carddav config "remote", and an > evolution config "local", but how do I run the "remote" <-> "local" > combined config? Are these "target config" and "sync config" (as described in the man page under "SYNCHRONIZATION BEYOND SYNCML" or datastore configurations? > I think I need to do this manually, because I don't see a template for > Evolution mail. > > I don't understand where in the man page it tells me how to do that. The relevant example is this (from CALDAV AND CARDDAV): The following commands set up synchronization with a generic WebDAV server that supports CalDAV, CardDAV and scanning starting at the root of the server. # configure target config syncevolution --configure \ --template webdav \ syncURL=http://example.com \ username=123456 \ "password=!@#ABcd1234" \ target-config@webdav # configure sync config syncevolution --configure \ --template SyncEvolution_Client \ syncURL=local://@webdav \ username= \ password= \ webdav \ calendar addressbook # initial slow sync syncevolution --sync slow webdav In your case, you seem to be only interested in CardDAV, so let's focus on just contacts. The commands in your case should be something like this: # set up access to zoho.com syncevolution --configure \ --template webdav \ syncURL=https://contacts.zoho.com/carddav/e...@oco.nnor.org/default/ \ username='e...@oco.nnor.org password='' \ target-config@zoho # double-check access syncevolution --print-items target-config@zoho addressbook # configure sync config, enabling only addressbook syncevolution --configure \ --template SyncEvolution_Client \ syncURL=local://@webdav \ username= \ password= \ zoho \ addressbook # double-check local access syncevolution --print-items zoho addressbook # Now "zoho addressbook" is matched with "target-config@zoho addressbook" # and we can sync the two: syncevolution --sync slow zoho # All following syncs are incremental: syncevolution zoho > I now am getting: > > ➤ syncevolution --run ev-local-addr > ... > [INFO] @default/addressbook: using configured database=zoho-backend > [ERROR] sending message to child failed: > org.syncevolution.gdbuscxx.Exception: 1483751134.3343.16@tara/addressbo > ok: datastore not configured > ... I'm not sure what you configured to get to this point. As your local ~/.config/syncevolution might be in an unclean state now, it might be worthwhile to throw it away (you don't have any other configs, do you?) with "rm -rf ~/.config/syncevolution" before running the commands above. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] [INFO] SoupTransport Failure
On Fri, 2017-01-06 at 19:30 -0700, Eric O'Connor wrote: > I'm using the same username/password as I use successfully on my > iPhone, and I can run the --print-items and get a list of vcf items. > > > $ syncevolution --configure syncURL='https://contacts.zoho.com/carddav/ > e...@oco.nnor.org/default/' backend=carddav username='e...@oco.nnor.org > ' password='' sync=slow database='1483751134.3343.16@tara' > eric-contacts9 addressbook > > $ syncevolution --run eric-contacts9 > ... > [INFO] SoupTransport Failure: https://contacts.zoho.com/carddav/eric@oc > o.nnor.org/default/ via libsoup: Unauthorized > [INFO] Transport giving up after 0 retries and 0:00min It takes two commands to set up CardDAV syncing: once for the target side (where CardDAV is used as storage) and once for the local side (with EDS, Akonadi or plain files as local storage). > Perhaps one issue is that I don't really understand how syncevolution > works. I think I want to sync between my webdav "backend", and my local > evolution "datastore", using the carddav "backend". You need two datastores for that and thus two backends, not just one. > I guess when I do --print-databases, I refer to them using the thing in > between parenthesis? > > What is SyncML? I just want to sync Caldav/Carddav. Do I need to learn > about SyncML? Not really - how SyncML works is an implementation detail. It's just the general concept (configure two sides, hook them up) which needs to be understood. Which documentation did you follow to get started? The README.rst explains the general concept in the "Synchronization beyond SyncML" section and "CalDAV and CardDAV" how to use that for CardDAV. The same content is also on syncevolution.org together with specific HOWTO articles about other setups. Unfortunately the rendering there got broken in several places when moving to a new Drupal version. I'm not sure yet what to do about that - abandon Drupal, fix its setup (a bit out of my league), or fix each broken page - all not very attractive :-/ -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Fri, 2016-11-18 at 16:35 +, Graham Cobb wrote: > On 18/11/16 15:06, Patrick Ohly wrote: > > SyncEvolution can be used in such a mode - one just needs a central hub > > which supports the full semantic and attributes of everything that one > > wants to sync, and the description of what each peer supports has to be > > accurate. Unfortunately, in practice both conditions aren't completely > > met. > > I don't think either condition is anywhere near being met. Darn, there goes my self-delusion. > What backend would you suggest can be used which "supports the full > semantic and attributes of everything that one wants to sync"? I am not > aware of one, but I have only tried a few. The EDS backend has full iCalendar 2.0 support and fairly complete vCard 3.0. In both cases, additional properties can be (okay, could be) stored as extensions. However, Evolution itself does not know about custom SyncEvolution-specific extensions (should they get added), so while in theory it should leave them alone, in practice that's not guaranteed. The same is true for CalDAV and CardDAV servers: extensions are supposed to be stored and preserved, but not everyone follows that. > The second condition is the most serious. In my experience of my many > devices over the years, the question of support is the hardest. The > combinations of design limitations, bugs and strange interactions > (attribute X can't be set if attribute Y is set) is really hard to > define. Even in the case where I knew the code intimately (the GPE > implementation for Maemo) the description language could not express the > restrictions I knew about (let alone the unknown bugs!). True. The profiles in SyncEvolution try to take care of different representations, but there are always differences that are going to be problematic. > > That happens also in 1:1 syncs and is unrelated to multi-way syncing. > > In my experience it is a much smaller problem in 1:1 cases: typically > things are either supported or not and the worst I see is that syncs may > keep trying to set data which is being ignored -- but no database > changes actually occur on either side if nothing has changed. In the > multi-way case, that turns into the data changing with attributes > toggling on and off or changing values as syncs with different devices > occur, even when no data has actually changed. I haven't looked into it > for some time but I seem to remember that it is partly due to the syncs > not being part of a single sync but appearing to be subsequent events, > making changes that then have to be propagated to other devices. Hmm, when items don't change, no changes should be applied and syncing repeatedly should be stable. > I am not blaming SyncEvolution -- I am just not convinced that multi-way > sync can ever be replaced by a series of two-way syncs. That's something that would be worthwhile investigating in depth. Until then we have to agree to disagree ;-} -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Fri, 2016-11-18 at 14:08 +, Graham Cobb wrote: > On 18/11/16 13:03, Patrick Ohly wrote: > > With multi-way you mean a sync topology that has cycles? Yes, that's > > indeed not possible with SyncEvolution. I also don't see a way to do it > > as long as one is stuck with existing data formats. > > Actually, I meant even without cycles. It seems to me from my own > experiments that it is impossible (in the real world) to keep N > 2 > devices in sync just using pairwise syncs (assuming changes on any > device, but disallowing conflicting changes). The main problem is > different sets of supported attributes. > > That was the problem OpenSync tried to solve (with its centralised > database and lists of supported attributes) but SyncEvolution ignores (a > very reasonable but large simplification). SyncEvolution can be used in such a mode - one just needs a central hub which supports the full semantic and attributes of everything that one wants to sync, and the description of what each peer supports has to be accurate. Unfortunately, in practice both conditions aren't completely met. SyncEvolution has to be the SyncML server, too, which it is, under the hood, when using SyncEvolution with ActiveSync or CalDAV/CardDAV. As soon as one allows to let a remote SyncML server do conflict handling, one is pretty much at the mercy of that server. > I have tried to simulate this by using a files backend as a common point > to synchronise everything with, but I still see a lot of spurious > changes and corruptions being propagated around. The file backend is a bit limited in that it does not fully support iCalendar 2.0 semantic. It can store individual VEVENTs, but it doesn't know about relationships between items sharing the same UID. I'm not sure anymore what the implication was in practice - might only be relevant when dealing with peers which themselves do not support the semantic. > That means that, for the time being, I am forced to treat Outlook as my > master and only do one-way syncs from there to my other devices. I suspect the reason for the spurious changes was more related to poor conversion between Outlook data formats and the master storage. As soon as a peer is expected to store data correctly and then doesn't, that undesired modification may get propagated back. That happens also in 1:1 syncs and is unrelated to multi-way syncing. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Running test cases without network access
On Fri, 2016-11-18 at 14:16 +0100, Tino Mettler wrote: > Btw., I just uploaded 1.5.2 to Debian Sid. Thanks! :-) -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Wed, 2016-11-16 at 09:48 +, Graham Cobb wrote:
> On 16/11/16 08:43, Tino Mettler wrote:
> > On Wed, Nov 16, 2016 at 08:16:29 +0100, Patrick Ohly wrote:
> >
> > [...]
> >
> >> while Buteo was a "cleanly designed" framework which avoided doing
> >> any of the hard work and delegated that to "plugins". In other
> >> words, it didn't actually solve the problems.
> >
> > OpenSync reloaded? :-)
>
> Oooh, a bit of a low blow :-)
Emotions running high ;-)
> I certainly learnt a lot from spending quite a lot of effort trying to
> make OpenSync work! The main one (and the main reason I am here) is
> that sync is **really** hard to do in the general case.
Amen to that.
I don't have a problem with trying out different ways of doing syncing.
Sometimes people have to try first before they realize how hard it is.
I'm just a bit sad and disappointed when those attempts then tie up
resources for years without actually leading to something that helps
users.
Then there are the projects with great claims ("Synchronize your your
PIM data to your mobile phone, iPod, Nokia Internet tablet, or between
computers" - search for it, it's a verbatim copy) although that's at
best a goal for the future. At least users find out about that as soon
as they dig deeper.
Worse is to sync data and then break it along the way, because then
users stop using sync software.
> Syncevolution does a great job on two-way sync but it would be really
> good to solve the multi-way problem one day :-)
With multi-way you mean a sync topology that has cycles? Yes, that's
indeed not possible with SyncEvolution. I also don't see a way to do it
as long as one is stuck with existing data formats.
--
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.
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Tue, 2016-11-15 at 23:04 +0100, deloptes wrote: > Patrick Ohly wrote: > > During all that time, SyncEvolution has had a functional SyncML > > implementation and backends for the PIM storage in MeeGo... > > Here is what they said: > > Sync via Bluetooth isn't well supported at the moment. We allow importing > contacts from another device, and adding capability to import calendars via > Bluetooth is work-in-progress (see > https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1 and > MER#1222 for that), but true synchronisation via Bluetooth is significantly > more difficult to achieve with the current stack. Reminds me of the discussions we had about comparing Bueto with SyncEvolution. SyncEvolution always had a strong focus on actually making syncing work (and yes, that gets ugly sometimes), while Buteo was a "cleanly designed" framework which avoided doing any of the hard work and delegated that to "plugins". In other words, it didn't actually solve the problems. Too late to say "told you so" now, there's literally no-one left from those discussions and it wouldn't matter anyway. > I guess I have to wait, or get involved. I asked why not use syncevolution? > but still it would need a backend ... I don't know when I'll be able to > have a look into the sdk and mer I don't know how much current PIM storage in SailFish OS has diverged from MeeGo; for MeeGo, kcalextended and qtcontacts were the relevant backends. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Tue, 2016-11-15 at 21:57 +0100, deloptes wrote: > deloptes wrote: > > > I'll try to find information how this version is supposed to work. Perhaps > > it is missing a service in the background. > > Jolla/Sailfish OS does not have syncml implemented (yet). Work is in > progress, was the answer. Huh? Then how did you sync between your N9 and the Sail Fish OS phone? Why does it advertise SyncML support via Bluetooth? I thought Sail Fish OS had continued to use Buteo as its sync solution because that's what they got from MeeGo, and there was a SyncML implementation for that (most recent repo probably https://github.com/kavuri/buteo-syncml). If that's the code, then it has been "in progress" for several years now. During all that time, SyncEvolution has had a functional SyncML implementation and backends for the PIM storage in MeeGo... -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Mon, 2016-11-14 at 20:27 +0100, deloptes wrote: > Patrick Ohly wrote: > > >> How can I get a working template/config for the device > > > > I would start with the Nokia template. > > > > This is what I did - it loops in ObexTransportAgent::wait(): iteration for > quite some time, but I guess I have to remove PC suite parameter and who > knows what I also have to modify. That doesn't look good :-( Is the phone still supported? Is it possible to see logs from the phone side or get someone to describe how the phone is supposed to be used for syncing via SyncML? > >> I tried phone-setup, but the python script dies with an error. > > > > Which one? > > > > The script hasn't been used much, I suspect. The only remaining phones > > with SyncML support were Nokia, and those typically all used the same > > settings. > > syncevo-phone-config > > syncevo-phone-config --bt-address > 94:XX:XX:XX:XX:8D --advanced --create-config=aquafish > Running test with test data inside /tmp/syncevo-phone-config1_7yeN/data and > test results inside /tmp/syncevo-phone-config1_7yeN/cache > Starting test for 1188 configurations... > Start 1/1188 test > [DEBUG 00:00:00] checking password property 'databasePassword' in > datastore 'addressbook' of config 'test-phone' with user identity '' > [ERROR 00:00:00] addressbook: backend addressbook is ambiguous, avoid the > alias and pick a specific backend instead directly That error comes from not knowing whether the Evolution or TDE backend is supposed to be used by the script. After a quick look at the script it seems that this cannot be specified. For you, the easiest solution probably is to disable the Evolution backends when compiling SyncEvolution. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Sync with SailFish OS via Bluetooth
On Sat, 2016-11-12 at 10:17 +0100, deloptes wrote: > Hi, > I am wondering if it is possible to sync Intex Aqua Fish with SailFish OS > via SyncEvolution. > > > sdp browse > > Service Name: SyncML Client > Service RecHandle: 0x10008 > Service Class ID List: > UUID 128: 0002--1000-8000-0002ee02 > Protocol Descriptor List: > "L2CAP" (0x0100) > "RFCOMM" (0x0003) > Channel: 25 > "OBEX" (0x0008) > Profile Descriptor List: > "" (0x0002--1000-8000-0002ee02) > Version: 0x0100 > > Service Name: SyncML Server > Service RecHandle: 0x10009 > Service Class ID List: > UUID 128: 0001--1000-8000-0002ee01 > Protocol Descriptor List: > "L2CAP" (0x0100) > "RFCOMM" (0x0003) > Channel: 26 > "OBEX" (0x0008) > Profile Descriptor List: > "" (0x0001--1000-8000-0002ee01) > Version: 0x0100 > > How can I get a working template/config for the device I would start with the Nokia template. > I tried phone-setup, but the python script dies with an error. Which one? The script hasn't been used much, I suspect. The only remaining phones with SyncML support were Nokia, and those typically all used the same settings. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Problem syncing with two profiles
On Fri, 2016-11-11 at 20:11 +0100, deloptes wrote: > Patrick Ohly wrote: > > Perhaps that's the reason for the if() check: a HTTP server might > > require a different LocURI (?) than an OBEX server, and the code does > > not immediately know what it is (depends on the transport). > > I don't see it in the sync via bluetooth. I see in the html log > > device ID: syncevolution-33702b00-09b0-4a05-8eb0-4057b41667a6 > device ID: syncevolution-5c646a89-d7bb-4338-b5b5-3e6f4eb6e1f9 Where do you see that? > In the xml I see only the Nokia/Phone ID > > > IMEI:/LocURI> > > > > ./devinf12 > > > > ./contacts > > > I was also thinking that based on the device ID it might be deciding to > compare all items, which perhaps makes also sense. I'm not sure. The initial, so called SAN message, is not getting dumped. See SyncContext::sendSAN() for the code which generates it. That there's no LocURI for SyncEvolution confirms my theory that the phone can't distinguish between the different computers. However, after thinking some more about it I suspect that sending a LocURI as part of the SyncML session wouldn't help: basically the phone picks the configuration (and thus the sync anchors) based on the information in the SAN message. At least that's how SyncEvolution does it. It's worth trying with remoteIdentifier set differently on the two computers. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Problem syncing with two profiles
On Thu, 2016-11-10 at 23:09 +0100, deloptes wrote:
> deloptes wrote:
>
> > Patrick Ohly wrote:
> >
> >> Sync with what? Mobile phone?
> >>
> >
> > Yes! I use Nokia N9.
> >
>
> >> There was a bug that affected some phones such that the sync itself
> >> completed, but the OBEX connection was closed prematurely, causing some
> >> phones to believe that an error occurred. But that should be fixed in
> >> master.
> >
> > Perhaps I use loglevel=10 ?
> >
> > regards
>
> FYI: I tried now without refresh-from-remote. I synced last time in the
> office and now first time at home. It went into slow sync immediately with
> following result. The next sync was normal.
So switching between home and office triggers a slow sync? I wonder
whether the phone sees different deviceIds for the SyncEvolution side in
that case.
There are two settings in SyncEvolution for this. From a config for the
Nokia N97:
# the identifier sent to the remote peer for a server initiated sync.
# if not set, deviceId will be used instead
remoteIdentifier = PC Suite
# The SyncML server gets this string and will use it to keep track of
# changes that still need to be synchronized with this particular
# client; it must be set to something unique (like the pseudo-random
# string created automatically for new configurations) among all clients
# accessing the same server.
# myFUNAMBOL also requires that the string starts with sc-pim-
# deviceId =
We do server initiated syncs with phones, so "PC Suite" is sent to the
phone in the initial message. If I remember correctly, that had to be
that fixed string, at least with some Nokia phones.
Note that there's no unique deviceId here, which means that different
computers will all look alike to the phone, which then notices a
mismatch of sync anchors when moving between computers and thus forces a
slow sync.
Hrm, there's a nice fat TODO in src/syncevo/SyncContext.cpp about this:
if (m_serverMode) {
// TODO: set the device ID for an OBEX server
} else {
substTag(xml, "fakedeviceid", getDevID());
}
I don't remember why that if() check is there, and why
SyncConfig::createPeerTemplate()'s
config->setDevID(string("syncevolution-") + UUID()) is not used to set a
unique deviceId when configuring phones.
Answering that would require some further code archeology and
experimenting; not sure when I will have time for that. Perhaps you can
check?
Here's an example of a sync with a SyncML server:
http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_001_outgoing.xml
syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65syncevolut...@lists.intel.com
The server then replies with:
http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-5-2/testing-amd64/34-synthesis/Client_Sync_eds_contact_testItems.send.client.A/syncevolution-log_trm001_002_incoming.xml
syncevolution-4b578bb6-c5ce-41ff-be35-651e9b77ac65syncevolut...@lists.intel.com
http://www.plan44.ch/fsync_nightly
Perhaps that's the reason for the if() check: a HTTP server might
require a different LocURI (?) than an OBEX server, and the code does
not immediately know what it is (depends on the transport).
--
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.
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] survey: providing SyncEvolution binaries
On Wed, 2016-09-21 at 14:05 +0200, Tino Mettler wrote: > 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). I've released 1.5.2 and the associated tags should all be in place and final. I understand that this is closer to the Debian Stretch freeze than originally hope, but perhaps you can still get it in. Thanks for your 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On Wed, 2016-10-26 at 17:44 +0100, Graham Cobb wrote: > On 26/10/16 17:10, Patrick Ohly wrote: > > I'll try that, thanks for the hint... yes, it helped. > > Good. > > > I'm now running into some new conversion issues for calendar data (time > > zone related). To be checked. > > I can't say I am surprised. The time zone stuff is fairly fragile -- I > seem to remember putting in some hacks to try to make the best of a bad > job. Make sure that the timezone of the syncevolution system is the > same as the timezone of the Outlook calendar that creates the events (I > seem to remember there are some cases where I had to make that > assumption, which is most likely true for most people). After checking I came to the conclusion that the differences are harmless and merely come from slightly different names getting assigned to the daylight resp. standard component of the time zone. Perhaps Exchange 2016 and/or recent time zone definition changes caused that. I've updated the test cases to get clean test passes. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] SyncEvolution 1.5.2 released
* various build fixes for libical v2, GCC v6/C++14 Source, Installation, Further information = http://syncevolution.org/blogs/pohly/2016/syncevolution-152-released Source code bundles for users are available in https://download.01.org/syncevolution/syncevolution/sources and the original source is in the git repositories http://cgit.freedesktop.org/SyncEvolution/ i386 and amd64 binaries for Debian-based distributions are available via the "stable" syncevolution.org repository. Add the following entry to your /etc/apt/source.list: deb https://download.01.org/syncevolution/apt stable main The GPG key for the repository needs to be imported as root with: apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 43D03AD9 The signing key was renewed for this release. If the key was already added earlier, refresh it with: apt-key adv --keyserver keyserver.ubuntu.com --refresh-keys 43D03AD9 Then install "syncevolution-evolution", "syncevolution-kde" and/or "syncevolution-activesync". These binaries include the "sync-ui" GTK GUI and were compiled for Ubuntu 14.04 LTS (Trusty) and should be compatible also with more recent distros. ActiveSync binaries were compiled for Debian Jessie, the upcoming Debian Stretch (based on current Testing), and Ubuntu Trusty. The packages mentioned above are meta-packages which pull in suitable packages matching the distro during installation. Older distributions can no longer be supported with precompiled binaries because of missing or incompatible libraries, but the source should still compile on older distros. The same binaries are also available as .tar.gz archives in https://download.01.org/syncevolution/syncevolution/. In contrast to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise. When using activesyncd, run "glib-compile-schemas /usr/share/glib-2.0/schemas" as root after unpacking the archive. rpm packages are no longer provided due to lack of demand; SyncEvolution is provided by Fedora as a distro package. After installation, follow the http://syncevolution.org/documentation/getting-started steps. More specific HOWTOs can be found in the Wiki: https://syncevolution.org/wiki/howto -- Patrick Ohly, on behalf of everyone who has helped to make SyncEvolution possible: http://syncevolution.org/about/contributors ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Problem syncing with two profiles
On Thu, 2016-11-10 at 09:15 +0100, deloptes wrote: > Hi, > sorry to bother again, but I observed an issue performing following use > case: > > 1. Sync at home with my user profile A (it says normal sync) > 2. Sync in the office with my user profile B > 2.1 do refresh-from-remote > 2.2 do a sync after some time (it says slow sync) Sync with what? Mobile phone? > My question is why it does slow sync in 2.2? What could be the reason? This should only happen if something went wrong. The latest syncevolution-log.html should tell whether it was the local (= SyncEvolution) or the remote (= phone) side which decided to do a slow sync. Then one has to check whether the previous sync completed normally. There was a bug that affected some phones such that the sync itself completed, but the OBEX connection was closed prematurely, causing some phones to believe that an error occurred. But that should be fixed in master. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On Sun, 2016-10-23 at 22:09 +0200, deloptes wrote: > I splitted both (tde and tdepim) > > tde.patch is to prevent the wallet backend from crashing syncevolution when > enabled. Again tdewallet backend is not tested by any means as I am not > using it. > > tdepim.patch is to make the notes backend build. > > Unfortunately I was still not able to perform an e2e test with this version. > I am looking forward to do it next. Again I do not expect any functional > issues as I am using the code from the previous version on daily bases. Thanks. I've merged the patches and will prepare a final release candidate now. The nightly build machine needs to go through some maintenance soon, so I might have to finish 1.5.2 this weekend. In the future, can you commit the changes in your local git repo with a suitable commit message and then export them with "git format-patch"? Alternatively I could also revive the github mirror of the repos and you could do a pull request. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On Wed, 2016-10-26 at 16:05 +0100, Graham Cobb wrote: > > Any idea how to proceed with this? Is the policy-key workaround perhaps > > not working as intended? > > No, it is nothing to do with policy-key. That gives different symptoms: > either OK status but 0-length response or some 4nn status (419? I can't > remember). > > It looks like the problem is that a FolderSync is needed. You need to > use --print-databases. See the "Problems" in the Wiki page. I'll try that, thanks for the hint... yes, it helped. I'm now running into some new conversion issues for calendar data (time zone related). To be checked. > All my patch in bug 61869 does is enable --print-databases to be used as > a manual workround for this problem. It doesn't attempt to solve it > automatically. > > If I remember correctly, one reason I didn't try to fix it automatically > is that I couldn't reproduce the problem! If you can reproduce the > problem reliably then maybe we can try to really fix it. I didn't run into it with older Exchange or Google's ActiveSync implementation, but now with Exchange 2016 I seem to hit it reliably. > By the way, this raises a couple of interesting questions for your build > testing. The EAS support (in the backend and in activesyncd) keeps state > (in ~/.cache/activesync, in gsettings, and in the wallet). You might > want to think about whether your automated testing wants to make sure it > destroys all that state before running. The automated testing already always starts from scratch. -- 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] Release preparations for 1.5.2
On Sun, 2016-10-23 at 19:11 +0100, Graham Cobb wrote: > On 23/10/16 15:51, Graham Cobb wrote: > > I don't think that is a regression in this version (I guess the previous > > version has the same problem), although until I can work out exactly > > what is happening I can't be sure. I will look into it a little further > > but I may not be able to fix it before I go on holiday. It might even > > require proper protocol version handling (which we have avoided so far > > -- see an earlier thread about EAS versions some time ago). > > The problem turned out to be PolicyKey related (I hate "provisioning"). > This exchange server seems to handle the need for provisioning > differently and doesn't send the 449 status unless you send a bad PolicyKey. > > The workround is to make sure that the policy-key is configured in the > account gsettings. Any non-null value will do, including 0. This > triggers provisioning, which will end up eventually with a valid PolicyKey. > > I have updated the wiki page to include setting that. Thanks for the wiki update, that has already helped one person - myself! I've signed up for a hosted Exchange 2016 service and (re-)enabled that in the nightly testing, replacing gconftool-2 commands with gsettings commands as per your instructions in the wiki. I am using the policy-key workaround, but haven't actually verified whether it is needed. With the work-around, I am running into a problem (see https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/ and https://nightly.syncevolution.org/2016-10-26-05-27_exchange_sanity_release-eas-jessie-amd64_prebuilt-jessie-amd64_trusty-amd64/prebuilt-jessie-amd64/21-exchange/Client_Source_eas_contact_testImport.log.html): basically any attempt to create some item on the Exchange server fails with an error code 12 = GDBus.Error:org.meego.activesyncd.SyncError.FolderHierarchyChanged: Sync error: Mailbox folders are not synchronized, need FolderSync first Here's a snippet from the activesyncd.log: ... (process:111:0xf61d090): libeas-DEBUG:> POST /Microsoft-Server-ActiveSync?Cmd=Sync=nigh...@ouvku.hostedoffice.ag=aaa99cb14effac6a8f447AAA=MeeGo HTTP/1.1 (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug-Timestamp: 1477486033 (process:111:0xf61d090): libeas-DEBUG:> Soup-Debug: SoupSessionAsync 1 (0xf623b90), SoupMessage 10 (0x147a7170), SoupSocket 11 (0x147d23a0) ... (process:111:0xf61d090): libeas-DEBUG:Received 12 bytes for request 0x14793f00 (process:111:0xf61d090): libeas-DEBUG:< HTTP/1.1 200 OK (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug-Timestamp: 1477486034 (process:111:0xf61d090): libeas-DEBUG:< Soup-Debug: SoupMessage 10 (0x147a7170) (process:111:0xf61d090): libeas-DEBUG:< Cache-Control: private (process:111:0xf61d090): libeas-DEBUG:< Content-Type: application/vnd.ms-sync.wbxml ... (process:111:0xf61d090): libeas-DEBUG:eas_connection - wbxml2xml++ (process:111:0xf61d090): libeas-DEBUG: === dump start: xml_len [168] === http://www.microsoft.com/;> 12 === dump end === That is with your "workround folder sync when server loses state" patch applied. Any idea how to proceed with this? Is the policy-key workaround perhaps not working as intended? > There are a few things that it might be nice to do one day (i.e. will > never happen :-) )... I have a similar list ;-} > 1) The whole gsettings stuff should be hidden from the users, with some > way to pass the necessary parameters from syncevolution. > > 2) I suspect that provisioning is now being triggered every time > activesyncd is restarted as loading the account details from gsettings > means activesyncd thinks the policy key has changed when it hasn't > really. We rely on this to get it set correctly the first time, but we > ought to find a way to work out that it hasn't actually changed. > > 3) The creation of Office365 means that for users using that service, > all the required parameters (except password) can be defaulted sensibly > if we know the email address. Maybe we should allow the case of > specifying an account which has not been set up in gsettings to use the > account name as an email address and then use the Office365 defaults. The envisioned solution was some kind of external account setup, with SyncEvolution completely hidden. All of these points would fit into such a setup helper. As it stands now, SyncEvolution is just some infrastructure component of a larger system, with a command line for power users. The only problem is that this larger system has never been implemented for most desktop systems. -- 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 repre
