KDE 3.1.3 Released!

The KDE Project announced
KDE 3.1.3 today. It's the third maintenance release of the successful KDE 3.1.x series and
ships with many bugfixes and improved translations. KDE 3.1.3 also contains a fix for a possible HTTP authentication leak
in the HTTP referrer header. Users of KDE 3.x are advised to upgrade to KDE 3.1.3. Read the change log or directly jump to the
download links on the KDE 3.1.3 Info Page. The Konstruct build toolset was updated accordingly.

Dot Categories: 


by Chakie (not verified)

... to all the developers!

by Robert Schouwenburg (not verified)

And thanks....

by obi (not verified)

You guys really rock.
Thank you !

by Ruediger Knoerig (not verified)

First a big,big THANK'S to the developer!
I've seen a lot of comments related to gcc3.4+ compilation issues. Is gcc3.4+ ready for production systems?
The actual snapshot of gideon had some trouble as I tried to compile it with gcc3.3.1 (prerelease from Jul. 20). I remember some trouble like
char *dst=QString (assignment (const char *) to (char *)), a double 'const' in
a xpm file (const char *name const = ...) and a lot of 'using default value for ... parameter of ( bool ... = false in the .cpp) in the Ada related stuff.

by fault (not verified)

const char *name const is perfectly valid C++, and is correct.. afaik.

by Arno Nym (not verified)

It is not ready until it has been released. 3.3.x is the current stable branch.

The reason for the numerous gcc 3.4 fixes is that the 3.4 branch has a new C++ parser, which is a little bit more picky about the standard.

by Dirk Mueller (not verified)

GCC 3.4+ is not ready for use it, nonetheless we try to keep
our code compatible to as many compilers as possible.

It is not recommended to use gcc 3.4 with KDE yet as it still contains
a few miscompilations and bugs that won't make the result of compilation usable for end users.

But if you're adventurous and not afraid of tracking down bugs and fix them,
you're welcome to try :-)

by Daniel Stone (not verified)

I don't even recommend using GCC 3.3, as it's absolutely awful.

ICEs on xfree86 and kdebase on multiple architectures (including, but not limited to: arm, mips and mipsel), used to ICE on i386, miscompiles ?dm authentication at -O2 on every architecture (AFAICS - at least amd64, i386, ia64, powerpc and sparc), and more. If you care about your code, stay back at 3.2 until they unbreak 3.3 (haw!).

Oh yeah, and it fails to compile aspseek (a 3.2 regression), because its parser is horribly broken, and they're not planning to fix that one till 3.4. Nice one!

by Garen (not verified)

dm authentication? I don't see a bug like that over at gcc.gnu.org/bugzilla. If you could generate a minimal test case for it and file a bugreport there I'm sure it would be useful.

by Daniel Stone (not verified)

It's been filed already, and I think they've fixed it in 3.4.

by Leo Savernik (not verified)

With gcc 3.4, can KDE finally be compiled with precompiled headers? How much faster will gcc 3.4 w/pch compile kde compared to gcc 2.95?

by Tim Jansen (not verified)

This won't work until somebody adjusts the make system (and possibly the sources), because gcc can only use one precompiled header per compilation unit. So you have to create header files that contain all headers that a program uses, then precompile this header file and include it from all sources.

by perraw (not verified)

But what if all qt headers are pre compiled in to qt_all.h and all kde headers are compiled into kde_all.h Then all qt headers first include qt_all.h and the same with kde? Wouldn't that help?

Or what approach is one suppose to take? I really hope we don't have to change all kde program and use ifdef using gcc-3.4 then one big fat file, else all different headers?

by Tim Jansen (not verified)

It would work, but I am not sure whether including 1000 precompiled headers is still faster than 50 that are not precompiled :)

The intended way seems to be that each application/module/library has an all.h with all headers that it needs.

by perraw (not verified)

MFC in Visual C++ you just include stdafx.h and you are done.
Anyway, it will be really interesting to see what will happen when we have gcc 3.4 around. I bet there will be a big flame fest on what we should do about it. Just thing about how easy it is to use a QThatClass without including the header for people not using PCH ;=)

by cbcbcb (not verified)

I've seen a few different approaches to compiled headers. The one I think makes most sense is that each program includes just the header files it requires. An all_headers.h is created which #includes all of the header files. Then to use the precompiled headers the build system adds -include precomp.h to the gcc command line. (The multiple inclusion guards in the original header files still work so they do not need to be parsed again)

This mechanism means that systems without precompiled headers don't suffer from including every single header file.

by Alistair Strachan (not verified)

It won't be. Precompiled headers reduce compile time, because headers that are included repeatedly through a lot of sources do not have to be continuously parsed by the preprocessor.

The compiled output may be marginally different, but I doubt it will be significantly faster.

by Justin (not verified)

Microsoft Visual C++ 6.0 supports precompiled headers, and it makes a world of difference.

When I build Psi on Linux (gcc 3.2) and Windows (MSVC++ 6), the MSVC build process blows gcc away in terms of speed. It's probably 4 or 5 times faster. To further rub it in, I'll note that my Linux box is a P4 1.6GHz and my Windows box is a P2 400MHz.

I am very much looking forward to precompiled headers in gcc.

by Richard (not verified)

This has been my experience as well. I used to do MFC programming on a P3 600MHz w/ 128MB RAM. It was quite snappy. But when developing a small Qt application on Linux, My 1.33GHz w/ 768MB RAM (that's more than twice as fast) it's a serious pain in the ass.

GCC 2.95.x used to be very reasonable in compile speed, but 3.x has changed dramatically.

It's funny though that no one has commented on your message yet. I bet no one wants to believe that GCC is not all that great when it comes to compile times. Maybe it's because we shouldn't complain because it's free anyway so we should fix it ourselves.

I've been looking forward to gcc 3.4 ever since 3.2 was released. I was dissapointed to learn that it was delayed for 3.4 though, I wanted this in 3.3 :)

by SadEagle (not verified)

No, it's probably because everyone has complained about g++'s compile times so much it's
getting old on us already :-).

by Rayiner Hashem (not verified)

Everybody and their mother knows that G++ is glacially slow. Searching for "gcc slow" on google nets 112,000 Google hits. Its acknowledged even in the gcc mailing lists.

by Leo Savernik (not verified)

> GCC 2.95.x used to be very reasonable in compile speed, but 3.x has changed dramatically.

Awww, if you call gcc 2.95's speed reasonable, then gcc 3.x must be really, utterly, painfully slow. So I'll stay with gcc 2.95 another 4 years :-(

by precompiled (not verified)

i've seen the difference of compiling a wxWidgets application on a PII400, with and without precompiled headers. the compile time dropped from 3 minutes to something like 40 seconds. the difference is more than obvious.

by FreakOne (not verified)

A bug that already occured in the debian packages of kde 3.1.2 found its way again into 3.1.3:
In /usr/bin/startkde line 150

LD_BIND_NOW=true kdeinit +kcminit +knotify

doesnt start kdeinit, what leads to the situation that all arts-related programs like kaboodle and noatun cant be startet. I fixed it changing to

kdeinit +kcminit +knotify

Did this happen to anybody else?

By the way, great work guys!

by SadEagle (not verified)

The LD_BIND_NOW=true is there for a reason, the change you're suggesting is incorrect.
Can you please elaborate on what exactly crashes, and further; I'd suggest you check your libvorbis install. (Although this prolly should go into bugzilla..)

by FreakOne (not verified)

To me the original line seemed like a typo - like someone missed a line break between the variable definition and the call of kdeinit. With the litle change it works...
What didnt work was that after logging into the kde session with kdm there was no sound with every kde app like kaboodle and noatun. No startup buzz and an error message claiming that kde couldnt initalize e.g. kaboodle.

by SadEagle (not verified)

Well, as I said, the change is wrong. It effectively turns the assignment into a no-op.
FOO=bar ./app sets FOO into apps environment. Doing it on a separate line merely sets a
shell local.

by AC (not verified)

Perhaps this is a dumb question, but how come there are no binary packages for Mandrake lately?

by Bojan (not verified)

Not a dumb question at all, I was asking myself the same thing...

by Arno Nym (not verified)

I think because Mandrake needs money and only provides them for a fee (club members or whatever they are called, not a mdk user myself...)

by JLP (not verified)

I think they will be up on Texstars RPM mirrors quite soon for users of Mandrake 9.1. The packages for 9.2 Beta 1 are already available on the offical Mandrake Cooker RPM mirrors.

by Jeremiah Cornelius (not verified)

Add to your /etc/apt/sources.list:

deb ftp://ftp.uni-kl.de/pub/linux/kde/stable/3.1.3/Debian woody main

by BenjyD (not verified)

What! Debian has 3.1.3 before Gentoo? Something's wrong here.

by Debian user (not verified)

What about sid aka unstable?

by Burrhus (not verified)

Gentoo has 3.1.3, but it's still in testing. If you really can't wait a few more days, you can comment it out in /usr/portage/profiles/package.mask.

by Amund (not verified)

Texstar provides rpm packages of kde 3.1.3 for Mandrake. If you have not installed any sw source for Texstar, you can do it with this comand under Mandrake 9.1:

urpmi.addmedia texstar ftp://ftp.ibiblio.org/pub/Linux/distributions/contrib/texstar/mandrake/9... with hdlist.cz

If the ftp server is not reachable, then you can try this:

urpmi.addmedia texstar2 ftp://ftp.bahcesehir.edu.tr/pub/texstar/mandrake/9.1/rpms with hdlist.cz

If you are not running 9.1, you can find a mirror here: http://plf.zarb.org/~nanardon/

Import the keys:
wget -O - ftp://ftp.ibiblio.org/pub/Linux/distributions/contrib/texstar/linux/dist... | gpg --import

Finaly you may Upgrade kde:

urpmi kdebase

Or you may upgrade everything:

urpmi --auto-select

(Later, you can find new SW at texstar and update your urpmi database:
urpmi.update texstar
urmpi.update -a

Then you can updrade all:

urpmi --auto-select

by a.c. (not verified)

you need to change this slightly to:

wget -O - ftp://ftp.ibiblio.org/pub/Linux/distributions/contrib/texstar/mandrake/g... | gpg --import

by AC (not verified)

Wow. Very informative. Thanks.

by Richard Jones (not verified)

Thanks for this advice, it works a treat (with the fix mentioned in the other reply). I ended up doing --auto-select, and had about 730Mb of RPMs to install (about 770 in total). I had done *no* RPM updating except for mandrake's security fixes since installing 9.1 from CD. There were a couple of very minor dependency issues:

1. saslauthd needed libcom_err.so.3 but I couldn't easily find something to satisfy it, so I uninstalled it (and postfix) :)

2. kdebase-kdm-config-file wasn't updated for 3.1.3, so I installed the 3.1.2 version instead, having to go --nodeps 'cos *that* wanted kdebase-3.1.2 ;)

All done in single-user mode, of course. Everything appears to be running just fine now.

by Coolvibe (not verified)

Kudos for this release. Also, FreeBSD already merged it into the ports tree. head on over at rabarber.fuitsalad.org for precompiled packages if you want to be compiling for the next few days.

by Coolvibe (not verified)

run sed -e s/if you want/if you _don't_ want/ on that sentence... Damn, I should have previewed...

by Hiryu (not verified)

I switched from 5 years of debian to SuSe 8.2 recently (Love both but don't wanna feel like a sys admin at home anymore).

How does one auto upgrade in an apt-like way to kde 3.1.3 in SuSe? I'm unclear on this matter...

I hope this fixes this small but annoying konqueror bug. :/


by Richard (not verified)

You need to be a little patient before the rpms arrive in the suse-8.2
apt repository. Just watch:

More about apt for suse at:

by Evan "JabberWok... (not verified)

You can use the text or X interface of 'yast', and do Software/Online Update (or 'yast online_update')...

or just go to the KDE Control Center and choose "Yast/Software/Online Update".

by Hiryu (not verified)

Thanks for the replies.

1st of all, I checked to make sure there were suse 8.2 rpms for kde 3.1.3 before posting (though I'm still with 3.1.1 so even just getting 3.1.2 would be fine).
Those rpms are found here:

I have tried the online update too but it didn't seem to work for me. Most likely I entered the url incorrectly. I'm still not entirely sure what files yast looks for so I can add urls correctly (on my first attempt anyway). I'll go experiment a bit now and see what I can pull off.

Again, thanks.

by Anonymous (not verified)

You have to add an URL ending with "yast-source/" directory to YaST like ftp://ftp.suse.com/pub/suse/i386/supplementary/KDE/update_for_8.2/yast-s... or equivalent on mirrors - atm this only holds KDE 3.1.2 but I would expect this to be updated soon to KDE 3.1.3 once the packages are more mature/tested.

by Hiryu (not verified)


Now that I have it added, what do I do? Nothing seems to get me to the versions of the packages on the url (which appears to be 3.1.1 now).

by Anonymous (not verified)

Call "Install and Remove Software" or "Online Update". :-)

by Hiryu (not verified)

Neither of which seem to be doing the trick... Very strange, I'll try it some more however and see what happens.


by jadrian (not verified)

I think you have to move that new ftp url up to the first place in the list...