Re: [PATCH 0/3] Remove unhelpful default value of EXTRA_OEMAKE

From: Martin Jansa <martin.jansa@gmail.com>
To: Mike Crowe <mac@mcrowe.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 0/3] Remove unhelpful default value of EXTRA_OEMAKE
Date: Fri, 5 Feb 2016 19:35:12 +0100	[thread overview]
Message-ID: <CA+chaQc6CsziwoCVqkQPC2CW=c_UzE3Z_PT59SqP0=TbfNvR7g@mail.gmail.com> (raw)
In-Reply-To: <20160205173256.GA7728@mcrowe.com>

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

Please send whatever you currently have, so I can test it in my world build
with more layers.

I've already included bitbake.conf change and e.g. pigz-native you listed
here is already failing so I doubt the build with test any reasonable
number of recipes if I let it run like this.

On Fri, Feb 5, 2016 at 6:32 PM, Mike Crowe <mac@mcrowe.com> wrote:

> On Tue, 2016-02-02 at 14:49 +0000, Mike Crowe wrote:
> > > > > [snip] Set EXTRA_OEMAKE = "" in bitbake.conf
>
> On Tuesday 02 February 2016 at 16:01:14 +0000, Richard Purdie wrote:
> > > > Which architectures did you test? Often, x86 is a bad choice here and
> > > > we'd need something cross (arm/mips/ppc) to ensure it really is doing
> > > > the right things. We also need to assess a bit more than just sato.
> > > > We can run this up on the autobuilder and see what happens.
>
> On Tue, 2016-02-02 at 21:04 +0000, Mike Crowe wrote:
> > > I've compile-tested qemux86 and qemuarm for core-image-sato. qemumips
> > > is building now.
>
> Since then I've collected enough patches to make "bitbake world" build
> successfully for qemux86, qemuarm, qemuppc and qemumips. qemux86-64 is
> building now. The recipes that needed fixing to explicitly set
> EXTRA_OEMAKE = "-e MAKEFLAGS=" were:
>
>   meta/recipes-bsp/apmd/apmd_3.2.2-15.bb
>   meta/recipes-bsp/libacpi/libacpi_0.2.bb
>   meta/recipes-bsp/pciutils/pciutils_3.4.1.bb
>   meta/recipes-connectivity/openssl/openssl.inc
>   meta/recipes-devtools/dmidecode/dmidecode_3.0.bb
>   meta/recipes-devtools/fdisk/gptfdisk_1.0.1.bb
>   meta/recipes-devtools/perl/perl-native_5.22.1.bb
>   meta/recipes-devtools/perl/perl_5.22.1.bb
>   meta/recipes-extended/ed/ed_1.9.bb
>   meta/recipes-extended/iputils/iputils_s20151218.bb
>   meta/recipes-extended/pigz/pigz.inc
>   meta/recipes-extended/stat/stat_3.3.bb
>   meta/recipes-extended/sysklogd/sysklogd.inc
>   meta/recipes-extended/unzip/unzip_6.0.bb
>   meta/recipes-gnome/gtk-theme-torturer/gtk-theme-torturer_git.bb
>   meta/recipes-support/ptest-runner/ptest-runner_2.0.bb
>
> I will submit patches for these shortly.
>
> > > We've been running with the previous version of the patch with our code
> > > for a while but now I look more closely that solution didn't have
> > > anywhere near as wide an impact so I'll switch us over to using these
> > > patches. That will runtime-test a few real mips and arm targets (and
> > > even x86 and x86-64 to a limited extent) but only with our customised
> > > set of packages.
>
> On Tuesday 02 February 2016 at 22:41:25 +0000, Richard Purdie wrote:
> > Thanks. Please do mention what tests have passed/failed just so I can
> > build some idea of the risk of the patch and decide if/as/when the
> > right time to merge it is.
>
> I've not yet done any more runtime tests. I hope to get the change into our
> tree tonight so everything gets rebuilt with it over the weekend and I can
> test next week.
>
> > > > A post to the architecture list is probably needed so everyone knows
> > > > this is happening (or at least being considered).
>
> I hope to send such a post later today.
>
> Mike.
>

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