Ubuntu 24.04 LTS (Noble Numbat) released

Ubuntu 24.04 LTS, codenamed "Noble Numbat", is here. This release continues
Ubuntu's proud tradition of integrating the latest and greatest open source
technologies into a high-quality, easy-to-use Linux distribution. The team
has been hard at work through this cycle, together with the community and
our partners, to introduce new features and fix bugs.

Our 10th Long Term Supported release sets a new standard in performance
engineering, enterprise security and developer experience.

Ubuntu Desktop brings the Subiquity installer to an LTS for the first time.
In addition to a refreshed user experience and a minimal install by default,
the installer now includes experimental support for ZFS and TPM-based full
disk encryption and the ability to import auto-install configurations. Post
install, users will be greeted with the latest GNOME 46 alongside a new App
Center and firmware-updater. Netplan is now the default for networking
configuration and supports bidirectionality with NetworkManager.

Ubuntu now enables frame pointers by default on 64-bit architectures to
enable CPU and off-CPU profiling for workload optimisation, alongside a
suite of critical performance tools pre-installed. The Linux 6.8 kernel now
enables low-latency features by default. For IoT vendors leveraging 32-bit
arm hardware, our armhf build has been updated to resolve the upcoming 2038
issue by implementing 64-bit time_t in all necessary packages.

As always, Ubuntu ships with the latest toolchain versions. .NET 8 is now
fully supported on Ubuntu 24.04 LTS (and Ubuntu 22.04 LTS) for the full
lifecycle of the release and OpenJDK 21 and 17 are both TCK certified to
adhere to Java interoperability standards. Ubuntu 24.04 LTS ships Rust 1.75
and a simpler Rust toolchain snap framework to enable future rust versions
to be delivered to developers on this release in years to come.

The newest Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon,
Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity, and Xubuntu
are also being released today. More details can be found for these at
their individual release notes under the Official Flavours section:

https://discourse.ubuntu.com/t/noble-numbat-release-notes/

Maintenance updates will be provided for 5 years for Ubuntu Desktop,
Ubuntu Server, Ubuntu Cloud and Ubuntu Core. All the remaining flavours
will be supported for 3 years. Additional security support is available
with ESM (Extended Security Maintenance).

To get Ubuntu 24.04 LTS
-----------------------

In order to download Ubuntu 24.04 LTS, visit:

https://ubuntu.com/download

Users of Ubuntu 23.10 will soon be offered an automatic upgrade to 24.04.
Users of 22.04 LTS will be offered the automatic upgrade when 24.04.1
LTS is released, which is scheduled for the 15th of August.
For further information about upgrading, see:

https://ubuntu.com/download/desktop/upgrade

As always, upgrades to the latest version of Ubuntu are entirely free of
charge.

We recommend that all users read the release notes, which document
caveats and workarounds for known issues, and provide more in-depth
information on the release itself. They are available at:

https://discourse.ubuntu.com/t/noble-numbat-release-notes/

Find out what's new in this release with a graphical overview:

https://ubuntu.com/desktop
https://ubuntu.com/desktop/features

If you have a question, or if you think you may have found a bug but
aren't sure, you can try asking in any of the following places:

#ubuntu on irc.libera.chat
https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
https://ubuntuforums.org
https://askubuntu.com
https://discourse.ubuntu.com

Help Shape Ubuntu
-----------------

If you would like to help shape Ubuntu, take a look at the list of ways
you can participate at:

https://discourse.ubuntu.com/contribute

About Ubuntu
------------

Ubuntu is a full-featured Linux distribution for desktops, laptops, IoT,
cloud, and servers, with a fast and easy installation and regular
releases. A tightly-integrated selection of excellent applications is
included, and an incredible variety of add-on software is just a few
clicks away.

Professional services including support are available from Canonical and
hundreds of other companies around the world. For more information about
support, visit:

https://ubuntu.com/support

More Information
----------------

You can learn more about Ubuntu and about this release on our website
listed below:

https://ubuntu.com

To sign up for future Ubuntu announcements, please subscribe to Ubuntu's
very low volume announcement list at:

https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce

On behalf of the Ubuntu Release Team,
Utkarsh Gupta

--
ubuntu-announce mailing list
ubuntu-announce@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce

Re: pastebinit default target on Ubuntu

Hey,

On apr 16 2024, at 8:23 am, Timo Aaltonen <tjaalton@ubuntu.com> wrote:
> Sergio Durigan Junior kirjoitti 15.4.2024 klo 20.51:
>> dpaste.com also runs a proprietary backend, so I'm -1 on using it.
>> There's dpaste.org, which is FLOSS and doesn't seem to load any ads.
>
> dpaste.org seems like a fine alternative, so +1 here too

Oh, I totally agree with this, and supporting dpaste.org was easy enough:
- https://github.com/pastebinit/pastebinit/pull/5

(for those who wants to use it already, just add that config to
~/.pastebin.d and adjust ~/.pastebinit.xml accordingly).

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: pastebinit default target on Ubuntu

On Tue, Apr 16, 2024 at 05:54:47PM +1200, Michael Hudson-Doyle wrote:

> > The current behavior of paste.ubuntu.com, and what I assumed was the
> > driver for moving away from this as a default, was that it requires a
> > login to VIEW the contents of the pastebin. AFAICS this is not
> > justifiable on the basis of preventing abuse with illicit/illegal
> > pastes, that's already addressed by requiring login on the submission
> > side.

> I think the current behaviour is to require login for at least one of
> submission or view, so a paste created while logged in can be viewed
> anonymously and a paste created anonymously (e.g. by pastebinit, which I
> don't think supports logging in?) requires a login to view.

Ok, I was unaware of this nuance. That being the case, I don't think "login
required" is a sound argument for a default other than paste.ubuntu.com.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

+1 maintenance report (Apr 15-Apr 20, 2024)

Hi there,

I was on my second +1 maintenance shift last week. I spent most of my time working through the update_excuses page from time to time. I spent some time analyzing package-revdep pairs from the non-amd64-nbs list, but couldn't derive the kind of conclusions that I expected to (I must admit that I learnt to think more clearly about NBS in the process).

I list the universe packages that I picked up from the update_excuses regressions and my work on each of them.

=== siconos ===
I came across this package in the NBS list. Tests that use the Python interface fail with 4.4.0+dfsg-4build1 because the Python interface isn't installed (though it is generated), making it akin to FTBFS. I filed a bug report [1]. The upstream setup.py depends on distutils and needs to be migrated to use setuptools, for which I submitted a merge proposal [2]. The bug report has been marked 'wont fix' and siconos binaries removed from noble.

[1] https://bugs.launchpad.net/ubuntu/+source/siconos/+bug/2061719
[2] https://code.launchpad.net/~pushkarnk/ubuntu/+source/siconos/+git/siconos/+merge/464496

=== ogre-next ===
Upstream changes to ogre-next, that apparently enable ogre projects co-exist with ogre-next projects, led to a massive clean-up of debian/rules in version 2.3.3+dfsg-0ubuntu1. The previous version let cmake find OGRE-Next projects by installing a patched .cmake file, which was removed by the latest version. I submitted a bug report [4] and a simple merge proposal [5]. I later withdrew the MP in favor of another MP [6], submitted a few hours before [5].

[4] https://bugs.launchpad.net/ubuntu/+source/ogre-next/+bug/2062378
[5] https://code.launchpad.net/~pushkarnk/ubuntu/+source/ogre-next/+git/ogre-next/+merge/464628
[6] https://code.launchpad.net/~j-rivero/ubuntu/+source/ogre-next/+git/ogre-next/+merge/464598

=== nodejs ===
I found the nodejs autopkgtests failing because of a stale python3-distutils dependency in debian/control/tests. Reported the bug [7] and submitted an MP [8]. Thanks bdrung for sponsoring.

[7] https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/2061946
[8] https://code.launchpad.net/~pushkarnk/ubuntu/+source/nodejs/+git/nodejs/+merge/464487

=== dgit ====
With version 11.7, the manpages-format test fails because it cannot find the tag2upload.5 manpage installed by the git-debpush binary. On investigation, I found tag2upload.5.gz being wrongly installed under man1 (instead of man5). I created a bug report [9] and found a Debian commit [10] that fixes this issue in version 11.8. It might be worth keeping [9] open until we sync with the latest version (11.9 for now) in Debian.

 [9] https://bugs.launchpad.net/ubuntu/+source/dgit/+bug/2062955
[10] https://salsa.debian.org/dgit-team/dgit/-/commit/7e33c8decf6438727a5b2fe15443b3c2f8f1cd43

=== tcpxtract ===
This is an interesting case where an assertion failure can be consistently reproduced on arm64, albeit only with the 1.0.1-17ubuntu1 binaries in the proposed pocket (as of today). The test command is a simple one and I cannot reproduce the failure locally (noble/arm64 on Pi5). Created a bug report [11]. Ran out of guesswork here (maybe I am missing something very fundamental)!

[11] https://bugs.launchpad.net/ubuntu/+source/tcpxtract/+bug/2063015


Other than the above investigations, I also did some autopkgtest requests with the right targets, to get things off the update_excuses list:

pyfai vs. pocl/5.0-2.1build3, which also needed silx/2.0.0+dfsg-1build1
dotnet8 vs. ltt-control -
gnucobol vs. gmp
nauty vs. gmp
normaliz vs. gmp
debcong/1.5.86ubuntu1 vs. rsyslog/8.2312.0-3ubuntu9
python-eventlet vs cinder

As a part of the NBS investigations, I looked into the following package-revdep pairs,
thanks to a guidance document from doko:

libpcap0.8 vs. aircrack-ng - thanks to schopin!
libcups2 vs. libqt5printsupport5t64
libcups2 vs. libqt6printsupport6
libcups2 vs. libqt6printsupport6t64
libcups2 vs. openjdk-8-jre-headless
jdupes vs. libjodycode
libgeoip1 vs. geoip-database
libgeoip1 vs. python3-geoip
libgeoip1 vs. subnetcalc

Thank you!

Pushkar

Re: Searching for autopkgtest regressions in Noble

I forgot to mention but I'd like to thank Brian Murray for helping me with the autopkgtest SQLite database and also suggestions for improvements. And sharing the results for other teams was his idea as well :)

Em 16/04/2024 18:54, Lucas Kanashiro escreveu:

Hi everyone,

As Noble release is approaching and in the final part of the cycle we had some big changes in the archive (time_t transition, xz's CVE fix), the Server team decided to compare the autopkgtest results from before the end of February, more precisely 2024-02-28 (a guess of a date before the time_t work started), and now (2024-04-16). This comparison could show us any potential regression due to big changes in the archive, and allow us to try to address those issues before the release.

What we did is basically get the latest test result of the packages in all architectures before the reference date (2024-02-28) and compare with the latest test run (2024-04-16) of the packages on the same architecture. We are using the autopkgtest SQLite database available here [1]. I am calling it "bad news" when the tests of a package in a given architecture was passing before the reference date and now they are not.

The script I used to do this is available here [2]. And I used the mapping of packages and teams [3] to get the list of packages. The output of the script is a JSON file that looks like the following for one package:

    

    "adsys": {

        "arm64": {

            "before": {

                "result": "all tests passed",

                "test_run_id": "20240227_182345_d0549@",

                "triggers": "samba/2:4.19.5+dfsg-1ubuntu1",

                "test_log": "https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/a/adsys/20240227_182345_d0549@/log.gz"

            },

            "after": {

                "result": "at least one test failed",

                "test_run_id": "20240416_122755_08ec0@",

                "triggers": "sssd/2.9.4-1.1ubuntu6 c-ares/1.27.0-1.0ubuntu1 samba/2:4.19.5+dfsg-4ubuntu9",

                "test_log": "https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/a/adsys/20240416_122755_08ec0@/log.gz"

            }

        }

    },

    

Attached are the output of the scripts for the following teams:

    

- foudantions-bugs

- desktop-packages

- kernel-package

- ubuntu-server 

The Server team is already going through the list to check if there is any real regression requiring some work. Keep in mind that not all packages listed there are necessarily real problems, maybe the test failed because of a bad trigger, or autopkgtest infra issue, so manual check is required to make sure this is a real regression. It is also important to note that the script always gets the latest test result before the reference date, so the failure being analysed could be a flaky test for instance, too.

If you have any question or suggestion on this let me know.

I hope that's useful for other teams.

[1] https://autopkgtest.ubuntu.com/static/autopkgtest.db

[2] https://github.com/lucaskanashiro/autopkgtest-diff

[3] http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.json

--   Lucas Kanashiro

--   Lucas Kanashiro

Searching for autopkgtest regressions in Noble

Hi everyone,

As Noble release is approaching and in the final part of the cycle we had some big changes in the archive (time_t transition, xz's CVE fix), the Server team decided to compare the autopkgtest results from before the end of February, more precisely 2024-02-28 (a guess of a date before the time_t work started), and now (2024-04-16). This comparison could show us any potential regression due to big changes in the archive, and allow us to try to address those issues before the release.

What we did is basically get the latest test result of the packages in all architectures before the reference date (2024-02-28) and compare with the latest test run (2024-04-16) of the packages on the same architecture. We are using the autopkgtest SQLite database available here [1]. I am calling it "bad news" when the tests of a package in a given architecture was passing before the reference date and now they are not.

The script I used to do this is available here [2]. And I used the mapping of packages and teams [3] to get the list of packages. The output of the script is a JSON file that looks like the following for one package:

    

    "adsys": {

        "arm64": {

            "before": {

                "result": "all tests passed",

                "test_run_id": "20240227_182345_d0549@",

                "triggers": "samba/2:4.19.5+dfsg-1ubuntu1",

                "test_log": "https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/a/adsys/20240227_182345_d0549@/log.gz"

            },

            "after": {

                "result": "at least one test failed",

                "test_run_id": "20240416_122755_08ec0@",

                "triggers": "sssd/2.9.4-1.1ubuntu6 c-ares/1.27.0-1.0ubuntu1 samba/2:4.19.5+dfsg-4ubuntu9",

                "test_log": "https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/a/adsys/20240416_122755_08ec0@/log.gz"

            }

        }

    },

    

Attached are the output of the scripts for the following teams:

    

- foudantions-bugs

- desktop-packages

- kernel-package

- ubuntu-server 

The Server team is already going through the list to check if there is any real regression requiring some work. Keep in mind that not all packages listed there are necessarily real problems, maybe the test failed because of a bad trigger, or autopkgtest infra issue, so manual check is required to make sure this is a real regression. It is also important to note that the script always gets the latest test result before the reference date, so the failure being analysed could be a flaky test for instance, too.

If you have any question or suggestion on this let me know.

I hope that's useful for other teams.

[1] https://autopkgtest.ubuntu.com/static/autopkgtest.db

[2] https://github.com/lucaskanashiro/autopkgtest-diff

[3] http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.json

--   Lucas Kanashiro

Re: pastebinit default target on Ubuntu

Sergio Durigan Junior kirjoitti 15.4.2024 klo 20.51:
> On Monday, April 15 2024, Robie Basak wrote:
>
>> Reason to keep it dpaste.com:
>>
>> People have complained that the login requirement makes it unusable for
>> helping Ubuntu users at large who don't necessarily have an Ubuntu SSO
>> account.
>
> The requirement for login is really a pain. I find myself avoiding
> paste.ubuntu.com most of the time because of it, especially if I know
> that the target audience might not even have a Launchpad account.

+1

>> Reason to keep it paste.ubuntu.com:
>>
>> I'm not keen on relying on third party services when not necessary,
>> especially ad-supported ones. I have no reason to distrust the current
>> operator, but in general, these things tend to go wrong sooner or later.
>
> dpaste.com also runs a proprietary backend, so I'm -1 on using it.
> There's dpaste.org, which is FLOSS and doesn't seem to load any ads.

dpaste.org seems like a fine alternative, so +1 here too

--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel