<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 8, 2014 at 3:01 PM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, 2014-01-08 at 16:09 +0000, Burton, Ross wrote:<br>
> Hi,<br>
><br>
> Despite a good start this thread got rapidly hijacked, so let's try again!<br>
><br>
> On 24 December 2013 01:09, Philip Balister <<a href="mailto:philip@balister.org">philip@balister.org</a>> wrote:<br>
> >> 1) Move piglit and deps to oe-core. Piglit is for QA purposes only<br>
> >> and pushes the boundaries of "core platform". In a sense this is a<br>
> >> repeat of the discussion we had with Midori... does oe-core contain<br>
> >> everything needed to sufficiently exercise the core components it<br>
> >> ships or not?<br>
> ><br>
> > I expect Richard will push back on this, and I would support him here.<br>
><br>
> Probably best to let Richard speak for himself here. :)<br>
<br>
</div>:)<br>
<br>
I have to admit I'm leaning towards pulling in the 4 recipes we need<br>
since the win is we get to test the GL stacks.<br>
<br>
We do support graphics in the core, we also do particularly badly at<br>
testing it. That is something I think we need to change. piglit lets us<br>
do that and its not like it has a significant number of dependencies.<br>
Having a couple more python modules to test the python stack probably<br>
isn't a bad idea ether. We pruned quite a number of recipes out, this is<br>
a case where we can add a small number for a significant win.<br>
<div class="im"><br>
> >> 2) Add piglit and deps to meta-yocto. Probably a new layer called<br>
> >> meta-yocto-qa (or similar) because the Yocto Compatible guidelines<br>
> >> forbid mixing distribution policy and recipes. We'd need to sync<br>
> >> meta-yocto-qa with the pieces of meta-oe that we want somehow, but<br>
> >> that's our problem.<br>
> ><br>
> > So meta-yocto is right out. I'm a user of numpy, and I certainly do not<br>
> > want to include something called meta-yocto-qa just to pick up numpy.<br>
><br>
> Right, so my point with the syncing was that this meta-yocto-qa layer<br>
> would be a copy of recipes from other places through combo-layer, and<br>
> would be clearly marked as such.<br>
><br>
> Reviewing the options:<br>
><br>
> 1) Add python-mako, python-numpy, waffle and piglit to oe-core, for<br>
> all BSPs to use.<br>
> 2) Add python-mako, python-numpy, waffle and piglit to meta-yocto<br>
> (effectively read-only clones with combo-layer, maintained in meta-oe<br>
> still) for Poky to use.<br>
> 3) Add meta-python layer to Poky, and waffle/piglit to meta-yocto<br>
> (read-only clones) for Poky to use.<br>
><br>
> Paul raises a good point about other BSPs potentially using Piglit to<br>
> test their GL stacks. Do any other BSPs test their GL integration,<br>
> and if so what tooling to they use? I'm only pushing for Piglit<br>
> because it's what the Intel driver team use to test Mesa, but if<br>
> nobody else wants to use it then that's an argument for keeping it in<br>
> Poky (or even cloning it into meta-intel?).<br>
<br>
</div>I'm in favour of 1). If there is significant community push back against<br>
that, I will go for 4) a kind of hybrid of 2/3 which is:<br>
<br>
4) use combo-layer filtering technology to import just the files we want<br>
from the meta-oe repo into the poky repo.<br>
<br>
The plus of 4) is that it would showcase a usage of combo-layer which is<br>
currently underused and IMO should be used more. Equally, I think 4)<br>
might not be liked by some. If would however fulfil the needs the Yocto<br>
Project has in this area.<br>
<br>
I would still prefer 1) though.<br></blockquote><div><br></div><div>I prefer 1 too. </div></div><div><br></div>-- <br>Otavio Salvador O.S. Systems<br><a href="http://www.ossystems.com.br" target="_blank">http://www.ossystems.com.br</a> <a href="http://code.ossystems.com.br" target="_blank">http://code.ossystems.com.br</a><br>
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750<br>
</div></div>