Bug 214695 - we should have dbus 1.0 in rhel5
we should have dbus 1.0 in rhel5
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dbus (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-08 16:25 EST by Matthias Clasen
Modified: 2013-03-13 00:51 EDT (History)
2 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-19 10:43:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthias Clasen 2006-11-08 16:25:05 EST
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.
Comment 1 RHEL Product and Program Management 2006-11-08 16:40:48 EST
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.
Comment 2 John (J5) Palmieri 2006-11-08 16:45:23 EST
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.
Comment 3 David Zeuthen 2006-11-08 16:52:05 EST
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.
Comment 4 John (J5) Palmieri 2006-11-08 16:57:40 EST
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.
Comment 5 David Zeuthen 2006-11-09 10:29:40 EST
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.
Comment 6 Matthias Clasen 2006-11-10 11:40:21 EST
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
Comment 7 John (J5) Palmieri 2006-11-10 11:44:39 EST
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.
Comment 8 Matthias Clasen 2006-11-13 16:44:59 EST
[mclasen@golem FC-6]$ brew latest-pkg dist-5E dbus
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
dbus-1.0.0-1.el5                          dist-5E               johnp
Comment 9 Jay Turner 2006-12-19 10:43:34 EST
dbus-1.0.0-6.el5 included in 20061218.1 trees.

Note You need to log in before you can comment on or make changes to this bug.