From: furryfixer <furryfixer@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: KDE X11 should be started with dbus-run-session
Date: Tue, 12 May 2020 03:06:19 +0200 [thread overview]
Message-ID: <20200512010619.YV8ZO8_0ObVrLAMjB01pKIpExU3e3MrVx5McZGCZDHQ@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-21766@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]
New comment by furryfixer on void-packages repository
https://github.com/void-linux/void-packages/issues/21766#issuecomment-627047559
Comment:
My knowledge is limited in this area, but I confirm this issue occurs with lxdm and xdm as well, so would not suspect DM's to be at fault. The issue does NOT occur at all with LXQT and same DMs.
Arch (or systemd specifially?) creates a dbus socket at "/run/user/$UID/bus" and assigns $DBUS_SESSION_BUS_ADDRESS to that socket. Void (elogind specifically?) does not (for any desktop environment I have installed).
In Void, at each login, both KDE and LXQT create a file in "~/.dbus/session-bus/" directory. This file contains a "$DBUS_SESSION_BUS_ADDRESS=unix:abstract=..." variable assignment for apps that want it. The comments indicate this can/will be used if "$DBUS_SESSION_BUS_ADDRESS is not otherwise set. It seems to be that, these electron apps at least, are not looking here. I assume because they always expect the bus address to be assigned (to the socket perhaps).
The difference between LXQT and KDE Plasma seems to be that LXQT actively assigns the value found in the file within "~/.dbus/session-bus/" directory to the $DBUS_SESSION_BUS_ADDRESS variable. This could perhaps be done somehow for the Void KDE Plasma package? Otherwise, Xsession scripts could use the method suggested above, "exec dbus-run-session @" for example, or "export $(dbus-launch)" prior to the exec line. Or, as we did when dbus stopped autolaunching X11 (before dbus-x11):
```
[ -z "$DBUS_SESSION_BUS_ADDRESS" ] && eval `dbus-launch --sh-syntax`
export DBUS_SESSION_BUS_ADDRESS
exec .....
```
next prev parent reply other threads:[~2020-05-12 1:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 23:05 [ISSUE] " ProjectMoon
2020-05-10 1:02 ` ericonr
2020-05-10 13:07 ` ProjectMoon
2020-05-10 22:34 ` ericonr
2020-05-11 17:47 ` furryfixer
2020-05-11 18:10 ` Johnnynator
2020-05-11 18:10 ` Johnnynator
2020-05-11 21:04 ` ProjectMoon
2020-05-12 1:06 ` furryfixer [this message]
2020-05-12 11:46 ` furryfixer
2020-05-12 12:11 ` furryfixer
2020-05-20 6:41 ` ericonr
2020-05-20 12:42 ` Johnnynator
2020-05-20 15:02 ` furryfixer
2020-07-17 10:28 ` Johnnynator
2020-07-17 10:28 ` [ISSUE] [CLOSED] " Johnnynator
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200512010619.YV8ZO8_0ObVrLAMjB01pKIpExU3e3MrVx5McZGCZDHQ@z \
--to=furryfixer@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).