On Mon, Nov 14, 2011 at 4:49 PM, Chris Kühl <blixtra(a)gmail.com> wrote:
On Mon, Nov 14, 2011 at 2:31 PM, Patrick Ohly
> 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.
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.
>> Work is now being done to correct failures that the
>> 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, 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.
Yeah, déjà vu. ;) My goal is to reach parity now.
I currently get 8 failures for each wrapper on my machine and
Krzesimir gets 5 failures. We are both on Fedora 15.
> 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.
3 of my failures magically went away so this could have been it.
I'll now start to work out the plan for running multiple concurrent sessions.