dbus 1.0 will be release very soon, probably tomorrow. We should get it into RHEL5, it only contains a few, but important fixes wrt to locking of pending calls.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
Reasonings for getting D-Bus 1.0 in: We are supporting a library that is supported upstream It is API/ABI stable and our customers can use it with confidence Many nasty crashers have been fixed Locking on pending calls would sometimes cause an assert crash and some little used API's also caused asserts due to locking issues. This was seen when openeing up the file dialog in evince on fc6. It is not a huge change from the library shipped with fc6 other than the fixes. The major change is the addition of machine-id files place in /var/lib/dbus. An issue with the new library is that some apps (i'm looking at HAL here) will try to call dbus_connection_close which will assert. This fatal assert can be patched out (I have a patch for it in the olpc branch) or more useful will be to disable asserts alltogether. You want to diable asserts in the final build anyway.
Some thoughts - yes, we really want D-Bus 1.0 in RHEL5 - build flags needs to be looked into; some distros were using D-Bus with asserts turned off and it caused crashes in HAL (rather than just warnings) and that effectively broke things. I'm almost positive other D-Bus using apps than HAL suffer from this. - Need to put D-Bus 1.0 in Rawhide and see what happens. Possibly try to put a D-Bus without asserts in Rawhide too but do this in close coordination with all other packages that uses D-Bus. My prediction right now is that things will break if we disable asserts. It's something we want to fix for FC7 going forward but it's a huge task going through all apps using D-Bus.
You essentially have D-Bus 1.0 in fc7 right now. A better test would be to install it on FC6 (which I have been running). The only thing that has had a problem was HAL. That is that I can see. So there might be others. BTW if you are crashing with asserts off you are doing something really bad and I would like to know thw apps that do.
Agree it's a bug if apps (like HAL.. but may have been fixed on HEAD, will definitely get fixed in the next release) crashes with asserts off but that's just the way it is. Btw, I think the most common crasher with asserts off is trying to free a DBusError not set, it's wrong but not "something really bad" I think. I guess we should just try a build with asserts turned off in Rawhide and fix bugs as they appear. But right now we're busy with RHEL5.
FWIW, here is the policy we use for glib and gtk: -enable-debug. Turns on various amounts of debugging support. Setting this to 'no' disables g_assert(), g_return_if_fail(), g_return_val_if_fail() and all cast checks between different object types. Setting it to 'minimum' disables only cast checks. Setting it to 'yes' enables runtime debugging. The default is 'minimum'. Note that 'no' is fast, but dangerous as it tends to destabilize even mostly bug-free software by changing the effect of many bugs from simple warnings into fatal crashes. Thus --enable-debug=no should not be used for stable releases of GLib. Our glib builds are done with --enable-debug=minimum
in dbus there are checks and asserts. --disable-asserts disables internal API asserts used to check the correctness of the bus and libraries. --disable-checks disables checks on public API's. The crashes you are seeing in HAL most likely have to do with the fact that checks are on by default.
[mclasen@golem FC-6]$ brew latest-pkg dist-5E dbus Build Tag Built by ---------------------------------------- -------------------- ---------------- dbus-1.0.0-1.el5 dist-5E johnp
dbus-1.0.0-6.el5 included in 20061218.1 trees.