Upcoming Ubuntu 24.04 LTS

Hi @RizzerOnGitHub

I know 24.04 will be another Ubuntu LTS. In the stats for the forum, I can see a lot of people still clicking on posts about 1.93 (e.g., from Ubuntu 20.04 LTS).

When do you think we’d need a 1.99 or 2.0 release to provide you with enough time for the LTS freeze? (including maybe a week or two for last-minute bug fixes like 1.98.1 and your recent bug reports on GitHub)


Based on this release schedule it looks like Feb 29th is the feature freeze, so I guess early February would be the last date? Would that give you enough time to create a DebiChem package?

Or should we try to get snap packages for releases?

Ubuntu is usually quick to pick up the Debian package. They already have builds of avogadrolibs 1.98.1-2, 1.98.1-2 : avogadrolibs package : Ubuntu. So I expect they’ll catch 1.98.1-3 and the corresponding avogadro package in the next day or two.

So if feature freeze is Feb 29 then early February at the latest Feb 10 should give them enough time, assuming there’s no interference from Qt packages (I’ll try Qt6 builds once 1.98.1 reaches testing).

This “fast” build is for the ubuntu “proposed” universe. We can watch the progress of 1.98.1 at avogadrolibs package : Ubuntu to see how long it will take to get to “release” universe, which is where you really want it to appear. There’s a risk that will take longer than we’d like.

IMHO, the Qt6 builds aren’t ready yet. I’m probably going to prioritize features (e.g., spectra, optimization constraints, auto-optimize tool) over Qt6 packaging over the next few weeks.

Great, thanks. So it seems like maybe “end of January” would be the more practical deadline = “about eight weeks from now.”

I’ll target some sort of 1.99 release for “end of January” even if it doesn’t have every bell and whistle.

Sounds good. I’ll stick with Qt5 in the meantime then.

If, by chance, I get everything working with Qt6, there will definitely be some posts on here. I’d rather target that for 2.0 … we use regex pretty heavily. Between those changes and packaging, it’ll take a while.

For .deb accepted to Debian testing, the automatic share and update to its relatives (e.g. Ubuntu, Kali, Raspian, Devuan) can complete in less than a week if the receiving distribution equally has a branch testing (e.g. Raspian) or is rolling (e,g. Kali). Thus, with avogadro 1.98.1-1 accepted by [2023-11-27 Mon] into Debian’s unstable (link to the package tracker), it could be in Debian testing by Sunday, and from there within a week in the proposed launchpads of Ubuntu Noble, too.

Assuming the package 1.98.1 uploaded for Debian testing does not contain an error (and as few as possible warnings), then the almost same stack of files can be used to eventually provide a backport which provides a distribution already published as stable/LTS a newer version of the program. Specific to Debian: this only requires dch --bpo, adjustment of the /debian/changelog file to point to stable-backports, and dpkg-buildpackage -us -uc -sa -D to prepare this upload. (And the upload to yield the backport can take place just after the upload for the version aiming branch testing as temporarily deferred

Because Ubuntu equally allows updates by backports and Avogadro2 already is introduced to the current Ubuntu 22.04 LTS, my suggestion is to keep the dates when Ubuntu 24.04 LTS enters freezing in mind, but prioritize a well rounded, stable Avogadro2. (And perhaps consider a backport of 1.981 to Ubuntu 22.04 LTS).

The hourly update by repology.org about Avogadro2, excluding unsupported Linux distributions (i.e. which no longer receive updates) is the one below:

Packaging status

Snap packages might be an option if snap already is installed and used for other applications. Similar to docker, if this infrastructure is necessary to support only Avogadro as sole application, I would choose the other road (Frost) and use the AppImage instead.

Yep. But I can see on the forum here that there are ~25 visits per day for “Avogadro 1.93 Export Molecule Doesn’t Work” and another ~20-25 visits per day to an issue with Open Babel and 1.93. A release made back in Feb. 2020.

(For reference, the threads about installing DLL for Windows builds get ~50-70 visits per day.)

So while my focus is on making Avogadro2 as good (and stable) a release as possible, I’m also aware that Ubuntu LTS releases are very influential. Whether users are unwilling to install newer packages or Flatpak / AppImage or unable (e.g., they are not allowed to install packages) 1.93 is still out there.

Thus, I’m inclined to make sure there’s some sort of stable release by the end of January.

I’ll leave backports, etc. up to @RizzerOnGitHub … although I’m sure Debichem is always happy to accept help.

Certainly backports are are bit of a nuisance logistically. Generally my busyness plate is full, I try not to add to it by putting backports on top of the workload. Though --bpo might ease some of the pain.

Though Qt6 is not necessary to have sorted by 24.04, I do think it is critical to get Wayland support fixed by 1.99.

Ubuntu has Wayland as the default session since 22.04, but I suspect the number of improvements to the implementation in the last two years will mean a significant increase in the number of users migrating. Fedora is even getting rid of the option of an X11 session (though keeping XWayland) completely from Fedora 40 (spring, so will include Avo 1.99), and it will likewise be gone from RHEL.

Running Avogadro works fine on a Wayland session but only if it is started from the command line, and with -platform xcb to run it with XWayland.

Unfortunately, what I imagine happens instead, and what will only happen more frequently after 24.04: a Linux user (non-technical, doesn’t know what Wayland is) who grabs Avo from the repo to check it out and starts it under Wayland is greeted with an app that just doesn’t work graphically, and will then probably be scared away for life :frowning:

So even if Wayland isn’t actually fixed, we should at least put in a temporary fix and somehow make it so that Avogadro only launches using XWayland (i.e. -platform xcb is “passed” by default).

I don’t know if I’ll have time to tackle GLEW => glbinding because … I don’t know how long it will take. Might be quick, might be a pain.

Let me see if I can at least start a branch to see how much work will be required.

Re the timeline, quoting parts of repology’s log on the example of Avogadro version 1.99:

  • 2024-02-10, Saturday: published on GitHub
  • 2024-02-10 20:25 Saturday: update by Homebrew Casks
  • 2024-02-12 16:31 Monday: manual update in Linux Debian unstable (x + 2 days)
  • 2024-02-15 15:06 Thursday: update Ubuntu 24.04 Proposed leading to the LTS release (x + 5 days)
  • 2024-02-17 04:05 Saturday: regular update in Linux Debian testing (x + 7 days).

Presumably a purely bug fixes 1.99.1 release is fine?

Beyond a question of Avogadro version numbers, packages can certainly backport bug fixes, which is one reason for tracking February 2024 Live Updates :slight_smile:

Yes, that was me. There don’t seem to be many Mac users installing via cask, though (350 over the last year) vs. ~450 already downloaded from GitHub.

I think the concern was that sometimes updates can take longer before they end up in Proposed. As an example, Fedora Rawhide still doesn’t have an update.