I had hit bug 508806. It was later closed as duplicate of bug 484624, and I'm not exactly sure that it is correct ... that one talks mostly about the default choice. But I've already done the choice, I have "qt4" in USE in make.conf, so this choice should be honoured. This does not happen, and instead I'm told the error is on my side. But I've ruled out the error in the begining by checking the settings via the 'euse' tool, it says I have "-gtk3" and "+qt4". If the developers insist that I have "+gtk3" then the error has to be in the 'euse' tool then. So I've filed bug #511186 for this. However, this one got closed as duplicate of bug 508806. I consider this wrong, bug 508806 is about the inability to emerge wireshark with my settings while bug 511186 is about the euse tool reporting the settings wrongly. If 'euse' says [- ] gtk3 (net-analyzer/wireshark): but 'emerge' treats the setting as "+gtk3" then they need to be fixed not to contradict each other. If this cannot be fixed properly then at least a big fat warning "THIS MAY BE INCORRECT" should be present visibly. (ATM, I see no mention about that neither in 'euse' output neither in 'euse' manpage). As the developers responsible for the situation around wireshark refuse to work for benefit of the users insisting that the default chosen by them is better than the defaults chosen by the user and should override them, and they even sabotage fixing gentoolkit (the 'euse' tool) by improperly closing the bugs, I believe this unfortunate situation should be taken care of somehow. Reproducible: Always Steps to Reproduce: 1. try to suggest that ebuilds should honour users wishes and respect USE flags Actual Results: we (the devolopers) know better than you (the users) what and how do you want to have installed Expected Results: the ebuild is fixed Note that bug 508806 has broken 'emerge world' for me without any action on my side, just updating. I believe, once upon a time, I've read that such behaviour is unacceptable, that updates in stable should always work without the user having to do any fixes/adjustments, so that automated security updates won't get blocked ...
(In reply to kavol from comment #0) > I had hit bug 508806. > It was later closed as duplicate of bug 484624, and I'm not exactly sure > that it is correct ... that one talks mostly about the default choice. > But I've already done the choice, I have "qt4" in USE in make.conf, so this > choice should be honoured. This does not happen, and instead I'm told the > error is on my side. > > But I've ruled out the error in the begining by checking the settings via > the 'euse' tool, it says I have "-gtk3" and "+qt4". > If the developers insist that I have "+gtk3" then the error has to be in the > 'euse' tool then. So I've filed bug #511186 for this. > > However, this one got closed as duplicate of bug 508806. I don't see what is wrong from Jeroen side here, you are getting the block because emerge tries to build wireshark with USE "gtk3" (from +gtk3 in ebuild) and "qt4" (from your setting) and, then, you need to run "echo net-analyzer/wireshark -gtk3 qt4 >> /etc/portage/package.use" Please run "man euse" and see "BUGS" section What is your profile? If qt4 comes from a profile, that profile should include some lines to either force qt4 for wireshark or disable qt4 for that enabling gtk3
(In reply to Pacho Ramos from comment #1) > I don't see what is wrong from Jeroen side here, you are getting the block > because emerge tries to build wireshark with USE "gtk3" (from +gtk3 in > ebuild) and "qt4" (from your setting) and, then, you need to run "echo > net-analyzer/wireshark -gtk3 qt4 >> /etc/portage/package.use" from my POV, what is wrong is that once I have qt4 set, and only one of gtk2, gtk3 and qt4 is required, it should no longer try to set gtk3 at least not in this way that it blocks updates meanwhile, I've found this: http://devmanual.gentoo.org/general-concepts/use-flags/ and it says "Occasionally, ebuilds will have conflicting USE flags for functionality. Checking for them and returning an error is not a viable solution. Instead, you must pick one of the USE flags in conflict to favour and should alert the user that a particular flag is being used instead." the current state breaks that rule > Please run "man euse" and see "BUGS" section so ... BUGS euse doesn't handle USE flags enabled or disabled by use.defaults, use.mask or package.use yet. It also doesn't completely understand the -* flag. 1) I don't have any "use.defaults" 2) if I get the dependencies right, relevant to me are: /usr/portage/profiles/default/linux/use.mask /etc/portage/profile/use.mask none of them mentions gtk3 nor qt4 3) same as above, relevant should be /etc/portage/package.use there is no mention about gtk3 or qt4 too not sure if I understand completely what is "-*" about, but I'd say it is irrelevant too so, to my best understanding, this has nothing to do with those documented problems > What is your profile? [9] default/linux/amd64/13.0/no-multilib * > If qt4 comes from a profile, that profile should include some lines to either > force qt4 for wireshark or disable qt4 for that enabling gtk3 no, I have it in make.conf; no profile seems to set this
(In reply to kavol from comment #2) > (In reply to Pacho Ramos from comment #1) > > I don't see what is wrong from Jeroen side here, you are getting the block > > because emerge tries to build wireshark with USE "gtk3" (from +gtk3 in > > ebuild) and "qt4" (from your setting) and, then, you need to run "echo > > net-analyzer/wireshark -gtk3 qt4 >> /etc/portage/package.use" > > from my POV, what is wrong is that once I have qt4 set, and only one of > gtk2, gtk3 and qt4 is required, it should no longer try to set gtk3 That cannot be done currently, what can be done is to try to prevent this blockade when a profile enabled qt4 > > at least not in this way that it blocks updates > > meanwhile, I've found this: > http://devmanual.gentoo.org/general-concepts/use-flags/ > > and it says > "Occasionally, ebuilds will have conflicting USE flags for functionality. > Checking for them and returning an error is not a viable solution. Instead, > you must pick one of the USE flags in conflict to favour and should alert > the user that a particular flag is being used instead." > > the current state breaks that rule As soon as ebuild needs to rely on REQUIRED_USE to prevent users from setting colliding features we cannot do much more. Also, I see Jeroen has explained this reasoning in comment #27 from bug 484624 [...] > so, to my best understanding, this has nothing to do with those documented > problems > euse is not getting the default from ebuild itself (see the default USE flags introduced in eapi1: http://devmanual.gentoo.org/ebuild-writing/eapi/index.html ) > > What is your profile? > > [9] default/linux/amd64/13.0/no-multilib * > > > If qt4 comes from a profile, that profile should include some lines to either > > force qt4 for wireshark or disable qt4 for that enabling gtk3 > > no, I have it in make.conf; no profile seems to set this Then, what you need to do is to play with package.use to satisfy the dep (as explained in handbook) Personally I still don't see any issue involving comrel problem here :|
I don't see why comrel is here. This is a technical problem not a behavioral one.
wireshark 1.10.x has this limitation, wireshark 1.11.x doesn't. I don't know what euse is doing, but I have no issues fixing this in /etc/portage/profile/package.use
maybe we could fix this in the kde profile by adding a package.use for wireshark and dropping the qt4 use flag?
Hello, as a QA team member, no direct QA related problem is visible here; we can try to help steer this in the right direction for both the maintainer and user. (In reply to kavol from comment #0) > I had hit bug 508806. > It was later closed as duplicate of bug 484624, and I'm not exactly sure > that it is correct ... that one talks mostly about the default choice. > But I've already done the choice, I have "qt4" in USE in make.conf, so this > choice should be honoured. This does not happen, and instead I'm told the > error is on my side. If you want Qt 4, you need to disable the default enabled GTK+ 3; the package works this way upstream, as it only builds for one toolkit at a time. Reference: https://bugs.gentoo.org/show_bug.cgi?id=484624#c23 One could go ahead and defer from upstream, but that is tedious and a cost. Reference: https://bugs.gentoo.org/show_bug.cgi?id=484624#c28 It seems planned, thus it might or might not be supported in the future; more progress here involves more manpower, like contributions in the form of patches. > But I've ruled out the error in the begining by checking the settings via > the 'euse' tool, it says I have "-gtk3" and "+qt4". > If the developers insist that I have "+gtk3" then the error has to be in the > 'euse' tool then. So I've filed bug #511186 for this. euse checks the state on your system, it doesn't take into account USE_ORDER properly; so, IUSE="... +gtk3 ..." is neglected. This could be considered a bug; next time try to file the bug again and focus on the actual problem, just leave out the mentions of other bugs, packages and persons to avoid side tracking. Reference: https://bugs.gentoo.org/show_bug.cgi?id=511186#c1 But let me try to do that for you first, I've changed and reassigned above bug. Please let both maintainers progress with bug #484624 and/or bug #511186 first; both are open and have recent activity, please give them some time to proceed. Thank you very much in advance.
The wireshark issue has been fixed for users of the desktop/* profiles. If you set qt4 in your own make.conf instead of using the profile then you should be smart enough to learn to use package.use as well.
(In reply to Rick Farina (Zero_Chaos) from comment #8) > The wireshark issue has been fixed for users of the desktop/* profiles. If > you set qt4 in your own make.conf instead of using the profile then you > should be smart enough to learn to use package.use as well. So the solution originally suggested as part of bug #484624 is now implemented. *** This bug has been marked as a duplicate of bug 484624 ***
