Quoting: Comandante ÑoñardoAs usual, I will upgrade after six months, just when the XX.04.01 version arrive.

See https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906 its scheduled for August 04, so around 4 months as usual for the first point release

View this comment - View article - View full comments

Quoting: CatKiller

Quoting: kaimanPretty conservative Kernel choice, there. I had hoped they'd at least ship with 5.16. OTOH, it will be summer before the .1 release is out and I'll upgrade, and then it's not too long for the first HWE update to materialize. But still ...

There's not really an unambiguously good choice. They've been off-by-one from the LTS kernels before, and it gives them a much higher maintenance burden because they're doing all the maintenance rather than the kernel devs. If they go with the LTS kernel (as they have here) then they either miss out or have to backport useful changes from the next version. Given that they have the HWE mechanism now, it's probably the better choice to use the LTS kernel for those users that aren't on the HWE track (servers, mainly), and have desktop users upgrading on the HWE cycle.

5.17 is also available with the linux-oem-22.04 package  

apt show linux-oem-22.04
Package: linux-oem-22.04
Version: 5.17.0.1003.3
Priority: optional
Section: kernel
Source: linux-meta-oem-5.17
Origin: Ubuntu
Maintainer: Ubuntu Kernel Team <[email protected]>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 9,216 B
Provides: kernel-testing--linux-oem-5.17--full--oem, kernel-testing--linux-oem-5.17--full--preferred
Depends: linux-image-oem-22.04 (= 5.17.0.1003.3), linux-headers-oem-22.04 (= 5.17.0.1003.3)
Download-Size: 1,702 B
APT-Sources: http://mirror.netsite.dk/ubuntu/archive jammy/main amd64 Packages
Description: Complete OEM Linux kernel and headers
 This package will always depend on the latest complete OEM Linux kernel
 and headers.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: Redface

Quoting: slaapliedje

Quoting: Anza

Quoting: RedfaceSee https://lists.debian.org/debian-devel-announce/2021/06/msg00000.html for the full freeze announcement of Buster which links to https://release.debian.org/bullseye/freeze_policy.html#full

QuoteNo changes in unstable that are not targeted for bullseye

Don't upload changes to unstable that are not targeted for bullseye. Having changes in unstable that are not targeted/appropriate for bullseye could complicate fixes for your package and related packages (like dependencies and reverse dependencies).

That means while sid/unstable is not technically frozen there are almost no newer versions during that time, mostly bugfixes, and newer versions only as exception.

I was reading the same document earlier and missed that part. So Debian testing and unstable are more of a rolling release with hiccups about every two years or so.

Basically. Every 6 months, Ubuntu snags a snapshot from Debian and tweaks the stuff and tries to stabilize it and then does a release.

This is just as wrong as: About every 2 years Debian snags a snapshot from sid and tweaks the stuff and tries to stabilize it and then does a release.

A snapshot is a moment in time, not a continuous flow of packages from sid to testing in Debian case, or a continuous flow of packages from sid (and sometimes experimental when sid is to old, like during a testing freeze) to Ubuntu development repositories.

We already had this discussion earlier in https://www.gamingonlinux.com/2021/08/debian-11-qbullseyeq-is-officially-out-now/comment_id=209308 where you had a lot of misunderstandings about Ubuntu where I explained with documentation how it is actually. Including that the automatic flow of packages from sid to Ubuntu devel is something that is turned on and off depending on the development schedule.

You just switched topic to something else inaccurate, until you suggested that a computer automation is something that just is, and can not be turned off by humans, like if computers where power by magic and fairies instead of mathematics and physics: https://www.gamingonlinux.com/2021/08/debian-11-qbullseyeq-is-officially-out-now/comment_id=209696

QuoteUhm... pretty sure it isn't a choice at the moment, it's literally automated.

I just gave up on feeding the troll at that part.

Quoting: slaapliedjeI just stick with Debian Sid as everytime I have strayed, I have not been happy. Unless I require stable (like on servers) then I stick to the Stable branch of Debian.

That is great, use what ever works and you like the most. But why do you have the urge to spread misinformation about other distributions?

Quoting: slaapliedjExcept that Ubuntu now wants you to use snaps instead of .debs.

A few packages are only available as snap and not deb anymore where they where available as deb before.
For 22.04 this will from what we know now be Ubuntu Software and Firefox from packages installed as default, and some more optional where Chromium is probably the most well known example.

But you make it sound like it goes for all packages. There are only the 2 mentioned snaps installed as enduser applications, and they pull in some dependencies like core20 for the core libraries and gnome libraries and gtk-themes, so under 10 snaps over all. And around 1800 deb packages installed, which is that high because many projects are packaged in a way that the source package builds a lot of binary packages.

So all around its like 99.5% of packages installed from a default desktop are deb, and 0.5% are snaps, if you count all the dependency packages as well.

But yeah, Ubuntu is all about snaps now:-) Furthermore you can still just remove all snaps and find alternatives elsewhere.

None of what you showed shows it is any different to what I said except different words. They still get their base debs built because of Debian. I have known about Ubuntu before it was even released. What I said is exactly how they used to do it, and from everything I have seen, it has not changed.

I am not trolling at all, you somehow interpret things differently than I do.

Debian doesn't take a snapshot for development.. they roll in Sid and if a package doesn't have a reported bug in 10 days, it gets shifted to Testing (assuming dependencies are still working). Then before release they do a soft freeze, and try to eliminate bugs, while holding back new versions unless exceptions are made.

Then they will do a hard freeze where it is bug crunch time. But they release when ready (isn't even a full 2 years always).

Ububtu is only remotely stable due to the greatness of Debian.

When Ubuntu is modifying apt to install Chromium via snap... they are wanting people to use snaps. Can't really argue against that... if they had the man power, I bet all of it but the core would be a snap package. The other 95% of packages are basically built by debian maintainers.

Ubuntu does after a release create new repositories right after a release for the development of the next release.
Most packages are synced from sid source packages until that is turned off for the freeze, but not those that have Ubuntu specific patches, those require maintainer attention, and those that do not have sid as upstream like the kernels or nvidia drivers for example.

This is something that goes on for months, so not a snapshot.
https://askubuntu.com/questions/104287/how-is-ubuntu-more-updated-than-debian/104299#104299 old article but well written, but LTS development does not take packages from testing any more, more about that later.

The packages are uploaded as the source packages, and then build on the Ubuntu build servers for that release, which also runs the same release. (the same goes for Debian, the maintainers that create or patch the packages do build them locally or on a build server to test them, but then upload the source packages to the Debian build system where they are then build in a consistent way), so that if the developer had some different libraries or configuration changes locally that it does not influence the build packages)

Neither Debian or Ubuntu use the packages build by the Debian developers so your statement about that Ubuntu is stable because of the packages build by developers makes no sense.
The stability of a distribution comes from the release management, build procedures and QA, all of those Ubuntu does independently of Debian.


The packages build in the Ubuntu devel repositories do not get immediately available to the users that have that distribution installed, but go into the proposed repository first. That way users do not get packages that fail to install or when not all packages are build successfully from one source package.

The disaster that happened to Popos in that YouTube video would not happen when someone uses the Ubutu devel repositories, and of course also not for those using released distributions.


Ubuntu has not modified apt to install Chromium via snap, apt install the Chromium deb package, which is a transitional package, an old concept used by Debian and Ubuntu for many years. That deb package does depend on snapd, which is a deb package that installs snap support. It is that deb package that then install the Chromium snap

See https://packages.ubuntu.com/impish/chromium-browser

Download the source package files, or only the tar.xz, and extract it and look at the debian/chromium-browser.preinst file in it. Its a around 100 lines shell scripts that install the snap.


The pre and post install<and remove scripts in deb packages run as root, and can do anything..
That is one of the major reasons that you have to be very careful with adding apt sources from outside the distribution. And if you do not trust Ubuntu to not install a distribution that adds Ubuntu repositories like Mint or Popos or Kde Neon.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: Anza

Quoting: RedfaceSee https://lists.debian.org/debian-devel-announce/2021/06/msg00000.html for the full freeze announcement of Buster which links to https://release.debian.org/bullseye/freeze_policy.html#full

QuoteNo changes in unstable that are not targeted for bullseye

Don't upload changes to unstable that are not targeted for bullseye. Having changes in unstable that are not targeted/appropriate for bullseye could complicate fixes for your package and related packages (like dependencies and reverse dependencies).

That means while sid/unstable is not technically frozen there are almost no newer versions during that time, mostly bugfixes, and newer versions only as exception.

I was reading the same document earlier and missed that part. So Debian testing and unstable are more of a rolling release with hiccups about every two years or so.

Basically. Every 6 months, Ubuntu snags a snapshot from Debian and tweaks the stuff and tries to stabilize it and then does a release.

This is just as wrong as: About every 2 years Debian snags a snapshot from sid and tweaks the stuff and tries to stabilize it and then does a release.

A snapshot is a moment in time, not a continuous flow of packages from sid to testing in Debian case, or a continuous flow of packages from sid (and sometimes experimental when sid is to old, like during a testing freeze) to Ubuntu development repositories.

We already had this discussion earlier in https://www.gamingonlinux.com/2021/08/debian-11-qbullseyeq-is-officially-out-now/comment_id=209308 where you had a lot of misunderstandings about Ubuntu where I explained with documentation how it is actually. Including that the automatic flow of packages from sid to Ubuntu devel is something that is turned on and off depending on the development schedule.

You just switched topic to something else inaccurate, until you suggested that a computer automation is something that just is, and can not be turned off by humans, like if computers where power by magic and fairies instead of mathematics and physics: https://www.gamingonlinux.com/2021/08/debian-11-qbullseyeq-is-officially-out-now/comment_id=209696

QuoteUhm... pretty sure it isn't a choice at the moment, it's literally automated.

I just gave up on feeding the troll at that part.

Quoting: slaapliedjeI just stick with Debian Sid as everytime I have strayed, I have not been happy. Unless I require stable (like on servers) then I stick to the Stable branch of Debian.

That is great, use what ever works and you like the most. But why do you have the urge to spread misinformation about other distributions?

Quoting: slaapliedjExcept that Ubuntu now wants you to use snaps instead of .debs.

A few packages are only available as snap and not deb anymore where they where available as deb before.
For 22.04 this will from what we know now be Ubuntu Software and Firefox from packages installed as default, and some more optional where Chromium is probably the most well known example.

But you make it sound like it goes for all packages. There are only the 2 mentioned snaps installed as enduser applications, and they pull in some dependencies like core20 for the core libraries and gnome libraries and gtk-themes, so under 10 snaps over all. And around 1800 deb packages installed, which is that high because many projects are packaged in a way that the source package builds a lot of binary packages.

So all around its like 99.5% of packages installed from a default desktop are deb, and 0.5% are snaps, if you count all the dependency packages as well.

But yeah, Ubuntu is all about snaps now:-) Furthermore you can still just remove all snaps and find alternatives elsewhere.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: Anza

Quoting: RedfaceNah, that is Debian, the Ubuntu development version, currently Jammy Jellyfish to be released as 20.04, does come close to a rolling release, but its like Debian testing and unstable affected by freezes, so its not really rolling, but close.

You can also use devel instead of the codename, devel is kind of a symlink to the current development repositories.

At least according to documentation, Debian unstable (aka. sid) is not subject to freezes. Testing is subject to freezes, so rolling stops for a while (shouldn't called testing rolling release as because of that it's not really one).

However as mentioned, there are other distributions out there that do rolling releases. Those are quickest way to fix the problem instead of waiting Canonical to implement true rolling release. Debian is the most familiar for Ubuntu users, Arch is doing bit of its own thing with AUR and all (which is not bad thing at all).

Debian Sid is basically a rolling release. There is usually a bit of a hiccup during the freeze of testing, but it isn't very long. But there is also a period of 'unrest' right after a new stable version is released. This is due to a ton of new packages and version bumps that flood into Sid. Historically there can be pretty nasty breakages during this point. But as long as you use upgrade, and not dist-upgrade, it is fine.

Yeah, and from a user standpoint its the same when running the Ubuntu development release and then after release immediately going to the next, or by tracking devel in the first place.

View this comment - View article - View full comments

Quoting: Anza

Quoting: RedfaceNah, that is Debian, the Ubuntu development version, currently Jammy Jellyfish to be released as 20.04, does come close to a rolling release, but its like Debian testing and unstable affected by freezes, so its not really rolling, but close.

You can also use devel instead of the codename, devel is kind of a symlink to the current development repositories.

At least according to documentation, Debian unstable (aka. sid) is not subject to freezes. Testing is subject to freezes, so rolling stops for a while (shouldn't called testing rolling release as because of that it's not really one).

However as mentioned, there are other distributions out there that do rolling releases. Those are quickest way to fix the problem instead of waiting Canonical to implement true rolling release. Debian is the most familiar for Ubuntu users, Arch is doing bit of its own thing with AUR and all (which is not bad thing at all).

See https://lists.debian.org/debian-devel-announce/2021/06/msg00000.html for the full freeze announcement of Buster which links to https://release.debian.org/bullseye/freeze_policy.html#full

QuoteNo changes in unstable that are not targeted for bullseye

Don't upload changes to unstable that are not targeted for bullseye. Having changes in unstable that are not targeted/appropriate for bullseye could complicate fixes for your package and related packages (like dependencies and reverse dependencies).

That means while sid/unstable is not technically frozen there are almost no newer versions during that time, mostly bugfixes, and newer versions only as exception.

I can tell from experience that running sid is very similar running the Ubuntu development version.
And since Ubuntu is closer to Ubuntu than Debian or Arch then Ubuntu development is the closest to a rolling release Ubuntu.

Instead of release upgrading to the next development release which opens days after the release of the current one, you also can change your repositories to use devel instead of the codename, either manually or with the https://github.com/wimpysworld/rolling-rhino script.

View this comment - View article - View full comments

Quoting: Anza

Quoting: ElectricPrismMAKE A ROLLING RELEASE UBUNTU VARIANT

It kind of exists, it's called Debian. You just need to enable the testing (or sid) repositories.

Nah, that is Debian, the Ubuntu development version, currently Jammy Jellyfish to be released as 20.04, does come close to a rolling release, but its like Debian testing and unstable affected by freezes, so its not really rolling, but close.

You can also use devel instead of the codename, devel is kind of a symlink to the current development repositories.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: shanedav4It's still not an install an go to get it working. You have to compile and install a couple dev version libraries to get it working. One is Xwayland. Forget about installing it on anything but the most bleeding edge rolling release distros. I would say it is still very much beta.

470 seems to already be in Debian Testing / Sid. Only a matter of time until it is backported to Bullseye. Pretty sure it doesn't require bleeding edge, just wait for your distribution to package it.

Nvidia has the requirements listed here https://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/xwayland.html

The xwayland with that commit is released now see https://www.gamingonlinux.com/2021/07/xwayland-2112-is-out-now-with-support-for-hardware-accelerated-nvidia-on-the-470-driver

I have now played several games on Ubuntu 21.10 with the 470 and 495 drivers and all had hardware accelerated graphics. On Gnome and Plasma.

What I had to do on Ubuntu 21.10 (and yammy the upcoming 22.04) was

enable DRM KMS either via inserting nvidia-drm.modeset=1 into grub or by creating a /etc/modprobe.d/zz-nvidia-modeset.conf file with that

Installing libnvidia-egl-wayland1

gsettings set org.gnome.mutter experimental-features [\"kms-modifiers\"]

and then just choosing either Ubuntu on wayland, or plasma on wayland before logging in.

For Debian Bullseye you would also need a newer xwayland and libnvidia-egl-wayland1 but they will maybe be available in backports too

View this comment - View article - View full comments

Quoting: Brandonmccoub2

Quoting: Comandante ÑoñardoWhat about 470.82.00?
Anyway, none of two are available for Ubuntu 20.04 LTS yet.

Do you know if the 495 driver is avaliable yet on Ubuntu?

Both 470.82.00 and 495.44 are in proposed for all supported releases from 18.04 up and the development for 22.04, see https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-470/+bug/1948025

There is always a bugreport tracking the new driver https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-470/+bug/1948025 for 495, I tend to find them on https://people.canonical.com/~ubuntu-archive/pending-sru.html searching for nvidia or whatever I am looking for.

Soon they will come as normal updates unless there are problems delaying that. If you want to try them from proposed read https://wiki.ubuntu.com/Testing/EnableProposed , do not just enable proposed and get everything from there.

I just installed 495 on 21.10 and seems to be ok, I tried Stellaris 64bit, Shadowrun 32bit and a youtube video
Still on xorg, I am going to try with wayland now

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: RedfaceI mentioned in this thread that Lutris is in 21.04, and it will be available in 21.10 when it releases too.
This is an important and in my opinion good way that Ubuntu is based on Debian. If you want a new package in Ubuntu you have to get it into Debian first. Its not only to not duplicate work but also to keep Ubuntu close to Debian.

I have already gone into that they do not build packages to have _ubuntu_ in them. The version of Lutris in 21.10 has no ubuntu in it for example: https://packages.ubuntu.com/hirsute/lutris
And while packaging is an important part to create a distribution, its not all, like for example building is important, where I have posted some links already, and we have not got into supporting multiple releases.

If that basically was no work the Popos and Mint for example would probably not rely on Ubuntu repositories for the bulk of their packages.

And I do have a lot of respect of Debian, it was in fact the first Linux distribution I installed on my Amiga in the 90ies.

What happens when Ubuntu stops listening to fans at all, and just drops 32bit support completely, like they wanted to? Wonder how many people will leave for another Distro.

Predicting the future is hard, but we can look at the past.

They never wanted to drop 32bit completely, see the announcement for dropping the i386 architecture
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2019-June/001261.html

QuoteWhile this means we will not provide 32-bit builds of new upstream versions
of libraries, there are a number of ways that 32-bit applications can
continue to be made available to users of later Ubuntu releases, as detailed
in [4]. We will be working to polish the 32-bit support story over the
course of the 19.10 development cycle. To follow the evolution of this
support, you can participate in the discourse thread at [5].

The controversy was not about that it would be impossible to run 32 bit programs, but that the way it apparently would be done, would both put to much on other developers like Valve and Wine, but also users.

See for example from Valve https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/

QuoteTo provide some background, support for 32-bit libraries is required in order to run not only the Steam client, but also the thousands of games available on Steam that only support 32-bit environments. Enabling the Steam client to run in pure 64-bit environments, while feasible, would leave the vast majority of the current Steam library inaccessible to such users without an additional compatibility layer.

Ubuntu wrote about additional compatibility layers, see above, and Valve then continues to write about their own.

QuoteTo that effect, Steam already bundles a lot of the dependencies needed by 32-bit games, but it currently relies on some key components being available on the host system: a 32-bit glibc, ELF loader, Mesa and NVIDIA graphics driver libraries, to name a few. We've been investigating ways to avoid these system dependencies for a while now, by looking into light containerization and other approaches. The announced change by Ubuntu would have required us to fully complete such a system in the 19.10 release time frame, as it would be required there to maintain functionality without requiring users to reinstall Steam through another method.

And one of the Wine developers: https://www.winehq.org/pipermail/wine-devel/2019-June/147898.html

QuoteIf they don't, then I have a suggestion for our packages: use the
Steam runtime. I see a lot of upsides: They've already solved this
problem; we don't need to re-invent this wheel. Ubuntu is already
working with them to support the use-case. The project is open-source,
well-funded, and has a clear motivation to continue being updated and
functional for the long-term. And people are already building and
running Wine in the runtime today.

And I did not like it either as a user, but I also hated that whole lot of misinformation being spread then. One of my comments to one of the threads on GOL: https://www.gamingonlinux.com/2019/06/canonical-are-now-saying-ubuntus-32bit-is-not-being-entirely-dropped-32bit-libraries-will-be-frozen/comment_id=157675

QuoteThat is not backing out, it is a clarification of their plans. They never said that 32 bit programs would not be able tun run any more. A lot of us are worried that the new ways will be Inferior to what we have today, especially in regard to how complicated it will be for users. And I still are.

A lot of online publication and posters claimed that it would be impossible, but this is Linux not Mac or Windows so there will always be ways for users to do what they want differently than their distribution providers. Do not believe everything you read.

But distributions are about convenience, after all we could all do a Linux from scratch installation and not use any distribution after all. So if they make it a lot harder for users we should go elsewhere.

P.S I did split my answers up in three because I got some error about a security token when posting all in one, but that could have been that I took a long time to write it too.

View this comment - View article - View full comments