Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 510042 - dev-qt/qt*-4.8.6 version bump
Summary: dev-qt/qt*-4.8.6 version bump
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal with 3 votes (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords: InVCS
: 517830 (view as bug list)
Depends on: 513128 514924 514942 514950 519266 528482 528486 528488 528492 528494 528500 528506
Blocks: 498010 501850
  Show dependency tree
 
Reported: 2014-05-11 09:24 UTC by David Kredba
Modified: 2014-11-20 08:50 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Kredba 2014-05-11 09:24:54 UTC
Could you please bump qt packages to version 4.8.6 released in April?

http://blog.qt.digia.com/blog/2014/04/24/qt-4-8-6-released/

Reproducible: Always
Comment 1 Michael Palimaka (kensington) gentoo-dev 2014-05-11 15:48:26 UTC
There are some packaging changes planned which is why this wasn't bumped yet.
Comment 2 Rafał Mużyło 2014-05-24 03:49:48 UTC
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 ?
Comment 3 Davide Pesavento gentoo-dev 2014-05-25 13:41:59 UTC
(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
Comment 4 Davide Pesavento gentoo-dev 2014-05-27 22:28:18 UTC
(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.
Comment 5 Nikos Chantziaras 2014-06-28 15:09:45 UTC
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.
Comment 6 John J. Aylward 2014-07-09 15:19:00 UTC
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.
Comment 7 Davide Pesavento gentoo-dev 2014-07-09 23:15:54 UTC
(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.
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2014-07-23 01:27:04 UTC
*** Bug 517830 has been marked as a duplicate of this bug. ***
Comment 9 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-10-27 14:07:28 UTC
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.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-10-27 17:36:29 UTC
I can confirm that a few random packages and kdelibs build fine against the new version.
Comment 11 David Kredba 2014-10-28 15:58:25 UTC
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.
Comment 12 Davide Pesavento gentoo-dev 2014-10-31 02:53:33 UTC
Yes, I'll move it this weekend, then ask arches to keyword qtchooser.
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-11-01 23:34:01 UTC
(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 :).
Comment 14 Paweł Stankowski 2014-11-02 02:20:30 UTC
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.
Comment 15 Paweł Stankowski 2014-11-02 02:32:41 UTC
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.
Comment 16 Andrés Becerra Sandoval 2014-11-05 16:45:46 UTC
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.
Comment 17 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-11-06 14:08:06 UTC
(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.
Comment 18 Andrés Becerra Sandoval 2014-11-06 21:44:21 UTC
(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
Comment 19 Davide Pesavento gentoo-dev 2014-11-06 22:09:21 UTC
(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.
Comment 20 John J. Aylward 2014-11-06 22:18:37 UTC
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?
Comment 21 Davide Pesavento gentoo-dev 2014-11-06 22:28:39 UTC
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.
Comment 22 Andrés Becerra Sandoval 2014-11-06 22:40:53 UTC
(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?
Comment 23 Andrés Becerra Sandoval 2014-11-07 21:33:41 UTC
(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.
Comment 24 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-11-10 21:41:47 UTC
(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.
Comment 25 Davide Pesavento gentoo-dev 2014-11-15 02:49:29 UTC
In tree.
Comment 26 David Kredba 2014-11-19 17:04:29 UTC
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 ~.
Comment 27 Manuel Rüger (RETIRED) gentoo-dev 2014-11-19 18:27:44 UTC
(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?
Comment 28 Davide Pesavento gentoo-dev 2014-11-20 02:19:06 UTC
(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!
Comment 29 Nikos Chantziaras 2014-11-20 04:57:50 UTC
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
Comment 30 Nikos Chantziaras 2014-11-20 05:52:45 UTC
(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.
Comment 31 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-11-20 08:50:52 UTC
Exactly. More specifically, keep it out of @world and portage would unmerge it itself.