Description of problem: When starting automatic connection at "MCC / Starting / automatic connection configuration / automatic connection" one can choose the username, but the window-flap opening at "default desktop" => doesn't list any "PLASMA/WAYLAND" session. Only "IceWM - IceWMSession and Plasma(X11)" are appearing. Wayland users must go through "Plasma/Systemsettings6/..." to get the wayland session changes, under condition that they possess an account in "KDE portofolio". Cauldron updated Steps to Reproduce: 1. Open MCC 2. Go to .../user automatic connection 3. Click the flap "Default Desktop"
CC: (none) => yvesbrungard
(In reply to Roger Checa from comment #0) > Description of problem: > > When starting automatic connection at "MCC / Starting / > automatic connection configuration / automatic connection" one can choose > the username, but the window-flap opening at "default desktop" => doesn't > list any "PLASMA/WAYLAND" session. > > Only "IceWM - IceWMSession and Plasma(X11)" are appearing. > > Wayland users must go through "Plasma/Systemsettings6/..." to get the > wayland session changes, under condition that they possess an account in > "KDE portofolio". > > > Cauldron updated > > > Steps to Reproduce: > 1. Open MCC > 2. Go to .../user automatic connection > 3. Click the flap "Default Desktop" That should be: 1. Open MCC 2. Click on Boot 3. Set up autologin to automatically login I don't see any wayland uptions there, either, but in my case that could be because I did something to remove all wayland choices from the list in SDDM. @ Roger, Before trying this, could you select Plasma Wayland in SDDM?
Component: Release (media or process) => RPM PackagesCC: sysadmin-bugs => kde, mageiatools, marja11
Status: NEW => NEEDINFO
Created attachment 14754 [details] wayland session absent
Wayland is actually selected in SDDM
You can read it in the Gkrellm device (bottom right) below date and time.
At this moment, MCC knows only about the X session location (/usr/share/xsessions/); hence, it cannot load or set Wayland sessions as they are located in /usr/share/wayland-sessions/. As a workaround, copying or making symlinks of the wayland sessions into the /usr/share/xsessions/ directory should make them available to MCC.
CC: (none) => arusanu
OK copying wayland sessions into the /usr/share/xsessions/ directory. The wayland session is now duly listed, and the automatic connection under wayland works.
(In reply to Roger Checa from comment #6) > OK copying wayland sessions into the /usr/share/xsessions/ directory. > The wayland session is now duly listed, and the automatic connection under > wayland works. OK, this is a workaround for you, but not the final solution for our tools.
Thanks for all the feedback. Assigning to the Mageia Tools Maintainers.
Status: NEEDINFO => NEWAssignee: bugsquad => mageiatools
Created attachment 14755 [details] path to add wayland window-managers to drakxtools The attached file is a crude attempt to add wayland window-managers to drakxtools srpm. Also, the chksession script, which belongs to desktop-common-data package, needs similar patching.
Created attachment 14756 [details] patch to add wayland window-managers to desktop-common-data source
Created attachment 14757 [details] updated patch for drakxtools Because the initial patch for drakxtools was bad, I've uploaded a new one. With the updated patch, I've properly tested drakautologin switching among various window managers, and it worked fine.
Attachment 14755 is obsolete: 0 => 1
Patching the scripts. What I did : 1. I deleted the symlink I created as said in Comment 5, in order to restore the original configuration (without the line wayland in MCC). 2. I patched the script "/sbin/chksession" as said in "Attachment 14756 [details] - Comment 10-" => The line "wayland" was newly listed at the MCC "auto. conn." The patch is OK ! The changes a user wants to operate are effective ! 3. I patched the script "/usr/lib/libDrakx/any.pm" as said in " Attachment 14757 [details] - Comment 11" => I wasn't able to note anything, but everything went on working well. The devs should be more competent than I, to understand the goal expected, concerning the effectiveness of this second patch.
@Aurelian Do you have credentials to push your patches on our git repository?
(In reply to papoteur from comment #13) > @Aurelian > Do you have credentials to push your patches on our git repository? Nope, I'm just a regular user that sometimes runs into bugs and post some workarounds if any.
The 2 patches are now on the git repository. @Martin, can you review them?
CC: (none) => mageia
Reviewing the drakx patch: The change to any::get_session_file() looks OK, although indentation should be 4 spaces, not 2. The change to any::sessions() looks wrong to me. I think it will only return the sessions found in the last directory it searched. I've not tested it though. Procedural things: 1. You should also add a brief description of any changes to the perl_install/NEWS file and, if they affect the installer, to the perl_install/install/NEWS file. 2. You should reference this bug report in both the NEWS file and in the git commit message, using the short-form style (mga#33738) 3. You should manually wrap lines in the git commit message to keep within 80 columns.
Reviewing the common-data patch: (I don't see this in git, so looking at the patch attached here) I think this breaks the --test option. The code in the 'else' clause needs to be executed unconditionally.
Created attachment 14812 [details] second version of chksession patch (In reply to Martin Whitaker from comment #17) > Reviewing the common-data patch: > I think this breaks the --test option. The code in the 'else' clause needs > to be executed unconditionally. Attached is a new common-data patch that should address your remarks about the "--test" option. (In reply to Martin Whitaker from comment #16) > The change to any::sessions() looks wrong to me. While I do agree that the "chdir()" statements are not gracefully handled in the patch, I'm questioning the usefulness, even usage, of the "chdir()" instructions in "any::sessions()." In fact, as a dirty test, commenting out "chdir()" lines doesn't affect the behavior of autologin functionality, and I have yet to identify any use for it in drakxtools. NB: Another thing came out of this. There shouldn't be any ".desktop" files with the same name in the sessions directories, as autologin will start only one type of session regardless of your choice. For Enlightenment DE, that will be the Wayland session. I haven't figure out on what criteria the session file is chosen.
Attachment 14756 is obsolete: 0 => 1
Hello, I applied Aurelian's patches. However LXQt (Wayland) session isn't listed. cat /usr/share/wayland-sessions/lxqt-wayland.desktop [Desktop Entry] Type=Application Exec=startlxqtwayland TryExec=startlxqtwayland DesktopNames=LXQt Name=LXQt (Wayland) Comment=Lightweight Qt Desktop - Wayland Session
commit db650a0853be39d1c54cf2ccee8bd157cfb34a99 Author: Aurelian R <arusanu@...> Date: Sat Jun 7 15:44:07 2025 +0200 Fix detection of Wayland sessions (mga#33738) --- Commit Link: https://gitweb.mageia.org/software/desktop/common-data/commit/?id=db650a0853be39d1c54cf2ccee8bd157cfb34a99
(In reply to papoteur from comment #19) > Hello, > I applied Aurelian's patches. However LXQt (Wayland) session isn't listed. The problem was the line before Name, chksession is confused with it. I have fixed (I hope) in lxqt-wayland-session. Could someone who knows the process publish a release of drakx/perl-install to have the fix? It would be interesting to have that out.
Seems it is drakx-installer-stage2 which should be updated to 18.69
CC: (none) => geiger.david68210
Ah no it is more drakxtools src.rpm
Has anyone tested whether both X and Wayland sessions are listed in MCC->Set up autologin? I still think the new version of "sub sessions()" looks broken. /usr/share/wayland-sessions doesn't exist on my Mageia 9 system, so I can't test it myself.
I have checked that LXQt(Wayland) is listed in drakautologin, I can select it. Restarting opens a LXQt Wayland session. @Martin What kind of bad behaviour do you expect?
The value returned by a Perl subroutine is the value of the last expression evaluated during execution of the subroutine. In the original code, that was the "@l;" at the end of the subroutine. In the new code, that "@l;" is inside the foreach loop, and "@l" is local to the loop. So I would expect only the sessions found in the final iteration of the loop (i.e. in /usr/share/wayland-sessions) to be listed.
I've also noticed that both the original and the new code are broken as regards to preserving the current working directory. chdir() returns a boolean value indicating success or failure, not the old cwd.
However, drakautologin doesn't use the sessions() subroutine - it executes /usr/sbin/chksession - so that isn't a good way to test whether sessions() is working. I'll have to dig deeper.
Created attachment 15015 [details] drakautologin listing available sessions There is both X and Wayland sessions. Thanks Martin for deeper investigations.
commit e4915551e4e85130c6d5aabc7bf5e64a954d16db Author: Martin Whitaker <mageia@...> Date: Sun Jun 8 10:34:57 2025 +0100 Fix new implementation of any::sessions() (mga#33738) Commit 98978485f changed sessions() to search two directories, but didn't merge the results into a single list. Actually the code was not valid Perl, so sessions() always returned an empty list. --- Commit Link: https://gitweb.mageia.org/software/drakx/commit/?id=e4915551e4e85130c6d5aabc7bf5e64a954d16db
commit 6da07ebf5c7cfb5af40232f87c357cdb83f6b4ae Author: Martin Whitaker <mageia@...> Date: Sun Jun 8 10:42:21 2025 +0100 Fix any::sessions() to really preserve cwd (mga#33738) Both the old and new implementations of sessions() used chdir() to change to the directory being searched and then tried to restore the current working directory using the return value of chdir(). But chdir() returns a boolean indicating success or failure, so that could never work. --- Commit Link: https://gitweb.mageia.org/software/drakx/commit/?id=6da07ebf5c7cfb5af40232f87c357cdb83f6b4ae
As far as I could see, sessions() is only really used in the installer, so we wouldn't see any problems until the installer is updated. So I've just fixed the bugs I spotted. I've tested the new code in isolation.
(In reply to Martin Whitaker from comment #32) The things you learn, thanks for the concise lesson on debugging/fixing bugs. I was just annoyed by the bug, and it seemed simple to hack at the time.
(In reply to Aurelian R from comment #33) > The things you learn, thanks for the concise lesson on debugging/fixing > bugs. I was just annoyed by the bug, and it seemed simple to hack at the > time. That's how I got started too. I had no experience of Perl at the beginning, but I've learnt over the years :-)