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

[Robert Yang]

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: Error: selected processor does not support `blx r0' in 
ARM mode
{standard input}:134: Error: selected processor does not support `bkpt #0' in 
ARM mode
{standard input}:185: Error: selected processor does not support `blx 
llint_throw_stack_overflow_error' in ARM mode
{standard input}:256: Error: selected processor does not support `blx r4' in 
ARM mode
{standard input}:310: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:311: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_enter-.LrelativePCBase' in ARM mode
{standard input}:315: Error: selected processor does not support `movw 
r2,#:lower16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
{standard input}:316: Error: selected processor does not support `movt 
r2,#:upper16:.Lllint_op_get_scope-.LrelativePCBase' in ARM mode
[snip]

Signed-off-by: Robert Yang 
---
 meta/recipes-sato/webkit/webkitgtk_2.10.7.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.10.7.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.10.7.bb
index 8eb6b9f..ff26c8c 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.10.7.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.10.7.bb
@@ -86,3 +86,4 @@ ARM_INSTRUCTION_SET = "arm"
 # Segmentation fault
 EXTRA_OECMAKE_append_powerpc = " -DENABLE_INTROSPECTION=OFF "
 
+COMPATIBLE_HOST_armv4 = 'null'
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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]

Signed-off-by: Robert Yang 
---
 meta/recipes-graphics/cogl/cogl-1.0.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc 
b/meta/recipes-graphics/cogl/cogl-1.0.inc
index 690ea3b..7a79aa7 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -73,3 +73,5 @@ FILES_libcogl-path = "${libdir}/libcogl-path${SOLIBS}"
 RPROVIDES_libcogl = "cogl-1.0"
 RCONFLICTS_libcogl = "cogl-1.0"
 RREPLACES_libcogl = "cogl-1.0"
+
+COMPATIBLE_HOST_armv4 = 'null'
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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
gnu-efi-3.0.3/lib/arm/lib1funcs.S:140: Error: selected processor does not 
support `clz r2,r0' in ARM mode
[snip]

Signed-off-by: Robert Yang 
---
 meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb 
b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb
index eca3459..6b130a2 100644
--- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb
+++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb
@@ -25,6 +25,7 @@ SRC_URI[md5sum] = "15a4bcbc18a9a5e8110ed955970622e6"
 SRC_URI[sha256sum] = 
"c530f21a15fd9c214dd92d29a6caa20fac989289267512020b6da1f5e6f5b4cb"
 
 COMPATIBLE_HOST = "(x86_64.*|i.86.*|aarch64.*|arm.*)-linux"
+COMPATIBLE_HOST_armv4 = 'null'
 
 def gnu_efi_arch(d):
 import re
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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 relocation 0x2b.
| make[3]: *** [halt.mod] Error 1
| make[3]: *** [cat.mod] Error 1
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| make[3]: *** [disk.mod] Error 1
| make[3]: *** [gptsync.mod] Error 1
| make[3]: *** [eval.mod] Error 1
| build-grub-module-verifier: error:build-grub-module-verifier: error:  
unsupported relocation 0x2bunsupported relocation 0x2b.

Signed-off-by: Robert Yang 
---
 meta/recipes-bsp/grub/grub_git.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-bsp/grub/grub_git.bb 
b/meta/recipes-bsp/grub/grub_git.bb
index 6919c9a..8f8c5ed 100644
--- a/meta/recipes-bsp/grub/grub_git.bb
+++ b/meta/recipes-bsp/grub/grub_git.bb
@@ -18,6 +18,7 @@ SRC_URI = "git://git.savannah.gnu.org/grub.git \
 S = "${WORKDIR}/git"
 
 COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
+COMPATIBLE_HOST_armv7a = 'null'
 
 inherit autotools gettext texinfo
 
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/arm

Robert Yang (4):
  grub_git: set COMPATIBLE_HOST_armv7a to null
  webkitgtk: set COMPATIBLE_HOST_armv4 to null
  gnu-efi: set COMPATIBLE_HOST_armv4 to null
  cogl-1.0: set COMPATIBLE_HOST_armv4 to null

 meta/recipes-bsp/gnu-efi/gnu-efi_3.0.3.bb| 1 +
 meta/recipes-bsp/grub/grub_git.bb| 1 +
 meta/recipes-graphics/cogl/cogl-1.0.inc  | 2 ++
 meta/recipes-sato/webkit/webkitgtk_2.10.7.bb | 1 +
 4 files changed, 5 insertions(+)

-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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
correctly then blacklisting only armv7a is probably not the correct
approach.


Have you tested all the other architectures?


No, I will have a try.


I tried:
armv7a
armv7at
armv4
armv5


Also armv6.

// Robert



There isn't anything *more* wrong with grub_git except armv7a, so I think
that mark it COMPATIBLE_HOST_armv7a = 'null' is OK, but I did find other recipes
failed to build, I will send a new PULL.

We have quite a lot of arm tunes, I think that we need a script or tool to
auto test them. What's your opinion, please ?

// Robert



// Robert



Ross

On 18 April 2016 at 10:29, Robert Yang mailto:liezhi.y...@windriver.com>> wrote:

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 relocation 0x2b.
| make[3]: *** [halt.mod] Error 1
| make[3]: *** [cat.mod] Error 1
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| make[3]: *** [disk.mod] Error 1
| make[3]: *** [gptsync.mod] Error 1
| make[3]: *** [eval.mod] Error 1
| build-grub-module-verifier: error:build-grub-module-verifier: error:
unsupported relocation 0x2bunsupported relocation 0x2b.

Signed-off-by: Robert Yang mailto:liezhi.y...@windriver.com>>
---
  meta/recipes-bsp/grub/grub_git.bb  | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-bsp/grub/grub_git.bb 
b/meta/recipes-bsp/grub/grub_git.bb 
index 6919c9a..8f8c5ed 100644
--- a/meta/recipes-bsp/grub/grub_git.bb 
+++ b/meta/recipes-bsp/grub/grub_git.bb 
@@ -18,6 +18,7 @@ SRC_URI = "git://git.savannah.gnu.org/grub.git
 \
  S = "${WORKDIR}/git"

  COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
+COMPATIBLE_HOST_armv7a = 'null'

  inherit autotools gettext texinfo

--
2.8.0

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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
@@ -24,6 +24,7 @@ def base_version_less_or_equal(variable, checkvalue, 
truevalue, falsevalue, d):
 return oe.utils.version_less_or_equal(variable, checkvalue, truevalue, 
falsevalue, d)
 
 def base_contains(variable, checkvalues, truevalue, falsevalue, d):
+bb.warn('base_contains is depracated, please use bb.utils.contains 
instead.')
 return bb.utils.contains(variable, checkvalues, truevalue, falsevalue, d)
 
 def base_both_contain(variable1, variable2, checkvalue, d):
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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 a/meta/recipes-graphics/directfb/directfb.inc 
b/meta/recipes-graphics/directfb/directfb.inc
index f6b7cbe..46748988 100644
--- a/meta/recipes-graphics/directfb/directfb.inc
+++ b/meta/recipes-graphics/directfb/directfb.inc
@@ -26,7 +26,7 @@ S = "${WORKDIR}/DirectFB-${PV}"
 LDFLAGS_append =" -lts -lm"
 
 # Workaround for linking issues seen with armv7a + gold
-LDFLAGS_append_arm = "${@base_contains('DISTRO_FEATURES', 'ld-is-gold', ' 
-fuse-ld=bfd ', '', d)}"
+LDFLAGS_append_arm = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' 
-fuse-ld=bfd ', '', d)}"
 
 BINCONFIG = "${bindir}/directfb-config"
 
diff --git a/meta/recipes-graphics/pango/pango_1.38.1.bb 
b/meta/recipes-graphics/pango/pango_1.38.1.bb
index 7fc65fd..756dac4 100644
--- a/meta/recipes-graphics/pango/pango_1.38.1.bb
+++ b/meta/recipes-graphics/pango/pango_1.38.1.bb
@@ -36,7 +36,7 @@ LIBV = "1.8.0"
 
 # This binary needs to be compiled for the host architecture.  This isn't 
pretty!
 do_compile_prepend_class-target () {
-   if ${@base_contains('DISTRO_FEATURES', 'ptest', 'true', 'false', d)}; 
then
+   if ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 'true', 'false', 
d)}; then
make CC="${BUILD_CC}" CFLAGS="" LDFLAGS="" 
AM_CPPFLAGS="$(pkg-config-native --cflags glib-2.0)" 
gen_all_unicode_LDADD="$(pkg-config-native --libs glib-2.0)" -C ${B}/tests 
gen-all-unicode
fi
 }
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.10.7.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.10.7.bb
index 8eb6b9f..d4f1d3b 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.10.7.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.10.7.bb
@@ -34,8 +34,8 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt 
libidn gnutls \
   ruby-native libnotify gstreamer1.0-plugins-bad \
   "
 
-PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'x11', 'x11', 'wayland' 
,d)} \
-   ${@base_contains('DISTRO_FEATURES', 'opengl', 'webgl', '' 
,d)} \
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 
'wayland' ,d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl', 
'' ,d)} \
enchant \
gtk2 \
libsecret \
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/warn

Robert Yang (2):
  directfb/pango/webkit: base_contains -> bb.utils.contains
  utils.bbclass: warn for deprecated base_contains

 meta/classes/utils.bbclass   | 1 +
 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 ++--
 4 files changed, 5 insertions(+), 4 deletions(-)

-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

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 not the correct
approach.


Have you tested all the other architectures?


No, I will have a try.


I tried:
armv7a
armv7at
armv4
armv5

There isn't anything *more* wrong with grub_git except armv7a, so I think
that mark it COMPATIBLE_HOST_armv7a = 'null' is OK, but I did find other recipes
failed to build, I will send a new PULL.

We have quite a lot of arm tunes, I think that we need a script or tool to
auto test them. What's your opinion, please ?

// Robert



// Robert



Ross

On 18 April 2016 at 10:29, Robert Yang mailto:liezhi.y...@windriver.com>> wrote:

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 relocation 0x2b.
| make[3]: *** [halt.mod] Error 1
| make[3]: *** [cat.mod] Error 1
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| build-grub-module-verifier: error: unsupported relocation 0x2b.
| make[3]: *** [disk.mod] Error 1
| make[3]: *** [gptsync.mod] Error 1
| make[3]: *** [eval.mod] Error 1
| build-grub-module-verifier: error:build-grub-module-verifier: error:
unsupported relocation 0x2bunsupported relocation 0x2b.

Signed-off-by: Robert Yang mailto:liezhi.y...@windriver.com>>
---
  meta/recipes-bsp/grub/grub_git.bb  | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-bsp/grub/grub_git.bb 
b/meta/recipes-bsp/grub/grub_git.bb 
index 6919c9a..8f8c5ed 100644
--- a/meta/recipes-bsp/grub/grub_git.bb 
+++ b/meta/recipes-bsp/grub/grub_git.bb 
@@ -18,6 +18,7 @@ SRC_URI = "git://git.savannah.gnu.org/grub.git
 \
  S = "${WORKDIR}/git"

  COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
+COMPATIBLE_HOST_armv7a = 'null'

  inherit autotools gettext texinfo

--
2.8.0

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

On 04/21/2016 03:42 PM, Richard Purdie wrote:

On Thu, 2016-04-21 at 15:22 +0800, Robert Yang wrote:

There are several recipes in oe-core which has:
PV = "0.0+git${SRCPV}"

These recipes don't have a release version, so we use
"0.0+git${SRCPV}",
but the package manager such 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 = "20160421". And when we upgrade them in the future, we can
change
the PV to that day. We can change all the current version 0.0 target
recipes to today, and add a sanity check for version 0.0.


No, this is the whole idea behind having the PR Server which injects a
revision before the hash in SRCPV. We have the same problem with other
git recipes even where there are versions since the revision can change
and we need to be able to sort the versions correctly.


Thanks, I saw that PR Server will change git0 -> git1 -> git2 when SRCREV
is changed, it works.

// Robert



Cheers,

Richard


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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 provides libgbm as
> one of
> its packages, hence virtual/mesa is added in DEPENDS for kms:
>
> PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm
> udev virtual/mesa mtdev"
>
> On TI platforms with SGX GPU we have GLES/EGL stack (provided by
> proprietary
> blobs, yeah) and a separate libgbm, based on Rob Clark's
> https://github.com/robclark/libgbm
> Since that is enough to run Weston on our platforms, I've been carrying
> this
> bbappend for long time:
>
> PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm
> udev libgbm mtdev"
>
> It's been working fine for long time, but people keep on asking questions
> and
> require cleaner solution, since bbappend in a separate layer is somewhat
> confusing. Now, the question is what is a proper solution here:
>
> 1. Change weston recipe in oe-core to depend on libgbm instead of
> virtual/mesa
> assuming that it is provided by mesa recipe and it works for other
> platforms.
>

I'd say this, either libgbm or virtual/libgbm.

2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa,
> although
> it looks like a hack and is somewhat reverse...
>

I think the libgbm recipe would basically be lying if you do that, that
doesn't sound ideal.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] mesa, libgbm and weston

[Denys Dmytriyenko]

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 for kms:

PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm udev 
virtual/mesa mtdev"

On TI platforms with SGX GPU we have GLES/EGL stack (provided by proprietary 
blobs, yeah) and a separate libgbm, based on Rob Clark's 
https://github.com/robclark/libgbm
Since that is enough to run Weston on our platforms, I've been carrying this 
bbappend for long time:

PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm udev 
libgbm mtdev"

It's been working fine for long time, but people keep on asking questions and 
require cleaner solution, since bbappend in a separate layer is somewhat 
confusing. Now, the question is what is a proper solution here:

1. Change weston recipe in oe-core to depend on libgbm instead of virtual/mesa 
assuming that it is provided by mesa recipe and it works for other platforms.

2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa, although 
it looks like a hack and is somewhat reverse...

-- 
Denys
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Max Krummenacher]

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 <
> > > > jussi.kukko...@intel.com> het volgende geschreven:
> > > > 
> > > > Hi Koen,
> > > > 
> > > > I was looking at xinput-calibrator in preparation for bug 9365
> > > > "Remove
> > > > xtscal in preference of xinput-calibrator", and I'm wondering
> > > > if you
> > > > remember the logic behind this commit:
> > > > 
> > > > commit 6464bcd67d10ab9967ac83c27c413c1014be707e
> > > > Author: Koen Kooi 
> > > > Date:   Wed Apr 30 11:33:23 2014 +0200
> > > > 
> > > >xinput-calibrator: fix XDG launch
> > > > 
> > > >In the move from meta-oe to OE-core XDG based launched was
> > > > dropped
> > > >without noting it in the commit message, so fix that
> > > > regression.
> > > > 
> > > >Gnome-session will now launch the calibrator again.
> > > > 
> > > > The commit installs the app desktop file in the XDG autostart
> > > > directory. But we already have a XSession script for a similar
> > > > purpose
> > > > -- the result in Sato is that xinput-calibrator runs twice (and
> > > > I
> > > > would expect that to happen in gnome as well)?
> 
> It does not run twice in our case (LXDE). Can you point to the
> XSession
> script you are referring to?

This is not entirely true.

For the Colibri iMX.7 xinput-calibrator was launched twice initially.
Once by the XDG launch and once by the XSession script
/etc/X11/Xsession.d/30xinput_calibrate.sh.

The formfactor file https://github.com/Freescale/meta-fsl-arm/blob/mast
er/recipes-bsp/formfactor/formfactor/mx7/machconfig sets
HAVE_TOUCHSCREEN=1.
As a workaround we now override machconfig for our machine.

So for me the question remains if installing xinput-calibrator by
itself should launch the calibrator or if this should be conditional on
a config provided by the formfactor package.

Max

> 
> --
> Stefan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Stefan Agner]

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 
Signed-off-by: Stefan Agner 
---
 ...vider_replacees-do-not-add-installed-pkg-.patch | 112 +
 meta/recipes-devtools/opkg/opkg_0.3.0.bb   |   1 +
 2 files changed, 113 insertions(+)
 create mode 100644 
meta/recipes-devtools/opkg/opkg/0001-pkg_get_provider_replacees-do-not-add-installed-pkg-.patch

diff --git 
a/meta/recipes-devtools/opkg/opkg/0001-pkg_get_provider_replacees-do-not-add-installed-pkg-.patch
 
b/meta/recipes-devtools/opkg/opkg/0001-pkg_get_provider_replacees-do-not-add-installed-pkg-.patch
new file mode 100644
index 000..29a9f59
--- /dev/null
+++ 
b/meta/recipes-devtools/opkg/opkg/0001-pkg_get_provider_replacees-do-not-add-installed-pkg-.patch
@@ -0,0 +1,112 @@
+From c5acac4ca0633088ea3f2d92dc236a43593e13b7 Mon Sep 17 00:00:00 2001
+From: Alejandro del Castillo 
+Date: Tue, 12 Jan 2016 17:12:18 -0600
+Subject: [PATCH] pkg_get_provider_replacees: do not add installed pkg to
+ replacee list
+
+If package A replaces provider B, and B is provided by A,
+pkg_get_provider_replacees incorrectly adds A to the list of B replacees
+when A is installed. During an upgrade, pacakge A is removed during
+pkg_remove_installed_replacees, then once more during the package
+upgrade.
+
+Add check to skip the insertion of package A into the replacees vector
+in pkg_get_provider_replacees.
+
+Signed-off-by: Alejandro del Castillo 
+---
+ libopkg/opkg_install.c | 13 +
+ tests/Makefile |  1 +
+ tests/regress/issue8913.py | 44 
+ 3 files changed, 54 insertions(+), 4 deletions(-)
+ create mode 100755 tests/regress/issue8913.py
+
+diff --git a/libopkg/opkg_install.c b/libopkg/opkg_install.c
+index dbfafa5..c2db870 100644
+--- a/libopkg/opkg_install.c
 b/libopkg/opkg_install.c
+@@ -427,10 +427,15 @@ static void pkg_get_provider_replacees(pkg_t * pkg,
+ continue;
+ for (j = 0; j < ap->pkgs->len; j++) {
+ pkg_t *replacee = ap->pkgs->pkgs[j];
+-int installed = (replacee->state_status == SS_INSTALLED)
+-|| (replacee->state_status == SS_UNPACKED);
+-if (installed)
+-pkg_vec_insert(replacees, replacee);
++pkg_t *old = pkg_hash_fetch_installed_by_name(pkg->name);
++/* skip pkg if installed: it  will be removed during upgrade
++ * issue 8913 */
++if (old != replacee) {
++int installed = (replacee->state_status == SS_INSTALLED)
++|| (replacee->state_status == SS_UNPACKED);
++if (installed)
++pkg_vec_insert(replacees, replacee);
++}
+ }
+ }
+ }
+diff --git a/tests/Makefile b/tests/Makefile
+index 707434f..d01e97b 100644
+--- a/tests/Makefile
 b/tests/Makefile
+@@ -39,6 +39,7 @@ REGRESSION_TESTS := core/01_install.py \
+   regress/issue127.py \
+   regress/issue152.py \
+   regress/issue154.py \
++  regress/issue8913.py \
+   misc/filehash.py \
+   misc/update_loses_autoinstalled_flag.py
+ RUN_TESTS := $(REGRESSION_TESTS:%.py=run-%.py)
+diff --git a/tests/regress/issue8913.py b/tests/regress/issue8913.py
+new file mode 100755
+index 000..aaa940f
+--- /dev/null
 b/tests/regress/issue8913.py
+@@ -0,0 +1,44 @@
++#! /usr/bin/env python3
++#
++# Reporter: alejandro.delcasti...@ni.com
++#
++# What steps will reproduce the problem?
++# ==
++#
++# 1.- Create package a (v 1.0) that Provides b and c, Replaces b, Conflicts 
with b.
++# install it
++# 2.- Create package a (v 2.0) that Provides b and c, Replaces b, Conflicts 
with b.
++# upgrade
++#
++# What is the expected output? What do you see instead?
++# =
++#
++# Upgrade fails
++#
++
++import os
++import opk, cfg, opkgcl
++
++opk.regress_init()
++
++o = opk.OpkGroup()
++o.add(Package="a", Version="1.0", Provides="b, c", Replaces="b", 
Conflicts="b")
++o.write_opk()
++o.write_list()
++
++opkgcl.update()
++
++opkgcl.install("a", "--force-postinstall")
++
++o = opk.OpkGroup()
++o.add(Package="a", Version="2.0", Provides="b, c", Replaces="b", 
Conflicts="b")
++o.write_opk()
++o.write_list()
++
++opkgcl.update()
++status = opkgcl.upgrade("--force-postinstall")
++
++if not opkgcl.is_installed("a", "2.0"):
++  opk.fail("New version of package 'a' available during upgrade but was 
not installed")
++
++opkgcl.remove("a")
+-- 
+2.8.0
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.3.0.bb 
b/meta/recipes-devtools/opkg/opkg_0.3.0.bb
index 5ad3e92..70110d5 100644
--- a/meta/recipes-devtools/opkg/opkg_0.3.0.bb
+++ b/

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

[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  
>>> het volgende geschreven:
>>>
>>> Hi Koen,
>>>
>>> I was looking at xinput-calibrator in preparation for bug 9365 "Remove
>>> xtscal in preference of xinput-calibrator", and I'm wondering if you
>>> remember the logic behind this commit:
>>>
>>> commit 6464bcd67d10ab9967ac83c27c413c1014be707e
>>> Author: Koen Kooi 
>>> Date:   Wed Apr 30 11:33:23 2014 +0200
>>>
>>>xinput-calibrator: fix XDG launch
>>>
>>>In the move from meta-oe to OE-core XDG based launched was dropped
>>>without noting it in the commit message, so fix that regression.
>>>
>>>Gnome-session will now launch the calibrator again.
>>>
>>> The commit installs the app desktop file in the XDG autostart
>>> directory. But we already have a XSession script for a similar purpose
>>> -- the result in Sato is that xinput-calibrator runs twice (and I
>>> would expect that to happen in gnome as well)?

It does not run twice in our case (LXDE). Can you point to the XSession
script you are referring to?

--
Stefan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Yannick GICQUEL]

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 performs the concatenation of the
u-boot-nodtb.bin and the device tree blob. The 'cat' command used
overrides the u-boot.bin in both DEPLOYDIR & build dir to propagate the
changes in later tasks (do_install, do_package, etc.)

Signed-off-by: Yannick Gicquel 
---
  meta/classes/uboot-sign.bbclass| 59 ++
  meta/recipes-bsp/u-boot/u-boot.inc |  2 +-
  2 files changed, 60 insertions(+), 1 deletion(-)
  create mode 100644 meta/classes/uboot-sign.bbclass

diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
new file mode 100644
index 000..63a5181
--- /dev/null
+++ b/meta/classes/uboot-sign.bbclass
@@ -0,0 +1,59 @@
+# This file is part of U-Boot verified boot support and is intended to be
+# inherited from u-boot recipe and from kernel-fitimage.bbclass.
+#
+# The signature procedure requires the user to generate an RSA key and
+# certificate in a directory and to define the following variable:
+#
+#   UBOOT_SIGN_KEYDIR = "/keys/directory"
+#   UBOOT_SIGN_KEYNAME = "dev" # keys name in keydir (eg. "dev.crt", "dev.key")
+#   UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
+#   UBOOT_SIGN_ENABLE = "1"
+#
+# As verified boot depends on fitImage generation, following is also required:
+#
+#   KERNEL_CLASSES ?= " kernel-fitimage "
+#   KERNEL_IMAGETYPE ?= "fitImage"
+#
+# The signature support is limited to the use of CONFIG_OF_SEPARATE in U-Boot.
+#
+# The tasks sequence is as below, using DEPLOY_IMAGE_DIR as common place to
+# treat the device tree blob:
+#
+# u-boot:do_deploy -> virtual/kernel:do_assemble_fitimage -> u-boot:do_install
+#
+# For more details on signature process, please refer to U-boot documentation.
+
+# Signature activation.
+UBOOT_SIGN_ENABLE ?= "0"
+
+# Default value for deployment filenames.
+UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
+UBOOT_DTB_BINARY ?= "u-boot.dtb"
+UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb"
+UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
+UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}"
+UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
+

I think you should split the file at this point and either put the lines
above into uboot-sign-base.bbclass and include it from here or put the
lines below into u-boot.inc directly. This way you don't add unnecessary
code for u-boot to kernel recipes, and lose the dependency on PN =
"u-boot" at the same time.


Thanks for the proposal, that's interesting.
I agree that splitting the file should remove the dependencies on 
'_pn-u-boot' and it also allow to keep usage of existing 'deploy' and 
'install' tasks.
But even in that case, we will still have a last reference to 'u-boot' 
recipe name, hardcoded in kernel-fitimage.bbclass:


d.appendVarFlag('do_assemble_fitimage', 'depends', ' u-boot:do_deploy')
 ^^
For now, I don't know a way to avoid using PREFERRED_PROVIDER_u-boot 
variable at some point.


Also, I worked on an update (keeping one class file) and in that case it 
now introduces specifics tasks for u-boot. (cf. patch attached).
I would prefer to keep the whole thing in one single class file to avoid 
fragmentation, except if introducing new tasks it is not advised for any 
reason?

Your comments are welcome.

Anyway, I would be able to send a V3 series (maybe without RFC) early 
next week.

Thank you all for Acked, Reviewed and comments!

Best regards,
Yannick



Regards,
Andreas


+#
+# Following is relevant only for u-boot recipes:
+#
+
+do_install_prepend_pn-u-boot () {
+   # Concatenate U-Boot w/o DTB & DTB with public key
+   # (cf. kernel-fitimage.bbclass for more details)
+   cd ${DEPLOYDIR}
+   if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ]; then
+   if [ -e "${UBOOT_NODTB_IMAGE}" -a -e "${UBOOT_DTB_IMAGE}" ]; 
then
+   cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
${UBOOT_IMAGE}
+   cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
${B}/${UBOOT_BINARY}
+   else
+   bbwarn "Failure while adding public key to u-boot binary. 
Verified boot won't be available."
+   fi
+   fi
+}
+
+python () {
+   if d.getVar('UBOOT_SIGN_ENABLE', True) == '1' and d.getVar('PN', True) 
== 'u-boot':
+   kernel_pn = d.getVar('PREFERRED_PROVIDER_virtual/kernel', True)
+   d.appendVarFlag('do_install', 'depends', ' 
%s:do_assemble_fitimage' % kernel_pn)
+}
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 3ba866d..037f35c 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc

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

[Denys Dmytriyenko]

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:

http://cgit.openembedded.org/openembedded-core/commit/?id=c8e0ec2da9ad4ce1c103966906a85f68c15400dd

There are other use cases for the packaging data to be available in SDK,
since it provides comprehensive info about SDK's contents and in the case of
opkg and dpkg is all text-based and can be easily parsed by simple scripts.

Introduce new "package-management" flag for SDKIMAGE_FEATURES list (similar
to the one already used for IMAGE_FEATURES) that controls presence of the
packaging data in resulting SDK, while unifying this behavior across the
board for supported pkg managers - rpm, opkg, dpkg.

Signed-off-by: Denys Dmytriyenko 
---
 meta/lib/oe/sdk.py | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/sdk.py b/meta/lib/oe/sdk.py
index f15fbdb..f1bbef6 100644
--- a/meta/lib/oe/sdk.py
+++ b/meta/lib/oe/sdk.py
@@ -155,14 +155,16 @@ class RpmSdk(Sdk):
 
 execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_TARGET_COMMAND", True))
 
-self.target_pm.remove_packaging_data()
+if not bb.utils.contains("SDKIMAGE_FEATURES", "package-management", 
True, False, self.d):
+self.target_pm.remove_packaging_data()
 
 bb.note("Installing NATIVESDK packages")
 self._populate_sysroot(self.host_pm, self.host_manifest)
 
 execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_HOST_COMMAND", True))
 
-self.host_pm.remove_packaging_data()
+if not bb.utils.contains("SDKIMAGE_FEATURES", "package-management", 
True, False, self.d):
+self.host_pm.remove_packaging_data()
 
 # Move host RPM library data
 native_rpm_state_dir = os.path.join(self.sdk_output,
@@ -232,14 +234,16 @@ class OpkgSdk(Sdk):
 
 execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_TARGET_COMMAND", True))
 
-self.target_pm.remove_packaging_data()
+if not bb.utils.contains("SDKIMAGE_FEATURES", "package-management", 
True, False, self.d):
+self.target_pm.remove_packaging_data()
 
 bb.note("Installing NATIVESDK packages")
 self._populate_sysroot(self.host_pm, self.host_manifest)
 
 execute_pre_post_process(self.d, 
self.d.getVar("POPULATE_SDK_POST_HOST_COMMAND", True))
 
-self.host_pm.remove_packaging_data()
+if not bb.utils.contains("SDKIMAGE_FEATURES", "package-management", 
True, False, self.d):
+self.host_pm.remove_packaging_data()
 
 target_sysconfdir = os.path.join(self.sdk_target_sysroot, 
self.sysconfdir)
 host_sysconfdir = os.path.join(self.sdk_host_sysroot, self.sysconfdir)
@@ -314,6 +318,9 @@ class DpkgSdk(Sdk):
 
 self._copy_apt_dir_to(os.path.join(self.sdk_target_sysroot, "etc", 
"apt"))
 
+if not bb.utils.contains("SDKIMAGE_FEATURES", "package-management", 
True, False, self.d):
+self.target_pm.remove_packaging_data()
+
 bb.note("Installing NATIVESDK packages")
 self._populate_sysroot(self.host_pm, self.host_manifest)
 
@@ -322,6 +329,9 @@ class DpkgSdk(Sdk):
 self._copy_apt_dir_to(os.path.join(self.sdk_output, 
self.sdk_native_path,
"etc", "apt"))
 
+if not bb.utils.contains("SDKIMAGE_FEATURES", "package-management", 
True, False, self.d):
+self.host_pm.remove_packaging_data()
+
 native_dpkg_state_dir = os.path.join(self.sdk_output, 
self.sdk_native_path,
  "var", "lib", "dpkg")
 self.mkdirhier(native_dpkg_state_dir)
-- 
2.2.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Ed Bartosh]

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
> 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 wks, it generates a default cfg as before.
> 
> Signed-off-by: Ioan-Adrian Ratiu 
> ---
>  .../lib/wic/plugins/source/isoimage-isohybrid.py   | 53 
> +-
>  1 file changed, 32 insertions(+), 21 deletions(-)
> 
> diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
> b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> index bc99283..8440581 100644
> --- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> +++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> @@ -27,6 +27,7 @@ import glob
>  
>  from wic import msger
>  from wic.pluginbase import SourcePlugin
> +from wic.utils.misc import get_custom_config
>  from wic.utils.oe.misc import exec_cmd, exec_native_cmd, get_bitbake_var
>  
>  class IsoImagePlugin(SourcePlugin):
> @@ -94,33 +95,43 @@ class IsoImagePlugin(SourcePlugin):
>  """
>  Create loader-specific (grub-efi) config
>  """
> -splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")
> -if os.path.exists(splash):
> -splashline = "menu background splash.jpg"
> +configfile = creator.ks.bootloader.configfile
> +if configfile:
> +grubefi_conf = get_custom_config(configfile)
> +if grubefi_conf:
> +msger.debug("Using custom configuration file "
> +"%s for grub.cfg" % configfile)
> +else:
> +msger.error("configfile is specified but failed to "
> +"get it from %s." % configfile)
>  else:
> -splashline = ""
> +splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")
> +if os.path.exists(splash):
> +splashline = "menu background splash.jpg"
> +else:
> +splashline = ""
>  
> -bootloader = creator.ks.bootloader
> +bootloader = creator.ks.bootloader
>  
> -grubefi_conf = ""
> -grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
> -grubefi_conf += "--parity=no --stop=1\n"
> -grubefi_conf += "default=boot\n"
> -grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
> -grubefi_conf += "\n"
> -grubefi_conf += "search --set=root --label %s " % part.label
> -grubefi_conf += "\n"
> -grubefi_conf += "menuentry 'boot'{\n"
> +grubefi_conf = ""
> +grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
> +grubefi_conf += "--parity=no --stop=1\n"
> +grubefi_conf += "default=boot\n"
> +grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
> +grubefi_conf += "\n"
> +grubefi_conf += "search --set=root --label %s " % part.label
> +grubefi_conf += "\n"
> +grubefi_conf += "menuentry 'boot'{\n"
>  
> -kernel = "/bzImage"
> +kernel = "/bzImage"
>  
> -grubefi_conf += "linux %s rootwait %s\n" \
> -% (kernel, bootloader.append)
> -grubefi_conf += "initrd /initrd \n"
> -grubefi_conf += "}\n"
> +grubefi_conf += "linux %s rootwait %s\n" \
> +% (kernel, bootloader.append)
> +grubefi_conf += "initrd /initrd \n"
> +grubefi_conf += "}\n"
>  
> -if splashline:
> -grubefi_conf += "%s\n" % splashline
> +if splashline:
> +grubefi_conf += "%s\n" % splashline
>  
>  msger.debug("Writing grubefi config %s/EFI/BOOT/grub.cfg" \
>  % cr_workdir)
> -- 
> 2.8.0
> 

-- 
--
Regards,
Ed
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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
index bdf0693..4fbb40a 100644
--- a/scripts/lib/recipetool/newappend.py
+++ b/scripts/lib/recipetool/newappend.py
@@ -81,7 +81,7 @@ def newappend(args):
 return 1
 
 if not path_ok:
-logger.warn('Unable to determine correct subdirectory path for 
bbappend file - check that what %s adds to BBFILES also matches .bbappend 
files. Using %s for now, but until you fix this the bbappend will not be 
applied.', os.path.join(destlayerdir, 'conf', 'layer.conf'), 
os.path.dirname(appendpath))
+logger.warn('Unable to determine correct subdirectory path for 
bbappend file - check that what %s adds to BBFILES also matches .bbappend 
files. Using %s for now, but until you fix this the bbappend will not be 
applied.', os.path.join(args.destlayer, 'conf', 'layer.conf'), 
os.path.dirname(append_path))
 
 layerdirs = [os.path.abspath(layerdir) for layerdir in 
rd.getVar('BBLAYERS', True).split()]
 if not os.path.abspath(args.destlayer) in layerdirs:
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Mark Hatle]

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:
 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" really is being written off for mysterious
 reasons, rpm4 was only just removed from oe-core (though
 depending on what releases you're using you may have never
 noticed it be added and removed again).  So you could just
 recover that from history (oe-core
 a6e7a86f1635be9a688c56c25e9d215ea4d2cc84 removed it) and fix it
 up.
>>>
>>>   just to be clear, if i can dredge up the recipe for rpm_4, i'm
>>> assuming i'd want to specify that i want the "package-management"
>>> image feature, as well as stating:
>>>
>>> PREFERRED_VERSION_rpm = "4.%"
>>> PREFERRED_VERSION_rpm-native = "4.%"
>>>
>>> correct?
>>
>> Just to confuse things further, you could write an OE recipe which
>> took the v4 rpm files from the other system and then simply
>> repackaged them into v5 rpms files. Nothing says you *must* compile
>> from source, the input could be the v4 rpms.
> 
>   great, just what i needed ... yet *another* strategy. in any event,
> can i confirm that if i have the recipe for RPM4, i can use
> PREFERRED_VERSION to use it for the OE build and, later, to install
> RPM4-format rpms built elsewhere?
> 
>   also, *if* i build an image based on RPM4, is it feasible (or even
> possible) to upgrade the whole thing to RPM5 later? i'm not sure i
> even want to think about the grief possibly involved in that.

Due to potential endian and header differences, I don't know.

It was certainly possible in the past to do this (and easy).  But at this point
it may no longer work.

I think this is a question that probably should go to the rpm5-users mailing
list, as they may have more information.

--Mark

>   thanks muchly.
> 
> rday
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Mark Hatle]

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 files are in rpm4 format; ergo,
> they obviously don't play well with a system built with current OE/YP.
> so ... what to do?

What is not working about the packages build with RPM 4?  The RPM format is
compatible between RPM 4 and RPM 5.

There are specific configurations that may or may not be used in the RPM 4
compilations, that may need to be enabled in RPM 5.  Things like compression
format for instance.

I need to see the errors that are encountered to give a clue as to what may be
wrong.

>   first, current muttering is, "grr ... why did OE migrate to
> rpm5?" i actually didn't really know the answer to that, so i poked
> around and found this:
> 
>   http://rpm5.org/community/rpm-users/0998.html

It's been a while, but there was a thread a while back on 4 vs 5 on the OE list,
and there was a mini thread on the YP list a few days ago.

Unfortunately I am not finding the email.

I'll quote from another email I've sent (this is NOT the one I'm referring to 
BTW).

Comparing RPM 4 to RPM 5 (circa May 2014):

HHGG:
* Don't panic!  RPM Packages are compatible between RPM 4 and RPM 5.

Background:

* RPM 4 and RPM 5 split a number of years ago.
   Both still have their purposes.

- RPM 4:
   * License: GPLv2+
   * Uses beecrypt and nss for encryption
   * Maintained and supported by Fedora(Red Hat)

- RPM 5:
   * License: LGPLv2.1
   * Uses beecrypt, and (nss or openssl or others) for encryption
 - Can't mix OpenSSL w/ GPLv2 due to license issue
   * Maintained and supported by Jeff Johnson

Differences:

* RPM 4 vs RPM 5
RPM 4 is missing the following features:

- Cross compile support / Cross endian support
  ** rpmbuild v4 is intended for native builds only

The RPM data structures should be little endian for the most part, but
historically RPM 4 did not transform everything to little endian.  This caused
problems when a package was built on x86 and installed on Power.  The berkleydb
itself was susceptible to this -- RPM5 does proper endian translations.

- "no arch"  / "not arch" support

In RPM4, there is a set list of 'compatible' and 'known' architectures.  If your
package 'arch' is not in this list, everything fails.

In RPM5, there is no set list.  Instead, there is a configuration of compatible
platforms (thats the /etc/rpm/platforms file).  The package arch is not used for
compatibility, instead there is a package platform that is inspected and
compared.  (Note, RPM4 also sets the platform, it just doesn't use it in this 
way.)

- Support for arbitrary tags

Packages can specify arbitrary information to include in the header and be
retrieved during install and inspection.  There tags are used by OpenEmbedded
for the 'Suggests' and 'Enhances' fields.  (While rarely used, we do support the
values.  In addition, I know of a few people who use the arbitrary tags to add
additional support information into the RPM packages themselves.  This is
outside the normal OE usage though.)

- RPM 5 has supported the 'Recommends' field for a long time, only recently has
RPM 4 added it -- and it was added in an incompatible way.

RPM 5 puts recommended items into the 'requires' field, and adds a 'MISSINGOK' 
flag.

RPM 4 defined a new tag for Recommended items.

(Both RPM 5 and 4 support each others implementations)

- RPM 5 maintainer actively cares about OE and YP usages.

You may not see Jeff on the mailing list, but I talk with him regularly and
discuss the problems and enhancements we have.  He will work through the issues
with me (and other YP folks) to try to come up with a solution that fits into
the RPM framework without creating new incompatibilities.  This is a huge help
for us.

- RPM 5 does not have a plug-in interface like RPM 4

This is the one place where I've seen discussions for people demanding RPM 4.
They need specific IMA, Smack, Selinux, etc plugins.  Frankly I think trusting
any system the size and complexity of RPM with that responsibility is
incorrect... but from a compatibility standpoint that may be one of the few
reasons to justify RPM 4 at present.

> the mention of "more flexibility in cross compilation and control"
> makes perfect sense to me, but is there a more comprehensive writeup
> somewhere that lays out the rationale for the move to rpm5 that can be
> used in its defense?
> 
>   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.

If you want package compatibility, this simply should not be necessary.

>   another option is to simply install a totally independent rpm5 on
> the centos 6 box, and use that exclusively for building packages to be
> installed on an OE system. has anyone done this?

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

[Robert P. J. Day]

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 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" really is being written off for mysterious
> > > reasons, rpm4 was only just removed from oe-core (though
> > > depending on what releases you're using you may have never
> > > noticed it be added and removed again).  So you could just
> > > recover that from history (oe-core
> > > a6e7a86f1635be9a688c56c25e9d215ea4d2cc84 removed it) and fix it
> > > up.
> >
> >   just to be clear, if i can dredge up the recipe for rpm_4, i'm
> > assuming i'd want to specify that i want the "package-management"
> > image feature, as well as stating:
> >
> > PREFERRED_VERSION_rpm = "4.%"
> > PREFERRED_VERSION_rpm-native = "4.%"
> >
> > correct?
>
> Just to confuse things further, you could write an OE recipe which
> took the v4 rpm files from the other system and then simply
> repackaged them into v5 rpms files. Nothing says you *must* compile
> from source, the input could be the v4 rpms.

  great, just what i needed ... yet *another* strategy. in any event,
can i confirm that if i have the recipe for RPM4, i can use
PREFERRED_VERSION to use it for the OE build and, later, to install
RPM4-format rpms built elsewhere?

  also, *if* i build an image based on RPM4, is it feasible (or even
possible) to upgrade the whole thing to RPM5 later? i'm not sure i
even want to think about the grief possibly involved in that.

  thanks muchly.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Andreas Oberritter]

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 and the device tree blob. The 'cat' command used
> overrides the u-boot.bin in both DEPLOYDIR & build dir to propagate the
> changes in later tasks (do_install, do_package, etc.)
> 
> Signed-off-by: Yannick Gicquel 
> ---
>  meta/classes/uboot-sign.bbclass| 59 
> ++
>  meta/recipes-bsp/u-boot/u-boot.inc |  2 +-
>  2 files changed, 60 insertions(+), 1 deletion(-)
>  create mode 100644 meta/classes/uboot-sign.bbclass
> 
> diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
> new file mode 100644
> index 000..63a5181
> --- /dev/null
> +++ b/meta/classes/uboot-sign.bbclass
> @@ -0,0 +1,59 @@
> +# This file is part of U-Boot verified boot support and is intended to be
> +# inherited from u-boot recipe and from kernel-fitimage.bbclass.
> +#
> +# The signature procedure requires the user to generate an RSA key and
> +# certificate in a directory and to define the following variable:
> +#
> +#   UBOOT_SIGN_KEYDIR = "/keys/directory"
> +#   UBOOT_SIGN_KEYNAME = "dev" # keys name in keydir (eg. "dev.crt", 
> "dev.key")
> +#   UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
> +#   UBOOT_SIGN_ENABLE = "1"
> +#
> +# As verified boot depends on fitImage generation, following is also 
> required:
> +#
> +#   KERNEL_CLASSES ?= " kernel-fitimage "
> +#   KERNEL_IMAGETYPE ?= "fitImage"
> +#
> +# The signature support is limited to the use of CONFIG_OF_SEPARATE in 
> U-Boot.
> +#
> +# The tasks sequence is as below, using DEPLOY_IMAGE_DIR as common place to
> +# treat the device tree blob:
> +#
> +# u-boot:do_deploy -> virtual/kernel:do_assemble_fitimage -> 
> u-boot:do_install
> +#
> +# For more details on signature process, please refer to U-boot 
> documentation.
> +
> +# Signature activation.
> +UBOOT_SIGN_ENABLE ?= "0"
> +
> +# Default value for deployment filenames.
> +UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
> +UBOOT_DTB_BINARY ?= "u-boot.dtb"
> +UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb"
> +UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
> +UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}"
> +UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
> +

I think you should split the file at this point and either put the lines
above into uboot-sign-base.bbclass and include it from here or put the
lines below into u-boot.inc directly. This way you don't add unnecessary
code for u-boot to kernel recipes, and lose the dependency on PN =
"u-boot" at the same time.

Regards,
Andreas

> +#
> +# Following is relevant only for u-boot recipes:
> +#
> +
> +do_install_prepend_pn-u-boot () {
> + # Concatenate U-Boot w/o DTB & DTB with public key
> + # (cf. kernel-fitimage.bbclass for more details)
> + cd ${DEPLOYDIR}
> + if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ]; then
> + if [ -e "${UBOOT_NODTB_IMAGE}" -a -e "${UBOOT_DTB_IMAGE}" ]; 
> then
> + cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
> ${UBOOT_IMAGE}
> + cat ${UBOOT_NODTB_IMAGE} ${UBOOT_DTB_IMAGE} > 
> ${B}/${UBOOT_BINARY}
> + else
> + bbwarn "Failure while adding public key to u-boot 
> binary. Verified boot won't be available."
> + fi
> + fi
> +}
> +
> +python () {
> + if d.getVar('UBOOT_SIGN_ENABLE', True) == '1' and d.getVar('PN', True) 
> == 'u-boot':
> + kernel_pn = d.getVar('PREFERRED_PROVIDER_virtual/kernel', True)
> + d.appendVarFlag('do_install', 'depends', ' 
> %s:do_assemble_fitimage' % kernel_pn)
> +}
> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
> b/meta/recipes-bsp/u-boot/u-boot.inc
> index 3ba866d..037f35c 100644
> --- a/meta/recipes-bsp/u-boot/u-boot.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
> @@ -12,7 +12,7 @@ S = "${WORKDIR}/git"
>  
>  PACKAGE_ARCH = "${MACHINE_ARCH}"
>  
> -inherit uboot-config deploy
> +inherit uboot-config uboot-sign deploy
>  
>  EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc 
> ${TOOLCHAIN_OPTIONS}" V=1'
>  EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

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:

meta/recipes-extended/images/core-image-kernel-dev.bb:

  IMAGE_ROOTFS_EXTRA_SPACE_append += "+ 300"

and there's this weirdness in meta/lib/oeqa/selftest/layerappend.py:

... snip ...
addtask build
"""
append = """
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_append = " file://appendtest.txt"

sysroot_stage_all_append() {
install -m 644 ${WORKDIR}/appendtest.txt ${SYSROOT_DESTDIR}/
}

"""

append2 = """
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_append += "file://appendtest.txt"



  not quite sure what's going on there with those two variations of
assignment to SRC_URI, so i'm just going to leave it alone.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

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 @@ require attr.inc

 # configure.ac was missing from the release tarball. This should be fixed in
 # future releases of attr, remove this when updating the recipe.
-SRC_URI_append += "file://attr-Missing-configure.ac.patch \
-   file://dont-use-decl-macros.patch \
-  "
+SRC_URI += "file://attr-Missing-configure.ac.patch \
+file://dont-use-decl-macros.patch \
+   "

 SRC_URI[md5sum] = "84f58dec00b60f2dc8fd1c9709291cc7"
 SRC_URI[sha256sum] = 
"25772f653ac5b2e3ceeb89df50e4688891e21f723c460636548971652af0a859"

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

... 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 until the final stage of processing. so what
> > this tells me is that all of the items you list in SRC_URI should
> > *not* be order-dependent, is that a fair statement? or, IOW, if
> > your layer depends on the items in SRC_URI being processed in a
> > specific order, you probably need to rework your recipe file.
>
> Sometimes order is important, e.g. two patches which change the same
> set of files would need to be applied in the correct order.

  if i had that situation, i would think the obvious approach is that
those two patches should be bundled into the same .scc file, where
patch application ordering is preserved. my point was that i wouldn't
want to count on the ordering of items in the SRC_URI list itself.

> >   and, finally, given that you can have a combination of SRC_URI
> > assignments and appends in the same .bbappend file:
> >
> >   SRC_URI += "..."
> >   SRC_URI_append = "..."
> >   SRC_URI_append_ = "..."
> >
> > that tells me that you *really* don't want any of that to be
> > order-dependent, as i mentioned before.
>
> Right, you'd have to be careful with this.

  and that's the point i was making ... if you're mixing conditional
and unconditional SRC_URI appending, you *really* don't want to count
on any particular order of processing of the items in that variable.

  oh, one more thing related to coding style. given that .bb recipe
files are the foundation on which further .bbappend customization is
built, it would seem that .bb files should consistently use just:

  SRC_URI = "..."

and not

  SRC_URI += "..."

*unless* they're first including some .inc file that would set that
variable to some common initial value.

  i know it would make no difference in the end, but for me, it's a
visual thing -- when i see any use of "+=", i normally assume that
there might be some earlier value that's been assigned, so i take a
little more care in what i'm doing. so my coding style for new recipe
files would be to *always* use:

  SRC_URI = "..."

unless there was a good reason not to. and, yes, i am that pedantic.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Richard Purdie]

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 packages?", which is not a path down which i want
> > to walk.
> > 
> > 
> > Assuming that the obviously correct option of "build the packages
> > inside OE" really is being written off for mysterious reasons, rpm4
> > was only just removed from oe-core (though depending on what
> > releases you're using you may have never noticed it be added and
> > removed again).  So you could just recover that from history
> > (oe-core a6e7a86f1635be9a688c56c25e9d215ea4d2cc84 removed it) and
> > fix it up.
> 
>   just to be clear, if i can dredge up the recipe for rpm_4, i'm
> assuming i'd want to specify that i want the "package-management"
> image feature, as well as stating:
> 
> PREFERRED_VERSION_rpm = "4.%"
> PREFERRED_VERSION_rpm-native = "4.%"
> 
> correct?

Just to confuse things further, you could write an OE recipe which took
the v4 rpm files from the other system and then simply repackaged them
into v5 rpms files. Nothing says you *must* compile from source, the
input could be the v4 rpms.

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

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, but I do caution
> against people just using it "because".  The RPM 5 version is
> generally better suited for the embedded world.  (There are been
> posts on more reasons on the oe-core lists in the past.  But as
> quick summary -- dynamic architecture support, better cross
> compilation support, cross- endian support, more configurable for
> custom distributions, etc.)"
> http://article.gmane.org/gmane.linux.embedded.yocto.general/28654/
>
> We ended up removing RPM4 support because it was clear that it was
> broken when using SMART as a package manager and we didn't have the
> resources to fix it, nor any objections to its removal.

  ah, i was unaware that smart does not play well with RPM4 ... i
think i'd better collect all this info so i can present it in one
shot. i think i'm going to look into the feasibility of installing
RPM5 on that centos build server, unless someone cautions me against
it.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Richard Purdie]

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 of it).
> 
>   first, if one simply appends items to SRC_URI, as in:
> 
>   SRC_URI += " \
>   derp.scc \
>   gorp.scc \
>   ...
>   "
> 
> then regardless of how FILESOVERRIDES adjusts the search order in the
> eventual FILESPATH, those items *must* be found somewhere, correct?
> (this seems pretty obvious to me, but i've been burned by obvious
> things before.)

They need to be found somewhere, yes.

>   next, i realize there are two forms of appending to SRC_URI:
> 
>  * SRC_URI +=
>  * SRC_URI_append =
> 
> first, is there an aesthetic preference for one over the other if the
> end result is the same? (just curious about what people here prefer
> to
> use.)

In general we should try and use += if possible as its simpler and
easier to understand what it does.

>   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 until the final stage of processing. so what this tells
> me is that all of the items you list in SRC_URI should *not* be
> order-dependent, is that a fair statement? or, IOW, if your layer
> depends on the items in SRC_URI being processed in a specific order,
> you probably need to rework your recipe file.

Sometimes order is important, e.g. two patches which change the same
set of files would need to be applied in the correct order.

Some things don't matter though.

>   (side note: i do realize that, in a single .scc file, the patches
> listed will be applied in precisely that order, but that's a
> different
> issue and not relevant here.)
> 
>   next, if there are truly conditional SRC_URI items, the only way to
> identify those is:
> 
>   SRC_URI_append_ = " ... blah blah ..."
> 
> you can't do this, can you?
> 
>   SRC_URI_ += " more stuff "

You can do that but it won't do what you'd want (it would overwrite the
original SRC_URI).

> i don't think i've ever seen an example of the latter, but maybe i
> just didn't look closely enough.

That would be because it wouldn't do anything useful in most cases.

>   and, finally, given that you can have a combination of SRC_URI
> assignments and appends in the same .bbappend file:
> 
>   SRC_URI += "..."
>   SRC_URI_append = "..."
>   SRC_URI_append_ = "..."
> 
> that tells me that you *really* don't want any of that to be
> order-dependent, as i mentioned before.

Right, you'd have to be careful with this.

>   is that about it? am i missing anything about SRC_URI definition
> and
> processing? thanks muchly.
> 
> rday
> 
> p.s.  oh, wait, two more curiosities. first, i still see the
> occasional example of this in numerous layers, including oe-core:
> 
> meta/recipes-support/attr/attr_2.4.47.bb:
> SRC_URI_append += "file://attr-Missing-configure.ac.patch \
> ^
> 
> pretty sure combining "SRC_URI_append" with "+=" is just as redundant
> as ever, no? :-)

+= means there is a space prepended so its equivalent to:

SRC_URI_append = " file://attr-Missing-configure.ac.patch \

but we should remove such things.

>   also, if the list of items in SRC_URI should be order-independent,
> then it would seem to make little sense to specifically use:
> 
>   SRC_URI_prepend = "..."
> 
> anywhere, right? IOW, there should be no situation in which
> specifically *prepending* to SRC_URI is necessary. but i found one
> example in oe-core:
> 
>   meta/recipes-devtools/qemu/qemu_2.5.0.bb:
> 
> SRC_URI += "file://configure-fix-Darwin-target-detection.patch \
> file://qemu-enlarge-env-entry-size.patch \
> file://Qemu-Arm-versatilepb-Add-memory-size
> -checking.patch \
> file://no-valgrind.patch \
> file://CVE-2016-1568.patch \
> file://CVE-2016-2197.patch \
> file://CVE-2016-2198.patch \
> file://pathlimit.patch \
>"
> SRC_URI_prepend = "
> http://wiki.qemu-project.org/download/${BP}.tar.bz2";
> SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
> SRC_URI[sha256sum] =
> "3443887401619fe33bfa5d900a4f2d6a79425ae2b7e43d5b8c36eb7a683772d4"
> 
>   uh ... yeah, i get that the above does the right thing but, come
> on,
> that just looks weird. is there a reason the qemu recipe deliberately
> goes out of its way to do this?

Its convention that the main source is at the top of SRC_URI. I
therefore don't really have an issue with what the qemu recipe does but
agree it could be cleaned up.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Sujith Haridasan]

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 
Signed-off-by: Christopher Larson 
Signed-off-by: Sujith Haridasan 
---
 .../recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
index 9b16147..67891a2 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
@@ -108,6 +108,8 @@ EXTRA_OECONF_class-target += "--enable-host-gi \
   ${@bb.utils.contains('GI_DATA_ENABLED', 'True', 
'--enable-introspection-data', '--disable-introspection-data', d)} \
  "
 
+PACKAGECONFIG ?= ""
+PACKAGECONFIG[doctool] = "--enable-doctool,--disable-doctool,python-mako,"
 
 do_compile_prepend_class-target() {
 # This prevents g-ir-scanner from writing cache data to $HOME
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jussi Kukkonen]

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 
b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
index 98c3ae4..ff35b33 100644
--- a/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
+++ b/meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
file://matchbox-panel/mb-panel.h;endline=10;md5=0b7db28f4b6863fb853d0467e590019a
 \
 
file://applets/startup/startup.c;endline=22;md5=b0a64fbef3097d79f8264e6907a98f03"
 
-DEPENDS = "gnome-common gtk+ startup-notification dbus dbus-glib"
+DEPENDS = "gnome-common gtk+ startup-notification dbus dbus-glib 
dbus-glib-native"
 DEPENDS += " ${@bb.utils.contains("MACHINE_FEATURES", "acpi", "libacpi", 
"",d)}"
 DEPENDS += " ${@bb.utils.contains("MACHINE_FEATURES", "apm", "apmd", "",d)}"
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

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 obviously correct option of "build the packages
> inside OE" really is being written off for mysterious reasons, rpm4
> was only just removed from oe-core (though depending on what
> releases you're using you may have never noticed it be added and
> removed again).  So you could just recover that from history
> (oe-core a6e7a86f1635be9a688c56c25e9d215ea4d2cc84 removed it) and
> fix it up.

  just to be clear, if i can dredge up the recipe for rpm_4, i'm
assuming i'd want to specify that i want the "package-management"
image feature, as well as stating:

PREFERRED_VERSION_rpm = "4.%"
PREFERRED_VERSION_rpm-native = "4.%"

correct?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jussi Kukkonen]

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 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
index 9b16147..aaca818 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
@@ -29,7 +29,7 @@ export STAGING_LIBDIR
 export STAGING_DIR_HOST
 export B
 
-DEPENDS_append = " libffi zlib glib-2.0 python"
+DEPENDS_append = " libffi zlib glib-2.0 python flex-native bison-native"
 
 # target build needs qemu to run temporary introspection binaries created
 # on the fly by g-ir-scanner and a native version of itself to run
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jussi Kukkonen]

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 available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jku/build-fixes
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/build-fixes

Jussi Kukkonen (3):
  gobject-introspection: Depend on native flex and bison
  connman-gnome: Depend on dbus-glib-native
  matchbox-panel-2: Depend on dbus-glib-native

 meta/recipes-connectivity/connman/connman-gnome_0.7.bb  | 2 +-
 .../recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb | 2 +-
 meta/recipes-sato/matchbox-panel-2/matchbox-panel-2_git.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jussi Kukkonen]

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 
b/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
index 7b875f0..3521c7f 100644
--- a/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
+++ b/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=eb723b61539feef013de476e68b5c50a \
 
file://properties/main.c;beginline=1;endline=20;md5=50c77c81871308b033ab7a1504626afb
 \
 
file://common/connman-dbus.c;beginline=1;endline=20;md5=de6b485c0e717a0236402d220187717a"
 
-DEPENDS = "gtk+ dbus-glib intltool-native gettext-native"
+DEPENDS = "gtk+ dbus-glib dbus-glib-native intltool-native gettext-native"
 
 # 0.7 tag
 SRCREV = "cf3c325b23dae843c5499a113591cfbc98acb143"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Joshua G Lock]

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 packages?", which is not a path down which i want
> > to walk.
> > 
> > 
> > Assuming that the obviously correct option of "build the packages
> > inside OE" really is being written off for mysterious reasons, rpm4
> > was only just removed from oe-core (though depending on what
> > releases you're using you may have never noticed it be added and
> > removed again).  So you could just recover that from history
> > (oe-core a6e7a86f1635be9a688c56c25e9d215ea4d2cc84 removed it) and
> > fix it up.
>   under the circumstances, that sounds like the simplest approach.
> would we be losing any significant functionality downgrading to rpm4?
> it's not my first choice, but if all that's required is to do basic
> installs and upgrades, i suspect it will work just fine.

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, but I do caution
against people just using it "because".  The RPM 5 version is generally
better suited for the embedded world.  (There are been posts on more
reasons on the oe-core lists in the past.  But as quick summary --
dynamic architecture support, better cross compilation support, cross-
endian support, more configurable for custom distributions, etc.)"
http://article.gmane.org/gmane.linux.embedded.yocto.general/28654/

We ended up removing RPM4 support because it was clear that it was
broken when using SMART as a package manager and we didn't have the
resources to fix it, nor any objections to its removal.

Some recent examples of the kinds of breakage:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8968
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8969

Regards,

Joshua
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Sujith Haridasan]

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 
Signed-off-by: Christopher Larson 
Signed-off-by: Sujith Haridasan 
---
 .../recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
index 9b16147..67891a2 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
@@ -108,6 +108,8 @@ EXTRA_OECONF_class-target += "--enable-host-gi \
   ${@bb.utils.contains('GI_DATA_ENABLED', 'True', 
'--enable-introspection-data', '--disable-introspection-data', d)} \
  "
 
+PACKAGECONFIG ?= ""
+PACKAGECONFIG[doctool] = "--enable-doctool,--disable-doctool,python-mako,"
 
 do_compile_prepend_class-target() {
 # This prevents g-ir-scanner from writing cache data to $HOME
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

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 obviously correct option of "build the packages
> inside OE" really is being written off for mysterious reasons, rpm4
> was only just removed from oe-core (though depending on what
> releases you're using you may have never noticed it be added and
> removed again).  So you could just recover that from history
> (oe-core a6e7a86f1635be9a688c56c25e9d215ea4d2cc84 removed it) and
> fix it up.

  under the circumstances, that sounds like the simplest approach.
would we be losing any significant functionality downgrading to rpm4?
it's not my first choice, but if all that's required is to do basic
installs and upgrades, i suspect it will work just fine.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Burton, Ross]

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" really is being written off for mysterious reasons, rpm4 was only just
removed from oe-core (though depending on what releases you're using you
may have never noticed it be added and removed again).  So you could just
recover that from history (oe-core a6e7a86f1635be9a688c56c25e9d215ea4d2cc84
removed it) and fix it up.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

  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 play well with a system built with current OE/YP.
so ... what to do?

  first, current muttering is, "grr ... why did OE migrate to
rpm5?" i actually didn't really know the answer to that, so i poked
around and found this:

  http://rpm5.org/community/rpm-users/0998.html

the mention of "more flexibility in cross compilation and control"
makes perfect sense to me, but is there a more comprehensive writeup
somewhere that lays out the rationale for the move to rpm5 that can be
used in its defense?

  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.

  another option is to simply install a totally independent rpm5 on
the centos 6 box, and use that exclusively for building packages to be
installed on an OE system. has anyone done this? does it represent a
sane/reasonable approach?

  finally, my reaction to all of this is, "why not just write recipes
for all that software so it can be built by OE?" but, as explained to
me, the OE package build system is *heavily* tied to a much larger
internal build process that resides on the centos 6 box, and there is
a real reluctance to try to extract the OE component from the larger
build process. the phrase that seems to pop up is, "not a chance in
hell."

  so ... thoughts? short of ripping out that part of the build process
and properly adding it as additional recipes to the OE build, is it
possible to build and install rpm5 on a centos 6 box? as a test, i can
try it for my fedora 23 system and, if that works, at least i can
demonstrate proof-of-concept.

  anyone done this? if it's possible, it would seem to be the simplest
solution under the circumstances.

rday

p.s. does adding the smart package manager into all of this make any
difference? i'm pretty familiar with RPM packaging, but have barely
looked at smart, and i don't know whether it would have any relevance
to this issue.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

  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:

  SRC_URI += " \
derp.scc \
gorp.scc \
...
  "

then regardless of how FILESOVERRIDES adjusts the search order in the
eventual FILESPATH, those items *must* be found somewhere, correct?
(this seems pretty obvious to me, but i've been burned by obvious
things before.)

  next, i realize there are two forms of appending to SRC_URI:

 * SRC_URI +=
 * SRC_URI_append =

first, is there an aesthetic preference for one over the other if the
end result is the same? (just curious about what people here prefer to
use.)

  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 until the final stage of processing. so what this tells
me is that all of the items you list in SRC_URI should *not* be
order-dependent, is that a fair statement? or, IOW, if your layer
depends on the items in SRC_URI being processed in a specific order,
you probably need to rework your recipe file.

  (side note: i do realize that, in a single .scc file, the patches
listed will be applied in precisely that order, but that's a different
issue and not relevant here.)

  next, if there are truly conditional SRC_URI items, the only way to
identify those is:

  SRC_URI_append_ = " ... blah blah ..."

you can't do this, can you?

  SRC_URI_ += " more stuff "

i don't think i've ever seen an example of the latter, but maybe i
just didn't look closely enough.

  and, finally, given that you can have a combination of SRC_URI
assignments and appends in the same .bbappend file:

  SRC_URI += "..."
  SRC_URI_append = "..."
  SRC_URI_append_ = "..."

that tells me that you *really* don't want any of that to be
order-dependent, as i mentioned before.

  is that about it? am i missing anything about SRC_URI definition and
processing? thanks muchly.

rday

p.s.  oh, wait, two more curiosities. first, i still see the
occasional example of this in numerous layers, including oe-core:

meta/recipes-support/attr/attr_2.4.47.bb:
SRC_URI_append += "file://attr-Missing-configure.ac.patch \
^

pretty sure combining "SRC_URI_append" with "+=" is just as redundant
as ever, no? :-)

  also, if the list of items in SRC_URI should be order-independent,
then it would seem to make little sense to specifically use:

  SRC_URI_prepend = "..."

anywhere, right? IOW, there should be no situation in which
specifically *prepending* to SRC_URI is necessary. but i found one
example in oe-core:

  meta/recipes-devtools/qemu/qemu_2.5.0.bb:

SRC_URI += "file://configure-fix-Darwin-target-detection.patch \
file://qemu-enlarge-env-entry-size.patch \
file://Qemu-Arm-versatilepb-Add-memory-size-checking.patch \
file://no-valgrind.patch \
file://CVE-2016-1568.patch \
file://CVE-2016-2197.patch \
file://CVE-2016-2198.patch \
file://pathlimit.patch \
   "
SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
SRC_URI[sha256sum] = 
"3443887401619fe33bfa5d900a4f2d6a79425ae2b7e43d5b8c36eb7a683772d4"

  uh ... yeah, i get that the above does the right thing but, come on,
that just looks weird. is there a reason the qemu recipe deliberately
goes out of its way to do this?

  ok, back to work ...

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Markus Lehtonen]

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. This patch
fixes that by creating the directory hierarchy inside
write_deploy_manifest().

[YOCTO #9446]

Signed-off-by: Markus Lehtonen 
---
 meta/classes/license.bbclass | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 43944e6..69335d6 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -181,8 +181,10 @@ def license_deployed_manifest(d):
 key,val = line.split(": ", 1)
 man_dic[dep][key] = val[:-1]
 
-image_license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY', True),
-d.getVar('IMAGE_NAME', True), 'image_license.manifest')
+lic_manifest_dir = os.path.join(d.getVar('LICENSE_DIRECTORY', True),
+d.getVar('IMAGE_NAME', True))
+bb.utils.mkdirhier(lic_manifest_dir)
+image_license_manifest = os.path.join(lic_manifest_dir, 
'image_license.manifest')
 write_license_files(d, image_license_manifest, man_dic)
 
 def get_deployed_dependencies(d):
-- 
2.6.6

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jose Alarcon]

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 
---
 meta/classes/rootfs-check-recommends.bbclass | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 meta/classes/rootfs-check-recommends.bbclass

diff --git a/meta/classes/rootfs-check-recommends.bbclass 
b/meta/classes/rootfs-check-recommends.bbclass
new file mode 100644
index 000..351e438
--- /dev/null
+++ b/meta/classes/rootfs-check-recommends.bbclass
@@ -0,0 +1,21 @@
+#
+# This bbclass adds an extra check to surface any unsatisfied
+# recommendation (RRECOMMENDS) as WARNINGS to the build output.
+#
+# To enable, use INHERIT in conf/distro/distro.conf:
+#
+#   INHERIT += "rootfs-check-recommends"
+#
+
+python log_check_recommends() {
+log_path = d.expand("${T}/log.do_rootfs")
+with open(log_path, 'r') as log:
+for line in log:
+if 'log_check' in line:
+continue
+
+if 'unsatisfied recommendation for' in line:
+bb.warn('[log_check] %s: %s' % (d.getVar('PN', True), line))
+}
+
+do_rootfs[postfuncs] += "log_check_recommends "
-- 
2.4.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Yannick GICQUEL]

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 related environment variables, and
a basic prepend to do_install task which performs the concatenation of the
u-boot-nodtb.bin and the device tree blob. The 'cat' command used
overrides the u-boot.bin in both DEPLOYDIR & build dir to propagate the
changes in later tasks (do_install, do_package, etc.)

Signed-off-by: Yannick Gicquel 
---
  meta/classes/uboot-sign.bbclass| 59 ++
  meta/recipes-bsp/u-boot/u-boot.inc |  2 +-
  2 files changed, 60 insertions(+), 1 deletion(-)
  create mode 100644 meta/classes/uboot-sign.bbclass

diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
new file mode 100644
index 000..63a5181
--- /dev/null
+++ b/meta/classes/uboot-sign.bbclass
@@ -0,0 +1,59 @@
+# This file is part of U-Boot verified boot support and is intended to be
+# inherited from u-boot recipe and from kernel-fitimage.bbclass.
+#
+# The signature procedure requires the user to generate an RSA key and
+# certificate in a directory and to define the following variable:
+#
+#   UBOOT_SIGN_KEYDIR = "/keys/directory"
+#   UBOOT_SIGN_KEYNAME = "dev" # keys name in keydir (eg. "dev.crt", "dev.key")
+#   UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
+#   UBOOT_SIGN_ENABLE = "1"
+#
+# As verified boot depends on fitImage generation, following is also required:
+#
+#   KERNEL_CLASSES ?= " kernel-fitimage "
+#   KERNEL_IMAGETYPE ?= "fitImage"
+#
+# The signature support is limited to the use of CONFIG_OF_SEPARATE in U-Boot.
+#
+# The tasks sequence is as below, using DEPLOY_IMAGE_DIR as common place to
+# treat the device tree blob:
+#
+# u-boot:do_deploy -> virtual/kernel:do_assemble_fitimage -> u-boot:do_install
+#
+# For more details on signature process, please refer to U-boot documentation.
+
+# Signature activation.
+UBOOT_SIGN_ENABLE ?= "0"
+
+# Default value for deployment filenames.
+UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb"
+UBOOT_DTB_BINARY ?= "u-boot.dtb"
+UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb"
+UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
+UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}"
+UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}"
+
+#
+# Following is relevant only for u-boot recipes:
+#
+
+do_install_prepend_pn-u-boot () {

Why _pn-u-boot here? What if I have my own version of u-boot recipe?

Oh good point, maybe this should be class-target instead of pn-u-boot
(here and elsewhere) ?



Hi Tom, Denys, all,

I initially though that any custom u-boot recipes declares a 'PROVIDE += 
"u-boot"' and the bitbake "_pn-" syntax will append functions to u-boot 
recipes only. Unfortunately, i just checked and confirmed the appends 
functions are not called anymore when the u-boot recipe is not named 
"u-boot".
Using "class-target" is an interesting idea, but it looks like the 
kernel recipe is also part of this class (at least on my setup), thus it 
may not be reliable enough.


What about using the "PREFERRED_PROVIDER_u-boot" variable instead of 
static 'u-boot' string in the relevant places ?
A "do_install_prepend_pn-${PREFERRED_PROVIDER_u-boot}" is not valid, but 
it can be performed by adding tasks in the python function at EOF.


Something like:

-do_deploy_append_pn-u-boot () {
+do_before_uboot_deploy () {

[snip]

python() {
  if d.getVar('PN', True) == d.getVar('PREFERRED_PROVIDER_u-boot', True):
 bb.build.addtask('do_before_uboot_deploy', None, 'do_deploy', d)
}

Off course, it requires few changes in other places, but I hope you'll 
see the idea ? What do you think ?


Best regards,
Yannick
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Ioan-Adrian Ratiu]

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 a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index 8440581..ed59d85 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -60,7 +60,7 @@ class IsoImagePlugin(SourcePlugin):
 """
 Create loader-specific (syslinux) config
 """
-splash = os.path.join(cr_workdir, "/ISO/boot/splash.jpg")
+splash = os.path.join(cr_workdir, "ISO/boot/splash.jpg")
 if os.path.exists(splash):
 splashline = "menu background splash.jpg"
 else:
@@ -105,7 +105,7 @@ class IsoImagePlugin(SourcePlugin):
 msger.error("configfile is specified but failed to "
 "get it from %s." % configfile)
 else:
-splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")
+splash = os.path.join(cr_workdir, "EFI/boot/splash.jpg")
 if os.path.exists(splash):
 splashline = "menu background splash.jpg"
 else:
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Ioan-Adrian Ratiu]

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 wks, it generates a default cfg as before.

Signed-off-by: Ioan-Adrian Ratiu 
---
 .../lib/wic/plugins/source/isoimage-isohybrid.py   | 53 +-
 1 file changed, 32 insertions(+), 21 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index bc99283..8440581 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -27,6 +27,7 @@ import glob
 
 from wic import msger
 from wic.pluginbase import SourcePlugin
+from wic.utils.misc import get_custom_config
 from wic.utils.oe.misc import exec_cmd, exec_native_cmd, get_bitbake_var
 
 class IsoImagePlugin(SourcePlugin):
@@ -94,33 +95,43 @@ class IsoImagePlugin(SourcePlugin):
 """
 Create loader-specific (grub-efi) config
 """
-splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")
-if os.path.exists(splash):
-splashline = "menu background splash.jpg"
+configfile = creator.ks.bootloader.configfile
+if configfile:
+grubefi_conf = get_custom_config(configfile)
+if grubefi_conf:
+msger.debug("Using custom configuration file "
+"%s for grub.cfg" % configfile)
+else:
+msger.error("configfile is specified but failed to "
+"get it from %s." % configfile)
 else:
-splashline = ""
+splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")
+if os.path.exists(splash):
+splashline = "menu background splash.jpg"
+else:
+splashline = ""
 
-bootloader = creator.ks.bootloader
+bootloader = creator.ks.bootloader
 
-grubefi_conf = ""
-grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
-grubefi_conf += "--parity=no --stop=1\n"
-grubefi_conf += "default=boot\n"
-grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
-grubefi_conf += "\n"
-grubefi_conf += "search --set=root --label %s " % part.label
-grubefi_conf += "\n"
-grubefi_conf += "menuentry 'boot'{\n"
+grubefi_conf = ""
+grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
+grubefi_conf += "--parity=no --stop=1\n"
+grubefi_conf += "default=boot\n"
+grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
+grubefi_conf += "\n"
+grubefi_conf += "search --set=root --label %s " % part.label
+grubefi_conf += "\n"
+grubefi_conf += "menuentry 'boot'{\n"
 
-kernel = "/bzImage"
+kernel = "/bzImage"
 
-grubefi_conf += "linux %s rootwait %s\n" \
-% (kernel, bootloader.append)
-grubefi_conf += "initrd /initrd \n"
-grubefi_conf += "}\n"
+grubefi_conf += "linux %s rootwait %s\n" \
+% (kernel, bootloader.append)
+grubefi_conf += "initrd /initrd \n"
+grubefi_conf += "}\n"
 
-if splashline:
-grubefi_conf += "%s\n" % splashline
+if splashline:
+grubefi_conf += "%s\n" % splashline
 
 msger.debug("Writing grubefi config %s/EFI/BOOT/grub.cfg" \
 % cr_workdir)
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Alexander D. Kanevskiy]

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(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 8bfd241..5d6f4a3 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -398,9 +398,13 @@ python () {
 # Create input image first.
 gen_conversion_cmds(type)
 localdata.setVar('type', type)
-cmds.append("\t" + localdata.getVar("COMPRESS_CMD_" + 
ctype, True))
+cmd = "\t" + localdata.getVar("COMPRESS_CMD_" + ctype, 
True)
+if cmd not in cmds:
+cmds.append(cmd)
 vardeps.add('COMPRESS_CMD_' + ctype)
-subimages.append(type + "." + ctype)
+subimage = type + "." + ctype
+if subimage not in subimages:
+subimages.append(subimage)
 if type not in alltypes:
 
rm_tmp_images.add(localdata.expand("${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"))
 
-- 
2.8.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Ioan-Adrian Ratiu]

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:
> >   
> > > 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 wks, it generates a default cfg as before.
> > > 
> > > Signed-off-by: Ioan-Adrian Ratiu 
> > > ---
> > >  .../lib/wic/plugins/source/isoimage-isohybrid.py   | 53 
> > > +-
> > >  1 file changed, 32 insertions(+), 21 deletions(-)
> > > 
> > > diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
> > > b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > > index bc99283..8440581 100644
> > > --- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > > +++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > > @@ -27,6 +27,7 @@ import glob
> > >  
> > >  from wic import msger
> > >  from wic.pluginbase import SourcePlugin
> > > +from wic.utils.misc import get_custom_config
> > >  from wic.utils.oe.misc import exec_cmd, exec_native_cmd, get_bitbake_var
> > >  
> > >  class IsoImagePlugin(SourcePlugin):
> > > @@ -94,33 +95,43 @@ class IsoImagePlugin(SourcePlugin):
> > >  """
> > >  Create loader-specific (grub-efi) config
> > >  """
> > > -splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")
> > > -if os.path.exists(splash):
> > > -splashline = "menu background splash.jpg"
> > > +configfile = creator.ks.bootloader.configfile
> > > +if configfile:
> > > +grubefi_conf = get_custom_config(configfile)
> > > +if grubefi_conf:
> > > +msger.debug("Using custom configuration file "
> > > +"%s for grub.cfg" % configfile)
> > > +else:
> > > +msger.error("configfile is specified but failed to "
> > > +"get it from %s." % configfile)
> > >  else:
> > > -splashline = ""
> > > +splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")  
> I know, it's not your code, but it looks like the result path(splash
> variable) will not include workdir. Look:
> 
> In [2]: os.path.join('/path/to/workdir', '/EFI/boot/splash.jpg')
> Out[2]: '/EFI/boot/splash.jpg'
> 
> In [3]: os.path.join('/path/to/workdir/', '/EFI/boot/splash.jpg')
> Out[3]: '/EFI/boot/splash.jpg'
> 
> It works this way:
> In [4]: os.path.join('/path/to/workdir/', 'EFI/boot/splash.jpg')
> Out[4]: '/path/to/workdir/EFI/boot/splash.jpg'
> 

Thanks for spotting this. I'll send another patch to fix it.

Ioan

> > > +if os.path.exists(splash):
> > > +splashline = "menu background splash.jpg"
> > > +else:
> > > +splashline = ""
> > >  
> > > -bootloader = creator.ks.bootloader
> > > +bootloader = creator.ks.bootloader
> > >  
> > > -grubefi_conf = ""
> > > -grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
> > > -grubefi_conf += "--parity=no --stop=1\n"
> > > -grubefi_conf += "default=boot\n"
> > > -grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
> > > -grubefi_conf += "\n"
> > > -grubefi_conf += "search --set=root --label %s " % part.label
> > > -grubefi_conf += "\n"
> > > -grubefi_conf += "menuentry 'boot'{\n"
> > > +grubefi_conf = ""
> > > +grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
> > > +grubefi_conf += "--parity=no --stop=1\n"
> > > +grubefi_conf += "default=boot\n"
> > > +grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
> > > +grubefi_conf += "\n"
> > > +grubefi_conf += "search --set=root --label %s " % part.label
> > > +grubefi_conf += "\n"
> > > +grubefi_conf += "menuentry 'boot'{\n"
> > >  
> > > -kernel = "/bzImage"
> > > +kernel = "/bzImage"
> > >  
> > > -grubefi_conf += "linux %s rootwait %s\n" \
> > > -% (kernel, bootloader.append)
> > > -grubefi_conf += "initrd /initrd \n"
> > > -grubefi_conf += "}\n"
> > > +grubefi_conf += "linux %s rootwait %s\n" \
> > > +% (kernel, bootloader.append)
> > > +grubefi_conf += "initrd /initrd \n"
> > > +grubefi_conf += "}\n"
> > >  
> > > -if splashline:
> > > -grubefi_conf += "%s\n" % splashline
> > > +if splashline:
> > > +grubefi_conf += "%s\n" % splashline
> > >  
> > >  msger.debug("Writing grubefi config %s/EFI/BOO

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

[Maxin B. John]

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:
  Running groupadd commands...
  NOTE: cronie: Performing groupadd with [ --system crontab]
  ERROR: cronie: groupadd command did not succeed.
  error: %pre(cronie-1.5.0-r0.core2_64) scriptlet failed, exit status 1
  error:   install: %pre scriptlet failed (2), skipping
  cronie-1.5.0-r0.core2_64

This is because we use flock command in preinstall scripts in packages
which create new groups/users.

[YOCTO #9496]

Signed-off-by: Maxin B. John 
---
 ...e-the-behaviour-of-c-parameter-to-match-u.patch | 73 ++
 meta/recipes-core/busybox/busybox_1.24.1.bb|  1 +
 2 files changed, 74 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch

diff --git 
a/meta/recipes-core/busybox/busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch
 
b/meta/recipes-core/busybox/busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch
new file mode 100644
index 000..8bcbd73
--- /dev/null
+++ 
b/meta/recipes-core/busybox/busybox/0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch
@@ -0,0 +1,73 @@
+From 198f18addf1d814c2fefcb492f3b9fbd221669bb Mon Sep 17 00:00:00 2001
+From: "Maxin B. John" 
+Date: Wed, 20 Apr 2016 18:24:45 +0300
+Subject: [PATCH] flock: update the behaviour of -c parameter to match upstream
+
+In upstream, -c 'PROG ARGS' means "run sh -c 'PROG ARGS'"
+
+function old new   delta
+flock_main   286 377 +91
+.rodata   155849  155890 +41
+
+Upstream-Status: Submitted
+[ http://lists.busybox.net/pipermail/busybox/2016-April/084142.html ]
+
+Signed-off-by: Maxin B. John 
+---
+ util-linux/flock.c | 20 ++--
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+diff --git a/util-linux/flock.c b/util-linux/flock.c
+index 05a747f..c85a25d 100644
+--- a/util-linux/flock.c
 b/util-linux/flock.c
+@@ -20,6 +20,7 @@ int flock_main(int argc, char **argv) 
MAIN_EXTERNALLY_VISIBLE;
+ int flock_main(int argc UNUSED_PARAM, char **argv)
+ {
+   int mode, opt, fd;
++char *cmd_args[4];
+   enum {
+   OPT_s = (1 << 0),
+   OPT_x = (1 << 1),
+@@ -57,7 +58,6 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
+   /* If it is "flock FILE -c PROG", then -c isn't caught by getopt32:
+* we use "+" in order to support "flock -opt FILE PROG -with-opts",
+* we need to remove -c by hand.
+-   * TODO: in upstream, -c 'PROG ARGS' means "run sh -c 'PROG ARGS'"
+*/
+   if (argv[0]
+&& argv[0][0] == '-'
+@@ -65,7 +65,10 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
+   || (ENABLE_LONG_OPTS && strcmp(argv[0] + 1, "-command") == 0)
+   )
+   ) {
+-  argv++;
++if (argc != optind + 3)
++bb_error_msg_and_die("-c requires exactly one command argument");
++else
++argv++;
+   }
+ 
+   if (OPT_s == LOCK_SH && OPT_x == LOCK_EX && OPT_n == LOCK_NB && OPT_u 
== LOCK_UN) {
+@@ -89,9 +92,14 @@ int flock_main(int argc UNUSED_PARAM, char **argv)
+   return EXIT_FAILURE;
+   bb_perror_nomsg_and_die();
+   }
+-
+-  if (argv[0])
+-  return spawn_and_wait(argv);
+-
++if (argv[0]) {
++cmd_args[0] = getenv("SHELL");
++if (!cmd_args[0])
++cmd_args[0] = (char*)DEFAULT_SHELL;
++cmd_args[1] = (char*)"-c";
++cmd_args[2] = argv[0];
++cmd_args[3] = NULL;
++return spawn_and_wait(cmd_args);
++}
+   return EXIT_SUCCESS;
+ }
+-- 
+2.4.0
+
diff --git a/meta/recipes-core/busybox/busybox_1.24.1.bb 
b/meta/recipes-core/busybox/busybox_1.24.1.bb
index bdaa5a5..f699f99 100644
--- a/meta/recipes-core/busybox/busybox_1.24.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.24.1.bb
@@ -32,6 +32,7 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-1.24.1-unzip.patch \
file://busybox-1.24.1-unzip-regression.patch \
file://busybox-1.24.1-truncate-open-mode.patch \
+   
file://0001-flock-update-the-behaviour-of-c-parameter-to-match-u.patch \
file://mount-via-label.cfg \
file://sha1sum.cfg \
file://sha256sum.cfg \
-- 
2.4.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Ed Bartosh]

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 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 wks, it generates a default cfg as before.
> > 
> > Signed-off-by: Ioan-Adrian Ratiu 
> > ---
> >  .../lib/wic/plugins/source/isoimage-isohybrid.py   | 53 
> > +-
> >  1 file changed, 32 insertions(+), 21 deletions(-)
> > 
> > diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
> > b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > index bc99283..8440581 100644
> > --- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > +++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
> > @@ -27,6 +27,7 @@ import glob
> >  
> >  from wic import msger
> >  from wic.pluginbase import SourcePlugin
> > +from wic.utils.misc import get_custom_config
> >  from wic.utils.oe.misc import exec_cmd, exec_native_cmd, get_bitbake_var
> >  
> >  class IsoImagePlugin(SourcePlugin):
> > @@ -94,33 +95,43 @@ class IsoImagePlugin(SourcePlugin):
> >  """
> >  Create loader-specific (grub-efi) config
> >  """
> > -splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")
> > -if os.path.exists(splash):
> > -splashline = "menu background splash.jpg"
> > +configfile = creator.ks.bootloader.configfile
> > +if configfile:
> > +grubefi_conf = get_custom_config(configfile)
> > +if grubefi_conf:
> > +msger.debug("Using custom configuration file "
> > +"%s for grub.cfg" % configfile)
> > +else:
> > +msger.error("configfile is specified but failed to "
> > +"get it from %s." % configfile)
> >  else:
> > -splashline = ""
> > +splash = os.path.join(cr_workdir, "/EFI/boot/splash.jpg")
I know, it's not your code, but it looks like the result path(splash
variable) will not include workdir. Look:

In [2]: os.path.join('/path/to/workdir', '/EFI/boot/splash.jpg')
Out[2]: '/EFI/boot/splash.jpg'

In [3]: os.path.join('/path/to/workdir/', '/EFI/boot/splash.jpg')
Out[3]: '/EFI/boot/splash.jpg'

It works this way:
In [4]: os.path.join('/path/to/workdir/', 'EFI/boot/splash.jpg')
Out[4]: '/path/to/workdir/EFI/boot/splash.jpg'

> > +if os.path.exists(splash):
> > +splashline = "menu background splash.jpg"
> > +else:
> > +splashline = ""
> >  
> > -bootloader = creator.ks.bootloader
> > +bootloader = creator.ks.bootloader
> >  
> > -grubefi_conf = ""
> > -grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
> > -grubefi_conf += "--parity=no --stop=1\n"
> > -grubefi_conf += "default=boot\n"
> > -grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
> > -grubefi_conf += "\n"
> > -grubefi_conf += "search --set=root --label %s " % part.label
> > -grubefi_conf += "\n"
> > -grubefi_conf += "menuentry 'boot'{\n"
> > +grubefi_conf = ""
> > +grubefi_conf += "serial --unit=0 --speed=115200 --word=8 "
> > +grubefi_conf += "--parity=no --stop=1\n"
> > +grubefi_conf += "default=boot\n"
> > +grubefi_conf += "timeout=%s\n" % (bootloader.timeout or 10)
> > +grubefi_conf += "\n"
> > +grubefi_conf += "search --set=root --label %s " % part.label
> > +grubefi_conf += "\n"
> > +grubefi_conf += "menuentry 'boot'{\n"
> >  
> > -kernel = "/bzImage"
> > +kernel = "/bzImage"
> >  
> > -grubefi_conf += "linux %s rootwait %s\n" \
> > -% (kernel, bootloader.append)
> > -grubefi_conf += "initrd /initrd \n"
> > -grubefi_conf += "}\n"
> > +grubefi_conf += "linux %s rootwait %s\n" \
> > +% (kernel, bootloader.append)
> > +grubefi_conf += "initrd /initrd \n"
> > +grubefi_conf += "}\n"
> >  
> > -if splashline:
> > -grubefi_conf += "%s\n" % splashline
> > +if splashline:
> > +grubefi_conf += "%s\n" % splashline
> >  
> >  msger.debug("Writing grubefi config %s/EFI/BOOT/grub.cfg" \
> >  % cr_workdir)
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
--
Regards,
Ed
-- 
___
Openembedded-co

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

[Tudor Florea]

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 about the missing dependency
but the dependency have to be completely removed.
Since this package contains oly tests it is safe to disable per file
dependencies and rely on the ones per package.

Signed-off-by: Tudor Florea 
---
 meta/recipes-devtools/valgrind/valgrind_3.11.0.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/valgrind/valgrind_3.11.0.bb 
b/meta/recipes-devtools/valgrind/valgrind_3.11.0.bb
index 51c88bf..8240500 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.11.0.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.11.0.bb
@@ -68,9 +68,9 @@ RRECOMMENDS_${PN} += "${TCLIBC}-dbg"
 RDEPENDS_${PN}-ptest += " sed perl perl-module-file-glob"
 RDEPENDS_${PN}-ptest_append_libc-glibc = " glibc-utils"
 
-# One of the tests contains a bogus interpreter path on purpose, and QA
-# check complains about it
-INSANE_SKIP_${PN}-ptest += "file-rdeps"
+# One of the tests contains a bogus interpreter path on purpose.
+# Skip file dependency check
+SKIP_FILEDEPS_${PN}-ptest = '1'
 
 do_compile_ptest() {
 oe_runmake check
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] rpm generation question

[Tudor Florea]

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 accordingly).
 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
>>>
>>> You can turn off the file level requires and provides on a per package 
>>> basis.
>>>
>>> SKIP_FILEDEPS_${PN}-ptest = '1'
>>
>> Mark,
>> Thank you for the information provided.
>> Unfortunately this did not work as expected.
>> First issue: the dependency on bogus interpreter still exists with the
>> line above.
>> I was able to force remove this dependency by setting
>> MERGEPERFILEDEPS = "0"
>> on meta/classes/package_rpm.bbclass. Of course this is not a fix but
>> only a test. I'm not sure if there is something missing around.
>>
>> The second issue: The rpm created this way can be installed using the
>> command:
>> rpm -ivH ./valgrind-ptest-3.11.0-r0.4.ppce500mc.rpm
>> but still fails when attempt to install using smart.
>>
>> Is this second issue a bug or smart is supposed to work this way?
> 
> What is the error with smart.  If it's the same dependency error then it 
> almost
> sounds like the feed database is out of sync.
It was the same error. I have rebuild and retest everything from scratch
and now is working.
I'm going to send a patch for this.
Thank you very much.
 Tudor.
> 
> --Mark
> 
>>
>> Thank you,
>>  Tudor.
>>
>>>
>>> Otherwise (for rpm packages) the system will attempt to discover and use the
>>> per-file interpreter and other dependencies.  Since ptest is only tests, 
>>> and the
>>> dependencies here are specific to tests -- it should be safe to disable 
>>> them.
>>>
>>> (If that isn't the right approach for some reason, there are some other 
>>> ways to
>>> do a file level provide, but they're significantly more complicated and 
>>> rarely
>>> used.)
>>>
>>> --Mark
>>>

 smart install valgrind-ptest-3.11.0-r0.1@ppce500mc
 Loading cache...
 Updating cache...
 ###
 [100%]

 Computing transaction...

  error: Can't install valgrind-ptest-3.11.0-r0.1@ppce500mc: no package
 provides /this/is/a/bogus/interpreter/name


 This is most probably caused by the file shell_badinterp contained in
 this package having the following contents:

 #! /this/is/a/bogus/interpreter/name

 true

 Does anyone have an idea how to get rid of this error?
 More specific: How can I exclude dependency on
 "/this/is/a/bogus/interpreter/name" for an rpm package?

 Thank you very much.
   Tudor.

>>>
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Andreas Oberritter]

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 bitbake should try to detect this and error out.
> I confirm do_deploy is executed before do_install.
> It looks like it is schedule this way by the last line of the file:
> 
> addtask deploy before do_build after do_compile
> 
> (I attached the log.task_order for reference - FYI, behavior is the same on
> jethro or today's master branch)

You're right, Yannick. I should have looked at u-boot.inc, instead of
assuming the behaviour of kernel.bbclass was generic.

Regards,
Andreas

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Richard Purdie]

On Thu, 2016-04-21 at 15:22 +0800, Robert Yang wrote:
> There are several recipes in oe-core which has:
> PV = "0.0+git${SRCPV}"
> 
> These recipes don't have a release version, so we use
> "0.0+git${SRCPV}",
> but the package manager such 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 = "20160421". And when we upgrade them in the future, we can
> change
> the PV to that day. We can change all the current version 0.0 target
> recipes to today, and add a sanity check for version 0.0.

No, this is the whole idea behind having the PR Server which injects a
revision before the hash in SRCPV. We have the same problem with other
git recipes even where there are versions since the revision can change
and we need to be able to sort the versions correctly.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert Yang]

There are several recipes in oe-core which has:
PV = "0.0+git${SRCPV}"

These recipes don't have a release version, so we use "0.0+git${SRCPV}",
but the package manager such 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 = "20160421". And when we upgrade them in the future, we can change
the PV to that day. We can change all the current version 0.0 target
recipes to today, and add a sanity check for version 0.0.

--
Thanks

Robert
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core