WJust more thoughtful dependency inclusion. For example, V4L2loopback DKMS is not required in the container which has a knock on effect of not pulling in kernel headers and build tools.
As @Bigpod says, slim-toolkit can't be used for desktop apps.
As @Bigpod says, slim-toolkit can't be used for desktop apps.
WThat said @Bigpod and I did manage to make a FROM scratch Ubuntu container base image that was smaller than the official base image from Canonical. Again, without using slim-toolkit.
So there might be a little wiggle room with Ubuntu-toolbox.
So there might be a little wiggle room with Ubuntu-toolbox.
Gyeah, it's fixed, i'll make a PR tmro
Gand figure out what's up with
rpm-ostreed.confGGitHub
This fixes optfix and makes the symlink not broken
Xthanks
Xi didn't write optfix i copied it from aura
Xyeah, oversight
GYeah, it was some error with loading the value from the config
Bjust disable secure boot 
?
?
GI'd rather avoid it, especially because I want to use TPM for disk encryption in the future
Byeah, I was mostly joking. I have secure boot, mostly for TPM disk decrypt, too.
Bseriously, the key loading is a problem for anything secureboot which is not trusted by microsoft (basically)
GIMO we should avoid putting kernel modules in main, save for nvidia
AWe should add your script to bluefin
ASome people seemed interested
Bmine? feel free
AI was looking into that setup but using my yubikey
Bor i can
AI think we need to install some package for dracut u2f
BI agree its a gray area. But the community did agree on it in the past, and it fits scope to some degree
https://universal-blue.org/scope/ since it enables hardware that Fedora won't.
I believe it's MUCH worse to face a "broken system" due to not enrolling the Ublue MOK for nvidia than for a game controller... So, I'm not too worried about it for now.
https://universal-blue.org/scope/ since it enables hardware that Fedora won't.
I believe it's MUCH worse to face a "broken system" due to not enrolling the Ublue MOK for nvidia than for a game controller... So, I'm not too worried about it for now.
BIts sadly just the cost of secureboot.
GKernel modules MUST NOT be included, they are added to ublue-os/akmods.?
Bthat meant not built in the repo, but could be clarified
GAh
GYeah, I understand, I'd just rather not have to enroll the key when my controller already works without the modules
BBut yeah, we do have some trouble where either becasue the kmods are signed and not loading, or the controller doesn't like our driver, it causes issues... so, I question the decision, too, even though i was part of it. The bigger issue is I'd want a good plan before REMOVING something.
I do know the akmods repo needs to be better documented... i've filed issues for it so I don't forget, but anyone can help with it.
So one idea would be:
I do know the akmods repo needs to be better documented... i've filed issues for it so I don't forget, but anyone can help with it.
So one idea would be:
- make sure akmods repo is well documented on how users can include any of those individual drivers in their custom repos
- remove the game controller drivers from
*-main(would still leave the v4l driver, i think) - add those game controller drivers to bluefine/bazzite
GMakes sense
BI should be clear, I'm not very sympathetic to the "i don't like enrolling a secure boot MOK" but i'm very sympathetic to pre-installing things that can cause trouble, specifically that seems to be the xone/xpad-noone driver compo
but i'm very sympathetic to pre-installing things that can cause trouble, specifically that seems to be the xone/xpad-noone driver compoBand I'm also biased to as few additions to main as possible
Bthat's been a learned bias though, as I more and more see main as the foundation of a toolkit, and... anything added is difficult/impossible to remove downstream
JI wouldn't say it's a bias, that's just how you're supposed to do it. 
WWhat is the status of Forge? I was listening to a podcast yesterday that was talking about Gitea beginning the process of trying to 1:1 github actions and it made me think "huh, I wanna have my ublue running entirely self hosted, maybe this'll work"
Whttps://docs.gitea.com/next/usage/actions/overview I'd love to look into it, and maybe help push forge along if it fits
Starting with Gitea 1.19, Gitea Actions are available as a built-in CI/CD solution.
Jsomeone needs to try it and see if it works.
WI'm down. On the "vision" I won't be doing 4 though
PXE boot the clients, select ublue in the menuWso this looks like it'd be deployed via podman cluster?
Wok, so ucore VM
WReally I just want to in house my image creation
Jit should run on any linux with podman or docker iirc
WIs it a single container? Cause if so, I'll just attempt to throw it in the mix on unraid
Wif its orchastrating multiple containers I may throw a VM at it for testing
JGitHub
On-prem Universal Blue. Contribute to ublue-os/forge development by creating an account on GitHub.
Jit's a few
Wyea, I'll just spin up a VM to test it in
Wkeep it contained
BI use gitea for git and their actions with act_runner for CI builds and as a container registry...
i can tell you that the buildah actions we use today don't work on act_runner, but could almost certainly be swapped out for docker's builder action (and still probably run against podman, if you like)
i can tell you that the buildah actions we use today don't work on act_runner, but could almost certainly be swapped out for docker's builder action (and still probably run against podman, if you like)
WHonestly if Forge does what it advertises (and if it doesn't, I bet its way further along than me starting from scratch) I think its probably the better starting point than trying to slam gitea in
W¯\_(ツ)_/¯
Wbut that conversation made me really curious to get it all building locally
