MichaIng
Debian Trixie | Upgrade script support thread
Similar to how we did for Debian Bullseye => Bookworm upgrades, we created a script to upgrade from Debian Bookworm to Trixie: https://github.com/MichaIng/DietPi/blob/dev/.meta/dietpi-trixie-upgrade
To upgrade your Debian 12 Bookworm based system to Debian 13 Trixie:
sudo bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-trixie-upgrade')"
From DietPi side, all base features and software options have been tested, though many via automated install tests, checking that the install procedure goes through, expected services are running, network ports are up, CLI commands succeed. The test matrix can be seen here: https://github.com/MichaIng/DietPi/wiki/Debian-Trixie-testing
If your system has a software title installed which is not supported on Debian Trixie (yet), the script will warn you about that, giving you the option to abort.
More info about Debian 13 Trixie can be found on our blog: https://dietpi.com/blog/?p=4014
I gave this a shot and worked mostly fine, except for a conflict with sabnzbd and python3-jaraco* packages. Always a hassle working with python out of venvs. ;)
Also a note that it might be good to mention bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/refs/heads/dev/.meta/dietpi-trixie-upgrade') has to be run as root, and can't be run directly with sudo, except with something like sudo bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/refs/heads/dev/.meta/dietpi-trixie-upgrade').
I usually don't like curl pipe to bash as a general rule...much less sudo pipe to bash, but for trustworthy projects I guess it's alright. Just a comment. More details on conflict below.
Just a note that this was done on an Rpi Zero 2 W, and not one that I was actually using for anything "real" yet. I had installed some random packages to play around a bit and test the trixie update, but that's about it. Bookworm build was thrown on here ~1 week ago.
Crux of the issue is that debian python3-setuptools now pulls in python3-jaraco.text:
dietpi@DietPiZero1:~$ apt depends python3-setuptools
python3-setuptools
Depends: python3-pkg-resources (= 78.1.1-0.1)
|Depends: python3-importlib-metadata
Depends: <python3-supported-min> (>= 3.10)
python3
Depends: python3-jaraco.text
Depends: python3-more-itertools
Depends: python3-typeguard
Depends: python3-typing-extensions
Depends: python3-zipp
Depends: <python3:any>
python3
Breaks: python3-wheel (<< 0.46.0)
Suggests: python-setuptools-doc
( Same from bookworm, for reference:
dietpi@DietPi4:/etc/apt$ apt depends python3-setuptools
python3-setuptools
Depends: python3-pkg-resources (= 66.1.1-1+deb12u1)
Depends: python3-distutils
Depends: <python3:any>
python3
Suggests: python-setuptools-doc
)
which then pulls in python3-jaraco.functools
dietpi@DietPiZero1:~$ apt depends python3-jaraco.text
python3-jaraco.text
Depends: python3-autocommand
|Depends: python3-importlib-resources
Depends: <python3-supported-min> (>= 3.9)
python3
Depends: python3-jaraco.context
Depends: python3-jaraco.functools
Depends: python3-more-itertools
Depends: <python3:any>
python3
Depends: python3-inflect
which then conflicts with the pip install process:
...
Attempting uninstall: jaraco.functools
Found existing installation: jaraco.functools 4.1.0
error: uninstall-no-record-file
× Cannot uninstall jaraco.functools 4.1.0
╰─> The package's contents are unknown: no RECORD file was found for jaraco.functools.
hint: The package was installed by debian. You should check if it can uninstall the package.
[FAILED] DietPi-Software | pip3 install -Ur requirements.txt
...
Removing the offending python packages allowed the process to complete after retrying.
Don't think I'd have time in the near future, but this really shouuuuld be put into a venv. I don't let coworkers fuck around with system python outside of containers anymore for exactly this reason. :)
Just a note, I have more detailed logs/apt deptrees upon request. Not sure if they'd be useful or not. It's late and I need to go to bed, so excuse any bad formatting/wording.
Thanks for testing.
Right, <(command) as well as < <(command) and similar do not work with sudo, since the implied temporary file is lost before bash can use it. A command | sudo bash pipe breaks TUI dialogues. Only variant would be sudo bash -c "$(command)", not sure why we did not suggest that one in our Bookworm release blog post (I just took the command from there). I adjusted it and added sudo, should work fine like that.
Regarding SABnzbd:
- A venv seems resonable indeed, given the large number of specific dependencies and versions: https://github.com/sabnzbd/sabnzbd/blob/develop/requirements.txt#L13
Though I wonder why it tries to uninstall the dist module instead of just overriding it with the site module. But that again, in theory, could break another dist module or package which depends on the exact/not older
jaraco.functoolsthe Debian package ships. - But in fact, this is the very first report with a clear dist vs
pipmodule conflict I ever faced, while we pretty consequently avoid venv for all software installs and override theexternally-managedflag present since Debian Bookworm. - A question here is why
python3-setuptoolsis actually installed. We installpipviaget-pip.pyand recentsetuptools, and there was only a single case where the Debian package was needed temporary due to a bug in another Debian package. Since PyPI provides pre-compiled modules in nearly all cases, and the Python ecosystem develops fast, IMO the Debian packaged Python modules are mostly irrelevant. - But with the "externally managed" things more commonly used, even that I am a fan of efficient resource sharing, I guess we will need to move more and more Python software installs into venv. That this becomes more common across distros, as well as
pipxetc, is indirectly leading to stricter Python dependencies and more conflicts remaining unnoticed or ignored.
Tried to update a pihole + unbound installation, but after the reboot the services were not started automatically.
I'm looking so I can restore, and I'll post the updates here.
Update: unbound service was not automatically started, so I had to do systemctl enable --now unbound.
Ok, DNS (unbound + pihole) is still not coming up. Need to investigate a little more.
Update2: pihole-FTL also needed to be started manually. Now it's working.
Is this something expected for these services? Are other services that should be handled manually?
I'll have to respond better when I have more time, but yeah it's really a nightmare understanding what python is going to try to do, and distributions have been (rightfully so) moving more and more toward disabling the ability to even mess with python out of a venv. I've had weird issues like python sourcing random forgotten dependencies in ~/.local left behind from old install scripts at work, and e.g. inadvertently grabbing an ancient copy of libssl with it, but leaving no indication that it was actually pulling in that dependency without serious lsof digging (pyside2 has always been a nightmare in itself honestly)...
I've been incredibly happy with uv lately and it's brought my insane workflow of python/pip/pipx/pyenv/pyenvrequirements.txt), uv sync to bootstrap a venv with the dependencies, then just source it and you're good to go. Upgrading major python version? uv python list to find available versions, uv python pin cpython-<version> (it'll drop a .python-version similar to pyenv), and then uv sync and you're good to go again. Want to upgrade a single dependency? Change a number/comparator in the pyproject.toml. Also creates lockfiles of dependencies by hash upon syncing.
It's insanely fast compared to anything else I've ever used too...It does do a lot of caching, which might need to be handled specially for dietpi since there's the SD card constraint for many users, although I've used UV a bit on my rpis and haven't seen any issues.
I always sound like a zealot when I talk about it, but its really been a gamechanger.
I think there may have been some other issues with a couple services failing after install, but I'll have to come back to this when I have more time.
Hello,
I tried the script today and it stopped when encountering a package that was not in the repositories (syncplay-common I think). I then did apt -f install (which did not remove this), apt autoremove (probably a bad idea!), then apt remove syncplay*, then reran the script. It seems to have finished successfully, reboot went OK.
Is this something expected for these services? Are other services that should be handled manually?
Whether the services are enabled or not should not change with the Trixie update, especially not the Pi-hole service which is not even a Debian package, hence not changed at all 🤔.
To enable them:
systemctl enable unbound pihole-FTL
If the command produces output about created symlinks, they were indeed not enabled before. If it does not produce any output, their startup failed at boot. In the latter case, check why:
journalctl -u unbound -u pihole-FTL
I've had weird issues like python sourcing random forgotten dependencies in
~/.localleft behind from old install scripts at work
Interesting. I mean a module is/should be loaded only if the project (or one of its dependencies) imports it actively. But then, the ~/.local user site indeed overrides any system site or dist instance of the module, so makes sense. But I do not remember a case where installing a package to a higher priority site lead to an uninstall attempt on a lower priority site, that is indeed confusing and does not make any sense. The other way round it would make sense, if e.g. the root user installs a module via pip as system module to /usr/local/lib site, while there is a --user instance of the package on ~/.local already, overriding it. Actually no idea what pip does in this case, a warning would be reasonable 😄.
uv however, as Python module itself, cannot be bootstrapped, can it? What makes it better than pyenv? That you do not need pip within the pyenv?
It does do a lot of caching, which might need to be handled specially for dietpi since there's the SD card constraint for many users
Yeah we disable the pip cache already by default. Usually no point to have the very same modules which were installed already stored another time in the cache. For build-only dependencies there is a certain possible use case, but as end user, when installing another Python software some time later, almost all dependencies have newer versions, which are then downloaded anyway, only bloating the unused cache further. For developers, of course, this is a different thing.
I tried the script today and it stopped when encountering a package that was not in the repositories (syncplay-common I think).
Hmm, that one is actually in the Trixie repo: https://packages.debian.org/trixie/syncplay
A package with quite a larger number of Python dependencies, hence a candidate with possible pip conflicts, we were discussing. Since you did remove syncplay now, to investigate, what happens if you try to install it again?
apt install syncplay
It installed fine.
But actually I don't care about syncplay itself, just the server, so I installed it and it also went fine. I guess my server package had some weird dependencies.
Maybe I can replicate it on a test system when installing syncplay and then run the distro upgrade.
Quite possible that there was some kind of dependency quirk the solver could not solve, without removing the package once. Generally, if anyone faces a similar issue, please copy&paste the related output here. We might be able to work around the issue in the script, if we see the package installed, or even solve it at Debian, to prevent others from facing the same issue.
My syncplay-server package was downloaded from the project's github - it was not the distro package.
Ah I see they provide DEB packages: https://github.com/Syncplay/syncplay/releases
Indeed their syncplay-server package is all-in-one, while the (newer, by version string) one from Debian Trixie splits out parts into syncplay-common. If I try to install their server package on Trixie, there are hence file conflicts:
dpkg: error processing archive /tmp/syncplay-server_1.7.4.deb (--unpack):
trying to overwrite '/usr/share/icons/hicolor/256x256/apps/syncplay.png', which is also in package syncplay-common (1.7.4+repack1-1)
And indeed the other way round it happens as well:
Unpacking syncplay-common (1.7.4+repack1-1) ...
dpkg: error processing archive /tmp/apt-dpkg-install-gGwUUX/60-syncplay-common_1.7.4+repack1-1_all.deb (--unpack):
trying to overwrite '/usr/share/icons/hicolor/256x256/apps/syncplay.png', which is also in package syncplay-server (1.7.4)
Preparing to unpack .../61-syncplay-server_1.7.4+repack1-1_all.deb ...
Quite a funny one, since the "newer" Debian syncplay-server package, which does not have the conflict, would be installed right next. I mean it makes sense:
- The APT resolver just sees declared package dependencies and conflicts. It sees the older
syncplay-server (1.7.4)package which will be upgraded tosyncplay-server (1.7.4+repack1-1)and pulls insyncplay-common (1.7.4+repack1-1)as additional new dependency. - Since the new
syncplay-serverdepends onsyncplay-common, the latter is unpacked first. - But
syncplay-commoncannot be unpacked, as long as the oldsyncplay-server (1.7.4)is still installed, due to the overlapping files 😄.
In that case, APT would need to remove the old server package, before unpacking syncplay-common. But such is outside of APT resolver's scope. It would require a Breaks:+Replaces: declaration for the particular versions from syncplay's GitHub, for APT to deal with automatically.
@lukaszsobala
If you install the server package from GitHub again, apt upgrade will again try to upgrade it to 1.7.4+repack1-1, isn't it? So I guess the best solution is to apt-mark hold syncplay-server, or creating an /etc/apt/preferences.d config to pin down syncplay packages from the Debian repo in general.
To be honest, debian's packages seem more sensible... Maybe there is a way to force this installation? Check for the package, remove then reinstall at the end?
Thanks for looking into it, there may be 0 other persons with this issue 😂
The Debian package comes with a systemd unit at least, so no need to setup an own service/startup procedure. But at the same time, if you e.g. created another startup mechanism, not via systemd, then install the Debian package, you might end up with 2 running syncplay-server instances. So at least, if we think about integrating a workaround into our script, the conservative approach would be better, not touching the instance, but assuming the admin will install a new version from Syncplay GitHub, once released.
But if a migration to the Debian package is wanted, indeed:
apt remove syncplay-server
apt install syncplay-server
EDIT: Probably too much text, but to prevent the conflicting Syncplay package upgrade: https://github.com/MichaIng/DietPi/commit/6697329
I preferred a preference config instead of apt-mark hold, since it prevents the installation silently, instead of throwing a warning on each apt upgrade.
uvhowever, as Python module itself, cannot be bootstrapped, can it? What makes it better thanpyenv? That you do not needpipwithin thepyenv?
It's like every single thing I used to do with 5 tools, but in one, with nothing ever conflicting with each other. Oh, and it's like 20 times faster for all those operations. The below took maybe 30-60 seconds to build ab-initio on a raspberry pi zero 2 W.
There are some caveats with it preferring the standalone python builds, (which you can override and use host/other python), but overall I find myself using their standalone builds whenever possible. And a lot of projects (including sabnzbd, coincidentally) have been working with uv devs on this normally, when there are problems.
See:
https://github.com/astral-sh/python-build-standalone/issues/548
https://github.com/sabnzbd/sabctools/issues/132
(fixed with sabctools==8.2.6—although there might be some kinks to work out still, it built and seemed to run fine just sedding it in the requirements.txt from the latest release tarball).
So overall, the process would be like this:
# install uv. Lot of other ways you can install as well
curl -fsSL https://astral.sh/uv/install.sh | sh
# if you have a need for a specific python, you can check out available versions here
# and then `uv python install` it. if you don't choose one, it'll choose automatically when
# you `uv sync`, within the confines of your pyproject.toml. pretty intuitive.
dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ uv python list
# let's install the latest cpython arm build from 3.13 major release, just to better illustrate.
# you're a big pyenv junky like I used to be, so I'm trying to show the kinds of things that were
# gamechangers for me. :)
dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ uv python install cpython-3.13.5-linux-aarch64-gnu
# again, you don't have to pin manually—if you don't, it'll just use
# the latest within the confines of what's defined in your pyproject.toml
# if you do pin, you'll see a `.python-version` similar to pyenv in your working dir
dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ uv python pin cpython-3.13.5-linux-aarch64-gnu
dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ uv init --bare
Initialized project `sabnzbd-master`
# only because of the workaround necessary above. probably by the time you wanna change things, 8.2.6 will be in the release tarball lol
dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ sed -i 's|sabctools==8.2.5|sabctools==8.2.6|g' requirements.txt
dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ uv add -r requirements.txt
Resolved 58 packages in 16.06s
Built paho-mqtt==1.6.1
Built sgmllib3k==1.0.0
Prepared 46 packages in 7.30s
Installed 46 packages in 605ms
+ apprise==1.9.3
+ babelfish==0.6.1
+ blinker==1.9.0
# ...
# removed package list for clarity, but just lists all of them out as you install with nice ansi shell coloration
# ...
# bootstrap and init a .venv from the pyproject.toml/uv.lock generated by your `uv add`
# you can similarly just add/remove packages/versions to the pyproject.toml with uv add/uv remove
dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ uv sync
Resolved 58 packages in 8ms
Audited 46 packages in 0.20ms
# source the venv and run it with the same config set by current dietpi package. Web UI runs and looks fine, but I have all my arrs in proxmox, so I won't really be able to test it thoroughly
dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ source .venv/bin/activate
(sabnzbd-master) dietpi@DietPiZero1:~/sabnzbd-uv/sabnzbd-master$ python3 -OO /etc/sabnzbd/SABnzbd.py -f sabnzbd.ini -n --disable-file-log
...
Overall the entire init/build process is maybe a minute or so. Took longer to type this up than to set up, even including figuring out the necessity of using 2.4.6 sabctools. Notably, I did get this warning while running from sabnzbd:
2025-07-31 22:35:14,344::WARNING::[SABnzbd:429] Could not link to OpenSSL library, please report here: https://github.com/sabnzbd/sabnzbd/issues/2421
which seems pretty minor, but don't really have time to look into it at the moment. Notably I just grabbed the latest python and sent it, so I didn't really think too much about it, lol.
Note, you can also throw no-cache option in a uv.toml, e.g. ~/.config/uv/uv.toml but haven't messed with it personally yet since I'm normally building stuff on beefy supermicro workstations where I'll cache anything and everything to speed up my workflow :P:
$ uv cache --help
Manage uv's cache
Usage: uv-3.13 cache [OPTIONS] <COMMAND>
Commands:
clean Clear the cache, removing all entries or those linked to specific packages
prune Prune all unreachable objects from the cache
dir Show the cache directory
Cache options:
-n, --no-cache Avoid reading from or writing to the cache, instead using a temporary
directory for the duration of the operation [env: UV_NO_CACHE=]
...
Apologies in advance for the absolutely horrible formatting and stream-of-consciousness text. Super busy and just been trying to late-night followup with the remaining energy of the day. :) But I hope this gives a bit of an overview of why I've been really enjoying uv, and why I think it'd potentially make your life a lot easier. Been a long time since I've been excited about python packaging...
You'd be much quicker than me to implement, since I'm not very familiar with how you organize everything in dietpi-software/global functions and such, but hopefully that's at least a good starting place if you wanted to try building with uv. There's potential I could put in a PR for this but it'd probably be a while—super busy and a thousand work/personal projects pulling my attention in a hundred directions. I'd be more than happy to assist if you have any troubles with the uv portion—just don't know if I have the mental bandwidth left to dig into a new set of multi-thousand LOC bash scripts at the moment. 😂
Just to provide a version that's a little bit easier to test, these are the basic commands you could run to bootstrap and run sabnzbd with uv, assuming you're in the unwrapped tarball with the relevant sabnzbd.ini.
curl -fsSL https://astral.sh/uv/install.sh | sh
uv python install cpython-3.13.5-linux-aarch64-gnu
uv python pin cpython-3.13.5-linux-aarch64-gnu
uv init --bare
sed -i 's|sabctools==8.2.5|sabctools==8.2.6|g' requirements.txt
uv add -r requirements.txt
uv sync
source .venv/bin/activate
python3 -OO /etc/sabnzbd/SABnzbd.py -f sabnzbd.ini -n --disable-file-log
Adding on another thing I like about uv. It's simple to define dependency groups like local sources—e.g. prebuilt source wheels/sdists/raw source dirs you grabbed and modified—right in your pyproject.toml...which is amazing when you need to patch dependencies and don't want to deal with the nightmare of doing that with...literally every other python tool lol. Same workflow here. uv init --bare, uv sync source .venv/bin/activate and that's it. uv.lock keeps a history of package hashes throughout git history. Super nice.
[project]
name = "REDACTED"
version = "5.3.1"
description = "REDACTED"
readme = "README.md"
requires-python = ">=3.10"
dependencies = [
"altgraph==0.17.4",
"bidict==0.23.1",
"certifi==2024.2.2",
"charset-normalizer==3.3.2",
"fbs",
"h11==0.14.0",
"idna==3.6",
"numpy==1.26.4",
"packaging==23.2",
"pillow>=11.2.0",
"pyinstaller==6.4.0",
"pyinstaller-hooks-contrib==2024.2",
"pyside2>=5.15.2.1",
"python-dotenv==1.0.1",
"python-engineio==4.11.2",
"python-socketio==5.12.1",
"requests==2.32.3",
"simple-websocket==1.0.0",
"urllib3==2.2.1",
"websocket-client>=1.8.0",
"wsproto==1.2.0",
]
[tool.uv.sources]
fbs = { path = "./external/wheels/fbs-1.2.5-py3-none-any.whl" }
So uv pulls pre-compiled Python binaries from here: https://github.com/astral-sh/python-build-standalone/releases
Sounds like a great replacement for pyenv indeed, to speed up our Home Assistant installs/upgrades. Now I am additionally happy that we split HA data and the pyenv instance, including module site consequently. And HA uses uv as well for its internal dependency management, when installing integrations via web UI etc. So shouldn't be too hard to replace /home/homeassistant/.pyenv (which is purged on any HA reinstall anyway) with a uv Python instance, and adjust /mnt/dietpi_userdata/homeassistant/deps to point to the uv package site.
Same theoretically for microblog.pub, though that project seems sadly dead, would be wasted time at this point.
upgraded a DietPi v9.15.2 Bookworm RPi 4 Model B (aarch64) to Trixie without any issues. Thank you! I also run following commands - as suggested by https://www.debian.org/releases/trixie/release-notes/upgrading.en.html: apt list '~o' apt purge '~o' apt list '~c' apt purge '~c'
Be careful with apt purge '~o'. The wording "obsolete" is somewhat misleading. This purges packages which are not present in any list currently stored on the system, i.e. those files in /var/lib/apt/lists. If those were moved to RAM (dietpi-software > Advanced Options > APT) after reboot, or cleaned via
/boot/dietpi/func/dietpi-set_software apt clean
It would attempt to purge all packages. Also dietpi-software installs quite a bunch of manually downloaded DEB packages, which are not distributed via APT repository, like Remote.It, LMS, Grafana for ARMv6 etc.
Of course you will notice this, it requires an interactive confirmation, and an attempt to purge essential system packages is aborted automatically. But it is the reason we are not doing this step in our script, but handle known migrations individually, like upgrading to new PHP, Python, Java, and libraries which carry their their version in package name, e.g. libicu72 => libicu76.
Let me know if apt list '~o' listed any real obsolete package in your case, so we can migrate it in the script.
Did apt list '~c' list anything? Isn't this implied in apt autopurge? I'll test this, else a reasonable additional cleanup step.
@MichaIng Thx for the explanation. Unfortunately I did not note down the Packages listed in apt list '~o'. But I remember there where about 10 or so. apt list '~c' only listed systemd-timesyncd. This was expected as I replaced it by chrony.
I also ran find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error' which gave my following list:
/etc/crontab.dpkg-dist
/etc/vim/vimrc.dpkg-dist
/etc/hdparm.conf.dpkg-dist
/etc/bash.bashrc.dpkg-dist
/etc/ca-certificates.conf.dpkg-old
Are they safe to remove?
Are they safe to remove?
Yes, all but the Vim one are expected, and you most likely edited vimrc intentionally.
apt autopurge really does not purge left config files from removed packages. I'll add this cleanup step to our upgrade scripts: https://github.com/MichaIng/DietPi/commit/69d3770
looks like Trixie has been released now as I got noticed by apt that Bookworm moved to oldstable 😄
Can we consider your script as a stable -> final (?), or should I wait a couple more days/weeks before there will be an official way to upgrade?
For a production system I recommend to wait for next DietPi release.
I just finished running through all dietpi-software install tests the last days, and there were quite some fixes needed, and some software titles have been added to the list which are not supported on Trixie yet. In many cases it is just because of missing binary builds, which I expect to be added soon, when maintainers become aware of the Trixie release. Older packages are often incompatible, especially for 32-bit systems due to time64 transition, newly introduced syscalls (well, not so new, but newly consequently used in Debian at least) to fix the year 2038 problem. However, the script will warn you already and offer to abort, if any affected software title is installed on your system.
Otherwise, the script has worked well already in many cases, and gained some more migrations and pitfall fixes since it exists. We will continue to add more migration steps if found/reported. This is why we have this GitHub issue: if you face any problems, let us know, and we will try to prevent/enhance it, for as long as it exists.
oki, I did try and fail
│ tshark ucf udev udevil udisks2 unbound unrar-free upower webpack wget
│ wireless-tools wireshark-common wpasupplicant x11-utils x11-xkb-utils
│ x11-xserver-utils xarchiver xfce4-power-manager xfce4-power-manager-data
│ xfconf xfsprogs xrdp xserver-xorg-core xserver-xorg-input-libinput zenoty
│ The following packages will be upgraded:
│ docker-compose
│ 1 upgraded, 0 newly installed, 0 to remove and 360 not upgraded.
│ 764 not fully installed or removed.
│ Need to get 0 B/11.1 MB of archives.
│ After this operation, 61.1 MB of additional disk space will be used.
│ Setting up cron-daemon-common (3.0pl1-197) ...^M
│ ^M
│ Configuration file '/etc/crontab'^M
│ ==> Modified (by you or by a script) since installation.^M
│ ==> Package distributor has shipped an updated version.^M
│ ==> Keeping old config file as default.^M
│ (Reading database ... ^M(Reading database ... 5%^M(Reading database ... 10%^M(Reading database ... 15%^M(Reading datab
│ ... 20%^M(Reading database ... 25%^M(Reading database ... 30%^M(Reading database ... 35%^M(Reading database ... 40%^M(
│ database ... 45%^M(Reading database ... 50%^M(Reading database ... 55%^M(Reading database ... 60%^M(Reading database .
│ (Reading database ... 70%^M(Reading database ... 75%^M(Reading database ... 80%^M(Reading database ... 85%^M(Reading
│ database ... 90%^M(Reading database ... 95%^M(Reading database ... 100%^M(Reading database ... 157516 files and
│ directories currently installed.)^M
│ Preparing to unpack .../docker-compose_2.26.1-4_arm64.deb ...^M
│ Unpacking docker-compose (2.26.1-4) over (1.29.2-3) ...^M
│ dpkg: error processing archive /var/cache/apt/archives/docker-compose_2.26.1-4_arm64.deb (--unpack):^M
│ trying to overwrite '/usr/libexec/docker/cli-plugins/docker-compose', which is also in package
│ docker-compose-plugin (2.39.1-1~debian.13~trixie)^M
│ dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)^M
│ Errors were encountered while processing:^M
│ /var/cache/apt/archives/docker-compose_2.26.1-4_arm64.deb^M
│ E: Sub-process /usr/bin/dpkg returned an error code (1)
Bug report sent: - Reference code: ce545ef0-1b89-4461-b92e-b3818a73fb25
@StephanStS crazy coincidence 😄. The very same report within minutes. Fixed some minutes ago: https://github.com/MichaIng/DietPi/commit/a582716
Probably not bad that the Trixie update forces the removal of unnecessarily doubled Docker Compose installs.
Any advice on how to proceed? Should I restore the backup, or is there an easy fix?
Just repeat the script, it will now purge the conflicting docker-compose package before attempting any package upgrades.
I did, however new error shows up.
root@sedruga:/home/dietpi# bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-trixie-upgrade')"
[ INFO ] dietpi-trixie-upgrade | Purge obsolete docker-compose package from Debian repo, since docker-compose-plugin from Docker repo is installed already, and both conflict on Trixie
[ INFO ] dietpi-trixie-upgrade | APT purge docker-compose, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
alsa-utils : Depends: libasound2t64 (>= 1.2.14) but it is not going to be installed
bluez : Depends: libasound2t64 (>= 1.0.17) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.76.0) but it is not going to be installed
Depends: libreadline8t64 (>= 7.0~rc1) but it is not going to be installed
chromium : Depends: libasound2t64 (>= 1.0.17) but it is not going to be installed
Depends: libatk1.0-0t64 (>= 2.32.0) but it is not going to be installed
Depends: libcups2t64 (>= 1.7.0) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.40.0) but it is not going to be installed
Depends: libgtk-3-0t64 but it is not going to be installed or
xdg-desktop-portal-backend
girepository-tools : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
gnupg : Depends: gnupg-l10n (= 2.2.40-1.1) but 2.4.7-21 is to be installed
gvfs : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
gvfs-backends : Depends: gvfs (= 1.50.3-1) but 1.57.2-2 is to be installed
Depends: gvfs-common (= 1.50.3-1) but 1.57.2-2 is to be installed
Depends: gvfs-daemons (= 1.50.3-1) but 1.57.2-2 is to be installed
Depends: gvfs-libs (= 1.50.3-1) but 1.57.2-2 is to be installed
Depends: libimobiledevice6 (>= 1.3.0) but it is not installable
gvfs-daemons : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
gvfs-libs : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
iproute2 : Depends: libtirpc3t64 (>= 1.0.2) but it is not going to be installed
libatk-bridge2.0-0t64 : Depends: libatk1.0-0t64 (= 2.56.2-1) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
libatopology2t64 : Depends: libasound2t64 (>= 1.2.7.1) but it is not going to be installed
libatspi2.0-0t64 : Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
libbabeltrace1 : Depends: libglib2.0-0t64 (>= 2.76.0) but it is not going to be installed
libblockdev-crypto3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-fs3 : Depends: libext2fs2t64 (>= 1.42.11) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-loop3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-mdraid3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-nvme3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-part3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-swap3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-utils3 : Depends: libglib2.0-0t64 (>= 2.76.0) but it is not going to be installed
libblockdev3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libcloudproviders0 : Depends: libglib2.0-0t64 (>= 2.56.0) but it is not going to be installed
libcurl3t64-gnutls : Depends: libgnutls30t64 (>= 3.8.6) but it is not going to be installed
Depends: libnettle8t64 but it is not going to be installed
libfm-modules : Depends: libfm-extra4t64 (>= 1.2.0) but it is not going to be installed
Depends: libfm-gtk3-4t64 (>= 1.3.2-2~) but it is not going to be installed
Depends: libfm4t64 (>= 1.3.0) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
Depends: libgtk-3-0t64 (>= 3.0.0) but it is not going to be installed
libgck-2-2 : Depends: libglib2.0-0t64 (>= 2.74.0) but it is not going to be installed
libgcr-4-4 : Depends: libglib2.0-0t64 (>= 2.74.0) but it is not going to be installed
libgio-2.0-dev : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
libgio-2.0-dev-bin : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
libgirepository-2.0-0 : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
libglib2.0-bin : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
libgoa-1.0-0b : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
libgstreamer1.0-0 : Depends: libglib2.0-0t64 (>= 2.81.1) but it is not going to be installed
libmenu-cache-bin : Depends: libfm-extra4t64 (>= 1.2.0) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.76.0) but it is not going to be installed
libmsgraph-1-1 : Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
libngtcp2-crypto-gnutls8 : Depends: libgnutls30t64 (>= 3.8.2) but it is not going to be installed
libpython3.13 : Depends: libpython3.13-stdlib (= 3.13.5-2) but it is not going to be installed
libqt5gui5t64 : Depends: libglib2.0-0t64 (>= 2.12.0) but it is not going to be installed
Depends: libmtdev1t64 (>= 1.0.8) but it is not going to be installed
Depends: libqt5core5t64 (>= 5.15.1) but it is not going to be installed
Depends: libqt5dbus5t64 (>= 5.14.1) but it is not going to be installed
Depends: libqt5network5t64 (>= 5.0.2) but it is not going to be installed
Depends: qtbase-abi-5-15-15
libqt5widgets5t64 : Depends: libqt5core5t64 (>= 5.15.1) but it is not going to be installed
Depends: qtbase-abi-5-15-15
librtmp1 : Depends: libgnutls30t64 (>= 3.8.1) but it is not going to be installed
Depends: libhogweed6t64 but it is not going to be installed
Depends: libnettle8t64 but it is not going to be installed
libsoup-2.4-1 : Depends: libglib2.0-0t64 (>= 2.62.0) but it is not going to be installed
libsrt1.5-gnutls : Depends: libgnutls30t64 (>= 3.7.0) but it is not going to be installed
Depends: libnettle8t64 but it is not going to be installed
libtirpc-dev : Depends: libtirpc3t64 (= 1.3.6+ds-1) but it is not going to be installed
libudisks2-0 : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
libvolume-key1 : Depends: libglib2.0-0t64 (>= 2.18.0) but it is not going to be installed
libxaw7 : Depends: libxt6t64 but it is not going to be installed
libxmu6 : Depends: libxt6t64 but it is not going to be installed
lxpanel : Depends: lxpanel-data (= 0.10.1-2) but 0.11.1-1 is to be installed
nextcloud-desktop-cmd : Depends: libnextcloudsync0t64 (= 3.16.4-1) but it is not going to be installed
Depends: libqt6sql6-sqlite but it is not going to be installed
Depends: libqt6core6t64 (>= 6.8.2) but it is not going to be installed
Depends: libqt6network6 (>= 6.7.0~) but it is not going to be installed
nmap : Depends: libpcap0.8t64 (>= 1.5.1) but it is not going to be installed
openssh-sftp-server : Depends: openssh-client (= 1:9.2p1-2+deb12u7) but 1:10.0p1-7 is to be installed
parted : Depends: libreadline8t64 (>= 6.0) but it is not going to be installed
python3 : PreDepends: python3-minimal (= 3.11.2-1+b1) but 3.13.5-1 is to be installed
python3-gdbm : Depends: python3 (>= 3.13.2-1~) but 3.11.2-1+b1 is to be installed
sqlite3 : Depends: libreadline8t64 (>= 6.0) but it is not going to be installed
suricata : Depends: libevent-2.1-7t64 (>= 2.1.8-stable) but it is not going to be installed
Depends: libpcap0.8t64 (>= 1.0.0) but it is not going to be installed
udisks2 : Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
unbound : Depends: libevent-2.1-7t64 (>= 2.1.8-stable) but it is not going to be installed
unrar-free : Depends: libarchive13t64 (>= 3.2.1) but it is not going to be installed
wget : Depends: libgnutls30t64 (>= 3.8.1) but it is not going to be installed
Depends: libnettle8t64 but it is not going to be installed
wpasupplicant : Depends: libreadline8t64 (>= 6.0) but it is not going to be installed
x11-xserver-utils : Depends: libxt6t64 but it is not going to be installed
xserver-xorg-core : Depends: libnettle8t64 but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
[FAILED] dietpi-trixie-upgrade | APT purge docker-compose
- Command: apt-get -y --allow-change-held-packages autopurge docker-compose
[ INFO ] dietpi-trixie-upgrade | APT purge docker-compose, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
alsa-utils : Depends: libasound2t64 (>= 1.2.14) but it is not going to be installed
bluez : Depends: libasound2t64 (>= 1.0.17) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.76.0) but it is not going to be installed
Depends: libreadline8t64 (>= 7.0~rc1) but it is not going to be installed
chromium : Depends: libasound2t64 (>= 1.0.17) but it is not going to be installed
Depends: libatk1.0-0t64 (>= 2.32.0) but it is not going to be installed
Depends: libcups2t64 (>= 1.7.0) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.40.0) but it is not going to be installed
Depends: libgtk-3-0t64 but it is not going to be installed or
xdg-desktop-portal-backend
girepository-tools : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
gnupg : Depends: gnupg-l10n (= 2.2.40-1.1) but 2.4.7-21 is to be installed
gvfs : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
gvfs-backends : Depends: gvfs (= 1.50.3-1) but 1.57.2-2 is to be installed
Depends: gvfs-common (= 1.50.3-1) but 1.57.2-2 is to be installed
Depends: gvfs-daemons (= 1.50.3-1) but 1.57.2-2 is to be installed
Depends: gvfs-libs (= 1.50.3-1) but 1.57.2-2 is to be installed
Depends: libimobiledevice6 (>= 1.3.0) but it is not installable
gvfs-daemons : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
gvfs-libs : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
iproute2 : Depends: libtirpc3t64 (>= 1.0.2) but it is not going to be installed
libatk-bridge2.0-0t64 : Depends: libatk1.0-0t64 (= 2.56.2-1) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
libatopology2t64 : Depends: libasound2t64 (>= 1.2.7.1) but it is not going to be installed
libatspi2.0-0t64 : Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
libbabeltrace1 : Depends: libglib2.0-0t64 (>= 2.76.0) but it is not going to be installed
libblockdev-crypto3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-fs3 : Depends: libext2fs2t64 (>= 1.42.11) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-loop3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-mdraid3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-nvme3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-part3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-swap3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libblockdev-utils3 : Depends: libglib2.0-0t64 (>= 2.76.0) but it is not going to be installed
libblockdev3 : Depends: libglib2.0-0t64 (>= 2.42.2) but it is not going to be installed
libcloudproviders0 : Depends: libglib2.0-0t64 (>= 2.56.0) but it is not going to be installed
libcurl3t64-gnutls : Depends: libgnutls30t64 (>= 3.8.6) but it is not going to be installed
Depends: libnettle8t64 but it is not going to be installed
libfm-modules : Depends: libfm-extra4t64 (>= 1.2.0) but it is not going to be installed
Depends: libfm-gtk3-4t64 (>= 1.3.2-2~) but it is not going to be installed
Depends: libfm4t64 (>= 1.3.0) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
Depends: libgtk-3-0t64 (>= 3.0.0) but it is not going to be installed
libgck-2-2 : Depends: libglib2.0-0t64 (>= 2.74.0) but it is not going to be installed
libgcr-4-4 : Depends: libglib2.0-0t64 (>= 2.74.0) but it is not going to be installed
libgio-2.0-dev : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
libgio-2.0-dev-bin : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
libgirepository-2.0-0 : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
libglib2.0-bin : Depends: libglib2.0-0t64 (= 2.84.3-1) but it is not going to be installed
libgoa-1.0-0b : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
libgstreamer1.0-0 : Depends: libglib2.0-0t64 (>= 2.81.1) but it is not going to be installed
libmenu-cache-bin : Depends: libfm-extra4t64 (>= 1.2.0) but it is not going to be installed
Depends: libglib2.0-0t64 (>= 2.76.0) but it is not going to be installed
libmsgraph-1-1 : Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
libngtcp2-crypto-gnutls8 : Depends: libgnutls30t64 (>= 3.8.2) but it is not going to be installed
libpython3.13 : Depends: libpython3.13-stdlib (= 3.13.5-2) but it is not going to be installed
libqt5gui5t64 : Depends: libglib2.0-0t64 (>= 2.12.0) but it is not going to be installed
Depends: libmtdev1t64 (>= 1.0.8) but it is not going to be installed
Depends: libqt5core5t64 (>= 5.15.1) but it is not going to be installed
Depends: libqt5dbus5t64 (>= 5.14.1) but it is not going to be installed
Depends: libqt5network5t64 (>= 5.0.2) but it is not going to be installed
Depends: qtbase-abi-5-15-15
libqt5widgets5t64 : Depends: libqt5core5t64 (>= 5.15.1) but it is not going to be installed
Depends: qtbase-abi-5-15-15
librtmp1 : Depends: libgnutls30t64 (>= 3.8.1) but it is not going to be installed
Depends: libhogweed6t64 but it is not going to be installed
Depends: libnettle8t64 but it is not going to be installed
libsoup-2.4-1 : Depends: libglib2.0-0t64 (>= 2.62.0) but it is not going to be installed
libsrt1.5-gnutls : Depends: libgnutls30t64 (>= 3.7.0) but it is not going to be installed
Depends: libnettle8t64 but it is not going to be installed
libtirpc-dev : Depends: libtirpc3t64 (= 1.3.6+ds-1) but it is not going to be installed
libudisks2-0 : Depends: libglib2.0-0t64 (>= 2.83.0) but it is not going to be installed
libvolume-key1 : Depends: libglib2.0-0t64 (>= 2.18.0) but it is not going to be installed
libxaw7 : Depends: libxt6t64 but it is not going to be installed
libxmu6 : Depends: libxt6t64 but it is not going to be installed
lxpanel : Depends: lxpanel-data (= 0.10.1-2) but 0.11.1-1 is to be installed
nextcloud-desktop-cmd : Depends: libnextcloudsync0t64 (= 3.16.4-1) but it is not going to be installed
Depends: libqt6sql6-sqlite but it is not going to be installed
Depends: libqt6core6t64 (>= 6.8.2) but it is not going to be installed
Depends: libqt6network6 (>= 6.7.0~) but it is not going to be installed
nmap : Depends: libpcap0.8t64 (>= 1.5.1) but it is not going to be installed
openssh-sftp-server : Depends: openssh-client (= 1:9.2p1-2+deb12u7) but 1:10.0p1-7 is to be installed
parted : Depends: libreadline8t64 (>= 6.0) but it is not going to be installed
python3 : PreDepends: python3-minimal (= 3.11.2-1+b1) but 3.13.5-1 is to be installed
python3-gdbm : Depends: python3 (>= 3.13.2-1~) but 3.11.2-1+b1 is to be installed
sqlite3 : Depends: libreadline8t64 (>= 6.0) but it is not going to be installed
suricata : Depends: libevent-2.1-7t64 (>= 2.1.8-stable) but it is not going to be installed
Depends: libpcap0.8t64 (>= 1.0.0) but it is not going to be installed
udisks2 : Depends: libglib2.0-0t64 (>= 2.80.0) but it is not going to be installed
unbound : Depends: libevent-2.1-7t64 (>= 2.1.8-stable) but it is not going to be installed
unrar-free : Depends: libarchive13t64 (>= 3.2.1) but it is not going to be installed
wget : Depends: libgnutls30t64 (>= 3.8.1) but it is not going to be installed
Depends: libnettle8t64 but it is not going to be installed
wpasupplicant : Depends: libreadline8t64 (>= 6.0) but it is not going to be installed
x11-xserver-utils : Depends: libxt6t64 but it is not going to be installed
xserver-xorg-core : Depends: libnettle8t64 but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
[FAILED] dietpi-trixie-upgrade | APT purge docker-compose
- Command: apt-get -y --allow-change-held-packages autopurge docker-compose
[ INFO ] DietPi-BugReport | Generating informative command outputs, please wait...
[ INFO ] DietPi-BugReport | cp /tmp/G_EXEC_ERROR_REPORT G_EXEC_ERROR_REPORT, please wait...
[ OK ] DietPi-BugReport | cp /tmp/G_EXEC_ERROR_REPORT G_EXEC_ERROR_REPORT
[ OK ] DietPi-BugReport | Packing upload archive
[ OK ] DietPi-BugReport | Sending bug report
[ OK ] DietPi-BugReport | Your bug report has been successfully uploaded.
