On Wed, Jan 8, 2014 at 3:01 PM, Richard Purdie < [email protected]> 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 <[email protected]> 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. > > > >> 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. > I prefer 1 too. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
