Comments

256 Comments

cldr-emoji-annotation-38~beta-3.fc33 updates correctly, thanks. (Fetched it from koji)

Also seeing this issue, even with --allowerasing:

 sudo dnf update --allowerasing --best
Last metadata expiration check: 0:10:07 ago on Mon 28 Sep 2020 09:52:37 BST.
Error: 
 Problem 1: cannot install the best update candidate for package cldr-emoji-annotation-dtd-38.0_13.0_0_1~alpha1-1.fc33.noarch
  - problem with installed package cldr-emoji-annotation-dtd-38.0_13.0_0_1~alpha1-1.fc33.noarch
  - nothing provides cldr-emoji-annotation = 38~beta-2.fc33 needed by cldr-emoji-annotation-dtd-1:38~beta-2.fc33.noarch
 Problem 2: cannot install the best update candidate for package cldr-emoji-annotation-38.0_13.0_0_1~alpha1-1.fc33.noarch
  - problem with installed package cldr-emoji-annotation-38.0_13.0_0_1~alpha1-1.fc33.noarch
  - package cldr-emoji-annotation-dtd-38.0_13.0_0_1~alpha1-1.fc33.noarch requires cldr-emoji-annotation = 38.0_13.0_0_1~alpha1-1.fc33, but none of the providers can be installed
  - package cldr-emoji-annotation-1:38~beta-2.fc33.noarch requires cldr-emoji-annotation-dtd, but none of the providers can be installed
  - cannot install both cldr-emoji-annotation-1:38~beta-2.fc33.noarch and cldr-emoji-annotation-38.0_13.0_0_1~alpha1-1.fc33.noarch
  - cannot install the best update candidate for package cldr-emoji-annotation-dtd-38.0_13.0_0_1~alpha1-1.fc33.noarch
  - nothing provides cldr-emoji-annotation = 38~beta-2.fc33 needed by cldr-emoji-annotation-dtd-1:38~beta-2.fc33.noarch
(try to add '--skip-broken' to skip uninstallable packages)

Seems to work well too, not noticed any regressions yet.

Just ran a system-upgrade, and did not see the FTI bug anymore. Thanks very much!

BZ#1852141 F33FailsToInstall: python3-google-api-client

Works find in normal usage, no regressions noted. Thanks!

I've "revoked" it. Not sure what that means, but it seems to stop the update from going to stable hopefully.

This makes python-pynwb uninstallable on Fedora 32. It should not be pushed to stable until a version of pywnb that can use this new version is available:

$ sudo dnf update --exclude=podman*
[sudo] password for asinha: 
Last metadata expiration check: 1:06:02 ago on Mon 17 Aug 2020 15:50:28 BST.
Dependencies resolved.

 Problem 1: cannot install the best update candidate for package python3-pynwb-1.2.1-1.fc32.noarch
  - nothing provides (python3.8dist(hdmf) >= 1.6.4 with python3.8dist(hdmf) < 2) needed by python3-pynwb-1.3.3-1.fc32.noarch
 Problem 2: problem with installed package python3-pynwb-1.2.1-1.fc32.noarch
  - package python3-pynwb-1.2.1-1.fc32.noarch requires (python3.8dist(hdmf) >= 1.5.4 with python3.8dist(hdmf) < 2), but none of the providers can be installed
  - cannot install both python3-hdmf-2.0.1-1.fc32.noarch and python3-hdmf-1.6.2-1.fc32.noarch
  - cannot install both python3-hdmf-1.6.2-1.fc32.noarch and python3-hdmf-2.0.1-1.fc32.noarch
  - cannot install both python3-hdmf-1.6.1-1.fc32.noarch and python3-hdmf-2.0.1-1.fc32.noarch
  - cannot install the best update candidate for package python3-hdmf-1.6.2-1.fc32.noarch
  - nothing provides (python3.8dist(hdmf) >= 1.6.4 with python3.8dist(hdmf) < 2) needed by python3-pynwb-1.3.3-1.fc32.noarch
============================================================================================================================================================================================================================================== Package                                                    Architecture                                        Version                                                    Repository                                                    Size
==============================================================================================================================================================================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 python3-hdmf                                               noarch                                              1.6.1-1.fc32                                               fedora                                                       207 k
 python3-hdmf                                               noarch                                              2.0.1-1.fc32                                               updates-testing                                              226 k
Skipping packages with broken dependencies:
 python3-pynwb                                              noarch                                              1.3.3-1.fc32                                               updates-testing                                              126 k

Transaction Summary
==============================================================================================================================================================================================================================================Skip  3 Packages

Nothing to do.
Complete!

BZ#1849403 dav1d-0.7.1 is available
BZ#1849403 dav1d-0.7.1 is available

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)

karma

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: FEDORA-2020-6660e9ee6e

karma

Hrm, seeing a regression here, but not sure what's causing it:

With the previous version, I was able to build images without any issue:

$ rpm -q containers-common
containers-common-0.2.0-1.fc32.x86_64

$ podman image build ...
Building redmine image
STEP 1: FROM ubuntu:xenial-20180705 AS ubuntu-xenial-20180705
Getting image source signatures
Copying blob 99f229f854da skipped: already exists
Copying blob c9b72a16d85e skipped: already exists
Copying blob 3620e2d282dc skipped: already exists

After the update, this doesn't work any more:

$ rpm -q containers-common
containers-common-1.0.0-1.fc32.x86_64

$ podman image build ...
Building redmine image
STEP 1: FROM ubuntu:xenial-20180705 AS ubuntu-xenial-20180705
Error: error creating build container: (image name "ubuntu:xenial-20180705" is a short name and no search registries are defined in /etc/containers/registries.conf): while pulling "ubuntu:xenial-20180705" as "localhost/ubuntu:xenial-20180705": Error initializing source docker://localhost/ubuntu:xenial-20180705: error pinging docker registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused

I see that the update already has 3 karma, rather quickly in 2 days: is no one else seeing this issue apart from me? Has the Dockerfile format that podman uses changed (in which case this is a major update and should not perhaps be pushed to stable releases now, right?)

The Dockerfile is in the repository here: https://github.com/SilverLabUCL/docker-redmine-osb/blob/master/Dockerfile

So, to reproduce:

$ git clone https://github.com/SilverLabUCL/docker-redmine-osb.git
$ cd docker-redmine-osb

$ podman build --tag "redmine" -f Dockerfile
STEP 1: FROM ubuntu:xenial-20180705 AS add-apt-repositories
Error: error creating build container: (image name "ubuntu:xenial-20180705" is a short name and no search registries are defined in /etc/containers/registries.conf): while pulling "ubuntu:xenial-20180705" as "localhost/ubuntu:xenial-20180705": Error initializing source docker://localhost/ubuntu:xenial-20180705: error pinging docker registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused

Works fine after downgrading.

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)

karma

Same issue here. Awaiting a new release :)