Merge branch 'main' into add-cncf-slack

jeckersb · web-flow · commit b03053a1a6f6 · 2025-05-27T11:44:31.000-04:00
diff --git a/Cargo.lock b/Cargo.lock
diff --git a/README.md b/README.md
@@ -26,6 +26,14 @@ can be upgraded in place seamlessly across any future changes.
 
 See the [project documentation](https://bootc-dev.github.io/bootc/).
 
+## Versioning
+
+Although bootc is not released to crates.io as a library, version
+numbers are expected to follow [semantic
+versioning](https://semver.org/) standards.  This practice began with
+the release of version 1.2.0; versions prior may not adhere strictly
+to semver standards.
+
 ## Adopters (base and end-user images)
 
 The bootc CLI is just a client system; it is not tied to any particular
@@ -47,6 +55,7 @@ Are you interested in working on bootc?  Great!  See our [CONTRIBUTING.md](CONTR
 There is also a list of [MAINTAINERS.md](MAINTAINERS.md).
 
 ## Governance
+See [GOVERNANCE.md](GOVERNANCE.md) for project governance details.
 
 ## Badges
 
diff --git a/blockdev/Cargo.toml b/blockdev/Cargo.toml
@@ -5,7 +5,7 @@ publish = false
 edition = "2021"
 license = "MIT OR Apache-2.0"
 name = "bootc-blockdev"
-repository = "https://github.com/containers/bootc"
+repository = "https://github.com/bootc-dev/bootc"
 version = "0.0.0"
 
 [dependencies]
diff --git a/cli/Cargo.toml b/cli/Cargo.toml
@@ -3,7 +3,7 @@ name = "bootc"
 version = "0.1.9"
 edition = "2021"
 license = "MIT OR Apache-2.0"
-repository = "https://github.com/containers/bootc"
+repository = "https://github.com/bootc-dev/bootc"
 readme = "README.md"
 publish = false
 default-run = "bootc"
diff --git a/contrib/packaging/bootc.spec b/contrib/packaging/bootc.spec
@@ -25,7 +25,7 @@ Summary:        Bootable container system
 # MIT OR Apache-2.0
 # Unlicense OR MIT
 License:        Apache-2.0 AND BSD-3-Clause AND MIT AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT) AND (Unlicense OR MIT)
-URL:            https://github.com/containers/bootc
+URL:            https://github.com/bootc-dev/bootc
 Source0:        %{url}/releases/download/v%{version}/bootc-%{version}.tar.zstd
 Source1:        %{url}/releases/download/v%{version}/bootc-%{version}-vendor.tar.zstd
 
diff --git a/docs/_config.yml b/docs/_config.yml
@@ -33,7 +33,7 @@ color_scheme: coreos
 # Aux links for the upper right navigation
 aux_links:
   "bootc on GitHub":
-    - "https://github.com/containers/bootc"
+    - "https://github.com/bootc-dev/bootc"
 
 footer_content: "Copyright &copy; <a href=\"https://www.redhat.com\">Red Hat, Inc.</a> and <a href=\"https://github.com/containers\">others</a>."
 
@@ -44,7 +44,7 @@ last_edit_time_format: "%b %e %Y at %I:%M %p"
 # Footer "Edit this page on GitHub" link text
 gh_edit_link: true
 gh_edit_link_text: "Edit this page on GitHub"
-gh_edit_repository: "https://github.com/containers/bootc"
+gh_edit_repository: "https://github.com/bootc-dev/bootc"
 gh_edit_branch: "main"
 gh_edit_source: docs
 gh_edit_view_mode: "tree"
diff --git a/docs/src/bootc-images.md b/docs/src/bootc-images.md
@@ -13,7 +13,7 @@ requirements.
 
 ## ostree-in-container
 
-With [bootc 1.1.3](https://github.com/containers/bootc/releases/tag/v1.1.3)
+With [bootc 1.1.3](https://github.com/bootc-dev/bootc/releases/tag/v1.1.3)
 or later, it is no longer required to have a `/ostree` directory
 present in the base image.
 
@@ -34,7 +34,7 @@ which is used by the [Fedora base image](https://gitlab.com/fedora/bootc/base-im
 
 ## Standard image content
 
-The bootc project provides a [baseimage](https://github.com/containers/bootc/tree/main/baseimage) reference
+The bootc project provides a [baseimage](https://github.com/bootc-dev/bootc/tree/main/baseimage) reference
 set of configuration files for base images. In particular at
 the current time the content defined by `base` must be used
 (or recreated). There is also suggested integration there with
diff --git a/docs/src/building/guidance.md b/docs/src/building/guidance.md
@@ -62,7 +62,7 @@ inside the container image filesystem itself.
 
 Special care and code changes will need to be made to container
 runtimes to support such nesting.  Some more discussion in
-[this tracker issue](https://github.com/containers/bootc/issues/128).
+[this tracker issue](https://github.com/bootc-dev/bootc/issues/128).
 
 ## systemd units
 
diff --git a/docs/src/experimental-bootc-image.md b/docs/src/experimental-bootc-image.md
@@ -3,7 +3,7 @@
 Experimental features are subject to change or removal. Please
 do provide feedback on them.
 
-Tracking issue: <https://github.com/containers/bootc/issues/690>
+Tracking issue: <https://github.com/bootc-dev/bootc/issues/690>
 
 ## Using `bootc image copy-to-storage`
 
diff --git a/docs/src/experimental-progress-fd.md b/docs/src/experimental-progress-fd.md
@@ -1,7 +1,7 @@
 
 # Interactive progress with `--progress-fd`
 
-This is an experimental feature; tracking issue: <https://github.com/containers/bootc/issues/1016>
+This is an experimental feature; tracking issue: <https://github.com/bootc-dev/bootc/issues/1016>
 
 While the `bootc status` tooling allows a client to discover the state
 of the system, during interactive changes such as `bootc upgrade`
diff --git a/docs/src/filesystem-sysroot.md b/docs/src/filesystem-sysroot.md
@@ -37,7 +37,7 @@ This storage is accessible via a `/usr/lib/bootc/storage` symbolic link which po
 `/sysroot`. (Avoid directly referencing the `/sysroot` target)
 
 At the current time, this storage is *not* used for the base bootable image.
-This [unified storage issue](https://github.com/containers/bootc/issues/20) tracks unification.
+This [unified storage issue](https://github.com/bootc-dev/bootc/issues/20) tracks unification.
 
 ## Expanding the root filesystem
 
diff --git a/docs/src/filesystem.md b/docs/src/filesystem.md
@@ -1,7 +1,7 @@
 # Filesystem
 
 As noted in other chapters, the bootc project currently
-depends on [ostree project](https://github.com/ostreedev/ostree/)
+depends on the [ostree project](https://github.com/ostreedev/ostree/)
 for storing the base container image. Additionally there is a [containers/storage](https://github.com/containers/storage) instance for [logically bound images](logically-bound-images.md).
 
 However, bootc is intending to be a "fresh, new container-native interface",
@@ -32,7 +32,7 @@ The rest of this document describes the state of the system when
 
 bootc uses ostree, which currently [squashes all timestamps to zero](https://ostreedev.github.io/ostree/repo/#content-objects).
 This is now viewed as an implementation bug and will be changed in the future.
-For more information, see [this tracker issue](https://github.com/containers/bootc/issues/20).
+For more information, see [this tracker issue](https://github.com/bootc-dev/bootc/issues/20).
 
 ## Understanding physical vs logical root with `/sysroot`
 
@@ -95,7 +95,7 @@ Some other image-based update systems do not have distinct "versions" of `/etc`
 it may be populated only set up at install time, and untouched thereafter.  But
 that creates "hysteresis" where the state of the system's `/etc` is strongly
 influenced by the initial image version.  This can lead to problems
-where e.g. a change to `/etc/sudoers.conf` (to give on simple example)
+where e.g. a change to `/etc/sudoers` (to give one simple example)
 would require external intervention to apply.
 
 For more on configuration file best practices, see [Building](building/guidance.md).
diff --git a/docs/src/intro.md b/docs/src/intro.md
@@ -16,9 +16,8 @@ systemd is in use, systemd acts as pid1 as usual - there's no "outer" process.
 
 # Status
 
-At the current time, bootc has not reached 1.0, and it is possible
-that some APIs and CLIs may change.  For more information, see
-the [1.0 milestone](https://github.com/containers/bootc/milestone/1).
+The CLI and API for bootc are now considered stable. Every existing system
+can be upgraded in place seamlessly across any future changes.
 
 However, the core underlying code uses the [ostree](https://github.com/ostreedev/ostree)
 project which has been powering stable operating system updates for
diff --git a/docs/src/logically-bound-images.md b/docs/src/logically-bound-images.md
@@ -13,7 +13,7 @@ These types of things are commonly not updated outside of the host, and there's
 
 Another simple way to say this is that logically bound images allow you to reference container images with the same confidence you can with `ExecStart=` in a systemd unit.
 
-The term "logically bound" was created to contrast with [physically bound](https://github.com/containers/bootc/issues/644) images. There are some trade-offs between the two approaches. Some benefits of logically bound images are:
+The term "logically bound" was created to contrast with [physically bound](https://github.com/bootc-dev/bootc/issues/644) images. There are some trade-offs between the two approaches. Some benefits of logically bound images are:
 
 - The bootc system image can be updated without re-downloading the app image bits.
 - The app images can be updated without modifying the bootc system image, this would be especially useful for development work
diff --git a/docs/src/relationship-particles.md b/docs/src/relationship-particles.md
@@ -281,7 +281,7 @@ But still: the bootc project will again much more strongly push any scenario tha
 In "unlocked" scenarios, the bootc project will continue to support a "traditional Unix" feeling where persistent changes to `/etc` can be written and maintained.  Similarly, it will continue to be supported to have machine-local kernel arguments.
 There is significant value in migrating "package based" systems to "image based" systems, even if they are still "unsigned" or "unlocked".
 
-The particle model calls for tools like [confext](https://uapi-group.org/specifications/specs/extension_image/#confext-configuration-extension) that use DDIs.  The "backend" of this (managing merged dynamic filesystem trees with overlayfs) and its relationship with systemd units is still relevant, but the bootc approach will again not expose DDIs to the user.  Instead, our approach will take cues from the cloud-native world and use e.g. [Kubernetes ConfigMap](https://github.com/containers/bootc/issues/22) and support signatures on these.
+The particle model calls for tools like [confext](https://uapi-group.org/specifications/specs/extension_image/#confext-configuration-extension) that use DDIs.  The "backend" of this (managing merged dynamic filesystem trees with overlayfs) and its relationship with systemd units is still relevant, but the bootc approach will again not expose DDIs to the user.  Instead, our approach will take cues from the cloud-native world and use e.g. [Kubernetes ConfigMap](https://github.com/bootc-dev/bootc/issues/22) and support signatures on these.
 
 ## More Modularity: Secondary OS installs
 
diff --git a/docs/src/relationships.md b/docs/src/relationships.md
@@ -35,7 +35,7 @@ There is a new [bootc-image-builder](https://github.com/osbuild/bootc-image-buil
 
 Just as `podman` does not depend on a Kubernetes API server, `bootc` will also not depend on one.
 
-However, there are also plans for `bootc` to also understand Kubernetes API types.  See [configmap/secret support](https://github.com/containers/bootc/issues/22) for example.
+However, there are also plans for `bootc` to also understand Kubernetes API types.  See [configmap/secret support](https://github.com/bootc-dev/bootc/issues/22) for example.
 
 Perhaps in the future we may actually support some kind of `Pod` analogue for representing the host state.  Or we may define a [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) which can be used inside and outside of Kubernetes.
 
@@ -90,17 +90,17 @@ using `bootc` will be more appealing.  bootc also does not
 e.g. drag in dependencies on `libdnf` and the RPM stack.
 
 bootc also has the benefit of starting as a pure Rust project;
-and while it [doesn't have an IPC mechanism today](https://github.com/containers/bootc/issues/4), the surface
+and while it [doesn't have an IPC mechanism today](https://github.com/bootc-dev/bootc/issues/4), the surface
 of such an API will be significantly smaller.
 
-Further, bootc does aim to [include some of the functionality of zincati](https://github.com/containers/bootc/issues/5).
+Further, bootc does aim to [include some of the functionality of zincati](https://github.com/bootc-dev/bootc/issues/5).
 
 But all this said: *It will be supported to use both bootc and rpm-ostree together*; they are not exclusive.
 For example, `bootc status` at least will still function even if packages are layered.
 
 ### Future bootc <-> podman binding
 
-All the above said, it is likely that at some point bootc will switch to [hard binding with podman](https://github.com/containers/bootc/pull/215).
+All the above said, it is likely that at some point bootc will switch to [hard binding with podman](https://github.com/bootc-dev/bootc/pull/215).
 This will reduce the role of ostree, and hence break compatibility with rpm-ostree.
 When such work lands, we will still support at least a "one way" transition from an
 ostree backend.  But once this happens there are no plans to teach rpm-ostree
diff --git a/lib/Cargo.toml b/lib/Cargo.toml
@@ -4,7 +4,7 @@ edition = "2021"
 license = "MIT OR Apache-2.0"
 name = "bootc-lib"
 readme = "README.md"
-repository = "https://github.com/containers/bootc"
+repository = "https://github.com/bootc-dev/bootc"
 # The intention is we'll follow semver here, even though this
 # project isn't actually published as a crate.
 version = "1.2.0"
diff --git a/lib/src/boundimage.rs b/lib/src/boundimage.rs
@@ -1,6 +1,6 @@
 //! # Implementation of "logically bound" container images
 //!
-//! This module implements the design in <https://github.com/containers/bootc/issues/128>
+//! This module implements the design in <https://github.com/bootc-dev/bootc/issues/128>
 //! for "logically bound" container images. These container images are
 //! pre-pulled (and in the future, pinned) before a new image root
 //! is considered ready.
diff --git a/lib/src/cli.rs b/lib/src/cli.rs
@@ -1012,6 +1012,8 @@ pub fn global_init() -> Result<()> {
         // This shouldn't ever happen
         eprintln!("failed to set name: {e}");
     }
+    // Silence SELinux log warnings
+    ostree::SePolicy::set_null_log();
     let am_root = rustix::process::getuid().is_root();
     // Work around bootc-image-builder not setting HOME, in combination with podman (really c/common)
     // bombing out if it is unset.
diff --git a/lib/src/fsck.rs b/lib/src/fsck.rs
@@ -95,7 +95,7 @@ impl FsckCheck {
 #[distributed_slice(FSCK_CHECKS)]
 static CHECK_RESOLVCONF: FsckCheck =
     FsckCheck::new("etc-resolvconf", 5, FsckFnImpl::Sync(check_resolvconf));
-/// See https://github.com/containers/bootc/pull/1096 and https://github.com/containers/bootc/pull/1167
+/// See https://github.com/bootc-dev/bootc/pull/1096 and https://github.com/containers/bootc/pull/1167
 /// Basically verify that if /usr/etc/resolv.conf exists, it is not a zero-sized file that was
 /// probably injected by buildah and that bootc should have removed.
 ///
diff --git a/lib/src/imgstorage.rs b/lib/src/imgstorage.rs
@@ -123,7 +123,7 @@ fn new_podman_cmd_in(storage_root: &Dir, run_root: &Dir) -> Result<Command> {
 }
 
 /// Ensure that "podman" is the first thing to touch the global storage
-/// instance. This is a workaround for https://github.com/containers/bootc/pull/1101#issuecomment-2653862974
+/// instance. This is a workaround for https://github.com/bootc-dev/bootc/pull/1101#issuecomment-2653862974
 /// Basically podman has special upgrade logic for when it is the first thing
 /// to initialize the c/storage instance it sets the networking to netavark.
 /// If it's not the first thing, then it assumes an upgrade scenario and we
diff --git a/lib/src/install.rs b/lib/src/install.rs
@@ -160,7 +160,7 @@ pub(crate) enum BoundImagesOpt {
     #[clap(hide = true)]
     /// Do not resolve any "logically bound" images at install time.
     Skip,
-    // TODO: Once we implement https://github.com/containers/bootc/issues/863 update this comment
+    // TODO: Once we implement https://github.com/bootc-dev/bootc/issues/863 update this comment
     // to mention source's root container storage being used as lookaside cache
     /// Bound images will be pulled and stored directly in the target's bootc container storage
     Pull,
diff --git a/lib/src/lints.rs b/lib/src/lints.rs
@@ -419,7 +419,7 @@ fn check_kernel(root: &Dir) -> LintResult {
     lint_ok()
 }
 
-// This one can be lifted in the future, see https://github.com/containers/bootc/issues/975
+// This one can be lifted in the future, see https://github.com/bootc-dev/bootc/issues/975
 #[distributed_slice(LINTS)]
 static LINT_UTF8: Lint = Lint {
     name: "utf8",
diff --git a/mount/Cargo.toml b/mount/Cargo.toml
@@ -5,7 +5,7 @@ publish = false
 edition = "2021"
 license = "MIT OR Apache-2.0"
 name = "bootc-mount"
-repository = "https://github.com/containers/bootc"
+repository = "https://github.com/bootc-dev/bootc"
 version = "0.0.0"
 
 [dependencies]
diff --git a/ostree-ext/Cargo.toml b/ostree-ext/Cargo.toml
@@ -14,7 +14,7 @@ version = "0.15.3"
 # semver here you must also bump our semver.
 containers-image-proxy = "0.7.0"
 # We re-export this library too.
-ostree = { features = ["v2025_1"], version = "0.20.0" }
+ostree = { features = ["v2025_2"], version = "0.20" }
 
 # Private dependencies
 anyhow = { workspace = true }
diff --git a/ostree-ext/README.md b/ostree-ext/README.md
@@ -11,7 +11,7 @@ to let us know.
 
 At the moment, the following projects are known to use this crate:
 
-- https://github.com/containers/bootc
+- https://github.com/bootc-dev/bootc
 - https://github.com/coreos/rpm-ostree
 
 The intention of this crate is to be where new high level ostree-related features
diff --git a/system-reinstall-bootc/Cargo.toml b/system-reinstall-bootc/Cargo.toml
@@ -3,7 +3,7 @@ name = "system-reinstall-bootc"
 version = "0.1.9"
 edition = "2021"
 license = "MIT OR Apache-2.0"
-repository = "https://github.com/containers/bootc"
+repository = "https://github.com/bootc-dev/bootc"
 readme = "README.md"
 publish = false
 # For now don't bump this above what is currently shipped in RHEL9.
diff --git a/system-reinstall-bootc/src/podman.rs b/system-reinstall-bootc/src/podman.rs
@@ -60,7 +60,7 @@ pub(crate) fn reinstall_command(image: &str, ssh_key_file: &str) -> Result<Comma
         "to-existing-root",
         // The user already knows they're reinstalling their machine, that's the entire purpose of
         // this binary. Since this is no longer an "arcane" bootc command, we can safely avoid this
-        // timed warning prompt. TODO: Discuss in https://github.com/containers/bootc/discussions/1060
+        // timed warning prompt. TODO: Discuss in https://github.com/bootc-dev/bootc/discussions/1060
         "--acknowledge-destructive",
         // The image is always pulled first, so let's avoid requiring the credentials to be baked
         // in the image for this check.
diff --git a/system-reinstall-bootc/src/prompt.rs b/system-reinstall-bootc/src/prompt.rs
diff --git a/utils/Cargo.toml b/utils/Cargo.toml
