Mantic has the 6.5 kernel, and the current ipu6-dkms package that is in mantic (git202302081010.7fdfb5eb-0ubuntu0.23.10.2) builds fine with it.
I'm also told that mantic will not get a 6.6 kernel.
Finally, the patches that I could locate about this issue also warn what 6.6 made "significant changes":
Kernel 6.6 has made some significant changes to how v4l2-async
(sub)dev registration works. Adjust the code accordingly.
It seems all to be #ifdef'ed, so less risky, unless a mistake was made (regression potential!).
Therefore, I have to ask, what's the reason to add patches to fix a non-existent problem, at least at this time? Are we expecting there to be a 6.6 kernel available for mantic, which will need these fixes? I know Timo already marked the bug as wontfix, and I agree with him, but that would mean rejecting the package currently in mantic-unapproved and asking to remove the patches that address this bug here, and I want to give you a chance to comment on this issue. Perhaps we missed something.
Mantic has the 6.5 kernel, and the current ipu6-dkms package that is in mantic (git20230208101 0.7fdfb5eb- 0ubuntu0. 23.10.2) builds fine with it.
I'm also told that mantic will not get a 6.6 kernel.
Finally, the patches that I could locate about this issue also warn what 6.6 made "significant changes":
Kernel 6.6 has made some significant changes to how v4l2-async
(sub)dev registration works. Adjust the code accordingly.
It seems all to be #ifdef'ed, so less risky, unless a mistake was made (regression potential!).
Therefore, I have to ask, what's the reason to add patches to fix a non-existent problem, at least at this time? Are we expecting there to be a 6.6 kernel available for mantic, which will need these fixes? I know Timo already marked the bug as wontfix, and I agree with him, but that would mean rejecting the package currently in mantic-unapproved and asking to remove the patches that address this bug here, and I want to give you a chance to comment on this issue. Perhaps we missed something.