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

Looks good. The web UI isn't allowing me to mark this as accepted for some reason but I'll merge it anyway.

In D41844#992483, @val_packett.cool wrote:

In D41844#992328, @editor_callfortesting.org wrote:

Can we land this without an aggressive MFC and test in CURRENT before the review goes stale?

+1. Will be a lot easier for me to submit my patches then. With those, it almost works well enough for me, the only thing missing is mmap'ed writes.

Rebase, update version to 6.5.0

Looks good to me.

Looks good, thanks!

Rebase

Rebase, update podman to 4.8.3

In D43121#988088, @dch wrote:

not sure what's missing but this fails on arm64. BTW if it helps I have one you can borrow as needed.

===>   buildah-1.33.2 depends on shared library: libgpgme.so - found (/usr/local/lib/libgpgme.so)
===>   Returning to build of buildah-1.33.2
===========================================================================
=======================<phase: configure      >============================
===== env: NO_DEPENDS=yes USER=dch UID=1002 GID=0
===>  Configuring for buildah-1.33.2
===========================================================================
=======================<phase: build          >============================
===== env: NO_DEPENDS=yes USER=dch UID=1002 GID=0
===>  Building for buildah-1.33.2
gmake[1]: Entering directory '/wrkdirs/usr/ports/sysutils/buildah/work/buildah-1.33.2'
gmake[1]: git: No such file or directory
rm -f internal/mkcw/embed/entrypoint.gz
gzip -k internal/mkcw/embed/entrypoint
gzip: can't stat: internal/mkcw/embed/entrypoint: No such file or directory
gmake[1]: *** [Makefile:86: internal/mkcw/embed/entrypoint.gz] Error 1
gmake[1]: Leaving directory '/wrkdirs/usr/ports/sysutils/buildah/work/buildah-1.33.2'
*** Error code 1

Looks good to me - the paragraphs I edited may need reformatting since I probably didn't estimate the 72 column mark consistently.

Fix for devel/bazel5 is merged in D42729. I will make a new diff for fixing devel/bazel which will also update to the current release version, 6.4.0.