The result is the following error:

GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details -  1: Not running within active session)

A solution for Python is discussed on Stack Overflow. Here’s how the problem can be solved for SyncEvolution. In your crontab, use:

54 9 * * * env `dbus-launch` sh -c 'trap "kill $DBUS_SESSION_BUS_PID" EXIT; syncevolution'


This starts a D-Bus session (dbus-launch), runs syncevolution, then kills the D-Bus daemon (via the process ID set by dbus-launch) once syncevolution completes. It does that every day at 9:54. If you change that, then don’t run it too often, because that can consume a lot of resources on the server.

SyncEvolution in Distributions

Some might argue that releasing the source would be enough and that users who want binaries should ask their distribution. I would be happy to see more distributions pick up SyncEvolution: Fedora already has it, Debian and Ubuntu don’t. I don’t know about others. There is an intent to package it for Debian, but the usage of AGPL in the Funambol library raised some concerns.

It seems that there will be a need for separate binaries for a while. Besides, when I release an update I want users to actually use it without having to wait for a distro update.

Evolution 2.24 and 2.26

For a while the situation seemed to get better, with three releases in a row with the same interface (2.12, 2.20, 2.22). But 2.24 changes the interface again (for a good reason, but still…) and 2.26 is likely to do it again (reverting an API change in order to use upstream libical).

Avoiding the problem: one binary to sync them all

The prospect of having to support yet another set of libs was enough motivation to rethink my approach. In 0.8.1 I added code which calls all required Evolution functions indirectly via dlopen/dlsym. That way the binary itself doesn’t have to be linked against specific versions of the Evolution libraries. Because the required functions behave the same in all Evolution releases (knock on wood for the future…), the same binary now works with all currently supported Evolution releases.

Not only do I have less work packaging Evolution, users now also no longer have to pick the right package. “aptitude install syncevolution” just works. Yeah!

In order to be compatible with future releases, the binary also checks library versions more recent than the ones that are known to work if it doesn’t find a known-good one. This is slightly risky because those future libraries might not be compatible after all, but I’ll keep an eye on that. If I’m lucky, then it’ll save me work, if not, then I would have to release an update anyway. Now on to releasing 0.8.1 itself…

Available Packages

The usual number of packages are available again:

• for Evolution 2.6 (x86 and AMD64), 2.8 (only x86), 2.12 (x86 and AMD64, also works for any Evolution >= 2.10), all of these as .tar.gz and .deb
• for Mac OS X (a fat binary for PPC and x86)
• for Maemo (ITOS 2008, should work on Chinook and Diablo)
• source code

For installation instructions see the www.estamos.de installation page.

iPhone

I have not prepared packages for the iPhone. This platform is now covered by Funambol’s own client.

Changes

There have been no changes since beta 3. For those who switch from 0.7 to 0.8, here’s the full list of changes since that version:

Updating user configuration: this version introduces a new, simplified configuration layout. Old configurations still work. They can be converted to the new format via a new “--migrate” command line option.

0.8 also uses a different change tracking for Mac OS X address book, Evolution calendars, task lists and memos. After switching from a previous release to the current one or vice versa, do a “syncevolution --sync refresh-from-server” once to reset the change tracking. Not doing so can result in applying the same changes to the server multiple times and thus duplicates.

• New configuration file layout: following the freedesktop.org recommendation, new configurations are stored in $XDG_CONFIG_HOME/syncevolution or $HOME/.config/syncevolution if XDG_CONFIG_HOME is not set. The old layout under $HOME/.sync4j/evolution is still supported.
• New command line options: new configurations can be created by syncevolution itself (--configure), including setting of all configuration properties (--sync-property, --source-property). The configuration can dumped to stdout (--print-config), with or without comments explaining each property (--quiet). See the README for details (relevant section online).
• The “evolutionsource” source property no longer has to be configured. If left blank, the default client database will be synchronized.
• Selecting which kind of data is to be synchronized under a specific source name is a lot easier now and the same on all supported platforms: the SyncEvolution backends can be selected via aliases (e.g. “contacts”) and the format is specified via an optional MIME type (e.g. “contacts:text/x-vcard”). In the unlikely situation that multiple backends are active which can synchronize the same kind of data, then the right one can be selected by the unique name of the backend (e.g. “Evolution Address Book”).
• New configurations automatically get a random client ID string. Setting it manually is still possible, but no longer necessary. Disabling unavailable data sources is also done automatically.

  SyncEvolution checks that the backend is available and there is at least one database (the first one will be synchronized unless explicitly changed). If these checks fail and the sync source was explicitly requested by the user by listing it after the server name, then an error is printed and no configuration is written. If the user wants the default setup, then the source is silently disabled.

• All passwords can be read from stdin at runtime or an environment variable (see “--sync-property password=?” or README for details). Both avoids the less secure storing of plain text passwords in the configuration files (SF #1832458).
• Detached recurrences: meeting series where some occurrences were modified are now supported. Previously only the main event was synchronized. All exceptions got lost when copying back from the server. Requires a SyncML server which supports this. ScheduleWorld was extended to do that.
• Fixed segfaults caused by logging certain data. The reason was an API change in the client library’s logging calls which the older SyncEvolution code hadn’t been adapted to. Did not normally occur, but might have been the reason for SF #1830149 (unconfirmed).
• Time zone support: the time zones of incoming events are mapped to native time zone definitions whenever possible. Currently this works if the TZID follows the Olson naming scheme with a location at the end. Matching the time zone has the advantage of being able to update the time zone definition without having to recreate the event. If matching fails and the VTIMEZONE definition differs from one already imported earlier, then SyncEvolution works arounds limitation in Evolution by renaming the time zone. Previously the new event used the old and most likely out-dated time zone definition.

  Evolution itself does not do either of these steps itself yet, thus importing meeting invitations via Evolution still fails in some cases. The code implementing the time zone handling described above was written with inclusion into Evolution itself in mind; it got included in Evolution 2.22.3.

• On Maemo/Nokia Internet Tablets, calendar synchronization now works because the new calendar change tracking no longer depends on some of the backend calls which used to fail (SF #1734977).
• Added SSL configuration options: certificate checking can be relaxed or disabled completely (SF #1852647).
• Added a new file backend: stores each SyncML item as a separate file in a directory. The directory has to be specified via the database name, using [file://]<path> as format. The file:// prefix is optional, but the directory is only created if it is used.

  Change tracking is done via the file systems modification time stamp: editing a file treats it as modified and then sends it to the server in the next sync. Removing and adding files also works.

  The local unique identifier for each item is its name in the directory. New files are created using a running count which initialized based on the initial content of the directory to “highest existing number + 1″ and incremented to avoid collisions.

  Although this sync source itself does not care about the content of each item/file, the server needs to know what each item sent to it contains and what items the source is able to receive. Therefore the “type” property for this source must contain a data format specified, including a version for it. Here are some examples:

  • type=file:text/vcard:3.0
  • type=file:text/plain:1.0
• Code restructuring: it is now possible to add new backends and thus write SyncML clients for other kinds of data without touching any line of code in SyncEvolution itself. All the required interfaces are documented inside SyncEvolution itself. A HTML documentation can be built via the new “make doc” target (requires Doxygen and dot).

  The SyncEvolution framework itself never depended on GNOME or Evolution, only the Evolution data sources did. If you want support for other ways of storing your data, consider writing a new data source – it is really easy. See EvolutionSyncSource or TrackingSyncSource for details.

• Messages are printed to the screen immediately. More readable log file format.
• Maemo: the useless “list: unable to access calendars: failure” error message is avoided. It was triggered by not having memo support in Evolution Data Server. Cleaned up the code so that it properly distinguishes between ‘calendar’, ‘memo list’ and ‘task list’.
• added server template for MemoToo; note that the server has not been tested
• added synchronization of Evolution memo summary

  Most devices only synchronize plain text and do not have a separate summary field. Such an extra summary field was added to Evolution after memo support was initially implemented in SyncEvolution, therefore SyncEvolution did not transmit that field.

  Added transmitting the summary by inserting it as first line of the plain text blob *if* it is not already identical with the first line. When receiving a memo, the summary is set from the first line *without* removing the first line because the first line might have been used as a normal part of the memo.

• Various other minor changes, fixes and lots of code cleanups.
• license cleanup: SyncEvolution is GPL v2 or later

Contacts

In practice it failed for contacts because of multiple bugs in the Connector.

I fixed those and prepared a patch, but it will take a while before there will be an official Evolution release which contains the fix. 2.22.3 was just released and there are no plans to do further maintenance updates before 2.24. If you care about this problem, then perhaps report the problem to you Linux distribution maintainers and (kindly!) ask for an update via the distribution.

With the patch the SyncEvolution test suite runs almost without errors. The remaining problems are related to not quite storing the test contacts as Evolution normally does. For example, the different name components (first/second/middle name, title) are modified slightly. This most likely is a limitation of Exchange and doesn’t look like it’ll affect normal names. Sometimes extra line breaks are added at the end of strings.

Events

With calendars there were other problems. Updating existing events consistently failed with 0.8 beta 2. I turned out that the code introduced in the betas for detached recurrences tries to use the Evolution calendar API in a way which is not implemented (or supported) by the Exchange backend (e_cal_modify_object(CALOBJ_MOD_THIS) without a recurrence ID doesn’t work). It worked with the file backend, but I suspect that I have used the API in a way that it wasn’t meant to be used. I solved this problem by rewriting the code slightly. SyncEvolution 0.7 and (once it is released) 0.8 should both work.

In general the Evolution Exchange Connector was not particularly stable. I had to add a five second delay between simulated syncs or it would return inconsistent data for the previous run. There are e-cal.c:319: Unexpected response warnings: they are printed directly by the Evolution library, so SyncEvolution cannot suppress them. They don’t seem to indicate any real problem, so just ignore them. The Connector also crashed frequently when accessing calendars for the first time. What worked best for me is to start Evolution, check my calendars and if I get a message that the backend crashed, try again. Your mileage may vary…

Configuration

Exchange databases can be selected just like normal Evolution databases: use their name for the evolutionsource property.

In addition to that, the evolutionpassword property must also be set for each source to the Exchange password! The user name is not needed.

0.8 beta 1 no longer depends on that call and therefore updating to it solved the problem, at least in that case where the user reported back. The other problem also can no longer occur. If you have calendar problems, please use 0.8.

The beta has been out for a while now, with no reports other than the expected (and now solved) X-OSSO-CONTACT-STATE issue on Maemo. I’m going to rework the www.estamos.de web pages soon so that they refer to 0.8 as the stable release. The final release will then follow this month.

This additional information can be essential for not missing a meeting, so anyone synchronizing his calendar or writing software which is used for that purpose should care. Neither SyncEvolution nor the SyncML servers it is commonly used with supported detached recurrence – until now. This has always been a thorn in my side, so it is with great pleasure that I can announce that 0.8 in combination with ScheduleWorld will finally synchronize detached recurrences. Both client and server required changes; I had to nudge Mark a bit until before he started working on it, but now that it is in place we are glad that we did it. In the remainder of this post I’ll give you a bit more background information.

iCalendar 2.0 + SyncML

The way how iCalendar 2.0 represents a recurring event is via a VEVENT’s RRULE property. This describes how the event repeats. A program calculating all occurrences evaluates that rule and then removes those instances which match the exceptions specified via the EXRULE or EXDATE properties.

A detached recurrence (sometimes also called “child event”) is stored as another VEVENT with the same UID as the parent event and a additional RECURRENCE-ID. This ID specifies which of the regular occurrences is overridden by the child event. Because the child is a normal VEVENT, all of the event properties can be specified independently of the parent.

In SyncML there are two ways of sending information about a recurring event and its exceptions: all VEVENTs with the same UID in the same item, or one VEVENT per item. After asking around among SyncML server developers it turned out that ScheduleWorld and Synthesis favored the “one VEVENT per item” approach because it is closer to the way how events are synchronized so far. It therefore has a chance to work even with servers which do not know the special semantic, as long as they preserve the relevant properties. This approach is what SyncEvolution and ScheduleWorld implement now.

Ordering of related VEVENTs

The ordering of these related items is important: ScheduleWorld must know the parent event before it can store the children. SyncEvolution takes care of sending items in the right order. Likewise, Evolution gets confused if a parent is added after its children: the parent event is added and stored in the calendar file with the original UID, but it cannot be retrieved under that UID until the data server is restarted. ScheduleWorld gets the order right, but because SyncEvolution is meant to also work with dumb servers (for example, a file sync source which knows nothing about the content of items), it works around this limitation by temporarily removing the children, adding the parent, then updating the parent with its children.

Updating/removing parent and children

ScheduleWorld cannot store children without a parent, so deleting the parent also removes all children. Evolution itself does the same, so normally everything works as expected. Now suppose that a dumb server tells SyncEvolution to remove only the parent. One solution would be to delete also the children, but then client and server would be out of sync. I decided to trick Evolution once more: because the API call to remove the parent automatically removes the children, they are saved by SyncEvolution before making that call and re-added afterwards. This leads to a slightly inconsistent state of the calendar, but the Evolution GUI copes and displays the children – poor orphans, you are not forgotten!

Whether modifications of a parent or child lead to an update of all related events is up to the client and server implementation. At worst it will lead to some extra traffic when items are resend although their content hasn’t changed. SyncEvolution can update both parent and children if asked to by the SyncML server.

Other SyncML servers

I’m not aware of any other SyncML server supporting detached recurrences, although there are mobile phones (like some Nokia models) which support them via a X-RECURRENCE-ID extension to vCalendar 1.0. Together with insufficient support for time zones, this looks like a rather significant gap for SyncML-based calendar synchronization compared to proprietary solutions. Hopefully SyncML server vendors will wake up and do something about it…

The Problem

After the US changed the dates when they switch to and from summer saving time in 2007, programs and OS installations had to be updated to accomodate for this change. Since 2.12, Evolution uses the time zone information that is installed in the system so that Linux distributors only have to update one central package (usually called “tzdata”) when such changes happen. The US change wasn’t the only example; it just happened to be the one which affected most users.

However, this change in Evolution had no effect for meeting invitations. Each meeting invitation comes with its own definition of the corresponding time zone, and this is what Evolution uses – or rather, tried to use. Importing a new meeting invitation into a calendar which already contains an old time zone definition ignores the new time zone definition. The new meeting is then displayed using the old definition. Everyone who has used Evolution for a while is likely to be affected by this, because time zone definitions in the file calendar backend are never deleted.

The reason for this problem is that Evolution is designed so that for each time zone identifier, only one definition can be stored per calendar. If you have imported the 2006 definition of GMT -0600 (Standard) / GMT -0500 (Daylight), then the updated 2007 definition of it will be ignored.

People (including a younger incarnation of myself… live and learn…) have argued that Microsoft should have embedded a revision string or year into their IDs to make them unique, but that is not required by the pertaining standards. Besides, Evolution 2.12 also no longer creates unique IDs. Recipients of meeting invitations simple have to handle conflicting time zone definitions, there’s no way around that.

Another problem with using the custom time zone definition that came with an event is that if that time zone changes later on, Evolution will continue to use the out-dated definition unless a new meeting invitation is sent. This also applies to old events that were created with Evolution <2.12: the current Evolution uses different IDs and therefore fails to use the more up-to-date system time zone information for those meetings.

Using the system time zones also potentially has the advantage of using more complete information about a time zone: the custom definitions included in meeting invitations are usually limited to just the transition rules for one year. If an event recurs in different years with different rules, then this is not sufficient. Unfortunately, Evolution only uses the rules for the two upcoming transitions even when the system time zone definition contains more rules. The effect is that a historic event in the US in 2006 is displayed using the updated rules for 2007, which leads to the wrong result for those weeks where the rules differ. Events very far in the future may also be affected.

Fixing the Problem

Redesigning the Evolution architecture was a scary thought because it would have been a very intrusive change which affects all calendar backends. Not suitable for a minor update in the stable release branch!

The approach taken instead for importing events consists of two steps:

1. When importing an event, try to match the time zone to one of the system time zones. If that succeeds, then the meeting will automatically use the current set of rules and is displayed correctly even if those rules change. This mapping currently works for old Evolution events (regardless whether they are imported anew or already exist in a calendar) and meeting invitations sent by programs using the Olson database naming scheme with the location at the end (e.g., /softwarestudio.org/Olson_20011030_5/Europe/Berlin).
2. The mapping does not yet work for Microsoft meeting invitations, to name just one example. Time zone identifiers are not standardized, so there needs to be a fallback: if mapping fails, the time zone definition is compared against an older definition with the same ID. If the definitions conflict, then the newer definition is renamed and stored under a new ID. This is visible in the Evolution GUI as a decimal number at the end of the the time zone name, like this: GMT -0600 (Standard) / GMT -0500 (Daylight) 2.

In addition to importing events as described above, the time zone definition of existing events in a calendar is also updated on the fly to the current definition when displaying or exporting the event. Of course, this only works if the time zone can be mapped. Otherwise, the original, possibly out-dated time zone definition is used. This transformation is not immediately obvious in an exported event because the ID remains the same and only the time zone definition is replaced by the current one.

Fixing Calendars

Obviously, you need an updated Evolution which contains the patches. 2.22.3 and 2.24 will have them. But updating Evolution alone is not enough: meetings with custom time zone definitions which were imported earlier will continue to use the old definitions. You have to reimport all meeting invitations once more to update the time zone definition.

Remaining Work (Volunteers Wanted!)

Only the file and Exchange calendar backends have been adapted at this time. The same kind of problems will continue to occur with backends like the GroupWise one, unless someone who knows that backend steps up and fixes it. The change is simple; use the file backend diff as example.

The handling of system time zone information should be extended so that it uses the complete database and thus displays past and future events correctly. The Evolution developers plan to add that in some major future update (i.e., not 2.22.3).

Mapping of Microsoft time zone IDs would be useful, even though it is not strictly required thanks to the fallback. Microsoft uses two different ID formats: one includes a location and thus could be mapped if someone put together a mapping table. The other is composed of the two GMT offsets, as in the example above. Because different locations with different rules can end up with the same ID, the ID alone would not be enough to map back to the location. Instead of investing effort into analyzing the rules and inferring the original location from that, it is probably easier to simply rely on the fallback for conflict resolution.

SyncEvolution and other external programs

SyncEvolution takes care of importing time zone definitions correctly since 0.8 alpha 1, even when combined with an older Evolution release. This has to be done by each program which imports events using a combination of e_cal_add_timezone() and e_cal_create_object(). Evolution itself has no chance to do the time zone mapping/renaming because it never has access to both the time zone definition and the corresponding event.

First, calendar synchronization will always lose information as long as any link in the chain from one Evolution client to the other is limited to vCalendar 1.0, because relevant features that Evolution depends on were added to 2.0 which the predecessor cannot express. This does not only affect Evolution, but also the Thunderbird client.

Second, nothing in the SyncEvolution support for contacts has changed since 0.7. The update therefore won’t magically fix the problem encountered in 0.7. I run nightly end-to-end tests between different Evolution versions using my.funambol.com, sync.scheduleworld.com, and www.synthesis.ch. All of these tests work just fine. There are no bug reports about it either.

Finally, the segfault mentioned in the blog was already fixed in the current stable release (0.7). All I can do is fix a problem and provide new binaries. I cannot retroactively fix the problem in installed older binaries – that would be the holy grail of system maintenance. The issue about the segfault is still open because some users had segfaults which I could not properly explain. They cannot reproduce them either anymore and thus the issue has to remain open until someone else can provide the information required to proceed.

That doesn’t mean that there is no problem, but it does mean that I am not aware of any that I can fix. If you have a problem, create a bug report or send me an email and will do my best to locate and fix the problem.

There is an ongoing discussion in the Open Source world about the responsibilities of users and developers. It started when Linux developers asked a bug reporter to execute a complex analysis to narrow down on the source of the problem. A good, complete bug report will speed up solving the problem. In the case of SyncEvolution that means describing the platform it runs on (distribution, Evolution version, …), how SyncEvolution was installed (binary or compiled from source), the server that is used, what the expected and what the real behavior is. If it segfaults, including a stack back trace (run under gdb, “thread apply all bt”) or a memory check with valgrind (just put valgrind in front of the command line) would help. If the log (normally written in /tmp/) does not contain confidential information or that information can be stripped, then providing it is a big help, too. I promise to keep all logs sent to me by email absolutely confidential.

I’m aware that not everyone is able to analyze a problem on his own. Just report the problem and I’ll try o reproduce it myself before asking further questions.

Another contentious issue is whether it is the responsibility of the users to make the developer’s life as easy as possible. If you use the SourceForge bug tracker, you will make my life easier and reduce the risk that your problem falls through the cracks. Just make sure that you assign the issue to me (happens automatically when selecting a category), otherwise I don’t get notified about the issue. However, I also accept bug reports by email.

Not reporting a problem is of course also an option which is even less work for a user, but then don’t expect that the next version will be any better than the old one…

Changes in 0.8

• New configuration file layout: following the freedesktop.org recommendation, new configurations are stored in $XDG_CONFIG_HOME/syncevolution or $HOME/.config/syncevolution if XDG_CONFIG_HOME is not set. The old layout under $HOME/.sync4j/evolution is still supported.
• New command line options: new configurations can be created by syncevolution itself (--configure), including setting of all configuration properties (--sync-property, --source-property). The configuration can dumped to stdout (--print-config), with or without comments explaining each property (--quiet). See the README for details.
• The evolutionsource source property no longer has to be configured. If left blank, the default client database will be synchronized.
• Selecting which kind of data is to be synchronized under a specific source name is a lot easier now and the same on all supported platforms: the SyncEvolution backends can be selected via aliases (e.g. “contacts”) and the format is specified via an optional MIME type (e.g. “contacts:text/x-vcard”). In the unlikely situation that multiple backends are active which can synchronize the same kind of data, then the right one can be selected by the unique name of the backend (e.g. “Evolution Address Book”).
• New configurations automatically get a random client ID string. Setting it manually is still possible, but no longer necessary.
• All passwords can be read from stdin at runtime or an environment variable (see --sync-property password=? or README for details). Both avoids the less secure storing of plain text passwords in the configuration files (SF #1832458).
• Detached recurrences: meeting series where some occurrences were modified are now supported. Previously only the main event was synchronized. All exceptions got lost when copying back from the server.
• Time zone support: the time zones of incoming events are mapped to native time zone definitions whenever possible. Currently this works if the TZID follows the Olson naming scheme with a location at the end. Matching the time zone has the advantage of being able to update the time zone definition without having to recreate the event. If matching fails and the VTIMEZONE definition differs from one already imported earlier, then SyncEvolution works arounds limitation in Evolution by renaming the time zone. Previously the new event used the old and most likely out-dated time zone definition.
• On Maemo/Nokia Internet Tablets, calendar synchronization now works because the new calendar change tracking no longer depends on some of the backend calls which used to fail (SF #1734977).
• Added SSL configuration options: certificate checking can be relaxed or disabled completely (SF #1852647).
• Adding support for new local data sources is easier now. The SyncEvolution frame work itself never depended on GNOME or Evolution, only the Evolution data sources did. If you want support for other ways of storing your data, consider writing a new data source – it is really simple. See EvolutionSyncSource or TrackingSyncSource for details.
• Messages are printed to the screen immediately. More readable log file format.
• Various other minor changes and fixes.

Switching between alpha and stable release

This version introduces a new, simplified configuration layout. Old configurations still work. They can be converted to the new format via a new --migrate command line option.

This version also uses a different change tracking for calendars, task lists and memos. After switching from a previous release to the current one or vice versa, do a syncevolution --sync --refresh-from-server once to reset the change tracking. Not doing so can result in applying the same changes to the server multiple times and thus duplicates.

Installation

Installation is done almost as described for the the stable release. But because I don’t want users of the stable version to pick up the alpha version accidentally, you need to use different repositories:

• on Debian/Ubunutu: deb http://www.estamos.de/download/apt unstable main
• Maemo: .install file for alpha release You must have Pimlico Dates installed! Thanks to Ross, it is available for ITOS 2008 from the OpenedHand repository. This limitation will be removed again in the final release.

Setup

This is the biggest difference compared to 0.7, and hopefully a big step forward: on all platforms a single command is enough to create a fully operational configuration: syncevolution --configure --sync-property username=<your SyncML account name> --sync-property password=<SyncML account password> <server name>. A unique device ID is chosen automatically. “addressbook”, “calendar”, “memo”, “todo” sources are enabled if possible and use the default local database. No more editing of config files…

syncevolution --template ? prints a list of built-in server templates. The example configurations still included in the distribution are no longer needed and will be removed.

To review the configuration, use syncevolution --print-config <server name>. There are several other configuration options which might be of interest, for example proxy and the new SSL settings. Those can be changed using the same syntax as for creating the initial configuration.

Known Problems

When testing detached recurrences with ScheduleWorld it turned out that ScheduleWorld accepted the events, but didn’t forward them to other clients. This is still under investigation.

Regarding the improved time zone handling: Evolution itself does not do either of these steps itself yet, thus importing meeting invitations via Evolution still fails in some cases. The code implementing the time zone handling described above was written with inclusion into Evolution itself in mind; a discussion with the Evolution developers about that is in progress.

[Updated 2008-06-11] The setup procedure on Maemo was supposed to not configure sources for which no data is found. This doesn’t seem to work as intended, leading to error reports for “memo” and “tasks”. Until this is fixed, please disable the extraneous sources with syncevolution --configure --source-property sync=none <server> memo todo.

• I noticed problems with the background thread which watched the Evolution Data Server and therefore disabled it. This means that SyncEvolution will hang again when EDS dies unexpectedly.
• I fixed an incompatibility of the Funambol C++ client library with the Synthesis server; as it turned out later, this had also been fixed by Funambol on the head revision without updating the release branch. Synchronizing notes with that server now works fine.

As I mentioned before, as part of the work for the iPhone SyncEvolution was first ported to Mac OS X. The 0.7 release on SourceForge now also has a precompiled package for that platform. It should run on PPC and x86, but was only tested on x86. This is considered a proof-of-concept: the packaging is very primitive and unless there is demand I won’t compile future versions for Mac OS X.

Compared to 0.6 there are several reasons to update, so don’t hesitate, get your update in time to unwrap, ahem, unpack it under the Christmas tree…