Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Thursday 16 May 2013 11:35:55 Phil Blundell wrote: On Thu, 2013-05-16 at 10:01 +0100, Tomas Frydrych wrote: On 15/05/13 21:49, Phil Blundell wrote: - we have a slightly funky 2-stage bootstrap process for cogl in order to break the dependency cycle with cairo; this involves hacks to the recipes for cogl, cairo, pango and harfbuzz (at least) which I suspect would not be very palatable to oe-core. I have never run into this, is this with recent cogls? It's because we build Cairo with the cogl backend enabled. That introduces a dependency of cairo on cogl (obviously), which is a problem because cogl-pango needs pango, which needs harfbuzz, which needs cairo. So what we do is build cogl initially with pango disabled, then use that to compile cairo and the rest of the stack, and then finally build the real cogl with everything enabled. Obviously the other option would be to build cairo twice, firstly without cogl and the second time with it. I don't think there's much to choose between the two. I was just speaking to one of the cogl developers and he was surprised that anyone would be using cairo's cogl backend since it's never really been finished. Is that backend definitely functionality that you're using? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Hi Phil, On 15/05/13 21:49, Phil Blundell wrote: On Wed, 2013-05-15 at 16:28 -0300, Otavio Salvador wrote: - we have a different (newer) version I think particularly for point updates we should be able to minimize the pain if the base recipes are set up well. - we use eglnative mostly, though we might start wanting to use glx under qemu for testing (subject to getting a suitable mesa) This is the crux of the difficulties with cogl/clutter. In Guacamayo I need to be able to use both eglnative and glx. I prefer eglnative + gles2, because I only need a single clutter based app running and the X11 overhead is not negligible, but on intel HW I have not been able to get this working satisfactorily in the past, so ended up using GLX for the likes of atom-pc and NUC. The solution I came up with is to predefine a bunch common configure+depends+rdepends sets in the clutter/cogl includes (there is only a finite number of configurations that makes sense, though my recipes do not cover them all), and then in a Guacamayo-specific bbappend choose a suitable configuration on per-machine basis. - we have a slightly funky 2-stage bootstrap process for cogl in order to break the dependency cycle with cairo; this involves hacks to the recipes for cogl, cairo, pango and harfbuzz (at least) which I suspect would not be very palatable to oe-core. I have never run into this, is this with recent cogls? The net result of all this is that, whenever I try to factor out a set of stuff that's generic clutter and could go into oe-core, I end up with recipes that have virtually nothing in common with what we're actually using and consequently don't actually solve any of my problems. I don't think we can create a set of recipes that 'just work' for everyone, but we can have recipes that minimal effort and that also provide sensible defaults for the common machines out there. There are some broader issues here though that need thought, particularly, a bbappend should be a method of last resort, it would be nice have a feature mechanism to ease the configuration. But distro features are of no use here because it is not possible to differentiate packages with different configs based on DF; machine features don't have this limitation, but are the wrong place for this, plus it is entirely conceivable you might want be able to build different configs for the same machine on the same tmp dir (I use pseudo-machines for this, like atom-egl, but that is just a nasty hack). Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 15/05/13 20:43, Richard Purdie wrote: On Wed, 2013-05-15 at 20:30 +0300, Richard Purdie wrote: How about the master branch gets renamed dylan so it clearly show what its meant to work against and follows the other repositories? Yes, that's on my TODO list, together with removing the couple of unnecessary updated recipes from master when that is done (glib, libxkbcommon). Just to clarify the Guacamayo/meta-clutter was not set up with the view to this proposal for an separate meta-clutter layer. I created it because I need somewhere with uptodate clutter and associated recipes (e.g., Mutter) so I could get on with the meta-gir (GObject Introspection) work and did not want to make that depend on meta-gucamayo. But I'd really prefer any such meta-clutter layer not to be my private sandbox, hence this proposal. Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 15/05/13 19:24, Paul Eggleton wrote: However, I do think it's important for us to try to work together for the benefit of everyone, I entirely agree with this; I certainly don't want to maintain a public meta-clutter layer that competes with, or is perceived to compete with some other recipes or efforts (oe-core or otherwise), this benefits no one, least of all anyone interested in being just a 'user' of these packages. Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Thu, 2013-05-16 at 10:01 +0100, Tomas Frydrych wrote: The solution I came up with is to predefine a bunch common configure+depends+rdepends sets in the clutter/cogl includes (there is only a finite number of configurations that makes sense, though my recipes do not cover them all), and then in a Guacamayo-specific bbappend choose a suitable configuration on per-machine basis. Right, that sounds fairly reasonable. Or one could presumably use PACKAGECONFIG for this sort of thing. - we have a slightly funky 2-stage bootstrap process for cogl in order to break the dependency cycle with cairo; this involves hacks to the recipes for cogl, cairo, pango and harfbuzz (at least) which I suspect would not be very palatable to oe-core. I have never run into this, is this with recent cogls? It's because we build Cairo with the cogl backend enabled. That introduces a dependency of cairo on cogl (obviously), which is a problem because cogl-pango needs pango, which needs harfbuzz, which needs cairo. So what we do is build cogl initially with pango disabled, then use that to compile cairo and the rest of the stack, and then finally build the real cogl with everything enabled. Obviously the other option would be to build cairo twice, firstly without cogl and the second time with it. I don't think there's much to choose between the two. this limitation, but are the wrong place for this, plus it is entirely conceivable you might want be able to build different configs for the same machine on the same tmp dir (I use pseudo-machines for this, like atom-egl, but that is just a nasty hack). This is something that's just fundamentally difficult in OE; there simply isn't any namespace to express that degree of freedom. DISTRO is essentially invariant for any given tmpdir, and the hierarchy in there reflects MACHINE and PN. So, if you want to build the same package with a different configuration then either MACHINE or PN is going to have to change. Traditionally of course it's been PN that changes in this situation. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 16/05/13 11:35, Phil Blundell wrote: On Thu, 2013-05-16 at 10:01 +0100, Tomas Frydrych wrote: The solution I came up with is to predefine a bunch common configure+depends+rdepends sets in the clutter/cogl includes (there is only a finite number of configurations that makes sense, though my recipes do not cover them all), and then in a Guacamayo-specific bbappend choose a suitable configuration on per-machine basis. Right, that sounds fairly reasonable. Or one could presumably use PACKAGECONFIG for this sort of thing. Yep, that's one of the things I need to clean up in my own recipes. It's because we build Cairo with the cogl backend enabled. That introduces a dependency of cairo on cogl (obviously), which is a problem because cogl-pango needs pango, which needs harfbuzz, which needs cairo. So what we do is build cogl initially with pango disabled, then use that to compile cairo and the rest of the stack, and then finally build the real cogl with everything enabled. This would probably merit some sort of cogl-initial recipe to add. This is something that's just fundamentally difficult in OE; there simply isn't any namespace to express that degree of freedom. DISTRO is essentially invariant for any given tmpdir, and the hierarchy in there reflects MACHINE and PN. So, if you want to build the same package with a different configuration then either MACHINE or PN is going to have to change. Traditionally of course it's been PN that changes in this situation. I originally went down the PN route, but that meant having to specify preferred providers and in my use case the sole criterion was the MACHINE. But for a generic solution, it's probably necessary to have some PN mechanism in place, maybe the keys in PACKAGECONFIG could be used to automatically create a mangled PN for non-standard configs. Tomas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Thu, 2013-05-16 at 12:21 +0100, Tomas Frydrych wrote:
This would probably merit some sort of cogl-initial recipe to add.
Yeah. If it was just a case of doing that then I would have done so;
the trouble is that you end up having to put garbage like
# We need to use the nopango build of cogl because we are a build dependency of
pango
PKG_CONFIG_PATH_prepend =
${STAGING_DIR_HOST}/${exec_prefix}/cogl-nopango/${baselib}/pkgconfig:
TARGET_LDFLAGS +=
-Wl,-rpath-link,${STAGING_DIR_HOST}/${exec_prefix}/cogl-nopango/${baselib}
in the recipes for everything else that participates in this dependency
chain and needs building before the real cogl. Which is ugly.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Hi Paul, On 14/05/13 17:55, Paul Eggleton wrote: Having clutter in OE-Core does not preclude such testing with additional BSPs, and I'm unclear on how moving it out to another layer helps at all with this specific issue. It prevents efficiently supporting clutter on any real machine that does not use mesa's GL, which means all machines not in meta-intel, and some machines in meta-intel. This is the main issue, real HW support. This could present a problem. What if I want Clutter but I don't want the latest version of glib, but instead the version that is being shipped with OE- Core that is tested with the other pieces of the system that depend upon it (especially given glib has recent history of breaking other packages)? Surely the safest alternative is the last stable version of Clutter that works with that version of glib? That would make it difficult to depend upon an external layer that provides its own newer version of glib would it not? Sometimes a 6 month old release is not enough, and having to provide the updated packages yourself is the least desirable of all options. In a small layer, such issues can be handled gracefully, and their impact limited. There's no denying that the maintenance of the Clutter recipes in OE-Core has slipped. I don't think that is an argument in itself to split them out, that just means we need to recognise that and maintain those recipes more effectively. The lack of maintenance reflects the relative importance of Clutter for oe-core, and is an orthogonal issue. I am not complaining that it is not being maintained, I am arguing that it cannot be properly maintained with just reference to mesa and qemu, hence the suggestion to split it out. Honestly I think if Clutter continues to be something that people are using to develop applications we're much better off with the canonical stable version being in OE-Core. Where 'canonical' means 'unusable on non-Intel HW', but I am repeating myself ... Tomas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Hi Paul, On 15/05/13 10:49, Paul Eggleton wrote: It prevents efficiently supporting clutter on any real machine that does not use mesa's GL, which means all machines not in meta-intel, and some machines in meta-intel. This is the main issue, real HW support. How does it prevent that? Surely if machine-specific changes are required then they will be required on top of a separate layer as much as they are if the recipes remain in OE-Core. It could be all pulled together into the meta-clutter layer, the supported BSPs and machines documented, etc, so that common machines just work out of the box. We could have a dedicated mailing list, a bug tracker, build a community around it, pull resources. The layer mechanism exists to allow specific recipes to be extended if needed. Having the recipes in OE-Core does not preclude their extension or replacement with newer versions elsewhere for those that need it. I have followed the model you advocate for over a year with clutter, and it is a PITA, so I am thinking that perhaps there are others who are doing the same and we could do it in one well known place. You may well be right about the need to test on other GL implementations. That does not explain how moving them to a separate layer directly helps to address that need. You must also expect to make some changes to the recipes themselves, so what changes would you be making? It's not just about testing, you have to build it first: I would like to see a set of recipes that can support a whole bunch of machines in the public OE BSP layers out of the box: configs that work and make sense, patches where needed, documentation, including documentation of BSP specific issues. In the absence of a community-owned meta-clutter layer, if anyone is stuck maintaining their own clutter recipes, I have a set at https://github.com/Guacamayo/meta-clutter which can perhaps be of some use. Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, May 15, 2013 at 8:35 AM, Tomas Frydrych tf+lists.yo...@r-finger.com wrote: Hi Paul, On 15/05/13 10:49, Paul Eggleton wrote: It prevents efficiently supporting clutter on any real machine that does not use mesa's GL, which means all machines not in meta-intel, and some machines in meta-intel. This is the main issue, real HW support. How does it prevent that? Surely if machine-specific changes are required then they will be required on top of a separate layer as much as they are if the recipes remain in OE-Core. It could be all pulled together into the meta-clutter layer, the supported BSPs and machines documented, etc, so that common machines just work out of the box. We could have a dedicated mailing list, a bug tracker, build a community around it, pull resources. +1 The layer mechanism exists to allow specific recipes to be extended if needed. Having the recipes in OE-Core does not preclude their extension or replacement with newer versions elsewhere for those that need it. I have followed the model you advocate for over a year with clutter, and it is a PITA, so I am thinking that perhaps there are others who are doing the same and we could do it in one well known place. +1 You may well be right about the need to test on other GL implementations. That does not explain how moving them to a separate layer directly helps to address that need. You must also expect to make some changes to the recipes themselves, so what changes would you be making? It's not just about testing, you have to build it first: I would like to see a set of recipes that can support a whole bunch of machines in the public OE BSP layers out of the box: configs that work and make sense, patches where needed, documentation, including documentation of BSP specific issues. In the absence of a community-owned meta-clutter layer, if anyone is stuck maintaining their own clutter recipes, I have a set at https://github.com/Guacamayo/meta-clutter which can perhaps be of some use. +1 I share same feeling of Tomas and I agree that a new layer is the way to go. Having it in a specific layer will allow for more shared work and easy a community creation around it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 15.05.2013 11:53, Otavio Salvador wrote: On Wed, May 15, 2013 at 8:35 AM, Tomas Frydrych tf+lists.yo...@r-finger.com wrote: Hi Paul, On 15/05/13 10:49, Paul Eggleton wrote: It prevents efficiently supporting clutter on any real machine that does not use mesa's GL, which means all machines not in meta-intel, and some machines in meta-intel. This is the main issue, real HW support. How does it prevent that? Surely if machine-specific changes are required then they will be required on top of a separate layer as much as they are if the recipes remain in OE-Core. It could be all pulled together into the meta-clutter layer, the supported BSPs and machines documented, etc, so that common machines just work out of the box. We could have a dedicated mailing list, a bug tracker, build a community around it, pull resources. +1 The layer mechanism exists to allow specific recipes to be extended if needed. Having the recipes in OE-Core does not preclude their extension or replacement with newer versions elsewhere for those that need it. I have followed the model you advocate for over a year with clutter, and it is a PITA, so I am thinking that perhaps there are others who are doing the same and we could do it in one well known place. +1 You may well be right about the need to test on other GL implementations. That does not explain how moving them to a separate layer directly helps to address that need. You must also expect to make some changes to the recipes themselves, so what changes would you be making? It's not just about testing, you have to build it first: I would like to see a set of recipes that can support a whole bunch of machines in the public OE BSP layers out of the box: configs that work and make sense, patches where needed, documentation, including documentation of BSP specific issues. In the absence of a community-owned meta-clutter layer, if anyone is stuck maintaining their own clutter recipes, I have a set at https://github.com/Guacamayo/meta-clutter which can perhaps be of some use. +1 I share same feeling of Tomas and I agree that a new layer is the way to go. Having it in a specific layer will allow for more shared work and easy a community creation around it. I fail to see why the presence of meta-clutter contradicts keeping clutter and related recipes in oe-core. If you add meta-clutter to your layers, then its recipes will override those in oe-core anyway. Of course, clutter recipes in oe-core could see some maintenance, but that's IMO a different topic. Regards, Andreas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Hi Paul, On 15/05/13 15:09, Paul Eggleton wrote: Can you not just get the appropriate changes into the BSP layers so that when you add the BSP on top of OE-Core it does just work out of the box? What you are really saying is that the onus of maintaining working clutter packages should be on the BSP maintainers. I have already explained previously in this thread why I don't think this is going to work out in practice, so I am not going to repeat myself again. If clutter is taken out of OE-Core this becomes even harder because then BSPs can no longer bbappend clutter or cogl (if that is indeed what is required in order to enable machine-specific functionality) without fiddling around with BBMASK or keeping the appends in yet another separate layer so they don't impact other BSP users who aren't building Clutter. The BSPs would not need to do anything regarding clutter, no bbappends, meta-clutter would be self-contained in this regard. I don't think there is any point in bothering the list with this discussion any further, we have gone around the circle more than once. The whole point of the proposal was to make maintaining, using and supporting the clutter packages easier for everyone, but it seems I underestimated how important Clutter is to oe-core, and I am already looking forward to this newly discovered importance being translated into user happiness before too long. :) Tomas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, May 15, 2013 at 1:34 PM, Tomas Frydrych tf+lists.yo...@r-finger.com wrote: Hi Paul, On 15/05/13 15:09, Paul Eggleton wrote: Can you not just get the appropriate changes into the BSP layers so that when you add the BSP on top of OE-Core it does just work out of the box? What you are really saying is that the onus of maintaining working clutter packages should be on the BSP maintainers. I have already explained previously in this thread why I don't think this is going to work out in practice, so I am not going to repeat myself again. If clutter is taken out of OE-Core this becomes even harder because then BSPs can no longer bbappend clutter or cogl (if that is indeed what is required in order to enable machine-specific functionality) without fiddling around with BBMASK or keeping the appends in yet another separate layer so they don't impact other BSP users who aren't building Clutter. The BSPs would not need to do anything regarding clutter, no bbappends, meta-clutter would be self-contained in this regard. I don't think there is any point in bothering the list with this discussion any further, we have gone around the circle more than once. The whole point of the proposal was to make maintaining, using and supporting the clutter packages easier for everyone, but it seems I underestimated how important Clutter is to oe-core, and I am already looking forward to this newly discovered importance being translated into user happiness before too long. :) I'd prefer we keep meta-clutter working until it happens ;-) -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wednesday 15 May 2013 17:34:45 Tomas Frydrych wrote: On 15/05/13 15:09, Paul Eggleton wrote: Can you not just get the appropriate changes into the BSP layers so that when you add the BSP on top of OE-Core it does just work out of the box? What you are really saying is that the onus of maintaining working clutter packages should be on the BSP maintainers. I have already explained previously in this thread why I don't think this is going to work out in practice, so I am not going to repeat myself again. No, I'm not. I'm saying configuration specific to a machine, if there is any, needs to be in the BSP layer for that machine. Whether the maintainer of that BSP or some external contributor provides and maintains that is a separate question. If there are clutter tests we can run on the Yocto Project reference hardware platforms (which I understand from Bruce may be refreshed for 1.5) and they could be run in an automated manner, we can run these on the autobuilder and this will help prove the functionality of clutter itself. Once the tests are set up it should be easy for others to run these regularly on their own autobuilders with other BSPs. If clutter is taken out of OE-Core this becomes even harder because then BSPs can no longer bbappend clutter or cogl (if that is indeed what is required in order to enable machine-specific functionality) without fiddling around with BBMASK or keeping the appends in yet another separate layer so they don't impact other BSP users who aren't building Clutter. The BSPs would not need to do anything regarding clutter, no bbappends, meta-clutter would be self-contained in this regard. First you say there are hardware specific bits, then you say there aren't any changes required. I'm not following at all. I don't think there is any point in bothering the list with this discussion any further, we have gone around the circle more than once. Sorry, but I don't think the important questions have been answered yet. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
I'd ask that we give trying to make this work from OE-Core a fair try. If in say 3 months from now OE-Core is causing clutter users pain we can look again at the problem. Equally, if nobody has sent me any clutter patches in the next three months, I wouldn't consider than a fair try. I'm happy enough to see the clutter recipes architecture changed to better support their users. If that means adding some of the machine specific tweaks to the core as examples I'm also ok with that rather than forcing those into BSP layers. I'm not saying we'll take every machine entry into the core but enough to show its usages would be acceptable in my view. I do agree with the view that we have enough mailing lists and so on and adding more is not appropriate where this is at right now. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, May 15, 2013 at 2:30 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I'd ask that we give trying to make this work from OE-Core a fair try. If in say 3 months from now OE-Core is causing clutter users pain we can look again at the problem. Equally, if nobody has sent me any clutter patches in the next three months, I wouldn't consider than a fair try. No, this is not fair. If you wish to keep it you need to do the work or find someone to make it. Tomas is willing to work in meta-clutter and he has the right to work in his solution. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wednesday 15 May 2013 14:36:16 Otavio Salvador wrote: On Wed, May 15, 2013 at 2:30 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I'd ask that we give trying to make this work from OE-Core a fair try. If in say 3 months from now OE-Core is causing clutter users pain we can look again at the problem. Equally, if nobody has sent me any clutter patches in the next three months, I wouldn't consider than a fair try. No, this is not fair. If you wish to keep it you need to do the work or find someone to make it. Tomas is willing to work in meta-clutter and he has the right to work in his solution. Nobody's suggesting Tomas can't work on meta-clutter. This is an open source project, people are pretty much free to contribute as they see fit. For my part, I will try to make sure the clutter recipes in OE-Core are better maintained in future. However, I do think it's important for us to try to work together for the benefit of everyone, and when it comes to OE-Core and other central pieces of the OE ecosystem, that means trying to understand the bigger picture outside of the day-to-day requirements that we all have on the projects we work on individually. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, May 15, 2013 at 3:24 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 15 May 2013 14:36:16 Otavio Salvador wrote: On Wed, May 15, 2013 at 2:30 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I'd ask that we give trying to make this work from OE-Core a fair try. If in say 3 months from now OE-Core is causing clutter users pain we can look again at the problem. Equally, if nobody has sent me any clutter patches in the next three months, I wouldn't consider than a fair try. No, this is not fair. If you wish to keep it you need to do the work or find someone to make it. Tomas is willing to work in meta-clutter and he has the right to work in his solution. Nobody's suggesting Tomas can't work on meta-clutter. This is an open source project, people are pretty much free to contribute as they see fit. For my part, I will try to make sure the clutter recipes in OE-Core are better maintained in future. However, I do think it's important for us to try to work together for the benefit of everyone, and when it comes to OE-Core and other central pieces of the OE ecosystem, that means trying to understand the bigger picture outside of the day-to-day requirements that we all have on the projects we work on individually. I agree but it seems it hadn't succeed in this specific case until now. I personally think Clutter will benefit from getting a specific place to look at and it does seem multiple people has been adding Clutter recipes in their internal layers (Phil for example, Guacamayo project and so on). People did group in Guacamayo community and got it working in some platforms, it might have been backported to OE-Core by Yocto team as it is important for the test coverage but it didn't happen until now. So far, meta-clutter seems to be the way to go for me. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, 2013-05-15 at 20:30 +0300, Richard Purdie wrote: I'd ask that we give trying to make this work from OE-Core a fair try. If in say 3 months from now OE-Core is causing clutter users pain we can look again at the problem. Equally, if nobody has sent me any clutter patches in the next three months, I wouldn't consider than a fair try. I'm happy enough to see the clutter recipes architecture changed to better support their users. If that means adding some of the machine specific tweaks to the core as examples I'm also ok with that rather than forcing those into BSP layers. I'm not saying we'll take every machine entry into the core but enough to show its usages would be acceptable in my view. I do agree with the view that we have enough mailing lists and so on and adding more is not appropriate where this is at right now. Just to add, I went and looked at the code/data in meta-clutter again. The README says meta-clutter depends only on oe-core and is meant to be used with the current stable release of it (currently dylan).. How about the master branch gets renamed dylan so it clearly show what its meant to work against and follows the other repositories? I'd still propose we try and get the core pieces into OE-Core master so there is no need for a master branch of that repo. Currently if you try that repo with master, there will be duplicated sstate postfuncs being run which are probably harmless. There are also other duplicated recipes (master glib-2.0 is newer). Over time as master and dylan diverge there probably will be worse compatibility issues. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, 2013-05-15 at 16:28 -0300, Otavio Salvador wrote: I agree but it seems it hadn't succeed in this specific case until now. I personally think Clutter will benefit from getting a specific place to look at and it does seem multiple people has been adding Clutter recipes in their internal layers (Phil for example, Guacamayo project and so on). I did actually have a couple of goes at trying to factor out some of our local changes to the clutter recipes for submission to oe-core, but on each occasion I gave up because the effort seemed to outweigh the benefits. For what it's worth, some of the ways in which our local recipes diverge from what's in oe-core are: - we have a different (newer) version - we build from a local git checkout, srctree-style, because our sources are significantly patched compared to upstream - we use eglnative mostly, though we might start wanting to use glx under qemu for testing (subject to getting a suitable mesa) - we have a slightly funky 2-stage bootstrap process for cogl in order to break the dependency cycle with cairo; this involves hacks to the recipes for cogl, cairo, pango and harfbuzz (at least) which I suspect would not be very palatable to oe-core. The net result of all this is that, whenever I try to factor out a set of stuff that's generic clutter and could go into oe-core, I end up with recipes that have virtually nothing in common with what we're actually using and consequently don't actually solve any of my problems. However, I have no doubt that someone cleverer than me could do a better job of it. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Hi Phil, On 13/05/13 16:41, Phil Blundell wrote: It seems a bit hyperbolic to claim that testing clutter is impossible without GPU hardware (either real or emulated). The majority of the code even in cogl, and virtually all the code in clutter itself, is mostly independent of the underlying GL implementation. From the point of view of testing whether clutter basically works and is correctly built/packaged it seems as though this ought to be quite sufficient. There are too separate issues: testing clutter itself, and using clutter to test other parts of the graphics stack. Re the former, all you can say after testing cogl/clutter against mesa software rasterizer is that a particular configuration and a particular backend (in oe-core that would be the GLX backend) work with mesa software rasterizer. This says nothing about any other configuration, with any other backend or whether it works with any other GL/GLES implementation. In reality, cogl/clutter need patches to build against the likes of TI's GLES (e.g., Beagleboard) or to work on the likes of RaspberryPi, and these patches cannot be included in oe-core, of course, because oe-core knows nothing of such machines. Then there are little annoyances, like the fact that over the last year or so, clutter has tended to have a dependency on a specific but mostly random versions of libxkbcommon (from what I can gather, determined more then anything by whatever the Fedora packager happened to package and what version of Fedora the clutter maintainer was using), or Clutter's customary insistence on as recent glib as you can get. This can all be nicely encapsulated in small layer. Regarding using clutter to test other parts of the graphics stack, which is what Richard is wanting clutter in oe-core for, this amounts to testing mesa sw rasterizer. There is limited value here, it's the one GL implementation that nobody using Yocto to build images will be deploying for real, so this is a weak argument for needing clutter in oe-core. Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 05/11/2013 05:49 PM, Richard Purdie wrote: I will however raise the point that a lot of people currently have a tendency to hide behind me in discussions. They see me reply and assume that since I've said something, that is it and they can keep quiet. I want to be clear this isn't going to work as on this and some other topics, it looks like I'm a lone voice. If people do believe in a particular issue, they do need to stand up and add weight to an argument themselves. I'd like to emphasize this point. Sometimes, Richard seems to be all alone defending decisions that are made. If he is supporting your position, support him publicly. Otherwise, there is a perception in the community that Richard is acting alone. Also, getting a variety of viewpoints out really helps technical discussion. Sometimes it is the little details in individual use cases that become really important. Philip ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Tuesday 14 May 2013 10:14:20 Tomas Frydrych wrote: On 13/05/13 16:41, Phil Blundell wrote: It seems a bit hyperbolic to claim that testing clutter is impossible without GPU hardware (either real or emulated). The majority of the code even in cogl, and virtually all the code in clutter itself, is mostly independent of the underlying GL implementation. From the point of view of testing whether clutter basically works and is correctly built/packaged it seems as though this ought to be quite sufficient. There are too separate issues: testing clutter itself, and using clutter to test other parts of the graphics stack. Re the former, all you can say after testing cogl/clutter against mesa software rasterizer is that a particular configuration and a particular backend (in oe-core that would be the GLX backend) work with mesa software rasterizer. This says nothing about any other configuration, with any other backend or whether it works with any other GL/GLES implementation. In reality, cogl/clutter need patches to build against the likes of TI's GLES (e.g., Beagleboard) or to work on the likes of RaspberryPi, and these patches cannot be included in oe-core, of course, because oe-core knows nothing of such machines. Having clutter in OE-Core does not preclude such testing with additional BSPs, and I'm unclear on how moving it out to another layer helps at all with this specific issue. Then there are little annoyances, like the fact that over the last year or so, clutter has tended to have a dependency on a specific but mostly random versions of libxkbcommon (from what I can gather, determined more then anything by whatever the Fedora packager happened to package and what version of Fedora the clutter maintainer was using), or Clutter's customary insistence on as recent glib as you can get. This can all be nicely encapsulated in small layer. This could present a problem. What if I want Clutter but I don't want the latest version of glib, but instead the version that is being shipped with OE- Core that is tested with the other pieces of the system that depend upon it (especially given glib has recent history of breaking other packages)? Surely the safest alternative is the last stable version of Clutter that works with that version of glib? That would make it difficult to depend upon an external layer that provides its own newer version of glib would it not? There's no denying that the maintenance of the Clutter recipes in OE-Core has slipped. I don't think that is an argument in itself to split them out, that just means we need to recognise that and maintain those recipes more effectively. It's not a case where we've missed the release because it was too close, we've not updated it for longer than that. Honestly I think if Clutter continues to be something that people are using to develop applications we're much better off with the canonical stable version being in OE-Core. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Hi Mark, On 10/05/13 21:37, Mark Hatle wrote: One of the key pieces of the oe-core, it must be able to work without any additional layers. It also much be able to be tested without any additional layers. I personally don't have a preference for the clutter and related items on where they live... but I do want to make sure that oe-core can standalone as a starting point for people to develop devices. Part of being standalone means that it is capable of being tested. Yes, but the clutter packages are not being tested, and more to the point, they cannot be meaningfully tested using oe-core, because such testing has to be done against a real OGL/GLES implementation -- Clutter can only be tested properly in conjunction with BSP layer(s). All you can test with oe-core is the mesa software rasterizer, which is just about the one thing nobody cares about because it is of no practical use. There are two ways that tested clutter packages are achievable: a) Generic clutter recipes in oe-core and BSP specific bbappends in the BSP layers. There are a couple of problems with this: I don't think the BSP maintainers have time/impetus for maintaining the bbappends and testing Clutter, and the BSP support might need upgrading the base package and dependencies (plus Clutter is a fairly high level package to be part of a BSP anyway, IMO). b) A dedicated layer that is not subject to the oe-core constraints and can make reference to external BSP layers. Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Hi Richard, On 10/05/13 23:18, Richard Purdie wrote: I am sure we all want a solid release so I am also sure Tomas wouldn't put experimental version of clutter near of release. From what I read of Tomas' emails, I actually think his plans differ from that as he finds that aspect of OE-Core frustrating. I am no sure what 'aspect' of OE-Core you mean. If you mean the six-monthly releases, then you are reading my emails all wrong -- I am a firm believer. Regarding experimental releases -- I am not interested in them much myself, but with meta-clutter, we could, of course, have negative priority recipes for any interim developer snapshots, if that is what people need. But what I am looking for most are uptodate recipes for *stable* releases of clutter more or less as they happen. I don't touch layers I don't maintain. If I did that, I would get hung, drawn and quartered. Please at least think through things like this before saying them :(. Can you imagine what you'd say to me if I pushed commits to meta-fsl-arm? Just so we are clear, I am not trying to wrench clutter out of your control. For all I care, set up meta-clutter on g.yp.o, and put the current official maintainer of the clutter packages in oe-core in charge, but I don't think we can get a usable clutter support without a dedicated layer in the long run. Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Mon, 2013-05-13 at 10:30 +0100, Tomas Frydrych wrote: Yes, but the clutter packages are not being tested, and more to the point, they cannot be meaningfully tested using oe-core, because such testing has to be done against a real OGL/GLES implementation -- Clutter can only be tested properly in conjunction with BSP layer(s). All you can test with oe-core is the mesa software rasterizer, which is just about the one thing nobody cares about because it is of no practical use. It seems a bit hyperbolic to claim that testing clutter is impossible without GPU hardware (either real or emulated). The majority of the code even in cogl, and virtually all the code in clutter itself, is mostly independent of the underlying GL implementation. From the point of view of testing whether clutter basically works and is correctly built/packaged it seems as though this ought to be quite sufficient. Indeed, testing against Mesa is in some sense a benefit because you can exercise both the GL and GLES2 backends (and even GLES1 if you so desired) as well as all the windowing systems. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 13 May 2013 16:41, Phil Blundell p...@pbcl.net wrote: It seems a bit hyperbolic to claim that testing clutter is impossible without GPU hardware (either real or emulated). The majority of the code even in cogl, and virtually all the code in clutter itself, is mostly independent of the underlying GL implementation. From the point of view of testing whether clutter basically works and is correctly built/packaged it seems as though this ought to be quite sufficient. Indeed, testing against Mesa is in some sense a benefit because you can exercise both the GL and GLES2 backends (and even GLES1 if you so desired) as well as all the windowing systems. Well, the software renderer in Mesa that we're shipping doesn't work with Clutter. If we integrate llvm into oe-core then we can enable llvmpipe which does actually work with Clutter. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Fri, May 10, 2013 at 7:18 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2013-05-10 at 17:22 -0300, Otavio Salvador wrote: On Fri, May 10, 2013 at 2:19 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2013-05-10 at 17:39 +0100, Tomas Frydrych wrote: On 10/05/13 12:32, Richard Purdie wrote: On Fri, 2013-05-10 at 11:56 +0100, Tomas Frydrych wrote: On 10/05/13 10:05, Richard Purdie wrote: The closely track upstream is the key part and I think the core can do this, apart from the ~six week stabilisation window. If you mean you are prepared to do frequent point releases to keep up with clutter, that could work. But if you mean that those interested can closely track oe-core master, then that is not that useful, there are too many other changes happening at the same time. A small single purpose layer means updates (and breakages) can be very contained. Point releases of what? I don't mind clutter in master changing quite a lot up to our stabilisation point. Once we've released, I don't mind someone else picking up a danny-clutter branch or something like that which is backporting specific changes. So we're going to have branch-pet package branches? There may be a time and a place for such things and its not different to the situation you'll end up in with a meta-clutter repository where you'll likely end up with danny-1.12 and danny-1.14 branches, or multiple sets of recipes in a single danny branch, thereby changing the definition of stable from that used in the core which will be confusing in itself. I don't think we need separated branches in a clutter specific layer, we just need to keep versions around so custom BSPs can stick to a specific one. Putting multiple branches on OE-Core/Poky confuse all users and also blocks on you for merges, fixes and like. It just does not scale. I think this does not scale and I am at Tomas side. The layer seems the right thing to do so it does not need to be done by branch and avoid confusing users. You're swapping one set of problems for another set the way I see it. No. We're making use of modular design and taking profit of it. My argument for this is that I really do want to stress out the graphics stack we have, clutter provides a good way to test some of those components, particularly some of the more unusual parts. Currently its mostly build test however we do have plans to make that runtime too. I do think that clutters unusual usage of the stack makes it particular useful in this role. I'd appreciate help from anyone who can help make this all work. I am all for this, but does using clutter for automated tests require for the clutter packages to be in oe-core? The only thing you can stress test in oe-core using clutter is mesa, which is only applicable to the i915/i965 chip sets. I think it would be useful if any such tests could be applied to other graphics stacks provided by BSPs; I think all of the BSPs would benefit from this. We'd be able to test mesa and the software fallbacks under qemu which would be a start. If we can get those working with a decent framework for the tests, I'm hoping wider BSP testing would follow. I don't have unlimited resources available but I can try and get the software infrastructure to the point where doing the testing could be picked up by someone else relatively easily. You could do just the same but adding meta-clutter to the AB setup for testing. One thing does not conflict with the another. I've always been extremely clear that I believe the core needs to stand on its own, including being testable. I appreciate some people disagree with that however I believe that without this, the quality in the core would drop substantially. Even maintaining the testability of what we have now is actually an incredible challenge. Anyone who thinks otherwise should spend a week triaging the autobuilder failures. And I fully agree but this does not mean we should have core growing. We can have core and also a small set of layers which are added to some tests, this also helps to uncover layer related issues and is also import to test. Nobody thinks it is easy but being hard doesn't mean it is right. Yocto community is growing and we will always have good and bad layers. The bad ones shouldn't be part of the test base, just it. Adding mode dimensions to a problem we already struggle with seems like a bad idea to me. This sounds like you're against the modular design and it is no sense for me. These dimensions also need test and if it cannot be done, we have a design flaw. It is a big help in trying to achieve this if we don't have many different layers involved as that would complicate the problem, even coordinating layer releases between different maintainers is tricky right now and trying to develop something like this over layer boundaries sounds like adding to
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Sat, 2013-05-11 at 17:39 -0300, Otavio Salvador wrote: On Fri, May 10, 2013 at 7:18 PM, Richard Purdie Adding mode dimensions to a problem we already struggle with seems like a bad idea to me. This sounds like you're against the modular design and it is no sense for me. These dimensions also need test and if it cannot be done, we have a design flaw. You think I'm against modular design? Seriously? Keep in mind I'm the person who played a big part in helping transition to the layers model in the first place instead of the monolithic OE classic, split up the fetchers in bitbake, split bitbake into client/server/uis and so on. My instinct is suggesting the timing is wrong for this particular change (it may be right for Tomas, I don't think its right for OE-Core). I've said what I plan to say on this now though. I will however raise the point that a lot of people currently have a tendency to hide behind me in discussions. They see me reply and assume that since I've said something, that is it and they can keep quiet. I want to be clear this isn't going to work as on this and some other topics, it looks like I'm a lone voice. If people do believe in a particular issue, they do need to stand up and add weight to an argument themselves. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, 2013-05-08 at 17:20 +0100, Tomas Frydrych wrote: On 08/05/13 16:23, Richard Purdie wrote: On Wed, 2013-05-08 at 16:11 +0100, Tomas Frydrych wrote: I think it would makes sense to move clutter related packages from oe-core into a dedicated layer: * AFAIK nothing in oe-core requires cogl/clutter/mx, * The packages in oe-core are effectively unmaintained, several upstream releases behind, and pretty much unusable, * The somewhat random nature of clutter and cogl releases makes it hard to sensibly manage these packages within the oe-core release cycle, but a dedicated layer could follow the upstream developments. I have started work on new clutter and related packages for use by meta-guacamayo at https://github.com/Guacamayo/meta-clutter, but I'd be more than happy for the layer to live somewhere else and become the canonical location for clutter-related bits and pieces. I have no idea why you've always felt the need to maintain the clutter pieces in your own layer rather than interacting with the ones in OE-Core instead which I'd love to see better maintained. I'm not aware of any barrier that has prevented that. It's mostly a matter of timing. Clutter does not provide LTS releases, it pretty much deprecates the previous stable branch as soon as new stable branch is started, so tracking the upstream reasonably quickly matters. The timing for the danny oe-core release and the arrival of clutter 1.12 was such that it simply could not have made it into oe-core. Needing 1.12 I had no option than to package it elsewhere. Yes, I could have submitted clutter 1.12 recipes to oe-core in some form and shape in the last 6 months, and we would have had a less outdated package in oe-core; but nevertheless outdated, since again the clutter 1.14 release came too late to make it into dylan. I can see this happening again and again. The trouble is you can make this argument for every single piece of software in OE-Core. There was nothing stopping you pushing the 1.12 work back into what became dylan as soon as it opened up for changes. There was also nothing you maintaining an a branch of danny with the 1.12 updates backported into it. If there is a good reason to maintain clutter, cogl and mx in oe-core, then I'll make patches for 1.14, but I am not convinced there is a good reason, and that everyone would be better served by a dedicated layer. A dedicated layer will still have timing issues, it will just move onto your personal schedule rather than the OE-Core one and whilst this will obviously suit you, it likely won't suit all other users. I suspect the bigger problem here is that clutter is hard to write recipes for since it needs to suit a number of different targets and configurations. Going to the effort of doing a generic implementation in OE-Core is hard, whereas creating your own layer means you can customise to your usecase and not worry about the other cases. I suspect your reply to this will be that anyone wanting to add other cases can send you patches. The implication is that the layer will become much more specialised/focused than the core recipes currently are. My preference would still be to fix up the recipes in the core, than have some specific branches for danny/dylan with the 1.12/1.14 components in if/as needed. We can create the core recipes so they're properly configurable to the different usecases. From what I gather you're going ahead with meta-clutter anyway though :/. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
Hi Richard, On 10/05/13 10:05, Richard Purdie wrote: Yes, I could have submitted clutter 1.12 recipes to oe-core in some form and shape in the last 6 months, and we would have had a less outdated package in oe-core; but nevertheless outdated, since again the clutter 1.14 release came too late to make it into dylan. I can see this happening again and again. The trouble is you can make this argument for every single piece of software in OE-Core. The clutter related packages are the only ones where I have run into this problem. In the last 12 months clutter went through 7 stable releases or so, of these there were 3 minor version changes, which signal API changes, another minor version change, as well as a major version change to 2.0, is on the horizon. If you are developing an application using clutter; you need to keep up. If you are using Yocto/OE to develop an application using clutter (and people do), then everyone is left to maintain their own rolling recipes. A dedicated layer will still have timing issues, it will just move onto your personal schedule rather than the OE-Core one and whilst this will obviously suit you, it likely won't suit all other users. For a small dedicated layer the schedule can closely track the upstream. It might not suit all clutter users, but I think it could be made to work for most of them; the current situation suits no one at all. I suspect the bigger problem here is that clutter is hard to write recipes for since it needs to suit a number of different targets and configurations. Going to the effort of doing a generic implementation in OE-Core is hard, whereas creating your own layer means you can customise to your usecase and not worry about the other cases. I suspect your reply to this will be that anyone wanting to add other cases can send you patches. The implication is that the layer will become much more specialised/focused than the core recipes currently are. My reply is that it clutter is not that complex, there are only a finite number of possible configurations that make sense and it should be entirely possible to write a good base recipe that can be easily tweaked using a bbappend based on machine and distro needs. But that's not the real issue. My preference would still be to fix up the recipes in the core, than have some specific branches for danny/dylan with the 1.12/1.14 components in if/as needed. We can create the core recipes so they're properly configurable to the different usecases. Fixing up the recipes in oe-core only addresses one aspect of the problem. The fast turnover of the clutter packages will remain, as will the fact that nothing in oe-core uses clutter, so the oe-core packages are untested. Then there is the fact that oe-core does not have any machines that clutter could be really used with. Then there are also other projects that are closely tied to clutter version, such as (the recently removed) mutter, and, dare I say, GnomeShell, which should be maintained together. I am still to hear any reason why clutter should be in oe-core ... the same logic that said mutter should be removed from oe-core applies to clutter, I think. Tomas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Fri, 2013-05-10 at 11:56 +0100, Tomas Frydrych wrote: Hi Richard, On 10/05/13 10:05, Richard Purdie wrote: Yes, I could have submitted clutter 1.12 recipes to oe-core in some form and shape in the last 6 months, and we would have had a less outdated package in oe-core; but nevertheless outdated, since again the clutter 1.14 release came too late to make it into dylan. I can see this happening again and again. The trouble is you can make this argument for every single piece of software in OE-Core. The clutter related packages are the only ones where I have run into this problem. That is down to the particular development focus you have right now though. To pick another example, if you're doing arm64 work, the toolchain is horribly dated in the core. I dare say you could have this issue for any of the software components (glib, gtk+) and so on. In the last 12 months clutter went through 7 stable releases or so, of these there were 3 minor version changes, which signal API changes, another minor version change, as well as a major version change to 2.0, is on the horizon. If you are developing an application using clutter; you need to keep up. If you are using Yocto/OE to develop an application using clutter (and people do), then everyone is left to maintain their own rolling recipes. I'd hope that with a decent set of core .inc files in OE-Core, this wouldn't be a big issue as you could add those newer versions trivially, then drop them as they make it into the core. A dedicated layer will still have timing issues, it will just move onto your personal schedule rather than the OE-Core one and whilst this will obviously suit you, it likely won't suit all other users. For a small dedicated layer the schedule can closely track the upstream. It might not suit all clutter users, but I think it could be made to work for most of them; the current situation suits no one at all. The closely track upstream is the key part and I think the core can do this, apart from the ~six week stabilisation window. I suspect the bigger problem here is that clutter is hard to write recipes for since it needs to suit a number of different targets and configurations. Going to the effort of doing a generic implementation in OE-Core is hard, whereas creating your own layer means you can customise to your usecase and not worry about the other cases. I suspect your reply to this will be that anyone wanting to add other cases can send you patches. The implication is that the layer will become much more specialised/focused than the core recipes currently are. My reply is that it clutter is not that complex, there are only a finite number of possible configurations that make sense and it should be entirely possible to write a good base recipe that can be easily tweaked using a bbappend based on machine and distro needs. But that's not the real issue. I agree it should be entirely possible. My preference would still be to fix up the recipes in the core, than have some specific branches for danny/dylan with the 1.12/1.14 components in if/as needed. We can create the core recipes so they're properly configurable to the different usecases. Fixing up the recipes in oe-core only addresses one aspect of the problem. The fast turnover of the clutter packages will remain, as will the fact that nothing in oe-core uses clutter, so the oe-core packages are untested. Then there is the fact that oe-core does not have any machines that clutter could be really used with. Then there are also other projects that are closely tied to clutter version, such as (the recently removed) mutter, and, dare I say, GnomeShell, which should be maintained together. Well, I originally tried to insist we had some mechanism for testing clutter in OE-Core however the pieces have either become obsoleted or removed for other reasons. I do really want to see ptest packages for clutter which the autobuilder would call into and run. I appreciate GL support under qemu through software rendering is currently problematic but I want to see that fixed in the 1.5 cycle. I am still to hear any reason why clutter should be in oe-core ... the same logic that said mutter should be removed from oe-core applies to clutter, I think. My argument for this is that I really do want to stress out the graphics stack we have, clutter provides a good way to test some of those components, particularly some of the more unusual parts. Currently its mostly build test however we do have plans to make that runtime too. I do think that clutters unusual usage of the stack makes it particular useful in this role. I'd appreciate help from anyone who can help make this all work. I would therefore like to see a decent set of clutter recipes in the core. I keep hearing people arguing for removing many different pieces of the core. I continue to believe we do need a small set of diverse technologies in the core,
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 10/05/13 12:32, Richard Purdie wrote: On Fri, 2013-05-10 at 11:56 +0100, Tomas Frydrych wrote: On 10/05/13 10:05, Richard Purdie wrote: The closely track upstream is the key part and I think the core can do this, apart from the ~six week stabilisation window. If you mean you are prepared to do frequent point releases to keep up with clutter, that could work. But if you mean that those interested can closely track oe-core master, then that is not that useful, there are too many other changes happening at the same time. A small single purpose layer means updates (and breakages) can be very contained. My argument for this is that I really do want to stress out the graphics stack we have, clutter provides a good way to test some of those components, particularly some of the more unusual parts. Currently its mostly build test however we do have plans to make that runtime too. I do think that clutters unusual usage of the stack makes it particular useful in this role. I'd appreciate help from anyone who can help make this all work. I am all for this, but does using clutter for automated tests require for the clutter packages to be in oe-core? The only thing you can stress test in oe-core using clutter is mesa, which is only applicable to the i915/i965 chip sets. I think it would be useful if any such tests could be applied to other graphics stacks provided by BSPs; I think all of the BSPs would benefit from this. I'd really like for people to be able to just pick up uptodate and working clutter packages for the major platforms the actively maintained BSPs support. Every so often someone asks about clutter for XYZ (usually the Beagleboard or RPi) on the clutter list: this should be readily available somewhere. have a good weekend everyone, Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Fri, 2013-05-10 at 17:39 +0100, Tomas Frydrych wrote: On 10/05/13 12:32, Richard Purdie wrote: On Fri, 2013-05-10 at 11:56 +0100, Tomas Frydrych wrote: On 10/05/13 10:05, Richard Purdie wrote: The closely track upstream is the key part and I think the core can do this, apart from the ~six week stabilisation window. If you mean you are prepared to do frequent point releases to keep up with clutter, that could work. But if you mean that those interested can closely track oe-core master, then that is not that useful, there are too many other changes happening at the same time. A small single purpose layer means updates (and breakages) can be very contained. Point releases of what? I don't mind clutter in master changing quite a lot up to our stabilisation point. Once we've released, I don't mind someone else picking up a danny-clutter branch or something like that which is backporting specific changes. My argument for this is that I really do want to stress out the graphics stack we have, clutter provides a good way to test some of those components, particularly some of the more unusual parts. Currently its mostly build test however we do have plans to make that runtime too. I do think that clutters unusual usage of the stack makes it particular useful in this role. I'd appreciate help from anyone who can help make this all work. I am all for this, but does using clutter for automated tests require for the clutter packages to be in oe-core? The only thing you can stress test in oe-core using clutter is mesa, which is only applicable to the i915/i965 chip sets. I think it would be useful if any such tests could be applied to other graphics stacks provided by BSPs; I think all of the BSPs would benefit from this. We'd be able to test mesa and the software fallbacks under qemu which would be a start. If we can get those working with a decent framework for the tests, I'm hoping wider BSP testing would follow. I don't have unlimited resources available but I can try and get the software infrastructure to the point where doing the testing could be picked up by someone else relatively easily. It is a big help in trying to achieve this if we don't have many different layers involved as that would complicate the problem, even coordinating layer releases between different maintainers is tricky right now and trying to develop something like this over layer boundaries sounds like adding to the complexity to the point I'd rather just scrap the idea :(. I'd really like for people to be able to just pick up uptodate and working clutter packages for the major platforms the actively maintained BSPs support. Agreed. Every so often someone asks about clutter for XYZ (usually the Beagleboard or RPi) on the clutter list: this should be readily available somewhere. I'd hope the recipes in the core would be in a good state in this regard. Have a good weekend. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Fri, May 10, 2013 at 2:19 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2013-05-10 at 17:39 +0100, Tomas Frydrych wrote: On 10/05/13 12:32, Richard Purdie wrote: On Fri, 2013-05-10 at 11:56 +0100, Tomas Frydrych wrote: On 10/05/13 10:05, Richard Purdie wrote: The closely track upstream is the key part and I think the core can do this, apart from the ~six week stabilisation window. If you mean you are prepared to do frequent point releases to keep up with clutter, that could work. But if you mean that those interested can closely track oe-core master, then that is not that useful, there are too many other changes happening at the same time. A small single purpose layer means updates (and breakages) can be very contained. Point releases of what? I don't mind clutter in master changing quite a lot up to our stabilisation point. Once we've released, I don't mind someone else picking up a danny-clutter branch or something like that which is backporting specific changes. So we're going to have branch-pet package branches? I think this does not scale and I am at Tomas side. The layer seems the right thing to do so it does not need to be done by branch and avoid confusing users. My argument for this is that I really do want to stress out the graphics stack we have, clutter provides a good way to test some of those components, particularly some of the more unusual parts. Currently its mostly build test however we do have plans to make that runtime too. I do think that clutters unusual usage of the stack makes it particular useful in this role. I'd appreciate help from anyone who can help make this all work. I am all for this, but does using clutter for automated tests require for the clutter packages to be in oe-core? The only thing you can stress test in oe-core using clutter is mesa, which is only applicable to the i915/i965 chip sets. I think it would be useful if any such tests could be applied to other graphics stacks provided by BSPs; I think all of the BSPs would benefit from this. We'd be able to test mesa and the software fallbacks under qemu which would be a start. If we can get those working with a decent framework for the tests, I'm hoping wider BSP testing would follow. I don't have unlimited resources available but I can try and get the software infrastructure to the point where doing the testing could be picked up by someone else relatively easily. You could do just the same but adding meta-clutter to the AB setup for testing. One thing does not conflict with the another. It is a big help in trying to achieve this if we don't have many different layers involved as that would complicate the problem, even coordinating layer releases between different maintainers is tricky right now and trying to develop something like this over layer boundaries sounds like adding to the complexity to the point I'd rather just scrap the idea :(. Well if layers make life harder it invalidates one of points of Yocto which I always liked and depends on heavily - modular design. I am sure we all want a solid release so I am also sure Tomas wouldn't put experimental version of clutter near of release. We are eating our own dog food so we are all interested in make it work, not the opposed. In this case I think it can be well coordinated. One possible thing is you could require AB used layers to be at git.yoctoproject.org so in case of broken recipes (bbappend or so) you could rename it. I'd really like for people to be able to just pick up uptodate and working clutter packages for the major platforms the actively maintained BSPs support. Agreed. Every so often someone asks about clutter for XYZ (usually the Beagleboard or RPi) on the clutter list: this should be readily available somewhere. I'd hope the recipes in the core would be in a good state in this regard. Good weekend for everyone :-) Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 5/10/13 3:22 PM, Otavio Salvador wrote: On Fri, May 10, 2013 at 2:19 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2013-05-10 at 17:39 +0100, Tomas Frydrych wrote: On 10/05/13 12:32, Richard Purdie wrote: On Fri, 2013-05-10 at 11:56 +0100, Tomas Frydrych wrote: On 10/05/13 10:05, Richard Purdie wrote: The closely track upstream is the key part and I think the core can do this, apart from the ~six week stabilisation window. If you mean you are prepared to do frequent point releases to keep up with clutter, that could work. But if you mean that those interested can closely track oe-core master, then that is not that useful, there are too many other changes happening at the same time. A small single purpose layer means updates (and breakages) can be very contained. Point releases of what? I don't mind clutter in master changing quite a lot up to our stabilisation point. Once we've released, I don't mind someone else picking up a danny-clutter branch or something like that which is backporting specific changes. So we're going to have branch-pet package branches? I think this does not scale and I am at Tomas side. The layer seems the right thing to do so it does not need to be done by branch and avoid confusing users. My argument for this is that I really do want to stress out the graphics stack we have, clutter provides a good way to test some of those components, particularly some of the more unusual parts. Currently its mostly build test however we do have plans to make that runtime too. I do think that clutters unusual usage of the stack makes it particular useful in this role. I'd appreciate help from anyone who can help make this all work. I am all for this, but does using clutter for automated tests require for the clutter packages to be in oe-core? The only thing you can stress test in oe-core using clutter is mesa, which is only applicable to the i915/i965 chip sets. I think it would be useful if any such tests could be applied to other graphics stacks provided by BSPs; I think all of the BSPs would benefit from this. We'd be able to test mesa and the software fallbacks under qemu which would be a start. If we can get those working with a decent framework for the tests, I'm hoping wider BSP testing would follow. I don't have unlimited resources available but I can try and get the software infrastructure to the point where doing the testing could be picked up by someone else relatively easily. You could do just the same but adding meta-clutter to the AB setup for testing. One thing does not conflict with the another. It is a big help in trying to achieve this if we don't have many different layers involved as that would complicate the problem, even coordinating layer releases between different maintainers is tricky right now and trying to develop something like this over layer boundaries sounds like adding to the complexity to the point I'd rather just scrap the idea :(. Well if layers make life harder it invalidates one of points of Yocto which I always liked and depends on heavily - modular design. One of the key pieces of the oe-core, it must be able to work without any additional layers. It also much be able to be tested without any additional layers. I personally don't have a preference for the clutter and related items on where they live... but I do want to make sure that oe-core can standalone as a starting point for people to develop devices. Part of being standalone means that it is capable of being tested. --Mark I am sure we all want a solid release so I am also sure Tomas wouldn't put experimental version of clutter near of release. We are eating our own dog food so we are all interested in make it work, not the opposed. In this case I think it can be well coordinated. One possible thing is you could require AB used layers to be at git.yoctoproject.org so in case of broken recipes (bbappend or so) you could rename it. I'd really like for people to be able to just pick up uptodate and working clutter packages for the major platforms the actively maintained BSPs support. Agreed. Every so often someone asks about clutter for XYZ (usually the Beagleboard or RPi) on the clutter list: this should be readily available somewhere. I'd hope the recipes in the core would be in a good state in this regard. Good weekend for everyone :-) Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Fri, May 10, 2013 at 05:22:47PM -0300, Otavio Salvador wrote: Well if layers make life harder it invalidates one of points of Yocto which I always liked and depends on heavily - modular design. +1 people are using many layers, so oe-core being regularly tested together with some other layers is just another test for propagated modular design. I am sure we all want a solid release so I am also sure Tomas wouldn't put experimental version of clutter near of release. We are eating our own dog food so we are all interested in make it work, not the opposed. In this case I think it can be well coordinated. he can even put experimental version there if it's in recipe with negative DEFAULT_PREFERRENCE, unfortunately he cannot do the same if experimantal recipes are in meta-clutter with higher priority and stable recipes in oe-core (unless he makes sure that everybody who is using meta-clutter will understand why he needs to set PREFERRED_VERSION to prevent experimental being used). -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Fri, May 10, 2013 at 5:37 PM, Mark Hatle mark.ha...@windriver.com wrote: On 5/10/13 3:22 PM, Otavio Salvador wrote: Well if layers make life harder it invalidates one of points of Yocto which I always liked and depends on heavily - modular design. One of the key pieces of the oe-core, it must be able to work without any additional layers. It also much be able to be tested without any additional layers. I personally don't have a preference for the clutter and related items on where they live... but I do want to make sure that oe-core can standalone as a starting point for people to develop devices. Part of being standalone means that it is capable of being tested. This wouldn't be a regression as it was not used widely for testing. Clutter would be much more useful for users if it could profit of a more active users base and avoid 'in-house' solutions and forks so I only see good points in split it out from OE-Core. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Fri, 2013-05-10 at 17:22 -0300, Otavio Salvador wrote: On Fri, May 10, 2013 at 2:19 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Fri, 2013-05-10 at 17:39 +0100, Tomas Frydrych wrote: On 10/05/13 12:32, Richard Purdie wrote: On Fri, 2013-05-10 at 11:56 +0100, Tomas Frydrych wrote: On 10/05/13 10:05, Richard Purdie wrote: The closely track upstream is the key part and I think the core can do this, apart from the ~six week stabilisation window. If you mean you are prepared to do frequent point releases to keep up with clutter, that could work. But if you mean that those interested can closely track oe-core master, then that is not that useful, there are too many other changes happening at the same time. A small single purpose layer means updates (and breakages) can be very contained. Point releases of what? I don't mind clutter in master changing quite a lot up to our stabilisation point. Once we've released, I don't mind someone else picking up a danny-clutter branch or something like that which is backporting specific changes. So we're going to have branch-pet package branches? There may be a time and a place for such things and its not different to the situation you'll end up in with a meta-clutter repository where you'll likely end up with danny-1.12 and danny-1.14 branches, or multiple sets of recipes in a single danny branch, thereby changing the definition of stable from that used in the core which will be confusing in itself. I think this does not scale and I am at Tomas side. The layer seems the right thing to do so it does not need to be done by branch and avoid confusing users. You're swapping one set of problems for another set the way I see it. My argument for this is that I really do want to stress out the graphics stack we have, clutter provides a good way to test some of those components, particularly some of the more unusual parts. Currently its mostly build test however we do have plans to make that runtime too. I do think that clutters unusual usage of the stack makes it particular useful in this role. I'd appreciate help from anyone who can help make this all work. I am all for this, but does using clutter for automated tests require for the clutter packages to be in oe-core? The only thing you can stress test in oe-core using clutter is mesa, which is only applicable to the i915/i965 chip sets. I think it would be useful if any such tests could be applied to other graphics stacks provided by BSPs; I think all of the BSPs would benefit from this. We'd be able to test mesa and the software fallbacks under qemu which would be a start. If we can get those working with a decent framework for the tests, I'm hoping wider BSP testing would follow. I don't have unlimited resources available but I can try and get the software infrastructure to the point where doing the testing could be picked up by someone else relatively easily. You could do just the same but adding meta-clutter to the AB setup for testing. One thing does not conflict with the another. I've always been extremely clear that I believe the core needs to stand on its own, including being testable. I appreciate some people disagree with that however I believe that without this, the quality in the core would drop substantially. Even maintaining the testability of what we have now is actually an incredible challenge. Anyone who thinks otherwise should spend a week triaging the autobuilder failures. Adding mode dimensions to a problem we already struggle with seems like a bad idea to me. It is a big help in trying to achieve this if we don't have many different layers involved as that would complicate the problem, even coordinating layer releases between different maintainers is tricky right now and trying to develop something like this over layer boundaries sounds like adding to the complexity to the point I'd rather just scrap the idea :(. Well if layers make life harder it invalidates one of points of Yocto which I always liked and depends on heavily - modular design. The layer model has its risks as well as its advantages. The risk is that we end up too fragmented, with too many maintainers who don't communicate and nothing ever works together. Even as the model stands today, its showing signs of strain. I posted patches near enough three weeks ago for meta-raspberrypi, no response. I know there are reasons why but they're not visible. The meta-fsl layers appear to spend more of their time not building than building and getting people to fix those in a timely fashion can sometimes be challenging, particularly with the split between arm and ppc and some of the transitions going on there etc. Right now, I think there are enough splits causing enough interoperability issues to be going on with in the layers and no, to be quite honest I don't think more layers is the right answer right now.
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, 2013-05-08 at 16:11 +0100, Tomas Frydrych wrote: I think it would makes sense to move clutter related packages from oe-core into a dedicated layer: * AFAIK nothing in oe-core requires cogl/clutter/mx, * The packages in oe-core are effectively unmaintained, several upstream releases behind, and pretty much unusable, I think this would be a fine idea. As you observe, the recipes in oe-core today are old, slightly hokey, and not a whole lot of use for much. We are currently maintaining our own clutter recipes in a local layer but it would be nice to have something else upstream to lean on. One particular issue for us is that the clutter recipes as they stand in oe-core are very X11-centric. We don't have X and, instead, use the eglnative backend. It'd be handy for us if some putative refactoring of the recipes made them more friendly to non-X11 deployments. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On Wed, 2013-05-08 at 16:11 +0100, Tomas Frydrych wrote: I think it would makes sense to move clutter related packages from oe-core into a dedicated layer: * AFAIK nothing in oe-core requires cogl/clutter/mx, * The packages in oe-core are effectively unmaintained, several upstream releases behind, and pretty much unusable, * The somewhat random nature of clutter and cogl releases makes it hard to sensibly manage these packages within the oe-core release cycle, but a dedicated layer could follow the upstream developments. I have started work on new clutter and related packages for use by meta-guacamayo at https://github.com/Guacamayo/meta-clutter, but I'd be more than happy for the layer to live somewhere else and become the canonical location for clutter-related bits and pieces. I have no idea why you've always felt the need to maintain the clutter pieces in your own layer rather than interacting with the ones in OE-Core instead which I'd love to see better maintained. I'm not aware of any barrier that has prevented that. I can't help feeling this is an artificially created problem :/. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 08/05/13 16:23, Richard Purdie wrote: On Wed, 2013-05-08 at 16:11 +0100, Tomas Frydrych wrote: I think it would makes sense to move clutter related packages from oe-core into a dedicated layer: * AFAIK nothing in oe-core requires cogl/clutter/mx, * The packages in oe-core are effectively unmaintained, several upstream releases behind, and pretty much unusable, * The somewhat random nature of clutter and cogl releases makes it hard to sensibly manage these packages within the oe-core release cycle, but a dedicated layer could follow the upstream developments. I have started work on new clutter and related packages for use by meta-guacamayo at https://github.com/Guacamayo/meta-clutter, but I'd be more than happy for the layer to live somewhere else and become the canonical location for clutter-related bits and pieces. I have no idea why you've always felt the need to maintain the clutter pieces in your own layer rather than interacting with the ones in OE-Core instead which I'd love to see better maintained. I'm not aware of any barrier that has prevented that. It's mostly a matter of timing. Clutter does not provide LTS releases, it pretty much deprecates the previous stable branch as soon as new stable branch is started, so tracking the upstream reasonably quickly matters. The timing for the danny oe-core release and the arrival of clutter 1.12 was such that it simply could not have made it into oe-core. Needing 1.12 I had no option than to package it elsewhere. Yes, I could have submitted clutter 1.12 recipes to oe-core in some form and shape in the last 6 months, and we would have had a less outdated package in oe-core; but nevertheless outdated, since again the clutter 1.14 release came too late to make it into dylan. I can see this happening again and again. If there is a good reason to maintain clutter, cogl and mx in oe-core, then I'll make patches for 1.14, but I am not convinced there is a good reason, and that everyone would be better served by a dedicated layer. Tomas ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] proposal to move cogl, clutter and related recipes from oe-core to dedicated meta-clutter layer
On 08/05/13 16:23, Phil Blundell wrote: One particular issue for us is that the clutter recipes as they stand in oe-core are very X11-centric. We don't have X and, instead, use the eglnative backend. It'd be handy for us if some putative refactoring of the recipes made them more friendly to non-X11 deployments. I have a similar problem in Guacamayo, where I have more than one target machine, and generally prefer to use the elg-native backend unless it cannot be avoided because the elg driver is too broken. So the recipes in Guacamayo were set up so as to make it easy to reconfigure the packages based on machine and distro features using a mininal bbappend, e.g., https://github.com/Guacamayo/meta-guacamayo/blob/master/meta-guacamayo/recipes-graphics/clutter/clutter-1.12_git.bbappend. The original recipes are too much marked by the specifics of the Guacamayo set up and their gradual evolution, but I am in the process of cleaning this up, so it can be used by others. Tomas -- http://sleepfive.com ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
