3 Nov
2024
3 Nov
'24
8:43 p.m.
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
4 Nov
4 Nov
12:24 a.m.
Daniel Wilkins via tde-users wrote:
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)
5 Nov
5 Nov
1:37 a.m.
Daniel Wilkins via tde-users wrote:
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
2:06 a.m.
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.
2:36 a.m.
On Mon, Nov 04, 2024 at 05:06:14PM -0500, 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.
11:09 p.m.
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.
BR
6 Nov
6 Nov
1:18 a.m.
Daniel Wilkins via tde-users wrote:
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?
1:49 a.m.
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
1:57 a.m.
Quick note:
This isn't a real patch, I haven't tested it. Pretty sure it'd work, thogh.
5:01 a.m.
Daniel Wilkins via tde-users wrote:
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
150
days inactive
153
days old
11 comments
2 participants
participants (2)
-
Daniel Wilkins -
deloptes