Same here. This is now a catch-22: rpmfusion cannot rebuild until this update goes stable from what I know.

This includes an ABI change: should this be hitting F32 at all? I expect other packages in Fedora will also need a rebuild? (I can't seem to find an update announcement for the ABI bump on -devel)

Sorry, late to the party here. Yes, this fixes the regression from the previous build. Thanks!

Ah, thanks. I'll go test that one out now. (tagging doesn't seem to send notifications on bodhi or I'd have seen it before :( )

Would it perhaps be better to use COPR for testing so that people need to opt-in to these RCs (also on rawhide where it seems we're using Fedora as a CI system with a new build every 2 hours? https://bodhi.fedoraproject.org/updates/?packages=podman)

At the moment, even if these updates do not make it to the stable updates repositories (some of the broken ones like the skopeo update made it there even: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cd7e382e0c). us folks that test the updates-testing repos are still getting them and seeing broken systems. The function of the updates-testing repositories is to test stable updates before they get to users, not to test rcs which are not intended for users in the first place, right?

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

A much better system would be to use copr (which has excellent scm integration) for all of these snapshots and only push stable versions of these tools to Fedora. That allows people to opt-in as opposed to the current system where I need to modify my repo files to opt out from these rcs. The other option is that I stop testing updates.

So, can someone confirm if this is a general bug? @tomsweeneyredhat, @dwalsh, @jwhonce: could you provide more info please? What tests did you do where you did not encounter this issue? What version of podman did you use?

Wouldn't all of us with a prior podman installation see this bug, and so won't all users now run into it?

RPM Fusion cannot do rebuilds until this update will reach stable.

Ah, right.

The issue is clearly with this update, since podman has not been updated on our systems. If this update requires podman version 2 from the other update, then the two builds need to be pushed together as one update to prevent breakages.

Our of curiosity: what version of podman are you on that you did (or are not) seeing this bug?

Is podman v2 required for this? I've got 1.9.3 here: podman-1.9.3-1.fc32.x86_64

The podman v2 update for F32 hasn't even hit testing yet, and has 0 karma so it won't get to stable any time soon either: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6660e9ee6e

Update currently blocked here by the lack of the corresponding -freeworld update on rpmfusion from the looks of it. Jan, would you be taking care of that bit too please?

 Problem 1: package qt5-qtenginio-1:1.6.2-28.fc32.x86_64 requires qt5-qtbase(x86-64) = 5.13.2, but none of the providers can be installed
  - package qt5-qtenginio-1:1.6.2-28.fc32.x86_64 requires libQt5Core.so.5(Qt_5.13.2_PRIVATE_API)(64bit), but none of the providers can be installed
  - cannot install both qt5-qtbase-5.14.2-5.fc32.x86_64 and qt5-qtbase-5.13.2-5.fc32.x86_64
  - cannot install both qt5-qtbase-5.13.2-5.fc32.x86_64 and qt5-qtbase-5.14.2-5.fc32.x86_64
  - cannot install both qt5-qtbase-5.13.2-4.fc32.x86_64 and qt5-qtbase-5.14.2-5.fc32.x86_64
  - cannot install the best update candidate for package qt5-qtenginio-1:1.6.2-28.fc32.x86_64
  - cannot install the best update candidate for package qt5-qtbase-5.13.2-5.fc32.x86_64
 Problem 2: package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 requires libQt5Gui.so.5(Qt_5.13.2_PRIVATE_API)(64bit), but none of the providers can be installed
  - cannot install both qt5-qtbase-gui-5.14.2-5.fc32.x86_64 and qt5-qtbase-gui-5.13.2-5.fc32.x86_64
  - cannot install both qt5-qtbase-gui-5.13.2-5.fc32.x86_64 and qt5-qtbase-gui-5.14.2-5.fc32.x86_64
  - cannot install both qt5-qtbase-gui-5.13.2-4.fc32.x86_64 and qt5-qtbase-gui-5.14.2-5.fc32.x86_64
  - cannot install the best update candidate for package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64
  - cannot install the best update candidate for package qt5-qtbase-gui-5.13.2-5.fc32.x86_64
 Problem 3: problem with installed package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64
  - package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 requires qt5-qtwebengine(x86-64) = 5.13.2, but none of the providers can be installed
  - cannot install both qt5-qtwebengine-5.14.2-2.fc32.x86_64 and qt5-qtwebengine-5.13.2-4.fc32.x86_64
  - cannot install both qt5-qtwebengine-5.13.2-4.fc32.x86_64 and qt5-qtwebengine-5.14.2-2.fc32.x86_64
  - cannot install the best update candidate for package qt5-qtwebengine-5.13.2-4.fc32.x86_64
 Problem 4: problem with installed package qt5-qtenginio-1:1.6.2-28.fc32.x86_64
  - package qt5-qtenginio-1:1.6.2-28.fc32.x86_64 requires qt5-qtbase(x86-64) = 5.13.2, but none of the providers can be installed
  - package qt5-qtenginio-1:1.6.2-28.fc32.x86_64 requires libQt5Core.so.5(Qt_5.13.2_PRIVATE_API)(64bit), but none of the providers can be installed
  - cannot install both qt5-qtbase-5.14.2-5.fc32.x86_64 and qt5-qtbase-5.13.2-5.fc32.x86_64
  - cannot install both qt5-qtbase-5.13.2-5.fc32.x86_64 and qt5-qtbase-5.14.2-5.fc32.x86_64
  - cannot install both qt5-qtbase-5.13.2-4.fc32.x86_64 and qt5-qtbase-5.14.2-5.fc32.x86_64
  - package python3-qt5-5.14.2-3.fc32.x86_64 requires libQt5Core.so.5(Qt_5.14)(64bit), but none of the providers can be installed
  - cannot install the best update candidate for package python3-qt5-5.13.2-5.fc32.x86_64

(Not given negative karma because this isn't an issue with this update)

Works, thanks very much!

The new adwaita-qt5 package causes Qutebrowser to crash. Filed bug:

• https://bugzilla.redhat.com/show_bug.cgi?id=1835864

works well, no regressions noted here

works well, no regressions noted here

Seems OK.

Seems OK.