Blets discuss here
B@EyeCantCU
BThe issues for this are:
https://github.com/ublue-os/hwe/issues/220
and
https://github.com/ublue-os/akmods/issues/156
https://github.com/ublue-os/hwe/issues/220
and
https://github.com/ublue-os/akmods/issues/156
B
EThis sounds interesting. I'll have a look. Have a couple ideas already circling in my head
Bi think the current implementation may start to give the idea of what is desired, but i was struggling with how to run fedora specific stuff in a container to get DNF/RPM info, but still have that be in a gitup action workflow step so we can use the results in metadata for building the image
Bi've seen an idea before... where podman runs in "script mode"
EI use Podman exec for the kernel signer. Would work here
Byeah, i think that's what i'm talking about
EI'll take a look at the existing implementation and see if I can't come up with something. First thing I noticed - why are workflow runs on PRs being disabled?
Bright, so instead of the step where i used
just go back to a normal step with no
addnab/docker-run-action@v3just go back to a normal step with no
uses specifiedEExactly
Bi don't know what you mean? we run workflows on PRs all the time, just not without approval for non-member/non-approver, and we don't push images to GHCR for PRs
EThe triggers were commented out in your PR for both build workflows
BOH! that's temporary
Bno need to be running lots of extra jobs when I'm just trying to get the workflow functioning
EAh, okay. Makes sense to me
Band the F40 matrix generates the fewest jobs
B@EyeCantCU i have a question for you 
does the issue scope / goal make sense?
does the issue scope / goal make sense?
Bi can try to clarify
EIt makes sense to me
Bcool
Byeah, i realized when i was looking at some bazzite stuff, "oh man! we could really benefit from having the proper kernels defined!" a lot of downstream stuff would be simplified as bazzite and bluefin wouldn't need variables to make matches or assumptions about the kernel version... but could query the image lable directly
Band i think it's just akmods and hwe which really need it since main will inherit the correct label from upstream
but akmods and hwe (and bazzite) are where we actually change kernels
but akmods and hwe (and bazzite) are where we actually change kernels
Bthanks for taking a look @EyeCantCU !
i've got kid/family stuff this morning, but i'll check back in the afternoon to either help or applaud your success
i've got kid/family stuff this morning, but i'll check back in the afternoon to either help or applaud your success
ENo problem! I'll be out for about an hour in an hour and a half and for a couple hours this afternoon but other than that, my weekend is (so far) wide open
EOkay - maybe I don't fully understand - how would this work in akmods? Wouldn't we only do this in main/hwe?
EYeah - we should be able to set this without changing akmods
Bit's important for akmods because each image is built with a specific kernel in mind
Beach kmod is built against 6.8.4-200.fc39.x86_64 or 6.7.11-204.fsync.fc39.x86_64 or an asus or surface specific kernel, etc
Band thus, the akmods images are all specific to that
Band, i'm back, btw
EAh, now I understand
Bcool... I'm happy to be challenged if my understanding is wrong, too... but I wasn't convinced I had yet correctly explained
ESo... This should be simple
EWe use Podman run and set uname as the entrypoint
EAnd pass -r
Bnot uname
EThen pass as a build arg to the container
Buname will yield the running kernel version
EThen we need to do what I do in kernel signer
EAnd use rpm
EI forgot that bit. Was already writing this out
Bi expected to do a podman run/exec, and inside there, use dnf to query what kernel WOULD be installed given the build-args and env vars for the kernel flavor
EBut I can adjust the kernel signer script for this easy
EIf we want what would be installed, that completely changes implementation and I need to scrap this :/. We can easily get what is installed this way though...
Bi added a comment just documentation https://github.com/ublue-os/akmods/issues/156#issuecomment-2053734863
Bi'm sorry i've not communicated well enough about it
EIt's all right. I made assumptions I shouldn't have
Bi do think we need to find out what WILL BE installed before building the image, because we need to have the label defined in advance so we can use it in the build step
