Bug 1554981

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.