RedHat RPMs for KDE 2.2.1

Benjamin Reed wrote in to tell us that he has helped out RedHat's KDE users and put together KDE 2.2.1 RPMs for RedHat 7.0 and 7.1. "Since I got such a great response for my "unofficial" RPMs last time, I thought I'd do it again. After what seems like years of building, I've got everything together." The packages are available via http or ftp.
If you can mirror these packages, please let him know. (He adds: "Coming soon: RedHat 6.2 packages -- who needs a life? =)."

Comments

by Benjamin Reed (not verified)

Although the symlink is fixed now for /usr/share/config/kdm, if you've changed your kdm settings at all from what was in the default RPMs (like changed the background color or logo or whatever), the directory will be renamed kdm.rpmsave and the symlink will replace it, but will not contain your "saved" files, so kdm *still* won't start.

I don't have the time to do this build tonight, it's already 3:30am for me, but I'll see if I can fix the rpms (or check for fixed ones in rawhide) and get them put together. Other than that, I'm running the 7.1 rpms on my desktop and it's looking pretty smooth.

by N Becker (not verified)

What is t"he symlink is fixed now for /usr/share/config/kdm"? I just built all from SRPMS, now kdm won't start. I see something changed in /usr/share/config/kdm setup, but what is the correct symlink?

by John Floyd (not verified)

Kdm still causes some trouble on my rh7.1 - after making sure that the kdmrc is ok etc.

kdm_greet is trying to call Xinerama functions which are not in my libs. I am running XFree86-4.0.3. There is a static libXinerama.a. Is this linked (no pun) to the actual Xserver being run (i760)? So of course gdm fails.

Regards
John

by Milan Svoboda (not verified)

It's perfect. I haven't reinstall my linux box :-)

by Asif Ali Rizwaan (not verified)

I would like to discuss a very simple way to improve and accelerate kde and
koffice development by breaking big packages to smaller ones. So, the objectives are:

1. Ease KDE package download and Installation.
2. Respecting Users' need and Avoiding unwanted package installation
3. Freeing up the clogged ftp servers :)
4. Easy upgrade of specific packages using KDE-Installer or manually
5. Easy Access to sources and More bug fixes by users and new kde developers.
6. Overall satisfied KDE user

To-do: break every big source package to about 1-2 MB maximum size (depending on the sources) but not more than 3 MB. The Kdebase, Kdelibs, Kdegames and other packages are of huge sizes :( kdebase=10MB, kdelibs=5+MB, Kdegames=10+MB and so on. I would suggest that these huge packages be broken into smaller bits, like:
------------------------
kdebase.core.tar.bz2
kdebase.konqueror.tar.bz2
kdebase.kicker.tar.bz2
kdebase.kcontrol.tar.bz2
kdebase.kate.tar.bz2
kdebase.kpersonalizer.tar.bz2
kdebase.ktip.tar.bz2
------------------------

likewise kdegames can be parted into many smaller packages:
------------------------
kdegames.kpat.tar.bz2
kdegames.sokoban.tar.bz2
kdegames.kwin4.tar.bz2
kdegames.kmines.tar.bz2
------------------------

I'm not asking to change the default way of distributing the sources and binary packages but asking for one more folder in the ftp.kde.org and its mirror which contains a folder 'separated' or 'Distributed' or whatever you may like, which will contain the split-upped kde packages.

1. Ease Download and (binary) Installation: no big deal, rpm, tar.bz2 and tar.gz or debs, will be quite smaller so it will reduce the download time required, you would appreciate this if you have a modem dial-up connection.

2. Avoiding unwanted packages: a typical kde user may not like to have all the package kde provides, take me for example, I really love to have the following games in kdegames package:

a. Patience
b. Kmines
c. Sirtet
d. Jezzball

and I do not want to have other games of the default kdegames package. I have no other option to discard those games from my installation (but to install and delete). if kdegames has a distributed smaller packages like:

i. kdegames.kpat.tar.bz2
ii. kdegames.kmines.tar.bz2
iii. kdegames.sirtet.tar.bz2
iv. kdegames.kjezz.tar.bz2

in this way I can get what I really need. And due to this huge size of kdegames new games cannot be included into the package like knights a nice chess frontend (http://knights.sourceforge.net) which is around 1MB of size. It could be easily become a package of kdegames as:

kdegames.knights.tar.bz2

In the Koffice I would love to have (download and install) only two Kword and Kspread, as like many kde users don't have to use other koffice apps even rarely. It would be nice to see:

i. koffice.kword.tar.bz2
ii. koffice.kspread.tar.bz2
iii. koffice.kpresenter.tar.bz2
iv. koffice.krayon.tar.bz2 (etc.)

3. Freeing up clogged ftp servers: As the packages become smaller (around 1-3 MB), the download time reduces considerably and hence ftp servers become unclogged and will be accessible for more people.

4. Easy Upgrade of Specific KDE apps using KDE-Installer or manually: most kde users just wish for individual konqueror, kmail, and other apps updates, but they could not do so at present. As I am happy for KDE 3.0's inclusion of kde-installer, but I am afraid it will also try to download the huge kde packages again making itself rather useless, except installing packages in proper sequence. The Kde-Installer will be benefitted with this type of distributed kde packages, allowing more flexibility and options to choose from. KDE-Installer can allow individual package upgrades like konqueror (satisfying the dependencies) or other apps. Users can also download their preferred apps for upgrading.

5. Easy Access to Source and More Bug Fixes: kde users and new kde developers are discouraged by the huge source sizes to download 10MB kdebase source to just to tweak a bit here or there. I was discouraged and unhappily forced to download 10MB kdebase.tar.bz2, just to check out and modify the kicker sources or to get (31k) cursor_large.bdf sources from kcontrol/input :( with which I created the white mouse cursor for KDE/X.
Not just tweaks, the bugs can be located and fixed easily as it get easy to check out the sources by new and experienced kde developers alike with the new 'distributed kde packages'.

6. Overall Satisfied KDE users: these things will definitely satisfy a kde user:

a. Reduced time on downloading source/binary kde packages
b. Easy, fast Accessible ftp download
c. Individual package upgrade
d. Easy to access source code
e. Fully (almost) customized kde
f. Easy installation with kde-installer
g. Alpha, Beta, RC1 etc version can be accessible to user (due to small package sizes)

I know that there are other factors affecting the above points like bandwidth, knowhow etc., I believe that the 'Distributed KDE Packages' will accelerate and improve kde development. And I would appreciate if the KDE Team kindly allow these distributed packages along with the standard (or current) packages. Thanks for reading up to this point ;)

by Michael Häckel (not verified)

Well, if you get the sources via cvs instead of ftp you have at least all the possibilities you are asking for, or even more.
If you are interested in kdebase/kcontrol/input, just type "cvs co kdebase/kcontrol/input" for example.
Or if you are just interested in kword, type:
cvs co -l koffice
cvs co koffice/lib
cvs co koffice/kword

How distributions organize their RPMs, that is their job. Some distributors do it already the way you want to have it.

Conectiva and Debian for example.

As well as Caldera. So there are three already.

by Asif Ali Rizwaan (not verified)

>How distributions organize their RPMs, that is their job

And other such as RH, Mandrake, SuSE etc., organize every package ditto to kde's package.

Seems like a great idea for source distribution. But as always... Open Source is like that having few people willing to do stuff or always suggesting a difficult way. I support fully your suggestion. KDE is huge and compilation time is precious. There is 40% of stuff I don't use in KDE which I wished could be automatically out.

But if no ones really accept your suggestion and put in practice, you can go for Conectiva Linux. (www.conectiva.com) - they do that thing for all packages to reduce installation size. RPMS are more tolerable than RedHat's or MDK's. I personally recommend giving up any distro and going for Conectiva. They also have apt-get for RPM etc...

But as Slackware being the best distribution around yet, it's hard cause few people are willing to do even Slackware packages. Some even tell that Slackware has not got a package manager. They really don't know what they're talking about.

I totally agree.

When I compile a new KDE on my laptop (333MHz K6-2 w/ 64MB RAM)
it takes hours and hours. I'm talking, 12+ hours or more.
At least, it seems like it was that long. It has been a while
since I've done it--primarily because I just don't have time
between work and school. Most of the stuff that gets compiled
I don't even use.

I can't even imagine how long it would take on my p200 w/ 128MB RAM.
I doubt the extra RAM would really make a huge difference, but I'm
sure the much slower CPU would.

by Reality Check (not verified)

Yes. Good that I you think like that too. Coz certain package maintainers don't like to hear such thing at all...

I have a 400Mhz Celeron B (128 L2)- Celeron is not a top line processor but its math-processor is better than even Pentium in some cases. 163MB of RAM, and a very fast Fujitsu 8GB Disk.

KDE 2.x takes up to 15 hours compiling code, without 'install'.

Even if you have a 1GHz Processor with 512 MB RAM, you will have also to spend at least 2 1/2 hours waiting for compilation be done.

by Benjamin Reed (not verified)

I would love for it to be broken up. The worst part about working on creating packages, regardless of the distro you're talking about, is you get through the entire build before you find out if something goes wrong. So I didn't just build kdebase once, for an hour. I built it 5 times, as little things broke or fixed themselves.

With smaller packages, that debug time will drop dramatically. It's a great idea, maybe it's worth putting together something that works in conjunction with the CVS tree and builds micro-packages.

by Asif Ali Rizwaan (not verified)

Dear Ben,

Thank you, thank you very much for creating KDE 2.2.x packages for RedHat 7.x, I appreciate your work very much and I understand how boring and troublesome creating RPMS from a source especially these KDE ones. Thanks again for your contribution to the User Community.

Yours thankfull :)
Rizwaan.

by jacques fuchs (not verified)

download kde

I need Kde base packages in a splited bunzip files. how can i downlaod this. where can i get this package.

by bondowine (not verified)

RedCarpet!!!!!!!

by Matti Palaste (not verified)

Yeah, I don't like gnome but KDE definitely needs tool like redcarpet.

Ok, maybe this qualifies as a "stupid question," but I bet a few other people are wondering as well...

Is there a certain order to install the RH 7.1 RPMS that will help all the dependency problems? If I just try to do *.rpm for all the packages, I get a hoard of dependency issues (with a stock RH 7.1 install). If I installed them in a certain order would it help this, as it seems like certain new packages depend of certain other new packages...

I don't want to do a --force and risk really screwing up my system.

Thanks,

Jeff

by Benjamin Reed (not verified)

Any dependency for my RedHat packages is either in the directory on the FTP/HTTP site, or is available straight from your RedHat CDs or RedHat update. If there's something missing, you should be able to use RedCarpet or autorpm or apt for RPM or any of the other RPM tools (or FTP =) to grab them from RedHat.

You shouldn't need a --force, that I'm aware of. I installed on a stock machine and it worked out OK, after downloading some things that weren't automatically installed by a workstation install.

Hi Ben,

I just replied to another post with this same issue, but your
message here begs another question.

What are the "some things" that you had to download to make
this install happy? And where can I get them.

I've just tried to get the RedCarpet package that you referred
to and it just dies on my system (RH7.1,AMD1.2,512MB). Of course
maybe I picked the wrong package from the 29 that rpmfind.net
lists. I tried red-carpet-1.1.2-ximian.1.i386.rpm. Now I'm
downloading autorpm-1.9.9-2.i386.rpm to give that a whirl.

Thanks for the help,

Mark Aubin

You don't need Red Carpet, but you can use it to install automatically sort out the dependencies.

But what should I do if I have kde2.0 on my RedHat 7.0?
Thanks.

by James Richard Tyrer (not verified)

Yes this is a stupid question.

Reason: are you really talking about *installing* KDE 2.2.1 or are you talking about *Upgrading*?

There is an order for installing:

Qt
Arts
Kdelibs
Kdelibs-sound
Kdebase
Other stuff

But, there is no order for Upgrading!!!!!

In fact, you need to install everything with one command or use Kpackage.

JRT

by Eduardo Sanchez (not verified)

Thank you Benjamin ! This is what I was looking for !
Thank you very much!

by Me (not verified)

I hope I don't sound stupid, but where do you start? I see a directory full of rpm's, but none that obviously says that it is the first to download, or which other ones to download to get things started.

-- IV

by Carbon (not verified)

All this information is available on kde.org, but I'll put it here for other's convienence:
You need to install KDE packages in this order:

kdelibs
kdebase
(else)

After kdelibs and kdebase (in that order), it doesnt matter what other packages you install, nor in what order you install them. If you want to upgrade QT, such as using qt-copy or just upgrading to the latest TT QT, get the latest in the 2.x series, and install/upgrade QT before you install kdelibs.

by J Blazevic (not verified)

I hope that somebody will release FreeBSD packages, I tried texstar's objprelink RPMs and although the release is just 0.0.1 it is really a vast improvement over 2.2 especially in stability department. Konqi is so bloody good!

by Krame (not verified)

I wasn't able to run previous KDE2.2 packages on my AMD K6-2 ( i585 ), so I'would like to ask if someone with K6 checked those new packages. I'm trying to avoid downloading all packages ( with my low-bandwidth connection ... ) only to see that they are not working.

by Carbon (not verified)

I can't imagine how your processor could prevent KDE binaries from running, as long as it's x86 (which the K6-2 is, along with every other Cyrix, Intel, and AMD processor). More likely, it's the way your distribution's software is set up.

by Danny (not verified)

well...ofcourse they will not run if compiled with compiler option -march=i686 (package name *.i686.rpm). But they will run faster on k6-2 if you use -march=i586 -mcpu=i686 (package name *.i586.rpm). Best ofcourse is to use -march=k6 (*.k6.rpm). Although I hear gcc3.0 is awfull in this respect, but then, kde should still be compiled with 2.95.....or 2.96 if you do not feel bad about this non-release.

All quite compilicated.

by Danny (not verified)

well...ofcourse they will not run if compiled with compiler option -march=i686 (package name *.i686.rpm). But they will run faster on k6-2 if you use -march=i586 -mcpu=i686 (package name *.i586.rpm). Best ofcourse is to use -march=k6 (*.k6.rpm). Although I hear gcc3.0 is awfull in this respect, but then, kde should still be compiled with 2.95.....or 2.96 if you do not feel bad about this non-release.

All quite compilicated.

by Carbon (not verified)

Well, RPMs compiled using special processor only optimizations are usually named differently. I.e kdelibs-2.2.1.i686.rpm or somesuch

Plus, I haven't heard of any distro putting out processor optimizied files except for Mandrake.

by Krame (not verified)

All rpms was named *.i386.rpm but all executables refused to run showing message: Illegal instruction.

by Carbon (not verified)

What distribution, QT version, and KDE version are you running?

by Benjamin Reed (not verified)

Ergh. I guess the kde configure is doing sse or something goofy regardless of what CFLAGS are given. Sorry, but it'll probably take a rebuild then...

by Danny (not verified)

>Ergh. I guess the kde configure is doing sse or something goofy regardless of what
>CFLAGS are given. Sorry, but it'll probably take a rebuild then...

Maybe its kde, but not neccesarily; gcc 2.96 (which RH and Mandrake use) is severely broken in some respects. I noticed that the mandrake src rpms have a few extra lines setting the compiler march and mcpu options (have a look at one of mdks spec files, do not have them here at work).

bye
danny

by Benjamin Reed (not verified)

The FTP server is going a bit wiggy, but it looks like the RPMs have made it to kde.org's FTP site at ftp://ftp.kde.org/pub/kde/stable/2.2.1/RedHat-unofficial/, so feel free to grab them there instead. ;)

by Rob Knop (not verified)

OK, I'm sure that CUPS is much better than LPRng. On the other hand, I had LPRng configured and working with my two printers (old Canon BJ200ex on parallel, Epson 860 on USB).

Does kdelibs really require cups? The RPM is claiming that it needs CUPS in order to be installed, and CUPS won't let itself be installed unless I remove LPRng.

So I remove LPRng and install CUPS. However, as best I can tell, your CUPS RPM here doesn't support USB printers. Is this correct?

I'm one who uses Gnome most of the time... I'd love to try out KE 2.2.1, but ideally I'd like to do it with a minimum of pain. If I can get my printers working easily with CUPS, then great, otherwise, I'll wait for something which integrates better with RedHat 7.1.

-Rob

by Benjamin Reed (not verified)

I think you should be able to --nodeps them and skip cups, but I can't guarantee it will work. I just tried removing cups and seeing if the print manager still comes up (and it does), but I don't have a printer here at home to test with. =)

If you really want to be sure, you can grab the .src.rpm and remove the cups references from the spec file and rebuild, but it looks like it should still work.

by Thorsten Schnebeck (not verified)

Try a stable release of gimpprint for cups

http://gimp-print.sourceforge.net

If your driver supports USB then CUPS/KDE support it, too

Bye

Thorsten

by Albert Schueller (not verified)

Installing rpms built by people you don't know is one of the biggest security threats for linux users. You should only install rpms from trusted sources, e.g. ftp.kde.org. If Mr. Reed really wants to package KDE, he should convince the maintainers of ftp.kde.org to post them. There is safety in numbers, lots of people using the rpms means lots of people to figure out if they are trojan horses. I have very little doubt that Mr. Reed is an honest volunteer of his time, but this issue should be at the forefront of anyone's mind as s/he downloads and installs rpms. I also have very little doubt that there are rpms out there, even in trusted locations, that have trojans inside them.

by Mark (not verified)

i have no idea who the hell this guy is either, but what i've learned from reports of others is that his redhat RPM's actually work on a 7.1 system. (go ahead, try the official RPM's from redhat before coming crawling back to these RPM's). from the url on the site, it looks like he might be an employee of opennms (appears to be another free software company)

there's obviously lots of people using these RPM's as ben mentioned his ftp server was getting hammered. in a nutshell, this is a trusted source.

by Ranger Rick (not verified)

Still doesn't mean I'm a trusted source, but I thank you for the vote of confidence. =)

by Anonymous Coward (not verified)

Who IS Ranger Rick?

by William Brainard (not verified)

Benjamin Reed was a worker for Anheiser Busch in 1892 in Jacksonville, Florida.
He killed a white worker for A.B. in an altercation on the 4th of July, gave himself up to the authorities, and was placed in the city jail. Word spread that there might be a lynching, so hundreds of armed blacks surrounded the jail and prevented any whites other than the authorities from passing. The state militia was called in and a gatling gun was placed in front of the jail. For a week troops maintained order until things calmed down. Later Reed was tried and convicted of manslaughter, served less than 5 years, returned to Jacksonville, got a job, and lived out the rest of his life in the city without incident.

by Ranger Rick (a.... (not verified)

Heh, wrong Benjamin Reed. :)

by W. Craig Trader (not verified)

Well, Ben Reed is personally known to me -- he's the head RPM guru for OpenNMS, and in general a really responsible guy. I'd install his binaries without worrying. Of course, that begs the question -- who am I? You can look me up at http://unicornsrest.org/craig/ ... or just do a Google search for me and see what you turn up.

If you're still concerned, you can always download the source RPMs, check the spec files and build them yourself -- I do that for a lot of packages.

by Biswapesh (not verified)

Hi Ben

Thanks for the RPMs - I spent hours doing rpm --rebuild on Bero's SRPMS, unfortunately, too many dependencies and takes too much time.

Question: Are the RPMs objprelinked ? Apparantly, it makes a big difference to startup speeds (I have objprelink installed though I guess that wouldn't make much difference).

- Biswa.

by Anonymous Coward (not verified)

I have tried the rpms, and am stalled at installing kdelibs. I have resolved all buy libxstl and libxml2, of which I don't seem to find RPMs from RedHat. Would anyone know where I can find the appropriate RPMs for the above two dependancies? Thanks in advance