bsherman is there a differnce between
@bsherman is there a differnce between kmod for v4l2loopback and our kmods? mainly asking would using kmods directly from rpmfusion circumvent these issues you are trying to solve
Bnot 100% sure what you mean...
our
our
akmods repo just pre-builds the akmods from rpmfusion for the specific kernel on the image version we are deploying and stages them so we can later install
Bhmm, so why could i layer v4l2loopback in past even tho out akmods were already applied
Bbut you are saying that after we make an image users cant apply new ones
Bv4l2loopback was the very first kmod added to main images, so I'm not sure when you could have done so
Bnvidia was the first one ever
Bi had it in an nvidia image
Btrue, i was just referring to main, not nvidia
Binteresting question.
BI'd have to sift through commits... another side of the problem is the inclusion of kernel-devel packages, i'm not sure if they were part of nvidia way back then
Bbut, regardless, the problem trying to solve has more to do with simplifiying the overall build process and incidentally makes the main images simpler/better for layering akmods
Bok looked at when i had added v4l2 akmod to my image it was mid april so i layered it before that as i was testing if that is enought to enable obs virtual cam(and it was)
Bthat was not coming across well in the chat discussion
Bok, i'm going to look at nvidia from that time frame, interesting
Bwhat does it simplify?
Bjust curious
Bdid you read my proposal?
Athe problem with the local layering seems to be that basically we freeze the dev dependencies at the build time and when a user tries to do
rpm-ostree install some-akmod then the kernel version it tries to pull in will be whatever is available in the repos and not what we set at build timeAHence dep conflict
Bfrom proposal 
- Reduce complexity of builds and number of images maintained
- Provide a single foundational image for all downstream Universal Blue images/users
- Prevent artificial restrictions on downstream usage
the single foundational image is confused today because of both nokmods and main existing
- Reduce complexity of builds and number of images maintained
- Provide a single foundational image for all downstream Universal Blue images/users
- Prevent artificial restrictions on downstream usage
the single foundational image is confused today because of both nokmods and main existing
Bi didnt even know nokmods image existed so
Byeah, it's getting confusing as we try to make workarounds
Bthat's part of what i'm trying to address before it gets worse
Bthat doesnt seem to be a problem if you update the image daily
Bbut main with kmods can't be the base for all of ublue today we had to hack a workaround
AIt may be a problem depending on which mirrors are hit, time frame of the kernel release and which mirrors have which versions
ABasically the same problem we were having of Rpmfusion being out of sync
Beh, it's different, becasue by adding a kmod to main it prevents downstreams from changing kernels
AI mean the root cause of why the kmods get that dependency conflict
Bk
Bit shouldnt
Bi mean there's a lot of things i think shouldn't work a certain way... i agree with you it should work better but RJ Kyle and I were all certainly stuck on this
there's a lot of things i think shouldn't work a certain way... i agree with you it should work better but RJ Kyle and I were all certainly stuck on thisBbetter question would have been why
Bso im asking why now
Bbecause i dont see a reason why it wouldnt work
BI am happy for you to find the answer and share. I would appreciate it.
Bfirst i would like to know why you think it doesnt work
Bor point me to discussion of why it doesnt work
AGitHub![[Bug] you can't install akmod-wl · Issue #85 · ublue-os/main](https://images-ext-1.discordapp.net/external/ckJq_Rau2yJNlDliH3mM2T96VkGShsKt0p6PUeVNuQ8/https/opengraph.githubassets.com/f3e52188ea216a17695099de74e1b58a41aa4388480ad64e8743826552e12306/ublue-os/main/issues/85)
When I install akmod-wl on my laptop using the silverblue-main:37 image, I get the following error. It works fine on the official silverblue image but this error apears on ublue. To reproduce, inst...
AIt’s linked in the proposal I think
AAt least in the original ticket it was
Bi think this was for the original question where i said that i could install akmods in past even if there were akmods present, now we are talking about adding kmod prevents downstream from changing kernel which seems not how it should work if you remove all kmods and kernel you should be able to add new kernel
BI feel like you're asking me to document months of intermittent effort here... not all done by me.
AYeah I think the problem with that is that you need to know what to remove, I think bazzite did that before nokmods existed - you can check their issue tracker
Byes becuase you are essentially saying trust me bro, i have a hard time making such a decision without being properly informed
Bwow
AAsking for such level of documentation seems completely unwarranted - that takes a lot of time to do… Possibly more than making the changes themselves
E@Bigpod it doesn't work. I've confirmed it as well
BI suppose I'm more saying I trust @EyeCantCU and @KyleGospo ... maybe that's an appeal to authority, but they were the ones blocked on asus/surface support and this is related to how we resolved that issue.
KYou can't install akmods on OCI, I tested this with the upstream fedora images
KIt's a limitation
