On Mon, Nov 14, 2011 at 2:31 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
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.
Ok. We should be close to requesting a merge. Only 2 failures to fix
before we've reached parity on our machines.
> 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:
I was thinking this may be the case.
Don't worry too much about the (probably) incomplete test setup,
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.
Yeah, déjà vu. ;) My goal is to reach parity now.
What I see occasionally is that the D-Bus server doesn't shut
(quickly enough?) after a test has completed.
Ok, I'll keep an eye out for this.
> One side issue... Late last week, I ran into an issue when using
> -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 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.