Re: [SyncEvolution] SyncEvolution 1.4.99.4
On Sun, 2014-10-19 at 20:52 +0200, Patrick Ohly wrote: On Sat, 2014-10-18 at 14:32 +0100, Graham Cobb wrote: But when I tried to upgrade using apt-get install syncevolution-activesync, apt-get would have been happy to install the new syncevolution-activesync without upgrading syncevolution-activesync-saucy and syncevolution-bundle as well. Adding syncevolution-kde caused all four packages to be upgraded. I think the dependency of syncevolution-activesync on syncevolution-activesync-wheezy | syncevolution-activesync-saucy | syncevolution-activesync-trusty should be versioned to require the same version. I agree, this should be changed. Will do. The 1.5 packages now in stable have that fixed. -- 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] SyncEvolution 1.4.99.4
Hi, just a small update: 1.4.99.4 made it into Debian Jessie: https://packages.debian.org/source/jessie/syncevolution Regards, Tino ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution 1.4.99.4
On Mon, 2014-10-27 at 15:32 +0100, Tino Mettler wrote: Hi Patrick, I just want to let you know that 1.4.99.4 is now in Debian unstable. I hope it will therefore become part of the next Debian stable release. That's good, thanks for your help. I noticed this week in an unrelated article about the systemd GR that there is a feature freeze deadline coming up for Debian early next week. Do you think it would be possible to get SyncEvolution 1.5 into that if I release it this weekend? The changes compared to 1.4.99.4 are minor, but some of the changes may be relevant for users. It would be cleaner to have a regular release in Debian, too. The NEWS entry for 1.4.99.4 - 1.5 is: * vcard: fix caching of PBAP contacts (FDO #84710) After changing PBAP to send raw items, caching them led to unnecessary disk writes and bogus contacts changed reports. That's because the merge script relied on the exact order of properties, which was only the same when doing the redundant decode/encode on the PBAP side. Instead of reverting back to sending re-encoded items, better enhance the contact merge script such that it detects contacts as unchanged when just the order of entries in the property arrays is different. This relies on an enhanced libsynthesis with the new RELAXEDCOMPARE() and modified MERGEFIELDS(). * sync: ignore unnecessary username property A local sync or Bluetooth sync do not need the 'username' property. When it is set despite that, issue a warning. Previously, the value was checked even when not needed, which caused such syncs to fail when set to something other than a plain username. * D-Bus server: fix unreliable shutdown handling Occassionally, syncevo-dbus-server locked up after receiving a CTRL-C. This primarily affected nightly testing, in particular (?) on Ubuntu Lucid. * scripting: prevent premature loop timeouts The more complex avoid data loss during merging scripting ran for longer than 5s limit under extreme conditions (full logging, busy system, running under valgrind), which resulted in aborting the script and a 10500 local internal error sync failure. * signon: fix providersignon.so (TC-1667) The shared providersignon.so ended up being compiled with gsso as prefix for the username. There also was a problem with invalid reference counting. * PBAP: support SYNCEVOLUTION_PBAP_CHUNK_TRANSFER_TIME = 0 When set to 0 or less, the chunk size is not getting adapted at all while still using transfers in chunks. -- 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] SyncEvolution 1.4.99.4
On Fri, Oct 31, 2014 at 14:04:26 +0100, Patrick Ohly wrote: On Mon, 2014-10-27 at 15:32 +0100, Tino Mettler wrote: Hi Patrick, I just want to let you know that 1.4.99.4 is now in Debian unstable. I hope it will therefore become part of the next Debian stable release. That's good, thanks for your help. I noticed this week in an unrelated article about the systemd GR that there is a feature freeze deadline coming up for Debian early next week. Do you think it would be possible to get SyncEvolution 1.5 into that if I release it this weekend? The changes compared to 1.4.99.4 are minor, but some of the changes may be relevant for users. Just plain no, because the freeze affects Debian testing. Every package must be in testing at the time of the freeze. However, new packages are uploaded to Debian unstable, and unstable-to-testing migration was set to 10 days. Therefore, the deadline for new packages that should become a part of Jessie was last Sunday. That's why I submitted the first 1.4.99.2 package last Saturday, and another package with a small fix last Sunday. :-) So let's hope that no important bugs are found that would prevent the migration to testing for the 1.4.99.2 package. Otherwise, Jessie will be shipped with 1.4. Updates will only be allowed if they fix important bug, and only these bugs. As usual, New upstream versions won't be possible, fixes have to be backported. If you point me to critical bugs that affects users of the Debian package including a fix (or a git commit that contains the fix), I could try to provide updated packages. It would be cleaner to have a regular release in Debian, too. I know. It just didn't work out. Regards, Tino ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution 1.4.99.4
On Fri, 2014-10-31 at 14:35 +0100, Tino Mettler wrote: On Fri, Oct 31, 2014 at 14:04:26 +0100, Patrick Ohly wrote: On Mon, 2014-10-27 at 15:32 +0100, Tino Mettler wrote: Hi Patrick, I just want to let you know that 1.4.99.4 is now in Debian unstable. I hope it will therefore become part of the next Debian stable release. That's good, thanks for your help. I noticed this week in an unrelated article about the systemd GR that there is a feature freeze deadline coming up for Debian early next week. Do you think it would be possible to get SyncEvolution 1.5 into that if I release it this weekend? The changes compared to 1.4.99.4 are minor, but some of the changes may be relevant for users. Just plain no, because the freeze affects Debian testing. Every package must be in testing at the time of the freeze. However, new packages are uploaded to Debian unstable, and unstable-to-testing migration was set to 10 days. Therefore, the deadline for new packages that should become a part of Jessie was last Sunday. Right, I hadn't thought of that. Updates will only be allowed if they fix important bug, and only these bugs. As usual, New upstream versions won't be possible, fixes have to be backported. If you point me to critical bugs that affects users of the Debian package including a fix (or a git commit that contains the fix), I could try to provide updated packages. Relevant for users of Debian binaries is: commit 50148ab580f8912fa3cf5cd55c1e68050d43cf45 Author: Patrick Ohly patrick.o...@intel.com Date: Thu Sep 25 06:57:50 2014 + scripting: prevent premature loop timeouts The more complex avoid data loss during merging scripting ran for longer than 5s limit under extreme conditions (full logging, busy system, running under valgrind), which resulted in aborting the script and a 10500 local internal error sync failure. The endless loop prevention should only be necessary to detect programming mistakes, so better disable it entirely. It would be cleaner to have a regular release in Debian, too. I know. It just didn't work out. Never mind. 1.4.99.4 is close enough. I don't mind getting prodded a bit regarding releases. I'm not actively following downstream release cycles, so telling me about them occasionally would help to get upstream releases out in time. -- 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] SyncEvolution 1.4.99.4
On Fri, Oct 31, 2014 at 15:40:39 +0100, Patrick Ohly wrote: [...] Relevant for users of Debian binaries is: commit 50148ab580f8912fa3cf5cd55c1e68050d43cf45 Author: Patrick Ohly patrick.o...@intel.com Date: Thu Sep 25 06:57:50 2014 + scripting: prevent premature loop timeouts The more complex avoid data loss during merging scripting ran for longer than 5s limit under extreme conditions (full logging, busy system, running under valgrind), which resulted in aborting the script and a 10500 local internal error sync failure. The endless loop prevention should only be necessary to detect programming mistakes, so better disable it entirely. Hi Patrick, thanks for that. [...] I don't mind getting prodded a bit regarding releases. I'm not actively following downstream release cycles, so telling me about them occasionally would help to get upstream releases out in time. OK, I'll keep that in mind. However, saw a bit late that the deadline for updates in unstable is freeze date minus 10 days. During the last freezes, packages in unstable at the point of the freeze were allowed to migrate to testing after the freeze. And of cause, big thanks to David Bremner for uploading the packages I submitted as fast as possible. Regards, Tino ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution 1.4.99.4
Hi Patrick, I just want to let you know that 1.4.99.4 is now in Debian unstable. I hope it will therefore become part of the next Debian stable release. Regards, Tino ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
Re: [SyncEvolution] SyncEvolution 1.4.99.4
On Sat, 2014-10-18 at 14:32 +0100, Graham Cobb wrote: On 15/09/14 16:19, Patrick Ohly wrote: This is the first release candidate for 1.5. No further changes are planned except for fixing yet-to-be-discovered bugs - so find them now! :-) I am trying to update my various configs and check that everything works. The first problem isn't really a bug because I know the Debian packaging is not a supported feature. But when I tried to upgrade using apt-get install syncevolution-activesync, apt-get would have been happy to install the new syncevolution-activesync without upgrading syncevolution-activesync-saucy and syncevolution-bundle as well. Adding syncevolution-kde caused all four packages to be upgraded. I think the dependency of syncevolution-activesync on syncevolution-activesync-wheezy | syncevolution-activesync-saucy | syncevolution-activesync-trusty should be versioned to require the same version. I agree, this should be changed. Will do. I am also surprised that activesyncd-saucy hasn't been upgraded. Is that because it has not changed? Exactly. -- 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] SyncEvolution 1.4.99.4
On 15/09/14 16:19, Patrick Ohly wrote: This is the first release candidate for 1.5. No further changes are planned except for fixing yet-to-be-discovered bugs - so find them now! :-) I am trying to update my various configs and check that everything works. The first problem isn't really a bug because I know the Debian packaging is not a supported feature. But when I tried to upgrade using apt-get install syncevolution-activesync, apt-get would have been happy to install the new syncevolution-activesync without upgrading syncevolution-activesync-saucy and syncevolution-bundle as well. Adding syncevolution-kde caused all four packages to be upgraded. I think the dependency of syncevolution-activesync on syncevolution-activesync-wheezy | syncevolution-activesync-saucy | syncevolution-activesync-trusty should be versioned to require the same version. I am also surprised that activesyncd-saucy hasn't been upgraded. Is that because it has not changed? Graham ___ SyncEvolution mailing list SyncEvolution@syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution
[SyncEvolution] SyncEvolution 1.4.99.4
About 1.4.99.4 == This is the first release candidate for 1.5. No further changes are planned except for fixing yet-to-be-discovered bugs - so find them now! :-) One focus in this release was on minimizing CPU consumption and disk writes. The most common case, a two-way sync with no changes on either side, no longer rewrites any meta data files. CPU consumption during local sync was reduced to one third by exchanging messages via shared memory instead of internal D-Bus. Redundant vCard decode/encode on the sending side of PBAP and too agressive flushing of meta data during a normal sync were removed. Altogether, sending 1000 contacts with photo data in a refresh-from-server local sync takes only one sixth of the CPU cycles compared to 1.3.99.3 (measured with valgrind's callgrind on x86_64). Based on community feedback and discussions, the terminology used in SyncEvolution for configuration, local sync and database access was revised. Some usability issues with setting up access to databases were addressed. For Google, the obsolete SyncML config template was removed and CalDAV/CardDAV were merged into a single Google template. Using Google Calendar/Contacts with OAuth2 authentication on a headless server becomes a bit easier: it is possible to set up access on one system with a GUI using either gSSO or GNOME Online Accounts, then take the OAuth2 refresh token and use it in SyncEvolution on a different system. See http://cgit.freedesktop.org/SyncEvolution/syncevolution/tree/src/backends/oauth2/README Some issues accessing Apple iCloud were fixed such that CardDAV works by just giving SyncEvolution username=foo...@icloud.com and password. No throrough testing was done, so iCloud support is still experimental. The PIM Manager API also supports Google Contact syncing. Some problems with suspending a PBAP sync were fixed. Suspend/abort can be tested with the sync.py example. The EDS memo backend is able to switch between syncing in plain text and iCalendar 2.0 VJOURNAL automatically. Details: * oauth2: new backend using libsoup/libcurl New backend implements identity provider for obtaining OAuth2 access token for systems without HMI support. Access token is obtained by making direct HTTP request to OAuth2 server and using refresh token obtained by user in some other way. New provider automatically updates stored refresh token when OAuth2 server is issuing new one. * PBAP: use raw text items This avoids the redundant parse/generate step on the sending side of the PBAP sync. * datatypes: raw text items with minimal conversion (FDO #52791) When using raw/text/calendar or raw/text/vcard as SyncEvolution databaseFormat, all parsing and conversion is skipped. The backend's data is identical to the item data in the engine. Finding duplicates in a slow sync is very limited when using these types because the entire item data must match exactly. This is useful for the file backend when the goal is to store an exact copy of what a peer has or for limited, read-only backends (PBAP). The downside of using the raw types is that the peer is not given accurate information about which vCard or iCalendar properties are supported, which may cause some peers to not send all data. * engine: flush map items less frequently The Synthesis API does not say explicitly, but in practice all map items get updated in a tight loop. Rewriting the m_mappingNode (case insensitive string comparisons) and serialization to disk (std::ostrstream) consume a significant amount of CPU cycles and cause extra disk writes that can be avoided by making some assumptions about the sequence of API calls and flushing only once. * SoupTransport: drop CA file check It used to be necessary to specify a CA file for libsoup to enable SSL certificate checking. Nowadays libsoup uses the default CA store unless told otherwise, so the check in SyncEvolution became obsolete. However, now there is a certain risk that no SSL checking is done although the user asked for it (when libsoup is not recent enough or compiled correctly). * local sync: exchange SyncML messages via shared memory Encoding/decoding of the uint8_t array in D-Bus took a surprisingly large amount of CPU cycles relative to the rest of the SyncML message processing. Now the actual data resides in memory-mapped temporary files and the D-Bus messages only contain offset and size inside these files. Both sides use memory mapping to read and write directly. For caching 1000 contacts with photos on a fast laptop, total sync time roughly drops from 6s to 3s. To eliminate memory copies, memory handling in libsynthesis or rather, libsmltk is tweaked such that it allocates the buffer used for SyncML message data in the shared memory buffer directly. This relies on knowledge of libsmltk internals, but those shouldn't change and if they do, SyncEvolution will notice (unexpected send buffer). *
