You are not logged in.
Yeah.
Offline
Cool. Many thanks for taking the time to explain a little. ![]()
I don't care what you do at home. Would you care to explain?
Offline
Cool. Many thanks for taking the time to explain a little.
I enjoy debating these things. You certainly made me think there, and what I said is really just one view. I suspect there are more than one sensible way to approach this one.
Overtime we (compositor team) might try to catch stderr and output it to a client like labnag so that the user can see error messages. If we do, they might influence how we think about this too.
Last edited by malm (2025-12-17 21:57:29)
Offline
Overtime we (compositor team) might try to catch stderr and output it to a client like labnag so that the user can see error messages.
When launching a Wayland session from LightDM (as BL does) then error messages are already being sent to ~/.xsesson-errors! (@hhh if you're using LightDM then please have a look at that file.)
This is because on Debian, LightDM installs /usr/share/lightdm/lightdm.conf.d/01_debian.conf containing this line:
session-wrapper=/etc/X11/XsessionThis is applied in Wayland sessions too, in spite of all the "X" references. But I don't think it's as horrifying as it may look - apart from sending error messages to the same ~/.xsesson-errors which users are already accustomed to, other important services like dbus are started up. Because it uses the "drop-in" /etc/X11/Xsession.d/ directory, apps can put files there when they are installed and they'll automatically get added to the startup sequence.
There are some things there which won't work on Wayland, but - at least at the moment - they harmlessly fail, while there are other things which are needed, and some other mechanism would have to be found if /etc/X11/Xsession were not invoked. Right now that's how my test Wayland VM is being started and although I haven't spent a lot of time on it yet, everything seems to be working.
It is possible to disable that Debian session-wrapper invocation by shipping another file (like lightdm.conf.d/50_bunsen.conf) and putting a different session-wrapper command there. I tried that once, and it didn't seem to change much, so I restored it to the Debian default, but as I said I haven't devoted many hours to this.
Of course @malm, for labwc itself you don't want to be wedded to the Debian session, but need it to be usable on any system. It might get complicated though.
Last edited by johnraff (2025-12-19 02:52:11)
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
When launching a Wayland session from LightDM (as BL does) then error messages are already being sent to ~/.xsesson-errors! (@hhh if you're using LightDM then please have a look at that file.)
I will. I'll do a fresh install when the next ISO is out. For now I'll just remove gdm3 and install bunsen-meta-all --no-install-recommends (bye bye, Wayland only system) but I'm currently running sid on my testing partition, so let's see what happens. ![]()
Boo, I forgot that xkb-data has been upgraded in sid and that wreaks havoc...
Error: Unable to satisfy dependencies. Reached two conflicting decisions:
1. keyboard-configuration:amd64 is selected for install because:
1. bunsen-meta-all:amd64=13.0-12 is selected for install
2. bunsen-meta-all:amd64 Depends console-setup
3. console-setup:amd64 Depends keyboard-configuration (= 1.244)
2. keyboard-configuration:amd64 Depends xkb-data (< 2.42A)
but none of the choices are installable:
[no choices]It'll be a few days before I can do a fresh install with trixie sources, I need to backup my labwc, niri and other Wayland configs.
I don't care what you do at home. Would you care to explain?
Offline