Hello Robie, sorry for the delay. (And thanks Antoine for your help and opinion.)
The problem we face today is not only that some SRUs are blocked. It's also that this problem exists now for years, and there are Ubuntu users that have non-compliant installations. We want to better support such setups, for example by adding more warnings and safeguards in do-release-upgrade. We do not want to make such kind of installations more frequent, nor want to preserve such cases. But we need a better way to support our partner cases. Some selected cases: - Jetsons just got SRU 2127473 [1] in proposed. There are thousands of jetsons users out there, stuck on Jammy until very recently. Yes, their installation is not as proper as we would hope (yet), but we can still make the experience of our users better, until we catch up and hopefully make these device compatible with Vanilla Ubuntu. SRUs 2127100 [2] and 2095032 [3] were accepted too, but we would rather make the context of the exception more formal. - Mediatek new packages were rejected : 2107525 [4], 2107524 [5]. These were put in the OEM archive [6] instead, because the team did not have much of the choice. But it makes the support and upgrade journey even worse. SRUs are generally accepted, like this 2126737 [7], when the testing can happen on a forcely upgraded system. - Qualcomm had most of its SRUs accepted: 2105425 [8], 2133787 [9], 2134514 [10], 2133923 [11]. Again we would rather make the context of the exception more formal and well-defined. - Nvidia Spark required SRUs 2111271 [12] and 2111723 [13]. Again, they were thankfully accepted, without the process being official and well-defined, we were lucky. Livecd-rootfs [14] was however rejected, but the nature of livecd-rootfs allows us to run it from forks. So we are lucky here. All machines that have a partner-specific kernel in LTS may end up in these situations. For example, Nvidia is shipping Ubuntu with their machines, but with a -nvidia kernel. The -nvidia kernel for 26.04 will not be ready when resolute is out, but will be later. And it was never in an interim release until now. To improve the situation, we want to implement this mechanism in do-release-upgrade to prevent the to upgrade until it's ready. In parallel, we're are working on improving the situation and hopefully having these kernels everywhere. And we need a proper way to service existing installation where the kernel is LTS only, but not yet in latest LTS. [1] https://bugs.launchpad.net/bugs/2127473 [2] https://bugs.launchpad.net/bugs/2127100 [3] https://bugs.launchpad.net/bugs/2095032 [4] https://bugs.launchpad.net/bugs/2107525 [5] https://bugs.launchpad.net/bugs/2107524 [6] http://oem.archive.canonical.com/updates/dists/jammy-baoshan/public/binary-arm64/Packages [7] https://bugs.launchpad.net/bugs/2126737 [8] https://bugs.launchpad.net/bugs/2105425 [9] https://bugs.launchpad.net/bugs/2133787 [10] https://bugs.launchpad.net/bugs/2134514 [11] https://bugs.launchpad.net/bugs/2133923 [12] https://bugs.launchpad.net/bugs/2111271 [13] https://bugs.launchpad.net/bugs/2111723 [14] https://bugs.launchpad.net/bugs/2109822 On Tue, Jan 13, 2026 at 8:38 PM Robie Basak <[email protected]> wrote: > Hi Frank, > > In our meeting of 2025-11-18[1], you mentioned that some packages were > already in the archive as a justification for your request. I asked what > specific use cases are broken, eg. images that you've shipped that don't > work, and require an SRU, that are blocked. You said you'd follow up, > but I haven't heard from you since. > > What's the status of this request now, please? Do you consider it > dropped? > > Thanks, > > Robie > > [1]: https://irclogs.ubuntu.com/2025/11/18/%23ubuntu-meeting.html#t20:22 >
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
