Cinnamon DE

[mister-drgn]

It's really cool what you all are doing here. I was just wondering if there's any interest in building a Cinnamon image. I know someone worked on one a couple years ago, but it seems to have fallen by the wayside: https://discussion.fedoraproject.org/t/introducing-fedora-silverblue-cinnamon/30056

Thanks, and apologies if people are sick of hearing, "Why don't you make an image for X?"

[castrojo]

We just need to find a volunteer to maintain it!

[castrojo]

If you'd like access I can just set you as a comaintainer, the best way to a good image is someone actually using it, then you could make it nice and clean.

[mister-drgn]

Sure, I'll give it a shot.

[castrojo]

Ok invite sent, welcome to the team!

The repo is set to not need a +1 from someone else to land a PR so feel free to rev fast and commit. When you feel it's mostly where you want it to be then we can add an approval mechanism for better long term maintenance, thanks for helping out!

[castrojo]

Oh, I forgot we wrote all this down, heh: https://ublue.it/CONTRIBUTING/

[mister-drgn]

So I'm trying out the version of cinnamon that's currently in the main branch. I followed the instructions for building the image locally and installing to a virtual machine, but after rebasing, I wasn't able to boot up--I never reached the display manager.

Then, I tried rebuilding the image, but using quay.io/fedora-ostree-desktops/silverblue:38 as the source image, instead of ghcr.io/ublue-os/base-main:38. It booted up just fine, and I was able to log into the cinnamon DE.

Any ideas what might be in the ublue-os/base-main image that would cause issues for the cinnamon install?

EDIT: I tried the first image again, and again it fails to reach to reach the display manager, but now I'm seeing the following stuck in the upper left corner: "Starting NetworkManager-Dispatcher.service -- Network Manager Script Dispatcher Service..." I don't know if there's an easy way to view all of the output during startup.

EDIT: Ohh, I just realized ghcr.io/ublue-os/base-main:38 is based on quay.io/fedora-ostree-desktops/base:38, so it isn't based on the silverblue image in the first place. I had removed all the packages that were already in silverblue, so that's a problem. I edited my packages.json to put back in all the cinnamon packages, not just the ones that aren't in silverblue. Tried again, and I still can't reach the display manager on startup. I guess I don't know whether the base image even has a display manager (yeah, looks like silverblue has gdm installed, whereas base does not).

EDIT: Oh, the cinnamon install comes with lightdm. Possibly I need that lightdm workaround that's used in ublue-os/budgie, but not in ublue-os/main's mate. Yeah, because if I go into a tty and run "systemctl status display-manager", it tells me lightdm failed to start.

Nice, the lightdm workaround from Budgie fixed it. I've got a working Cinnamon image.

[mister-drgn]

I'm curious what maintaining it would entail. I'm still learning about rpm-ostree, but I took a look at the Budgie setup as an example. It looks like you set up the code for building your image, where the main things are the containerfile and the the json with desired packages (but of course other stuff matters too, like anything you want to add to the etc directory). Then, the git workflow script builds a new version of your image each day by taking the base fedora image and updating it with the latest versions of all the packages you specified. So this process is automated, and people can get daily updates of your image without your actually checking those images. But presumably a good maintainer would download the image most days and at least check that nothing is obviously broken. And then you would make further tweaks to the image as things evolve, e.g., with new versions of fedora.

If I still have your ear, I'll ask another question, since I appreciate the chance to learn more about this stuff. I noticed people complaining about dependency errors when they update base fedora silverblue. These errors apparently occur because some of their layered packages are newer than their silverblue system image, which I'm guessing also gets updated once a day. So a fix for this issue could be to run your updates right after the new silverblue image is released, when presumably it's up to date with all the latest package updates. But a cleaner fix could be to set up a custom rpm-ostree image that already includes all of the packages they might want to layer on, like what you're doing here. So then everything gets updated together when you build the new image, and there's no issue with the system and the layered packages being out of sync.

Someone could hypothetically set up an image like these just for their personal use, with all the packages they care about--maybe that's a lot of trouble if you aren't trying to support other users, but it gives you the advantage of github keeping a history of recent states of your system, for easy rolling back, without the added complication of dealing with layers. And probably even if it starts out being for personal use, people end up sharing over time--that's the linux way.

[castrojo]

But presumably a good maintainer would download the image most days and at least check that nothing is obviously broken. And then you would make further tweaks to the image as things evolve, e.g., with new versions of fedora.

Yeah ideally people are just using the image, once it's set up it's basically automatic, and then adding F39 when those builds start and removing the unsupported version.

These errors apparently occur because some of their layered packages are newer than their silverblue system image, which I'm guessing also gets updated once a day.

Yeah, unfortunately lots of the official documentation encourages layering and adding things to the image, which I don't agree with because it's just "better PPAs". If you layer everything you just end up getting stuck as you would on normal workstation which isn't ideal.

So then everything gets updated together when you build the new image, and there's no issue with the system and the layered packages being out of sync.

Right! So for example if you're on an ublue image you wouldn't be seeing all the issues that everyone else is seeing right now with rpmfusion (r/fedora has just been post after post with people with broken setups because they layered rpmfusion. 😭 )

If there is a problem with rpmfusion (like we've had in the past) the images just don't build and your pc just stays on the last known-good image until it gets a fresh one. So the errors are still there, it's just an extra layer of protection, your client never ends up with a package conflict. One the conflict is fixed the next time it builds and succeeds, THEN your pc gets the update.

Someone could hypothetically set up an image like these just for their personal use, with all the packages they care about--maybe that's a lot of trouble if you aren't trying to support other users, but it gives you the advantage of github keeping a history of recent states of your system, for easy rolling back, without the added complication of dealing with layers. And probably even if it starts out being for personal use, people end up sharing over time--that's the linux way.

Yeah that's part of the reason we did this, if everything is easy to share people will just make good base images and then you'd just pick a high quality one. Plus once it's setup it's mostly automatic, and it's really handy when you have more than one PC as you just have everything "managed" in github. All your clients have your exact perfect setup right from install.

[mister-drgn]

Thanks, this is great. I hadn't thought about that feature--that broken builds never get pushed out, so you never even see them on your local machine.

I'll keep asking questions here, if that's alright, although perhaps I should be asking in the discord. I know one key feature of immutable distros is that the user can still edit their home directory, which is obviously critical for being able to do anything. As I understand it, rpm-ostree never even touches the home directory, although apps may automatically download their config files. However, this seems like an issue if you want to include configuration details in your custom image, for example customizing some add-ons for your desktop environment (e.g., gnome extensions or cinnamon applets).

I feel like there must be a way to do this, so maybe I'm missing something. Either you change the default settings for those add-ons in a system directory, or you include a script or something that writes to the user's home directory? That would also be relevant if you wanted to include particular flatpaks in your custom image, but it seems messy.

[castrojo]

It's ok to ask questions, they get captured here better than in discord. Yeah, we can't touch your home or /usr/local and some other places, they're reserved for users.

The way we're getting around that currently is by doing a post-install config, either via a GUI like yafti to install flatpaks or by shipping just shortcuts. In the past we would just put a custom script in /usr/bin and then do all the post-install steps.

Ideally we'd just list the flatpaks in packages.json and the final image would just have all of that but that's currently not possible, though we may be able to do that in the ISO at some point in the future, we'd just need to figure out how to do that.

[mister-drgn]

Got it. You can do whatever you want in the ISO, hypothetically, but if people rebase off one of your images then they'd need to run a script or something.

Unrelated, one thing about this that excites me is that it uses OCI containers. As I understand it, that means I can treat these like any other container and run them with docker or podman. That's potentially relevant for work because I have colleagues who deploy a complicated system setup to a bunch of machines with ansible. I do dev work using a janky old docker container that replicates what their system looked like 1.5 years ago. I'm planning to catch up by running their ansible script to install their system into a (podman + distrobox, probably) container. But, hypothetically, if I could convince them to use rpm-ostree, then instead they could run an install script on a server to build an image and just deploy that image onto their machines. And then if I want to do dev work on a perfect copy of their system setup, I could just run a container on my computer from that same image.

It's pretty unlikely that all of that would happen--particularly as it would require their switching from ubuntu to fedora--but a guy can dream. In any case, I like the idea that you could use the same image either for your entire system or for a container on your system. Things get complicated if that system itself uses containers, since you can't run a container inside another container, but I've done docker in docker before, and distrobox seems to handle launching new containers outside of your current container well.

[leonardobetti]

hey there castrojo, stumbled upon your channel on Youtube and I think you're doing a great job mate. Just had a quick question: can we use proprietary software to build images? I was thinking of creating a custom version of Fedora Silverblue for UI/UX designers that includes Figma, Penpot within docker, Vscode, Tailscale, Obsidian, Nvidia drivers, Cloudflare DNS, and some private fonts like SF Pro, and all that stuff. I'm also interested in adding realtek wireless drivers rtl8812au, but I'm not sure about the implications of violating the license agreement because most part are not free software. What do you reckon, that could be an issue?

[mister-drgn]

You might want to make a new topic for this question. ublue, unlike official Fedora, does include proprietary software, for example there are versions with nvidia drivers preinstalled.

[castrojo]

I'm not a lawyer but I think stuff for stuff like docker, vscode, tailscale, obsidian, etc. that's just rebundling publically available binaries then you're probably fine. There's prior art with distros shipping non-free binaries, so I don't feel we're doing anything that people haven't been doing for years already.

Private fonts that you paid money for likely have a strict license, I'd probably keep those in a private repo and then copy them over as a post installation thing.