Merge pull request #1325 from jeckersb/move-from-containers-org

Rewrite containers org links to bootc-dev org

Author: cgwalters

README.md

@@ -34,7 +34,7 @@ start by looking at [ADOPTERS.md](ADOPTERS.md).
 
 ## Community discussion
 
-The [GitHub discussion forum](https://github.com/containers/bootc/discussions) is enabled.
+The [GitHub discussion forum](https://github.com/bootc-dev/bootc/discussions) is enabled.
 
 This project is also tightly related to the previously mentioned Fedora/CentOS bootc project,
 and many developers monitor the relevant discussion forums there. In particular there's a

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]

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"

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
 

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"

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

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
 

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`
 

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`

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
 

docs/src/filesystem.md

@@ -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`
 

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

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
 

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

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"

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.

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.
 ///

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

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,

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",

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]

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

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.

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.

system-reinstall-bootc/src/prompt.rs

@@ -67,7 +67,7 @@ pub(crate) fn reboot() -> Result<()> {
 }
 
 /// Temporary safety mechanism to stop devs from running it on their dev machine. TODO: Discuss
-/// final prompting UX in https://github.com/containers/bootc/discussions/1060
+/// final prompting UX in https://github.com/bootc-dev/bootc/discussions/1060
 pub(crate) fn temporary_developer_protection_prompt() -> Result<()> {
     // Print an empty line so that the warning stands out from the rest of the output
     println!();

utils/Cargo.toml

@@ -4,7 +4,7 @@ publish = false
 version = "0.0.0"
 edition = "2021"
 license = "MIT OR Apache-2.0"
-repository = "https://github.com/containers/bootc"
+repository = "https://github.com/bootc-dev/bootc"
 
 [dependencies]
 anyhow = { workspace = true }