only thing that caught my eye is that it
only thing that caught my eye is that it won't return the 300 version.
50 Replies
why?
GitHub
chore(ci): handle varied kernel releases for coreos · ublue-os/kern...
A caching layer for Fedora kernels. Contribute to ublue-os/kernel-cache development by creating an account on GitHub.
i was trying to be a head of the game a bit for if we used this to cache a "coreos:next" kernel which was for a future release
just would cause uCore to kernel swap
hmm...
re this... i see tagging needs some love
yeah
hmm... i'm not following why this would cause a kernel swap...
if the originally requested kernel
eg, 6.10.1-300.fc41 exists in koji, we never hit the case statement
if 6.9.11-200.fc40 exists in koji, we don't hit the case statement
i think what you are concerned about has to do with not checking for a difference in the "fcNN" from the ostree.linux label vs the desired fedora release
but it's escaping me at the moment... so i'll just fix tags for now 🙂
yeah, I think that is right.
wait, IS there a tag problem here? I think it actually looks fine
we should be pulling the coreos kernel always. Unless the new coreos kernel is 6.9.7-200 and not 6.9.7-300
i agree with you
all this does is validate the version string
and if the kernel doesn't exist, decrements the "-200" to "-100" etc
it pre-validates the version against koji
yepp. I assumed that current coreos kernel version was 6.9.7-300fc40.... Bad assumption
it's
sorry, yeah, i did potentially make it more confusing with the handling of 300
if i understand correctly... -300 is currently being used in kernels for fc41
so, at some point i thought, there could be a chance where coreos:next might be on fc41 with a 300 kernel, maybe
yeah
i could simplify it to not include that
i'm indifferent
no I think it's fine. I had assumed that we were still on 300
even if we were on 300, i think this should still work
since it would just read the ostree.linux label... for -300.fc40
and then not find it in koji
decrement to 200
and then it should find it
but that REALLY should only happen when caching kernels where the fcNN release doesn't match CoreOS source
the default behavior of the function is "verify the kernel from label exists and use that"
I added a comment in github.
I've got to go pickup some kids, so need to step away... feel free to merge if approved and good.
Just getting back
@M2 how you feeling about this now? I'm around for the rest of the night so I can fire off gts, test stuff, etc.
aka I am ready to approve and burn down things
This is good.
@j0rge g2g
merged and built fine
but I think I need a fix in bluefin? Still errored out looking for 200 instead of 100
https://github.com/ublue-os/kernel-cache/pkgs/container/coreos-stable-kernel/252897877?tag=39
^^^^ it built the right thing!
@bsherman got time to take a look? Sorry this font thing in F39 appears to be widespread so I need to get a build out
@j0rge
ooooh, ninja! thanks!
trying it now
closer, there's the log
Rebuild akmods
Akmods last built 6 hours ago. Update was landed 2 hours ago so akmods needs a button press and then it will work
but the right hand side is good now
oh gotcha, on it, THANK YOU!
this flatpak font thing is infuriating lol
never change linux desktop
lol
I'm guessing that it's the change to Inter or something
like in the runtime or whatever?
Yeah
Fiftydinar has what's going on. But fontcache is in a bad spot.
Distrobox had something similar in the past as well.
i just got back
My pr fixes that. Akmods needs a rebuild
I did the rebuild
same error though
https://github.com/ublue-os/akmods/actions/runs/10231091397
it's correct, and kernel-cache is correct,
6.9.7-100.fc39.x86_64Did you merge my pr?
https://github.com/ublue-os/bluefin/actions/runs/10231063753/job/28307467723#step:13:699
After updating akmods my PR works
GitHub
chore(ci): fix gts kernel version check · ublue-os/bluefin@f2a8e55
The next generation Linux workstation, designed for reliability, performance, and sustainability. - chore(ci): fix gts kernel version check · ublue-os/bluefin@f2a8e55
ok i'm trying to catch up
OH MY GOD I FORGOT TO MERGE YOUR PR.
this is not merged yet
hold up sherman
lol
it looks like kernel cache built AFTER akmods
yeah I rebuilt that too
that is not ideal, though it could be ok depending
I bet this works now:
I need to merge stuff after this is green I'll go cache -> akmods -> bluefin right?
right
well really
understood.
kernel-cache > akmods > main > hwe (but hwe is a maybe depending on if you use it or not)
man, this whole time, I just didn't merge the PR.
I should have my head examined
oh yeah looks like we got it!
sherman fixing things just by showing up just in time to watch m2 point out that I should have pressed a button 3 hours ago.
Rebuild the world button
it's how i roll
i think this failed maybe because main wasn't built...
https://github.com/ublue-os/hwe/actions/runs/10231740903/job/28308006650
oh ok, I can do that
nope, still nvidia skew. Ok, good enough progress for the day, there's skew in nvidia here and with qemu stuff in 39 so probably best to call it and wait for the next round tomorrow.