In last month's On The Desktop column, we instructed you on the fairly headache-proof process of installing the Helix GNOME desktop environment. This month, we introduce you to the trials and tribulations of installing KDE 2.0, the latest and greatest KDE of them all.
|Here’s Lookin’ at You: KDE 2.0 is a beautiful thing. That is, once you can finally convince it to compile straight.|
In last month’s On The Desktop column, we instructed you on the fairly headache-proof process of installing the Helix GNOME desktop environment. This month, we introduce you to the trials and tribulations of installing KDE 2.0, the latest and greatest KDE of them all.
What’s the problem, you say? At the time this article was being researched, KDE 2.0 had just entered its Beta 3 cycle and was eight or so weeks from release. Certainly by the time you read this, KDE 2.0 should be soup, and pre-compiled binaries and RPMs should be ready to install on your system. In addition, the various Linux distro companies may even be ready to incorporate it into their distributions.
In any case, at the time of this writing, there were no precompiled binaries to be found of Beta 3 (a.k.a KDE 1.92). The only stuff available was source code. So, if you are a perfectly sane person, you’ll probably want to go straight to your favorite Linux distribution’s support Web site or ftp.kde.org, right this minute, and look for the appropriate KDE 2.0 binaries.
Of course, if you’re the daring type and feel that you haven’t experienced that warm and cuddly Open Source Software experience unless you’ve spent several hours compiling a GUI environment yourself, or if you want to fully appreciate the kinds of nutty things those Krazy software developers have to put up with, then by all means, read on.
Getting The Source Code: CVS and CVSup
Writing a column like this one is always an adventure. In order to present you with the latest, greatest and coolest stuff, we have to put ourselves out there on the bleeding edge and risk life and limb for you, our readers.
You might be asking yourself, “What is this lunatic talking about?” Well, right now as you read this, the source code for KDE 2.0 is probably sitting there at ftp.kde.org just patiently waiting for you to download it. But, since the sources were not available via FTP at the time of this writing, we had to get it the hard way — via CVS and CVSup.
What are CVS and CVSup you ask? CVS stands for the Code Versioning System, which is a way for Open Source Software developers to collaborate on programming projects and exchange code with each other. It’s similar to FTP except that the server keeps track of versioning changes on each file uploaded to it, so that whenever program developers download new code from the CVS and CVSUP servers, they only download the stuff that has actually changed — and not the entire codebase. You can interact with the server via a CVS or CVSup client, which will allow you to download the software that you need to directories that you specify. CVS provides a command-line interface, while CVSup uses a much friendlier GUI.
While retrieving source code from CVS and CVSUP servers is probably not the easiest way of obtaining the code, it’s still the best way to ensure that you’re getting the latest and greatest source (that bleeding edge stuff we were talking about before). Usually, you can assume that the developers who upload have tested their code and that it should actually work. Unfortunately, in our case, it took several days of trying before we found a KDE 2.0 code snapshot that would actually compile (hundreds of changes were occurring to the codebase during the writing of this article, but that’s another story).
Log into your Linux machine as root. Create a file in your /root directory called .CVSRC with the following lines in it:
cvs -z4 -q
diff -u3 -p
Don’t ask me what this means. They are parameters that affect the way the CVS client interacts with the servers. Unless they are set specifically that way, they won’t work.
Chances are that you’ve already got the command-line CVS client on your system. Command-line clients are icky, but fortunately for you, one of the really nice developers at the KDE project, Cristian Tibirna (tibirina@kde. org), developed a great script that automatically downloads the entire KDE 2.0 codebase and its required files. It can be downloaded from the Linux Magazine Web site at http://www.linux-mag.com/downloads/. Called upd, the script is written in the Python scripting language. You’ll want to make sure Python is installed on your system, and you’ll want to put this script in a subdirectory of a disk volume with lots of space on it (preferably in a subdirectory of your home directory called /kde or kde2).
Before you execute the upd script, you’ll want to execute the following command from a terminal window while you are in the /kde or /kde2 directory you just created:
What this command does is set a system variable called CVSROOT that points to the central CVS server at kde. org. Alternatively, you can point this at a mirror if you find that you can’t log in with the CVS command-line utility or if the upd script bombs. The CVS mirrors are located at:
Once you’ve set the CVSROOT variable, be sure to leave the terminal window open. If you close the window that shell session dies, and you’ll have to run that export command again for the CVS client to recognize it.
Okay! Ready to run that script? Not so fast. If you run it now, you’ll download the latest “head code” from the CVS server. That’s not release code. You want the latest bleeding edge stuff? Well, then never mind. Go ahead, and good luck.
Should you want to pull down the stuff tagged as KDE 2.0 release code, you’ll want to modify the line in the upd script that reads:
and change it to:
use cvscmd =
Note: We’re not sure that they’re actually going to tag it as KDE_2_00 (it could be called KDE_2), but following their existing conventions, it will probably work given that beta 2 was called KDE_ 1_90 and beta 3 was called KDE_ 1_92.
When you’re ready, run ./upd from the (still) open terminal window. The script will create the following directories on your system and download all the related KDE source files into them:
Alternatively, instead of using CVS, you can use CVSUP, which is a nice GUI program that allows you to pick and choose what packages you want to bring down (including ancillary ones not part of the base distribution). You can read about how to do that at http://www.kde.org/cvsup.html, KDE’s fine CVSup page.
Compiling the QT Library
OK, you’ve got the files. Now the fun part comes. The first thing you’ll want to do is compile the QT 2.2.0 library. It’s the prerequisite for everything.
QT is located in the /qt-copy subdirectory of whatever directory all your source code is in. You’ll want to read the README and README-qt-copy files in that directory. They have detailed instructions on how to install it and compile Qt. Suffice it to say, they ask you to do the following:
a) Modify your shell’s .profile or .bash_profile to set and export an environmental variable called QTDIR that points to where your QT 2.2.0 source code (and libraries once they’re compiled) resides. This is extremely important. QT won’t compile without it. All the .configure scripts for all the resulting modules will fail if it points to any other QT libraries on your system.
|Customize This: KDE 2.0 is infinitely customizable and even allows you to use themes designed for GNOME.|
b) If you downloaded the source from CVS, run ‘make -f Makefile.cvs’ from a terminal window after you’ve set the QTDIR variable.
c) run ./configure -sm -gif
d) run make to compile the QT library.
If you screw up any of these steps and QT fails to compile, simply type make clean to clean out the workfiles. Then, retrace your steps. A successful compile will create a fat libqt. so.x.x.x binary (which will vary in size from 6 MB and upwards, depending on the particular distribution that you are running) and several links to that binary in /qt-copy/lib.
To be absolutely paranoid-sure that the compiler knows to use the correct QT library, you might want to run the two following commands in your terminal session:
These commands will force the g++ compiler to look in these directories for QT 2.2.0.
If you downloaded the release sources from the FTP site, you will need to create a symbolic link in each and every one of the package subdirectories (you will have to do this quite a few times!) to /kde-common/admin by running the command:
ln -s ../kde-common/admin
CVS users will need to issue the following command:
Finally, to compile each module, you’ll have to issue these commands:
As in the QT installation, if the compile bombs for any reason, for any of the package directories, you can run makeclean to undo everything that you did. It will clear out all the work files it made.
But be careful. make install is the command which actually copies the compiled binaries to their installed destination. This is controlled by an environmental variable which is known as $KDEDIR. You will need to set this in your .profile, or in your shell’s startup script in your /root directory, for your current user account.
By default, the .configure script, which sets up the compile process, assumes $KDEDIR to be /opt/kde, but some distributions may have a value for $KDEDIR already hard-coded into your existing .profile. For example, Red Hat Linux sets this variable by default as /usr, which will cause your existing KDE 1.x binaries (if you have them installed) to be overwritten. So, you might want to change this if you care about preserving your original KDE.
If all of this intimidates the hell out of you, don’t worry. It scared the hell out of us too. Remember our buddy Cristian at KDE? He also wrote a script that compiles and installs everything for you in sequence. The script, called make_kde, can also be found at our Web site at http://www.linux.com/ downloads/.
To run the script, simply issue the following command from your terminal window:
At this point, depending on how fast your computer is, you should either go out for a pizza and a movie, or consider reading a Russian novel. The make_kde script will tell you what package it’s working on at every step of the way. You can keep up with what’s happening with the compile process by running:
on the make.report-XXXXXXX logfile that make_kde produces in your source directory.
|IE 5.0 for Linux? The new Konqueror browser built into KDE 2.0 makes even the Microsoft home page look good.|
Finally, you may want to consider installing the OpenSSH Secure Socket Layer (SSL) 3.0 libraries on your system. These can be obtained as binaries, precompiled for your Linux distribution, or you can get them from www.openssl.org. What for, you ask? KDE 2.0 and the Konqueror Web browser now support OpenSSL’s SSL crypto libraries. So, you can now connect to secure Web sites and safely engage in Web shopping when using Konqueror or any KDE 2.0 software which uses the Konqueror Web browsing engine. With the release of KDE 2.0, Netscape is no longer the only game in town for secure Web access on Linux!
Making it All Work
If you’ve actually gotten this far without screwing up or having your source code blow up in your face, we salute you. To run KDE 2.0, you’ll want to create an .xinitrc file in your home directory that contains just the single line:
Note: startkde should be launched from whatever directory $KDEDIR is defined as in your profile. Simply log out, log in and re-launch X using startx. If you get a bitmap with Konqi the Dragon on it, congratulations! You’ve successfully compiled and installed KDE 2.0 from source code. Now go get a life! But of course, if you really had a life, a date, a clue, or a pet that needed your attention, you would have been smart enough to download the binaries anyway. You could also make your favorite distro company happy by purchasing the latest .1 revision of the week and installing it off of CD.
For more information on the subject of .xinitrc files, what they do and how to deal with graphical login programs with your KDE installation, check out Lou Grinzo’s January 2000 On The Desktop column at: http://www.linux-mag.com/2000-01/desktop_01.html. See you next month.
Jason Perlow is a freelance writer and systems integrator. He can be reached at email@example.com.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62