openembedded-core.git/meta/recipes-bsp, branch master Mirror of openembedded-core gnu-efi: copy header files for x32 build 2017-04-11T07:50:53+00:00 Saul Wold sgw@linux.intel.com 2017-04-10T15:58:30+00:00 3398552663e1e18aaf352d682a77a8ad3af94e5a Gnu-efi needs to be build for 64bit since it is a boot time tool. It needs these 2 headers to be in 64 bit versions, we can use the existing 32bit ones as there is not really any difference. [YOCTO #11051] Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Gnu-efi needs to be build for 64bit since it is a boot time tool. It
needs these 2 headers to be in 64 bit versions, we can use the existing
32bit ones as there is not really any difference.

[YOCTO #11051]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot: Add bc-native to DEPENDS to fix u-boot/spl build. 2017-04-05T11:36:46+00:00 Philip Balister philip@balister.org 2017-04-03T12:51:38+00:00 02a76f320d3cddbfaae2fc5bee7d3660d95e6b7a Signed-off-by: Philip Balister <philip@balister.org> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Signed-off-by: Philip Balister <philip@balister.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
u-boot-fw-utils: reuse the same override HOSTCC patch as u-boot-mkimage 2017-03-17T16:52:44+00:00 Denys Dmytriyenko denys@ti.com 2017-03-14T19:37:34+00:00 2815f819c1a620949213fa952557c03f7d594ed6 Signed-off-by: Denys Dmytriyenko <denys@ti.com> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
u-boot: Update patch to match upstream 2017-03-13T13:13:57+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2017-03-13T07:29:23+00:00 048af2455aa65b25fd74bfe0e6d3a0af7562b42f After discussions with upstream this version of the patch was proposed and is being submitted to upstream u-boot. Update to that version (which is better than my workaround). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
After discussions with upstream this version of the patch was proposed
and is being submitted to upstream u-boot. Update to that version
(which is better than my workaround).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot: fix extlinux creation race 2017-03-13T09:43:05+00:00 Jack Mitchell jack@embed.me.uk 2017-03-11T14:16:02+00:00 60c90398580998b2379bb438f0f75b29285135a5 There was a race condition in the uboot-extlinux bbclass where only a half written extlinux.conf would be put in the deploy directory. Fix this by adding the deploy task after the do_install rather than after the do_compile. Signed-off-by: Jack Mitchell <jack@embed.me.uk> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
There was a race condition in the uboot-extlinux bbclass where
only a half written extlinux.conf would be put in the deploy
directory. Fix this by adding the deploy task after the do_install
rather than after the do_compile.

Signed-off-by: Jack Mitchell <jack@embed.me.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot-mkimage: Fix use of 'cc' instead of BUILD_CC 2017-03-11T16:08:48+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2017-03-11T10:37:38+00:00 e777d6873ce9a8a80288ecbcfc86239e0ed0e2f9 OE needs to be able to change the default compiler. If we pass in HOSTCC through the make command, it overwrites not only this setting but also the setting in tools/Makefile wrapped in ifneq ($(CROSS_BUILD_TOOLS),) which breaks the build. We therefore add a way of changing the default in the top level Makefile without interfering with the other setting. I've emailed this workaround to Masahiro Yamada for discussion. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
OE needs to be able to change the default compiler. If we pass in HOSTCC
through the make command, it overwrites not only this setting but also the
setting in tools/Makefile wrapped in ifneq ($(CROSS_BUILD_TOOLS),) which
breaks the build.

We therefore add a way of changing the default in the top level Makefile
without interfering with the other setting.

I've emailed this workaround to Masahiro Yamada for discussion.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta: start to ignore the largefile distro feature 2017-03-07T21:46:52+00:00 Andre McCurdy armccurdy@gmail.com 2017-03-07T04:58:47+00:00 a75ccaea77c8aad8d46e87e8ed4af2e2e0ad5327 The largefile distro feature has been enabled by default in oe-core for a long time and, more recently, also in poky-tiny. Building without the largefile distro feature receives little or no testing. Many packages now enable LFS without exposing a configure option, so there should be very little expectation that disabling the distro feature will result in a distro which globally disables LFS. Respecting the distro feature adds a maintenance over-head and may be the source of configurations oddities (e.g. dbus-native currently builds with LFS disabled for no clear reason - fixed by this commit). Ignore the largefile distro feature more widely, as a first step towards deprecating and eventually removing it. Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
The largefile distro feature has been enabled by default in oe-core
for a long time and, more recently, also in poky-tiny. Building
without the largefile distro feature receives little or no testing.
Many packages now enable LFS without exposing a configure option, so
there should be very little expectation that disabling the distro
feature will result in a distro which globally disables LFS.

Respecting the distro feature adds a maintenance over-head and may be
the source of configurations oddities (e.g. dbus-native currently
builds with LFS disabled for no clear reason - fixed by this commit).

Ignore the largefile distro feature more widely, as a first step
towards deprecating and eventually removing it.

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
recipes: Move out stale GPLv2 versions to a seperate layer 2017-03-07T20:04:58+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2017-03-02T12:04:08+00:00 19b7e950346fb1dde6505c45236eba6cd9b33b4b These are recipes where the upstream has moved to GPLv3 and these old versions are the last ones under the GPLv2 license. There are several reasons for making this move. There is a different quality of service with these recipes in that they don't get security fixes and upstream no longer care about them, in fact they're actively hostile against people using old versions. The recipes tend to need a different kind of maintenance to work with changes in the wider ecosystem and there needs to be isolation between changes made in the v3 versions and those in the v2 versions. There are probably better ways to handle a "non-GPLv3" system but right now having these in OE-Core makes them look like a first class citizen when I believe they have potential for a variety of undesireable issues. Moving them into a separate layer makes their different needs clearer, it also makes it clear how many of these there are. Some are probably not needed (e.g. mc), I also wonder whether some are useful (e.g. gmp) since most things that use them are GPLv3 only already. Someone could now more clearly see how to streamline the list of recipes here. I'm proposing we mmove to this separate layer for 2.3 with its future maintinership and testing to be determined in 2.4 and beyond. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
These are recipes where the upstream has moved to GPLv3 and these old
versions are the last ones under the GPLv2 license.

There are several reasons for making this move. There is a different
quality of service with these recipes in that they don't get security
fixes and upstream no longer care about them, in fact they're actively
hostile against people using old versions. The recipes tend to need a
different kind of maintenance to work with changes in the wider ecosystem
and there needs to be isolation between changes made in the v3 versions
and those in the v2 versions.

There are probably better ways to handle a "non-GPLv3" system but right
now having these in OE-Core makes them look like a first class citizen
when I believe they have potential for a variety of undesireable issues.

Moving them into a separate layer makes their different needs clearer, it
also makes it clear how many of these there are. Some are probably not
needed (e.g. mc), I also wonder whether some are useful (e.g. gmp)
since most things that use them are GPLv3 only already. Someone could
now more clearly see how to streamline the list of recipes here.

I'm proposing we mmove to this separate layer for 2.3 with its future
maintinership and testing to be determined in 2.4 and beyond.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot: Fix handling of CMD_LICENSE in u-boot-mkimage 2017-03-04T23:18:10+00:00 Marek Vasut marex@denx.de 2017-02-28T19:41:10+00:00 f7d4375146af22c72e2bdc9426329cd37f610a47 Only ever change the CMD_LICENSE in the u-boot config if it is enabled to prevent corruption of the config file. In case the CMD_LICENSE was already disabled, the sed substitution inserted another "# " in front of the CMD_LICENSE which triggered a restart of Kconfig oldconfig and failed the build. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Ross Burton <ross.burton@intel.com> 
Only ever change the CMD_LICENSE in the u-boot config if it is enabled
to prevent corruption of the config file. In case the CMD_LICENSE was
already disabled, the sed substitution inserted another "# " in front
of the CMD_LICENSE which triggered a restart of Kconfig oldconfig and
failed the build.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
recipes: Make use of the new bb.utils.filter() function 2017-03-01T11:17:22+00:00 Peter Kjellerstedt peter.kjellerstedt@axis.com 2017-02-27T13:02:50+00:00 0a1427bf9aeeda6bee2cc0af8da4ea5fd90aef6f Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>