Update origin

README.md

@@ -5,7 +5,7 @@
 > There are breaking changes between this and the previous version.
 > If you are merging changes from the previous (v0) version, please refer to [the heads-up blog post](https://universal-blue.org/blog/2023/09/02/startingpoint-rewrite-heads-up-what-you-need-to-know/).
 
-[![build-ublue](https://github.com/m0ngr31/cabos/actions/workflows/build.yml/badge.svg)](https://github.com/m0ngr31/cabos/actions/workflows/build.yml)
+[![build-ublue](https://github.com/jitcos/cabos/actions/workflows/build.yml/badge.svg)](https://github.com/jitcos/cabos/actions/workflows/build.yml)
 
 This is a constantly updating template repository for creating [a native container image](https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable) designed to be customized however you want. GitHub will build your image for you, and then host it for you on [ghcr.io](https://github.com/features/packages). You then just tell your computer to boot off of that image. GitHub keeps 90 days worth image backups for you, thanks Microsoft!
 
@@ -20,7 +20,7 @@ Don't worry, it only requires some basic knowledge about using the terminal and
 After setup, it is recommended you update this README to describe your custom image.
 
 > **Note**
-> Everywhere in this repository, make sure to replace `m0ngr31/cabos` with the details of your own repository. Unless you used one of the automatic repository setup tools in which case the previous repo identifier should already be your repo's details.
+> Everywhere in this repository, make sure to replace `jitcos/cabos` with the details of your own repository. Unless you used one of the automatic repository setup tools in which case the previous repo identifier should already be your repo's details.
 
 > **Warning**
 > To start, you *must* create a branch called `live` which is exclusively for your customizations. That is the **only** branch the GitHub workflow will deploy to your container registry. Don't make any changes to the original "template" branch. It should remain untouched. By using this branch structure, you ensure a clear separation between your own "published image" branch, your development branches, and the original upstream "template" branch. Periodically sync and fast-forward the upstream "template" branch to the most recent revision. Then, simply rebase your `live` branch onto the updated template to effortlessly incorporate the latest improvements into your own repository, without the need for any messy, manual "merge commits".
@@ -46,15 +46,15 @@ To rebase an existing Silverblue/Kinoite installation to the latest build:
 
 - First rebase to the unsigned image, to get the proper signing keys and policies installed:
   ```
-  rpm-ostree rebase ostree-unverified-registry:ghcr.io/m0ngr31/cabos:latest
+  rpm-ostree rebase ostree-unverified-registry:ghcr.io/jitcos/cabos:latest
   ```
 - Reboot to complete the rebase:
   ```
   systemctl reboot
   ```
 - Then rebase to the signed image, like so:
   ```
-  rpm-ostree rebase ostree-image-signed:docker://ghcr.io/m0ngr31/cabos:latest
+  rpm-ostree rebase ostree-image-signed:docker://ghcr.io/jitcos/cabos:latest
   ```
 - Reboot again to complete the installation
   ```
@@ -64,7 +64,7 @@ To rebase an existing Silverblue/Kinoite installation to the latest build:
 This repository builds date tags as well, so if you want to rebase to a particular day's build:
 
 ```
-rpm-ostree rebase ostree-image-signed:docker://ghcr.io/m0ngr31/cabos:20230403
+rpm-ostree rebase ostree-image-signed:docker://ghcr.io/jitcos/cabos:20230403
 ```
 
 This repository by default also supports signing.

boot_menu.yml

@@ -1,5 +1,5 @@
 ublue_variants:
-  - label: m0ngr31/cabos
+  - label: jitcos/cabos
     ks: /kickstart/ublue-os.ks
     flavors:
       - label: cabos