This bug was fixed in the package linux-restricted-modules -
4.15.0-153.160
---------------
linux-restricted-modules (4.15.0-153.160) bionic; urgency=medium
* Master version: 4.15.0-153.160
* LRMv5: switch primary version handling to kernel-versions data set
(LP: #1928921)
- [Packaging] convert to v5 autogen form
- [Packaging] convert to v5 autogen form -- git compatibility
* Miscellaneous Ubuntu changes
- debian/tracking-bug -- update from master
- debian/dkms-versions -- update from kernel-versions (main/2021.06.21)
-- Stefan Bader <stefan.ba...@canonical.com> Thu, 29 Jul 2021 08:29:47
+0200
** Changed in: linux-restricted-modules (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1928921
Title:
LRMv5: switch primary version handling to kernel-versions data set
Status in linux package in Ubuntu:
Triaged
Status in linux-restricted-modules package in Ubuntu:
Fix Released
Bug description:
Switch fetching dkms-versions data for these packages to the kernel-
versions dataset.
Currently the primary dkms-versions data is committed directly to the
primary kernel packages. This allows this information to cascade
reliably to all derivatives and their associated LRM packages. But
once the primaries are closed it is increasingly hard to change this
data. This makes performing an LRM-only respin very difficult as it
differs in handling from a primary spin.
We move the primary version dataset out of the kernel packages into a
shared external "kernel-versions" dataset. Each package which needs
this data then obtains the information it needs directly, with it
committed locally to that package at update time.
This renders preparation of am initial (-1) spin and a later LRM-only
respin identicle. We simply update the shared dataset and perform a
no-change rebuild (./update-versions) on them and they will
automatically get the updated version information.
We will want to update update-dkms-versions in all primary main
packages, and introduce same into all LRM packages. As we already run
update-dkms-versions in the primary main packages, and are introducing
update-dkms-versions handling to update-versions in LRM this should
not change kernel crank proceedure. The cycle proceedure will need a
new step to update the shared kernel-versions dataset before cranking
commences.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928921/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
