Hello! Does anyone need anything fixed in 1.2.1?

Various smaller (and one larger) fixes have accumulated on the maintenance branch. If I don't hear otherwise, then I will get the ball rolling on packaging and pushing a 1.2.1 update. Here's what I have so far (from the NEWS file): * GTK UI + config: fix "custom server" setup (BMC #13511)  When the "default" config template (= ScheduleWorld) was downgraded to  "not consumer ready" in SyncEvolution 1.1.0.99.1, setting up a custom  SyncML service in the GTK UI stopped working because the UI wouldn't  show the "not consumer ready" config.  The problem described above is deterministic and fixed now.  Initially the problem seemed to be random. So perhaps there is  also another, related issue. * phone sync: delete<->delete conflict + phone calendar+todo sync (BMC #23744)  When deleting an item on phone and locally, the next sync failed with  ERROR messages about "object not found". Retrying the sync then worked. * Nokia: prevent accidental usage of "calendar" or "todo" sources  Nokia phones use a combined "calendar+todo" source for syncing. The  "calendar" and "todo" sources also exist because that is where local  databases are configured.  In such a setup, syncing always has to use "calendar+todo". For example,  to refresh from the Linux desktop to the phone, use:       --sync refresh-from-server <config> calendar+todo  To work with items (restore, show local content), use the underlying sources,  as in:       --print-items <config> calendar  It was possible to accidentally sync with the "calendar". This commit  prevents that by adding an invalid URI setting to the "calendar" and  "todo" sources in the Nokia and Ovi templates. Existing configs are not  touched, so beware when you already have configured your Nokia phone. * syncevo-dbus-server + phone sync: catch SIGPIPE to avoid premature exit  Frederik Elwert reported that running a local sync with a phone via  Bluetooth caused the syncevo-dbus-server to shut down during a sync.  Explicitly telling the process to ignore the SIGPIPE signal solved that  problem. * documentation: added glossary and command line conventions sections,  improved listing of properties, embedd property definitions in man page,  README and README.html * EDS compatibility: fixed inconsistency in libecal check  The check for the _r variants in libical still used an older max  version. This might have prevented using them (if not found) or  could have led to a mixture of old and new libecal in the same  process (probably crashed). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list SyncEvolution(a)syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution

On Tue, 2011-11-22 at 14:04 +0000, Peter Robinson wrote: > On Mon, Nov 21, 2011 at 8:13 PM, Patrick Ohly <patrick.ohly(a)intel.com&gt; wrote: > > Hello! > > > > Does anyone need anything fixed in 1.2.1? > > 1.2 fails to build in F-17. I'm not sure if that's because of the > glib2 deprecations being turned on or eds changes for 3.3.x (or a > combination of both). A full build log is here > http://koji.fedoraproject.org/koji/getfile?taskID=3532017&name=build.log > but I've not had a chance to look at it any closer. Looks to me like it fails because of including specific glib headers instead of glib.h. The function deprecation is just a warning. Can you try replacing all <glib/*.h> include statements with <glib.h> and provide the patch? Would it be okay to ship 1.2.1 without that patch? Just trying to find out how important it is.