On Mon, Nov 14, 2011 at 2:31 PM, Patrick Ohly <[email protected]> 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: > http://syncev.meego.com/2011-11-12-12-51_all/testing-amd64/nightly.html#dbus > 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. > What I see occasionally is that the D-Bus server doesn't shut down > (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 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. > Ok, noted. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
