Description of problem: After updating to PackageKit 0.5.7, all updates display the same orange icon. Before, I would see green for updates, bug icon for bugfixes, and red for security fixes. I've seen this on three systems running F12. All started happening on each system after the PK 0.5.7 update batch. Version-Release number of selected component (if applicable): gnome-packagekit-2.28.3-0.1.20091211git.fc12 PackageKit-0.5.7-1.fc12 How reproducible: Always Actual results: All updates have plain orange icon. Expected results: Specific icon per update should be showing.
If you've got some spare time, git bisect would be a great thing for you to do.
I went back to 0.5.6, but it also shows the same icon for all updates. I knew it was working back then. I refreshed my package caches and metadata. pkcon get-updates shows "Normal" for all updates. Multiple systems I use (all F12) plus a friend's (who is on F13) are showing "Normal". Did something with bodhi or the mirrors break? Doesn't bodhi provide the severity part of update metadata?
(In reply to comment #2) > Did something with bodhi or the mirrors break? Doesn't bodhi provide the > severity part of update metadata? Yes, it does. It might be a good idea to open up updateinfo.xml and check the data is correct.
(In reply to comment #3) > Yes, it does. It might be a good idea to open up updateinfo.xml and check the > data is correct. Opening up updateinfo.xml reveals update information. For example, the gdb-7.0.1-35.fc12 update: <update from="updates" status="stable" type="bugfix" version="1.4"><id>FEDORA-2010-4470</id><title>gdb-7.0.1-35.fc12... Or qt update: <update from="updates" status="stable" type="security" version="1.4"><id>FEDORA-2010-4518</id><title>qt-4.6.2-8.fc12... The update description and reference links are displayed properly but the severity icon is not. I apparently didn't clear enough cached information yesterday as I can easily reproduce the issue now between 0.5.7 (incorrect icons) and 0.5.6 (correct icons). I reran my bisect and I lost icons after the first bisect step. $ git bisect log git bisect start # bad: [ce464e69911bab704c4347c9777cb04a361c290d] Release version 0.5.7 git bisect bad ce464e69911bab704c4347c9777cb04a361c290d # good: [66bec12f805d7c99b9ceda476fa9775ba1352ac8] Release version 0.5.6 git bisect good 66bec12f805d7c99b9ceda476fa9775ba1352ac8 # good: [9120e8d5790d658e5151631eb3e2ce8feb3534dc] yum: Ensure we look in all update notices for a security update. Fixes rh#526279 git bisect good 9120e8d5790d658e5151631eb3e2ce8feb3534dc # bad: [975e8cc9d7f59eafe0a67d7c6ff9e154db3bcc30] trivial: fix some of the fallout from backporting patches from master git bisect bad 975e8cc9d7f59eafe0a67d7c6ff9e154db3bcc30 Commit 9120e8d5790d658e5151631eb3e2ce8feb3534dc would not compile so I skipped it and after compiling 975e8cc9d7f59eafe0a67d7c6ff9e154db3bcc30 my icons broke. I verified it by reinstalling 0.5.6 and refreshing my cache, updates came back. Went back to the bad bisect and icons broke. I don't have to refresh my cache after upgrading to the bad version to see the wrong severity reported.
I upgraded to F13 and it's the same way. Makes sense since the commit I bisected mentioned you backported 0.6.x code into the 0.5.x branch.
Created attachment 404647 [details] what was applied After a bit of testing, it seems that the yum function md.get_applicable_notices does not work and never seems to return any results. James, any hints? The patch we applied to PK is attached.
Michael, what ver of yum is this?
(In reply to comment #7) > Michael, > what ver of yum is this? yum-3.2.27-2.fc12.noarch and yum-3.2.27-2.fc13.noarch
So even though yum-plugin-security uses that API, it must be broken? From the yum code: def get_applicable_notices(self, pkgtup): """ Retrieve any update notices which are newer than a given std. pkgtup (name, arch, epoch, version, release) tuple. Returns: list of (pkgtup, notice) that are newer than the given pkgtup, in the order of newest pkgtups first. """ ...and looking at PK.get_updates() you are passing it the return value from self.yumbase.doPackageLists(pkgnarrow='updates') ... Eg. the _latest_ update. Unsurprisingly yum can't find any errata pertaining to packages newer than the latest available.
Okay, thanks, that makes more sense now. Is there a property/function to get the updated (the currently installed) package from the result of self.yumbase.doPackageLists(pkgnarrow='updates')? Or a better way to get the notices for installed..latest-in-repo? Thanks.
Check how i does it in yumex :) http://git.fedoraproject.org/git/?p=yumex.git;a=blob;f=src/yumexbackend/yum_server.py;h=a82ae59c0cb6ebec32c5cb7c579dc6ce8a57ef45;hb=ccc96336dd69046d3ecb609b57caec3b10ea59da Line 997 : (get_update_info)
Tim, doesn't that just show the last update info, not all the update infos that exist between the installed and available package?
Yeh, Time isn't calling applicable_notices in yumex but he is calling base.up.getUpdatesTuples() which is the easiest way currently to get the pkgtup's for the installed packages which have updates. The security plugin uses: def _get_name2oldpkgtup(base): oupdates = map(lambda x: x[1], base.up.getUpdatesTuples()) name2tup = {} for pkgtup in oupdates: # Get the latest "old" pkgtups if (pkgtup[0] in name2tup and _rpm_tup_vercmp(name2tup[pkgtup[0]], pkgtup) > 0): continue name2tup[pkgtup[0]] = pkgtup return name2tup ...and then for each package I use pkg.name as an index into the above. I'm not sure now why I do version comparison to get the latest installed tuple, it seems worthless even on RHEL-5, so building a dict based on base.up.getUpdatesTuples() is probably enough. Note that the security plugin currently doesn't process base.up.getObsoletesTuples(), on my assumption that nobody would be insane enough to do a security update via. an obsoletes ... that's probably a minor bug.
*** Bug 572915 has been marked as a duplicate of this bug. ***
Created attachment 406491 [details] the fixed patch This is what I've applied to git master, and seems to fix the bug for me.
Created attachment 406511 [details] pk 0.5 branch version Richard, this is a patch for your 0.5.x branch. It is better, as some updates display "Bugfix" and the bug icon, but some updates still show "Normal" for severity when the updateinfo.xml file shows "Bugfix". Bug fix glibc-2.11.1-4.i686 The GNU libc libraries Normal imsettings-libs-0.108.0-1.fc12.x86_64 Libraries for imsettings
*** Bug 582523 has been marked as a duplicate of this bug. ***
Richard, this bug is not 100% fixed (per comment 16). Is it no longer going to be investigated?
(In reply to comment #18) > Richard, this bug is not 100% fixed (per comment 16). Is it no longer going to > be investigated? Isn't 0.5.x for F12, not F13?
(In reply to comment #19) > > Isn't 0.5.x for F12, not F13? My fault for not updating the bug. I still see the occasional update flagged with a normal severity under F13 (0.6.x). $ pkcon get-updates Getting updates [=========================] Normal eject-2.1.5-19.fc13.x86_64 A program that ejects removable media using software control Security libtiff-3.9.4-1.fc13.x86_64 Library of functions for manipulating TIFF format image files Security libtiff-3.9.4-1.fc13.i686 Library of functions for manipulating TIFF format image files updateinfo.xml: <update from="updates" status="stable" type="bugfix" version="1.4"><id>FEDORA-2010-10826</id><title>eject-2.1.5-19.f c13</title><release>Fedora 13</release><issued date="2010-07-06 16:24:48"/>...
It is my belief that this bug has been resolved sometime in the F14 cycle. I have not seen the issue in F14 or F15.
This bug has popped back up. PackageKit-0.6.16-1.fc15.x86_64 I had 54 updates. All updates show Normal.
(In reply to comment #22) > This bug has popped back up. > > PackageKit-0.6.16-1.fc15.x86_64 > > I had 54 updates. All updates show Normal. Michael, if you install an older version of yum does it begin to work? Similarly, if you install older versions of PackageKit does it work? If so, this is an important regression. I'll try to reproduce here on a VM. Richard.
Unfortunately it is hard to reproduce. With today's updates they all show up with the correct severity. I've tried yum-3.2.29-7.fc15.noarch and yum-3.2.29-8.fc15.noarch but it made no difference.
My system currently has "Normal" updates listed. Is there any logging or testing that you would like me to try? I have normal yum and rpm packages installed (from updates). PackageKit-0.6.17-1.fc15.x86_64 rpm-4.9.1.1-1.fc15.x86_64 yum-3.2.29-9.fc15.noarch $ pkcon get-updates Getting updates [=========================] Starting [=========================] Getting information [=========================] Normal gstreamer-rtsp-0.10.8-1.fc15.x86_64 GStreamer RTSP server library Security kernel-2.6.40.3-0.fc15.x86_64 The Linux kernel Security kernel-devel-2.6.40.3-0.fc15.x86_64 Development package for building kernel modules to match the kernel Security kernel-headers-2.6.40.3-0.fc15.x86_64 Header files for the Linux kernel for use by glibc Normal lohit-devanagari-fonts-2.4.5-4.fc15.noarch Free Devanagari Script Font Normal lohit-telugu-fonts-2.4.5-14.fc15.noarch Free Telugu font Security perf-2.6.40.3-0.fc15.x86_64 Performance monitoring for the Linux kernel Normal traceroute-3:2.0.18-1.fc15.x86_64 Traces the route taken by packets over an IPv4/IPv6 network
When I checked for updates today it lists more updates and they all show up correctly now. Even the ones that previously showed as Normal. I have not performed any updates since my last comment.
Still seeing this on F16. Updates have been displaying fine until today. gpk shows 24 updates. All of them are listed under "Other updates" and no detail text displays for any update. $ rpm -q PackageKit gnome-packagekit PackageKit-0.6.20-1.fc16.x86_64 gnome-packagekit-3.2.1-1.fc16.x86_64
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. 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 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.