Bug 161071

I now believe the issue with rhn-applet is due to bug #160873

Check this file:

/usr/share/rhn/up2date_client/sourcesConfig.py

lines 161-162:

        #FIXME:
        releasever = "3"

Change "3" into "4" and up2date works again. Had the same problem with
the livna repository.

Removing those two lines did it for me.

releasever is assigned the result of a method call right before, and the method
name is up2dateUtils.getVersion() :-)

I found that the file

"/usr/share/rhn/up2date_client/sourcesConfig.py"

has the WRONG release version in line #162

Change the "3" to a "4" and things work much better.

Have/had the same problem. Before changing anything in the source, it fetched
packetlists from /4/, but always looked in /3/ for obsoletes.

baseurl I use in fedora.repo (instead of the mirrorlist-url):

baseurl=ftp://internal/mirrors/fedora/core/$releasever/$basearch/os/


Changing the line mentioned above seemed to help. But now it reports that:

rpm was unable to load a header
initRepo
bytes=440-18648
An error has occurred:
exceptions.IndexError
See /var/log/up2date for more information

Where it reports:

[Mon Jul 11 19:10:37 2005] up2date   File "/usr/sbin/up2date", line 1265, in ?
    sys.exit(main() or 0)
   File "/usr/sbin/up2date", line 800, in main
    fullUpdate, dryRun=options.dry_run))
   File "/usr/sbin/up2date", line 1137, in batchRun
    batch.run()
   File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 78, in run
    self.__dryRun()
   File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 163, in __dryRun
    self.percentCallback)
   File "/usr/share/rhn/up2date_client/up2date.py", line 386, in dryRun
    ret = depsolve.solvedep()
   File "/usr/share/rhn/up2date_client/depSolver.py", line 722, in solvedep
    ret = self.process_deps(deps)
   File "/usr/share/rhn/up2date_client/depSolver.py", line 616, in process_deps
    changed = self.__dependencies(dependencies)
   File "/usr/share/rhn/up2date_client/depSolver.py", line 383, in __dependencies
    added = self.__add(solved, check = 1)
   File "/usr/share/rhn/up2date_client/depSolver.py", line 221, in __add
    hdr = headerList[p]
   File "/usr/share/rhn/up2date_client/headers.py", line 37, in __getitem__
    self.__retrievePackage(item)
   File "/usr/share/rhn/up2date_client/headers.py", line 42, in __retrievePackage
    hdr, sourceType = rpcServer.doCall(self.repos.getHeader, item)
   File "/usr/share/rhn/up2date_client/rpcServer.py", line 316, in doCall
    ret = apply(method, args, kwargs)
   File "/usr/share/rhn/up2date_client/repoDirector.py", line 32, in getHeader
    return self.handlers[channel['type']].getHeader(pkg, msgCallback,
progressCallback)
   File "/usr/share/rhn/up2date_client/rpmSource.py", line 213, in getHeader
    header = source.getHeader(pkg, progressCallback = progressCallback)
   File "/usr/share/rhn/up2date_client/repoBackends/repomdRepo.py", line 242, in
getHeader
    hdr = rpm.readHeaderListFromFile(tmpfilename)[0]

Another workaround:
Place your baseurl into a simple file and use:

mirrorlist=file:///etc/mymirror/core

to point to that file in your /etc/yum.repos.d/fedora.repo

This way you don't have to patch the up2date-source. Or simply avoid using
$releasever in your fedora.repo, and use 4 instead :-)


But this still does not solve my above mentioned problem that up2date has an
"IndexError" (whatever that means in this case).

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

The problem appears to be in package "fedora-release"

It's version is 3-8.

It contains the /etc/fedora-release which contains the incorrect string:
"Fedora Core release 3 (Heidelberg)"

Both of these should show 4 not 3.

The former is used by the scripts which decide what release this is, hence the
problems described elsewhere in this bug report.

Re: Comment #8, the fedora-release package you're referring to is the one for
Fedora Core 3. The fedora-release package in FC4 is fedora-release-4-2 and it
contains the correct string:
"Fedora Core release 4 (Stentz)"

Comment #2 identifies the immediate reason for this problem (hardcoded version
number of 3 rather than 4 in up2date_client), but the underlying problem is that
up2date doesn't figure out the release version for itself correctly, hence the
need for the "FIXME" workaround of hardcoding it.

Sorry, may I retract my comment #8 - double checking the release, I appear to
have an old fedora-release rpm which seems to have caused the problem.

I would like to confirm that I was not using "up2date" when I updated this, and
the master respository fedora-release has the correct version.

An incorrect fedora-release rpm would cause the problem described.

To #9: Paul, I see that the FIXME-workaround is not ideal - but as mentioned in
#5 and #6 there seem to be other issues than that - at least here. Since up2date
itself is for version 4 - would it be possible to push out a release with 3->4
fixed in the source for a first step? But even when fixing that one thing by
hand, I still get the IndexError - and have no clue where that might come from :-(

Has anyone found a resolution to this problem? No matter what I do I still get 
the "exceptions.IndexError" message and Up2date quits. 

My e-mail address is ekaagan

Cheers,
eliot

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

The problem seems to be the fedora-release RPM not always updating on an 
upgrade of the system.  You should upgrade it manually if you have this 
problem.  (This can definitely occur if you upgraded from FC3 to FC4
via yum or apt.)

up2date is no longer shipped with Fedora Core; it's functionality 
has been replaced by pup, found in the pirut package.  The only fixes 
likely to be made to up2date in RedHat Linux and earlier Fedora Core 
versions are security fixes by Fedora Legacy.  This does not seem to 
be a security bug, so I'm closing it.

If the problem is appropriate to RHEL and occurs to a user there, it 
can be filed as such.

(In reply to comment #14)
> The problem seems to be the fedora-release RPM not always updating on an 
> upgrade of the system.  You should upgrade it manually if you have this 
> problem.  (This can definitely occur if you upgraded from FC3 to FC4
> via yum or apt.)

No, the problem is as described in Comment #2 that up2date has the release
number hardcoded into it instead of working it out properly for itself (e.g. by
checking the version of fedora-release).

> up2date is no longer shipped with Fedora Core; it's functionality 
> has been replaced by pup, found in the pirut package.  The only fixes 
> likely to be made to up2date in RedHat Linux and earlier Fedora Core 
> versions are security fixes by Fedora Legacy.  This does not seem to 
> be a security bug, so I'm closing it.

That's certainly true.

> If the problem is appropriate to RHEL and occurs to a user there, it 
> can be filed as such.

Fair enough.