Sorry for top posting... Have you verified that GL still works with this major version bump? Ross-- Ross Burton Sent with Sparrow

Signed-off-by: Andrei Gherzan <andrei@...> --- meta-fri2/conf/machine/fri2.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-fri2/conf/machine/fri2.conf

Signed-off-by: Andrei Gherzan <andrei@...> --- common/recipes-multimedia/ffmpeg/ffmpeg.inc | 110 --------------------- common/recipes-multimedia/ffmpeg/ffmpeg_0.7.12.bb | 44

This mail was sent out by Package Report System. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in

This mail was sent out by Package Report System. It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check. You can

Automake-1.13 fix to matchbox-wm git attached. - ML

Struggling to get shared state mirrors to work. I can see files with the same file name (and therefore the same hash) in my mirror and, after a build, in my local sstate cache direcotry.

From: Tom Zanussi <tom.zanussi@...> Normally pre-canned properties are supplied as JSON from a file, which the user can specify using e.g. the -i option. We can reuse that basic functionality

From: Tom Zanussi <tom.zanussi@...> If the user specifies a layer priority following the layer name, layer creation will proceed without further queries using the specified layer priority and

From: Tom Zanussi <tom.zanussi@...> This does a bit of refactoring of the bsp-generation code to make it generically reusable for generating non-bsp layers. The first user remains the existing

From: Tom Zanussi <tom.zanussi@...> Since I've been doing kind of similar work lately for the 'custom kernel' support for yocto-bsp and have gotten several requests lately (mainly from Darren

From: Tom Zanussi <tom.zanussi@...> Add a 'layer' target containing all the data that will be used to generate a generic yocto layer. Signed-off-by: Tom Zanussi <tom.zanussi@...> ---

From: Tom Zanussi <tom.zanussi@...> This is essentially 'the documentation' for the yocto-layer tool. Signed-off-by: Tom Zanussi <tom.zanussi@...> --- scripts/lib/bsp/help.py | 228

From: Tom Zanussi <tom.zanussi@...> Implementation of the 'yocto-layer' command-line tool, for creating generic layers and listing their input properties. Signed-off-by: Tom Zanussi

From: Tom Zanussi <tom.zanussi@...> Add a new yocto_layer_create() function that will be used to generate a generic yocto layer (for the new 'yocto-layer' command). Signed-off-by: Tom Zanussi

--needs more testing Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@...> --- plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF | 1 + .../src/org/yocto/bc/bitbake/ShellSession.java

Hi Thomas, http://gcc.gnu.org/onlinedocs/gcc/Cross_002dprofiling.html#Cross_002dprofiling. Yes this should work. Thanks! It's also documented in the kernel source tree

That is definitely a weakness in the installer. Would you please open a bug for this? An improved installer is something we are working on and this would be good input to track. Thanks, -- Darren

Dear Robert Berger, I supposed the idea is to generate to coverage data on the target, and then analyze them with gcov on the build machine.

Hi, I use Yocto Project, 1.3 "danny" for a beagle-xm and would like to show kernel code coverage with a core-image-sato-sdk. This image is pretty complete. Unfortunately there is no gcov available on