can someone paste in the architecture diagram for imbev? sorry in a call
can someone paste in the architecture diagram for imbev? sorry in a call
J@Kyle Gospo jeefy at work is like "aww ublue, how cute."
J^^^ CNCF's runners firing on all cylinders today
IWhat I'm seeing as a difference is that ublue is using
ostree container commit
Knot required, that was a recent change
Kthat just does some cleanup prior to layer generation, such as wiping out temporary files
Aostree container commit cleaned var essentially
A
Universal Blue
Hadn’t heard of that specifically, but had herd of similar projects. Didn’t use one, because I didn’t have time to learn one, and I think the results would be less aesthetically pleasing.
Aif you use rechunk it will also clean var so you dont need it
Ai should try to build kinoite using "from fedora"
Athat would be a flex
Afuture plans
II'm thinking of the following:
- Refactor ublue-os/main to
, replace rpm-ostree calls with standard dnf calls. There're a few hacks that need to be done with bootc, but it can otherwise be treated like mutable fedora most of the time within the ContainerfileFROM quay.io/fedora/fedora-bootc:VER - Refactor downstream images in the same way
- The rest might be able to be reused as is
IWould a branch or strangler strategy be preferred?
RWe could, but then we have the added burden of managing package lists for Gnome, KDE etc, which we don't currently do
Right now, we just
Right now, we just
FROM quay.io/fedora-ostree-desktops/{silverblue|kinoite|something}:VERIs there a significant difference between the atomic desktops and the mutable variants using the corresponding package group other than the immutability?
NTimothee would be a good one to ask on that. He is in Matrix in the Atomic desktops channel.
NI don't see him too often in here.
Jhah yeah this is what we're supposed to be doing, we got some repos we cloned as main-bootc, hwe-bootc, etc but I don't think we're using them
JI'm not sure if we need to have a ton of new repos, we could just opportunanistically snag swap the common ones like gnome/kde, as those come online.
IIt'd be simple to switch the base image and remove a
dnf groupinstallhow's the tool song go? save us from our wanton slumber? 
Zi was wondering when we would get to doing this. Very interesting. what does
groupinstall
Nit's a DNF command. There are groups of packages you can install and allows you to install all the ones you need. An example would be like the Gnome DE or KDE DE.
Aif you do that you will get an invalid selinux policy and invalid permissions on your directory tree
Aand it will not boot
II haven't encountered that with bootc, but that might be relevant to rpm-ostree -> bootc migration
Athe reason you ahvent is because youre using an image that has the DE in the commit
Aso it has correct SELinux and correct directory permissions
Aif you make the base commit smaller, such as using an image without a DE it doesn quite work
Athe guys here had this problem with cosmic too
Athey needed to use a workaround for selinux
II don't think that's the case,
dnf list installed | grep -i gnomeand does it boot?
II believe so, but I can confirm that rq
Awhats the link to almalinux
IThat's the base image that I'm using, and that image does not contain a DE
Acan you link me?
R
Afoudn it
Adidnt lol
Aok went through it, its essentially a variant of the fedora-bootc
IConfirmed, it does boot
Awhere is the policy for gnome?
Aselinux-policy-targeted?
IExactly, the AlmaLinux image uses the Fedora bootc config as a git submoduel
Acould be that, so it was only an issue with cosmic
AView selinux-policy-targeted-40.24-1.fc40 in Fedora 40. selinux-policy-targeted: SELinux targeted policy
Aso its included in the base commit
IWould a ublue EL10 image be CentOS Stream based?
IWhat you have in https://github.com/ublue-os/main-bootc/tree/initial-bootc-desktop-builds is exactly what I had in mind
GitHub
OCI base images of Fedora bootc with batteries included - GitHub - ublue-os/main-bootc at initial-bootc-desktop-builds
