Description of problem: gdbm-libs cannot be installed on Fedora 29. It appears that something it provides moved from gdbm to gdbm-libs or compat-gdbm-libs and package dependencies don't handle this properly. Version-Release number of selected component (if applicable): gdbm-libs-1.16-1.fc29.x86_64.rpm How reproducible: Every time Steps to Reproduce: 1. `docker run --tty -i --rm fedora:rawhide /bin/bash` 2. `dnf install gdbm-libs` Actual results: Error: Transaction check error: file /usr/lib64/libgdbm_compat.so.4.0.0 from install of gdbm-libs-1:1.16-1.fc29.x86_64 conflicts with file from package gdbm-1:1.14.1-3.fc28.x86_64 Expected results: gdbm-libs should be installed. Additional info: This breaks the upgrade path from Fedora 28. This is a very common dependency. It is also breaking CI setups that attempt to use a Rawhide docker container.
Proposed as a Blocker for 29-beta by Fedora user sgallagh using the blocker tracking app because: For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed.
Discussed at the 2018-07-16 blocker review meeting [1]: This bug has been punted (delay decision) - from some preliminary investigation during the meeting this one doesn't seem clear cut and it does not actually seem to be breaking upgrade tests, so sgallagh will look into it further before we make any decision [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-07-16/
This is a blocker for me; when installing python2-dnf the error as described appears. (Evidence here: https://travis-ci.org/robertdebock/ansible-role-xinetd/jobs/403876902) In my situation I start with a new container, run "dnf install python2 python2-dnf sudo" and get an error.
(In reply to Robert de Bock from comment #3) > This is a blocker for me; when installing python2-dnf the error as described > appears. (Evidence here: > https://travis-ci.org/robertdebock/ansible-role-xinetd/jobs/403876902) > > In my situation I start with a new container, run "dnf install python2 > python2-dnf sudo" and get an error. So, it looks like the problem may be specifically with the fedora:rawhide container on hub.docker.com. It's *really* out of date (four months). I just switched my CI setup to use registry.fedoraproject.org/fedora:rawhide instead of just fedora:rawhide and it seems to work fine. Probably best to use Fedora's official container images, rather than the out-of-date ones on Docker Hub. I'm voting -1 blocker on this; the problem seems restricted to this case, so it's not violating the general upgrade criteria.
Indeed, first running `dnf -y update` followed by `dnf -y install python2-dnf` fixes the issue. In that case, this issue should be closed. Thanks for explaining Stephen Gallagher. Can a new image from fedora:rawhide be pushed to hub.docker.com?
Updating summary.
*** Bug 1609480 has been marked as a duplicate of this bug. ***
Does anyone still believe this ought to be reviewed as a potential F29 blocker?
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
(In reply to Adam Williamson from comment #8) > Does anyone still believe this ought to be reviewed as a potential F29 > blocker? The simplest solution would be to update rawhide images in docker.io registry :-)
Yes, but with my blocker bug wrangler hat on, I am selfish. I only care about bugs if they are proposed or accepted as blockers. If I can get this one off the list, so far as that hat is concerned, it doesn't exist any more. ;)
I think this bug isn't F29 blocker. Who is capable to update fedora docker hub image? To move this issue on...
Discussed during the 2018-08-20 blocker review meeting: [1] The decision to classify this bug as a "RejectedBlocker" was made as the latest information makes it clear that this has to do with outdated container images on the docker.com hub, and as such there is no reason to block Fedora 29 release on it (though obviously we should ensure those images are updated more often). [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-08-20/f29-blocker-review.2018-08-20-16.00.txt
This is ridiculous. Why aren't we auto-pushing container base images to docker.io?
Moving to 'distribution' for now, this may be best off as a releng pagure ticket or something - nirik?
There is an update pending on docker.io: https://github.com/docker-library/official-images/pull/4749 docker doesn't allow you do 'auto-push' that I am aware of. You have to submit pull requests for any changes. Additionally we are working to make rawhide and branched composes auto update _our_ registery every compose. Hopefully that will be done soon and at least make our containers of more use. I'm not sure there's anything left to track here that already isn't being done, but if so, sure, file a releng ticket or note it here.
(In reply to Kevin Fenzi from comment #16) > There is an update pending on docker.io: > > https://github.com/docker-library/official-images/pull/4749 > It updated just s27 and f28 images. rawhide is still not updated. (due to issues with compose if I have correct info)
Cannot reproduce anymore with latest docker.io/fedora:rawhide