Hi y'all, I'm running 14.1.2 (with some 14.1.3, some of the slackbuilds are broken,) on Slackware 15 and I've noticed an issue with flatpak apps. They were unable to access the keystore for me and after some debugging I found that in TDE the environment variables for dbus (DBUS_SESSION_BUS_ADDRESS and PID) aren't set, where in environments which have working flatpak apps they are. Sure enough, dbus-launch [flatpak app] lets them launch successfully. I've found a couple of other weird bits which I think may be dbus related too.
I've tried adding an "eval $(dbus-launch)" to my ~/.xprofile per what happens in starttde, I also tried adding it manually into the starttde script right around where tde_dbus_hardwarecontrol is invoked but I don't have the vars set in my actual session in either case. Does anyone know how I can fix this?
Thanks, Danny
Daniel Wilkins via tde-users wrote:
I've tried adding an "eval $(dbus-launch)" to my ~/.xprofile per what happens in starttde, I also tried adding it manually into the starttde script right around where tde_dbus_hardwarecontrol is invoked but I don't have the vars set in my actual session in either case. Does anyone know how I can fix this?
I don't know but in debian I have the variable
$ export | grep -i dbus declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
note this is the session bus - the one started in the user environment there is also the system bus - the one started by the system when booting (but seems not so relevant here)
On Sun, Nov 03, 2024 at 09:24:18PM +0100, deloptes via tde-users wrote:
$ export | grep -i dbus declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
Interesting, I wonder if this is a packaging issue then. Do you start your session via tdm or something else?
Daniel Wilkins via tde-users wrote:
$ export | grep -i dbus declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
Interesting, I wonder if this is a packaging issue then. Do you start your session via tdm or something else?
yes TDM - standard setup - no other desktop installed.
Might be packaging issue - don't know - but I tend to recall that dbus is started by systemd.
/lib/systemd/systemd --user _ (sd-pam) _ /usr/bin/pulseaudio --daemonize=no --log-target=journal _ /usr/bin/dbus-daemon --session --address=systemd: --nofork ...
And I think this variable should be available There are hints about shell being not bash etc.
BR
On Mon, Nov 04, 2024 at 10:37:49PM +0100, deloptes via tde-users wrote:
Might be packaging issue - don't know - but I tend to recall that dbus is started by systemd.
I think that might be the exact issue. tde doesn't bother setting that up because systemd normally does (which Slackware doesn't use) and also the shell games in tdeinit (tdm -> starttde -> tdeinit wrapper -> tdeinit) are probably cleaning up the environment at some point, keeping my modifications from reaching the actual session environment. I'll open up a bug on the packaging side.
On Mon, Nov 04, 2024 at 05:06:14PM -0500, Daniel Wilkins via tde-users wrote:
On Mon, Nov 04, 2024 at 10:37:49PM +0100, deloptes via tde-users wrote: from reaching the actual session environment. I'll open up a bug on the packaging side.
Actually just confirmed that changing the line invoking the tdeinit wrapper to a dbus-launch of the tdeinit wrapper fixes the problem. Since this isn't an issue in the vast majority of distros, it should probably be applied as a patch on the packaging end.
Daniel Wilkins via tde-users wrote:
Actually just confirmed that changing the line invoking the tdeinit wrapper to a dbus-launch of the tdeinit wrapper fixes the problem. Since this isn't an issue in the vast majority of distros, it should probably be applied as a patch on the packaging end.
I was about to mention dbus-launch ... but found out you already posted. I was not aware that Slackware is not using dbus. I wonder how this is possible as tons of applications interact via dbus. To me it looks crippled. Anyway, glad you found the solution and raised the issue.
BR
On Tue, Nov 05, 2024 at 08:09:30PM +0100, deloptes via tde-users wrote:
Daniel Wilkins via tde-users wrote:
I was about to mention dbus-launch ... but found out you already posted. I was not aware that Slackware is not using dbus. I wonder how this is possible as tons of applications interact via dbus. To me it looks crippled. Anyway, glad you found the solution and raised the issue.
Slackware does ship with dbus, every other desktop session I've ever ran set the dbus user session up by default. I'm not quite sure what's going on differently there.
Daniel Wilkins via tde-users wrote:
I was about to mention dbus-launch ... but found out you already posted. I was not aware that Slackware is not using dbus. I wonder how this is possible as tons of applications interact via dbus. To me it looks crippled. Anyway, glad you found the solution and raised the issue.
Slackware does ship with dbus, every other desktop session I've ever ran set the dbus user session up by default. I'm not quite sure what's going on differently there.
Sorry I obviously meant systemd. If systemd is not in use, the desktop should start the user session of dbus via dbus-launch. I guess introducing systemd it was decided to manage dbus user session via systemd. This is appropriate decision. It seems TDE should check if systemd is in use and if not start the session via dbus-launch. And it seems to me it is not only Slackware, but any distro not using systemd - Debuan comes to my mind. How is it handled in Devuan? Does someone know?
On Tue, Nov 05, 2024 at 10:18:39PM +0100, deloptes via tde-users wrote:
It seems TDE should check if systemd is in use and if not start the session via dbus-launch.
All good. it should be easy enough to fix in starttde. Something like this?
diff --git a/starttde b/starttde index 66360e228..bbc3b2202 100755 --- a/starttde +++ b/starttde @@ -772,9 +772,15 @@ TDE_SESSION_UID=`id -u` export TDE_SESSION_UID echo "[starttde] TDE_SESSION_UID: $TDE_SESSION_UID" 1>&2
+# If we're not running under systemd, we need to launch tdeinit with dbus-launch +DBUSWRAPPER="" +if [ -z $DBUSWRAPPER ] && [ -x $(which dbus-launch) ]; then + DBUSWRAPPER=$(which dbus-launch) +fi + # We set LD_BIND_NOW to increase the efficiency of tdeinit. # tdeinit unsets this variable before loading applications. -LD_BIND_NOW=true $TDEDIR/bin/start_tdeinit_wrapper --new-startup +kcminit_startup +LD_BIND_NOW=true $DBUSWRAPPER $TDEDIR/bin/start_tdeinit_wrapper --new-startup +kcminit_startup if test $? -ne 0; then # Startup error echo "[starttde] Could not start tdeinit. Check your installation." 1>&2
Quick note: This isn't a real patch, I haven't tested it. Pretty sure it'd work, thogh.
Daniel Wilkins via tde-users wrote:
On Tue, Nov 05, 2024 at 10:18:39PM +0100, deloptes via tde-users wrote:
It seems TDE should check if systemd is in use and if not start the session via dbus-launch.
All good. it should be easy enough to fix in starttde. Something like this?
diff --git a/starttde b/starttde index 66360e228..bbc3b2202 100755 --- a/starttde +++ b/starttde @@ -772,9 +772,15 @@ TDE_SESSION_UID=`id -u` export TDE_SESSION_UID echo "[starttde] TDE_SESSION_UID: $TDE_SESSION_UID" 1>&2
+# If we're not running under systemd, we need to launch tdeinit with dbus-launch +DBUSWRAPPER="" +if [ -z $DBUSWRAPPER ] && [ -x $(which dbus-launch) ]; then
- DBUSWRAPPER=$(which dbus-launch)
+fi
May be there is a better way to check if dbus session is started for the user. Look in starttde below following line # Start tde_dbus_hardwarecontrol at background
In debian there is the dbus-x11 package that contains dbus-launch command. It provides also few scripts where it says
$ cat /etc/X11/Xsession.d/75dbus_dbus-launch # $Id:$ # In order to activate the session bus at X session launch # simply place use-session-dbus into your /etc/X11/Xsession.options file #
STARTDBUS= DBUSLAUNCH=/usr/bin/dbus-launch
if has_option use-session-dbus; then if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] && [ -x "$DBUSLAUNCH" ]; then STARTDBUS=yes fi fi
if [ -n "$STARTDBUS" ]; then # Note that anything that is D-Bus-activated between here and # 95dbus_update-activation-env will not have the complete environment # set up by Xsession.d, unless the Xsession.d snippet that sets the # environment variable also calls dbus-update-activation-environment. # See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815503 eval $($DBUSLAUNCH --exit-with-session --sh-syntax) fi
-
Daniel Wilkins -
deloptes