> Kernel modules MUST NOT be included, they are added to ublue-os/akmods. ?
Kernel 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
WEspecially since I'll have multiple machines on the same image, save internet bandwidth
Whave it build locally then distribute to the entire house
Byea, i'd like to build locally too... i'd kinda like to get the workflows setup so theyd run on either github or gitea if possible
Bthis is related
BI saw an interesting post by Walters today: https://github.com/coreos/fedora-coreos-tracker/issues/1263#issuecomment-1680999863
The important line is:
Got me thinking, having frequent upgrades of ucore/ublue is great, but the best way to gate them is to install from a local mirror, and then I choose when I want to sync the mirror with ghcr... it not only provides a buffer between build and install, but saves bandwidth for those are are running ublue/ucore on multiple systems.
The important line is:
[Users can] mirror the OS update containers on their own to a registry and update it on their own timeframe and schedule. Which is what they already need to know how to do for application containers!the context is replacing zincati/simplifying its function and instead of having complexity, managing things in a better way.
Got me thinking, having frequent upgrades of ucore/ublue is great, but the best way to gate them is to install from a local mirror, and then I choose when I want to sync the mirror with ghcr... it not only provides a buffer between build and install, but saves bandwidth for those are are running ublue/ucore on multiple systems.
Wyea, read that
Bso, even if building in github, could just mirror to a local container registry
WMy inclination, at least with some of this, is to get it off of github
WPersonally I don't love the idea of "hey, my entire system configuration is in a public repo"
Wthe tradeoffs right now are totally in the "worth it" camp, but if I can help get it to where its entirely onprem I'll happily be a guinea pig.
Wreally dumb question... how large are these images? Like I'm looking at one of the images on github and for the life of me it doesn't show a filesize.
Btotal size is around 6GB depending which variant and nvidia or no
Byou can just
podman pullah, larger than I thought.
WNot huge though.
Band really most of the work I do for ublue involves locally running
podman build Containerfileusually only the github workflows themselves need to be in github for testing
Wat ~6gb, to replicate github's 90 day retention, that's about a half a TB per image
Wouch
WI'd probably cut back a bit
Wone of the things I've been thinking of doing, which is really dumb, is to do a local cached repo for dnf, then once you have that, in theory you could build N images on the fly from from it, but that sounds like hyper-overkill
BI am spoiled with fast internet now, and i've already considered caching container registries and DNF repos, etc...
but I may be moving somewhere with much restricted internet... if so, it'll be imperative to figure that out
but I may be moving somewhere with much restricted internet... if so, it'll be imperative to figure that out
Jtransparent inhouse registry would be dope, I filed an issue for that in the website repo.
