KDiagram 3.0.1 is an update to our charting libraries which fixes a bug in the cmake path configuration. It also updates translations and removes some unused Qt 5 code.
URL: https://download.kde.org/stable/kdiagram/3.0.1/
sha256: 4659b0c2cd9db18143f5abd9c806091c3aab6abc1a956bbf82815ab3d3189c6d
Signed by E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell jr@jriddell.org
https://jriddell.org/esk-riddell.gpg
I have now been playing games only on Linux for a year, and it has been great.
With the GPU shortage, I had been waiting for prices to come back to reasonable levels before buying a new GPU. So far, I had always bought NVIDIA GPUs as I was using Windows to run games and the NVIDIA drivers had a better “reputation” than the AMD/Radeon ones.
With Valve’s Proton seriously taking off thanks to the Steam Deck, I wanted to get rid of the last computer in the house that was running Microsoft Windows, that I had kept only for gaming.
But the NVIDIA drivers story on Linux had never been great, especially on distributions that move kernel versions quickly to follow upstream releases like Fedora. I had tried using the NVIDIA binary drivers on Fedora Kinoite but quickly ran into some of the issues that we have listed in the docs.
At the time, the Universal Blue project did not exist yet (Jorge Castro started it a bit later in the year), otherwise I would have probably used that instead. If you need NVIDIA support today on Fedora Atomic Desktops (Silverblue, Kinoite, etc.), I heavily recommend using the Universal Blue images.
Hopefully this will be better in the future for NVIDIA users with the work on NVK
So, at the beginning of last year (January 2023), I finally decided to buy an AMD Radeon RX 6700 XT GPU card.
What a delight. Nothing to setup, fully supported out of the box, works perfectly on Wayland. Valve’s Proton does wonders. I can now play on my Linux box all the games that I used to play on Windows and they run perfectly. Just from last year, I played Age of Wonders 4 and Baldur’s Gate 3 without any major issue, and did it pretty close to the launch dates. Older titles usually work fairly well too.
Sure, some games require some little tweaks, but it is nothing compared to the horrors of managing a Windows machine. And some games require tweaks on Windows as well (looking at you Cyberpunk 2077). The best experience is definitely with games bought on Steam which usually work out of the box. For those where it is not the case, protondb is usually a good source to find the tweaks needed to make the games work. I try to keep the list of tweaks I use for the games that I play updated on my profile there.
I am running all of this on Fedora Kinoite with the Steam Flatpak. If you want a more console-like or Steam Deck-like experience on your existing computers, I recommend checking out the great work from the Bazzite team.
Besides Steam, I use Bottles, Cartridge and Heroic Games Launcher as needed (all as Flatpaks). I have not looked at Origins or Uplay/Ubisoft Connect games yet.
According to protondb, the only games from my entire Steam library that are not supported are mostly multiplayer games that require some specific anti-cheat that is only compatible with Windows.
I would like to say a big THANK YOU to all the open source graphics and desktop developers out there and to (in alphabetical order) AMD, Collabora, Igalia, Red Hat, Valve, and other companies for employing people or funding the work that makes gaming on Linux a reality.
Happy new year and happy gaming on Linux!
Lots of my KDE contributions revolve around plugin code and their metadata, meaning I have a good overview of where and how metadata is used. In this post, I will highlight some recent changes and show you how to utilize them in your Plasma Applets and KRunner plugins!
Applets (or Widgets) are one of Plasma’s main selling points regarding customizability.
Next to user-visible information like the name, description and categories, there is a need for some technical metadata properties.
This includes X-Plasma-API-Minimum-Version for the compatible versions, the ID and the package structure, which should always be “Plasma/Applet”.
For integrating with the system tray, applets had to specify the X-Plasma-NotificationArea and X-Plasma-NotificationAreaCategory properties.
The first one says that it may be shown in the system tray and the second one says in which category it belongs. But since we don’t want any applets
without categories in there, the first value is redundant and may be omitted! Also, it was treated like a boolean value, but only "true" or "false" were expected.
I stumbled upon this when correcting the types in metadata files.
This was noticed due to preparations for improving the JSON linting we have in KDE. I will resume working on it and might also blog about it :).
What most applets in KDE specify is X-KDE-MainScript, which determines the entrypoint of the applet.
This is usually “ui/main.qml”, but in some cases the value differs. When working with applets, it is confusing to first have to look at the
metadata in order to find the correct file. This key was removed in Plasma6 and the file is always ui/main.qml.
Since this was the default value for the property, you may even omit it for Plasma5.
The same filename convention is also enforced for QML config modules (KCMs).
What all applets needed to specify was X-Plasma-API. This is typically set to "declarativeappletscript",
but we de facto never used its value, but enforced it being present. This was historically needed because in Plasma4, applets could
be written in other scripting languages. From Plasma6 onward, you may omit this key.
In the Plasma repositories, this allowed me to clean up over 200 lines of JSON data.
Just in case you were wondering: We have migrated from metadata.desktop files to only metadata.json files in Plasma6.
This makes providing metadata more consistent and efficient. In case your projects still use the old format, you can run desktoptojson -i pathto/metadata.desktop
and remove the file afterward.
See https://develop.kde.org/docs/plasma/widget/properties/#kpackagestructure for more detailed information. You can even do the conversion when targeting Plasma5 users!
Another nice addition is that “/runner” will now be the default object path. This means you can omit this one key. Check out the template to get started: https://invent.kde.org/frameworks/krunner/-/tree/master/templates/runner6python. DBus-Runners that worked without deprecations in Plasma5 will continue to do so in Plasma6! For C++ plugins, I will make a porting guide like blog post soonish, because I have started porting my own plugins to work with Plasma6.
Finally, I want to wish you all a happy and productive new year!
Tellico 3.5.3 is available, with a few minor clean-ups.
This is a lighter month due to holidays (and also I’m trying not to burn out), but I tried to fit in a bit of KDE anyway. It’s all bugfixes anyway because of the feature freeze!
Not mentioned is a bunch of really boring busywork like unbreaking the stable branches of Gear applications due to the CI format changing.
[Bugfix] Fixed a bunch of papercuts with the Android build, and the new nightlies should be appearing in the F-Droid repository soon! It’s mostly adding missing icons and making sure it looks good in qqc2-breeze-style (the style we use on Android and Plasma Mobile.) [24.02]
[Bugfix] Fixed Akkoma and Pleroma tags not being detected correctly, they should open in Tokodon instead of your web browser again! [24.02]
[Bugfix] KScreenLocker CI now runs supported tests, see the KillTest fixes and pamTest fix. Failing tests also make the pipeline visibly fail, as it should. (Unfortunately, the pipeline as of writing fails to due some unrelated regression?) [6.0]
[Bugfix] The lockscreen greeter now handles even the fallback theme failing, and display the “please unlock using loginctl” message instead of a black screen. [6.0]
[Bugfix] Improves the QtQuickControls style selection mechanism to work around a possible regression in Qt6. This should stop applications from mysteriously not opening in the rare (but unsupported) cases where our official styles aren’t installed/loading. [6.0]
[Bugfix] Fixed a bunch of TextArea bugs that affected mobile form factors, such as Plasma Mobile and Android. This is mostly for Tokodon (because we abuse TextAreas a lot in scrolling content) but it can help other applications too! The selectByMouse property is now respected, the cursor handles should show up less. [6.0]
[Bugfix] Invisible MenuItems in qqc2-breeze-style are collapsed like in qqc2-desktop-style. Mobile applications should no longer have elongated menus with lots of blank space! [6.0]
[Bugfix] You can finally right-click with a touchpad in qqc2-desktop-style TextFields again! This bug has been driving me up a wall when testing our Qt6 stuff. [6.0]
[Feature] When the Kirigami theme plugin fails to load, the error message will soon be a bit more descriptive. This should make it easier for non-developers to figure out why Kirigami applications don’t look correct. [6.0]
[Bugfix] Fixed KWeather not launching on Android because it needed QApplication. I didn’t know QtCharts is QWidgets-based! [24.02]
I also went around and fixed up a bunch of other mobile applications with Android contributions too small to mention. Applications like Qrca, Kongress, etc.
[Bugfix] Prevent the NeoChat notification daemon from sticking around forever although that should rarely happen. [24.02]
Nagged for a new QtKeychain release due to a critical bug that would cause applications to never open KWallet5. Please also nag your distributions to package 0.14.2 soon! Anything using QtKeychain 0.14.1 or below won’t work in Plasma 6. This doesn’t affect people in the dev session, because QtKeychain should be built from git.
Helping the Gentoo KDE Team with packaging Plasma 6 and KDE Gear 6. I managed to update my desktop to Plasma 6 and submitted fixes to get it closer to working. I also added Arianna, PlasmaTube and MpvQt packages.
The ownCloud product Infinite Scale is going to be released in version five soon. The latest stable version is 4.0.5 and I am sure everybody checked it out already and is blown away by it’s performance, elegance and ease of use.
No, not yet?
Ok, well, in that case, here comes rescue: With the little script described here, it becomes really easy to start Infinite Scale to check it out on your computer. It makes it really easy and quick for you, without Linux super admin powers whatsoever.
To use it, you just need to open a terminal on your machine and cd into a directory somewhere in your home where you can afford to host some bytes.
Without further preparation, you type the following command line (NOT as user root please):
@jriddell:kde.org
alex1701c
redstrate
curl -L https://owncloud.com/runocis.sh | /bin/bash
What it does is that it automatically pulls the latest stable version of Infinite Scale from the official download server of ownCloud onto your computer. For that, it creates a configuration and a start script, and starts the server. The script detects the platform on which your’re running to download the right binary version. It also looks up the hostname and configures the installation for that name.
Once the server was started Infinite Scale’s web client can be accessed by pointing a browser to the URL https://your-hostname:9200/. Since this is an installation for testing purposes, it does not have a proper certificate configured. That is why your browser is complaining about the cert, and you have to calm it. And indeed, that is one of the reasons why you’re not supposed to use this sneak peak in production or even exposed to the internet.
For the nerds, the script does not really do magic, but just curls the golang single binary of Infinite Scale down to the machine into a sandbox directory, chmod it to be executable and create a working config and a data dir. All happens with the priviledges of the logged in user, no sudo or root involved. You’re encouraged to double check the install script using for example the command curl -L https://owncloud.com/runocis.sh | less - of course you never should trust anybody running scripts from the internet on your machine.
If the server is stopped by pressing Ctrl-C, it later can be started again by the script runocis.sh that was kindly left behind in the sandbox as well.
The installer was tested on these three platforms: 64 bit AMD/Intel CPU based Linux machines, 64 bit Raspberry Pi with Raspbian OS and MacOSX. The flavour of Linux should not make a difference.
If you encounter a problem with the script or if you have suggestions to improve, please find it in my this’n that section on Github. I am happy to receive issue reports or pull requests.
For further information and setups suitable for production please refer to the Infinite Scale documentation.
As someone suffering from a latent burnout thingy which has become more imminent in recent years and as someone who is still struggling to develop strategies to alleviate its effects on health and general well-being, I wholeheartedly recommend everyone to watch this video and let those points sink. Yes, even if you are not (yet) affected. The video is not all about burnout but about strategies for sustaining long-term sanity.
https://www.youtube.com/watch?v=qyz6sOVON68
Enjoy. :)
chsh is a small tool that lets you change the default shell for your current
user. In order to let any user change their own shell, which is set in
/etc/passwd, it needs privileges and is generally setuid root.
I am of the opinion that
setuid/setgid binaries are a UNIX
legacy that should be deprecated. I will explain the security reasons behind
that statement in a future post.
In this “UNIX legacy” series of posts, I am looking at classic setuid
binaries and try to find better, safer alternatives for common use cases. In
this post, we will look at alternatives to changing your login shell.
People usually change their default shell because they want to use a modern alternative to Bash (Zsh, fish, Oils, nushell, etc.).
Changing the default shell (especially to a non POSIX or Bash compatible one) might have unintended consequences as some scripts relying on Bash compatibility might not work anymore. There are lots of warnings about this, for example for the fish shell:
On Fedora Atomic Desktops (Silverblue, Kinoite, etc.), your preferred shell may not always be available, notably if you have to reset your overlays for an upgrade, and could lead to an unusable system:
So overall, it is a bad idea to change the default login shell for interactive users.
For non-interactive users or system users, the shell is usually set by the system administrator only and the user itself never needs to change it.
If you are using
systemd-homed,
then you can change your own shell via the
homectl
command without needing setuid binaries but for the same reasons as above, it
is still not a good idea.
If you want to use another shell than the default one, you can use the functionality from your graphical terminal emulator to start it by default instead of Bash.
I recommend using the freshly released Prompt (sources) terminal if you are running on Fedora Silverblue or other GNOME related desktops. You can set your preferred shell in the Profiles section of the preferences. It also has great integration for toolbox/distrobox containers. We’re investigating making this the default in a future version of Fedora Silverblue (issue#520).
If you are running on Fedora Kinoite or other KDE related desktops, you should
look at Konsole’s
profiles features. You
can create your own profiles and set the Command to /bin/zsh to use another
shell. You can also assign shortcuts to profiles to open them directly a new
tab, or use /bin/toolbox enter fedora-toolbox-39 as Command to directly
enter a toolbox container for example.
This is obviously not an exhaustive list and other modern terminal emulators also let you specify which command to start.
If your terminal emulator does not allow you to do that, then you can use the alternative from the next section.
If you want to change the default shell for a user on a server, then you can
add the following code snippet at the beginning of the user’s ~/.bashrc
(example for fish):
# Only trigger if:
# - 'fish' is not the parent process of this shell
# - We did not call: bash -c '...'
# - The fish binary exists and is executable
if [[ $(ps --no-header --pid=$PPID --format=comm) != "fish" && -z ${BASH_EXECUTION_STRING} && -x "/bin/fish" ]]; then
shopt -q login_shell && LOGIN_OPTION='--login' || LOGIN_OPTION=''
exec fish $LOGIN_OPTION
fi