SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I ran "find /usr /etc -name \*kd\*.new" to find them all. FYI, the kdmrc.new (and backgroundrc.new) was in /etc/kde/kdm
Once I moved the .new files into their proper names, I had a working KDE.
You can quickly find *.new files using slackpkg. I can't remember the argument to pass at the moment though. One thing though is that slackpkg did not find /usr/bin/startkde.new as I don't think it looks through /usr/bin.
I'm glad to hear that this worked!! Now, my next project is to find a way to get this going on Slackware 13 and beyond.
Woodsman, I'll be happy to lend you a hand on this project. Time dependent of course.
I've noticed one strange thing. If I try to start a root session in Konsole, it rejects my password. I can still use su to become root with no trouble. I normally use sudo, but haven't set it up on the virtual machine.
Ok, everything is working much better now! KDM (which looks really good by the way) is working correctly. I had to change the "Welcome to Kubuntu"to "Welcome to Slackware". There are still a few quirks though. I'm getting a double Trash can icon on the desktop. Also, wicd is being loaded twice. That leads me to believe that something is being sourced more than once. Will take a look at this later though. Time to get some rest!
Will continue to post things as I find them. Anybody else, feel free to post your findings also.
Ah, yes, that would also work. Also, running slackpkg new-config would just about catch most *.new files.
I noticed another quirk. Building knemo works, but no binary is created, as in, nothing is created in /usr/bin. I'm not entirely sure why it does that, although I thought that knemo was a qt4 application only.
I solved the root shell in console problem. I guess it's using sudo. Once I added my user to the sudoer file and entered my user password instead of the root password, the root shell worked.
Now I have a couple other questions that, hopefully, Woodsman can answer next time he can check the thread.
In his README file he mentions that the packages were built with hooks for various things like libdvdcss, for example. Will the programs take advantage of that if it is already installed, or does one need to rebuild and reinstall such packages?
I also notice packages libcaldav and libical and was wondering if these permit access to Google calendars. If so, how? I saw no new korganiser resources that looked appropriate. If not, I'm hoping opensync works. On 3.5.10, it is not handling timezones correctly.
I'm nearly ready to take the plunge on my live system.
Ok, I was able to build dbus-qt3 on a Virtual 13.1 64 bit. All of these had to be built in order as described in Woodsman's Page:
If everything goes well, I should be able to have packages build for Slackware 13.1 64 bit. This install will be along side KDE4 which is what I really want to test. I should be able to build 32-bit packages if everything goes well.
Well, after trying, and trying, I couldn't get arts to build in Slackware 13.1. It may build on 13.0, but I don't have it installed in Virtualbox at the moment. As it stands, it appears that installing TDE on 13.1 or beyond is a no go. I may try later using SVN instead.
I updated my web page with a warning not to use upgradepkg to install Trinity with KDE 3.5.10 installed.
There are two Trinity list groups that might help: one for developers and one for users. As my schedule right now is horrible for any meaningful support, please consider joining one or both groups. The links are available at the Trinity web site.
A note for those having problems: The pre-built Trinity 3.5.12 packages install in /usr and not /opt. Because the pre-built packages thus far available are intended only for 12.2, that should not pose problems as long as all remnants of KDE 3.5.10 are removed. Installing those same packages in 13.0 or later will cause problems. The solution is to rebuild the packages and ensure the build scripts build for installing in /opt.
Removing the remnants of KDE 3.5.10 include the following:
Please note I have not tested the build process on post 12.2 systems. I designed my build scripts to accommodate installations in either /usr or /opt, but there easily might be some bugs in that process. I also have not tested the build scripts for building foundation packages in post 12.2 systems, such as qt3, dbus, etc. My scripts at this point check for the packages being installed, but do not yet have any robust testing for ensuring those foundation packages are installed correctly and won't conflict with other expected stock packages such as qt4.
The build scripts support building Trinity 3.5.12 in 12.2 using /opt rather than /usr, which would allow both KDE 3.5.10 and Trinity 3.5.12 to be installed concurrently. Check the build scripts documentation for overriding the defaults.
I have experienced no problems using my existing ~/.kde profile when testing Trinity.
Regarding the empty K-menu problems. I'll take a wild guess the solution has already been alluded to in this thread. That is, the /etc/profile.d/kde.sh script is installed as a *.new file. Without that file being sourced correctly, the startup sequence will not find the correct xdg paths for the menus.
I built the kdebase package using *.new files because in the past I always was frustrated with the stock Slackware overwriting my customizations of those related files. My kdebase build script has a related comment about that. The script can be modified, of course. The following files are built and installed as *.new files: