Comments

269 Comments

That worked: it brings in the desired runc from updates-testing. Now running test suite, will LGTM once that passes (which I'm expecting).

Still doesn't pull in the required runc. Could it be the missing epoch?

# rpm -qp --requires podman-0.8.5-4.gitdc5a711.fc28.x86_64.rpm |grep runc
runc >= 1.0.0-51

# rpm -q --provides runc
runc = 2:1.0.0-50.dev.git20aff4f.fc28
runc(x86-64) = 2:1.0.0-50.dev.git20aff4f.fc28
               ^^-----

I see runc >= 1.0.0-50 but that doesn't actually work: the required release is -51. (Yes, I've tested. With runc-1.0.0-50.dev.git20aff4f.fc28, I see the tmpfs crash)

@baude, would you mind rebuilding with a new RPM dependency?

Requires: runc >= 2:1.0.0-51

With runc-2:1.0.0-46.dev.gitb4e2ecb, this podman build fails when run with --tmpfs (libpod issue 1396). Thank you!

Two regressions: no error thrown on invalid command, and --tmpfs broken. Filed issues #1395 and #1396 respectively. Neither are glaring showstoppers, but I'm not quite prepared to give it karma. Sorry.

LGTM. Tried upgrading from podman-0.8.3-1 and 0.8.4-1; the former correctly replaced containernetworking-cni with -plugins; the latter simply upgraded -plugins from 0.7.3-1 to -2. In all cases, docker-autotest suite passes the expected tests (now including the tcp/udp issue, #735).

Won't install for me either:

  Upgrading:
 podman                                  x86_64             0.8.4-1.git9f9b8cf.fc28               updates-testing             6.7 M
Installing dependencies:
 containernetworking-plugins             x86_64             0.7.3-1.fc28                          updates-testing              12 M
.....
Error: Transaction check error:
  file /usr/libexec/cni/bridge from install of containernetworking-plugins-0.7.3-1.fc28.x86_64 conflicts with file from package containernetworking-cni-0.7.1-1.fc28.x86_64
(and many more of those)

LGTM. Passes all the expected docker-autotest subtests.

LGTM. podman-0.8.3-1.git9d09a4d.fc28 passes expected subset of docker-autotest.

Passes much of docker-autotest suite; one weird failure in iptables, will continue investigating tomorrow.

Passes much of docker-autotest; no apparent regressions.

After some tweaking in the cgroups test (adding --cgroup-manager=cgroupfs) to account for new defaults, this build passes 114 of 122 tests in autotest suite.

I'm unable to reproduce the problem reported by @tomsweeneyredhat

Passes 114 out of 122 in autotest suite. (The rest are N/A or I'm-investigating-but-am-pretty-sure-they're-N/A).

conmon package works fine with podman-0.8.1-1.git6b4ab2a.fc28.x86_64; have not tested cri-o.

Passes greater subset of docker-autotest than previous version

I'm seeing regressions: issues 389 and 580 are back. @mheon believes it's a conmon issue, I agree that it's suspicious that both those issues were fixed in conmon.

Seems broken; podman ps/images seems ok, but run doesn't run:

# podman run fedora date
error reading container (probably exited) json message: EOF

ps shows the container created but never actually run:

# podman ps -a
podman ps -a
CONTAINER ID   IMAGE                             COMMAND   CREATED         STATUS    PORTS   NAMES
2927990a5d9b   docker.io/library/fedora:latest   date      3 seconds ago   Created           sharp_fermi

The f28 build seems fine at first glance

Mostly good.

Mostly good.