linux/poky.git/meta/conf/machine, branch 1.2_M2

Remove last remnants of kernel26 MACHINE_FEATURES

2012-01-10T17:28:43+00:00

There is no reason to continue to carry this feature (From OE-Core rev: f1193e077d187b9ce18ae0686b1a1f0f9832036d) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

Change -mno-thumb to -marm

2011-12-24T10:05:44+00:00

Recent versions of the GCC reject the -mno-thumb option. In order to prevent the compiler from generating code for the Thumb instruction set the -marm switch should be used instead. For details see GNU bug #47930. (From OE-Core rev: 72dc73f5a647ccd38145fd888c109a144f202963) Signed-off-by: Ken Werner Signed-off-by: Richard Purdie

arch-powerpc: set PACKAGE_EXTRA_ARCHS

2011-12-22T13:13:46+00:00

Set PACKAGE_EXTRA_ARCHS for the generic tunes ("powerpc" and "powerpc-nf") thus allowing to use them instead of tuning to the specific CPU. (From OE-Core rev: 5eafbe2d8684ee1c45477bfd69b579af47adccd9) Signed-off-by: Ilya Yanok Signed-off-by: Richard Purdie

conf/machine/include/arm add extra MACHINEOVERRIDES like x86 does

2011-12-13T12:28:11+00:00

* motivated by this NAK http://patchwork.openembedded.org/patch/15777/ and today's discussion on #yocto I hope it's worth it to send this RFC (From OE-Core rev: e3e1fef27345e2ea923b76b1e6bcb9cd5572cec6) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

x86 tune: fix TUNE_PKGARCH definition for proper PACKAGE_ARCH

2011-12-12T21:50:19+00:00

rpmbuild can not handle the PACKAGE_ARCH of these kinds: x86_64-x32, core2-64, core2-64-x32 With these kinds of PACKAGE_ARCH the --target parameter of rpmbuild becomes like: core2-64-x32-poky-linux-gnux32 ; And rpmbuild extracts %_target (arch) wrongly as core2 generating these kinds of rpms with incorrect filenames: zip-3.0-r0.core2.rpm So this commit fixes the issue by making PACKAGE_ARCH like this: x86_64_x32, core2_64, core2_64_x32 Now --target parameter of rpmbuild becomes like: core2_64_x32-poky-linux-gnux32 ; And rpmbuild extracts %_target (arch) correctly as core2_64_x32 generating these kinds of rpms with correct filenames: zip-3.0-r0.core2_64_x32.rpm (From OE-Core rev: 1a599cc822ad517f9ba70ceb0e39c5572d37a5a6) Signed-off-by: Nitin A Kamble Signed-off-by: Richard Purdie

conf/machine: Don't poke around providers which aren't machine specific/safe

2011-12-06T22:47:03+00:00

Machines shouldn't be poking around PREFERRED_PROVIDERS which aren't machine specific or at least machine safe. Kernels are machine specific and the xserver is selectable. libx11 and mesa are now really a distro choice and machine configurations shouldn't be poking around them as it just leads to corruption, conflicts and confusion. (From OE-Core rev: 97a57aca12437c24b628071bb189c9f3b94e27ca) Signed-off-by: Richard Purdie

Convert to use direct access to the data store (instead of bb.data.Var())

2011-11-10T11:51:19+00:00

This is the result of running the following over the metadata: sed \ -e 's:bb.data.\(setVar([^,()]*,[^,()]*\), *\([^ )]*\) *):\2.\1):g' \ -e 's:bb.data.\(setVarFlag([^,()]*,[^,()]*,[^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -e 's:bb.data.\(getVar([^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \ -e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \ -e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^() ]*\) *):\2.\1):g' \ -e 's:bb.data.\(getVar([^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -i `grep -ril bb.data *` (From OE-Core rev: b22831fd63164c4db9c0b72934d7d734a6585251) Signed-off-by: Richard Purdie

x86 tune files: set baselib for x32 tune as libx32

2011-10-20T16:13:37+00:00

This ensures that on a multilib system the two executable formats don't conflict. (From OE-Core rev: 7b3cf9556085429faf8155a6eea412a0b8cc2c52) Signed-off-by: Nitin A Kamble Signed-off-by: Richard Purdie

arch-ia32: Add a generic x86 override (instead of i{3|4|5|6}86 and so on)

2011-10-14T23:41:23+00:00

(From OE-Core rev: bd7663f5fa07394e5157f74e9958ebd88b7355b6) Signed-off-by: Richard Purdie

xserver-xf86(-dri)-lite: rename to xserver-xorg and xserver-xorg-lite

2011-10-11T17:08:31+00:00

* xserver-xorg is closer to upstream naming and that's how it's named in OE-classic and meta-oe? It would make meta-oe transition easier and better to do it now then convert meta-oe to xserver-xf86 and then rename it back later. (From OE-Core rev: 0b31c7200a368533df970f0efeb81e2e20c73593) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie