Piglit in Poky

Piglit in Poky

[Burton, Ross]

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

Re: Piglit in Poky

[Philip Balister]

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
> 

Re: [OE-core] Piglit in Poky

[Philip Balister]

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
> 

Re: [oe] Piglit in Poky

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

On Mon, Dec 23, 2013 at 08:09:30PM -0500, Philip Balister wrote:
> 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.

Agreed, meta-python in meta-oe repository sounds a lot better than
having the same recipe in 2 layers.

> > 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-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [OE-core] Piglit in Poky

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

On Mon, Dec 23, 2013 at 08:09:30PM -0500, Philip Balister wrote:
> 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.

Agreed, meta-python in meta-oe repository sounds a lot better than
having the same recipe in 2 layers.

> > 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-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [oe] [OE-core] Piglit in Poky

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

On Mon, Dec 23, 2013 at 08:09:30PM -0500, Philip Balister wrote:
> 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.

Agreed, meta-python in meta-oe repository sounds a lot better than
having the same recipe in 2 layers.

> > 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-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Piglit in Poky

[Koen Kooi]

-----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-----

Re: Piglit in Poky

[Paul Eggleton]

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

Re: [OE-core] Piglit in Poky

[Paul Eggleton]

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

Re: Piglit in Poky

[Paul Eggleton]

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

Re: [OE-core] Piglit in Poky

[Paul Eggleton]

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

Re: Piglit in Poky

[Koen Kooi]

-----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-----

Re: Piglit in Poky

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

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
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 567 bytes --]

Re: [OE-core] Piglit in Poky

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

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
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 567 bytes --]

Re: Piglit in Poky

[Koen Kooi]

-----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-----

Re: Piglit in Poky

[Andrei Gherzan]

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

Re: [OE-core] Piglit in Poky

[Andrei Gherzan]

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

Re: [oe] Piglit in Poky

[Paul Eggleton]

On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> 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.

I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you 
didn't realise Koen was joking...

> Related to meta-oe, even if that would be a smaller problem, I think
> meta-openembedded is a better name for that layer too.

That doesn't solve the problem I was talking about, namely that there's little 
distinction between meta-openembedded the repository (that contains a number 
of layers) and meta-oe which is one of those layers. These are two different 
things and the similar naming makes it hard to always know which one people 
are talking about.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] Piglit in Poky

[Paul Eggleton]

On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> 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.

I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you 
didn't realise Koen was joking...

> Related to meta-oe, even if that would be a smaller problem, I think
> meta-openembedded is a better name for that layer too.

That doesn't solve the problem I was talking about, namely that there's little 
distinction between meta-openembedded the repository (that contains a number 
of layers) and meta-oe which is one of those layers. These are two different 
things and the similar naming makes it hard to always know which one people 
are talking about.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] Piglit in Poky

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 4531 bytes --]

On Fri, Jan 03, 2014 at 01:26:05PM +0000, Paul Eggleton wrote:
> On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> > 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.
> 
> I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you 
> didn't realise Koen was joking...

My understanding was that Koen was talking about renaming
meta-openembedded repository to meta-yocto, which would be kind of nice,
but too late for that now, it would be very confusing with the other
meta-yocto repository.

> > Related to meta-oe, even if that would be a smaller problem, I think
> > meta-openembedded is a better name for that layer too.
> 
> That doesn't solve the problem I was talking about, namely that there's little 
> distinction between meta-openembedded the repository (that contains a number 
> of layers) and meta-oe which is one of those layers. These are two different 
> things and the similar naming makes it hard to always know which one people 
> are talking about.

What's even worse is that github mirror names the repositories
meta-oe/oe-core so even the small distinction "meta-openembedded" =
repo, "meta-oe" = layer doesn't work there.

https://github.com/openembedded

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [OE-core] Piglit in Poky

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 4531 bytes --]

On Fri, Jan 03, 2014 at 01:26:05PM +0000, Paul Eggleton wrote:
> On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> > 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.
> 
> I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you 
> didn't realise Koen was joking...

My understanding was that Koen was talking about renaming
meta-openembedded repository to meta-yocto, which would be kind of nice,
but too late for that now, it would be very confusing with the other
meta-yocto repository.

> > Related to meta-oe, even if that would be a smaller problem, I think
> > meta-openembedded is a better name for that layer too.
> 
> That doesn't solve the problem I was talking about, namely that there's little 
> distinction between meta-openembedded the repository (that contains a number 
> of layers) and meta-oe which is one of those layers. These are two different 
> things and the similar naming makes it hard to always know which one people 
> are talking about.

What's even worse is that github mirror names the repositories
meta-oe/oe-core so even the small distinction "meta-openembedded" =
repo, "meta-oe" = layer doesn't work there.

https://github.com/openembedded

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [oe] Piglit in Poky

[Paul Eggleton]

On Friday 03 January 2014 14:37:27 Martin Jansa wrote:
> On Fri, Jan 03, 2014 at 01:26:05PM +0000, Paul Eggleton wrote:
> > On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> > > 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.
> > 
> > I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you
> > didn't realise Koen was joking...
> 
> My understanding was that Koen was talking about renaming
> meta-openembedded repository to meta-yocto, which would be kind of nice,
> but too late for that now, it would be very confusing with the other
> meta-yocto repository.

I don't think that would be possible anyway. The Yocto Project itself does not 
officially maintain support for the contents of that repository. It's true that 
I'm maintaining meta-webserver and folks at Wind River are maintaining meta-
networking and some other bits and pieces, but AIUI that work isn't officially 
under the Yocto Project umbrella - e.g. we do not run these through our QA / 
testing / release processes like we do Poky / OE-Core.

> > > Related to meta-oe, even if that would be a smaller problem, I think
> > > meta-openembedded is a better name for that layer too.
> > 
> > That doesn't solve the problem I was talking about, namely that there's
> > little distinction between meta-openembedded the repository (that
> > contains a number of layers) and meta-oe which is one of those layers.
> > These are two different things and the similar naming makes it hard to
> > always know which one people are talking about.

FWIW, I didn't yet mention my suggestion - I was thinking about meta-oe (the 
layer) being renamed to "meta-misc" in the absence of some better suggestion. 
I'm sure we could have a transition mechanism via a specialised layer.conf 
where the old name continues to work for a limited time.

> What's even worse is that github mirror names the repositories
> meta-oe/oe-core so even the small distinction "meta-openembedded" =
> repo, "meta-oe" = layer doesn't work there.
> 
> https://github.com/openembedded

Yes, that should definitely be changed as well. They're supposed to be mirrors 
so they should have the exact same names, IMHO.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] Piglit in Poky

[Paul Eggleton]

On Friday 03 January 2014 14:37:27 Martin Jansa wrote:
> On Fri, Jan 03, 2014 at 01:26:05PM +0000, Paul Eggleton wrote:
> > On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> > > 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.
> > 
> > I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you
> > didn't realise Koen was joking...
> 
> My understanding was that Koen was talking about renaming
> meta-openembedded repository to meta-yocto, which would be kind of nice,
> but too late for that now, it would be very confusing with the other
> meta-yocto repository.

I don't think that would be possible anyway. The Yocto Project itself does not 
officially maintain support for the contents of that repository. It's true that 
I'm maintaining meta-webserver and folks at Wind River are maintaining meta-
networking and some other bits and pieces, but AIUI that work isn't officially 
under the Yocto Project umbrella - e.g. we do not run these through our QA / 
testing / release processes like we do Poky / OE-Core.

> > > Related to meta-oe, even if that would be a smaller problem, I think
> > > meta-openembedded is a better name for that layer too.
> > 
> > That doesn't solve the problem I was talking about, namely that there's
> > little distinction between meta-openembedded the repository (that
> > contains a number of layers) and meta-oe which is one of those layers.
> > These are two different things and the similar naming makes it hard to
> > always know which one people are talking about.

FWIW, I didn't yet mention my suggestion - I was thinking about meta-oe (the 
layer) being renamed to "meta-misc" in the absence of some better suggestion. 
I'm sure we could have a transition mechanism via a specialised layer.conf 
where the old name continues to work for a limited time.

> What's even worse is that github mirror names the repositories
> meta-oe/oe-core so even the small distinction "meta-openembedded" =
> repo, "meta-oe" = layer doesn't work there.
> 
> https://github.com/openembedded

Yes, that should definitely be changed as well. They're supposed to be mirrors 
so they should have the exact same names, IMHO.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] Piglit in Poky

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 4302 bytes --]

On Fri, Jan 3, 2014 at 3:26 PM, Paul Eggleton <paul.eggleton@linux.intel.com
> wrote:

> On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> > 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.
>
> I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you
> didn't realise Koen was joking...
>
>
Misread that. I thought he was talking about poky. Taking back my stupid
statement.



>  > Related to meta-oe, even if that would be a smaller problem, I think
> > meta-openembedded is a better name for that layer too.
>
> That doesn't solve the problem I was talking about, namely that there's
> little
> distinction between meta-openembedded the repository (that contains a
> number
> of layers) and meta-oe which is one of those layers. These are two
> different
> things and the similar naming makes it hard to always know which one people
> are talking about.


In that case the collection of layers should be meta-openembedded and the
meta-oe layer something like meta-openembedded-common or whatever.

-- 
*ag*

[-- Attachment #2: Type: text/html, Size: 6171 bytes --]

Re: [OE-core] Piglit in Poky

[Andrei Gherzan]

On Fri, Jan 3, 2014 at 3:26 PM, Paul Eggleton <paul.eggleton@linux.intel.com
> wrote:

> On Friday 03 January 2014 13:25:13 Andrei Gherzan wrote:
> > 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.
>
> I'm not following; meta-yocto is already called meta-yocto ... ? Maybe you
> didn't realise Koen was joking...
>
>
Misread that. I thought he was talking about poky. Taking back my stupid
statement.



>  > Related to meta-oe, even if that would be a smaller problem, I think
> > meta-openembedded is a better name for that layer too.
>
> That doesn't solve the problem I was talking about, namely that there's
> little
> distinction between meta-openembedded the repository (that contains a
> number
> of layers) and meta-oe which is one of those layers. These are two
> different
> things and the similar naming makes it hard to always know which one people
> are talking about.


In that case the collection of layers should be meta-openembedded and the
meta-oe layer something like meta-openembedded-common or whatever.

-- 
*ag*

Re: [oe] Piglit in Poky

[Paul Eggleton]

On Tuesday 24 December 2013 11:50:50 Martin Jansa wrote:
> On Mon, Dec 23, 2013 at 08:09:30PM -0500, 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.
> > 
> > > 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.
> 
> Agreed, meta-python in meta-oe repository sounds a lot better than
> having the same recipe in 2 layers.

FWIW, independent of this issue I'd like to see us have a meta-python layer in 
the meta-openembedded repo anyway. I'll even volunteer to maintain it if it 
helps.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] Piglit in Poky

[Paul Eggleton]

On Tuesday 24 December 2013 11:50:50 Martin Jansa wrote:
> On Mon, Dec 23, 2013 at 08:09:30PM -0500, 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.
> > 
> > > 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.
> 
> Agreed, meta-python in meta-oe repository sounds a lot better than
> having the same recipe in 2 layers.

FWIW, independent of this issue I'd like to see us have a meta-python layer in 
the meta-openembedded repo anyway. I'll even volunteer to maintain it if it 
helps.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Piglit in Poky

[Burton, Ross]

Hi,

Despite a good start this thread got rapidly hijacked, so let's try again!

On 24 December 2013 01:09, Philip Balister <philip@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

Re: [OE-core] Piglit in Poky

[Burton, Ross]

Hi,

Despite a good start this thread got rapidly hijacked, so let's try again!

On 24 December 2013 01:09, Philip Balister <philip@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

Re: [poky] Piglit in Poky

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]

On Wed, Jan 08, 2014 at 04:09:10PM +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@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.

4) meta-python in meta-oe (at least for easier copy somewhere else with combo-layer)

> 
> 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
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [poky] [OE-core] Piglit in Poky

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]

On Wed, Jan 08, 2014 at 04:09:10PM +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@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.

4) meta-python in meta-oe (at least for easier copy somewhere else with combo-layer)

> 
> 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
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [OE-core] Piglit in Poky

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]

On Wed, Jan 08, 2014 at 04:09:10PM +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@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.

4) meta-python in meta-oe (at least for easier copy somewhere else with combo-layer)

> 
> 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
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Piglit in Poky

[Richard Purdie]

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@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

Re: [OE-core] Piglit in Poky

[Richard Purdie]

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@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

Re: [OE-core] Piglit in Poky

[Richard Purdie]

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@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

Re: Piglit in Poky

[Nicolas Dechesne]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On Wed, Jan 8, 2014 at 6:01 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> >
> > On 24 December 2013 01:09, Philip Balister <philip@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.

[-- Attachment #2: Type: text/html, Size: 2042 bytes --]

Re: [OE-core] Piglit in Poky

[Nicolas Dechesne]

On Wed, Jan 8, 2014 at 6:01 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> >
> > On 24 December 2013 01:09, Philip Balister <philip@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.

Re: 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@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
> 
> 
> 
> 

Re: [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@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
> 
> 
> 
> 

Re: Piglit in Poky

[Burton, Ross]

On 8 January 2014 18:44, Philip Balister <philip@balister.org> wrote:
> 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@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

Re: [OE-core] Piglit in Poky

[Burton, Ross]

On 8 January 2014 18:44, Philip Balister <philip@balister.org> wrote:
> 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@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

Re: [OE-core] Piglit in Poky

[Burton, Ross]

On 8 January 2014 18:44, Philip Balister <philip@balister.org> wrote:
> 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@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

Re: [oe] Piglit in Poky

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

On Wed, Jan 8, 2014 at 3:01 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> 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@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.
>

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

[-- Attachment #2: Type: text/html, Size: 4639 bytes --]

Re: [OE-core] Piglit in Poky

[Otavio Salvador]

On Wed, Jan 8, 2014 at 3:01 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> 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@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.
>

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