February 2010 - syncevolution@synevolution.org

[SyncEvolution] How to select the evolution target calendar

by Matthias Urlichs

Hello, I have one small problem: I cannot select which local Evolution calendar SyncEvolution actually talks to. Apparently it uses the first entry in the /apps/evolution/calendar/sources gconf entry that it can find. Since the order of these entries isn't changeable and I need to separate "work" from "home" calendar entries (with separate mobiles to sync to …), I'd like some way to change that. Either this is not possible yet, or I'm blind and didn't find it in the documentation …? Otherwise, thanks for the excellent tool; it works with our Oracle calendar like a charm (using the values in the Oracle branch). -- Matthias

10 years

4
7
0 / 0

[SyncEvolution] SyncEvolution 1.0 beta 2 released

by Patrick Ohly

SyncEvolution 1.0 beta 2 is available. Binary packages are provided, including Bluetooth support this time. Major improvements: * easier setup of a phone with the sync-ui and GNOME Bluetooth plugin * prevention of slow sync enabled by default and integrated into sync-ui * recovery dialog and restore from backup in sync-ui * database dumps and comparisons more efficient Despite some open issues (see below), this release is ready for getting packaged in staging areas of distros as replacement for 0.9.2 and for day-to-day use. If you find issues, please report them: http://syncevolution.org/support SyncEvolution synchronizes personal information management (PIM) data like contacts, calenders, tasks, and memos using the SyncML information synchronization standard. Up to and including 0.9.x, a third-party SyncML server is required. In the 1.0 beta, SyncEvolution itself is already able to act as a SyncML server, both via HTTP and Bluetooth (direct sync with phones). As before, documentation for 1.0 is only available in the "Development" section of syncevolution.org, including HOWTOs for setting up the HTTP SyncML server and phones manually. Details ======= Setting up a phone became a bit easier with beta 2, because SyncEvolution is now integrated with the GNOME Bluetooth panel: once a device with SyncML client support is paired, a button offers to bring up the sync-UI and configure or synchronize with that device. We do a fuzzy match against the Bluetooth device name to find a suitable template (not manufacturer/model, because that is not readily available). Still not many (read: hardly any) templates available, though. The binaries on syncevolution.org are compiled with Bluetooth support. libbluetooth2 or libbluetooth3 should be installed, but are not essential. If there is no suitable version of it, the Bluetooth channel has to be selected manually as part of the syncURL. Unexpected slow syncs are prevented by default, in contrast to beta 1 where this feature was available but turned off. When an unexpected slow sync is detected in a client, users have to follow the instructions provided by the command line or sync-ui and choose how to proceed (explicitly request slow sync, refresh from server or client, restore from backup). SyncEvolution as server currently cannot prevent slow syncs, even when initiating the sync with a phone. In preparation for syncing automatically, logdir and database handling was improved considerably. Backups use less disk space because identical files share the same file content via hard links. This also speeds up the synccompare Perl script. Database dumps and the corresponding comparison are delayed until the session really runs, which avoids doing needless work a) when the server a client tries to contact is unreachable or down and b) by only including sources that are really in use during a sync on the server side. The Synthesis XML configuration was split up into different parts which are assembled from /usr/share/syncevolution/xml. Files in ~/.config/syncevolution-xml override and extend the default files, which my be useful when adding support for a new phone. Summary of changes since 1.0 beta 1: * sync-ui: recovery dialog (MB #8050), device setup, config usable with long strings (MB #9278), fixed displaying of source phases during sync (MB #9320) * sync-ui + syncevo-dbus-server: integration with Bluez to detect paired devices (MB #9216, MB #7089), select template based on device name (MB #7838), detect network and Bluetooth connectivity (only with ConnMan, MB #7700), passwords stored in GNOME keyring by syncevo-dbus-server are shown with dots in sync-ui (MB #9169) * Evolution addressbook backend: avoid picking CouchDB, second try (MB #7877) * Evolution calendar backend: minor fix for change tracking when deleting a single instance of a recurring event * build fixes: Bluetooth compatibility (MB #9289), use libical _r variant of calls because 0.43 has issues in the normal version, conflict with system libsynthesis and libsmltk (MB #9811) * Horde: avoid confusing the server with a deviceId that starts like the ones used in old Funambol clients, helps with calendar sync (MB #9347) * better reporting when SyncEvolution dies during a sync (only happend once when it wasn't installed properly, but still... MB #9844) * performance improvements: synccompare much faster/database dumps consume less disk space/more intelligent about expiring obsolete session directories and backups/database accesses are reduced in several backends (MB #7708), shorter logs (MB #8092) * slow sync detection: now also works in the case where the client detects an anchor mismatch and enabled by default (MB #2416) * OBEX transport: some error handling changes and removal of polling, now also possible via sync-ui + syncevo-dbus-server (MB #9436) * API changes: SyncSource introduces an "isEmpty" operation which is needed for the slow sync detection * SyncML: split up configuration (MB #7712), increased default message size because the old one might have been too small for large DevInf structures * several fixes for virtual data sources ("calendar+todo"): now works on client side, fixed naming on server (MB #9664), fixed error message for slow sync detection, supported in combination with sync-UI (MB #9535) * fixes for shared configuration layout: finding sessions of peers in non-default context, adding sources affected peers in the same context (MB #9329), wrong context during --configure when using shortcut for peers in non-default context (MB #9338) Known gaps for 1.0 final and beyond: Redesigned and reimplemented D-Bus API, required by sync-UI: - 'syncevolution' command line tool bypasses D-Bus server and runs sync sessions itself (MB #5043) - availability of peers not detected when using NetworkManager (connected for HTTP, paired for Bluetooth; MB #7700) SyncML server in general: - suspend/resume support is untested (MB #2425) - the progress events and statistics reported for a SyncML client are not generated when running as SyncML server, will require a fair amount of refactoring in the Synthesis engine (MB #7709) HTTP SyncML server: - a configuration must be created for each peer manually, including a remoteDeviceId value that contains the peer's SyncML device ID (MB #7838) OBEX SyncML server ("sync with phones"): - does not support phones which require a SAN 1.0 message (MB #9312) - determining a working configuration for an unknown phone requires a bit of experimenting, which should be automated (MB #9862) OBEX SyncML client: - parsing of SAN message is rudimentary and depends on an existing local configuration, needs to be refined depending on which SyncML server software it is meant to work with (MB #6175) Automatic sync (MB #6378): - no support for the various server push notification mechanisms - no intelligent detection of local changes - no regular background sync, development is in progress Upgrading from 1.0 beta 1: moving back and forth should work seamlessly Upgrading from 0.9.x: * Upgrading and downgrading should work seamlessly when using existing configurations. But this being an beta, better ensure that you have backups of both your data and your configurations in ~/.config/syncevolution. * The new configuration layout is only used when creating new configurations or explicitly invoking "syncevolution --migrate" (see above). Such configs cannot be used by older SyncEvolution releases. Source, Installation, Further information ========================================= http://syncevolution.org/blogs/pohly/2010/syncevolution-10beta2-released Source snapshots are in http://downloads.syncevolution.org/syncevolution/sources i386, amd64 and lpia binaries of 1.0 beta 2 for Debian-based distributions are available via the "unstable" syncevolution.org repository. Add the following entry to your /apt/source.list, then install "syncevolution-evolution": deb http://downloads.syncevolution.org/apt unstable main These binaries include the new "sync-ui" GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy). 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/evolution. In contrast to 0.8.x archives, the 0.9 .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 getting started steps: http://syncevolution.org/documentation/getting-started -- Patrick Ohly, on behalf of everyone who has helped to make SyncEvolution possible: http://syncevolution.org/about/contributors

10 years, 4 months

4
8
0 / 0

[SyncEvolution] Backend changes tracking and Automatic sync

by Zhu, Yongsheng

Hi, all I'm working on automatic sync. One of scenario is to track changes of backends and do automatic sync. So we need define APIs for this. See below. // a listener to listen to changes of backend class SyncSourceListener { public: /** itemAdded is a callback when an item is newly added by backend */ virtual void itemAdded(const string &luid, const string &item, bool raw) {}; /** itemRemoved is a callback when an item is newly removed by backend */ virtual void itemRemoved(const string &luid) {}; /** itemUpdated is a callback when an item is newly updated by backend */ virtual void itemUpdated (const string &luid, const string &item, bool raw) {}; }; class SyncSource { public: ... //add listener of the sync source void startListener(SyncSourceListener *listener) { throw std::runtime_error("don't support listener"); } }; The example code is: class MyListener : public SyncSourceListener { // implement itemAdded, itemRemoved, itemUpdated if wanted }; Syncsource source; MyListener listener; source.setListener(listener); Some behaviors are specified by Patrick: - open()/close() are not called - a source is used either for change notifications or data access - it only has to support at most one listener - changes made by SyncEvolution as part of a sync may be reported, but don't have to - the listener instance is owned by the caller - the source should continue monitoring changes until destructed For SyncSourceListener, the concern here is that we are not sure whether needing this level of detail. For backend tracking used in automatic sync, below API is enough: virtual void itemChanged(); // callback when there is any change in the backend Anyone has idea or suggestion? Another thing is that backends don't have opportunity to process its changes only if they are integrated with glib main loop. We should have a mechanism to support this. Potential solutions are(rough ideas): 1) new threads for backends 2) add APIs in SyncEvolution and syncEvolution call APIs to give opportunity to backends to process their changes. Anyone who has concerns or ideas, please feel free to raise them. Thanks. Regards, Yongsheng

10 years, 4 months

1
0
0 / 0

Re: [SyncEvolution] CouchDB contacts database problem continues at 0.9.2]

by Ian Reid

Subject: Re: [SyncEvolution] CouchDB contacts database problem continues at 0.9.2 Date: Thu, 25 Feb 2010 19:20:10 -0800 On Thu, 2010-02-25 at 21:26 +0100, Patrick Ohly wrote: > On Sat, 2010-02-20 at 17:17 +0100, Patrick Ohly wrote: > > Looking at the code again and the alleged fix for the Couchdb problem I > > see that the fix can't have the desired effect. It did reorder the > > databases as desired, but picking the default one is done differently. > > I've reopened 7877. Sorry for that! > > A (working!) fix should be in 1.0 beta 2. This time, I actually ran some > tests with a default configuration on an Ubuntu chroot and that worked. > > With 1.0 beta being a viable alternative for 0.9.2, I'd rather not do a > 0.9.3 update. Is that okay? > Patrick, 1.0 beta 2 is working well for me. I certainly have no need to go back to 0.9.x. Thank you for checking back. I'm still looking forward to direct sync via bluetooth with Nokia 2760, although it wouldn't surprise me if this very low-end phone is not supported. It does work with the Nokia Windows synchronization package however, so perhaps there is hope. Nicely done presentation at FOSDEM 2010 by-the-way. Best regards, Ian

10 years, 4 months

1
0
0 / 0

Re: [SyncEvolution] CouchDB contacts database problem continues at 0.9.2

by Patrick Ohly

On Sat, 2010-02-20 at 17:17 +0100, Patrick Ohly wrote: > Looking at the code again and the alleged fix for the Couchdb problem I > see that the fix can't have the desired effect. It did reorder the > databases as desired, but picking the default one is done differently. > I've reopened 7877. Sorry for that! A (working!) fix should be in 1.0 beta 2. This time, I actually ran some tests with a default configuration on an Ubuntu chroot and that worked. With 1.0 beta being a viable alternative for 0.9.2, I'd rather not do a 0.9.3 update. Is that okay? -- 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.

10 years, 4 months

1
0
0 / 0

[SyncEvolution] sync KDEPIM -- Nokia N900

by Eildert Groeneveld

Dear All as an early Linux user (as of LSL.9) its great to lay my hands on an Nokai N900, running a complete Linux installation on a phone. However, what is sorely missing for this setup to make sense to me is KDEPIM -- N900 synchronization particularly the ever changing calendar. (years ago I used kpilot and the Treo) After having again surfing the internet it seems that syncevolution seems to be the furthest developed and thus something I should focus on and try to get it going. There are a number of questions, the answers to which might put me on the right track. should the following work or are there other options: 1. syncevolution direct: N900<->laptop (kde4.4/kubuntu) seems to work going by the documentation is that so? only via BT? syncevolution from 30.1. would be running in the N900 on the laptop 1:0.9.2+1.0beta1 2. syncevolution n900 -- google -- laptop same packages as above 3. akonadi on the laptop side again syncing with google Which would be the best route to follow? Thus far, I have not been able to sync the N900 with google: I cannot establish contact, eventually syncevolution times out on the N900. For configuration with google: sync url and web url are as proposed by syncevol the other specs are: username: tredlie(a)googlemail.com password : xxxxxxx contacts database: contacts (what actually should go in here?) calendar database: left empty at this stage ( (what actually should go in here?) notes: not set other fileds : normal Sync can this be expected to work? If yes: any idea what might be wrong? Is there a log somewhere? It would be great, if we could finally have a proven sync path for KPEPIM and other devices. greetings Eildert

10 years, 4 months

2
6
0 / 0

[SyncEvolution] Bluetooth panel in syncevolution.org binaries (was: Re: SyncML Tests 2010-02-24 09-48: head-evolution-hardy-2.22.1-amd64)

by Patrick Ohly

On Mi, 2010-02-24 at 08:53 +0000, Ohly, Patrick wrote: > prepare > Value > compile > failed > dist > failed > libsynthesis-fetch-config > okay > syncevolution-fetch-config > okay > Total passed cases (all: 4) > 2 Our Ubuntu Hardy build environment doesn't have libgnome-bluetooth-dev, which is required for the Bluetooth panel plugin. I've installed the necessary files from Karmic, forceing dpkg to ignore dependencies because I didn't want to touch existing files (see below). Hopefully this will result in a plugin .so which works on later distros. Clearly it won't work on Hardy. # dpkg -i libgnome-bluetooth-dev_2.28.1-0ubuntu2_amd64.deb libgnome-bluetooth7_2.28.1-0ubuntu2_amd64.deb (Reading database ... 30151 files and directories currently installed.) Preparing to replace libgnome-bluetooth-dev 2.28.1-0ubuntu2 (using libgnome-bluetooth-dev_2.28.1-0ubuntu2_amd64.deb) ... Unpacking replacement libgnome-bluetooth-dev ... Selecting previously deselected package libgnome-bluetooth7. Unpacking libgnome-bluetooth7 (from libgnome-bluetooth7_2.28.1-0ubuntu2_amd64.deb) ... dpkg: dependency problems prevent configuration of libgnome-bluetooth7: libgnome-bluetooth7 depends on libdbus-glib-1-2 (>= 0.78); however: Version of libdbus-glib-1-2 on system is 0.74-2. libgnome-bluetooth7 depends on libglib2.0-0 (>= 2.18.0); however: Version of libglib2.0-0 on system is 2.16.3-1. libgnome-bluetooth7 depends on libgtk2.0-0 (>= 2.15.0); however: Version of libgtk2.0-0 on system is 2.12.9-3ubuntu2. dpkg: error processing libgnome-bluetooth7 (--install): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of libgnome-bluetooth-dev: libgnome-bluetooth-dev depends on libgnome-bluetooth7 (= 2.28.1-0ubuntu2); however: Package libgnome-bluetooth7 is not configured yet. dpkg: error processing libgnome-bluetooth-dev (--install): dependency problems - leaving unconfigured Errors were encountered while processing: libgnome-bluetooth7 libgnome-bluetooth-dev (hardy-amd64)root@knlcst4:/tmp# dpkg -i --force-depends libgnome-bluetooth-dev_2.28.1-0ubuntu2_amd64.deb libgnome-bluetooth7_2.28.1-0ubuntu2_amd64.deb (Reading database ... 30159 files and directories currently installed.) Preparing to replace libgnome-bluetooth-dev 2.28.1-0ubuntu2 (using libgnome-bluetooth-dev_2.28.1-0ubuntu2_amd64.deb) ... Unpacking replacement libgnome-bluetooth-dev ... Preparing to replace libgnome-bluetooth7 2.28.1-0ubuntu2 (using libgnome-bluetooth7_2.28.1-0ubuntu2_amd64.deb) ... Unpacking replacement libgnome-bluetooth7 ... dpkg: libgnome-bluetooth7: dependency problems, but configuring anyway as you request: libgnome-bluetooth7 depends on libdbus-glib-1-2 (>= 0.78); however: Version of libdbus-glib-1-2 on system is 0.74-2. libgnome-bluetooth7 depends on libglib2.0-0 (>= 2.18.0); however: Version of libglib2.0-0 on system is 2.16.3-1. libgnome-bluetooth7 depends on libgtk2.0-0 (>= 2.15.0); however: Version of libgtk2.0-0 on system is 2.12.9-3ubuntu2. Setting up libgnome-bluetooth7 (2.28.1-0ubuntu2) ... Setting up libgnome-bluetooth-dev (2.28.1-0ubuntu2) ... Processing triggers for libc6 ... ldconfig deferred processing now taking place -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Pützstr. 5 Phone: +49-228-2493652 53129 Bonn Germany

10 years, 4 months

1
0
0 / 0

[SyncEvolution] Evolution data temporarily gone -> deleted on server

by Patrick Ohly

[Reposting here with Nicholas' permission] On Mi, 2010-02-24 at 07:01 +0000, Nicholas Goodwin wrote: > I would like to file a bug/change request against SyncEvolution 0.9, > running SyncUI on Ubuntu 9.10 with Evolution 2.28.1 and ScheduleWorld. > > For some reason, Evolution sometimes forgets its contacts, tasks etc. > Rebooting the machine solves this problem - the data is still there. If > you run a sync in this state, everything is deleted from the server. It > would be more sensible if it first warned the user somehow that all the > data had disappeared. This is indeed bad. I haven't heard of this problem before. Regarding working around this as you suggested: we could do it in a similar way as the "preventSlowSync" option. With sync property "preventClearPeer=1" set (default), a sync which removes all items from a peer is not allowed to proceed, with a suitable error message. To proceed, the user would then have to pick a sync mode as in the "preventSlowSync" case (slow, refresh from server/client) or run a two-way sync with "preventClearPeer=0". Better names for "preventClearPeer" welcome. > I can provide logs etc. if necessary. A log would be interesting, although I doubt that it will tell us anything about this EDS failure. -- 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.

10 years, 4 months

1
0
0 / 0

[SyncEvolution] Addressbook error when using LDAP-based addressbook

by Robert Markula

Hi, I'm using syncevolution 0.9 on Ubuntu 9.10 karmic in conjunction with funambol. In evolution I've got a LDAP addressbook which I can access just fine (in evolution). However, running syncevolution, I immediately get the following error: [ERROR] addressbook: reading all items: EBookStatus returned 20 What does this error message mean? Cheers, Robert

10 years, 4 months

2
2
0 / 0

[SyncEvolution] Sync-UI on ubuntu desktop

by Bommaraju, Rajyalakshmi

HI, I am trying to run sync-ui on my ubuntu desktop. Lanches fine, I setup account for scheduleworld and pressed "Sync Now" button. I am getting "Fatal database error" . What am I missing? I do have evolution-data-server on my system. Thanks Raji

10 years, 4 months

4
18
0 / 0

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

syncevolution February 2010