|Summary:||[TRACKER] Qt5 unmasking|
|Product:||Gentoo Linux||Reporter:||Davide Pesavento <pesa>|
|Component:||[OLD] Development||Assignee:||Qt Bug Alias <qt>|
|Severity:||normal||CC:||aarondoom, alex, ansla80, anton.wd, b.brachaczek, bugzilla, carlphilippreh, cognifloyd+gentoobugs, cruzki123, doug.hunley, egorov_egor, esigra, eugene.shalygin, evan.teran, gef.kornflakes, gentoo, gentoo, genzilla, jacobgodserv, Jens.Rutschmann, jer, joost.ruis, josef64, jrmalaq, karl.j.linden, kde, kjackie, kripton, losier.cc, maggu2810, malte_e1, Manfred.Knick, manyac, mexahotabop, mihais23, mike, milo000, milosvova, mmk, mrueg, news.gdc, nikoli, nucrap, olemarkus, orzel, paul, qh, rafalklys, reagentoo, reivzy, robink, saintdev, sven.eden, sven.koehler, tdalman, tomboy64, ua_gentoo_bugzilla, uwelk, vdupras, vivo75, voron1, walch.martin, waynedpj, xaviermiller, yuriy, zeekec, zzam|
|Package list:||Runtime testing required:||---|
|Bug 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|
|Bug Blocks:||514450, 530152, 450412, 459918, 477484, 479638, 488640, 488646, 489508, 499576, 504604, 513478, 515692, 516864, 517866, 521484, 522274, 524390, 525410, 527066, 537002|
Description Davide Pesavento 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 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 6 Davide Pesavento 2014-08-29 23:59:31 UTC
30 Aug 2014; Davide Pesavento <email@example.com> +qt5-build.eclass: Initial commit of qt5-build.eclass
Comment 7 Davide Pesavento 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) 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) 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) 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) 2015-02-01 10:58:13 UTC
+ 01 Feb 2015; Ben de Groot <firstname.lastname@example.org> base/use.mask, package.mask: + Unmask Qt5
Comment 20 Davide Pesavento 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) 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.