only thing that caught my eye is that it
only thing that caught my eye is that it won't return the 300 version.
Bwhy?
MGitHub
A caching layer for Fedora kernels. Contribute to ublue-os/kernel-cache development by creating an account on GitHub.
Bi 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
Mjust would cause uCore to kernel swap
Bhmm...
Bre this... i see tagging needs some love
Myeah
Bhmm... 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 the originally requested kernel
eg, 6.10.1-300.fc41 exists in koji, we never hit the case statement
Bif 6.9.11-200.fc40 exists in koji, we don't hit the case statement
Bi 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
Bbut it's escaping me at the moment... so i'll just fix tags for now 
Myeah, I think that is right.
Bwait, IS there a tag problem here? I think it actually looks fine
Mwe should be pulling the coreos kernel always. Unless the new coreos kernel is 6.9.7-200 and not 6.9.7-300
Bi agree with you
Ball this does is validate the version string
Band if the kernel doesn't exist, decrements the "-200" to "-100" etc
Bit pre-validates the version against koji
Myepp. I assumed that current coreos kernel version was 6.9.7-300fc40.... Bad assumption
Mit's
Bsorry, yeah, i did potentially make it more confusing with the handling of 300
Bif 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
so, at some point i thought, there could be a chance where coreos:next might be on fc41 with a 300 kernel, maybe
Myeah
Bi could simplify it to not include that
Bi'm indifferent
Mno I think it's fine. I had assumed that we were still on 300
Beven if we were on 300, i think this should still work
Bsince 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
and then not find it in koji
decrement to 200
and then it should find it
Bbut that REALLY should only happen when caching kernels where the fcNN release doesn't match CoreOS source
Bthe default behavior of the function is "verify the kernel from label exists and use that"
BI 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.
I've got to go pickup some kids, so need to step away... feel free to merge if approved and good.
JJust getting back
J@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.
Jaka I am ready to approve and burn down things
MThis is good.
M@j0rge g2g
Jmerged and built fine
Jbut I think I need a fix in bluefin? Still errored out looking for 200 instead of 100
J^^^^ it built the right thing!
J@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
M
M@j0rge
Jooooh, ninja! thanks!
Jtrying it now
JJcloser, there's the log
MRebuild akmods
MAkmods last built 6 hours ago. Update was landed 2 hours ago so akmods needs a button press and then it will work
Mbut the right hand side is good now
