When trying to install an update I got could not do simulate: Traceback (most recent call last): File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2120, in _update_packages txmbr = self.yumbase.update(po=pkg) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3326, in update updated_pkg = self.getInstalledPackageObject(updated) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 2610, in getInstalledPackageObject raise Errors.RpmDBError, _('Package tuple $s could not be found in rpmdb') $ str(pkgtup) RpmDBError: Package tuple ('exo', 'i686', '0', '0.3.106', '2.fc13') could not be found in rpmdb I would expect PackageKit to handle it some other and more user friendly way than showing the backtrace. The content of the yum exception content do however also not seem to be suitable for displaying to a user. :-( PackageKit-0.6.4-1.fc13.i686 gnome-packagekit-2.30.1-1.fc13.i686 yum-3.2.27-4.fc13.noarch
It seems like exo was successfully updated anyway: May 25 10:24:08 localhost yum: Updated: exo-0.3.106-3.fc13.i686 The update was successful, only leaving bug 579748.
This bug has been triaged -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'll re-assign and ask the yum guys what's going on. Feel free to reassign back to PK if it's my problem.
Mads, What version of yum is that? Did you modify the traceback output you pasted in? B/c you have: getInstalledPackageObject raise Errors.RpmDBError, _('Package tuple $s could not be found in rpmdb') in the output - but $s doesn't exist in the yum pkgs I can find - only raise Errors.RpmDBError, _('Package tuple %s could not be found in rpmdb') % str(pkgtup) and RpmDBError is just a sub of YumBaseError so - it should be catchable just the same for PackageKit. What exceptions are you catching in yumbackend when you go to update, Richard?
Mads, what yum plugins do you have?
(In reply to comment #4) > Mads, > What version of yum is that? It was yum-3.2.27-4.fc13.noarch > Did you modify the traceback output you pasted in? No I did not modify the traceback. Perhaps PK modified it to be extra sure no spurious printf expansion is done? Yes, an abrt report would have been more reliable than me cut'n'pasting ;-) (In reply to comment #5) > Mads, what yum plugins do you have? Loaded plugins: auto-update-debuginfo, fastestmirror, merge-conf, presto, refresh-packagekit, remove-with-leaves Requesting info from rhughes to answer seths question.
(In reply to comment #4) > What exceptions are you catching in yumbackend when you go to update, Richard? Just exceptions.IOError -- but RpmDBError exception should not be generated surely as yum has just queried the rpmdb for the update list surely?
I'm not sure where "package_ids" is coming from in PK but I wonder if something is going wrong there (is this from a client? -- so could it be a bad cache of data clientside?), or maybe _findPackage() (side note: wow to that function). If you can reproduce it, it'd probably be helpful to know of the PK pkgid says it's repo is "installed" or not. Dito. what the po.repoid is after _findPackage(). And the installed/available versions of the package. From what I can see on the yum side the pkg you are passing in to yb.update() is the latest available pkg, which is then doing the reverse lookup for what it updates ... it then gets a pkgtup and then looks that up in the rpmdb, but that pkgtup doesn't exist in the rpmdb. I'm not sure how self.up.updating_dict can contain pkgtups which aren't in the rpmdb, so that seems like a yum bug ... but it also seems like one which would hit us all the time.
So a theory of the interaction: 1. user runs PK- it generates the updates list and hold onto this data - it doesn't require locking anything b/c nothing is happening, really. 2. user goes to a prompt and runs 'yum update foo' or 'yum install bar' which modifies the rpmdb 3. user then goes back to the PK box and says 'update' (or whatever) and PK then tries to use the info it has in state. For the original reporter: does that process ring any bells to you? Does it seem possible that is what happened?
(In reply to comment #9) > So a theory of the interaction: > 1. user runs PK- it generates the updates list and hold onto this data - it > doesn't require locking anything b/c nothing is happening, really. > 2. user goes to a prompt and runs 'yum update foo' or 'yum install bar' which > modifies the rpmdb > 3. user then goes back to the PK box and says 'update' (or whatever) and PK > then tries to use the info it has in state. > > For the original reporter: does that process ring any bells to you? Does it > seem possible that is what happened? If "1. user runs PK" happens automatically when the user logs in (and an alert might appear) "2. user goes to a prompt" thus discusses _any_ direct use of yum "3. user goes back to PK box" means that the user clicks the alert icon - then it sounds like a plausible explanation. I still haven't figured out where PackageKit stores its state, how to see it and how to control it. But it seems like stores something (besides what it can get from rpm and yum). That can get of of sync, and then the user has no idea what is going on can't do anything.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.