[OE-core] [PATCH 2/4] webkitgtk: set COMPATIBLE_HOST_armv4 to null

It doesn't build with armv4: {standard input}: Assembler messages: {standard input}:52: Error: selected processor does not support `blx llint_throw_stack_overflow_error' in ARM mode {standard input}:126: Error: selected processor does not support `bkpt #0' in ARM mode {standard input}:128:

[OE-core] [PATCH 4/4] cogl-1.0: set COMPATIBLE_HOST_armv4 to null

It doesn't build with armv4: cogl-texture-deprecated.c -fPIC -DPIC -o deprecated/.libs/cogl-texture-deprecated.o {standard input}: Assembler messages: {standard input}:831: Error: selected processor does not support `clz r3,r0' in ARM mode make[4]: *** [deprecated/cogl-fixed.lo] Error 1 [snip]

[OE-core] [PATCH 3/4] gnu-efi: set COMPATIBLE_HOST_armv4 to null

It doesn't build with armv4: lib1funcs.S: Assembler messages: Assembler messages: gnu-efi-3.0.3/lib/arm/lib1funcs.S:140: Error: selected processor does not support `clz r3,r1' in ARM mode gnu-efi-3.0.3/lib/arm/div64.S:95: Error: selected processor does not support `clz r2,r4' in ARM mode

[OE-core] [PATCH 1/4] grub_git: set COMPATIBLE_HOST_armv7a to null

It doesn't work with armv7a: | build-grub-module-verifier: error: unsupported relocation 0x2b. | make[3]: *** [reboot.mod] Error 1 | make[3]: *** Waiting for unfinished jobs | build-grub-module-verifier: error: unsupported relocation 0x2b. | build-grub-module-verifier: error: unsupported

[OE-core] [PATCH 0/4] set COMPATIBLE_HOST for several recipes

The following changes since commit 9838f8d077d16e52ad592879d65a9e8350b93075: build-appliance-image: Update to krogoth head revision (2016-04-19 21:25:53 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/arm

Re: [OE-core] [PATCH 2/2] grub_git: set COMPATIBLE_HOST_armv7a to null

On 04/22/2016 09:44 AM, Robert Yang wrote: On 04/21/2016 09:01 AM, Robert Yang wrote: On 04/21/2016 04:37 AM, Burton, Ross wrote: Andre's comment from the last time you submitted this is still valid: Unless you have verified that armv4, armv5, armv6 and armv7ve all work

[OE-core] [PATCH 2/2] utils.bbclass: warn for deprecated base_contains

Signed-off-by: Robert Yang --- meta/classes/utils.bbclass | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass index 81b92cb..cf4bd25 100644 --- a/meta/classes/utils.bbclass +++ b/meta/classes/utils.bbclass @@

[OE-core] [PATCH 1/2] directfb/pango/webkit: base_contains -> bb.utils.contains

Signed-off-by: Robert Yang --- meta/recipes-graphics/directfb/directfb.inc | 2 +- meta/recipes-graphics/pango/pango_1.38.1.bb | 2 +- meta/recipes-sato/webkit/webkitgtk_2.10.7.bb | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git

[OE-core] [PATCH 0/2] ase_contains -> bb.utils.contains (master branch only)

The following changes since commit 9838f8d077d16e52ad592879d65a9e8350b93075: build-appliance-image: Update to krogoth head revision (2016-04-19 21:25:53 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/warn

Re: [OE-core] [PATCH 2/2] grub_git: set COMPATIBLE_HOST_armv7a to null

On 04/21/2016 09:01 AM, Robert Yang wrote: On 04/21/2016 04:37 AM, Burton, Ross wrote: Andre's comment from the last time you submitted this is still valid: Unless you have verified that armv4, armv5, armv6 and armv7ve all work correctly then blacklisting only armv7a is probably

Re: [OE-core] About PV = "0.0+git${SRCPV}"

ch as opkg/rpm/smart may not upgrade them correctly when the recipes is upgraded since we can't make sure that SRCPV_new > SRCPV_old. How about we use date for these recipes which doesn't have a release version? For example, if we integrate them to oe-core today, then PV = "2016042

Re: [OE-core] mesa, libgbm and weston

On Thu, Apr 21, 2016 at 5:06 PM Denys Dmytriyenko wrote: > All, > > I've been meaning to ask this for quite some time. It appears that Weston's > DRM compositor enabled with "kms" PACKAGECONFIG doesn't really need the > entire > mesa, but it only needs libgbm. Now, mesa in

[OE-core] mesa, libgbm and weston

All, I've been meaning to ask this for quite some time. It appears that Weston's DRM compositor enabled with "kms" PACKAGECONFIG doesn't really need the entire mesa, but it only needs libgbm. Now, mesa in OE-Core provides libgbm as one of its packages, hence virtual/mesa is added in DEPENDS

Re: [OE-core] xinput-calibrator startup question

Hi Stefan Am Donnerstag, den 21.04.2016, 13:11 -0700 schrieb Stefan Agner: > On 2016-04-19 14:01, Jussi Kukkonen wrote: > > On 19 April 2016 at 21:24, Koen Kooi > > wrote: > > > > > > > Op 19 apr. 2016, om 17:12 heeft Jussi Kukkonen < > > > >

[OE-core] [PATCH][jethro] opkg: backport fix for double remove of packges

From: Stefan Agner Backport the fix 7885da3974 ("pkg_get_provider_replacees: do not add installed pkg to replacee list"). This avoids opkg trying to remove a package twice e.g. when upgrading. Suggested-by: Alejandro del Castillo

Re: [OE-core] xinput-calibrator startup question

On 2016-04-19 14:01, Jussi Kukkonen wrote: > On 19 April 2016 at 21:24, Koen Kooi wrote: >> >>> Op 19 apr. 2016, om 17:12 heeft Jussi Kukkonen >>> het volgende geschreven: >>> >>> Hi Koen, >>> >>> I was looking at xinput-calibrator in

Re: [OE-core] [RFC][PATCH v2 1/4] u-boot: basic support of dtb append for verified boot

Le 21/04/2016 16:06, Andreas Oberritter a écrit : On 20.04.2016 15:50, Yannick Gicquel wrote: This introduces a new uboot-sign.class to support U-Boot verified boot. This part delivers the new class file, with related environment variables, and a basic prepend to do_install task which

[OE-core] [PATCH] sdk.py: preserve packaging data when SDKIMAGE_FEATURES has "package-management"

From: Denys Dmytriyenko This is not enabled by default, as there are still limitations and possible issues with opkg (and rpm?) packaging data containing broken symlinks for local indexes:

Re: [OE-core] [PATCH v3 1/2] wic: isoimage-isohybrid: add grubefi configfile support

Hi Ioan-Adrian, Great! Thank you! Signed-off-by: Ed Bartosh On Thu, Apr 21, 2016 at 01:10:12PM +0300, Ioan-Adrian Ratiu wrote: > The latest wic kickstart refactoring introduced a bootloader option > "--configfile" which lets wks' specify a custom grub.cfg for use >

[OE-core] [PATCH] recipetool.newappend: fix syntax error for 'not path_ok' error

From: Christopher Larson Signed-off-by: Christopher Larson --- scripts/lib/recipetool/newappend.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/lib/recipetool/newappend.py b/scripts/lib/recipetool/newappend.py

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On 4/21/16 9:25 AM, Robert P. J. Day wrote: > On Thu, 21 Apr 2016, Richard Purdie wrote: > >> On Thu, 2016-04-21 at 08:50 -0400, Robert P. J. Day wrote: >>> On Thu, 21 Apr 2016, Burton, Ross wrote: >>> On 21 April 2016 at 13:06, Robert P. J. Day wrote:

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On 4/21/16 7:06 AM, Robert P. J. Day wrote: > > looking for advice on how to most cleanly deal with the following. > currently working on BSP layer to which some folks want to add RPMs > that are currently (and for quite some time have been) built on a > centos 6 system, which means those RPM

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On Thu, 21 Apr 2016, Richard Purdie wrote: > On Thu, 2016-04-21 at 08:50 -0400, Robert P. J. Day wrote: > > On Thu, 21 Apr 2016, Burton, Ross wrote: > > > > > > > > On 21 April 2016 at 13:06, Robert P. J. Day > > > wrote: > > > next bit of muttering is, "can we

Re: [OE-core] [RFC][PATCH v2 1/4] u-boot: basic support of dtb append for verified boot

On 20.04.2016 15:50, Yannick Gicquel wrote: > This introduces a new uboot-sign.class to support U-Boot verified boot. > > This part delivers the new class file, with related environment variables, and > a basic prepend to do_install task which performs the concatenation of the > u-boot-nodtb.bin

Re: [OE-core] question about order of processing SRC_URI items

On Thu, 21 Apr 2016, Richard Purdie wrote: > In general we should try and use += if possible as its simpler and > easier to understand what it does. regarding "_append +=", there are only two files left in oe-core that i will let someone else deal with if they want. first:

[OE-core] [PATCH] attr: Remove redundant "+=" after "_append"

Signed-off-by: Robert P. J. Day --- diff --git a/meta/recipes-support/attr/attr_2.4.47.bb b/meta/recipes-support/attr/attr_2.4.47.bb index 44eee39..556c8e4 100644 --- a/meta/recipes-support/attr/attr_2.4.47.bb +++ b/meta/recipes-support/attr/attr_2.4.47.bb @@ -2,9 +2,9

Re: [OE-core] question about order of processing SRC_URI items

... some stuff snipped ... On Thu, 21 Apr 2016, Richard Purdie wrote: > On Thu, 2016-04-21 at 07:19 -0400, Robert P. J. Day wrote: > > more significantly, i realize the final order of SRC_URI items > > depending on which one you use might be different, as "_append" > > leaves the appending

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On Thu, 2016-04-21 at 08:50 -0400, Robert P. J. Day wrote: > On Thu, 21 Apr 2016, Burton, Ross wrote: > > > > > On 21 April 2016 at 13:06, Robert P. J. Day > > wrote: > > next bit of muttering is, "can we downgrade the OE build to > > use > > rpm4-format

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On Thu, 21 Apr 2016, Joshua G Lock wrote: ... snip ... > On the topic of RPM4 vs. RPM5 you should be able to find more > details in the list archives, I easily found a brief summary by Mark > Hatle in the Yocto Project mailing list archive: > > "There are some specific uses of RPM 4 in the YP,

Re: [OE-core] question about order of processing SRC_URI items

On Thu, 2016-04-21 at 07:19 -0400, Robert P. J. Day wrote: > i'm currently building up a BSP layer which is going to involve > quite a bit of FILESEXTRAPATHS and OVERRIDES and conditionals in my > kernel bbappend files so i want to make sure i understand the > processing order (or what there is

[OE-core] [PATCH] gobject-introspection: fix floating dep on python-mako

From: Christopher Larson This was resulting in non-deterministic builds where g-ir-doc-tool may or may not exist depending on whether python-mako was built previously. Add a PACKAGECONFIG so the dependency is explicit. Signed-off-by: Sujith H

[OE-core] [PATCH 3/3] matchbox-panel-2: Depend on dbus-glib-native

This is required for dbus-binding-tool. Signed-off-by: Jussi Kukkonen --- meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On Thu, 21 Apr 2016, Burton, Ross wrote: > > On 21 April 2016 at 13:06, Robert P. J. Day wrote: >   next bit of muttering is, "can we downgrade the OE build to use > rpm4-format packages?", which is not a path down which i want to walk. > > > Assuming that the

[OE-core] [PATCH 1/3] gobject-introspection: Depend on native flex and bison

Signed-off-by: Jussi Kukkonen --- .../recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb

[OE-core] [PATCH 0/3] Add missing build dependencies

I found some build issues by running a build/cleansstate/wipe-sysroot/re-build cycle on individual recipes. cheers Jussi The following changes since commit 6c1c01392d91f512e2949ad1d57a75a8077478ba: build-appliance-image: Update to krogoth head revision (2016-04-19 21:26:33 +0100) are

[OE-core] [PATCH 2/3] connman-gnome: Depend on dbus-glib-native

This is required for dbus-binding-tool. Signed-off-by: Jussi Kukkonen --- meta/recipes-connectivity/connman/connman-gnome_0.7.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/connman/connman-gnome_0.7.bb

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On Thu, 2016-04-21 at 08:24 -0400, Robert P. J. Day wrote: > On Thu, 21 Apr 2016, Burton, Ross wrote: > > > > On 21 April 2016 at 13:06, Robert P. J. Day > > wrote: > >     next bit of muttering is, "can we downgrade the OE build to > > use > >   rpm4-format

[OE-core] [PATCH] gobject-introspection: fix floating dep on python-mako

From: Christopher Larson This was resulting in non-deterministic builds where g-ir-doc-tool may or may not exist depending on whether python-mako was built previously. Add a PACKAGECONFIG so the dependency is explicit. Signed-off-by: Sujith H

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On Thu, 21 Apr 2016, Burton, Ross wrote: > > On 21 April 2016 at 13:06, Robert P. J. Day wrote: >   next bit of muttering is, "can we downgrade the OE build to use > rpm4-format packages?", which is not a path down which i want to walk. > > > Assuming that the

Re: [OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

On 21 April 2016 at 13:06, Robert P. J. Day wrote: > next bit of muttering is, "can we downgrade the OE build to use > rpm4-format packages?", which is not a path down which i want to walk. > Assuming that the obviously correct option of "build the packages inside OE"

[OE-core] trying to reconcile OE builds with rpm4-format rpm files built on centos 6

looking for advice on how to most cleanly deal with the following. currently working on BSP layer to which some folks want to add RPMs that are currently (and for quite some time have been) built on a centos 6 system, which means those RPM files are in rpm4 format; ergo, they obviously don't

[OE-core] question about order of processing SRC_URI items

i'm currently building up a BSP layer which is going to involve quite a bit of FILESEXTRAPATHS and OVERRIDES and conditionals in my kernel bbappend files so i want to make sure i understand the processing order (or what there is of it). first, if one simply appends items to SRC_URI, as in:

[OE-core] [PATCH] license.bbclass: make sure that image manifest dir exists

Previously, write_deploy_manifest() was relying on write_package_manifest() to create the subdirectory for the manifest file. However, do_rootfs may be an empty function so that write_package_manifest() will not be called and the manifest subdirectory will not be created, causing a build failure.

[OE-core] [PATCH] Create class to test for unsatisfied RRECOMMENDS

The do_rootfs log contains a number of unsatisfied package recommendations. At the moment those are only visible when reviewing the rootfs log. This class adds an extra check to surface any unsatisfied recommendation as WARNINGS to the build output. Signed-off-by: Jose Alarcon

Re: [OE-core] [RFC][PATCH v2 1/4] u-boot: basic support of dtb append for verified boot

Le 20/04/2016 23:03, Tom Rini a écrit : On Wed, Apr 20, 2016 at 03:49:58PM -0400, Denys Dmytriyenko wrote: On Wed, Apr 20, 2016 at 03:50:36PM +0200, Yannick Gicquel wrote: This introduces a new uboot-sign.class to support U-Boot verified boot. This part delivers the new class file, with

[OE-core] [PATCH v3 2/2] wic: isoimage-isohybrid: fix splash file paths

os.path.join discards the cr_workdir var contents if the path of the second arguments is absolute. Signed-off-by: Ioan-Adrian Ratiu --- scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[OE-core] [PATCH v3 1/2] wic: isoimage-isohybrid: add grubefi configfile support

The latest wic kickstart refactoring introduced a bootloader option "--configfile" which lets wks' specify a custom grub.cfg for use while booting. This is very useful for creating stuff like boot menus. This change lets isoimage-isohybrid use --configfile; if this option is not specified in a

[OE-core] [PATCH] image.bbclass: don't execute compression commands multiple times

In case of chained conversion methods are used via COMPRESS_CMD_* there is chance that some of steps would be executed multiple times. [YOCTO #9482] Signed-off-by: Alexander D. Kanevskiy --- meta/classes/image.bbclass | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-)

Re: [OE-core] [PATCH] wic: isoimage-isohybrid: add grubefi configfile support

On Thu, 21 Apr 2016 10:03:31 +0300 Ed Bartosh wrote: > On Wed, Apr 20, 2016 at 06:08:38PM +0300, Ioan-Adrian Ratiu wrote: > > I forgot to mention this is v2... sorry. > > > > On Wed, 20 Apr 2016 18:06:15 +0300 > > Ioan-Adrian Ratiu wrote: > >

[OE-core] [PATCH] busybox: update flock behavior to match upstream

In "util-linux" implementation of flock, -c 'PROG ARGS' means run "sh -c 'PROG ARGS'". At present, busybox implementation doesn't follow it. That causes errors like the one listed below: smart install /media/cronie-1.5.0-r0.core2_64.rpm Updating cache... Output from cronie-1.5.0-r0@core2_64:

Re: [OE-core] [PATCH] wic: isoimage-isohybrid: add grubefi configfile support

On Wed, Apr 20, 2016 at 06:08:38PM +0300, Ioan-Adrian Ratiu wrote: > I forgot to mention this is v2... sorry. > > On Wed, 20 Apr 2016 18:06:15 +0300 > Ioan-Adrian Ratiu wrote: > > > The latest wic kickstart refactoring introduced a bootloader option > > "--configfile" which

[OE-core] [PATCH 1/1] valgrind: turn off the file level dependency

Attempting to install ptest for valgrind fails with this error: error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package provides /this/is/a/bogus/interpreter/name This is because one of the tests contains a bogus interpreter path on purpose It is not enough to skip the QA warning

Re: [OE-core] rpm generation question

On 20/04/2016 04:08, Mark Hatle wrote: > On 4/19/16 7:15 PM, Tudor Florea wrote: >> >> >> On 19/04/2016 21:02, Mark Hatle wrote: >>> On 4/19/16 12:05 PM, Tudor Florea wrote: As part of our test infrastructure we're attempting to install ptest packages (and execute the tests

Re: [OE-core] [RFC PATCH 1/4] u-boot: basic support of device tree blob reassembly

On 20.04.2016 10:27, Yannick GICQUEL wrote: > Le 19/04/2016 16:30, Andreas Oberritter a écrit : >> On 19.04.2016 14:46, Yannick Gicquel wrote: [...] >>> +addtask assemble_dtb after do_deploy before do_install >> The task do_deploy executes after do_install. Does it really work this >> way? I think

Re: [OE-core] About PV = "0.0+git${SRCPV}"

may not upgrade them > correctly when the recipes is upgraded since we can't make sure that > SRCPV_new > SRCPV_old. > > How about we use date for these recipes which doesn't have a release > version? For example, if we integrate them to oe-core today, then > PV = "20

[OE-core] About PV = "0.0+git${SRCPV}"

sure that SRCPV_new > SRCPV_old. How about we use date for these recipes which doesn't have a release version? For example, if we integrate them to oe-core today, then PV = "20160421". And when we upgrade them in the future, we can change the PV to that day. We can change all the c