From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 23167E008D0; Wed, 1 Mar 2017 07:12:40 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KHOP_DYNAMIC autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 KHOP_DYNAMIC Relay looks like a dynamic address Received: from dan.rpsys.net (5751f4a1.skybroadband.com [87.81.244.161]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 56231E0082A for ; Wed, 1 Mar 2017 07:12:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v21FCOGK005165; Wed, 1 Mar 2017 15:12:24 GMT Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HcmqMz0rZfzD; Wed, 1 Mar 2017 15:12:24 +0000 (GMT) Received: from hex ([192.168.3.34]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v21FCJff005153 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 1 Mar 2017 15:12:20 GMT Message-ID: <1488381139.24526.30.camel@linuxfoundation.org> From: Richard Purdie To: Patrick Ohly Date: Wed, 01 Mar 2017 15:12:19 +0000 In-Reply-To: <1488352225.7785.83.camel@intel.com> References: <1487625169-22282-1-git-send-email-anibal.limon@linux.intel.com> <1488312568.7785.73.camel@intel.com> <1488340816.24526.26.camel@linuxfoundation.org> <1488352225.7785.83.camel@intel.com> X-Mailer: Evolution 3.18.5.2-0ubuntu3.1 Mime-Version: 1.0 Cc: yocto@yoctoproject.org, openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:12:40 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote: > On Wed, 2017-03-01 at 04:00 +0000, Richard Purdie wrote: > > > > On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote: > > > > > > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > > > > > > > > > > > > common.test_signatures: Test executed in BSP and DISTRO layers > > > > to > > > > review > > > >     doesn't comes with recipes that changes the signatures. > > > I have a question about the goal for this test: is it meant to > > > detect > > > layers which incorrectly change the signatures of allarch recipes > > > or > > > recipes which share the same tune flags with other machines? > > > > > > Let's take MACHINE=edison as an example. > > The test is not for these things. Its using the sstate signatures > > for > > something different compared to those other tests. > > > > The idea is that if you have a set of layers and generate the > > signatures for world, then you add say a BSP layer but do not > > select > > that MACHINE, the signatures should remain unchanged. > That's useful too, of course. > > Is the "build single distro for different machines" scenario that I > described part of the Yocto Compliance 2.0? Should there be tests for > it? Right now its not but I'd consider it. The question is can we write an easy generic test for it, and also clearly phrase the criteria in the list of compliance questions with a binary yes/no answer? Cheers, Richard From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dan.rpsys.net (5751f4a1.skybroadband.com [87.81.244.161]) by mail.openembedded.org (Postfix) with ESMTP id 4404B730A4 for ; Wed, 1 Mar 2017 15:12:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v21FCOGK005165; Wed, 1 Mar 2017 15:12:24 GMT Received: from dan.rpsys.net ([127.0.0.1]) by localhost (dan.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HcmqMz0rZfzD; Wed, 1 Mar 2017 15:12:24 +0000 (GMT) Received: from hex ([192.168.3.34]) (authenticated bits=0) by dan.rpsys.net (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v21FCJff005153 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 1 Mar 2017 15:12:20 GMT Message-ID: <1488381139.24526.30.camel@linuxfoundation.org> From: Richard Purdie To: Patrick Ohly Date: Wed, 01 Mar 2017 15:12:19 +0000 In-Reply-To: <1488352225.7785.83.camel@intel.com> References: <1487625169-22282-1-git-send-email-anibal.limon@linux.intel.com> <1488312568.7785.73.camel@intel.com> <1488340816.24526.26.camel@linuxfoundation.org> <1488352225.7785.83.camel@intel.com> X-Mailer: Evolution 3.18.5.2-0ubuntu3.1 Mime-Version: 1.0 Cc: yocto@yoctoproject.org, openembedded-core@lists.openembedded.org Subject: Re: [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation 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, 01 Mar 2017 15:12:33 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote: > On Wed, 2017-03-01 at 04:00 +0000, Richard Purdie wrote: > > > > On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote: > > > > > > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > > > > > > > > > > > > common.test_signatures: Test executed in BSP and DISTRO layers > > > > to > > > > review > > > >     doesn't comes with recipes that changes the signatures. > > > I have a question about the goal for this test: is it meant to > > > detect > > > layers which incorrectly change the signatures of allarch recipes > > > or > > > recipes which share the same tune flags with other machines? > > > > > > Let's take MACHINE=edison as an example. > > The test is not for these things. Its using the sstate signatures > > for > > something different compared to those other tests. > > > > The idea is that if you have a set of layers and generate the > > signatures for world, then you add say a BSP layer but do not > > select > > that MACHINE, the signatures should remain unchanged. > That's useful too, of course. > > Is the "build single distro for different machines" scenario that I > described part of the Yocto Compliance 2.0? Should there be tests for > it? Right now its not but I'd consider it. The question is can we write an easy generic test for it, and also clearly phrase the criteria in the list of compliance questions with a binary yes/no answer? Cheers, Richard