[OE-core] ✗ patchtest: failure for Add foundation for riscv architecture

[Patchwork]

== Series Details ==

Series: Add foundation for riscv architecture
Revision: 1
URL   : https://patchwork.openembedded.org/series/9254/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-devtools/gcc/gcc-7.2/0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH 08/10] gcc-runtime: Disable libitm on riscv

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-runtime.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index ee08529a5f..d3d4bd36a8 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -20,6 +20,8 @@ RUNTIMELIBITM = "libitm"
 RUNTIMELIBITM_mipsarch = ""
 RUNTIMELIBITM_nios2 = ""
 RUNTIMELIBITM_microblaze = ""
+RUNTIMELIBITM_riscv32 = ""
+RUNTIMELIBITM_riscv64 = ""
 
 RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
 ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
'', d)} \
-- 
2.14.2

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

[OE-core] [PATCH 10/10] openssl: Add support for riscv32/riscv64

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-connectivity/openssl/openssl10.inc | 6 ++
 meta/recipes-connectivity/openssl/openssl_1.1.0f.bb | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/meta/recipes-connectivity/openssl/openssl10.inc 
b/meta/recipes-connectivity/openssl/openssl10.inc
index a710e9e25a..469775582b 100644
--- a/meta/recipes-connectivity/openssl/openssl10.inc
+++ b/meta/recipes-connectivity/openssl/openssl10.inc
@@ -135,6 +135,12 @@ do_configure () {
linux-powerpc64)
target=linux-ppc64
;;
+   linux-riscv64)
+   target=linux-generic64
+   ;;
+   linux-riscv32)
+   target=linux-generic32
+   ;;
linux-supersparc)
target=linux-sparcv8
;;
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
index 711a95985a..4517f8734a 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
@@ -95,6 +95,12 @@ do_configure () {
linux-powerpc64)
target=linux-ppc64
;;
+   linux-riscv64)
+   target=linux-generic64
+   ;;
+   linux-riscv32)
+   target=linux-generic32
+   ;;
linux-supersparc)
target=linux-sparcv9
;;
-- 
2.14.2

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

[OE-core] [PATCH 07/10] gcc: Backport fix for a segfault on riscv

[Khem Raj]

seen during kernel compile

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gcc/gcc-7.2.inc  |  1 +
 ...le-non-legitimate-address-in-riscv_legiti.patch | 50 ++
 2 files changed, 51 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-7.2/0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch

diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
b/meta/recipes-devtools/gcc/gcc-7.2.inc
index 796e6b1eef..5883bc61a6 100644
--- a/meta/recipes-devtools/gcc/gcc-7.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
@@ -74,6 +74,7 @@ SRC_URI = "\
file://0047-sync-gcc-stddef.h-with-musl.patch \
file://0048-gcc-Enable-static-PIE.patch \
file://fix-segmentation-fault-precompiled-hdr.patch \
+   
file://0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git 
a/meta/recipes-devtools/gcc/gcc-7.2/0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch
 
b/meta/recipes-devtools/gcc/gcc-7.2/0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch
new file mode 100644
index 00..fe175abecd
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-7.2/0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch
@@ -0,0 +1,50 @@
+From 16210e6270e200cd4892a90ecef608906be3a130 Mon Sep 17 00:00:00 2001
+From: Kito Cheng 
+Date: Thu, 4 May 2017 02:11:13 +0800
+Subject: [PATCH] RISC-V: Handle non-legitimate address in
+ riscv_legitimize_move
+
+GCC may generate non-legitimate address due to we allow some
+load/store with non-legitimate address in pic.md.
+
+  2017-05-12  Kito Cheng  
+
+  * config/riscv/riscv.c (riscv_legitimize_move): Handle
+  non-legitimate address.
+---
+Upstream-Status: Backport
+
+ gcc/ChangeLog|  5 +
+ gcc/config/riscv/riscv.c | 16 
+ 2 files changed, 21 insertions(+)
+
+diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
+index f7fec4bfcf8..d519be1659a 100644
+--- a/gcc/config/riscv/riscv.c
 b/gcc/config/riscv/riscv.c
+@@ -1385,6 +1385,22 @@ riscv_legitimize_move (enum machine_mode mode, rtx 
dest, rtx src)
+   return true;
+ }
+ 
++  /* RISC-V GCC may generate non-legitimate address due to we provide some
++ pattern for optimize access PIC local symbol and it's make GCC generate
++ unrecognizable instruction during optmizing.  */
++
++  if (MEM_P (dest) && !riscv_legitimate_address_p (mode, XEXP (dest, 0),
++ reload_completed))
++{
++  XEXP (dest, 0) = riscv_force_address (XEXP (dest, 0), mode);
++}
++
++  if (MEM_P (src) && !riscv_legitimate_address_p (mode, XEXP (src, 0),
++reload_completed))
++{
++  XEXP (src, 0) = riscv_force_address (XEXP (src, 0), mode);
++}
++
+   return false;
+ }
+ 
+-- 
+2.14.2
+
-- 
2.14.2

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

[OE-core] [PATCH 09/10] elfutils: Fix missing library on linker cmdline

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/elfutils/elfutils_0.170.bb   |  1 +
 ...0001-libasm-may-link-with-libbz2-if-found.patch | 39 ++
 2 files changed, 40 insertions(+)
 create mode 100644 
meta/recipes-devtools/elfutils/files/0001-libasm-may-link-with-libbz2-if-found.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.170.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.170.bb
index 8a339e48c9..3b81e287b0 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.170.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.170.bb
@@ -17,6 +17,7 @@ SRC_URI += "\
 file://0005-fix-a-stack-usage-warning.patch \
 file://0006-Fix-build-on-aarch64-musl.patch \
 file://0007-Fix-control-path-where-we-have-str-as-uninitialized-.patch 
\
+file://0001-libasm-may-link-with-libbz2-if-found.patch \
 "
 SRC_URI_append_libc-musl = " 
file://0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch"
 
diff --git 
a/meta/recipes-devtools/elfutils/files/0001-libasm-may-link-with-libbz2-if-found.patch
 
b/meta/recipes-devtools/elfutils/files/0001-libasm-may-link-with-libbz2-if-found.patch
new file mode 100644
index 00..fb0b060b4b
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/files/0001-libasm-may-link-with-libbz2-if-found.patch
@@ -0,0 +1,39 @@
+From 7672e363468271b4c63ff58770c5aac15ab8f722 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Wed, 4 Oct 2017 22:30:46 -0700
+Subject: [PATCH] libasm may link with libbz2 if found
+
+This can fail to link binaries like objdump
+where indirect libraries may be not found by linker
+
+| 
/mnt/a/oe/build/tmp/work/riscv64-bec-linux/elfutils/0.170-r0/recipe-sysroot/usr/lib/libbz2.so.1:
 error adding symbols: DSO missing from command line
+| collect2: error: ld returned 1 exit status
+
+Signed-off-by: Khem Raj 
+---
+Upstream-Status: Pending
+
+ src/Makefile.am | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index e03bc32..9b7e853 100644
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -39,11 +39,11 @@ EXTRA_DIST += make-debug-archive.in
+ CLEANFILES += make-debug-archive
+ 
+ if BUILD_STATIC
+-libasm = ../libasm/libasm.a
++libasm = ../libasm/libasm.a $(zip_LIBS)
+ libdw = ../libdw/libdw.a -lz $(zip_LIBS) $(libelf) $(libebl) -ldl
+ libelf = ../libelf/libelf.a -lz
+ else
+-libasm = ../libasm/libasm.so
++libasm = ../libasm/libasm.so $(zip_LIBS)
+ libdw = ../libdw/libdw.so $(zip_LIBS) $(libelf) $(libebl) -ldl
+ libelf = ../libelf/libelf.so
+ endif
+-- 
+2.14.2
+
-- 
2.14.2

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

[OE-core] [PATCH 06/10] binutils: Convert SRC_URI and SRCREV to weak defines

[Khem Raj]

This makes it easy to override them in bbappends

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/binutils/binutils-2.29.inc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils-2.29.inc 
b/meta/recipes-devtools/binutils/binutils-2.29.inc
index 27d46eb088..35f76cba6d 100644
--- a/meta/recipes-devtools/binutils/binutils-2.29.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.29.inc
@@ -18,9 +18,10 @@ BINUPV = "${@binutils_branch_version(d)}"
 
 UPSTREAM_CHECK_GITTAGREGEX = "binutils-(?P\d+_(\d_?)*)"
 
-SRCREV = "37e991bb143ca2106330bcdc625590d53838b7a1"
+SRCREV ?= "37e991bb143ca2106330bcdc625590d53838b7a1"
+BINUTILS_GIT_URI ?= 
"git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git"
 SRC_URI = "\
- 
git://sourceware.org/git/binutils-gdb.git;branch=binutils-${BINUPV}-branch;protocol=git
 \
+ ${BINUTILS_GIT_URI} \
  file://0003-configure-widen-the-regexp-for-SH-architectures.patch \
  file://0004-Point-scripts-location-to-libdir.patch \
  file://0005-Only-generate-an-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch \
-- 
2.14.2

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

[OE-core] [PATCH 01/10] site: Add riscv32 and riscv64

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/site/riscv32-linux | 4 
 meta/site/riscv64-linux | 4 
 2 files changed, 8 insertions(+)
 create mode 100644 meta/site/riscv32-linux
 create mode 100644 meta/site/riscv64-linux

diff --git a/meta/site/riscv32-linux b/meta/site/riscv32-linux
new file mode 100644
index 00..a496bd1aca
--- /dev/null
+++ b/meta/site/riscv32-linux
@@ -0,0 +1,4 @@
+# glib-2.0
+glib_cv_stack_grows=${glib_cv_stack_grows=no}
+glib_cv_uscore=${glib_cv_uscore=no}
+
diff --git a/meta/site/riscv64-linux b/meta/site/riscv64-linux
new file mode 100644
index 00..a496bd1aca
--- /dev/null
+++ b/meta/site/riscv64-linux
@@ -0,0 +1,4 @@
+# glib-2.0
+glib_cv_stack_grows=${glib_cv_stack_grows=no}
+glib_cv_uscore=${glib_cv_uscore=no}
+
-- 
2.14.2

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

[OE-core] [PATCH 03/10] siteinfo: Define data for riscv32 and riscv64

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/classes/siteinfo.bbclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index 1aada40695..29cd2aa82b 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -47,6 +47,8 @@ def siteinfo_data(d):
 "ppc": "endian-big bit-32 powerpc-common",
 "ppc64": "endian-big bit-64 powerpc-common",
 "ppc64le" : "endian-little bit-64 powerpc-common",
+"riscv32": "endian-little bit-32 riscv-common",
+"riscv64": "endian-little bit-64 riscv-common",
 "sh3": "endian-little bit-32 sh-common",
 "sh4": "endian-little bit-32 sh-common",
 "sparc": "endian-big bit-32",
@@ -95,6 +97,10 @@ def siteinfo_data(d):
 "powerpc64-linux-muslspe": "powerpc-linux powerpc64-linux",
 "powerpc64-linux": "powerpc-linux",
 "powerpc64-linux-musl": "powerpc-linux",
+"riscv32-linux": "riscv32-linux",
+"riscv32-linux-musl": "riscv32-linux",
+"riscv64-linux": "riscv64-linux",
+"riscv64-linux-musl": "riscv64-linux",
 "x86_64-cygwin": "bit-64",
 "x86_64-darwin": "bit-64",
 "x86_64-darwin9": "bit-64",
-- 
2.14.2

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

[OE-core] [PATCH 04/10] kernel-arch.bbclass: Add riscv to kernel arch map

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/classes/kernel-arch.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index d036fcf20c..cf0edb6173 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -14,7 +14,7 @@ valid_archs = "alpha cris ia64 \
parisc s390  v850 \
avr32 blackfin \
microblaze \
-   nios2 arc xtensa"
+   nios2 arc riscv xtensa"
 
 def map_kernel_arch(a, d):
 import re
@@ -26,6 +26,7 @@ def map_kernel_arch(a, d):
 elif re.match('aarch64$', a):   return 'arm64'
 elif re.match('aarch64_be$', a):return 'arm64'
 elif re.match('mips(isa|)(32|64|)(r6|)(el|)$', a):  return 'mips'
+elif re.match('riscv(32|64|)(eb|)$', a):return 'riscv'
 elif re.match('p(pc|owerpc)(|64)', a):  return 'powerpc'
 elif re.match('sh(3|4)$', a):   return 'sh'
 elif re.match('bfin', a):   return 'blackfin'
-- 
2.14.2

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

[OE-core] [PATCH 02/10] insane: Add entries for riscv 32bit/64bit

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/classes/insane.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 0a3b528ddb..def9c707a4 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -94,6 +94,8 @@ def package_qa_get_machine_dict(d):
 "mipsisa64r6":   ( 8,  0,0,  False,
 64),
 "mipsisa64r6el": ( 8,  0,0,  True, 
 64),
 "nios2":  (113,0,0,  True, 
 32),
+"riscv":  (243,0,0,  True, 
 32),
+"riscv64":(243,0,0,  True, 
 64),
 "s390":   (22, 0,0,  False,
 32),
 "sh4":(42, 0,0,  True, 
 32),
 "sparc":  ( 2, 0,0,  False,
 32),
@@ -119,6 +121,8 @@ def package_qa_get_machine_dict(d):
 "microblaze":  (189, 0,0,  False,  
   32),
 "microblazeeb":(189, 0,0,  False,  
   32),
 "microblazeel":(189, 0,0,  True,   
   32),
+"riscv":  (243,  0,0,  True,   
   32),
+"riscv64":(243,  0,0,  True,   
   64),
 "sh4":(  42, 0,0,  True,   
   32),
   },
 "uclinux-uclibc" : {
-- 
2.14.2

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

[OE-core] [PATCH 00/10] Add foundation for riscv architecture

[Khem Raj]

riscv is new cool kid in town. This pull request enables
base infrastructure to support riscv32 and riscv64 profiles
full architecture and qemu port is in meta-riscv
https://github.com/kraj/meta-riscv

These changes are being rapidly upstreamed, eventually we
might have a very thin layer

The following changes since commit abf2e9526a11bcb51b71b90a7b76bd33af656494:

  systemd-serialtty: allow empty package (2017-09-26 11:07:36 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib kraj/riscv
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=kraj/riscv

Khem Raj (10):
  site: Add riscv32 and riscv64
  insane: Add entries for riscv 32bit/64bit
  siteinfo: Define data for riscv32 and riscv64
  kernel-arch.bbclass: Add riscv to kernel arch map
  runqemu: Add riscv support for qemu machines
  binutils: Convert SRC_URI and SRCREV to weak defines
  gcc: Backport fix for a segfault on riscv
  gcc-runtime: Disable libitm on riscv
  elfutils: Fix missing library on linker cmdline
  openssl: Add support for riscv32/riscv64

 meta/classes/insane.bbclass|  4 ++
 meta/classes/kernel-arch.bbclass   |  3 +-
 meta/classes/siteinfo.bbclass  |  6 +++
 meta/recipes-connectivity/openssl/openssl10.inc|  6 +++
 .../recipes-connectivity/openssl/openssl_1.1.0f.bb |  6 +++
 meta/recipes-devtools/binutils/binutils-2.29.inc   |  5 ++-
 meta/recipes-devtools/elfutils/elfutils_0.170.bb   |  1 +
 ...0001-libasm-may-link-with-libbz2-if-found.patch | 39 +
 meta/recipes-devtools/gcc/gcc-7.2.inc  |  1 +
 ...le-non-legitimate-address-in-riscv_legiti.patch | 50 ++
 meta/recipes-devtools/gcc/gcc-runtime.inc  |  2 +
 meta/site/riscv32-linux|  4 ++
 meta/site/riscv64-linux|  4 ++
 scripts/runqemu|  4 ++
 14 files changed, 132 insertions(+), 3 deletions(-)
 create mode 100644 
meta/recipes-devtools/elfutils/files/0001-libasm-may-link-with-libbz2-if-found.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc-7.2/0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch
 create mode 100644 meta/site/riscv32-linux
 create mode 100644 meta/site/riscv64-linux

-- 
2.14.2

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

[OE-core] [PATCH 05/10] runqemu: Add riscv support for qemu machines

[Khem Raj]

Signed-off-by: Khem Raj 
---
 scripts/runqemu | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/runqemu b/scripts/runqemu
index df76270904..9dc6a05c57 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1077,6 +1077,10 @@ class BaseConfig(object):
 qbsys = 'mipsel'
 elif mach == 'qemumips64el':
 qbsys = 'mips64el'
+elif mach == 'qemuriscv64':
+qbsys = 'riscv64'
+elif mach == 'qemuriscv32':
+qbsys = 'riscv32'
 
 return 'qemu-system-%s' % qbsys
 
-- 
2.14.2

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

[OE-core] [PATCH] bash-ptest: install additional locales

[Juro Bystricky]

bash-ptest fails several tests. This patch fixes:

FAIL: run-intl

The test used to fail because of missing locales (fr_FR, de_DE)

[YOCTO #12145]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-extended/bash/bash.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/bash/bash.inc 
b/meta/recipes-extended/bash/bash.inc
index f6cb7e4..f5338c8 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -24,6 +24,8 @@ ALTERNATIVE_PRIORITY = "100"
 RDEPENDS_${PN} += "base-files"
 RDEPENDS_${PN}_class-nativesdk = ""
 RDEPENDS_${PN}-ptest += "make"
+RDEPENDS_${PN}-ptest_append_libc-glibc += " locale-base-fr-fr 
locale-base-de-de"
+DEPENDS_ptest_append_libc-glibc += " locale-base-fr-fr locale-base-de-de"
 
 USERADD_PACKAGES = "${PN}-ptest"
 USERADD_PARAM_${PN}-ptest = "--create-home --user-group test"
-- 
2.7.4

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

Re: [OE-core] Recipe versions and layer confusion

[Andre McCurdy]

On Thu, Oct 5, 2017 at 2:44 PM, Leonardo Sandoval
 wrote:
> On Thu, 5 Oct 2017 10:19:18 -0500
> Leonardo Sandoval  wrote:
>
>> On Thu, 5 Oct 2017 16:49:28 +0200
>> Mike Looijmans  wrote:
>>
>> > I'm confused.
>> >
>> > Layer "meta-xilinx" defines:
>> >
>> > recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb
>> >
>> > This recipe is too old for my liking, so I made a newer one in "meta-topic"
>> >
>> > recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb
>> >
>> >
>> > Much to my surprise, when I build, OE picks the 2017.1 version and not the
>> > 2017.3 version.
>> >
>> > bitbake-layers show-layers reveils:
>> > ..
>> > meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
>> > meta-topic/home/mike/projects/zynq-platform/meta-topic  6
>> > ..
>> >
>> > so that means that my meta-topic should win even if my PV were lower, 
>> > right?

Yes. The comments in bitbake/lib/bb/providers.py -> findBestProvider()
explain the process pretty well:

  If there is a PREFERRED_VERSION, find the highest-priority bbfile
  providing that version.  If not, find the latest version provided by
  an bbfile in the highest-priority set.

The only caveat is that if PREFERRED_VERSION contains a wildcard (%)
and matches more than one available version then all bets are off and
results may be unpredictable. It's up to the user to ensure that
doesn't happen.

Note that looking at the meta-xilinx recipe it seems that PV is set
manually and doesn't follow the recipe name, so depending on how you
set PV in your new recipe, it may not be completely obvious which
recipe is actually being used?

  
https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Recipe versions and layer confusion

[Paul Eggleton]

Hi Mike,

On Friday, 6 October 2017 3:49:28 AM NZDT Mike Looijmans wrote:
> I'm confused.
> 
> Layer "meta-xilinx" defines:
> 
> recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb
> 
> This recipe is too old for my liking, so I made a newer one in "meta-topic"
> 
> recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb
> 
> 
> Much to my surprise, when I build, OE picks the 2017.1 version and not the 
> 2017.3 version.
> 
> bitbake-layers show-layers reveils:
> ..
> meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
> meta-topic/home/mike/projects/zynq-platform/meta-topic  6
> ..
> 
> so that means that my meta-topic should win even if my PV were lower, right?

At face value I would have to agree - it doesn't sound like it's working the 
way it should.

What does bitbake-layers show-recipes  arm-trusted-firmware show ?

Another diagnostic would be to do bitbake -DDD arm-trusted-firmware and see if 
it gives any explanation as to why it's picking the older version (you'll have 
to wade through all of the other irrelevant debug info though).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ltp: update to new upstream release 20170929

[Khem Raj]

On Thu, Oct 5, 2017 at 10:47 AM, Fathi Boudra  wrote:
> * Update SRCREV to match 20170929 release
> * Drop patches available in 20170929 release:
>   - 0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
>   - 0038-commands-gdb01-replace-stdin-with-dev-null.patch
>

A build time test for musl target would be appreciated.

> Signed-off-by: Fathi Boudra 
> ---
>  ...E_SIZE-redefinition-and-O_CREAT-undeclear.patch | 113 
> -
>  ...ommands-gdb01-replace-stdin-with-dev-null.patch |  34 ---
>  .../ltp/{ltp_20170516.bb => ltp_20170929.bb}   |   4 +-
>  3 files changed, 1 insertion(+), 150 deletions(-)
>  delete mode 100644 
> meta/recipes-extended/ltp/ltp/0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
>  delete mode 100644 
> meta/recipes-extended/ltp/ltp/0038-commands-gdb01-replace-stdin-with-dev-null.patch
>  rename meta/recipes-extended/ltp/{ltp_20170516.bb => ltp_20170929.bb} (96%)
>
> diff --git 
> a/meta/recipes-extended/ltp/ltp/0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
>  
> b/meta/recipes-extended/ltp/ltp/0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
> deleted file mode 100644
> index c8738ae0d4..00
> --- 
> a/meta/recipes-extended/ltp/ltp/0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
> +++ /dev/null
> @@ -1,113 +0,0 @@
> -From a9d5595d2fa2ab252f1cabf63f4b65c3efbafeb9 Mon Sep 17 00:00:00 2001
> -From: Dengke Du 
> -Date: Thu, 10 Aug 2017 15:27:03 +0800
> -Subject: [PATCH] ltp: fix PAGE_SIZE redefinition and O_CREAT undeclear when
> - build with musl
> -
> -error 1:
> -
> -|stack_clash.c:50:22: error: expected identifier or '(' before numeric 
> constant
> -| static unsigned long PAGE_SIZE;
> -
> -This is because the musl libc already contain PAGE_SIZE definition in 
> limits.c,
> -we can check it here:
> -
> -https://git.musl-libc.org/cgit/musl/tree/include/limits.h#n43
> -
> -error 2:
> -
> -|ck01.c:157:22: error: 'O_CREAT' undeclared (first use in this function); 
> did you mean 'S_IREAD'?
> -|   fd = open(filename, O_CREAT | O_TRUNC | O_RDWR, 0644);
> -|   ^~~
> -|   S_IREAD
> -
> -This is because the musl libc put those in fcntl.h, so we should include that
> -file.
> -
> -Upstream-Status: Submitted [ 
> https://github.com/linux-test-project/ltp/pull/194 ]
> -
> -Signed-off-by: Dengke Du 
> 
> - testcases/cve/stack_clash.c   | 12 ++--
> - testcases/kernel/syscalls/flock/flock01.c |  1 +
> - testcases/kernel/syscalls/flock/flock02.c |  1 +
> - 3 files changed, 8 insertions(+), 6 deletions(-)
> -
> -diff --git a/testcases/cve/stack_clash.c b/testcases/cve/stack_clash.c
> -index 2ef1a82..7c45991 100644
>  a/testcases/cve/stack_clash.c
> -+++ b/testcases/cve/stack_clash.c
> -@@ -47,7 +47,7 @@
> - #include "tst_test.h"
> - #include "tst_safe_stdio.h"
> -
> --static unsigned long PAGE_SIZE;
> -+static unsigned long PAGE_SIZE_tst;
> - static unsigned long PAGE_MASK;
> - static unsigned long GAP_PAGES = 256;
> - static unsigned long THRESHOLD;
> -@@ -66,7 +66,7 @@ void exhaust_stack_into_sigsegv(void)
> -   exhaust_stack_into_sigsegv();
> - }
> -
> --#define MAPPED_LEN PAGE_SIZE
> -+#define MAPPED_LEN PAGE_SIZE_tst
> - static unsigned long mapped_addr;
> -
> - void segv_handler(int sig, siginfo_t *info, void *data LTP_ATTRIBUTE_UNUSED)
> -@@ -150,7 +150,7 @@ void do_child(void)
> -   stack_t signal_stack;
> -   struct sigaction segv_sig = {.sa_sigaction = segv_handler, .sa_flags 
> = SA_ONSTACK|SA_SIGINFO};
> -   void *map;
> --  unsigned long gap = GAP_PAGES * PAGE_SIZE;
> -+  unsigned long gap = GAP_PAGES * PAGE_SIZE_tst;
> -   struct rlimit rlimit;
> -
> -   rlimit.rlim_cur = rlimit.rlim_max = RLIM_INFINITY;
> -@@ -200,8 +200,8 @@ void setup(void)
> - {
> -   char buf[4096], *p;
> -
> --  PAGE_SIZE = sysconf(_SC_PAGESIZE);
> --  PAGE_MASK = ~(PAGE_SIZE - 1);
> -+  PAGE_SIZE_tst = sysconf(_SC_PAGESIZE);
> -+  PAGE_MASK = ~(PAGE_SIZE_tst - 1);
> -
> -   buf[4095] = '\0';
> -   SAFE_FILE_SCANF("/proc/cmdline", "%4095[^\n]", buf);
> -@@ -214,7 +214,7 @@ void setup(void)
> -   tst_res(TINFO, "stack_guard_gap = %ld", GAP_PAGES);
> -   }
> -
> --  THRESHOLD = (GAP_PAGES - 1) * PAGE_SIZE;
> -+  THRESHOLD = (GAP_PAGES - 1) * PAGE_SIZE_tst;
> -
> -   {
> -   volatile int *a = alloca(128);
> -diff --git a/testcases/kernel/syscalls/flock/flock01.c 
> b/testcases/kernel/syscalls/flock/flock01.c
> -index 3e17be4..06d89e3 100644
>  a/testcases/kernel/syscalls/flock/flock01.c
> -+++ b/testcases/kernel/syscalls/flock/flock01.c
> -@@ -69,6 +69,7 @@
> - #include 
> - #include 
> - #include 
> -+#include 
> - #include "test.h"
> -
> - void setup(void);
> -diff --git a/testcases/kernel/syscalls/flock/flock02.c 
> 

Re: [OE-core] [PATCH] linux-firmware: Split i.MX SDMA firmwares

[Daiane Angolini]

On Thu, Oct 5, 2017 at 3:00 PM, Otavio Salvador  wrote:
> This splits out the i.MX SDMA firmwares for i.MX6 and i.MX7 SoCs. This
> also includes the required runtime provides, conflicts and replaces
> for the old firmware-imx which was provided by NXP BSP layer.
>
> Signed-off-by: Otavio Salvador 

Reviewed-by: Daiane Angolini 

> ---
>
>  .../recipes-kernel/linux-firmware/linux-firmware_git.bb | 17 
> +
>  1 file changed, 17 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> index 6798ace639..cb923e8a7b 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> @@ -46,6 +46,7 @@ LICENSE = "\
>  & Firmware-ralink_a_mediatek_company_firmware \
>  & Firmware-ralink-firmware \
>  & Firmware-rtlwifi_firmware \
> +& Firmware-imx-sdma_firmware \
>  & Firmware-siano \
>  & Firmware-tda7706-firmware \
>  & Firmware-ti-connectivity \
> @@ -104,6 +105,7 @@ LIC_FILES_CHKSUM = "\
>  
> file://LICENCE.ralink_a_mediatek_company_firmware;md5=728f1a85fd53fd67fa8d7afb080bc435
>  \
>  file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
>  file://LICENCE.rtlwifi_firmware.txt;md5=00d06cfd3eddd5a2698948ead2ad54a5 
> \
> +file://LICENSE.sdma_firmware;md5=51e8c19ecc2270f4b8ea30341ad63ce9 \
>  file://LICENCE.siano;md5=4556c1bf830067f12ca151ad953ec2a5 \
>  file://LICENCE.tda7706-firmware.txt;md5=835997cf5e3c131d0695c7d9103e 
> \
>  file://LICENCE.ti-connectivity;md5=c5e02be633f1499c109d1652514d85ec \
> @@ -164,6 +166,7 @@ 
> NO_GENERIC_LICENSE[Firmware-ralink_a_mediatek_company_firmware] = 
> "LICENCE.ralin
>  NO_GENERIC_LICENSE[Firmware-ralink-firmware] = "LICENCE.ralink-firmware.txt"
>  NO_GENERIC_LICENSE[Firmware-rtlwifi_firmware] = 
> "LICENCE.rtlwifi_firmware.txt"
>  NO_GENERIC_LICENSE[Firmware-siano] = "LICENCE.siano"
> +NO_GENERIC_LICENSE[Firmware-imx-sdma_firmware] = "LICENSE.sdma_firmware"
>  NO_GENERIC_LICENSE[Firmware-tda7706-firmware] = 
> "LICENCE.tda7706-firmware.txt"
>  NO_GENERIC_LICENSE[Firmware-ti-connectivity] = "LICENCE.ti-connectivity"
>  NO_GENERIC_LICENSE[Firmware-ti-keystone] = "LICENCE.ti-keystone"
> @@ -239,6 +242,8 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
>   ${PN}-gplv2-license ${PN}-carl9170 \
>   ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
> ${PN}-qca \
>   \
> + ${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q 
> ${PN}-imx-sdma-imx7d \
> + \
>   ${PN}-iwlwifi-license ${PN}-iwlwifi \
>   ${PN}-iwlwifi-135-6 \
>   ${PN}-iwlwifi-3160-7 ${PN}-iwlwifi-3160-8 ${PN}-iwlwifi-3160-9 \
> @@ -550,6 +555,17 @@ FILES_${PN}-whence-license = 
> "${nonarch_base_libdir}/firmware/WHENCE"
>
>  RDEPENDS_${PN}-bnx2-mips += "${PN}-whence-license"
>
> +# For imx-sdma
> +LICENSE_${PN}-imx-sdma  = "Firmware-imx-sdma_firmware"
> +
> +FILES_${PN}-imx-sdma-imx6q = 
> "${nonarch_base_libdir}/firmware/imx/sdma/sdma-imx6q.bin"
> +
> +RPROVIDES_${PN}-imx-sdma-imx6q = "firmware-imx-sdma-imx6q"
> +RREPLACES_${PN}-imx-sdma-imx6q = "firmware-imx-sdma-imx6q"
> +RCONFLICTS_${PN}-imx-sdma-imx6q = "firmware-imx-sdma-imx6q"
> +
> +FILES_${PN}-imx-sdma-imx7d = 
> "${nonarch_base_libdir}/firmware/imx/sdma/sdma-imx7d.bin"
> +
>  # For iwlwifi
>  LICENSE_${PN}-iwlwifi   = "Firmware-iwlwifi_firmware"
>  LICENSE_${PN}-iwlwifi-135-6 = "Firmware-iwlwifi_firmware"
> @@ -713,6 +729,7 @@ LICENSE_${PN} = "\
>  & Firmware-radeon \
>  & Firmware-ralink_a_mediatek_company_firmware \
>  & Firmware-ralink-firmware \
> +& Firmware-imx-sdma_firmware \
>  & Firmware-siano \
>  & Firmware-tda7706-firmware \
>  & Firmware-ti-connectivity \
> --
> 2.14.2
>
> --
> ___
> 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] python-ptest: various fixes

[Juro Bystricky]

python-ptest needs python-tests package installed in order to
run any tests.
This patch adds python-tests as a runtime dependency, so the test suite
will be present in the image.
While in there, also removed several build host references.

[YOCTO #12144]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-devtools/python/python_2.7.13.bb | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python_2.7.13.bb 
b/meta/recipes-devtools/python/python_2.7.13.bb
index 4d73cd2..8770699 100644
--- a/meta/recipes-devtools/python/python_2.7.13.bb
+++ b/meta/recipes-devtools/python/python_2.7.13.bb
@@ -154,7 +154,7 @@ FILES_lib${BPN}2 = "${libdir}/libpython*.so.*"
 PACKAGES += "${PN}-misc"
 FILES_${PN}-misc = "${libdir}/python${PYTHON_MAJMIN}"
 RDEPENDS_${PN}-modules += "${PN}-misc"
-RDEPENDS_${PN}-ptest = "${PN}-modules"
+RDEPENDS_${PN}-ptest = "${PN}-modules ${PN}-tests"
 #inherit ptest after "require python-${PYTHON_MAJMIN}-manifest.inc" so 
PACKAGES doesn't get overwritten
 inherit ptest
 
@@ -164,6 +164,16 @@ do_install_ptest() {
sed -e s:LIBDIR/python/ptest:${PTEST_PATH}:g \
 -e s:LIBDIR:${libdir}:g \
 -i ${D}${PTEST_PATH}/run-ptest
+
+   #Remove build host references
+   sed -i \
+   -e 's:--with-libtool-sysroot=${STAGING_DIR_TARGET}'::g \
+   -e 's:--sysroot=${STAGING_DIR_TARGET}::g' \
+   -e 's|${DEBUG_PREFIX_MAP}||g' \
+   -e 's:${HOSTTOOLS_DIR}/::g' \
+   -e 's:${RECIPE_SYSROOT}::g' \
+   -e 's:${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}::g' \
+   ${D}/${PTEST_PATH}/Makefile
 }
 
 # catch manpage
-- 
2.7.4

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

[OE-core] [PATCH] bitbake.conf: Add 'id' to HOSTTOOLS

[Otavio Salvador]

The 'id' utility is used in 'rootfs_check_host_user_contaminated'
rootfs-postcommand so it must be available.

Signed-off-by: Otavio Salvador 
---

 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index f41680b27e..6f53b23a67 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -476,7 +476,7 @@ HOSTTOOLS += " \
 [ ar as awk basename bash bzip2 cat chgrp chmod chown chrpath cmp cp cpio \
 cpp cut date dd diff diffstat dirname du echo egrep env expand expr false \
 fgrep file find flock g++ gawk gcc getconf getopt git grep gunzip gzip \
-head hostname install ld ldd ln ls make makeinfo md5sum mkdir mknod \
+head hostname id install ld ldd ln ls make makeinfo md5sum mkdir mknod \
 mktemp mv nm objcopy objdump od patch perl pod2man pr printf pwd python 
python2 \
 python2.7 python3 ranlib readelf readlink rm rmdir rpcgen sed sh sha256sum 
\
 sleep sort split stat strings strip tail tar tee test touch tr true uname \
-- 
2.14.2

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

[OE-core] [PATCH] linux-firmware: Split i.MX SDMA firmwares

[Otavio Salvador]

This splits out the i.MX SDMA firmwares for i.MX6 and i.MX7 SoCs. This
also includes the required runtime provides, conflicts and replaces
for the old firmware-imx which was provided by NXP BSP layer.

Signed-off-by: Otavio Salvador 
---

 .../recipes-kernel/linux-firmware/linux-firmware_git.bb | 17 +
 1 file changed, 17 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 6798ace639..cb923e8a7b 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -46,6 +46,7 @@ LICENSE = "\
 & Firmware-ralink_a_mediatek_company_firmware \
 & Firmware-ralink-firmware \
 & Firmware-rtlwifi_firmware \
+& Firmware-imx-sdma_firmware \
 & Firmware-siano \
 & Firmware-tda7706-firmware \
 & Firmware-ti-connectivity \
@@ -104,6 +105,7 @@ LIC_FILES_CHKSUM = "\
 
file://LICENCE.ralink_a_mediatek_company_firmware;md5=728f1a85fd53fd67fa8d7afb080bc435
 \
 file://LICENCE.ralink-firmware.txt;md5=ab2c269277c45476fb449673911a2dfd \
 file://LICENCE.rtlwifi_firmware.txt;md5=00d06cfd3eddd5a2698948ead2ad54a5 \
+file://LICENSE.sdma_firmware;md5=51e8c19ecc2270f4b8ea30341ad63ce9 \
 file://LICENCE.siano;md5=4556c1bf830067f12ca151ad953ec2a5 \
 file://LICENCE.tda7706-firmware.txt;md5=835997cf5e3c131d0695c7d9103e \
 file://LICENCE.ti-connectivity;md5=c5e02be633f1499c109d1652514d85ec \
@@ -164,6 +166,7 @@ 
NO_GENERIC_LICENSE[Firmware-ralink_a_mediatek_company_firmware] = "LICENCE.ralin
 NO_GENERIC_LICENSE[Firmware-ralink-firmware] = "LICENCE.ralink-firmware.txt"
 NO_GENERIC_LICENSE[Firmware-rtlwifi_firmware] = "LICENCE.rtlwifi_firmware.txt"
 NO_GENERIC_LICENSE[Firmware-siano] = "LICENCE.siano"
+NO_GENERIC_LICENSE[Firmware-imx-sdma_firmware] = "LICENSE.sdma_firmware"
 NO_GENERIC_LICENSE[Firmware-tda7706-firmware] = "LICENCE.tda7706-firmware.txt"
 NO_GENERIC_LICENSE[Firmware-ti-connectivity] = "LICENCE.ti-connectivity"
 NO_GENERIC_LICENSE[Firmware-ti-keystone] = "LICENCE.ti-keystone"
@@ -239,6 +242,8 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-gplv2-license ${PN}-carl9170 \
  ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
${PN}-qca \
  \
+ ${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
+ \
  ${PN}-iwlwifi-license ${PN}-iwlwifi \
  ${PN}-iwlwifi-135-6 \
  ${PN}-iwlwifi-3160-7 ${PN}-iwlwifi-3160-8 ${PN}-iwlwifi-3160-9 \
@@ -550,6 +555,17 @@ FILES_${PN}-whence-license = 
"${nonarch_base_libdir}/firmware/WHENCE"
 
 RDEPENDS_${PN}-bnx2-mips += "${PN}-whence-license"
 
+# For imx-sdma
+LICENSE_${PN}-imx-sdma  = "Firmware-imx-sdma_firmware"
+
+FILES_${PN}-imx-sdma-imx6q = 
"${nonarch_base_libdir}/firmware/imx/sdma/sdma-imx6q.bin"
+
+RPROVIDES_${PN}-imx-sdma-imx6q = "firmware-imx-sdma-imx6q"
+RREPLACES_${PN}-imx-sdma-imx6q = "firmware-imx-sdma-imx6q"
+RCONFLICTS_${PN}-imx-sdma-imx6q = "firmware-imx-sdma-imx6q"
+
+FILES_${PN}-imx-sdma-imx7d = 
"${nonarch_base_libdir}/firmware/imx/sdma/sdma-imx7d.bin"
+
 # For iwlwifi
 LICENSE_${PN}-iwlwifi   = "Firmware-iwlwifi_firmware"
 LICENSE_${PN}-iwlwifi-135-6 = "Firmware-iwlwifi_firmware"
@@ -713,6 +729,7 @@ LICENSE_${PN} = "\
 & Firmware-radeon \
 & Firmware-ralink_a_mediatek_company_firmware \
 & Firmware-ralink-firmware \
+& Firmware-imx-sdma_firmware \
 & Firmware-siano \
 & Firmware-tda7706-firmware \
 & Firmware-ti-connectivity \
-- 
2.14.2

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

[OE-core] [PATCH] ltp: update to new upstream release 20170929

[Fathi Boudra]

* Update SRCREV to match 20170929 release
* Drop patches available in 20170929 release:
  - 0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
  - 0038-commands-gdb01-replace-stdin-with-dev-null.patch

Signed-off-by: Fathi Boudra 
---
 ...E_SIZE-redefinition-and-O_CREAT-undeclear.patch | 113 -
 ...ommands-gdb01-replace-stdin-with-dev-null.patch |  34 ---
 .../ltp/{ltp_20170516.bb => ltp_20170929.bb}   |   4 +-
 3 files changed, 1 insertion(+), 150 deletions(-)
 delete mode 100644 
meta/recipes-extended/ltp/ltp/0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
 delete mode 100644 
meta/recipes-extended/ltp/ltp/0038-commands-gdb01-replace-stdin-with-dev-null.patch
 rename meta/recipes-extended/ltp/{ltp_20170516.bb => ltp_20170929.bb} (96%)

diff --git 
a/meta/recipes-extended/ltp/ltp/0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
 
b/meta/recipes-extended/ltp/ltp/0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
deleted file mode 100644
index c8738ae0d4..00
--- 
a/meta/recipes-extended/ltp/ltp/0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch
+++ /dev/null
@@ -1,113 +0,0 @@
-From a9d5595d2fa2ab252f1cabf63f4b65c3efbafeb9 Mon Sep 17 00:00:00 2001
-From: Dengke Du 
-Date: Thu, 10 Aug 2017 15:27:03 +0800
-Subject: [PATCH] ltp: fix PAGE_SIZE redefinition and O_CREAT undeclear when
- build with musl
-
-error 1:
-
-|stack_clash.c:50:22: error: expected identifier or '(' before numeric constant
-| static unsigned long PAGE_SIZE;
-
-This is because the musl libc already contain PAGE_SIZE definition in limits.c,
-we can check it here:
-
-https://git.musl-libc.org/cgit/musl/tree/include/limits.h#n43
-
-error 2:
-
-|ck01.c:157:22: error: 'O_CREAT' undeclared (first use in this function); did 
you mean 'S_IREAD'?
-|   fd = open(filename, O_CREAT | O_TRUNC | O_RDWR, 0644);
-|   ^~~
-|   S_IREAD
-
-This is because the musl libc put those in fcntl.h, so we should include that
-file.
-
-Upstream-Status: Submitted [ 
https://github.com/linux-test-project/ltp/pull/194 ]
-
-Signed-off-by: Dengke Du 

- testcases/cve/stack_clash.c   | 12 ++--
- testcases/kernel/syscalls/flock/flock01.c |  1 +
- testcases/kernel/syscalls/flock/flock02.c |  1 +
- 3 files changed, 8 insertions(+), 6 deletions(-)
-
-diff --git a/testcases/cve/stack_clash.c b/testcases/cve/stack_clash.c
-index 2ef1a82..7c45991 100644
 a/testcases/cve/stack_clash.c
-+++ b/testcases/cve/stack_clash.c
-@@ -47,7 +47,7 @@
- #include "tst_test.h"
- #include "tst_safe_stdio.h"
- 
--static unsigned long PAGE_SIZE;
-+static unsigned long PAGE_SIZE_tst;
- static unsigned long PAGE_MASK;
- static unsigned long GAP_PAGES = 256;
- static unsigned long THRESHOLD;
-@@ -66,7 +66,7 @@ void exhaust_stack_into_sigsegv(void)
-   exhaust_stack_into_sigsegv();
- }
- 
--#define MAPPED_LEN PAGE_SIZE
-+#define MAPPED_LEN PAGE_SIZE_tst
- static unsigned long mapped_addr;
- 
- void segv_handler(int sig, siginfo_t *info, void *data LTP_ATTRIBUTE_UNUSED)
-@@ -150,7 +150,7 @@ void do_child(void)
-   stack_t signal_stack;
-   struct sigaction segv_sig = {.sa_sigaction = segv_handler, .sa_flags = 
SA_ONSTACK|SA_SIGINFO};
-   void *map;
--  unsigned long gap = GAP_PAGES * PAGE_SIZE;
-+  unsigned long gap = GAP_PAGES * PAGE_SIZE_tst;
-   struct rlimit rlimit;
- 
-   rlimit.rlim_cur = rlimit.rlim_max = RLIM_INFINITY;
-@@ -200,8 +200,8 @@ void setup(void)
- {
-   char buf[4096], *p;
- 
--  PAGE_SIZE = sysconf(_SC_PAGESIZE);
--  PAGE_MASK = ~(PAGE_SIZE - 1);
-+  PAGE_SIZE_tst = sysconf(_SC_PAGESIZE);
-+  PAGE_MASK = ~(PAGE_SIZE_tst - 1);
- 
-   buf[4095] = '\0';
-   SAFE_FILE_SCANF("/proc/cmdline", "%4095[^\n]", buf);
-@@ -214,7 +214,7 @@ void setup(void)
-   tst_res(TINFO, "stack_guard_gap = %ld", GAP_PAGES);
-   }
- 
--  THRESHOLD = (GAP_PAGES - 1) * PAGE_SIZE;
-+  THRESHOLD = (GAP_PAGES - 1) * PAGE_SIZE_tst;
- 
-   {
-   volatile int *a = alloca(128);
-diff --git a/testcases/kernel/syscalls/flock/flock01.c 
b/testcases/kernel/syscalls/flock/flock01.c
-index 3e17be4..06d89e3 100644
 a/testcases/kernel/syscalls/flock/flock01.c
-+++ b/testcases/kernel/syscalls/flock/flock01.c
-@@ -69,6 +69,7 @@
- #include 
- #include 
- #include 
-+#include 
- #include "test.h"
- 
- void setup(void);
-diff --git a/testcases/kernel/syscalls/flock/flock02.c 
b/testcases/kernel/syscalls/flock/flock02.c
-index 414df68..9ddf729 100644
 a/testcases/kernel/syscalls/flock/flock02.c
-+++ b/testcases/kernel/syscalls/flock/flock02.c
-@@ -75,6 +75,7 @@
- #include 
- #include 
- #include 
-+#include 
- #include 
- #include 
- #include "test.h"
--- 
-2.7.4
-
diff --git 
a/meta/recipes-extended/ltp/ltp/0038-commands-gdb01-replace-stdin-with-dev-null.patch
 

Re: [OE-core] [PATCH] toolchain-shar-extract: compare SDK and host gcc versions

[Mark Hatle]

I realize this reply is months after the original email.  But I think I found a
bug with the implementation.  See below inline.

On 1/25/17 7:18 AM, Ed Bartosh wrote:
> If ext sdk is built by gcc version higher than host gcc version
> and host gcc version is 4.8 or 4.9 the installation is known to
> fail due to the way uninative sstate package is built.
> 
> It's a known issue and we don't have a way to fix it for above
> mentioned combinations of build and host gcc versions.
> 
> Detected non-installable combinations of gcc versions and
> print an installation error.
> 
> [YOCTO #10881]
> 
> Signed-off-by: Ed Bartosh 
> ---
>  meta/classes/populate_sdk_base.bbclass | 1 +
>  meta/files/toolchain-shar-extract.sh   | 8 
>  2 files changed, 9 insertions(+)
> 
> diff --git a/meta/classes/populate_sdk_base.bbclass 
> b/meta/classes/populate_sdk_base.bbclass
> index 5ad08c6..588a3cb 100644
> --- a/meta/classes/populate_sdk_base.bbclass
> +++ b/meta/classes/populate_sdk_base.bbclass
> @@ -226,6 +226,7 @@ EOF
>   -e 's#@SDK_VERSION@#${SDK_VERSION}#g' \
>   -e '/@SDK_PRE_INSTALL_COMMAND@/d' \
>   -e '/@SDK_POST_INSTALL_COMMAND@/d' \
> + -e 's#@SDK_GCC_VER@#${@oe.utils.host_gcc_version(d)}#g' \

The return value from "oe.utils.host_gcc_version(d)" includes a leading '-'...

>   ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.sh
>  
>   # add execution permission
> diff --git a/meta/files/toolchain-shar-extract.sh 
> b/meta/files/toolchain-shar-extract.sh
> index 9295ddc..3f54c96 100644
> --- a/meta/files/toolchain-shar-extract.sh
> +++ b/meta/files/toolchain-shar-extract.sh
> @@ -11,6 +11,9 @@ export PATH=`echo "$PATH" | sed -e 's/:\.//' -e 's/::/:/'`
>  INST_ARCH=$(uname -m | sed -e "s/i[3-6]86/ix86/" -e "s/x86[-_]64/x86_64/")
>  SDK_ARCH=$(echo @SDK_ARCH@ | sed -e "s/i[3-6]86/ix86/" -e 
> "s/x86[-_]64/x86_64/")
>  
> +INST_GCC_VER=$(gcc --version | sed -ne 's/.* 
> \([0-9]\+\.[0-9]\+\)\.[0-9]\+.*/\1/p')

The item above fails with the message:

line 28: gcc: command not found

If the host does not have gcc on it.  (I realize this is incredibly rare
situation, but is valid in some cases.)  It might be a good idea to catch this
and put up a warning or otherwise clean up the error situation.

> +SDK_GCC_VER='@SDK_GCC_VER@'
> +

So based on the above you will end up with:

INST_GCC_VER="4.8"
SDK_GCC_VER="-4.9"

>  verlte () {
>   [  "$1" = "`printf "$1\n$2" | sort -V | head -n1`" ]
>  }
> @@ -112,6 +115,11 @@ fi
>  # SDK_EXTENSIBLE is exposed from the SDK_PRE_INSTALL_COMMAND above
>  if [ "$SDK_EXTENSIBLE" = "1" ]; then
>   DEFAULT_INSTALL_DIR="@SDKEXTPATH@"
> + if [ "$INST_GCC_VER" = '4.8' -a "$SDK_GCC_VER" = '4.9' ] || [ 
> "$INST_GCC_VER" = '4.8' -a "$SDK_GCC_VER" = '' ] || \
> + [ "$INST_GCC_VER" = '4.9' -a "$SDK_GCC_VER" = '' ]; then

The comparisons above do not include the leading '-', so it would appear to me
that the checked would never end up being true -- and thus the error below would
never happen.

Am I seeing what is happening right?  If so, we'll need to get this fixed...

--Mark


> + echo "Error: Incompatible SDK installer! Your host gcc version 
> is $INST_GCC_VER and this SDK was built by gcc higher version."
> + exit 1
> + fi
>  fi
>  
>  if [ "$target_sdk_dir" = "" ]; then
> 

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

Re: [OE-core] Building and using a second toolchain

[Mike Crowe]

Recap: I have a bootloader recipe that uses both the primary AArch64
cross-toolchain and an AArch32 cross-toolchain. I arrange for those
toolchains to be available by setting MULTILIBS for the machine and adding
the multilib compiler to DEPENDS for the recipe. However, this means that
the AArch32 sysroot for the recipe is not cleaned up correctly by do_clean
since it is outside WORKDIR.

On Friday 08 September 2017 at 07:53:41 +0100, Richard Purdie wrote:
> Option 3 may be to have the core staging.bbclass clean code iterate
> over the sysroots, it sounds like its creating them, just not cleaning
> them up, which is kind of a bug. "clean" is a slow path so even a tiny
> performance hit there for this likely isn't an issue...

Sorry for the delay, but I'm finally looking at this again.

I've read through staging.bbclass and I'm not sure what the best way to
implement what you suggest is.

The simplest way would be to build up a deduplicated list of sysroots from
the destsysroot assignments in extend_recipe_sysroot. If this list differs
from RECIPE_SYSROOT then stick the result in a variable and add a function
to CLEANFUNCS to perform the cleanup. Unfortunately, this adds code to the
normal build path which, based on your comment above, is probably not
acceptable.

The alternative would be to always add a function to CLEANFUNCS which runs
the same loop as extend_recipe_sysroot to identify the sysroots and remove
them (the primary ones should have already been deleted by do_clean at that
point.) This should have no effect on the normal build path, but the code
will probably not be updated if extend_recipe_sysroot changes in the
future.

Or, something else.

Do you have any further advice?

Thanks.

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

Re: [OE-core] Recipe versions and layer confusion

[Mike Looijmans]

On 05-10-17 16:59, Mark Hatle wrote:

On 10/5/17 9:49 AM, Mike Looijmans wrote:

I'm confused.

Layer "meta-xilinx" defines:

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb

This recipe is too old for my liking, so I made a newer one in "meta-topic"

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb


Much to my surprise, when I build, OE picks the 2017.1 version and not the
2017.3 version.


Typically the version is selected by whichever PV is 'higher'.  However there
are many ways to change this behavior.

The primary way is for a configuration file (often the machine configuration) to
defined a preferred version.  I.e.

   PREFERRED_VERSION_arm-trusted-firmware = "2017.1"

Most likely there is a line like that someone in meta-xilinx.


Nope, no such line.



Additional ways would be to have a recipe define itself as never the default
version.


bitbake-layers show-layers reveils:
..
meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
meta-topic/home/mike/projects/zynq-platform/meta-topic  6
..


The layer priority does not directly affect recipe selection.  It may if you
have two layers of the -same- version.

--Mark


so that means that my meta-topic should win even if my PV were lower, right?


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)







Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Recipe versions and layer confusion

[Leonardo Sandoval]

On Thu, 5 Oct 2017 16:49:28 +0200
Mike Looijmans  wrote:

> I'm confused.
> 
> Layer "meta-xilinx" defines:
> 
> recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb
> 
> This recipe is too old for my liking, so I made a newer one in "meta-topic"
> 
> recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb
> 
> 
> Much to my surprise, when I build, OE picks the 2017.1 version and not the 
> 2017.3 version.
> 
> bitbake-layers show-layers reveils:
> ..
> meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
> meta-topic/home/mike/projects/zynq-platform/meta-topic  6
> ..
> 
> so that means that my meta-topic should win even if my PV were lower, right?

"For example, a layer that has a recipe with a higher PV value but for which 
the BBFILE_PRIORITY is set to have a lower precedence still has a lower 
precedence."

taken from

http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#var-BBFILE_PRIORITY

> 
> 
> Kind regards,
> 
> Mike Looijmans
> System Expert
> 
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
> 
> Please consider the environment before printing this e-mail
> 
> 
> Visit us at the Space Tech Expo Europe (Stand E-71)
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

Re: [OE-core] Recipe versions and layer confusion

[Mark Hatle]

On 10/5/17 9:49 AM, Mike Looijmans wrote:
> I'm confused.
> 
> Layer "meta-xilinx" defines:
> 
> recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb
> 
> This recipe is too old for my liking, so I made a newer one in "meta-topic"
> 
> recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb
> 
> 
> Much to my surprise, when I build, OE picks the 2017.1 version and not the 
> 2017.3 version.

Typically the version is selected by whichever PV is 'higher'.  However there
are many ways to change this behavior.

The primary way is for a configuration file (often the machine configuration) to
defined a preferred version.  I.e.

  PREFERRED_VERSION_arm-trusted-firmware = "2017.1"

Most likely there is a line like that someone in meta-xilinx.

Additional ways would be to have a recipe define itself as never the default
version.

> bitbake-layers show-layers reveils:
> ..
> meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
> meta-topic/home/mike/projects/zynq-platform/meta-topic  6
> ..

The layer priority does not directly affect recipe selection.  It may if you
have two layers of the -same- version.

--Mark

> so that means that my meta-topic should win even if my PV were lower, right?
> 
> 
> Kind regards,
> 
> Mike Looijmans
> System Expert
> 
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
> 
> Please consider the environment before printing this e-mail
> 
> 
> Visit us at the Space Tech Expo Europe (Stand E-71)
> 

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

[OE-core] Recipe versions and layer confusion

[Mike Looijmans]

I'm confused.

Layer "meta-xilinx" defines:

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb

This recipe is too old for my liking, so I made a newer one in "meta-topic"

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb


Much to my surprise, when I build, OE picks the 2017.1 version and not the 
2017.3 version.


bitbake-layers show-layers reveils:
..
meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
meta-topic/home/mike/projects/zynq-platform/meta-topic  6
..

so that means that my meta-topic should win even if my PV were lower, right?


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Illegal instruction when running go binaries in qemux86

[Paul Barker]

On Thu, Oct 5, 2017 at 3:31 PM, Burton, Ross  wrote:
> On 5 October 2017 at 15:23, Paul Barker  wrote:
>>
>> So my question is: should we just set GO386 = "387" so that it applies
>> to all go binaries and accept the slight loss of performance on x86
>> systems that do support sse2 instructions? Or should we make this
>> MACHINE specific so that sse2 instructions can be used where
>> supported?
>
>
> Definitely machine-specific.  Need a way of mapping from OE tunes to Go
> options that control the instructions used.
>
> Ross

Looking again, we already have go_map_arm() in goarch.bbclass to set
HOST_GOARM and TARGET_GOARM. We probably need to do the same for the
GO386 variable.

Cheers,

-- 
Paul Barker
Togán Labs Ltd
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Illegal instruction when running go binaries in qemux86

[Burton, Ross]

On 5 October 2017 at 15:23, Paul Barker  wrote:

> So my question is: should we just set GO386 = "387" so that it applies
> to all go binaries and accept the slight loss of performance on x86
> systems that do support sse2 instructions? Or should we make this
> MACHINE specific so that sse2 instructions can be used where
> supported?
>

Definitely machine-specific.  Need a way of mapping from OE tunes to Go
options that control the instructions used.

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

[OE-core] Illegal instruction when running go binaries in qemux86

[Paul Barker]

So, after fixing all my build issues I now have runtime issues :(

Software written in go fails on qemux86 with illegal instruction traps:

root@qemux86:~# netns ls
[   18.984298] traps: netns[491] trap invalid opcode ip:807b541
sp:bf9694bc error:0[   18.985354]  in netns[8048000+1c3000]
Illegal instruction
root@qemux86:~# runc
traps: runc[492] trap invalid opcode ip:807b561 sp:bff6ec1c
error:0[   21.604966]  in runc[8048000+457000]
Illegal instruction

I've done a git bisect and tracked this down to commit 20b35747
"qemuboot.conf: make cpus match built artifacts" on master. This has
been backported to pyro as commit d9456782 and I've confirmed that I
have the same issue on pyro. On pyro in particular this is a
regression as the patch was backported after pyro was released.

The important change is:

-QB_CPU_x86 = "-cpu qemu32"
+QB_CPU_x86 = "-cpu pentium2"

So my guess was that the go toolchain isn't limiting itself to the
instructions supported by pentium2.

To fix things I've added the following line to meta/classes/go.bbclass
and meta/recipes-devtools/go/go-common.inc:

export GO386 = "387"

As documented in https://golang.org/doc/install/source, this ensures
that sse2 instructions aren't used. This fixes the issue and I now
have working go binaries on qemux86 :)

So my question is: should we just set GO386 = "387" so that it applies
to all go binaries and accept the slight loss of performance on x86
systems that do support sse2 instructions? Or should we make this
MACHINE specific so that sse2 instructions can be used where
supported?

Whatever we do will need backporting to pyro as well.

Cheers,

-- 
Paul Barker
Togán Labs Ltd
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] argp-standalone: drop RDEPENDS dev/staticdev packages on main package

[liu . ming50]

From: Ming Liu 

This ensures argp-standalone-staticdev package could be installed
correctly(without depending on the empty argp-standalone package) if
it's being required during SDK population.

Signed-off-by: Ming Liu 
---
 meta/recipes-support/argp-standalone/argp-standalone_1.3.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-support/argp-standalone/argp-standalone_1.3.bb 
b/meta/recipes-support/argp-standalone/argp-standalone_1.3.bb
index bd0cfdf..21bbcab 100644
--- a/meta/recipes-support/argp-standalone/argp-standalone_1.3.bb
+++ b/meta/recipes-support/argp-standalone/argp-standalone_1.3.bb
@@ -19,6 +19,9 @@ inherit autotools
 
 CFLAGS += "-fPIC -U__OPTIMIZE__"
 
+RDEPENDS_${PN}-dev = ""
+RDEPENDS_${PN}-staticdev = ""
+
 do_install() {
install -D -m 0644 ${B}/libargp.a ${D}${libdir}/libargp.a
install -D -m 0644 ${S}/argp.h ${D}${includedir}/argp.h
-- 
2.7.4

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

Re: [OE-core] [PATCH] argp-standalone: set ALLOW_EMPTY to PN

[Ming Liu]

Hi, Ross:

Agreed, will send a V2 soon.

//Ming Liu

2017-10-05 12:22 GMT+02:00 Burton, Ross :

> On 5 October 2017 at 04:48,  wrote:
>
>> From: Ming Liu 
>>
>> This ensures argp-standalone-staticdev package could be installed
>> correctly(depending on argp-standalone) if it's being required during
>> SDK population.
>>
>
> I'd prefer to remove the dependency on PN in PN-staticdev, as a
> argp-standalone library package with nothing in it is more confusing.
>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Go runtime host contamination

[Paul Barker]

On Thu, Sep 28, 2017 at 10:22 PM, Matt Madison  wrote:
> On Thu, Sep 28, 2017 at 10:28 AM, Paul Barker  wrote:
>> Hey,
>>
>> I'm trying to upgrade runc-opencontainers in meta-virtualization to
>> v1.0.0-rc4 and hitting a host contamination issue.
>>
>> Both host and target are x86-64 but I'm using glibc on the host
>> (Ubuntu 16.04) and musl on the target. I'm getting link failures
>> referring to missing symbols "__vfprintf_chk" and "__fprintf_chk" in
>> libcontainer. I'm pretty sure these symbols exist in glibc but not in
>> musl.
>>
>> The failure is occurring when trying to link libcontainer which uses
>> the go extension cgo to incorporate some c code in with the go code.
>>
>> Using a pretty dumb grep, I can see the contamination in the go-runtime 
>> package:
>>
>> $ grep -r __fprintf_chk
>> tmp/work/core2-64-oe-linux-musl/go-runtime/1.9-r0/image/
>> Binary file
>> tmp/work/core2-64-oe-linux-musl/go-runtime/1.9-r0/image/usr/lib/go/src/host-tools/trace
>> matches
>> Binary file
>> tmp/work/core2-64-oe-linux-musl/go-runtime/1.9-r0/image/usr/lib/go/src/host-tools/pprof
>> matches
>> Binary file
>> tmp/work/core2-64-oe-linux-musl/go-runtime/1.9-r0/image/usr/lib/go/pkg/linux_amd64/runtime/cgo.a
>> matches
>
> Yep, I see what's going on here.  I have a patch in the works to take
> care of it.
>

Right, with a detour via the innards of the go linker I've finally
spotted the problem here.

The recipe in question is overriding GOROOT in the do_compile stage to
point at recipe-sysroot-native.

With that fixed, and Matt's latest patch on the oe-core mailing list
applied, runc-opencontainers now builds as expected for qemux86-64.

Cheers,

-- 
Paul Barker
Togán Labs Ltd
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libarchive: 3.2.2 -> 3.3.1

[Patrick Ohly]

On Mon, 2017-04-24 at 09:16 +0800, Huang Qiyu wrote:
> 3) Delete three patches, since they are integrated upstream. 
...
>    non-recursive-extract-and-list.patch
...
> -Upstream-Status: Submitted 
> [https://github.com/libarchive/libarchive/pull/812]

What made you think that this patch had been integrated upstream? It
was submitted, but unfortunately has not been merged yet despite a
favorable review.

Please be a bit more careful in future updates. Removing the patch
causes meta-swupd to break.

I've sent a patch adding back the patch ("libarchive: re-add non-
recursive extract and list support") but it is not clear whether that
can be merged in time for 2.4.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


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

[OE-core] [PATCH] libarchive: re-add non-recursive extract and list support

[Patrick Ohly]

This patch is needed for meta-swupd. Without it, some bsdtar
invocations fail with:
bsdtar: Option -n is not permitted in mode -x

The patch was removed in the update to 3.3.1 with the claim that it
had been merged upstream, but that is not the case.

Signed-off-by: Patrick Ohly 
---
 
meta/recipes-extended/libarchive/libarchive/non-recursive-extract-and-list.patch
 | 153 -
 meta/recipes-extended/libarchive/libarchive_3.3.2.bb   
  |   1 +-
 2 files changed, 154 insertions(+)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/non-recursive-extract-and-list.patch

diff --git 
a/meta/recipes-extended/libarchive/libarchive/non-recursive-extract-and-list.patch
 
b/meta/recipes-extended/libarchive/libarchive/non-recursive-extract-and-list.patch
new file mode 100644
index 000..cd7be51
--- /dev/null
+++ 
b/meta/recipes-extended/libarchive/libarchive/non-recursive-extract-and-list.patch
@@ -0,0 +1,153 @@
+From 47f7566f6829c2b14e21a699916de4998c72 Mon Sep 17 00:00:00 2001
+From: Patrick Ohly 
+Date: Mon, 24 Oct 2016 12:54:48 +0200
+Subject: [PATCH 1/1] non-recursive extract and list
+
+Sometimes it makes sense to extract or list a directory contained in
+an archive without also doing the same for the content of the
+directory, i.e. allowing -n (= --no-recursion) in combination with the
+x and t modes.
+
+bsdtar uses the match functionality in libarchive to track include
+matches. A new libarchive API call
+archive_match_include_directories_recursively() gets introduced to
+influence the matching behavior, with the default behavior as before.
+
+Non-recursive matching can be achieved by anchoring the path match at
+both start and end. Asking for a directory which itself isn't in the
+archive when in non-recursive mode is an error and handled by the
+existing mechanism for tracking unused inclusion entries.
+
+Upstream-Status: Submitted [https://github.com/libarchive/libarchive/pull/812]
+
+Signed-off-by: Patrick Ohly 
+
+---
+ libarchive/archive.h   |  2 ++
+ libarchive/archive_match.c | 30 +-
+ tar/bsdtar.1   |  3 +--
+ tar/bsdtar.c   | 12 ++--
+ 4 files changed, 42 insertions(+), 5 deletions(-)
+
+diff --git a/libarchive/archive.h b/libarchive/archive.h
+index 32710201..59fb4aa6 100644
+--- a/libarchive/archive.h
 b/libarchive/archive.h
+@@ -1093,6 +1093,8 @@ __LA_DECL intarchive_match_excluded(struct archive *,
+  */
+ __LA_DECL int archive_match_path_excluded(struct archive *,
+   struct archive_entry *);
++/* Control recursive inclusion of directory content when directory is 
included. Default on. */
++__LA_DECL int archive_match_include_directories_recursively(struct archive *, 
int _enabled);
+ /* Add exclusion pathname pattern. */
+ __LA_DECL int archive_match_exclude_pattern(struct archive *, const char *);
+ __LA_DECL int archive_match_exclude_pattern_w(struct archive *,
+diff --git a/libarchive/archive_match.c b/libarchive/archive_match.c
+index be72066e..bb6a3407 100644
+--- a/libarchive/archive_match.c
 b/libarchive/archive_match.c
+@@ -93,6 +93,9 @@ struct archive_match {
+   /* exclusion/inclusion set flag. */
+   int  setflag;
+ 
++  /* Recursively include directory content? */
++  int  recursive_include;
++
+   /*
+* Matching filename patterns.
+*/
+@@ -223,6 +226,7 @@ archive_match_new(void)
+   return (NULL);
+   a->archive.magic = ARCHIVE_MATCH_MAGIC;
+   a->archive.state = ARCHIVE_STATE_NEW;
++  a->recursive_include = 1;
+   match_list_init(&(a->inclusions));
+   match_list_init(&(a->exclusions));
+   __archive_rb_tree_init(&(a->exclusion_tree), _ops_mbs);
+@@ -471,6 +475,28 @@ archive_match_path_excluded(struct archive *_a,
+ }
+ 
+ /*
++ * When recursive inclusion of directory content is enabled,
++ * an inclusion pattern that matches a directory will also
++ * include everything beneath that directory. Enabled by default.
++ *
++ * For compatibility with GNU tar, exclusion patterns always
++ * match if a subset of the full patch matches (i.e., they are
++ * are not rooted at the beginning of the path) and thus there
++ * is no corresponding non-recursive exclusion mode.
++ */
++int
++archive_match_include_directories_recursively(struct archive *_a, int 
_enabled)
++{
++  struct archive_match *a;
++
++  archive_check_magic(_a, ARCHIVE_MATCH_MAGIC,
++  ARCHIVE_STATE_NEW, "archive_match_include_directories_recursively");
++  a = (struct archive_match *)_a;
++  a->recursive_include = _enabled;
++  return (ARCHIVE_OK);
++}
++
++/*
+  * Utility functions to get statistic information for inclusion patterns.
+  */
+ int
+@@ -781,7 +807,9 @@ static int
+ match_path_inclusion(struct 

Re: [OE-core] [PATCH] argp-standalone: set ALLOW_EMPTY to PN

[Burton, Ross]

On 5 October 2017 at 04:48,  wrote:

> From: Ming Liu 
>
> This ensures argp-standalone-staticdev package could be installed
> correctly(depending on argp-standalone) if it's being required during
> SDK population.
>

I'd prefer to remove the dependency on PN in PN-staticdev, as a
argp-standalone library package with nothing in it is more confusing.

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

[OE-core] [PATCH] cross.bbclass: Remove usage of host flags for cross-compilation

[Nikolay Merinov]

BUILD_* flags can't be used as TARGET_* flags even for "cross" packages.

gcc-cross buils leaks config.log's through "gcc-stashed-builddir" and
TARGET_* flags to libgcc cross-build through "gcc/libgcc.mvars" file
on "gcc-stashed-builddir". This means that if BUILD_CFLAGS contains
host-specific flags like "-isystem/usr/include" libgcc build will
fail "do_qa_configure" and "do_package_qa" checks.

Remove host-related flags from TARGET_* flags for gcc-cross build.

Signed-off-by: Nikolay Merinov 
---
 meta/classes/cross.bbclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 4887317a9a..29d4424829 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -28,10 +28,10 @@ MULTIMACH_TARGET_SYS = 
"${BUILD_ARCH}${BUILD_VENDOR}-${BUILD_OS}"
 export PKG_CONFIG_DIR = "${exec_prefix}/lib/pkgconfig"
 export PKG_CONFIG_SYSROOT_DIR = ""
 
-TARGET_CPPFLAGS = "${BUILD_CPPFLAGS}"
-TARGET_CFLAGS = "${BUILD_CFLAGS}"
-TARGET_CXXFLAGS = "${BUILD_CXXFLAGS}"
-TARGET_LDFLAGS = "${BUILD_LDFLAGS}"
+TARGET_CPPFLAGS = ""
+TARGET_CFLAGS = ""
+TARGET_CXXFLAGS = ""
+TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE}"
 
 CPPFLAGS = "${BUILD_CPPFLAGS}"
 CFLAGS = "${BUILD_CFLAGS}"
-- 
2.14.2

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

[OE-core] [PATCH] utils.bbclass: Support applications with keys in check_app_exist function

[Nikolay Merinov]

check_app_exist function must support cases when "app" variable defined
as "progname --keys". For example BUILD_CC="gcc -march=x86-64" must
pass sanity check.

Signed-off-by: Nikolay Merinov 
---
 meta/classes/utils.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
index 081e662da1..8e07eac07a 100644
--- a/meta/classes/utils.bbclass
+++ b/meta/classes/utils.bbclass
@@ -320,7 +320,7 @@ hardlinkdir () {
 
 
 def check_app_exists(app, d):
-app = d.expand(app).strip()
+app = d.expand(app).split()[0].strip()
 path = d.getVar('PATH')
 return bool(bb.utils.which(path, app))
 
-- 
2.14.2

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

[OE-core] [PATCH] perl-native: Provide correct lddlflags

[Nikolay Merinov]

For shared libraries compilation perl uses LDDLFLAGS instead of
LDFLAGS. Value for LDDLFLAGS can be provided through
recipe-sysroot-native/usr/lib/perl-native/perl/config.sh file
generated during perl-native compilation.

With default LDDLFLAGS libxml-parser-perl-native package have no
correct rpath in Expat.so module. Provide correct LDDLFLAGS for perl
modules compilation to fix build on hosts without libexpat.so.

Signed-off-by: Nikolay Merinov 
---
 meta/recipes-devtools/perl/perl-native_5.24.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/perl/perl-native_5.24.1.bb 
b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
index e01d11fbed..6c56a7d701 100644
--- a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
+++ b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
@@ -32,6 +32,7 @@ do_configure () {
-Dcc="${CC}" \
-Dcflags="${CFLAGS}" \
-Dldflags="${LDFLAGS}" \
+   -Dlddlflags="${LDFLAGS} -shared" \
-Dcf_by="Open Embedded" \
-Dprefix=${prefix} \
-Dvendorprefix=${prefix} \
-- 
2.14.2

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

[OE-core] [PATCH] nspr, nss: Use BUILD_CC instead of hardcoded "gcc"

[Nikolay Merinov]

Recipes nspr_4.16.bb and nss_3.31.1.bb ignored BUILD_CC and it's
BUILD_CFLAGS and tried to compile with hardcoded "gcc" instead. As
result build for this recipes will fail if host use different name for
compiler or require any flags.

Signed-off-by: Nikolay Merinov 
---
 meta/recipes-support/nspr/nspr_4.16.bb | 2 +-
 meta/recipes-support/nss/nss_3.31.1.bb | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-support/nspr/nspr_4.16.bb 
b/meta/recipes-support/nspr/nspr_4.16.bb
index bb178fe712..78ef994ffd 100644
--- a/meta/recipes-support/nspr/nspr_4.16.bb
+++ b/meta/recipes-support/nspr/nspr_4.16.bb
@@ -155,7 +155,7 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 
'ipv6', d)}"
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
 
 do_compile_prepend() {
-   oe_runmake CROSS_COMPILE=1 CFLAGS="-DXP_UNIX" LDFLAGS="" CC=gcc -C 
config export
+   oe_runmake CROSS_COMPILE=1 CFLAGS="-DXP_UNIX ${BUILD_CFLAGS}" 
LDFLAGS="" CC="${BUILD_CC}" -C config export
 }
 
 do_compile_append() {
diff --git a/meta/recipes-support/nss/nss_3.31.1.bb 
b/meta/recipes-support/nss/nss_3.31.1.bb
index 955862fddb..588708fc31 100644
--- a/meta/recipes-support/nss/nss_3.31.1.bb
+++ b/meta/recipes-support/nss/nss_3.31.1.bb
@@ -66,8 +66,8 @@ do_compile_prepend_class-native() {
 
 do_compile() {
 export CROSS_COMPILE=1
-export NATIVE_CC="gcc"
-export NATIVE_FLAGS="${HOST_CFLAGS}"
+export NATIVE_CC="${BUILD_CC}"
+export NATIVE_FLAGS="${BUILD_CFLAGS}"
 export BUILD_OPT=1
 
 export FREEBL_NO_DEPEND=1
@@ -118,7 +118,7 @@ do_install_prepend_class-nativesdk() {
 
 do_install() {
 export CROSS_COMPILE=1
-export NATIVE_CC="gcc"
+export NATIVE_CC="${BUILD_CC}"
 export BUILD_OPT=1
 
 export FREEBL_NO_DEPEND=1
-- 
2.14.2

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