anything reusable or you shoving it all thru docker-slim?
anything reusable or you shoving it all thru docker-slim?
JI want ubuntu-toolbox to go on a diet too
Bthat one defently cant go trought slim-toolkit as docker-slim is now called
JGitHub
WIP container for DaVinci Resolve installation and runtime dependencies - GitHub - zelikos/davincibox: WIP container for DaVinci Resolve installation and runtime dependencies
Bmakes sense
GWhy do we install xone and xpad drivers in main?
Kxpad is in the kernel by default
Kwe opt for xpad-noone, xone, and xpadneo
Kbasically just upstream+ when combined like that
Ksupports everything the mainline kernel does and more
Kprior to xpad-noone you had to blacklist xpad to have xone
GProblem I have is that it doesn't run without enrolling the key
Gbtw @hermmm optfix doesn't work
G
Gother than that not much else to really comment on
Geverything else in the startingpoint rewrite works from what I can tell
Gnix-me-down # run the ublue nix uninstaller by dnkmmrneed to fix this
nix-me-up # run the ublue nix installer by dnkmmr
Git uses a file for some reason, instead of a directory
Gok I think I fixed it now
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.confGitHub
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
(would still leave the v4l driver, i think)*-main - 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. 
