Please submit your unindexed layers

Please submit your unindexed layers

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

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

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

Thanks!

Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Please submit your unindexed layers

[Carlos Rafael Giani]

On 05/02/2013 03:27 PM, Paul Eggleton wrote:
> 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
>

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?

Re: Please submit your unindexed layers

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Please submit your unindexed layers

[Burton, Ross]

On 2 May 2013 14:54, Carlos Rafael Giani <dv@pseudoterminal.org> 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?

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

Re: Please submit your unindexed layers

[Carlos Rafael Giani]

On 05/07/2013 09:24 AM, Iorga, Cristian wrote:
> 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:paul.eggleton@linux.intel.com]
> Sent: Thursday, May 02, 2013 5:11 PM
> To: openembedded-devel@lists.openembedded.org
> Cc: Carlos Rafael Giani; Burton, Ross; Iorga, Cristian
> Subject: Re: [oe] Please submit your unindexed layers
>
> 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
>

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?

Re: Please submit your unindexed layers

[Chris Larson]

On Tue, May 7, 2013 at 3:49 AM, Carlos Rafael Giani
<dv@pseudoterminal.org>wrote:

> * 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"
-- 
Christopher Larson

Re: Please submit your unindexed layers

[Burton, Ross]

On 7 May 2013 11:49, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
> * 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