Comments

564 Comments

You could maybe file it against flatpak in Redhat Enterprise Linux 8 in bugzilla.redhat.com

Sorry, I don't know. I would suspect something in flatpak OCI backend is not working right. Maybe wait and see if the RHEL flatpak update improves things? Or maybe RHEL flatpak needs some OCI patches backported? This update installs just fine on Fedora.

@sumomu, "Can't pull from untrusted non-gpg verified remote" sounds like an issue with flatpak, not this update

As for the openh264 error, the error is completely unrelated to this update. It's trying to say that the openh264 update from flathub (not from fedora) requires a newer flatpak version than what's available from centos. This should already be fixed as part of https://bugzilla.redhat.com/show_bug.cgi?id=1754450 in RHEL 7.7.

I've removed the reference to #1763401 from this update

I've added gnome-software-3.34.1-5.fc31 build that updates a few appstream ID references that I noticed were changed between F30 and F31. No other functional changes in gnome-software.

Huh, weird

User Icon kalev commented & provided feedback on crun-0.9.1-1.fc31 3 years ago

Submitting to stable as latest podman in stable requires this.

@jvoss, What you are seeing is a regression from a busted shared-mime-info update, not this one. See https://bodhi.fedoraproject.org/updates/FEDORA-2019-b5c8297c68

OK, thanks!

It just got pushed to stable, so too late to hold this off.

I believe gtk upstream intends to have gtk point releases suitable for everywhere though, that's why there are no branches for different gnome versions. I'd suggest to bring this up with upstream first.

@dan1mal, We have a concept of updates that are being tested before being pushed to the base repository. This update is currently in "testing" state, and once it is verified to not cause additional issues compared to what's in the base repo, then it's moved to "stable". These two states correspond to the /etc/yum.repos.d/fedora.repo ("stable") and /etc/yum.repos.d/fedora-updates-testing.repo ("testing") repos.

The main thing here that's important to verify during testing is that it doesn't cause additional issues compared to what's in stable (doesn't cause regressions). No regressions mean that this update should be good to move to stable.

This doesn't mean that it's not important to find non-regression issues, but these should go to a bug tracking system and not block this update from being moved to stable. That's why I asked if this is a regression or not :)

Re https://gitlab.gnome.org/GNOME/gnome-control-center/issues/401, I doubt that's the same issue you are running into. Probably worth filing a new one and adding screenshots and anything that looks like relevant from 'journalctl -a -b'.

Also, could someone file a bug against https://gitlab.gnome.org/GNOME/gnome-control-center and report the online accounts issue? It could also be a gnome-online-accounts bug, not gnome-control-center, but it doesn't super much matter which one to file against. Thanks!

@alciregi, @dan1mal: are the online accounts issues a regression compared to what's in F31 stable?

Let's unpush this one as well as the rest of the updates that depend on module(libgit2:0.28) already got unpushed.

Yes, sorry, I messed up a bit by putting babl and gegl04 into separate Bodhi updates. They are in stable now though, so once the mirrors sync up, it should all work out fine.

Great, thanks for testing it, @martinpitt!