Tested from Koji, rendered Chrome and VScode correctly as hoped


I have seen the brokenness with both Chrome and VSCode.

Should this update be unpushed?


Tested with freeipa-provided subid's successfully. LGTM

LGTM; confirm that this fixes the issue with installing signed collections

BZ#2171961 toolbox- is available

LGTM! Also tested specifically with FreeIPA provided subid's. When not configured correctly, toolbox still fails as expected.

BZ#2171961 toolbox- is available

Seems the current spec still has a %package quadlet:

%package quadlet
Summary: Easily create systemd services using %{name}
Requires: %{name} = %{epoch}:%{version}-%{release}
Conflicts: quadlet

I don't know if that explains the behavior, but I think the conflicts belongs in the main package now, at least

I definitely had to remove podman-quadlet manually. I'm looking at the specfile and I see the obsoletes line, and it appears to be correct.

Updating Subscription Management repositories. Transaction ID : 695 Begin time : Thu 09 Feb 2023 08:38:05 AM CST Begin rpmdb : 1e4cd75cbd9ba87adccd9919af8123226f00136441e8e4a2d4cf099eb7ca35b1 End time : Thu 09 Feb 2023 08:38:06 AM CST (1 seconds) End rpmdb : db15e28b7e950e8269ca18d663af7c8c5469298e649d82ee1773ab95bef9c0da User : Martin Jackson <mjackson> Return-Code : Success Releasever : 37 Command Line : erase podman-quadlet Comment : Packages Altered: Removed podman-quadlet-5:4.4.0-1.fc37.x86_64 @@System

(From the manual removal) vs:

Obsoletes: %{name}-quadlet <= 5:4.4.0-1

in the current specfile. So I'm not sure why I would have had to do that...


Pulled from the koji builds. Works for rootless and rootful containers.

Note that the previously built subpackage podman-quadlet has now been integrated into the podman binary package in this release. You will need to remove podman-quadlet manually if you have one.

I think that depends on which should hit stable before podman does


Tested with rootful and rootless containers, including new quadlet features. LGTM


Works for me on Dell XPS 13 (laptop) and XPS 8900 (PC)

Thanks @lsm5!

Also - update on the warnings above - I have found that this installation of podman was still using the cni backend, so these warnings were expected.

With rc2 and -plugins installed, I'm getting warning messages like this with old cni config files from previous (i.e. 4.3.1) versions of podman:

podman run -it --net=host -v /home/martjack/gitwork/newprints/docs:/site:"rw,z" --entrypoint htmltest WARN[0000] Error validating CNI config file /home/martjack/.config/cni/net.d/87-podman.conflist: [failed to find plugin "bridge" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "portmap" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "firewall" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "tuning" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin]]

Is this expected? I removed the conflist files and that makes the warnings go away (and things still work).

Also, it seems that -quadlet has to be installed "intentionally"; I'm assuming this is deliberate for now, as -quadlet is still in "preview" mode, but I wanted to note it here just in case.


Works for me, including quadlet functions.

Tested via the koji builds. LGTM

BZ#2089022 New separated subscription-manager-rhsm-certificates package conflicts with existing subscription-manager-rhsm-certificates