Qt-4.5.0_rc1 hit the tree. Should you upgrade?

February 13, 2009 · Posted in Gentoo

..or not? Let me do a quick summary first. Qt-4.5.0_rc1 has been on qting-edge[1] overlay for up to two weeks now. We fixed as many bugs and building problems as possible. This version of Qt seems to be way too better than _beta1. From my part I would say yes upgrade. In case you are a kde4 user you might encounter several bugs. I ll come to this a bit later. So I d like to give you some directions on serveral problems that hit users the first hours of qt-4.5.0_rc1 release.

How to ugrade? I have tones of blockages!

In case portage complains about a hell of blockages the solution is quite simple. Obviously you were using the qt metapackage ( x11-libs/qt:4 ). If this is the case, you need to un emerge it:

emerge -C x11-libs/qt:4

Then you need to edit /var/lib/portage/world. Find x11-libs/qt entry and modify it like this:

x11-libs/qt:3

Now you are done. Run emerge -uDNav world and everything should be fine. If you still have questions about this , please drop by Gentoo forums[2]. We have a dedicated thread for this situation[3].

Ok I upgraded. Now kde4 looks ugly/crashing/etc

A known issue is a kdm crash. You wont have it if you are using the latest kdm in the tree. If you dont, please upgrade.

As the ewarn message suggest, you should re-build PyQt4, qscintilla, kdelibs. Our Gentoo KDE Devs suggest to rebuild libplasma and plasma-workspace. The fact that most of our users dont have such crashes make me think that you should rebuild everything that fails. But thats quite abstract.
If you still have issues after rebuilding please follow the below steps to fill a bug:

1) Open a bug on kde bugzilla[4]
2) Open a bug on our bugzilla[5]and assign it to kde_AT_gentoo.org
3) Paste the link from upstream bug on the bug you opened on Gentoo bugzilla
4) We ll take it from there. Just be around in case we need you to provide more info to us

This might sound too much but it will really help us track all the problems and poke upstream about that. So it is just a 5′ work that might help hundreds of other users

You can always not open a bug on our bugzilla and monitor it yourself but I would prefer to know all the problems and the possible patches that fix them in order to apply them on portage.

Conclusion:

People keep complaining that we should remove Qt-4.5 or mask it from tree. I will provide you two links[6][7] why I think we should have it or what problems you might encounter . After all is ~arch so it is normal to expect some mulfunctions for those who use KDE4. But please remember that not everybody is using KDE4. There are other people with xfce,fluxbox and other DE that want a shiny new Qt for their Qt4 applications. Should we dissapoint them in favor of KDE4? I dont think so

Links:

[1] http://github.com/gentoo-qt/qting-edge/tree/master

[2] http://forums.gentoo.org

[3] http://forums.gentoo.org/viewtopic-t-736457.html

[4] http://bugs.kde.org

[5] http://bugs.gentoo.org

[6] http://labs.trolltech.com/blogs/2009/02/10/why-kde-42-should-use-qt-45/

[7] http://labs.trolltech.com/blogs/2008/12/04/how-kde-4-is-blocking-qt-45/

Tags: Gentoo, qt

Comments

28 Responses to “Qt-4.5.0_rc1 hit the tree. Should you upgrade?”

FireBurn on February 13th, 2009 2:54 pm

Why not hard mask the ebuild, it is a RC after all not a final release.

There are plenty of examples of final releases being hard masked due to compatibility issues (look at python)

I think it’s not very considerate putting something that does have known issues with an entire desktop environment into ~arch.

I’m sure the Gnome folks would be equally annoyed if someone put an RC of GTK+ into ~arch if it caused problems too.

Mike
dude on February 13th, 2009 2:55 pm

How can I set the graphicsystem? I would like to try the new raster system, but I could not find any use flag.
Markos on February 13th, 2009 3:12 pm

@Mike
As I said before its way better to use it with kde4 rather than qt-4.4.2. Even though the latest qt-gui-4.4.2 we have on portage doesnt fully cooperates with kde4. We plan a new release of qt-gui-4.4.2 with more patches in order to solve some issues. You can always mask it your self if it doesnt cooperate well in your system. But the fact that we tested it a lot and didnt see some obvious or critical failures makes me think that this version does more good than bad. After all, fill a bug as I suggested in order to poke upstream and fix it :)

@dude

Use “raster” use flag on qt-gui :). Note that this feature is new and might lead to some bugzzz :)
Andreas Nilsson on February 13th, 2009 3:15 pm

I think it’s right to release it. And it’s working just fine with 4.2 as far as I can tell. The only thing I’ve noticed is a bit weird coloration of the panel. The gradient is way lighter at the bottom after the upgrade, and the same discoloration occurs in the plasmoids to.

Let ~arch be ~arch and deliver fresh packages there, thats why we have it.
Markos on February 13th, 2009 3:23 pm

This is exactly my thought. ~arch is for shiny new packages :). Hard masking is for highly broken packages. Qt-4.5 is not a broken package at all :). The fact that it is not 100% cooperative with kde4 ( yet ) doenst make it candidate for masking.

Andreas, you might want to fill a bug as I suggested on the post in order to push that upstream or just wait till the next version of Qt-4.5 :)
Temet on February 13th, 2009 4:54 pm

Even if I’m not concerned (I run “arch” Gentoo), I really appreciate the communication and the pieces of advice!
Thanks :D
Markos on February 13th, 2009 5:30 pm

No problem. The fact that I am a developer doesnt mean that I stopped being a gentoo user. So I am trying to see problems from both users’&developers’ point of view and get as much feedback as possible. Thank you all.
ant on February 13th, 2009 6:05 pm

I think I’ll wait until 4.5 final… qt-core-4.5.0_rc1 doesn’t even compile for me:

compiling main.cpp
linking ../../../bin/moc
/usr/lib/gcc/i686-pc-linux-gnu/4.3.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lQtGui
collect2: ld returned 1 exit status
make: *** [../../../bin/moc] Error 1
/usr/libexec/paludis/utils/emake: emake returned error 2
Markos on February 13th, 2009 6:09 pm

This is not not valid. I did fix it two days ago

http://bugs.gentoo.org/show_bug.cgi?id=258667

Please re-sync your tree
ant on February 13th, 2009 8:38 pm

Oops, that’s what I get for not paying attention. Thanks a lot!
chithanh on February 13th, 2009 9:13 pm

~arch is for users living on the bleeding edge who can (or should be able to) handle such problems. Thank you very much for adding Qt-4.5.0_rc1 to the tree.

BTW, I noticed that the meta ebuild (x11-libs/qt) is still at 4.4, is it going to be dropped?
Markos on February 13th, 2009 9:17 pm

:)

Yes the metapackage will be dropped . There wont be qt metapackage from now on. Users should migrate to split ebuilds :)
peter on February 13th, 2009 10:20 pm

i’ve just upgraded to qt4.5 and everything works great (actually i’m also doing a emerge -e world… i know, i’m crazy :) )
Arne on February 14th, 2009 1:08 am

QtScriptTools (The QtScript Debugger new with 4.5) seems to be missing, it’s not build with qt-script and there is no qt-scripttools ether.
Markos on February 14th, 2009 1:23 am

Thanks for that. You are right. It doesnt build at all. I ll run some tests and fix the qt-script ebuild to ship scripttools too :)
ant on February 14th, 2009 2:15 am

Upgrade went fine, KDE apps work fine as far as I can tell, and the tray icons finally display correctly!

But now I’m having a weird problem with some Qt apps – they work fine but lock up with 100% CPU after using them for a few seconds. Arora works fine (I’m posting this from it), Psi freezes as soon as I go to type a message, qgit4 freezes if I click a row on the main window.

The symptoms sound similar to this on the forums: http://forums.gentoo.org/viewtopic-p-5467478.html#5467478
I’m going to recompile some things that were suggested there, will let you guys know if it fixed it or not.
Markos on February 14th, 2009 2:22 am

Yes , qt-4.5 seems to cause some troubles on those apps. Well this is def not Gentoo specific :).
You can contact the upstream of those apps or just wait till the next version. I dont think there is nothing we can do unless upstream provide a patch for those apps. If you want , open a bug on our bugzilla , just to keep track for the falling apps :)
ant on February 14th, 2009 5:23 am

Oh well, I can live without them for now. Thanks for the info!
Alec on February 14th, 2009 7:50 am

Thanks a lot! Sometimes I wish there were more shiny new packages in testing. :)

I also have a question… Above, you said that that you could enable the “raster” graphics system using the flag. Hovever, is there a way to enable the opengl system? According to –help-qt, it’s possible to change them using the –graphicssystem option; however, if I choose opengl, it complains that it can’t open it. But it doesn’t complain if I select raster.

So as I understand, Qt can use the native system (which is the default) and the raster system (which can be set as default with the flag). But where is the opengl system? Is it just way too unstable?
Markos on February 14th, 2009 3:15 pm

Unfortunately not :(. “opengl” backend requires opengl module to be build “inside” qt-gui. The fact that we build qt-opengl module as a separate module from qt-gui doesnt allow us to do that linking.
I did some tests and tried to do a workaround but all of them failed.
Well I guess, this is the first(?) disadvantage of splitting qt into modules…
Volker Armin Hemmann on February 15th, 2009 5:21 am

KDE worked PERFECT with qt-4.4.9999 (qt-copy). No crashs, nice looking. Perfect. I upgraded to rc1 – it was a complete crash fest. A few hours ago, I did it again. Installed -rc1, re-emerget pyqt4, kdelibs, than all of kde.
Result?
Ugly fonts
Konqueror is a complete crashfest.
(http://bugs.gentoo.org/show_bug.cgi?id=259020)

So how do I get qt-4.4.9999 back? At least it WORKED.
Alec on February 15th, 2009 7:28 am

So will anything be done about that? From what I know, running in OpenGL mode would provide significant performance boost in Qt applications – way greater than raster…
Retrry on February 15th, 2009 12:02 pm

Hm, I cannot compile the Qt. I get error – “The GTK theme support cannot be enabled due to functionality tests!”.
Markos on February 15th, 2009 12:21 pm

@Volker Armin Hemmann

Unfortunatelly you cant. 4.4.9999 was qt-copy. KDE moved qt-copy to 4.5 so there are no live ebuilds for 4.4 anymore. KDE and Qt are working on 4.5 now … I ve never heard again of your issue. You might need to rebuild several kde libs ( kdelibs, libplasma, plasma-workspace ).
If this doesnt work, use the ~qt-4.4.2 ebuilds. I recently pushed on tree new ebuilds for qt-gui-4.4.2, qt-core-4.4.2,qt-sql-4.4.2 and qt-webkit-4.4.2 with many qt-copy patches. You should be fine :)

@Alec
Not for now until we solve all the qt-4.5 bugs. Then I ll focus on the performance :)

@Retrry
I ve never heard about that either. Please open a bug with a complete build log :)
Retrry on February 15th, 2009 12:29 pm

@Markos
I just compiled it with use flag -gtkstyle.

And I will open bug report later :)
Loller on February 16th, 2009 10:21 pm

Yep, Xfce, fluxbox and other WM rock to launch the xterm – however don’t call them DE, that’s ridiculous.

I have also a 3Kb collection of patches to modify GTK+ to run more smoothly in XFCE and Fluxbox. Incidentally it renders gnome unusable but that will not stop us to insert it into ~branches, right??!?
Markos on February 16th, 2009 10:34 pm

I cannot answer that since my only field of responsibility is Qt. You should contact directly gkt+ maintainers or gnome herd.

Dont be so strict about xfce,fluxbox etc. There are really many people who actually uses those WM. And many many people who have still kde-3.5 ( since this is the *stable*). Qt != kde4, despite the fact the KDE4 is the biggest QT4 project if I may say.
andriy on March 7th, 2009 4:39 am

Unfortunately new kdm still crashes on root login… sigh. Using kde3′s kdm for now.