Tumbleweed - Review of the week 2024/09
Dear Tumbleweed users and hackers, This week was truly crazy for the staging masters — apologies to Ana for flooding you with requests. Many contributors have been busy preparing our packages for RPM 4.20 (which is still at least half a year out – but we preferred to fix things now rather than being under pressure then). When the effort started on Feb 20, we had 2066 spec files that would have failed to build with RPM 4.20. Today, just 10 days later, we have less than 700 – and many requests in the queue to address those. Of course, that’s not everything that happened this week. We have again delivered six snapshots (0223, 0225, 0226, 0227, 0228, and 0229) with the following changes: * libjxl 0.10.0 & 0.10.1 (this time the update went without fallout) * Samba 4.19.5 * Linux kernel 6.7.6 * mdadm 4.3: stricter on naming devices posix compliant * Mozilla Firefox 123.0 * chrony 4.5 * openSSH 9.6p1 * fwupd 1.9.14 * exiv2 0.28.2 * Ruby 3.2 has been removed: this includes all the ruby gems AND the ruby 3.2 interpreter The staging lists and backlog are largely filled with the same old topics: * ImageMagick 7.1.1.29 * Python 3.x fixes for CVE-2023-6597 (TmpDir cleaning) * openblas 0.3.26: breaks python-networkx, and python-scikit-learn * openjpeg 2.5.1: breaks ghostscript * KDE Frameworks and Plasma 6: Staging turns out to be messy * KDE Gear 24.02.0 – Requires KDE Frameworks 6 * Systemd 255.3 * python 3.9 deprecation: we decided to postpone this a little but, due to the still large fallout from Python 3.12 addition. Removing a Python flavor will require us to rebuild all the Python packages for the new builds to drop the python39 flavor. Too many packages fail to build at this moment. * KDE Frameworks and Plasma 6: Staging turns out to be messy * dbus-broker: a big step forward; upgrades seem to be an issue that needs to be addressed * libxml 2.12.x: slow/no progress * GCC 14: phase 2: use gcc14 as the default compiler Cheers, Dominique
Am 01.03.24 um 17:36 schrieb Dominique Leuenberger:
KDE Frameworks and Plasma 6: Staging turns out to be messy
Since KDE Plasma 6.0 was published on 28 Feb, is there something we could test? Regards, Frank
* Frank Krüger via openSUSE Factory <factory@lists.opensuse.org> [03-01-24 18:45]:
Am 01.03.24 um 17:36 schrieb Dominique Leuenberger:
KDE Frameworks and Plasma 6: Staging turns out to be messy
Since KDE Plasma 6.0 was published on 28 Feb, is there something we could test?
zypper se -s plasma6 opi plasma6 https://software.opensuse.org/search for plasma6 google may even help -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Am Samstag, 2. März 2024, 00:38:33 CET schrieb Frank Krüger via openSUSE Factory:
Am 01.03.24 um 17:36 schrieb Dominique Leuenberger:
KDE Frameworks and Plasma 6: Staging turns out to be messy
Since KDE Plasma 6.0 was published on 28 Feb, is there something we could test?
I would expect, that according this: * KDE Frameworks and Plasma 6: Staging turns out to be messy It takes a while to solve all issues and dependencies. So next week Plasma 6.0.1 will be released with a lot of fixes, I think the KDE-maintainers will wait till this is out. Ulf
I played around with the packages in https://en.opensuse.org/SDB:KDE_repositories#KDE_Frameworks_6,_Plasma_6_and_... a bit and got it working. Not a good idea to do the upgrade inside a session of course, it was killed and I had to finish it from the console. I know, I'm just experimenting. :-) The audio controls didn't work until after reboot also (pulse->pipewire?). Otherwise I have something that looks pretty nice now! Installed: plasma6-desktop plasma6-workspace plasma6-session plasma6-branding-openSUSE sddm-greeter-qt6 sddm-kcm6 sddm-qt6 plasma6-systemmonitor plasma6-pa discover6 Den lör 2 mars 2024 kl 08:09 skrev Ulf via openSUSE Factory < factory@lists.opensuse.org>:
Am Samstag, 2. März 2024, 00:38:33 CET schrieb Frank Krüger via openSUSE Factory:
Am 01.03.24 um 17:36 schrieb Dominique Leuenberger:
KDE Frameworks and Plasma 6: Staging turns out to be messy
Since KDE Plasma 6.0 was published on 28 Feb, is there something we could test?
I would expect, that according this: * KDE Frameworks and Plasma 6: Staging turns out to be messy It takes a while to solve all issues and dependencies. So next week Plasma 6.0.1 will be released with a lot of fixes, I think the KDE-maintainers will wait till this is out.
Ulf
On 3/1/24 11:36, Dominique Leuenberger wrote:
The staging lists and backlog are largely filled with the same old topics:
* KDE Frameworks and Plasma 6: Staging turns out to be messy * KDE Gear 24.02.0 – Requires KDE Frameworks 6 * KDE Frameworks and Plasma 6: Staging turns out to be messy
I see that plasma 6 is now in staging. Is there any information as to how this will roll out to TW ? Specifically, Plasma 6 is supposed to default to Wayland but TW was originally installed with X11. Will Plasma 6 on TW force us to switch to Wayland or will X11 also still be supported ? I have a server which is used by multiple users who connect via Remote Destkop ( xrdp ) and from what I've found Wayland does not have support for rdp yet. It seems that it has Remote Control support where you can login to an existing desktop session but not Remote Desktop for multiple concurrent sessions as well as the existing server login session. FWIW, arch recently rolled out Plasma 6 and my arch machine defaulted to Wayland on the next install after rebooting and when you login on the console it just displays a black screen and the desktop never appears. I still haven't found the source of that issue BUT switching arch back to Plasma X11 on the login screen works fine. Anywhere that I can read more about the Plasma 6 rollout plans ? Thanks ! -- Regards, Joe
пʼятниця, 8 березня 2024 р. 18:14:34 EET Joe Salmeri написано:
On 3/1/24 11:36, Dominique Leuenberger wrote: Specifically, Plasma 6 is supposed to default to Wayland but TW was originally installed with X11.
Will Plasma 6 on TW force us to switch to Wayland or will X11 also still be supported ?
I'm using KDE:Unstable for >3 months and X11 is available without problem. Though I'm using Wayland, I've tried to switch in SDDM to X11 several times for tests. -- Kind regards, Mykola Krachkovsky
On 3/8/24 11:35, Mykola Krachkovsky wrote:
пʼятниця, 8 березня 2024 р. 18:14:34 EET Joe Salmeri написано:
On 3/1/24 11:36, Dominique Leuenberger wrote: Specifically, Plasma 6 is supposed to default to Wayland but TW was originally installed with X11.
Will Plasma 6 on TW force us to switch to Wayland or will X11 also still be supported ? I'm using KDE:Unstable for >3 months and X11 is available without problem. Though I'm using Wayland, I've tried to switch in SDDM to X11 several times for tests.
Thanks Mykola, I'm using plasma 6 with my arch machine ( with X11 ), what I am interested in is what the plans for for rolling this out in TW. Fedora I believe is planning to get rid of x11. -- Regards, Joe
субота, 9 березня 2024 р. 02:34:36 EET Joe Salmeri написано:
Thanks Mykola, I'm using plasma 6 with my arch machine ( with X11 ), what I am interested in is what the plans for for rolling this out in TW.
Fedora I believe is planning to get rid of x11.
As the path is KDE:Unstable → KDE → openSUSE:Factory, I don't think any removal is expected. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
субота, 9 березня 2024 р. 12:03:13 EET Mykola Krachkovsky написано:
субота, 9 березня 2024 р. 02:34:36 EET Joe Salmeri написано:
Thanks Mykola, I'm using plasma 6 with my arch machine ( with X11 ), what I am interested in is what the plans for for rolling this out in TW.
Fedora I believe is planning to get rid of x11.
As the path is KDE:Unstable → KDE → openSUSE:Factory, I don't think any removal is expected.
KDE:Unstable and KDE are openSUSE build repositories: KDE:Unstable: https://build.opensuse.org/project/show/KDE:Unstable:Frameworks https://build.opensuse.org/project/show/KDE:Unstable:Applications KDE: https://build.opensuse.org/project/show/KDE:Frameworks https://build.opensuse.org/project/show/KDE:Applications KDE repository is what linked as development repository for Factory. -- Kind regards, Mykola Krachkovsky
In data sabato 9 marzo 2024 01:34:36 CET, Joe Salmeri ha scritto: Hello,
Thanks Mykola, I'm using plasma 6 with my arch machine ( with X11 ), what I am interested in is what the plans for for rolling this out in TW.
No plans at this time to change the default, as far as I can remember. -- Luca Beltrame GPG key ID: A29D259B
On Sat, Mar 9, 2024 at 6:39 AM Luca Beltrame <lbeltrame@kde.org> wrote:
In data sabato 9 marzo 2024 01:34:36 CET, Joe Salmeri ha scritto:
Hello,
Thanks Mykola, I'm using plasma 6 with my arch machine ( with X11 ), what I am interested in is what the plans for for rolling this out in TW.
No plans at this time to change the default, as far as I can remember.
Does that mean you're reverting the upstream default to use Plasma Wayland? -- 真実はいつも一つ！/ Always, there's only one truth!
On 3/9/24 08:32, Christophe Marin via openSUSE Factory wrote:
On samedi 9 mars 2024 13:55:32 CET Neal Gompa wrote:
Does that mean you're reverting the upstream default to use Plasma Wayland?
No.
It means we won't make plasma 6 unusable for users that want/need to use X11.
Good news and thanks for the clarification. I use TW as a terminal server for multiple similtaneous Remote Desktop users ( using xrdp package ). From what I've seen/read/found, it does not appear that Remote Desktop works with Wayland at this point although I did find some stuff that work is being done. I also have another server which is headless and using xrdp which has multiple Remote Desktop users. When you try to research the topic it seems many people confuse Remote Desktop with Remote Control. Remote Desktop is multiple remote sessions with different users, Remote Control is remote access sharing the desktop session of the currently logged in user. I cannot switch to wayland until Remote Desktop is supported. -- Regards, Joe
On 10.03.2024 02:48, Joe Salmeri wrote:
I also have another server which is headless and using xrdp which has multiple Remote Desktop users.
When you try to research the topic it seems many people confuse Remote Desktop with Remote Control.
Remote Desktop is multiple remote sessions with different users, Remote Control is remote access sharing the desktop session of the currently logged in user.
I cannot switch to wayland until Remote Desktop is supported.
A Wayland session is defined by a running Wayland compositor. No remote access to the Wayland session is possible as long as the compositor is not running. So the only possible mode of remote access *is* Remote Control in your definition. KWin supported virtual backend for almost 10 years and "kwin_wayland --virtual" should work. If your KDE session enables remote access you should be able to connect remotely to "kwin_wayland --virtual". What is missing is Display Manager layer where you could connect to the system, authenticate and have your session started. That is what you define as Remote Desktop. Or to put it differently - it is not possible transparently, you cannot replace connection to one compositor (greeter session) by connection to another compositor (user session). But vncserver mode should work - ssh into the remote system and start some script that launches headless Wayland session, then connect to it using your program of choice.
On 3/9/24 21:21, Andrei Borzenkov wrote:
On 10.03.2024 02:48, Joe Salmeri wrote:
I also have another server which is headless and using xrdp which has multiple Remote Desktop users.
When you try to research the topic it seems many people confuse Remote Desktop with Remote Control.
Remote Desktop is multiple remote sessions with different users, Remote Control is remote access sharing the desktop session of the currently logged in user.
I cannot switch to wayland until Remote Desktop is supported.
A Wayland session is defined by a running Wayland compositor. No remote access to the Wayland session is possible as long as the compositor is not running. So the only possible mode of remote access *is* Remote Control in your definition.
KWin supported virtual backend for almost 10 years and "kwin_wayland --virtual" should work. If your KDE session enables remote access you should be able to connect remotely to "kwin_wayland --virtual".
What is missing is Display Manager layer where you could connect to the system, authenticate and have your session started. That is what you define as Remote Desktop. Or to put it differently - it is not possible transparently, you cannot replace connection to one compositor (greeter session) by connection to another compositor (user session). But vncserver mode should work - ssh into the remote system and start some script that launches headless Wayland session, then connect to it using your program of choice.
I remain confused about Wayland, please pardon my asking for clarification about it. My users and I center our workflow around logging into remote servers with "ssh -X" and then running GUI programs on the servers with the graphical output, keyboard, and mouse presented locally. They may simultaneously log into multiple remote servers and display their outputs locally, possibly in multiple virtual KDE desktops. Some users may also connect via xrdp to export the entire remote desktop. Questions: Does Wayland support networked connections similar to X11? If not, will it in the future? If not, what are the alternatives beside staying with X11? If Wayland does support remote connections, what port(s} does it use? Are connections encrypted? What of authentication? Thanks in advance for hopefully good answers. Regards, Lew
On 10.03.2024 09:55, Lew Wolfgang wrote:
On 3/9/24 21:21, Andrei Borzenkov wrote:
On 10.03.2024 02:48, Joe Salmeri wrote:
I also have another server which is headless and using xrdp which has multiple Remote Desktop users.
When you try to research the topic it seems many people confuse Remote Desktop with Remote Control.
Remote Desktop is multiple remote sessions with different users, Remote Control is remote access sharing the desktop session of the currently logged in user.
I cannot switch to wayland until Remote Desktop is supported.
A Wayland session is defined by a running Wayland compositor. No remote access to the Wayland session is possible as long as the compositor is not running. So the only possible mode of remote access *is* Remote Control in your definition.
KWin supported virtual backend for almost 10 years and "kwin_wayland --virtual" should work. If your KDE session enables remote access you should be able to connect remotely to "kwin_wayland --virtual".
What is missing is Display Manager layer where you could connect to the system, authenticate and have your session started. That is what you define as Remote Desktop. Or to put it differently - it is not possible transparently, you cannot replace connection to one compositor (greeter session) by connection to another compositor (user session). But vncserver mode should work - ssh into the remote system and start some script that launches headless Wayland session, then connect to it using your program of choice.
I remain confused about Wayland, please pardon my asking for clarification about it. My users and I center our workflow around logging into remote servers with "ssh -X" and then running GUI programs on the servers with the graphical output, keyboard, and mouse presented locally. They may simultaneously log into multiple remote servers and display their outputs locally, possibly in multiple virtual KDE desktops. Some users may also connect via xrdp to export the entire remote desktop.
Questions:
Does Wayland support networked connections similar to X11?
No.
If not, will it in the future?
No (at least, everything so far indicates that Wayland will never be extended over network).
If not, what are the alternatives beside staying with X11?
waypipe for "ssh -X". For "exporting entire desktop" both KDE and GNOME should support desktop sharing in Wayland.
If Wayland does support remote connections, what port(s} does it use? Are connections encrypted? What of authentication?
Desktop sharing is usually using RDP or VNC. You need to check your DE manuals what options they support. It is completely out of scope for Wayland.
Thanks in advance for hopefully good answers.
Regards, Lew
On 3/9/24 23:31, Andrei Borzenkov wrote:
Does Wayland support networked connections similar to X11?
No.
Not to complain, but I remember Sun Microsystem's slogan "The Network is the Computer" in 1986, partially enabled by X11. It sounds like Wayland is dropping that philosophy in favor of a simpler environment centered on the individual user sitting in front of a single computer. The X11 paradigm did have issues with local display of graphics generated remotely. Even if a local workstation had a super-duper graphics adapter it wasn't usable for a program running on a remote server. (If this can be done somehow, please let me know!) How will this work with Wayland using waypipe? Will it possibly improve graphical performance over a network?
If not, will it in the future?
No (at least, everything so far indicates that Wayland will never be extended over network).
I understand now, networking is out of scope for Wayland.
If not, what are the alternatives beside staying with X11?
waypipe for "ssh -X". For "exporting entire desktop" both KDE and GNOME should support desktop sharing in Wayland.
With waypipe, you have the Wayland Compositor running on the local machine, correct? It doesn't then run on the remote server, right? Does this imply that the remote graphics program can utilize the local graphics accelerator? That would be a big win!
If Wayland does support remote connections, what port(s} does it use? Are connections encrypted? What of authentication?
Desktop sharing is usually using RDP or VNC. You need to check your DE manuals what options they support. It is completely out of scope for Wayland.
Understand. xrdp can be configured to use TLS to ensure secure connections. In summary as I understand it, Wayland is basically changing the fundamental design philosophy of UNIX/Linux networked computing. We're loosing some things, and gaining others. Does this mean that Linux is now closer to the MS Windows environment? Regards, Lew
On 10.03.2024 19:28, Lew Wolfgang wrote:
On 3/9/24 23:31, Andrei Borzenkov wrote:
Does Wayland support networked connections similar to X11?
No.
Not to complain, but I remember Sun Microsystem's slogan "The Network is the Computer" in 1986, partially enabled by X11. It sounds like Wayland is dropping that philosophy in favor of a simpler environment centered on the individual user sitting in front of a single computer.
Yes, Wayland is really designed for local clients on the local system.
The X11 paradigm did have issues with local display of graphics generated remotely. Even if a local workstation had a super-duper graphics adapter it wasn't usable for a program running on a remote server. (If this can be done somehow, please let me know!)
How will this work with Wayland using waypipe? Will it possibly improve graphical performance over a network?
If not, will it in the future?
No (at least, everything so far indicates that Wayland will never be extended over network).
I understand now, networking is out of scope for Wayland.
If not, what are the alternatives beside staying with X11?
waypipe for "ssh -X". For "exporting entire desktop" both KDE and GNOME should support desktop sharing in Wayland.
With waypipe, you have the Wayland Compositor running on the local machine, correct?
Yes.
It doesn't then run on the remote server, right?
It does. Two instances of waypipe talk to each other, just like ssh client talks to ssh server.
Does this imply that the remote graphics program can utilize the local graphics accelerator?
Wayland works by sharing opaque buffers between client and compositor. Waypipe sends these buffers from the remote system to your local system for display. Of course compositor on your local system may use whatever acceleration is available to render those buffers and application on the remote system may use whatever acceleration is available to fill in these buffers if needed, it does not change a bit in how fast your network will deliver them. Which is not specific to Wayland at all.
That would be a big win!
If Wayland does support remote connections, what port(s} does it use? Are connections encrypted? What of authentication?
Desktop sharing is usually using RDP or VNC. You need to check your DE manuals what options they support. It is completely out of scope for Wayland.
Understand. xrdp can be configured to use TLS to ensure secure connections.
GNOME Remote Desktop supports TLS with RDP, I do not know about KDE.
In summary as I understand it, Wayland is basically changing the fundamental design philosophy of UNIX/Linux networked computing. We're loosing some things, and gaining others. Does this mean that Linux is now closer to the MS Windows environment?
Regards, Lew
On 10.03.2024 08:21, Andrei Borzenkov wrote:
What is missing is Display Manager layer where you could connect to the system, authenticate and have your session started. That is what you define as Remote Desktop. Or to put it differently - it is not possible transparently, you cannot replace connection to one compositor (greeter session) by connection to another compositor (user session).
Never say "never" :) https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/92 Not sure if something similar exists for KDE, from the description it sounds rather tied to GDM.
On Sun, Mar 10, 2024 at 11:04 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On 10.03.2024 08:21, Andrei Borzenkov wrote:
What is missing is Display Manager layer where you could connect to the system, authenticate and have your session started. That is what you define as Remote Desktop. Or to put it differently - it is not possible transparently, you cannot replace connection to one compositor (greeter session) by connection to another compositor (user session).
Never say "never" :)
https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/92
Not sure if something similar exists for KDE, from the description it sounds rather tied to GDM.
It is being discussed for KDE Plasma upstream too. We'll have it soon enough. -- 真実はいつも一つ！/ Always, there's only one truth!
On 3/10/24 00:21, Andrei Borzenkov wrote:
On 10.03.2024 02:48, Joe Salmeri wrote:
I also have another server which is headless and using xrdp which has multiple Remote Desktop users.
When you try to research the topic it seems many people confuse Remote Desktop with Remote Control.
Remote Desktop is multiple remote sessions with different users, Remote Control is remote access sharing the desktop session of the currently logged in user.
I cannot switch to wayland until Remote Desktop is supported.
A Wayland session is defined by a running Wayland compositor. No remote access to the Wayland session is possible as long as the compositor is not running. So the only possible mode of remote access *is* Remote Control in your definition.
KWin supported virtual backend for almost 10 years and "kwin_wayland --virtual" should work. If your KDE session enables remote access you should be able to connect remotely to "kwin_wayland --virtual".
What is missing is Display Manager layer where you could connect to the system, authenticate and have your session started. That is what you define as Remote Desktop. Or to put it differently - it is not possible transparently, you cannot replace connection to one compositor (greeter session) by connection to another compositor (user session). But vncserver mode should work - ssh into the remote system and start some script that launches headless Wayland session, then connect to it using your program of choice.
Thanks for the explanation. Those aren't my definitions, those are pretty commonly used, however, in my research on this topic there also seems to be a lot of information out there that misuses the terms so I wanted to be clear in my post. Remote Control / Remote Screen Sharing / Remote Management / Remote Screen Mirroring or whatever term you prefer lets you see the 1st computers screen on a 2nd remote computer. In the Microsoft world they call it Remote Assistance. While it may use some of the same technology as Remote Desktop ( also called Terminal Services on Windows ) is very different in that Remote Desktop provides multiple remote users access to a desktop session. I am aware of this limitation currently in Wayland but was pointed out "Never say Never" as work is being done to provide headless support for Wayland through GDM and I believe that the KDE people are also working on something. I've been following that link about Wayland thgrough GDM. The xrdp people are also watching/communicating with the TigerVNC people looking into how to provide this type functionality. Linux is such a great multi-user server so hopefully it is not a matter of if but one of when it will be available. -- Regards, Joe
On 3/9/24 06:39, Luca Beltrame wrote:
In data sabato 9 marzo 2024 01:34:36 CET, Joe Salmeri ha scritto:
Hello,
Thanks Mykola, I'm using plasma 6 with my arch machine ( with X11 ), what I am interested in is what the plans for for rolling this out in TW. No plans at this time to change the default, as far as I can remember.
Hi Luca, Can you elaboate? It is my understanding that the default on plasma 6 is Wayland. The default in current TW installs is x11. Which default are you referrring too ? FWIW, I've tried plasma 6 on 3 different test systems, on the 2 arch based systems, if I use plasma6 + x11 then everything seems to work, if I use plasma6 + wayland then after entrig -- Regards, Joe
On 3/9/24 06:39, Luca Beltrame wrote:
In data sabato 9 marzo 2024 01:34:36 CET, Joe Salmeri ha scritto:
Hello,
Thanks Mykola, I'm using plasma 6 with my arch machine ( with X11 ), what I am interested in is what the plans for for rolling this out in TW. No plans at this time to change the default, as far as I can remember.
Hi Luca, Can you please clearify / elaboate ? It is my understanding that the default on plasma 6 is Wayland. The default in current TW installs is x11. Which default are you referrring too ? FWIW, I've tried plasma 6 on 3 different test systems. On the 2 arch based systems, if I use plasma6 + x11 then everything seems to work, if I use plasma6 + wayland then after entering the password all I have is a black screen with a mouse pointer and no desktop. The 3rd test system is KDE Neon, which has no issues with plasma6 + wayland. -- Regards, Joe
participants (12)
-
Andrei Borzenkov -
Christophe Marin -
Dominique Leuenberger -
Ernst Persson -
Frank Krüger -
Joe Salmeri -
Lew Wolfgang -
Luca Beltrame -
Mykola Krachkovsky -
Neal Gompa -
Patrick Shanahan -
Ulf