Skip to contentSkip to conversation

Please submit your unindexed layers

DISCUSSION Paul Eggleton 4 participants 7 messages May 2, 2013 – May 7, 2013 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

Hi all,

Even a cursory search of github reveals that there are a growing number of layers being worked on in the community that aren't currently listed in the OE layer index. I don't think it would be right for us to just add all of these in bulk as we don't necessarily have all the needed information to do so, and it's not clear if some of them are forks, or if they will continue to be published in the same place, etc. So, what we really need is for the maintainers of these layers to submit them to the layer index themselves, or have someone else do it on their behalf.

If you're maintaining a publicly accessible layer that already does something useful and is not currently in the OE layer index, please submit it so that other folks in the community can find it easily. The submission form doesn't need a login and is pretty straightforward to fill in:

http://layers.openembedded.org/layerindex/submit/

If you have any problems or concerns please let me know.

Thanks!

Paul

Signature · 2 lines
Paul Eggleton
Intel Open Source Technology Centre
#1 lore raw
Quoted 16 lines · Paul Eggleton

Hi all,

Even a cursory search of github reveals that there are a growing number of layers being worked on in the community that aren't currently listed in the OE layer index. I don't think it would be right for us to just add all of these in bulk as we don't necessarily have all the needed information to do so, and it's not clear if some of them are forks, or if they will continue to be published in the same place, etc. So, what we really need is for the maintainers of these layers to submit them to the layer index themselves, or have someone else do it on their behalf.

If you're maintaining a publicly accessible layer that already does something useful and is not currently in the OE layer index, please submit it so that other folks in the community can find it easily. The submission form doesn't need a login and is pretty straightforward to fill in:

Quoted 8 lines

http://layers.openembedded.org/layerindex/submit/

If you have any problems or concerns please let me know.

Thanks!

Paul

While I do have a layer for GStreamer 1.0 , I did not want to add it to the index. My guess was that OE core developers might have been preparing recipes for GStreamer 1.0 for later OE core versions already, so the layer would then eventually be in conflict with OE core.

So, should I add it now?

#2 lore raw
Quoted 6 lines · On Thursday 02 May 2013 15:54:39 Carlos Rafael Giani wrote:

While I do have a layer for GStreamer 1.0 , I did not want to add it to the index. My guess was that OE core developers might have been preparing recipes for GStreamer 1.0 for later OE core versions already, so the layer would then eventually be in conflict with OE core.

So, should I add it now?

I guess it depends on how long it will take to integrate these recipes in OE- Core. If it's going to take more than a couple of weeks it's probably fine to add it to the index with a note saying the layer is temporary until the recipes are integrated.

Cristian, Ross - opinions?

Cheers,
Paul

Signature · 2 lines
Paul Eggleton
Intel Open Source Technology Centre

A message that is not in the archive (sent off-list or not yet received): 969F26A8BAB325438E7EB80D3C3134FB1622BB2A@IRSMSX102.ger.corp.intel.com

#4 lore raw
Quoted 21 lines · Cristian

Hello all,

My opinion is that we can directly integrate gstreamer-1.0 into oe-core, as it does not replace gstreamer-0.10. I did not test this scenario, so I don't know if it's working, but I will do that and see how it is working.

Regards,
Cristian

-----Original Message-----
From: Paul Eggleton [mailto:[email protected]]
Sent: Thursday, May 02, 2013 5:11 PM
To: [email protected]
Cc: Carlos Rafael Giani; Burton, Ross; Iorga, Cristian
Subject: Re: [oe] Please submit your unindexed layers

Quoted 5 lines · On Thursday 02 May 2013 15:54:39 Carlos Rafael Giani wrote:

While I do have a layer for GStreamer 1.0 , I did not want to add it to the index. My guess was that OE core developers might have been preparing recipes for GStreamer 1.0 for later OE core versions already, so the layer would then eventually be in conflict with OE core.

Quoted 8 lines
Quoted 1 line

So, should I add it now?

I guess it depends on how long it will take to integrate these recipes in OE- Core. If it's going to take more than a couple of weeks it's probably fine to add it to the index with a note saying the layer is temporary until the recipes are integrated.

Cristian, Ross - opinions?

Cheers,
Paul

I added support for dylan to meta-gstreamer1.0 . There are a few points I'd like to take care of before or during an integration into OE-Core:

* it uses _prepend in various places; I was able to replace all but one of them with prefuncs. The remaining one is populate_packages_prepend , and I just do not see how this could be turned into a prefunc. (And it is necessary to use it, because do_packages_split apparently cannot be used anywhere else.) I think prefuncs are cleaner, because they do not modify an existing
function. Also, if the indentation style changes again someday, prefuncs cause less problems than _prepend does.

* Empty -glib and -apps packages are generated, which are necessary, since the -meta packages depend on them. I think this can be done a bit smarter, that is, make the -meta package depend on these only if they are not empty.

* gstreamer1.0-omx contains a raspberrypi specific part, which is enabled explicitely. If enabled, it makes the package machine specific. It can be seen here: https://github.com/dv1/meta-gstreamer1.0/blob/master/recipes-multimedia/gstreamer/gstreamer1.0-omx.inc#L28 what is your opinion about this? (Also, it is currently missing a GSTREAMER_1_0_OMX_CORE_NAME setting , which is different for the raspberry pi than for bellagio.)

* The recipes make use of PACKAGECONFIG to enable/disable plugins with dependencies and some features (like Orc, or LGPL mode in gstreamer1.0-libav). I also explicitely disable any packages that were either not ported to 1.0 , or have dependencies without any known OE recipes in OE-Core or meta-oe . This is best shown in -bad : https://github.com/dv1/meta-gstreamer1.0/blob/master/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc#L21
I explicitely disable to make sure plugins do not appear all of a sudden if someday recipes for a previously unsupported dependency are added and the dependency is built with OE. Unfortuantely, upstream did not add a configuration option to disable all plugins with dependencies by default. (--with-plugins works only for dependencyless plugins.) I thought about patching configure.ac , but that would have to be done for all plugin packages (-base/-good/-bad/-ugly) , and seemed like something that involves more than a few lines, so I hesitated to do it. I'd like to hear your opinion about the way it is done now in the recipe.

* Is it okay to add _git versions of the recipes to oe-core?

#5 lore raw
Quoted 9 lines · Carlos Rafael Giani

* it uses _prepend in various places; I was able to replace all but one of them with prefuncs. The remaining one is populate_packages_prepend , and I just do not see how this could be turned into a prefunc. (And it is necessary to use it, because do_packages_split apparently cannot be used anywhere else.)
I think prefuncs are cleaner, because they do not modify an existing
function. Also, if the indentation style changes again someday, prefuncs cause less problems than _prepend does.

Warning: as things stand today, as far as I know, prefuncs/postfuncs don't affect the checksums of the variable they interact with, so changing the contents of a prefunc/postfunc won't cause the function to be re-run automatically. You can work around this by adding it to vardeps as well:

    do_foo[vardeps] += "bar"
    do_foo[prefuncs] += "bar"
Signature · 1 line
Christopher Larson
#6 lore raw
In reply to Carlos Rafael Giani
Quoted 8 lines · Carlos Rafael Giani

* it uses _prepend in various places; I was able to replace all but one of them with prefuncs. The remaining one is populate_packages_prepend , and I just do not see how this could be turned into a prefunc. (And it is necessary to use it, because do_packages_split apparently cannot be used anywhere else.)
I think prefuncs are cleaner, because they do not modify an existing
function. Also, if the indentation style changes again someday, prefuncs cause less problems than _prepend does.

The preferred way to do this is to use PACKAGESPLITFUNCS, examples in the systemd and update-rc.d classes.

Ross

#7 lore raw
In reply to Carlos Rafael Giani
Quoted 6 lines · Carlos Rafael Giani

While I do have a layer for GStreamer 1.0 , I did not want to add it to the index. My guess was that OE core developers might have been preparing recipes for GStreamer 1.0 for later OE core versions already, so the layer would then eventually be in conflict with OE core.

So, should I add it now?

Please add it, it's useful until it's integrated into oe-core. With that said, please re-base your branch to master and send it to the oe-core list - the sooner we get it in the better.

Ross