From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 38D0B1388C0 for ; Sun, 28 Feb 2016 19:04:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC1DE21C02B; Sun, 28 Feb 2016 19:03:44 +0000 (UTC) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B25A121C001 for ; Sun, 28 Feb 2016 19:03:38 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id p65so43122772wmp.1 for ; Sun, 28 Feb 2016 11:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=2Qye12vPCy1s2LNJrVScB0dBvNEDB6DlqEMtCt0/D2o=; b=nFF3xYW24CbMEtJ97PLDLKcGJM47ZXViFAPkw960RPh+ss4aOfFHHEkeLGcZJrx2yS SfBJ8s56e1uOefkhX90I5RAUd3XaNOjNSukuQTIdty3kW61kdjV37aCCeLR0wWlEGhG4 LlYzFApYoCziZ79fHdZicDNM9YMWD9jIOTLiLP0UKpVj2nJu1JchR32IKjGXYmVrl73Q LfBe47cbuzTK2pwnsHcAceFFWPxEGHiP8E2htHYKcs03RTGzkBZl/fb4XhwfRfLVHDwV IfIZF+RRVLo6rE1WjRvmdm17AwnMFn5wF4j4Zl/W0jOL51cBboy/k5G62uXFjaPqJG7k I7ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2Qye12vPCy1s2LNJrVScB0dBvNEDB6DlqEMtCt0/D2o=; b=WvFo7TWzphQ5WxQxiYJHC8ACBVcdWOqw/8QyP7akOAwsTADcPUc3HjJ3CLN7uGaDCf mKE7VqClMhD3dGpsk/qe6UR6BYGxuNZPnBXPPVe43OvsHY6hmXQrU5V3seFL48yGSlGo K/Z5OBWa52PiaBgaUXzep2mn7BA2z5SKBHJpbUBP4iR0DDLKPl6AjUY7qQB+AT/B+BAm ijhjIxTH6M+y/AmxDaS+v//iwzJiurR/FMO6MmJVYhPgW0xGYvZtb9Lt1D4tckO6tC1B PsuKd8so1gsnEGyVehy2JILgvK10dRNl/eWCnBUXVBavhsVP7nCeSEKX1pKzoCryp6s7 h1qQ== X-Gm-Message-State: AD7BkJJbVp5Wvw0sSfBdLYsHHtYsaAmb0uMeK1jQvjcmP3p4AUjAV+JRdOA6L8N1EmCZpA== X-Received: by 10.28.14.140 with SMTP id 134mr7541783wmo.39.1456686217502; Sun, 28 Feb 2016 11:03:37 -0800 (PST) Received: from [172.20.0.40] ([165.255.114.147]) by smtp.googlemail.com with ESMTPSA id 74sm12809894wmn.17.2016.02.28.11.03.35 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 11:03:36 -0800 (PST) Subject: Re: [gentoo-user] useflag hell. To: gentoo-user@lists.gentoo.org References: <56D33906.10501@verizon.net> From: Alan McKinnon X-Enigmail-Draft-Status: N1110 Message-ID: <56D3441C.2060909@gmail.com> Date: Sun, 28 Feb 2016 21:01:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <56D33906.10501@verizon.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: c6472b5e-364d-4a0b-9eb6-49f8d4413340 X-Archives-Hash: e00cebdcf7597638f232414322f369b2 On 28/02/2016 20:14, Alan Grimes wrote: > I've been running number theory code for a few weeks, so haven't been > updating my machine too often... > > I for the last day or so I'm in a run my "pretendupdate" script, look at > the results, decide whether to run ufed or bleep with package.use.... > run the pretendupdate script again, do something while it computes, come > back to it hours later, and repeat the cycle... This is really getting > silly and I'm starting to suspect that I'm stuck in useflag hell and > there isn't a solution to this. There's always a solution, and they are seldom hard to solve. However, portage doesn't exactly make it easy for you with the output. Mere information is often obfuscated and looks like stuff you must fix, whereas the real nuggets can be hidden in the noise. Often running without -v can help considerably. So, here goes, comments inline > > > > > tortoise ~ # ./pretendupdate > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > > !!! Multiple package instances within a single package slot have been pulled > !!! into the dependency graph, resulting in a slot conflict: > > dev-libs/icu:0 > > (dev-libs/icu-56.1:0/56::gentoo, ebuild scheduled for merge) pulled in by > (no parents that aren't satisfied by other packages in this slot) > > (dev-libs/icu-55.1:0/55::gentoo, installed) pulled in by > dev-libs/icu:0/55=[abi_x86_32(-),abi_x86_64(-)] required by > (dev-qt/qtcore-4.8.7-r1:4/4::gentoo, installed) > > ^^^^^^ Despite what it looks like all this is mere information. Two separate things result in different version of Qt being pulled into the problem solution. And it's exactly the form you'd expect. The first chunk is really saying that icu-56.1 is the most recent version and all other things being equal, that's the one portage would install. The second chunk is saying that qtcore-4.8.7-r1 requires icu-55.1 (not the most recent), so portage spews forth heaps of junk to helpfully let you not figure it out. What portage really should say is more like: Most recent version of icu (icu-56.1) not installed due to these requirements: qtcore-4.8.7-r1 requires icu-55.1 Ignore the multiple OMG! bangs before all of the above output > > > > It may be possible to solve this problem by using package.mask to > prevent one of those packages from being selected. However, it is also > possible that conflicting dependencies exist such that they are > impossible to satisfy simultaneously. If such a conflict exists in > the dependencies of two different packages, then those packages can > not be installed simultaneously. > > For more information, see MASKED PACKAGES section in the emerge man > page or refer to the Gentoo Handbook. > > > !!! The ebuild selected to satisfy > ">=media-libs/mlt-0.9.8-r1[ffmpeg,kdenlive,melt,qt5,sdl,xml]" has unmet > requirements. This is the expression portage needs to install based on dependencies, most recent version, maskings, and your USE flags. It's informational. > - media-libs/mlt-0.9.8-r2::gentoo USE="ffmpeg fftw gtk kde kdenlive lua > melt opengl python qt5 sdl xine xml -compressed-lumas -debug -frei0r > -jack -libav -libsamplerate -qt4 -rtaudio (-ruby) -vdpau" ABI_X86="64" > CPU_FLAGS_X86="mmx sse sse2" PYTHON_TARGETS="python2_7" > > The following REQUIRED_USE flag constraints are unsatisfied: > kde? ( qt4 ) This is the actual problem, According to the ebuild, if you set USE="kde", then you also need USE="qt4". Your USE has qt5 enabled, and that's the problem. Presumably, mtl does not yet support KDE with Qt5 > > The above constraints are a subset of the following complete expression: > python? ( python_targets_python2_7 ) qt5? ( !qt4 ) kde? ( qt4 ) And this is the helpful gigantic USE expression, all of which must be satisfied to install mlt. The bit above this shows just the part that is problematic, so this is also informational. Note > > (dependency required by "kde-apps/kdenlive-15.12.1::gentoo" [ebuild]) > (dependency required by "kde-apps/kdemultimedia-meta-15.12.1-r1::gentoo" > [ebuild]) > (dependency required by "kde-apps/kde-apps-meta-15.08.3-r3::gentoo" > [ebuild]) > (dependency required by "kde-apps/kde-meta-15.08.3::gentoo" [ebuild]) > (dependency required by "@selected" [set]) > (dependency required by "@world" [argument]) And the is a part of the full dep tree that leads to mlt being included > tortoise ~ # > > > ###################### > > > The attached files are whatever is left after --- six years of resolving > similar issues on this same install... What you need to do now is set one of the following combinations in package.use for mlt: USE=-kde qt4 -qt5 USE=kde qt4 -qt5 On a plasma system like you have this will probably cause similar issues for other packages, so you must iteratively solve those as well till no more inconsistencies remain. Portage does an atrocious job of presenting it's output to you, but essentially it's a problem in graph theory and detecting mutually incompatible data. -- Alan McKinnon alan.mckinnon@gmail.com