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
It was not a SuSE audit, but one by an independent, external group.
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!!
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
> 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.
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?
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!
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.
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
Do you know what a SONAME is?
Do you really expect Debian to distribute things prohibted in the license?
Please go ahead and tell Suse how illegal distribution of KDE is.
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. ;-)
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)
bingo! :-D
/kidcat
(not a suse user either)
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
--
[email protected] -=|[ SuSE, The Linux Desktop Experts ]|=- [email protected]
Just another GNOME user jealous at the fact that KDE is open and isn't controlled by lethargic companies like Ximian, SUN and RedHat.
**BEEP**
**BEEP**
**BEEP**
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 :)
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.
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
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
Sorry, there is already a message about how to fix this, I didn't saw that.
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?
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
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!
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
Thanks. SMOKE looks interesting.
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
Because the new one was functionally broken in several ways.
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.
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.
Hum, I enabled xft, but didn't remeber do see xrender.
I'll try and inform about it laqter if works, or not.
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....
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! :(
Yeah, recompiled everthing from zero and worked.
Too bad qt 3.1 ships with this bug in configure :(
Hi,
I ran into the same problem. Can you please tell me the exact options you used to compile qt?
Many thanks!
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).
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).
Thanks, I got it.
I don't see many speed diference, but I assume it's better to compile for k6 anyway :)
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.
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...
Stfw. Hint: mkspecs/linux-g++/qmake.conf
HTH. HAND.
J
Which option better: "-march=athlon" or "-march=athlon-tbird" for my AMD athlon processor 650 mhz?
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 !
gnome's antialias is not connected to kde antialias , i think you know that and you wrote it nevertheless.
chris
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 :-)
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.
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) ;-)
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).
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.
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 :-)