Red Hat Bugzilla – Bug 214695
we should have dbus 1.0 in rhel5
Last modified: 2013-03-13 00:51:01 EDT
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
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.
- 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
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.