Installed the updated kdelibs and kdebase packages. Cleaned house to restore baselines.
Regarding the previous reports:
1. Trinity still creates a /root/.kde3 directory for root. As far as I can tell, Trinity is using /root/.kde because everything is performing as expected. A huge improvement! :)
Some snooping revealed that the only directories in /root/.kde3 are the cache, socket, and tmp directories. The same directories exist in /root/.kde too. I deleted all six directories and restarted X. All six were recreated.
I restored the snippet I had in startkde to create the KDEROOTHOME environment variable on-the-fly. That stopped the creation of the /root/.kde3 directory.
Something still remains awry.
==================================================
2. There is no ~/.xsession-errors file being created. I had those files this afternoon when we were debugging. What happened to the file? Looks like a regression there.
==================================================
3. I temporarily removed the "1>&2" redirects from startkde so I would have stdout on the screen. I did not see anything abnormal.
==================================================
4. I changed the "1>&2" redirects to "2>&1" so I might see error messages. I did not see any of those I reported previously, but I would be more assured if I saw a proper xsession-errors file.
==================================================
5. hplip-systray still starts. Something is bothering me about this nonsense. This was a nuisance several years ago and I cannot remember what I did to stop the train. I don't think KDE ever honored the XDG ~/.config/autostart directory. Hence, the recent startkde tweak to add that directory probably does not help. Probably should undo that tweak.
Hopefully something in the fogs of my mind surface to help me remember the magic from a few years ago. Rest assured that when I remember the solution we will document the resolution somewhere!
==================================================
6. The problem with creating a .directory file in the root of the file system is gone.
==================================================
7. I'm not seeing the "xset: bad font path element" nuisance message.
==================================================
Let's figure out what happened to the xsession-errors file so we can be sure that most of these problems are history.
I hope that helps!
Darrell
> Quick comment here. The above was very important.
> ;-) Trinity expects to
> see KDEROOTHOME set, not KDEHOME, when run as root.
> Maybe you can help
> here; is this a Debian-only distinction, or do other Linux
> systems also
> use KDEROOTHOME?
Setting KDEROOTHOME helps when running as root. Trinity did not create a new /root/.kde3 directory.
I made the change in my proposed startkde. An updated proposed script is attached. I added the following test:
# Run a quick test for root.
if [ -z "$KDEROOTHOME" ] && [ "$UID" = "0" ]; then
echo "startkde: User ID is $UID. Setting KDEROOTHOME to $KDEHOME."
export KDEROOTHOME=$KDEHOME
fi
So setting KDEROOTHOME will help and I hope my change cures the problem.
However, in addition to running my conky display from /root/.kde/Autostart, I realized that KPersonalizer was not running. That provides confirmation that Trinity starts out honoring $KDEHOME for root but then changes sometime after. Trinity must be reading the startupconfig file from /root/.kde in order to not run KPersonalizer. So although KDEROOTHOME helps avoid some of the problems I described, there remains something awry with the way Trinity starts out correctly and then veers off course.
Updated svn. Will be several hours before I can provide a report.
In the mean time, I see the newest version of startkde.
I found a few spots where I updated some of the echo messages since I sent you my last proposed copy. In these messages I added the "startkde: " prefix. Those prefixes help people debug because they then know from where the messages derive. Cosmetic only, but helpful.
I added two echo messages regarding XDG. Again, cosmetic but helpful.
Notes about the new startkde in svn.
I submitted a change that checked and created KDEROOTHOME. Have you seen that change in my previous messages. Have you decided against that change and incorporated the same checks in the base code? My ego is not at stake :) --- I'm just checking to make sure.
There are two sections in the current svn startkde that repeat. Start at line 139:
if [ -d /opt/kde3 ]; then
if [ -n "$KDEDIRS" ]; then
export KDEDIRS=$KDEDIRS:/opt/kde3/:/usr/
else
export KDEDIRS=/opt/kde3/:/usr/
fi
fi
if [ -d /opt/kde3 ]; then
if [ -n "$KDEDIRS" ]; then
export KDEDIRS=$KDEDIRS:/opt/kde3/:/usr/
else
export KDEDIRS=/opt/kde3/:/usr/
fi
fi
In my proposed script the second snippet reads:
if [ -d /opt/trinity ]; then
if [ -n "$KDEDIRS" ]; then
export KDEDIRS=$KDEDIRS:/opt/trinity/:/usr/
else
export KDEDIRS=/opt/trinity/:/usr/
fi
fi
I don't know whether you want my snippet or meant to delete the second repeating snippet in the current startkde.
New proposed startkde attached.
I updated svn but have not yet recompiled. I'm getting there.... :)
> > 1. As non-root Trinity seems to completely honor
> $KDEHOME. There is no
> > ~/.kde3 directory created and Trinity uses my existing
> ~/.kde directory.
> >
> > As root Trinity does not fully honor $KDEHOME.
> >
> <snip>
> Quick comment here. The above was very important.
> ;-) Trinity expects to
> see KDEROOTHOME set, not KDEHOME, when run as root.
> Maybe you can help
> here; is this a Debian-only distinction, or do other Linux
> systems also
> use KDEROOTHOME?
I know about the KDEROOTHOME variable. I have not toyed with a sufficient number of distros to provide a full answer. The stock Slackware does NOT set the variable. Certainly I can adjust my local /etc/profile.d variable scripts to set that variable. I will test that.
With that said, I wonder whether a simple check can be added in Trinty to look at $UID when KDEROOTHOME is not set?
> ===========================================================
> >
> > 4. The existing startkde is Debianized and causes
> breakage on Slackware
> > systems. I am submitting a proposed new startkde
> script. The proposed
> > script avoids certain presumptions and adds some tests
> before running
> > various commands. The proposed script also adds
> additional echo messages
> > to help debugging efforts.
>
> Can you attach it please? I would like to look at
> it/get it in SVN ASAP
> as we have already run past the feature freeze and these
> types of major
> changes need to be tested thoroughly prior to release.
Yes. Attached. I was going to attach to the previous message but decided to wait until I updated svn and could review your changes. :)
My proposed script is more robust that previous scripts, including the original kde scripts. Part of my additions I already had in my own modified 3.5.10 script. The script works fine here, but I don't have a Debian install using Trinity to test there.
As I mentioned, now that the core packages build and are installed (but not tested for usability!), I am again trying to build koffice.
I would like to ignore previous koffice reports and start fresh.
The first items I hope get addressed are the following configure warnings:
unknown icon type in kivio/plugins/kivioconnectortool/Makefile.in (kivio_connector_cursor1.png)
unknown icon type in kivio/plugins/kivioconnectortool/Makefile.in (kivio_connector_cursor2.png)
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
unknown icon prefix action in kpresenter/toolbar/Makefile.in
The warnings more than likely are non-fatal errors, but they also should be fixed. I'm new to this game, but I suspect the problem is with incorrect file names or typos in the make files or something similar.
Darrell
All core packages build. The following also build:
k3b
amarok
knemo
ktorrent
These popular non-core packages are yet untested but will be soon:
koffice
digikam
gtk-qt-engine
gwenview
k9copy
kaffeine
I have had problems building koffice. Now that the core packages build and install, which establishes a known foundation and baseline, I will start again trying to build koffice.
I have not yet installed any packages in a testing environment. Soon!
Darrell
Okay, I'm a little slow. I added the --enable-closure option to the kdeartwork build script and the package built.
Thus, at this point, all core trinity kde packages build on Slackware 12.2!
Darrell
There is some nominal support in kcontrol to support startup management.
I don't know what all is available in this area for KDE 3.5.x, but I'd like to see more.
As Slackers tend to be rather anal about such GUI apps <roll eyes>, very little in that way ever apeared in Slackware.
There is some kind of Lilo manager hook in kcontrol. There is something called qgrubeditor that supports GRUB 1. That tool now only supports QT4 (what's new). I don't see qgrubeditor in svn so here is a vote to support that.
Then there are the startup services and daemons. I don't know if any KDE GUI tool exists for that. If there I would appreciate a link so I can consider how that tool might be adapted to Slackware. I think the Ubuntu folks have something like that, but of course, GTK.
This all would be something for 3.5.13 of course.
Darrell