NAK/cmmt: [PATCH V2 0/6][SRU][OEM-5.14/Jammy/OEM-5.17/Unstable] build backport-iwlwifi-dkms as linux-modules-iwlwifi-ABI

[Timo Aaltonen]

Dimitri John Ledkov kirjoitti 26.4.2022 klo 18.20:
> Overall this is good, and imho is almost ready to land into
> linux-unstable. But some tweaks are still required to make a V3 patch
> series:
> 
> 1) rename the flag standalone=1 to type=standalone (mentioned in
> another email as reply to patch 5/6)
> 
> 2) correctly mark existing modules as type=built-in and the iwlwifi
> one as type=standalone (see reply to patch 5/6)
> 
> 3) drop metapackage from src:linux; provide a new patch to build
> linux-modules-MODULE-FLAVOUR-VARIANT from src:linux-meta (or explain
> why that meta works)
> 
> 4) fix dkms module install paths for type=built-in and type=standalone
> 
> 5) all of the dkms-versions changes should be collected together, as a
> single commit, against
> https://git.launchpad.net/~canonical-kernel/+git/kernel-versions/tree/dkms-versions/jammy:main
> and we should test existing kernel builds that adding all of these
> key=value pairs doesn't affect existing builds (it shouldn't). This
> will start propagating the dkms-versions updates in a kernel cycle to
> all the kernels, without actually changing anything.
> 
> 6) Submit patch to
> https://git.launchpad.net/~canonical-kernel/+git/kernel-versions/tree/update-dkms-versions
> such that debpath is updated correctly (as mentioned in the other
> email). One can test this by setting a given dkms version to a lower
> version in both column 2 and debpath=, rerun the script locally and
> observe that it correctly updates version number in both column two
> and debpath.
> 
> 7) then the rest of debian/* stuff can be committed as a single patch,
> on top of a tree with updated dkms-versions. To convert a given kernel
> from the old one-by-one dkms way, to this unified and declarative way.
> Starting with linux-unstable, then linux-oem-5.17 & jammy:linux
> 
> In a force majeure situation, dkms-versions will be able to just stay
> the same / unchanged, and one would be able to revert a single patch
> of the kernel tree & recrank if somehow these changes do not produce
> equivalent results to before for the rest of the things.
> 
> Hopefully that's it =/ but maybe new issues will be found when reviewing V3.

Apparently v3 is blocked by dkms build breakage with current 
linux-unstable caused by rebase to 5.18, but I can't wait for this to 
land there first. So I've asked vicamo to send v3 for oem-5.14/5.17 asap 
so it could be reviewed in time for a respin next week (which is later 
than others expect it to land, but oh well).



-- 
t