In D49821#1136169, @dch wrote:

LGTM, testing with stable/14 today. thanks Doug for tracking this down & explaining it.

This version disables sparse-file handling which is the cause of the incompatibility with Podman

In D49821#1135863, @jlduran wrote:

The GitHub issue should be:
https://github.com/containers/podman/issues/25270

In D15865#1126691, @zlei wrote:

In D15865#1126562, @editor_callfortesting.org wrote:

From the Jails Production User call: This work is still of interest, particularly in the context of OCI jail progress.
DCH: "This needs serious rebasing." Do any developers have interest in this feature?

I think @dfr is interested with this :)

Review feedback

Addressed review feedback.

Review feedback

Committed without remembering to add 'Differential Revision'

Committed without remembering to add 'Differential Revision'

Committed without remembering to add 'Differential Revision'

Committed without remembering to add 'Differential Revision'

Committed without remembering to add 'Differential Revision'

After further testing, I came across a regression in 'podman build' and 'buildah build' which I will get fixed upstream (https://github.com/containers/common/pull/2326). I will add that as patches to the buildah and podman ports and test a bit more before I ship this.

In D48869#1114602, @osa wrote:

Here's the patch{F109555392}

In D48869#1114547, @osa wrote:

The patch introduces new dependency - sysutils/catatonit; the current version in the ports tree is 0.1.7, latest one is 0.2.1. Is there any plans to update the port to the recent version?

I've taken a look on the version 0.2.1 of the catatonit. Your patches in the freebsd branch look good, however there's a small change in the distribution:

--- catatonit.c
+++ catatonit.c
-#ifdef HAVE_CLOSE_RANGE
+#ifdef HAVE_LINUX_CLOSE_RANGE_H

So, I've applied both of your patches, fix the rejection and built new version. Hope that can be updated as well.

Combined your patches into one here.

In D48869#1114547, @osa wrote:

The patch introduces new dependency - sysutils/catatonit; the current version in the ports tree is 0.1.7, latest one is 0.2.1. Is there any plans to update the port to the recent version?

Looks good

Looks good to me. It would also be nice to have something similar for ip6addrctl to make it easier to have different address selection policies in vnet jails (e.g. host is dual stack and prefers IPv6 but jail only has IPv4 and should prefer IPv4 replies to DNS lookups).

This version also sets a default command of "/bin/sh" for the minimal image which is common practice for Linux base images but perhaps that should be separated out.

Are there any other concerms for this one - I would like to land it and move onto the shell-based container image build.

Override PATH for make-oci-image.sh so that we get pwd_mkdb from the cross tools rather than the host.

I tested this for amd64, i386, aarch64 and riscv64 and the metadata is correct.

In D47941#1093574, @osa wrote:

In D47941#1093322, @bofh wrote:

Why not upgrade to 1.17.0 instead of just patching these 2 files?

My understanding is every podman release has multiple components, and here's the quote for v5.2.5:

Updated Buildah to v1.37.5
Updated the containers/storage library to v1.55.1

It seems like that versions of those components are need to be in sync.
@dfr please correct my if I'm wrong.

Also, I've tried to upgrade podman and components to the recent versions, but I've got an issue with the recent version of podman v.5.3.1, so decision was made to upgrade to the more or less "working" version.

In D47941#1093322, @bofh wrote:

Why not upgrade to 1.17.0 instead of just patching these 2 files?

Thanks for clearing this up!

This is great, thanks!

LGTM

LGTM

LGTM

LGTM

Thanks for working on this. In the past, I have usually tried to update all the podman-suite ports as a group, mainly to make sure that manpages shared by podman and buildah (which live in sysutils/containers-common) don't get stale. On the other hand, I don't think there is any harm upgrading podman and buildah separately - I can follow up with containers-common later.

In D47668#1087193, @jlduran wrote:

Another +1.
Testing here using podman to inject metadata into containers, something similar to the original motivation.
Regarding the restrictions for reading the sysctl from inside the jail, I have no strong opinions, and fully trust your judgement (based on current names, most likely allow.read_meta, as I would interpret allow.metadata as being able to set metadata from inside the jail).

I'm going to land this now with a short MFC timer. Still trying to figure out why current doesn't need this.

In D47661#1086713, @emaste wrote:

Indeed FreeBSD-pkg-bootstrap should presumably depend on these three

Move the OCI image bits to Makefile.oci and don't treat them as distribution artifacts. If enabled, the OCI images are written to ${DESTDIR}/ociimages.

In D46759#1078518, @cperciva wrote:

I think what we really want here is a Makefile.oci and oci-release/oci-install targets which get run from the release and install targets in release/Makefile.

Rebase, address review feedback.

LGTM - thanks for working on this. I think lib9p can support a socket-based transport which allows for testing lib9p itself. In the kernel there is an attempt at an abstraction layer but I think that its only ever been used with virtio,

Rebase, address review feedback

Rebase and address feedback from cperciva

Fix spelling of OCI

Rebase to pick up spelling fix to release.7

Clarify the language around OCI, making clear that this change adds
container images rather than anything Oracle related and renaming the
build artifacts from oci-*.tgz to container-image-*.tgz. Also set the
default command for the minimal shell image to /bin/sh similar to many
Linux distribution base images.

In D46759#1065924, @lwhsu wrote:

I have a small concern that is under release there are two different concepts using the same name OCI, Oracle Cloud Image/Infrastructure and Open Container Initiative. I am not sure if this really makes people confusing but it seems better if we can avoid this conflict.

This needs buildah and skopeo to be installed into the release chroot. Currently, its setup to build from the /usr/ports if that is present, similar to other tools such as git - this might not be a great idea since buildah and slopeo will pull in go, llvm and openjdk as build dependencies. When testing, I mostly used NOPORTS so that they would be installed using pkg.

LGTM