Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[Alexander Kanavin]

On Wed, 14 Aug 2019 at 13:36,  wrote:

> On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> > > I had a glance at the profile output from master-next and the
> > > problem
> > > wasn't where I thought it would be, it was in the scheduler code.
> > > That
> > > is good as those classes are effectively independent of the other
> > > changes and hence are a separate fix.
> > >
> > > I've put a patch in -next which takes the above test to 36s which
> > > is
> > > close to the older bitbake.
> > >
> > > Could be interesting to see how it looks for others and different
> > > workloads.
> >
> > I just tried the same test I did yesterday with
> > ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it doesn't
> > seem to improve things much: bitbake is stuck at "NOTE: Executing
> > Tasks" for 15 minutes now.
>
> This might sound slightly crazy but can you try commenting out this
> line in runqueue.py:
>
> logger.debug(2, "Holding off tasks %s" %
> pprint.pformat(self.holdoff_tasks))
>
> ?
>

Even crazier is the outcome: it helped! The whole thing completed after
15m49secons (with much of the time going to the empty task spin), that's
some 3 minutes slower, but certainly it's usable again.

I have not enabled the hash server at any point.

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

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[Alexander Kanavin]

On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> I had a glance at the profile output from master-next and the problem
> wasn't where I thought it would be, it was in the scheduler code. That
> is good as those classes are effectively independent of the other
> changes and hence are a separate fix.
>
> I've put a patch in -next which takes the above test to 36s which is
> close to the older bitbake.
>
> Could be interesting to see how it looks for others and different
> workloads.
>

I just tried the same test I did yesterday with
ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it doesn't seem to
improve things much: bitbake is stuck at "NOTE: Executing Tasks" for 15
minutes now.

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

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[richard . purdie]

On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> > I had a glance at the profile output from master-next and the
> > problem
> > wasn't where I thought it would be, it was in the scheduler code.
> > That
> > is good as those classes are effectively independent of the other
> > changes and hence are a separate fix.
> > 
> > I've put a patch in -next which takes the above test to 36s which
> > is
> > close to the older bitbake.
> > 
> > Could be interesting to see how it looks for others and different
> > workloads.
> 
> I just tried the same test I did yesterday with
> ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it doesn't
> seem to improve things much: bitbake is stuck at "NOTE: Executing
> Tasks" for 15 minutes now.

This might sound slightly crazy but can you try commenting out this
line in runqueue.py:

logger.debug(2, "Holding off tasks %s" % pprint.pformat(self.holdoff_tasks))

?

This was with the hash server disabled, right?

Cheers,

Richard

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

Re: [OE-core] [PATCH 1/3] linux-yocto: add drm-bochs support

[Richard Purdie]

On Wed, 2019-08-14 at 17:26 +0200, Alexander Kanavin wrote:
> This allows better modesetting support for the '-vga std'
> emulated hardware provided by Qemu, which we want to
> standardize on.
> 
> See here for background:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
> 
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
>  meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +-
>  meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb  | 2 +-
>  meta/recipes-kernel/linux/linux-yocto_4.19.bb| 2 +-
>  meta/recipes-kernel/linux/linux-yocto_5.0.bb | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)

https://autobuilder.yoctoproject.org/typhoon/#/builders/41/builds/929

Cheers,

Richard

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

[OE-core] [PATCH] systemd: Refresh patch after removal of __secure_getenv patch

[Khem Raj]

Signed-off-by: Khem Raj 
---
 .../0005-src-basic-missing.h-check-for-missing-strndupa.patch   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch
 
b/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch
index df1043b27d..47ee2795a7 100644
--- 
a/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch
+++ 
b/meta/recipes-core/systemd/systemd/0005-src-basic-missing.h-check-for-missing-strndupa.patch
@@ -76,7 +76,7 @@ Signed-off-by: Andrej Valek 
 --- a/src/basic/missing_stdlib.h
 +++ b/src/basic/missing_stdlib.h
 @@ -11,3 +11,15 @@
- #define secure_getenv getenv
+ #error "neither secure_getenv nor __secure_getenv are available"
  #  endif
  #endif
 +
-- 
2.22.0

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

[OE-core] ✗ patchtest: failure for linux-yocto/4.19: make drm-bochs feature available

[Patchwork]

== Series Details ==

Series: linux-yocto/4.19: make drm-bochs feature available
Revision: 1
URL   : https://patchwork.openembedded.org/series/19280/
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 Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 6b36db8365)



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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 1/3] musl: Update to latest tip

[Khem Raj]

Fixes build regressions on risc-v
Detailed changelog is here [1]

[1] 
https://git.musl-libc.org/cgit/musl/log/?qt=range=d0b547dfb5f7678cab6bc39dd736ed6454357ca4..29e8737f81ccc9fbadcf61a75318aa3d0516aafa

Signed-off-by: Khem Raj 
---
 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index 6425b5cd36..64aee6c448 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -4,7 +4,7 @@
 require musl.inc
 inherit linuxloader
 
-SRCREV = "d0b547dfb5f7678cab6bc39dd736ed6454357ca4"
+SRCREV = "29e8737f81ccc9fbadcf61a75318aa3d0516aafa"
 
 BASEVER = "1.1.23"
 
-- 
2.22.0

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

[OE-core] [PATCH 2/3] systemd: Drop musl __secure_getenv patch

[Khem Raj]

This API is now implemented in musl [1]

[1] 
https://git.musl-libc.org/cgit/musl/commit/?id=7844ecb590893f8344324837956718001402d297

Signed-off-by: Khem Raj 
---
 ...en-secure-versions-are-not-available.patch | 32 ---
 meta/recipes-core/systemd/systemd_242.bb  |  2 +-
 2 files changed, 1 insertion(+), 33 deletions(-)
 delete mode 100644 
meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch
 
b/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch
deleted file mode 100644
index 37979755d0..00
--- 
a/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From b8055a61b5df6b43b8d3117936587b874b0a339b Mon Sep 17 00:00:00 2001
-From: Chen Qi 
-Date: Mon, 25 Feb 2019 11:01:18 +0800
-Subject: [PATCH 01/24] Use getenv when secure versions are not available
-
-musl doesnt implement secure version, so we default
-to it if configure does not detect a secure implementation
-
-Signed-off-by: Khem Raj 
-
-Upstream-Status: Denied
-
-Signed-off-by: Chen Qi 

- src/basic/missing_stdlib.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/basic/missing_stdlib.h b/src/basic/missing_stdlib.h
-index 188a8d4..c0ffe86 100644
 a/src/basic/missing_stdlib.h
-+++ b/src/basic/missing_stdlib.h
-@@ -8,6 +8,6 @@
- #  if HAVE___SECURE_GETENV
- #define secure_getenv __secure_getenv
- #  else
--#error "neither secure_getenv nor __secure_getenv are available"
-+#define secure_getenv getenv
- #  endif
- #endif
--- 
-2.7.4
-
diff --git a/meta/recipes-core/systemd/systemd_242.bb 
b/meta/recipes-core/systemd/systemd_242.bb
index 1953fef413..6992062cef 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -32,7 +32,7 @@ SRC_URI += "file://touchscreen.rules \
 
 # patches needed by musl
 SRC_URI_append_libc-musl = " ${SRC_URI_MUSL}"
-SRC_URI_MUSL = 
"file://0001-Use-getenv-when-secure-versions-are-not-available.patch \
+SRC_URI_MUSL = "\
file://0002-don-t-use-glibc-specific-qsort_r.patch \

file://0003-missing_type.h-add-__compare_fn_t-and-comparison_fn_.patch \

file://0004-add-fallback-parse_printf_format-implementation.patch \
-- 
2.22.0

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

[OE-core] [PATCH 3/3] mesa: Add packageconfigs for vc4 and v3d

[Khem Raj]

This helps in enabling them via packageconfig from SOC layers

Signed-off-by: Khem Raj 
---
 meta/recipes-graphics/mesa/mesa.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 60d07f536c..fcd19884f5 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -94,10 +94,14 @@ PACKAGECONFIG[egl] = "-Degl=true, -Degl=false"
 
 PACKAGECONFIG[etnaviv] = ""
 PACKAGECONFIG[kmsro] = ""
+PACKAGECONFIG[vc4] = ""
+PACKAGECONFIG[v3d] = ""
 
 GALLIUMDRIVERS = "swrast"
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv', 
',etnaviv', '', d)}"
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'kmsro', 
',kmsro', '', d)}"
+GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'vc4', ',vc4', 
'', d)}"
+GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'v3d', ',v3d', 
'', d)}"
 
 # radeonsi requires LLVM
 GALLIUMDRIVERS_LLVM33 = "${@bb.utils.contains('PACKAGECONFIG', 'r600', 
',radeonsi', '', d)}"
-- 
2.22.0

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

Re: [OE-core] [PATCH] libffi: Upgrade to 3.3-rc0

[Khem Raj]

On Wed, Aug 14, 2019 at 3:42 PM akuster808  wrote:
>
>
>
> On 8/14/19 3:29 PM, Khem Raj wrote:
> > libffi 3.1 release has been a bit aged and new architectures, compilers
> > have since been come on stage to compile it, we have been carrying
> > patches, but its better to use the latest 3.3 rc0 which has lot of these
> > issues handled and is in good shape.
>
> Will the RC part cause the PE to be invoked when 3.3 comes out?  I did
> this on wireshark and shot myself in the foot.
>

I am expecting the releases to be 3.3.0  but looking into the history
of releases it
could be 3.3 so yes you are right, Probably I will renable the recipe
to libffi_3.2+3.3-rc0.bb
and that should fix this

> - armin
> >
> > Signed-off-by: Khem Raj 
> > ---
> >  .../libffi/0001-New-RISC-V-port-281.patch | 827 --
> >  .../0001-libffi-Support-musl-x32-build.patch  |  30 -
> >  ...e-compiler-internal-define-for-linux.patch |  32 -
> >  ...-mips-fix-MIPS-softfloat-build-issue.patch | 177 
> >  .../libffi/libffi/not-win32.patch |  10 +-
> >  .../{libffi_3.2.1.bb => libffi_3.3-rc0.bb}|  11 +-
> >  6 files changed, 8 insertions(+), 1079 deletions(-)
> >  delete mode 100644 
> > meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
> >  delete mode 100644 
> > meta/recipes-support/libffi/libffi/0001-libffi-Support-musl-x32-build.patch
> >  delete mode 100644 
> > meta/recipes-support/libffi/libffi/0001-mips-Use-compiler-internal-define-for-linux.patch
> >  delete mode 100644 
> > meta/recipes-support/libffi/libffi/0001-mips-fix-MIPS-softfloat-build-issue.patch
> >  rename meta/recipes-support/libffi/{libffi_3.2.1.bb => libffi_3.3-rc0.bb} 
> > (76%)
> >
> > diff --git 
> > a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch 
> > b/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
> > deleted file mode 100644
> > index 589c4d3c44..00
> > --- a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
> > +++ /dev/null
> > @@ -1,827 +0,0 @@
> > -From 8ac73103bf12ce4f776940cb17f3ced15a362f23 Mon Sep 17 00:00:00 2001
> > -From: Stef O'Rear 
> > -Date: Sun, 11 Mar 2018 05:55:15 -0700
> > -Subject: [PATCH] New RISC-V port (#281)
> > -
> > -* Add RISC-V support
> > -
> > -This patch adds support for the RISC-V architecture (https://riscv.org).
> > -
> > -This patch has been tested using QEMU user-mode emulation and GCC 7.2.0
> > -in the following configurations:
> > -
> > -* -march=rv32imac -mabi=ilp32
> > -* -march=rv32g -mabi=ilp32d
> > -* -march=rv64imac -mabi=lp64
> > -* -march=rv64g -mabi=lp64d
> > -
> > -The ABI currently can be found at
> > -https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md .
> > -
> > -* Add RISC-V to README
> > -
> > -* RISC-V: fix configure.host
> > -
> > -Upstream-Status: Backport 
> > [https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3]
> > -Signed-off-by: Alistair Francis 
> > 
> > - Makefile.am   |   4 +
> > - configure.ac  |   5 +
> > - src/riscv/ffi.c   | 445 ++
> > - src/riscv/ffitarget.h |  68 +++
> > - src/riscv/sysv.S  | 214 
> > - 5 files changed, 736 insertions(+)
> > - create mode 100644 src/riscv/ffi.c
> > - create mode 100644 src/riscv/ffitarget.h
> > - create mode 100644 src/riscv/sysv.S
> > -
> > -diff --git a/Makefile.am b/Makefile.am
> > -index 0e40451..3837650 100644
> >  a/Makefile.am
> > -+++ b/Makefile.am
> > -@@ -32,6 +32,7 @@ EXTRA_DIST = LICENSE ChangeLog.v1 ChangeLog.libgcj   
> >   \
> > -  src/powerpc/asm.h src/powerpc/aix.S src/powerpc/darwin.S   \
> > -  src/powerpc/aix_closure.S src/powerpc/darwin_closure.S \
> > -  src/powerpc/ffi_darwin.c src/powerpc/ffitarget.h   \
> > -+ src/riscv/ffi.c src/riscv/ffitarget.h src/riscv/sysv.S \
> > -  src/s390/ffi.c src/s390/sysv.S src/s390/ffitarget.h\
> > -  src/sh/ffi.c src/sh/sysv.S src/sh/ffitarget.h src/sh64/ffi.c   \
> > -  src/sh64/sysv.S src/sh64/ffitarget.h src/sparc/v8.S\
> > -@@ -122,6 +123,9 @@ endif
> > - if MIPS
> > - nodist_libffi_la_SOURCES += src/mips/ffi.c src/mips/o32.S src/mips/n32.S
> > - endif
> > -+if RISCV
> > -+nodist_libffi_la_SOURCES += src/riscv/ffi.c src/riscv/sysv.S
> > -+endif
> > - if BFIN
> > - nodist_libffi_la_SOURCES += src/bfin/ffi.c src/bfin/sysv.S
> > - endif
> > -diff --git a/configure.ac b/configure.ac
> > -index ce30853..33375aa 100644
> >  a/configure.ac
> > -+++ b/configure.ac
> > -@@ -226,6 +226,10 @@ case "$host" in
> > - TARGET=MIPS; TARGETDIR=mips
> > - ;;
> > -
> > -+  riscv*-*-*)
> > -+TARGET=RISCV; TARGETDIR=riscv
> > -+;;
> > -+
> > -   nios2*-linux*)
> > - TARGET=NIOS2; TARGETDIR=nios2
> > - ;;
> > -@@ -298,6 +302,7 @@ if test $TARGETDIR = unknown; then
> > - fi
> > -
> > - AM_CONDITIONAL(MIPS, test x$TARGET = xMIPS)
> > 

Re: [OE-core] [PATCH] libffi: Upgrade to 3.3-rc0

[akuster808]

On 8/14/19 3:29 PM, Khem Raj wrote:
> libffi 3.1 release has been a bit aged and new architectures, compilers
> have since been come on stage to compile it, we have been carrying
> patches, but its better to use the latest 3.3 rc0 which has lot of these
> issues handled and is in good shape.

Will the RC part cause the PE to be invoked when 3.3 comes out?  I did
this on wireshark and shot myself in the foot.

- armin
>
> Signed-off-by: Khem Raj 
> ---
>  .../libffi/0001-New-RISC-V-port-281.patch | 827 --
>  .../0001-libffi-Support-musl-x32-build.patch  |  30 -
>  ...e-compiler-internal-define-for-linux.patch |  32 -
>  ...-mips-fix-MIPS-softfloat-build-issue.patch | 177 
>  .../libffi/libffi/not-win32.patch |  10 +-
>  .../{libffi_3.2.1.bb => libffi_3.3-rc0.bb}|  11 +-
>  6 files changed, 8 insertions(+), 1079 deletions(-)
>  delete mode 100644 
> meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
>  delete mode 100644 
> meta/recipes-support/libffi/libffi/0001-libffi-Support-musl-x32-build.patch
>  delete mode 100644 
> meta/recipes-support/libffi/libffi/0001-mips-Use-compiler-internal-define-for-linux.patch
>  delete mode 100644 
> meta/recipes-support/libffi/libffi/0001-mips-fix-MIPS-softfloat-build-issue.patch
>  rename meta/recipes-support/libffi/{libffi_3.2.1.bb => libffi_3.3-rc0.bb} 
> (76%)
>
> diff --git 
> a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch 
> b/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
> deleted file mode 100644
> index 589c4d3c44..00
> --- a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
> +++ /dev/null
> @@ -1,827 +0,0 @@
> -From 8ac73103bf12ce4f776940cb17f3ced15a362f23 Mon Sep 17 00:00:00 2001
> -From: Stef O'Rear 
> -Date: Sun, 11 Mar 2018 05:55:15 -0700
> -Subject: [PATCH] New RISC-V port (#281)
> -
> -* Add RISC-V support
> -
> -This patch adds support for the RISC-V architecture (https://riscv.org).
> -
> -This patch has been tested using QEMU user-mode emulation and GCC 7.2.0
> -in the following configurations:
> -
> -* -march=rv32imac -mabi=ilp32
> -* -march=rv32g -mabi=ilp32d
> -* -march=rv64imac -mabi=lp64
> -* -march=rv64g -mabi=lp64d
> -
> -The ABI currently can be found at
> -https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md .
> -
> -* Add RISC-V to README
> -
> -* RISC-V: fix configure.host
> -
> -Upstream-Status: Backport 
> [https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3]
> -Signed-off-by: Alistair Francis 
> 
> - Makefile.am   |   4 +
> - configure.ac  |   5 +
> - src/riscv/ffi.c   | 445 ++
> - src/riscv/ffitarget.h |  68 +++
> - src/riscv/sysv.S  | 214 
> - 5 files changed, 736 insertions(+)
> - create mode 100644 src/riscv/ffi.c
> - create mode 100644 src/riscv/ffitarget.h
> - create mode 100644 src/riscv/sysv.S
> -
> -diff --git a/Makefile.am b/Makefile.am
> -index 0e40451..3837650 100644
>  a/Makefile.am
> -+++ b/Makefile.am
> -@@ -32,6 +32,7 @@ EXTRA_DIST = LICENSE ChangeLog.v1 ChangeLog.libgcj 
> \
> -  src/powerpc/asm.h src/powerpc/aix.S src/powerpc/darwin.S   \
> -  src/powerpc/aix_closure.S src/powerpc/darwin_closure.S \
> -  src/powerpc/ffi_darwin.c src/powerpc/ffitarget.h   \
> -+ src/riscv/ffi.c src/riscv/ffitarget.h src/riscv/sysv.S \
> -  src/s390/ffi.c src/s390/sysv.S src/s390/ffitarget.h\
> -  src/sh/ffi.c src/sh/sysv.S src/sh/ffitarget.h src/sh64/ffi.c   \
> -  src/sh64/sysv.S src/sh64/ffitarget.h src/sparc/v8.S\
> -@@ -122,6 +123,9 @@ endif
> - if MIPS
> - nodist_libffi_la_SOURCES += src/mips/ffi.c src/mips/o32.S src/mips/n32.S
> - endif
> -+if RISCV
> -+nodist_libffi_la_SOURCES += src/riscv/ffi.c src/riscv/sysv.S
> -+endif
> - if BFIN
> - nodist_libffi_la_SOURCES += src/bfin/ffi.c src/bfin/sysv.S
> - endif
> -diff --git a/configure.ac b/configure.ac
> -index ce30853..33375aa 100644
>  a/configure.ac
> -+++ b/configure.ac
> -@@ -226,6 +226,10 @@ case "$host" in
> - TARGET=MIPS; TARGETDIR=mips
> - ;;
> - 
> -+  riscv*-*-*)
> -+TARGET=RISCV; TARGETDIR=riscv
> -+;;
> -+
> -   nios2*-linux*)
> - TARGET=NIOS2; TARGETDIR=nios2
> - ;;
> -@@ -298,6 +302,7 @@ if test $TARGETDIR = unknown; then
> - fi
> - 
> - AM_CONDITIONAL(MIPS, test x$TARGET = xMIPS)
> -+AM_CONDITIONAL(RISCV, test x$TARGET = xRISCV)
> - AM_CONDITIONAL(BFIN, test x$TARGET = xBFIN)
> - AM_CONDITIONAL(SPARC, test x$TARGET = xSPARC)
> - AM_CONDITIONAL(X86, test x$TARGET = xX86)
> -diff --git a/src/riscv/ffi.c b/src/riscv/ffi.c
> -new file mode 100644
> -index 000..b744fdd
>  /dev/null
> -+++ b/src/riscv/ffi.c
> -@@ -0,0 +1,445 @@
> -+/* ---
> -+   ffi.c - Copyright (c) 2015 Michael Knyszek 
> -+

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[richard . purdie]

On Wed, 2019-08-14 at 22:27 +0200, Alexander Kanavin wrote:
> On Wed, 14 Aug 2019 at 14:55, 
> wrote:
> > You followed up mentioning this wasn't with master-next. I think
> > there
> > is a patch in -next which will help with the empty task spin so
> > both
> > together might get us back to more normal numbers.
> > 
> 
> As all of these patches are now in master, I re-ran the test with
> that (209f89ab8ed51ac2867ca8f749336af1ee24ab25), but without
> including the spinning task part, pressing ctrl-c just as it starts.
> The outcome is 9m42s, compared to 2m9s for the baseline
> (6c7c0cefd34067311144a1d4c01986fe0a4aef26). So the worst is fixed,
> but the slowdown is still noticeable.

Right, it still definitely needs work. Its a balancing act between
sorting out the execution bugs in the code and figuring out the
performance problem.

If anyone wants to experiment, the way I'd debug this is to run the
before and after cases with the -P option to bitbake. If you want to
exit early just make the code return where it prints "Executing tasks"
or whatever makes sense as Ctrl+C won't write the profile data.

You want the profile.log.processed file.

So save that file with the "before" commit, then save it afterwards and
look at those files and see where its spending more time.

If someone generates those two files I'll happily take a look, I'm kind
of used to reading them. There are four sets of output in there, same
data but different sorting/types, each has its uses.

Cheers,

Richard

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

[OE-core] [PATCH] libffi: Upgrade to 3.3-rc0

[Khem Raj]

libffi 3.1 release has been a bit aged and new architectures, compilers
have since been come on stage to compile it, we have been carrying
patches, but its better to use the latest 3.3 rc0 which has lot of these
issues handled and is in good shape.

Signed-off-by: Khem Raj 
---
 .../libffi/0001-New-RISC-V-port-281.patch | 827 --
 .../0001-libffi-Support-musl-x32-build.patch  |  30 -
 ...e-compiler-internal-define-for-linux.patch |  32 -
 ...-mips-fix-MIPS-softfloat-build-issue.patch | 177 
 .../libffi/libffi/not-win32.patch |  10 +-
 .../{libffi_3.2.1.bb => libffi_3.3-rc0.bb}|  11 +-
 6 files changed, 8 insertions(+), 1079 deletions(-)
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-libffi-Support-musl-x32-build.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-mips-Use-compiler-internal-define-for-linux.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-mips-fix-MIPS-softfloat-build-issue.patch
 rename meta/recipes-support/libffi/{libffi_3.2.1.bb => libffi_3.3-rc0.bb} (76%)

diff --git a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch 
b/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
deleted file mode 100644
index 589c4d3c44..00
--- a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
+++ /dev/null
@@ -1,827 +0,0 @@
-From 8ac73103bf12ce4f776940cb17f3ced15a362f23 Mon Sep 17 00:00:00 2001
-From: Stef O'Rear 
-Date: Sun, 11 Mar 2018 05:55:15 -0700
-Subject: [PATCH] New RISC-V port (#281)
-
-* Add RISC-V support
-
-This patch adds support for the RISC-V architecture (https://riscv.org).
-
-This patch has been tested using QEMU user-mode emulation and GCC 7.2.0
-in the following configurations:
-
-* -march=rv32imac -mabi=ilp32
-* -march=rv32g -mabi=ilp32d
-* -march=rv64imac -mabi=lp64
-* -march=rv64g -mabi=lp64d
-
-The ABI currently can be found at
-https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md .
-
-* Add RISC-V to README
-
-* RISC-V: fix configure.host
-
-Upstream-Status: Backport 
[https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3]
-Signed-off-by: Alistair Francis 

- Makefile.am   |   4 +
- configure.ac  |   5 +
- src/riscv/ffi.c   | 445 ++
- src/riscv/ffitarget.h |  68 +++
- src/riscv/sysv.S  | 214 
- 5 files changed, 736 insertions(+)
- create mode 100644 src/riscv/ffi.c
- create mode 100644 src/riscv/ffitarget.h
- create mode 100644 src/riscv/sysv.S
-
-diff --git a/Makefile.am b/Makefile.am
-index 0e40451..3837650 100644
 a/Makefile.am
-+++ b/Makefile.am
-@@ -32,6 +32,7 @@ EXTRA_DIST = LICENSE ChangeLog.v1 ChangeLog.libgcj   
\
-src/powerpc/asm.h src/powerpc/aix.S src/powerpc/darwin.S   \
-src/powerpc/aix_closure.S src/powerpc/darwin_closure.S \
-src/powerpc/ffi_darwin.c src/powerpc/ffitarget.h   \
-+   src/riscv/ffi.c src/riscv/ffitarget.h src/riscv/sysv.S \
-src/s390/ffi.c src/s390/sysv.S src/s390/ffitarget.h\
-src/sh/ffi.c src/sh/sysv.S src/sh/ffitarget.h src/sh64/ffi.c   \
-src/sh64/sysv.S src/sh64/ffitarget.h src/sparc/v8.S\
-@@ -122,6 +123,9 @@ endif
- if MIPS
- nodist_libffi_la_SOURCES += src/mips/ffi.c src/mips/o32.S src/mips/n32.S
- endif
-+if RISCV
-+nodist_libffi_la_SOURCES += src/riscv/ffi.c src/riscv/sysv.S
-+endif
- if BFIN
- nodist_libffi_la_SOURCES += src/bfin/ffi.c src/bfin/sysv.S
- endif
-diff --git a/configure.ac b/configure.ac
-index ce30853..33375aa 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -226,6 +226,10 @@ case "$host" in
-   TARGET=MIPS; TARGETDIR=mips
-   ;;
- 
-+  riscv*-*-*)
-+  TARGET=RISCV; TARGETDIR=riscv
-+  ;;
-+
-   nios2*-linux*)
-   TARGET=NIOS2; TARGETDIR=nios2
-   ;;
-@@ -298,6 +302,7 @@ if test $TARGETDIR = unknown; then
- fi
- 
- AM_CONDITIONAL(MIPS, test x$TARGET = xMIPS)
-+AM_CONDITIONAL(RISCV, test x$TARGET = xRISCV)
- AM_CONDITIONAL(BFIN, test x$TARGET = xBFIN)
- AM_CONDITIONAL(SPARC, test x$TARGET = xSPARC)
- AM_CONDITIONAL(X86, test x$TARGET = xX86)
-diff --git a/src/riscv/ffi.c b/src/riscv/ffi.c
-new file mode 100644
-index 000..b744fdd
 /dev/null
-+++ b/src/riscv/ffi.c
-@@ -0,0 +1,445 @@
-+/* ---
-+   ffi.c - Copyright (c) 2015 Michael Knyszek 
-+ 2015 Andrew Waterman 
-+ 2018 Stef O'Rear 
-+   Based on MIPS N32/64 port
-+
-+   RISC-V Foreign Function Interface
-+
-+   Permission is hereby granted, free of charge, to any person obtaining
-+   a copy of this software and associated documentation files (the
-+   ``Software''), to deal in the Software without restriction, including
-+   without limitation 

[OE-core] [PATCH V2] libffi: Upgrade to 3.3-rc0

[Khem Raj]

libffi 3.1 release has been a bit aged and new architectures, compilers
have since been come on stage to compile it, we have been carrying
patches, but its better to use the latest 3.3 rc0 which has lot of these
issues handled and is in good shape.

Use 3.2.1+3.3-rc0 for PV to keep room for upgrade path without PE bump

Signed-off-by: Khem Raj 
---
v2: Set PV = 3.2.1+3.3-rc0

 .../libffi/0001-New-RISC-V-port-281.patch | 827 --
 .../0001-libffi-Support-musl-x32-build.patch  |  30 -
 ...e-compiler-internal-define-for-linux.patch |  32 -
 ...-mips-fix-MIPS-softfloat-build-issue.patch | 177 
 .../libffi/libffi/not-win32.patch |  10 +-
 ...ibffi_3.2.1.bb => libffi_3.2.1+3.3-rc0.bb} |  13 +-
 6 files changed, 9 insertions(+), 1080 deletions(-)
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-libffi-Support-musl-x32-build.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-mips-Use-compiler-internal-define-for-linux.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-mips-fix-MIPS-softfloat-build-issue.patch
 rename meta/recipes-support/libffi/{libffi_3.2.1.bb => 
libffi_3.2.1+3.3-rc0.bb} (72%)

diff --git a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch 
b/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
deleted file mode 100644
index 589c4d3c44..00
--- a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
+++ /dev/null
@@ -1,827 +0,0 @@
-From 8ac73103bf12ce4f776940cb17f3ced15a362f23 Mon Sep 17 00:00:00 2001
-From: Stef O'Rear 
-Date: Sun, 11 Mar 2018 05:55:15 -0700
-Subject: [PATCH] New RISC-V port (#281)
-
-* Add RISC-V support
-
-This patch adds support for the RISC-V architecture (https://riscv.org).
-
-This patch has been tested using QEMU user-mode emulation and GCC 7.2.0
-in the following configurations:
-
-* -march=rv32imac -mabi=ilp32
-* -march=rv32g -mabi=ilp32d
-* -march=rv64imac -mabi=lp64
-* -march=rv64g -mabi=lp64d
-
-The ABI currently can be found at
-https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md .
-
-* Add RISC-V to README
-
-* RISC-V: fix configure.host
-
-Upstream-Status: Backport 
[https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3]
-Signed-off-by: Alistair Francis 

- Makefile.am   |   4 +
- configure.ac  |   5 +
- src/riscv/ffi.c   | 445 ++
- src/riscv/ffitarget.h |  68 +++
- src/riscv/sysv.S  | 214 
- 5 files changed, 736 insertions(+)
- create mode 100644 src/riscv/ffi.c
- create mode 100644 src/riscv/ffitarget.h
- create mode 100644 src/riscv/sysv.S
-
-diff --git a/Makefile.am b/Makefile.am
-index 0e40451..3837650 100644
 a/Makefile.am
-+++ b/Makefile.am
-@@ -32,6 +32,7 @@ EXTRA_DIST = LICENSE ChangeLog.v1 ChangeLog.libgcj   
\
-src/powerpc/asm.h src/powerpc/aix.S src/powerpc/darwin.S   \
-src/powerpc/aix_closure.S src/powerpc/darwin_closure.S \
-src/powerpc/ffi_darwin.c src/powerpc/ffitarget.h   \
-+   src/riscv/ffi.c src/riscv/ffitarget.h src/riscv/sysv.S \
-src/s390/ffi.c src/s390/sysv.S src/s390/ffitarget.h\
-src/sh/ffi.c src/sh/sysv.S src/sh/ffitarget.h src/sh64/ffi.c   \
-src/sh64/sysv.S src/sh64/ffitarget.h src/sparc/v8.S\
-@@ -122,6 +123,9 @@ endif
- if MIPS
- nodist_libffi_la_SOURCES += src/mips/ffi.c src/mips/o32.S src/mips/n32.S
- endif
-+if RISCV
-+nodist_libffi_la_SOURCES += src/riscv/ffi.c src/riscv/sysv.S
-+endif
- if BFIN
- nodist_libffi_la_SOURCES += src/bfin/ffi.c src/bfin/sysv.S
- endif
-diff --git a/configure.ac b/configure.ac
-index ce30853..33375aa 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -226,6 +226,10 @@ case "$host" in
-   TARGET=MIPS; TARGETDIR=mips
-   ;;
- 
-+  riscv*-*-*)
-+  TARGET=RISCV; TARGETDIR=riscv
-+  ;;
-+
-   nios2*-linux*)
-   TARGET=NIOS2; TARGETDIR=nios2
-   ;;
-@@ -298,6 +302,7 @@ if test $TARGETDIR = unknown; then
- fi
- 
- AM_CONDITIONAL(MIPS, test x$TARGET = xMIPS)
-+AM_CONDITIONAL(RISCV, test x$TARGET = xRISCV)
- AM_CONDITIONAL(BFIN, test x$TARGET = xBFIN)
- AM_CONDITIONAL(SPARC, test x$TARGET = xSPARC)
- AM_CONDITIONAL(X86, test x$TARGET = xX86)
-diff --git a/src/riscv/ffi.c b/src/riscv/ffi.c
-new file mode 100644
-index 000..b744fdd
 /dev/null
-+++ b/src/riscv/ffi.c
-@@ -0,0 +1,445 @@
-+/* ---
-+   ffi.c - Copyright (c) 2015 Michael Knyszek 
-+ 2015 Andrew Waterman 
-+ 2018 Stef O'Rear 
-+   Based on MIPS N32/64 port
-+
-+   RISC-V Foreign Function Interface
-+
-+   Permission is hereby granted, free of charge, to any person obtaining
-+   a copy of this software and associated documentation files 

[OE-core] [PATCH] linux-yocto/4.19: make drm-bochs feature available

[bruce . ashfield]

From: Bruce Ashfield 

The other active kernel versions have this feature available. To
consistently enable the same video output for qemu, we can cherry
pick the feature to 4.19.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_4.19.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
index 52deb3fc86..8d4545039e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "ca2e3322f4c5678eaef6434c808d0842c805d74d"
-SRCREV_meta ?= "283939d5c9ebec9750c34982405a39a9864ac10f"
+SRCREV_meta ?= "20a6158aa35dbf11819382ef1eeb28915afea765"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
index be25d075de..2255a7b959 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine_qemuarm ?= "b5a2efa31290f31384971494031285d394635938"
 SRCREV_machine ?= "4ec6f255163da37a4c83528e5835b6b9baccee63"
-SRCREV_meta ?= "283939d5c9ebec9750c34982405a39a9864ac10f"
+SRCREV_meta ?= "20a6158aa35dbf11819382ef1eeb28915afea765"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
index 7704bd3e55..1a542d81cf 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= 
"4ec6f255163da37a4c83528e5835b6b9baccee63"
 SRCREV_machine_qemux86-64 ?= "4ec6f255163da37a4c83528e5835b6b9baccee63"
 SRCREV_machine_qemumips64 ?= "ca47368b698795cd5cada84dbfcceda1f47da1aa"
 SRCREV_machine ?= "4ec6f255163da37a4c83528e5835b6b9baccee63"
-SRCREV_meta ?= "283939d5c9ebec9750c34982405a39a9864ac10f"
+SRCREV_meta ?= "20a6158aa35dbf11819382ef1eeb28915afea765"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}
 \
-- 
2.19.1

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

Re: [OE-core] [PATCH 1/3] linux-yocto: add drm-bochs support

[Bruce Ashfield]

On Wed, Aug 14, 2019 at 6:21 PM Richard Purdie
 wrote:
>
> On Wed, 2019-08-14 at 17:26 +0200, Alexander Kanavin wrote:
> > This allows better modesetting support for the '-vga std'
> > emulated hardware provided by Qemu, which we want to
> > standardize on.
> >
> > See here for background:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
> >  meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +-
> >  meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb  | 2 +-
> >  meta/recipes-kernel/linux/linux-yocto_4.19.bb| 2 +-
> >  meta/recipes-kernel/linux/linux-yocto_5.0.bb | 2 +-
> >  5 files changed, 5 insertions(+), 5 deletions(-)
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/41/builds/929

4.19 didn't have the drm-bochs fragment. I just cherry picked it to
the branch and pushed it to the repo. I'll send a SRCREV bump for the
4.19 meta data shortly that should fix it, and this patch can stay
as-is.

Bruce

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



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

[Hongzhi, Song]

On 8/14/19 11:33 PM, Bruce Ashfield wrote:

On Wed, Aug 14, 2019 at 5:48 AM Hongzhi, Song
 wrote:


On 8/14/19 11:48 AM, Bruce Ashfield wrote:

On Tue, Aug 13, 2019 at 11:39 PM Bruce Ashfield
  wrote:

On Tue, Aug 13, 2019 at 11:04 PM Bruce Ashfield
  wrote:

On Tue, Aug 13, 2019 at 11:01 PM Hongzhi, Song  
wrote:

On 8/14/19 10:53 AM, Bruce Ashfield wrote:

On Tue, Aug 13, 2019 at 9:59 PM Hongzhi, Song
mailto:hongzhi.s...@windriver.com>> wrote:


  On 8/13/19 8:27 PM, Bruce Ashfield wrote:
  >
  >
  > On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song
  > mailto:hongzhi.s...@windriver.com>
  >> wrote:
  >
  > A new patch let kernel source Documentation/Kconfig in top
  Kconfig
  > So kernel-devsrc should include Documentation/ too.
  > Otherwise "make scripts" will fails.
  >
  > patch:
  > commit b1663d7e3a7961fc45262fd68a89253f2803036c
  > Author: Mauro Carvalho Chehab mailto:mchehab%2bsams...@kernel.org>
  > >>
  > Date:   Tue Jun 4 09:26:27 2019 -0300
  >
  > docs: Kbuild/Makefile: allow check for missing docs at
  build time
  >
  > While this doesn't make sense for production Kernels, in
  order to
  > avoid regressions when documents are touched, let's add a
  > check target at the make file.
  >
  > Signed-off-by: Mauro Carvalho Chehab
  > mailto:mchehab%2bsams...@kernel.org>
  >>
  > Signed-off-by: Jonathan Corbet mailto:cor...@lwn.net>
  > >>
  >
  > Signed-off-by: Hongzhi.Song mailto:hongzhi.s...@windriver.com>
  > >>
  > ---
  >  meta/recipes-kernel/linux/kernel-devsrc.bb
  
  >  | 2 +-
  >  1 file changed, 1 insertion(+), 1 deletion(-)
  >
  > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
  
  >
  > b/meta/recipes-kernel/linux/kernel-devsrc.bb
    
  > index 5ec5929..a874e06 100644
  > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
  
  >
  > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
  
  >
  > @@ -65,7 +65,7 @@ do_install() {
  >  )
  >
  >  # then drop all but the needed Makefiles/Kconfig files
  > -rm -rf $kerneldir/build/Documentation
  > +#rm -rf $kerneldir/build/Documentation
  >
  >
  > In the spirit of keeping kernel-devsrc as small as possible (I have
  > another patch pending if you really want the full kernel
  source), this
  > should only keep the Documentation/ files that are required to pass
  > the check, not keep all of Documentation.


  If you have a better patch, I am pleasure to accept it.


???

This is where you'd typically do a v2 of the patch after getting a
review of a change.

But if you are refusing the feedback, then yes, I'll do a version of
the patch myself rather than just blindly copying in all of the
documentation. I'll submit it myself.

RP/Ross, whoever is taking in patches, drop this version, and I'll do
my own.

I am not very familiar with the kernel-devsrc.bb. I have no objection
for your decision.

At a minimum, we shouldn't leave the commented out #rm -rf 
$kerneldir/build/Documentation, so I can do that and tweak the commit message a 
bit as well.

Leave it with me, and I'll send it to the list (hopefully tomorrow) to be sure 
it still solves your problem.

Aha. Now I see what is actually happening. On reading the patch, I
thought you were requiring the existence of the *entire* Documentation
directory, not just the Kbuild infrastructure that would be triggered
if the documentation warning is enabled.

I still want to change things just a bit, but I'll leave your
Signed-off-by on the patch, since it won't be a structural change as I
thought.

But can you provide me your test steps ? Do you have a tweaked kernel
config that is enabling WARN_MISSING_DOCUMENTS and COMPILE_TEST ?


My steps:

1. git clone git://git.yoctoproject.org/poky

2. TOOLCHAIN_TARGET_TASK_append = " python-dev kernel-dev kernel-devsrc"

  TOOLCHAIN_HOST_TASK_append = " nativesdk-openssl-dev
nativesdk-bison nativesdk-flex"

  >> local.conf


3. bitbake core-image-minimal && bitbake core-image-minimal -c populate_sdk

4.

[OE-core] [PATCH 1/2] util-linux: Make pam specific logic apply to target recipe alone

[Khem Raj]

This helps with a case where a distro builds one image with systemd and
another with sysvinit, it ends up recompiling almost everything since
python3-native gets rebuilt and tracing dependencies with
bitbake-diffsigs shows that the chain ends at util-linux-native being
recompiled because distro features now does or does not have 'pam'

Hash for dependent task 
python/python3_3.7.4.bb:do_prepare_recipe_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-devt
ools/python/python3_3.7.4.bb changed from 
8befaac4f995aaff3f95d27c9caaf1006f86e1344b02c1ae82f5d12f885f2240 to 
2a45fe0cd0d3640a88c4a5c8b1880c4e9
a089cc7446a91d2a920c1cef6fa916a
Hash for dependent task 
util-linux/util-linux_2.34.bb:do_populate_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-
core/util-linux/util-linux_2.34.bb changed from 
0db292cb2e37d5788bdcf51038b2802d748b719d860aca3a26d7a793b0cf3905 to 
15d6e165f025f10c2c455df8a87
5cafe021eaed4214c793e708d4827a58ca89d
Hash for dependent task 
util-linux/util-linux_2.34.bb:do_install:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-core/util-linux/util-linux_2.34.bb
 changed from 54bb4ee6bdb5c7fc260dabddb4932cb0e554a62cd92aba080a18306291fb470b 
to e25b1119ce8dd7ca43fbd2db771e04fa
6ff6b9d701fd78ac6c443224b036ed9f
   
basehash changed from 
8e8687a866689a697001dedc0a43f478e68e6efe270bd77362f24c6000f9e882 to 
62df6610eab9c1b1a17d7132943507641c8538690
f26186843c86144d4598e64
Variable do_install value changed:

rm -f ${D}${bindir}/chkdupexe
-   if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
+   if [ "${@bb.utils.filter('PACKAGECONFIG', 'pam', d)}" ]; then
install -d ${D}${sysconfdir}/pam.d
install -m 0644 ${WORKDIR}/runuser.pamd ${D}${sysconfdir}/pam.d/runuser
install -m 0644 ${WORKDIR}/runuser-l.pamd 
${D}${sysconfdir}/pam.d/runuser-l
@@ -47,5 +47,4 @@
rm -f ${D}${base_sbindir}/nologin
rm -f ${D}${base_bindir}/kill

-DISTRO_FEATURES{pam} = Unset
PACKAGECONFIG{pam} = Unset

So far it seems this pam conditional code in util-linux is target
specific and would not apply to native or nativesdk recipes

Signed-off-by: Khem Raj 
---
 meta/recipes-core/util-linux/util-linux.inc | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 84c7012752..5b1b919800 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -190,20 +190,19 @@ do_install () {
echo 'MOUNTALL="-t nonfs,nosmbfs,noncpfs"' > 
${D}${sysconfdir}/default/mountall
 
rm -f ${D}${bindir}/chkdupexe
+}
 
-   if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
+do_install_class-target () {
+   if [ "${@bb.utils.filter('PACKAGECONFIG', 'pam', d)}" ]; then
install -d ${D}${sysconfdir}/pam.d
install -m 0644 ${WORKDIR}/runuser.pamd 
${D}${sysconfdir}/pam.d/runuser
install -m 0644 ${WORKDIR}/runuser-l.pamd 
${D}${sysconfdir}/pam.d/runuser-l
-   fi
-   if [ "${@bb.utils.filter('PACKAGECONFIG', 'pam', d)}" ]; then
# Required for "su -" aka "su --login" because
# otherwise it uses "other", which has "auth pam_deny.so"
# and thus prevents the operation.
ln -s su ${D}${sysconfdir}/pam.d/su-l
fi
 }
-
 # nologin causes a conflict with shadow-native
 # kill causes a conflict with coreutils-native (if ${bindir}==${base_bindir})
 do_install_append_class-native () {
@@ -267,7 +266,7 @@ ALTERNATIVE_${PN}-doc = "\
 blkid.8 eject.1 findfs.8 fsck.8 kill.1 last.1 lastb.1 libblkid.3 logger.1 
mesg.1 \
 mountpoint.1 nologin.8 rfkill.8 sulogin.8 utmpdump.1 uuid.3 wall.1\
 "
-ALTERNATIVE_${PN}-doc += "${@bb.utils.contains('PACKAGECONFIG', 'pam', 'su.1', 
'', d)}"
+ALTERNATIVE_${PN}-doc_append_class-target = 
"${@bb.utils.contains('PACKAGECONFIG', 'pam', ' su.1', '', d)}"
 
 ALTERNATIVE_LINK_NAME[blkid.8] = "${mandir}/man8/blkid.8"
 ALTERNATIVE_LINK_NAME[eject.1] = "${mandir}/man1/eject.1"
-- 
2.22.0

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

[OE-core] [PATCH 2/2] systemd.bbclass: Limit rm_sysvinit_initddir and rm_systemd_unitdir to target alone

[Khem Raj]

These postfuncs cause native recipes to rebuild when changing system
init provider between sysvinit and systemd. Some of these native recipes
are pretty early in dependency chain ( e.g. util-linux ) which can casue
rebuild of pretty much everything including compiler.

Found with bitbake-diffsigs

Hash for dependent task 
python/python3_3.7.4.bb:do_prepare_recipe_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-devt
ools/python/python3_3.7.4.bb changed from 
2a45fe0cd0d3640a88c4a5c8b1880c4e9a089cc7446a91d2a920c1cef6fa916a to 
bc2a0921cce50da1b7be3b59a3d8211ec
2a31262493ffa5909acbb7116fad3bf
Hash for dependent task 
util-linux/util-linux_2.34.bb:do_populate_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-
core/util-linux/util-linux_2.34.bb changed from 
15d6e165f025f10c2c455df8a875cafe021eaed4214c793e708d4827a58ca89d to 
54e542d5da99cacfc9290ef5d27
9de50bdcb9195f67ae6dfff59fe41d10f7bd2
Hash for dependent task 
util-linux/util-linux_2.34.bb:do_install:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-core/
util-linux/util-linux_2.34.bb changed from 
e25b1119ce8dd7ca43fbd2db771e04fa6ff6b9d701fd78ac6c443224b036ed9f to 
bb5b172a83e7edd272402a9dcd80c4e1
29aa1ecb824c2cfa388086cfed24fef5
basehash changed from 
62df6610eab9c1b1a17d7132943507641c8538690f26186843c86144d4598e64 to 
80471f7c0bded9d1b593da69708b0e0f10882db08
5e1bf769edb3018e6c744d0
Variable rm_sysvinit_initddir value changed:
@@ -11,4 +11,4 @@
 shutil.rmtree(sysv_initddir)

 DISTRO_FEATURES{systemd} = Unset
-DISTRO_FEATURES{sysvinit} = Set
+DISTRO_FEATURES{sysvinit} = Unset

Signed-off-by: Khem Raj 
---
 meta/classes/systemd.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index d1cb17dc8d..747055b8fa 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -214,7 +214,6 @@ python rm_systemd_unitdir (){
 if (os.path.exists(systemd_libdir) and not os.listdir(systemd_libdir)):
 os.rmdir(systemd_libdir)
 }
-do_install[postfuncs] += "rm_systemd_unitdir "
 
 python rm_sysvinit_initddir (){
 import shutil
@@ -229,4 +228,8 @@ python rm_sysvinit_initddir (){
 if (os.path.exists(systemd_system_unitdir) and 
os.listdir(systemd_system_unitdir)):
 shutil.rmtree(sysv_initddir)
 }
-do_install[postfuncs] += "rm_sysvinit_initddir "
+
+do_install[postfuncs] += "${RMINITDIR} "
+RMINITDIR_class-target = " rm_sysvinit_initddir rm_systemd_unitdir "
+RMINITDIR = ""
+
-- 
2.22.0

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

[OE-core] [PATCH V2 1/2] util-linux: Make pam specific logic apply to target recipe alone

[Khem Raj]

This helps with a case where a distro builds one image with systemd and
another with sysvinit, it ends up recompiling almost everything since
python3-native gets rebuilt and tracing dependencies with
bitbake-diffsigs shows that the chain ends at util-linux-native being
recompiled because distro features now does or does not have 'pam'

Hash for dependent task 
python/python3_3.7.4.bb:do_prepare_recipe_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-devt
ools/python/python3_3.7.4.bb changed from 
8befaac4f995aaff3f95d27c9caaf1006f86e1344b02c1ae82f5d12f885f2240 to 
2a45fe0cd0d3640a88c4a5c8b1880c4e9
a089cc7446a91d2a920c1cef6fa916a
Hash for dependent task 
util-linux/util-linux_2.34.bb:do_populate_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-
core/util-linux/util-linux_2.34.bb changed from 
0db292cb2e37d5788bdcf51038b2802d748b719d860aca3a26d7a793b0cf3905 to 
15d6e165f025f10c2c455df8a87
5cafe021eaed4214c793e708d4827a58ca89d
Hash for dependent task 
util-linux/util-linux_2.34.bb:do_install:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-core/util-linux/util-linux_2.34.bb
 changed from 54bb4ee6bdb5c7fc260dabddb4932cb0e554a62cd92aba080a18306291fb470b 
to e25b1119ce8dd7ca43fbd2db771e04fa
6ff6b9d701fd78ac6c443224b036ed9f
   
basehash changed from 
8e8687a866689a697001dedc0a43f478e68e6efe270bd77362f24c6000f9e882 to 
62df6610eab9c1b1a17d7132943507641c8538690
f26186843c86144d4598e64
Variable do_install value changed:

rm -f ${D}${bindir}/chkdupexe
-   if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
+   if [ "${@bb.utils.filter('PACKAGECONFIG', 'pam', d)}" ]; then
install -d ${D}${sysconfdir}/pam.d
install -m 0644 ${WORKDIR}/runuser.pamd ${D}${sysconfdir}/pam.d/runuser
install -m 0644 ${WORKDIR}/runuser-l.pamd 
${D}${sysconfdir}/pam.d/runuser-l
@@ -47,5 +47,4 @@
rm -f ${D}${base_sbindir}/nologin
rm -f ${D}${base_bindir}/kill

-DISTRO_FEATURES{pam} = Unset
PACKAGECONFIG{pam} = Unset

So far it seems this pam conditional code in util-linux is target
specific and would not apply to native or nativesdk recipes

Signed-off-by: Khem Raj 
---
v2:
- Add missing do_install append qualifier
- No need to mark ALTERNATIVE_${PN}-doc target specific

 meta/recipes-core/util-linux/util-linux.inc | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 84c7012752..1fa82363b1 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -190,20 +190,19 @@ do_install () {
echo 'MOUNTALL="-t nonfs,nosmbfs,noncpfs"' > 
${D}${sysconfdir}/default/mountall
 
rm -f ${D}${bindir}/chkdupexe
+}
 
-   if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
+do_install_append_class-target () {
+   if [ "${@bb.utils.filter('PACKAGECONFIG', 'pam', d)}" ]; then
install -d ${D}${sysconfdir}/pam.d
install -m 0644 ${WORKDIR}/runuser.pamd 
${D}${sysconfdir}/pam.d/runuser
install -m 0644 ${WORKDIR}/runuser-l.pamd 
${D}${sysconfdir}/pam.d/runuser-l
-   fi
-   if [ "${@bb.utils.filter('PACKAGECONFIG', 'pam', d)}" ]; then
# Required for "su -" aka "su --login" because
# otherwise it uses "other", which has "auth pam_deny.so"
# and thus prevents the operation.
ln -s su ${D}${sysconfdir}/pam.d/su-l
fi
 }
-
 # nologin causes a conflict with shadow-native
 # kill causes a conflict with coreutils-native (if ${bindir}==${base_bindir})
 do_install_append_class-native () {
-- 
2.22.0

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

[OE-core] [PATCH V2 2/2] systemd.bbclass: Limit rm_sysvinit_initddir and rm_systemd_unitdir to target alone

[Khem Raj]

These postfuncs cause native recipes to rebuild when changing system
init provider between sysvinit and systemd. Some of these native recipes
are pretty early in dependency chain ( e.g. util-linux ) which can casue
rebuild of pretty much everything including compiler.

Found with bitbake-diffsigs

Hash for dependent task 
python/python3_3.7.4.bb:do_prepare_recipe_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-devt
ools/python/python3_3.7.4.bb changed from 
2a45fe0cd0d3640a88c4a5c8b1880c4e9a089cc7446a91d2a920c1cef6fa916a to 
bc2a0921cce50da1b7be3b59a3d8211ec
2a31262493ffa5909acbb7116fad3bf
Hash for dependent task 
util-linux/util-linux_2.34.bb:do_populate_sysroot:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-
core/util-linux/util-linux_2.34.bb changed from 
15d6e165f025f10c2c455df8a875cafe021eaed4214c793e708d4827a58ca89d to 
54e542d5da99cacfc9290ef5d27
9de50bdcb9195f67ae6dfff59fe41d10f7bd2
Hash for dependent task 
util-linux/util-linux_2.34.bb:do_install:virtual:native:/mnt/a/yoe/sources/openembedded-core/meta/recipes-core/
util-linux/util-linux_2.34.bb changed from 
e25b1119ce8dd7ca43fbd2db771e04fa6ff6b9d701fd78ac6c443224b036ed9f to 
bb5b172a83e7edd272402a9dcd80c4e1
29aa1ecb824c2cfa388086cfed24fef5
basehash changed from 
62df6610eab9c1b1a17d7132943507641c8538690f26186843c86144d4598e64 to 
80471f7c0bded9d1b593da69708b0e0f10882db08
5e1bf769edb3018e6c744d0
Variable rm_sysvinit_initddir value changed:
@@ -11,4 +11,4 @@
 shutil.rmtree(sysv_initddir)

 DISTRO_FEATURES{systemd} = Unset
-DISTRO_FEATURES{sysvinit} = Set
+DISTRO_FEATURES{sysvinit} = Unset

Signed-off-by: Khem Raj 
---
v2: Rebase

 meta/classes/systemd.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index d1cb17dc8d..747055b8fa 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -214,7 +214,6 @@ python rm_systemd_unitdir (){
 if (os.path.exists(systemd_libdir) and not os.listdir(systemd_libdir)):
 os.rmdir(systemd_libdir)
 }
-do_install[postfuncs] += "rm_systemd_unitdir "
 
 python rm_sysvinit_initddir (){
 import shutil
@@ -229,4 +228,8 @@ python rm_sysvinit_initddir (){
 if (os.path.exists(systemd_system_unitdir) and 
os.listdir(systemd_system_unitdir)):
 shutil.rmtree(sysv_initddir)
 }
-do_install[postfuncs] += "rm_sysvinit_initddir "
+
+do_install[postfuncs] += "${RMINITDIR} "
+RMINITDIR_class-target = " rm_sysvinit_initddir rm_systemd_unitdir "
+RMINITDIR = ""
+
-- 
2.22.0

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

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[Alexander Kanavin]

On Wed, 14 Aug 2019 at 14:55,  wrote:

> You followed up mentioning this wasn't with master-next. I think there
> is a patch in -next which will help with the empty task spin so both
> together might get us back to more normal numbers.
>

As all of these patches are now in master, I re-ran the test with that
(209f89ab8ed51ac2867ca8f749336af1ee24ab25), but without including the
spinning task part, pressing ctrl-c just as it starts. The outcome is
9m42s, compared to 2m9s for the baseline
(6c7c0cefd34067311144a1d4c01986fe0a4aef26).
So the worst is fixed, but the slowdown is still noticeable.

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

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[Mikko.Rapeli]

On Wed, Aug 14, 2019 at 02:08:01PM +0200, Alexander Kanavin wrote:
> On Wed, 14 Aug 2019 at 13:36,  wrote:
> 
> > On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > > richard.pur...@linuxfoundation.org> wrote:
> > > > I had a glance at the profile output from master-next and the
> > > > problem
> > > > wasn't where I thought it would be, it was in the scheduler code.
> > > > That
> > > > is good as those classes are effectively independent of the other
> > > > changes and hence are a separate fix.
> > > >
> > > > I've put a patch in -next which takes the above test to 36s which
> > > > is
> > > > close to the older bitbake.
> > > >
> > > > Could be interesting to see how it looks for others and different
> > > > workloads.
> > >
> > > I just tried the same test I did yesterday with
> > > ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it doesn't
> > > seem to improve things much: bitbake is stuck at "NOTE: Executing
> > > Tasks" for 15 minutes now.
> >
> > This might sound slightly crazy but can you try commenting out this
> > line in runqueue.py:
> >
> > logger.debug(2, "Holding off tasks %s" %
> > pprint.pformat(self.holdoff_tasks))
> >
> > ?
> >
> 
> Even crazier is the outcome: it helped! The whole thing completed after
> 15m49secons (with much of the time going to the empty task spin), that's
> some 3 minutes slower, but certainly it's usable again.
> 
> I have not enabled the hash server at any point.

Indeed, commenting that debug statement out removes few minutes of the
bitbake preparation times.

Here is a time stamped output from master branch:

2019-08-14_14:29:24  
2019-08-14_14:29:35  Initialising tasks...done.
2019-08-14_14:32:41  Checking sstate mirror object availability...done.
2019-08-14_14:32:41  Sstate summary: Wanted 436 Found 426 Missed 10 Current 
2407 (97% match, 99% complete)
2019-08-14_14:32:41  NOTE: Executing Tasks
2019-08-14_14:32:52  NOTE: Setscene tasks completed

And with the comment removed:

2019-08-14_14:35:10  
2019-08-14_14:35:21  Initialising tasks...done.
2019-08-14_14:35:30  Checking sstate mirror object availability...done.
2019-08-14_14:35:30  Sstate summary: Wanted 436 Found 426 Missed 10 Current 
2407 (97% match, 99% complete)
2019-08-14_14:35:30  NOTE: Executing Tasks

And just in case back to master branch state:

2019-08-14_14:41:32  
2019-08-14_14:41:43  Initialising tasks...done.
2019-08-14_14:45:02  Checking sstate mirror object availability...done.
2019-08-14_14:45:02  Sstate summary: Wanted 436 Found 426 Missed 10 Current 
2407 (97% match, 99% complete)
2019-08-14_14:45:02  NOTE: Executing Tasks

I did not flush caches in between and I stopped the builds once bitbake started 
doing stuff, so I think sstate cache was completely buffered in memory
from file system and IO delays did not affect the timings.

Change to poky was exactly:

--- a/bitbake/lib/bb/runqueue.py
+++ b/bitbake/lib/bb/runqueue.py
@@ -2216,7 +2216,7 @@ class RunQueueExecute:
 for dep in self.sqdata.sq_covered_tasks[tid]:
 if dep not in self.runq_complete:
 self.holdoff_tasks.add(dep)
-logger.debug(2, "Holding off tasks %s" % 
pprint.pformat(self.holdoff_tasks))
+# logger.debug(2, "Holding off tasks %s" % 
pprint.pformat(self.holdoff_tasks))
 
 def process_possible_migrations(self):
 changes = False

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

Re: [OE-core] [thud][PATCH v2 1/4] curl: fix CVE-2018-16890 CVE-2019-3822 CVE-2019-3823

[akuster808]

On 8/13/19 4:25 PM, Kevin Weng via Openembedded-core wrote:
> Signed-off-by: Kevin Weng 
> ---
>  .../curl/curl/CVE-2018-16890.patch| 50 +
>  .../curl/curl/CVE-2019-3822.patch | 47 
>  .../curl/curl/CVE-2019-3823.patch | 55 +++
>  meta/recipes-support/curl/curl_7.61.0.bb  |  3 +
>  4 files changed, 155 insertions(+)
>  create mode 100644 meta/recipes-support/curl/curl/CVE-2018-16890.patch
>  create mode 100644 meta/recipes-support/curl/curl/CVE-2019-3822.patch
>  create mode 100644 meta/recipes-support/curl/curl/CVE-2019-3823.patch

I master and Warrior not affected?

- armin
>
> diff --git a/meta/recipes-support/curl/curl/CVE-2018-16890.patch 
> b/meta/recipes-support/curl/curl/CVE-2018-16890.patch
> new file mode 100644
> index 00..3776f362bc
> --- /dev/null
> +++ b/meta/recipes-support/curl/curl/CVE-2018-16890.patch
> @@ -0,0 +1,50 @@
> +From 53d3c2f92b4a7561b1006494badf8cf2ef9110c0 Mon Sep 17 00:00:00 2001
> +From: Daniel Stenberg 
> +Date: Wed, 2 Jan 2019 20:33:08 +0100
> +Subject: [PATCH 1/3] NTLM: fix size check condition for type2 received data
> +
> +Bug: https://curl.haxx.se/docs/CVE-2018-16890.html
> +Reported-by: Wenxiang Qian
> +CVE-2018-16890
> +
> +Upstream-Status: Backport
> +[https://github.com/curl/curl/commit
> +/b780b30d1377adb10bbe774835f49e9b237fb9bb]
> +
> +CVE: CVE-2018-16890
> +
> +Signed-off-by: Kevin Weng 
> +---
> + lib/vauth/ntlm.c | 7 ---
> + 1 file changed, 4 insertions(+), 3 deletions(-)
> +
> +diff --git a/lib/vauth/ntlm.c b/lib/vauth/ntlm.c
> +index cdb8d8f0d..0212756ab 100644
> +--- a/lib/vauth/ntlm.c
>  b/lib/vauth/ntlm.c
> +@@ -5,7 +5,7 @@
> +  *| (__| |_| |  _ <| |___
> +  * \___|\___/|_| \_\_|
> +  *
> +- * Copyright (C) 1998 - 2017, Daniel Stenberg, , et al.
> ++ * Copyright (C) 1998 - 2019, Daniel Stenberg, , et al.
> +  *
> +  * This software is licensed as described in the file COPYING, which
> +  * you should have received as part of this distribution. The terms
> +@@ -182,10 +182,11 @@ static CURLcode ntlm_decode_type2_target(struct 
> Curl_easy *data,
> + target_info_len = Curl_read16_le([40]);
> + target_info_offset = Curl_read32_le([44]);
> + if(target_info_len > 0) {
> +-  if(((target_info_offset + target_info_len) > size) ||
> ++  if((target_info_offset >= size) ||
> ++ ((target_info_offset + target_info_len) > size) ||
> +  (target_info_offset < 48)) {
> + infof(data, "NTLM handshake failure (bad type-2 message). "
> +-"Target Info Offset Len is set incorrect by the 
> peer\n");
> ++  "Target Info Offset Len is set incorrect by the peer\n");
> + return CURLE_BAD_CONTENT_ENCODING;
> +   }
> + 
> +-- 
> +2.22.0
> +
> diff --git a/meta/recipes-support/curl/curl/CVE-2019-3822.patch 
> b/meta/recipes-support/curl/curl/CVE-2019-3822.patch
> new file mode 100644
> index 00..4f612ddd5e
> --- /dev/null
> +++ b/meta/recipes-support/curl/curl/CVE-2019-3822.patch
> @@ -0,0 +1,47 @@
> +From 761b51f66c7b1cd2cd6c71b807bfdb6a27c49b30 Mon Sep 17 00:00:00 2001
> +From: Daniel Stenberg 
> +Date: Thu, 3 Jan 2019 12:59:28 +0100
> +Subject: [PATCH 2/3] ntlm: fix *_type3_message size check to avoid buffer
> + overflow
> +
> +Bug: https://curl.haxx.se/docs/CVE-2019-3822.html
> +Reported-by: Wenxiang Qian
> +CVE-2019-3822
> +
> +Upstream-Status: Backport
> +[https://github.com/curl/curl/commit
> +/50c9484278c63b958655a717844f0721263939cc]
> +
> +CVE: CVE-2019-3822
> +
> +Signed-off-by: Kevin Weng 
> +---
> + lib/vauth/ntlm.c | 11 +++
> + 1 file changed, 7 insertions(+), 4 deletions(-)
> +
> +diff --git a/lib/vauth/ntlm.c b/lib/vauth/ntlm.c
> +index 0212756ab..3be0403d9 100644
> +--- a/lib/vauth/ntlm.c
>  b/lib/vauth/ntlm.c
> +@@ -777,11 +777,14 @@ CURLcode Curl_auth_create_ntlm_type3_message(struct 
> Curl_easy *data,
> +   });
> + 
> + #ifdef USE_NTRESPONSES
> +-  if(size < (NTLM_BUFSIZE - ntresplen)) {
> +-DEBUGASSERT(size == (size_t)ntrespoff);
> +-memcpy([size], ptr_ntresp, ntresplen);
> +-size += ntresplen;
> ++  /* ntresplen + size should not be risking an integer overflow here */
> ++  if(ntresplen + size > sizeof(ntlmbuf)) {
> ++failf(data, "incoming NTLM message too big");
> ++return CURLE_OUT_OF_MEMORY;
> +   }
> ++  DEBUGASSERT(size == (size_t)ntrespoff);
> ++  memcpy([size], ptr_ntresp, ntresplen);
> ++  size += ntresplen;
> + 
> +   DEBUG_OUT({
> + fprintf(stderr, "\n   ntresp=");
> +-- 
> +2.22.0
> +
> diff --git a/meta/recipes-support/curl/curl/CVE-2019-3823.patch 
> b/meta/recipes-support/curl/curl/CVE-2019-3823.patch
> new file mode 100644
> index 00..194e6e6430
> --- /dev/null
> +++ b/meta/recipes-support/curl/curl/CVE-2019-3823.patch
> @@ -0,0 +1,55 @@
> +From 40f6c913f63cdbfa81daa7ac7f1c7415bb99edeb Mon Sep 17 00:00:00 2001
> +From: Daniel Gustafsson 
> 

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[richard . purdie]

On Wed, 2019-08-14 at 14:08 +0200, Alexander Kanavin wrote:
> On Wed, 14 Aug 2019 at 13:36, 
> wrote:
> > On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > > richard.pur...@linuxfoundation.org> wrote:
> > > > I had a glance at the profile output from master-next and the
> > > > problem
> > > > wasn't where I thought it would be, it was in the scheduler
> > code.
> > > > That
> > > > is good as those classes are effectively independent of the
> > other
> > > > changes and hence are a separate fix.
> > > > 
> > > > I've put a patch in -next which takes the above test to 36s
> > which
> > > > is
> > > > close to the older bitbake.
> > > > 
> > > > Could be interesting to see how it looks for others and
> > different
> > > > workloads.
> > > 
> > > I just tried the same test I did yesterday with
> > > ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it
> > doesn't
> > > seem to improve things much: bitbake is stuck at "NOTE: Executing
> > > Tasks" for 15 minutes now.
> > 
> > This might sound slightly crazy but can you try commenting out this
> > line in runqueue.py:
> > 
> > logger.debug(2, "Holding off tasks %s" %
> > pprint.pformat(self.holdoff_tasks))
> > 
> > ?
> 
> Even crazier is the outcome: it helped! 

Cool, I think I can explain it.

The holdoff_tasks list can contain a list of nearly all the tasks at
some points in execution. Even though the debug messages aren't being
printed on the console, they are being sent over the internal IPC bus
between the cooker, UI and other event handlers. Obviously for small
task lists its not a problem, for large ones its multiple 4k chunks
over pipes which isn't going to be fast.

We have done a lot of optimisation in the past but its all too easy to
trend on something like this and upset things :/.

> The whole thing completed after 15m49secons (with much of the time
> going to the empty task spin), that's some 3 minutes slower, but
> certainly it's usable again.

You followed up mentioning this wasn't with master-next. I think there
is a patch in -next which will help with the empty task spin so both
together might get us back to more normal numbers.

Cheers,

Richard

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

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[Alexander Kanavin]

On Wed, 14 Aug 2019 at 14:08, Alexander Kanavin 
wrote:

>
> This might sound slightly crazy but can you try commenting out this
>> line in runqueue.py:
>>
>> logger.debug(2, "Holding off tasks %s" %
>> pprint.pformat(self.holdoff_tasks))
>>
>> ?
>>
>
> Even crazier is the outcome: it helped! The whole thing completed after
> 15m49secons (with much of the time going to the empty task spin), that's
> some 3 minutes slower, but certainly it's usable again.
>
> I have not enabled the hash server at any point.
>

I need to clarify: this was with current master
(18b8e2e10494d3b0e18743a1bf9e99038da4229c), not master-next.

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

[OE-core] [PATCH] stress-ng: provide stress

[Mikko Rapeli]

Since stress-ng replaces and is compatible with stress,
provide stress to be compatible with the old recipe
and binary packages.

Signed-off-by: Mikko Rapeli 
---
 meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb 
b/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
index e800040..64e0928 100644
--- a/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
+++ b/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
@@ -14,6 +14,10 @@ SRC_URI[sha256sum] = 
"d09dd2a1aea549e478995bf9be90b38906a4cdf33ea7b245ef9d46aa52
 
 DEPENDS = "coreutils-native"
 
+PROVIDES = "stress"
+RPROVIDES_${PN} = "stress"
+RPROVIDES_${PN}-dev = "stress-dev"
+
 inherit bash-completion
 
 do_install() {
-- 
1.9.1

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

[OE-core] ✗ patchtest: failure for kernel-yocto: misc build / config changes

[Patchwork]

== Series Details ==

Series: kernel-yocto: misc build / config changes
Revision: 1
URL   : https://patchwork.openembedded.org/series/19276/
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:



* Patch[3/5] linux-yocto: arch/x86/boot: use prefix map to avoid 
embedded paths
 Issue Yocto Project bugzilla tag is not correctly formatted 
[test_bugzilla_entry_format] 
  Suggested fixSpecify bugzilla ID in commit description with format: 
"[YOCTO #]"



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

[Randy MacLeod]

On 8/6/19 2:51 AM, Martin Jansa wrote:

This is the same reproducer I am using in:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
but with this SRCREV I haven't reproduced it yet in first 500 
iterations, so it's definitely improving for me (used to reproduce it at 
least once in first 500 iterations)


Now I'm testing the reproducer with "qmake -install qinstall".


Any update Martin?



Using a variation of Juro's script and adding a little stress-ng load,
it _seems_ that I can make the problem happen more quickly than without
system stress but it's a shared system so _seems_ is underlined.

Using stress-ng was supposed to be a quick check to see if I could
get the reproducer down to minutes rather than around an hour.

Results are promising so I'll continue to use this approach as
I add debugging to pseudo and add an inline, immediate check in
the context of:

http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/glibc-locale.inc?h=master#n72
to see if the UID/GID are equal to my UID/GID.

Test runs summaries are below.

../Randy



cat src/distro/yocto/b/uid-diff/glibc-locale-stress
#!/bin/bash

fname='glibc-locale_master_august13'
max=100
for (( i=1; i <= $max; i++ ))
do
echo "$i/$max  ${fname}_$i.log"
bitbake glibc-locale -c cleanall 2>&1 > /dev/null
# add some stress
stress-ng -t 1000 --switch 8 --switch-freq 5 &
bitbake glibc-locale 2>&1 > ${fname}_$i.log
# Destress
killall -9 stress-ng
if grep -q "host-user-contaminated" ${fname}_$i.log; then
echo "error !"
  exit 2
#else
  #rm ${fname}_$i.log
fi
done


On a (shared) system where lscpu shows 128 cores
and no stress:

Trial   Iteration Error
1   44
2   19


stress-ng -t 1000 --switch 8 --switch-freq 5

5 was just the frequency that generated a high enough
but not too high load. On this systems, each process used ~30% of a cpu.

Trial   Iteration Error
1   3
2   18


stress-ng -t 1000 --switch 16 --switch-freq 5

Trial   Iteration Error
1   3
2   1
3   11

stress-ng -t 1000 --switch 32 --switch-freq 5

Trial   Iteration Error
1   2
2   9
3   8


stress-ng -t 1000 --switch 64 --switch-freq 5

Trial   Iteration Error
1   4
2   13
3   >6


stress-ng -t 1000 --mq 64
 128 processes using 98% cpu each

Trial   Iteration Error
1   14
2   NaN

Trial 2 was precluded by other users of the shared system complaining!
The idea was to cause more rapid context switches. Later, I might try
this again with say 16 workers. If anyone has a better idea, please
reply.

EOM



Regards,

On Tue, Aug 6, 2019 at 12:43 AM Bystricky, Juro 
mailto:juro.bystri...@intel.com>> wrote:


I can reproduce the problem fairly easily  (and, sadly even with the
latest commits as 060058bb29f70b244e685b3c704eb0641b736f73 ).
In my case, it seems easy to reproduce if I have 40+ threads running.
The reproducer script (below) fails typically within the first 10
iterations.


#!/bin/bash

fname='glibc-locale_master_august8'
max=1000
for (( i=1; i <= $max; i++ ))
do
     echo "$i/$max  ${fname}_$i.log"
     bitbake glibc-locale -c cleanall 2>&1 > /dev/null
     bitbake glibc-locale 2>&1 > ${fname}_$i.log
      if grep -q "host-user-contaminated" ${fname}_$i.log; then
         echo "error !"
       exit 2
     #else
       #rm ${fname}_$i.log
     fi

done


From: openembedded-core-boun...@lists.openembedded.org

[openembedded-core-boun...@lists.openembedded.org
] on behalf
of Seebs [se...@seebs.net ]
Sent: Saturday, August 03, 2019 7:23 AM
To: Khem Raj
Cc: openembedded-core@lists.openembedded.org

Subject: Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix
openat() with a directory symlink [NAK]

On Sat, 3 Aug 2019 05:33:46 -0700
Khem Raj mailto:raj.k...@gmail.com>> wrote:

 > Will this fix the file ownership issue that we see with Glibc-locale
 > packages from time to time?

I have no idea. Since I haven't got a reliable reproducer for it, I
can't test it in a sane way.

-s
--
___
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





--
# Randy MacLeod
# Wind River Linux
--

[OE-core] ✗ patchtest: failure for gcc-cross-canadian: Drop obsolete shlibs exclusion

[Patchwork]

== Series Details ==

Series: gcc-cross-canadian: Drop obsolete shlibs exclusion
Revision: 1
URL   : https://patchwork.openembedded.org/series/19277/
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 Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 6b36db8365)



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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

Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

[Martin Jansa]

"qmake -install qinstall" reproducer from the bugzilla ticket still
reproduces the issues every time even with latest pseudo, but that might be
different root cause than glibc-locale issue.

On Wed, Aug 14, 2019 at 6:02 PM Randy MacLeod 
wrote:

> On 8/6/19 2:51 AM, Martin Jansa wrote:
> > This is the same reproducer I am using in:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
> > but with this SRCREV I haven't reproduced it yet in first 500
> > iterations, so it's definitely improving for me (used to reproduce it at
> > least once in first 500 iterations)
> >
> > Now I'm testing the reproducer with "qmake -install qinstall".
>
> Any update Martin?
>
>
>
> Using a variation of Juro's script and adding a little stress-ng load,
> it _seems_ that I can make the problem happen more quickly than without
> system stress but it's a shared system so _seems_ is underlined.
>
> Using stress-ng was supposed to be a quick check to see if I could
> get the reproducer down to minutes rather than around an hour.
>
> Results are promising so I'll continue to use this approach as
> I add debugging to pseudo and add an inline, immediate check in
> the context of:
>
>
> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/glibc-locale.inc?h=master#n72
> to see if the UID/GID are equal to my UID/GID.
>
> Test runs summaries are below.
>
> ../Randy
>
>
>
> cat src/distro/yocto/b/uid-diff/glibc-locale-stress
> #!/bin/bash
>
> fname='glibc-locale_master_august13'
> max=100
> for (( i=1; i <= $max; i++ ))
> do
>  echo "$i/$max  ${fname}_$i.log"
>  bitbake glibc-locale -c cleanall 2>&1 > /dev/null
>  # add some stress
>  stress-ng -t 1000 --switch 8 --switch-freq 5 &
>  bitbake glibc-locale 2>&1 > ${fname}_$i.log
>  # Destress
>  killall -9 stress-ng
>  if grep -q "host-user-contaminated" ${fname}_$i.log; then
>  echo "error !"
>exit 2
>  #else
>#rm ${fname}_$i.log
>  fi
> done
>
>
> On a (shared) system where lscpu shows 128 cores
> and no stress:
>
> Trial   Iteration Error
> 1   44
> 2   19
>
>
> stress-ng -t 1000 --switch 8 --switch-freq 5
>
> 5 was just the frequency that generated a high enough
> but not too high load. On this systems, each process used ~30% of a cpu.
>
> Trial   Iteration Error
> 1   3
> 2   18
>
>
> stress-ng -t 1000 --switch 16 --switch-freq 5
>
> Trial   Iteration Error
> 1   3
> 2   1
> 3   11
>
> stress-ng -t 1000 --switch 32 --switch-freq 5
>
> Trial   Iteration Error
> 1   2
> 2   9
> 3   8
>
>
> stress-ng -t 1000 --switch 64 --switch-freq 5
>
> Trial   Iteration Error
> 1   4
> 2   13
> 3   >6
>
>
> stress-ng -t 1000 --mq 64
>   128 processes using 98% cpu each
>
> Trial   Iteration Error
> 1   14
> 2   NaN
>
> Trial 2 was precluded by other users of the shared system complaining!
> The idea was to cause more rapid context switches. Later, I might try
> this again with say 16 workers. If anyone has a better idea, please
> reply.
>
> EOM
>
> >
> > Regards,
> >
> > On Tue, Aug 6, 2019 at 12:43 AM Bystricky, Juro
> > mailto:juro.bystri...@intel.com>> wrote:
> >
> > I can reproduce the problem fairly easily  (and, sadly even with the
> > latest commits as 060058bb29f70b244e685b3c704eb0641b736f73 ).
> > In my case, it seems easy to reproduce if I have 40+ threads running.
> > The reproducer script (below) fails typically within the first 10
> > iterations.
> >
> >
> > #!/bin/bash
> >
> > fname='glibc-locale_master_august8'
> > max=1000
> > for (( i=1; i <= $max; i++ ))
> > do
> >  echo "$i/$max  ${fname}_$i.log"
> >  bitbake glibc-locale -c cleanall 2>&1 > /dev/null
> >  bitbake glibc-locale 2>&1 > ${fname}_$i.log
> >   if grep -q "host-user-contaminated" ${fname}_$i.log; then
> >  echo "error !"
> >exit 2
> >  #else
> >#rm ${fname}_$i.log
> >  fi
> >
> > done
> >
> > 
> > From: openembedded-core-boun...@lists.openembedded.org
> > 
> > [openembedded-core-boun...@lists.openembedded.org
> > ] on behalf
> > of Seebs [se...@seebs.net ]
> > Sent: Saturday, August 03, 2019 7:23 AM
> > To: Khem Raj
> > Cc: openembedded-core@lists.openembedded.org
> > 
> > Subject: Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix
> > openat() with a directory symlink [NAK]
> >
> > On Sat, 3 Aug 2019 05:33:46 -0700
> > Khem Raj mailto:raj.k...@gmail.com>> wrote:
> >
> >  > Will this fix the file ownership issue that we see with
> Glibc-locale
> >  > packages from time to time?
> >
> > I have no idea. Since I haven't got a 

Re: [OE-core] [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M

[Alexander Kanavin]

On Wed, 14 Aug 2019 at 18:42, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> I'm not sure I agree with this.
>
> We are meant to work on embedded systems and 256MB should be enough to
> let us bring up X under qemu.
>
> I'm fine with some sdk/ptest images having more memory, that makes
> sense but 256MB not allowing X under qemu seems rather poor.
>
> Are we really saying the minimal image size we can emulate is 256MB
> ram?
>

Note that riscv/arm/arm64 qemu configs *already* override this setting to
512M, as seen in the patch (and so does
meta-yocto-bsp/conf/machine/beaglebone-yocto.conf), so this simply brings
x86/mips/ppc as well to that level.

In our local development we have bumped it even to 2048M, because with 256M
there are cryptic boot failures (that have nothing to do with X), and the
final SoC target will have far more memory anyway. Embedded does not
necessarily mean "not a lot of RAM".

If there is a need to test tight-memory scenarios, that can be adjusted
per-image (or per-distro like poky-tiny), but I would argue that the
default should be such that no one has to stare at mysterious error
messages that are ultimately due to lack of RAM. It is not easy to diagnose
such situations, e.g. the error message here was "unable to execute
xkbcomp", so I had to rebuild the image with strace, and then run X under
it to see that the problem was clone() returning with ENOMEM.  We'll be
surely seeing more of the same as software bloat marches on.

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

Re: [OE-core] [PATCH] stress-ng: provide stress

[Richard Purdie]

On Wed, 2019-08-14 at 15:56 +0300, Mikko Rapeli wrote:
> Since stress-ng replaces and is compatible with stress,
> provide stress to be compatible with the old recipe
> and binary packages.
> 
> Signed-off-by: Mikko Rapeli 
> ---
>  meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
> b/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
> index e800040..64e0928 100644
> --- a/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
> +++ b/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
> @@ -14,6 +14,10 @@ SRC_URI[sha256sum] =
> "d09dd2a1aea549e478995bf9be90b38906a4cdf33ea7b245ef9d46aa52
>  
>  DEPENDS = "coreutils-native"
>  
> +PROVIDES = "stress"
> +RPROVIDES_${PN} = "stress"
> +RPROVIDES_${PN}-dev = "stress-dev"
> +

Isn't that going to need RCONFLICTS and RREPLACES too?

Cheers,

Richard

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

[OE-core] [PATCH v2] stress-ng: provide stress

[Mikko Rapeli]

Since stress-ng replaces and is compatible with stress,
provide stress to be compatible with the old recipe
and binary packages.

Signed-off-by: Mikko Rapeli 
---
 meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb | 5 +
 1 file changed, 5 insertions(+)

v2: added RCONFLICTS and RREPLACES, removed -dev package since it's actually 
empty,
decided not to add transition support for stress-ng-bashcompletion because
I don't need it

v1: 
http://lists.openembedded.org/pipermail/openembedded-core/2019-August/285724.html

diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb 
b/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
index e800040..7d194b3 100644
--- a/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
+++ b/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
@@ -14,6 +14,11 @@ SRC_URI[sha256sum] = 
"d09dd2a1aea549e478995bf9be90b38906a4cdf33ea7b245ef9d46aa52
 
 DEPENDS = "coreutils-native"
 
+PROVIDES = "stress"
+RPROVIDES_${PN} = "stress"
+RREPLACES_${PN} = "stress"
+RCONFLICTS_${PN} = "stress"
+
 inherit bash-completion
 
 do_install() {
-- 
1.9.1

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

[OE-core] [PATCH 3/3] qemu: switch to '-vga std' emulated hardware from vmware/cirrus for x86/mips

[Alexander Kanavin]

This is the qemu default since qemu 2.2, is generally supported better,
and is recommended by upstream. It also has already been in use for arm/risc
and ovmf.

Additional information:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/

'-vga virtio' emulated hardware remains in use when virgl is enabled via a 
runqemu override.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/machine/include/qemuboot-mips.inc | 2 +-
 meta/conf/machine/include/qemuboot-x86.inc  | 2 +-
 meta/conf/machine/qemux86-64.conf   | 1 +
 meta/conf/machine/qemux86.conf  | 1 +
 scripts/runqemu | 6 --
 5 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-mips.inc 
b/meta/conf/machine/include/qemuboot-mips.inc
index 3a4c8f96f1e..18221dc0a76 100644
--- a/meta/conf/machine/include/qemuboot-mips.inc
+++ b/meta/conf/machine/include/qemuboot-mips.inc
@@ -2,7 +2,7 @@
 IMAGE_CLASSES += "qemuboot"
 QB_MACHINE = "-machine malta"
 QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty"
-QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -device usb-tablet"
+QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
 QB_SYSTEM_NAME = "qemu-system-${TUNE_ARCH}"
diff --git a/meta/conf/machine/include/qemuboot-x86.inc 
b/meta/conf/machine/include/qemuboot-x86.inc
index 3931b0f0fb3..495418fa04b 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -9,7 +9,7 @@ QB_CPU_KVM_x86-64 = "-cpu core2duo"
 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"
 QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=${UVESA_MODE} 
oprofile.timer=1 uvesafb.task_timeout=-1"
-QB_OPT_APPEND = "-vga vmware -show-cursor -usb -device usb-tablet"
+QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
 
diff --git a/meta/conf/machine/qemux86-64.conf 
b/meta/conf/machine/qemux86-64.conf
index 4b50e664e42..7c70dbddf52 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -24,6 +24,7 @@ XSERVER = "xserver-xorg \
xf86-video-fbdev \
xf86-video-vmware \
xf86-video-modesetting \
+   xf86-video-vesa \
xserver-xorg-module-libint10 \
"
 
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index 3832302f07b..8e0da820761 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -24,6 +24,7 @@ XSERVER = "xserver-xorg \
xf86-video-fbdev \
xf86-video-vmware \
xf86-video-modesetting \
+   xf86-video-vesa \
xserver-xorg-module-libint10 \
"
 
diff --git a/scripts/runqemu b/scripts/runqemu
index df3c8aad084..8f9a0d7dbb4 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -145,8 +145,6 @@ class BaseConfig(object):
 # to be added with -drive if=pflash.
 # Found in the same places as the rootfs, with or without one of
 # these suffices: qcow2, bin.
-# Setting one also adds "-vga std" because that is all that
-# OVMF supports.
 self.ovmf_bios = []
 # When enrolling default Secure Boot keys, the hypervisor
 # must provide the Platform Key and the first Key Exchange Key
@@ -1280,10 +1278,6 @@ class BaseConfig(object):
 for ovmf in self.ovmf_bios:
 format = ovmf.rsplit('.', 1)[-1]
 self.qemu_opt += ' -drive if=pflash,format=%s,file=%s' % (format, 
ovmf)
-if self.ovmf_bios:
-# OVMF only supports normal VGA, i.e. we need to override a -vga 
vmware
-# that gets added for example for normal qemux86.
-self.qemu_opt += ' -vga std'
 
 self.qemu_opt += ' ' + self.qemu_opt_script
 
-- 
2.17.1

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

[OE-core] [PATCH 1/3] linux-yocto: add drm-bochs support

[Alexander Kanavin]

This allows better modesetting support for the '-vga std'
emulated hardware provided by Qemu, which we want to
standardize on.

See here for background:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb  | 2 +-
 meta/recipes-kernel/linux/linux-yocto_4.19.bb| 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.0.bb | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 96117ccf3f7..2268faf512c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -46,7 +46,7 @@ KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb"
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc"
 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
-KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc 
features/drm-bochs/drm-bochs.scc"
 KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
 KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " 
cfg/x32.scc", "" ,d)}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
index 4013a0c2d0b..e2108a6e2bd 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
@@ -38,7 +38,7 @@ KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb"
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc"
 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
-KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc 
features/drm-bochs/drm-bochs.scc"
 KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/scsi/scsi-debug.scc", "" ,d)}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
index 9e822f2e7f3..71fd5734ada 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
@@ -38,7 +38,7 @@ KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb"
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc"
 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
-KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc 
features/drm-bochs/drm-bochs.scc"
 KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/scsi/scsi-debug.scc", "" ,d)}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
index cee8af7c995..5a45e7502c4 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
@@ -43,7 +43,7 @@ COMPATIBLE_MACHINE = 
"qemuarm|qemuarmv5|qemuarm64|qemux86|qemuppc|qemumips|qemum
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
-KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc 
features/drm-bochs/drm-bochs.scc"
 KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " 
cfg/x32.scc", "" ,d)}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.0.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
index 0e4a372d2dd..87fe42ea2ab 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
@@ -47,7 +47,7 @@ COMPATIBLE_MACHINE = 
"qemuarm|qemuarmv5|qemuarm64|qemux86|qemuppc|qemumips|qemum
 # Functionality flags
 KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
 KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
-KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc 
features/drm-bochs/drm-bochs.scc"
 KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " 
cfg/x32.scc", "" ,d)}"
-- 
2.17.1

-- 

[OE-core] [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M

[Alexander Kanavin]

This was already the case for various specific qemu machines,
and 256M was found to be no longer sufficient for x86 either when
switching X from vmware to standard vga+bochs vesa driver as provided
by qemu (Xorg would then attempt to clone() itself with ENOMEM returned).

Let's just accept this new reality :)

Signed-off-by: Alexander Kanavin 
---
 meta/classes/qemuboot.bbclass | 2 +-
 meta/conf/machine/include/qemuboot-mips.inc   | 1 -
 meta/conf/machine/include/riscv/qemuriscv.inc | 1 -
 meta/conf/machine/qemuarm.conf| 1 -
 meta/conf/machine/qemuarm64.conf  | 1 -
 5 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 15a9e63f2b2..9d4f4dbd70b 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -57,7 +57,7 @@
 # IMAGE_CLASSES += "qemuboot"
 # See "runqemu help" for more info
 
-QB_MEM ?= "-m 256"
+QB_MEM ?= "-m 512"
 QB_SERIAL_OPT ?= "-serial mon:stdio -serial null"
 QB_DEFAULT_KERNEL ?= "${KERNEL_IMAGETYPE}"
 QB_DEFAULT_FSTYPE ?= "ext4"
diff --git a/meta/conf/machine/include/qemuboot-mips.inc 
b/meta/conf/machine/include/qemuboot-mips.inc
index 75bb98861f8..3a4c8f96f1e 100644
--- a/meta/conf/machine/include/qemuboot-mips.inc
+++ b/meta/conf/machine/include/qemuboot-mips.inc
@@ -1,6 +1,5 @@
 # For runqemu
 IMAGE_CLASSES += "qemuboot"
-QB_MEM = "-m 256"
 QB_MACHINE = "-machine malta"
 QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty"
 QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -device usb-tablet"
diff --git a/meta/conf/machine/include/riscv/qemuriscv.inc 
b/meta/conf/machine/include/riscv/qemuriscv.inc
index 84d09fa78e2..bd7568121cc 100644
--- a/meta/conf/machine/include/riscv/qemuriscv.inc
+++ b/meta/conf/machine/include/riscv/qemuriscv.inc
@@ -24,7 +24,6 @@ UBOOT_ENTRYPOINT_riscv64 = "0x8020"
 
 # qemuboot options
 QB_KERNEL_CMDLINE_APPEND = "earlycon=sbi"
-QB_MEM = "-m 512"
 QB_MACHINE = "-machine virt"
 QB_DEFAULT_KERNEL = "fw_jump.elf"
 QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
diff --git a/meta/conf/machine/qemuarm.conf b/meta/conf/machine/qemuarm.conf
index 0a2c9953125..26f40b14194 100644
--- a/meta/conf/machine/qemuarm.conf
+++ b/meta/conf/machine/qemuarm.conf
@@ -11,7 +11,6 @@ SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
 
 # For runqemu
 QB_SYSTEM_NAME = "qemu-system-arm"
-QB_MEM = "-m 512"
 QB_MACHINE = "-machine virt"
 QB_CPU = "-cpu cortex-a15"
 # Standard Serial console
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index 353ac927d94..ec2a887bddf 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -11,7 +11,6 @@ SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
 
 # For runqemu
 QB_SYSTEM_NAME = "qemu-system-aarch64"
-QB_MEM = "-m 512"
 QB_MACHINE = "-machine virt"
 QB_CPU = "-cpu cortex-a57"
 QB_CPU_KVM = "-cpu host"
-- 
2.17.1

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

Re: [OE-core] [PATCH] stress-ng: provide stress

[Mikko.Rapeli]

On Wed, Aug 14, 2019 at 03:38:56PM +0100, Richard Purdie wrote:
> On Wed, 2019-08-14 at 15:56 +0300, Mikko Rapeli wrote:
> > Since stress-ng replaces and is compatible with stress,
> > provide stress to be compatible with the old recipe
> > and binary packages.
> > 
> > Signed-off-by: Mikko Rapeli 
> > ---
> >  meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
> > b/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
> > index e800040..64e0928 100644
> > --- a/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
> > +++ b/meta/recipes-extended/stress-ng/stress-ng_0.10.00.bb
> > @@ -14,6 +14,10 @@ SRC_URI[sha256sum] =
> > "d09dd2a1aea549e478995bf9be90b38906a4cdf33ea7b245ef9d46aa52
> >  
> >  DEPENDS = "coreutils-native"
> >  
> > +PROVIDES = "stress"
> > +RPROVIDES_${PN} = "stress"
> > +RPROVIDES_${PN}-dev = "stress-dev"
> > +
> 
> Isn't that going to need RCONFLICTS and RREPLACES too?

I did not need them. I'm not updating existing images or mixing
stress and stress-ng binary packages in a package repo.

But I will add them in a v2.

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

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[Peter Kjellerstedt]

> -Original Message-
> From: richard.pur...@linuxfoundation.org
> 
> Sent: den 14 augusti 2019 14:56
> To: Alexander Kanavin 
> Cc: Peter Kjellerstedt ; Khem Raj
> ; OE-core  c...@lists.openembedded.org>
> Subject: Re: [OE-core] Long delays with latest bitbake (was: [PATCH
> 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS
> recursively)
> 
> On Wed, 2019-08-14 at 14:08 +0200, Alexander Kanavin wrote:
> > On Wed, 14 Aug 2019 at 13:36, 
> > wrote:
> > > On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > > > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > > > richard.pur...@linuxfoundation.org> wrote:
> > > > > I had a glance at the profile output from master-next and the
> > > > > problem
> > > > > wasn't where I thought it would be, it was in the scheduler
> > > code.
> > > > > That
> > > > > is good as those classes are effectively independent of the
> > > other
> > > > > changes and hence are a separate fix.
> > > > >
> > > > > I've put a patch in -next which takes the above test to 36s
> > > which
> > > > > is
> > > > > close to the older bitbake.
> > > > >
> > > > > Could be interesting to see how it looks for others and
> > > different
> > > > > workloads.
> > > >
> > > > I just tried the same test I did yesterday with
> > > > ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it
> > > doesn't
> > > > seem to improve things much: bitbake is stuck at "NOTE: Executing
> > > > Tasks" for 15 minutes now.
> > >
> > > This might sound slightly crazy but can you try commenting out this
> > > line in runqueue.py:
> > >
> > > logger.debug(2, "Holding off tasks %s" %
> > > pprint.pformat(self.holdoff_tasks))
> > >
> > > ?
> >
> > Even crazier is the outcome: it helped!
> 
> Cool, I think I can explain it.
> 
> The holdoff_tasks list can contain a list of nearly all the tasks at
> some points in execution. Even though the debug messages aren't being
> printed on the console, they are being sent over the internal IPC bus
> between the cooker, UI and other event handlers. Obviously for small
> task lists its not a problem, for large ones its multiple 4k chunks
> over pipes which isn't going to be fast.
> 
> We have done a lot of optimisation in the past but its all too easy to
> trend on something like this and upset things :/.
> 
> > The whole thing completed after 15m49secons (with much of the time
> > going to the empty task spin), that's some 3 minutes slower, but
> > certainly it's usable again.
> 
> You followed up mentioning this wasn't with master-next. I think there
> is a patch in -next which will help with the empty task spin so both
> together might get us back to more normal numbers.
> 
> Cheers,
> 
> Richard

I can just confirm that removing the debug line removes almost all of 
the delays I was seeing. Here are some time statistics from my builds:

6c7c0cef: 02:50
7df31ff3: 06:13  (first attempt)
a0542ed3: 06:32  (master)
19a88c68: 43:19* (~yesterday's master-next)
b0a0e4a6: 06:55  (master-next)
no debug: 03:04  (master-next + removal of "Holding off tasks" debug)

* I aborted this build after about half of the 12540 tasks were done...

One thing I have noticed while I was doing the timings is that I do 
not seem to be able to kill the bitbake server with bitbake -m after 
the builds have completed, but have to resort to using kill -9 most 
of the time... 

//Peter

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

[OE-core] cmake find_program and hosttools_dir

[Michael Ho]

Hi all,

I wanted to ask what would be a good way to fix an issue with cmake
find_program and the tools listed in ASSUME_PROVIDED. I checked against the
Warrior branch and it seems that currently find_program does not search the
hosttools directory for programs because HOSTTOOLS_DIR is not listed in the
CMAKE_FIND_ROOT_PATH variable (in cmake.bbclass). This means if you call
find_program to get the path to the git binary, it will fail to find the
program. I've attached a minimal recipe and CMakeLists.txt to demonstrate.

If you attempt to compile the recipe, you'll see:
| CMake Error at CMakeLists.txt:6 (message):
|   No git binary found

If I modify the cmake.bbclass and add this directory to CMAKE_FIND_ROOT_PATH,
it still fails because by default it wants to only search in the
subdirectories bin and usr/bin. If I then modify base.bbclass to generate a
"bin" symlink in the hosttools directory that points back to the hosttools
directory, it is enough to trick cmake. I also found a second solution where
if I instead add a default definition to CMAKE_PROGRAM_PATH to include the
root directory, this works also. I've included this second fix in the patch
I've sent.

Is this a good solution or is there something I'm missing here?

Thanks.

Kind regards,
Michael Ho

$ cat files/CMakeLists.txt
cmake_minimum_required (VERSION 2.6)
project (Tutorial)

find_program(HOST_GIT git)
if(NOT HOST_GIT)
message(FATAL_ERROR "No git binary found")
endif()

$ cat find-git.bb
SUMMARY = "Example recipe to test find_program and git-native"
LICENSE = "CLOSED"

DEPENDS = "git-native"

SRC_URI = "file://CMakeLists.txt"
S = "${WORKDIR}"

inherit cmake

do_install() {
:
}
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake.bbclass: add HOSTTOOLS_DIR to CMAKE_FIND_ROOT_PATH

[Michael Ho]

The find_program command will fail if it is used on a tool that is listed in
ASSUME_PROVIDED. This is because these tools are in the hosttools directory
which is not listed in CMAKE_FIND_ROOT_PATH so cmake will not find them.

Adding the directory HOSTTOOLS_DIR to the CMAKE_FIND_ROOT_PATH variable fixes
the initial issue of needing to search for tools in ASSUME_PROVIDED.

Note that this change alone does not fix the issue because find_program will
by default only look into the subdirectories bin and usr/bin under the paths
in CMAKE_FIND_ROOT_PATH to find the programs and the hosttools directory has
instead the symlinks directly present without these subdirectories.

Set CMAKE_PROGRAM_PATH to by default include the root directory so
find_program can search the hosttools directory without needing the prefix
directories.
---
 meta/classes/cmake.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index d3f0d70..f41eb8d 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -99,11 +99,12 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE 
STRING "LDFLAGS" )
 
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
-set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
+set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN} ${HOSTTOOLS_DIR})
 set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM} )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
+set( CMAKE_PROGRAM_PATH "/" )
 
 # Use qt.conf settings
 set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
-- 
2.7.4

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

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[Khem Raj]

On Wed, Aug 14, 2019 at 7:57 AM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: richard.pur...@linuxfoundation.org
> > 
> > Sent: den 14 augusti 2019 14:56
> > To: Alexander Kanavin 
> > Cc: Peter Kjellerstedt ; Khem Raj
> > ; OE-core  > c...@lists.openembedded.org>
> > Subject: Re: [OE-core] Long delays with latest bitbake (was: [PATCH
> > 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS
> > recursively)
> >
> > On Wed, 2019-08-14 at 14:08 +0200, Alexander Kanavin wrote:
> > > On Wed, 14 Aug 2019 at 13:36, 
> > > wrote:
> > > > On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > > > > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > > > > richard.pur...@linuxfoundation.org> wrote:
> > > > > > I had a glance at the profile output from master-next and the
> > > > > > problem
> > > > > > wasn't where I thought it would be, it was in the scheduler
> > > > code.
> > > > > > That
> > > > > > is good as those classes are effectively independent of the
> > > > other
> > > > > > changes and hence are a separate fix.
> > > > > >
> > > > > > I've put a patch in -next which takes the above test to 36s
> > > > which
> > > > > > is
> > > > > > close to the older bitbake.
> > > > > >
> > > > > > Could be interesting to see how it looks for others and
> > > > different
> > > > > > workloads.
> > > > >
> > > > > I just tried the same test I did yesterday with
> > > > > ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it
> > > > doesn't
> > > > > seem to improve things much: bitbake is stuck at "NOTE: Executing
> > > > > Tasks" for 15 minutes now.
> > > >
> > > > This might sound slightly crazy but can you try commenting out this
> > > > line in runqueue.py:
> > > >
> > > > logger.debug(2, "Holding off tasks %s" %
> > > > pprint.pformat(self.holdoff_tasks))
> > > >
> > > > ?
> > >
> > > Even crazier is the outcome: it helped!
> >
> > Cool, I think I can explain it.
> >
> > The holdoff_tasks list can contain a list of nearly all the tasks at
> > some points in execution. Even though the debug messages aren't being
> > printed on the console, they are being sent over the internal IPC bus
> > between the cooker, UI and other event handlers. Obviously for small
> > task lists its not a problem, for large ones its multiple 4k chunks
> > over pipes which isn't going to be fast.
> >
> > We have done a lot of optimisation in the past but its all too easy to
> > trend on something like this and upset things :/.
> >
> > > The whole thing completed after 15m49secons (with much of the time
> > > going to the empty task spin), that's some 3 minutes slower, but
> > > certainly it's usable again.
> >
> > You followed up mentioning this wasn't with master-next. I think there
> > is a patch in -next which will help with the empty task spin so both
> > together might get us back to more normal numbers.
> >
> > Cheers,
> >
> > Richard
>
> I can just confirm that removing the debug line removes almost all of
> the delays I was seeing. Here are some time statistics from my builds:
>
> 6c7c0cef: 02:50
> 7df31ff3: 06:13  (first attempt)
> a0542ed3: 06:32  (master)
> 19a88c68: 43:19* (~yesterday's master-next)
> b0a0e4a6: 06:55  (master-next)
> no debug: 03:04  (master-next + removal of "Holding off tasks" debug)
>
> * I aborted this build after about half of the 12540 tasks were done...
>
> One thing I have noticed while I was doing the timings is that I do
> not seem to be able to kill the bitbake server with bitbake -m after
> the builds have completed, but have to resort to using kill -9 most
> of the time...

me too.  My world build time came down to < 15 mins as well, Last
night it was at 45 mins and still parsing before I stopped it.

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

[OE-core] [PATCH 2/5] kern-tools: Add SPDX license headers to source files

[bruce . ashfield]

From: Bruce Ashfield 

Integrating the following commit:

Add SPDX license headers to source files

Kconfiglib/* were under ISC license before they were imported
here from https://github.com/ulfalizer/Kconfiglib
Adjusting SPDX header to reflect that fact.

tools/* all have some sort of GPLv2 headers; adding SPDX header
to make it obvious.

This address bug #13334 :
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13334

Change-Id: I243f2dd266a398f982798b771e74a67be70ecb52
Signed-off-by: William Bourque 

Signed-off-by: William Bourque 
Signen-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb 
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 5c1d7f691f..c8e736a987 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -1,10 +1,10 @@
 SUMMARY = "Tools for managing Yocto Project style branched kernels"
 LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = 
"file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1bda400e2828845ba0d06c"
+LIC_FILES_CHKSUM = 
"file://git/tools/kgit;beginline=5;endline=9;md5=9c30e971d435e249624278c3e343e501"
 
 DEPENDS = "git-native"
 
-SRCREV = "af1a779f662c81da521e4d602f3c6446547d12a2"
+SRCREV = "7604d2d1a49d88e38d5b5854209dc1435b790893"
 PR = "r12"
 PV = "0.2+git${SRCPV}"
 
-- 
2.19.1

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

[OE-core] [PATCH 3/5] linux-yocto: arch/x86/boot: use prefix map to avoid embedded paths

[bruce . ashfield]

From: Bruce Ashfield 

>From the kernel patch:

[
It was observed that the kernel embeds the path in the x86 boot
artifacts.

From https://bugzilla.yoctoproject.org/show_bug.cgi?id=13458:

[
   If you turn on the buildpaths QA test, or try a reproducible build, you
   discover that the kernel image contains build paths.

   $ strings bzImage-5.0.19-yocto-standard |grep tmp/
   out of pgt_buf in
   
/data/poky-tmp/reproducible/tmp/work-shared/qemux86-64/kernel-source/arch/x86/boot/compressed/kaslr_64.c!?

   But what's this in the top-level Makefile:

   $ git grep prefix-map
   Makefile:KBUILD_CFLAGS  += $(call
   cc-option,-fmacro-prefix-map=$(srctree)/=)

   So the __FILE__ shouldn't be using the full path.  However
   arch/x86/boot/compressed/Makefile has this:

   KBUILD_CFLAGS := -m$(BITS) -O2

   So that clears KBUILD_FLAGS, removing the -fmacro-prefix-map option.
]

Other architectures do not clear the flags, but instead prune before
adding boot or specific options. There's no obvious reason why x86 isn't
doing the same thing (pruning vs clearing) and no build or boot issues
have been observed.

So we make x86 can do the same thing, and we no longer have embedded paths.
]

This issue has been reported upstream, and a patch submission is
pending, but for now, we'll soak the proposed patch in linux-yocto to
see if any issues are found

[YOCTO: #13458]

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/linux-yocto-rt_5.0.bb |  4 ++--
 .../linux/linux-yocto-tiny_5.0.bb  |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_5.0.bb   | 18 +-
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
index 9e822f2e7f..f66ee6f4ad 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
@@ -11,8 +11,8 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "9c1e84c9b81b6bf1df55f26f2e0517266c37f7eb"
-SRCREV_meta ?= "c2e34d9ab2894edc6abc6be9ac89907bf4348447"
+SRCREV_machine ?= "e6cb812b5532630b6fc6dfd7778d57a4907d3180"
+SRCREV_meta ?= "96c82f3d7ab25a3f44e517f9dbbb53e2c4c45729"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.0;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
index a1719651b6..42e0dcd603 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
@@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine_qemuarm ?= "fabee455f397ba8054f35a3ad5f2250bbad93bef"
-SRCREV_machine ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
-SRCREV_meta ?= "c2e34d9ab2894edc6abc6be9ac89907bf4348447"
+SRCREV_machine_qemuarm ?= "b9001287984b0066814c8739f38d629de73739b7"
+SRCREV_machine ?= "55dd15336b7301b686a0c183f5372b49c1003d03"
+SRCREV_meta ?= "96c82f3d7ab25a3f44e517f9dbbb53e2c4c45729"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.0.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
index 0e4a372d2d..ea4b6f5b33 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
@@ -12,16 +12,16 @@ KBRANCH_qemux86  ?= "v5.0/standard/base"
 KBRANCH_qemux86-64 ?= "v5.0/standard/base"
 KBRANCH_qemumips64 ?= "v5.0/standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "9161b2fa2f1cec0ba02976c389c788445858e0de"
-SRCREV_machine_qemuarm64 ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
-SRCREV_machine_qemumips ?= "7de9b8f0db98e51a666477c8e2b64f1964b45410"
-SRCREV_machine_qemuppc ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
+SRCREV_machine_qemuarm ?= "d1ed980ad989252d42386c8bc63b2f5f11985ea4"
+SRCREV_machine_qemuarm64 ?= "55dd15336b7301b686a0c183f5372b49c1003d03"
+SRCREV_machine_qemumips ?= "1520e78195e64f27be46a46a8d6711c8470fb083"
+SRCREV_machine_qemuppc ?= "55dd15336b7301b686a0c183f5372b49c1003d03"
 SRCREV_machine_qemuriscv64 ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
-SRCREV_machine_qemux86 ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
-SRCREV_machine_qemux86-64 ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
-SRCREV_machine_qemumips64 ?= "5a8b27bcc0b16077ab8edfcd3fb25c80dc2c652e"
-SRCREV_machine ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
-SRCREV_meta ?= "c2e34d9ab2894edc6abc6be9ac89907bf4348447"
+SRCREV_machine_qemux86 ?= "55dd15336b7301b686a0c183f5372b49c1003d03"
+SRCREV_machine_qemux86-64 ?= "55dd15336b7301b686a0c183f5372b49c1003d03"
+SRCREV_machine_qemumips64 ?= 

[OE-core] [PATCH 0/5] kernel-yocto: misc build / config changes

[bruce . ashfield]

From: Bruce Ashfield 

Hi all,

This pull request is a collection of smaller fixes that I've been collecting
while I work through the 5.2/5.3 kernel intro, new libc-headers, etc. There's
no reason to make them wait while I finish that work, so here they are in a
single branch.

There's nothing major here, just a some legwork changes, licensing update
and a short term workaround for embedded host paths in the kernel binaries.

Cheers,

Bruce

The following changes since commit 88c6be81a5fbed098999fbef5576c5e0bb90cc21:

  opensbi: handle deploy task under sstate (2019-08-06 11:24:27 +0100)

are available in the Git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (5):
  kernel-devsrc: tweak for v5.3+
  kern-tools: Add SPDX license headers to source files
  linux-yocto: arch/x86/boot: use prefix map to avoid embedded paths
  kernel-yocto: import security fragments from meta-security
  kconf_check: tweak CONFIG_ regex

 .../kern-tools/kern-tools-native_git.bb|  4 ++--
 meta/recipes-kernel/linux/kernel-devsrc.bb |  4 ++--
 .../linux/linux-yocto-rt_4.19.bb   |  2 +-
 .../recipes-kernel/linux/linux-yocto-rt_5.0.bb |  4 ++--
 .../linux/linux-yocto-tiny_4.19.bb |  2 +-
 .../linux/linux-yocto-tiny_5.0.bb  |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.19.bb  |  2 +-
 meta/recipes-kernel/linux/linux-yocto_5.0.bb   | 18 +-
 8 files changed, 21 insertions(+), 21 deletions(-)

-- 
2.19.1

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

[OE-core] [PATCH 5/5] kconf_check: tweak CONFIG_ regex

[bruce . ashfield]

From: Bruce Ashfield 

As reported in https://bugzilla.yoctoproject.org/show_bug.cgi?id=12563,
the regex that matches valid CONFIG_ options was missing some of the
ones in net/netfilter/ipvs/Kconfig, and hence triggering invalid
option warnings.

By dropping the trailing space on the regex, we'll cover all the cases
for valid option.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb 
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index c8e736a987..8ca7193c8c 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = 
"file://git/tools/kgit;beginline=5;endline=9;md5=9c30e971d435
 
 DEPENDS = "git-native"
 
-SRCREV = "7604d2d1a49d88e38d5b5854209dc1435b790893"
+SRCREV = "bb6df0ef2365689cd3df6f76a8838cddae0d9343"
 PR = "r12"
 PV = "0.2+git${SRCPV}"
 
-- 
2.19.1

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

[OE-core] ✗ patchtest: failure for cmake.bbclass: add HOSTTOOLS_DIR to CMAKE_FIND_ROOT_PATH

[Patchwork]

== Series Details ==

Series: cmake.bbclass: add HOSTTOOLS_DIR to CMAKE_FIND_ROOT_PATH
Revision: 1
URL   : https://patchwork.openembedded.org/series/19273/
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:



* Patchcmake.bbclass: add HOSTTOOLS_DIR to CMAKE_FIND_ROOT_PATH
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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 4/5] kernel-yocto: import security fragments from meta-security

[bruce . ashfield]

From: Bruce Ashfield 

Adding the following fragments from meta-security to make them
centrally available and easier to maintain:

   283939d5c9e kernel-cache: add yama security fragments
   0b86f3fa241 kernel-cache: add ima fragments
   731b466654d kernel-cache: add smack
   813afe8ff47 kernel-cache: add apparmor fragments

Signed-off-by: Armin Kuster 
Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb| 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb  | 2 +-
 meta/recipes-kernel/linux/linux-yocto_4.19.bb  | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.0.bb   | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
index 4013a0c2d0..52deb3fc86 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "ca2e3322f4c5678eaef6434c808d0842c805d74d"
-SRCREV_meta ?= "960be4218436fbbb3500e019f7abf02fa94e6aac"
+SRCREV_meta ?= "283939d5c9ebec9750c34982405a39a9864ac10f"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
index f66ee6f4ad..b214ee0a0a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "e6cb812b5532630b6fc6dfd7778d57a4907d3180"
-SRCREV_meta ?= "96c82f3d7ab25a3f44e517f9dbbb53e2c4c45729"
+SRCREV_meta ?= "7f6e97c357746382d4339e7e0463637e715acd4b"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.0;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
index 4759d80438..be25d075de 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine_qemuarm ?= "b5a2efa31290f31384971494031285d394635938"
 SRCREV_machine ?= "4ec6f255163da37a4c83528e5835b6b9baccee63"
-SRCREV_meta ?= "960be4218436fbbb3500e019f7abf02fa94e6aac"
+SRCREV_meta ?= "283939d5c9ebec9750c34982405a39a9864ac10f"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
index 42e0dcd603..33672c6d49 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine_qemuarm ?= "b9001287984b0066814c8739f38d629de73739b7"
 SRCREV_machine ?= "55dd15336b7301b686a0c183f5372b49c1003d03"
-SRCREV_meta ?= "96c82f3d7ab25a3f44e517f9dbbb53e2c4c45729"
+SRCREV_meta ?= "7f6e97c357746382d4339e7e0463637e715acd4b"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
index cee8af7c99..7704bd3e55 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= 
"4ec6f255163da37a4c83528e5835b6b9baccee63"
 SRCREV_machine_qemux86-64 ?= "4ec6f255163da37a4c83528e5835b6b9baccee63"
 SRCREV_machine_qemumips64 ?= "ca47368b698795cd5cada84dbfcceda1f47da1aa"
 SRCREV_machine ?= "4ec6f255163da37a4c83528e5835b6b9baccee63"
-SRCREV_meta ?= "960be4218436fbbb3500e019f7abf02fa94e6aac"
+SRCREV_meta ?= "283939d5c9ebec9750c34982405a39a9864ac10f"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}
 \
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.0.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
index ea4b6f5b33..898f824d48 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
@@ -21,7 +21,7 @@ SRCREV_machine_qemux86 ?= 
"55dd15336b7301b686a0c183f5372b49c1003d03"
 SRCREV_machine_qemux86-64 ?= "55dd15336b7301b686a0c183f5372b49c1003d03"
 SRCREV_machine_qemumips64 ?= "9d4105b32cf123a861bc754377d2f2e156278a7e"
 SRCREV_machine ?= "55dd15336b7301b686a0c183f5372b49c1003d03"
-SRCREV_meta ?= "96c82f3d7ab25a3f44e517f9dbbb53e2c4c45729"
+SRCREV_meta ?= "7f6e97c357746382d4339e7e0463637e715acd4b"
 
 # remap qemuarm to qemuarma15 for the 5.0 kernel
 # KMACHINE_qemuarm ?= "qemuarma15"
-- 

[OE-core] [PATCH 1/5] kernel-devsrc: tweak for v5.3+

[bruce . ashfield]

From: Bruce Ashfield 

The 5.3 kernel has two changes that require tweaks to the minimal
kernel-devsrc package.

- 4ce97317f [x86/purgatory: Do not use __builtin_memcpy and __builtin_memset]

  This change removes the need for arch/x86/purgatory/string.c and
  instead reuses a copy in arch/x86/boot/compressed/, so we can't copy
  the file anymore. To support older kernels, we make the copy survive
  the non-existence of the file.

- b1663d7e [docs: Kbuild/Makefile: allow check for missing docs at build time]

  This change adds the sourceing of Documentation/Kbuild to the top
  level Kbuild file. So we now leave the copy of Documention/'s Kbuild
  in the devsrc.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 5ec5929735..3900489ac5 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -65,7 +65,6 @@ do_install() {
 )
 
 # then drop all but the needed Makefiles/Kconfig files
-rm -rf $kerneldir/build/Documentation
 rm -rf $kerneldir/build/scripts
 rm -rf $kerneldir/build/include
 
@@ -205,11 +204,12 @@ do_install() {
cp -a --parents arch/x86/purgatory/sha256.c $kerneldir/build/ 
2>/dev/null || :
 
cp -a --parents arch/x86/purgatory/stack.S $kerneldir/build/
-   cp -a --parents arch/x86/purgatory/string.c $kerneldir/build/
+   cp -a --parents arch/x86/purgatory/string.c $kerneldir/build/ 
2>/dev/null || :
cp -a --parents arch/x86/purgatory/setup-x86_64.S $kerneldir/build/
cp -a --parents arch/x86/purgatory/entry64.S $kerneldir/build/
cp -a --parents arch/x86/boot/string.h $kerneldir/build/
cp -a --parents arch/x86/boot/string.c $kerneldir/build/
+   cp -a --parents arch/x86/boot/compressed/string.c $kerneldir/build/ 
2>/dev/null || :
cp -a --parents arch/x86/boot/ctype.h $kerneldir/build/
fi
 
-- 
2.19.1

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

Re: [OE-core] [PATCH] kernel-devsrc: cp Documentation/ to sdk kernel

[Bruce Ashfield]

On Wed, Aug 14, 2019 at 5:48 AM Hongzhi, Song
 wrote:
>
>
> On 8/14/19 11:48 AM, Bruce Ashfield wrote:
> > On Tue, Aug 13, 2019 at 11:39 PM Bruce Ashfield
> >   wrote:
> >> On Tue, Aug 13, 2019 at 11:04 PM Bruce Ashfield
> >>   wrote:
> >>>
> >>> On Tue, Aug 13, 2019 at 11:01 PM Hongzhi, 
> >>> Song  wrote:
>  On 8/14/19 10:53 AM, Bruce Ashfield wrote:
> > On Tue, Aug 13, 2019 at 9:59 PM Hongzhi, Song
> > mailto:hongzhi.s...@windriver.com>> wrote:
> >
> >
> >  On 8/13/19 8:27 PM, Bruce Ashfield wrote:
> >  >
> >  >
> >  > On Tue, Aug 13, 2019 at 1:35 AM Hongzhi.Song
> >  > mailto:hongzhi.s...@windriver.com>
> >   >  >> wrote:
> >  >
> >  > A new patch let kernel source Documentation/Kconfig in top
> >  Kconfig
> >  > So kernel-devsrc should include Documentation/ too.
> >  > Otherwise "make scripts" will fails.
> >  >
> >  > patch:
> >  > commit b1663d7e3a7961fc45262fd68a89253f2803036c
> >  > Author: Mauro Carvalho Chehab  >  
> >  >  >  >>
> >  > Date:   Tue Jun 4 09:26:27 2019 -0300
> >  >
> >  > docs: Kbuild/Makefile: allow check for missing docs at
> >  build time
> >  >
> >  > While this doesn't make sense for production Kernels, in
> >  order to
> >  > avoid regressions when documents are touched, let's add a
> >  > check target at the make file.
> >  >
> >  > Signed-off-by: Mauro Carvalho Chehab
> >  >  >  
> >   >  >>
> >  > Signed-off-by: Jonathan Corbet  >  
> >  > >>
> >  >
> >  > Signed-off-by: Hongzhi.Song  >  
> >  >  >  >>
> >  > ---
> >  >  meta/recipes-kernel/linux/kernel-devsrc.bb
> >  
> >  >  | 2 +-
> >  >  1 file changed, 1 insertion(+), 1 deletion(-)
> >  >
> >  > diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> >  
> >  >
> >  > b/meta/recipes-kernel/linux/kernel-devsrc.bb
> >    
> >  > index 5ec5929..a874e06 100644
> >  > --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> >  
> >  >
> >  > +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> >  
> >  >
> >  > @@ -65,7 +65,7 @@ do_install() {
> >  >  )
> >  >
> >  >  # then drop all but the needed Makefiles/Kconfig files
> >  > -rm -rf $kerneldir/build/Documentation
> >  > +#rm -rf $kerneldir/build/Documentation
> >  >
> >  >
> >  > In the spirit of keeping kernel-devsrc as small as possible (I 
> > have
> >  > another patch pending if you really want the full kernel
> >  source), this
> >  > should only keep the Documentation/ files that are required to 
> > pass
> >  > the check, not keep all of Documentation.
> >
> >
> >  If you have a better patch, I am pleasure to accept it.
> >
> >
> > ???
> >
> > This is where you'd typically do a v2 of the patch after getting a
> > review of a change.
> >
> > But if you are refusing the feedback, then yes, I'll do a version of
> > the patch myself rather than just blindly copying in all of the
> > documentation. I'll submit it myself.
> >
> > RP/Ross, whoever is taking in patches, drop this version, and I'll do
> > my own.
>  I am not very familiar with the kernel-devsrc.bb. I have no objection
>  for your decision.
> >>> At a minimum, we shouldn't leave the commented out #rm -rf 
> >>> $kerneldir/build/Documentation, so I can do that and tweak the commit 
> >>> message a bit as well.
> >>>
> >>> Leave it with me, and I'll send it to the list (hopefully tomorrow) to be 
> >>> sure it still solves your problem.
> >> Aha. Now I see what is actually happening. On reading the patch, I
> >> thought you were requiring the existence of the 

[OE-core] [PATCH] gcc-cross-canadian: Drop obsolete shlibs exclusion

[Richard Purdie]

This is a very old change as and be inferred from the name in the comment.
We've since had many changes to pkgdata including separating it
to its own sysroot now so the reasons for this blanket exclusion are
likely long gone.

If the shlib provides were really the problem I'd much rather have
a dedicated variable for that too.

Removing this fixes missing dependencies on nativesdk-libc and other
libs which would then happen automatically.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gcc/gcc-cross-canadian.inc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc 
b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
index 807e47e0ee2..f14cbf71522 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-canadian.inc
@@ -63,9 +63,6 @@ do_compile () {
(cd ${B}/${TARGET_SYS}/libgcc; oe_runmake enable-execute-stack.c 
unwind.h md-unwind-support.h sfp-machine.h gthr-default.h)
 }
 
-# Having anything auto depending on gcc-cross-sdk is a really bad idea...
-EXCLUDE_FROM_SHLIBS = "1"
-
 PACKAGES = "${PN}-dbg ${PN} ${PN}-doc"
 
 FILES_${PN} = "\
-- 
2.20.1

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

Re: [OE-core] [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M

[Richard Purdie]

On Wed, 2019-08-14 at 17:26 +0200, Alexander Kanavin wrote:
> This was already the case for various specific qemu machines,
> and 256M was found to be no longer sufficient for x86 either when
> switching X from vmware to standard vga+bochs vesa driver as provided
> by qemu (Xorg would then attempt to clone() itself with ENOMEM
> returned).
> 
> Let's just accept this new reality :)

I'm not sure I agree with this.

We are meant to work on embedded systems and 256MB should be enough to
let us bring up X under qemu.

I'm fine with some sdk/ptest images having more memory, that makes
sense but 256MB not allowing X under qemu seems rather poor.

Are we really saying the minimal image size we can emulate is 256MB
ram?

Cheers,

Richard

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