KDE 3.1 Release Slips to Next Month, KDE 3.1RC5 Out

Sunday, 8 December 2002 | Dre

The much-anticipated release of KDE 3.1, originally scheduled for this week, has been delayed, most likely until early next month. On the positive side, the delay could not have been for a better reason. Dirk Mueller, the KDE 3.1 Release Coordinator, explained that the delay was caused by a security audit of the 3.1 CVS tree. The audit was prompted by the identification of a class of vulnerabilities by FozZy from the "Hackademy Audit Project" (thanks to FozZy and all others who help identify security issues in KDE, and a big thanks to Dirk Mueller, Waldo Bastian, George Staikos, Lubos Lunak and the others who are leading or helping in the current security audit). After discussing the issues with the packaging engineers and KDE developers, and in light of the upcoming year-end Holidays, the decision was virtually unanimous to wait until early January for the official 3.1 release.

While the decision was a difficult one, and is sure to disappoint quite some people, hats off to the KDE Project for making the right decision and treating security with the utmost importance that is warranted. The security fixes will be backported to KDE 2.2.2.

In the meantime, what was to have been KDE 3.1 (with some, but obviously not all, of the security audit completed) has been re-tagged as KDE 3.1 RC5 and is now available for testing. The KDE Project hopes that with this release more bugs will be found and reported by the community so they can be fixed while the security audit continues. Stay tuned.

Comments:

That's great... - Rizwaan - 2002-12-07

Really that is the most appreciable gesture for the KDE Team... Giving Priority to security :) Thanks I can wait a month or two for a stable, secure KDE...

Online survey shows that the decision is correct - Anonymous - 2002-12-07

"Should KDE 3.1 wait for security fixes before release?": <a href="http://pclinuxonline.com/modules.php?name=Surveys&op=results&pollID=136&mode=&order=&thold=">pclinuxonline poll</a>

Re: Online survey shows that the decision is correct - Sylvester - 2002-12-07

Okay, I too think that KDE should wait indeed till all severe bugs are fixed, before releasing a final version. But I think bugs would be found much faster if RPMs were made for the release candidates. In the thread about KDE 3.1rc2 on this site, on the question if RPM's were made available, someone said: "no, because kde 3.1 final is right around the corner.. too much work. this is meant for people willing to test anyways, and that means ppl who compile from src" Two times wrong: this was posted on november the 5th, so 'around the corner' was a little to optimistic, and I am willing to use a release candidate and report bugs, but I really don't have the time to compile the source myself.

Re: Online survey shows that the decision is correct - Anonymous - 2002-12-07

The interesting period is the one to the next release, here RC3, not the final one. KDE 3.1 RC2 was released on November 4th, 2002. KDE 3.1 RC3 was released on November 11th, 2002.

Re: Online survey shows that the decision is correct - a.c. - 2002-12-08

that was planned to be that way due to SVG

Re: RPMs - R2-D2 - 2002-12-08

"Okay, I too think that KDE should wait indeed till all severe bugs are fixed, before releasing a final version. But I think bugs would be found much faster if RPMs were made for the release candidates." I have to agree with this. I tried compiling KDE from source once, and I'll *never* try that again. If RPMs were put out, I'd download them, install them, and it'd take up about four hours of my time--mostly in the downloading, which I can automate and spend elsewhere. But if I try to compile on my 450MHz Celeron/96M RAM (which can handle Red Hat 8.0 with KDE 3.0.5 just fine--I'd never even *think* about Windows eXPloit on this box), I'd be waiting for it to finish compiling when the next release came out. Testing RPMs--whether they came from KDE or from Red Hat--would definitely be a major convenience (hint, hint).

Re: RPMs - James Richard Tyrer - 2002-12-09

Actually, it only takes about 2 days to build on my 400 MHz K6 III. You can 'nice' it and it won't interfere with doing other things if you install it in: "/usr/kde3/" and then change your KDEDIR and PATH after the whole thing is installed. It is a real pain the first time you build it, and from time to time I do screw up something on my system and it won't build again. But, if you don't install other things from source, you won't have that problem.

Re: RPMs - Xanadu - 2002-12-12

>Actually, it only takes about 2 days to build on my 400 MHz K6 III. I think you're missing the point. "about 2 DAYS" *DAYS* The idea is about building RPM's for those that use that package manager (I use Gentoo, so...). An RPM person (and I guess a DEB too) could install it in about 5 minutes (minus DL time, of course). That is what the dissucion is about. Again, I'm on Gentoo. I EXPECT things to take a while. Sometimes even a couple days to finish. But an RPM user that *WANTS* to help the KDE project by helping debug it, will want RPMs (or DEBs, of course).

Re: Online survey shows that the decision is correct - Jad - 2002-12-08

Yes, it would be a Good Thing to, at least, always have a final RC release with binaries and all - in other words to only call stable release what we usually call aq x.x.1 release. J.A.

Re: Online survey shows that the decision is correct - jaycee - 2002-12-09

"Okay, I too think that KDE should wait indeed till all severe bugs are fixed, before releasing a final version. But I think bugs would be found much faster if RPMs were made for the release candidates" But surely these sort of bugs, security bugs, are (as has just been shown by them being found by an audit, but not by actual use) /not/ likely to be found faster if binaries are available? Sure, bugs *in general* will be, but these? That's not to say, of course, that security bugs aren't found if the source isn't available - IIS is proof of that! -- jc

Re: Online survey shows that the decision is correct - Inorog - 2002-12-10

If KDE-3.1 had to be delayed because of _security_ bugs, the RCs should be _immediately_ deleted by the users that decided to compile them when they went out. So, what makes RC RPMs necessary in all this?

Re: Online survey shows that the decision is correct - Inorog - 2002-12-10

Re: Online survey shows that the decision is correct - Sylvester - 2002-12-13

In initial message: "The security fixes will be backported to KDE 2.2.2." I conclude from this sentence that these security issues are not new at all, but that people just became aware of it now. So why delaying the release? Almost everyone has these bugs already in his system... Why don't they get the security fixes ready for KDE 3.1.1 or something like that and release KDE 3.1 now?

Re: Online survey shows that the decision is correct - Thorsten Schnebeck - 2002-12-08

Wrong question :-) "Should KDE release 3.1 this year without binary-packages?" To release something with known security issues is out of question! Bye Thorsten

compile failure in kdelibs/kdeui/kedittoolbar.cpp - Anonymous - 2002-12-07

Patch to fix this mistake: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdeui/kxmlguiclient.h.diff?r1=1.40&r2=1.40.2.1

Re: compile failure in kdelibs/kdeui/kedittoolbar. - Damn G... - 2002-12-07

Thank you! I spent hours last night trying to figure out what was the problem. Hope this works.

Re: compile failure in kdelibs/kdeui/kedittoolbar. - Anonymous - 2002-12-07

You can also download today's updated kdelibs source tarball.

Building right now - cbcbcb - 2002-12-07

kdelibs and kdebase are already done. And Konqueror still leaks memory :(

Re: Building right now - anon - 2002-12-07

konqueror working fine here! i have only 128M RAM but it is good quality. it does not leak!

Re: Building right now - cbcbcb - 2002-12-08

There's a script here which still shows gradual increase in memory usage in 3.1rc5: http://bugs.kde.org/show_bug.cgi?id=51061 Perhaps you might like to try this script and see if you can reproduce the leak. You might need to run the script a few times to really see the increase in memory usage.

Re: Building right now - Kirk - 2002-12-08

I have a gig of ram and here is my current memory usage: Mem: 1033592k total, 989508k used, 44084k free, 42556k buffers Swap: 2097136k total, 2360k used, 2094776k free, 671500k cached after this uptime 19:37:25 up 3 days, 1 min, 1 user, load average: 0.00, 0.10, 0.17 I am running currently gaim, xchat and this konq window. Memory leak? I think so.

Re: Building right now - ac - 2002-12-08

This is how Linux works. Nothing to do with KDE.

Re: Building right now - Rayiner Hashem - 2002-12-08

I don't think so. Take a look at the states. You've got 670MB in the page cache, 45MB free, and 40MB in buffers. All that is available memory which is serving as a file cache. So you've got 750+ MB free. That's only about 250MB used, which seems about right. I've been running for few hours now, and I've got 175MB used.

Re: Building right now - JJ - 2002-12-08

I think you are reading the numbers wrong. I'll bet you are only looking at this bit: "Mem: 1033592k total, 989508k used" and then you think all your memory is used up - NOT TRUE! Most of that memory is being used for buffers, cache etc. If a program on your box was to request a 100MB block of memory then there would be no problem satisfying that demand. The reason you see such a high number as "used" is simply becourse Linux will always try to use as much memory as possible for cache and buffers to improve system performance, but as soon as some program needs the RAM, it's imidiately released and handed over to the program. This does not signify a memory leak, it only signifies that you do not know how Linux works. If you want to go hunting for memory leaks, I sugest you take a look at the actual memory usage of a specific application, not of the system as a whole.

Re: Building right now - Leaker - 2002-12-08

Here Konqueror - or some other part of KDE that "can't be removed" (kind of like IE on windows) - leaks badly and swaps like mad. As for RAM, 128 megs is definitely *not* enough. In genera; KDE is as a slow as molasses on my 600MhZ P3 with 128 megs RAM (and nowhere near as snappy as XP on same system).

Re: Building right now - Jesper Juhl - 2002-12-08

> In genera; KDE is as a slow as molasses on my 600MhZ P3 with 128 megs RAM (and nowhere near as snappy as XP on same system). There's lots of stuff you can do to improve performance. For example : 1) When compiling KDE, optimize for your current CPU - for example, don't build for i386 if you have a Pentium. 2) Don't build KDE with debug info (if you want to report bugs, enabeling debug is good though). 3) Turn the eye candy down a bit. Stuff like transparency, antialiasing, animated menus, a huge background image etc all take a chunk out of your performance. 4) Make sure your X configuration is making the best possible use of your graphics card. There are plenty of ways to improve general X performance. 5) Go over your system configuration and make sure you are not running a lot of programs you don't need/use anyway. Many distributions run lots of daemons and other stuff by default that you may not need - disable some of that to free up some CPU cycles and RAM. I'm sure you (or someone else) can come up with other good ideas, but now you have a place to start if you want to improve performance :-)

Re: Building right now - Anonymous - 2002-12-08

6) Use gcc 3.2.x. 7) Use a binutils version which uses combreloc. 8) Use glibc 2.3. 9) Use current XFree version, otherwise delete unnecessary fonts. 10) Compile Qt with --disable-opengl if you don't need it (screensavers, kpovmodeler). This will reduce the number of relocations needing linking at start-up noticeable. 11) Or use "prelink" (not equal to objprelink) to medicate binaries and libraries. 12) Configure kdelibs with --enable-fast-malloc=full

Re: Building right now - Michael Jahn - 2002-12-08

13. User a kernel with preempt, lowlatency, O(1). 14. Compile with -O3 -fomit-frame-pointer -pipe -march=yourcpu (*) 15. Add fam to start on boot (allows KDE to track files quicker) 16. Add your hostname to /etc/hosts (if it's not already there) (*): One could argue about -O3. Some think that -Os is a better choice. I don't really notice a difference between -O2, -O3 and -Os, but it makes a difference on slower cpus. Some of these hints are taken from a discussion on the gentoo mailing list.

excellent ! - thierry - 2002-12-08

nothing to add !

I can think of one more! - Anonymous - 2002-12-11

16) Run kdebugdialog and turn off all debug output.

Re: Building right now - Erik - 2002-12-09

> 14. Compile with -O3 -fomit-frame-pointer -pipe -march=yourcpu (*) And how do you expect that compiling with "-pipe" will improve the performance of KDE? As far as I can tell, it only controls the communication between the various build tools during the build process and has no effect on the contents of the output files. From "info gcc": " `-pipe' Use pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the GNU assembler has no trouble." > 16. Add your hostname to /etc/hosts (if it's not already there) What about all the people who do not get a static PI-addres/hostmane from their ISP but only a dynamic IP-adresses? Should they have anything more than "127.0.0.1 localhost" in that file? How and when does the contents of that file affect the performance of KDE?

Re: Building right now - Michael Jahn - 2002-12-09

> And how do you expect that compiling with "-pipe" will improve the performance of KDE? As far as I can tell, it only controls the communication between the various build tools during the build process and has no effect on the contents of the output files. From "info gcc": I did not specifically say, that -pipe improves perfomance ;-). But again, this is not by me but was on found on a gentoo mailing list/forum: http://forums.gentoo.org/viewtopic.php?t=3209 You can also have a look there for a discussion of the hostname item.

Re: Building right now - Erik - 2002-12-11

> 11) Or use "prelink" (not equal to objprelink) to medicate binaries and > libraries. Prelink is not buildable. It ends with: prelink.c: In function `prelink_set_checksum': prelink.c:819: warning: passing arg 1 of `elf32_xlatetof' from incompatible pointer type prelink.c:819: warning: passing arg 3 of `elf32_xlatetof' makes integer from pointer without a cast prelink.c:819: too many arguments to function `elf32_xlatetof' prelink.c:822: warning: passing arg 1 of `elf32_xlatetom' from incompatible pointer type prelink.c:822: warning: passing arg 3 of `elf32_xlatetom' makes integer from pointer without a cast prelink.c:822: too many arguments to function `elf32_xlatetom' make[2]: *** [prelink.o] Error 1 I have prelink-20021002, libelf-0.8.2, gcc-3.2.1 and glibc-2.3.1.

Re: Building right now - shivaken - 2003-01-18

Try with libelf-0.8.0 . It may be caused with libelf-0.8.2 .

Re: Building right now - Sangohn Christian - 2002-12-10

Can you tell how to achieve these optimisations please? Or point me to the apropriate documentation. I´m running a Dual P3 (Katmai core) with 256Mb memeory and I´ve never checked if the things I compile are optimized for my CPU. TIA

Re: Building right now - Erik - 2002-12-11

> 2) Don't build KDE with debug info (if you want to report bugs, enabeling > debug is good though). My recommendation is to always build kde with --enable-debug=full and then strip the installed binaries and libraries. When you need to report a bug you don't have to rebuild, just reinstall the binary and the libraries it uses. I assume that strip --strip-all will remove all the overhead produced by --enable-debug=full except for debug output (that is seen when running applications from Konsole). > 4) Make sure your X configuration is making the best possible use of your > graphics card. There are plenty of ways to improve general X performance. And what would that be except for decreasing resolution/colors, which I do not want to sacrifice?

Re: Building right now - ac - 2002-12-08

Bzzzt, wrong. I only have a Celeron 350 and it is _fine_ here.

Re: Building right now - kde developer - 2002-12-08

You clearly don't understand what Konqueror is or how it works. It can easily be removed, as can all of its plugins and components. This has been demonstrated time and time again. If you can honestly find a reproducible way to trigger a leak then file a detailed bug report and we will fix it. Valgrind is a great tool for that.

Re: Building right now - cbcbcb - 2002-12-08

I can 100% reproduce a leak in Konqueror. I just use it to browse the web, and slowly but surely its memory usage increases. However, if I run Konqueror in valgrind it is unusably slow, so that's out. Konqueror does leak memory, and KDE developers denying that isn't going to help. :) I have reported two scriptable memory leaks in 3.1rc3 and these seem to have been fixed. However, I think the Konqueror/KDE developers should be putting some serious effort into tracing memory leaks (or switch KDE to use a garbage collection strategy)

Re: Building right now - Tom - 2002-12-08

Can you explain your method of verifying that memory is leaking? I assume (/hope) that you're not just looking at the current total memory usage... Tom

Re: Building right now - cbcbcb - 2002-12-08

The VIRT column provided in top 3.1.1 for the Konqueror process

Re: Building right now - Waldo Bastian - 2002-12-08

It's normal for the process size to grow somewhat with time due to fragmentation of the free memory. However, over time the memory use should stabilize, e.g. under normal workloads, if you have used it for 2 days, it should hardly increase the 3rd day. If that's not the case then there is something wrong indeed, the key is then to identify the site or construct that causes it :-} Cheers, Waldo

Re: Building right now - James Richard Tyrer - 2002-12-10

Is there some valid reason that you don't simply buy another 256 Megs of memory? You are correct that LINUX can NOT run KDE efficently with only 128 Megs of memory? However, it isn't KDE that is slow, it is the system that is slow and the reason is that swaping to disk is slow.

Re: Building right now - More RC's - 2002-12-10

I COMPLETELY AGREE :) Hmmm, wait ... What would I rather spend money on, buying a license of XP or buying more RAM? Gee, let me think now. More RAM makes the whole Linux experience so much better. Just do it, damnit :)

Re: Building right now - oliv - 2002-12-10

please do not troll on linux with such stupid argumentation. Linux without KDE is fast on low memory machines. KDE requires a huge amount of RAM, and this is definetely not the OS fault. Rox is much much faster/lighter than KDE or Gnome and does not require that much. So is XFCE. Linux/FreeBSD/whateverOS is not responsible for the amounts of RAM that both Gnome and KDE require.

Re: Building right now - James Richard Tyrer - 2002-12-10

I did not make a "stupid agrumentation" you misunderstood me. KDE does require 256 Megs of ram to run well. That is NOT the OS's fault. However, it *is* the OS swaping virtual memory to disk that results in KDE being slow. This actually does not effect the speed when running an application. However, when starting an application or switching to a different application, the first thing that happens is a VM disk swap. This is what slows it down. In todays market, 0.75 Geg of memory is not expensive. So, I don't think that the 256 Megs (0.25 Geg) of memory that you need run KDE is a huge amount of RAM.

Re: Building right now - Aaron J. Seigo - 2002-12-11

i suppose the key (and variable) term is "runs well". i have it on a few 64MB systems around here and it runs just fine with recent releases on recent distros (e.g. MDK9 and SuSe8.1). no fancy wallpapers or other memory-consuming items and only 3-4 apps running at a time, but it's snappy enough for daily use ... of course, my primary desktop has 256MB of RAM... =)

Re: Building right now - Dude - 2002-12-18

Hey guys, i've a stupid question. Which version of qt are you using to compile 3.1rc5? I get always errors like this, when compiling kdelibs : uic -nounload -o keygenwizard.h ./keygenwizard.ui uic: relocation error: /root/qt-x11-free-3.1.1/bin/uic: undefined symbol: _ZN7QString9fromAsciiEPKci make[4]: *** [keygenwizard.h] Error 127 make[4]: Leaving directory .../kdelibs-3.1rc5/kio/kssl' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory .../kde-3.1-rc5/src/kdelibs-3.1rc5/kio/kssl' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory .../kde-3.1-rc5/src/kdelibs-3.1rc5/kio' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory .../kde-3.1-rc5/src/kdelibs-3.1rc5' make: *** [all] Error 2 I've dl and compiled qt-x11-free-3.1.1. And by the way, is there anywhere a doku/faq how to compile kde3.1? I searched and searched...but the guys from KDE have obviously forgotten? to put some instructions on the website. And the FAQ's there are only for old versions... Thx, TheDude.

Re: Building right now - Anonymous - 2002-12-18

> uic: relocation error: /root/qt-x11-free-3.1.1/bin/uic: undefined symbol: _ZN7QString9fromAsciiEPKci uic is picking up another Qt library as the one it was linked against. Play with LD_LIBRARY_PATH/ld.so.conf. > And by the way, is there anywhere a doku/faq how to compile kde3.1? http://developer.kde.org/build/compile_cvs.html

Re: Building right now - Dude - 2002-12-19

Thx...hope it'll work.

An uanassailable decision. - guinstar - 2002-12-07

Who can fault this decision except for those who haven't progressed beyond the "Are we there yet?" stage.

Why? - KDE User - 2002-12-07

On the release page it says: Bugs...none Security issues...none So why not release it?

Re: Why? - Anonymous - 2002-12-07

You didn't read the news article? There is a security audit still running which may lead to discovery of exploitable security leaks not fixed in RC5 and fixing potential security flaws in general.

getting the 3.1 branch with cvs(up) - Michael Jahn - 2002-12-07

Hi, I've been using cvsup for a few months now. Until 3.1 was branched, HEAD was always usable, but now that the feature freeze is over, HEAD becomes too unstable. I want to download the (almost) stable 3.1 branch with cvsup. So I set tag=KDE_3_1_BRANCH. But if I cvsup then, I only get a corrupted system: missing Makefile.cvs, almost no qt-copy, no configure, lots of files missing. Does anyone know, what I am doing wrong? Micha

Re: getting the 3.1 branch with cvs(up) - anon - 2002-12-08

you are relying on KDE ... which is wrong. Buy commercial software and you will have less to worry about and have a better life.

Re: getting the 3.1 branch with cvs(up) - KDE User - 2002-12-08

> you are relying on KDE ... which is wrong. absolutely not. there are commercial software where you CAN rely on KDE.

Re: getting the 3.1 branch with cvs(up) - standsolid - 2002-12-08

dear god here come the flames...

Re: getting the 3.1 branch with cvs(up) - Jiffy - 2002-12-08

Looking at: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/qt-copy/ I see qt-copy does not have a KDE_3_1_BRANCH tag. You're not supposed to get a configure file. You're supposed to type make -f Makefile.cvs to create the configure file. I don't know why you aren't getting a Makefile.cvs (kdelibs seems to have it tagged for KDE_3_1_BRANCH). You might want to try "tag=.". I haven't successfully compiled from CVS since KDE 3.1 Beta 2. I have had nothing but trouble compiling KDELIBS with the recent Release Candidates. There is an annoying bug (51112) I want to further investigate and possibly fix, but I can't even compile. My most recent problem is this error: .libs/dcopclient.o: In function `DCOPClient::staticMetaObject()': .libs/dcopclient.o(.text+0x939a): undefined reference to `QMetaObject::new_metaobject(char const*, QMetaObject*, QMetaData const*, int, QMetaData const*, int, QMetaProperty const*, int, QMetaEnum const*, int, bool (*)(QObject*, int, int, QVariant*), QClassInfo const*, int)' .libs/dcopclient.o: In function `DCOPClient::applicationRegistered(QCString const&)': . . . I'm sure I'm just doing something wrong. I did switch from QT 3.1.0 beta 2 to QT 3.1.0 final. Oh well, I think I'll go try the tarballs.

Re: getting the 3.1 branch with cvs(up) - ac - 2002-12-08

maybe you should delete your *.moc files. you may need to delete files generated from *.ui at some point.

Re: getting the 3.1 branch with cvs(up) - Michael Jahn - 2002-12-08

> You're not supposed to get a configure file. You're supposed to type > make -f Makefile.cvs > to create the configure file. I don't know why you aren't getting a Makefile.cvs (kdelibs seems to have it tagged for KDE_3_1_BRANCH). You might want to try "tag=.". Yes, I know. But there _were_ configure files in cvs. I don't know what went wrong the first couple of times I tried. Either it was fixed in CVS or I made some stupid mistake. Nonetheless it works now and that's all that counts. To answer to your problem: I always do a "make clean distclean" in all cvs modules before recompiling everything. This gets rid of old files which could be in the way. Maybe this could help you too. Michael Jahn

Re: getting the 3.1 branch with cvs(up) - rinse - 2002-12-10

About HEAD, well that is now the branch for KDE 3.2, so you can expect that it won't be as stable as it was befor the branching :o) about KDE_3_1_BRANCH, try using a different cvs mirror Rinse

Thank you for putting security first! - Jesper Juhl - 2002-12-08

Shipping a KDE 3.1 release with known security problems would have been bad. Every project should put a huge emphasis on software security, and I'm glad to see the KDE developers postpone the release date in order to fix security issues. That's the right desition to make. A big thank you from me to the KDE developers!

Hmmm not what with 3.1rc5 - J Battles - 2002-12-08

I almost had 3.0.99 built when I saw 3.1rc5 so I started compiling it instead. I hit the following building kdelibs. Wonder if I need to go back and update libxml etc. Course I am using the latest (a bit buggy) version of QT which has caused some pains. Anyone run into this yet? See below from make >make.log while building kdelibs-3.1rc5 <p /> <code>Ed: compile output placed in comment</code>

Re: Hmmm not what with 3.1rc5 - ac - 2002-12-08

Read this: http://dot.kde.org/1039281841/1039286480/

Re: Hmmm not what with 3.1rc5 - J Battles - 2002-12-08

Thanks, I should have looked at the CVS updates before posting. Found the updates. LOL I made the assumption if it was released, it would probably compile.

What a good idea - socialEcologist - 2002-12-08

You are absolutely right to put security first. Let's go and build the most secure and most stable unix desktop kde team.

devices:/ file-system - Alexandros Karypidis - 2002-12-08

Can anyone tell me why it is that whenever I try to mount a CD or floppy as a simple user I get the message "only root can do that"? Mounting these devices works ok from command-line (my fstab is correct)...

Re: devices:/ file-system - Brent Cook - 2002-12-09

I had the same problem. To fix it, I unchecked the 'Show Floppy/CDROM' boxes in Desktop Behavior settings. Then I right-clicked the desktop and created new floppy and cd-rom device icons manually with the Create New... menu. This sounds like a bug; I also noticed that the context menu with the manually created device icons is much bigger (now has eject, etc.) They also don't move when the devices are mounted. Create the icons manually for now. Wierd!

Re: devices:/ file-system - diederik - 2002-12-09

You sure there is the user option in /etc/fstab for you cdrom/burner/floppy devices? e.g. like this: /dev/cdroms/cdrom1 /mnt/burner iso9660 noauto,ro,user 0 0 /dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro,user 0 0

Re: devices:/ file-system - Alexandros Karypidis - 2002-12-12

Yes, my floppy/dvd/cdrw are defined as: /dev/cdrecorder /media/cdrecorder auto ro,noauto,user,exec 0 0 /dev/cdrom /media/cdrom auto ro,noauto,user,exec 0 0 /dev/fd0 /media/floppy auto noauto,user,sync 0 0 where /dev/cdrom --> /dev/scd1 and /dev/cdrecorder --> /dev/scd0 (ide-scsi emulation)

Trouble with Lilo... - Braden MacDonald - 2002-12-08

I just compiled, and am enjoying 3.1 RC 5. Congradulations to the KDE team! I really like the integration of xscreensaver - Now my list of screensavers is huge! However, I have one major problem: in KDM, the lilo entries are not displayed. instead, I get a blank selection box under the restart option. My lilo paths are correct, and I'm using Mandrake 9.0. Any ideas?

xscreensaver?!?!? Yippee - Rimmer - 2002-12-09

I love the xscreensaver stuff in Redhat 8. Can't wait to be able to use it with KDE.

Re: xscreensaver?!?!? Yippee - ac - 2002-12-09

Seriously, what's your point? It has always been in KDE.

Seriously... - Rimmer - 2002-12-09

if can you use xscreensaver modules in KDE it's not f*&#!% clear.

Re: Seriously... - ac - 2002-12-09

Then don't use RedHat. Seriously, what's your point? KDE has had support for xscreensaver for a long time. Since 2000/01/26. http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdeartwork/kscreensaver/

Re: Seriously... - dr_lha - 2002-12-09

You're wrong. KDE has had support for it's own screensavers only - always a stupid "Not Invented Here" thing about KDE I thought. Support for xscreensavers modules is a new and welcome thing.

Re: Seriously... - ac - 2002-12-09

_you're_ wrong. look at the damn link and the CVS logs - always the stupid trolls i thought. *sigh* Revision 1.1 / (download) - annotate - [select for diffs], Wed Jan 26 04:00:48 2000 UTC (2 years, 10 months ago) by jones Branch: MAIN Configuration for xscreensaver hacks

Re: Seriously... - dr_lha - 2002-12-10

My bad. It's still not been in there in an obvious way though.

Re: Seriously... - not me - 2002-12-11

The xscreensaver support has always been spotty. It works on some distros and not on others. I know it hasn't worked on Debian for quite some time. I would have thought KDE didn't support xscreensaver myself if I hadn't already seen the support in some other distros. Hopefully that has been fixed.

I think there is a way but... - Rimmer - 2002-12-09

I can't figure it out. I found a xscreensaver.kss file in /usr/bin. This brings up the xscreensaver configuration utility. Unfortunately, there isn't a xscreensaver.desktop file to be found (I'm running Redhat 8). The xscreensaver.desktop file is needed to make xscreensaver an option in the KDE screensaver dialog (I think). Now searching on Google revealed a number of hits for rpm's with xscreensaver.desktop files. So it appears (am I wrong here) that there is wrapper for xscreensaver that causes KDE to treat it like any other screensaver. It possible that this works in distributions other then Redhat. The question is... where can you get xscreensaver.desktop file. I wonder if this wrapper is no longer being maintained? ac could probably answer these questions if he wasn't so busy being mean.

Problem executing xscreensaver.kss - Rimmer - 2002-12-09

Well I copied one of my .desktop files and tried to make it point to xscreensaver.kss. The xscreensaver entry is now visible in the KDE screensaver dialog. Unfortunately, I've discovered that the program doesn't seem to do anything when called (with xscreensaver.kss). It's strange, because running xscreensaver.kss -test works fine. xscreensaver.kss -setup also works (and the setup buttom in the KDE control panel runs the xscreensaver configuration tool. Any suggestions?

Re: Problem executing xscreensaver.kss - redcane - 2003-01-22

read the /usr/bin/xscreensaver.kss script... You can modify it to run xscreensaver in a way that works (I hope,I'm just looking into it now)... Of course you still need to create that .desktop file

Re: Problem executing xscreensaver.kss - perraw - 2003-01-24

Hi, Just install kdeartwork from kde 3.1 (not earlier) and you should be all set. That is what I did last night on a RH8 machine. He had kde 3.0.x before and upgrading to kde 3.1 solved all problems for him... P

Re: Trouble with Lilo... - Ingo Klöcker - 2002-12-09

Have a look at $KDEDIR/share/config/kdm/kdmrc: # Offer LiLo boot options in shutdown dialog. Default is false UseLilo=false Set it to UseLilo=true if you want Lilo in KDM.

Re: Trouble with Lilo... - ac - 2002-12-09

Can we make it true by default on Linux?

Re: Trouble with Lilo... - Paul Koshevoy - 2002-12-09

I run Linux, and have not had any use for LILO for over a year now. GRUB is the way to go, so all the KDE LILO bindings are useless to me. Perhaps it should not be hard wired to true/false, but rather determined at run time which boot system is used on the box and enable/disable the LILO boot options based on that? Paul.

Re: Trouble with Lilo... - Braden MacDonald - 2002-12-09

I have it set to UseLilo=true, it still shows only an empty selection box.

Re: Trouble with Lilo... - greg - 2002-12-11

I had this problem too, its not a matter of selecting LILO or not, its a matter of your map files not cooperating in /boot/. Try setting them to global readable. Maybe try global writeable. Greg

Compile Issues - Chris Anderson - 2002-12-08

Everytime I try and do a make on kdelibs I get this error: .libs/dcopclient.o: In function `QPtrList<DCOPClientTransaction>::replace(unsigned int, DCOPClientTransaction const *)': .libs/dcopclient.o(.QPtrList<DCOPClientTransaction>::gnu.linkonce.t.replace(unsigned int, DCOPClientTransaction const *)+0x1c): undefined reference to `QGList::replaceAt(unsigned int, void *)' .libs/dcopclient.o: In function `QPtrList<_IceConn>::replace(unsigned int, _IceConn const *)': .libs/dcopclient.o(.QPtrList<_IceConn>::gnu.linkonce.t.replace(unsigned int, _IceConn const *)+0x1c): undefined reference to `QGList::replaceAt(unsigned int, void *)' collect2: ld returned 1 exit status make[3]: *** [libDCOP.la.closure] Error 1 make[3]: Leaving directory `/source/kde/kdelibs-3.1rc5/dcop' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/source/kde/kdelibs-3.1rc5/dcop' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/source/kde/kdelibs-3.1rc5' make: *** [all] Error 2 Anyone have ideas as to how I can fix it?

Re: Compile Issues - Tommi Uimonen - 2002-12-10

Are you using gcc 3.2? I'm not sure if it solves the problem, but I tried with 2.95 and got the same linker error (cvs from 3.12.2002 or so). Tried gcc 3.2, but didn't get qt to compile witb it, so I gave up and apt-getted unofficial kde3.1 and got it working. Tommi

Re: Compile Issues - John - 2002-12-10

"make clean && make" should do it. Looks like you have old objects and the linker is trying to link them with new objects compiled with newer headers.

Re: Compile Issues - Jord Swart - 2003-01-03

Have no solution, but having the same problem. Was wondering if you founf a solution in the mean time.

Re: Compile Issues - Chris Anderson - 2003-01-03

Thanks for the replies, I planned to switch distros so it didn't end up mattering in the end (had free time, installed mandrake to play with it). As for a workaround, I'd try what they mentioned, I had a lot of problems with Redhat's GCC 2.96 (read up on it, understand why now). GCC 3.2 works flawlessly so far

Re: Compile Issues - Jord Swart - 2003-01-03

Got the solution: specify all the qt paths (qt dir, qt lib etc) when doing the configure. If in doubt do a configure --help, you will see the needed options listed. Personally I was using the instructions at women.kde.org, but somehow setting the environment variables wasn't enough. Don't know why (might have to do with my debian installation?). Oh, just in case, make sure you are using a recent version of qt (3.1 and above or qt-copy from cvs). Cheers, Jord

stop making us suffer! - standsolid - 2002-12-09

no!!!! we want a final! I will boycott this release forever! .:starts compiliing:. sorry for rant. i'm impatient.

Suse didn't want it - A Debian user... - 2002-12-09

Hello, the truth is likely that SuSE just didn't want a KDE 3.1 release now, since it doesn't meet their own distribution schedule. I hope this isn't a long-term trend for KDE. Anyway, I am using Karolinga KDE packages for KDE3.1 on Debian, and who cares, if Suse allows to call them final or not. They are secure enough for me now. The long term direction should certainly include security audits for the external interfaces. I welcome that. It's only that keeping back KDE 3.1 doesn't make 3.0 and 2.x very much more secure.... Regards, Kay

Re: Suse didn't want it - Another Debian user - 2002-12-09

Take your stupid theories elsewhere, KDE has a very open development process, and the decision to delay the release was based on general consensus on the KDE mailing lists.

Re: Suse didn't want it - Debian User - 2002-12-09

Well, stupid, maybe they are. But it's no secret how Suse manpower is the one making decisions about KDE releases, is it? I find it strange that at the END of a feature freeze, bug fix cycle, a Suse employee proposes a further delay for a code audit to fix bugs that current stable releases already have... The good is that if they took it too far, they would loose control, yes. Regards, Kay

Re: Suse didn't want it - Waldo Bastian - 2002-12-09

That's because SuSE cares about quality :-) Cheers, Waldo -- bastian@kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian@suse.com

Re: Suse didn't want it - SniggleWitch - 2002-12-09

No. If SuSE cared that much about quality the code audit would (should?) have happened before feature freeze - before any RC at any rate.

Re: Suse didn't want it - Anonymous - 2002-12-09

It was not a SuSE audit, but one by an independent, external group.

Re: Suse didn't want it - Xavian-Anderson Macpherson - 2002-12-18

Maybe SuSE should hire that independent testing group!?!? And if the bug fixes could work on the existing releases of KDE-2.2.2 and KDE-3.0, why wouldn't they work on KDE-3.1 as well? I mean it is like someone else said, if the exiating releases of KDE had the same pre-existing security issues, it would have made no difference to release this one. Becuase it was not as though those prior releases were without any security problems. If they had been, THEY WOULD NOT HAVE NEEDED TO BE FIXED! So please explain all of this again. How is releasing KDE-3.1 now, worse than having all of the benefits it offers, when the security of all the prior releases were NO BETTER than KDE-3.1?!?! Again, IF THE SAME SECURITY ISSUES WERE NOT PRESENT IN THEM, THE FIXES WOULD NOT HAVE BEEN RETROFITTED!!

Re: Suse didn't want it - Debian User - 2002-12-09

Ok, sorry for mixing KDE with Suse issues. But one thing I cannot let go unnoticed. It's not like the KDE 3.0.0 shipped with 8.0 was tested much. I encountered it at work: a) It didn't save settings. b) Suse control modules failed to load in kcontrol. I really hope, Suse gets KDE 3.1 right. But would it hurt much for that, if KDE 3.1 was ready some weeks before Suse 9.0 ? Yours, Kay

Re: Suse didn't want it - Anonymous - 2002-12-09

> But it's no secret how Suse manpower is the one making decisions about KDE releases, is it? It's written SuSE. And if it's no secret how it comes that nobody knows that? Perhaps because it's untrue? > I find it strange that at the END of a feature freeze, bug fix cycle, a Suse employee proposes a further delay for a code audit to fix bugs that current stable releases already have. You mean Dirk Müller? I don't think that he is employed by SuSE. If you would have picked the previous or the next release coordinator but with this one you fail.

Re: Suse didn't want it - joergen ramskov - 2002-12-09

So you want them to release a version with known security issues?! Is that a responsible thing to do? What they have decided is obviously the right thing to do no matter who proposed it. Until you provide some solid evidence, your talk about Suse controlling the KDE project is pure FUD, so bring on the evidence or keep quiet. Furthermore, it's not like you can't get KDE 3.1 - just grab it - the RC5 version (which would have otherwise been the 3.1 final) is available, so what is your problem exactly?

Re: Suse didn't want it - Ruediger Knoerig - 2002-12-09

Typical for a debian user - paranoid & hungry for pre-final releases. Not very surprising since debian distro's are known for being in a permanent pre-release state (something for people which prefer working on the system over working with the system). IMHO you did a very,very good job! Who wants the new kde should compile it - there have been enough release candidates (aka pre-releases) - but for KDE's PR its better to get a final what's worth calling it - and not a final released with a security bug list from network & software security experts. For the Suse guy's & ladies: Thank you for spending so much manpower & knowledge for this project!

Re: Suse didn't want it - kosh - 2002-12-10

That person is NOT a typical debian user and such a moron would be tore apart on #debian-kde or on the lists for spouting bull like that. All the debian-kde people I know are happy the release is being delayed until these security problems can be sorted out.

Re: Suse didn't want it - Debian User - 2002-12-10

Hi there, This is clearly part of why debian-kde is just talking. I just want to mention that KDE3.x is not allowed to enter Debian unstable before the gcc3.2.x transition is done. There is no technical reason to bind these issues. And sadly enough, the transition won't happen this year, maybe next year, maybe.... Debian really suffers from pseudo-explanations. I remember when KDE3 couldn't enter Debian because of many other things. Including and not limited SSL licence, Woody release, .... We have a tendency to make up reasons for things we don't want yet. Yes, likely we don't have KDE packaging infrastructure in place yet. But we don't want to say so. The thing I love about Debian is that once it IS in place, it will be great. It is not now. You will see, even after gcc3.2 transition, there will be other reasons... Thanks, Kay

Re: Suse didn't want it - Debian user - 2002-12-10

Do you know what a SONAME is? Do you really expect Debian to distribute things prohibted in the license?

Re: Suse didn't want it - Debian User - 2002-12-10

Please go ahead and tell Suse how illegal distribution of KDE is.

Re: Suse didn't want it - Scott Wheeler - 2002-12-09

The KDE developers that work at SuSE in general were KDE developers first and SuSE employees later. I believe that their priorities follow that pattern (specifically for KDE issues). For instance for 3.0 I remember Waldo advocating setting things back a bit even thought that was *not* convenient for SuSE, which was trying to get 8.0 out the door. Again, most of these folks are KDE developers that were hired by SuSE *because* of their commitment to KDE. If SuSE hires some of the more dedicated KDE developers, of course SuSE employees have a say in important KDE issues, but please keep in mind "SuSE employees" != "SuSE". If you don't like this, well, lobby for other companies to pay people to work on KDE. ;-)

Re: Suse didn't want it - Marc - 2002-12-09

I even dare to say: If SuSE really employs 50+% of the KDE core developers then they deserve it to be slightly ahead of the competition. Marc (Not a SuSE user)

Re: Suse didn't want it - kidcat - 2002-12-11

bingo! :-D /kidcat (not a suse user either)

Re: Suse didn't want it - Waldo Bastian - 2002-12-09

There will be updates for KDE 3.0 and KDE 2.2 shortly. In fact one of the reasons I wanted to delay 3.1 is that that allows us (KDE) to focus on those security updates first. Cheers, Waldo -- bastian@kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian@suse.com

GNOME fud - ac - 2002-12-09

Just another GNOME user jealous at the fact that KDE is open and isn't controlled by lethargic companies like Ximian, SUN and RedHat.

Troll Detector - AC - 2002-12-09

**BEEP** **BEEP** **BEEP**

Re: Suse didn't want it - protoman - 2002-12-09

Well, first I do agree that those problems should be found earlier... I don't like the fact RC releases have no binaries too, I predict (but hope I'm wrong) lots of bugs will be in 3.1 final because of this, let's hope not. But between this and saying SuSe controls KDE releases there is a long way. I was called as troll because asumptions that if binaries where made those security problems would not be found anyway, I asked explanation (open-source coders don't test the program for security problem, but audit the source they told me, and I humbly asked escuse, but I still belive other bugs are there). What does it have to do? Simply, sometimes we think we know more than other people but we don't! And we must ask cordially for those people explain to us how things really are, so calm down, if people of KDE team says that Suse have anything to do with this. So I thanks Waldo for enlightenning (did I wrote right?) us :)

Re: Suse didn't want it - Eric Laffoon - 2002-12-09

Even though this assertion has been rebutted it is still remarkable for the perspective and the clear ignorance behind it. SuSE is not the only company supporting KDE development anyway. Mandrake, TrollTech and others have. theKompany has sponsored KDE development and my company, Kitty Hooch (kittyhooch.com), continues to sponsor at least one full time developer on Quanta. Ignorance is not such a bad thing unless it resists knowledge. We all start out ignorant. Here's what I learned... One full time developer is easily worth 10 or more "spare time programmers". That is not an insult to those who volunteer. They simply don't have their head in the code as much and don't have the momentum so they are often less efficient in the time they do have. It's human nature. However beyond that, without someone out in front taking a lead in development the entire process tends to fall apart and grind to a halt! Starting a large project back in motion can take months to get it back to a good momentum. In light of what I know now after several years managing a project the value of those full time people to KDE and it's individual projects is beyond estimation. In many cases it is the difference between a project exploding or fading away. For this reason, even if the absurd assertion that started this thread were true, it seems that we all owe companies like SuSE and Mandrake a great debt of grattitude. Especially since they allow these programmers to simply follow their passion as I do with Andras. If I were to schedule a release to better enable me to pay Andras (I don't) I would find it hard to believe that anyone would be upset given that it would take several times as long and be far worse quality without him. It is hard to believe there are KDE users ready to bite the hand that feeds them. It has not been easy to pay Andras this year but I was glad to do it. If there were as many contributors who felt as strong as the critics KDE would have more polished full featured apps than we could imagine. If you want things sooner make it possible for more people to work full time instead of attacking those companies who already are doing a lot.

Re: Suse didn't want it - Daniel Stone - 2002-12-10

Kay, You're full of shit. The stated reasons are entirely correct, as I watched the whole thing unfold on kde-packager. Go away. Scant regards, Daniel, Debian KDE co-maintainer

problem compiling kdelibs on mdk 8.2 - protoman - 2002-12-09

I got a 1.3Ghz K7 on my work, so I decided to compile it, but....... Anyone have a solution for this? /bin/sh ../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../kdefx -I../interfaces -I../dcop -I../libltdl -I../kdecore -I../kdeui -I../kio -I../kio/kio -I../kio/kfile -I.. -I/usr/lib/qt31/include -I/usr/X11R6/include -I/opt/kde31/include -DQT_THREAD_SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -O2 -fno-exceptions -fno-check-new -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_COMPAT -c -o kedittoolbar.lo `test -f 'kedittoolbar.cpp' || echo './'`kedittoolbar.cpp kedittoolbar.cpp: In method `bool KEditToolbarWidget::save ()': kxmlguiclient.h:284: `void KXMLGUIClient::setXMLFile (const QString &, bool = false, bool = true)' is protected kedittoolbar.cpp:399: within this context kxmlguiclient.h:284: `void KXMLGUIClient::setXMLFile (const QString &, bool = false, bool = true)' is protected kedittoolbar.cpp:402: within this context

Re: problem compiling kdelibs on mdk 8.2 - protoman - 2002-12-09

Sorry, there is already a message about how to fix this, I didn't saw that.

kdebindings question - David Goodenough - 2002-12-09

As I understand it there is a problem with kdebindings (there is certainly at least one open "it does not compile" bug) which have stopped those building the Debian packages from including kdebindings. For some reason kdebindings has never been included in the Debian packages, and it would be really neat to get included this time. Any chance of getting so it builds cleanly enough for them to include it?

Re: kdebindings question - Richard Dale - 2002-12-10

I think most of kdebindings should build, apart from qtobjc and kdeobjc (those aren't built by default). Note that the license for qtjava and kdejava has been changed from GPL to LGPL. I hope that helps with any SWT licensing issues. I'm keen on looking into what's involved in doing a kde-swt binding in the new year - a KDE version of Eclipse would be really neat. -- Richard

Re: kdebindings question - newguy - 2002-12-11

Richard, I'm interested in learning to build language bindings for qt and kde. I would especially like to build bindings for common lisp, which I'm just now learning and enjoying thoroughly. I really don't know where to begin and I'm a new programmer who has never attempted to bind a language... can you point me to some literature that might help me understand the big picture of how language bindings are designed? So far googling has turned up nothing in terms of an introduction to the subject. It would be nice to have some background before I try to grok the details. Thanks!

Re: kdebindings question - Richard Dale - 2002-12-11

The only general purpose bindings generation tool I know of is SWIG, but I don't think that is powerful enough to wrap the large Qt/KDE apis (c. 750 classes, 14000 methods). The tool I use is called kalyptus (in kdebindings), which was derived from a documentation generator, kdoc. You can run some headers through that and see what sort of output it produces (eg use options -fjava or -fc to generate java or C). The PerlQt bindings use a library called SMOKE, which is language independent. I think the best way to do bindings for Common Lisp would be to use that - the language should be dynamic enough. There is a kde-perl mailing list where you can discuss SMOKE with Ashley Winters who came up with the idea -- Richard

Re: kdebindings question - newguy - 2002-12-13

Thanks. SMOKE looks interesting.

Wallpaper (background) control panel module - Brandon Zehm - 2002-12-10

Does anyone know why they went back to the old (imho lame) wallpaper control panel module? I loved the one in beta2, and if they don't put it back in I'll probably end up hacking the one from beta2 into my 3.1 installation ;) The thing I really liked about the wall-paper module from beta2 was that if I had multiple wall-papers selected I could instantly change between them by just clicking on the image name I wanted and then "apply". The wall-paper module in rc5/3.0.5 does not allow this. There is no way for me to force the display of any given wall-paper without either waiting ~100 hours for it to choose it on its own or going back to the "single wall-paper" mode. Brandon

Re: Wallpaper (background) control panel module - Anonymous - 2002-12-10

Because the new one was functionally broken in several ways.

fonts, cpu and icons - protoman - 2002-12-10

I compiled qt 3.1 and kdelibs/kdebase/arts 3.1. But now I can't get antialiased fonts. I probally missed something in compilation. Can anyone please tell me how I compile qt with antialias support? More, when compiling I noticed no cpu flags where passed to the compiler. Is that right? In this case how can I make it compile for athlon to get more speed? And for last... icons look terrible :( Only win2k icons look well in kde 3.1, any tipo about this? Thanks in advance.

Re: fonts, cpu and icons - Shamyl Zakariya - 2002-12-10

Probably you just need to recompile Qt with xft/xrender support. I can't say for certain, because gentoo automates all this away (for better? for worse?) but I've gotten the impression reading the kde lists that the configure script for qt 3.1 no longer turns it on by default. I could be wrong about the configure -- but this is clearly a lack of xrender support in qt.

Re: fonts, cpu and icons - protoman - 2002-12-10

Hum, I enabled xft, but didn't remeber do see xrender. I'll try and inform about it laqter if works, or not.

No, still no good - protoman - 2002-12-10

I included xrender, make sure it was enabled (I even have the translucent menus with xrender). I have xft support because I'm getting ttf fonts in kde. The only thing is that the fonts aren't antialiased. I have $QT_XFT set to 1, I have xft enabled in my ~/.qt/qtrc... On kde3.0 (that I still have installed) I have antialiased fonts... So I have no clue on what's wrong :) Maybe I should do a clean recompilation of QT... but that would make no sense at all....

Re: No, still no good - protoman - 2002-12-10

Hum, no. My mistake, it was set to use software transparency. QT isn't compiling with xrender, so I'll try recompiling it all.... Man this will take a lot of time! :(

Re: No, still no good - protoman - 2002-12-11

Yeah, recompiled everthing from zero and worked. Too bad qt 3.1 ships with this bug in configure :(

Re: No, still no good - huangdi - 2002-12-11

Hi, I ran into the same problem. Can you please tell me the exact options you used to compile qt? Many thanks!

Re: No, still no good - protoman - 2002-12-11

Sure: ./configure -thread -prefix /usr/lib/qt31 -cups -xft -xrender the -thread, -prefix and -cups options would make no difference, the thing is -xft and -xrender. And note that you make to do a make clean and then recompile everthing (I know, I know, it took me 4 hours on a 1.3 Ghz athlon).

Re: fonts, cpu and icons - Jesper Juhl - 2002-12-12

To optimize for your CPU when building KDE you need to set a few environment variables before running "configure" and "make". The env vars you need to set are CFLAGS, CPPFLAGS and CXXFLAGS. The values you can put in there depend a bit on what your compiler supports. On my box (1.4GHz Athlon) using the gcc 2.95.3 compiler I use these values : CFLAGS="-O2 -march=k6 -mcpu=k6" (same for the two others). Newer compilers like gcc 3.2.x have better support for newer CPU's and support flags like -march=athlon, -march=athlon-xp etc... Check the gcc manual for your version of your compiler and see what options it can handle for -march= and -mcpu=. Also, I'd recommend only using -O2 and not the -O3 or higher optimizations, since higher than -O2 sometimes break things while -O2 is safe (at least that's my experience).

Re: fonts, cpu and icons - protoman - 2002-12-12

Thanks, I got it. I don't see many speed diference, but I assume it's better to compile for k6 anyway :)

Re: fonts, cpu and icons - Jesper Juhl - 2002-12-12

If you have a newer compiler you'll see a greater difference by using one of the newer -march=athlon or -march=athlon-xp (or -march=i686 , -march=pentiumpro etc if you have an Intel CPU) options.

Re: fonts, cpu and icons - protoman - 2002-12-12

I have a gcc-3.2, but I don't know how to make qt use it. It always use g++ (I have both, the 3.2 is g++-3.2) even that I set CXX, and there is no option in configure to change it. As I have to compile qt with the same gcc as the rest of kde...

Re: fonts, cpu and icons - Jaana - 2002-12-12

Stfw. Hint: mkspecs/linux-g++/qmake.conf HTH. HAND. J

Re: fonts, cpu and icons - Pavel - 2003-08-04

Which option better: "-march=athlon" or "-march=athlon-tbird" for my AMD athlon processor 650 mhz?

Cooker & Antialiased Fonts - NewMandrakeUser - 2002-12-10

I have been running KDE 3.0.4 for ML 9.0, with beautiful antialiased fonts. However, an upgrade to KDE 3.1rc5 from cooker (yeah, I know, it is beta) ruined the antialising, which still works for instance in Gnome's Nautilus. Any ideas ?. Thanks !

Re: Cooker & Antialiased Fonts - ch - 2002-12-11

gnome's antialias is not connected to kde antialias , i think you know that and you wrote it nevertheless. chris

Re: Cooker & Antialiased Fonts - NewMandrakeUser - 2002-12-11

Yes Chris, I know that but I didn't mean to bash anyone. My only point is that the upgrade didn't hurt X itself. I guess the 3.1 rc's are being compiled without antialiasing flags, but I wanted to hear someone else's experience. KDE 3.1 is JUST AMAZING, I love it, and it is loading much faster than 3.0.* in my athlon box :-)

Re: Cooker & Antialiased Fonts - protoman - 2002-12-11

I had this problem (look at above's message). Basically xrender wasn't being compiled in QT 3.1 because of a bug in configure (it says it compile with it by default but it dosen't, you have to put the xrender option in configure). Try to use translucents menus with xrender, or look if your icons aren't a bad on borders. If menu looks empty or icons borders aren't nice, your qt is missing xrender. This made me recompiling ALL qt again (sight) and then worked.

Re: Cooker & Antialiased Fonts - NewMandrakeUser - 2002-12-11

Thanks a lot protoman !. I just read the thread :-) . I think I'll wait until the fine mandrake folks recompile it (I am too busy to do it myself right now) ;-)

Re: Cooker & Antialiased Fonts - protoman - 2002-12-11

You're welcome. I don't know if by default kde builds binaries for your architerure (I didn't see any -march=athlon on compilation), so maybe it just builds for i386 (anyone knows this?). If that's the case and you use mandrake 8.2 and have a good internet connection I can place the sources+binaries on a http (they're come with a go.sh that have all compilation options I used). My mdk 8.2 have some upgrated packages (from security and few others as samba that I can tell you where I got).

Re: Cooker & Antialiased Fonts - protoman - 2002-12-11

Oh yeah. If there is a easy way (and someone teach it to me) to make the sources into rpms I can gladly make it.

Re: Cooker & Antialiased Fonts - NewMandrakeUser - 2002-12-19

Thanks a lot, but it won't be necessary. I found a post in cooker's list with the recipe to fix it: I just ran fc-cache, and that configured fontconfig properly. Cheers :-)

Hats off to KDE - noSunlightWorksForMe - 2002-12-11

I wanted to start by congrats to KDE, it takes a lot of courage to pull a working and viable entity off the shelves and patch it later (read: i now fully beleive the linux world IS bettter than the "other guys") Now admittedly, I am a near linux/power hungry newbie, but I need to ask: does it really matter if your x comes up 0.1ms slower if it means that it is more secure? I am mainly writing in reponse to those who are raving that 3.1 loads faster. Personally, I would eat a few extra seconds if it meant that everything I need to be secure loaded everytime. If you happen to make something load faster, but without sacrificing security/functionality, then I would love to see your code.

Re: Hats off to KDE - zelegans - 2002-12-11

Well, never undeestimate the effect of 1ms on a p4@3Gz on a 486 SX system ;)

Re: Hats off to KDE - NoSunlightWorksForMe - 2002-12-12

true enough, but you see the point. Loading linux up everyday for a typical use where it is being shutdown every night, well, this is still going to be a slow process. you still need to load a keyboard in order for it to work properly, there isn't much you can do to prevent that. now if you need to load on more module in order for the computer to be safe from some of the people in this thread, then this is where my point comes into play.

Looks good, but bloated. - Absinthe - 2002-12-12

I'm running RC5, and I've noticed a lot of improvements in things that I use. However, I also noticed how much longer this release took to compile than other releases. KDE is getting way too fat with a high number of apps few people ever use. I hope that the KDE team does some research and a policy shift soon, and starts trimming the fat. I would also like to see a release branch where there's a feature freeze and a focus on stability, reducing the memory footprint, and increasing performance. Other than that, I have very little to complain about. KDE is (imo) clearly the best desktop available.

Re: Looks good, but bloated. - protoman - 2002-12-12

I agree. And the bad thing is that it was very easy to prevent this problem, just by doing separeted packages instead of a few with lots of things in side. For example: I never use noatun, but as I don't wanted to crash anything by removing it from makefile, there was I compiling something I don't use...

Re: Looks good, but bloated. - Melchior FRANZ - 2002-12-13

> I never use noatun, but as I don't wanted to crash anything by removing it from makefile, there was I compiling something I don't use... ##### You certainly don't configure by hand every time, but use a custom configure script instead, no? Simply add a line like this before the configure command: export DO_NOT_COMPILE="noatun"

Re: Looks good, but bloated. - Dylan Carlson - 2002-12-13

I think it's more appropriate to have the user set what they'd like installed than to make them turn off what they don't. And there are, between all of the KDE bundles, so many applications that this is very tedious. IMO, the solution is to narrow the focus of these bundles down to the most important, most needed/wanted applications. Move the rest of them out. The developers of those applications might be offended, but it's the right thing to do. KDE's getting porky. And you know what they say. You can't teach a pig how to sing. It wastes your time, and it annoys the pig.

Re: Looks good, but bloated. - protoman - 2002-12-13

Maybe someone should create a ncurses program for running KDE configure scripts that have all those kind of options? It would help people a lot IMHO. There was a discussion about what matters, binaries or sources, for the end-user in kde-core-devel. Well, take the number of hidden options that exists in configure (most users dosen't even know about export) and I tell you: what matters are binaries :(

Re: Looks good, but bloated. - Øyvind Sæther - 2002-12-13

"KDE is getting way too fat with a high number of apps few people ever use.". My view is the more applications, the better. KDE can be packaged to only include the basic desktop and no/few applications, or packaged to include everything. Some distributions make seperate packages for all programs (i.e. noatun has it's own RPM), some only make one large package for every KDE package (i.e. kdemultimedia is just one big package). This is a packing issue. My view is that KDE should include as much as possible, giveing users the option to choose what parts they want. Noone is forceing you to install everything. I'm no computer wizard, but even I have figured out how to split the KDE packages into seperate, smaller RPM's giveing my girlfriend, parents and friends the ability to choose what spesific parts of KDE they want. I have been useing KDE since 2.2, and spendt much time on the new searching for good KDE apps for everything. Alot of the stuff I've downloaded seperatelly over the years has now made it into KDE, and I think that's just great. No more browsing every apps homepage to check for updates, just upgrade KDE and get the latest stable versions of everything (and again, it -is- optionall if I want to install these parts or not). I think KDE should have ONE (not two, three, just the best one) application for everything as standard.

Re: Looks good, but bloated. - Dylan Carlson - 2002-12-13

I can't disagree more. If you asked around, I think you'd find most people would disagree also. People should not have to make subpackages out of the various KDE suites to eliminate the applications that, when it comes down to it, most people realistically don't use. This may be anecdotal, but just about everyone I've talked to has complained about KDE bloat, many moreso than I ever have. People don't really have a lot of choice when it comes to narrowing that stuff down. It takes over 9 hours on a 1.5G machine to install most of the packages associated with a KDE release. Call me crazy, but that's excessive for a desktop distribution, at least half of the applications of which are not widely used. 1. It's a manual process for those who compile KDE to remove them (if it is in fact possible). 2. The makers of binary packages for linux distros and other unix platforms alike have to default to compiling everything, and therefore forcing this bloat upon their users. 3. Most people are not rolling custom RPM's of the KDE stuff for their friends and neighbors, and most people are not the beneficiaries of such packages. Most people are getting everything + the kitchen sink. Take it for what it's worth. KDE should focus on building a good, stable, small footprint core, and let people tack on additional applications with secondary packages as it suits them. Throwing every little kde application in the world into these bundles might be great for having a lot of bullets on a Gnome vs KDE comparison chart, or a presentation or something -- but ultimately it results in a lot of wasted bandwidth, CPU time, disk space and unnecessarily complicates an otherwise gorgeous desktop suite. I would appeal very strongly to the KDE committee to make some adjustments in this way.

Re: Looks good, but bloated. - aleXXX - 2002-12-13

Well, a nice thing would be to have a small "[kx ]dialog" based script/makefile-thingy, which asks which parts you want to compile. Would be nice if somebody would try to implement something like this. Like ./configure --ask-for-packages and then a dialog pops up where you can select/deselect the various subdirs. Alex

Re: Looks good, but bloated. - penkuin - 2002-12-13

Yes. The word is focus. But even limiting to a maximum of 3 per category would be an be a big improvement. This also applies to the Distros. For the intial install less is more. Later one can install any package you want.

Re: Looks good, but bloated. - IR - 2002-12-13

Cant - per package group - there be voted what packages go in it? So each new KDE release would be released via publicly the current most populair KDE based apps? This would strip at least some bloat for each package group.

GAH! - crichards - 2002-12-14

I'm just going to wait for KDE 3.1. I'm running RC3 right now, and it works great. I've got a question though: Will there be patches? I'd hate downloading all the code on 56k again.

Download is a love act !!! - Lover John - 2002-12-26

Do it again, baby ... Just do it again ... Download is a great love act ...

From an end-user.. Thanks! - Curtis Rey - 2002-12-16

As an end-users and dedicated KDE user I think that waiting to release the next version a month or two is absolutely the right decision. I have migrated from the land of Redmondians because I get sick and tired of over-priced and underperforming products. If Bill, Steve and their many men of merry would have taking the time to develop and audit their software properly they wouldn't be getting such bad press and putting their clientele's data at risk. I can wait for better coding. KDE 3.0x is working just fine for right now. Sure, I want all the improvements I've been reading about. But, It just goes to show that you can have it feature rich and fast or you can take your time and have a better product with new features and better code/security by doing it right in the first place. Keep up the good work! Thanks again for giving me an alternative that works. :)

Kde3.1rc5-MandrakeRPM, "missing" file, solution! ; - MaxPayne - 2002-12-31

if these RPMs complain that libart_lgpl2-2.so.2 is missing, get it from: ftp://rpmfind.net/linux/KDE/stable/koffice-1.2/Mandrake/8.2/libart_lgpl2-2.3.10-2mdk.i586.rpm just installed mdk to try out kde3.1rc5, and didn't want to install all the "bulk" and scrapped some apps during the installation... anyways, i think there should be a note with the binaries saying that this rpm is needed in order to run this kde release (without it, when you type "startx" it just quits after briefly showing the X screen, without displaying any error message...). no reply necessary (i guess) - just actions (as suggested above) should be taken ;)

security fixes - anonymous loser - 2003-01-03

dunno about you but i have been a kde user since 2.2 and there is one thing im sure of : even after they complete their audit and delay release, the damn thing will still have bugs, will still crash, and will still eventually be found to have security holes, so just release the damn thing. :p if it actually is solid, i will sh*t a gold brick and send them a chunk of it.