Bug#1033390: plasma-desktop: Autostart Applications do not start when XDG_CONFIG_HOME is not $HOME/.config

2023-03-23 Thread James R Phillips
Package: plasma-desktop
Version: 4:5.27.2-1
Severity: normal

Dear Maintainer,

I boot multiple OS installs with a common /home partition, and have found it
best to maintain separate XDG configuration directories in $HOME, one for
each OS install. This prevents the desktop setting of each OS from interfering
with each other. This is done by setting the value of the XDG_CONFIG_HOME
environmental variable differently for each OS. When this variable is not set,
the default location for XDG configuration is $HOME/.config.

This mostly works with KDE plasma in Testing, but I do find that the autostart
applications are not starting if XDG_CONFIG_HOME is not $HOME/.config. When they
don't start, I can still see them in the Autostart section of plasma's System
Settings, and can add and remove them there.

A workaround I have found, if XDG_CONFIG_HOME is not $HOME/.config, is to put
a symlink in $HOME/.config pointing to $XDG_CONFIG_HOME/autostart. Once this
is done, the applications do start at login.

It seems clear that the startup process is ignoring the value of XDG_CONFIG_HOME
in searching for autostart application; it is instead always looking for
them in $HOME/.config/autostart.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-desktop depends on:
ii  accountsservice  22.08.8-6
ii  breeze   4:5.27.2-1
ii  kactivitymanagerd5.27.2-1
ii  kde-cli-tools4:5.27.2-1
ii  kded55.103.0-1
ii  kio  5.103.0-1
ii  kpackagetool55.103.0-1
ii  layer-shell-qt   5.27.2-1
ii  libaccounts-qt5-11.16-2
ii  libc62.36-8
ii  libglib2.0-0 2.74.6-1
ii  libibus-1.0-51.5.27-5
ii  libkaccounts24:22.12.3-1
ii  libkf5activities55.103.0-1
ii  libkf5activitiesstats1   5.103.0-1
ii  libkf5authcore5  5.103.0-1
ii  libkf5baloo5 5.103.0-2
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5codecs55.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-1
ii  libkf5configgui5 5.103.0-1
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5globalaccel-bin5.103.0-1
ii  libkf5globalaccel5   5.103.0-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kcmutilscore5  5.103.0-3
ii  libkf5kdelibs4support5   5.103.0-1
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5newstuffcore5  5.103.0-1
ii  libkf5notifications5 5.103.0-1
ii  libkf5notifyconfig5  5.103.0-1
ii  libkf5package5   5.103.0-1
ii  libkf5plasma55.103.0-1
ii  libkf5plasmaquick5   5.103.0-1
ii  libkf5quickaddons5   5.103.0-1
ii  libkf5runner55.103.0-1
ii  libkf5service-bin5.103.0-1
ii  libkf5service5   5.103.0-1
ii  libkf5solid5 5.103.0-1
ii  libkf5sonnetcore55.103.0-1
ii  libkf5sonnetui5  5.103.0-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5windowsystem5  5.103.0-1
ii  libkf5xmlgui55.103.0-1
ii  libkworkspace5-5 4:5.27.2-1
ii  libnotificationmanager1  4:5.27.2-1
ii  libpackagekitqt5-1   1.1.0-1
ii  libphonon4qt5-4  4:4.11.1-4
ii  libprocesscore9

Bug#254057: Update of kdelibs4 and kdelibs-bin solved the problem

2004-07-11 Thread James R. Phillips

Package: kde
Version: 4:3.1.2

I wrote earlier to say this bug (254057) afflicted me.  The issue was 
solved tonight when I updated to kdelibs4 and kdelibs-bin from 
unstable.  The versions went from 4:3.2.2-2 (testing version) to 
4:3.2.3-2 (unstable version) on both packages.  This resolved the 
problem for me, and I now have all widget styles available.


$ apt-show-versions -a kdelibs4
kdelibs44:3.2.3-2   install ok installed
No stable version
kdelibs44:3.2.2-2   testing
kdelibs44:3.2.3-2   unstable
kdelibs4/unstable uptodate 4:3.2.3-2

$ apt-show-versions -a kdelibs-bin
kdelibs-bin 4:3.2.3-2   install ok installed
No stable version
kdelibs-bin 4:3.2.2-2   testing
kdelibs-bin 4:3.2.3-2   unstable
kdelibs-bin/unstable uptodate 4:3.2.3-2

Maybe the movement of these packages to testing should be expedited, 
since they seem to solve this problem.


Thanks,

James R. Phillips
South Bend, Indiana




Bug#254057: Loss of non-built-in kde widgets also happened to me

2004-07-09 Thread James R. Phillips

Package: kde
Version: 4:3.1.2

I found this bug report (254057) in the database, and want to report 
that the loss of non-built-in kde widget styles also happened to me 
today.  I think it might be related an updated qt3 library, which I 
believe only recently went into testing (libqt3c102-3:3.2.3-4).


I first noticed it after a reboot, made necessary by recompiling the 
kernel (2.6.7).  This suggests to me that the problem occured when the 
object code from the updated qt3 library was loaded into memory for the 
first time.


I am running a system of mostly testing, with a few unstable apps, using 
apt-pinning.  It was recently installed using the sarge net-install cd, 
test candidate 1.


I tried apt-get install --reinstall for all installed kde-artwork 
packages, but while the reinstallation went fine, it did not bring back 
the desired (keramic) widget style.


James R. Phillips
South Bend, Indiana