From twilson at csufresno.edu Tue Dec 17 00:58:40 2013 From: twilson at csufresno.edu (Todd Wilson) Date: Tue, 17 Dec 2013 00:58:40 +0000 Subject: [SyncEvolution] Syncing two servers Message-ID: Hi, I've been looking at the syncevolution documentation online in an effort to determine whether it can be used to keep two remote servers (say, CalDAV and CalDAV, or CalDAV and ActiveSync) in sync, and I haven't been able find an answer. Can anyone help me with this? More specifically, I have calendars on two different servers (Zimbra and Google), both of which are accessible via CalDAV, and one of which (Zimbra) is accessible via ActiveSync. I would like to find a way to keep both of my calendars in sync, with minimal delay, and I'm wondering whether syncevolution might be part of the solution. For example, * Can I sync both remote sources to a single local database? * If not, can I sync them to two local databases, and then keep these local databases in sync, either through syncevolution or by different means? * Does syncevolution only sync through polling, or can it be configured to receive push information from servers? Thanks for any help you can provide! Todd Wilson _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Dec 17 07:41:19 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 17 Dec 2013 08:41:19 +0100 Subject: [SyncEvolution] Syncing two servers In-Reply-To: References: Message-ID: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> On Tue, 2013-12-17 at 00:58 +0000, Todd Wilson wrote: > Hi, I've been looking at the syncevolution documentation online in an effort > to determine whether it can be used to keep two remote servers (say, CalDAV > and CalDAV, or CalDAV and ActiveSync) in sync, and I haven't been able find > an answer. Can anyone help me with this? Sure. This list is a good start. > More specifically, I have calendars on two different servers (Zimbra and > Google), both of which are accessible via CalDAV, and one of which (Zimbra) > is accessible via ActiveSync. I would like to find a way to keep both of my > calendars in sync, with minimal delay, and I'm wondering whether > syncevolution might be part of the solution. SyncEvolution can do this, but it is not one of the common use cases, so you are chartering new territory. Beware, there might be dragons. What you need is the so called "local sync" - "local" because the sync logic and data transfer back and forth between both sides gets done on the machine on which SyncEvolution runs, by SyncEvolution. You can set it up in two ways: 1. Sync between the two servers directly. A single sync run will get them in sync. 2. Sync both servers against the same local database. You need to run syncs multiple times, alternating between the two servers, until no changes are transferred any more. I suggest you follow the second approach. Syncing may have to read and write data on one side of the sync (the one which is treated internally as the SyncML server side) more often, so having that on local storage will be faster. Start with the file backend for local storage. That will write one file per VEVENT, just as in the engine internally. EDS and Akonadi store it differently (one item per UID), which makes access more complicated in SyncEvolution. I assume that you are not already using SyncEvolution for something else. In that case you can use the "@default" context for your local databases and sync configs. # Choose directory for data files. datapath=$HOME/some-directory mkdir -p $datapath # Configure default "calendar" (named by convention). syncevolution --configure \ backend=file \ databaseFormat=text/calendar # Configure Zimbra, following the "CalDAV and CardDAV" section # in the README (aka "man syncevolution"). # Configure Google Calendar, using a similar approach but with *oAuth2*. For oAuth2 you will need SyncEvolution 1.3.99.6 and either GNOME Online Accounts >= 3.8 or Ubuntu Online Accounts with the Ubuntu patches (not in 1.3.99.6 yet) - see the 1.3.99.6 and 1.3.99.5 release announcement. It would be nice to document the specific steps for both GOA and UOA in a HOWTO in the SyncEvolution Wiki. This is very new and I haven't had the time to write up something. > For example, > > * Can I sync both remote sources to a single local database? Yes. > * Does syncevolution only sync through polling, or can it be configured to > receive push information from servers? It can only sync through polling. There's a feature request open for it, but no current plans to work on it: https://bugs.freedesktop.org/show_bug.cgi?id=52689 For CalDAV there's no standardized push mechanism. Apple uses something based on XMMP. I'm not sure about Google. The CalConnect group just announced an expert group which will standardize push. For ActiveSync there is something, based on keeping a TCP connection to the server open and having one pending command which the server replies to when there was a change. However, neither SyncEvolution nor activesyncd support that because there was no time to implement 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. From patrick.ohly at intel.com Tue Dec 17 07:42:06 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 17 Dec 2013 08:42:06 +0100 Subject: [SyncEvolution] Syncing two servers In-Reply-To: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> Message-ID: <1387266126.5855.101.camel@pohly-mobl1.fritz.box> On Tue, 2013-12-17 at 08:41 +0100, Patrick Ohly wrote: > # Choose directory for data files. > datapath=$HOME/some-directory > mkdir -p $datapath > > # Configure default "calendar" (named by convention). > syncevolution --configure \ > backend=file \ > databaseFormat=text/calendar Please add: database=file://$datapath -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From g+syncevolution at cobb.uk.net Tue Dec 17 10:33:46 2013 From: g+syncevolution at cobb.uk.net (g+syncevolution at cobb.uk.net) Date: Tue, 17 Dec 2013 10:33:46 +0000 Subject: [SyncEvolution] Syncing two servers In-Reply-To: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> Message-ID: <52B0288A.5050400@cobb.uk.net> On 17/12/13 07:41, Patrick Ohly wrote: > For ActiveSync there is something, based on keeping a TCP connection to > the server open and having one pending command which the server replies > to when there was a change. However, neither SyncEvolution nor > activesyncd support that because there was no time to implement it. If the work was done to support the ActiveSync mechanism, would SyncEvolution actually be able to do anything with it? Would the update have to trigger a complete new sync, or could the sync be done incrementally in some way? Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Dec 17 10:42:50 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 17 Dec 2013 11:42:50 +0100 Subject: [SyncEvolution] Syncing two servers In-Reply-To: <52B0288A.5050400@cobb.uk.net> References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> <52B0288A.5050400@cobb.uk.net> Message-ID: <1387276970.5855.105.camel@pohly-mobl1.fritz.box> On Tue, 2013-12-17 at 10:33 +0000, g+syncevolution at cobb.uk.net wrote: > On 17/12/13 07:41, Patrick Ohly wrote: > > For ActiveSync there is something, based on keeping a TCP connection to > > the server open and having one pending command which the server replies > > to when there was a change. However, neither SyncEvolution nor > > activesyncd support that because there was no time to implement it. > > If the work was done to support the ActiveSync mechanism, would > SyncEvolution actually be able to do anything with it? Would the update > have to trigger a complete new sync, or could the sync be done > incrementally in some way? SyncEvolution would start a new sync, but that new sync would be incremental, just as it is now when syncing at regular poll intervals. In the case of ActiveSync, that new sync could be done fairly efficiently, because the connection to the server would still be open. However, that's something to be dealt with inside activesyncd. SyncEvolution wouldn't be aware of it at all. It just needs to know that server data has changed. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From twilson at csufresno.edu Wed Dec 18 09:16:29 2013 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 18 Dec 2013 01:16:29 -0800 Subject: [SyncEvolution] Syncing two servers In-Reply-To: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> Message-ID: Thanks, Patrick, this looks very promising! A couple of questions below: On Mon, Dec 16, 2013 at 11:41 PM, Patrick Ohly wrote: > You can set it up in two ways: > 1. Sync between the two servers directly. A single sync run will > get them in sync. > 2. Sync both servers against the same local database. You need to > run syncs multiple times, alternating between the two servers, > until no changes are transferred any more. > I suggest you follow the second approach. I wonder, would your recommendation change if the syncing between my two servers were only one-way -- that is to say, if I only make changes in one calendar but want them to be reflected in both? For oAuth2 you will need SyncEvolution 1.3.99.6 and either GNOME Online > Accounts >= 3.8 or Ubuntu Online Accounts with the Ubuntu patches (not > in 1.3.99.6 yet) - see the 1.3.99.6 and 1.3.99.5 release announcement. > How would you suggest installing 1.3.99.6 on my Ubuntu 13.10 system? The Ubuntu packages are old (1.2.99.4), Evolution is behind (3.8.4), the installation documentation only refers to much earlier distributions, and when I try installing from the unstable repository as suggested in the release notes for 1.3.99.6, I get missing dependencies (activesyncd, libebook, libecal) and am not able to find any hints about the proper way to resolve these. > * Does syncevolution only sync through polling, or can it be configured to > > receive push information from servers? > > It can only sync through polling. There's a feature request open for it, > but no current plans to work on it: > https://bugs.freedesktop.org/show_bug.cgi?id=52689 > > For CalDAV [...] > > For ActiveSync [...] Thanks for the information. I'm looking forward to giving SyncEvolution a try! --Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Wed Dec 18 10:11:56 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 18 Dec 2013 11:11:56 +0100 Subject: [SyncEvolution] Syncing two servers In-Reply-To: References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> Message-ID: <1387361516.5855.139.camel@pohly-mobl1.fritz.box> On Wed, 2013-12-18 at 01:16 -0800, Todd Wilson wrote: > Thanks, Patrick, this looks very promising! A couple of questions > below: > > > On Mon, Dec 16, 2013 at 11:41 PM, Patrick > Ohly wrote: > > You can set it up in two ways: > 1. Sync between the two servers directly. A single sync > run will > get them in sync. > 2. Sync both servers against the same local database. You > need to > run syncs multiple times, alternating between the two > servers, > until no changes are transferred any more. > I suggest you follow the second approach. > > > I wonder, would your recommendation change if the syncing between my > two servers were only one-way -- that is to say, if I only make > changes in one calendar but want them to be reflected in both? In that case the situation is indeed a bit more favorable for directly syncing between the servers, albeit there's still one caveat specific to calendars: internally, individual VEVENTs get synced. In ActiveSync and CalDAV, an item can consist of multiple VEVENTs, so both backends go through considerable effort to split and merge into/from individual VEVENTs. This will cause additional network traffic. I've toyed with the idea of changing the syncing such that it works with a set of related VEVENTs as a single item, but then we end up with the problem of translating between one side which uses individual VEVENTs (SyncML) and another side with uses a set (CalDAV, ActiveSync). It's complicated :-/ > For oAuth2 you will need SyncEvolution 1.3.99.6 and either > GNOME Online > Accounts >= 3.8 or Ubuntu Online Accounts with the Ubuntu > patches (not > in 1.3.99.6 yet) - see the 1.3.99.6 and 1.3.99.5 release > announcement. > > > How would you suggest installing 1.3.99.6 on my Ubuntu 13.10 system? > > The Ubuntu packages are old (1.2.99.4), Evolution is behind (3.8.4), > the installation documentation only refers to much earlier > distributions, and when I try installing from the unstable repository > as suggested in the release notes for 1.3.99.6, I get missing > dependencies (activesyncd, libebook, libecal) and am not able to find > any hints about the proper way to resolve these. The SyncEvolution 1.3.99.6 binaries should work. Can you install "syncevolution-evolution"? activesyncd won't work. It was compiled for a specific version of EDS, 3.4, and is only compatible with that. 3.6 and 3.8 changed the API too much. It might not even compile when using EDS > 3.4. I haven't checked that, though. As always, patches welcome. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Wed Dec 18 10:37:53 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 18 Dec 2013 11:37:53 +0100 Subject: [SyncEvolution] Syncing two servers In-Reply-To: <1387361516.5855.139.camel@pohly-mobl1.fritz.box> References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> <1387361516.5855.139.camel@pohly-mobl1.fritz.box> Message-ID: <1387363073.5855.142.camel@pohly-mobl1.fritz.box> On Wed, 2013-12-18 at 11:11 +0100, Patrick Ohly wrote: > activesyncd won't work. It was compiled for a specific version of EDS, > 3.4, and is only compatible with that. 3.6 and 3.8 changed the API too > much. > > It might not even compile when using EDS > 3.4. I haven't checked that, > though. As always, patches welcome. Actually, I am compiling activesyncd with EDS 3.8 on Debian Testing as part of the nightly testing. I just don't package and publish the resulting binaries, because providing binaries is enough work already as it is. Maintaining per-distro orr per-EDS-version repos and educating users which one to use would be even more work. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From twilson at csufresno.edu Wed Dec 18 16:49:02 2013 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 18 Dec 2013 08:49:02 -0800 Subject: [SyncEvolution] Syncing two servers In-Reply-To: <1387361516.5855.139.camel@pohly-mobl1.fritz.box> References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> <1387361516.5855.139.camel@pohly-mobl1.fritz.box> Message-ID: On Wed, Dec 18, 2013 at 2:12 AM, Patrick Ohly wrote: > > How would you suggest installing 1.3.99.6 on my Ubuntu 13.10 system? > > > > The Ubuntu packages are old (1.2.99.4), Evolution is behind (3.8.4), > > the installation documentation only refers to much earlier > > distributions, and when I try installing from the unstable repository > > as suggested in the release notes for 1.3.99.6, I get missing > > dependencies (activesyncd, libebook, libecal) and am not able to find > > any hints about the proper way to resolve these. > > The SyncEvolution 1.3.99.6 binaries should work. Can you install > "syncevolution-evolution"? > That's what I tried: # *tail -n1 /etc/apt/sources.list* deb http://downloads.syncevolution.org/apt unstable main # *apt-cache policy syncevolution-evolution | grep Candidate* Candidate: 1:1.3.99.6-1 # *apt-get install syncevolution-evolution* Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help resolve the situation: The following packages have unmet dependencies. syncevolution-evolution : Depends: libebook1.2-5 but it is not installable or libebook1.2-6 but it is not installable or libebook1.2-7 but it is not installable or libebook1.2-8 but it is not installable or libebook1.2-9 but it is not installable or libebook1.2-10 but it is not installable or libebook1.2-11 but it is not installable or libebook-1.2-11 but it is not installable or libebook-1.2-12 but it is not installable or libebook-1.2-13 but it is not installable Depends: libecal1.2-3 but it is not installable or libecal1.2-4 but it is not installable or libecal1.2-5 but it is not installable or libecal1.2-6 but it is not installable or libecal1.2-7 but it is not installable or libecal1.2-8 but it is not installable or libecal1.2-9 but it is not installable or libecal1.2-10 or libecal-1.2-10 but it is not installable or libecal-1.2-11 but it is not installable E: Unable to correct problems, you have held broken packages. --Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Wed Dec 18 18:13:47 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 18 Dec 2013 19:13:47 +0100 Subject: [SyncEvolution] Syncing two servers In-Reply-To: References: <1387266079.5855.100.camel@pohly-mobl1.fritz.box> <1387361516.5855.139.camel@pohly-mobl1.fritz.box> Message-ID: <1387390427.5855.157.camel@pohly-mobl1.fritz.box> On Wed, 2013-12-18 at 08:49 -0800, Todd Wilson wrote: > On Wed, Dec 18, 2013 at 2:12 AM, Patrick Ohly > wrote: > > How would you suggest installing 1.3.99.6 on my Ubuntu 13.10 > system? > > > > > The Ubuntu packages are old (1.2.99.4), Evolution is > behind (3.8.4), > > the installation documentation only refers to much earlier > > distributions, and when I try installing from the unstable > repository > > as suggested in the release notes for 1.3.99.6, I get > missing > > dependencies (activesyncd, libebook, libecal) and am not > able to find > > any hints about the proper way to resolve these. > > > The SyncEvolution 1.3.99.6 binaries should work. Can you > install > "syncevolution-evolution"? > > > That's what I tried: > > > # tail -n1 /etc/apt/sources.list > deb http://downloads.syncevolution.org/apt unstable main > # apt-cache policy syncevolution-evolution | grep Candidate > Candidate: 1:1.3.99.6-1 > # apt-get install syncevolution-evolution > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help resolve the situation: > > > The following packages have unmet dependencies. > syncevolution-evolution : Depends: libebook1.2-5 but it is not > installable or > libebook1.2-6 but it is not > installable or > libebook1.2-7 but it is not > installable or > libebook1.2-8 but it is not > installable or > libebook1.2-9 but it is not > installable or > libebook1.2-10 but it is not > installable or > libebook1.2-11 but it is not > installable or > libebook-1.2-11 but it is not > installable or > libebook-1.2-12 but it is not > installable or > libebook-1.2-13 but it is not > installable I see. The package dependencies aren't defined correctly in the package, libebook-1.2-14 is also acceptable but not listed. FWIW, I already revised the automated testing the last view days. It now includes real install tests of these packages. I'm not with it yet, so I haven't actually seen the results for Saucy (= 13.10), but I expect I'll see the same failure as you did. Anyway, you can install with "aptitude install syncevolution-bundle". That installs the same package, without enforcing dependencies on Evolution. The resulting binaries will then work with EDS 3.8 (that's something that I had tested when releasing 1.3.99.6). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From chingupt at gmail.com Tue Dec 31 11:15:42 2013 From: chingupt at gmail.com (Sachin Gupta) Date: Tue, 31 Dec 2013 16:45:42 +0530 Subject: [SyncEvolution] Backend as Mysql Message-ID: Hi All, Is there support for MySQL as backend? i see that sqllite is supported, but it seems to be used only for contacts, but not for cal and todo. Which one is suitable for Contacts, Calendar, Tasks together? I need to be able to access this backend do some manipulation at runtime before syncing with the server. Regards Sachin _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Tue Dec 10 08:22:33 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 10 Dec 2013 09:22:33 +0100 Subject: SyncEvolution 1.3.99.6 released In-Reply-To: <1347469739.8868.100.camel@pohly-mobl1.fritz.box> References: <1347469739.8868.100.camel@pohly-mobl1.fritz.box> Message-ID: <1386663753.5903.182.camel@pohly-mobl1.fritz.box> Hello! This update focuses on SyncEvolution in IVI again. It adds support for GENIVI Diagnostic Log and Trace (DLT) and enhances searching in the unified address book. The biggest change for normal Linux desktop users is enhanced support for recent distros. Binaries on syncevolution.org now work with EDS >= 3.6 *and* < 3.6. Distros with libical1 like Ubuntu Saucy are also supported. Automated testing was updated to cover these newer platforms more thoroughly. The binaries support Google CalDAV in combination with GNOME Online Accounts (GOA) >= 3.8 and and Google CardDAV with GOA >= 3.10. To use CardDAV with GOA 3.8, one has to patch or recompile GOA [1]. Support for Google CalDAV/CardDAV with Ubuntu Online Accounts requires recompilation of SyncEvolution with one additional patch [2]. [1] http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/src/backends/goa/README [2] https://bugs.freedesktop.org/show_bug.cgi?id=72263 Details: * GNOME Online Accounts: fix D-Bus problem in syncevolution.org binaries Support was included in syncevolution.org binaries, but was not tested and did not actually work due to some issue accessing the D-Bus session. * libsynthesis: partial fix batching of items The batching of contact writes introduced with SyncEvolution 1.3.99.4 caused problems with non-SyncEvolution SyncML peers when syncing contacts stored in EDS >= 3.6. EDS < 3.6 was not affected. That part is fixed. However, even in SyncEvolution<->SyncEvolution syncs another crash was found. This will require more investigation. Clearly the feature is not ready yet for general sync, so for now it is disabled by default and only enabled in the simpler PBAP sync. * libsynthesis: avoid redundant (and sometimes slow) getaddrbyname() (FDO #70771) The network lookup of the hostname can be slow (10 second delay when not connected) and shouldn't be necessary anyway, so disable it. * PIM: accent-insensitive and transliterated search (FDO #56524) Accent-insensitive search ignores accents, using the same code as in EDS. Transliterated search ignores foreign scripts by transliterating search term and contact properties to Latin first. That one is using ICU directly in the same way as EDS, but doesn't use the EDS ETransliterator class to avoid extra string copying. This commit changes the default behavior such that searching is by default most permissive (case- and accent-insensitive, does transliteration). Flags exist to restore more restrictive matching. * PIM: relax phone number matching Previously, the current default country was used to turn phone numbers without an explicit country code into full E164 numbers, which then had to match the search term when doing a caller ID lookup. This was inconsistent with EDS, where a weaker EQUALS_NATIONAL_PHONE_NUMBER was done. The difference is that a comparison between a number with country code matches one without if the national number of the same, regardless of the current default country. This is better because it reduces the influence of the hard to guess default country on matching. Another advantage of this change is the lower memory consumption and faster comparison, because strings are now stored in 4 + 8 byte numbers instead of strings of varying length. * PIM: fix incorrect write into pim-manager.ini (FDO #70772) Removing a peer accidentally wrote the updated list of active address books into the "sort" property of pim-manager.ini, which then prevented starting the PIM Manager. * PIM: ignore broken sort order in config (FDO #70772) Failure to set the sort order from pim-manager.ini should not prevent the startup of the PIM Manager because the client cannot really diagnose and fix the problem. It is better to try again with the default sort order. * PIM: adapt to locale changes at runtime (FDO #66618) Listen to signals from localed D-Bus system service and update all internal state which depends on the current locale. This state includes: - pre-computed data in all loaded contacts - filtering (for example, case sensitivity is locale dependent) - the sort order This feature can be controlled by setting the SYNCEVOLUTION_LOCALED env variable: - "session" - use a localed instance on the D-Bus session bus instead of the system instance. This was originally meant for testing, but might also be useful for per-user setting changes. - "none" - disables the feature * PIM: fix sync.py + multiple peers Due to overwriting a variable, configuring multiple different peers did not work. * D-Bus server: support DLT (FDO #66769) Diagnostic Log and Trace (DLT) manages a sequence of log messages, with remote controllable level of detail. SyncEvolution optionally (can be chosen at compile time and again at runtime) uses DLT instead of its own syncevolution-log.html files. See README-DLT.rst for more information. To use the feature, configure SyncEvolution with "--enable-dbus-server=--dlt --no-syslog" * EDS: enhanced compatibility mode SyncEvolution compiled for EDS < 3.6 can now also load EDS backends compiled for EDS >= 3.6. The packaging for syncevolution.org uses that to bundle EDS backends compiled on different distros in the same package. * EDS: SYNCEVOLUTION_EBOOK_QUERY env variable Setting the SYNCEVOLUTION_EBOOK_QUERY env variable to a valid EBook query string limits the results to contacts matching that query. Useful only in combination with --print-items or --export. Only implemented for EDS >= 3.6. * EDS: fix compile problem with boost and EDS > 3.36 This fixes the following problem, seen with Boost 1.53.0 on altlinux when compiling for EDS >= 3.6: /usr/include/boost/smart_ptr/shared_ptr.hpp: In instantiation of 'typename boost::detail::sp_array_access::type boost::shared_ptr::operator[](std::ptrdiff_t) const [with T = char*; typename boost::detail::sp_array_access::type = void; std::ptrdiff_t = long int]': src/backends/evolution/EvolutionSyncSource.cpp:163:38: required from here /usr/include/boost/smart_ptr/shared_ptr.hpp:663:22: error: return-statement with a value, in function returning 'void' [-fpermissive] make[2]: *** [src/backends/evolution/src_backends_evolution_syncecal_la-EvolutionSyncSource.lo] * PBAP: add support for obexd 0.48 obexd 0.48 is almost the same as obexd 0.47, except that it dropped the SetFilter and SetFormat methods in favor of passing a Bluex 5-style filter parameter to PullAll. SyncEvolution now supports 4, in words, four different obexd APIs. Sigh. This feature was originally announced for SyncEvolution 1.3.99.5, but not actually included in the code yet. Upgrading from releases <= 1.3.99.4: If the value of "username/databaseUser/proxyUser" contains a colon, the "user:" prefix must be added to the value, to continue treating it like a plain user name and not some reference to an unknown identity provider (like "id:", "goa:", "signon:", etc.). The lookup of passwords in GNOME Keyring was updated slightly in 1.3.99.5. It may be necessary to set passwords anew if the old one is no longer found. Upgrading from release 1.2.x: The sync format of existing configurations for Mobical (aka Everdroid) must be updated manually, because the server has encoding problems when using vCard 3.0 (now the default for Evolution contacts): syncevolution --configure \ syncFormat=text/x-vcard \ mobical addressbook The Funambol template explicitly enables usage of the "refresh-from-server" sync mode to avoid getting throttled with 417 'retry later' errors. The same must be added to existing configs manually: syncevolution --configure \ enableRefreshSync=TRUE \ funambol Upgrading from releases before 1.2: Old configurations can still be read. But writing, as it happens during a sync, must migrate the configuration first. Releases >= 1.2 automatically migrates configurations. The old configurations will still be available (see "syncevolution --print-configs") but must be renamed manually to use them again under their original names with older SyncEvolution releases. Source, Installation, Further information ========================================= http://syncevolution.org/blogs/pohly/2013/syncevolution-13996-released Source code bundles for users are available in http://downloads.syncevolution.org/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 are available via the "unstable" syncevolution.org repository. Add the following entry to your /apt/source.list: deb http://downloads.syncevolution.org/apt stable main Then install "syncevolution-evolution", "syncevolution-kde" and/or "syncevolution-activesync". These binaries include the "sync-ui" GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy), except for "syncevolution-activesync" which depends on libraries in Debian Squeeze, for example EDS 3.4. Older distributions like Debian 4.0 (Etch) can no longer be supported with precompiled binaries because of missing libraries, but the source still compiles when not enabling the GUI (the default). The same binaries are also available as .tar.gz and .rpm archives in http://downloads.syncevolution.org/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. After installation, follow the http://syncevolution.org/documentation/getting-started steps. -- Patrick Ohly, on behalf of everyone who has helped to make SyncEvolution possible: http://syncevolution.org/about/contributors From patrick.ohly at intel.com Fri Dec 13 10:48:19 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 13 Dec 2013 11:48:19 +0100 Subject: SyncEvolution 1.3.99.6 released In-Reply-To: <1386663753.5903.182.camel@pohly-mobl1.fritz.box> References: <1347469739.8868.100.camel@pohly-mobl1.fritz.box> <1386663753.5903.182.camel@pohly-mobl1.fritz.box> Message-ID: <1386931699.5903.227.camel@pohly-mobl1.fritz.box> On Tue, 2013-12-10 at 09:22 +0100, Patrick Ohly wrote: > The binaries support Google CalDAV in combination with GNOME Online > Accounts (GOA) >= 3.8 and and Google CardDAV with GOA >= 3.10. To use > CardDAV with GOA 3.8, one has to patch or recompile GOA [1]. I just noticed that Debian has already picked up that patch; it's in the current Debian Testing. From tino.keitel+syncevolution at tikei.de Fri Dec 13 11:25:47 2013 From: tino.keitel+syncevolution at tikei.de (tino.keitel+syncevolution at tikei.de) Date: Fri, 13 Dec 2013 12:25:47 +0100 Subject: [SyncEvolution] SyncEvolution 1.3.99.6 released In-Reply-To: <1386663753.5903.182.camel@pohly-mobl1.fritz.box> References: <1386663753.5903.182.camel@pohly-mobl1.fritz.box> Message-ID: <20131213112547.GA15813@mac.home> Hi Patrick, I totally missed the 1.3.99.6 release because the mail was a reply to an old announcement and was sorted into an old mail thread. I guess it's a better idea to not reply to an old mail when sending out an announcement. I also regulary checked https://syncevolution.org/blogs where all the other 1.3.99.x versions were mentioned, but 1.3.99.6 is missing there, too. Regarding libsynthesis, the libsynthesis_3.4.0.47+syncevolution-1-3-99-6 git tag is missing commit 572bba1742c290607755e6ec2e95c5e0733466f4 which bumbs the libsynthesis version to 3.4.0.47.1, but syncevolution 1.3.99.6 requires 3.4.0.47.1. Sorry for complaining so much. :-) Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Dec 13 16:54:47 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 13 Dec 2013 17:54:47 +0100 Subject: [SyncEvolution] SyncEvolution 1.3.99.6 released In-Reply-To: <20131213112547.GA15813@mac.home> References: <1386663753.5903.182.camel@pohly-mobl1.fritz.box> <20131213112547.GA15813@mac.home> Message-ID: <1386953687.5903.234.camel@pohly-mobl1.fritz.box> On Fri, 2013-12-13 at 12:25 +0100, tino.keitel+syncevolution at tikei.de wrote: > I totally missed the 1.3.99.6 release because the mail was a reply to > an old announcement and was sorted into an old mail thread. I use Evolution's "edit as new message" to clone the previous announcement, which usually starts a new mail thread. However, the previous announcement also already had an "in-reply-to" header, so at some point in the past I must have made the mistake of using reply-to. The next announcement will be a truly virgin email where I just cut-and-paste text, I swear ;-/ > I also regulary checked https://syncevolution.org/blogs > where all the other 1.3.99.x versions were mentioned, but 1.3.99.6 is > missing there, too. Good point, I forgot to publish that. In my release checklist it's a separate point from writing the post, but this time I wasn't quite following that list (lot of last minute changes, etc.) and forgot about that point. > Regarding libsynthesis, the > libsynthesis_3.4.0.47+syncevolution-1-3-99-6 git tag is missing commit > 572bba1742c290607755e6ec2e95c5e0733466f4 which bumbs the libsynthesis > version to 3.4.0.47.1, but syncevolution 1.3.99.6 requires 3.4.0.47.1. The libsynthesis_3.4.0.47+syncevolution-1-3-99-6 git tag has the commit (http://cgit.freedesktop.org/SyncEvolution/libsynthesis/commit/?id=572bba1742c290607755e6ec2e95c5e0733466f4), the release wouldn't have compiled otherwise. It's just master that hadn't been updated to that tag yet. Fixed. > Sorry for complaining so much. :-) Not at all, thanks for pointing this out. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From tino.keitel+syncevolution at tikei.de Fri Dec 13 20:10:16 2013 From: tino.keitel+syncevolution at tikei.de (tino.keitel+syncevolution at tikei.de) Date: Fri, 13 Dec 2013 21:10:16 +0100 Subject: [SyncEvolution] SyncEvolution 1.3.99.6 released In-Reply-To: <1386953687.5903.234.camel@pohly-mobl1.fritz.box> References: <1386663753.5903.182.camel@pohly-mobl1.fritz.box> <20131213112547.GA15813@mac.home> <1386953687.5903.234.camel@pohly-mobl1.fritz.box> Message-ID: <20131213201016.GA18546@mac.home> On Fri, Dec 13, 2013 at 17:54:47 +0100, Patrick Ohly wrote: > The libsynthesis_3.4.0.47+syncevolution-1-3-99-6 git tag has the commit > (http://cgit.freedesktop.org/SyncEvolution/libsynthesis/commit/?id=572bba1742c290607755e6ec2e95c5e0733466f4), the release wouldn't have compiled otherwise. It's just master that hadn't been updated to that tag yet. Fixed. It looks like git fetch only fetches new tags, and does not update changed tags. git fetch --tags brought the updated tag here. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Fri Dec 13 21:30:13 2013 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 13 Dec 2013 22:30:13 +0100 Subject: [SyncEvolution] SyncEvolution 1.3.99.6 released In-Reply-To: <20131213201016.GA18546@mac.home> References: <1386663753.5903.182.camel@pohly-mobl1.fritz.box> <20131213112547.GA15813@mac.home> <1386953687.5903.234.camel@pohly-mobl1.fritz.box> <20131213201016.GA18546@mac.home> Message-ID: <1386970213.5855.23.camel@pohly-mobl1.fritz.box> On Fri, 2013-12-13 at 21:10 +0100, tino.keitel+syncevolution at tikei.de wrote: > On Fri, Dec 13, 2013 at 17:54:47 +0100, Patrick Ohly wrote: > > > The libsynthesis_3.4.0.47+syncevolution-1-3-99-6 git tag has the commit > > (http://cgit.freedesktop.org/SyncEvolution/libsynthesis/commit/?id=572bba1742c290607755e6ec2e95c5e0733466f4), the release wouldn't have compiled otherwise. It's just master that hadn't been updated to that tag yet. Fixed. > > It looks like git fetch only fetches new tags, and does not update > changed tags. git fetch --tags brought the updated tag here. Correct. I am occasionally setting tags anew when a release candidate turns out to require further changes. The alternative would be to assign new versions to each release candidate, but that could lead to an inflation of version numbers. I'd prefer to stick with the current approach, even though it can be confusing occasionally. Perhaps annotated tags avoid this problem - I need to check that. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From tino.keitel+syncevolution at tikei.de Mon Dec 16 08:24:44 2013 From: tino.keitel+syncevolution at tikei.de (tino.keitel+syncevolution at tikei.de) Date: Mon, 16 Dec 2013 09:24:44 +0100 Subject: [SyncEvolution] SyncEvolution 1.3.99.6 released In-Reply-To: <1386970213.5855.23.camel@pohly-mobl1.fritz.box> References: <1386663753.5903.182.camel@pohly-mobl1.fritz.box> <20131213112547.GA15813@mac.home> <1386953687.5903.234.camel@pohly-mobl1.fritz.box> <20131213201016.GA18546@mac.home> <1386970213.5855.23.camel@pohly-mobl1.fritz.box> Message-ID: <20131216081305.GA27664@mac.home> On Fri, Dec 13, 2013 at 22:30:13 +0100, Patrick Ohly wrote: [...] > Correct. I am occasionally setting tags anew when a release candidate > turns out to require further changes. The alternative would be to assign > new versions to each release candidate, but that could lead to an > inflation of version numbers. I'd prefer to stick with the current > approach, even though it can be confusing occasionally. > > Perhaps annotated tags avoid this problem - I need to check that. Hi, as often, it's just a matter of proper adjustment of the git configuration. In this case, "git config --local --add remote..fetch +refs/tags/*:refs/tags/*" did the trick. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From g+syncevolution at cobb.uk.net Mon Dec 9 19:57:21 2013 From: g+syncevolution at cobb.uk.net (Graham Cobb) Date: Mon, 9 Dec 2013 19:57:21 +0000 Subject: [SyncEvolution] Ubuntu Saucy + libical0 vs. libical1 + KDE In-Reply-To: <1384080653.32243.86.camel@pohly-mobl1.fritz.box> References: <1384080653.32243.86.camel@pohly-mobl1.fritz.box> Message-ID: <52A620A1.80707@cobb.uk.net> On 10/11/13 10:50, Patrick Ohly wrote: > Ubuntu essentially just copies the packaging done by Tino Keitel, who > recently said that he is willing to enable KDE support if he can get > help testing that. See > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682520 I am happy to help test in a Debian Jessie environment, if that helps. I use KDE with kontact for PIM, and do not use Evolution. If this is built from Patrick's latest versions, I could even test with ActiveSync -- particularly if you felt like packaging activesyncd as well :-) Unfortunately, I cannot help with Ubuntu. Graham _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Tue Dec 10 10:07:27 2013 From: tino.keitel+syncevolution at tikei.de (tino.keitel+syncevolution at tikei.de) Date: Tue, 10 Dec 2013 11:07:27 +0100 Subject: [SyncEvolution] Ubuntu Saucy + libical0 vs. libical1 + KDE In-Reply-To: <52A620A1.80707@cobb.uk.net> References: <1384080653.32243.86.camel@pohly-mobl1.fritz.box> <52A620A1.80707@cobb.uk.net> Message-ID: <20131210100727.GA22476@mac.home> On Mon, Dec 09, 2013 at 19:57:21 +0000, Graham Cobb wrote: > On 10/11/13 10:50, Patrick Ohly wrote: > > Ubuntu essentially just copies the packaging done by Tino Keitel, who > > recently said that he is willing to enable KDE support if he can get > > help testing that. See > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682520 > > I am happy to help test in a Debian Jessie environment, if that helps. > I use KDE with kontact for PIM, and do not use Evolution. Hi, Debian still has libical0. > If this is built from Patrick's latest versions, I could even test with > ActiveSync -- particularly if you felt like packaging activesyncd as > well :-) I already prepared 1.3.99.6 packages and will provide them once 1.3.99.6 was released. Activesyncd seems to be part of evolution-activesync, which is not in Debian[1]. Regards, Tino [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699713 _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution