On Mo, 2011-11-14 at 14:10 +0100, Chris Kühl wrote: > For a while now I've been working on porting the syncevo-dbus-server > to use the GIO dbus implementation, GDBus. This is a configure time > option that can be explicitly set using the --with-gio-gdbus flag or, > if no flag is given, looks for an adequate version of GIO and, if > found, builds with GIO GDBus. > > The work is taking place on the gio-gdbus branch. The code changes in > the dbus/server/ files have only been made to make things work with > both implementations. The GIO GDBus implmentation lives in the > src/gdbusxx directory.
Once you have something that you want to be included in an automatic test run, push a branch called "for-master/gio-gdbus" and it will be included in the next test run. Currently I start these runs manually, so drop me a note. The test run will also not do much with that particular change except for checking that it causes no regressions when --with-gio-gdbus is off, so I would add a new build platform using Debian Testing where that flag is set, then run the D-Bus tests there. > Work is now being done to correct failures that the test-dbus.py > script bring up. Currently there are no more errors but 23 failures. > This is compared to 11 failures when running the test-dbus.py script > on the master branch. None of those errors occur in the nightly testing of the master branch: http://syncev.meego.com/2011-11-12-12-51_all/testing-amd64/nightly.html#dbus Don't worry too much about the (probably) incomplete test setup, better focus on the issues that are caused by the GIO GDBus usage. Eventually it would be nice to know whether the other failures are really due to some missing setup. They might also be genuine bugs which simply do not show up on the test platform. What I see occasionally is that the D-Bus server doesn't shut down (quickly enough?) after a test has completed. > One side issue... Late last week, I ran into an issue when using the > -O0 gcc flag. It was generating invalid code from the > MethodHandler::add method. With the other optimization levels this > doesn't occur. I'm not sure if this should be considered an issue as > it seems to be a known issue[1] in GCC. -O0 doesn't really have to work, but I don't like mysteries. If there was an endless supply of time, then this should be investigated. There may be reasons outside of our source for the failure, but perhaps not. -- 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 [email protected] http://lists.syncevolution.org/listinfo/syncevolution
