In current Rawhide (Fedora-Rawhide-20190306.n.1), podman cannot be installed due to an unresolved dependency on conmon.
conmon is a subpackage of cri-o. Digging into it a bit, it seems the cri-o packager decided to retire the non-modular package:
but did not (as they presumably should have done) get cri-o signed off to have a default module stream:
which means nothing outside of the module can properly depend on it, AIUI.
So, either podman needs to stop depending on conmon, or the cri-o situation needs to be sorted out. CCing the cri-o packager.
This breaks some openQA install tests, where podman winds up in the package set.
Oh, it seems the podman owner is also the cri-o maintainer, which simplifies things. :P
*** Bug 1686926 has been marked as a duplicate of this bug. ***
pwhalen says this also affects F30.
(In reply to Adam Williamson from comment #0)
> In current Rawhide (Fedora-Rawhide-20190306.n.1), podman cannot be installed
> due to an unresolved dependency on conmon.
Description says rawhide but this BZ is for fedora 30. Which is not the same.
And fedora 30 does not have conmon in module
rpm -q podman conmon
BTW rawhide(f31) was fixed by
I would say this BZ can be closed.
"Description says rawhide but this BZ is for fedora 30. Which is not the same."
It applies to both. See comment #3. It's assigned to 30 as fixing it in 30 is more critical (and requires blocker bureaucracy).
"And fedora 30 does not have conmon in module
rpm -q podman conmon
You are probably looking at old information. (also, 'rpm -q' is telling you what you have installed; a package that is retired is not automatically uninstalled unless something obsoletes it). The f30 branch in git is certainly retired:
there has not been a successful F30 compose for some time (we are working on this), but if you look at recent failed composes, they do not have conmon:
"BTW rawhide(f31) was fixed by
I'll have to check if that is a correct fix, thanks.
"I would say this BZ can be closed."
not yet :)
As sgallagh points out, this is an automatic blocker: "Bugs which entirely prevent the composition of one or more of the release-blocking images required to be built for a currently-pending (pre-)release" - this prevents the compose of aarch64 and armhfp Server disk images. Marking as accepted.
correction, only aarch64 Server disk image is blocking, not armhfp.
*** Bug 1686813 has been marked as a duplicate of this bug. ***
There was a fix committed:
and a few new builds of podman done this morning. One of them bumps versions of podman:
podman-1.1.2-1.dev.git0ad9b6b.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a449d35971
(In reply to Dusty Mabe from comment #9)
> There was a fix committed:
> and a few new builds of podman done this morning. One of them bumps versions
> of podman:
I noticed f29 was bumped to 1.1.2 by Dan Walsh but f30 wasn't. So I bumped f30 to keep upgrade path straight.
podman-1.1.2-2.dev.git0ad9b6b.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-23ba2f111f
For the record, I was not convinced that "fix" was correct, but per https://bugzilla.redhat.com/show_bug.cgi?id=1686813#c6 it probably is. (Well, I'm not sure that bundling conmon into podman is really legit, but since it's a thing that's being done, removing the dependency is probably fine).
It seems to be correct from my testing in the IoT compose.
podman-1.1.2-2.dev.git0ad9b6b.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-23ba2f111f
podman-1.1.2-2.dev.git0ad9b6b.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.