SRU review. I appreciate the importance of fixing this and the general approach seems OK to me.
0. I do have some difficulty in understand the exact mechanism involved. Is it correct that in *all* cases it's now wrong in Jammy for /etc/default/grub.d/oem-flavour.cfg to point to `oem- somerville*-meta|oem-stella*-meta|oem-sutton*-meta` what about after the user upgrades to Noble? What should happen then? What assurances do we have that removing /etc/default/grub.d/oem-flavour.cfg will result in a still-working kernel? I think it would really help to document the technical mechanisms involved here in more detail so that reviewers and observers can get some more confidence in the fix, but I don't think that part is a blocker for SRU. 1. I understand that this currently only affects Jammy. But it's a general pattern that will eventually happen on every LTS, right? So from the SRU philosophy that we avoid future regressions by fixing the development release first, shouldn't there at least be a bug that tracks a long term solution to the general problem that, when fixed, will stop this problem recurring? 2. I appreciate that the severity of this bug and its ability to regress existing behaviour means that we shouldn't block on such a fix actually landing before we hack a fix for Jammy, but could that bug at least be created so that it is tracked, please? 3. I appreciate that this is both important and that some hack is going to have to go somewhere. But please could you get an ack for this from someone on the desktop team please, as they maintain this package and if we're going to do something as unusual as this then they should probably have input? 4. I think the "&& exit 0" lines are a bug, because they will preclude any #DEBHELPER# snippets from running. It looks like debhelper already has generated code in ubuntu-drivers.postinst so this seems like a real and immediate issue. Probably the easiest is to move this into a function and use `return`, but note that then you'll need to do explicit error checking since `set -e` will no longer work. But also, please add `set -e` anyway as is best practice. 5. Why is a previous debian/changelog entry being changed? If you're correcting a previous mistake then I guess it's subjective as to whether that's OK, but I can't distinguish between that and an inadvertent change. Please could you clarify? 6. Shouldn't you be triggering update-grub after touching /etc/default/grub.d, or is there a mechanism for that already in place? 7. I think some additional testing is warranted: specifically to test idempotency of the upgrade path, as well as correct handling for the common case of a non-OEM install. Please could you add to the Test Plan to test these paths? Due to point 4, I fairly sure that the current upload needs amending, so I'm rejecting it from the queue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2083657 Title: Remove oem-flavour.cfg for the OEM kernel retirement To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2083657/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
