Debian 13 "trixie" released
123 points by runxiyu
123 points by runxiyu
Quick note for anyone running Dovecot: the upgrade to version 2.4 is not seamless & the configuration file format has changed. You’ll probably need to do some careful hand editing post upgrade.
This bit me a few months ago when upgrading to testing. The upgrade docs on the dovecot website aren’t great - some of the samples are not the correct syntax!
Other one that bit me was /etc/sysctl.conf is no longer loaded, you need to create a file in /etc/sysctl.d instead.
Can you even upgrade to Trixie and therefore hit that problem? I haven’t checked in a while, but I recall reading that Debian doesn’t support major version upgrades. That’s the main reason I’ve been running Ubuntu Server instead of Debian on my servers to be honest. (I know you can manually edit sources.list, but from everything I read that isn’t supported, while Ubuntu’s do-release-upgrade is)
I guess you could be trying to copy your Bullseye Dovecot config over to a new Trixie server..
Yes, it does support major upgrades. The release notes describe how you do them.
You might be thinking of older RHEL.
I’m fairly certain that I’m thinking about Debian, not RHEL. But I seem to have been wrong. Even looking at old Debian release notes, they clearly contain guidance on upgrading from the previous version.
I half-remember reading StackOverflow answers which provide instructions on how to upgrade to Jessie or something which contained warnings that it’s not officially supported. I might be misremembering, I might have misinterpreted the answers, or they might’ve been incorrect. Regardless, happy to learn that I was wrong.
you’ve been terribly misinformed, Debian has been designed to be, and indeed has been, continuously upgradeable for over thirty years.
some people have even been exercising that upgrade path for that long: https://diziet.dreamwidth.org/11840.html
Correct, see https://lobste.rs/c/bzdynn.
Might start choosing Debian again for servers then. Ubuntu has gone downhill in the past few years.
Yep, my mail server started life on (I believe) debian lenny (v5), over 15 years ago :)
Has gone via every debian version since, it’s had the hardware completely changed out from under it and was later P2V’d, all without a reinstall.
Debian absolutely does support major version upgrades & always has done: It’s one of the core Debian things that they support it!
Upgrading by hand editing sources.list is explicitly supported in the installation instructions / release notes. Some handholding is (inevitably) required for the occasional package, but upgrades are expected to “just work” the vast majority of the time.
This is why the dovecot incompatible upgrade is a (relatively) big deal that will catch people out - they’re used to just hitting the metaphorical upgrade button & letting apt do its thing.
Thanks, I probably would have missed it because I don’t expect email software to break backward compat.
I wasn’t aware of the replicator feature they are removing. If I was, I probably would have been using it instead of a Ceph device, so I guess I was lucky.
FWIW, this one is covered in the Debian release notes too: https://www.debian.org/releases/trixie/release-notes/issues.en.html#dovecot-configuration-changes
I’m terrible myself at bothering to read the Debian upgrade docs, but they’re there and honestly quite good!
I didn’t read Dovecot’s instructions carefully enough so I broke it anyway. That was easy to fix though, so not a big deal. And the new format makes a lot of sense.
Congratulations and thank you to all of the Debian developers. I’ve been a happy user for 30 years.
Trixie has a couple of important changes from the perspective of upstream Rust crates.
cargo in Debian stable now has the MSRV-aware resolver, so when Debian users use Debian-shipped Rust to compile code from crates.io, an upstream crate increasing its MSRV should result in Debian users staying on an old version of the crate instead of getting a build error.
Also, now that 32-bit x86 is no longer supported as an installation architecture and only as multiarch libraries to allow legacy software to run, it’s no longer the case that upstream crates would get compiled by Debian in x87 floating-point mode, which the upstream is unlikely to test. (32-bit x86 configs in upstream Rust have always used SSE2 floating-point math.)
A few hours in with my sandbox laptop… quite uneventful. My provisioning scripts required just a few tweaks (don’t need Emacs from backports anymore…), plus having a more recent Gnome has unlocked a few extensions I’d been ogling for a while.
I think I’ve been using Debian for a good chunk of the last twenty years. I wonder if I’ll still use it in 20 years- that will be close to my retirement…
Is it me or is section 5.1.1 of the upgrade notes a bit terrifying?
An issue in OpenSSH in bookworm can lead to inaccessible remote systems if an upgrade being supervised over an SSH connection is interrupted. Users may be unable to re-connect to the remote system to resume the upgrade.
That’s gotta be a pretty common home user scenario.
There’s a longer explanation on Colin Watson’s blog. What the release notes mean is that you should be able to avoid the problem if you update to the most recent possible version of openssh in bookworm before upgrading to trixie.
Thanks for the link, that makes a ton of sense.
At this point in my life I’m pretty much afraid of running apt over SSH unless it’s in a tmux. I’ve never had a full-brick issue like this SSH upgrade could cause, but I’ve definitely had SSH connections die while apt is waiting for me to answer a modal configuration question. This leaves the package in a semi-configured state and the upgrade half-finished… It’s always been recoverable but there’s been enough “hrmmmm so what is good and what is broken” moments that I just instinctively always do it in a tmux so I can pick up where I left off.
I upgraded a debian 12 VM that was running KDE just fine, and the upgraded system now has fairly frequent OOMs (it is a fairly low memory VM… presumably too low now). It appears plasmashell and kwin in 6.x are using more memory than their 5.x versions – not sure if this is expected (just the nature 6.x) or a bug with the version/build.
Other than that, upgrading from bookworm went quite well! I was expecting more breakages – pleasantly surprised so far.
The Debian codename is assigned before the release number. Debian testing isn’t numbered partly to discourage people from treating it as a release prematurely. The codename acts as a fixed name for use in package URLs across the transition from testing to stable.
Now that I think of it, I’m not sure this reason is valid anymore, since you could write trixie as the source in your sources.list file 2 years ago and it would act the same way that writing testing does. I suppose the difference happens when you actually release trixie and testing is now something else.
In fact, that’s exactly what I did: all my homelab servers have been on trixie rather than testing for months now specifically because I wanted to end up on stable eventually. (I wanted Podman 5 because of certain features, and for reasons I failed to write down I decided to use testing instead of backports.)
The inverse is valid as well, and arguably more important. Bookworm is now oldstable. Specifying “bookworm” in sources.list means that one upgrades when one is ready to, not when upstream decides.
For sure. Honestly, the thing I don’t understand the utility of is tracking something like stable; surely that opens you up to getting ambushed by a major upgrade, right? My Debian-fu isn’t strong enough to have a good idea of how that would play out.
Debian 1.0 was released as 1.1 because a third party distributed CDs of pre-release software claiming to be “Debian 1.0”, which is why Debian stopped assigning numbers before release. The only fixed label that semver gives you is the major number, which necessarily has all the -alpha or -testing caveats stripped off. A naive user looking for the “latest” version is going to pick the biggest number and get a distribution that lacks fast-track security patches and has unannounced disruptive changes.
Because it’s fun
It’s not that fun having to memorize a sorted list of Toy Story characters and their corresponding animal DJs just to manage servers.
It’s worse when they keep choosing names beginning with B, which causes terrible collisions in the shitty meatware hash algorithm that my memory relies on.
It’s even worse when you’re using Ubuntu and some major dependencies that have similar naming conventions, except that each of those major releases tends to only operate on a single version of Ubuntu, so for every single install script you write you have a lookup table of
version = [
("20.04", "focal", "noetic"),
("22.04", "jammy", "humble"),
("24.04", "noble", "jazzy"),
]
I’m glad to have fun but for fuck’s sake guys this is not fun.
I have a small conspirancy theory which is that the release team chose those on purpose to push people into using version numbers instead of codenames more often.