Re: Analyzing migrations: britney, update_output.txt, chdist, dose-distcheck, apt solver 3
On Mon, Jun 17, 2024, Adrien Nader wrote: > Second, it would probably be beneficial to have the list of old and new > package names in migrations if they are different. (and then show > package status when hovering over a package's name!) A few mere hours after sending my previous e-mail, I was talking with Graham and was made aware (again?) of the transition tracker. My browser history tends to indicate that I had never visited Ubuntu's before. It can be seen at https://ubuntu-archive-team.ubuntu.com/transitions/index.html There's something to note though: > Affected: .depends ~ > /\b(libvtk9\.3|libvtk9\.3\-qt|libvtk9\.1t64|libvtk9\.1t64\-qt)\b/ This doesn't include libvtk9.1 without the t64 suffix and it was therefore missing some of the packages I had identified manually because these are amd64-only and had not been transition for t64. I don't know how often this kind of situation happens. In any case, I'm also happy because it does what I was after. On https://ubuntu-archive-team.ubuntu.com/transitions/html/auto-vtk9.html#!good,bad,partial,unknown,!notintesting there is a "Collisions" section that says "auto-opencascade through f3d" which is exactly what I had seen and I think I can integrate that into my better excuses frontend. It's reporting "gdal" and "libmatio" however. The transition are basically complete but the new packages declare Breaks: on their previous version... -- 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
Analyzing migrations: britney, update_output.txt, chdist, dose-distcheck, apt solver 3
Hi, This is a documentation message rather than a report. Let's face it: I'm at the stage where I barely understand some parts of britney's reports but as everyone knows, this is also the stage where we feel the most confident teaching about things. This is written as a story rather than documentation with a clear plan but I'll forgive myself as I'll be talking about things which are basically not documented and very little known: anything is an improvement! Finally, let's be frank: you won't read this e-mail in full, it's too long and it will feel too remote from your day-to-day tasks. But! You should however get a high-level idea of what it's talking about and come back when you have a use what is discussed here. # Context As part of my +1 shift last week (this was written 6 days ago), I was using my rewritten update_excuses page: https://ubuntu.dcln.fr/update_excuses.html (I announced it here in an another e-mail a few minutes ago) In this page, excuses are categorized. I've designed the categories as best as I could to make them meaningful (I know there are some things to improve). At some point on Tuesday, the categories and corresponding excuses count were as follows: - needing attention 254 - blocked by another 65 - merely waiting106 - no issues so far6 - waiting for another item's results 9 - requiring approval 1 - Britney missing information 164 The high count for "merely waiting" surprised me as this means britney says the following: Will attempt migration (Any information below is purely informational) Several of these are very recent (expected) but many are a month old! Britney says it's going to migrate them, why is that not happening? I noticed kicad there, I love kicad, let's look at it. The report says it should migrate but it's five days old already. There's no other indication but it depends on opencascade. Opencascade should also migrate too and it's seventeen days old. At this point, we don't have an easy way to figure out the issue from the page (or rather, we didn't have one). # Britney's other output: update_output.txt We can turn to update_output.txt which is documented in exactly two places it seems: - https://wiki.ubuntu.com/ProposedMigration#The_update_output.txt_file_is_completely_unreadable.21 - https://release.debian.org/doc/britney/short-intro-to-migrations.html We look for kicad in update_output.txt. trying: kicad skipped: kicad (115, 1, 42) got: 5+0: a-3:a-0:a-0:i-0:p-0:r-1:s-1 * riscv64: kicad From the "trying: kicad" chunk, we learn that kicad would make kicad uninstallable on riscv64. That's not very helpful (at least to my untrained eyes) and riscv64 is a red herring as britney only complains about one architecture and riscv64 seems to be today's victim. Kicad is also listed in the ipywidgets and opencascade blocks. skipped: ipywidgets (0, 3, 73) got: 5+0: a-4:a-0:a-0:i-0:p-0:r-0:s-1 * amd64: python-ipywidgets-doc [...] * riscv64: f3d, getdp, getdp-sparskit, gmsh, kicad, libadacgi-dev, [...], ada-bar-codes opencascade slic3r-prusa - splitting the component into single items and retrying them trying: slic3r-prusa [...] trying: opencascade skipped: opencascade (0, 5, 142) got: 25+0: a-3:a-0:a-0:i-0:p-0:r-21:s-1 * riscv64: f3d, getdp, getdp-sparskit, gmsh, kicad, [...] trying: ada-bar-codes [...] It seems that installing either will make kicad uninstallable. There's a large overlap between the set of packages that would become uninstallable with these two packages. At that point I had no idea what to look at next so I looked at the first package that would become uninstallable in the lists: f3d. Unlike kicad and opencascade, f3d is reported as blocked due to "another item". Britney mentions "vtk9 (not considered)" and "opencascade". The "not considered" part means that this dependency is stuck; don't ask me why it's "not considered"; don't ask me about which words are used in any of britney's messages. Back to update_output.txt, we look for "f3d" and there's no "trying: f3d": it seems it's only a victim and in any case, it seems we're not going to get more out of update_output.txt for f3d. # Back to update_excuses.html We look at vtk9 and there's an issue with camitk tests on amd64: dependencies cannot be installed. Logs show: 76s Broken libvtk9.3:amd64 Breaks on libvtk9.1:amd64 < none @un H > (< 9.3.0+dfsg1-1) 76s Considering libvtk9.1t64:amd64 9 as a solution to libvtk9.3:amd64 8 76s Re-Instated libvtk9.1t64:amd64 The (first) answer is written but I wasn't satisfied with the short answer and how tedious it was to get there. Moreover I was now wondering why vtk9 was blocking kicad which doesn't depend on it. Indeed, libvtk9.3 has a Breaks on libvtk9.1 and that's probably my
A better update_excuses.html
Hi, I firmly believe that reports must make issues obvious and should offer everything useful for digging in deeper. I don't think update_excuses.html does that: it mostly exposes micro-issues and makes you click several times before getting the information you need. It's britney's output re-formatted rather that we happen to use, not a tool designed for us. Over the past several months, I've been working on a better frontend for it. There's an awful lot more to do but I feel it's already much better. I had been running it from my laptop but I've finally created a production environment for it last week: https://ubuntu.dcln.fr/update_excuses.html The typical update_excuses.html is fetch and rewritten into this page. The reason I don't use the YAML output is because it's not richer nor more structured than the HTML output, and I would be starting from a blank sheet, probably sometimes losing elements. Some of the improvements: a) tabular tests results make it easier to spot patterns (e.g. arch-related failures, but also tests failing on all arches) b) test results have an accompanying date (again, to spot patterns) c) re-written statuses because which I find much more detailed and explicit (e.g. when tests results are not available yet but migration reference failed and that test won't block the migration) d) don't merely display LP bug numbers but also bug title and last-update e) categories and matching package population report e.g. - needing attention (261) [ i.e. at least one test failed ] - blocked by another (61) [ requires another package to also migrate which is blocked ] - merely waiting (148) [ requires another package to also migrate which is not blocked (at least that's what britney says) ] - no issues so far (0) [ no test failed, so far ] - waiting for another item's results (3) [ see below ] - requiring approval (1) [ self-explanatory, now linux-nvidia which blocks the three above ] - Britney missing information (164) [ britney is waiting for something, most likely package builds, sometimes for a long time due to failed builds ] f) ability to hide categories, architectures or packages of some teams g) more up-to-date build status (not a big difference when britney takes 20 minutes to run but a much bigger one when it takes 6 hours) but also more detailed build status: rather than "missing", it can be success, failed, dependency wait and more h) list of packages ready to migrate but blocked by the current package And many more. I usually introduce changes after being frustrated by something. Updates are necessarily delayed compared to britney but only by a few minutes (hi launchpad team! sorry for the server load!). Code is hosted on gitlab: https://gitlab.com/adrien-n/update_excuses_rewriter Feature requests, comments and issue reports are welcome. Keep in mind that if you find something frustrating or painful, you're likely not the only one and many people are probably also slowed down by the same issues. The code is terrible right now, but the goal is to separate parsing current excuses and creating the new output and all will be much better (but that's when I feel confident all of britney's outputs are handled) PS: a lot of the work involved is to actually fully understand britney's output; it's likely that I've misunderstood some nuances and corrections are appreciated. -- 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
Building a database of flaky autopkgtests
Hi, This is something I discussed in Madrid and some people were interested. Basically, I'd like to build a database of tests that are not reliable. I think there is value in knowing which tests are flaky. What will be done or can be done with this knowledge is uncertain and will certainly depend on the results. I don't think it's wise to think too much about the subsequent steps for now. I've spent countless hours on the APIs; they're pretty simple. # IRC Mention "flakydb" on #ubuntu-devel, #ubuntu-release or send me a private message, mention the package name, and write the rest free-form. # E-mail Send me an e-mail with "flakydb" in the subject, mention the package name, and write the rest free-form. # Carrier pigepn similar to e-mail but it won't be available until the eggs have hatched. That's it. I'll do the post-processing. It's entirely optional and more importantly, you can spam me while you're investigating something. If you think a test is flaky, don't wait, send a message, and if later on you find out it isn't, fine, just send another message. I will deal with everything. Same if you don't have all the details or really, any reason. I will handle everything else. The reason it's important to message early is because when investigating a test that turns out to be flaky, a retry is likely to make the test disappear from our radars by definition. Happy spamming, -- 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: New tzdata release for ubuntu 20.04 lts (and higher)
Hi, On Sat, Feb 03, 2024, Dauren Sarsenov wrote: > Hi, guys. > > I wonder, how much time does it usually take to release an update version of > tzdata package? Asking, because there is a new upstream build > (https://www.iana.org/time-zones), and rather critical one to us, who live in > Kazakhstan. The clock is to be moved 1 hour back on the 1st of March 2024. > The new build of tzdata contains the appropriate rule, thus it is highly > anticipated currently. On the Ubuntu side, we are aware of the update but the person usually doing the updates has not been able to do it. This is something that we are planning to address in the next two weeks (regardless of their availability) although I cannot fully guarantee it at the moment. Best, -- 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: Choice of the openssl version for 23.10 and 24.04
On Thu, Dec 14, 2023, Seth Arnold wrote: > On Mon, Dec 04, 2023 at 10:28:02AM +0100, Adrien Nader wrote: > > We talked about creating a new "openssl" package that is whatever the > > most recent version is (in universe, and probably with no ESM-guarantee > > Would this hypothetical package be strictly upstream OpenSSL, or would we > make it match our Opinionated View on OpenSSL? (Or, another way: Would it > support ancient protocols like SSLv2 so that scanner tools could use it?) > > Or, another another way: What problem is this going to solve? It would have been similar to something that would go into Debian's experimental: newer and upcoming versions and changes. The problems that would be solved would have been the ones caused by being unable to upgrade to a newer openssl version basically. But the reasons this has not materialized are not technical. -- 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: Choice of the openssl version for 23.10 and 24.04
Hi, On Mon, Dec 11, 2023, Robie Basak wrote: > On Mon, Dec 04, 2023 at 10:28:02AM +0100, Adrien Nader wrote: > > We talked about creating a new "openssl" package that is whatever the > > most recent version is (in universe, and probably with no ESM-guarantee > > attached somehow). This might need a bit of fiddling with packaging > > though and in any case, I've had absolutely no time to do that so far. > > Please note that this would be problematic for a number of reasons. > > If there's something more recent, then users start using it because it's > more recent. Then they are surprised when they find that it has security > caveats. This just leads to disappointment and frustration all round. > > We had this situation with MySQL in an LTS release many years ago, and > my conclusion following that was that we should never do it again. > > For this reason, I think it's unacceptable to concurrently ship > something newer in a given Ubuntu release unless it comes with all the > same quality commitments we make for the older version. > > > no ESM-guarantee attached somehow > > I don't speak for Canonical here, but also seems unworkable because how > would we describe ESM then? > > ESM* > > * except for packages X, Y and Z > > If you want to "ship" something like this, best be honest about it and > put it in a PPA IMHO. Then it'd be clear to users that it comes with > no/reduced quality commitments. I've been holding off this for months now. I can't find a good way to make it because no matter what I can think of, I know some people will run with it long-term. Well, one way I had in mind was to introduce a time-bomb but I'm not happy with that either. It's an annoying situation because it also prevents people from actually testing new versions, APIs, and so on. But at the same time I really don't want people to believe this would somewhat be "official" and it seems some people would use it almost as such. We all know how things go in practice. So, lot of talks but not a single line of code nor a single command so far. Well, I'll try to get that discussion on release schedule going upstream. I had no time for that until now but it's sorely needed. -- 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: Choice of the openssl version for 23.10 and 24.04
On Mon, Dec 04, 2023, Dimitri John Ledkov wrote: > Hi, > > On Fri, 20 Oct 2023 at 15:35, Adrien Nader wrote: > > > > On Fri, Oct 20, 2023, Adrien Nader wrote: > > > Hi, > > > > > > A few weeks ago, openssl maintainers announced moving to a time-based > > > release (April and October): > > > > > > https://www.openssl.org/blog/blog/2023/09/29/OpenSSL-Update-ICMC23/ > > > > > > > Key takeaway 3 : Time Based Release Policy > > > > We’re transitioning to time-based releases. This shift ensures > > > > predictability, allowing our users and developers to plan better and > > > > benefit from timely updates. The releases will be scheduled every > > > > April and October. > > > > > > Based on this and the openssl 3.0 release date, I'd expect a new LTS > > > version to be released (almost) in time for 26.04 but not for 24.04. > > > > > > *IF* an openssl LTS release is out in April 26.04, we might want to > > > track the corresponding openssl git branch during the 26.04 release in > > > order to be able to ship it. This is more than two years away however > > > and a lot can happen until then. I don't have a crystal ball > > > unfortunately. In any case, we'll know if the planned and the actual > > > release cadence and calendar match. > > > > Dimitri asked me for some more details so I dug a bit more. It's > > actually better explained in a better blog post from late August: > > > > https://www.openssl.org/blog/blog/2023/08/27/steps-forward > > > > > We’re also shifting how we release the OpenSSL library. We’ve adopted > > > a time-based release policy, with releases every April and October. > > > After our 3.2 release in October, our 3.3 release in April next year > > > will be our first time-based release, marking our initial venture into > > > this approach. > > > > And the release policy has been updated too: > > > > https://www.openssl.org/policies/general/release-policy.html > > > > > Planning: Continuous process, provides input to the Release Definition > > > phase. > > > Release Definition: Defines release backlog, lasts up to 4 weeks. > > > Development: Execution of the release backlog, spans from 20 to 24 weeks. > > > Release: Addressing issues discovered by the community in pre-releases. > > > Up to 6 weeks. > > > Support: A support phase. > > > > If they follow their plan, we'd therefore have pre-release versions > > several weeks before Ubuntu releases. Of course, feature freeze > > concerns apply if the pre-release isn't out in time. > > > > That's all I've seen so far (OK, I didn't dig that much). We'll see very > > soon how that turns out in practice for the 3.2 release. > > With every other major piece of our dependencies, we have committed to > picking up regular time based releases which fit our schedule. > This includes things like GNOME, KDE, OpenStack, GCC. > I think we should commit to picking up the latest OpenSSL for every > Ubuntu release going forward. > 3.2 has been released, albeit in late November, and we should show > good will and encourage OpenSSL to stick to their new time based > releases. > > Can we please start the upgrade of OpenSSL to 3.2? > > And then if OpenSSL 3.3 is released in early April, pick that up as > well for 24.04. If the new cadence for 3.3 means May, pick it up for > the 24.10 instead. The issue is that we do not know when will be the next openssl LTS. We can safely bet there will be one before 26.04 and update to the most recent version for 24.10 (since by 26.04, the current LTS won't be supported anymore). However we can't really bet there will be one by 24.04 and even if there were, there probably wouldn't be a new one in time by 26.04. What you are asking for is equivalent to not using openssl LTS releases for Ubuntu LTS releases. There are many more non-LTS releases so we're more likely to end up with a non-LTS version. Openssl time-based releases are very very recent. This was announced late August and only one version was released under this model so far. It wasn't even on time. The delay was fairly small, especially for a first version using this model (and a change mid-cycle). I think they need a bit more time. Will they be late again? Will they continue this scheme? What else? I don't expect openssl upstream can answer these; they don't have enough hindsight yet. We talked about creating a new "openssl" package that is whatever the most recent version is (in universe, and probably with no ESM-guarantee attached somehow). This might need a bit of fiddling with packaging though and in any case, I've had absolutely no time to do that so far. Would such a package fit the needs you see? Otherwise, really, I think your question is equivalent to not using openssl LTS releases which would be a big departure from the current position. -- 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: Choice of the openssl version for 23.10 and 24.04
On Mon, Dec 04, 2023, Dimitri John Ledkov wrote: > On Mon, 4 Dec 2023 at 12:34, Adrien Nader wrote: > > > > (stripping the quotes a bit) > > > > On Mon, Dec 04, 2023, Dimitri John Ledkov wrote: > > > On Mon, 4 Dec 2023 at 09:28, Adrien Nader wrote: > > > > The issue is that we do not know when will be the next openssl LTS. We > > > That's irrelevant. Once Ubuntu release goes stable, we no longer apply > > > full upstream point releases, and create our own stream of security > > > and stable fixes anyway. > > > Our timelines of support are also longer than either shorter or longer > > > upstream support timelines. > > > > The point is that security updates require work and using a version that > > no other distribution uses (which will always be the case unless other > > distribution release dates align with Ubuntu's) prevents sharing the > > work with other distributions. This was stated earlier (months ago) in > > this thread. I don't know how that played out in hindsight. That would > > be an interesting thing to know. > > > > Even if we're not on the same point version as other distributions, > > there is still a lot of common things, especially for typical security > > patches, and lots of testing in common. I don't think the patches are > > very difficult to port across versions (except the ones which porting is > > horribly painful) but QA and verification are another matter. Keep in > > mind that 3.0 was a big release with many architectural changes and this > > has continued in 3.1 and 3.2. There are certainly fewer and fewer > > changes but I don't think I would call these changes uncommon yet. > > > > Finally, Ubuntu is not the only distribution with longer support than > > openssl's five years for LTS: there can still be cross-distro > > cooperation after these years, and it will actually be even more > > valuable. > > > > > > can safely bet there will be one before 26.04 and update to the most > > > > recent version for 24.10 (since by 26.04, the current LTS won't be > > > > supported anymore). However we can't really bet there will be one by > > > > 24.04 and even if there were, there probably wouldn't be a new one in > > > > time by 26.04. > > > > > > > > What you are asking for is equivalent to not using openssl LTS releases > > > > for Ubuntu LTS releases. > > > > > > Yes. > > > > > > > There are many more non-LTS releases so we're > > > > more likely to end up with a non-LTS version. > > > > > > > > Openssl time-based releases are very very recent. > > > > > > We did ship the first KDE time-based release when it came out for the > > > first time. > > > > KDE, especially in Ubuntu, is far less risky than openssl. It is also > > updated far more easily. > > > > I've been trying to make an SRU for openssl for several months now and > > it hasn't landed yet. I'm not blaming anyone here: there are tons of > > reasons for that (including the fact that I don't have the bandwidth to > > re-spin something at the moment). > > > > The fact is that today we're not able to update openssl for anything > > except security updates. In other words, no matter what the openssl > > maintainer puts in a release, that maintainer won't have anything to do > > with it after the release: only the security team will. That makes me > > completely uncomfortable with using a release without some kind of > > agreement with the security team. Using the most recent version would > > make my life easier but I don't think it's the right trade-off here. > > > > By the way, I don't know how that would play with FIPS: I'm not sure it > > would be manageable. > > > > > > This was announced > > > > late August and only one version was released under this model so far. > > > > It wasn't even on time. The delay was fairly small, especially for a > > > > first version using this model (and a change mid-cycle). I think they > > > > need a bit more time. Will they be late again? Will they continue this > > > > scheme? What else? I don't expect openssl upstream can answer these; > > > > they don't have enough hindsight yet. > > > > > > > > We talked about creating a new "openssl" package that is whatever the > > > > most recent version is (in universe, and probably with no ESM-guarantee > > > > attached somehow). This might need a bit of fiddling with packagi
Re: Choice of the openssl version for 23.10 and 24.04
(stripping the quotes a bit) On Mon, Dec 04, 2023, Dimitri John Ledkov wrote: > On Mon, 4 Dec 2023 at 09:28, Adrien Nader wrote: > > The issue is that we do not know when will be the next openssl LTS. We > That's irrelevant. Once Ubuntu release goes stable, we no longer apply > full upstream point releases, and create our own stream of security > and stable fixes anyway. > Our timelines of support are also longer than either shorter or longer > upstream support timelines. The point is that security updates require work and using a version that no other distribution uses (which will always be the case unless other distribution release dates align with Ubuntu's) prevents sharing the work with other distributions. This was stated earlier (months ago) in this thread. I don't know how that played out in hindsight. That would be an interesting thing to know. Even if we're not on the same point version as other distributions, there is still a lot of common things, especially for typical security patches, and lots of testing in common. I don't think the patches are very difficult to port across versions (except the ones which porting is horribly painful) but QA and verification are another matter. Keep in mind that 3.0 was a big release with many architectural changes and this has continued in 3.1 and 3.2. There are certainly fewer and fewer changes but I don't think I would call these changes uncommon yet. Finally, Ubuntu is not the only distribution with longer support than openssl's five years for LTS: there can still be cross-distro cooperation after these years, and it will actually be even more valuable. > > can safely bet there will be one before 26.04 and update to the most > > recent version for 24.10 (since by 26.04, the current LTS won't be > > supported anymore). However we can't really bet there will be one by > > 24.04 and even if there were, there probably wouldn't be a new one in > > time by 26.04. > > > > What you are asking for is equivalent to not using openssl LTS releases > > for Ubuntu LTS releases. > > Yes. > > > There are many more non-LTS releases so we're > > more likely to end up with a non-LTS version. > > > > Openssl time-based releases are very very recent. > > We did ship the first KDE time-based release when it came out for the > first time. KDE, especially in Ubuntu, is far less risky than openssl. It is also updated far more easily. I've been trying to make an SRU for openssl for several months now and it hasn't landed yet. I'm not blaming anyone here: there are tons of reasons for that (including the fact that I don't have the bandwidth to re-spin something at the moment). The fact is that today we're not able to update openssl for anything except security updates. In other words, no matter what the openssl maintainer puts in a release, that maintainer won't have anything to do with it after the release: only the security team will. That makes me completely uncomfortable with using a release without some kind of agreement with the security team. Using the most recent version would make my life easier but I don't think it's the right trade-off here. By the way, I don't know how that would play with FIPS: I'm not sure it would be manageable. > > This was announced > > late August and only one version was released under this model so far. > > It wasn't even on time. The delay was fairly small, especially for a > > first version using this model (and a change mid-cycle). I think they > > need a bit more time. Will they be late again? Will they continue this > > scheme? What else? I don't expect openssl upstream can answer these; > > they don't have enough hindsight yet. > > > > We talked about creating a new "openssl" package that is whatever the > > most recent version is (in universe, and probably with no ESM-guarantee > > attached somehow). This might need a bit of fiddling with packaging > > though and in any case, I've had absolutely no time to do that so far. > > > > Would such a package fit the needs you see? > > Only one version, the latest openssl, in every Ubuntu release, going forward. > > Shipping two openssl in the archive is extremely difficult and ends up > being unusable. Devel packages previously have not been coinstallable > and even if they are it is impossible to get a consistent build > environment that can build either or both openssl versions, leading to > extremely bad user experience. For example inability to compile > scripting language native extensions as part of container builds and > the like - prime past example > https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1794589 Thanks for the link. I was expecting some troubles around that approach but didn't know this had already happened.
Re: Choice of the openssl version for 23.10 and 24.04
NB: re-sending with an e-mail adderss that isn't moderated; moderator: feel free to reject duplicate mails in the moderation queue (stripping the quotes a bit) On Mon, Dec 04, 2023, Dimitri John Ledkov wrote: > On Mon, 4 Dec 2023 at 09:28, Adrien Nader wrote: > > The issue is that we do not know when will be the next openssl LTS. We > That's irrelevant. Once Ubuntu release goes stable, we no longer apply > full upstream point releases, and create our own stream of security > and stable fixes anyway. > Our timelines of support are also longer than either shorter or longer > upstream support timelines. The point is that security updates require work and using a version that no other distribution uses (which will always be the case unless other distribution release dates align with Ubuntu's) prevents sharing the work with other distributions. This was stated earlier (months ago) in this thread. I don't know how that played out in hindsight. That would be an interesting thing to know. Even if we're not on the same point version as other distributions, there is still a lot of common things, especially for typical security patches, and lots of testing in common. I don't think the patches are very difficult to port across versions (except the ones which porting is horribly painful) but QA and verification are another matter. Keep in mind that 3.0 was a big release with many architectural changes and this has continued in 3.1 and 3.2. There are certainly fewer and fewer changes but I don't think I would call these changes uncommon yet. Finally, Ubuntu is not the only distribution with longer support than openssl's five years for LTS: there can still be cross-distro cooperation after these years, and it will actually be even more valuable. > > can safely bet there will be one before 26.04 and update to the most > > recent version for 24.10 (since by 26.04, the current LTS won't be > > supported anymore). However we can't really bet there will be one by > > 24.04 and even if there were, there probably wouldn't be a new one in > > time by 26.04. > > > > What you are asking for is equivalent to not using openssl LTS releases > > for Ubuntu LTS releases. > > Yes. > > > There are many more non-LTS releases so we're > > more likely to end up with a non-LTS version. > > > > Openssl time-based releases are very very recent. > > We did ship the first KDE time-based release when it came out for the > first time. KDE, especially in Ubuntu, is far less risky than openssl. It is also updated far more easily. I've been trying to make an SRU for openssl for several months now and it hasn't landed yet. I'm not blaming anyone here: there are tons of reasons for that (including the fact that I don't have the bandwidth to re-spin something at the moment). The fact is that today we're not able to update openssl for anything except security updates. In other words, no matter what the openssl maintainer puts in a release, that maintainer won't have anything to do with it after the release: only the security team will. That makes me completely uncomfortable with using a release without some kind of agreement with the security team. Using the most recent version would make my life easier but I don't think it's the right trade-off here. By the way, I don't know how that would play with FIPS: I'm not sure it would be manageable. > > This was announced > > late August and only one version was released under this model so far. > > It wasn't even on time. The delay was fairly small, especially for a > > first version using this model (and a change mid-cycle). I think they > > need a bit more time. Will they be late again? Will they continue this > > scheme? What else? I don't expect openssl upstream can answer these; > > they don't have enough hindsight yet. > > > > We talked about creating a new "openssl" package that is whatever the > > most recent version is (in universe, and probably with no ESM-guarantee > > attached somehow). This might need a bit of fiddling with packaging > > though and in any case, I've had absolutely no time to do that so far. > > > > Would such a package fit the needs you see? > > Only one version, the latest openssl, in every Ubuntu release, going forward. > > Shipping two openssl in the archive is extremely difficult and ends up > being unusable. Devel packages previously have not been coinstallable > and even if they are it is impossible to get a consistent build > environment that can build either or both openssl versions, leading to > extremely bad user experience. For example inability to compile > scripting language native extensions as part of container builds and > the like - prime past example > https://bugs.launchpad.net/ubuntu/+source/nodejs/+
Re: Choice of the openssl version for 23.10 and 24.04
NB: re-sending with an e-mail adderss that isn't moderated; moderator: feel free to reject duplicate mails in the moderation queue On Mon, Dec 04, 2023, Dimitri John Ledkov wrote: > Hi, > > On Fri, 20 Oct 2023 at 15:35, Adrien Nader wrote: > > > > On Fri, Oct 20, 2023, Adrien Nader wrote: > > > Hi, > > > > > > A few weeks ago, openssl maintainers announced moving to a time-based > > > release (April and October): > > > > > > https://www.openssl.org/blog/blog/2023/09/29/OpenSSL-Update-ICMC23/ > > > > > > > Key takeaway 3 : Time Based Release Policy > > > > We’re transitioning to time-based releases. This shift ensures > > > > predictability, allowing our users and developers to plan better and > > > > benefit from timely updates. The releases will be scheduled every > > > > April and October. > > > > > > Based on this and the openssl 3.0 release date, I'd expect a new LTS > > > version to be released (almost) in time for 26.04 but not for 24.04. > > > > > > *IF* an openssl LTS release is out in April 26.04, we might want to > > > track the corresponding openssl git branch during the 26.04 release in > > > order to be able to ship it. This is more than two years away however > > > and a lot can happen until then. I don't have a crystal ball > > > unfortunately. In any case, we'll know if the planned and the actual > > > release cadence and calendar match. > > > > Dimitri asked me for some more details so I dug a bit more. It's > > actually better explained in a better blog post from late August: > > > > https://www.openssl.org/blog/blog/2023/08/27/steps-forward > > > > > We’re also shifting how we release the OpenSSL library. We’ve adopted > > > a time-based release policy, with releases every April and October. > > > After our 3.2 release in October, our 3.3 release in April next year > > > will be our first time-based release, marking our initial venture into > > > this approach. > > > > And the release policy has been updated too: > > > > https://www.openssl.org/policies/general/release-policy.html > > > > > Planning: Continuous process, provides input to the Release Definition > > > phase. > > > Release Definition: Defines release backlog, lasts up to 4 weeks. > > > Development: Execution of the release backlog, spans from 20 to 24 weeks. > > > Release: Addressing issues discovered by the community in pre-releases. > > > Up to 6 weeks. > > > Support: A support phase. > > > > If they follow their plan, we'd therefore have pre-release versions > > several weeks before Ubuntu releases. Of course, feature freeze > > concerns apply if the pre-release isn't out in time. > > > > That's all I've seen so far (OK, I didn't dig that much). We'll see very > > soon how that turns out in practice for the 3.2 release. > > With every other major piece of our dependencies, we have committed to > picking up regular time based releases which fit our schedule. > This includes things like GNOME, KDE, OpenStack, GCC. > I think we should commit to picking up the latest OpenSSL for every > Ubuntu release going forward. > 3.2 has been released, albeit in late November, and we should show > good will and encourage OpenSSL to stick to their new time based > releases. > > Can we please start the upgrade of OpenSSL to 3.2? > > And then if OpenSSL 3.3 is released in early April, pick that up as > well for 24.04. If the new cadence for 3.3 means May, pick it up for > the 24.10 instead. The issue is that we do not know when will be the next openssl LTS. We can safely bet there will be one before 26.04 and update to the most recent version for 24.10 (since by 26.04, the current LTS won't be supported anymore). However we can't really bet there will be one by 24.04 and even if there were, there probably wouldn't be a new one in time by 26.04. What you are asking for is equivalent to not using openssl LTS releases for Ubuntu LTS releases. There are many more non-LTS releases so we're more likely to end up with a non-LTS version. Openssl time-based releases are very very recent. This was announced late August and only one version was released under this model so far. It wasn't even on time. The delay was fairly small, especially for a first version using this model (and a change mid-cycle). I think they need a bit more time. Will they be late again? Will they continue this scheme? What else? I don't expect openssl upstream can answer these; they don't have enough hindsight yet. We talked about creating a new "openssl"
Re: Choice of the openssl version for 23.10 and 24.04
NB: attempting to re-send with a slightly different e-mail address that might make my mails pass list moderation automatically (no idea why I receive mails to a From: which isn't the one I'm subscribed with) On Mon, Dec 04, 2023, Dimitri John Ledkov wrote: > On Mon, 4 Dec 2023 at 12:34, Adrien Nader wrote: > > I concur with you here: I believe that using 3.0 in Noble is > > problematic. However I think we do not have a good solution at the > > moment. All solutions have serious drawbacks. > > > > For the record, I started this thread when I was about to update openssl > > to 3.1 in whichever release was under development back then. And at some > > point I realized things were not going to work out well. One thing > > that's very difficult is that when Ubuntu non-LTS gets a new openssl > > version, we have no idea on which openssl version we'll end up for our > > next LTS. > > > > This can improve with openssl having a release schedule but > > what we really need is the LTS schedule. This is really a recent change > > for openssl and I haven't had time to interact with upstream since 3.2 > > was released (before that I was monitoring how that release was going). > > Strictly speaking, there could be openssl LTS releases every 4.5 years > > and that would be really painful. Less than every 2 years seems > > doubtful. I would expect something between 2 and 4 years: 2, 2.5, 3, > > 3.5, 4; that's a lot of possibilities. > > > > (I'll draft something on pen and paper and see if a two-years and > > three-years cadence for LTS would be sensible based on the 5=4+1 years > > of openssl LTS schedule) > > > > We should first engage with upstream on this. I've had absolutely no > > time since mid-October but I hope I can make a bit of room for that > > soon. At least we should check if this has been brought up recently. > > https://www.openssl.org/blog/blog/2023/11/23/OpenSSL32/ > """ > The next feature release after OpenSSL 3.2 will be OpenSSL 3.3, which > will be released no later than 30 April 2024. This release is expected > to include QUIC server support. The determination of what other > features will be shipped in OpenSSL 3.3 is ongoing and will be decided > by our recently announced Release Steering Committee. > """ > Thus timing wise it seems doable to ship noble with v3.3, unless things slip > > Looking at feature list between v3.0 and v3.2, we absolutely desire: > > * Support for client side QUIC, including support for multiple streams > (RFC 9000) That one was at or near the top of openssl changes that made me want to update but it turns out it's a new API and therefore not compatible with one of the existing QUIC libraries. As such, openssl might not be where to look for when it comes to QUIC support. (I don't know how's our support for QUIC currently) > * Support for Ed25519ctx, Ed25519ph and Ed448ph in addition to > existing support for Ed25519 and Ed448 (RFC 8032) > * Support for deterministic ECDSA signatures (RFC 6979) > * Support for the Argon2 KDF, along with supporting thread pool > functionality (RFC 9106) > * Support for TCP Fast Open on Linux, macOS and FreeBSD, where enabled > and supported (RFC 7413) > * Support for TLS certificate compression, including library support > for zlib, Brotli and zstd (RFC 8879) > > Without these features, most users will seek out to get that, and will > find ways to get it, without running our build of OpenSSL, exposing > them to security risks. > > Can you backport all of that to the v3.0 series? how is that going to > make it look any much different from shipping v3.2 or v3.3? This has been my concern too: I don't want us to end up with a franken-openssl. I'm now very confident this won't happen, in particular for Noble. The only question is therefore how needed are these features. If you look at the changes in openssl 3.x versions, you'll always see a long list of change at a pretty rapid pace. I'm sure 3.3 will include many features we'll want too. I have absolutely no doubt about it. But what's the point in shipping something we cannot support? Today we can't really support an non-LTS openssl version. We wouldn't have this conversation if openssl were in universe but it's not, it's in main. > https://www.openssl.org/policies/releasestrat.html > """ > We may designate a release as a Long Term Support (LTS) release. LTS > releases will be supported for at least five years and we will specify > one at least every four years. Non-LTS releases will be supported for > at least two years. > """ I remembered only one year for non-LTS but like for LTS, that final year is security-only. > If synergy and co
Re: Choice of the openssl version for 23.10 and 24.04
On Fri, Oct 20, 2023, Adrien Nader wrote: > Hi, > > A few weeks ago, openssl maintainers announced moving to a time-based > release (April and October): > > https://www.openssl.org/blog/blog/2023/09/29/OpenSSL-Update-ICMC23/ > > > Key takeaway 3 : Time Based Release Policy > > We’re transitioning to time-based releases. This shift ensures > > predictability, allowing our users and developers to plan better and > > benefit from timely updates. The releases will be scheduled every > > April and October. > > Based on this and the openssl 3.0 release date, I'd expect a new LTS > version to be released (almost) in time for 26.04 but not for 24.04. > > *IF* an openssl LTS release is out in April 26.04, we might want to > track the corresponding openssl git branch during the 26.04 release in > order to be able to ship it. This is more than two years away however > and a lot can happen until then. I don't have a crystal ball > unfortunately. In any case, we'll know if the planned and the actual > release cadence and calendar match. Dimitri asked me for some more details so I dug a bit more. It's actually better explained in a better blog post from late August: https://www.openssl.org/blog/blog/2023/08/27/steps-forward > We’re also shifting how we release the OpenSSL library. We’ve adopted > a time-based release policy, with releases every April and October. > After our 3.2 release in October, our 3.3 release in April next year > will be our first time-based release, marking our initial venture into > this approach. And the release policy has been updated too: https://www.openssl.org/policies/general/release-policy.html > Planning: Continuous process, provides input to the Release Definition phase. > Release Definition: Defines release backlog, lasts up to 4 weeks. > Development: Execution of the release backlog, spans from 20 to 24 weeks. > Release: Addressing issues discovered by the community in pre-releases. Up to > 6 weeks. > Support: A support phase. If they follow their plan, we'd therefore have pre-release versions several weeks before Ubuntu releases. Of course, feature freeze concerns apply if the pre-release isn't out in time. That's all I've seen so far (OK, I didn't dig that much). We'll see very soon how that turns out in practice for the 3.2 release. -- 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: Choice of the openssl version for 23.10 and 24.04
Hi, A few weeks ago, openssl maintainers announced moving to a time-based release (April and October): https://www.openssl.org/blog/blog/2023/09/29/OpenSSL-Update-ICMC23/ > Key takeaway 3 : Time Based Release Policy > We’re transitioning to time-based releases. This shift ensures > predictability, allowing our users and developers to plan better and > benefit from timely updates. The releases will be scheduled every > April and October. Based on this and the openssl 3.0 release date, I'd expect a new LTS version to be released (almost) in time for 26.04 but not for 24.04. *IF* an openssl LTS release is out in April 26.04, we might want to track the corresponding openssl git branch during the 26.04 release in order to be able to ship it. This is more than two years away however and a lot can happen until then. I don't have a crystal ball unfortunately. In any case, we'll know if the planned and the actual release cadence and calendar match. -- Adrien On Wed, May 31, 2023, Adrien Nader wrote: > Hi, > > On Thu, May 18, 2023, Adrien Nader wrote: > > On Wed, May 17, 2023, Dimitri John Ledkov wrote: > > > 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. > > > > Note that experimental currently has 3.1 (yes, it's experimental and it > > doesn't have to go anywhere else). > > > > I need to get in touch with the team on the debian side and ask them > > their plans regarding versions support. > > I don't actually have a particularly good channel to discuss with them. > > I guess it would also make more sense that the people doing the updates > in the stable releases do, especially if that involves more than Debian. > > -- > 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: Choice of the openssl version for 23.10 and 24.04
Hi, On Thu, May 18, 2023, Adrien Nader wrote: > On Wed, May 17, 2023, Dimitri John Ledkov wrote: > > 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. > > Note that experimental currently has 3.1 (yes, it's experimental and it > doesn't have to go anywhere else). > > I need to get in touch with the team on the debian side and ask them > their plans regarding versions support. I don't actually have a particularly good channel to discuss with them. I guess it would also make more sense that the people doing the updates in the stable releases do, especially if that involves more than Debian. -- 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: Choice of the openssl version for 23.10 and 24.04
On Wed, May 17, 2023, Dimitri John Ledkov wrote: > 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. Note that experimental currently has 3.1 (yes, it's experimental and it doesn't have to go anywhere else). I need to get in touch with the team on the debian side and ask them their plans regarding versions support. > 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. Unfortunately, the optimisations currently being added don't seem very standalone since they're frequently architectural ones (see the end of this message). Even benchmarking might be non-trivial. For instance, one of the current issue seem to be locking and lock contention: properly benchmarking such changes requires a good test environment and possibly extra hardware. I had thought about making a PPA for newer versions in order to make it easier for people to execute their own benchmark with them. That's maybe the only way to gather more feedback on the performance changes. > 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
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
Choice of the openssl version for 23.10 and 24.04
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. 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? 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) -- 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
