Ping, can someone please push this into stable?

podman restore now works again.

podman-3.4.7-1.fc35 glibc-2.34-38.fc35

LGTM. podman-4.1.0-2.fc37 are now passing. Thank you!

Yay! nmap-ncat-7.92-4.fc37 is now in stable. A simple retrigger-tests picked it up, and podman gating tests now pass.

CI failure is due to a bug in nmap-ncat-7.92-3.fc37

Podman tests are all green, yay! toolbox fails but it's the usual problem when switching to a new Fedora release. I recommend waiving it.

Rootless failures all seem to have to do with systemd-ish errors. Log says systemd-250.3-5.fc37. I got a Rawhide VM, it had systemd -4, everything worked. Ran dnf upgrade, got systemd -6, everything works. I'm going to just assume that -5 was a very brief and very broken version. If these errors happen again, then I'll worry.

Test failure is a criu bug, not podman: https://github.com/checkpoint-restore/criu/pull/1706

It is OK to waive.

podman-remote, both root and rootless, pass all tests.

LGTM. One failure (#13283), probably criu-related, IMO not a showstopper. Apart from that passes gating tests root & rootless (local only, haven't tried remote).

Passes everything except the network reload test which Paul assures me is fixed in main.

Works fine with podman-4.0.0-0.5.rc4.fc36

For some weird reason, the tests reran with the same ancient obsolete broken RC (podman-4.0.0-0.1.rc1.fc36) instead of the latest RC.

Still, this time there was only one failure in each run (root/rootless) and it's a well-known one in that RC. This can be waived.

LGTM. I get the same test failure, and assume it's just some sort of netavark bug that will be fixed some day:

not ok 297 podman network reload
# (from function `die' in file ./helpers.bash, line 484,
#  in test file ./500-networking.bats, line 265)
#   `die "curl did not timeout, status code: $status"' failed
# # podman rm -t 0 --all --force --ignore
# # podman ps --all --external --format {{.ID}} {{.Names}}
# # podman images --all --format {{.Repository}}:{{.Tag}} {{.ID}}
# quay.io/libpod/testimage:20210610 9f9ec7f2fdef
# # podman run -d --name myweb -p 5351:80 --network podman -v /tmp/podman_bats.WVrj6B/hello.txt:/var/www/index.txt:Z -w /var/www quay.io/libpod/testimage:20210610 /bin/busybox-extras httpd -f -p 80
# 7237eb4778f6783181d6eb7b68e2130cfb79b5cca5052ad87e27761fac24968d
# # podman inspect 7237eb4778f6783181d6eb7b68e2130cfb79b5cca5052ad87e27761fac24968d --format {{(index .NetworkSettings.Networks "podman").IPAddress}}
# 10.88.1.189
# # podman inspect 7237eb4778f6783181d6eb7b68e2130cfb79b5cca5052ad87e27761fac24968d --format {{(index .NetworkSettings.Networks "podman").MacAddress}}
# 36:b0:68:bd:a1:e2
# #/vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
# #| FAIL: curl did not timeout, status code: 0
# #\^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This build needs to make it out into the world. Any idea why it's stuck? I can't click on the failure log.

podman run works again. Running system-test suite to make sure, but LGTM so far.

Tests passed this time! Well, almost: filed https://github.com/containers/buildah/issues/3771 for what looks like a real bug.

Anyhow, LGTM.

I think I wasted my entire morning chasing a CDN fault; and think perhaps this gating-test failure may have been related. I've re-triggered the tests and will monitor to see if they pass this time.

Podman works again, at least as far as podman info not crashing any more. I have not run the entire test suite, and can't right now.

Tested with podman-4.0.0-0.4.rc3.fc36 on 5.17.0-0.rc0.20220112gitdaadb3bd0e8d.63.fc36.x86_64. Passes podman tests. LGTM.