[OE-core] Piglit in Poky

[Philip Balister]

On 01/08/2014 12:01 PM, Richard Purdie wrote:
> On Wed, 2014-01-08 at 16:09 +0000, Burton, Ross wrote:
>> Hi,
>>
>> Despite a good start this thread got rapidly hijacked, so let's try again!
>>
>> On 24 December 2013 01:09, Philip Balister <philip at balister.org> wrote:
>>>> 1) Move piglit and deps to oe-core.  Piglit is for QA purposes only
>>>> and pushes the boundaries of "core platform".  In a sense this is a
>>>> repeat of the discussion we had with Midori...  does oe-core contain
>>>> everything needed to sufficiently exercise the core components it
>>>> ships or not?
>>>
>>> I expect Richard will push back on this, and I would support him here.
>>
>> Probably best to let Richard speak for himself here. :)
> 
> :)
> 
> I have to admit I'm leaning towards pulling in the 4 recipes we need
> since the win is we get to test the GL stacks.
> 
> We do support graphics in the core, we also do particularly badly at
> testing it. That is something I think we need to change. piglit lets us
> do that and its not like it has a significant number of dependencies.
> Having a couple more python modules to test the python stack probably
> isn't a bad idea ether. We pruned quite a number of recipes out, this is
> a case where we can add a small number for a significant win.

Does this mean you will fix the host contamination that occurs when
machines have atals and/or blas devel packages installed :)

We should probably look carefully at the numpy recipe if we go this route,

Philip

> 
>>>> 2) Add piglit and deps to meta-yocto.  Probably a new layer called
>>>> meta-yocto-qa (or similar) because the Yocto Compatible guidelines
>>>> forbid mixing distribution policy and recipes.  We'd need to sync
>>>> meta-yocto-qa with the pieces of meta-oe that we want somehow, but
>>>> that's our problem.
>>>
>>> So meta-yocto is right out. I'm a user of numpy, and I certainly do not
>>> want to include something called meta-yocto-qa just to pick up numpy.
>>
>> Right, so my point with the syncing was that this meta-yocto-qa layer
>> would be a copy of recipes from other places through combo-layer, and
>> would be clearly marked as such.
>>
>> Reviewing the options:
>>
>> 1) Add python-mako, python-numpy, waffle and piglit to oe-core, for
>> all BSPs to use.
>> 2) Add python-mako, python-numpy, waffle and piglit to meta-yocto
>> (effectively read-only clones with combo-layer, maintained in meta-oe
>> still) for Poky to use.
>> 3) Add meta-python layer to Poky, and waffle/piglit to meta-yocto
>> (read-only clones) for Poky to use.
>>
>> Paul raises a good point about other BSPs potentially using Piglit to
>> test their GL stacks.  Do any other BSPs test their GL integration,
>> and if so what tooling to they use?  I'm only pushing for Piglit
>> because it's what the Intel driver team use to test Mesa, but if
>> nobody else wants to use it then that's an argument for keeping it in
>> Poky (or even cloning it into meta-intel?).
> 
> I'm in favour of 1). If there is significant community push back against
> that, I will go for 4) a kind of hybrid of 2/3 which is:
> 
> 4) use combo-layer filtering technology to import just the files we want
> from the meta-oe repo into the poky repo.
> 
> The plus of 4) is that it would showcase a usage of combo-layer which is
> currently underused and IMO should be used more. Equally, I think 4)
> might not be liked by some. If would however fulfil the needs the Yocto
> Project has in this area.
> 
> I would still prefer 1) though.
> 
> Cheers,
> 
> Richard
> 
> 
> 
>