This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- hirsute' to 'verification-done-hirsute'. If the problem still exists, change the tag 'verification-needed-hirsute' to 'verification-failed- hirsute'.
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-hirsute -- 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-restricted-modules package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux-restricted-modules source package in Bionic: Fix Released Status in linux source package in Focal: Fix Committed Status in linux-restricted-modules source package in Focal: Fix Released Status in linux source package in Hirsute: Fix Committed 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
