Re: Red Hat Network Alert Notification Tool FC4 Subscription Alert

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tony Nelson wrote:
At 7:08 AM +0100 7/11/05, Paul Howarth wrote:

On Sun, 2005-07-10 at 13:43 -0400, Tony Nelson wrote:

At 12:02 AM -0400 7/10/05, Terry Snyder wrote:

Ever since I upgraded to Fedora Core 4 from Fedora Core 3 my Red Hat
Network Alert Notification Tool has stopped working.  Everything I
click on the blue check mark it ask to Activate my Subscription.  I
click on Activate every time and I am still not notified when updates
are available.  Is there any way to fix this?
What Paul Howarth said.  No.  Basically, Up2Date has been updated to use a
new data format and no longer needs a "headers" directory on the server.
Unfortunately, rhn-applet-*'s have not been updated and still rely on that
"headers" directory, and it is always empty.
No so; rhn-applet *has* been updated to handle repomd style metadata,
it's just broken (perhaps we should say "an attempt to update it to use
repomd metadata" has been made?).

Hmm, OK.
Actually I'll take back what I said about rhn-applet having been updated 
to handle repomd style metadata. Yesterday I had a look at the code to 
see if I could figure out what was wrong with it (as best I could since 
I'm not a python programmer).
Whilst /usr/share/rhn/rhn_applet/rhn_sources.py parses the repomd entry 
in /etc/sysconfig/rhn/sources, that's about it as far as repomd handling 
goes.
The first thing that seems to go wrong is that an exception is thrown 
when trying to lnstantiate an object of class AppletSourcesConfigFile to 
parse the configuration file. The parent of this class is 
SourcesConfigFile from up2date 
(/usr/share/rhn/up2date_client/sourcesConfig.py), which tries to import 
"yumBaseRepo" from 
/usr/share/rhn/up2date_client/repoBackends/yumBaseRepo.py. This in turn 
tries to import "yum" (part of yum itself), which tries to import the 
following:
import rpmUtils
import rpmUtils.updates
import rpmUtils.arch

The exception is thrown when trying to import "rpmUtils.updates". I believe this is due to a namespace clash, as there is a rpmUtils.py file in /usr/share/rhn/up2date_client, whereas yum is looking for the /usr/lib/python2.4/site-packages/rpmUtils directory. This problem can be worked around by adding the three "import" lines above near the start of /usr/bin/rhn-applet-{gui,tui}.
The next thing that goes wrong is that initUp2dateConfig from 
/usr/share/rhn/up2date_client/config.py is called, and this falls over 
because regular users can't read /etc/sysconfig/rhn/up2date-uuid. 
Comments in the code suggest that the applet shouldn't even be trying to 
read this file, but I can't figure out that bit (yet). If the code is 
tweaked to ignore this error, the next problem appears when we arrive at
/usr/share/rhn/rhn_applet/rhn_applet_model.py to process the repo 
entries (the __build_sources method). This code understands sources of 
type "up2date" (not used in Fedora), "yum", and "apt" but not "repomd", 
so it bombs out.
That's as far as I got, and I'm giving up on it. Perhaps the tweak to 
import the rpmUtils modules early changed subsequent code paths so I'm 
missing something significant. I don't know; as I said I'm not a python 
programmer.
Both up2date and rhn-applet still use a "headers" directory if you
specify a "yum" repo (rather than repomd) in the rhn sources file.


I'm on FC3 and Up2Date works for me (though not for some people).  In my
opinion, until FC4 has a working Up2Date (or a replacement)
Isn't yum a replacement?

Oh.  Does FC4 yum notify users when there are updates to install, say, by
puting an icon in the top bar?
No. But you could run "yum check-update" to find out if there are any 
updates.
Paul.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]
  Powered by Linux