Re: Choice of the openssl version for 23.10 and 24.04
We had similar dilemma around focal release. And I did SRU one off upgrade from 1.1.0 to 1.1.1. it was a minor disaster. (As in like the sad depressing songs in A minor scale). It is best to stick to one openssl version in a release. It is best to stick to longer supported one. It is best not to chase minor ones that nobody will use or want long term. Mantic is open for development, and usually optimisations are fairly standalone. Even if upstream is not backporting performance optimisations - we can do so, and have done that for x86, s390x, ppc64el, arm64 in the past. If there are high priority optimisations that we want in our openssl we should attempt backports of those onto current openssl release we ship in mantic. Note, we would have to then monitor for regressions & security fixes to those optimisation backports. On Wed, 17 May 2023, 21:35 Adrien Nader, wrote: > On Tue, May 16, 2023, Marc Deslauriers wrote: > > On 2023-05-15 05:18, Adrien Nader wrote: > > > Hello, > > > > > > Ubuntu currently ships openssl 3.0. Debian will release with 3.0. > > > > > > Debian experimental contains 3.1. Openssl 3.1 has been out for a couple > > > months. It seemed natural to switch to 3.1 which contains a number of > > > interesting changes including fixes for performance regressions except > > > that... > > > > > > Quoting https://www.openssl.org/policies/releasestrat.html : > > > > > > - Version 3.1 will be supported until 2025-03-14 > > > - Version 3.0 will be supported until 2026-09-07 (LTS). > > > > > > The support for 3.1 spans two years while the support for 3.0 spans 5 > > > years since it's an LTS. > > > > > > If the openssl teams keeps the same cadence (I love extrapolating with > > > only two data points, it's much simpler), then 3.2 could be released > > > September 2024 and it could be just in time to be included in 24.10 but > > > obviously not 24.04. There's also no indication at the moment that 3.2 > > > would be an LTS release. As for 3.3, it would be released March 2026 > and > > > that would still be early enough to make it the next LTS. > > > > > > As I said, these dates are extrapolation based on the 3.0 to 3.1 > release > > > and I haven't seen communication from the openssl team about their > > > roadmap besides that they had to remove it at some point because it > > > needed more work. It's seems unlikely that the result of "more work" is > > > as simple as "release every 18 months". > > > > > > In any case, it seems unlikely that 3.2 is released in time for 24.04 > > > feature freeze AND is an LTS. I'm going to raise this topic on the > > > openssl issue tracker but I wanted to begin the discussion here since > > > the same issue is likely to pop again in the future. > > > > > > In short: > > > > > > In 24.04, do we want to include a release of openssl that will be > > > supported for "at least two years", possibly starting a year before our > > > release, or do we want to include a release that will be supported for > > > "at least five years", possibly starting two years before our release. > > > > I'd rather we stick with an OpenSSL LTS release, as that is possibly what > > others distros will be using and we will be able to collaborate on fixes > > once the upstream support goes away. > > OK. I don't have strong opinions on this, especially since I'm not the > one who will be pushing security updates. > > My main concern is a possible backlash, especially since 3.0's > performance is sometimes a lot worse than 1.1's and that there won't be > a newer version in a Ubuntu LTS before 26.04 ( > https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544 is one > example ). > Can this be cherry picked into mantic? > > > Bonus questions: > > > > > > What do we do when the support on the openssl side ends but there's > > > three more years of support for our LTS releases? > > > > We do like we do for all the other packages in our archive, we backport > > patches to the unsupported version. (And we support our LTS releases for > a > > minimum of 10 years now...) > > I had forgotten this was now 10 years; I was too set on Bionic's > schedule. > > One advantage of using 3.0 is that it would be the same version as in > Jammy. Maybe even 26.04 will use it too... > > > > > > > In case we SRU newer versions of openssl, will we attempt to maintain > > > the same behaviour? (I wanted to ask that question but the answer is > > > probably not a yes/no: a best-effort policy might make more sense) > > > > > > > We don't SRU newer versions of OpenSSL. The attempts we've made in the > past > > to SRU a minor point release resulted in hundreds of fixes required all > over > > the archive and caused regressions for users. Backporting security fixes > and > > specific bug fixes is the best approach. > > Thanks for the explanation. > > -- > Adrien > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: >
linux-headers-5.15.0-1028-gke for Ubuntu 22.04
@elad.ga...@wiz.io
Kernel headers, modules and modules-extras for GKE kernel versions
5.15.0.1027, 5.15.0.1028 and 5.15.0.1030 have now restored to the archive.
There has also been an exception to any archive pruning/deleting made for
future gke
and gkeop (Anthos on VMware) kernel header and module packages due to the
GKE deployments being long-lived and often having older kernels installed.
See https://lists.ubuntu.com/archives/ubuntu-devel/2023-May/042571.html for
context
Phil (Canonical Public Cloud Team)
> 1. Now, instaed of "apt install -y linux-headers-$(uname -r)", I do
> """
> KERNEL_VERSION="$(uname -r | sed 's,-gke,,g')"
> pull-lp-debs -p debs -D ppa --ppa 'canonical-kernel-team/ppa'
> linux-headers-${KERNEL_VERSION}-gke -s all
> pull-lp-debs -p debs -D ppa --ppa 'canonical-kernel-team/ppa'
> linux-gke-headers-${KERNEL_VERSION} -s all
> apt install -y ./*.deb
>
> """
> and it looks OK.
>
>
> 1. I use the latest GKE version, seems like they didn't update the kernel
> versions in them..
>
> Thanks!
>
> From: Dimitri John Ledkov >
> Sent: Monday, May 15, 2023 12:46
> To: Elad Gabay >
> Cc: ubuntu-devel-discuss at lists.ubuntu.com
>
> >
> Subject: Re: linux-headers-5.15.0-1028-gke for Ubuntu 22.04
>
> Caution - External Sender
>
>
> 1) did you try pull-lp-debs as suggested in the first email, and is
> that not sufficient to find/download header debs and install them?
>
> 2) I have to point out that linux-gke 5.15.0-1028.33 was superseded on
> 2023-01-06 (more than 4 months ago) by linux-gke - 5.15.0-1024.29
>
> The kernel gke abi you are using is 4 months obsolete and likely
> contains multiple publicly known security vulnerabilities. GKE
> provides multiple update mechanisms (cluster/image based, or
> apt/unattended-upgrades based) , which one should be using to receive
> kernel security updates for your cluster. Please contact your GKE
> support to investigate why your clusters are not receiving security
> updates.
>
> Given your post, and other posts from other GKE users, I am deeply
> concerned that many GKE deployments are not receiving updates, which
> Ubuntu is publishing for GKE. Note that Ubuntu has no callhome
> capability to explain why particular Ubuntu installations are not
> downloading and applying security updates.
>
> On Sun, 14 May 2023 at 12:26, Elad Gabay > wrote:
> >>* Hi,
> *>* I don't have access to do full host bind mount therefore I can't use
> headers from the node, I need to be able to fetch the headers from a
> container\other machine.
> *>* Now I see the same for linux-headers-5.15.0-1030-gke version.
> *>* Thanks
> *>*
> *>* From: Dimitri John Ledkov >
> *>* Sent: Saturday, May 13, 2023 03:03
> *>* To: Elad Gabay >
> *>* Cc: ubuntu-devel-discuss at lists.ubuntu.com
>
> >
> *>* Subject: Re: linux-headers-5.15.0-1028-gke for Ubuntu 22.04
> *>>* Caution - External Sender
> *>>>* Please see this discussion over here
> *>* https://lists.ubuntu.com/archives/kernel-team/2023-May/139336.html
> and
> *>* the emails before/later in the thread.
> *>>* tl;dr Note you have access to headers on the host that you can bind
> *>* mount in the container, you are using obsolete out-of-date kernel ABI.
> *>* You can use `pull-pkg / pull-lp-debs / pull-lp-ddebs` as needed to
> *>* fetch desired packages for Jammy ABI directly from launchpad.
> *>>* On Sat, 13 May 2023 at 00:51, Elad Gabay > wrote:
> *>* >
> *>* > Hello,
> *>* > Is there a reason that "linux-headers-5.15.0-1028-gke" published only
> for Ubuntu 20.04 but not for 22.04?
> *>* > https://packages.ubuntu.com/uk/focal/main/linux-headers-5.15.0-1028-gke
>
> *>* > Ubuntu – Details of package linux-headers-5.15.0-1028-gke in focal
> *>* > Linux kernel headers for version 5.15.0 on 64 bit x86 SMP
> *>* > packages.ubuntu.com
> *>* >
> *>* >
> *>* > Thanks
> *>* > Elad
> *>* > --
> *>* > Ubuntu-devel-discuss mailing list
> *>* > Ubuntu-devel-discuss at lists.ubuntu.com
>
> *>* > Modify settings or unsubscribe at:
>
Re: Choice of the openssl version for 23.10 and 24.04
On Tue, May 16, 2023, Marc Deslauriers wrote: > On 2023-05-15 05:18, Adrien Nader wrote: > > Hello, > > > > Ubuntu currently ships openssl 3.0. Debian will release with 3.0. > > > > Debian experimental contains 3.1. Openssl 3.1 has been out for a couple > > months. It seemed natural to switch to 3.1 which contains a number of > > interesting changes including fixes for performance regressions except > > that... > > > > Quoting https://www.openssl.org/policies/releasestrat.html : > > > > - Version 3.1 will be supported until 2025-03-14 > > - Version 3.0 will be supported until 2026-09-07 (LTS). > > > > The support for 3.1 spans two years while the support for 3.0 spans 5 > > years since it's an LTS. > > > > If the openssl teams keeps the same cadence (I love extrapolating with > > only two data points, it's much simpler), then 3.2 could be released > > September 2024 and it could be just in time to be included in 24.10 but > > obviously not 24.04. There's also no indication at the moment that 3.2 > > would be an LTS release. As for 3.3, it would be released March 2026 and > > that would still be early enough to make it the next LTS. > > > > As I said, these dates are extrapolation based on the 3.0 to 3.1 release > > and I haven't seen communication from the openssl team about their > > roadmap besides that they had to remove it at some point because it > > needed more work. It's seems unlikely that the result of "more work" is > > as simple as "release every 18 months". > > > > In any case, it seems unlikely that 3.2 is released in time for 24.04 > > feature freeze AND is an LTS. I'm going to raise this topic on the > > openssl issue tracker but I wanted to begin the discussion here since > > the same issue is likely to pop again in the future. > > > > In short: > > > > In 24.04, do we want to include a release of openssl that will be > > supported for "at least two years", possibly starting a year before our > > release, or do we want to include a release that will be supported for > > "at least five years", possibly starting two years before our release. > > I'd rather we stick with an OpenSSL LTS release, as that is possibly what > others distros will be using and we will be able to collaborate on fixes > once the upstream support goes away. OK. I don't have strong opinions on this, especially since I'm not the one who will be pushing security updates. My main concern is a possible backlash, especially since 3.0's performance is sometimes a lot worse than 1.1's and that there won't be a newer version in a Ubuntu LTS before 26.04 ( https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544 is one example ). > > Bonus questions: > > > > What do we do when the support on the openssl side ends but there's > > three more years of support for our LTS releases? > > We do like we do for all the other packages in our archive, we backport > patches to the unsupported version. (And we support our LTS releases for a > minimum of 10 years now...) I had forgotten this was now 10 years; I was too set on Bionic's schedule. One advantage of using 3.0 is that it would be the same version as in Jammy. Maybe even 26.04 will use it too... > > > > In case we SRU newer versions of openssl, will we attempt to maintain > > the same behaviour? (I wanted to ask that question but the answer is > > probably not a yes/no: a best-effort policy might make more sense) > > > > We don't SRU newer versions of OpenSSL. The attempts we've made in the past > to SRU a minor point release resulted in hundreds of fixes required all over > the archive and caused regressions for users. Backporting security fixes and > specific bug fixes is the best approach. Thanks for the explanation. -- Adrien -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu 23.04 is Unusable with GNOME 44.0 Due to Major Bugs - Priority Must Be for GNOME 44.1 ASAP!
Do you have launchpad bugs for these issues? I do have freezes every now and then, and I have seen the cursor being stuck in the resize icon, and wanted to check if the reports match what I'm seeing on my system (xorg). On Tue, May 16, 2023 at 11:44 AM tothepoin...@gmail.com < tothepoin...@gmail.com> wrote: > I am sure I am many who have already pointed this out, but Gnome 44.0 in > Ubuntu 23.04 is plagued with bugs, windows not focusing, random freezes > which requires a hard-reset, mouse cursor stuck on resize icon and do not > even try using a Wayland session. And...And...It's a mess. > > Gnome 44.1 is a major, MAJOR bug fix release that resolves all these > problems. It must be released ASAP to fix 23.04! > > Why have you guys not made it a priority so as to make 23.04 stable? > Other distros had made it a priority and have long put out 44.1, except > Ubuntu! I had to downgrade to 22.10. > > If you are in the process of releasing it then fantastic. What's the > timeline on that? > > Thank you in advance. > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
