Re: [OE-core] Piglit in Poky
Hi, Despite a good start this thread got rapidly hijacked, so let's try again! On 24 December 2013 01:09, Philip Balister phi...@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. :) 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?). Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
On Wed, 2014-01-08 at 16:09 +, 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 phi...@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. 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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
On Wed, Jan 8, 2014 at 6:01 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On 24 December 2013 01:09, Philip Balister phi...@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. I am in favor of that too. I would like to use piglit too to test GLES on some of our ARM projects. I am not sure when we can get to do it, but i am definitely interested into that, and it's been on a TODO list for some time now. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
On 01/08/2014 12:01 PM, Richard Purdie wrote: On Wed, 2014-01-08 at 16:09 +, 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 phi...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
On 8 January 2014 18:44, Philip Balister phi...@balister.org wrote: On 01/08/2014 12:01 PM, Richard Purdie wrote: On Wed, 2014-01-08 at 16:09 +, 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 phi...@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, I've looked at it enough to know I don't want to look at it anymore. ;) Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
On Sun, Dec 29, 2013 at 04:44:52PM +0100, Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philip Balister schreef op 28-12-13 23:33: On 12/28/2013 10:28 AM, Koen Kooi wrote: Paul Eggleton schreef op 28-12-13 12:48: Hi Koen, On Tuesday 24 December 2013 15:22:32 Koen Kooi wrote: Burton, Ross schreef op 23-12-13 19:01: We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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? 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. Speaking of layers, can you *please* rename meta-yocto to meta-poky? It's what it's actually is and would remove a lot of confusion when trying to explain that yocto is not a distro, even if the distro layer is called 'meta-yocto'. This is a tangent, but a couple of points: 1) This rename would not come for free. We'd need to update people's existing bblayers.conf files on the fly, as we did when meta-yocto-bsp was split out of meta-yocto, and thus bump LCONF_VERSION; however, doing this only in poky has resulted in annoying problems when users remove poky from their configurations (since LCONF_VERSION is out-of-step between Poky and OE-Core, leading to confusing errors in this situation). Thus I think we'd want to solve this once and for all by bumping the value in OE-Core as well as Poky. 2) If you propose this rename, perhaps you will also consider renaming meta-oe, since that name within a similarly named meta-openembedded repository leads to a similar level of confusion...? I have no problems with renaming that layer since I get confused by this a few times a week myself :) What would we we rename it to? I'm very tempted to suggest 'meta-yocto' I definitely find meta-yocto a better option here. It would save me from some confusion when talking about yocto to other people. Related to meta-oe, even if that would be a smaller problem, I think meta-openembedded is a better name for that layer too. -- Andrei Gherzan m: +40.744.478.414 | f: +40.31.816.28.12 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philip Balister schreef op 28-12-13 23:33: On 12/28/2013 10:28 AM, Koen Kooi wrote: Paul Eggleton schreef op 28-12-13 12:48: Hi Koen, On Tuesday 24 December 2013 15:22:32 Koen Kooi wrote: Burton, Ross schreef op 23-12-13 19:01: We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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? 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. Speaking of layers, can you *please* rename meta-yocto to meta-poky? It's what it's actually is and would remove a lot of confusion when trying to explain that yocto is not a distro, even if the distro layer is called 'meta-yocto'. This is a tangent, but a couple of points: 1) This rename would not come for free. We'd need to update people's existing bblayers.conf files on the fly, as we did when meta-yocto-bsp was split out of meta-yocto, and thus bump LCONF_VERSION; however, doing this only in poky has resulted in annoying problems when users remove poky from their configurations (since LCONF_VERSION is out-of-step between Poky and OE-Core, leading to confusing errors in this situation). Thus I think we'd want to solve this once and for all by bumping the value in OE-Core as well as Poky. 2) If you propose this rename, perhaps you will also consider renaming meta-oe, since that name within a similarly named meta-openembedded repository leads to a similar level of confusion...? I have no problems with renaming that layer since I get confused by this a few times a week myself :) What would we we rename it to? I'm very tempted to suggest 'meta-yocto' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFSwEN0MkyGM64RGpERAnuDAKC5kxJXiSjM0RtJPu8Gksu4t7IaOACdFyyq vPBlgjhnZyECigXVQNUkj1U= =laEu -END PGP SIGNATURE- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
On Monday 23 December 2013 20:09:30 Philip Balister wrote: On 12/23/2013 01:01 PM, Burton, Ross wrote: We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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. This all depends on the scope of these tools. If the scope is only the Yocto Project QA team, adding them to the core would be a difficult sell. However, if the target audience were a larger number of BSP maintainers (and to be honest, I would expect maintainers of BSPs for hardware supporting GL acceleration to want to be able to run these tests) then adding these components to the core starts to make sense, to me at least. 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. So this presents a quandry. Moving numpy to a special layer to support a specific recipe is just not the right thing to do. Conceivably, we could create a layer for the bits of meta-oe that are python related, but I am not sure that solves your entire problem. I certainly do not want to see one recipe appear in two layers. That is a recipe for trouble. There is a third way - use combo-layer to keep a maintained copy of the recipe in the meta-yocto-qa layer, just as we do with OE-Core within the poky repository. It has worked well enough there, although here we would be being more selective about the recipes we were pulling; it could be problematic if for example a dependency were added from a recipe that is part of the filter on a recipe that is not part of the filter. Long term, we need to make the layer model work for the entire project and get over the reluctance to use other peoples layers. This is a tricky thing. If we start relying heavily on layers for our builds that we don't currently have an active role in maintaining, there will be a natural assumption that we'll step up and help maintain those layers; it will be made more difficult if those layers contain a large number of recipes. Specifically regarding meta-oe, as you may be aware our reluctance to use this layer directly up to now was because of its use of bbappends and overlayed recipes that change the apparent behaviour of core recipes. Most of this has been tidied up, however one last such issue still exists [1] and is apparently still leading to problems for users [2], so there is still work needing to be done here. Cheers, Paul [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=5546 [2] https://lists.yoctoproject.org/pipermail/poky/2013-December/009463.html -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
Hi Koen, On Tuesday 24 December 2013 15:22:32 Koen Kooi wrote: Burton, Ross schreef op 23-12-13 19:01: We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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? 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. Speaking of layers, can you *please* rename meta-yocto to meta-poky? It's what it's actually is and would remove a lot of confusion when trying to explain that yocto is not a distro, even if the distro layer is called 'meta-yocto'. This is a tangent, but a couple of points: 1) This rename would not come for free. We'd need to update people's existing bblayers.conf files on the fly, as we did when meta-yocto-bsp was split out of meta-yocto, and thus bump LCONF_VERSION; however, doing this only in poky has resulted in annoying problems when users remove poky from their configurations (since LCONF_VERSION is out-of-step between Poky and OE-Core, leading to confusing errors in this situation). Thus I think we'd want to solve this once and for all by bumping the value in OE-Core as well as Poky. 2) If you propose this rename, perhaps you will also consider renaming meta-oe, since that name within a similarly named meta-openembedded repository leads to a similar level of confusion...? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Eggleton schreef op 28-12-13 12:48: Hi Koen, On Tuesday 24 December 2013 15:22:32 Koen Kooi wrote: Burton, Ross schreef op 23-12-13 19:01: We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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? 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. Speaking of layers, can you *please* rename meta-yocto to meta-poky? It's what it's actually is and would remove a lot of confusion when trying to explain that yocto is not a distro, even if the distro layer is called 'meta-yocto'. This is a tangent, but a couple of points: 1) This rename would not come for free. We'd need to update people's existing bblayers.conf files on the fly, as we did when meta-yocto-bsp was split out of meta-yocto, and thus bump LCONF_VERSION; however, doing this only in poky has resulted in annoying problems when users remove poky from their configurations (since LCONF_VERSION is out-of-step between Poky and OE-Core, leading to confusing errors in this situation). Thus I think we'd want to solve this once and for all by bumping the value in OE-Core as well as Poky. 2) If you propose this rename, perhaps you will also consider renaming meta-oe, since that name within a similarly named meta-openembedded repository leads to a similar level of confusion...? I have no problems with renaming that layer since I get confused by this a few times a week myself :) regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFSvu4jMkyGM64RGpERAqnnAJ9+ASZITy/zGdjAC9PypPkWVsKO/ACdFF00 0Mfkmf+s20DWkHs6NwxkZYM= =YCAe -END PGP SIGNATURE- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
On 12/28/2013 10:28 AM, Koen Kooi wrote: Paul Eggleton schreef op 28-12-13 12:48: Hi Koen, On Tuesday 24 December 2013 15:22:32 Koen Kooi wrote: Burton, Ross schreef op 23-12-13 19:01: We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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? 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. Speaking of layers, can you *please* rename meta-yocto to meta-poky? It's what it's actually is and would remove a lot of confusion when trying to explain that yocto is not a distro, even if the distro layer is called 'meta-yocto'. This is a tangent, but a couple of points: 1) This rename would not come for free. We'd need to update people's existing bblayers.conf files on the fly, as we did when meta-yocto-bsp was split out of meta-yocto, and thus bump LCONF_VERSION; however, doing this only in poky has resulted in annoying problems when users remove poky from their configurations (since LCONF_VERSION is out-of-step between Poky and OE-Core, leading to confusing errors in this situation). Thus I think we'd want to solve this once and for all by bumping the value in OE-Core as well as Poky. 2) If you propose this rename, perhaps you will also consider renaming meta-oe, since that name within a similarly named meta-openembedded repository leads to a similar level of confusion...? I have no problems with renaming that layer since I get confused by this a few times a week myself :) What would we we rename it to? Philip regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core signature.asc Description: OpenPGP digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Burton, Ross schreef op 23-12-13 19:01: Hi, We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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? 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. Speaking of layers, can you *please* rename meta-yocto to meta-poky? It's what it's actually is and would remove a lot of confusion when trying to explain that yocto is not a distro, even if the distro layer is called 'meta-yocto'. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFSuZioMkyGM64RGpERAgglAKCHbnivOF3g/ZVMGYadm4pDDzfKVQCdGqlY YdzFCCkRyP8WWMuNJRlR6x4= =4M6P -END PGP SIGNATURE- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Piglit in Poky
Hi, We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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? 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. Thoughts and opinions welcome over Christmas, otherwise I'll toss a coin. :) Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Piglit in Poky
On 12/23/2013 01:01 PM, Burton, Ross wrote: Hi, We'd like to integrate Piglit (an OpenGL test suite) into Poky so that we can run automated QA on the GL stack. Piglit is currently residing in meta-oe, but as Poky is a self-contained project we can't just add meta-oe to it: apart from the size of meta-oe, we can't ensure stability if meta-oe makes incompatible changes that affect Poky. Piglit isn't a stand-alone package, there are the dependencies of waffle, python-mako and python-numpy to consider too. There are two possibilities I can see: 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. 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. So this presents a quandry. Moving numpy to a special layer to support a specific recipe is just not the right thing to do. Conceivably, we could create a layer for the bits of meta-oe that are python related, but I am not sure that solves your entire problem. I certainly do not want to see one recipe appear in two layers. That is a recipe for trouble. Long term, we need to make the layer model work for the entire project and get over the reluctance to use other peoples layers. Philip Thoughts and opinions welcome over Christmas, otherwise I'll toss a coin. :) Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
