This bug was fixed in the package linux-oem-5.10 - 5.10.0-1049.51
---------------
linux-oem-5.10 (5.10.0-1049.51) focal; urgency=medium
* focal/linux-oem-5.10: 5.10.0-1049.50 -proposed tracker (LP:
#1944209)
* e1000e extremly slow (LP: #1930754)
- SAUCE: e1000e: Separate TGP board type from SPT
- SAUCE: e1000e: Fixing packet loss issues on new platforms
* CVE-2021-41073
- io_uring: ensure symmetry in handling iter types in loop_rw_iter()
-- Chia-Lin Kao (AceLan) <acelan....@canonical.com> Mon, 27 Sep 2021
18:33:36 +0800
** Changed in: linux-oem-5.10 (Ubuntu Focal)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-restricted-modules 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-oem-5.10 package in Ubuntu:
Invalid
Status in linux-restricted-modules package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux-oem-5.10 source package in Bionic:
Invalid
Status in linux-restricted-modules source package in Bionic:
Fix Released
Status in linux source package in Focal:
Fix Released
Status in linux-oem-5.10 source package in Focal:
Fix Released
Status in linux-restricted-modules source package in Focal:
Fix Released
Status in linux source package in Hirsute:
Fix Released
Status in linux-oem-5.10 source package in Hirsute:
Invalid
Status in linux-restricted-modules source package in Hirsute:
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
