From mcrha at redhat.com Wed May 22 08:32:31 2019 From: mcrha at redhat.com (Milan Crha) Date: Wed, 22 May 2019 10:32:31 +0200 Subject: [SyncEvolution] Use python3 (was: Re: Detect python binary name in build time) In-Reply-To: <0ffd37ceaec899a17eb5c7fbcf4b768aeb5fecd7.camel@redhat.com> References: <588d574feb2a7b272a0329161037406b9797b5a4.camel@redhat.com> <0ffd37ceaec899a17eb5c7fbcf4b768aeb5fecd7.camel@redhat.com> Message-ID: On Fri, 2019-04-05 at 12:57 +0200, Milan Crha wrote: > The attached is a result of the files being processes > through it, including slightly modified patch proposed earlier (it > looks for python3 now, instead of python2). Hi, I've been playing with this a bit more and there's an issue with python3-twisted [1]. Once fixed, a similar issue rises with the syncevo-http-server.py. The attached is an additional change to the SyncEvolution, which removes that "import gobject", because it's not used at that file at all. If you'd prefer to keep it there (like if it's needed and I overlooked something), then you might change the import to the smart one, like in src/dbus/server/pim/examples/sync.py, where it reads: try: import gobject except ImportError: from gi.repository import GObject as gobject Hope it helps. Bye, Milan [1] https://bugzilla.redhat.com/show_bug.cgi?id=1712748 -------------- next part -------------- A non-text attachment was scrubbed... Name: py3-import-gobject.patch Type: text/x-patch Size: 463 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From xy at roth.biz Thu May 16 06:18:55 2019 From: xy at roth.biz (Roth) Date: Thu, 16 May 2019 08:18:55 +0200 Subject: [SyncEvolution] SyncEvolution 1.5.1 released In-Reply-To: <1433772013.5005.1120.camel@intel.com> References: <1433772013.5005.1120.camel@intel.com> Message-ID: 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. Many thanks Christian On Mon, 2015-06-08 at 16:00 +0200, Patrick Ohly wrote: > About SyncEvolution=================== > SyncEvolution synchronizes personal information management (PIM) > datavia various protocols (SyncML, CalDAV/CardDAV, ActiveSync). It > syncscontacts, appointments, tasks and memos. It syncs to web > services or toSyncML-capable phones via Bluetooth. > Binaries are available for Linux desktops (using GNOME Evolution, > orKDE's Akonadi), for Maemo (Nokia N900, N9) and Sailfish OS > (Jollaphone). > About 1.5.1=========== > Maintenance release. Binaries now also get compiled for Debian > 8.0"Jessie". > Details: > * avoid time zone issue with Funambol server > The Funambol iCalendar 2.0 parser fails to handle time zones with > quotation marks around the TZID value, which is something that > SyncEvolution started to add in 1.4.99.3. While it is valid to quote > like that, it is not necessary, so avoid quoting in this case to > restore interoperability. > * syncevo-http-server: stop using deprecated twisted.web.error (FDO > #90419) > This has become a real problem for example on Fedora 22 where > the old name is no longer available. > * syncevo-http-server: use TLS instead of SSLv3 > This fixes a potential security risk and connection problems with > clients that don't support SSLv3 anymore. > * syncing: avoid segfault for invalid text inside items (FDO #90118) > As reported by Canonical, syncing fails if data items contain text > which is not correct UTF-8 in one of the fields that SyncEvolution > logs in the command line output (like SUMMARY of a calendar event). > That is because the byte string coming from the item is > passed unchecked to the D-Bus implementation for transmission via D- > Bus. But D-Bus strings must be correct UTF-8, so depending on the D- > Bus library in use, one gets a segfault (GIO D-Bus, due to an > unchecked NULL pointer access) or an "out of memory" error (libdbus, > which checks for NULL). > SyncEvolution now replaces invalid bytes with a question mark in > its output while preserving the rest of the text. > * file backend: log item manipulation > Extracting a meaningful description of each item from the > Synthesis engine when updating and adding items is easy to do for > items of certain known types (contacts and calendar items). > * command line: preserve log prefix of target side of local sync > In some cases, the prefix which was supposed to be embedded in the > log messages from the target side of a local sync got lost on the > way to the command line tool. > Primarily this affected the added/updated/deleted messages, as in: > [INFO remote at client] @client/addressbook: started [INFO > remote at client] updating "Joan Doe" [INFO remote at client] > @client/addressbook: received 1/1 > * compile fix: use ${PKG_CONFIG} instead of pkg-config. > This fixes the build on Exherbo that only has prefixed versions > of pkg-config. > * WebDAV: handle 403 during Google OAuth authentication > When sending an access token with insufficient scope (for > example, because the Ubuntu Online Accounts service definition was > incomplete, as documented in FDO #86824), Google responds with a 403 > "service denied" error. > This is now dealt with by retrying, just as for a transient 401 > error. > * CalDAV: more efficient "is empty" check (FDO #86335) > Since 1.4.99.4, syncing WebDAV collections always checks > first whether there are items in the collections. This was partly > done for slow sync prevention (which is not necessary for empty > collections), partly for the "is the datastore usable" check. > However, this did not take into account that for CalDAV > collections, the entire content gets downloaded for this check. That > is because filtering by item type (VEVENT vs. VJOURNAL) is not > implemented correctly by all servers. So now all CalDAV syncs, > whether incremental or slow, always transfered all items, which is > not the intention (incremental syncs should be fast and efficient). > This release adds a more efficient isEmpty() check: for simple > CardDAV collections, only luid and etag get transferred, as > in listAllItems(). This is the behavior from 1.5. > For CalDAV, a report with a filter for the content type is used > and the transfer gets aborted after the first item, without > actually double-checking the content of the item. This is different > from listAllItems(), which really transfers the content. This extra > content check would only be needed for some old servers (Radical > 0.7) and is not essential, because reporting "not empty" even when > empty is safe. > * WebDAV: send Basic Auth via http in some cases (FDO #57248) > It turned out that finding databases on an Apple Calendar server > accessed via http depends on sending Basic Auth even when the server > does not ask for it: without authentication, there is no information > about the current principal, which is necessary for finding the > user's databases. > To make this work again, sending the authentication header is now > forced for plain http if (and only if) the request which should have > returned the principal URL fails to include it. This implies sending > the same request twice, but as this scenario should be rare in > practise (was only done for testing), this is acceptable. > * Ubuntu Online Accounts: support plain text credentials > The backend for UOA was rewritten by Alberto Mardegan and now > also can use plain username/password credentials stored in UOA. > * various compiler error and warning fixes > > Source, Installation, Further > information========================================= > http://syncevolution.org/blogs/pohly/2015/syncevolution-151-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, lpia and amd64 binaries for Debian-based distributions > areavailable via the "stable" syncevolution.org repository. Add > thefollowing 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 > B2EC3981 > Then install "syncevolution-evolution", "syncevolution-kde" > and/or"syncevolution-activesync". > These binaries include the "sync-ui" GTK GUI and were compiled > forUbuntu 10.04 LTS (Lucid), except for ActiveSync binaries which > werecompiled for Debian Wheezy, Ubuntu Saucy, Ubuntu Trusty an > DebianJessie. The packages mentioned above are meta-packages which > pull insuitable packages matching the distro during installation. > Older distributions like Debian 4.0 (Etch) can no longer be > supportedwith precompiled binaries because of missing libraries, but > the sourcestill compiles when not enabling the GUI (the default). > The same binaries are also available as .tar.gz and .rpm archives in > https://download.01.org/syncevolution/syncevolution/. In contrastto > 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and > thecontent must be moved to /usr, because several files would not be > foundotherwise. > After installation, follow the > http://syncevolution.org/documentation/getting-started steps. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Thu May 16 12:46:17 2019 From: patrick.ohly at intel.com (Patrick Ohly) Date: Thu, 16 May 2019 14:46:17 +0200 Subject: [SyncEvolution] SyncEvolution 1.5.1 released In-Reply-To: References: <1433772013.5005.1120.camel@intel.com> Message-ID: 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 at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From dclement1 at laposte.net Fri May 17 14:10:20 2019 From: dclement1 at laposte.net (Daniel CLEMENT) Date: Fri, 17 May 2019 16:10:20 +0200 Subject: [SyncEvolution] SyncEvolution 1.5.1 released In-Reply-To: References: <1433772013.5005.1120.camel@intel.com> Message-ID: <1558102220.2727.8.camel@laposte.net> Le jeudi 16 mai 2019 ? 14:46 +0200, Patrick Ohly a ?crit?: > 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. PMFJI, but I was a Funambol user once. Then Funambol became Onemediahub which in turn became Zefiro (and my account got converted without asking). Now, Zefiro is far from being a complete sync solution: it appears to work for photos, files and (maybe) contacts. (I'm not using it.) I doubt that my Funambol settings work any longer. I might have a chance to test next week on a dummy install; I'll come back then to post the results. BR, Daniel > 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 at syncevolution.org > https://lists.syncevolution.org/mailman/listinfo/syncevolution -- Daniel CLEMENT _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From xy at roth.biz Mon May 20 14:52:57 2019 From: xy at roth.biz (Roth) Date: Mon, 20 May 2019 16:52:57 +0200 Subject: [SyncEvolution] SyncEvolution 1.5.1 released In-Reply-To: References: <1433772013.5005.1120.camel@intel.com> Message-ID: <19939f20d89ca21bcc7fa6c04c2969b35c4e22af.camel@roth.biz> Hello and many thanks for your quick reply. After your answers I realized that the connection to my server was interrupted. After restarting the server it is working again as before! No bug after the update. :-) Kind regards Christian On Thu, 2019-05-16 at 14:46 +0200, Patrick Ohly wrote: > Roth writes: > > Hello,since two weeks, I guess it is since I've updated > > syncevolution Iexperience problems connecting the server (see > > logfile).I get a 511error.I'm using Debian Testing with > > syncevolution 1.5.3-2Any hint is very appreciated. > > The log shows that you connect to Funambol and that the server > returnsthis 511 error. I've not tested against that server (or any > server, tobe honest) in a while, so I can't say whether that is a > regression attheir end. It might also be specific to the one item > that SyncEvolutionis trying to store on the server. > The log itself doesn't show what item that is. You can try to run at > ahigher log level and then perhaps temporarily remove that > itemlocally. If it was because of that item, then the sync might > complete. > Bye, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcrha at redhat.com Thu May 2 12:51:52 2019 From: mcrha at redhat.com (Milan Crha) Date: Thu, 2 May 2019 14:51:52 +0200 Subject: [SyncEvolution] Port to libecal-2.0 and libebook API changes In-Reply-To: <918113471738d7160151838ae6dba2a19cd0a6da.camel@redhat.com> References: <918113471738d7160151838ae6dba2a19cd0a6da.camel@redhat.com> Message-ID: <66d8b7755cff52989827c43e3a2e9e3e7064b0ab.camel@redhat.com> On Wed, 2019-04-24 at 17:49 +0200, Milan Crha wrote: > There are going to be made huge libecal API changes... Hi, upstream libical received additional API changes in the libical-glib part, which touch also the previous patch. Even it's not released yet I prepared those new changes (attached). Bye, Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: syncevolution2.patch Type: text/x-patch Size: 1345 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From deloptes at gmail.com Thu May 2 18:59:04 2019 From: deloptes at gmail.com (deloptes) Date: Thu, 2 May 2019 20:59:04 +0200 Subject: [SyncEvolution] Port to libecal-2.0 and libebook API changes In-Reply-To: <66d8b7755cff52989827c43e3a2e9e3e7064b0ab.camel@redhat.com> References: <918113471738d7160151838ae6dba2a19cd0a6da.camel@redhat.com> <66d8b7755cff52989827c43e3a2e9e3e7064b0ab.camel@redhat.com> Message-ID: Hi, but shouldn't be somewhere there a libical version check? On Thu, May 2, 2019 at 2:50 PM Milan Crha wrote: > On Wed, 2019-04-24 at 17:49 +0200, Milan Crha wrote: > > There are going to be made huge libecal API changes... > > Hi, > upstream libical received additional API changes in the libical-glib > part, which touch also the previous patch. Even it's not released yet I > prepared those new changes (attached). > Bye, > Milan > _______________________________________________ > SyncEvolution mailing list > SyncEvolution at syncevolution.org > https://lists.syncevolution.org/mailman/listinfo/syncevolution > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From mcrha at redhat.com Fri May 3 05:47:44 2019 From: mcrha at redhat.com (Milan Crha) Date: Fri, 3 May 2019 07:47:44 +0200 Subject: [SyncEvolution] Port to libecal-2.0 and libebook API changes In-Reply-To: References: <918113471738d7160151838ae6dba2a19cd0a6da.camel@redhat.com> <66d8b7755cff52989827c43e3a2e9e3e7064b0ab.camel@redhat.com> Message-ID: <66447249359bc9c7dff450104cd8ae6d15d80034.camel@redhat.com> On Thu, 2019-05-02 at 20:59 +0200, deloptes wrote: > but shouldn't be somewhere there a libical version check? Hi, that's assured through HAVE_LIBECAL_2_0 (see the first patch at this thread). Nothing of this had been released yet, the evolution-data- server's libecal-2.0 is waiting for the libical release currently, with which it'll use libical-glib part of the libical project. The current libecal-1.2 uses plain libical. Bye, Milan _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution