I run Home Assistant Core on a Raspberry Pi. I installed it in a Python venv and now and then I feel a need to upgrade. Today was such a day.
So, having backed everything up, I went for the plunge. Let’s install version 2025.1.2.
The usual dance goes a bit like this:
sudo systemctl stop homeassistant
sudo su homeassistant
cd /opt/homeassistant
source bin/activate
pip install --upgrade homeassistant
exit
sudo systemctl start homeassistant
Then all the dependencies are installed, so I usually go for a coffee, and once things have settled down (I use top to check that the system is idle), I usually restart homeassistance, just to make sure that it stops and starts nicely.
This time, I had no such luck. Lots of little issues. The major one seemed to be that import av in one of the core modules suffered from some sort of ValueError exception.
Having duckducked the issue for a while, I realized this meant that I had to do the upgrade from Python 3.12 to 3.13. Upgrading va to version 14.x using pip does not help. Since I always forget how to do this, I’m now writing this blog post.
Recollecting the steps, the moves are, more or less these:
Again, restarting Home Assistant takes a while and a bit more since all the dependencies are built. Go grab a snack or just a quiet coffee and, viola, you will end up with a fresh install of Home Assistant version 2025.1.2
Tellico 4.1 is available, with some improvements and bug fixes. This release and any subsequent bugfix dot releases (such as 4.1.1) will be the last ones that build with Qt5.
Improvements
Improved image loading to be on-demand only, improving load time for local and remote images (Bug 490922).
Redesigned the welcome screen.
Added option to disable the welcome screen.
Added property to disable line feed replacement in Paragraph fields.
Added tooltips in the Settings for configured image location.
Added a tooltip to show the internal field name for custom fields.
Tweaked the report templates to follow color settings.
Added option to disable building of documentation.
The first maintenance release of the 24.12 series is out packed with important fixes and enhancements. This update focuses on polishing the newly introduced built-in effects, resolving issues with bin effects and the effect stack, and addressing some recently introduced crashes. Other highlights include fixing an issue where hiding a track in a sequence could alter the length of the parent sequence, ensuring tags and markers are maintained when reloading proxy clips, fixing Whisper model downloads and installation of Python virtual environment (venv) issues on some Linux distributions.
If you’re old enough, you probably remember that there was a meme
from the 4.x days is that Plasma is all about clocks.
I’ve started working on some new artwork, and ended up sidetracked
spending more time designing fun clocks for Plasma than on what I
planned to work on, proving there’s some truth to the meme.
These are based on one of the coolest watch designs I’ve seen in
recent years – a Raketa Avant Garde:
In the latest Plasma 6.3 Beta, you will find a new executable named kcursorgen in /usr/bin. It can convert an SVG cursor theme to the XCursor format, in any sizes you like. Although this tool is intended for internal use in future Plasma versions, there are a few tricks you can play now with it and an SVG cursor theme.
(Unfortunately, the only theme with the support that I know, besides Breeze, is Catppuccin. I have this little script that might help you convert more cursor themes.)
Requirements
The qt6-svg library.
The xcursorgen command, usually found in xorg-xcursorgen package.
Trick 1: Cursors at any size you like
You should be able to set any cursor size with SVG cursors, right? Well, not at the moment, because:
Only those apps using the Wayland cursor shape protocol would be using SVG cursors. Other apps still use the XCursor format, with a limited list of sizes.
Plasma's cursor setting UI hasn't been updated to allow arbitrary sizes.
But we can do it manually with kcursorgen. Take Breeze for example:
Step 1: Make a copy of the theme
First, copy the cursor theme to your home directory. And let's change the directory name, so the original one is not overriden:
Then open ~/.local/share/icons/breeze_cursors.my/index.theme in the editor. Change the name in Name[_insert your locale_]= so you can tell it from the original in the cursor settings.
Step 2: Regenerate the XCursor files
For example, if we want a size 36 cursor, and the display scale is 250%:
Some Wayland apps don't support fractional scaling, so they will round the scale up. So we need to include both 2.5 and 3 in the scale list.
The above command generates XCursor at size 36, 90 and 108. Note that the max size of the original Breeze theme is 72, so this is something not possible with the original theme.
(kcursorgen also adds paddings when necessary, to satisfy alignment requirements of some apps / toolkits. E.g., GTK3 requires cursor image sizes to be multiple of 3 when the display scale is 3. So please use --sizes=36 --scales=1,2.5,3, not --sizes=36,90,108 --scales=1, because only the former would consider alignments.)
Then you can go to systemsettings - cursor themes, select your new theme, and choose size 36 in the dropdown.
(Yes, you can have HUGE cursors without shaking. Size 240.)
Trick 2: Workaround for the huge cursor problem in GTK4
As explained before, Breeze theme triggers a bug in GTK4 when global scaling is used, resulting in huge cursors. It's because Breeze's "nominal size" (24) is different from the image size (32).
We can work around this problem by changing the nominal size to 32.
Step 1 is same as above. Then we modify the metadata:
cd ~/.local/share/icons/breeze_cursors.my
find cursors_scalable/ -name 'metadata.json' -exec sed -i 's/"nominal_size": 24/"nominal_size": 32/g''{}'\;rm -r cursors/
kcursorgen --svg-theme-to-xcursor --svg-dir=cursors_scalable --xcursor-dir=cursors --sizes=32 --scales=1,1.5,2,2.5,3
Then you can go to systemsettings - cursor themes, select your new theme, and choose size 32 in the dropdown. Cursors in GTK4 apps should be fixed now.
Extra idea: (For distro maintainers) reduce cursor theme package size to 1/10
It might be possible to only package the index.theme file and cursors_scalable directory for the Breeze cursor theme (and other SVG cursors themes), then in an postinstall script, use kcursorgen to generate the cursors directory on the user's machine.
This would greatly reduce the package size. And also you can generate more sizes without worrying about blown package size.
But the fact that kcursorgen is in the breeze package might make some dependency problems. I have an standalone Python script that does the same. (But it requires Python and PySide6.)
The Amarok Development Squad is happy to announce the immediate availability of Amarok 3.2.1, the first bugfix release for Amarok 3.2 "Punkadiddle"!
3.2.1 features fixes for some small UI bugs, improvements for file transfers to MTP devices, and some compilation fixes for different combinations of Qt6 versions and compilers, enabling easier testing of Qt6 builds.
Additionally, it is now theoretically possible to enable last.fm and gpodder.net support in a Qt6 build. However, this requires Qt6 support in liblastfm and libmygpo-qt; a functionality that
is not yet included in the most recent released versions of the libraries.
Changes since 3.2.0
CHANGES:
Support gpodder and lastfm on Qt6 builds
Limit maximum current track font size more when context view is narrow
BUGFIXES:
Fix displaying settings button for Internet services
Enable Wikipedia context applet on Qt6 builds
Don't crash when copying multiple files to MTP device (BR 467616)
Avoid unnecessarily flooding MTP devices with storage capacity queries
Compilation fixes for various compiler + Qt6 version combinations
Getting Amarok
In addition to source code, Amarok is available for installation from many distributions' package
repositories, which are likely to get updated to 3.2.1 soon, as well as
the flatpak available on flathub.
A while ago a colleague of mine asked about our crash infrastructure in Plasma
and whether I could give some overview on it. This seems very useful to
others as well, I thought. Here I am, telling you all about it!
Our crash infrastructure is comprised of a number of different components.
KCrash: a KDE Framework performing crash interception and prepartion for handover to…
coredumpd: a systemd component performing process core collection and handover to…
Sentry: a web service and UI for tracing and presenting crashes for developers
We already looked at KCrash, coredumpd, and DrKonqi. This week it’s time to look at the final piece of the puzzle — Sentry.
Sentry
Sentry is the service we have on the developer side of a crash to manage incoming reports.
As we’ve learned in the DrKonqi post, a Sentry-specific trace created by the preamble is eventually sent off to our Sentry server. In Sentry, yet more processing happens!
Symbolication
If the user hasn’t explicitly opted into it, there usually aren’t debug symbols available on the user system. This would ordinarily render backtraces useless since they are just a bunch of memory addresses without names or references to our source code.
One of the reasons we adopted Sentry is because it can
fill in the gaps through a process called symbolication. For symbolication it essentially needs to know all the loaded libraries and can then fetch the relevant debug symbols via the various debuginfod instances out there. Once it has the debug symbols it can resolve that the address 0x2343244 is really the function int main(int argc, char **argv)
Fingerprinting
When a trace has been symbolicated it’s ready for fingerprinting. This tries to merge together the same
crash appearing in different submission into one single sentry event. Generally speaking if two submissions have the same trace frames, they are considered the same crash and merged into one event (in practice the rules are a bit more complicated).
Result
Eventually the crash event appears for us to fix.
In a future blog post, I’ll also give a more detailed guide on how to use Sentry to its full potential.