Debian 12.5 Released To Provide The Latest Security & Bug Fixes

[phoronix]

Phoronix: Debian 12.5 Released To Provide The Latest Security & Bug Fixes

Debian 12.5 is out this weekend as the newest stable point release for this widely-used Linux distribution in order to ship the latest security fixes and various bug fixes...

https://www.phoronix.com/news/Debian-12.5-Released

[thebear]

One of the few things I miss, coming from Ubuntu, are the hwe releases.. A 6.5 kernel option (at install) for Debian 12 would be nice

[piorunz]

One of the few things I miss, coming from Ubuntu, are the hwe releases.. A 6.5 kernel option (at install) for Debian 12 would be nice

Have you checked what kernel is available in bookworm-backports? It contains exactly that you are looking for, kernel 6.5 😁

https://tracker.debian.org/pkg/linux-signed-amd64

[thebear]

Have you checked what kernel is available in bookworm-backports? It contains exactly that you are looking for, kernel 6.5 😁

https://tracker.debian.org/pkg/linux-signed-amd64

Right, it's probably just me not being able to figure out how to enable backports and configuring linux-image and firmware-nonfree-misc (erc.) to be pulled from backports. I guess I could drop to shell at the end of a guided install before reboot and edit some files + issue some apt commands. But an easier way would be nice. (unless there already is one?)

[ferry]

Right, it's probably just me not being able to figure out how to enable backports and configuring linux-image and firmware-nonfree-misc (erc.) to be pulled from backports. I guess I could drop to shell at the end of a guided install before reboot and edit some files + issue some apt commands. But an easier way would be nice. (unless there already is one?)

Assuming your kernel boots normally you can add Backports to sources.list any time. Instructions are here: https://backports.debian.org/Instructions/
After that installing a kernel from Backports is no different that installing any other package. You could use the CLI apt, TUI aptitude or GUI synaptic, muon.

[piorunz]

Right, it's probably just me not being able to figure out how to enable backports and configuring linux-image and firmware-nonfree-misc (erc.) to be pulled from backports. I guess I could drop to shell at the end of a guided install before reboot and edit some files + issue some apt commands. But an easier way would be nice. (unless there already is one?)

Normal way is to add bookworm-backports later after install. Will your computer not work on default 6.1 kernel?

Anyway, you can add backports by adding this to /etc/apt/sources.list:
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware

Then install backports kernel:
sudo apt update
sudo apt install linux-image-amd64 -t bookworm-backports

You may be able to do it all from install shell, I've never tried it.

[stormcrow]

Right, it's probably just me not being able to figure out how to enable backports and configuring linux-image and firmware-nonfree-misc (erc.) to be pulled from backports. I guess I could drop to shell at the end of a guided install before reboot and edit some files + issue some apt commands. But an easier way would be nice. (unless there already is one?)

In addition to the above replies, please keep in mind that Debian backports can make your system less stable, or even break it. The packages in backports don't go through the same rigorous testing gated stable packages do especially not in the environment that already exists on your computer. Things can break due to library dependency mismatches, lack of testing for the features you might use but others may not, etc.

Heed the warning! If you must use backports, only install the specific package you need. I'll add introducing a new kernel can make the whole system subtly (or not subtly as has been amply demonstrated lately with even the upstream LTS branch) broken. If there's nothing functionally broken with your current setup, then it's advisable to leave it alone! At least till there's a cohesively tested path forward (ex. Debian 13, new MX Linux release, etc. )

Since I mentioned it, I wish I could recommend MX Linux because it's based on Debian stable, but its different in that it doesn't use SystemD (therefore SystemD never gets in your way) and its XFCE "flagship" release follows the LTS kernel + an upgraded Mesa stack, etc. Sounds great in theory. But in practice on my hardware, it introduces enough instability that things are subtly broken. I get random graphics freezes in the XFCE version, and even in the KDE spin there's freezes + crashes of various KDE programs. Debian Bookworm's KDE, on the other hand, is the most stable and best KDE experience I've had in a very long time. So, point is don't rock the boat unless you discover you need to. Undoubtedly you're going to find people that say "Yeah I use backports all the time! It's great!..." I've learned over time that people tend to overlook problems when the problems don't rise to a level that annoys them personally, yet may annoy or be a complete deal breaker to others. So take their assurances and my caution with the same grains of salt.

[iustinp]

In addition to the above replies, please keep in mind that Debian backports can make your system less stable, or even break it. The packages in backports don't go through the same rigorous testing gated stable packages do especially not in the environment that already exists on your computer. Things can break due to library dependency mismatches, lack of testing for the features you might use but others may not, etc.

Heed the warning! If you must use backports, only install the specific package you need. I'll add introducing a new kernel can make the whole system subtly (or not subtly as has been amply demonstrated lately with even the upstream LTS branch) broken. If there's nothing functionally broken with your current setup, then it's advisable to leave it alone! At least till there's a cohesively tested path forward (ex. Debian 13, new MX Linux release, etc. )

While you are correct that backport get less testing, you have two minor issues in the above.

First, backport packages are supported to be testing packages, build on stable. Hence, direct library mismatches can't happen. Of course, there might me bugs related to undeclared-by-depended-on functionality, but it's not like installing the sid package on stable.

Second, related to path forward - there's a reason why you're not allowed to upload into backports _unless_ the package (with that exact version) is already in testing, and the reason is exactly this, a tested path forward. I.e., at any point in time, the package in backports is higher version than stable, but smaller-or-equivalent version to testing, and hence future "new" stable.

[stormcrow]

While you are correct that backport get less testing, you have two minor issues in the above.

First, backport packages are supported to be testing packages, build on stable. Hence, direct library mismatches can't happen. Of course, there might me bugs related to undeclared-by-depended-on functionality, but it's not like installing the sid package on stable.

Second, related to path forward - there's a reason why you're not allowed to upload into backports _unless_ the package (with that exact version) is already in testing, and the reason is exactly this, a tested path forward. I.e., at any point in time, the package in backports is higher version than stable, but smaller-or-equivalent version to testing, and hence future "new" stable.

Which is pretty much what I said. There's more to dependency compatibility than function definition compatibility. Subtle changes in behavior even when the function definitions don't change can still break assumed behavior causing issues elsewhere. Hence the cautions about subtle and non-subtle breakage due to insufficient testing. It's not always obvious if code changes, even minor bug fixes, have unintended consequences elsewhere in a software chain. That's why they're in testing/backports to begin with and haven't been moved to stable (nor will they be released to stable as is, testing doesn't move to stable till the next major release except in rare major security related event where a SID or testing package group has to replace one in stable). I agree the likelihood of breakage isn't that high if it's not a wholesale backports deployment, but it's not zero. The more fundamental the package is to the smooth functioning of the entire system the more likely changes can have undesirable effects, even and especially the kernel and/or Mesa.

[iustinp]

Which is pretty much what I said. There's more to dependency compatibility than function definition compatibility. Subtle changes in behavior even when the function definitions don't change can still break assumed behavior causing issues elsewhere. Hence the cautions about subtle and non-subtle breakage due to insufficient testing. It's not always obvious if code changes, even minor bug fixes, have unintended consequences elsewhere in a software chain. That's why they're in testing/backports to begin with and haven't been moved to stable (nor will they be released to stable as is, testing doesn't move to stable till the next major release except in rare major security related event where a SID or testing package group has to replace one in stable). I agree the likelihood of breakage isn't that high if it's not a wholesale backports deployment, but it's not zero. The more fundamental the package is to the smooth functioning of the entire system the more likely changes can have undesirable effects, even and especially the kernel and/or Mesa.

I still think you're too cautious. It is very possible that a package gets the same version (not debian version) in new stable, just (of course) built against sid. Basically:

v1.1-1 (sid) → promoted to testing →  (time passes) → released as part of new stable v1.1-1
          ⤷  → forked to backports as v1.1-1~bpo1 (no diffs) →      you "upgrade" to ↗︎

Basically, you can get from v1.1-1~bpo1 to v1.1-1, which has zero diffs in both upstream or debian, just rebuilt against different set of packages.

I've ran both backported kernels, and self-built kernels, for years. I've not ran Mesa or Gnome or complex package chains, but the kernel is standalone package. And I've ran even set of packages, like nagios, or norg and borgmatic, etc.

Of course you can get breakage, but it's not like backports is unusable.