Debian 13 Trixie will release with KDE Plasma 6. Any developers interested to join this effort?

Hello all enthusiasts of KDE Plasma 6 on Debian :slight_smile:

Good news. The Debian community recently announced that, in the future, Debian 13 Trixie will release with Plasma version 6. Joy.

Any KDE volunteer developers interested to join this effort? Link to their announcement, related links to documentation and code are down below into the screenshot.

Both me and the Ubertus team would be happy, as volunteer, to contribute testing and documentation, if needed. I am an end-user of KDE 5 and 6. Not a developer.

I tried to add links here, but it failed. On clicking “Create Topic” button, it says that I’m not yet allowed. I guess because this is not yet activated for my account. Below is a screenshot of my full message with links.



Latest status updates and opportunities to contribute to KDE Plasma 6 for Debian 13 Trixie

Note

  • (a) For newcomer contributors, this automated official installer is easier and faster to install, test, and contributed to. The present official installer is only for testing. Because it is unstable. So not for production. All installers include all KDE Plasma 6 pre-configured packages.
  • (b) For advanced contributors, you are welcome to download each package individually. Then configure them to your liking. Three version to choose from. Which are listed above from older to the newest version. The package Testing version is older and more stable. In comparison, the package Experimental version is the newest but more unstable. Those are only single package. For newcomers. It is suggested to use the official installer. Which includes all Plasma 6 pre-configured packages.

Note to myself

  • ID_J2C1K3R2

I’m glad that Debian users will finally have Plasma 6, over a year after it was released.

Personally I’m not very interested in Debian, because its fundamental release cycle doesn’t provide what I as a developer need most: up-to-date software libraries needed for building Plasma and other KDE software from git master. For KDE developers, this is probably the biggest sticking point. We’re looking for distros that facilitate this, which is probably why many of us end up with Arch, OpenSUSE Tumbleweed, Fedora KDE, or a derivative of one of these distros.

Old non-KDE apps are problematic too, but I can always get newer versions from Flathub no matter the distro.

Personally I’m not very interested in Debian, because its fundamental release cycle doesn’t provide what I as a developer need most: up-to-date software libraries needed for building Plasma and other KDE software from git master.

Hi @ngraham :slight_smile: I’m assuming that you’re referring to Debian Stable version. I agree that Stable is very old. Dusty-fossilized-old. In turn, not attractive to most developers. Whom enjoy recent versions.

My original post above is about the other and more recent versions of Debian. For those not familiar with those. They are called Testing, Unstable, and Experimental. I was not referring to the dusty old Debian Stable version. Maybe my original post was not clear about this.

For those not familiar with the Debian Testing version automated installer, it presently includes KDE Plasma version 6.2.5-1. Which was released December 31st, 2024. In other words, just 4 weeks before my original post. And roughly 6 weeks from now. Debian Experimental version includes a more recent version. Presently KDE 6.2.91.1-1. Which was released less than 2 weeks ago.

There are multiple ways to get more recent package versions on Debian. Including very fresh-out-of-the-oven-version :wink:

Below is the same reply as above. But with details for those interested.


Newer version for developers

Below are two suggested resolutions to consider for developer interested to contribute to more recent versions of both KDE Plasma 6 on Debian 13 Trixie.

Resolution 1: Testing or Experimental versions

Debian 13 Trixie Experimental automated installer presently includes KDE Plasma version 6.2.91.1-1. Which was released less than 2 weeks ago.

Debian 13 Trixie Testing automated installer presently includes KDE Plasma version 6.2.5-1. Which was released December 31st, 2024. In other words, just 6 weeks ago.

For those not familiar with Debian and Ubuntu release relationships. Ubuntu LTS releases are syncs/powered by Debian Testing. For Ubuntu non-LTS releases, Ubuntu syncs with Debian Unstable.

Resolution 2: Flatpak

To get cutting edge KDE 6 version for developer, how about creating a Flatpak installer on https://flathub.org ?

For interested contributors, those documentations might be of interest:

When configured appropriately, Flatpak has very strong security. For both developers and end-users interested in stronger security, this Flatpak configuration can easily be done, per app, or for all apps, with this amazing Flatseal app. Including on-off GUI switches.

Resolution 3: Any other?

Do you have any other resolution to suggest for developers to get newer version of KDE plasma on Debian 13 Trixie?


Newer version for end-users

In the future, after Debian 13 Trixie Testing turns into a Stable version. For end-users to get more recent version of KDE Plasma 6. Below are three suggested resolutions to consider.

Resolution 1: Backport

With Debian Stable, when adding this Backport repository, end-users could get ongoing updates for KDE Plasma 6.

For those not familiar with this Backport, this related doc might be of interest

Search presently available Backport packages. Those include recent Linux Kernel versions.

Plasma 6 is not yet added to Backport, obviously. Any volunteer interested to contribute this?

Resolution 2: Flatpak

Flatpak works really well on a Debian Stable. I used it for years now. How about creating a Flatpak for KDE Plasma 6 packages?

As you probably know, Flathub already has lots of successful System Flatpaks

Resolution 3: Any other?

Do you have any other resolution to suggest for end-users to get newer future versions of KDE plasma on Debian 13 Trixie?

I have one the .AppImage format works great no attempted vendor lockin files need to be installed like the flatpak or snap, just the image and it works. I have 6 installed according to the wonderful little thing I found called appman, its creator has an effort going to make many available and allowed to automatically updated using his script you install in home or any directory in the path. It works great. A simple one script in the directory that asks exactly one question at first startup where to store the files. Then you go on your merry way installing any of them in his database. It is structured so other can have their own database they manage to install files from. Only thing lacking is gpg signed files that are checked for added security.

~/bin/AppImage$ apmf

- YOU HAVE INSTALLED 6 PROGRAMS MANAGED BY "APPMAN"

-  APPNAME        |  VERSION      |  TYPE            |  SIZE  
-  -------        |  -------      |  ----            |  ----  
â—†  floorp         |  128.8.0      |  dynamic-binary  |  292   MiB
â—†  telegram       |  5.10.7       |  dynamic-binary  |  179   MiB
â—†  losslesscut    |  3.64.0       |  appimage        |  151   MiB
â—†  etcher-latest  |  1.19.25      |  appimage        |  138   MiB
â—†  skype          |  8.134.0.202  |  appimage        |  112   MiB
â—†  gpgfrontend    |  2.1.7        |  appimage        |  44    MiB

 TOTAL SIZE: 913 MiB of disk space in use

The backports situation it would be fantastic if someone would step and replace Norbert who used to do such a wonderful job before the Debian Developers chased him away. I used them many times they always worked flawlessly and were updated on every release to give you the latest software. Sadly no one has stepped forward to fill his shoes. This is why I gave up on stable and just go testing/unstable/experimental now. It gives the latest software all them rolling releases get in a system that I like to use.

wonderful little thing I found called appman

Thanks for sharing @JohnBrown :slight_smile: I’m assuming that you’re referring to this. I’m not familiar with it.

This AppMan AppImages manager reminds me of this GearLever. I used it for more than a year now. Easy to use. Frequently updated.

For those not familiar with GearLever, it is a Flatpak app which is able to “manage AppImages with ease! Gear lever will organize and manage AppImage files for you, generate desktop entries and app metadata, update apps in-place or keep multiple versions side-by-side.” Their website at https://mijorus.it/projects/gearlever/

I’m assuming that you’re suggesting to use AppImages to publish KDE Plasma 6 on Debian to end-users.

A challenge with AppImages is that, on Debian 12 and 13, for newcomers, AppImages are too hard to install, use, and update. Mid-level users or advanced users have no challenge with this. But most newcomers really struggle. In other words, the growth of AppImages is significantly slowed down because of its hard and steep initial learning curve. In turn, the AppImages community is much smaller than the Flatpak community.

In comparison, also on Debian 12 and 13, with the Flatpak publisher Flathub, it is very easy and quick to install Flatpak apps in just a few clicks using a graphical user interface (GUI). Next, still very easy to automatically update them. All of the above using either Debian 12 or 13 built-in GUI package manager or the website at https://flathub.org or the command line for advanced user without GUI.

@JohnBrown :slight_smile: Another significant challenge with AppImage is its weak security

I mean that with AppImages, on Debian 12 or 13, for newcomers there are no easy and quick ways for them to customize either each or all AppImages permissions.

I believe that most maintainers of AppImages have good behaviors. While at the same time, the risk with AppImages is that if a maintainer with evil behaviors sets not appropriate permissions. In turn, it is too hard for newcomers to adapt those permissions.

In comparison, with Flatpak, still on Debian 12 or 13, for newcomers, using this Flatseal, it is easy and quick to them to customize either each or all Flatpak permissions to their liking. Many configs simply by flipping an on-off switch. Optionnaly, they have access to fine-grained permissions. This means that after installing any Flathub app, before using the newly install app, using Flatseal, newcomers are able to easily and quickly adapt permissions to their liking.

There are no Flatseal equivalent on AppImages. You’re welcome to educate me if any.

I still believe that AppImages are great for mid-level or advanced Debian end-users. While at the same time, for newcomers, the security risk is significant.

I was looking into that they have the ability to use gpg signing and sandboxing on install. All they lack is the effort to get it all done in a nice central repository with all of that enabled. I found one person who is half the way there with a repository method for installing and automatically updating the packages with sandboxing if wanted. Only lack the gpg signing to make it complete. This is the way forward with no vendor lock in required with a package format that just works.

I am assuming that you’re referring to the one of many Backport maintainers who was manually publishing to Debian Backport repository

If you’re not familiar with publishing packages to Debian Backport repository. There are two main options to choose from. Either manual or automatic publishing. Where the automatic option does not depend on a maintainer’s manual actions to publish all updates.

Those documentation above needs to be adapted for Debian 13 Trixie of course

Backup documentation about Debian Backport repository:

Manual or automatic publishing are equally valuable. Depends on the maintainer and end-users’ needs. I prefer automatic.

Speaking of automatic, when hosted and configured appropriately, all Flatpak packages distributed via Flathub are immediately and automatically updated. No need to wait for an additional layer of maintainer. In other words, no bottleneck.

In the case of the KDE backports the only ones I ever really used I was talking about Norbert Preining. He did them on the SUSE OBS service not the Debian repositories. And I am more than familar with how all this works having used Debian since Woody came out in 2003 I think it was I switched to it to get out of .rpm hell.