Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1601479 - Packaging issues with outdated hub.docker.com fedora:rawhide containers
Summary: Packaging issues with outdated hub.docker.com fedora:rawhide containers
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Josh Boyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
: 1609480 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-16 13:16 UTC by Stephen Gallagher
Modified: 2019-01-09 22:00 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-09 22:00:37 UTC


Attachments (Terms of Use)

Description Stephen Gallagher 2018-07-16 13:16:15 UTC
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.

Comment 1 Fedora Blocker Bugs Application 2018-07-16 13:18:16 UTC
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.

Comment 2 Lukas Ruzicka 2018-07-16 16:50:09 UTC
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/

Comment 3 Robert de Bock 2018-07-17 05:06:36 UTC
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.

Comment 4 Stephen Gallagher 2018-07-17 14:32:20 UTC
(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.

Comment 5 Robert de Bock 2018-07-17 18:17:54 UTC
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?

Comment 6 Adam Williamson 2018-07-19 19:55:38 UTC
Updating summary.

Comment 7 Marek Skalický 2018-07-30 10:47:09 UTC
*** Bug 1609480 has been marked as a duplicate of this bug. ***

Comment 8 Adam Williamson 2018-08-13 18:37:38 UTC
Does anyone still believe this ought to be reviewed as a potential F29 blocker?

Comment 9 Jan Kurik 2018-08-14 10:25:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 10 Lukas Slebodnik 2018-08-14 15:24:09 UTC
(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 :-)

Comment 11 Adam Williamson 2018-08-14 20:09:19 UTC
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. ;)

Comment 12 Marek Skalický 2018-08-15 07:44:16 UTC
I think this bug isn't F29 blocker.

Who is capable to update fedora docker hub image? To move this issue on...

Comment 13 Geoffrey Marr 2018-08-20 20:04:36 UTC
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

Comment 14 Neal Gompa 2018-08-21 14:45:54 UTC
This is ridiculous. Why aren't we auto-pushing container base images to docker.io?

Comment 15 Adam Williamson 2018-08-22 00:10:40 UTC
Moving to 'distribution' for now, this may be best off as a releng pagure ticket or something - nirik?

Comment 16 Kevin Fenzi 2018-08-22 00:34:24 UTC
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.

Comment 17 Lukas Slebodnik 2018-08-23 07:02:34 UTC
(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)

Comment 18 Lukas Slebodnik 2019-01-09 22:00:37 UTC
Cannot reproduce anymore with latest docker.io/fedora:rawhide


Note You need to log in before you can comment on or make changes to this bug.