From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.chez-thomas.org (mail.mlbassoc.com [65.100.170.105]) by mail.openembedded.org (Postfix) with ESMTP id B2EEB6D2E6 for ; Wed, 23 Oct 2013 17:13:31 +0000 (UTC) Received: by mail.chez-thomas.org (Postfix, from userid 1998) id 89BD1F8120C; Wed, 23 Oct 2013 11:13:33 -0600 (MDT) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hermes.chez-thomas.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.3.2 Received: from [192.168.1.114] (zeus [192.168.1.114]) by mail.chez-thomas.org (Postfix) with ESMTP id 2F01AF8120A; Wed, 23 Oct 2013 11:13:30 -0600 (MDT) Message-ID: <526803BD.8010106@mlbassoc.com> Date: Wed, 23 Oct 2013 11:13:33 -0600 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Burton, Ross" References: <5267D269.2020701@mlbassoc.com> In-Reply-To: Cc: OE-core Subject: Re: Mesa mess X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:13:33 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-10-23 08:07, Burton, Ross wrote: > On 23 October 2013 14:43, Gary Thomas wrote: >> With the current master (Poky ffb440c37c), I can't build anything >> with a virtual/mesa requirement. This seems to bring in both mesa >> and mesa-gl, which fight to the death, killing the build :-( > > Presumably you want just mesa-gl? > > I guess your distro is setting a preferred provider for > virtual/something to mesa-gl, and something else is pulling in mesa, > probably through a default. Can you check that all of the > mesa-related virtual/* lines are set in your distro, my hunch is that > you don't have virtual/mesa set to mesa-gl. > > If the distro looks right then try using depexp to see what is pulling > in mesa when it shouldn't be? I looked through this and nothing was obvious. According to depmod, neither mesa nor mesa-gl have any direct "reverse depends", i.e. packages that depend on them. As far as I can see, it's just coming from the xserver-xorg dependency on virtual/mesa. Which led me to another experiment which I truly do not understand. I removed the mesa-gl recipe and now when I try to build 'virtual/mesa' I get a message that there is no provider :-( However, I *can* build mesa with no problems. I also checked it against the other PROVIDES from mesa.inc and all of them except for virtual/mesa work. How can this possibly be? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------