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
Who can fault this decision except for those who haven't
progressed beyond the "Are we there yet?" stage.
On the release page it says:
Bugs...none
Security issues...none
So why not release it?
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.
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
you are relying on KDE ... which is wrong.
Buy commercial software and you will have less to worry about and have a better life.
> you are relying on KDE ... which is wrong.
absolutely not.
there are commercial software where you
CAN rely on KDE.
dear god here come the flames...
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.
maybe you should delete your *.moc files. you may need to delete files generated from *.ui at some point.
> 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
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
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!
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
Ed: compile output placed in commentRead this: http://dot.kde.org/1039281841/1039286480/
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.
You are absolutely right to put security first.
Let's go and build the most secure and most stable unix desktop kde team.
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)...
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!
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
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)
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?
I love the xscreensaver stuff in Redhat 8. Can't wait to be able to use it with KDE.
Seriously, what's your point? It has always been in KDE.
if can you use xscreensaver modules in KDE it's not f*&#!% clear.
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/
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.
_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
My bad. It's still not been in there in an obvious way though.
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 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.
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?
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
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
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.
Can we make it true by default on Linux?
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.
I have it set to UseLilo=true, it still shows only an empty selection box.
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
Everytime I try and do a make on kdelibs I get this error:
.libs/dcopclient.o: In function `QPtrList::replace(unsigned int, DCOPClientTransaction const *)':
.libs/dcopclient.o(.QPtrList::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?
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
"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.
Have no solution, but having the same problem. Was wondering if you founf a solution in the mean time.
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
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
no!!!! we want a final! I will boycott this release forever!
.:starts compiliing:.
sorry for rant. i'm impatient.
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
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.
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
That's because SuSE cares about quality :-)
Cheers,
Waldo
--
[email protected] -=|[ SuSE, The Linux Desktop Experts ]|=- [email protected]
No. If SuSE cared that much about quality the code audit would (should?) have happened before feature freeze - before any RC at any rate.