[OE-core] [PATCH] glibc: Set libc_cv_ssp_all to no as well

2018-04-12 Thread Khem Raj 
This is not a problem right now but if we
were to use -fstack-protector-all this can
cause build errors

Signed-off-by: Khem Raj 
---
 meta/recipes-core/glibc/glibc.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/glibc/glibc.inc 
b/meta/recipes-core/glibc/glibc.inc
index 9e02ffdff1..ce1222be68 100644
--- a/meta/recipes-core/glibc/glibc.inc
+++ b/meta/recipes-core/glibc/glibc.inc
@@ -50,6 +50,7 @@ CACHED_CONFIGUREVARS += " \
   libc_cv_rootsbindir=${base_sbindir} \
   libc_cv_localedir=${localedir} \
   libc_cv_ssp_strong=no \
+  libc_cv_ssp_all=no \
   libc_cv_ssp=no \
 "
 
-- 
2.17.0

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

[OE-core] [pyro][PATCH 2/2 v2] gdb: fix header ordering for TRAP_HWBKPT

2018-04-12 Thread Daniel Díaz 
This error can appear in gdb/nat/linux-ptrace.c because of
the order in which some headers are processed:
| In file included from ../../gdb-7.11.1/gdb/nat/linux-ptrace.c:20:0:
| ../../gdb-7.11.1/gdb/nat/linux-ptrace.h:175:22: error: expected identifier 
before numeric constant
|  # define TRAP_HWBKPT 4
|   ^
| Makefile:2357: recipe for target 'linux-ptrace.o' failed
| make[2]: *** [linux-ptrace.o] Error 1
| make[2]: *** Waiting for unfinished jobs
| make[2]: Leaving directory 
'/oe/build/tmp-rpb-glibc/work/aarch64-linaro-linux/gdb/7.11.1-r0/build-aarch64-linaro-linux/gdb'
| Makefile:8822: recipe for target 'all-gdb' failed
| make[1]: *** [all-gdb] Error 2
| make[1]: Leaving directory 
'/oe/build/tmp-rpb-glibc/work/aarch64-linaro-linux/gdb/7.11.1-r0/build-aarch64-linaro-linux'
| Makefile:846: recipe for target 'all' failed
| make: *** [all] Error 2

A patch from GDB's current master solves the issue.

(From OE-Core rev: 4aaf747099714ec11158571527396ed9e818729e)

Signed-off-by: Daniel Díaz 
Signed-off-by: Ross Burton 
---
v2: Add signed-off-by to patch.

 meta/recipes-devtools/gdb/gdb-7.12.1.inc   |  1 +
 ...4-defining-TRAP_HWBKPT-before-including-g.patch | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/gdb-Fix-ia64-defining-TRAP_HWBKPT-before-including-g.patch

diff --git a/meta/recipes-devtools/gdb/gdb-7.12.1.inc 
b/meta/recipes-devtools/gdb/gdb-7.12.1.inc
index 634756c..1d81185 100644
--- a/meta/recipes-devtools/gdb/gdb-7.12.1.inc
+++ b/meta/recipes-devtools/gdb/gdb-7.12.1.inc
@@ -16,6 +16,7 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://0009-Change-order-of-CFLAGS.patch \
file://0010-resolve-restrict-keyword-conflict.patch \
file://package_devel_gdb_patches_120-sigprocmask-invalid-call.patch 
\
+   file://gdb-Fix-ia64-defining-TRAP_HWBKPT-before-including-g.patch \
 "
 SRC_URI[md5sum] = "193453347ddced7acb6b1cd2ee8f2e4b"
 SRC_URI[sha256sum] = 
"4607680b973d3ec92c30ad029f1b7dbde3876869e6b3a117d8a7e90081113186"
diff --git 
a/meta/recipes-devtools/gdb/gdb/gdb-Fix-ia64-defining-TRAP_HWBKPT-before-including-g.patch
 
b/meta/recipes-devtools/gdb/gdb/gdb-Fix-ia64-defining-TRAP_HWBKPT-before-including-g.patch
new file mode 100644
index 000..9bf99f6
--- /dev/null
+++ 
b/meta/recipes-devtools/gdb/gdb/gdb-Fix-ia64-defining-TRAP_HWBKPT-before-including-g.patch
@@ -0,0 +1,53 @@
+From 49bd068c3acf376a3018c0ebd849bf7f72a1874d Mon Sep 17 00:00:00 2001
+From: James Clarke 
+Date: Fri, 19 Jan 2018 17:22:49 +
+Subject: [PATCH] gdb: Fix ia64 defining TRAP_HWBKPT before including
+ gdb_wait.h
+
+On ia64, gdb_wait.h eventually includes siginfo-consts-arch.h, which
+contains an enum with TRAP_HWBKPT, along with a #define. Thus we cannot
+define TRAP_HWBKPT to 4 beforehand, and so gdb_wait.h must be included
+earlier; include it from linux-ptrace.h so it can never come afterwards.
+
+gdb/ChangeLog:
+
+   * nat/linux-ptrace.c: Remove unnecessary reinclusion of
+   gdb_ptrace.h, and move including gdb_wait.h ...
+   * nat/linux-ptrace.h: ... to here.
+
+Upstream-Status: Accepted 
[https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5a6c3296a7a90694ad4042f6256f3da6d4fa4ee8]
+
+Signed-off-by: Daniel Díaz 
+---
+ gdb/nat/linux-ptrace.c | 2 --
+ gdb/nat/linux-ptrace.h | 1 +
+ 2 files changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/gdb/nat/linux-ptrace.c b/gdb/nat/linux-ptrace.c
+index 3447e07..dd3310e 100644
+--- a/gdb/nat/linux-ptrace.c
 b/gdb/nat/linux-ptrace.c
+@@ -21,8 +21,6 @@
+ #include "linux-procfs.h"
+ #include "linux-waitpid.h"
+ #include "buffer.h"
+-#include "gdb_wait.h"
+-#include "gdb_ptrace.h"
+ #include 
+ 
+ /* Stores the ptrace options supported by the running kernel.
+diff --git a/gdb/nat/linux-ptrace.h b/gdb/nat/linux-ptrace.h
+index 5954945..6faa89b 100644
+--- a/gdb/nat/linux-ptrace.h
 b/gdb/nat/linux-ptrace.h
+@@ -21,6 +21,7 @@
+ struct buffer;
+ 
+ #include "nat/gdb_ptrace.h"
++#include "gdb_wait.h"
+ 
+ #ifdef __UCLIBC__
+ #if !(defined(__UCLIBC_HAS_MMU__) || defined(__ARCH_HAS_MMU__))
+-- 
+2.7.4
+
-- 
2.7.4

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

[OE-core] [pyro][PATCH 1/2 v2] glibc: add missing TRAP_BRANCH/TRAP_HWBKPT definitions

2018-04-12 Thread Daniel Díaz 
From: Fathi Boudra 

Patch submitted upstream, pending to be merged:
https://sourceware.org/bugzilla/show_bug.cgi?id=21286

(From OE-Core rev: 11ebb5054e5ec1171ade90249e3a30ac8174a35a)

Signed-off-by: Fathi Boudra 
Signed-off-by: Daniel Díaz 
Signed-off-by: Ross Burton 
---
v2: No changes.

 ...o.h-enum-definition-for-TRAP_HWBKPT-is-mi.patch | 68 ++
 meta/recipes-core/glibc/glibc_2.25.bb  |  1 +
 2 files changed, 69 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0029-bits-siginfo.h-enum-definition-for-TRAP_HWBKPT-is-mi.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0029-bits-siginfo.h-enum-definition-for-TRAP_HWBKPT-is-mi.patch
 
b/meta/recipes-core/glibc/glibc/0029-bits-siginfo.h-enum-definition-for-TRAP_HWBKPT-is-mi.patch
new file mode 100644
index 000..bef8887
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0029-bits-siginfo.h-enum-definition-for-TRAP_HWBKPT-is-mi.patch
@@ -0,0 +1,68 @@
+From 297aca56465035dce1f7b91b5cdda54379141957 Mon Sep 17 00:00:00 2001
+From: Pratyush Anand 
+Date: Wed, 22 Mar 2017 17:02:38 +0530
+Subject: [PATCH] bits/siginfo.h: enum definition for TRAP_HWBKPT is missing
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Compile following linux kernel test code with latest glibc:
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
+
+and we get following error:
+breakpoint_test_arm64.c: In function ‘run_test’:
+breakpoint_test_arm64.c:171:25: error: ‘TRAP_HWBKPT’ undeclared (first use in 
this function)
+  if (siginfo.si_code != TRAP_HWBKPT) {
+ ^
+I can compile test code by modifying my local
+/usr/include/bits/siginfo.h and test works great. Therefore, this patch
+will be needed in upstream glibc so that issue is fixed there as well.
+
+Signed-off-by: Pratyush Anand 
+
+Upstream-Status: Submitted 
[https://sourceware.org/bugzilla/show_bug.cgi?id=21286]
+---
+ bits/siginfo.h | 6 +-
+ sysdeps/unix/sysv/linux/bits/siginfo.h | 6 +-
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/bits/siginfo.h b/bits/siginfo.h
+index 4919df5..6dc714e 100644
+--- a/bits/siginfo.h
 b/bits/siginfo.h
+@@ -140,8 +140,12 @@ enum
+ {
+   TRAP_BRKPT = 1, /* Process breakpoint.  */
+ #  define TRAP_BRKPT  TRAP_BRKPT
+-  TRAP_TRACE  /* Process trace trap.  */
++  TRAP_TRACE, /* Process trace trap.  */
+ #  define TRAP_TRACE  TRAP_TRACE
++  TRAP_BRANCH,/* Process branch trap. */
++# define TRAP_BRANCH  TRAP_BRANCH
++  TRAP_HWBKPT /* hardware breakpoint/watchpoint  */
++# define TRAP_HWBKPT  TRAP_HWBKPT
+ };
+ # endif
+ 
+diff --git a/sysdeps/unix/sysv/linux/bits/siginfo.h 
b/sysdeps/unix/sysv/linux/bits/siginfo.h
+index 7b0d4f6..9cdf42a 100644
+--- a/sysdeps/unix/sysv/linux/bits/siginfo.h
 b/sysdeps/unix/sysv/linux/bits/siginfo.h
+@@ -235,8 +235,12 @@ enum
+ {
+   TRAP_BRKPT = 1, /* Process breakpoint.  */
+ #  define TRAP_BRKPT  TRAP_BRKPT
+-  TRAP_TRACE  /* Process trace trap.  */
++  TRAP_TRACE, /* Process trace trap.  */
+ #  define TRAP_TRACE  TRAP_TRACE
++  TRAP_BRANCH,/* Process branch trap. */
++# define TRAP_BRANCH  TRAP_BRANCH
++  TRAP_HWBKPT /* hardware breakpoint/watchpoint  */
++# define TRAP_HWBKPT  TRAP_HWBKPT
+ };
+ # endif
+ 
+-- 
+2.7.4
+
diff --git a/meta/recipes-core/glibc/glibc_2.25.bb 
b/meta/recipes-core/glibc/glibc_2.25.bb
index 58b90b7..49fcf0c 100644
--- a/meta/recipes-core/glibc/glibc_2.25.bb
+++ b/meta/recipes-core/glibc/glibc_2.25.bb
@@ -43,6 +43,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \

file://0026-elf-dl-deps.c-Make-_dl_build_local_scope-breadth-fir.patch \
file://0027-locale-fix-hard-coded-reference-to-gcc-E.patch \
file://0028-Rework-fno-omit-frame-pointer-support-on-i386.patch \
+   
file://0029-bits-siginfo.h-enum-definition-for-TRAP_HWBKPT-is-mi.patch \
 "
 
 NATIVESDKFIXES ?= ""
-- 
2.7.4

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

[OE-core] [PATCH] glib-2.0/glib.inc: fix broken mingw build

2018-04-12 Thread Juro Bystricky 
mingw build was broken by the commit:
"glib-2.0/glib.inc: apply MLPREFIX renaming to all package classes"

When building for mingw, we encounter build errors such as:

  mv: cannot stat '/<...>/usr/libexec/gio-querymodules': No such file 
or directory

The file that exists is actually "gio-querymodules.exe", but still there is no
good reason to rename it to "nativesdk-gio-querymodules.exe".
So for mingw we simply avoid renaming of the executable, by skippng the line:

  mv -v ${D}${libexecdir}/gio-querymodules 
${D}${libexecdir}/${MLPREFIX}gio-querymodules

[YOCTO #12679]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-core/glib-2.0/glib.inc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index b7c32e6..92ac19e 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -91,6 +91,9 @@ USE_NLS_class-target = "yes"
 USE_NLS_class-nativesdk = "yes"
 CACHED_CONFIGUREVARS_append_class-native = " ac_cv_path_MSGFMT=/bin/false"
 
+EXEEXT = ""
+EXEEXT_mingw32 = ".exe"
+
 do_install_append () {
if [ -f ${D}${bindir}/gtester-report ]; then
sed ${D}${bindir}/gtester-report -i -e '1s|^#!.*|#!/usr/bin/env 
python3|'
@@ -106,7 +109,7 @@ do_install_append () {
fi
 
 # Make sure gio-querymodules is unique among multilibs
-if test "x${MLPREFIX}" != "x"; then
+if test "x${MLPREFIX}" != "x" && test "${EXEEXT}" != ".exe"; then
 mv ${D}${libexecdir}/gio-querymodules 
${D}${libexecdir}/${MLPREFIX}gio-querymodules
 fi
 }
-- 
2.7.4

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

Re: [OE-core] kernel menuconfig broken?

2018-04-12 Thread Andreas Müller 
On Thu, Apr 12, 2018 at 11:46 PM, Andreas Müller
 wrote:
> On Thu, Apr 12, 2018 at 11:38 PM, Cal Sullivan
>  wrote:
>> If you're using a non-linux-yocto kernel you likely need to apply this patch
>> to your kernel as well:
>>
>> https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/recipes-kernel/linux/linux-intel/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch
> Correct: RaspberryPi kernel
>>
>> (This is in all linux-yocto kernels, I'm only linking to meta-intel because
>> I knew where it was off the top of my head)
>>
>> This was sent upstream but last I looked it didn't gain any traction. I
>> think Bruce resent it recently but I can't be sure.
>>
>> Thanks,
>> Cal
>>
> That looks very promising - will try and let you know - thanks in advance :)
>
Perfect! - Thanks Cal for quick help!

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

Re: [OE-core] kernel menuconfig broken?

2018-04-12 Thread Andreas Müller 
On Thu, Apr 12, 2018 at 11:38 PM, Cal Sullivan
 wrote:
> If you're using a non-linux-yocto kernel you likely need to apply this patch
> to your kernel as well:
>
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/recipes-kernel/linux/linux-intel/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch
Correct: RaspberryPi kernel
>
> (This is in all linux-yocto kernels, I'm only linking to meta-intel because
> I knew where it was off the top of my head)
>
> This was sent upstream but last I looked it didn't gain any traction. I
> think Bruce resent it recently but I can't be sure.
>
> Thanks,
> Cal
>
That looks very promising - will try and let you know - thanks in advance :)

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

Re: [OE-core] kernel menuconfig broken?

2018-04-12 Thread Cal Sullivan 
If you're using a non-linux-yocto kernel you likely need to apply this 
patch to your kernel as well:


https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/recipes-kernel/linux/linux-intel/0001-menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch

(This is in all linux-yocto kernels, I'm only linking to meta-intel 
because I knew where it was off the top of my head)


This was sent upstream but last I looked it didn't gain any traction. I 
think Bruce resent it recently but I can't be sure.


Thanks,
Cal

On 04/12/2018 01:28 PM, Andreas Müller wrote:

On Mon, Apr 2, 2018 at 11:57 PM, Trevor Woerner  wrote:

On Sun 2018-04-01 @ 11:49:58 PM, Andreas Müller wrote:

When running bitbake -cmenuconfig virtual/kernel I get a flood of
undefined reference errors. Am I alone here?

Sadly, I think you might be.

 $ bitbake virtual/kernel -c menuconfig

works fine for me.

I assume you're doing this for something RaspberryPi-ish?

 Build Configuration:
 BB_VERSION   = "1.37.0"
 BUILD_SYS= "x86_64-linux"
 NATIVELSBSTRING  = "opensuse-42.3"
 TARGET_SYS   = "arm-oe-linux-gnueabi"
 MACHINE  = "raspberrypi3"
 DISTRO   = "nodistro"
 DISTRO_VERSION   = "nodistro.0"
 TUNE_FEATURES= "arm armv7ve vfp thumb neon vfpv4 
callconvention-hard cortexa7"
 TARGET_FPU   = "hard"
 meta-raspberrypi = 
"master:63e53f919089027259a513dc2cd4b140789bf1a3"
 meta = 
"master:4cedddb83623c79980b354642dfeaf78218ca4b7"
 meta-oe
 meta-gnome
 meta-python
 meta-networking
 meta-multimedia  = 
"master:b9d1d8718834f7287e5a65373b952cbfe9ce83fe"
 meta-qt5 = 
"master:e60e849de1158c879bd2c150fe79b207cdac031a"
 meta-qt5-extra   = 
"master:a0cf057b2f335e8d2be9180f20770773334ec209"
 meta-realtime= 
"master:250bc6eaa47e550c1db5e2b0ebd42d86ee43650e"
 meta-browser = 
"master:d1c902440cba26a9d1271cfb914633c68ee3791c"

OK I found that I am not alone [1] and followed the suggestion to
install ncurses-devel. Strange: it install ncurses-libs x86_64. Now I
have back menuconfig but it looks horrible: All framing chars are
displayed as '@'. If I remember correct there was such an issue long
lime ago.

However it is not beautiful but I can work with it.

[1] https://github.com/crops/poky-container/issues/17

Andreas


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

Re: [OE-core] kernel menuconfig broken?

2018-04-12 Thread Andreas Müller 
On Thu, Apr 12, 2018 at 11:19 PM, Cal Sullivan
 wrote:
> Fixed by this hopefully?
>
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=sumo=d5075b648b06d3120fc7e4c47ccda3d620754590
>
> Thanks,
> Cal
I am sitting on sumo -21 commits so it is included in my builds - sigh..

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

Re: [OE-core] kernel menuconfig broken?

2018-04-12 Thread Cal Sullivan 

Fixed by this hopefully?

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=sumo=d5075b648b06d3120fc7e4c47ccda3d620754590

Thanks,
Cal

On 04/12/2018 01:28 PM, Andreas Müller wrote:

On Mon, Apr 2, 2018 at 11:57 PM, Trevor Woerner  wrote:

On Sun 2018-04-01 @ 11:49:58 PM, Andreas Müller wrote:

When running bitbake -cmenuconfig virtual/kernel I get a flood of
undefined reference errors. Am I alone here?

Sadly, I think you might be.

 $ bitbake virtual/kernel -c menuconfig

works fine for me.

I assume you're doing this for something RaspberryPi-ish?

 Build Configuration:
 BB_VERSION   = "1.37.0"
 BUILD_SYS= "x86_64-linux"
 NATIVELSBSTRING  = "opensuse-42.3"
 TARGET_SYS   = "arm-oe-linux-gnueabi"
 MACHINE  = "raspberrypi3"
 DISTRO   = "nodistro"
 DISTRO_VERSION   = "nodistro.0"
 TUNE_FEATURES= "arm armv7ve vfp thumb neon vfpv4 
callconvention-hard cortexa7"
 TARGET_FPU   = "hard"
 meta-raspberrypi = 
"master:63e53f919089027259a513dc2cd4b140789bf1a3"
 meta = 
"master:4cedddb83623c79980b354642dfeaf78218ca4b7"
 meta-oe
 meta-gnome
 meta-python
 meta-networking
 meta-multimedia  = 
"master:b9d1d8718834f7287e5a65373b952cbfe9ce83fe"
 meta-qt5 = 
"master:e60e849de1158c879bd2c150fe79b207cdac031a"
 meta-qt5-extra   = 
"master:a0cf057b2f335e8d2be9180f20770773334ec209"
 meta-realtime= 
"master:250bc6eaa47e550c1db5e2b0ebd42d86ee43650e"
 meta-browser = 
"master:d1c902440cba26a9d1271cfb914633c68ee3791c"

OK I found that I am not alone [1] and followed the suggestion to
install ncurses-devel. Strange: it install ncurses-libs x86_64. Now I
have back menuconfig but it looks horrible: All framing chars are
displayed as '@'. If I remember correct there was such an issue long
lime ago.

However it is not beautiful but I can work with it.

[1] https://github.com/crops/poky-container/issues/17

Andreas


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

Re: [OE-core] kernel menuconfig broken?

2018-04-12 Thread Andreas Müller 
On Mon, Apr 2, 2018 at 11:57 PM, Trevor Woerner  wrote:
> On Sun 2018-04-01 @ 11:49:58 PM, Andreas Müller wrote:
>> When running bitbake -cmenuconfig virtual/kernel I get a flood of
>> undefined reference errors. Am I alone here?
>
> Sadly, I think you might be.
>
> $ bitbake virtual/kernel -c menuconfig
>
> works fine for me.
>
> I assume you're doing this for something RaspberryPi-ish?
>
> Build Configuration:
> BB_VERSION   = "1.37.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "opensuse-42.3"
> TARGET_SYS   = "arm-oe-linux-gnueabi"
> MACHINE  = "raspberrypi3"
> DISTRO   = "nodistro"
> DISTRO_VERSION   = "nodistro.0"
> TUNE_FEATURES= "arm armv7ve vfp thumb neon vfpv4 
> callconvention-hard cortexa7"
> TARGET_FPU   = "hard"
> meta-raspberrypi = 
> "master:63e53f919089027259a513dc2cd4b140789bf1a3"
> meta = 
> "master:4cedddb83623c79980b354642dfeaf78218ca4b7"
> meta-oe
> meta-gnome
> meta-python
> meta-networking
> meta-multimedia  = 
> "master:b9d1d8718834f7287e5a65373b952cbfe9ce83fe"
> meta-qt5 = 
> "master:e60e849de1158c879bd2c150fe79b207cdac031a"
> meta-qt5-extra   = 
> "master:a0cf057b2f335e8d2be9180f20770773334ec209"
> meta-realtime= 
> "master:250bc6eaa47e550c1db5e2b0ebd42d86ee43650e"
> meta-browser = 
> "master:d1c902440cba26a9d1271cfb914633c68ee3791c"
OK I found that I am not alone [1] and followed the suggestion to
install ncurses-devel. Strange: it install ncurses-libs x86_64. Now I
have back menuconfig but it looks horrible: All framing chars are
displayed as '@'. If I remember correct there was such an issue long
lime ago.

However it is not beautiful but I can work with it.

[1] https://github.com/crops/poky-container/issues/17

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

Re: [OE-core] [PATCH] meta-oe/numactl: Enable NUMA in the kernel config

2018-04-12 Thread Khem Raj 
On Thu, Apr 12, 2018 at 11:26 AM, Alistair Francis  wrote:
> On Thu, Apr 12, 2018 at 8:49 AM, Khem Raj  wrote:
>> On 4/10/18 10:09 AM, Alistair Francis wrote:
>>> If a user has specified numa in their DISTRO_FEATURES then they should
>>> have NUMA support enabled in the kernel. Without kernel support the
>>> numactl program is not very useful.
>>>
>>
>> This should be done in OE-Core as part of main recipe.
>
> Do you mean in core linux-yocto
> (meta/recipes-kernel/linux/linux-yocto.inc)? That seemed a little odd
> to me as the numactl package comes from the meta-oe layer. I was
> thinking it made sense to keep them together.
>

its controlled by a distro feature which would add right knobs to it in core.
it wont be changing any functionality therefore and hence would be ok

> Alistair
>
>>
>> Note that this patch is sent to oe-core ml but is actually against
>> meta-oe layer which follows oe-devel mailing list.
>>
>>> Signed-off-by: Alistair Francis 
>>> ---
>>>  meta-oe/recipes-kernel/linux/linux-yocto.inc   | 2 ++
>>>  meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend | 1 +
>>>  meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend | 1 +
>>>  meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend | 1 +
>>>  meta-oe/recipes-support/numactl/numactl/numa.cfg   | 2 ++
>>>  meta-oe/recipes-support/numactl/numactl_git.bb | 1 +
>>>  6 files changed, 8 insertions(+)
>>>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto.inc
>>>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
>>>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
>>>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
>>>  create mode 100644 meta-oe/recipes-support/numactl/numactl/numa.cfg
>>>
>>> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto.inc 
>>> b/meta-oe/recipes-kernel/linux/linux-yocto.inc
>>> new file mode 100644
>>> index 000..9533eb6
>>> --- /dev/null
>>> +++ b/meta-oe/recipes-kernel/linux/linux-yocto.inc
>>> @@ -0,0 +1,2 @@
>>> +KERNEL_FEATURES_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'numa', 
>>> 'features/numa/numa.scc', '', d)}"
>>> +
>>> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend 
>>> b/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
>>> new file mode 100644
>>> index 000..161f9d3
>>> --- /dev/null
>>> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
>>> @@ -0,0 +1 @@
>>> +require linux-yocto.inc
>>> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend 
>>> b/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
>>> new file mode 100644
>>> index 000..161f9d3
>>> --- /dev/null
>>> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
>>> @@ -0,0 +1 @@
>>> +require linux-yocto.inc
>>> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend 
>>> b/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
>>> new file mode 100644
>>> index 000..161f9d3
>>> --- /dev/null
>>> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
>>> @@ -0,0 +1 @@
>>> +require linux-yocto.inc
>>> diff --git a/meta-oe/recipes-support/numactl/numactl/numa.cfg 
>>> b/meta-oe/recipes-support/numactl/numactl/numa.cfg
>>> new file mode 100644
>>> index 000..fe1394d
>>> --- /dev/null
>>> +++ b/meta-oe/recipes-support/numactl/numactl/numa.cfg
>>> @@ -0,0 +1,2 @@
>>> +CONFIG_NUMA=y
>>> +CONFIG_ACPI_NUMA=y
>>> diff --git a/meta-oe/recipes-support/numactl/numactl_git.bb 
>>> b/meta-oe/recipes-support/numactl/numactl_git.bb
>>> index b9cbcf0..ef2dab2 100644
>>> --- a/meta-oe/recipes-support/numactl/numactl_git.bb
>>> +++ b/meta-oe/recipes-support/numactl/numactl_git.bb
>>> @@ -21,6 +21,7 @@ SRC_URI = "git://github.com/numactl/numactl \
>>>  file://run-ptest \
>>>  file://0001-define-run-test-target.patch \
>>>  "
>>> +SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'numa', ' 
>>> file://numa.cfg', '', d)}"
>>>
>>>  S = "${WORKDIR}/git"
>>>
>>>
>>
>> --
>> ___
>> 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] [PATCH] meta-oe/numactl: Enable NUMA in the kernel config

2018-04-12 Thread Alistair Francis 
On Thu, Apr 12, 2018 at 8:49 AM, Khem Raj  wrote:
> On 4/10/18 10:09 AM, Alistair Francis wrote:
>> If a user has specified numa in their DISTRO_FEATURES then they should
>> have NUMA support enabled in the kernel. Without kernel support the
>> numactl program is not very useful.
>>
>
> This should be done in OE-Core as part of main recipe.

Do you mean in core linux-yocto
(meta/recipes-kernel/linux/linux-yocto.inc)? That seemed a little odd
to me as the numactl package comes from the meta-oe layer. I was
thinking it made sense to keep them together.

Alistair

>
> Note that this patch is sent to oe-core ml but is actually against
> meta-oe layer which follows oe-devel mailing list.
>
>> Signed-off-by: Alistair Francis 
>> ---
>>  meta-oe/recipes-kernel/linux/linux-yocto.inc   | 2 ++
>>  meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend | 1 +
>>  meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend | 1 +
>>  meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend | 1 +
>>  meta-oe/recipes-support/numactl/numactl/numa.cfg   | 2 ++
>>  meta-oe/recipes-support/numactl/numactl_git.bb | 1 +
>>  6 files changed, 8 insertions(+)
>>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto.inc
>>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
>>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
>>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
>>  create mode 100644 meta-oe/recipes-support/numactl/numactl/numa.cfg
>>
>> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto.inc 
>> b/meta-oe/recipes-kernel/linux/linux-yocto.inc
>> new file mode 100644
>> index 000..9533eb6
>> --- /dev/null
>> +++ b/meta-oe/recipes-kernel/linux/linux-yocto.inc
>> @@ -0,0 +1,2 @@
>> +KERNEL_FEATURES_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'numa', 
>> 'features/numa/numa.scc', '', d)}"
>> +
>> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend 
>> b/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
>> new file mode 100644
>> index 000..161f9d3
>> --- /dev/null
>> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
>> @@ -0,0 +1 @@
>> +require linux-yocto.inc
>> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend 
>> b/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
>> new file mode 100644
>> index 000..161f9d3
>> --- /dev/null
>> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
>> @@ -0,0 +1 @@
>> +require linux-yocto.inc
>> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend 
>> b/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
>> new file mode 100644
>> index 000..161f9d3
>> --- /dev/null
>> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
>> @@ -0,0 +1 @@
>> +require linux-yocto.inc
>> diff --git a/meta-oe/recipes-support/numactl/numactl/numa.cfg 
>> b/meta-oe/recipes-support/numactl/numactl/numa.cfg
>> new file mode 100644
>> index 000..fe1394d
>> --- /dev/null
>> +++ b/meta-oe/recipes-support/numactl/numactl/numa.cfg
>> @@ -0,0 +1,2 @@
>> +CONFIG_NUMA=y
>> +CONFIG_ACPI_NUMA=y
>> diff --git a/meta-oe/recipes-support/numactl/numactl_git.bb 
>> b/meta-oe/recipes-support/numactl/numactl_git.bb
>> index b9cbcf0..ef2dab2 100644
>> --- a/meta-oe/recipes-support/numactl/numactl_git.bb
>> +++ b/meta-oe/recipes-support/numactl/numactl_git.bb
>> @@ -21,6 +21,7 @@ SRC_URI = "git://github.com/numactl/numactl \
>>  file://run-ptest \
>>  file://0001-define-run-test-target.patch \
>>  "
>> +SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'numa', ' 
>> file://numa.cfg', '', d)}"
>>
>>  S = "${WORKDIR}/git"
>>
>>
>
> --
> ___
> 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] [PATCH] xserver-nodm-init: Respawn service in case of failure

2018-04-12 Thread Nicolas Dechesne 
On Thu, Apr 12, 2018 at 5:55 PM, Khem Raj  wrote:
> On 4/10/18 12:48 PM, Nicolas Dechesne wrote:
>> On Tue, Apr 10, 2018 at 1:20 PM, Ramon Fried  wrote:
>>> From: Ramon Fried 
>>>
>>> It appears that sometimes xserver-nodm.service is starting before
>>> display driver finished loading causing the following failure in
>>> Xorg log:
>>> (EE) open /dev/dri/card0: No such file or directory
>>>
>>> The introduced by this patch is to restart the service,
>>> hopefully the display driver will finish loading.
>>>
>>> Signed-off-by: Ramon Fried 
>>
>> we are seeing this issue on Dragonboard with meta-qcom BSP, where all
>> drivers needed for display/gpu are modules, so the display
>> initialization comes up 'late' in the boot. I had a discussion with
>> some upstream gnome folks who indicated that a similar race can be
>> observed on any hardware, it is not uncommon, and that's why they use
>> Restart=always in gdm.service as well, so that it keep trying until
>> the display comes up.
>>
>> it sounds reasonable change to me.
>
> Restarting service always seems like a workaround here. I wonder if the
> kernel modules tied themselves to systemd-modules-load.service then the
> dependencies should
> sort themselves out. Alternatively we can also create a dependency on
> device being made available.

I would tend to agree that restart is a workaround, but since
gdm.service does that too, i thought it wasn't so bad..

we tried with a udev rule like that:

ACTION=="add", SUBSYSTEM=="drm", KERNEL=="card0", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="xserver-nodm.service"

and it works well too.

between the two, i still prefer the restart=always..

>
>>
>> Reviewed-by: Nicolas Dechesne 
>>
>>> ---
>>>  .../x11-common/xserver-nodm-init/xserver-nodm.service.in | 
>>> 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git 
>>> a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>>>  
>>> b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>>> index 324a26f549..87dc4f8fcd 100644
>>> --- 
>>> a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>>> +++ 
>>> b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>>> @@ -5,6 +5,7 @@ Description=Xserver startup without a display manager
>>>  EnvironmentFile=/etc/default/xserver-nodm
>>>  User=@USER@
>>>  ExecStart=/etc/xserver-nodm/Xserver
>>> +Restart=always
>>>
>>>  [Install]
>>>  Alias=display-manager.service
>>> --
>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] xserver-nodm-init: Respawn service in case of failure

2018-04-12 Thread Khem Raj 
On 4/10/18 12:48 PM, Nicolas Dechesne wrote:
> On Tue, Apr 10, 2018 at 1:20 PM, Ramon Fried  wrote:
>> From: Ramon Fried 
>>
>> It appears that sometimes xserver-nodm.service is starting before
>> display driver finished loading causing the following failure in
>> Xorg log:
>> (EE) open /dev/dri/card0: No such file or directory
>>
>> The introduced by this patch is to restart the service,
>> hopefully the display driver will finish loading.
>>
>> Signed-off-by: Ramon Fried 
> 
> we are seeing this issue on Dragonboard with meta-qcom BSP, where all
> drivers needed for display/gpu are modules, so the display
> initialization comes up 'late' in the boot. I had a discussion with
> some upstream gnome folks who indicated that a similar race can be
> observed on any hardware, it is not uncommon, and that's why they use
> Restart=always in gdm.service as well, so that it keep trying until
> the display comes up.
> 
> it sounds reasonable change to me.

Restarting service always seems like a workaround here. I wonder if the
kernel modules tied themselves to systemd-modules-load.service then the
dependencies should
sort themselves out. Alternatively we can also create a dependency on
device being made available.

> 
> Reviewed-by: Nicolas Dechesne 
> 
>> ---
>>  .../x11-common/xserver-nodm-init/xserver-nodm.service.in | 
>> 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git 
>> a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in 
>> b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>> index 324a26f549..87dc4f8fcd 100644
>> --- 
>> a/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>> +++ 
>> b/meta/recipes-graphics/x11-common/xserver-nodm-init/xserver-nodm.service.in
>> @@ -5,6 +5,7 @@ Description=Xserver startup without a display manager
>>  EnvironmentFile=/etc/default/xserver-nodm
>>  User=@USER@
>>  ExecStart=/etc/xserver-nodm/Xserver
>> +Restart=always
>>
>>  [Install]
>>  Alias=display-manager.service
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>

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

Re: [OE-core] [PATCH] meta-oe/numactl: Enable NUMA in the kernel config

2018-04-12 Thread Khem Raj 
On 4/10/18 10:09 AM, Alistair Francis wrote:
> If a user has specified numa in their DISTRO_FEATURES then they should
> have NUMA support enabled in the kernel. Without kernel support the
> numactl program is not very useful.
> 

This should be done in OE-Core as part of main recipe.

Note that this patch is sent to oe-core ml but is actually against
meta-oe layer which follows oe-devel mailing list.

> Signed-off-by: Alistair Francis 
> ---
>  meta-oe/recipes-kernel/linux/linux-yocto.inc   | 2 ++
>  meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend | 1 +
>  meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend | 1 +
>  meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend | 1 +
>  meta-oe/recipes-support/numactl/numactl/numa.cfg   | 2 ++
>  meta-oe/recipes-support/numactl/numactl_git.bb | 1 +
>  6 files changed, 8 insertions(+)
>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto.inc
>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
>  create mode 100644 meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
>  create mode 100644 meta-oe/recipes-support/numactl/numactl/numa.cfg
> 
> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto.inc 
> b/meta-oe/recipes-kernel/linux/linux-yocto.inc
> new file mode 100644
> index 000..9533eb6
> --- /dev/null
> +++ b/meta-oe/recipes-kernel/linux/linux-yocto.inc
> @@ -0,0 +1,2 @@
> +KERNEL_FEATURES_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'numa', 
> 'features/numa/numa.scc', '', d)}"
> +
> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend 
> b/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
> new file mode 100644
> index 000..161f9d3
> --- /dev/null
> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.12.bbappend
> @@ -0,0 +1 @@
> +require linux-yocto.inc
> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend 
> b/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
> new file mode 100644
> index 000..161f9d3
> --- /dev/null
> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.14.bbappend
> @@ -0,0 +1 @@
> +require linux-yocto.inc
> diff --git a/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend 
> b/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
> new file mode 100644
> index 000..161f9d3
> --- /dev/null
> +++ b/meta-oe/recipes-kernel/linux/linux-yocto_4.15.bbappend
> @@ -0,0 +1 @@
> +require linux-yocto.inc
> diff --git a/meta-oe/recipes-support/numactl/numactl/numa.cfg 
> b/meta-oe/recipes-support/numactl/numactl/numa.cfg
> new file mode 100644
> index 000..fe1394d
> --- /dev/null
> +++ b/meta-oe/recipes-support/numactl/numactl/numa.cfg
> @@ -0,0 +1,2 @@
> +CONFIG_NUMA=y
> +CONFIG_ACPI_NUMA=y
> diff --git a/meta-oe/recipes-support/numactl/numactl_git.bb 
> b/meta-oe/recipes-support/numactl/numactl_git.bb
> index b9cbcf0..ef2dab2 100644
> --- a/meta-oe/recipes-support/numactl/numactl_git.bb
> +++ b/meta-oe/recipes-support/numactl/numactl_git.bb
> @@ -21,6 +21,7 @@ SRC_URI = "git://github.com/numactl/numactl \
>  file://run-ptest \
>  file://0001-define-run-test-target.patch \
>  "
> +SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'numa', ' 
> file://numa.cfg', '', d)}"
>  
>  S = "${WORKDIR}/git"
>  
> 

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

Re: [OE-core] [PATCH v3] package.bbclass: allow using EXCLUDE_FROM_SHLIBS for subpackages

2018-04-12 Thread Andrii Bordunov 

Another ping.

Any comments? Or could it be just applied as is?


Thank you,
Andrii

On 03/13/2018 07:25 PM, Andrii Bordunov wrote:

Ping

Rebased patch to latest master.

Regarding special value for the variable, it could be done with 
PRIVATE_LIBS to mean all libraries, I think. PRIVATE_LIBS could be set 
per-package already.

Would it be a better option?
However, EXCLUDE_FROM_SHLIBS seems to be a more proper thing to use.


Thank you,
Andrii

On 03/16/2017 05:07 PM, Andrii Bordunov wrote:

Hi Richard,

Sorry, my Python knowledge is quite basic. I'm sure it's possible to 
have a (global?) EXCLUDE_FROM_SHLIBS list holding subpackage names, 
but how it could lead to performance improvement? It would also need 
some check for every subpackage.

Could you please give more details?
And what do you mean under "all packages"? The intent is like 
opposite, to split package operations, not to gather.


As for False parameter to getVar, OK, I just used existing 
EXCLUDE_FROM_SHLIBS example (seems fixed now).


In the meantime tried to make a quick and dirty profiling like following:

   bitbake -c package glibc
   bitbake -c clean glibc
   python -m cProfile -s cumtime 
/mnt/src/oe/distro/bitbake/bin/bitbake -c package glibc > result.txt


Result is below. If got it right, there are 3833 getVar calls with 
total time 0.025 second (including subcalls).
This gives ~6.5 microsecond duration of one call (incl subcalls). Not 
a lot.

This is only a partial rebuild of one package of course.
Also tried to do all of this with and without my patch, but getVar 
calls number stays exactly the same (w/o modifying glibc recipe, but 
anyway).


   NOTE: Tasks Summary: Attempted 314 tasks of which 314 didn't need 
to be rerun and all succeeded.
    672869 function calls (667640 primitive calls) in 12.912 
seconds

  Ordered by: cumulative time
  ncalls  tottime  percall  cumtime  percall 
filename:lineno(function)

   1    0.001    0.001   12.913   12.913 bitbake:25()
   1    0.001    0.001   12.082   12.082 
main.py:320(bitbake_main)

   1    0.005    0.005   11.494   11.494 knotty.py:253(main)
 250   11.476    0.046   11.476    0.046 {method 'poll' of 
'_multiprocessing.Connection' objects}

   ...
   4481/4046    0.007    0.000    0.026    0.000 
data_smart.py:666(getVarFlag)

   ...
   3833/3719    0.002    0.000    0.025    0.000 
data_smart.py:569(getVar)

   ...
    1338    0.002    0.000    0.003    0.000 
data_smart.py:805(getVarFlags)




Thank you,
Andrii

On 16.11.16 12:47, Richard Purdie wrote:

On Mon, 2016-10-10 at 20:02 +0300, Andrii Bordunov wrote:

Some packages containing shared libraries might be registered
as shlib providers when they shouldn't (for example, the lib is for
their private use and must not generate any dependency).

EXCLUDE_FROM_SHLIBS is targeted at that, but it could be set
for entire recipe only.

This patch expands EXCLUDE_FROM_SHLIBS usage, so now it's possible
to set it in a style similar with RDEPENDS. For example:
 EXCLUDE_FROM_SHLIBS_${PN}-ptest = "1"

Signed-off-by: Andrii Bordunov 
---
 meta/classes/package.bbclass | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)


My main concern here is actually performance. For a package with many
sub packages you just added many calls to getVar when that getVar is
extremely unlikely to find any value. Whilst not hugely slow, that
operation isn't trivial and hard to fix later.

I'm wondering if we could support the syntax

EXCLUDE_FROM_SHLIBS = "${PN}-ptest"

and then have "1", used in a couple of places as the special value to
mean all packages?

Also please use False, not 0 as the parameter to getVar.

Cheers,

Richard


--

From 4a33d384a72a351bad5a98e46a7c9c1c9755635e Mon Sep 17 00:00:00 2001
From: Andrii Bordunov 
Date: Mon, 12 Mar 2018 08:13:44 -0700
Subject: [PATCH v3] Allow EXCLUDE_FROM_SHLIBS to be specified for
subpackages

Some subpackages containing shared libraries might be registered
as shlib providers when they shouldn't (the lib is for their private use
and must not generate any dependency).

EXCLUDE_FROM_SHLIBS is targeted at that, but it could be set
for entire recipe only.

This patch expands EXCLUDE_FROM_SHLIBS usage, so now it's possible
to set it like following:
EXCLUDE_FROM_SHLIBS_${PN}-ptest = "1"

Signed-off-by: Andrii Bordunov 
---
  meta/classes/package.bbclass | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 317c775..5d49d41 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1571,6 +1571,13 @@ python package_do_shlibs() {

  workdir = d.getVar('WORKDIR')

+shlib_pkgs = []
+for pkg in packages.split():
+if d.getVar('EXCLUDE_FROM_SHLIBS_' + pkg, False):
+bb.note("not generating shlibs for %s" % pkg)
+else:
+

Re: [OE-core] [PATCH 2/3] bind: fix openSSL detection when using multiarch

2018-04-12 Thread Koen Kooi 


> Op 11 apr. 2018, om 11:25 heeft Koen Kooi  het 
> volgende geschreven:

[..]

> There is one change that will need careful consideration if it is meant for 
> sumo, it looks like the sysroot code treats libdir differently from 
> base_libdir:
> 
>   [koen@fedora-vm build-rpb]$ ls 
> tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/lib/
>   x86_64-linux
> 
>   [koen@fedora-vm build-rpb]$ ls 
> tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/usr/lib/
>   aarch64-linaro-linux   libcomps.solibexpat.a  
> libgdbm_compat.so libgthread-2.0.so.0.5400.3  libmpc.so.3.1.0 
>   libparted-fs-resize.so.0.0.1  libpython3.so  libtermcap.so
>   [..]
>   libcheck.so.0.0.0  libelf.so.1libgdbm_compat.a
> libgthread-2.0.so.0   libmpc.so.3 
> libparted-fs-resize.so.0  libpython3.5m.so.1.0  libssl.so.1.0.2
> 
> E2fsprogs installs into base_libdir, which gets the multiarch treatment, and 
> mkfs.ext4 fails to find its libs during image generation. 

The assumption seems to have been correct, trying a build with this change:

[koen@fedora-vm openembedded-core]$ git diff
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index a911f2a..7f2df17 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -78,6 +78,7 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
 
 bindir = "${STAGING_BINDIR_NATIVE}"
 sbindir = "${STAGING_SBINDIR_NATIVE}"
+base_libdir = "${STAGING_LIBDIR_NATIVE}"
 libdir = "${STAGING_LIBDIR_NATIVE}"
 includedir = "${STAGING_INCDIR_NATIVE}"
 sysconfdir = "${STAGING_ETCDIR_NATIVE}"
@@ -89,6 +90,7 @@ export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} 
${base_libdir} /lib /lib64
 
 NATIVE_PACKAGE_PATH_SUFFIX ?= ""
 bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
+base_libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libexecdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 


regards,

Koen

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

[OE-core] [PATCH v2] dropbear: update to 2018.76

2018-04-12 Thread Andrej Valek 
- update dropbear to version 2018.76
- refresh and drop obsolete patches
- add option to use localoptions.h header file
- do not use harden stuff, which leads to QA warning

Signed-off-by: Andrej Valek 
---
 meta/recipes-core/dropbear/dropbear.inc|   8 +-
 .../0001-urandom-xauth-changes-to-options.h.patch  |  16 +--
 .../dropbear/dropbear/0003-configure.patch |  43 ---
 .../dropbear/0005-dropbear-enable-pam.patch|  40 +++---
 .../dropbear/0007-dropbear-fix-for-x32-abi.patch   | 140 -
 .../0007-fix-localoptions-search-path.patch|  51 
 .../fix-libtomcrypt-libtommath-ordering.patch  |  49 
 meta/recipes-core/dropbear/dropbear_2017.75.bb |   5 -
 meta/recipes-core/dropbear/dropbear_2018.76.bb |   5 +
 9 files changed, 92 insertions(+), 265 deletions(-)
 delete mode 100644 meta/recipes-core/dropbear/dropbear/0003-configure.patch
 delete mode 100644 
meta/recipes-core/dropbear/dropbear/0007-dropbear-fix-for-x32-abi.patch
 create mode 100644 
meta/recipes-core/dropbear/dropbear/0007-fix-localoptions-search-path.patch
 delete mode 100644 
meta/recipes-core/dropbear/dropbear/fix-libtomcrypt-libtommath-ordering.patch
 delete mode 100644 meta/recipes-core/dropbear/dropbear_2017.75.bb
 create mode 100644 meta/recipes-core/dropbear/dropbear_2018.76.bb

diff --git a/meta/recipes-core/dropbear/dropbear.inc 
b/meta/recipes-core/dropbear/dropbear.inc
index b6b436c584..16ac6442f8 100644
--- a/meta/recipes-core/dropbear/dropbear.inc
+++ b/meta/recipes-core/dropbear/dropbear.inc
@@ -14,10 +14,8 @@ DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
'libpam', '', d)}"
 
 SRC_URI = "http://matt.ucc.asn.au/dropbear/releases/dropbear-${PV}.tar.bz2 \
file://0001-urandom-xauth-changes-to-options.h.patch \
-   file://0003-configure.patch \
file://0004-fix-2kb-keys.patch \
-   file://0007-dropbear-fix-for-x32-abi.patch \
-   file://fix-libtomcrypt-libtommath-ordering.patch \
+   file://0007-fix-localoptions-search-path.patch \
file://init \
file://dropbearkey.service \
file://dropbear@.service \
@@ -52,6 +50,10 @@ PACKAGECONFIG[system-libtom] = 
"--disable-bundled-libtom,--enable-bundled-libtom
 EXTRA_OECONF += "\
  ${@bb.utils.contains('DISTRO_FEATURES', 'pam', '--enable-pam', 
'--disable-pam', d)}"
 
+# This option appends to CFLAGS and LDFLAGS from OE
+# This is causing [textrel] QA warning
+EXTRA_OECONF += "--disable-harden"
+
 do_install() {
install -d ${D}${sysconfdir} \
${D}${sysconfdir}/init.d \
diff --git 
a/meta/recipes-core/dropbear/dropbear/0001-urandom-xauth-changes-to-options.h.patch
 
b/meta/recipes-core/dropbear/dropbear/0001-urandom-xauth-changes-to-options.h.patch
index dc9d5782e8..684641dcbd 100644
--- 
a/meta/recipes-core/dropbear/dropbear/0001-urandom-xauth-changes-to-options.h.patch
+++ 
b/meta/recipes-core/dropbear/dropbear/0001-urandom-xauth-changes-to-options.h.patch
@@ -2,20 +2,20 @@ Subject: [PATCH 1/6] urandom-xauth-changes-to-options.h
 
 Upstream-Status: Inappropriate [configuration]
 ---
- options.h | 2 +-
+ default_options.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
-diff --git a/options.h b/options.h
-index 7d06322..71a21c2 100644
 a/options.h
-+++ b/options.h
-@@ -247,7 +247,7 @@ much traffic. */
+diff --git a/default_options.h b/default_options.h
+index 3b75eb8..1fd8082 100644
+--- a/default_options.h
 b/default_options.h
+@@ -243,7 +243,7 @@ Homedir is prepended unless path begins with / */
+ 
  /* The command to invoke for xauth when using X11 forwarding.
   * "-q" for quiet */
- #ifndef XAUTH_COMMAND
 -#define XAUTH_COMMAND "/usr/bin/xauth -q"
 +#define XAUTH_COMMAND "xauth -q"
- #endif
+ 
  
  /* if you want to enable running an sftp server (such as the one included with
 -- 
diff --git a/meta/recipes-core/dropbear/dropbear/0003-configure.patch 
b/meta/recipes-core/dropbear/dropbear/0003-configure.patch
deleted file mode 100644
index 8469a50eff..00
--- a/meta/recipes-core/dropbear/dropbear/0003-configure.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 58dd24a80ca0f400d0761afd9ce2b7f684fc9125 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Eric=20B=C3=A9nard?= 
-Date: Thu, 25 Apr 2013 00:27:25 +0200
-Subject: [PATCH] configure: add a variable to allow openpty check to be cached
-
-Upstream-Status: Submitted [ https://github.com/mkj/dropbear/pull/48 ]
-
-Signed-off-by: Dengke Du 

- configure.ac | 11 ---
- 1 file changed, 8 insertions(+), 3 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 893b904..245408d 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -177,15 +177,20 @@ AC_ARG_ENABLE(openpty,
-   AC_MSG_NOTICE(Not using openpty)
-   else
-   AC_MSG_NOTICE(Using openpty if available)
--