When SERIAL_CONSOLES is set by bitbake.conf the assignment is with "??=", so this change will break things unexpectedly for anyone who may rely on over-riding SERIAL_CONSOLES from a local.conf file, e

Just my opinion, but I'd vote against this change. Running "../temp/run.do_compile" works from either directory but editing sources and running "quilt refresh" etc only works from ${S}.

I'm still seeing this issue with Qt 5.4.1 and it seems to be related to using gold as the linker (ie adding ld-is-gold to DISTRO_FEATURES). With Qt 5.4.x, including ld-is-gold in DISTRO_FEATURES cause

<florian.boor@...> wrote: Are you sure that excluding tslib-native from DEPENDS works? Since -lts is hardcoded in LDFLAGS (see directfb.inc) the linker won't run unless libts.so is found

Binaries linked with gold may contain a RUNPATH instead of an RPATH. Update chrpath.bbclass process_file_linux() to handle both cases. Signed-off-by: Andre McCurdy <armccurdy@...> --- meta/class

Hi Florian, <florian.boor@...> wrote: That's a bit mysterious. It does fail for me. I wonder if your build is somehow finding a libts.so from the host system? Good, I think removing the

Enabling support for the smb protocol does not create a build time dependency on samba. Signed-off-by: Andre McCurdy <armccurdy@...> --- meta/recipes-support/curl/curl_7.40.0.bb | 2 +- 1 file ch

Remove obsolete comment describing SRCREV and re-order SECTION, DEPENDS and PV lines. No functional changes. Signed-off-by: Andre McCurdy <armccurdy@...> --- meta/recipes-devtools/mtd/mtd-utils_

Make the v4l PACKAGECONFIG option control building of the video4linux2 plug-in (not use of libv4l, as it did before) and enable by default. Add a separate libv4l PACKAGECONFIG to control use of libv4l

Backport from busybox 1_22_stable branch: http://git.busybox.net/busybox/commit/?h=1_22_stable&id=5698ff93233b47218a677fd7facd8cc90211d1a4 Signed-off-by: Andre McCurdy <armccurdy@...> --- .../bu

Backport from busybox 1_22_stable branch: http://git.busybox.net/busybox/commit/?h=1_22_stable&id=28dd64a0e1a9cffcde7799f2849b66c0e16bb9cc Signed-off-by: Andre McCurdy <armccurdy@...> --- ...ope

<otavio@...> wrote: The reasons I had for explicit enabling were: - The video4linux2 plug-in is typically being built now and judging by the patches to gst-plugins-good it's not unusual f

Splitting the DirectFB recipe into .bb and .inc hinders maintenance and the addition of new features such as class-native support. Remove directfb.inc and merge everything into directfb_1.7.6.bb. No f

OK, that's a good reason to keep it. Actually from that point of view DirectFB is a good candidate for having almost everything in the .inc and using the .bb to define version and hashes only (there's

Remove duplicate EXTRA_OECONF definition from directfb_1.7.6.bb. Signed-off-by: Andre McCurdy <armccurdy@...> --- meta/recipes-graphics/directfb/directfb.inc | 11 ++++++----- meta/recipes-graphi

Thanks for testing and reporting this. Rather than take the risk that this might not be the final fix, perhaps the safest approach is just to revert the offending patch from dizzy?

Signed-off-by: Andre McCurdy <armccurdy@...> --- meta/recipes-support/libevent/libevent_2.0.21.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/recipes-support/libeven

Signed-off-by: Andre McCurdy <armccurdy@...> --- .../libevent/libevent-2.0.21/disable_tests.patch | 15 --------------- .../libevent-2.0.21/obsolete_automake_macros.patch | 15 --------------- ...

There's no libnl1 recipe in oe-core (or any other layer in the layer index). Keeping the libnl1 PACKAGECONFIG is likely to cause problems for the libnl PACKAGECONFIG since libnl and libnl1 both use --

Signed-off-by: Andre McCurdy <armccurdy@...> --- meta/recipes-connectivity/libpcap/libpcap.inc | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/meta/recipes-conne