Saturday, January 30, 2010

Qt 4.6.0, KDE SC 4.4, configChanged()

As a heads up to everyone out there: we're getting a lot of bug reports, particularly crashes, from people using Qt 4.6.0. That version of Qt has a handful of crashes in it that some KDE apps trigger all too reliably. A patch release of Qt, v4.6.1, has been released that addresses a number of these issues. Qt 4.6.2 that's upcoming will be even better, and I understand that some distributions have been backporting some of these critical fixes. If you are having a hard time with the 4.4 release candidates, please check your Qt version first.

Then there's this bug in glibc, which has been fixed, and some distributions have backported those fixes to affected versions already. Unfortunately, some of our users are still getting exposed to it. Not fun.

Just one of those months, it seems.

The 4.4 release for KDE SC is coming along well. We've been hammering nasties, of both the crasher and general misbehavior sort, over the head at a reasonable pace, even though 4.5 is open and some work is going on there. I count 52 backport commits to the 4.4 branch in just Plasma-land in the last seven days.

(A "backport" is when we fix something in the main development branch, in this case it is what will eventually become KDE SC 4.5, and then after testing it there merge the fix into the previous stable branch, in this case what will become KDE SC 4.4.0.)

(Trunk teaser: Marco is doing some really nice work on notification and job display right now. Woo! This is why you want to join us and run an svn trunk build of KDE SC so you can help us test while you get the first tastes of things coming down the pipe! ;)

12 comments:

mpyne said...

One thing to keep in mind is that the glibc bug may not affected release versions of KDE as the MALLOC_CHECK_ feature in question is not enabled by our startup script. (It may still be enabled by the distro)

Nicolai said...

It might be a dumb question, but what does the 'SC' stand for?

gjditchfield said...

Is there some place where subscribers to ppa:kubuntu-ppa/beta can get a better version of Qt than karmic's 4.6.0?

isaacj87 said...

Dang it Aaron. You know that isn't fair. Now, I HAVE to know what new developments are happening in trunk. Any chance us little people can get a screencast or screenie of the new greatness?

Thanks :)

Kevin Kofler said...

As a heads up to everyone out there: we're getting a lot of bug reports, particularly crashes, from people using Qt 4.6.0. That version of Qt has a handful of crashes in it that some KDE apps trigger all too reliably. A patch release of Qt, v4.6.1, has been released that addresses a number of these issues. Qt 4.6.2 that's upcoming will be even better, and I understand that some distributions have been backporting some of these critical fixes. If you are having a hard time with the 4.4 release candidates, please check your Qt version first.

Fedora has Qt 4.6.1 in Rawhide and in our (unofficial) kde-unstable repository (which carries the KDE SC 4.4 prereleases built for our stable releases).

When will 4.6.2 be out? Or alternatively, any particular post-4.6.1 fixes we should backport? Are they in the kde-qt.git repo? Do you have a list of commit ids to backport?

Fedora releases are still on Qt 4.5.3. When we will push KDE SC 4.4.0 as an official Fedora update, it will definitely include the latest Qt 4.6.x bugfix release.

Then there's this bug in glibc, which has been fixed, and some distributions have backported those fixes to affected versions already. Unfortunately, some of our users are still getting exposed to it. Not fun.

This bug was fixed in glibc 2.11.1 which was pushed as a Fedora 12 update on January 12 (update reference FEDORA-2009-12470).

mpyne said...
One thing to keep in mind is that the glibc bug may not affected release versions of KDE as the MALLOC_CHECK_ feature in question is not enabled by our startup script. (It may still be enabled by the distro)

Or disabled. ;-) FWIW, that's what we did in Fedora in our 4.4 prerelease packages due to that glibc bug.

Ignat said...

This might be not the best place to ask about it, but I have a small question regarding the notification system. With KDE built from trunk, I don't see any Plasma notifications. Instead, the notification-daemon is used, and after killing it manually, KNotify falls back to using KPassivePopup (hope this is how it's called). Why could that be?
Oh, and it's really nice you're trying to improve the design of those Plasma notification popups.

Notmart said...

@isaacj87: still some refinements to do. as soon as will be ready there will be a juicy screencast :)
@ignat: you have to kill the notification daemon and then restart plasma
oh, and make sure notifications and jobs is enabled in thne plasma config

pvandewyngaerde said...

http://reviewboard.kde.org/r/2758/

this looks like something that can be easily backported.

to bad i dont know how

Hans said...

@Nicolai:
SC stands for "Software Compilation". http://dot.kde.org/2009/11/24/repositioning-kde-brand

Damn teasers before even 4.4 is out! /me runs kdesvn-build

Naproxeno said...

Sorry if I'm wrong Aaron but could Qt 4.6.0 be related to the memory leaks in plasma-desktop (along the lines of Bug 206317). I've been suffering this bug since the beginning and it's my only pet peeve with Plasma.

I've read that you run Plasma through Valgrind during Tokamak 3 and it certainly it's better now but I still can consistently get over 100 MBs. of memory usage by plasma-desktop (according to the system monitor in KRunner) after some days without rebooting.

Please, don't take this as a personal demand. I just want to know where the problem is (Plasma, Qt, Kubuntu,...). Of course, the sooner it's solved the better but I can imagine how busy you are already... :-)

I've commented on that bug report but if there's something else I could try, just tell me.

Thanks!

Aaron J. Seigo said...

@Kevin Koffler: sounds like the KDE Fedora team is doing a good job, as seems usual these days. i'm really impressed by the work i continually see happening there. :)

as for lists of commit id's to backport and what not, that's probably a question better answered by people on the kde packaging list. i haven't gone through and fished out what commits are worth backporting, and i don't want to give half-assed advice about something that important.

@Naproxeno: probably doesn't have anything to do with Qt 4.6.0. it's very hard to tell what the problem would be without knowing what widgets you are using, what interactions you are engaging in with plasma and doing some local profiling.

i know we closed up some more leaks (though mostly of the more minor sort) over the last months (including a couple very recently). they are getting smaller and fewer, though third party widgets are harder to vouch for obviously ;)

another round of valgrinding for 4.5 should hopefully root out remaining issues. it will be another topic for this tokamak.

Naproxeno said...

@Aaron: Thanks for your answer! I'm quite certain that the problem is not on the widgets because I tried starting with a default desktop (deleting plasma* config files) and i still leaks. However Roman Jarosz has now suggested in the bug report that it could be a problem with notifications. As you just said that Marco is now working on those, perhaps this will be fixed indirectly by this work.

Anyway, thanks for your time and effort. Now back to counting the days till KDE SC 4.4. :-)