GNOME Bugzilla – Bug 739666
doesn't show updates when there are updates
Last modified: 2016-05-28 15:49:22 UTC
Yesterday I got a notification for system updates. Today I clicked View on the notification but once Software loaded it said "Software is up to date" (but the timestamp indicated it was only checked yesterday morning). So just now I pressed the reload button and then it loaded for a while and then I got another notification and then the list of updates filled in. It may be related to the fact that I did a yum install ffmpeg yesterday evening. Obviously the most desirable behavior is that Software shows me the list of updates available without me having to wait for a manual reload.
aday kalev: you got a view on bug 739666 ? it's fairly serious if it's valid Services Bug http://bugzilla.gnome.org/show_bug.cgi?id=739666 normal, Normal, ---, gnome-software-maint, UNCONFIRMED, doesn't show updates when there are updates kalev looks. kalev aday: we talked about this a bit on irc the other day aday: it can happen when installing something manually with yum aday: when we detect that something external has touched the package database, we reset the internal states that are then possibly out of date so what happened there was the there were available updates, then something got installed with yum, which reset the updates next day's check would show the updates again aday kalev: ah ok. still reasonably serious... is there a viable fix? kalev removing the update notification together with the internal state reset, I guess so that when this happens, we won't have the stale notification any more Marking as a target bug for GNOME 3.16.
Surely we also have to immediately start a new check for updates (and not issue a new notification when that check completes)? Otherwise the issue in comment #0 would still occur.
See also bug #741715
moving off target now
I just logged in, pulled up software update, and knowing that it routinely messes up and says that there is nothing to update, I asked it to recheck for updates. It came back again with no updates. Then (since I'm developing a deep distrust of software update), I did a CLI dnf update. There were 27 updates pending. Clearly, software update is broken. Its possible that it is configured out-of-the-box wrong. Is there anything that I can set to make it actually work, or should I just stop using it because it is too broken to fix? Example where software update has totally failed: [prodadm@production ~]$ sudo dnf update [sudo] password for prodadm: Fedora 22 - x86_64 - Updates 2.3 MB/s | 14 MB 00:06 Last metadata expiration check performed 0:00:14 ago on Sun Sep 13 09:55:47 2015. Dependencies resolved. ======================================================================= ========= Package Arch Version Repository Size ======================================================================= ========= Upgrading: epson-inkjet-printer-escpr x86_64 1.5.0-1.1lsb3.2.fc22 updates 2.0 M libxml2 i686 2.9.2-4.fc22 updates 684 k libxml2 x86_64 2.9.2-4.fc22 updates 677 k libxml2-devel x86_64 2.9.2-4.fc22 updates 1.1 M libxml2-python x86_64 2.9.2-4.fc22 updates 248 k mesa-dri-drivers i686 10.6.3-2.20150729.fc22 updates 8.5 M mesa-dri-drivers x86_64 10.6.3-2.20150729.fc22 updates 8.2 M mesa-filesystem i686 10.6.3-2.20150729.fc22 updates 35 k mesa-filesystem x86_64 10.6.3-2.20150729.fc22 updates 35 k mesa-libEGL i686 10.6.3-2.20150729.fc22 updates 97 k mesa-libEGL x86_64 10.6.3-2.20150729.fc22 updates 96 k mesa-libEGL-devel i686 10.6.3-2.20150729.fc22 updates 40 k mesa-libEGL-devel x86_64 10.6.3-2.20150729.fc22 updates 40 k mesa-libGL i686 10.6.3-2.20150729.fc22 updates 213 k mesa-libGL x86_64 10.6.3-2.20150729.fc22 updates 191 k mesa-libGL-devel x86_64 10.6.3-2.20150729.fc22 updates 160 k mesa-libGLES x86_64 10.6.3-2.20150729.fc22 updates 41 k mesa-libOSMesa i686 10.6.3-2.20150729.fc22 updates 1.3 M mesa-libOSMesa x86_64 10.6.3-2.20150729.fc22 updates 1.2 M mesa-libgbm i686 10.6.3-2.20150729.fc22 updates 55 k mesa-libgbm x86_64 10.6.3-2.20150729.fc22 updates 55 k mesa-libgbm-devel x86_64 10.6.3-2.20150729.fc22 updates 28 k mesa-libglapi i686 10.6.3-2.20150729.fc22 updates 70 k mesa-libglapi x86_64 10.6.3-2.20150729.fc22 updates 52 k mesa-libwayland-egl x86_64 10.6.3-2.20150729.fc22 updates 37 k mesa-libwayland-egl-devel x86_64 10.6.3-2.20150729.fc22 updates 25 k mesa-libxatracker x86_64 10.6.3-2.20150729.fc22 updates 1.2 M Transaction Summary ======================================================================= ========= Upgrade 27 Packages Total download size: 26 M Is this ok [y/N]:
What does "pkcon get-updates" say?
There are a large set of new updates today. pkcon get-updates reports nothing to update, but dnf reports a large list. Is that where the fault lies? [prodadm@production ~]$ pkcon -c -1 -v get-updates 20:21:47 PackageKit Verbose debugging enabled (on console 1) 20:21:47 PackageKit filter=(null), filters=0 20:21:48 PackageKit adding state 0x5582864ff0d0 20:21:48 PackageKit role now get-updates Getting updates [=========================] :21:48 P Waiting in queue [=========================] Starting [=========================] Finished [=========================] :22:01 P There are no updates available at this time.d0 [prodadm@production ~]$ sudo dnf update [sudo] password for john: RPM Fusion for Fedora 22 - Free - Updates 444 kB/s | 73 kB 00:00 Adobe Systems Incorporated 11 kB/s | 1.8 kB 00:00 RPM Fusion for Fedora 22 - Nonfree - Updates 219 kB/s | 28 kB 00:00 RPM Fusion for Fedora 22 - Free 1.0 MB/s | 551 kB 00:00 Fedora 22 - x86_64 - Updates 1.8 MB/s | 14 MB 00:08 RPM Fusion for Fedora 22 - Nonfree 831 kB/s | 170 kB 00:00 Last metadata expiration check performed 0:00:00 ago on Tue Sep 15 20:22:55 2015. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: fluidsynth x86_64 1.1.6-5.fc22 fedora 29 k fluidsynth-libs x86_64 1.1.6-5.fc22 fedora 234 k lash x86_64 0.5.4-21.fc22 fedora 158 k Upgrading: SDL_mixer x86_64 1.2.12-10.fc22 updates 97 k libinput x86_64 1.0.1-2.fc22 updates 90 k libinput-devel x86_64 1.0.1-2.fc22 updates 31 k mesa-dri-drivers i686 10.6.3-3.20150729.fc22 updates 8.5 M mesa-dri-drivers x86_64 10.6.3-3.20150729.fc22 updates 8.2 M mesa-filesystem i686 10.6.3-3.20150729.fc22 updates 35 k mesa-filesystem x86_64 10.6.3-3.20150729.fc22 updates 35 k mesa-libEGL i686 10.6.3-3.20150729.fc22 updates 98 k mesa-libEGL x86_64 10.6.3-3.20150729.fc22 updates 96 k mesa-libEGL-devel i686 10.6.3-3.20150729.fc22 updates 40 k mesa-libEGL-devel x86_64 10.6.3-3.20150729.fc22 updates 40 k mesa-libGL i686 10.6.3-3.20150729.fc22 updates 213 k mesa-libGL x86_64 10.6.3-3.20150729.fc22 updates 191 k mesa-libGL-devel x86_64 10.6.3-3.20150729.fc22 updates 160 k mesa-libGLES x86_64 10.6.3-3.20150729.fc22 updates 41 k mesa-libOSMesa i686 10.6.3-3.20150729.fc22 updates 1.3 M mesa-libOSMesa x86_64 10.6.3-3.20150729.fc22 updates 1.2 M mesa-libgbm i686 10.6.3-3.20150729.fc22 updates 55 k mesa-libgbm x86_64 10.6.3-3.20150729.fc22 updates 55 k mesa-libgbm-devel x86_64 10.6.3-3.20150729.fc22 updates 28 k mesa-libglapi i686 10.6.3-3.20150729.fc22 updates 70 k mesa-libglapi x86_64 10.6.3-3.20150729.fc22 updates 52 k mesa-libwayland-egl x86_64 10.6.3-3.20150729.fc22 updates 37 k mesa-libwayland-egl-devel x86_64 10.6.3-3.20150729.fc22 updates 25 k mesa-libxatracker x86_64 10.6.3-3.20150729.fc22 updates 1.2 M openssh x86_64 6.9p1-7.fc22 updates 445 k openssh-askpass x86_64 6.9p1-7.fc22 updates 78 k openssh-clients x86_64 6.9p1-7.fc22 updates 645 k openssh-server x86_64 6.9p1-7.fc22 updates 468 k perl-Text-Unidecode noarch 1.24-1.fc22 updates 142 k perl-Thread-Queue noarch 3.06-1.fc22 updates 22 k php-cli x86_64 5.6.13-1.fc22 updates 4.0 M php-common x86_64 5.6.13-1.fc22 updates 1.1 M php-gd x86_64 5.6.13-1.fc22 updates 97 k php-pdo x86_64 5.6.13-1.fc22 updates 150 k php-process x86_64 5.6.13-1.fc22 updates 87 k php-xml x86_64 5.6.13-1.fc22 updates 258 k ruby x86_64 2.2.3-44.fc22 updates 74 k ruby-irb noarch 2.2.3-44.fc22 updates 93 k ruby-libs x86_64 2.2.3-44.fc22 updates 2.9 M rubygem-bigdecimal x86_64 1.2.6-44.fc22 updates 86 k rubygem-io-console x86_64 0.4.3-44.fc22 updates 56 k rubygem-psych x86_64 2.0.8-44.fc22 updates 85 k rubygem-rdoc noarch 4.2.0-44.fc22 updates 481 k Transaction Summary ================================================================================ Install 3 Packages Upgrade 44 Packages Total download size: 33 M Is this ok [y/N]:
Suggest closing this ticket. I am convinced that the real issue is the difference in the repo sync between yum/dnf and pkcon. Offline email thread at users@lists.fedoraproject.org: ========== From: Gordon Messmer <gordon.messmer@gmail.com> Reply-to: Community support for Fedora users <users@lists.fedoraproject.org> To: Community support for Fedora users <users@lists.fedoraproject.org> Subject: Re: What is broken with software update? Date: Sun, 13 Sep 2015 18:36:47 -0700 (09/13/2015 09:36:47 PM) Mailer: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 On 09/13/2015 07:07 AM, John Mellor wrote: > Then (since I'm developing a deep distrust of software update), I did a > CLI dnf update. There were 27 updates pending. Clearly, software > update is broken. Nothing is clearly broken. yum/dnf repositories are not synchronized. No mechanism nor mandate exists for keeping them in sync. This has been discussed to death on this list, but no example has been provided that can't be explained simply as "dnf checked a repository with older data and then, later, checked a different repository with data that is more up to date." ========== From: John Mellor <john.mellor@gmail.com> To: Community support for Fedora users <users@lists.fedoraproject.org> Subject: Re: What is broken with software update? Date: Tue, 15 Sep 2015 21:44:39 -0400 Mailer: Evolution 3.16.5 (3.16.5-1.fc22) Ok, its remotely possible. My recalled experience has been that the Gnome updater is not finding even 5-day-old updates, but assuming that some weird preferred repo out there is totally broken, I'm willing to test that thesis. I checked the dnf log and dnf is configured to select some indeterminate Fedora mirrors site. I'm willing to bet that the unselected mirrors are no more than a couple of hours out-of-date at worst, and there is actually a software error at work here. So, how to I preconfigure my system to get the two updaters to select the same repo? ========== From: Gordon Messmer <gordon.messmer@gmail.com> Reply-to: Community support for Fedora users <users@lists.fedoraproject.org> To: Community support for Fedora users <users@lists.fedoraproject.org> Subject: Re: What is broken with software update? Date: Wed, 16 Sep 2015 10:46:25 -0700 (09/16/2015 01:46:25 PM) Mailer: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 Pick a mirror for each of your enabled repositories, edit the files under /etc/yum.repos.d, disable metalink and enable baseurl with your preferred mirror. > P.S, just out of curiosity, why is the software updater not sharing the > same dnf and yum metadata backend that clearly works better? It does use the same backend. It keeps a separate copy of the metadata, though. Never was sure why; I thought that's what packagekitd was *for*. ========== From: John Mellor <john.mellor@gmail.com> To: Community support for Fedora users <users@lists.fedoraproject.org> Subject: Re: What is broken with software update? Date: Fri, 18 Sep 2015 20:33:39 -0400 Mailer: Evolution 3.16.5 (3.16.5-1.fc22) Interesting test. Forcing both to use the same repo results in the same data. The metadata separation problem seems to explain the observed issue nicely. ========== From: Richard Hughes <hughsient@gmail.com> Reply-to: Community support for Fedora users <users@lists.fedoraproject.org> To: Community support for Fedora users <users@lists.fedoraproject.org> Subject: Re: What is broken with software update? Date: Sat, 19 Sep 2015 09:33:24 +0100 (09/19/2015 04:33:24 AM) On 16 September 2015 at 18:46, Gordon Messmer <gordon.messmer@gmail.com> wrote: > Never was sure why; I thought that's what packagekitd was *for*. PackageKit needs to offer clients results with guaranteed latencies; it's no good if the command-not-found handler takes 700ms to return results, or gnome-software takes 15 seconds to show the first overview screen. This is why some of the fancier stuff was turned off with the yum backend. The problem with sharing a cache is that PackageKit downloads an entire set of repository files at the same time, all coherent to each other. It then atomically swaps the link in the cache so that at any time you can query PackageKit for results and get something sane in a small amount of time. What dnf does, and yum did, is download only the files that it needs. This is great for command line use where you might just want to check for updates, but means that we have metadata from different repositories with different ages, and most importantly different metadata files in the same repo with different ages (repo files reference each other internally). This means using dnf that you can do something like a search with no additional downloads, but when you come to install something it could be that half way through the depsolve it works out that the filelists isn't new enough and starts downloading a new metadata file, so it can re-depsolve and continue on to install. PackageKit can't do this, as we only promise network access during certain method calls, and we have strict latency requirements for some requests, where downloading at random points would shatter both promises. If PK and DNF could agree to download all metadata at a set time for all repositories and do an atomic switch that would be great, and we could certainly share a cache. Until then, it makes sense to have separate locations. What we can fix is downloading the same file twice in some cases, and in that case either squid helps, or CAShe can fix that in the longer term. Richard.