Bug 435474

 This error is coming from dbus-python, so I'm not sure what I can do. We catch
any DBus exceptions and continue, which is why pupplet didn't exit.
 Are you still running the older yum-updatesd?
 Is there a dbus/dbus-python update for 5.2?

I do not see any dbus-python updates for 5.2.  This is consistent across many
many reboots so I am running the latest yum-updatesd.

Oh, BTW, you will get that error if there is an error in your callout function
in puplet.  Basically you are doing a c->python->c->python call.  When an error
occurs in your python callback it bubbles up until our C module handles it and
prints out a cryptic error.  Later versions of the python bindings fixed this to
do a proper traceback.  I am more than certain the error is in puplet or the
notification icon module you are using.

 Ok, thanks john. Just to clarify what you mean by "callout function". AIUI we have:

python    C       python
puplet => dbus => yum-updatesd (and then back again, for the response)

...so you think there is an error on the puplet side? For the request itself?

 The weird thing is that the above versions of puplet+yum-updatesd work fine on
Fedora 8, so does that imply we are doing something with the bindings that does
work on RHEL-5?

sorry, it gets a bit confusing when talking about local function calls in a RPC
library.  I'm talking about just the library side.  A callout or callback
function is the python method that is called in puplet when responding to a
reply or error from a message it sent.  What happens is the C D-Bus library gets
a reply and then tells the python bindings about it, the python bindings then
use the C python calls to call your python callout.  When an error happens in
your callout and it is not handled the older versions of the bindings bubbles
that back to C handler in the bindings which then print an error as if it
happened in the bindings and not in your application.  Newer versions of the
bindings handle this better along with slightly changing the semantics of D-Bus
calls which might account for it working in F-8 and not in RHEL.

What you are looking for is a variable named 't' which is being accessed before
it was assigned (Exception exceptions.NameError: "global name 't' is not
defined").  The best thing to do is put a try/except block around all of your
callouts. 

looking at the pirut code I noticed you are make all blocking calls so it is an
unhanded error from yum-updatesd where the error is happening.  You can figure
which one it is by putting try except blocks around all of the exported methdod
in yum-updatesd.  The error message looks a bit off since I can't find any
globals called 't'.  

Created attachment 296699 [details]
simple cmd line yum-updatesd controller

 Ok, so I got a latest RHEL-5 box ... added yum-updatesd, and wrote a simple
cmd line dbs client to talk to yum-updatesd, it showed no updates as "yum list
updates" showed nothing (but worked).
 I added  net-snmp-5.3.1-14.el5, and now yum list updates shows it. At which
point I got the same thing from the cmd line client. So everything seems to
work.
 AFAICS that means the gui client should work too, as those are the only things
it's calling.

 Cameron, can you check the cmd line client ... does it work, and puplet still
fail? Can you also give me the output of, for you:

# yum list installed rpm yum\*
Installed Packages
rpm.x86_64				 4.4.2-48.el5		installed      

yum.noarch				 3.2.8-7.el5		installed      

yum-metadata-parser.x86_64		 1.1.2-2.el5		installed      

yum-rhn-plugin.noarch			 0.5.3-1.el5		installed      

yum-security.noarch			 1.1.10-6.el5		installed      

yum-updatesd.noarch			 1:0.9-2.el5		installed      

yum-utils.noarch			 1.1.10-6.el5		installed

This is the output of you cmd line client:

import: unable to open module file
`/usr/lib/ImageMagick-6.2.8/modules-Q16/coders/glib.la': No such file or directory.
/home/cmeadors/Desktop/attachment.cgi: line 7: syntax error near unexpected
token `('
/home/cmeadors/Desktop/attachment.cgi: line 7: `bus = dbus.SystemBus()'

and output from 'yum list installed rpm yum\*':

rpm.i386                                 4.4.2-48.el5           installed       
yum.noarch                               3.2.8-7.el5            installed       
yum-aliases.noarch                       1.1.10-6.el5           installed       
yum-basearchonly.noarch                  1.1.10-6.el5           installed       
yum-changelog.noarch                     1.1.10-6.el5           installed       
yum-downloadonly.noarch                  1.1.10-6.el5           installed       
yum-filter-data.noarch                   1.1.10-6.el5           installed       
yum-kmod.noarch                          1.1.10-6.el5           installed       
yum-list-data.noarch                     1.1.10-6.el5           installed       
yum-metadata-parser.i386                 1.1.2-2.el5            installed       
yum-protect-packages.noarch              1.1.10-6.el5           installed       
yum-protectbase.noarch                   1.1.10-6.el5           installed       
yum-rhn-plugin.noarch                    0.5.3-1.el5            installed       
yum-security.noarch                      1.1.10-6.el5           installed       
yum-skip-broken.noarch                   1.1.10-6.el5           installed       
yum-updateonboot.noarch                  1.1.10-6.el5           installed       
yum-updatesd.noarch                      1:0.9-2.el5            installed       
yum-utils.noarch                         1.1.10-6.el5           installed       
yum-versionlock.noarch                   1.1.10-6.el5           installed       

I truly don't understand this error.  Pirut works fine.  I have ImageMagick
installed, but it did not change when this behaviour showed up.  I have removed
all unnecessary extra packages to see if my system is tainted.  I will try to
reproduce on a clean system.

Just to make things more interesting, when I start your cmd line client I get an
ImageMagick cursor.

Cameron,
What's the first two lines of the script which you saved from james' attachment?

First 5 lines:

#! /usr/bin/python -tt

import sys
import dbus
import dbus.glib


I tested on a different machine.  Same results on a clean install with updates.
 I did notice that I can get two different errors depending on how I execute the
file.

$ sh updatesd-cntl.py 

doesn't return and I see a different cursor.  Obviously the wrong way to execute
a python script now that I turn my brain on.  Yet interesting unexpected results.

$ python updatesd-cntl.py 
Traceback (most recent call last):
  File "updatesd-cntl.py", line 29, in ?
    elif sys.argv[1].lower().replace('-', '') == "getupdateinfo":
IndexError: list index out of range

Probably more useful. Sorry about the garbage.

"""sh updatesd-cntl.py """

...Ok that's running the python as sh, and isn't going to work.

"""python updatesd-cntl.py """
 
..that's working, then, just pass "get-update-info" as a parameter.

$ python updatesd-cntl.py get-update-info
New: {u'name': u'gd', u'arch': u'i386', u'summary': u'A graphics library for
quick creation of PNG or JPEG images\n', u'epoch': u'0', u'version': u'2.0.33',
u'release': u'9.4.el5_1.1', u'sourcerpm': u'gd-2.0.33-9.4.el5_1.1.src.rpm',
u'type': u'security'}
Old: {u'name': u'gd', u'arch': u'i386', u'summary': u'A graphics library for
quick creation of PNG or JPEG images\n', u'epoch': u'0', u'version': u'2.0.33',
u'release': u'9.4.el5_1.1', u'sourcerpm': u'gd-2.0.33-9.4.el5_1.1.src.rpm',
u'type': u'security'}

Count: 1

 Ok, so dbus is working. Does puplet still show an exception?
 Can you paste all of the stdout/stderr from when you run puplet?

$ puplet 
Exception exceptions.NameError: "global name 't' is not defined" in
'dbus_bindings._GIL_safe_cmessage_function_handler' ignored

Created attachment 297140 [details]
Fix for translations in puplet

 Ok, this should fix it ... if you can apply this to /usr/bin/puplet and test
that'd be great.

patch applied.  The exception is gone. Still no puplet icon.  you cmd line tool
says:

$ python updatesd-cntl.py get-update-info
New: {u'name': u'cpuspeed', u'summary': u'CPU frequency adjusting daemon',
u'epoch': u'1', u'version': u'1.2.1', u'release': u'3.el5', u'sourcerpm':
u'cpuspeed-1.2.1-3.el5.src.rpm', u'arch': u'i386'}
Old: {u'name': u'cpuspeed', u'summary': u'CPU frequency adjusting daemon',
u'epoch': u'1', u'version': u'1.2.1', u'release': u'3.el5', u'sourcerpm':
u'cpuspeed-1.2.1-3.el5.src.rpm', u'arch': u'i386'}

Count: 1


Do I need to restart anything?  Clear any cache?  Just to be clear, is puplet
configured to always be shown, or only show when there are updates?

It took awhile after I restarted puplet, but it finally showed up.  Can you
explain the long delay?  I thought puplet sent a dbus message when it started to
ask if there were updates.  When I restarted it, there were definitely updates.  

 Ok, so what happens is that puplet sends a message saying "please check if
there are updates" ... and when yum-updatesd checks it sends a message back
saying "there are updates". However yum-updatesd limits the amount of time
between updates to "updaterefresh" time (default is 10 minutes).
 puplet should probably just ask for a list of updates when it starts, and if
that is none then ask for a refresh.

 On various older versions yum-updatesd just ignored the updatesrefresh option,
so as we fixed that the delay has fallen out.

 I assume the delay didn't seem much longer than 10 minutes?

No, the delay wasn't much longer that 10 minutes (I was not paying enough
attention to tell you exactly how long).  It would be nice to have it work as
you have suggested, but 10 minutes is an acceptable delay.

BTW, I did restart yum-updatesd before I restarted puplet and confirmed there
were updates with you cmd line tool.  Does that still jive with how it is
supposed to work?

 Yeh, it explains it exactly ... when you restarted yum-updatesd it would do an
updates check ... and so then refuse to do another for 10 minutes if puplet
missed that first one.

Ok.  In that case. I would say your fix is good.

Just a note but the typical pattern for requesting lists which can be updated
over  D-Bus is to register a signal listener for the update signals and then
request the current list.  The service would then return whatever it had in its
cache and then  update its own list and send update signals on the diff between
the two list.  Not sure if this is applicable to yum-updatesd but just thought I
would share.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0388.html