SOURCES/Containerfile.5.md

@@ -9,7 +9,7 @@ Containerfile(Dockerfile) - automate the steps of creating a container image
 The **Containerfile** is a configuration file that automates the steps of creating a container image. It is similar to a Makefile. Container engines (Podman, Buildah, Docker) read instructions from the **Containerfile** to automate the steps otherwise performed manually to create an image. To build an image, create a file called **Containerfile**.
 
 The **Containerfile** describes the steps taken to assemble the image. When the
-**Containerfile** has been created, call the `buildah bud`, `podman build`, `docker build` command,
+**Containerfile** has been created, call the `buildah build`, `podman build`, `docker build` command,
 using the path of context directory that contains **Containerfile** as the argument. Podman and Buildah default to **Containerfile** and will fall back to **Dockerfile**. Docker only will search for **Dockerfile** in the context directory.
 
 
@@ -31,7 +31,7 @@ A Containerfile is similar to a Makefile.
 # USAGE
 
   ```
-  buildah bud .
+  buildah build .
   podman build .
   ```
 
@@ -40,7 +40,7 @@ A Containerfile is similar to a Makefile.
   build.
 
   ```
-  buildah bud -t repository/tag .
+  buildah build -t repository/tag .
   podman build -t repository/tag .
   ```
 
@@ -109,7 +109,7 @@ Current supported mount TYPES are bind, cache, secret and tmpfs.
 
        e.g.
 
-       mount=type=bind,source=/path/on/host,destination=/path/in/container
+       mount=type=bind,source=/path/on/host,destination=/path/in/container,relabel=shared
 
        mount=type=tmpfs,tmpfs-size=512M,destination=/path/in/container
 
@@ -131,6 +131,18 @@ Current supported mount TYPES are bind, cache, secret and tmpfs.
 
 	      · from: stage or image name for the root of the source. Defaults to the build context.
 
+	      · relabel=shared, z: Relabels src content with a shared label.
+
+	      . relabel=private, Z: Relabels src content with a private label.
+
+	      Labeling systems like SELinux require proper labels on the bind mounted content mounted into a container. Without a label, the security system might prevent the processes running in side the container from using the content. By default, container engines do not change the labels set by the OS. The relabel flag tells the engine to relabel file objects on the shared mountz.
+
+	      The relabel=shared and z options tell the engine that two or more containers will share the mount content. The engine labels the content with a shared content label.
+
+	      The relabel=private and Z options tell the engine to label the content with a private unshared label. Only the current container can use a private mount.
+
+	      Relabeling walks the file system under the mount and changes the label on each file, if the mount has thousands of inodes, this process takes a long time, delaying the start of the container.
+
 	      · rw, read-write: allows writes on the mount.
 
        Options specific to tmpfs:
@@ -207,7 +219,7 @@ Container engines pass secret the secret file into the build using the `--secret
 
 **--mount**=*type=secret,TYPE-SPECIFIC-OPTION[,...]*
 
-- `id` is the identifier for the secret passed into the `buildah bud --secret` or `podman build --secret`. This identifier is associated with the RUN --mount identifier to use in the Containerfile.
+- `id` is the identifier for the secret passed into the `buildah build --secret` or `podman build --secret`. This identifier is associated with the RUN --mount identifier to use in the Containerfile.
 
 - `dst`|`target`|`destination` rename the secret file to a specific file in the Containerfile RUN command to use.
 
@@ -224,7 +236,7 @@ RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar
 The secret needs to be passed to the build using the --secret flag. The final image built does not container the secret file:
 
 ```
- buildah bud --no-cache --secret id=mysecret,src=mysecret.txt .
+ buildah build --no-cache --secret id=mysecret,src=mysecret.txt .
 ```
 
   -- The **RUN** instruction executes any commands in a new layer on top of the current
@@ -463,7 +475,7 @@ The secret needs to be passed to the build using the --secret flag. The final im
   In the above example, the output of the **pwd** command is **a/b/c**.
 
 **ARG**
-   -- ARG <name>[=<default value>]
+   -- `ARG <name>[=<default value>]`
 
   The `ARG` instruction defines a variable that users can pass at build-time to
   the builder with the `podman build` and `buildah build` commands using the
@@ -594,6 +606,56 @@ The secret needs to be passed to the build using the --secret flag. The final im
   $ podman build --build-arg HTTPS_PROXY=https://my-proxy.example.com .
   ```
 
+**Platform/OS/Arch ARG**
+   -- `ARG <name>`
+
+  When building multi-arch manifest-lists or images for a foreign-architecture,
+  it's often helpful to have access to platform details within the `Containerfile`.
+  For example, when using a `RUN curl ...` command to install OS/Arch specific
+  binary into the image.  Or, if certain `RUN` operations are known incompatible
+  or non-performant when emulating a specific architecture.
+
+  There are several named `ARG` variables available. The purpose of each should be
+  self-evident by its name.  _However_, in all cases these ARG values are **not**
+  automatically populated.  You must always declare them within each `FROM` section
+  of the `Containerfile`.
+
+  The available `ARG <name>` variables are available with two prefixes:
+
+  * `TARGET...` variable names represent details about the currently running build
+    context (i.e. "inside" the container).  These are often the most useful:
+    * `TARGETOS`: For example `linux`
+    * `TARGETARCH`: For example `amd64`
+    * `TARGETPLATFORM`: For example `linux/amd64`
+    * `TARGETVARIANT`: Uncommonly used, specific to `TARGETARCH`
+  * `BUILD...` variable names signify details about the _host_ performing the build
+    (i.e. "outside" the container):
+    * `BUILDOS`: OS of host performing the build
+    * `BUILDARCH`: Arch of host performing the build
+    * `BUILDPLATFORM`: Combined OS/Arch of host performing the build
+    * `BUILDVARIANT`: Uncommonly used, specific to `BUILDARCH`
+
+  An example `Containerfile` that uses `TARGETARCH` to fetch an arch-specific binary could be:
+
+  ```
+  FROM busybox
+  ARG TARGETARCH
+  RUN curl -sSf -O https://example.com/downloads/bin-${TARGETARCH}.zip
+  ```
+
+  Assuming the host platform is `linux/amd64` and foreign-architecture emulation
+  enabled (e.g. `qemu-user-static`), then running the command:
+
+  ```
+  $ podman build --platform linux/s390x .
+  ```
+
+  Would end up running `curl` on `https://example.com/downloads/bin-s390x.zip` and producing
+  a container image suited for the the `linux/s390x` platform.  **Note:** Emulation isn't
+  strictly required, these special build-args will also function when building using
+  `podman farm build`.
+
+
 **ONBUILD**
   -- `ONBUILD [INSTRUCTION]`
   The **ONBUILD** instruction adds a trigger instruction to an image. The

SOURCES/containers.conf

@@ -734,6 +734,15 @@ runtime = "runc"
 #  "/run/current-system/sw/bin/crun",
 #]
 
+#crun-vm = [
+#  "/usr/bin/crun-vm",
+#  "/usr/local/bin/crun-vm",
+#  "/usr/local/sbin/crun-vm",
+#  "/sbin/crun-vm",
+#  "/bin/crun-vm",
+#  "/run/current-system/sw/bin/crun-vm",
+#]
+
 #kata = [
 #  "/usr/bin/kata-runtime",
 #  "/usr/sbin/kata-runtime",

SOURCES/containers.conf.5.md

@@ -753,9 +753,9 @@ Indicates whether the application should be running in remote mode. This flag mo
 
 Default OCI specific runtime in runtimes that will be used by default. Must
 refer to a member of the runtimes table. Default runtime will be searched for
-on the system using the priority: "crun", "runc", "kata".
+on the system using the priority: "crun", "runc", "runj", "kata", "runsc", "ocijail"
 
-**runtime_supports_json**=["crun", "runc", "kata", "runsc", "youki", "krun"]
+**runtime_supports_json**=["crun", "crun-vm", "runc", "kata", "runsc", "youki", "krun"]
 
 The list of the OCI runtimes that support `--format=json`.
 
@@ -763,7 +763,7 @@ The list of the OCI runtimes that support `--format=json`.
 
 The list of OCI runtimes that support running containers with KVM separation.
 
-**runtime_supports_nocgroups**=["crun", "krun"]
+**runtime_supports_nocgroups**=["crun", "crun-vm", "krun"]
 
 The list of OCI runtimes that support running containers without CGroups.
 

SOURCES/shortnames.conf

@@ -20,6 +20,7 @@
   "registry" = "docker.io/library/registry"
   "swarm" = "docker.io/library/swarm"
   # Fedora
+  "fedora-bootc" = "registry.fedoraproject.org/fedora-bootc"
   "fedora-minimal" = "registry.fedoraproject.org/fedora-minimal"
   "fedora" = "registry.fedoraproject.org/fedora"
   # Gentoo
@@ -56,6 +57,7 @@
   "rhel7" = "registry.access.redhat.com/rhel7"
   "rhel7.9" = "registry.access.redhat.com/rhel7.9"
   "rhel-atomic" = "registry.access.redhat.com/rhel-atomic"
+  "rhel9-bootc" = "registry.redhat.io/rhel9/rhel-bootc"
   "rhel-minimal" = "registry.access.redhat.com/rhel-minimal"
   "rhel-init" = "registry.access.redhat.com/rhel-init"
   "rhel7-atomic" = "registry.access.redhat.com/rhel7-atomic"
@@ -100,7 +102,7 @@
   "ubi9/buildah" = "registry.access.redhat.com/ubi9/buildah"
   "ubi9/skopeo" = "registry.access.redhat.com/ubi9/skopeo"
   # Rocky Linux
-  "rockylinux" = "docker.io/library/rockylinux"
+  "rockylinux" = "quay.io/rockylinux/rockylinux"
   # Debian
   "debian" = "docker.io/library/debian"
   # Kali Linux

SPECS/containers-common.spec

@@ -4,15 +4,15 @@
 # pick the oldest version on c/image, c/common, c/storage vendored in
 # podman/skopeo/podman.
 %global skopeo_branch main
-%global image_branch v5.29.2
+%global image_branch v5.29.3
-%global common_branch v0.57.3
+%global common_branch v0.57.5
 %global storage_branch v1.51.0
 %global shortnames_branch main
 
 Epoch: 2
 Name: containers-common
 Version: 1
-Release: 81%{?dist}
+Release: 82%{?dist}
 Summary: Common configuration and documentation for containers
 License: ASL 2.0
 # arch limitation because of go-md2man (missing on i686)
@@ -175,6 +175,10 @@ EOF
 %{_datadir}/rhel/secrets/*
 
 %changelog
+* Wed Jul 17 2024 Jindrich Novy <jnovy@redhat.com> - 2:1-82
+- update vendored components 
+- Resolves: RHEL-40801
+
 * Wed Feb 14 2024 Jindrich Novy <jnovy@redhat.com> - 2:1-81
 - Update shortnames from Pyxis
 - Related: Jira:RHEL-2110