[RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[Martin Jansa]

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

1) layer priority, currently it has:
       BBFILE_PRIORITY_gplv2 = "1"
   which is lower than oe-core with:
       BBFILE_PRIORITY_core = "5"
   so in order to use recipes from meta-gplv2 layer, user has to add
   couple PREFERRED_VERSIONS. Was this intended use for meta-gplv2?
   I can see some advantages of this (that the layer can be included
   without immediate side effects), but on the other hand why would
   anyone include this layer if he isn't deeply scared from (L)GPLv3
   versions sneaking into the build?
   In our local builds I'm bumping the priority to 6 to resolve this.
   Alternatively we can add some conf/distro/gplv2-versions.inc file
   in meta-gplv2 so that people who want to use all available recipes
   in gplv2 compatible version can include it in their DISTRO.

2) branch for morty, currently the recipes aren't compatible with morty
   but with e.g. gnutls version added there it might be better option
   to share the gplv2 work there even when oe-core/morty contains most
   of these recipes as well.
   The recipes I had to modify to be compatible with morty are:
   https://github.com/shr-project/meta-gplv2/commits/jansa/morty
   88d1052 coreutils: make it compatible with Yocto 2.2 Morty
   5e08ac2 rsync: make it compatible with Yocto 2.2 Morty
   b33037f libiconv: make it compatible with Yocto 2.2 Morty

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

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

Re: [RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[Andre McCurdy]

On Fri, Apr 21, 2017 at 1:59 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> 1) layer priority, currently it has:
>        BBFILE_PRIORITY_gplv2 = "1"
>    which is lower than oe-core with:
>        BBFILE_PRIORITY_core = "5"
>    so in order to use recipes from meta-gplv2 layer, user has to add
>    couple PREFERRED_VERSIONS. Was this intended use for meta-gplv2?

I guess the intention is that if you blacklist GPLv3 etc then only the
recipes in meta-gplv2 will be considered.

>    I can see some advantages of this (that the layer can be included
>    without immediate side effects), but on the other hand why would
>    anyone include this layer if he isn't deeply scared from (L)GPLv3
>    versions sneaking into the build?
>    In our local builds I'm bumping the priority to 6 to resolve this.

If any of the recipes in meta-gplv2 still contain BBCLASSEXTEND =
"native" then that could cause problems (generally you only want to
use the older recipes for the target, not for -native).

>    Alternatively we can add some conf/distro/gplv2-versions.inc file
>    in meta-gplv2 so that people who want to use all available recipes
>    in gplv2 compatible version can include it in their DISTRO.
>
> 2) branch for morty, currently the recipes aren't compatible with morty
>    but with e.g. gnutls version added there it might be better option
>    to share the gplv2 work there even when oe-core/morty contains most
>    of these recipes as well.
>    The recipes I had to modify to be compatible with morty are:
>    https://github.com/shr-project/meta-gplv2/commits/jansa/morty
>    88d1052 coreutils: make it compatible with Yocto 2.2 Morty
>    5e08ac2 rsync: make it compatible with Yocto 2.2 Morty
>    b33037f libiconv: make it compatible with Yocto 2.2 Morty
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: [RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[Martin Jansa]

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

You're right, after fixing our tooling to correctly override
BBFILE_PRIORITY based on priorities in layer list I'm seeing such
issue.e.g. gstreamer failing with:

| autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac
              file requires the infrastructure from gettext-0.17 but this
version               is older. Please upgrade to gettext-0.17 or newer.
| autopoint: *** Stop.
|
| autopoint failed
| WARNING: exit code 1 from a shell command.

and similar issues in apt, grub, netcf, rrdtool.

There is quite a few native BBCLASSEXTENDs in meta-gplv2:
OE @ ~/meta-gplv2 $ git grep BBCLASSEXTEND
recipes-core/gettext/gettext_0.16.1.bb:BBCLASSEXTEND = "native nativesdk"
recipes-core/readline/readline_5.2.bb:BBCLASSEXTEND = "native nativesdk"
recipes-devtools/elfutils/elfutils_0.148.bb:BBCLASSEXTEND = "native
nativesdk"
recipes-devtools/m4/m4_1.4.9.bb:BBCLASSEXTEND = "nativesdk"
recipes-devtools/mtools/mtools_3.9.9.bb:BBCLASSEXTEND = "native nativesdk"
recipes-extended/cpio/cpio_v2.inc:BBCLASSEXTEND = "native"
recipes-extended/findutils/findutils.inc:BBCLASSEXTEND = "native nativesdk"
recipes-extended/gperf/gperf.inc:BBCLASSEXTEND = "native"
recipes-extended/libidn/libidn_0.6.14.bb:BBCLASSEXTEND = "native nativesdk"
recipes-extended/tar/tar.inc:BBCLASSEXTEND = "native nativesdk"
recipes-extended/texinfo/texinfo_4.8.bb:BBCLASSEXTEND = "native"
recipes-support/gdbm/gdbm_1.8.3.bb:BBCLASSEXTEND = "native nativesdk"
recipes-support/nettle/nettle.inc:BBCLASSEXTEND = "native nativesdk"





On Fri, Apr 21, 2017 at 11:19 PM, Andre McCurdy <armccurdy@gmail.com> wrote:

> On Fri, Apr 21, 2017 at 1:59 PM, Martin Jansa <martin.jansa@gmail.com>
> wrote:
> > 1) layer priority, currently it has:
> >        BBFILE_PRIORITY_gplv2 = "1"
> >    which is lower than oe-core with:
> >        BBFILE_PRIORITY_core = "5"
> >    so in order to use recipes from meta-gplv2 layer, user has to add
> >    couple PREFERRED_VERSIONS. Was this intended use for meta-gplv2?
>
> I guess the intention is that if you blacklist GPLv3 etc then only the
> recipes in meta-gplv2 will be considered.
>
> >    I can see some advantages of this (that the layer can be included
> >    without immediate side effects), but on the other hand why would
> >    anyone include this layer if he isn't deeply scared from (L)GPLv3
> >    versions sneaking into the build?
> >    In our local builds I'm bumping the priority to 6 to resolve this.
>
> If any of the recipes in meta-gplv2 still contain BBCLASSEXTEND =
> "native" then that could cause problems (generally you only want to
> use the older recipes for the target, not for -native).
>
> >    Alternatively we can add some conf/distro/gplv2-versions.inc file
> >    in meta-gplv2 so that people who want to use all available recipes
> >    in gplv2 compatible version can include it in their DISTRO.
> >
> > 2) branch for morty, currently the recipes aren't compatible with morty
> >    but with e.g. gnutls version added there it might be better option
> >    to share the gplv2 work there even when oe-core/morty contains most
> >    of these recipes as well.
> >    The recipes I had to modify to be compatible with morty are:
> >    https://github.com/shr-project/meta-gplv2/commits/jansa/morty
> >    88d1052 coreutils: make it compatible with Yocto 2.2 Morty
> >    5e08ac2 rsync: make it compatible with Yocto 2.2 Morty
> >    b33037f libiconv: make it compatible with Yocto 2.2 Morty
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>

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