Oddly my PR for akmods is passing for 37 but failing for 38 because 38 claims it can't find v4l2loop
Oddly my PR for akmods is passing for 37 but failing for 38 because 38 claims it can't find v4l2loopback. Very confusing as I never touched it
ELooks like it checks for dnf then for yum and fails after being unable to find either to actually install it
EOH this goes back to build 46
AYou can ping me for a review if you need
Jyeah I don't understand what's going on there either
ALooks like you approved and it is a simple revert
ASo it is good
Khttps://fedoramagazine.org/4-cool-new-projects-to-try-in-copr-for-june-2023/
made it into fedora magazine again
made it into fedora magazine again
Kthis time with a little GPT build I set up for personal use 
JI just saw the upstream project on this cli, how is it?
Jhmm, not sure why removing wl still leads to this error
EIt seems it happened before that PR in a build from 14 hours ago: https://github.com/ublue-os/akmods/actions/runs/5207937936. Same error
EI will definitely have to check that out. Awesome job landing in the magazine
GThey recommended an older unmaintained copr of Hyprland
GUnfortunately
Kworks quite well, I'm using it with a little bash script to make invoices from my git history
Kmakes my life so much easier lol
EI just realized the last two Nvidia 530 builds have failed
E*scheduled builds
Joh wow, the log is just huge
EI downloaded it and it's taking a while for me to make sense of it all
JJover and over again
ELooking like the same issue with builds for akmods
KHave we done any akmod builds in Copr or the like? There's a few kernel modules I'd love to do akmods for
Jlooks like we're stuck until we fix the build
Jwe wanted to stop building wl
ELooking through all of this, trying to figure out what the heck is going on. Probably going to take a bit
EEverything is just in the GitHub repo at the moment to my knowledge
EGitHub
A caching layer for pre-built akmod RPMs. Contribute to ublue-os/akmods development by creating an account on GitHub.
JI think we're to the point where we need to start documenting the internals around akmods, nvidia, etc.
Jfor the rest of us I mean, like, I am kind of useless right now with this stuff, heh
EIt's our best friends from yesterday: akmods: DNF not found, using YUM instead.
/usr/sbin/akmods: line 310: yum: command not found
/usr/sbin/akmods: line 310: yum: command not found
EAnd no fallback to rpm-ostree
KThese would be nice to redo as kmods
Kaura and openrgb for LED control, gcadapter lets you use those gamecube USB adapters nintendo made at 1000hz, and gasket is for Google's Coral TPM. Nice for home servers.
Jwe have the openrgb udev rules already too!
Jthose are in there
EThere's a current issue for Open Razer too
EI looked into it and have a copr for it setup but I ran into an issue building it
KThis dkms/potential kmod is OpenRGBs i2c-piix4 and i2c-nct6775 for motherboard LED control
Ksame for the aura-gpu, that does ASUS Aura control on specific hardware
JI think I have 2 mobos with that stuff
Jit's kind of neat in my ncase N1, it's my chimeraOS machine and the rgb shines out of the case, it's kinda neat.
AIt's actually pretty simple so far we just have some scripts that install the akmod packages from rpmfusion and run
I can try to update the readme this weekend
akmods --force to build them I can try to update the readme this weekend
Jis this a case where we're waiting on rpmfusion then?
EI'd assume so. We didn't break anything on our end. I've just been going through things off and on for the last couple hours trying to find the source so I can file a bug report
EAnd, optimistically, fix the problem lol
NWhat’s the point of sigstore cosign over gpg + detached signatures?
I thought I understood it but I’m a bit confused now
I thought I understood it but I’m a bit confused now
Jsigstore/cosign is the defacto signing method for containers so we reuse it
