Ublue Aurora Custom Image

Development environment: https://docs.projectbluefin.io/bluefin-dx

Terminal setup: https://docs.projectbluefin.io/command-line/

Rebasing: https://docs.projectbluefin.io/administration/

Custom Images:

Images for NVIDIA and non-NVIDIA at: https://github.com/whelanh/myAurora

OneDrive:

brew install onedrive
# type onedrive to register/connect with your MSft OneDrive account
brew services start onedrive

Tailscale:

Already installed in Aurora
tailscale up --ssh # flag permits ssh access
tailscale ssh <tailscale node name>

Toolbox (good pattern: use to compile Stockfish...but can now do in custom image):

toolbox create
toolbox enter
sudo dnf groupinstall "Development Tools"
sudo dnf in gcc-c++

Cron Replacement: https://fedoramagazine.org/systemd-timers-for-scheduling-tasks/

systemctl --user stop schedule-test.timer
systemctl --user disable schedule-test.timer
systemctl --user stop schedule-test.service
systemctl --user disable schedule-test.service
systemctl --user daemon-reload
systemctl --user reset-failed

systemctl --user enable schedule-test.service
systemctl --user enable schedule-stockfish.service
systemctl --user enable schedule-test.timer
systemctl --user enable schedule-test-two.timer
systemctl --user enable schedule-stockfish.timer

systemctl --user start schedule-test.timer
systemctl --user start schedule-test-two.timer
systemctl --user start schedule-stockfish.timer
systemctl --user status schedule-test
systemctl --user list-unit-files

To update all distrobox apps:

distrobox upgrade --all

Rstudio (now part of my custom image)

Chezmoi (for managing dotfiles):

https://chezmoi.io/quick-start/

Setting Up KDE Builder (to compile your own KDE Plasma)

From: https://blues.win/posts/kde-dev-bazzite/

The magic that makes containerization a viable strategy for KDE development is Distrobox. In their own words:

Distrobox uses podman, docker or lilipod to create containers using the Linux distribution of your choice. The created container will be tightly integrated with the host, allowing sharing of the $HOME directory of the user, external storage, external USB devices and graphical apps (X11/Wayland), and audio.

Bazzite is based on Fedora, so we plan to create a Fedora distrobox. In the container, we will install all of our development tools and then build KDE from source. The resulting artifacts will be available outside of the container back on the host system.

To reduce some friction, I've created a Fedora-based Docker image that contains all of the necessary KDE development packages. It is available via the GitHub Container Registry.

sudo mkdir -p /var/local/kde-dev/{home,kde}
sudo chown $(id -u):$(id -u) /var/local/kde-dev/{home,kde}

mkdir -p /var/local/kde-dev/home/.config
cp ./kde-builder.yaml /var/local/kde-dev/home/.config

distrobox create \
	--name kde-dev \
	--home /var/local/kde-dev/home \
	--volume /var/local/kde-dev/kde:/var/local/kde-dev/kde:Z \
	--init \
	--additional-packages "systemd" \
	--pull \
	--image ghcr.io/ledif/ublue-kde-dev:latest

In the above configuration, we have a directory tree in /var/local/kde-dev for the source files, the intermediate build files and the final /usr directory tree representing the entire desktop environment. We also create a separate home directory for the container, just so that our Bash history and profiles are not intermixed with those on the host.

/var/local/kde-dev
├── home
│   ├── .config
│   │   ├── kde-builder.yaml
│   ├── .local
│   │   ├── share
│   │   └── state
└── kde
    ├── build
    ├── log
    ├── src
    └── usr
        ├── bin
        ├── etc
        ├── include
        ├── lib
        ├── lib64
        ├── libexec
        ├── mkspecs
        └── share

The provided kde-builder.yml file tells the KDE build system to utilize the shared /var/local/kde-dev/kde directory.

After this is set up, you can then enter into the container and build KDE Plasma.

distrobox enter kde-dev
kde-builder workspace

It will definitely take a long time to compile, so consider taking a nice stroll around the neighborhood in the meantime.

Running Your Own Plasma

After the entire project finishes building, the build artifacts will be available on the host in /var/local/kde-dev/kde/usr. But, how can we run it?

We first need to tell SDDM about it, which means adding a session to /usr/share/wayland-sessions. But how can we add our KDE development session to /usr if it is read-only? Fortunately, there is one exception to the whole /usr being immutable thing:

❯ ls -l /usr/local
lrwxrwxrwx. 6 root root 15 Mar  5  2024 /usr/local -> ../var/usrlocal

/usr/local is actually a symbolic link to the writeable /var/usrlocal directory! Since SDDM can pick up sessions in /usr/local/share/wayland-sessions, we can actually add our session there with little fuss.

cat << EOF > /tmp/plasmawayland-dev6.desktop
[Desktop Entry]
Exec=/var/local/kde-dev/kde/usr/lib64/libexec/plasma-dbus-run-session-if-needed /var/local/kde-dev/kde/usr/lib64/libexec/startplasma-dev.sh -wayland
DesktopNames=KDE
Name=Plasma (Dev)
Comment=Plasma Development by KDE
X-KDE-PluginInfo-Version=6.4.4
EOF

sudo mkdir -p /usr/local/share/wayland-sessions
sudo mv /tmp/plasmawayland-dev6.desktop /usr/local/share/wayland-sessions

Now, you can log out of your session and pick the new "Plasma (Dev)" choice to run your fresh-from-source farm-to-table newly built KDE Plasma.