tde-devels

devels@trinitydesktop.org

9 participants
3775 discussions

Re: [trinity-devel] First Trinity 3.5.12 Usability Test (KDEROOTHOME)

by Darrell Anderson

> 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.

14 years, 7 months

Re: [trinity-devel] First Trinity 3.5.12 Usability Test (startkde)

by Darrell Anderson

Found a few more echo messages that needed the "startkde: " prefix.

14 years, 7 months

Re: [trinity-devel] First Trinity 3.5.12 Usability Test

by Darrell Anderson

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.

14 years, 7 months

Re: [trinity-devel] First Trinity 3.5.12 Usability Test

by Darrell Anderson

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.

14 years, 7 months

Building koffice

by Darrell Anderson

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

14 years, 7 months

Slackware 12.2 Status

by Darrell Anderson

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

14 years, 7 months

Building kdeartwork

by Darrell Anderson

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

14 years, 7 months

Startup Management

by Darrell Anderson

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

14 years, 7 months

Building kdeartwork

by Darrell Anderson

All core packages, as well as amarok, ktorrent, k3b, and knemo built without error! kdeartwork is the lone holdout in tonight's effort. :( Log attached. Darrell

14 years, 7 months

Helpful Packages But Not Prerequisties

by Darrell Anderson

I'm thinking ahead with you offering binary packages for Slackware. There are several packages that do not have to be installed to build the core KDE packages. I have created this list from watching the build messages and logs. There might be additional packages to add to this list: libcarddav (part of the Trinity Project, kdepim) libcaldav (part of the Trinity Project, kdepim) avahi (dns-sd, DNS service discovery/zeroconf, kdelibs/kdebase) lua hspell (Hebrew spell checking) krb5 (kerberos) OpenEXR Libraries (EXR image format support, several KDE packages) GraphicsMagick (various image filters; e.g. koffice/krita, kdebase) JRE-Java Runtime Engine (kdebindings) JDK-Java Development Kit (kdebindings) SIP PyQT3 PyKDE (Trinity KDE Python bindings; require SIP and PyQT) PostgreSQL (koffice/kexi) Transcode, ffmpeg (k3b ripping) libdvdread, libdvdnav (k3b video ripping) If the binaries are built without these packages installed, then the build process will not create any related support, even if the end-user installs those packages after installing the KDE packages. If the binaries are built with these packages installed, then the end-user should be able to make use of those hooks as soon as the additional packages are added. What happens when the packages are built to provide that support but the end-user does not have the support packages installed? I'm presuming nothing happens and the built-in support is a dead-end stub. Hopefully the xsession errors log is not filled with useless messages. I always thought the KDE developers were horribly sloppy about controlling stdout/stderr messages captured in the xsession errors log. Have you done any testing in this area or offer any observations from daily use of Trinity? As you liked the idea about two sets of packages, one embracing full third-party support and one set stripped to the essentials, seems some testing in this area will be needed if we travel that road. For my first full build set I am going to build mostly without the third-party support. I likely will install most of the third-party packages listed previously and then build another set of packages. I'm curious what the differences will be in package sizes and performance. I have both a Pentium I and II box that provide some hard-core performance testing of any distro. :) If you decide to support two sets of packages I foresee a handful of exceptions. For example, people using K3B will presume and want full ripping support out of the box. I think that package has to be built the same for either set of packages. The K3B package in Slackware never was built that way because of concerns about digital restrictions. I always thought the package should be built with full support but then just don't include the other packages with the distro. At least then when users add the necessary support packages K3B would work immediately as advertised. Darrell

14 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels