podman: 3.1.2 -> 3.2.1

[zowoq]

https://github.com/containers/podman/releases/tag/v3.2.0

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Added a release notes entry if the change is major or breaking
• Fits CONTRIBUTING.md.

nixos tests failing ...

[saschagrunert]

LGTM

[zowoq]

podman run --rm -it docker.io/alpine
Error: opening seccomp profile failed: open /usr/share/containers/seccomp.json: no such file or directory

https://github.com/containers/podman/releases/tag/v3.2.0

• The podman info command now includes the path of the Seccomp profile Podman is using, available cgroup controllers, and whether Podman is connected to a remote service or running containers locally.
• Fixed a bug where setting a custom Seccomp profile via the seccomp_profile option in containers.conf had no effect, and the default profile was used instead.

Not sure if we're supposed to have been shipping seccomp.json and the upstream fixes have surfaced this or if the missing file error is actually a bug and the file isn't required by default.

I'll continue with this PR tomorrow and I'll have a dig through the podman code then.

[saschagrunert]

I'll continue with this PR tomorrow and I'll have a dig through the podman code then.

Thank you! I expect that podman falls back to the internal seccomp profile (struct) if the file is not present on disk. So maybe this is a real regression, yes.

[saschagrunert]

Created containers/podman#10556 for tracking

[zowoq]

Thank you @saschagrunert!

[zowoq]

Oh, I should have looked at the logs sooner. I'd assumed the test failure was the same as the seccomp problem I ran into trying podman manually but it's a different error.

tar cv --files-from /dev/null | podman import - scratchimg
Getting image source signatures
Copying blob 84ff92691f90 .
Error: Error reading blob sha256:84ff92691f909a05b224e1c56abb4864f01b4f8e3c854e4bb4c7baf1d3f6d652: Digest did not match, expected sha256:84ff92691f909a05b224e1c56abb4864f01b4f8e3c854e4bb4c7baf1d3f6d652, got sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

> podman system prune -af && tar cv --files-from /dev/null | podman import - scratchimg
Deleted Images
Total reclaimed space: 0B
Getting image source signatures
Copying blob 84ff92691f90 .
Error: Error reading blob sha256:84ff92691f909a05b224e1c56abb4864f01b4f8e3c854e4bb4c7baf1d3f6d652: Digest did not match, expected sha256:84ff92691f909a05b224e1c56abb4864f01b4f8e3c854e4bb4c7baf1d3f6d652, got sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

> podman system prune -af && tar cvf scratchimg.tar --files-from /dev/null && podman import scratchimg.tar scratchimg
Deleted Images
Total reclaimed space: 0B
Getting image source signatures
Copying blob 84ff92691f90 done
Copying config 2f7343ecb7 done
Writing manifest to image destination
Storing signatures
scratchimg

Bisected to containers/podman@0f7d54b.

I'll file an issue about this upstream when I have time.

[saschagrunert]

LGTM

[zowoq]

@ofborg build podman.tests

[adisbladis]

LGTM and tests are passing so I'm feeling fine about this one.

cc @roberth as this release supposedly adds support for rootless docker-compose.
containers/podman#9169