The Kubuntu Team is happy to announce that Kubuntu 25.04 has been released.

Codenamed “Plucky Puffin”, Kubuntu 25.04 continues our tradition of giving you Friendly Computing by integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.

The release features the latest KDE Plasma 6.3 desktop, KDE Gear 24.12.3, kernel 6.14, and many other updated applications and libraries.

Applications for core day-to-day usage are included and updated, such as Firefox, and LibreOffice.

In addition to the applications on our install media, 25.04 benefits from the huge number of applications in the Ubuntu archive, plus those installable via snap or other methods.

Please refer to our release notes for further details.

Download Kubuntu 25.04 or learn how to upgrade from 24.10.

Note: For upgrades from 24.10, there may a delay of a few hours to days between the official release announcements and the Ubuntu Release Team enabling upgrades.

Welcome to the March 2025 development and community update.

Development Report

Text Tool Rework Progress

Wolthera is still buried in text work for 5.3.

• Add Language text property, which is important for font-shaping, line-break, word-break and text-transform. (Change)
• Better font unit conversion and other small fixes. (Change)
• Ensure alignment, dominant-baseline and baseline-shift follow CSS-inline-3 and SVG2. (Change)
• Rework text decorations so they are calculated as per css-text-decor-4. (Change)

Palettes

Several bugs in color palette editing have been fixed in the stable build, including failure to save group and number of rows, crash when adding a group to a palette in a document, and lag when adding a swatch. (bug 461521, bug 476589, bug 476607, bug 478715) (Change, by Mathias Wein)

In the unstable nightly builds, the Python Palette Docker has been re-added, which can manage palettes and export them to .gpl and .svg formats. (Change, by Freya Lupen)

Qt6 Port Progress

Krita 6.0.0-prealpha now supports PyQt6, and all built-in Python plugins have been updated to support it alongside PyQt5. (Change, by Freya Lupen)

User-made plugins will require updating by the author to work on Krita 6. Krita 6 will not be released any time soon, but for plugin authors who want to get a head start, see the change link for porting tips!

Wayland Testing

Krita doesn't yet support the Linux compositor Wayland, but it can now be enabled for testing purposes on the unstable nightly builds by setting the environment variable QT_QPA_PLATFORM=wayland. (Change, by Nicolas Fella)

Community Report

March 2025 Monthly Art Challenge Results

For the "Virtual Plein Air Painting" theme, 19 forum members submitted 26 original artworks. And the winner is… multiple entries by @Elixiah. Black Bear Pass:

Also check out the other entry, Druid Arch, Colorado.

The April Art Challenge is Open Now

For the April Art Challenge, @Elixiah handed the winner's honor of choosing the theme to second-place @Mythmaker, who handed it to third-place-tie @Katamaheen, who has chosen illustrating "Fairy Tales and Bedtime Stories" as the theme. The optional challenge is to design the artwork as a book cover. See the full brief for more details, and paint a familiar story with a new brush.

Featured Artwork

Best of Krita-Artists - February/March 2025

Nine images were submitted to the Best of Krita-Artists Nominations thread, which was open from February 14th to March 11th. When the poll closed on March 14th, these five wonderful works made their way onto the Krita-Artists featured artwork banner:

Krozz Defender by @Yaroslavus_Artem

Gagarin Scientific Research Station by @Dima

The Anger That Breaks from Within by @ryanwc

Xavier by @MangooSalade

2025 by @Montie

Ways to Help Krita

Krita is Free and Open Source Software developed by an international team of sponsored developers and volunteer contributors.

Visit Krita's funding page to see how user donations keep development going, and explore a one-time or monthly contribution. Or check out more ways to Get Involved, from testing, coding, translating, and documentation writing, to just sharing your artwork made with Krita.

Other Notable Changes

Other notable changes in Krita's development builds from Mar. 17 - Apr. 17, 2025, that were not covered by the Development Report.

Stable branch (5.2.10-prealpha):

• Brush Editor: Don't apply active mirror tool to the brushstroke preview. (bug report) (Change, by Scott Petrovic)
• ACB Palette: Use title for the palette name. (Change, by Halla Rempt)

Unstable branch (5.3.0-prealpha):

Bug fixes:

• Tools: Fix tool opacity being reset when switching brushes. (bug report) (Change, by D Kang)
• Tools: Fix sampling screen color when using multiple screens with different screen scaling. (Change, by killy |0veufOrever)
• Tools: Keep brush rotation during brush resize action. (Change, by Maciej Jesionowski)
• Layer Stack: When transforming a filter mask or its parent layer, show the content's bounds instead of the mask's entire canvas bounds. (Change, by Maciej Jesionowski)
• Animation Export: Fix failure to overwrite existing animation sequence. (bug report) (Change, by Emmet O'Neill)
• Animation: Make changing animation settings such as framerate and start/end frame undoable, and affect the document modified state. (bug report) (Change, by Emmet O'Neill)
• Usability: Make bundle activation/deactivation clearer, using a checkbox. (bug report) (Change, by Scott Petrovic)
• Canvas: Speed up canvas panning with rulers, by reducing the rate of ruler updates. (Change, by Maciej Jesionowski)

Features:

• Animation/Recorder: Update built-in FFmpeg to version 7.1. (Change, by Dmitry Kazakov)
• Batch Export Plugin: Add Bilinear filtering option. (Change, by Austin Anderson)

Nightly Builds

Pre-release versions of Krita are built every day for testing new changes.

Get the latest bugfixes in Stable "Krita Plus" (5.2.10-prealpha): Linux - Windows - macOS (unsigned) - Android arm64-v8a - Android arm32-v7a - Android x86_64

Or test out the latest Experimental features in "Krita Next" (5.3.0-prealpha). Feedback and bug reports are appreciated!: Linux - Windows - macOS (unsigned) - Android arm64-v8a - Android arm32-v7a - Android x86_64

Haruna version 1.4.0 is released.

Added support for recursive subtitle search, rotating video and opening youtube playlists from a video url containing a playlist id https://www.youtube.com/watch?v=video_id&list=playlist_id

Fixed issues with tracks menus showing incorrect tracks and changed the behavior of progress/seek slider while pressed to pause the video.

Windows version:

• haruna-1.4.0-windows-gcc-x86_64.exe
• haruna-1.4.0-windows-gcc-x86_64.7z

Availability of other package formats depends on your distro and the people who package Haruna.

If you like Haruna then support its development: GitHub Sponsors | Liberapay | PayPal

Feature requests and bugs should be posted on bugs.kde.org, ignoring the bug report template can result in your report being ignored.

Changelog

1.4.0

Features

• Added setting to search subtitles recursively. Searches folders relative to the parent folder of the playing file and folders defined by the `Load subtitles from` setting
• Added support for opening youtube playlists from urls containing a playlist id
• Added actions to rotate video clockwise (ctrl + r) and counter clockwise (ctrl + e)

Bugfixes

• Fix tracks menus showing tracks from previously opened files
• Fix subtitles added by drag and drop not being added to the subtitles menu
• While the progress/seek slider is pressed the video is paused, fixes continuously opening the next video when dragged and held all the why to the end

Fedora 42 has been released! 🎉 So let’s see what is included in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).

Note: You can also read this post on the Fedora Magazine.

New COSMIC Atomic variant

The new COSMIC desktop has been packaged for Fedora and a new Atomic variant created for it thanks to Ryan Brue. It is not yet available on the website but should be soon. See fedora-websites#351. Edit: It is now live: Fedora COSMIC Atomic.

See the Fedora change request.

Changes for all variants

composefs enabled by default

Following Fedora CoreOS in Fedora 41, Fedora Atomic Desktops are now using composefs by default. This is an important first step towards better integrity for the system content.

Note: As a side effect of this change, the systemd-remount-fs.service unit may fail to start on your system. Until we find a good way to fix this, you can find a workaround to apply in the atomic-desktops-sig#72 issue or in the common issue thread on the forum.

See the Fedora change request and the tracking issue atomic-desktops-sig#35.

Migration to a static GRUB config

As part of the move to composefs, we had to migrate systems to using a static GRUB config.

This also removes the duplicated entries in the boot menu for installations that pre-dates Fedora 41.

The transition will happen automatically during the first boot on Fedora 42. You can verify that it worked by looking at the status of the bootloader-update service:

$ sudo systemctl status bootloader-update.service

We are still missing documentation on how to change some GRUB settings now that the configuration is static. See the tracking issue atomic-desktops-sig#73.

Custom keyboard layout set on installation (for LUKS unlock)

This fix is important for setups where the root disk is encrypted with LUKS and the user is asked a passphrase on boot. The keyboard layout is now set as a kernel argument during the installation by Anaconda. If you want to later change the keyboard layout used for the LUKS password prompt, you will have to update the kernel argument.

Example to set the keyboard layout to the french keyboard:

$ sudo rpm-ostree kargs --append=vconsole.keymap=fr

Example to replace an existing layout by another:

$ sudo rpm-ostree kargs --replace=vconsole.keymap=de

See atomic-desktops-sig#6.

No longer building for PPC64LE

According to the countme statistics, we did not have users on PPC64LE, so we decided to stop building the Fedora Atomic Desktops for that architecture.

If you relied on those images, you can migrate to Fedora Bootc images (which are available for PPC64LE) or use a conventionnal Fedora package based installation.

See the Fedora change request.

What’s new in Silverblue

GNOME 48

Fedora Silverblue comes with the latest GNOME 48 release.

For more details about the changes that alongside GNOME 48, see What’s new in Fedora Workstation 42 on the Fedora Magazine, Looking ahead at 2025 and Fedora Workstation and jobs on offer! and Fedora Workstation 42 is upon us! from Christian F.K. Schaller.

What’s new in Kinoite

KDE Plasma 6.3

Fedora Kinoite ships with Plasma 6.3, Frameworks 6.11 and Gear 24.12.

See also What’s New in Fedora KDE Plasma Desktop 42? on the Fedora Magazine.

What’s new in Sway Atomic

Nothing specific this release.

What’s new in Budgie Atomic

The default software center for Budgie Atomic is now Plasma Discover. To rebase from Fedora 41 to 42, you will have to use the command line as rebasing via GNOME Software will move your system to Fedora Silverblue.

See: fedora-budgie/project/issue/5.

Changes in unofficial images

Until we complete the work needed in the Fedora infrastructure to build and push official container images for the Atomic Desktops (see releng#12142 and cloud-image-uploader#37), I am providing unofficial builds of those. They are built on GitLab.com CI runners, use the official Fedora packages and the same sources as the official images.

You can find the configuration and list on gitlab.com/fedora/ostree/ci-test and the container images at quay.io/organization/fedora-ostree-desktops.

Container images signed with cosign (sigstore)

The unofficial container images are now signed with cosign. You can configure your system to verify the signature of the images using the instructions from the project README.

Container images available for aarch64

We are now building all our variants for the aarch64 architecture as well.

Goodbye to Sericea and Onyx (now Sway Atomic & Budgie Atomic)

We have now removed all container images under that name. Use the new names:

• Sericea: sway-atomic
• Onyx: budgie-atomic

Unofficial, experimental Fedora Asahi Remix Atomic Desktops

We are now producing unofficial, experimental bootable container images targeting Apple Silicon, using the packages from the Fedora Asahi Remix project.

Those images are in a working state, but the installation procedure is not ready for general use. We thus only recommend that you give this a try if you are ready to help with the development or are ready to re-install you system and lose data.

See: fedora-asahi-remix-atomic-desktops project on GitHub

See also the Fedora Asahi Remix 42 is now available posts on the Fedora Magazine.

Note that those images currently do not support the x86 emulation detailed in New in Fedora: Running x86 programs on ARM systems.

Universal Blue, Bluefin, Bazzite and Aurora

Our friends in the Universal Blue project (Bazzite, Bluefin, Aurora) have prepared the update to Fedora 42. Look for upcoming announcements in their Discourse.

I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA proprietary drivers, extra media codec, out of tree kernel drivers, etc.).

What’s next

Roadmap to Bootable Containers

The next major evolution for the Atomic Desktops will be to transition to Bootable Containers. See also the Fedora bootc documentation.

We have established a roadmap (atomic-desktops-sig#26) and we need your help to make this a smooth transition for all of our existing users.

Turning the sysext experiment into a good experience

Systemd system extensions (sysexts) are a new option when you need some applications available on your system and can not run them in containers or as Flatpaks for various reasons. They offer an alternative approach to package layering as they do not increase update time and can be enabled or disabled as needed.

Support for sysexts is still in development for the Atomic Desktops but they already provide advantages over package layering for some use cases. See the currently experimental project: github.com/travier/fedora-sysexts.

Unifying the Atomic Desktops documentation

We would like to unify the documentation for the Fedora Atomic Desktops into a single one instead of having per desktop environments docs which are mostly duplicate of one another and need to be constantly synced.

See the tracking issue atomic-desktops-sig#10 if you want to help us do that.

Where to reach us

We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.

• Atomic Desktops SIG: Issue tracker (gitlab.com/fedora/ostree/sig), #atomic-desktops:fedoraproject.org
• Silverblue: Workstation Working Group, #silverblue:fedoraproject.org
• Kinoite: KDE SIG, #kinoite:fedoraproject.org
• Sway Atomic: Sway SIG, #sway:fedoraproject.org
• Budgie Atomic: Budgie SIG, #budgie:fedoraproject.org
• COSMIC Atomic: COSMIC SIG, #cosmic:fedoraproject.org

Historically passwords and credentials in all of our apps and services (such as kio and our Network Manager plasmoid), are stored and managed by our KWallet subsystem and API. In a similar way, GNOME had gnome-keyring, and other similar systems were available. A major problem was the mutually incompatible interface between them, making impossible to have a single place where all the passwords go.

For this reason, a standard DBus interface called Secret Service has been developed, and systems like KWallet, gnome-keyring and KeepassXC have adopted the interface as well.

In the future, we want to eventually port our applications to use the Secret Service API directly, preferably via the QtKeychain library (some applications already do), which will use Secret Service natively on Linux. And as a bonus the Windows/Android native systems on those platforms will work too.

This will make our applications work much better, be more integrated in other desktops or platforms, and be less dependent on the KWallet framework which has big legacy code parts at this point.

Right now, KWallet has the option to bring up a Secret Service compatible interface, and this is a valuable first step, but there are still some potential problems in the migration path:

• Applications using Secret Service will store their secret data in different places when running in different environment, including our own that have been migrated. If you login into a different session ,every app will have forgotten its credentials.
• It’s possible to use a different Secret Service provider also in a Plasma session, for instance enabling it in KeepassXC. At that point some apps will save into it, while other ones will keep using KWallet with a different storage backend.
• Applications ported from KWallet to SecretService will lose their credentials, unless some clunky porting code is written for each application.

A KWallet compatibility layer

Enter the recent refactor that happened in KWallet: it has now been split into 2 different system services now: one that exposes only the Secret Service API, and one that exposes only the KWallet API.

The service exposing the KWallet API has been written from scratch and is now just a thin wrapper around the Secret Service API, translating the KWallet DBus calls to Secret Service ones. The old KWallet service is now a pure Secret Service provider that just happens to use the old KWallet backend, exposing to Secret Service all the entries that had already been stored in the past.

This decouples our KWallet compatibility layer for existing or old applications (not only KDE applications, also third party ones like Chromium use it) with our actual secret storage and SecretService implementation, allowing a separate development roadmap, and even potential future transition to a different backend in a completely transparent way to the user.

You can see this decoupling in the same spirit as the recent KWin Wayland/X11 split: being able to develop the new technology without risking breaking compatibility of the legacy system.

What it means for users and developers

For the immediate future, not much really changes: users will still have all their secrets accessible, and every app they use that was using KWallet will keep working without forgetting anything.

In the same way, for developers, the whole KWallet C++ API keeps working exactly as it was (even though we’re discouraging its use in new projects). Also, the KWallet-to-Secret-Service API proxy layer will save data inside Secret Service with the same schema used by QtKeychain, keeping the data accessible if the application gets ported from using the KWallet C++ API to QtKeychain.

An experimental feature

Disclaimer: The following description is of an experimental feature behind a hidden configuration key: it will take a bit before it’s deemed ready for prime time.

One advantage of having 2 independent services to handle the KWallet API and the Secret Service one is that now it’s possible to chose different backends as well, such as KeepassXC, gnome-keyring or oo7.

Setting the following in kwalletrc:

[Migration]
MigrateTo3rdParty=true
[KSecretD]
Enabled=false

With this, the old KWallet backend (now a service called ksecretd) won’t be started anymore, and instead any Secret Service provider that is running or has been configured to be DBus-activatable will be used. The first time this happens, a data migration procedure will be executed, writing the data in KWallet into the new service, keeping all the user-saved secrets accessible.

Welcome to a new issue of "This Week in KDE Apps"! Every week we cover as much as possible of what's happening in the world of KDE apps.

As Carl is still in vacation, this issue is only partially complete.

System Apps

Dolphin Manage your files

The Dolphin search integration has been rewritten from scratch. Notably, users can now switch the search tool between a simple search algorithm and one using file indexing and offering advanced search options. This way users are no longer forced to use the file index whenever it is available and can instead search in a slower but more reliable manner.

The overall user interface design is much improved with better clarity about what is currently being searched and which parameters can be changed. It was designed in a collaborative effort by Kristen McWilliam, Jin Liu, Andy Betts, Tagwerk, Felix Ernst, and a few others. (Felix Ernst, 25.08.0. Link)

The "Show in Groups" action was moved from the "View" menu to the "Sort By" menu. (Nate Graham, 25.08.0. Link)

The "Change View Mode" button which was recently added to Dolphin's default tool bar configuration is now icon-only by default (just like we had intended). (Akseli Lahtinen, 25.08.0. Link)

In the Trash context menu the "Properties" action is now once again in the last position just like in all the other Dolphin view context menus. This now-fixed inconsistency was an unintended side-effect of us moving the "Delete" action last to make it less likely to click it by accident when aiming at "Restore". (Kai Uwe Broulik, 25.08.0. Link)

Dolphin will now hide the background of the navigation bar when it's outside of the toolbar. (Akseli Lahtinen, 25.08.0. Link)

Other

Various improvements were made for the KDE Open and Save dialog:

• People using single-click selection can now click on checkboxes to select individual items in multi-selection dialogs. This works similarly to how it does in Dolphin. (Akseli Lahtinen, KIO 6.14. Link)
• Open and Save dialogs now allow quickly filtering through files by filename when pressing CTRL+I or Backslash key, like in Dolphin. (Akseli Lahtinen, KIO 6.14. Link)

…And Everything Else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out Nate's blog about Plasma and be sure not to miss his This Week in Plasma series, where every Saturday he covers all the work being put into KDE's Plasma desktop environment.

For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.

Get Involved

The KDE organization has become important in the world, and your time and contributions have helped us get there. As we grow, we're going to need your support for KDE to become sustainable.

You can help KDE by becoming an active community member and getting involved. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer either. There are many things you can do: you can help hunt and confirm bugs, even maybe solve them; contribute designs for wallpapers, web pages, icons and app interfaces; translate messages and menu items into your own language; promote KDE in your local community; and a ton more things.

You can also help us by donating. Any monetary contribution, however small, will help us cover operational costs, salaries, travel expenses for contributors and in general just keep KDE bringing Free Software to the world.

To get your application mentioned here, please ping us in invent or in Matrix.

Finishing Up

Hey everyone, It’s me again, back with the final update for this year’s Season of KDE. So, turns out things don’t really go as planned and it took me some extra time to bring it over the line.

Since my last post, I wrote the tests for the Kalah game, the associated TUI, a greedy move selection and benchmarked Oware and Bohnenspiel. My mid-sem exams happened, in between, and delayed me by 2 weeks.

Dear fans of music & open source music players,
in preparation of the upcoming Amarok 3.3 release, a beta release (3.2.81) has been prepared.

As shown in the ChangeLog, the changes are mostly technical: Qt5 support is removed, and Amarok 3.3 beta is compatible with Qt6/KF6 only. Additionally, a database scheme update (first such since 2012) fixes encoding and date related bugs.

Please note that due to the database update, downgrading from 3.3 beta is not directly possible, and returning to pre-3.3 versions requires the database (at ~/.local/share/amarok/mysqle/) to be manually backed up beforehand.

Aligning with current major KDE Frameworks version should simplify various direct and indirect software dependencies. However, phonon-vlc is the only supported backend on Qt6 Phonon, which Amarok 3.3 beta is still using for audio playback. This imposes some constraints e.g. on equalizer and analyzer functionalities. A more comprehensive overview of audio backend status is available on an invent.kde.org issue and a related work-in-progress merge request.

Additionally, there isn't official releases with Qt6 support of liblastfm available yet (needed for last.fm support). To enable the functionality, one needs to use library version built from e.g. sources at https://github.com/Mazhoon/liblastfm/tree/81e8f9dc16a0a18fe9a066d51c2071086326670b .

The Amarok 3.3 beta source tarball is available on download.kde.org and it has been signed with Tuomas Nurmi's GPG key. In addition to the source code, it is likely that some distributions will provide beta packages. The various nightly git builds provided by various splendid packagers should also provide a way of using the beta changes and participating in the testing.

Happy listening!

Final update

So this is my final blog regarding the Season of KDE 2025, I’m feeling happy for what I accomplished. Over the past few weeks, I’ve implemented PvP system for mancala game, this project has been a deep dive into game development, networking and user experience.

Summary of work done so far

1. Move tracking Mechanics

At the heart of this project lies the MankalaEngine, an engine designed to handle rules and gameplay of various mancala variants. I’ve added some more feature in the engine:

• Move tracking: The lastMoveMethod() method allows to retrieve the last move played by the player and computer.

2. PvP Mode

It allows the real-time multiplayer gameplay using XMPP. Following is a brief summary:

• XMPP Integration: Players connect to each other using their jabber IDs and exchange move using the established chat room in real-time.
• Turn Management: The Player 1 always start, and turns alternate between the two players.
• Board Syncing: Players manually update their boards based on the opponent’s move, ensuring both the players have accurate view of the game state.

3. Man Page Documentation

To make the game accesible, I’ve created a man page for bohnenspieltui. This man page provides the information abou the game, including:

• Synopsis and Description: A brief overview and explanation of the game variant.
• Usage: Instructions for running the PvP mode.
• Added a minor improvement of card view in Mancala GUI.

Future Work

While the task for this term is completed, their are several areas for improvement:

• Automated board syncing by replacing the current manual one.
• Integrating the engine to the mancala GUI.
• Extending the PvP to other variants.

Final Words

Thanks to KDE community, XMPP community and Benson Muite and João Gouveia and Blue from Macaw.me for the guidance and support. And I encourage the aspiring contributors to take part in Season of KDE to learn and grow as a developer.

Work done so far

Implemented the PvP mode by leveraging XMPP for communication, enabling the played to exchange moves. The code for this are implementd in connection.h, connection.cpp and bohnenspieltui.cpp.

Setting up the PvP mode

The player select the game mode they desires to play, for PvP the choice would be option P.

Connecting to XMPP server

To establish the chat room and enable the communication the player must provide their jabber id and password and the opponent’s JID (This should be done from both players side).

The program then establishes a connection to the XMPP server using the entered credentials. The game proceeds only when the credentials are verified.

Host and Turn Order

The program determines who will play first in a simple manner i.e., by comparing the lexicographical order of their jabber IDs.

Sending a move

When it’s player turn, they are prompted to enter their move. The move is validated and sent to opponent via the established chat room.

The board is updated locally and then the turn is passed to the opponent.

Receiving a move

When the move is received from the opponent, the program prompts the player to sync the board manually.

This is to ensure that both the players have their board in sync. Then the program prompts the user to enter their move and it game will be continued.

What’s next

• Automatic move sync
• The man page to explain the working to players.