Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 454132 (qt5-porting) - [TRACKER] Qt5 unmasking
Summary: [TRACKER] Qt5 unmasking
Status: RESOLVED FIXED
Alias: qt5-porting
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal with 18 votes (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords: Tracker
Depends on: 328689 433956 448178 450492 451456 457024 457174 458582 459690 462216 462218 466216 471602 477766 483648 489278 490254 496800 504322 510556 510698 511042 511594 512726 517532 517714 518262 518542 519190 519860 522382 523122 523124 532140 532962
Blocks: 514450 530152 450412 459918 477484 479638 488640 488646 489508 499576 504604 513478 515692 516864 517866 521484 522274 524390 525410 527066 537002
  Show dependency tree
 
Reported: 2013-01-26 11:33 UTC by Davide Pesavento
Modified: 2016-08-11 11:27 UTC (History)
67 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 Davide Pesavento gentoo-dev 2013-01-26 11:33:33 UTC
Tracker bug for Qt5 support in portage. All bugs that should be solved before Qt5 can enter the tree must block this tracker.
Comment 1 Johannes Huber (RETIRED) gentoo-dev 2013-04-23 10:10:10 UTC
Add kde in cc as it is needed for kde frameworks 5.
Comment 2 DrSlony 2014-03-25 08:10:11 UTC
Does the lack of activity here indicate that no progress has been made, or just that this issue has not been updated?
Comment 3 Uwe L. Korn 2014-03-25 10:46:59 UTC
There is progress in the issues this bug depends on. The primary reason for this bug is to accumulate other bugs that stop Qt5 from being moved into the tree.
Comment 4 DrSlony 2014-03-25 10:54:48 UTC
Yes, how silly of me :]
Comment 5 Kelly Price 2014-04-27 14:00:38 UTC
Would bug 448178 block this bug?
Comment 6 Davide Pesavento gentoo-dev 2014-08-29 23:59:31 UTC
  30 Aug 2014; Davide Pesavento <pesa@gentoo.org> +qt5-build.eclass:
  Initial commit of qt5-build.eclass
Comment 7 Davide Pesavento gentoo-dev 2014-09-11 01:53:09 UTC
Qt 5.3.1 (-r3) is now in tree, masked.
Comment 8 Paweł Stankowski 2014-10-07 22:25:35 UTC
3 of 6 bugs that left are about WebKit module. If remaining ones are fixed, is it possible to unmask Qt5 but not WebKit?
Comment 9 Malte E. 2014-10-20 02:39:45 UTC
A thought: aren't the non-qtwebkit bugs problems with the specific applications (and their build systems) rather than Qt5? Shouldn't they be fixed by masking the respective package until their build system is fixed or until Qt5 reaches stable, rather than by masking Qt5?
Comment 10 Paweł Stankowski 2014-10-20 05:04:47 UTC
The problem is that when you have both qt 4 and 5 installed, some applications use qt5 and there is no switch to change that behavior. Therefore 'qt4' use flag becomes unpredictable as well when qt5 is installed.
Comment 11 Malte E. 2014-10-20 11:33:44 UTC
I'm aware of the problem. I'm just saying that when a package can't handle Qt dependencies the way we want it, it's an issue with that package, not with Qt. In turn it should be that package that is masked (or at least its qt4/qt5 USE flags), instead of Qt5. Whoever still wants to use those packages can unmask them and or their USE flags and take the necessary precautions, as always. I think it's more important to finally fix all the bugs depending on this bug and maybe get KDE 5 in the tree as well than to make sure those three packages aren't broken.
Comment 12 Michael Palimaka (kensington) gentoo-dev 2014-10-20 11:48:40 UTC
(In reply to Malte E. from comment #9)
> A thought: aren't the non-qtwebkit bugs problems with the specific
> applications (and their build systems) rather than Qt5? Shouldn't they be
> fixed by masking the respective package until their build system is fixed or
> until Qt5 reaches stable, rather than by masking Qt5?

They should be fixed before unmasking because it's not nice to break the tree. They're not what's blocking the unmasking though (we can easily pin the affected packages to Qt 4 if necessary).
Comment 13 Jacob Floyd 2014-12-13 00:27:35 UTC
Does qt5 unmasking depend on qt 4.8.6 unmasking (#530238) because of qtchooser (#529196)?

I've had qt5.3.2 installed on my amd64 box for awhile, but now a @world update is showing conflicts because newer qt5 ebuilds (the eclass?) are requiring dev-qt/qtchooser which requires !<dev-qt/qt*-4.8.6. I don't care about automatic switching between qt5 and qt4 because I only need qt5 for a couple of development apps, not the whole system. I'd rather not have to keyword 4.8.6 just to keep 5.3.2 on my system under portage, especially since 4.8.6 has "known regressions" (#530238, comment 3).
Comment 14 M. B. 2014-12-20 16:23:30 UTC
Sigil 0.7.x also depends on Qt5.
https://bugs.gentoo.org/show_bug.cgi?id=465436
Comment 15 Michael Dec 2014-12-31 19:59:07 UTC
From /usr/portage/profiles/base/use.mask:
># Michael Palimaka <kensington gentoo.org> (1 May 2013)
># Mask until Qt 5 is in portage. (The flag is here already
># to permit the neccessary package preparation.)
>qt5
Since Qt 5 is in portage as qtcore-5.3.2-r1 and newer are available, what is holding back unmasking of qt5 useflag?
Comment 16 Michael Palimaka (kensington) gentoo-dev 2015-01-01 08:31:37 UTC
(In reply to Michael Dec from comment #15)
> From /usr/portage/profiles/base/use.mask:
> ># Michael Palimaka <kensington gentoo.org> (1 May 2013)
> ># Mask until Qt 5 is in portage. (The flag is here already
> ># to permit the neccessary package preparation.)
> >qt5
> Since Qt 5 is in portage as qtcore-5.3.2-r1 and newer are available, what is
> holding back unmasking of qt5 useflag?

The USE flag can't be unmasked until the qt5 packages themselves are unmasked too.
Comment 17 Igor Poboiko 2015-01-15 15:48:18 UTC
I am not quite sure that that is purpose of use.mask.
AFAIK it is made to block flags due to non-availability of dependencies on some architectures, or some stuff being absolutely and completely broken. In our case masking packages should be enough - if user wants something with Qt5, he sets the "qt5" flag and sees that packages are masked; he unmasks packages and becomes happy.

I am not sure though, I guess someone should ask the Q&A team?
Comment 18 Michael Palimaka (kensington) gentoo-dev 2015-01-29 18:18:44 UTC
(In reply to Igor Poboiko from comment #17)
> I am not quite sure that that is purpose of use.mask.
> AFAIK it is made to block flags due to non-availability of dependencies on
> some architectures, or some stuff being absolutely and completely broken. In
> our case masking packages should be enough - if user wants something with
> Qt5, he sets the "qt5" flag and sees that packages are masked; he unmasks
> packages and becomes happy.
> 
> I am not sure though, I guess someone should ask the Q&A team?

Something unmasked cannot depend on something that's masked, the same way the stable package foo cannot have a USE flag pulling a dependency on unstable libbar.
Comment 19 Ben de Groot (RETIRED) gentoo-dev 2015-02-01 10:58:13 UTC
+  01 Feb 2015; Ben de Groot <yngwin@gentoo.org> base/use.mask, package.mask:
+  Unmask Qt5
Comment 20 Davide Pesavento gentoo-dev 2015-02-01 17:54:20 UTC
Why was it p.masked on arches on which it's not keyworded?
Comment 21 Ben de Groot (RETIRED) gentoo-dev 2015-02-02 06:27:40 UTC
(In reply to Davide Pesavento from comment #20)
> Why was it p.masked on arches on which it's not keyworded?

Because repoman was complaining on those arches. Maybe a use.mask might have been enough. Anyway, it gives them an easy target for keywording, and zlogene is already on that.
Comment 22 Ben de Groot (RETIRED) gentoo-dev 2015-03-14 16:20:29 UTC
Qt5 has been unmasked, so this tracker can be considered resolved. The few remaining issues were added as blockers to the stable tracker, bug #543326.