Thank you for the heads up!

Assignee: bugsquad => kde
Priority: Normal => release_blocker
CC: (none) => fri
Severity: normal => major
Target Milestone: --- => Mageia 10

Should this be fixed in Mageia, or added in release notes upgrade instructions?

Flags: (none) => in_release_notes10?

(In reply to Morgan Leijström from comment #2)
> Should this be fixed in Mageia, or added in release notes upgrade
> instructions?

Is added I think, I remember put that wayland is the default session, and x11 require now manual work.
Perhaps additional info for the upgrades is required, please check

Apparently this is a packaging error. The fact is that after the upgrade, without the kwin-x11 package installed you login to your desktop and you get windows borderless (which can't be moved), because the binary kwin_x11 is just missed. It's not related to the newer default session in wayland.

This issue is due to the fact that now KDE defaults to Wayland and everything is named as the X11 is the addition. 

I believe that the easiest way to mitigate this is by not allowing the Plasma X11 session to be launched by the display manager after an upgrade to Mageia-10. 

One option is to move the /usr/share/xsessions/plasmax11.desktop file from the plasma-workspace package to the kwin-X11 package, which will prevent an end user from starting an X11 Plasma session. Thus, the users that want or wish to use Plasma-X11 will need to properly add it, i.e., install "task-plasma-x11" or "kwin-x11" at a minimum.

But David should weigh in on it.

CC: (none) => arusanu

(In reply to Aurelian R from comment #5)

> This issue is due to the fact that now KDE defaults to Wayland and
> everything is named as the X11 is the addition. 
> 
> I believe that the easiest way to mitigate this is by not allowing the
> Plasma X11 session to be launched by the display manager after an upgrade to
> Mageia-10. 
> 
> One option is to move the /usr/share/xsessions/plasmax11.desktop file from
> the plasma-workspace package to the kwin-X11 package, which will prevent an
> end user from starting an X11 Plasma session. Thus, the users that want or
> wish to use Plasma-X11 will need to properly add it, i.e., install
> "task-plasma-x11" or "kwin-x11" at a minimum.
> 

That won't be the correct fix. The xsession entry works perfectly fine, the problem arises during the upgrade from mga9 to mga10, not on a fresh installation. In mga9, both Plasma Wayland and X11 sessions already existed distinctly, so users might want to continue using the X11 version after the upgrade (alongside Wayland, which they may have already installed and been using). Consider also that they might have autologin configured or be starting from a $HOME/.desktop file, there's no need to "hide" the session entry.

The simplest fix is to add a "Requires: kwin-x11" dependency to the plasma package existing in both mga9 and mga10. The attached patch demonstrates this.

Created attachment 15488 [details]
kwin-x11 dependency

(In reply to Giuseppe Ghibò from comment #7)
> Created attachment 15488 [details]
> kwin-x11 dependency

That will make a Plasma Wayland install to have X11 support regardless if it is an upgrade or a fresh install.

(In reply to Aurelian R from comment #8)
> (In reply to Giuseppe Ghibò from comment #7)
> > Created attachment 15488 [details]
> > kwin-x11 dependency
> 
> That will make a Plasma Wayland install to have X11 support regardless if it
> is an upgrade or a fresh install.

And so? In mga9 was so.

Another solution would be to introduce a fix in mga9 that includes both kwin and kwin-x11.

kwin in mga9 would have "kwin-x11" as a dependency (Requires: kwin-x11). kwin in mga10 won't have the kwin-x11, deps.

This would ensure that both packages are installed during the mga9 upgrade. When upgrading from mga9 to mga10, kwin-x11 would be carried over seamlessly.

(In reply to Giuseppe Ghibò from comment #9)
> And so? In mga9 was so.
I have no issues with enabling both X11 and Wayland support for Plasma by default as there is no interference when using one or the other, I was just making an observation as Plasma is switching from being X11 centered in mga9 to Wayland centered in mga10.

(In reply to Giuseppe Ghibò from comment #10)
> Another solution would be to introduce a fix in mga9 that includes both kwin
> and kwin-x11
 This is the cleanest solution as users are advised to update their systems before upgrading to the newer distro.

kwin-5.27.10-1.4.mga9 build in progress with new kwin-x11 sub-pkg splitted out.

CC: (none) => geiger.david68210

(In reply to David GEIGER from comment #12)

> kwin-5.27.10-1.4.mga9 build in progress with new kwin-x11 sub-pkg splitted
> out.

I think this will work.

Assigning to QA to validate the update for mga9,


Packages in 9/Core/Updates_testing:
======================
kwin-5.27.10-1.4.mga9
kwin-common-5.27.10-1.4.mga9
kwin-handbook-5.27.10-1.4.mga9.noarch.rpm
kwin-wayland-5.27.10-1.4.mga9
kwin-x11-5.27.10-1.4.mga9
libkcmkwincommon5-5.27.10-1.4.mga9
libkwin-devel-5.27.10-1.4.mga9
libkwin5-5.27.10-1.4.mga9
libkwineffects14-5.27.10-1.4.mga9
libkwinglutils14-5.27.10-1.4.mga9
lib64kcmkwincommon5-5.27.10-1.4.mga9
lib64kwin-devel-5.27.10-1.4.mga9
lib64kwin5-5.27.10-1.4.mga9
lib64kwineffects14-5.27.10-1.4.mga9
lib64kwinglutils14-5.27.10-1.4.mga9

From SRPMS
kwin-5.27.10-1.4.mga9.src.rpm

Assignee: kde => qa-bugs

Created attachment 15492 [details]
Excerpt of journal: kwin-x11 and wayland

Tested on a Lenovo ThinkCentre with Intel grafics.

Autologin into a KDE Plasma desktop (x11) works fine.
No regression found.

Login into Plasma Wayland. Looks find. Never tested before.

Ulrich

(In reply to Ulrich Beckmann from comment #15)

> Created attachment 15492 [details]
> Excerpt of journal: kwin-x11 and wayland
> 
> Tested on a Lenovo ThinkCentre with Intel grafics.
> 
> Autologin into a KDE Plasma desktop (x11) works fine.
> No regression found.
> 
> Login into Plasma Wayland. Looks find. Never tested before.
> 
> Ulrich

The full test requires to update mga9 to mga10.

Created attachment 15493 [details]
Cli log from journal and test to upgrade kwin

Tested an upgrade to mga10 (Cauldron) using dnf as described here

https://bugs.mageia.org/show_bug.cgi?id=35168#c3

The transaction succeded, but the result did not boot into a working desktop.
Kwin and Kwin-x11 and others are still stuck to mga9.

Ulrich

Has the upgrade failed for reasons other than package conflicts? Specifically, did it fail due to errors in other packages? Or was it completed smoothly?

Did kwin-x11 remain installed in Mageia 10?

I'd use urpmi for the upgrade, as stated in https://wiki.mageia.org/en/Mageia_10_Release_Notes, like this:

urpmi --auto-update --auto --force

Sorry, I did not pretend to post the whole dump.

Yes, kwin-x11 remains, but stuck to mga9.

Urpmi is not configured here. I use dnf only.
Dnf may be pickier than urpmi, but of course, there is a real problem.

Ulrich

I'm unable to find any repository mirror with these update packages.
I have tried a whole bunch of repositories that are indicated in https://mirrors.mageia.org/status as up-to-date, but I always get the following messages from qarepo:

"""
ERROR: libkcmkwincommon5-5.27.10-1.4.mga9 not found in the remote repository.
ERROR: libkwin-devel-5.27.10-1.4.mga9 not found in the remote repository.
ERROR: libkwin5-5.27.10-1.4.mga9 not found in the remote repository.
ERROR: libkwineffects14-5.27.10-1.4.mga9 not found in the remote repository.
ERROR: libkwinglutils14-5.27.10-1.4.mga9 not found in the remote repository.
"""

@ Guiseppe Ghibó

The upgrade completed smoothly. If there are package conflicts dnf selects a workable subset of the whole transaction.

@ PC LX

These are i686 packages and must be omitted in a x86_64 system.

Ulrich

(In reply to Ulrich Beckmann from comment #19)
> Sorry, I did not pretend to post the whole dump.
> 
> Yes, kwin-x11 remains, but stuck to mga9.
> 
> Urpmi is not configured here. I use dnf only.
> Dnf may be pickier than urpmi, but of course, there is a real problem.
> 
> Ulrich

So it appears the update was only partial.

The issue may be outdated DNF metadata on the mirrors, as genrepo sometimes crashes (it’s not as stable as in Fedora). It's hard to say exactly what happened.

First, use a mirror full in sync from https://mirrors.mageia.org/status

For example, Princeton is currently supposed to be fully synced.

Then try:

dnf clean all
dnf makecache
dnf check-update

Then see if it tries to list kwin-x11 for Mageia 10.

Finally, re-issue a full update with:

dnf update --refresh

Or install it manually:

dnf update kwin-x11

and see if it install the mga10 version.

(In reply to Ulrich Beckmann from comment #21)
> @ Guiseppe Ghibó
> 
> The upgrade completed smoothly. If there are package conflicts dnf selects a
> workable subset of the whole transaction.
> 
> @ PC LX
> 
> These are i686 packages and must be omitted in a x86_64 system.
> 
> Ulrich

Here is the complete list of packages generated on mga BS for the testing packages:

x86_64:
https://pkgsubmit.mageia.org/uploads/done/9/core/updates_testing/20260319223825.daviddavid.duvel.3725484/kwin-5.27.10-1.4.mga9/packages.x86_64.0.20260319223945.log

i686:
https://pkgsubmit.mageia.org/uploads/done/9/core/updates_testing/20260319223825.daviddavid.duvel.3725484/kwin-5.27.10-1.4.mga9/packages.i586.0.20260319225138.log

Are these packages available on the choosen mirrors:

https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/updates_testing/

? It's also possible the packages are available the RPM, but the DNF metadata might be broken. Are these packages listed in dnfdragora?

(In reply to Giuseppe Ghibò from comment #23)
One big issue I detect with dnf metadata is you don't know from what mirror come
And is the first thing downloaded before perform an install/update (and I guess upgrade) operation so if you get a rotten metadata, dnf will try to search packages that could not exist anymore when you package/work for cauldron.

So I set fixed mirror for dnf (and/or mock) for cauldron
I just upset of have to remember time after time that we need to purge mirrors from urpmi/dnf mirrorlist

(In reply to katnatek from comment #24)

> (In reply to Giuseppe Ghibò from comment #23)
> One big issue I detect with dnf metadata is you don't know from what mirror
> come
> And is the first thing downloaded before perform an install/update (and I
> guess upgrade) operation so if you get a rotten metadata, dnf will try to
> search packages that could not exist anymore when you package/work for
> cauldron.
> 
> So I set fixed mirror for dnf (and/or mock) for cauldron
> I just upset of have to remember time after time that we need to purge
> mirrors from urpmi/dnf mirrorlist

Yes, the default entry in /etc/yum.repos.d/mageia-x86_64.repo uses fastestmirror=1, and tries to get the fastest mirrors. However, sometimes for certain geographic zone this seems to work well, but for others it usually ends up choosing a mirror that isn't the fastest. A simple "dnf makecache" can sometimes take half an hour, while on other DNF native based distributions this is completed in at most a few  minutes. To get the DNF metadata up-to-date, and coherent we need to improve the ports of createrepo_c and detect when it crashes on generating the metadata. But that's another issue.

(In reply to Giuseppe Ghibò from comment #25)
> Yes, the default entry in /etc/yum.repos.d/mageia-x86_64.repo uses
> fastestmirror=1, and tries to get the fastest mirrors. However, sometimes
> for certain geographic zone this seems to work well, but for others it
> usually ends up choosing a mirror that isn't the fastest. A simple "dnf
> makecache" can sometimes take half an hour, while on other DNF native based
> distributions this is completed in at most a few  minutes. To get the DNF
> metadata up-to-date, and coherent we need to improve the ports of
> createrepo_c and detect when it crashes on generating the metadata. But
> that's another issue.

Is not only that could not be the fastest, is that could be a rotten out of sync one, and dnf will try to satisfy packages versions that not match no matter if try to get from all possible mirrors.

RH x86_64 
LC_ALL=C urpmi --auto --auto-update 
medium "QA Testing (64-bit)" is up-to-date
medium "Core Release" is up-to-date
medium "Core Updates" is up-to-date
medium "Nonfree Release" is up-to-date
medium "Nonfree Updates" is up-to-date
medium "Tainted Release" is up-to-date
medium "Tainted Updates" is up-to-date
medium "Core 32bit Release" is up-to-date
medium "Core 32bit Updates" is up-to-date
medium "Nonfree 32bit Release" is up-to-date
medium "Nonfree 32bit Updates" is up-to-date
medium "Tainted 32bit Release" is up-to-date
medium "Tainted 32bit Updates" is up-to-date


installing kwin-common-5.27.10-1.4.mga9.x86_64.rpm lib64kwin5-5.27.10-1.4.mga9.x86_64.rpm lib64kwinglutils14-5.27.10-1.4.mga9.x86_64.rpm lib64kwineffects14-5.27.10-1.4.mga9.x86_64.rpm kwin-5.27.10-1.4.mga9.x86_64.rpm kwin-x11-5.27.10-1.4.mga9.x86_64.rpm lib64kcmkwincommon5-5.27.10-1.4.mga9.x86_64.rpm from //root/qa-testing/x86_64
Preparing...                     ###########################################################################
      1/7: lib64kwinglutils14    ###########################################################################
      2/7: lib64kwineffects14    ###########################################################################
      3/7: lib64kwin5            ###########################################################################
      4/7: lib64kcmkwincommon5   ###########################################################################
      5/7: kwin-common           ###########################################################################
      6/7: kwin-x11              ###########################################################################
      7/7: kwin                  ###########################################################################
      1/6: removing kwin-5.27.10-1.2.mga9.x86_64
                                 ###########################################################################
      2/6: removing kwin-common-5.27.10-1.2.mga9.x86_64
                                 ###########################################################################
      3/6: removing lib64kwin5-5.27.10-1.2.mga9.x86_64
                                 ###########################################################################
      4/6: removing lib64kwineffects14-5.27.10-1.2.mga9.x86_64
                                 ###########################################################################
      5/6: removing lib64kwinglutils14-5.27.10-1.2.mga9.x86_64
                                 ###########################################################################
      6/6: removing lib64kcmkwincommon5-5.27.10-1.2.mga9.x86_64
                                 ##########################

Latter will come with upgrade test
First will check if Plasma works without issues

In a VM Looks good, will upgrade the VM to check if all goes well

I've tested the upgrade of a quite loaded Mageia 9 instance to cauldron using urpmi. The cauldron system is fully functional with Plasma X11 and Wayland.

Here are all the packages with "kwin" substring:   

Mageia 9 (Wayland + X11):
$ rpm -qa | grep kwin
kwindowsystem-5.114.0-1.mga9
lib64kcmkwincommon5-5.27.10-1.2.mga9
lib64kwinglutils14-5.27.10-1.2.mga9
lib64kwineffects14-5.27.10-1.2.mga9
lib64kwin5-5.27.10-1.2.mga9
kwin-common-5.27.10-1.2.mga9
kwin-5.27.10-1.2.mga9
kwin-wayland-5.27.10-1.2.mga9

Mageia10 after upgrade from 9:
$ rpm -qa | grep kwin
lib64kwinglutils14-5.27.10-1.4.mga9
lib64kwineffects14-5.27.10-1.4.mga9
lib64kwin5-5.27.10-1.4.mga9
lib64kcmkwincommon5-5.27.10-1.4.mga9
kf5-kwindowsystem-5.116.0-2.mga10
kwindowsystem-6.22.0-1.mga10
lib64kcmkwincommon-x11_6-6.5.5-1.mga10
lib64kcmkwincommon6-6.5.5-2.mga10
lib64kwin6-6.5.5-2.mga10
kwin-common-6.5.5-2.mga10
kwin-wayland-6.5.5-2.mga10
lib64kwin-x11_6-6.5.5-1.mga10
kwin-6.5.5-2.mga10
kwin-x11-6.5.5-1.mga10

Correction to the above list for Mageia 9:
*kwin*-1.2.mga9 should be *kwin*-1.4.mga9

I think this is fixed now. The upgrade via dnf has some problems, but that's a different issue.

(In reply to Giuseppe Ghibò from comment #31)
> I think this is fixed now. The upgrade via dnf has some problems, but that's
> a different issue.

I agree Just want to finish the VM upgrade and reboot to check the RH update with plasma session

The upgrade go at 50% ~

(In reply to katnatek from comment #32)
> (In reply to Giuseppe Ghibò from comment #31)
> > I think this is fixed now. The upgrade via dnf has some problems, but that's
> > a different issue.
> 
> I agree Just want to finish the VM upgrade and reboot to check the RH update
> with plasma session
> 
> The upgrade go at 50% ~

Perfect. Let's wait for it to complete to be sure.

Despite the manual actions to get rid of rocm packages the VM upgrade 
Looks good, the desktop delay a few to start but that no matter (just test x11 session)

I reboot now the RH to test Plasma

RH Plasma x11 & wayland tested
Not issues to report

Whiteboard: (none) => MGA9-64-OK
Flags: (none) => test_passed_mga9_64+

Used a QEMU/KVM VM for testing these kwin packages, and do an upgrade from Mageia 9 to Mageia 10.
Used urpmi for all the installs and upgrades.
Used a x86_64 system so i586/i686 packages were not tested.

Now for the actual testing.

The kwin packages installed without issues. The upgrade to Mageia 10 also went well, with the exception of the package lib64rocm-opencl-runtime5.7-5.7.1-3.1.mga9 that add a conflict, so I skipped the rocm packages. After the upgrade I removed all orphaned packages, and all mga9 packages that could be removed without removing mga10 packages.

These are the mga9 packages remaining:
"""
$ rpm -qa | grep mga9
lib64hsakmt1-1.0.6-0.5.7.1.2.mga9
lib64rocm-runtime1-5.7.1-1.1.mga9
lib64rocm-opencl-runtime5.7-5.7.1-3.1.mga9
"""

All Plasma and kwin packages upgraded without issues. After the upgrade, both Plasma X11 and Plasma Wayland were tested. Wayland still has issues but both worked as expected.

This update also gets an OK from me too.

RH i586

Install with packages from webkit2
https://bugs.mageia.org/show_bug.cgi?id=35228#c5

Reboot
Start Plasma X11

Looks good

Sorry to not test a 32b upgrade

Whiteboard: MGA9-64-OK => MGA9-64-OK,MGA9-32-OK
Flags: (none) => test_passed_mga9_32+

Validating.

CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update

MGA9-64, Plasma, Ryzen 5600, nvidia 3050

The following 6 packages are going to be installed:

- kwin-5.27.10-1.4.mga9.x86_64
- kwin-common-5.27.10-1.4.mga9.x86_64
- kwin-x11-5.27.10-1.4.mga9.x86_64
- lib64kwin5-5.27.10-1.4.mga9.x86_64
- lib64kwineffects14-5.27.10-1.4.mga9.x86_64
- lib64kwinglutils14-5.27.10-1.4.mga9.x86_64

226KB of additional disk space will be used.



--rebooted

used for awhile without any identified isues

CC: (none) => brtians1

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2026-0022.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED