Bug 214218

This is usually a symptom of the session bus either not running, or not bound to
your session. It's not a setroubleshoot issue.

For starters, is DBUS_SESSION_BUS_ADDRESS defined in your environment? (e.g. set
| grep DBUS_SESSION).

When happens when you run dbus-monitor? Do you get the same you list above?

Did you ssh in thus bypassing the dbus-launch gdm performs for you?

Provided you have a DBUS_SESSION_BUS_ADDRESS defined then what does 'ps ax |
grep dbus' show? Do you have a daemon listed after the dbus-launch? Is it
running? What happens if you close your session and log back in? Does the
problem go away?

Anyway, this isn't a setroubleshoot issue per se, it's more to do with dbus or
how you're trying to run things.

as discussed on irc, when calling sealert it just dies:

[tscherf@tiffy ~]$ sealert -s

(Setroubleshoot-Browser:5423): libglade-CRITICAL **: glade_xml_build_interface:
assertion `wid != NULL' failed
Traceback (most recent call last):
  File "/usr/bin/sealert", line 426, in ?
    start_service()
  File "/usr/bin/sealert", line 376, in start_service
    app.main()    
  File "/usr/bin/sealert", line 350, in main
    self.browser = BrowserApplet()
  File "/usr/lib/python2.4/site-packages/setroubleshoot/browser.py", line 79, in
__init__
    self.init_widgets()
  File "/usr/lib/python2.4/site-packages/setroubleshoot/browser.py", line 104,
in init_widgets
    self.window.connect_after("realize", self.on_realize)
AttributeError: 'NoneType' object has no attribute 'connect_after'

rpm -V setroubleshoot|grep glade shows no problem with the glade files.

problem remains with setroubleshoot rawhide version 1.3-1
 

Thorsten, I would like to do one more diagnostic test for me please. This
morning I discovered many of the system-config-* applets will not run, they seem
to fail because they can't open the X display. The tracebase in comment #2 is
saying there is no window, the inability to open the display is a very likely
candidate for why there is no window. 

For the failing console helper apps if I monitor /var/log/Xorg.0.log (tail -f)
I'll see message like this:

AUDIT: Tue Nov  7 13:11:18 2006: 2241 Xorg: client 31 rejected from local host

and what the client sees is a failure to open the X windows display and the
inability to open any windows.

Could you please see if you're getting these messages in your
/var/log/Xorg.0.log file? Try running system-config-soundcard, that's one which
I know fails for me. Try it with sealert -s on the command line and invoked from
the System->Administration->setroubleshoot menu item. Are the client rejection
messages generated in the X log when you do these things?

there is no log entry as you described. sorry. I really guess it has something
to do with dbus. we could try to isolate the problem later on, will be available
around 2pm EST, if you would like access one of the machines where this bug
happened...

Apparently, i have the same bug, some strings which should not be i18l, should
be, i have found one in browser.py.

-        self.window_name = _('browser')
+        self.window_name = "browser"

There are other files to patch, because the notification is show but the icon is
not.
 
When I start gnome in English all work perfectly.

ps: the same log output as Thorsten about dbus.

Good catch Alphonse! That would certainly explain things, thank you for your
help in diagnosing the problem. I never occurred to me to consider i18n as a
root cause.

However, I think this line:

self.window_name = _('browser')

is correct, that the name displayed to the user and it should be i18n, but the
mistake was then using this name to look up the widget in the glade file, here:

        self.window = self.wTree.get_widget(self.window_name)

that name should be hard coded to match the name in the glade file.

Thorsten, does running in english or modifying either of the two lines
referenced in /usr/lib/python2.4/site-packages/browser.py to be 'browser' fix
the problem for you? The i18n component probably explains why the problem you
were reporting wasn't surfacing more often and why we were not seeing it.

Oh, by the way, along with fixing the i18n issue, we'll also fix the error
checking/reporting, the dbus failure was a red herring caused by a chain of
earlier events.

Very good catch.

When changing  self.window_name = _("browser") to  self.window_name =
("browser") it works without problems.

cf: There are other files to patch, because the notification is show but the
icon is not.

Oups, self.window_name = "browser" fix entirely the problem for me too (after a
reboot)

*** Bug 215135 has been marked as a duplicate of this bug. ***