[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Bug Janitor Service changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME --- Comment #35 from Bug Janitor Service --- This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #34 from Bug Janitor Service --- Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 David Edmundson changed: What|Removed |Added Status|CONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #33 from David Edmundson --- We changed some setting/unsetting env paths in 5.24 please retest -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Nate Graham changed: What|Removed |Added Component|general |Startup process Assignee|k...@davidedmundson.co.uk|plasma-b...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Nate Graham changed: What|Removed |Added Status|REOPENED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Nate Graham changed: What|Removed |Added CC||n...@kde.org, ||plasma-b...@kde.org Assignee|plasma-b...@kde.org |k...@davidedmundson.co.uk Component|generic-wayland |general -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #32 from Gerald Cox --- Here is a response from: https://bugzilla.redhat.com/show_bug.cgi?id=1912046 In case you didn't see it. I pushed a pull request to beef up systemd's docs a bit: https://github.com/systemd/systemd/pull/18137. It also deprecates a blanket 'systemctl import-environment' command and changes systemctl to emit a warning when that is used. It is fairly easy to describe how the environment is constructed by systemd, but the interaction with other parts of the stack is complex and not documented well. I don't think the systemd man pages are appropriate for this kind of documentation — we don't have the expertise and they would become stale at some point. We could probably put a document under systemd.io if no better place is found. > To dig a bit further, the memo says "Define shell-specific setup through > shell-specific profile scripts.", > but systemd goes through the shell-specific profile scripts. Systemd itself doesn't use the shell *at all*. This also means that it doesn't care about profile scripts. Instead, various desktop environments execute in an environment where the shell profile functions have been executed, and when they call 'import-environment' or the dbus-api equivalent to propagate session-specific variables, various variables are pushed to the manager environment block. I don't think this makes sense, because we end up with too many wrong things in the global environment. What I think should happen is that the desktop environment should export a few variables it sets itself (emphasize *itself* here, if the desktop environment is assigning a variable, it knows whether it belongs in the global session block): DESKTOP_SESSION, DISPLAY, GDMSESSION, GDM_LANG, GNOME_SETUP_DISPLAY?, SESSION_MANAGER?, WAYLAND_DISPLAY, XAUTHORITY, XDG_SESSION_*, or equivalent for other environments. Whenever a shell process is created for the user, it should execute shell profile functions and create set the shell-specific variables there. I'm not an expert in bash profile initialization, but it seems that the right thing happens already: when I clean up my systemd user environment block by removing e.g. all MODULE* variables, and start a shell process as a service, I get them back: $ systemd-run --user -t bash (nested) $ set|grep ^MODULE MODULEPATH=/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles MODULEPATH_modshare=/usr/share/modulefiles:1:/usr/share/Modules/modulefiles:1:/etc/modulefiles:1 MODULESHOME=/usr/share/Modules MODULES_CMD=/usr/share/Modules/libexec/modulecmd.tcl MODULES_RUN_QUARANTINE='LD_LIBRARY_PATH LD_PRELOAD' When I start a gnome-terminal, the shell in the gnome terminal also has the MODULE* variables. So it seems that the environment-modules stuff is properly initialized without pushing anything through the manager environment block. I don't think there's anything to fix in environment modules. It's gnome-desktop/kde that might need some tweaking. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #31 from David Edmundson --- can someone direct me to an ISO/Virtualbox Image which I can use to reproduce? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #30 from Göran Uddeborg --- Yes, starting my (plasma) session from GDM everything seems to work properly. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #29 from Gerald Cox --- (In reply to Göran Uddeborg from comment #28) > Created attachment 134407 [details] > Beginning of wayland-errors > > The symptoms of this issue are the following, right? > - The desktop background is black. > - There is no context menu on the background. > - The panel doesn't start. > - Applications started via autostart files DO get started. > > If so; I see this issue too, but with Intel graphics. (More exactly, a > Lenovo T460.) This is on Fedora 33. It didn't appear when I initially > upgraded to 33, but when I recently upgraded everything it started. > > I tried the suggestion from comment #24, but it didn't make any difference. > I also added a ps command, and redirected standard out to standard error so > it would get caught in the wayland-errors file, and attach the beginning of > that file here. (I don't know where standard out shows up, if anywhere, > otherwise.) Yes, that's the issue. Thanks for the report. Have you tried using GDM? For me at least, GDM appears to work fine - the problem only appears to manifest itself when using SDDM. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #28 from Göran Uddeborg --- Created attachment 134407 --> https://bugs.kde.org/attachment.cgi?id=134407&action=edit Beginning of wayland-errors The symptoms of this issue are the following, right? - The desktop background is black. - There is no context menu on the background. - The panel doesn't start. - Applications started via autostart files DO get started. If so; I see this issue too, but with Intel graphics. (More exactly, a Lenovo T460.) This is on Fedora 33. It didn't appear when I initially upgraded to 33, but when I recently upgraded everything it started. I tried the suggestion from comment #24, but it didn't make any difference. I also added a ps command, and redirected standard out to standard error so it would get caught in the wayland-errors file, and attach the beginning of that file here. (I don't know where standard out shows up, if anywhere, otherwise.) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #27 from Gerald Cox --- (In reply to Rex Dieter from comment #26) > Well I'm stumped, you're effectively unconditionally running dbus-daemon (to > replace an already-running dbus-broker) and that somehow works. Using > dbus-broker doesn't work (for you). We still have no idea why, and no clues > why this only affects some users. > > Is that a fair assessment? We do know a little bit. AFAIK it only affects Radeon users in conjunction with SDDM, or rather let's put it this way, I haven't heard of any reports with people using other chipsets. It also started when the change in comment #15 was introduced. The SDDM bug is referenced in comment #17. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #26 from Rex Dieter --- Well I'm stumped, you're effectively unconditionally running dbus-daemon (to replace an already-running dbus-broker) and that somehow works. Using dbus-broker doesn't work (for you). We still have no idea why, and no clues why this only affects some users. Is that a fair assessment? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335
--- Comment #25 from Gerald Cox ---
(In reply to Rex Dieter from comment #24)
> Anyone experiencing issues (Gerald?), try adding this near the top of
> /usr/libexec/plasma-dbus-run-session-if-needed
>
> # probe dbus first
> qdbus-qt5 >& /dev/null ||:
>
> (before the check: if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ] )
>
> that will ensure socket activation has a chance to start it first
Hey Rex, thanks for the suggestion. Unfortunately it didn't work. If you look
at the script trace info I provided in comment #19, it shows:
dbus_session_bus_address unix:path=/run/user/1000/bus
As we're getting closer to F34, I would suggest we look at switching out SDDM
for GDM unless we get some quick traction on getting this issue resolved.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335
--- Comment #24 from Rex Dieter ---
Anyone experiencing issues (Gerald?), try adding this near the top of
/usr/libexec/plasma-dbus-run-session-if-needed
# probe dbus first
qdbus-qt5 >& /dev/null ||:
(before the check: if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ] )
that will ensure socket activation has a chance to start it first
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #23 from Rex Dieter --- Sorry, just realized that was mentioned first comment. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #22 from Rex Dieter --- Part of the problem too may be that fedora switched to using dbus-broker by default instead of dbus-daemon awhile back (and dbus-run-session is for the latter), https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335
--- Comment #21 from Gerald Cox ---
(In reply to David Edmundson from comment #20)
> that echo was before the if statement?
Yes, I put that in to show the value. It is still part of the if statement,
but since it exists the if statement isn't triggered.
>
> And commenting out
>
> "if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]
> then
> drs=dbus-run-session
> fi"
>
>
> magically makes things work?
I don't actually comment out that if statement, what I do was suggested here:
https://github.com/sddm/sddm/issues/1335
Which basically bypasses this script all together and just invokes
dbus-run-session.
Interesting to note, the script works fine when running GDM, it's only when
using SDDM that it is an issue - and apparently only when using radeon
graphics.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335
--- Comment #20 from David Edmundson ---
that echo was before the if statement?
And commenting out
"if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]
then
drs=dbus-run-session
fi"
magically makes things work?
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 torokat...@gmail.com changed: What|Removed |Added CC||torokat...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Göran Uddeborg changed: What|Removed |Added CC||goe...@uddeborg.se -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #19 from Gerald Cox --- Thanks for the quick response. Here is what was produced by the script: dbus_session_bus_address unix:path=/run/user/1000/bus OpenGL vendor string: X.Org OpenGL renderer string: AMD PITCAIRN (DRM 2.50.0, 5.9.14-200.fc33.x86_64, LLVM 11.0.0) OpenGL version string: 4.5 (Core Profile) Mesa 20.2.4 OpenGL shading language version string: 4.50 Driver: RadeonSI GPU class: Southern Islands OpenGL version: 4.5 GLSL version: 4.50 Mesa version: 20.2.4 Linux kernel version: 5.9.14 Requires strict binding:no GLSL shaders: yes Texture NPOT support: yes Virtual Machine:no plasmalog.txt (END) The results in the file are the same for both GDM and SDDM. The difference is that GDM opens Plasma successfully. SDDM opens the plasma session with a solid black screen. I can open a terminal window, but the desktop is solid black, I can't see any panels. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #18 from David Edmundson --- So we think DBus is started, but DBUS_SESSION_BUS_ADDRESS is not set? If we're unsure, lets add some echo HERE >> /tmp/log type messages throughout that script -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Gerald Cox changed: What|Removed |Added CC||gb...@bzb.us Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #17 from Gerald Cox --- This fix causes a black screen desktop on Fedora 33 when using the combination of Radeon and SDDM. It has been reported here: https://github.com/sddm/sddm/issues/1335 and here: https://bugzilla.redhat.com/show_bug.cgi?id=1897717 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #16 from martc...@gmx.net --- Thanks for the fix. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 David Edmundson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from David Edmundson --- davidedmundson wrote: > @bug_id = 404335 > @bug_status = RESOLVED > @resolution = FIXED > @cf_commitlink = > https://invent.kde.org/plasma/plasma-workspace/commit/8475fe4545998c806704a45a7d912f777a11533f > > Git commit 8475fe4545998c806704a45a7d912f777a11533f by David Edmundson. > Committed on 30/06/2020 at 10:59. > Pushed by davidedmundson into branch 'master'. > > Only spawn dbus-run-session if there isn't a session already > > Typically on modern systems this will be started for us earlier in the > startup series and we don't have to worry about it. > > For X11 clients look for the bus address on the X11 root window as a way > of sharing. > > For reasons at the time we start our own DBus session within our wayland > session. Nesting causes conflicts and problems so this patch only start > a dbus session if one has not been set up already. > > M +1-1login-sessions/plasmawayland-dev.desktop.cmake > M +1-1login-sessions/plasmawayland.desktop.cmake > M +1-0startkde/CMakeLists.txt > A +10 -0startkde/plasma-dbus-run-session-if-needed -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Bug Janitor Service changed: What|Removed |Added Status|REPORTED|ASSIGNED Ever confirmed|0 |1 --- Comment #14 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/128 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #13 from David Edmundson --- Those setups don't get wayland anyway, but it's certainly the easiest path to resolving the bug, so I'll make an updated patch doing that. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #12 from Fabian Vogt --- (In reply to David Edmundson from comment #11) > >There's simply no alternative. That seems to be the consensus on > >https://github.com/bus1/dbus-broker/issues/145 as well. > > Ack, but I've personally changed my mind about whether it's our > responsibility to do any kind of fallback. > (https://phabricator.kde.org/D19004) > > dbus-broker and dbus-daemon are both socket activated. On all good setups it > will "just work". > > It was just a hack for an old Ubuntu at the time, but that's no longer the > case. Unless on X11, where a property is changed on the root window, DBUS_SESSION_BUS_ADDRESS has to be set in the environment to have a common session bus. So unless DBus is explicitly started by a parent process in one way or another, this is actually not enough AFAICT. With systemd, pam_systemd takes care of that I think, but what is on systems where this isn't the case, like without systemd or on FreeBSD, where DBus is an "afterthought"? The method of only using dbus-run-session if DBUS_SESSION_BUS_ADDRESS is unset seems the safest. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #11 from David Edmundson --- >There's simply no alternative. That seems to be the consensus on >https://github.com/bus1/dbus-broker/issues/145 as well. Ack, but I've personally changed my mind about whether it's our responsibility to do any kind of fallback. (https://phabricator.kde.org/D19004) dbus-broker and dbus-daemon are both socket activated. On all good setups it will "just work". It was just a hack for an old Ubuntu at the time, but that's no longer the case. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335
Fabian Vogt changed:
What|Removed |Added
CC||fab...@ritter-vogt.de
--- Comment #10 from Fabian Vogt ---
What might work is to have a wrapper around dbus-run-session which only starts
a session bus if necessary, e.g.:
drs=
[ -n "${DBUS_SESSION_BUS_ADDRESS}" ] || drs=dbus-run-session
exec ${drs} "$@"
Maybe this could be added to startplasma-wayland itself.
What is unavoidable though is the use of dbus-run-session to start the bus if
it's not there yet.
There's simply no alternative. That seems to be the consensus on
https://github.com/bus1/dbus-broker/issues/145 as well.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 martc...@gmx.net changed: What|Removed |Added CC||martc...@gmx.net --- Comment #9 from martc...@gmx.net --- I would like to point out that even with the regular D-Bus implementation using `dbus-run-session` causes problems. This is at least the case under systemd-based distributions where the D-Bus processes (including the session D-Bus) are started via systemd. I've explained it in further detail in this Arch Linux issue: https://bugs.archlinux.org/task/66766 The main problem is that `org.freedesktop.systemd1` is not available this way preventing software relying on it to work, e.g. https://github.com/Martchus/syncthingtray#required-system-configuration. In my opinion starting the session D-Bus and starting the graphical environment should not be coupled. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #8 from Ardith Metz --- Gnome 3.34 adopted systemd for start/manage session: https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/ I hope KDE join it some day. I saw some effort in https://github.com/KDE/plasma-systemd-integration but it stalled. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Patrick Silva changed: What|Removed |Added CC||bugsefor...@gmx.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #7 from David Edmundson --- Yes, that's why this bug is still open. That doesn't mean I'm just going to naively replace one bug for another. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #6 from Ardith Metz --- (In reply to David Edmundson from comment #5) > We absolutely cannot do that as a strict dependency. Then don't and simply assume that system has dbus already started which is true for most if not all distros. The current approach is described as detrimental[1] https://github.com/bus1/dbus-broker/issues/145#issuecomment-398727176 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #5 from David Edmundson --- We absolutely cannot do that as a strict dependency. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #4 from Ardith Metz --- (In reply to David Edmundson from comment #3) > That's true only if one has dbus socket activated. Switching plasma session to run as systemd user service would allow to create dependency on dbus.socket service. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 David Edmundson changed: What|Removed |Added CC||k...@davidedmundson.co.uk --- Comment #3 from David Edmundson --- >but it's also possible to just omit dbus-run-session command and run >/usr/bin/startplasmacompositor directly. That's true only if one has dbus socket activated. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #2 from Ardith Metz --- The issue is not about that you should rely on dbus-broker but about that you shouldn't rely on dbus-daemon and be agnostic of whatever dbus implementation is used. In other words prepare for that dbus-run-session won't exist on system anymore. dbus-broker maintainers gave you same ideas what to do but it's also possible to just omit dbus-run-session command and run /usr/bin/startplasmacompositor directly. I assume that at the time "Ubuntu LTS supported dbus-broker for at least two years" the vast majority of distros will already migrate to dbus-broker so unless the goal is to make KDE wayland session an Ubuntu LTS only thing you would better to reconsider this. Fedora 30 is expected in May 2019. No, you don't have to thank me for this heads-up at all. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 --- Comment #1 from Christoph Feck --- I am tempted to close this, and ask for a notification once Ubuntu LTS supported dbus-broker for at least two years. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 404335] Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session
https://bugs.kde.org/show_bug.cgi?id=404335 Rex Dieter changed: What|Removed |Added CC||rdie...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
