Description of problem: Gnome-software starts, but does not operate correctly. See the screenshots for more info. The main problems are: 1. It does not see any repositories except for Linux Vendor. 2a. It does not display any pictures of the packages. 2b. If it does it only sees a small number of packages. 3. It does not find anything. 4. It does not update. Version-Release number of selected component (if applicable): gnome-software-3.27.92-1.fc28.x86_64 How reproducible: Always Steps to Reproduce: 1. Run gnome-software. 2. Try to work with it. Expected results: It should work normally. Additional info: [root@tester ftest]# dnf repolist Failed to synchronize cache for repo 'aivarannamaa-thonny', disabling. Failed to synchronize cache for repo 'pkotvan-texlive-beamerthemeredhat', disabling. Last metadata expiration check: 2:55:34 ago on Tue 13 Mar 2018 03:29:34 PM CET. repo id repo name status *fedora Fedora 28 - x86_64 57,094 *fedora-modular Fedora Modular 28 - x86_64 5 google-chrome google-chrome 3 *rpmfusion-free RPM Fusion for Fedora 28 - Free 567 *rpmfusion-free-updates-testing RPM Fusion for Fedora 28 - Free - Test Updates 0 *rpmfusion-nonfree RPM Fusion for Fedora 28 - Nonfree 199 *rpmfusion-nonfree-updates-testing RPM Fusion for Fedora 28 - Nonfree - Test Updates 0 *updates Fedora 28 - x86_64 - Updates 0 *updates-modular Fedora Modular 28 - x86_64 - Updates 0 *updates-testing Fedora 28 - x86_64 - Test Updates 1,757 *updates-testing-modular Fedora Modular 28 - x86_64 - Test Updates 0
Proposed as a Blocker for 28-beta by Fedora user lruzicka using the blocker tracking app because: Gnome-software belongs to core applications for Fedora. We expect that these applications will be working without any issues.
Created attachment 1407658 [details] First impression
Created attachment 1407659 [details] Looking for packages
Created attachment 1407674 [details] After some waiting
Created attachment 1407675 [details] List of installed packages
Created attachment 1407677 [details] Visible repositories
This is broadly speaking a known issue (since yesterday): it's actually broader than GNOME Software, it's packagekit. packagekit is apparently thrown off by the modular repos, and this isn't immediately fixable. The current plan appears to be this: <nirik> adamw: sgallagh split out the modular repo into subpackages and we were going to exclude them on workstation... <nirik> IMHO, it would nice to see if PK could just land some quick fix instead to ignore those repos, but I guess thats not going to happen <sgallagh> nirik: I'm going to try to see to it that PK does that at least for Final <sgallagh> (Or, ideally, actually supports them properly at that point would be even better) <nirik> it doesn't seem like ti would be that hard to ignore based on some repo feature/file. <nirik> yeah, that would be nice As a note, I believe we will need to exclude the repos for KDE as well, as KDE's updater is also PackageKit-based.
For the record, the intended 'official' update notification/application tool for Fedora KDE is plasma-pk-updates: https://github.com/KDE/plasma-pk-updates KDE also contains at least one and I think two other package management applications (dnfdragora and whatever the one that's sort of like GNOME Software is called), but the one that's intended to notify the user of updates and install them on request is that one, and it's PackageKit-based.
A good release criterion we can cite here is "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops" - this bug will affect update installation on both Workstation and KDE, with the 'default graphical package manager' for update purposes.
gnome-software 3.28.0 / PackageKit-1.1.9-2.fc28 improves this situation by making the errors correctly show up in gnome-software, instead of crashing packagekitd and silently failing in gnome-software. In addition to the modular repos, I believe we also have gnome-software erroring out for the missing openh264 repos -- they are enabled_metadata=1 and skip_if_unavailable=False, which makes libdnf error out when it sees the missing metadata. As a fix, I first came up with https://pagure.io/fedora-repos/pull-request/69 to remove skip_if_unavailable=False, but then later talked to dgilmore who said that he's planning on putting empty repo metadata in place to fix this instead.
For the record, there were actually two bugs here. The first one reported was due to a mirrormanager misconfiguration. The remaining (arguably more serious) one is that PackageKit will operate on the modular repo as if it was a traditional repo... meaning that standard ENVR priority would take place. So as a result, if the modular repo had (for an actual, real example) the Node.js 9.x experimental stream available, PackageKit would treat this as an update to the 8.x LTS stream in the traditional repositories. With proper module support, that version would be invisible to the depsolver unless specifically requested by enabling that module. We also can't just tell PK to completely ignore the module-enabled repos because of the following situation: A user intentionally installs an older version (let's say Node.js 6.x LTS) using module-aware DNF. The next time they used PK to perform updates, it would see the "newer" 8.x version in the traditional repo and update to that unexpectedly. Our workaround for F28 (at least Beta, probably also GA) is to ship the modular repos ONLY for Fedora Server Edition and not for the other editions/spins until we fix PackageKit, possibly by moving the logic into libdnf, which PK consumes.
"As a fix, I first came up with https://pagure.io/fedora-repos/pull-request/69 to remove skip_if_unavailable=False, but then later talked to dgilmore who said that he's planning on putting empty repo metadata in place to fix this instead." Yes, this one also happens every cycle :/
Ok, thanks for clarification. Feel free to close this bug, if you have others to track the situation.
I nominated https://bugzilla.redhat.com/show_bug.cgi?id=1544193 as a blocker to track the openh264 repo metadata issue separately.
+1 blocker per criteria in Comment 9.
+1 blocker.
-1 blocker +1 FE
okay after talking to adamw I am changing to +1 blocker. what the actual fix is, is not totally clear to me in the bug. but it looks like PackageKit or gnome-software needs to change some behaviour.
So, AIUI, here's the state right now: * 15544193 was split out to cover the h264 repo issue * fedora-repos-28-0.7, which splits out the modular repos, is stable f28 * fedora-repos-modular is only listed in server-product in comps * fedora-repos-modular does not provide anything but 'fedora-repos-modular' * Nothing else requires 'fedora-repos-modular' Given all of that, I'm gonna say the blocker issues here are resolved. The bug itself remains outstanding, as...PackageKit still doesn't DTRT. But it's no longer blocking Beta. Please comment if I got anything wrong there.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. 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 EOL if it remains open with a Fedora 'version' of '28'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.