Bug 435474 - puplet never appears in notification tray
puplet never appears in notification tray
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pirut (Show other bugs)
5.2
All Linux
high Severity urgent
: rc
: ---
Assigned To: James Antill
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-29 11:10 EST by Cameron Meadors
Modified: 2013-01-10 05:22 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2008-0388
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 10:22:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
simple cmd line yum-updatesd controller (1006 bytes, text/plain)
2008-03-03 23:25 EST, James Antill
no flags Details
Fix for translations in puplet (875 bytes, patch)
2008-03-07 00:51 EST, James Antill
no flags Details | Diff

  None (edit)
Description Cameron Meadors 2008-02-29 11:10:29 EST
Description of problem:
puplet never appears in the notification tray.  'yum check-update' shows
updates.  when I run puplet from the command like I see

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

but it does not exit.

Version-Release number of selected component (if applicable):
pirut-1.3.28-10.el5

How reproducible:
everytime

Steps to Reproduce:
1. Login
2. observe the lack on puplet icon
3.
  
Actual results:
no puplet icon in notification tray

Expected results:
puplet icon in tray showing status of updates

Additional info:

I am testing on a 5.2 beta build client 20080225.0
Comment 1 James Antill 2008-02-29 12:25:22 EST
 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?
Comment 2 Cameron Meadors 2008-02-29 13:24:58 EST
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.
Comment 4 John (J5) Palmieri 2008-03-03 17:46:30 EST
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.
Comment 5 James Antill 2008-03-03 18:56:43 EST
 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?
Comment 6 John (J5) Palmieri 2008-03-03 19:21:37 EST
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. 
Comment 7 John (J5) Palmieri 2008-03-03 19:34:27 EST
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'.  
Comment 8 James Antill 2008-03-03 23:25:50 EST
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
Comment 9 Cameron Meadors 2008-03-04 08:35:35 EST
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       
Comment 11 Cameron Meadors 2008-03-04 11:28:29 EST
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.
Comment 12 Cameron Meadors 2008-03-04 11:42:37 EST
Just to make things more interesting, when I start your cmd line client I get an
ImageMagick cursor.
Comment 13 Seth Vidal 2008-03-04 13:53:58 EST
Cameron,
What's the first two lines of the script which you saved from james' attachment?


Comment 14 Cameron Meadors 2008-03-04 15:41:56 EST
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.
Comment 15 James Antill 2008-03-04 16:10:21 EST
"""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.
Comment 16 Cameron Meadors 2008-03-04 16:47:32 EST
$ 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
Comment 17 James Antill 2008-03-04 17:43:07 EST
 Ok, so dbus is working. Does puplet still show an exception?
 Can you paste all of the stdout/stderr from when you run puplet?
Comment 18 Cameron Meadors 2008-03-05 14:52:55 EST
$ puplet 
Exception exceptions.NameError: "global name 't' is not defined" in
'dbus_bindings._GIL_safe_cmessage_function_handler' ignored
Comment 19 James Antill 2008-03-07 00:51:14 EST
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.
Comment 20 Cameron Meadors 2008-03-10 09:21:51 EDT
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?
Comment 21 Cameron Meadors 2008-03-10 10:45:09 EDT
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.  
Comment 22 James Antill 2008-03-10 11:11:05 EDT
 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?
Comment 23 Cameron Meadors 2008-03-10 11:27:09 EDT
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?
Comment 24 James Antill 2008-03-10 11:35:10 EDT
 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.
Comment 25 Cameron Meadors 2008-03-10 11:57:43 EDT
Ok.  In that case. I would say your fix is good.
Comment 26 John (J5) Palmieri 2008-03-10 11:58:58 EDT
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.
Comment 32 errata-xmlrpc 2008-05-21 10:22:16 EDT
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

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