[SyncEvolution] SyncEvolution 1.2.1 released
SyncEvolution 1.2.1 === Maintenance release with various bug fixes. * 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. * vCard: X- chat extensions were limited to one instance per kind For example, only one Jabber account could be synchronized. This was caused by an incomplete definition of the conversion to and from vCard. * 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. * syncevo-http-server: support chained SSL certificates So far, the file pointed to by --certificate-file had to contain the server certificated (signed by a CA known to the client) and (optionally) a client certificate. Now the file may also contain additional intermediate certificates which will be sent to the client (chained certificates). * 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). * glib: avoid including glib/*.h headers directly Recent glib deprecates the direct inclusion of some of its headers, in favor of including glib.h. Doing that here whenever possible, so perhaps it now compiles on Fedora 17 (untested). 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. Release 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/2011/syncevolution-121-released Source snapshots are in http://downloads.syncevolution.org/syncevolution/sources i386, lpia and amd64 binaries for Debian-based distributions are available via the stable 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 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 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 ___ SyncEvolution mailing
Re: [SyncEvolution] Update on work to port syncevo-dbus-server to GIO GDBus
On Wed, Nov 16, 2011 at 2:52 PM, Patrick Ohly patrick.o...@intel.com wrote: On Mi, 2011-11-16 at 11:58 +0100, Patrick Ohly wrote: On Mi, 2011-11-16 at 11:10 +0100, Chris Kühl wrote: On Mon, Nov 14, 2011 at 4:49 PM, Chris Kühl blix...@gmail.com wrote: On Mon, Nov 14, 2011 at 2:31 PM, Patrick Ohly patrick.o...@intel.com wrote: Ok. We should be close to requesting a merge. Only 2 failures to fix before we've reached parity on our machines. After fixing those remaining issues, we ran the server under valgrind and fixed up a few memory leaks we found. I've now created a for-master/gio-gdbus branch, squashed the commits and pushed. I've started a test run. There seems to be a regression in the D-Bus testing. On Ubuntu Lucid, startup of the syncevo-dbus-server without GIO GDBus fails: http://syncev.meego.com/2011-11-16-10-54_dist/lucid-amd64/6-dbus/output.txt So, I finally got the issue in Debian Stable and Ubuntu LTS fixed. Turned out to be that I'd inadvertently set the server's main connection to shared instead of private. I'm not sure why this was only causing issues on these distros. That initially sent me searching for the issue in all the wrong places. Along the way I was also able to fix the --enable-notify flag which was broken. You can now actually disable notifications. This will all be in for-master/gio-gdbus within the next hour or so. The same binary runs on Debian Testing, albeit with regressions in TestSessionAPIsReal.testSync and TestSessionAPIsReal.testSyncSecondSession : http://syncev.meego.com/2011-11-16-10-54_dist/prebuilt-amd64/6-dbus/output.txt The nightly.html doesn't properly report the individual D-Bus errors, only the overall failure is correctly reported - I will investigate that. For comparison, this used to work in the previous test run: http://syncev.meego.com/2011-11-12-12-51_all/lucid-amd64/nightly.html Linking on Debian Testing fails because some library symbol is used without directly linking against that library (the binutils on that platform are more demanding and check for this): http://syncev.meego.com/2011-11-16-10-54_dist/gcc-4.6-amd64/3-compile/output.txt It should be fairly easy for me to fix these issues, while it is harder for you unless you have access to the right platforms or know what the issue is. Just let me know if you want me to lend a hand. Can you try these again, I'm not running into these issues on Debian Testing. Cheers, Chris -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] syncevo-dbus-server + forking processes
On Wed, Nov 16, 2011 at 2:39 PM, Patrick Ohly patrick.o...@intel.com wrote: On Mi, 2011-11-16 at 13:55 +0100, Chris Kühl wrote: On Wed, Nov 16, 2011 at 12:22 PM, Patrick Ohly patrick.o...@intel.com wrote: Here are some requirements for sync in forked process: * should be disabled when running outside of the D-Bus daemon (syncevolution command line in non-daemon mode, client-test testing) * interactive password requests through D-Bus must continue to work * abort/suspend requests via D-Bus must work * the forked process should shut down cleanly, so that valgrind --follow-child=yes --leak-check=yes provides sane results (the forked process in a local sync currently fails to do that, because it is forked in a less controlled environment and therefore just calls _exit()) * logging: * the main syncevo-dbus-server process should use syslog logging for its own messages, without redirecting stdout/stderr * the forked process should start redirecting stdout/stderr into the normal logging mechanism (so that library error messages are visible when running the syncevolution command line as client of the D-Bus server and, later, they appear in log files) and switch to a session log when the session is ready Thanks for the list of requirements. I'll take these into consideration. Some in there that we hadn't talked about before. I know, that's why I'd rather discuss this upfront. Some of these requirements are implied by change must not cause regressions (interactive passwords, abort/suspend), others are open questions (startup/shutdown of the forked process, logging). Somewhat related to this work is support for push sync. I suspect that this will also use forked processes to monitor remote and local databases without interfering with the main process. It would be good if the mechanism for forking and communication between process was generic and not tied to syncing alone. I'm not really well informed on the plans for push sync other that what I found in [1], There are no more specific plans yet. but the idea that I had in mind was for the forking process to initiate a d-bus peer-to-peer (one-to-one in the d-bus spec) connection by forking the process with the d-bus address as a command line argument. The client then uses that for communication. This seems pretty generic to me. The only differences would be the d-bus interface used. ...but maybe I'm misunderstanding what you mean. No, that's what I was looking for. When you say command line argument, does that mean that there will be an exec() involved? Would that start the same binary or something else? Yes this was going to be my proposal. The advantage of the exec() is that the new process is much cleaner. The downside is that it is harder to implement (How does the forking process find the right executable? I believe the place for the helper sync binary would be in the libexec directory: /usr/libexec/syncevolution/sync-session for example. How does injecting valgrind into the new binary work?) Valgrind can follow child processes with --trace-children=yes and create a log-file per process by inserting %p in the log-file name. and a bit more expensive (must load all libraries again). This will definitely require a small bit more resources to be used and take a few microseconds longer to start but these are resources that will be mostly loaded from memory (and probably cache) after the first sync session is started and be freed when the process disappears. Also, the time a fork-exec pair takes over just a fork is insignificant compared to how long a sync session takes. It might be easier to avoid the exec() and instead return to main() of the syncevo-dbus-server in the forked process (including freeing of all parent process resources, which must be done anyway), The potential problem I see is that some of the resources we may not be able to free because they are not under our control: libraries, etc. then go down a different path as if the binary had just been started. This is how I originally intended to implement this till I started looking into it a little more and asking around. To me, the potential problems seem to outweigh the advantages. Cheers, Chris ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
