import containers-common-1-82.module+el8.10.0+22202+761b9a65

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 .
   ```
 
@@ -82,7 +82,7 @@ A Containerfile is similar to a Makefile.
   -- If no digest is given to the **FROM** instruction, container engines apply the
   `latest` tag. If the used tag does not exist, an error is returned.
 
-  -- A name can be assigned to a build stage by adding **AS name** to the instruction. 
+  -- A name can be assigned to a build stage by adding **AS name** to the instruction.
   The name can be referenced later in the Containerfile using the **FROM** or **COPY --from=<name>** instructions.
 
 **MAINTAINER**
@@ -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
 
@@ -117,45 +117,57 @@ Current supported mount TYPES are bind, cache, secret and tmpfs.
 
        Common Options:
 
-              · src, source: mount source spec for bind and volume. Mandatory for bind. If `from` is specified, `src` is the subpath in the `from` field.
+	      · src, source: mount source spec for bind and volume. Mandatory for bind. If `from` is specified, `src` is the subpath in the `from` field.
 
-              · dst, destination, target: mount destination spec.
+	      · dst, destination, target: mount destination spec.
 
-              · ro, read-only: true (default) or false.
+	      · ro, read-only: true (default) or false.
 
        Options specific to bind:
 
-              · bind-propagation: shared, slave, private, rshared, rslave, or rprivate(default). See also mount(2).
+	      · bind-propagation: shared, slave, private, rshared, rslave, or rprivate(default). See also mount(2).
 
-              . bind-nonrecursive: do not setup a recursive bind mount.  By default it is recursive.
+	      . bind-nonrecursive: do not setup a recursive bind mount.  By default it is recursive.
 
-              · from: stage or image name for the root of the source. Defaults to the build context.
+	      · from: stage or image name for the root of the source. Defaults to the build context.
 
-              · rw, read-write: allows writes on the mount.
+	      · 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:
 
-              · tmpfs-size: Size of the tmpfs mount in bytes. Unlimited by default in Linux.
+	      · tmpfs-size: Size of the tmpfs mount in bytes. Unlimited by default in Linux.
 
-              · tmpfs-mode: File mode of the tmpfs in octal. (e.g. 700 or 0700.) Defaults to 1777 in Linux.
+	      · tmpfs-mode: File mode of the tmpfs in octal. (e.g. 700 or 0700.) Defaults to 1777 in Linux.
 
-              · tmpcopyup: Path that is shadowed by the tmpfs mount is recursively copied up to the tmpfs itself.
+	      · tmpcopyup: Path that is shadowed by the tmpfs mount is recursively copied up to the tmpfs itself.
 
 	Options specific to cache:
 
-              · id: Create a separate cache directory for a particular id.
+	      · id: Create a separate cache directory for a particular id.
 
-              · mode: File mode for new cache directory in octal. Default 0755.
+	      · mode: File mode for new cache directory in octal. Default 0755.
 
-              · ro, readonly: read only cache if set.
+	      · ro, readonly: read only cache if set.
 
-              · uid: uid for cache directory.
+	      · uid: uid for cache directory.
 
-              · gid: gid for cache directory.
+	      · gid: gid for cache directory.
 
-              · from: stage name for the root of the source. Defaults to host cache directory.
+	      · from: stage name for the root of the source. Defaults to host cache directory.
 
-              · rw, read-write: allows writes on the mount.
+	      · rw, read-write: allows writes on the mount.
 
 **RUN --network**
 
@@ -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 common_branch v0.57.3
+%global image_branch v5.29.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