Comments
ankursinha
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!
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!
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
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)
Same issue here. Awaiting a new release :)
Works, thanks very much!
Also seeing this issue, even with --allowerasing: