Description of problem: fails to notify user of new updates, and abruptly halts any user-ordered check for new updates, even when such updates exist. Version-Release number of selected component (if applicable): 0.9.1-6.fc21 How reproducible: Either start system 24 hours after running "yum update" (the only reliable way left to check for and install updates), run "Software Updater" in system tray, or run "check for new updates" option in apper. Steps to Reproduce: 1. Open apper. 2. Select "Updates." 3. Click "Check for updates" button. Or: 1. Click on "Software Updater" in system tray. 2. Click "Check for new updates." Actual results: Within a fraction of a second, apper abruptly stops checking for updates. Apper insists system is up to date. Running "yum update" in CLI typically will check for and install updates though apper never even knew those updates were available. Expected results: Apper should notice new updates at system startup, especially 24 hours or longer after the last update check. It does not. And when I ask it to check updates it should not quit the check before it even gets started. Additional info: I have only one workaround. I have had to abandon apper, start a Konsole instance, and run "sudo yum update" either on startup or just before shutdown or both, to keep my system up to date. This works, but why should I even keep apper around if it will not do this thing by itself? This has been going on for a week. It started one day before the "push" of the current version. The update of apper, which I accomplished with yum, did not solve the problem.
Instead of 'yum update', what does 'pkcon update' say?
Someone on irc confirmed this same issue and 'pkcon update' didn't work for them either, so let's bounce this over to PackageKit for now.
(In reply to Rex Dieter from comment #2) > Someone on irc confirmed this same issue and 'pkcon update' didn't work for > them either, so let's bounce this over to PackageKit for now. For the reference that was me.
The commend "pkcon update" simply says, "Finished. No packages require update." Now that might mean nothing at the moment, because I recently ran a yum update. But that command ran awfully quickly, as if it wasn't going to check a thing.
I'm seeing the same issue here (F21). I've traced the issue a little, and there seem to be two problems: - The errorCode function in /usr/share/kde4/apps/plasma/plasmoids/org.packagekit.updater/contents/ui/main.qml is invoked, but this fails because the "error" parameter is not declared. The following message appears in ~/.xsession-errors: plasma-desktop(1427) DeclarativeAppletScript::signalHandlerException: Exception caught: QVariant(QVariantMap, QMap(("expressionBeginOffset", QVariant(int, 134) ) ( "expressionCaretOffset" , QVariant(int, 139) ) ( "expressionEndOffset" , QVariant(int, 139) ) ( "fileName" , QVariant(QString, "file:///usr/share/kde4/apps/plasma/plasmoids/org.packagekit.updater/contents/ui/main.qml") ) ( "lineNumber" , QVariant(int, 120) ) ( "message" , QVariant(QString, "Can't find variable: error") ) ( "sourceId" , QVariant(int, -1720018160) ) ) ) - If this is fixed, we learn that the update fails because of an "unknown error".
I just verified: the command "pkcon update" does nothing. It starts, then it "finishes." It sees nothing to update. But yum update just updated thirty-nine packages. I tried it on two different computers. Same or similar results on both. Both run F21.
I just got "pkconf refresh" to take more than a second (i.e. to actually do something) by deleting /var/cache/PackageKit beforehand. So maybe there's a cache invalidation/cache age issue with PackageKit or the backend.
I think I've got an idea of what is going on. Since d90ecb799b7d9dd03175e0c42f83908dab50c4cd, the cache age in (some places in) Packagekit defaults to infinity (GUINT_MAX). But Apperd calls the refresh cache method without setting a cache age hint, so maybe this is why no update is triggered.
Also seeing this behavior, also no effect from pkconf. On last try this morning apper ran instantly (from KDE in Fedora 21), claimed system was up to date, and then YUM installed over 250 updates. Am running Fedora 21 with KDE on both a P7P55 MB based desktop and a Lenovo T420s laptop and both are showing identical issue. The first time I saw this behavior I noted that the package databases were empty in both /var/cache/yum and /var/cache/PackageKit. The yum databases have rebuilt themselves (I also ran Yum makecache at one point) but the /var/cache/PackageKit/metadata/fedora/packages - along with the other repository /package dirs under PackageKit, are still empty - don't know if that is normal one way or the other.
Hi, This looks definitely like a PackageKit issue. Only a 'pkcon refresh force' makes PackageKit find new updates. See also bug report [1] Martin Kho [1] https://bugzilla.redhat.com/show_bug.cgi?id=1193520
This morning (19 February 2015, at about 1025 UTC) I ran "sudo pkcon refresh force" and got an updates-available indication in my "systray." (I use KDE.) But when I then tried to run the update, it choked on this problem: one of the packages needed to be obsoleted (qma2, IIRC) and pkcon couldn't handle that. So I had to run the update with yum. Then I had to rerun "pkcon refresh force" to make the update indication go away. This might give a clue to the problem with pkcon. At the same time, it points out another flaw the program has long had. It cannot always handle every update scenario. Some common (though not "everyday") problems cause it to fail, often for days, if not weeks. Not all users will know to run "yum update" when this sort of thing happens.
Obsoletes used to just work with PackageKit-yum, this seems to be yet another regression from PackageKit-hif.
I am also experiencing this problem for at least the last 6 weeks or more. Has any progress been made toward a resolution?
*** Bug 1193520 has been marked as a duplicate of this bug. ***
I've marked my report as duplicate of this bug, the symptoms are exactly the same and it's definitely related to PackageKit.
Richard, any advice here? Should we follow the evidence in comment #8 and look into explicitly setting cache age somehow? (that won't help fix the 'pkcon update' simple case, however)
I've opened bug 1201938 for the "pkcon refresh" version of this problem. Until it is fixed, one needs to specify a reasonable cache age to make pkcon refresh do something, e.g. "pkcon -c 86400 refresh".
Something happened today that *seems like it might have fixed this*. I pulled the following updates using sudo yum update: sudo yum history list 11 Loaded plugins: langpacks ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 11 | update | 2015-03-14 12:48 | E, I, U | 31 EE Warning: RPMDB altered outside of yum. sudo yum history info 11 Loaded plugins: langpacks Transaction ID : 11 Begin time : Sat Mar 14 12:48:41 2015 Begin rpmdb : 1670:f9903bf8ac035ed04d2a7be1df90f2a00b9cb74a End time : 12:50:07 2015 (86 seconds) End rpmdb : 1671:53cc99bc59a338e1764e7b4143ad013ebe4e7d48 ** User : Jim <kd1yv3> Return-Code : Success Command Line : update Transaction performed with: Installed rpm-4.12.0.1-4.fc21.x86_64 @updates Installed yum-3.4.3-153.fc21.noarch @koji-override-0/$releasever Installed yum-metadata-parser-1.1.4-14.fc21.x86_64 @koji-override-0/$releasever Packages Altered: adobe-linux-x86_64 | 951 B 00:00:00 adobe-linux-x86_64/primary | 1.2 kB 00:00:00 adobe-linux-x86_64 2/2 Updated NetworkManager-openconnect-0.9.8.6-2.fc21.x86_64 ? Update 0.9.10.2-1.fc21.x86_64 @updates Updated NetworkManager-vpnc-1:0.9.9.0-6.git20140428.fc21.x86_64 @koji-override-0/$releasever Update 1:0.9.10.2-1.fc21.x86_64 @updates Updated appstream-data-21-19.fc21.noarch ? Update 21-20.fc21.noarch @updates Updated colord-1.2.9-1.fc21.x86_64 @updates Update 1.2.9-2.fc21.x86_64 @updates Updated colord-libs-1.2.9-1.fc21.x86_64 @updates Update 1.2.9-2.fc21.x86_64 @updates Updated cups-filters-1.0.58-1.fc21.x86_64 @koji-override-0/$releasever Update 1.0.66-1.fc21.x86_64 @updates Updated cups-filters-libs-1.0.58-1.fc21.x86_64 @koji-override-0/$releasever Update 1.0.66-1.fc21.x86_64 @updates Updated gnutls-3.3.12-1.fc21.x86_64 @updates Update 3.3.13-1.fc21.x86_64 @updates Erase kernel-3.17.8-300.fc21.x86_64 ? Install kernel-3.18.9-200.fc21.x86_64 @updates Erase kernel-core-3.17.8-300.fc21.x86_64 ? Install kernel-core-3.18.9-200.fc21.x86_64 @updates Erase kernel-modules-3.17.8-300.fc21.x86_64 ? Install kernel-modules-3.18.9-200.fc21.x86_64 @updates Erase kernel-modules-extra-3.17.8-300.fc21.x86_64 ? Install kernel-modules-extra-3.18.9-200.fc21.x86_64 @updates Updated krb5-libs-1.12.2-9.fc21.x86_64 @koji-override-0/$releasever Update 1.12.2-14.fc21.x86_64 @updates Updated libgpg-error-1.13-3.fc21.x86_64 @koji-override-0/$releasever Update 1.17-2.fc21.x86_64 @updates Updated librsvg2-2.40.7-1.fc21.x86_64 @updates Update 2.40.8-1.fc21.x86_64 @updates Dep-Install lz4-r127-1.fc21.x86_64 @updates Updated openconnect-7.03-1.fc21.x86_64 ? Update 7.05-1.fc21.x86_64 @updates Updated perl-Date-Manip-6.48-1.fc21.noarch ? Update 6.49-1.fc21.noarch @updates Updated perl-Getopt-Long-2.43-1.fc21.noarch @updates Update 2.45-1.fc21.noarch @updates Updated perl-List-AllUtils-0.09-1.fc21.noarch @fedora Update 0.09-2.fc21.noarch @updates Updated poppler-0.26.2-6.fc21.x86_64 ? Update 0.26.2-7.fc21.x86_64 @updates Updated poppler-glib-0.26.2-6.fc21.x86_64 ? Update 0.26.2-7.fc21.x86_64 @updates Updated poppler-qt-0.26.2-6.fc21.x86_64 ? Update 0.26.2-7.fc21.x86_64 @updates Updated poppler-utils-0.26.2-6.fc21.x86_64 ? Update 0.26.2-7.fc21.x86_64 @updates Updated qemu-guest-agent-2:2.1.3-2.fc21.x86_64 @updates Update 2:2.1.3-3.fc21.x86_64 @updates Updated webkitgtk3-2.4.8-1.fc21.x86_64 ? Update 2.4.8-2.fc21.x86_64 @updates Updated wget-1.16.2-1.fc21.x86_64 @updates Update 1.16.3-1.fc21.x86_64 @updates Scriptlet output: 1 warning: /etc/cups/cups-browsed.conf created as /etc/cups/cups-browsed.conf.rpmnew === From that list, appstream-data looks like it may be related. I also manually tried to install a package using rpm. sudo rpm -Uvh /multimedia/isos/adobe-release-x86_64-1.0-1.noarch.rpm I doubt that this is related; however the 1 package that Apper is now reporting as available to install is flash plugin Adobe Flash Player 11.2 . That is coincidentally the same package that I was trying to update with the rpm command. Is this a permanent fix, or just a coincidence? JimR
Looks like I spoke too soon. Apper still only shows that 1 single update, but yum shows dozens now. ============================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================== Updating: flash-plugin x86_64 11.2.202.451-release adobe-linux-x86_64 6.9 M gstreamer1-plugins-bad-free x86_64 1.4.5-2.fc21 updates 1.5 M kcm_colors x86_64 4.11.16-3.fc21 updates 154 k kde-style-oxygen x86_64 4.11.16-3.fc21 updates 452 k kde-workspace x86_64 4.11.16-3.fc21 updates 9.8 M kde-workspace-libs x86_64 4.11.16-3.fc21 updates 595 k kgreeter-plugins x86_64 4.11.16-3.fc21 updates 102 k khotkeys x86_64 4.11.16-3.fc21 updates 314 k khotkeys-libs x86_64 4.11.16-3.fc21 updates 160 k kinfocenter x86_64 4.11.16-3.fc21 updates 600 k kmenuedit x86_64 4.11.16-3.fc21 updates 371 k ksysguard x86_64 4.11.16-3.fc21 updates 301 k ksysguard-libs x86_64 4.11.16-3.fc21 updates 254 k ksysguardd x86_64 4.11.16-3.fc21 updates 122 k ktp-auth-handler x86_64 0.9.0-1.fc21.1 updates 102 k kwin x86_64 4.11.16-3.fc21 updates 2.4 M kwin-libs x86_64 4.11.16-3.fc21 updates 234 k libgcrypt x86_64 1.6.3-1.fc21 updates 373 k libgudev1 x86_64 216-21.fc21 updates 60 k libkworkspace x86_64 4.11.16-3.fc21 updates 118 k liveusb-creator noarch 3.13.3-1.fc21 updates 254 k plasma-scriptengine-python x86_64 4.11.16-3.fc21 updates 93 k python-blivet noarch 1:0.61.15-1.fc21 updates 686 k rpm x86_64 4.12.0.1-5.fc21 updates 500 k rpm-build-libs x86_64 4.12.0.1-5.fc21 updates 110 k rpm-libs x86_64 4.12.0.1-5.fc21 updates 275 k rpm-plugin-selinux x86_64 4.12.0.1-5.fc21 updates 48 k rpm-plugin-systemd-inhibit x86_64 4.12.0.1-5.fc21 updates 48 k rpm-python x86_64 4.12.0.1-5.fc21 updates 90 k systemd x86_64 216-21.fc21 updates 5.2 M systemd-compat-libs x86_64 216-21.fc21 updates 126 k systemd-libs x86_64 216-21.fc21 updates 322 k systemd-python x86_64 216-21.fc21 updates 93 k systemd-python3 x86_64 216-21.fc21 updates 95 k Transaction Summary ============================================================================================================================================== Upgrade 34 Packages
Is there anything that I an provide to aid in resolution?
*** Bug 1190970 has been marked as a duplicate of this bug. ***
Now that we have multiple other reports, will this get any priority?
I noted that the apper and the automatic update modules only propose fc21 updates for installed fc20 (or perhaps lower) packages. In the update comparison mechanism apparently only the release level is taken into account and not the version within the release. How to reproduce: download some fc20 packages in my case I took gramps-4.0.3-1.fc20.noarch.rpm and gramps-common-4.0.3-1.fc20.noarch.rpm and did a localinstall of both in my fc21 system gramps works fine (the fc21 version did not which is the reason for this attempt) -now apper in 'updates' will propose fc21 versions -some time after every system start the automatic update will show the two fc21 versions as available updates
the bug is due to this commit: https://github.com/hughsie/PackageKit/commit/1615ace6ea5f3348ab8c76b713809bbe5a450d23
(In reply to marc-schmitzer from comment #8) > Packagekit defaults to infinity (GUINT_MAX). But Apperd calls the refresh > cache method without setting a cache age hint, so maybe this is why no > update is triggered. Apper needs to set cache-age both when doing GetUpdates and also when doing RefreshCache (which you don't really need to use these days); we can't have a heuristic that works well without this extra data. If you're checking every 24h for updates, 24h for a cache age would make sense (unless you're clicking a button for a manual refresh, when 10mins would be better), but the daemon can't guess when things are "new enough" to return results without downloading 100's of megs of metadata.
Reassigning to apper per comment 25.
Created attachment 1019399 [details] apper cache age support this patch set the cache age for the user refresh request to 1 second and to 1 hour for the apperd daemon you find a patched version of apper here:https://copr.fedoraproject.org/coprs/scorpionit/apper/
Thanks for the patch, going with 10min/1hr (instead of 1sec/1hr) which is closer to what hughsie recommended.
apper-0.9.1-9.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/apper-0.9.1-9.fc22
Created attachment 1019723 [details] cache age for apper plasmoid This patch add cache-age (10 minutes) to apper plasmoid
Thanks!
to build on fedora 21 require kwin-libs and kwin-gles-libs
(In reply to Fedora Update System from comment #29) > apper-0.9.1-9.fc22 has been submitted as an update for Fedora 22. > https://admin.fedoraproject.org/updates/apper-0.9.1-9.fc22 What about Fedora 21? I still have the same problems there.
Currently fighting f21 build failures (lagely) due to bug #1207945
Elia, thanks for the patches, dantti (upstream apper dev) had some feedback on irc: [13:47] <dantti> rdieter: ... instead of using the global Daemon::setHints().. I would suggest using the m_transaction->setHints() [13:47] <dantti> and using the % operator instead of + would you mind reworking the fix with these suggestions in mind?
Created attachment 1019908 [details] new cache age patch - replaced + operator with % - moved sizeHints from ApperKCM to PkTransaction (in this way the plasmoid patch are not required yet) If I replace Daemon::sizeHints() with m_transaction->setHints() the sizeHints are ignored... probably I am doing something wrong but I don't have idea how to resolve this :-( sorry for my english
apper-0.9.1-10.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/apper-0.9.1-10.fc21
Package apper-0.9.1-10.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing apper-0.9.1-10.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7088/apper-0.9.1-9.fc22 then log in and leave karma (feedback).
I'm watching the comments for the F22 and F21 packages. It would seem that the fix works well on F22 but *not* on F21. I'm still waiting for the release of F22. Since I'm still on F21, the suggested command su -c 'yum update --enablerepo=updates-testing apper-0.9.1-10.fc22' returns "No package available" on my systems.
Try instead: su -c 'yum update --enablerepo=updates-testing apper'
I have been testing apper-0.9.1-10.fc21.x86_64 and apper is not showing updates even when ran manually it says no updates are available. When I first installed 0.9.1-10 it failed to find any updates. On the next system restart Apper did show some updates but this happened only once and since then no updates are shown. DNF and Yum show many updates.
I am running FC21, so I just substituted 21 into the command # su -c 'yum update --enablerepo=updates-testing apper-0.9.1-10.fc22' I ran this on my engineering machine yesterday. It pulled a list of a few dozen updates, including the one for apper. Those installed (except for one, which could not find the package on the mirror, but did not seem related to apper). itself. Meantime, tonight that machine is reporting new updates are available. So excited, I haven't seen that in months! About to run the original update on my FC21 Production Machine.
I installed the apper update yesterday at about 1300 UTC. This morning I started two F21 systems and waited. Five minutes later I ran: $ sudo pkcon refresh force and got notices of 11 or 13 updates, depending on the system. And once again I had to run that command from konsole to get news of the updates. Once I had them, I could install them in the usual way. This is how I have been running my system since this issue first appeared. So that update seems to have changed nothing.
In my case it's worse: even after running pkcon refresh force, apper gives does not show packages to be updated; the only way to update the system is running yum update, which always works.
(In reply to bug_fedora from comment #42) > I am running FC21, so I just substituted 21 into the command > About to run the original update on my FC21 Production Machine. Yes, it worked correctly on my Prod Machine as well.
apper-0.9.1-10.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
I'm still using F21, and the problems with apper persist. Maybe when the upgrade team releases F22 I'll see some relief. But I still have to run "pkcon refresh force" as a superuser to see any updates, even twenty-four hours later.
(In reply to Terry A. Hurlbut from comment #47) > I'm still using F21, and the problems with apper persist. Maybe when the > upgrade team releases F22 I'll see some relief. But I still have to run > "pkcon refresh force" as a superuser to see any updates, even twenty-four > hours later. Please try : pkcon repair pkcon -c -1 refresh force (In reply to Rex Dieter from comment #40) > Try instead: > su -c 'yum update --enablerepo=updates-testing apper' this also updates to me kde-runtime.x86_64 and kde dependencies and it is working (I done a reboot )
(In reply to Sergio Monteiro Basto from comment #48) > (In reply to Terry A. Hurlbut from comment #47) > > I'm still using F21, and the problems with apper persist. Maybe when the > > upgrade team releases F22 I'll see some relief. But I still have to run > > "pkcon refresh force" as a superuser to see any updates, even twenty-four > > hours later. > > Please try : > > pkcon repair > pkcon -c -1 refresh force > > > (In reply to Rex Dieter from comment #40) > > Try instead: > > su -c 'yum update --enablerepo=updates-testing apper' > > this also updates to me kde-runtime.x86_64 and kde dependencies and it is > working (I done a reboot ) Herewith the output: $ sudo pkcon repair [sudo] password for Temlakos: FIXME: need to call pk_progress_bar_start() earlier![=========================] Finished [=========================] [=========================] Finished [=========================] [Temlakos@temlakos ~]$ sudo pkcon -c -1 refresh force Refreshing cache [=========================] Waiting for authentication [=========================] Downloading repository information[=========================] Loading cache [=========================] Downloading repository information[=========================] Loading cache [=========================] Downloading repository information[=========================] Loading cache [=========================] Finished [=========================] No updates listed, but it might be too soon for that anyway.
Today, at about 1800 UTC (give or take an hour), one of my systems pulled down two tzdata package updates without my having to "force" a "pkcon refresh." I knew those were out there, because my other system already had them. Now I'm waiting to see what other updates it will take, and when, and how long I have to wait for them. Should I have to wait twenty-four hours?
FC21 repair seems to have worked here. Installed apper update yesterday with repair and refresh, this evening system pulled down about 20 new updates. After updating via KDE 'SystemSettings', "yum update" showed no pending updates.
No luck here, with FC21. First run apper, check for updates. "Your system is updated, checked 5 hrs ago". Then run "pkcon update", "No packages require update at this time". Run "yum -y update", bazinga: [pfessel@wotan ~]$ sudo yum -y update [sudo] senha para pfessel: Plugins carregados: langpacks, remove-with-leaves, show-leaves Resolvendo dependências --> Executando verificação da transação ---> O pacote libmediainfo.x86_64 0:0.7.73-1.fc21 será atualizado ---> O pacote libmediainfo.x86_64 0:0.7.73-2.fc21 será uma atualização ---> O pacote libzen.x86_64 0:0.4.31-1.fc21 será atualizado ---> O pacote libzen.x86_64 0:0.4.31-2.fc21 será uma atualização ---> O pacote mediainfo.x86_64 0:0.7.73-1.fc21 será atualizado ---> O pacote mediainfo.x86_64 0:0.7.73-2.fc21 será uma atualização ---> O pacote mediainfo-gui.x86_64 0:0.7.73-1.fc21 será atualizado ---> O pacote mediainfo-gui.x86_64 0:0.7.73-2.fc21 será uma atualização ---> O pacote tzdata.noarch 0:2015c-1.fc21 será atualizado ---> O pacote tzdata.noarch 0:2015d-1.fc21 será uma atualização ---> O pacote tzdata-java.noarch 0:2015c-1.fc21 será atualizado ---> O pacote tzdata-java.noarch 0:2015d-1.fc21 será uma atualização --> Resolução de dependências finalizada Proabley the tzdata* files are the same john getsoian referred to on previous (#51) comment.
I mentioned the tzdata packages. Yes, they are the ones. Did you try the "pkcon repair" and "pkcon -c -1 refresh force" commands from comment 48?
Yes, gone there, did that. Should I try it again?
Try it once more, then wait forty-eight hours. Then report your findings. That's my plan.
apper-0.9.1-10.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
After forty-eight hours without an update notice, I ran the pkcon repair and refresh commands again. No updates found. I ran this test at about 0939 UTC. Then I ran yum -y update, and still found no updates. So maybe this works properly after all.
Re: comment 57 if pkcon commands don't work, then no PK client will, and it's not *this* bug, but something else.
I don't mean to say the commands do not work. I do suggest the test is inconclusive, since yum update found no packages for update, either. That suggest the system was up-to-date, anyway.
This morning at about 05:31 EDT (or 09:31 UTC), my two F21 systems each showed about thirty-odd updates--without my having to specify any line commands. They all installed properly.
I Had to run "pkcon repair" and "pkcon -c -1 refresh force" twice over ~48 hours and since then update notifications seem to be working fine now. Matching the same package updates listed by yum and dnf.
Well it still not 100% reliably working.. Yumex-dnf popped up in the tray showing updates are available, checking apper manually showed none. I had to use "pkcon refresh force" for apper to show the updates.
This problem still exists. I have done a clean install of Fedora 22 KDE "stable" multiple times, & have come across this problem. Neither Apper nor dnf can pull updates, no matter how many times a manual update is attempted, & no matter how much time goes by. This goes on for days. I just tried "pkcon refresh force", & that seems to have worked for Apper. Apper can finally update packages, but dnf still doesn't see the updates.
I see the same issue. Apper sees updates that DNF does not see.
(In reply to Paul Lipps from comment #64) > I see the same issue. Apper sees updates that DNF does not see. We that's a different issue you might want to open a new issue. That said did you tried dnf update --refresh ? Default metadata expire is 7 days, at least in Fedora 22.