| Summary: | dev-qt/qt*-4.8.6 version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David Kredba <kredba> |
| Component: | [OLD] Library | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ab4bd, andres.becerra, b.brachaczek, b.buschinski, dschridde+gentoobugs, john, mrueg, multilib+disabled, realnc, ua_gentoo_bugzilla, walch.martin |
| Priority: | Normal | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 513128, 514924, 514942, 514950, 519266, 528482, 528486, 528488, 528492, 528494, 528500, 528506 | ||
| Bug Blocks: | 498010, 501850 | ||
|
Description
David Kredba
2014-05-11 09:24:54 UTC
There are some packaging changes planned which is why this wasn't bumped yet. A minor (and very late) request: qtdemo has been removing graphicsview example based upon qt3support useflag IMHO, that quite wrong - while that example is there as an example of porting away from qt3 QCanvas API, it's also the only example about using QGrapicsView. So, would you reconsider that ? (In reply to Rafał Mużyło from comment #2) > A minor (and very late) request: > qtdemo has been removing graphicsview example based upon qt3support useflag > > IMHO, that quite wrong - while that example is there as an example of > porting away from qt3 QCanvas API, it's also the only example about using > QGrapicsView. > > So, would you reconsider that ? Yeah, makes sense. Those two examples don't seem to really require qt3support, they were disabled based just on this line in graphicsview.pro: contains(QT_CONFIG, qt3support):SUBDIRS += portedcanvas portedasteroids (In reply to Davide Pesavento from comment #3) > (In reply to Rafał Mużyło from comment #2) > > A minor (and very late) request: > > qtdemo has been removing graphicsview example based upon qt3support useflag > > > > IMHO, that quite wrong - while that example is there as an example of > > porting away from qt3 QCanvas API, it's also the only example about using > > QGrapicsView. > > > > So, would you reconsider that ? > > Yeah, makes sense. Those two examples don't seem to really require > qt3support, they were disabled based just on this line in graphicsview.pro: > > contains(QT_CONFIG, qt3support):SUBDIRS += portedcanvas portedasteroids This is fixed in git for the live ebuild and will be in 4.8.6 too. Qt 4.8.5 has a nasty bug where CPU usage is very high on some Qt applications even when they're idle. They consume about 30% CPU time on idle.
The culprit is QCoreApplication::processEvents(). When calling it with:
while (something) {
processEvents(QEventLoop::WaitForMoreEvents);
}
It returns too soon, resulting in a busy loop. My own applications are affected by this (e.g. games-engines/qtads) as well as others, like SMPlayer (media-video/smplayer).
It would be nice if this version bump could be given a high priority because of this problem.
When installing, I didn't not get any configuration files in /etc/xdg/qtchooser/ for the chooser install, and I had to place them there manually. This may have been due to a partial failed install, then a fresh pull from the overlay, then a successful install. For qtchooser, there should also be an eselect module for selecting which config the symlink points to. I'm not 100% sure on how eselect modules work, but if run by a normal (non-root) user, they should be able to eselect either the global items (/etc/xdg/qtchooser/*), or their locally installed ones ($HOME/.config/qtchooser/*), the symlink for the "default.conf" being created in their home directory. (In reply to John J. Aylward from comment #6) > When installing, I didn't not get any configuration files in > /etc/xdg/qtchooser/ for the chooser install, and I had to place them there > manually. This may have been due to a partial failed install, then a fresh > pull from the overlay, then a successful install. It's not your fault. I simply haven't written the code to generate qtchooser conf files yet. > > For qtchooser, there should also be an eselect module for selecting which > config the symlink points to. > Correct but can be done later. For now (and for backwards compat) default.conf will be hardwired to qt4.conf > I'm not 100% sure on how eselect modules work, but if run by a normal > (non-root) user, they should be able to eselect either the global items > (/etc/xdg/qtchooser/*), or their locally installed ones > ($HOME/.config/qtchooser/*), the symlink for the "default.conf" being > created in their home directory. Yes this would be nice to have. *** Bug 517830 has been marked as a duplicate of this bug. *** Can we move it to the tree now? I think all the major issues are fixed now, and the remaining work can be done after unleashing on the community. I can confirm that a few random packages and kdelibs build fine against the new version. Please move it. With 4.8.5 there was some fun too ( :-) ) and ~ARCH audience can handle it if there will be some nitpicking needed IMHO. I know you are not asking me but I was not able to resist :D. Yes, I'll move it this weekend, then ask arches to keyword qtchooser. (In reply to Davide Pesavento from comment #12) > Yes, I'll move it this weekend, then ask arches to keyword qtchooser. btw if you need help moving stuff, let us know and we'll do it for you :). Many autoconf, cmake and possibly other scripts look for qt binaries with '-qt4' or '-qt5' suffixes. Maybe you could consider adding '/usr/bin/*-qt4' symlinks? It would at least solve FindQt4.cmake which cannot find Qt4 atm. I think VLC also may have problem with finding proper 'rcc' binary with some use flags combination. When it had both 'rcc-qt4' and 'rcc-qt5' symlinks in /usr/bin, it would always take proper one. I think I was wrong about VLC - it will use pkg-config to find proper path of rcc, moc and uic binaries. Nevertheless '*-qt4' symlinks would make qt packages Debian-compatible, and some packages could make use of them. Dear Developers, I have qt-4.8.6 merged in a chroot. Would it be ok If I do bug reports for the packages that fail to merge in my system with this qt version? I would mark the bugs as blocking this one. (In reply to Andrés Becerra Sandoval from comment #16) > Dear Developers, > > I have qt-4.8.6 merged in a chroot. > > Would it be ok If I do bug reports for the packages that fail to merge in my > system with this qt version? > > I would mark the bugs as blocking this one. Yes, please do. (In reply to Michał Górny from comment #17) > (In reply to Andrés Becerra Sandoval from comment #16) > > Dear Developers, > > > > I have qt-4.8.6 merged in a chroot. > > > > Would it be ok If I do bug reports for the packages that fail to merge in my > > system with this qt version? > > > > I would mark the bugs as blocking this one. > > Yes, please do. Michał, In order to create the bug reports I previously created the /usr/bin/qmake-qt4 symbolic link to /usr/lib64/qt4/bin/qmake (In reply to Andrés Becerra Sandoval from comment #18) > In order to create the bug reports I previously created the > /usr/bin/qmake-qt4 symbolic link to /usr/lib64/qt4/bin/qmake No that's wrong and is making your testing useless... I suggest you to stop now and reply to my questions on the various bugs. I've been running qt 4.8.6 from the overlay for so many months now that I forgot I was a watcher on this bug... I use KDE as my window manager and have had 0 issues with getting things working on AMD64... Is there a reason this needs more testing (other than ARCH approval) before going into the main tree? The new qt4-build-multilib eclass is under mandatory review right now, as per Gentoo policy. There haven't been any objections so far, so I think I'll commit it in a couple of days, followed by the 4.8.6 ebuilds. (In reply to Davide Pesavento from comment #19) > (In reply to Andrés Becerra Sandoval from comment #18) > > In order to create the bug reports I previously created the > > /usr/bin/qmake-qt4 symbolic link to /usr/lib64/qt4/bin/qmake > > No that's wrong and is making your testing useless... I suggest you to stop > now and reply to my questions on the various bugs. Ok, it is better to unmerge and start again? (In reply to Davide Pesavento from comment #19) > (In reply to Andrés Becerra Sandoval from comment #18) > > In order to create the bug reports I previously created the > > /usr/bin/qmake-qt4 symbolic link to /usr/lib64/qt4/bin/qmake > > No that's wrong and is making your testing useless... I suggest you to stop > now and reply to my questions on the various bugs. Davide, I am sorry for the noise. I thing I had an old binary version of qtcore, mixed with new versions. Now I have successfully built these packages against qt-4.8.6: app-cdr/k3b-2.0.3-r1 app-emulation/virtualbox-4.3.18 app-text/goldendict-1.0.1 dev-libs/libdbusmenu-qt-0.9.3_pre20140619 dev-python/matplotlib-1.4.2 dev-python/PyQt4-4.11.3_pre20141024 kde-base/kdelibs-4.14.2 kde-base/print-manager-4.14.2 kde-misc/kwebkitpart-1.3.4 kde-misc/plasma-nm-0.9.3.5 media-gfx/digikam-4.4.0 media-libs/libkface-4.4.0 media-libs/libkgeomap-4.4.0 media-libs/mlt-0.9.0 media-libs/phonon-4.8.2 media-libs/phonon-vlc-0.8.1 media-plugins/kipi-plugins-4.4.0 media-video/kdenlive-0.9.8 media-video/qt-recordmydesktop-0.3.8-r2 net-libs/libnm-qt-0.9.8.3 net-misc/networkmanager-0.9.10.1_pre20141101 net-misc/owncloud-client-1.6.4 sci-misc/mendeleydesktop-1.12.1 I am going to mark the bugs as Invalid. (In reply to Davide Pesavento from comment #21) > The new qt4-build-multilib eclass is under mandatory review right now, as > per Gentoo policy. There haven't been any objections so far, so I think I'll > commit it in a couple of days, followed by the 4.8.6 ebuilds. Please finally do that. There will be no (more) replies, nor people caring about what's in the eclass as long as it works! Jeez, I think I'm going to mask emul-linux-x86-qtlibs along with revdeps right now if you don't want to help us get things done in a reasonable time. In tree. All built and rebuilt (even with slim-LTO using pre gcc-4.9.3, with addition of __attribute__((used)) to one row of JITStubs.h in qtscript and qtwebkit), maybe you can drop the pmask and let it go to ~. (In reply to David Kredba from comment #26) > All built and rebuilt (even with slim-LTO using pre gcc-4.9.3, with addition > of __attribute__((used)) to one row of JITStubs.h in qtscript and qtwebkit), > maybe you can drop the pmask and let it go to ~. I think qtchooser needs to be keyworded by all arches first. But maybe it is a good idea to use arch specific masks? (In reply to Manuel Rüger from comment #27) > I think qtchooser needs to be keyworded by all arches first. But maybe it is > a good idea to use arch specific masks? Yep, after a brief period in package.mask, that was exactly the plan. And I just implemented it. After more than 6 months, this bug can finally be closed. qtchooser keywording and unmasking on other arches will continue in bug 529196. Thanks everyone! Please at least provide upgrade instructions. What's the upgrade path? Right now, @world update is broken on my system: http://pastebin.com/raw.php?i=3nsc54Lx (In reply to Nikos Chantziaras from comment #29) > Please at least provide upgrade instructions. What's the upgrade path? Right > now, @world update is broken on my system: > > http://pastebin.com/raw.php?i=3nsc54Lx OK, the whole error log was a red herring. The only thing that's needed is to unmerge app-emulation/emul-linux-x86-qtlibs. 99.9% of all the other error messages are irrelevant. Exactly. More specifically, keep it out of @world and portage would unmerge it itself. |
