Hello,
Looking back through the archives I noted a thread: "Fedora and RHN"
where Barry Nathan recommended ermptying the /var/spool/up2date
directory. Apparently, someone else had the same problem with a
different repository. I tried Barry's suggestion and it worked to get
my up2date working without error (Thanks Barry!).
I've used up2date for a long time and have never had this problem before
and would like to know if this is due to the fragility of the yum
repository, the yum client code, or something else? Is this
something that we should expect to have to do from time to time?
Barry noted that there was a bugzilla bug concerning this. The up2date
GUI freezes when this happens but it doesn't seem that the underlying
problem, the error creating the traceback, is being addressed:
Traceback (most recent call last):
File "/usr/sbin/up2date", line 1188, in ?
sys.exit(main() or 0)
File "/usr/sbin/up2date", line 766, in main
fullUpdate, dryRun=options.dry_run))
File "/usr/sbin/up2date", line 1051, in batchRun
batch.run()
File "up2dateBatch.py", line 58, in run
File "up2dateBatch.py", line 96, in __findPackagesToUpdate
File "packageList.py", line 123, in run
File "rhnPackageInfo.py", line 404, in obsoletesList
File "rpcServer.py", line 110, in doCall
File "repoDirector.py", line 27, in getObsoletes
File "rpmSource.py", line 249, in getObsoletes
File "/usr/share/rhn/up2date_client/repoBackends/yumRepo.py", line
311, in getObsoletes
baseFileName = "%s-%s-%s.%s.hdr" % (pkg[0], pkg[1], pkg[2], pkg[4])
IndexError: list index out of range
I saved the files that were in /var/spool/up2date and it's clear they
were causing the problem. I can make them available to a developer who
may think them worth looking at if it will help to determine why
up2date blew up in the first place.
Regards, Mike Klinke
