B@Kyle Gospo ok, so lets look at why this could be not getting current version
Bhttps://github.com/ublue-os/kernel-cache/blob/main/.github/workflows/reusable-build.yml#L83 this shows where we query
https://github.com/ublue-os/kernel-cache/actions/runs/10150612317/job/28068191789#step:7:405 this shows a recent build of kernel-cache finding fsync 6.9.9 FROM copr
but... recent builds in copr are newer (6.9.11 and 6.9.12) https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/package/kernel/
https://github.com/ublue-os/kernel-cache/actions/runs/10150612317/job/28068191789#step:7:405 this shows a recent build of kernel-cache finding fsync 6.9.9 FROM copr
but... recent builds in copr are newer (6.9.11 and 6.9.12) https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/package/kernel/
Bi'm trying to reproduce locally
BFYI also @M2 but I know you are kinda unavailable
Kmaybe a dnf cache clear before doing anything would fix this?
Knot sure if that's somehow being reused
Boh, i see, it's a query sort order issue
Koh?
BBwe are tailing and grabbing the last one
Kah
Bhmm... this kinda sucks because that's the sorted order
Bsweet! I found the answer...
Bstandby for fix
BGitHub
We need to version sort the kernels we pull from COPR so that we can reliably find the newest version.
K@j0rge ack pls
Band we can already see it works https://github.com/ublue-os/kernel-cache/actions/runs/10152621567/job/28074399818?pr=22#step:7:841
Bi will say...
i'm SOOOOOO GLAD we only have to query kernels like this in ONE place now! what a huge relief
i'm SOOOOOO GLAD we only have to query kernels like this in ONE place now! what a huge relief
Kno kidding
JGOTCHU FAM
Kright in time for nvidia to complicate the whole damn thing too
Byou seem upset by this nvidia thing 
B
Bplease tell me that's AI generated and not real
J
Jhe cooks them individually
Hyou can easily spot that its ai generated 
Kright, no leather jacket
Kdefinitely AI generated
JI feel like we've done the "ok, one last lift for nvidia, I'm sure this is the last one"
Jlike 5 times?
Bmeh
Kok guys, if you're using a nvidia 16xx/2xxx or newer you can use thebuild, or the-nvidiabuild. If you're on a 1xxx you must use the-nvidia-legacybuild, please rebase from-nvidia-legacybefore F41 or you system will break. Also if you're using a-nvidiaor9xxyou must use the8xxxbuild. Please donate $5 to my Cloudflare storage bill-nvidia-legacy-legacy
Jcan one of you theorycraft how I'd fsync :latest?
J"$5 you outta your mind?!?!?"
"Oh no. Not per user. Just in total."
"!!!!!!!"
"Oh no. Not per user. Just in total."
"!!!!!!!"
Hhonestly to avoid breaking anything i would try make some kind of logic script to run once and auto rebase legacy nvidia users to the legacy repo, i can try cook one up if you want?
Kyeah, not there yet but we can use ublue-update to do it
Kautomagically
Hwell i can cook up a check for older cards and rebase them correctly
Hlspci -nn | grep -P "(VGA compatible|3D) controller .+G(M|P|K)\d{3}"exit 0 = legacy (700, 900 or 10 series)
exit 1 = other
it looks for the DIE name in the lspci output
HGitHub
Adds /usr/libexec/nvidia-legacy-hardware as a script on nvidia images.
will exit 1 if the machine has no legacy nvidia cards.
I did not add this to the non nvidia image as it is nvidia specific and...
will exit 1 if the machine has no legacy nvidia cards.
I did not add this to the non nvidia image as it is nvidia specific and...
M@bsherman thanks for figuring this out.
Jquestion: I see kernel-cache builds every day
Jshouldn't it just build when the kernel changes?
Jor is it like "too annoying just cron it"
Mif its the same version it just gets the same tag. We have no date tags so it doesn't matter
Mbasically path of least resistance. If github was charging us we could investigate it. Otherwise.... why bother?
Jgotcha
