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 <armccu...@gmail.com> wrote: > On Fri, Apr 21, 2017 at 1:59 PM, Martin Jansa <martin.ja...@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.ja...@gmail.com > > > > -- > > _______________________________________________ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto