Boh, i thought it was just me
B
B
X
everything is "degraded" (except packages)Xthey've been having incidents daily for three days...
NThis is why all we need to move to federated Gitea/foregjo asap /s
XI hope Gitea Actions gets some quick development...
Xgood /s there, almost caught me agreeing
NIt sounds really fun in theory, but in practice, administrating your own git server + website + actions runner + whatever else gitea has doesn’t sound fun tbh
Bgitea is great for a homelab, or even a small business, (I use for both) but even finding people committed to maintaining the gitea and related services is not the the biggest problem... its cost and availability of infrastructure...
Its been discussed in discord and other places before, but Jorge covered it pretty well in the Brodie "Tech over Tea" interview yesterday...
Goals for this include "running it responsibly", "like a real OSS project with governance", and being "about the automation before the fancy features". Also, if github has problems, much bigger customers (who are paying top dollar for the service) are having the same issues, with more significant impact to their bottom line and their own customers.
We have the benefit of using microsoft/github for free (nearly free) CI, code hosting, communications, registry downloads, asset downloads. It's pretty amazing really.
Its been discussed in discord and other places before, but Jorge covered it pretty well in the Brodie "Tech over Tea" interview yesterday...
Goals for this include "running it responsibly", "like a real OSS project with governance", and being "about the automation before the fancy features". Also, if github has problems, much bigger customers (who are paying top dollar for the service) are having the same issues, with more significant impact to their bottom line and their own customers.
We have the benefit of using microsoft/github for free (nearly free) CI, code hosting, communications, registry downloads, asset downloads. It's pretty amazing really.
BAnd... I just saw "/s" and have to search what that means...
B"/s" is known as the sarcasm switchGot it.
Xabout the automation before the fancy featuresmfw the automation is the fancy feature
Bregardless, I'm still happy with what I wrote 
JGitHub
I recently moved to a custom image based on silverblue-main. Before that, it was an official ISO installation of Fedora Silverblue 36 updated to 38 and all those time, I had some level of Device Se...
Jnot sure on this one if someone wants to take a look
PI can't say I know much at all about that - but doing a quick check my now ublue laptop passes more of the security checks (if you copy the technical report from that dialog) compared to my plain fedora desktop (the desktop has been upgraded from fedora 35 or 36 compared to the fresh ublue install on my laptop, and the hardware is obviously different so not sure how much that affects thigns)
Bbased on what i just read if you have nvidia drivers you cant pass kernel verification but i could be wrong(quite a lot wrong)
PAlso sigh building extra kernel modules in the container build is not as easy as I was hoping. Or well, the compiling is fine, but getting depmod updated seems to be problematic since it wants to use the kernel of the actual machine running the build (which is whatever kernel the github action is running on, currently some azure 5.15 kernel, very different from the kernel I'm actually trying to deal with in the image)
Pand you can't do the depmod update on boot since /lib/modules isn't writable (though having it be done in the image would be better anyway IMO)
C
POh, may have figured it out. Maybe
PAh ok, yeah got the kernel modules working probably. Now just the issue of the xone firmware downloader which wants to write firmware to /lib/firmware which is obviously read only
Jcan you just extract the firmware and plop it in there?
PWell it would be possible to grab the firmware during image build - which is what I'd like to do in an ideal world - but I'm guessing that the firmware isn't necessarily redistributable as far as licensing goes; I'm assuming that's why xone is distributed with a script to fetch the firmware from MS.
PCurrent solution that I think is working: create a symlink from /lib/firmware/xow_dongle.bin to /usr/local/lib/firmware/xow_dongle.bin during image build, and then modify the download script to put the firmware in the latter location
POk, yep, elite controller on dongle is working! Haven't added the download script changes to my image yet but that should be easy
P@j0rge in case you're interested, my proof of concept of building xone as part of the image build is here: https://github.com/Pythoner6/ublue-custom/commit/705cdf5bc44aaefbc42464246e5dee52de30439e
PProbably a bit hacky and missing some things (like perhaps a better way of consuming the xone source code, or at least doing checksums on it etc). But functional at least for now.
PBeing able to do this IMO is a huge selling point of ublue for me. Now I don't have to worry about setting that up on any new machines, yay!
BHave you seen https://github.com/bsherman/ublue-kmods
GitHub
Vanilla Fedora immutable images with Nvidia and xbox drivers added - GitHub - bsherman/ublue-kmods: Vanilla Fedora immutable images with Nvidia and xbox drivers added
BWe ( ublue-os org ) also have an akmods repo that is prepped to start adding akmods builds.
BI’m definitely interested in other approaches and perspectives though.
Actually the pending changes in ublue-os/akmods aren’t by me but I expect to be working on it in next few days
Actually the pending changes in ublue-os/akmods aren’t by me but I expect to be working on it in next few days
BThe main feedback I have for you with respect to getting that added into ublue-main, we definitely want the akmod rpms rather than files added in ad hoc.
There was even some great work done to push our own ad hoc config files into rpm. Much clearer downstream to know where files come in the base images from when owned by rpm
There was even some great work done to push our own ad hoc config files into rpm. Much clearer downstream to know where files come in the base images from when owned by rpm
AThere is literally a flag for it:
So there is no reason to bring individual files in manually. Just telll it to build module X for kernel Y, and to put the RPMs in the output directory. Then install those RPMs with rpm-ostree. As long as all kernels are installed in the chroot build environment I think it will work.
Also for anyone curious "why not just call
So there is no reason to bring individual files in manually. Just telll it to build module X for kernel Y, and to put the RPMs in the output directory. Then install those RPMs with rpm-ostree.
As long as all kernels are installed in the chroot build environment I think it will work.Also for anyone curious "why not just call
akmodsakmodsakmodsbuildcat "$(which akmods)" | grep akmodsbuild -C10akmodsrpm-ostree install@pythoner6
BRight. Part of the issue is the linked change set doesn’t use akmods unless I overlooked it.
AYea if you mean pythoner's link, it was grabbing final files from some other repository instead of building them with akmods locally.
BYeah. I’m mobile. Harder to interact on phone.
PYes - totally understand that the way I'm doing it is perhaps not right for ublue proper. However I have some thoughts on why I wanted to do it the way I am, but about to head out, will try to put down my thoughts later
BTrying to hotspot. But for some reason discord won’t load messages while on my hotspot 
PNo I am compiling from source, just using the source directly instead of going through the extra layer of akmods
AOh okay. But akmods is the easy way. 
Leverage if you can. The solution you posted was pulling driver files from another image which is fragile.
Leverage if you can. The solution you posted was pulling driver files from another image which is fragile.PWill post my thoughts later when I have time
ALooking forward to hearing.
AIf anyone's interested in pursuing automated kmod RPM building, I added some extra info that helps at the bottom of the post:
💾ublue-dev
Any project that follows the akmod spec should be able to build, but I've only used it for NVIDIA drivers.
💾ublue-dev
Any project that follows the akmod spec should be able to build, but I've only used it for NVIDIA drivers.
BBthanks @j0rge
BAnd... another PR to avoid subshell/cosign from env... this feels like whack-a-mole, but surely this is the last one!
https://github.com/ublue-os/config/pull/37
https://github.com/ublue-os/config/pull/37
Jgotchu