From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 24504E005B9; Tue, 12 May 2015 21:09:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 68C5AE00477 for ; Tue, 12 May 2015 21:09:11 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id D21EC60014CC; Wed, 13 May 2015 07:09:09 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1431490150; bh=eTZilE0tlSjBwmG9uFG8QosaM+kLHvbLS908wzCV7z4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CnXUH1k4BbP96l6TQkqEtfSBM6Ae1AvM+AM8bX0DS/nz2sQ3LRfR61L8x9CPhJ2ko kS8xlqBgevHnoW3v/lChU6No26ghHf3U+QFtc5oBY6DPM9vVClp+IK7ZUvIx8zibhQ HLM/Qnb4nlEwv5Ats7n8lqpv7Ay0CnHgrnIw7Z/M= Message-ID: <5552CE65.8030507@mail.bg> Date: Wed, 13 May 2015 07:09:09 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Otavio Salvador References: <1430408987-24977-1-git-send-email-picmaster@mail.bg> <1430408987-24977-2-git-send-email-picmaster@mail.bg> <5550DC19.80308@mail.bg> <5550E5E3.5090502@mail.bg> <55513E7A.4060304@mail.bg> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-demos][PATCH] riotboard: Fix broken image builds against linux-fslc X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 04:09:15 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Otavio, On 05/12/2015 03:41 PM, Otavio Salvador wrote: > On Mon, May 11, 2015 at 8:42 PM, Nikolay Dimitrov wrote: >> On 05/11/2015 08:46 PM, Otavio Salvador wrote: >>> On Mon, May 11, 2015 at 2:24 PM, Nikolay Dimitrov >>> wrote: >>>> >>>> Hi Otavio, >>>> >>>> On 05/11/2015 08:09 PM, Otavio Salvador wrote: >>>>> >>>>> >>>>> On Mon, May 11, 2015 at 1:43 PM, Nikolay Dimitrov >>>>> wrote: >>>>>> >>>>>> >>>>>> Ping. >>>>> >>>>> >>>>> >>>>> I am building it here for testing. >>>> >>>> >>>> >>>> That's great, thanks for looking into it. >>> >>> >>> Your patch can get a change: >>> >>> diff --git a/conf/machine/imx6dl-riotboard.conf >>> b/conf/machine/imx6dl-riotboard.conf index bf50eaf..260deed 100644 >>> --- a/conf/machine/imx6dl-riotboard.conf +++ >>> b/conf/machine/imx6dl-riotboard.conf @@ -19,4 +19,4 @@ SERIAL_CONSOLE >>> = "115200 ttymxc1" # FIXME: Workaround for building against >>> linux-fslc MACHINE_EXTRA_RRECOMMENDS_remove = "fsl-alsa-plugins" >>> PREFERRED_VERSION_imx-test = "00.00.00" -MACHINE_GSTREAMER_PLUGIN = >>> "" +MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard = "" >>> >>> This makes the patch in meta-fsl-demos not needed and seems cleaner. >>> >>> Can you take a look and confirm? >> >> >> This code sits in riotboard-specific conf file, so there's no difference >> between MACHINE_GSTREAMER_PLUGIN and >> MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard variables. The machine suffix >> is redundant in the 2nd case. But even if I use the proposed >> MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard, the fsl-image-multimedia-full >> image build still fails. > > I reproduced it here. It fails only with X11 and my test was using > Framebuffer. I have sent a patch for review. The patch looks ok to me. I suppose that after this fix, the RDEPENDS hack for imx6sl is not needed anymore? >> Regarding the meta-fsl-demos patch - the need for this fix is because >> the packagegroup-fsl-gstreamer-full.bb is again adding the >> gst-plugins-gl dependency, disregarding the available capabilities >> (either hardware or kernel). > > See above. > >> So, my motivation for doing it this way for short term is the following: >> 1. I still have single kernel to maintain (fslc) as of today. >> 2. The board builds are broken at least since 23.April and I have to do >> something about it. >> >> FYI, for a long-term solution I plan to do the following, if you agree: >> - Support building multiple kernels, including both FSL and FSLC >> - Somehow declare the capabilities of the hardware/kernel and take it >> into account by in recipes. We need something like KERNEL_FEATURES and >> MACHINE_FEATURES, and only if a feature is declared by both variables, >> then it should be used (not sure whether this is the same as the >> COMBINED_FEATURES mechanism). I'm looking towards your ideas here, as >> you guys have much more Yocto experience than me. >> >> To summarize: my patch set is not perfect, but as of today we don't >> have all the ingredients to make it perfect. Tomorrow we could have >> these ingredients, but I can't see how far is this tomorrow. > > The biggest challenge here is how to express KERNEL_FEATURES which are > recipe/provider specific. > > We have some providers: > > linux-fslc > linux-imx > linux- > > and each can provide different kernel features. I agree with the long > term plan but I didn't yet came up with something which scales and > work. I'll reiterate my thoughts - it's not only the kernel features. All the parts in the system need to consider a feature, before it's built: - hardware - kernel - userspace A feature shouldn't be compiled and/or deployed in the image unless all the system parts confirm its support, otherwise we'll have a failed build or runtime issues. With my current limited knowledge I see 2 basic paths for implementing this: - 1 shared variable per feature, which is mangled across the recipes/layers (the usual enable/disable dance); - mechanism similar to COMBINED_FEATURES, which needs to "AND" 2 or more sets of variables across the system. This is already done implicitly in lots of places with heavy usage of $base_contains, but it's not easy to read and explicit. // board.conf MACHINE_FEATURES += "opengl" // kernel provider KERNEL_FEATURES += "opengl" // image or recipe should check features indirectly XXXXXXX_append = "${base_contains('COMBINED_FEATURES', 'opengl', 'gst-plugins-gl', '', d)} Something like this... Regards, Nikolay