When building GL apps for non-x86 machines (e.g. raspberrypi) emgd-driver-bin is being dragged in as a valid provider. To avoid build breakage fix it at the source by limiting emgd-driver-bin to x86 a

When building GL apps for non-x86 machines (e.g. raspberrypi) emgd-driver-bin is being dragged in as a valid provider. To avoid build breakage fix it at the source by limiting emgd-driver-bin to x86 a

It is strongly discouraged to use wildcards in SRC_URI since it breaks when using multiple bbappends and immediate expansion of FILESDIR. This fixes a do_install failure when building with multiple BS

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 vishal gupta schreef op 13-12-13 15:05: LD=arm-angstrom-linux-gnueabi-ld | scripts/kconfig/conf -s arch/arm/Kconfig LD=arm-angstrom-linux-gnueabi-ld | CHK

Signed-off-by: Koen Kooi <koen@...> --- meta-fri2/README | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meta-fri2/README b/meta-fri2/README index af33c0b.

Op 15 aug. 2012, om 11:46 heeft Paul Eggleton <paul.eggleton@...> het volgende geschreven: Have a look at task-boot and task-basic in meta-oe: https://github.com/openembedded/meta-oe/tree/

Shouldn't this be sent to the oe-core list?!?!? Op 31 jul. 2012, om 22:35 heeft sidebranch.openembedded@... het volgende geschreven:

Op 28 jun. 2012, om 12:56 heeft Paul Eggleton het volgende geschreven: But do note that if you ship libstdc++ without anything linking to it you forego on the linking exception to the GPL. That is gen

Op 26 jun. 2012, om 11:09 heeft Robert P. J. Day het volgende geschreven: I'm afraid you have fallen into the yocto trap of confusing the umbrella project with the buildsystem project under that umbre

Op 13 apr. 2012, om 10:45 heeft Richard Purdie het volgende geschreven: Consider this scenario: OS disk on spinning rust (sda1, /) BUILDDIR on spinning rust (sdb1, /OE) WORKDIR on SSD (sdc1, /OE/build

Op 13 apr. 2012, om 11:56 heeft Tomas Frydrych het volgende geschreven: Try building webkit or asio, the linker will uses ~1.5GB per object, so for asio you need PARALLEL_MAKE * 1.5 GB of ram to avoid

Dave, Coud summarize the discussion about this during bspfest, collab and the AB meeting please? regards, Koen Op 30 mrt. 2012, om 21:00 heeft Osier-mixon, Jeffrey het volgende geschreven:

Op 30 mrt. 2012, om 18:21 heeft Darren Hart het volgende geschreven: Yes, it would force angstrom developers to ignore upstream and work on downstream projects or as I will label them from now on: for

Op 30 mrt. 2012, om 17:28 heeft Darren Hart het volgende geschreven: But it is the only component of the YP that gets released as part of the YP release, no? And that's why angstrom (currently!) only

Op 30 mrt. 2012, om 16:52 heeft Darren Hart het volgende geschreven: [snip] Yes, but see below What does a 'yocto project release' actually mean? Right now it looks more like a 'poky (the distro) rele

Op 30 mrt. 2012, om 16:49 heeft Tom Rini het volgende geschreven: Exactly! I said that *poky* is not an upstream, nothing about YP. Exactly. I said that *poky* is not an upstream. Like meta-ti won't b

My apologies for loosing the reply indent, I blame apple mail Op 30 mrt. 2012, om 14:01 heeft Osier-mixon, Jeffrey het volgende geschreven: linux-yocto is a kernel, which is used by machines in meta-i

Op 30 mrt. 2012, om 13:45 heeft Tom Rini het volgende geschreven: If oe-core doesn't count, that will go directly against the agreement the OE developers made with the yocto ones when deciding to drop

Op 30 mrt. 2012, om 13:18 heeft Mark Hatle het volgende geschreven: 1) It's downstream, I want to use upstream (oe-core, bitbake) 2) meta-yocto is *absolutely* unwanted, the meta-ti layer angstrom use

Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven: Why on top of poky? I do not want poky, nor do my customers, oe-core is what we need and want. This proposal to move angstrom under