[OE-core] [PATCH] python/python3: add virtual/crypt to DEPENDS

2018-08-20 Thread Hongxu Jia
Since  `6146b8c glibc: Disable crypt support in glibc' in oe-core,
python2/3 could not find symbol crypt which caused import crypt failed.
[snip]
>>> import crypt
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.5/crypt.py", line 3, in 
import _crypt
ImportError: 
/usr/lib64/python3.5/lib-dynload/_crypt.cpython-35m-x86_64-linux-gnu.so: 
undefined symbol: crypt
[snip]

Add virtual/crypt to DEPENDS, and python's build system (setup.py)
will search libcrypt.so in recipe-sysroot and add `-lcrypt' if it
exists.

Signed-off-by: Hongxu Jia 
---
 meta/recipes-devtools/python/python3_3.5.5.bb | 4 +++-
 meta/recipes-devtools/python/python_2.7.15.bb | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/python/python3_3.5.5.bb 
b/meta/recipes-devtools/python/python3_3.5.5.bb
index beaf3dc..bfe91fb 100644
--- a/meta/recipes-devtools/python/python3_3.5.5.bb
+++ b/meta/recipes-devtools/python/python3_3.5.5.bb
@@ -1,6 +1,8 @@
 require recipes-devtools/python/python.inc
 
-DEPENDS = "python3-native libffi bzip2 gdbm openssl sqlite3 zlib 
virtual/libintl xz qemu-native qemu-helper-native"
+DEPENDS = "python3-native libffi bzip2 gdbm openssl \
+   sqlite3 zlib virtual/libintl xz qemu-native \
+   qemu-helper-native virtual/crypt"
 
 PR = "${INC_PR}.0"
 PYTHON_MAJMIN = "3.5"
diff --git a/meta/recipes-devtools/python/python_2.7.15.bb 
b/meta/recipes-devtools/python/python_2.7.15.bb
index 3044c3d..43d9ff5 100644
--- a/meta/recipes-devtools/python/python_2.7.15.bb
+++ b/meta/recipes-devtools/python/python_2.7.15.bb
@@ -1,6 +1,7 @@
 require python.inc
 
-DEPENDS = "python-native libffi bzip2 gdbm openssl readline sqlite3 zlib"
+DEPENDS = "python-native libffi bzip2 gdbm openssl \
+   readline sqlite3 zlib virtual/crypt"
 
 PR = "${INC_PR}"
 
-- 
2.7.4

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


Re: [OE-core] [PATCH] nativesdk-packagegroup-sdk-host: Add wayland-scanner to

2018-08-20 Thread Seokha Ko



currently nativesdk-wayland-dev package bin directory which includes wayland-scanner only.
And, IMHO, if there are other tools for dev package, we need them for nativesdk target also.
Thank you.
- Original Message -


From: Khem Raj 
To:  

Cc: Patches and discussions about the oe-core layer 

Sent: 18.08.21 09:50 GMT +0900
Subject: Re: [OE-core] [PATCH] nativesdk-packagegroup-sdk-host: Add
 wayland-scanner to




On Mon, Aug 20, 2018 at 4:26 PM Seokha Ko  wrote:>> The wayland-scanner was missing from the native toolchain for SDK build> because it's copied from wayland dev package.>> Signed-off-by: Seokha Ko > --->  .../packagegroups/nativesdk-packagegroup-sdk-host.bb| 2 +->  1 file changed, 1 insertion(+), 1 deletion(-)>> diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb> index e2f6169994..4dc6eea23e 100644> --- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb> +++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb> @@ -23,7 +23,7 @@ RDEPENDS_${PN} = "\>  nativesdk-makedevs \>  nativesdk-dnf \>  nativesdk-cmake \> -${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', '', d)} \> +${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland-dev', '', d)} \Do we need the whole dev package ? if not I would suggest to packageit into a separate output packageand include that along with nativesdk-wayland>  nativesdk-sdk-provides-dummy \>  ">> --> 2.17.1>> --> ___> Openembedded-core mailing list> Openembedded-core@lists.openembedded.org> http://lists.openembedded.org/mailman/listinfo/openembedded-core





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


Re: [OE-core] [PATCH V2] nasm: fix CVE-2018-8883 & CVE-2018-8882 & CVE-2018-10016 & CVE-2018-10316

2018-08-20 Thread ChenQi

Caused ovmf do_compile failure.
https://autobuilder.yocto.io/builders/nightly-musl/builds/1254/steps/BuildImages/logs/stdio 



Best Regards,
Chen Qi

On 08/20/2018 09:23 AM, Hongxu Jia wrote:

Signed-off-by: Hongxu Jia 
---
  ...t-we-are-not-reading-past-end-of-a-buffer.patch | 65 ++
  ...001-asm-eval.c-Avoid-possible-divide-by-0.patch | 40 +
  .../0001-assemble-Check-global-line-limit.patch| 50 +
  .../nasm/nasm/0001-fix-CVE-2018-8882.patch | 30 ++
  meta/recipes-devtools/nasm/nasm_2.13.03.bb |  4 ++
  5 files changed, 189 insertions(+)
  create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
  create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
  create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-assemble-Check-global-line-limit.patch
  create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-fix-CVE-2018-8882.patch

diff --git 
a/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
 
b/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
new file mode 100644
index 000..a56a08b
--- /dev/null
+++ 
b/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
@@ -0,0 +1,65 @@
+From c5785fdf1d660eaefb9711284414262d0cfe8843 Mon Sep 17 00:00:00 2001
+From: Adam Majer 
+Date: Fri, 17 Aug 2018 14:48:17 +0800
+Subject: [PATCH] Verify that we are not reading past end of a buffer
+
+Simple reproducer is just,
+
+ret :ep
+
+which triggers a buffer overread due to parsing of an invalid
+segment override.
+
+Signed-off-by: Adam Majer 
+
+Upstream-Status: Submitted [https://bugzilla.nasm.us/show_bug.cgi?id=3392447]
+CVE: CVE-2018-8883
+Signed-off-by: Hongxu Jia 
+---
+ include/opflags.h | 2 +-
+ include/tables.h  | 1 +
+ x86/regs.pl   | 3 ++-
+ 3 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/include/opflags.h b/include/opflags.h
+index ef2838c1..8d4b6b1e 100644
+--- a/include/opflags.h
 b/include/opflags.h
+@@ -166,7 +166,7 @@
+ #define REG_CLASS_BND   GEN_REG_CLASS(9)
+
+ #define is_class(class, op) (!((opflags_t)(class) & ~(opflags_t)(op)))
+-#define is_reg_class(class, reg)is_class((class), nasm_reg_flags[(reg)])
++#define is_reg_class(class, reg)is_class((class), ((reg) < 
nasm_reg_flags_size ? nasm_reg_flags[(reg)] : 0))
+
+ #define IS_SREG(reg)is_reg_class(REG_SREG, (reg))
+ #define IS_FSGS(reg)is_reg_class(REG_FSGS, (reg))
+diff --git a/include/tables.h b/include/tables.h
+index 24a665e2..458752ce 100644
+--- a/include/tables.h
 b/include/tables.h
+@@ -64,6 +64,7 @@ extern const char * const nasm_reg_names[];
+ typedef uint64_t opflags_t;
+ typedef uint16_t  decoflags_t;
+ extern const opflags_t nasm_reg_flags[];
++extern const size_t nasm_reg_flags_size;
+ /* regvals.c */
+ extern const int nasm_regvals[];
+
+diff --git a/x86/regs.pl b/x86/regs.pl
+index 3a1b56f5..cb5cea68 100755
+--- a/x86/regs.pl
 b/x86/regs.pl
+@@ -158,7 +158,8 @@ if ( $fmt eq 'h' ) {
+   printf "%-15s /* %-5s */\n",
+   $regs{$reg}.',', $reg;
+ }
+-print "};\n";
++print "};\n\n";
++print "const size_t nasm_reg_flags_size = sizeof(nasm_reg_flags) / 
sizeof(opflags_t);\n";
+ } elsif ( $fmt eq 'vc' ) {
+ # Output regvals.c
+ print "/* automatically generated from $file - do not edit */\n\n";
+--
+2.17.1
+
diff --git 
a/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
 
b/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
new file mode 100644
index 000..6ceeca0
--- /dev/null
+++ 
b/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
@@ -0,0 +1,40 @@
+From 8ad049cf9ccda2a5133a97506011862bcfc4a0c0 Mon Sep 17 00:00:00 2001
+From: Adam Majer 
+Date: Fri, 17 Aug 2018 14:15:35 +0800
+Subject: [PATCH] asm/eval.c: Avoid possible divide by 0
+
+During a divide operation, we already tested that the
+divisor has is_simple, but then when testing it for 0,
+we again verify that it does not contain any unknown parts.
+This extra check prevents detection of cases when
+reloc_value returns 0.
+
+Use reloc_value instead in detection of 0 divisor.
+
+https://bugzilla.nasm.us/show_bug.cgi?id=3392473
+
+Signed-off-by: Adam Majer 
+
+Upstream-Status: Submitted [https://bugzilla.nasm.us/show_bug.cgi?id=3392473]
+CVE: CVE-2018-10016
+Signed-off-by: Hongxu Jia 
+---
+ asm/eval.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/asm/eval.c b/asm/eval.c
+index 816983b9..57c598c5 100644
+--- a/asm/eval.c
 b/asm/eval.c
+@@ -585,7 +585,7 @@ static expr *expr5(int critical)
+   " scalar values");
+ return NULL;
+ }
+-if (j != '*' && !is_unknown(f) && reloc_value(f) 

[OE-core] : feedback on externalsrc patch

2018-08-20 Thread Vignesh Rajendran (RBEI/ECF3)
Hello Khem, Paul,

I am waiting for any feedback for the patch changes.
https://patchwork.openembedded.org/patch/150819/


The approach suggested to use "DEBUG_PREFIX_MAP relative to S instead of 
WORKDIR" seems not possible due to the package.bbclass approach.
https://github.com/openembedded/openembedded-core/blob/f9324af88a99eca28b160fa31aa4516fd397e44b/meta/classes/package.bbclass#L449

the sources are explicitly copied from workparentdir path
cmd = processdebugsrc % (sourcefile, workbasedir, localsrc_prefix, 
workparentdir, dvar, debugsrcdir)

Can you please clarify if my view is correct or Do I am missing something?

Thanks in Advance.

Mit freundlichen Grüßen / Best regards

Rajendran Vignesh
RBEI/ECF33

Tel. +91 422 67-65103

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


Re: [OE-core] [PATCH] nativesdk-packagegroup-sdk-host: Add wayland-scanner to the SDK native toolchain

2018-08-20 Thread Seokha Ko



currently nativesdk-wayland-dev package bin directory which includes wayland-scanner only.
And, IMHO, if there are other tools for dev package, we need them for nativesdk target also.
Thank you.
- Original  Message -


From: Khem Raj 
To:  

CC: Patches and discussions about the oe-core layer 

Sent: 18.08.21 09:50 GMT +0900
Subject: Re: [OE-core] [PATCH] nativesdk-packagegroup-sdk-host: Add wayland-scanner to the SDK native toolchain




On Mon, Aug 20, 2018 at 4:26 PM Seokha Ko  wrote:>> The wayland-scanner was missing from the native toolchain for SDK build> because it's copied from wayland dev package.>> Signed-off-by: Seokha Ko > --->  .../packagegroups/nativesdk-packagegroup-sdk-host.bb| 2 +->  1 file changed, 1 insertion(+), 1 deletion(-)>> diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb> index e2f6169994..4dc6eea23e 100644> --- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb> +++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb> @@ -23,7 +23,7 @@ RDEPENDS_${PN} = "\>  nativesdk-makedevs \>  nativesdk-dnf \>  nativesdk-cmake \> -${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', '', d)} \> +${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland-dev', '', d)} \Do we need the whole dev package ? if not I would suggest to packageit into a separate output packageand include that along with nativesdk-wayland>  nativesdk-sdk-provides-dummy \>  ">> --> 2.17.1>> --> ___> Openembedded-core mailing list> Openembedded-core@lists.openembedded.org> http://lists.openembedded.org/mailman/listinfo/openembedded-core





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


Re: [OE-core] [PATCH 1/1] assimp.py: fix AttributeError in tearDownClass

2018-08-20 Thread ChenQi

On 08/21/2018 12:53 AM, Richard Purdie wrote:

On Fri, 2018-08-17 at 17:17 +0800, Chen Qi wrote:

When running this test case, we will see the following error.

   AttributeError: type object 'BuildAssimp' has no attribute
'project'

assimp.py test case does not make use of SDKBuildProject, so remove
the import statement and the tearDownClass.

Signed-off-by: Chen Qi 
---
  meta/lib/oeqa/sdk/cases/assimp.py | 5 -
  1 file changed, 5 deletions(-)

I'm not seeing this error when I run the test and I can't see it on the
autobuilders. Why are you seeing this and we're not?

I'm trying to understand some other odd behaviour in SDK tests and am
wondering if this is related or not.

(e.g. https://autobuilder.yocto.io/builders/nightly-mips/builds/1221/st
eps/Running%20SDK%20Sanity%20Tests/logs/stdio)

Cheers,

Richard

I did a quick search and found this one: 
https://github.com/pexpect/pexpect/pull/31

"""
|sys.stdout.buffer| is not guaranteed to exist - e.g. if |sys.stdout| 
has been reassigned to an |io.StringIO| instance, it won't.

"""

And we have in ConcurrencyTestSuite:
process_result._stdout_buffer = io.StringIO()

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


[OE-core] [PATCH V4] sstate: Avoid indirect autoconf-archive-native dependencies

2018-08-20 Thread changqing.li
From: Changqing Li 

remove the indirect dependcy of autoconf-archive-native via
SSTATE_EXCLUDEDEPS_SYSROOT to avoid not needed .m4 installed
into sysroot, which may cause compile problem.

Signed-off-by: Changqing Li 
---
 meta/conf/layer.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index cc77d07..2cbe952 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -90,6 +90,9 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
 .*->.*-initial.* \
 .*(base-passwd|shadow-sysroot)->.* \
 "
+# Avoid adding autoconf-archive-native to sysroot without a specific
+# dependency in the recipe.
+SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
 
 # We need to keep bitbake tools in PATH
 PATH := 
"${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR}"
-- 
2.7.4

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


Re: [OE-core] [PATCH] nativesdk-packagegroup-sdk-host: Add wayland-scanner to the SDK native toolchain

2018-08-20 Thread Khem Raj
On Mon, Aug 20, 2018 at 4:26 PM Seokha Ko  wrote:
>
> The wayland-scanner was missing from the native toolchain for SDK build
> because it's copied from wayland dev package.
>
> Signed-off-by: Seokha Ko 
> ---
>  .../packagegroups/nativesdk-packagegroup-sdk-host.bb| 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
> b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> index e2f6169994..4dc6eea23e 100644
> --- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> +++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
> @@ -23,7 +23,7 @@ RDEPENDS_${PN} = "\
>  nativesdk-makedevs \
>  nativesdk-dnf \
>  nativesdk-cmake \
> -${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', 
> '', d)} \
> +${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 
> 'nativesdk-wayland-dev', '', d)} \

Do we need the whole dev package ? if not I would suggest to package
it into a separate output package
and include that along with nativesdk-wayland

>  nativesdk-sdk-provides-dummy \
>  "
>
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] openssl: fix hardcoded paths in native for openssl 1.1

2018-08-20 Thread Andre McCurdy
Relying on hardcoded built-in paths causes openssl-native to not be
relocateable from sstate.

Solution for openssl 1.1, based on the existing solution from
openssl 1.0:

  
http://git.openembedded.org/openembedded-core/commit/?id=771d3123331fbfab1eb9ce47e3013eabcb2248f5

Signed-off-by: Andre McCurdy 
---
 ...SLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch | 39 ++
 .../recipes-connectivity/openssl/openssl_1.1.0i.bb | 10 ++
 2 files changed, 49 insertions(+)
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch

diff --git 
a/meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch
 
b/meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch
new file mode 100644
index 000..67d06fc
--- /dev/null
+++ 
b/meta/recipes-connectivity/openssl/openssl/0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch
@@ -0,0 +1,39 @@
+From 26e98beb8a987cdc69699aaffc5599926fb1b293 Mon Sep 17 00:00:00 2001
+From: Andre McCurdy 
+Date: Fri, 17 Aug 2018 20:33:44 -0700
+Subject: [PATCH] allow OPENSSLDIR and ENGINESDIR CFLAGS to be controlled
+
+Upstream-Status: Inappropriate [OE Specific]
+
+Signed-off-by: Andre McCurdy 
+---
+ Configurations/unix-Makefile.tmpl | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/Configurations/unix-Makefile.tmpl 
b/Configurations/unix-Makefile.tmpl
+index 034d93e..2310d12 100644
+--- a/Configurations/unix-Makefile.tmpl
 b/Configurations/unix-Makefile.tmpl
+@@ -156,6 +156,10 @@ LIBDIR={- #
+ ENGINESDIR={- use File::Spec::Functions;
+   catdir($prefix,$libdir,"engines-$sover") -}
+ 
++# Intermediate variables so the values defined via CFLAGS can be controlled.
++OE_DOPENSSLDIR=$(OPENSSLDIR)
++OE_DENGINESDIR=$(ENGINESDIR)
++
+ # Convenience variable for those who want to set the rpath in shared
+ # libraries and applications
+ LIBRPATH=$(INSTALLTOP)/$(LIBDIR)
+@@ -174,7 +178,7 @@ HTMLSUFFIX=html
+ 
+ CROSS_COMPILE= {- $config{cross_compile_prefix} -}
+ CC= $(CROSS_COMPILE){- $target{cc} -}
+-CFLAGS={- our $cflags2 = join(" ",(map { "-D".$_} @{$target{defines}}, 
@{$config{defines}}),"-DOPENSSLDIR=\"\\\"\$(OPENSSLDIR)\\\"\"","-DENGINESDIR=\"\\\"\$(ENGINESDIR)\\\"\"")
 -} {- $target{cflags} -} {- $config{cflags} -}
++CFLAGS={- our $cflags2 = join(" ",(map { "-D".$_} @{$target{defines}}, 
@{$config{defines}}),"-DOPENSSLDIR=\"\\\"\$(OE_DOPENSSLDIR)\\\"\"","-DENGINESDIR=\"\\\"\$(OE_DENGINESDIR)\\\"\"")
 -} {- $target{cflags} -} {- $config{cflags} -}
+ CFLAGS_Q={- $cflags2 =~ s|([\\"])|\\$1|g; $cflags2 -} {- $config{cflags} -}
+ LDFLAGS= {- $target{lflags}." ".$ENV{'LDFLAGS'} -}
+ PLIB_LDFLAGS= {- $target{plib_lflags} -}
+-- 
+1.9.1
+
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb
index 507f8f8..d2f2624 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb
@@ -14,6 +14,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz 
\
file://run-ptest \
file://openssl-c_rehash.sh \
file://0001-Take-linking-flags-from-LDFLAGS-env-var.patch \
+   
file://0001-allow-OPENSSLDIR-and-ENGINESDIR-CFLAGS-to-be-control.patch \
"
 
 SRC_URI_append_class-nativesdk = " \
@@ -30,6 +31,9 @@ inherit lib_package multilib_header ptest relative_symlinks
 #| ./libcrypto.so: undefined reference to `makecontext'
 EXTRA_OECONF_append_libc-musl = " -DOPENSSL_NO_ASYNC"
 
+EXTRA_OEMAKE_append_class-native = " OE_DOPENSSLDIR='/not/builtin' 
OE_DENGINESDIR='/not/builtin'"
+EXTRA_OEMAKE_append_class-nativesdk = " OE_DOPENSSLDIR='/not/builtin' 
OE_DENGINESDIR='/not/builtin'"
+
 do_configure () {
os=${HOST_OS}
case $os in
@@ -116,6 +120,12 @@ do_install () {
 }
 
 do_install_append_class-native () {
+   create_wrapper ${D}${bindir}/openssl \
+   OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
+   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
+   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
+   OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
+
# Install a custom version of c_rehash that can handle sysroots 
properly.
# This version is used for example when installing ca-certificates 
during
# image creation.
-- 
1.9.1

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


[OE-core] [PATCH] nativesdk-packagegroup-sdk-host: Add wayland-scanner to the SDK native toolchain

2018-08-20 Thread Seokha Ko
The wayland-scanner was missing from the native toolchain for SDK build
because it's copied from wayland dev package.

Signed-off-by: Seokha Ko 
---
 .../packagegroups/nativesdk-packagegroup-sdk-host.bb| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index e2f6169994..4dc6eea23e 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -23,7 +23,7 @@ RDEPENDS_${PN} = "\
 nativesdk-makedevs \
 nativesdk-dnf \
 nativesdk-cmake \
-${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', 
'', d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 
'nativesdk-wayland-dev', '', d)} \
 nativesdk-sdk-provides-dummy \
 "
 
-- 
2.17.1

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


Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt

2018-08-20 Thread Andre McCurdy
On Mon, Aug 20, 2018 at 2:03 PM, Peter Kjellerstedt
 wrote:
>> -Original Message-
>> From: Andre McCurdy 
>> Sent: den 20 augusti 2018 22:23
>> To: Khem Raj 
>> Cc: Richard Purdie ; Peter
>> Kjellerstedt ; Patches and discussions
>> about the oe-core layer 
>> Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on
>> virtual/crypt
>>
>> On Mon, Aug 20, 2018 at 12:45 PM, Khem Raj  wrote:
>> > On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie
>> >  wrote:
>> >>
>> >> On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote:
>> >> > busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
>> >> >
>> >> > Signed-off-by: Peter Kjellerstedt 
>> >> > ---
>> >> >  meta/recipes-core/busybox/busybox.inc | 3 ++-
>> >> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
>> >> > core/busybox/busybox.inc
>> >> > index 8c6dbbaf9b..a8ba10d21c 100644
>> >> > --- a/meta/recipes-core/busybox/busybox.inc
>> >> > +++ b/meta/recipes-core/busybox/busybox.inc
>> >> > @@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
>> many
>> >> > common UNIX utilities into
>> >> >  HOMEPAGE = "http://www.busybox.net;
>> >> >  BUGTRACKER = "https://bugs.busybox.net/;
>> >> >
>> >> > -DEPENDS += "kern-tools-native"
>> >> > +# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
>> defined
>> >> > +DEPENDS += "kern-tools-native virtual/crypt"
>> >>
>> >> I'm not a bug fan of adding dependencies which might not be needed.
>> How
>> >> common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't
>> >> our default config?
>> >
>> > yes perhaps it should be packageconfig
>>
>> Busybox doesn't use PACKAGECONFIG. Conditional configuration is
>> handled by adding / removing cfg fragments and testing whether SRC_URI
>> contains "foo.cfg" (and also parsing the final .config within tasks
>> such as do_install). Unfortunately that approach doesn't work so well
>> for conditional build dependencies...
>>
>> Our Busybox defconfig does enable CONFIG_USE_BB_CRYPT (and there's no
>> cfg fragment to disable it) so the virtual/crypt dependency isn't
>> needed in our default builds.
>
> In our case we have our own defconfig. I am not responsible for it, it is
> maintained by our busybox maintainer, and he has apparently decided that
> we don't want CONFIG_USE_BB_CRYPT enabled.

Could you ask him about it? Maybe there's some advantage to it that isn't clear.

The general OE approach is to use system libraries when possible so
using external libcrypt does actually align to that.

Maybe we should use external libcrypt by default (with the option to
switch back to the built-in crypt functions via a cfg fragment)?

> I can of course add the dependency via a bbappend, but having to do that
> seems wrong given how the rest of busybox is configured (with defconfig
> and cfg fragments) and where enabling some options that don't happen to
> be enabled in the OE-Core default configuration will then break the build.
>
>> Disabling busybox's internal crypt functions doesn't seem like a very
>> common thing to want to do.
>>
>> config USE_BB_CRYPT
>> bool "Use internal crypt functions"
>> default y
>> help
>>   Busybox has internal DES and MD5 crypt functions.
>>   They produce results which are identical to corresponding
>>   standard C library functions.
>>
>>   If you leave this disabled, busybox will use the system's
>>   crypt functions. Most C libraries use large (~70k)
>>   static buffers there, and also combine them with more general
>>   DES encryption/decryption.
>>
>>   For busybox, having large static buffers is undesirable,
>>   especially on NOMMU machines. Busybox also doesn't need
>>   DES encryption/decryption and can do with smaller code.
>>
>>   If you enable this option, it will add about 4.8k of code
>>   if you are building dynamically linked executable.
>>   In static build, it makes code _smaller_ by about 1.2k,
>>   and likely many kilobytes less of bss.
>
> //Peter
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt

2018-08-20 Thread Peter Kjellerstedt
> -Original Message-
> From: Andre McCurdy 
> Sent: den 20 augusti 2018 22:23
> To: Khem Raj 
> Cc: Richard Purdie ; Peter
> Kjellerstedt ; Patches and discussions
> about the oe-core layer 
> Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on
> virtual/crypt
> 
> On Mon, Aug 20, 2018 at 12:45 PM, Khem Raj  wrote:
> > On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie
> >  wrote:
> >>
> >> On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote:
> >> > busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
> >> >
> >> > Signed-off-by: Peter Kjellerstedt 
> >> > ---
> >> >  meta/recipes-core/busybox/busybox.inc | 3 ++-
> >> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
> >> > core/busybox/busybox.inc
> >> > index 8c6dbbaf9b..a8ba10d21c 100644
> >> > --- a/meta/recipes-core/busybox/busybox.inc
> >> > +++ b/meta/recipes-core/busybox/busybox.inc
> >> > @@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
> many
> >> > common UNIX utilities into
> >> >  HOMEPAGE = "http://www.busybox.net;
> >> >  BUGTRACKER = "https://bugs.busybox.net/;
> >> >
> >> > -DEPENDS += "kern-tools-native"
> >> > +# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
> defined
> >> > +DEPENDS += "kern-tools-native virtual/crypt"
> >>
> >> I'm not a bug fan of adding dependencies which might not be needed.
> How
> >> common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't
> >> our default config?
> >
> > yes perhaps it should be packageconfig
> 
> Busybox doesn't use PACKAGECONFIG. Conditional configuration is
> handled by adding / removing cfg fragments and testing whether SRC_URI
> contains "foo.cfg" (and also parsing the final .config within tasks
> such as do_install). Unfortunately that approach doesn't work so well
> for conditional build dependencies...
> 
> Our Busybox defconfig does enable CONFIG_USE_BB_CRYPT (and there's no
> cfg fragment to disable it) so the virtual/crypt dependency isn't
> needed in our default builds.

In our case we have our own defconfig. I am not responsible for it, it is 
maintained by our busybox maintainer, and he has apparently decided that 
we don't want CONFIG_USE_BB_CRYPT enabled. 

I can of course add the dependency via a bbappend, but having to do that 
seems wrong given how the rest of busybox is configured (with defconfig 
and cfg fragments) and where enabling some options that don't happen to 
be enabled in the OE-Core default configuration will then break the build.

> Disabling busybox's internal crypt functions doesn't seem like a very
> common thing to want to do.
> 
> config USE_BB_CRYPT
> bool "Use internal crypt functions"
> default y
> help
>   Busybox has internal DES and MD5 crypt functions.
>   They produce results which are identical to corresponding
>   standard C library functions.
> 
>   If you leave this disabled, busybox will use the system's
>   crypt functions. Most C libraries use large (~70k)
>   static buffers there, and also combine them with more general
>   DES encryption/decryption.
> 
>   For busybox, having large static buffers is undesirable,
>   especially on NOMMU machines. Busybox also doesn't need
>   DES encryption/decryption and can do with smaller code.
> 
>   If you enable this option, it will add about 4.8k of code
>   if you are building dynamically linked executable.
>   In static build, it makes code _smaller_ by about 1.2k,
>   and likely many kilobytes less of bss.

//Peter

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


Re: [OE-core] [PATCH 1/1] assimp.py: fix AttributeError in tearDownClass

2018-08-20 Thread Richard Purdie
On Mon, 2018-08-20 at 17:53 +0100, Richard Purdie wrote:
> On Fri, 2018-08-17 at 17:17 +0800, Chen Qi wrote:
> > When running this test case, we will see the following error.
> > 
> >   AttributeError: type object 'BuildAssimp' has no attribute
> > 'project'
> > 
> > assimp.py test case does not make use of SDKBuildProject, so remove
> > the import statement and the tearDownClass.
> > 
> > Signed-off-by: Chen Qi 
> > ---
> >  meta/lib/oeqa/sdk/cases/assimp.py | 5 -
> >  1 file changed, 5 deletions(-)
> 
> I'm not seeing this error when I run the test and I can't see it on
> the
> autobuilders. Why are you seeing this and we're not?
> 
> I'm trying to understand some other odd behaviour in SDK tests and am
> wondering if this is related or not.
> 
> (e.g. https://autobuilder.yocto.io/builders/nightly-mips/builds/1221/
> st
> eps/Running%20SDK%20Sanity%20Tests/logs/stdio)

To answer my own question, disabling parallelism makes this show up. So
we have a bug in the error handling code in the parallelism :(

Cheers,

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


Re: [OE-core] [V2][PATCH] gnutls: Update to 3.6.3

2018-08-20 Thread Andre McCurdy
On Fri, Aug 17, 2018 at 3:39 PM, akuster808  wrote:
> On 08/17/2018 02:31 PM, Andre McCurdy wrote:
>> On Fri, Aug 17, 2018 at 7:14 AM, Armin Kuster  wrote:
>>> [v2]
>>> Fix new config options form with to disable.
>>>
>>> [v1]
>>> release notes: 
>>> https://lists.gnupg.org/pipermail/gnutls-devel/2018-July/008584.html
>>>
>>> add ssl3 and tls1.3 config options now supported.
>>>
>>> Signed-off-by: Armin Kuster 
>>> ---
>>>  meta/recipes-support/gnutls/gnutls.inc   | 2 ++
>>>  .../gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb}  | 5 +++--
>>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>>  rename meta/recipes-support/gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} 
>>> (53%)
>>>
>>> diff --git a/meta/recipes-support/gnutls/gnutls.inc 
>>> b/meta/recipes-support/gnutls/gnutls.inc
>>> index 04c0fd2af8..f204e5f4c0 100644
>>> --- a/meta/recipes-support/gnutls/gnutls.inc
>>> +++ b/meta/recipes-support/gnutls/gnutls.inc
>>> @@ -30,6 +30,8 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn2"
>>>  PACKAGECONFIG[libtasn1] = 
>>> "--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
>>>  PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
>>>  PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
>>> +PACKAGECONFIG[ssl3] = "--enable-ssl3-support,--disable-ssl3-support,"
>>> +PACKAGECONFIG[tls13] = "--enable-tls13-support,--disable-tls13-support,"
>> I'm not sure whether either of these should have PACKAGECONFIG options.
>>
>> SSL v3 is obsolete and if gnutls is disabling it by default now then
>> it's probably best to leave it that way (dead and buried). Experienced
>> users can always enable via EXTRA_OECONF if they really need it.
>>
>> TLS 1.3 is the opposite - it's brand new. If we add a PACKAGECONFIG
>> option to control it then it becomes the gnutls recipe maintainer's
>> job to figure out when to enable it by default. I think it's better to
>> leave that decision to upstream gnutls.
> No change in behavior in the way its setup now.
>
> You can send a patch to correct them. I am not doing a v3 for this.

No, not a big issue either way.

I thought we might be getting a v3 anyway to move the [v1] and [v2]
comments below the "---" line but the v2 got merged as-is...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH V3] sstate: Avoid indirect autoconf-archive-native dependencies

2018-08-20 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of
> changqing...@windriver.com
> Sent: den 20 augusti 2018 04:31
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH V3] sstate: Avoid indirect autoconf-archive-
> native dependencies
> 
> From: Changqing Li 
> 
> remove the indirect dependcy of autoconf-archive-native via
> SSTATE_EXCLUDEDEPS_SYSROOT to avoid not needed .m4 installed
> into sysroot, which may cause compile problem.
> 
> Signed-off-by: Changqing Li 
> ---
>  meta/conf/layer.conf | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index cc77d07..63346ae 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -90,6 +90,8 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
>  .*->.*-initial.* \
>  .*(base-passwd|shadow-sysroot)->.* \
>  "
> -
> +# Avoid adding autoconf-archive-native to sysroot without a specific
> +# dependency in the recipe.
> +SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"

Please re-add the empty line here.

>  # We need to keep bitbake tools in PATH
>  PATH := 
> "${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR}"
> --
> 2.7.4

//Peter

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


Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt

2018-08-20 Thread Andre McCurdy
On Mon, Aug 20, 2018 at 12:45 PM, Khem Raj  wrote:
> On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie
>  wrote:
>>
>> On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote:
>> > busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
>> >
>> > Signed-off-by: Peter Kjellerstedt 
>> > ---
>> >  meta/recipes-core/busybox/busybox.inc | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
>> > core/busybox/busybox.inc
>> > index 8c6dbbaf9b..a8ba10d21c 100644
>> > --- a/meta/recipes-core/busybox/busybox.inc
>> > +++ b/meta/recipes-core/busybox/busybox.inc
>> > @@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of many
>> > common UNIX utilities into
>> >  HOMEPAGE = "http://www.busybox.net;
>> >  BUGTRACKER = "https://bugs.busybox.net/;
>> >
>> > -DEPENDS += "kern-tools-native"
>> > +# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not defined
>> > +DEPENDS += "kern-tools-native virtual/crypt"
>>
>> I'm not a bug fan of adding dependencies which might not be needed. How
>> common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't
>> our default config?
>
> yes perhaps it should be packageconfig

Busybox doesn't use PACKAGECONFIG. Conditional configuration is
handled by adding / removing cfg fragments and testing whether SRC_URI
contains "foo.cfg" (and also parsing the final .config within tasks
such as do_install). Unfortunately that approach doesn't work so well
for conditional build dependencies...

Our Busybox defconfig does enable CONFIG_USE_BB_CRYPT (and there's no
cfg fragment to disable it) so the virtual/crypt dependency isn't
needed in our default builds.

Disabling busybox's internal crypt functions doesn't seem like a very
common thing to want to do.

config USE_BB_CRYPT
bool "Use internal crypt functions"
default y
help
  Busybox has internal DES and MD5 crypt functions.
  They produce results which are identical to corresponding
  standard C library functions.

  If you leave this disabled, busybox will use the system's
  crypt functions. Most C libraries use large (~70k)
  static buffers there, and also combine them with more general
  DES encryption/decryption.

  For busybox, having large static buffers is undesirable,
  especially on NOMMU machines. Busybox also doesn't need
  DES encryption/decryption and can do with smaller code.

  If you enable this option, it will add about 4.8k of code
  if you are building dynamically linked executable.
  In static build, it makes code _smaller_ by about 1.2k,
  and likely many kilobytes less of bss.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] x86_64: ldd does not work (not a dynamic executable)

2018-08-20 Thread richard . purdie
On Mon, 2018-08-20 at 12:06 +0200, Ricardo Ribalda Delgado wrote:
> Hi
> 
> I think that I found a bug with ldd on sumo. Whenever I try to use it
> on the target with an dynamic binary, it returns:
> 
> root@qt5122:~# ldd ./qtec_webcam
> not a dynamic executable
> 
> 
> The reason seems to be that it cannot find the dynamic linker:
> 
> It is searching for:
> RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> /libx32/ld-linux-x32.so.2"
> 
> whith ldd being at:
> /lib/ld-linux-x86-64.so.2

We allow base_libdir to be configured and default to /lib even on
x64_64. ldd should really be honouring base_libdir so that sounds like
a bit but it would be ours as upstream will just want to conform to the
architecture standard which is lib64.

Cheers,

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


Re: [OE-core] x86_64: ldd does not work (not a dynamic executable)

2018-08-20 Thread Khem Raj
This seems a bug, but we need to ensure it works with multilib
On Mon, Aug 20, 2018 at 3:06 AM Ricardo Ribalda Delgado
 wrote:
>
> Hi
>
> I think that I found a bug with ldd on sumo. Whenever I try to use it
> on the target with an dynamic binary, it returns:
>
> root@qt5122:~# ldd ./qtec_webcam
> not a dynamic executable
>
>
> The reason seems to be that it cannot find the dynamic linker:
>
> It is searching for:
> RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> /libx32/ld-linux-x32.so.2"
>
> whith ldd being at:
> /lib/ld-linux-x86-64.so.2
>
> This can be patched on glibc with:
>
> git diff ./sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> diff --git a/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> b/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> index 44d76e8aa1..611efd56b0 100644
> --- a/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> +++ b/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> @@ -1,3 +1,3 @@
>  /LD_TRACE_LOADED_OBJECTS=1/a\
>  add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
> -s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
>]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6"_
> +s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
>]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_
>
> I can very easily make a patch for this and send it, but  it is too
> strange, that I have been the first person to stumble with this thing
> :), and I do not know if this is a bug OE-specific or shall I also
> ping upstream.
>
> Any ideas?
>
> Thanks!
>
>
> --
> Ricardo Ribalda
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt

2018-08-20 Thread Khem Raj
On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie
 wrote:
>
> On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote:
> > busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
> >
> > Signed-off-by: Peter Kjellerstedt 
> > ---
> >  meta/recipes-core/busybox/busybox.inc | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
> > core/busybox/busybox.inc
> > index 8c6dbbaf9b..a8ba10d21c 100644
> > --- a/meta/recipes-core/busybox/busybox.inc
> > +++ b/meta/recipes-core/busybox/busybox.inc
> > @@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of many
> > common UNIX utilities into
> >  HOMEPAGE = "http://www.busybox.net;
> >  BUGTRACKER = "https://bugs.busybox.net/;
> >
> > -DEPENDS += "kern-tools-native"
> > +# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not defined
> > +DEPENDS += "kern-tools-native virtual/crypt"
>
> I'm not a bug fan of adding dependencies which might not be needed. How
> common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't
> our default config?

yes perhaps it should be packageconfig

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


[OE-core] [PATCH 5/5] llvm: Use HOST_ARCH in LLVM_TARGETS_TO_BUILD for builds

2018-08-20 Thread Khem Raj
LLVM_TARGETS_TO_BUILD is needed to represent HOST_ARCH for
builds and target specific additions should use class-target
override

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/llvm/llvm_git.bb | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-devtools/llvm/llvm_git.bb 
b/meta/recipes-devtools/llvm/llvm_git.bb
index d853d4151d..df7c13 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -44,14 +44,15 @@ def get_llvm_arch(bb, d, arch_var):
 else:
 raise bb.parse.SkipRecipe("Cannot map '%s' to a supported LLVM 
architecture" % a)
 
-def get_llvm_target_arch(bb, d):
-return get_llvm_arch(bb, d, 'TARGET_ARCH')
+def get_llvm_host_arch(bb, d):
+return get_llvm_arch(bb, d, 'HOST_ARCH')
+
 #
 # Default to build all OE-Core supported target arches (user overridable).
 #
-LLVM_TARGETS ?= "${@get_llvm_target_arch(bb, d)}"
-LLVM_TARGETS_prepend_x86 = "AMDGPU;"
-LLVM_TARGETS_prepend_x86-64 = "AMDGPU;"
+LLVM_TARGETS ?= "${@get_llvm_host_arch(bb, d)}"
+LLVM_TARGETS_prepend_class-target_x86 = "AMDGPU;"
+LLVM_TARGETS_prepend_class-target_x86-64 = "AMDGPU;"
 
 ARM_INSTRUCTION_SET_armv5 = "arm"
 ARM_INSTRUCTION_SET_armv4t = "arm"
-- 
2.18.0

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


[OE-core] [PATCH 3/5] gdb: Alias rpl_stat to stat() on musl

2018-08-20 Thread Khem Raj
Use CPPFLAGS instead of CFLAGS since there is C++ compiler being used for 
somefiles

Fixes
gdb/gdbserver/../../../gdb-8.1.1/gdb/gdbserver/../common/common-utils.c:419: 
undefined reference to `rpl_stat'
| collect2: error: ld returned 1 exit status
| make[4]: *** [Makefile:414: libinproctrace.so] Error 1

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gdb/gdb_8.1.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gdb/gdb_8.1.1.bb 
b/meta/recipes-devtools/gdb/gdb_8.1.1.bb
index 84ab08ce93..c6eac84dd8 100644
--- a/meta/recipes-devtools/gdb/gdb_8.1.1.bb
+++ b/meta/recipes-devtools/gdb/gdb_8.1.1.bb
@@ -26,4 +26,4 @@ EOF
chmod +x ${WORKDIR}/python
fi
 }
-CFLAGS_append_libc-musl = " -Drpl_gettimeofday=gettimeofday"
+CPPFLAGS_append_libc-musl = " -Drpl_gettimeofday=gettimeofday -Drpl_stat=stat"
-- 
2.18.0

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


[OE-core] [PATCH 4/5] dos2unix.bbclass: Move to oe-core

2018-08-20 Thread Khem Raj
- Import from meta-oe layer

- This is useful for many packages where CR-LF
  needs to be adjusted, many recipes depend on it
  e.g. meta-multimedia libebml and so on.

- Add myself as maintainer for now

Signed-off-by: Khem Raj 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../dos2unix/dos2unix_7.4.0.bb| 34 +++
 2 files changed, 35 insertions(+)
 create mode 100644 meta/recipes-support/dos2unix/dos2unix_7.4.0.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 0d1c72a85f..19bd148700 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -134,6 +134,7 @@ RECIPE_MAINTAINER_pn-dmidecode = "Alexander Kanavin 
"
 RECIPE_MAINTAINER_pn-dnf = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-docbook-xml-dtd4 = "Yi Zhao "
 RECIPE_MAINTAINER_pn-docbook-xsl-stylesheets = "Yi Zhao 
"
+RECIPE_MAINTAINER_pn-dos2unit = "Khem Raj "
 RECIPE_MAINTAINER_pn-dosfstools = "Yi Zhao "
 RECIPE_MAINTAINER_pn-dpkg = "Aníbal Limón "
 RECIPE_MAINTAINER_pn-dropbear = "Yi Zhao "
diff --git a/meta/recipes-support/dos2unix/dos2unix_7.4.0.bb 
b/meta/recipes-support/dos2unix/dos2unix_7.4.0.bb
new file mode 100644
index 00..9964315ee7
--- /dev/null
+++ b/meta/recipes-support/dos2unix/dos2unix_7.4.0.bb
@@ -0,0 +1,34 @@
+SUMMARY = "Convert text file line endings between CRLF and LF"
+DESCRIPTION = "The Dos2unix package includes utilities dos2unix and \
+unix2dos to convert plain text files in DOS or Mac format to Unix \
+format and vice versa."
+HOMEPAGE = "http://waterlan.home.xs4all.nl/dos2unix.html;
+SECTION = "support"
+
+LICENSE = "BSD-2-Clause"
+LIC_FILES_CHKSUM = "file://COPYING.txt;md5=1b78fca784db24f4a40e30b300787f3f"
+
+SRC_URI = "git://git.code.sf.net/p/dos2unix/dos2unix"
+
+# Release 7.4.0
+SRCREV = "1182533bde3c1fe65be2ead465e87671faa2c027"
+
+S = "${WORKDIR}/git/dos2unix"
+
+inherit gettext perlnative
+
+# The dos2unix NLS relies on po4a-native, while po4a recipe is
+# provided by meta-perl layer, so make it optional here, you
+# need have meta-perl in bblayers.conf before enabling nls in
+# PACKAGECONFIG.
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[nls] = "ENABLE_NLS=1,ENABLE_NLS=,po4a-native"
+
+EXTRA_OEMAKE = "${PACKAGECONFIG_CONFARGS} LDFLAGS_USER='${LDFLAGS}'"
+EXTRA_OEMAKE_class-native = "ENABLE_NLS="
+
+do_install () {
+   oe_runmake DESTDIR="${D}${base_prefix}" install
+}
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.18.0

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


[OE-core] [PATCH 2/5] gdb: Upgrade to 8.1.1

2018-08-20 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/gdb/{gdb-8.1.inc => gdb-8.1.1.inc}  | 4 ++--
 ...{gdb-cross-canadian_8.1.bb => gdb-cross-canadian_8.1.1.bb} | 0
 .../gdb/{gdb-cross_8.1.bb => gdb-cross_8.1.1.bb}  | 0
 meta/recipes-devtools/gdb/{gdb_8.1.bb => gdb_8.1.1.bb}| 0
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/gdb/{gdb-8.1.inc => gdb-8.1.1.inc} (89%)
 rename meta/recipes-devtools/gdb/{gdb-cross-canadian_8.1.bb => 
gdb-cross-canadian_8.1.1.bb} (100%)
 rename meta/recipes-devtools/gdb/{gdb-cross_8.1.bb => gdb-cross_8.1.1.bb} 
(100%)
 rename meta/recipes-devtools/gdb/{gdb_8.1.bb => gdb_8.1.1.bb} (100%)

diff --git a/meta/recipes-devtools/gdb/gdb-8.1.inc 
b/meta/recipes-devtools/gdb/gdb-8.1.1.inc
similarity index 89%
rename from meta/recipes-devtools/gdb/gdb-8.1.inc
rename to meta/recipes-devtools/gdb/gdb-8.1.1.inc
index 4d9faa2d4b..ad80dd3e4d 100644
--- a/meta/recipes-devtools/gdb/gdb-8.1.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.1.1.inc
@@ -18,6 +18,6 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://package_devel_gdb_patches_120-sigprocmask-invalid-call.patch 
\
file://gdb-Fix-ia64-defining-TRAP_HWBKPT-before-including-g.patch \
 "
-SRC_URI[md5sum] = "f46487561f9a16916a8102316f7fd105"
-SRC_URI[sha256sum] = 
"af61a0263858e69c5dce51eab26662ff3d2ad9aa68da9583e8143b5426be4b34"
+SRC_URI[md5sum] = "372fa63a53adeee1bfbfd581d8da9e34"
+SRC_URI[sha256sum] = 
"97dcc3169bd430270fc29adb65145846a58c1b55cdbb73382a4a89307bdad03c"
 
diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian_8.1.bb 
b/meta/recipes-devtools/gdb/gdb-cross-canadian_8.1.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross-canadian_8.1.bb
rename to meta/recipes-devtools/gdb/gdb-cross-canadian_8.1.1.bb
diff --git a/meta/recipes-devtools/gdb/gdb-cross_8.1.bb 
b/meta/recipes-devtools/gdb/gdb-cross_8.1.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross_8.1.bb
rename to meta/recipes-devtools/gdb/gdb-cross_8.1.1.bb
diff --git a/meta/recipes-devtools/gdb/gdb_8.1.bb 
b/meta/recipes-devtools/gdb/gdb_8.1.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb_8.1.bb
rename to meta/recipes-devtools/gdb/gdb_8.1.1.bb
-- 
2.18.0

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


[OE-core] [PATCH 1/5] mesa: Enable gallium-llvm on x86 and x86_64

2018-08-20 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 meta/recipes-graphics/cairo/cairo.inc | 3 ++-
 meta/recipes-graphics/mesa/mesa.inc   | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cairo/cairo.inc 
b/meta/recipes-graphics/cairo/cairo.inc
index 20e0d2c92a..7347f223ff 100644
--- a/meta/recipes-graphics/cairo/cairo.inc
+++ b/meta/recipes-graphics/cairo/cairo.inc
@@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
 DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
 
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xcb', 
'', d)} \
-   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
+   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'opengl', '', 
d)}"
 
 PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no 
--disable-xlib,${X11DEPENDS}"
 PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 5afd0db4b7..dd626d9f00 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -48,6 +48,9 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 
'wayland vulkan', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan', 
'dri3', '', d)} \
   "
 
+PACKAGECONFIG_append_x86 = " gallium-llvm gallium r600"
+PACKAGECONFIG_append_x86-64 = " gallium-llvm gallium r600"
+
 # "gbm" requires "dri", "opengl"
 PACKAGECONFIG[gbm] = "--enable-gbm,--disable-gbm"
 
-- 
2.18.0

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


[OE-core] [PATCH V3 0/5] Use llvmpile for mesa on x86/x86-64

2018-08-20 Thread Khem Raj
This series fixes llvm build to support multilib configurations
Adds dos2unix bbclass to core from meta-oe
Fixes ppc security flags world builds

v2:
Upgrade binutils and gdb
Fix libidb2 cross build issue when build host == target host

v3:
Fix sstate differences between different builds for llvm-native
Fix gdb on x86_64/musl
Import dos2unix recipe into core along with bbclass

The following changes since commit 3cb303ffee8610d41c9a0745d366556c24066bc3:

  weston-init: run login before start weston.service (2018-08-20 11:59:44 +0100)

are available in the Git repository at:

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

Khem Raj (5):
  mesa: Enable gallium-llvm on x86 and x86_64
  gdb: Upgrade to 8.1.1
  gdb: Alias rpl_stat to stat() on musl
  dos2unix.bbclass: Move to oe-core
  llvm: Use HOST_ARCH in LLVM_TARGETS_TO_BUILD for builds

 meta/conf/distro/include/maintainers.inc  |  1 +
 .../gdb/{gdb-8.1.inc => gdb-8.1.1.inc}|  4 +--
 ...ian_8.1.bb => gdb-cross-canadian_8.1.1.bb} |  0
 .../{gdb-cross_8.1.bb => gdb-cross_8.1.1.bb}  |  0
 .../gdb/{gdb_8.1.bb => gdb_8.1.1.bb}  |  2 +-
 meta/recipes-devtools/llvm/llvm_git.bb| 11 +++---
 meta/recipes-graphics/cairo/cairo.inc |  3 +-
 meta/recipes-graphics/mesa/mesa.inc   |  3 ++
 .../dos2unix/dos2unix_7.4.0.bb| 34 +++
 9 files changed, 49 insertions(+), 9 deletions(-)
 rename meta/recipes-devtools/gdb/{gdb-8.1.inc => gdb-8.1.1.inc} (89%)
 rename meta/recipes-devtools/gdb/{gdb-cross-canadian_8.1.bb => 
gdb-cross-canadian_8.1.1.bb} (100%)
 rename meta/recipes-devtools/gdb/{gdb-cross_8.1.bb => gdb-cross_8.1.1.bb} 
(100%)
 rename meta/recipes-devtools/gdb/{gdb_8.1.bb => gdb_8.1.1.bb} (92%)
 create mode 100644 meta/recipes-support/dos2unix/dos2unix_7.4.0.bb

-- 
2.18.0

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


Re: [OE-core] [PATCH 1/9] mesa: Enable gallium-llvm on x86 and x86_64

2018-08-20 Thread Khem Raj
On Mon, Aug 20, 2018 at 10:14 AM Khem Raj  wrote:
>
> On Mon, Aug 20, 2018 at 2:40 AM Richard Purdie
>  wrote:
> >
> > On Sun, 2018-08-19 at 10:23 -0700, Khem Raj wrote:
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/recipes-graphics/cairo/cairo.inc | 3 ++-
> > >  meta/recipes-graphics/mesa/mesa.inc   | 3 +++
> > >  2 files changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-graphics/cairo/cairo.inc b/meta/recipes-
> > > graphics/cairo/cairo.inc
> > > index 20e0d2c92a..7347f223ff 100644
> > > --- a/meta/recipes-graphics/cairo/cairo.inc
> > > +++ b/meta/recipes-graphics/cairo/cairo.inc
> > > @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender
> > > libxext"
> > >  DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
> > >
> > >  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> > > 'x11 xcb', '', d)} \
> > > -   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
> > > +   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
> > > +   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
> > > 'opengl', '', d)}"
> > >
> > >  PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no --
> > > disable-xlib,${X11DEPENDS}"
> > >  PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
> > > diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-
> > > graphics/mesa/mesa.inc
> > > index 6aedeee9dc..2671d4de4d 100644
> > > --- a/meta/recipes-graphics/mesa/mesa.inc
> > > +++ b/meta/recipes-graphics/mesa/mesa.inc
> > > @@ -47,6 +47,9 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATU
> > > RES', 'wayland vulkan', d)} \
> > > ${@bb.utils.contains('DISTRO_FEATURES', 'x11
> > > vulkan', 'dri3', '', d)} \
> > >  "
> > >
> > > +PACKAGECONFIG_append_x86 = " gallium-llvm gallium r600"
> > > +PACKAGECONFIG_append_x86-64 = " gallium-llvm gallium r600"
> > > +
> > >  # "gbm" requires "dri", "opengl"
> > >  PACKAGECONFIG[gbm] = "--enable-gbm,--disable-gbm"
> >
> > Adding this patch causes:
> >
> > "oe-selftest -r sstatetests.SStateTests.test_sstate_32_64_same_hash"
> >
> > to fail. I've not looked into it in more detail other than to narrow it
> > down to this patch.
> >
>
>  my hunch is that its due to new env variables
> probably we need to add them to exclude list...?
> see
> YOCTO_ALTERNATE_* vars
>
> http://git.openembedded.org/openembedded-core/commit/?h=master-next=c5a27bd4d450911afa38846bc00ef762e4414eda
>

I think I see the problem, its because of DLLVM_TARGETS_TO_BUILD being used
for native llvm. I am testting this fix
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master=7cc195f4f8850ad314ef9b93535f874f05a6f9ed



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


[OE-core] Yocto Project Unassigned Bugs - Help Needed

2018-08-20 Thread Jolley, Stephen K
All,



The triage team meets weekly and does its best to handle the bugs reported into 
the bugzilla. The number of people attending that meeting has fallen, as have 
the number of people available to help fix bugs. One of the things we hear 
users report is they don't know how to help. We (the triage team) are therefore 
going to start reporting out the currently 314 unassigned bugs.



We're hoping people may be able to spare some time now and again to help out 
with these.



Bugs are split into two types, "true bugs" where things don't work as they 
should and "enhancements" which are features we'd want to add to the system.



There are also roughly three different "priority" classes right now, "2.6", 
"2.99" and "Future", the more pressing/urgent issues being in "2.6".



Please review this link and if a bug is something you would be able to help 
with either take ownership of the bug, or send me (stephen.k.jol...@intel.com) 
an e-mail with the bug number you would like and I will assign it to you 
(please make sure you have a bugzilla account).



The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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


Re: [OE-core] [PATCH 4/9] dos2unix.bbclass: Move to oe-core

2018-08-20 Thread Khem Raj
I updated this in pull branch to include recipe as well.
On Mon, Aug 20, 2018 at 10:02 AM Khem Raj  wrote:
>
> On Mon, Aug 20, 2018 at 2:43 AM Richard Purdie
>  wrote:
> >
> > On Mon, 2018-08-20 at 11:23 +0200, Martin Hundebøll wrote:
> > > Hi Khem,
> > >
> > > On 19/08/2018 19.23, Khem Raj wrote:
> > > > - Import from meta-oe layer
> > > >
> > > > - This is useful for many packages where CR-LF
> > > >needs to be adjusted, many recipes depend on it
> > > >e.g. meta-multimedia libebml and so on.
> > > >
> > > > Signed-off-by: Khem Raj 
> > > > ---
> > > >   meta/classes/dos2unix.bbclass | 14 ++
> > > >   1 file changed, 14 insertions(+)
> > > >   create mode 100644 meta/classes/dos2unix.bbclass
> > > >
> > > > diff --git a/meta/classes/dos2unix.bbclass
> > > > b/meta/classes/dos2unix.bbclass
> > > > new file mode 100644
> > > > index 00..3fc17e2196
> > > > --- /dev/null
> > > > +++ b/meta/classes/dos2unix.bbclass
> > > > @@ -0,0 +1,14 @@
> > > > +# Class for use to convert all CRLF line terminators to LF
> > > > +# provided that some projects are being developed/maintained
> > > > +# on Windows so they have different line terminators(CRLF) vs
> > > > +# on Linux(LF), which can cause annoying patching errors during
> > > > +# git push/checkout processes.
> > > > +
> > > > +do_convert_crlf_to_lf[depends] += "dos2unix-
> > > > native:do_populate_sysroot"
> > >
> > > Shouldn't the dos2unix recipe live in oe-core also, when a class
> > > depends upon it?
> >
> > Not necessarily, we do have a number of core classes which aren't
> > directly used in OE-Core but are needed by many layers and having a
> > common copy makes sense.
> >
> > I'd agree it is good to try and have something which tests them though.
> >
>
> in this case, I think it would make sense to bring in recipe as well, since 
> the
> motivation to bring this into core is to unlink dependency on meta-oe layer
>
> > Cheers,
> >
> > Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/9] mesa: Enable gallium-llvm on x86 and x86_64

2018-08-20 Thread Khem Raj
On Mon, Aug 20, 2018 at 2:40 AM Richard Purdie
 wrote:
>
> On Sun, 2018-08-19 at 10:23 -0700, Khem Raj wrote:
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/recipes-graphics/cairo/cairo.inc | 3 ++-
> >  meta/recipes-graphics/mesa/mesa.inc   | 3 +++
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-graphics/cairo/cairo.inc b/meta/recipes-
> > graphics/cairo/cairo.inc
> > index 20e0d2c92a..7347f223ff 100644
> > --- a/meta/recipes-graphics/cairo/cairo.inc
> > +++ b/meta/recipes-graphics/cairo/cairo.inc
> > @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender
> > libxext"
> >  DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
> >
> >  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> > 'x11 xcb', '', d)} \
> > -   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
> > +   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
> > +   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
> > 'opengl', '', d)}"
> >
> >  PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no --
> > disable-xlib,${X11DEPENDS}"
> >  PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
> > diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-
> > graphics/mesa/mesa.inc
> > index 6aedeee9dc..2671d4de4d 100644
> > --- a/meta/recipes-graphics/mesa/mesa.inc
> > +++ b/meta/recipes-graphics/mesa/mesa.inc
> > @@ -47,6 +47,9 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATU
> > RES', 'wayland vulkan', d)} \
> > ${@bb.utils.contains('DISTRO_FEATURES', 'x11
> > vulkan', 'dri3', '', d)} \
> >  "
> >
> > +PACKAGECONFIG_append_x86 = " gallium-llvm gallium r600"
> > +PACKAGECONFIG_append_x86-64 = " gallium-llvm gallium r600"
> > +
> >  # "gbm" requires "dri", "opengl"
> >  PACKAGECONFIG[gbm] = "--enable-gbm,--disable-gbm"
>
> Adding this patch causes:
>
> "oe-selftest -r sstatetests.SStateTests.test_sstate_32_64_same_hash"
>
> to fail. I've not looked into it in more detail other than to narrow it
> down to this patch.
>

 my hunch is that its due to new env variables
probably we need to add them to exclude list...?
see
YOCTO_ALTERNATE_* vars

http://git.openembedded.org/openembedded-core/commit/?h=master-next=c5a27bd4d450911afa38846bc00ef762e4414eda

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


Re: [OE-core] Submission of 'emit-buildvars' class?

2018-08-20 Thread Enrico Scholz via Openembedded-core
Alexander Kanavin  writes:

>> I do not know, how this can be done with plain OE.  As said, SDKs are too
>> heavy weighted, 'devshell' too slow and can not be scripted, 'externalsrc'
>> is broken, slow and can not be scripted.
>
> For better or worse, Yocto Project has standardized on devtool (not
> devshell!)

'devtool' is for writing recipes, not for writing software.


> and externalsrc for these kind of local development workflows. You are
> very welcome to improve and add to them, so they are not broken

I tried 'externalsrc' after the per-package sysroot changes but just run
into bugs (class tried to write into read-only mounted source dir, every
2nd 'do_fetch' failed because sysroot was already populated).


Doing a 'make -f ../Makefile.common install' which writes data directly
into the NFS root is much faster than doing all the steps of the dev*
tools.


> or slow,

They *are* slow.

| $ cd workspace/kernel
| 
| $ git commit -m 'empty' --allow-empty
| 
| $ time bitbake linux-mainline
| real4m7.417s
| user0m0.763s
| sys 0m0.110s

vs.

| time make -f ../Makefile.kernel  -j12
| real0m13.204s
| user0m54.888s
| sys 0m17.970s



Even a plain 'bitbake'  is takes 0.5 sec:

| $ time bitbake
| Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake 
--help' for usage information.
| 
| real0m0.588s
| user0m0.255s
| sys 0m0.023s

vs.

| $ time make
| real0m0.007s
| user0m0.002s
| sys 0m0.005s



And some things are impossible because they are not supported by the
design.  E.g. how would would you implement the flymake 'check-syntax'
target[1]

| check-syntax:
| gcc -o /dev/null -S ${CHK_SOURCES} || true

with devtool/devshell/externalsrc?


Deciding which task to execute (compile, do_compile_kernelmodules) and
installation into NFS root is not supported by dev* either.



Enrico


Footnotes: 
[1]  
https://www.gnu.org/software/emacs/manual/html_mono/flymake.html#Example_002d_002d_002dConfiguring-a-tool-called-via-make

-- 
SIGMA Chemnitz GmbH   Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13   Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 4/9] dos2unix.bbclass: Move to oe-core

2018-08-20 Thread Khem Raj
On Mon, Aug 20, 2018 at 2:43 AM Richard Purdie
 wrote:
>
> On Mon, 2018-08-20 at 11:23 +0200, Martin Hundebøll wrote:
> > Hi Khem,
> >
> > On 19/08/2018 19.23, Khem Raj wrote:
> > > - Import from meta-oe layer
> > >
> > > - This is useful for many packages where CR-LF
> > >needs to be adjusted, many recipes depend on it
> > >e.g. meta-multimedia libebml and so on.
> > >
> > > Signed-off-by: Khem Raj 
> > > ---
> > >   meta/classes/dos2unix.bbclass | 14 ++
> > >   1 file changed, 14 insertions(+)
> > >   create mode 100644 meta/classes/dos2unix.bbclass
> > >
> > > diff --git a/meta/classes/dos2unix.bbclass
> > > b/meta/classes/dos2unix.bbclass
> > > new file mode 100644
> > > index 00..3fc17e2196
> > > --- /dev/null
> > > +++ b/meta/classes/dos2unix.bbclass
> > > @@ -0,0 +1,14 @@
> > > +# Class for use to convert all CRLF line terminators to LF
> > > +# provided that some projects are being developed/maintained
> > > +# on Windows so they have different line terminators(CRLF) vs
> > > +# on Linux(LF), which can cause annoying patching errors during
> > > +# git push/checkout processes.
> > > +
> > > +do_convert_crlf_to_lf[depends] += "dos2unix-
> > > native:do_populate_sysroot"
> >
> > Shouldn't the dos2unix recipe live in oe-core also, when a class
> > depends upon it?
>
> Not necessarily, we do have a number of core classes which aren't
> directly used in OE-Core but are needed by many layers and having a
> common copy makes sense.
>
> I'd agree it is good to try and have something which tests them though.
>

in this case, I think it would make sense to bring in recipe as well, since the
motivation to bring this into core is to unlink dependency on meta-oe layer

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


Re: [OE-core] [PATCH 8/9] gdb: Upgrade to 8.1.1

2018-08-20 Thread Khem Raj
On Mon, Aug 20, 2018 at 3:59 AM Richard Purdie
 wrote:
>
> On Sun, 2018-08-19 at 19:41 -0700, Khem Raj wrote:
> > On Sun, Aug 19, 2018 at 7:19 PM ChenQi  wrote:
> > >
> > > There's a build failure on autobuilder.
> > >
> > > https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/70
> > > 0/steps/BuildImages/logs/stdio
> > >
> >
> >  I pushed a patch to pull branch which should fix it
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/
> > master=a05cc1ee8eb1cb05064164a9ae62db6dc78d022b
>
> I'm afraid not:
>
> https://autobuilder.yocto.io/builders/nightly-musl/builds/1252/steps/Bu
> ildImages/logs/stdio
>
> https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/701/st
> eps/BuildImages/logs/stdio
>

yeah C++, how can I ignore that. Refreshed the patch to use CPPFLAGS instead
of CFLAGS, verified locally too. Give it a shot

http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master=dc5dd1be33265c28e0f029b12888183d55f3


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


Re: [OE-core] [PATCH v2] classes/package: Clean up getstatusoutput

2018-08-20 Thread richard . purdie
On Mon, 2018-08-20 at 10:54 -0500, Joshua Watt wrote:
> Replaces usage of the deprecated oe.utils.getstatusoutput() with
> Python
> subprocess calls.
> 
> Signed-off-by: Joshua Watt 
> ---
>  meta/classes/package.bbclass | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/classes/package.bbclass
> b/meta/classes/package.bbclass
> index 4ce9de2f573..3976811d19f 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -380,6 +380,7 @@ def splitdebuginfo(file, dvar, debugdir,
> debuglibdir, debugappend, debugsrcdir,
>  # sourcefile is also generated containing a list of debugsources
>  
>  import stat
> +import subprocess
>  
>  src = file[len(dvar):]
>  dest = debuglibdir + os.path.dirname(src) + debugdir + "/" +
> os.path.basename(src) + debugappend
> @@ -409,16 +410,10 @@ def splitdebuginfo(file, dvar, debugdir,
> debuglibdir, debugappend, debugsrcdir,
>  
>  bb.utils.mkdirhier(os.path.dirname(debugfile))
>  
> -cmd = "'%s' --only-keep-debug '%s' '%s'" % (objcopy, file, debugfile)
> -(retval, output) = oe.utils.getstatusoutput(cmd)
> -if retval:
> -bb.fatal("objcopy failed with exit code %s (cmd was %s)%s" % 
> (retval, cmd, ":\n%s" % output if output else ""))
> +subprocess.check_output([objcopy, '--only-keep-debug', file, debugfile])

Sorry, I just realised it needs a stderr=subprocess.STDOUT in there to
ensure the right things happen with logging...

Cheers,

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


Re: [OE-core] [PATCH 1/1] assimp.py: fix AttributeError in tearDownClass

2018-08-20 Thread Richard Purdie
On Fri, 2018-08-17 at 17:17 +0800, Chen Qi wrote:
> When running this test case, we will see the following error.
> 
>   AttributeError: type object 'BuildAssimp' has no attribute
> 'project'
> 
> assimp.py test case does not make use of SDKBuildProject, so remove
> the import statement and the tearDownClass.
> 
> Signed-off-by: Chen Qi 
> ---
>  meta/lib/oeqa/sdk/cases/assimp.py | 5 -
>  1 file changed, 5 deletions(-)

I'm not seeing this error when I run the test and I can't see it on the
autobuilders. Why are you seeing this and we're not?

I'm trying to understand some other odd behaviour in SDK tests and am
wondering if this is related or not.

(e.g. https://autobuilder.yocto.io/builders/nightly-mips/builds/1221/st
eps/Running%20SDK%20Sanity%20Tests/logs/stdio)

Cheers,

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


Re: [OE-core] Submission of 'emit-buildvars' class?

2018-08-20 Thread Alexander Kanavin
2018-08-20 17:58 GMT+02:00 Enrico Scholz :
> I do not know, how this can be done with plain OE.  As said, SDKs are too
> heavy weighted, 'devshell' too slow and can not be scripted, 'externalsrc'
> is broken, slow and can not be scripted.

For better or worse, Yocto Project has standardized on devtool (not
devshell!) and externalsrc for these kind of local development
workflows. You are very welcome to improve and add to them, so they
are not broken or slow, but a wholly different mechanism is not likely
to be accepted.

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


Re: [OE-core] Submission of 'emit-buildvars' class?

2018-08-20 Thread Enrico Scholz via Openembedded-core
Alexander Kanavin  writes:

>> we are using for some time an 'emit-buildvars' class which exports
>> bitbake variables into makefile fragments.  This class is used for for
>> developing of kernel, u-boot and other low level software and for
>> generic packaging.
>
> I don't quite understand how this is useful? Can you provide specific
> usage scenarios please?

I ma doing perhaps 70% of my development for kernel, u-boot and barebox.
Building them with the actual toolchain requires only a

| make -f ../Makefile.kernel tftp

Result is available after a few seconds on the TFTP server; when using a
specialized variant ('kbuild-file=...'), even faster so that it can be
used in Emacs flymake mode.


Ditto for other programs (testsuites or so); you write your recipe with
all the 'DEPENDS', execute the 'emit_buildvars' task and build your
application with

| make -f ../Makefile.common R=my-app

When you see that something is missing in DEPENDS, add it, reexecute
'emit_buildvars' and it will be in the per-package sysroot.  Excluding
the build time of the dependency, this won't take more than 30 seconds.


Or, it is trivial to run unfsd in the enviornment of the image recipe
and to build kernel modules with

| make -f ../Makefile.kernel modules modules-install

These modules will be installed there and can be used immediately on the
target system:

| # rmmod foo-module
| # modprobe foo-module


I do not know, how this can be done with plain OE.  As said, SDKs are too
heavy weighted, 'devshell' too slow and can not be scripted, 'externalsrc'
is broken, slow and can not be scripted.


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


[OE-core] [PATCH v2] classes/package: Clean up getstatusoutput

2018-08-20 Thread Joshua Watt
Replaces usage of the deprecated oe.utils.getstatusoutput() with Python
subprocess calls.

Signed-off-by: Joshua Watt 
---
 meta/classes/package.bbclass | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 4ce9de2f573..3976811d19f 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -380,6 +380,7 @@ def splitdebuginfo(file, dvar, debugdir, debuglibdir, 
debugappend, debugsrcdir,
 # sourcefile is also generated containing a list of debugsources
 
 import stat
+import subprocess
 
 src = file[len(dvar):]
 dest = debuglibdir + os.path.dirname(src) + debugdir + "/" + 
os.path.basename(src) + debugappend
@@ -409,16 +410,10 @@ def splitdebuginfo(file, dvar, debugdir, debuglibdir, 
debugappend, debugsrcdir,
 
 bb.utils.mkdirhier(os.path.dirname(debugfile))
 
-cmd = "'%s' --only-keep-debug '%s' '%s'" % (objcopy, file, debugfile)
-(retval, output) = oe.utils.getstatusoutput(cmd)
-if retval:
-bb.fatal("objcopy failed with exit code %s (cmd was %s)%s" % (retval, 
cmd, ":\n%s" % output if output else ""))
+subprocess.check_output([objcopy, '--only-keep-debug', file, debugfile])
 
 # Set the debuglink to have the view of the file path on the target
-cmd = "'%s' --add-gnu-debuglink='%s' '%s'" % (objcopy, debugfile, file)
-(retval, output) = oe.utils.getstatusoutput(cmd)
-if retval:
-bb.fatal("objcopy failed with exit code %s (cmd was %s)%s" % (retval, 
cmd, ":\n%s" % output if output else ""))
+subprocess.check_output([objcopy, '--add-gnu-debuglink', debugfile, file])
 
 if newmode:
 os.chmod(file, origmode)
-- 
2.17.1

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


[OE-core] [PATCH] autoconf: update runtime perl module dependencies

2018-08-20 Thread Mikko Rapeli
Test in SDK was failing to execute:

$ autoreconf --install --force

due to missing perl modules. Add the needed perl modules
for target build:

perl-module-bytes
perl-module-thread-queue
perl-module-threads

Duplicate the perl module dependencies for SDK as well.

Now autoreconf runs with a trivial example.

Signed-off-by: Mikko Rapeli 
---
 meta/recipes-devtools/autoconf/autoconf.inc | 31 ++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/autoconf/autoconf.inc 
b/meta/recipes-devtools/autoconf/autoconf.inc
index df81bc6..b82af5a 100644
--- a/meta/recipes-devtools/autoconf/autoconf.inc
+++ b/meta/recipes-devtools/autoconf/autoconf.inc
@@ -10,24 +10,49 @@ DEPENDS_class-native = "m4-native gnu-config-native"
 DEPENDS_class-nativesdk = "nativesdk-m4 nativesdk-gnu-config"
 RDEPENDS_${PN} = "m4 gnu-config \
  perl \
+ perl-module-bytes \
  perl-module-carp \
  perl-module-constant \
+ perl-module-data-dumper \
  perl-module-errno \
  perl-module-exporter \
  perl-module-file-basename \
  perl-module-file-compare \
  perl-module-file-copy \
+ perl-module-file-find \
  perl-module-file-glob \
  perl-module-file-path \
  perl-module-file-stat \
- perl-module-file-find \
  perl-module-getopt-long \
  perl-module-io-file \
  perl-module-posix \
- perl-module-data-dumper \
+ perl-module-thread-queue \
+ perl-module-threads \
 "
 RDEPENDS_${PN}_class-native = "m4-native gnu-config-native"
-RDEPENDS_${PN}_class-nativesdk = "nativesdk-m4 nativesdk-gnu-config"
+RDEPENDS_${PN}_class-nativesdk = "\
+ nativesdk-gnu-config \
+ nativesdk-m4 \
+ nativesdk-perl \
+ nativesdk-perl-module-bytes \
+ nativesdk-perl-module-carp \
+ nativesdk-perl-module-constant \
+ nativesdk-perl-module-data-dumper \
+ nativesdk-perl-module-errno \
+ nativesdk-perl-module-exporter \
+ nativesdk-perl-module-file-basename \
+ nativesdk-perl-module-file-compare \
+ nativesdk-perl-module-file-copy \
+ nativesdk-perl-module-file-find \
+ nativesdk-perl-module-file-glob \
+ nativesdk-perl-module-file-path \
+ nativesdk-perl-module-file-stat \
+ nativesdk-perl-module-getopt-long \
+ nativesdk-perl-module-io-file \
+ nativesdk-perl-module-posix \
+ nativesdk-perl-module-thread-queue \
+ nativesdk-perl-module-threads \
+  "
 
 SRC_URI = "${GNU_MIRROR}/autoconf/autoconf-${PV}.tar.gz \
   file://program_prefix.patch"
-- 
1.9.1

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


Re: [OE-core] Submission of 'emit-buildvars' class?

2018-08-20 Thread Alexander Kanavin
2018-08-20 16:01 GMT+02:00 Enrico Scholz via Openembedded-core
:
> we are using for some time an 'emit-buildvars' class which exports
> bitbake variables into makefile fragments.  This class is used for for
> developing of kernel, u-boot and other low level software and for
> generic packaging.

I don't quite understand how this is useful? Can you provide specific
usage scenarios please?

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


[OE-core] Submission of 'emit-buildvars' class?

2018-08-20 Thread Enrico Scholz via Openembedded-core
Hello,

we are using for some time an 'emit-buildvars' class which exports
bitbake variables into makefile fragments.  This class is used for for
developing of kernel, u-boot and other low level software and for
generic packaging.

The class supports exporting images over userspace NFS and is available
at

  
https://github.com/sigma-embedded/meta-de.sigma-chemnitz/blob/sumo/classes/elito-emit-buildvars.bbclass
  
https://github.com/sigma-embedded/meta-de.sigma-chemnitz/tree/sumo/scripts/buildvars
  
https://github.com/sigma-embedded/meta-de.sigma-chemnitz/blob/sumo/classes/elito-nfs-export.bbclass

It is much faster than 'devshell' and can be used in a scripted
environment.  A complete SDK is far too heavy weight for our tasks
and not flexible enough.

Is there common interest in such a functionality? If so, I would split
it out from our layer and submit it for core.



A more detailed description:

The generated makefile fragment contains information about the per-package
sysroot and can be used to set e.g. $PATH.  The system requires a small
Makefile to instantiate these variables; e.g. for common cases something
like

  workspace/Makefile.common ---
|  # --*- makefile -*--
| WORKSPACE_DIR := $(abspath $(dir $(lastword $(MAKEFILE_LIST
| DEPLOY_DIR ?= ${WORKSPACE_DIR}/../build/tmp/deploy
| MACHINE ?= imx8m-var-dart
| 
| _BUILDVAR_STYLE ?= _generic_
| include ${DEPLOY_DIR}/buildvars/${MACHINE}/$R.mk
| 
| %:
|   ${MAKE} $@

is enough.  For kernel development, the makefile contains some more
information about the image which is going to be exported over NFS.

  workspace/Makefile.kernel ---
| # --*- makefile -*--
| WORKSPACE_DIR := $(abspath $(dir $(lastword $(MAKEFILE_LIST
| DEPLOY_DIR ?= ${WORKSPACE_DIR}/../build/tmp/deploy
| MACHINE ?= imx8m-var-dart
| 
| _BUILDVAR_STYLE := kernel
| IMAGE_RECIPE = camtest-image
| 
| HAVE_NFSROOT=1
| include ${WORKSPACE_DIR}/../sources/de.sigma-chemnitz.core/mk/nfs-opt.mk
| include ${DEPLOY_DIR}/buildvars/${MACHINE}/linux-mainline.mk


Now, generate the '.mk' fragments either manually:

| $ bitbake busybox -c emit_buildvars

or enable it within the recipe (recommended when working on it)

| BUILDVARS_EMIT = "true"

and build the package.


When you try to fix something in 'busybox', extract the sources
somewhere (e.g. in workspace/) and call

| make -f ../Makefile.common R=busybox all

to build it.


Else, see the class for more details.



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


Re: [OE-core] [PATCH v5] kernel-devsrc: restructure for out of tree (and on target) module builds

2018-08-20 Thread Bruce Ashfield

On 08/19/2018 11:36 AM, richard.pur...@linuxfoundation.org wrote:

On Sat, 2018-08-18 at 22:50 -0400, Bruce Ashfield wrote:

[...]

v5:
   - added failure catch for x86 purgatory files which changed in 4.18
 and hence are not universal across versions
   - added explicity bison and flex rdepends for mips64 prepare phase
   - added mips64 files required for scripts/prepare phase
   - added files required for missing syscall support


Tests passed so I've merged it, thanks for persevering, we finally got
there! :)


Excellent! I was hoping v6 wasn't going to be required :D

I'm sure that more corner cases will start popping up as it
gets exercised in the tree.

When they do pop up, I can handle them (via bugs, or whatever),
since I'm pretty familiar with this right now.

Onto 4.18, which I expect to have to you by mid-week.

Cheers,

Bruce



Cheers,

Richard



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


Re: [OE-core] [PATCH 2/2] wic: bootimg-partition: Select a preferred type if multi kernel images are installed

2018-08-20 Thread Tom Rini
On Mon, Aug 20, 2018 at 06:42:25PM +0800, Kevin Hao wrote:

> Automatically select one kernel type image based on a predefined
> precedence list if there are multi kernel images installed.
> 
> Signed-off-by: Kevin Hao 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [OE-core] [PATCH 8/9] gdb: Upgrade to 8.1.1

2018-08-20 Thread Richard Purdie
On Sun, 2018-08-19 at 19:41 -0700, Khem Raj wrote:
> On Sun, Aug 19, 2018 at 7:19 PM ChenQi  wrote:
> > 
> > There's a build failure on autobuilder.
> > 
> > https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/70
> > 0/steps/BuildImages/logs/stdio
> > 
> 
>  I pushed a patch to pull branch which should fix it
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/
> master=a05cc1ee8eb1cb05064164a9ae62db6dc78d022b

I'm afraid not:

https://autobuilder.yocto.io/builders/nightly-musl/builds/1252/steps/Bu
ildImages/logs/stdio

https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/701/st
eps/BuildImages/logs/stdio

Cheers,

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


[OE-core] [PATCH 2/2] wic: bootimg-partition: Select a preferred type if multi kernel images are installed

2018-08-20 Thread Kevin Hao
Automatically select one kernel type image based on a predefined
precedence list if there are multi kernel images installed.

Signed-off-by: Kevin Hao 
---
 .../lib/wic/plugins/source/bootimg-partition.py| 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py 
b/scripts/lib/wic/plugins/source/bootimg-partition.py
index 2e9b9f5ed657..ddc880be366f 100644
--- a/scripts/lib/wic/plugins/source/bootimg-partition.py
+++ b/scripts/lib/wic/plugins/source/bootimg-partition.py
@@ -130,24 +130,28 @@ class BootimgPartitionPlugin(SourcePlugin):
 
 if not custom_cfg:
 # The kernel types supported by the sysboot of u-boot
-kernel_types = ["uImage", "zImage", "Image", "vmlinux", "fitImage"]
+kernel_types = ["zImage", "Image", "fitImage", "uImage", "vmlinux"]
 has_dtb = False
 fdt_dir = '/'
 kernel_name = None
-for task in cls.install_task:
-src, dst = task
-# Find the kernel image name
-for image in kernel_types:
+
+# Find the kernel image name, from the highest precedence to lowest
+for image in kernel_types:
+for task in cls.install_task:
+src, dst = task
 if re.match(image, src):
-if not kernel_name:
-kernel_name = os.path.join('/', dst)
-else:
-raise WicError('Multi kernel file founded')
+kernel_name = os.path.join('/', dst)
+break
+if kernel_name:
+break
 
+for task in cls.install_task:
+src, dst = task
 # We suppose that all the dtb are in the same directory
 if re.search(r'\.dtb', src) and fdt_dir == '/':
 has_dtb = True
 fdt_dir = os.path.join(fdt_dir, os.path.dirname(dst))
+break
 
 if not kernel_name:
 raise WicError('No kernel file founded')
-- 
2.14.4

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


[OE-core] [PATCH 1/2] wic: bootimg-partition: Add support to specify a custom extlinux.conf

2018-08-20 Thread Kevin Hao
Add support to specify a custom extlinux.conf via something like:
bootloader --configfile="extlinux.conf"

Signed-off-by: Kevin Hao 
---
 .../lib/wic/plugins/source/bootimg-partition.py| 79 +-
 1 file changed, 47 insertions(+), 32 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py 
b/scripts/lib/wic/plugins/source/bootimg-partition.py
index 7d61595d0414..2e9b9f5ed657 100644
--- a/scripts/lib/wic/plugins/source/bootimg-partition.py
+++ b/scripts/lib/wic/plugins/source/bootimg-partition.py
@@ -30,6 +30,7 @@ import re
 from glob import glob
 
 from wic import WicError
+from wic.engine import get_custom_config
 from wic.pluginbase import SourcePlugin
 from wic.misc import exec_cmd, get_bitbake_var
 
@@ -114,38 +115,52 @@ class BootimgPartitionPlugin(SourcePlugin):
 if source_params.get('loader') != "u-boot":
 return
 
-# The kernel types supported by the sysboot of u-boot
-kernel_types = ["uImage", "zImage", "Image", "vmlinux", "fitImage"]
-has_dtb = False
-fdt_dir = '/'
-kernel_name = None
-for task in cls.install_task:
-src, dst = task
-# Find the kernel image name
-for image in kernel_types:
-if re.match(image, src):
-if not kernel_name:
-kernel_name = os.path.join('/', dst)
-else:
-raise WicError('Multi kernel file founded')
-
-# We suppose that all the dtb are in the same directory
-if re.search(r'\.dtb', src) and fdt_dir == '/':
-has_dtb = True
-fdt_dir = os.path.join(fdt_dir, os.path.dirname(dst))
-
-if not kernel_name:
-raise WicError('No kernel file founded')
-
-# Compose the extlinux.conf
-extlinux_conf = "default Yocto\n"
-extlinux_conf += "label Yocto\n"
-extlinux_conf += "   kernel %s\n" % kernel_name
-if has_dtb:
-extlinux_conf += "   fdtdir %s\n" % fdt_dir
-bootloader = cr.ks.bootloader
-extlinux_conf += "append root=%s rootwait %s\n" \
- % (cr.rootdev, bootloader.append if bootloader.append 
else '')
+configfile = cr.ks.bootloader.configfile
+custom_cfg = None
+if configfile:
+custom_cfg = get_custom_config(configfile)
+if custom_cfg:
+# Use a custom configuration for extlinux.conf
+extlinux_conf = custom_cfg
+logger.debug("Using custom configuration file "
+ "%s for extlinux.cfg", configfile)
+else:
+raise WicError("configfile is specified but failed to "
+   "get it from %s." % configfile)
+
+if not custom_cfg:
+# The kernel types supported by the sysboot of u-boot
+kernel_types = ["uImage", "zImage", "Image", "vmlinux", "fitImage"]
+has_dtb = False
+fdt_dir = '/'
+kernel_name = None
+for task in cls.install_task:
+src, dst = task
+# Find the kernel image name
+for image in kernel_types:
+if re.match(image, src):
+if not kernel_name:
+kernel_name = os.path.join('/', dst)
+else:
+raise WicError('Multi kernel file founded')
+
+# We suppose that all the dtb are in the same directory
+if re.search(r'\.dtb', src) and fdt_dir == '/':
+has_dtb = True
+fdt_dir = os.path.join(fdt_dir, os.path.dirname(dst))
+
+if not kernel_name:
+raise WicError('No kernel file founded')
+
+# Compose the extlinux.conf
+extlinux_conf = "default Yocto\n"
+extlinux_conf += "label Yocto\n"
+extlinux_conf += "   kernel %s\n" % kernel_name
+if has_dtb:
+extlinux_conf += "   fdtdir %s\n" % fdt_dir
+bootloader = cr.ks.bootloader
+extlinux_conf += "append root=%s rootwait %s\n" \
+ % (cr.rootdev, bootloader.append if 
bootloader.append else '')
 
 install_cmd = "install -d %s/extlinux/" % hdddir
 exec_cmd(install_cmd)
-- 
2.14.4

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


[OE-core] x86_64: ldd does not work (not a dynamic executable)

2018-08-20 Thread Ricardo Ribalda Delgado
Hi

I think that I found a bug with ldd on sumo. Whenever I try to use it
on the target with an dynamic binary, it returns:

root@qt5122:~# ldd ./qtec_webcam
not a dynamic executable


The reason seems to be that it cannot find the dynamic linker:

It is searching for:
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
/libx32/ld-linux-x32.so.2"

whith ldd being at:
/lib/ld-linux-x86-64.so.2

This can be patched on glibc with:

git diff ./sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
diff --git a/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
b/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
index 44d76e8aa1..611efd56b0 100644
--- a/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
+++ b/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
@@ -1,3 +1,3 @@
 /LD_TRACE_LOADED_OBJECTS=1/a\
 add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
   ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6"_
+s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
   ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_

I can very easily make a patch for this and send it, but  it is too
strange, that I have been the first person to stumble with this thing
:), and I do not know if this is a bug OE-specific or shall I also
ping upstream.

Any ideas?

Thanks!


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


Re: [OE-core] [PATCH] busybox: Add a dependency on virtual/crypt

2018-08-20 Thread Richard Purdie
On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote:
> busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
> 
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/recipes-core/busybox/busybox.inc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
> core/busybox/busybox.inc
> index 8c6dbbaf9b..a8ba10d21c 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of many
> common UNIX utilities into
>  HOMEPAGE = "http://www.busybox.net;
>  BUGTRACKER = "https://bugs.busybox.net/;
>  
> -DEPENDS += "kern-tools-native"
> +# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not defined
> +DEPENDS += "kern-tools-native virtual/crypt"

I'm not a bug fan of adding dependencies which might not be needed. How
common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't
our default config?

Cheers,

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


Re: [OE-core] [PATCH 4/9] dos2unix.bbclass: Move to oe-core

2018-08-20 Thread Richard Purdie
On Mon, 2018-08-20 at 11:23 +0200, Martin Hundebøll wrote:
> Hi Khem,
> 
> On 19/08/2018 19.23, Khem Raj wrote:
> > - Import from meta-oe layer
> > 
> > - This is useful for many packages where CR-LF
> >needs to be adjusted, many recipes depend on it
> >e.g. meta-multimedia libebml and so on.
> > 
> > Signed-off-by: Khem Raj 
> > ---
> >   meta/classes/dos2unix.bbclass | 14 ++
> >   1 file changed, 14 insertions(+)
> >   create mode 100644 meta/classes/dos2unix.bbclass
> > 
> > diff --git a/meta/classes/dos2unix.bbclass
> > b/meta/classes/dos2unix.bbclass
> > new file mode 100644
> > index 00..3fc17e2196
> > --- /dev/null
> > +++ b/meta/classes/dos2unix.bbclass
> > @@ -0,0 +1,14 @@
> > +# Class for use to convert all CRLF line terminators to LF
> > +# provided that some projects are being developed/maintained
> > +# on Windows so they have different line terminators(CRLF) vs
> > +# on Linux(LF), which can cause annoying patching errors during
> > +# git push/checkout processes.
> > +
> > +do_convert_crlf_to_lf[depends] += "dos2unix-
> > native:do_populate_sysroot"
> 
> Shouldn't the dos2unix recipe live in oe-core also, when a class
> depends upon it?

Not necessarily, we do have a number of core classes which aren't
directly used in OE-Core but are needed by many layers and having a
common copy makes sense.

I'd agree it is good to try and have something which tests them though.

Cheers,

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


Re: [OE-core] [PATCH 1/9] mesa: Enable gallium-llvm on x86 and x86_64

2018-08-20 Thread Richard Purdie
On Sun, 2018-08-19 at 10:23 -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-graphics/cairo/cairo.inc | 3 ++-
>  meta/recipes-graphics/mesa/mesa.inc   | 3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-graphics/cairo/cairo.inc b/meta/recipes-
> graphics/cairo/cairo.inc
> index 20e0d2c92a..7347f223ff 100644
> --- a/meta/recipes-graphics/cairo/cairo.inc
> +++ b/meta/recipes-graphics/cairo/cairo.inc
> @@ -22,7 +22,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender
> libxext"
>  DEPENDS = "libpng fontconfig pixman glib-2.0 zlib"
>  
>  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> 'x11 xcb', '', d)} \
> -   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)}"
> +   ${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
> +   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
> 'opengl', '', d)}"
>  
>  PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no --
> disable-xlib,${X11DEPENDS}"
>  PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-
> graphics/mesa/mesa.inc
> index 6aedeee9dc..2671d4de4d 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -47,6 +47,9 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATU
> RES', 'wayland vulkan', d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11
> vulkan', 'dri3', '', d)} \
>  "
>  
> +PACKAGECONFIG_append_x86 = " gallium-llvm gallium r600"
> +PACKAGECONFIG_append_x86-64 = " gallium-llvm gallium r600"
> +
>  # "gbm" requires "dri", "opengl"
>  PACKAGECONFIG[gbm] = "--enable-gbm,--disable-gbm"

Adding this patch causes:

"oe-selftest -r sstatetests.SStateTests.test_sstate_32_64_same_hash"

to fail. I've not looked into it in more detail other than to narrow it
down to this patch.

Cheers,

Richard

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


Re: [OE-core] [PATCH 4/9] dos2unix.bbclass: Move to oe-core

2018-08-20 Thread Martin Hundebøll

Hi Khem,

On 19/08/2018 19.23, Khem Raj wrote:

- Import from meta-oe layer

- This is useful for many packages where CR-LF
   needs to be adjusted, many recipes depend on it
   e.g. meta-multimedia libebml and so on.

Signed-off-by: Khem Raj 
---
  meta/classes/dos2unix.bbclass | 14 ++
  1 file changed, 14 insertions(+)
  create mode 100644 meta/classes/dos2unix.bbclass

diff --git a/meta/classes/dos2unix.bbclass b/meta/classes/dos2unix.bbclass
new file mode 100644
index 00..3fc17e2196
--- /dev/null
+++ b/meta/classes/dos2unix.bbclass
@@ -0,0 +1,14 @@
+# Class for use to convert all CRLF line terminators to LF
+# provided that some projects are being developed/maintained
+# on Windows so they have different line terminators(CRLF) vs
+# on Linux(LF), which can cause annoying patching errors during
+# git push/checkout processes.
+
+do_convert_crlf_to_lf[depends] += "dos2unix-native:do_populate_sysroot"


Shouldn't the dos2unix recipe live in oe-core also, when a class depends 
upon it?


// Martin


+
+# Convert CRLF line terminators to LF
+do_convert_crlf_to_lf () {
+   find ${S} -type f -exec dos2unix {} \;
+}
+
+addtask convert_crlf_to_lf after do_unpack before do_patch



--
Kind regards,
Martin Hundebøll
Embedded Linux Consultant

+45 61 65 54 61
mar...@geanix.com

Geanix IVS
https://geanix.com
DK39600706
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 1/2] bitbake.conf: add PERSISTENT_LOG_DIR variable

2018-08-20 Thread Ankur Tyagi
Initially I thought of doing that but then dropped it because it would
create a dependency on syslog configuration file.
If in future syslog configuration parameter (LOGFILE) gets renamed, then we
need to make corresponding change as well.

I think creating /var/log as a link is a less dependent change.

Let me know your thoughts.

Regards
Ankur

On Mon, Aug 20, 2018 at 1:49 PM ChenQi  wrote:

> The requirement is to put logs into directories other than /var/log.
> Could it be achieved by modifying the syslog daemon configuration file
> (e.g. /etc/syslog.conf) to replace /var/log with the specified
> directory. Maybe the corresponding logrotate configuration file also
> needs to be modified.
>
> Best Regards,
> Chen Qi
>
> On 08/18/2018 08:59 AM, Ankur Tyagi wrote:
> > This variable is only respected when VOLATILE_LOG_DIR is "no".
> >
> > The default value is "" which results in the /var/log being log
> directory.
> >
> > The user could override this value to a path e.g "/home/root/log" which
> > results /var/log being a link pointing to /home/root/log directory on
> > persistent storage.
> >
> > Signed-off-by: Ankur Tyagi 
> > ---
> >   meta/conf/bitbake.conf | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index e5dc1ac..9db22c8 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -88,6 +88,8 @@ ROOT_HOME ??= "/home/root"
> >   # If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log
> links to /var/volatile/log.
> >   # If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is
> on persistent storage.
> >   VOLATILE_LOG_DIR ?= "yes"
> > +# If VOLATILE_LOG_DIR is false and PERSISTENT_LOG_DIR is set, /var/log
> links to PERSISTENT_LOG_DIR
> > +PERSISTENT_LOG_DIR ??= ""
> >
> >   ##
> >   # Architecture-dependent build variables.
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/1] cmake-native: fix to function correctly in case of eSDK

2018-08-20 Thread Chen Qi
Our eSDK is expected to provide traditional SDK's functionality. But
for cmake, it could not function well in eSDK.

This problem is discovered by the assimp.py test case. The error message
is as below.

  testsdkext/tmp/sysroots/x86_64/usr/lib/libz.so: error adding symbols: file in 
wrong format
  collect2: error: ld returned 1 exit status

The problem is about cmake-native being unable to find the correct lib.
nativesdk-cmake has solved this problem. So make use of the solution to
solve the eSDK problem.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/cmake/cmake-native_3.11.4.bb | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.11.4.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.11.4.bb
index 9f371e9..f55c519 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.11.4.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.11.4.bb
@@ -3,7 +3,12 @@ inherit native
 
 DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native 
curl-native"
 
-SRC_URI += 
"file://0004-Disable-use-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch"
+SRC_URI += 
"file://0004-Disable-use-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch \
+file://OEToolchainConfig.cmake \
+file://environment.d-cmake.sh \
+
file://0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch \
+"
+
 
 B = "${WORKDIR}/build"
 do_configure[cleandirs] = "${B}"
@@ -31,6 +36,15 @@ do_compile() {
 
 do_install() {
oe_runmake 'DESTDIR=${D}' install
+
+   # The following codes are here because eSDK needs to provide 
compatibilty
+   # for SDK. That is, eSDK could also be used like traditional SDK.
+   mkdir -p ${D}${datadir}/cmake
+   install -m 644 ${WORKDIR}/OEToolchainConfig.cmake ${D}${datadir}/cmake/
+   mkdir -p ${D}${base_prefix}/environment-setup.d
+   install -m 644 ${WORKDIR}/environment.d-cmake.sh 
${D}${base_prefix}/environment-setup.d/cmake.sh
 }
 
 do_compile[progress] = "percent"
+
+SYSROOT_DIRS_NATIVE += "${datadir}/cmake ${base_prefix}/environment-setup.d"
-- 
1.9.1

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


[OE-core] [PATCH 0/1] cmake-native: fix to function correctly in case of eSDK

2018-08-20 Thread Chen Qi
*** BLURB HERE ***
The following changes since commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f:

  kernel-devsrc: restructure for out of tree (and on target) module builds 
(2018-08-19 16:35:22 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/cmake-esdk
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/cmake-esdk

Chen Qi (1):
  cmake-native: fix to function correctly in case of eSDK

 meta/recipes-devtools/cmake/cmake-native_3.11.4.bb | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

-- 
1.9.1

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


Re: [OE-core] [PATCH] classes/package: Clean up getstatusoutput

2018-08-20 Thread richard . purdie
On Sun, 2018-08-19 at 21:43 -0500, Joshua Watt wrote:
> Replaces usage of the deprecated oe.utils.getstatusoutput() with Python
> subprocess calls.
> 
> Signed-off-by: Joshua Watt 
> ---
>  meta/classes/package.bbclass | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index 4ce9de2f573..b05d2858281 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -380,6 +380,7 @@ def splitdebuginfo(file, dvar, debugdir, debuglibdir, 
> debugappend, debugsrcdir,
>  # sourcefile is also generated containing a list of debugsources
>  
>  import stat
> +import subprocess
>  
>  src = file[len(dvar):]
>  dest = debuglibdir + os.path.dirname(src) + debugdir + "/" + 
> os.path.basename(src) + debugappend
> @@ -409,16 +410,18 @@ def splitdebuginfo(file, dvar, debugdir, debuglibdir, 
> debugappend, debugsrcdir,
>  
>  bb.utils.mkdirhier(os.path.dirname(debugfile))
>  
> -cmd = "'%s' --only-keep-debug '%s' '%s'" % (objcopy, file, debugfile)
> -(retval, output) = oe.utils.getstatusoutput(cmd)
> -if retval:
> -bb.fatal("objcopy failed with exit code %s (cmd was %s)%s" % 
> (retval, cmd, ":\n%s" % output if output else ""))
> +cmd = (objcopy, '--only-keep-debug', file, debugfile)
> +try:
> +subprocess.check_output(cmd)
> +except subprocess.CalledProcessError as e:
> +bb.fatal("objcopy failed with exit code %s (cmd was %s)%s" % 
> (e.returncode, ' '.join(cmd), ":\n%s" % output.decode('utf-8') if e.output 
> else ""))
>  
>  # Set the debuglink to have the view of the file path on the target
> -cmd = "'%s' --add-gnu-debuglink='%s' '%s'" % (objcopy, debugfile, file)
> -(retval, output) = oe.utils.getstatusoutput(cmd)
> -if retval:
> -bb.fatal("objcopy failed with exit code %s (cmd was %s)%s" % 
> (retval, cmd, ":\n%s" % output if output else ""))
> +cmd = (objcopy, '--add-gnu-debuglink', debugfile, file)
> +try:
> +subprocess.check_output(cmd)
> +except subprocess.CalledProcessError as e:
> +bb.fatal("objcopy failed with exit code %s (cmd was %s)%s" % 
> (e.returncode, ' '.join(cmd), ":\n%s" % output.decode('utf-8') if e.output 
> else ""))
>  
>  if newmode:
>  os.chmod(file, origmode)

I appreciate this is a direct replacement and functionally equivalent
but are these custom exceptions any real use? Its hard to actually get
them right and I suspect we may be better off without them using the
standard formatter?

Cheers,

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


[OE-core] [PATCH v3] rootfs-postcommands: put image testdata under sstate control

2018-08-20 Thread André Draszik
From: André Draszik 

The testdata.json is being written to DEPLOY_DIR_IMAGE directly,
thus bypassing sstate, which results in an ever growing list
of files.

Write them to IMGDEPLOYDIR instead, so as to benefit from the
automatic management via sstate.

Signed-off-by: André Draszik 

---
v3: rebased
v2: fix typo in subject line
---
 meta/classes/rootfs-postcommands.bbclass | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index ca690a6e59..e816824f28 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -316,17 +316,18 @@ rootfs_sysroot_relativelinks () {
 python write_image_test_data() {
 from oe.data import export2json
 
-testdata = "%s/%s.testdata.json" % (d.getVar('DEPLOY_DIR_IMAGE'), 
d.getVar('IMAGE_NAME'))
-testdata_link = "%s/%s.testdata.json" % (d.getVar('DEPLOY_DIR_IMAGE'), 
d.getVar('IMAGE_LINK_NAME'))
+deploy_dir = d.getVar('IMGDEPLOYDIR')
+link_name = d.getVar('IMAGE_LINK_NAME')
+testdata_name = os.path.join(deploy_dir, "%s.testdata.json" % 
d.getVar('IMAGE_NAME'))
 
-bb.utils.mkdirhier(os.path.dirname(testdata))
 searchString = "%s/"%(d.getVar("TOPDIR")).replace("//","/")
-export2json(d, testdata,searchString=searchString,replaceString="")
+export2json(d, testdata_name, searchString=searchString, replaceString="")
 
-if testdata_link != testdata:
+if os.path.exists(testdata_name):
+testdata_link = os.path.join(deploy_dir, "%s.testdata.json" % 
link_name)
 if os.path.lexists(testdata_link):
-   os.remove(testdata_link)
-os.symlink(os.path.basename(testdata), testdata_link)
+os.remove(testdata_link)
+os.symlink(os.path.basename(testdata_name), testdata_link)
 }
 write_image_test_data[vardepsexclude] += "TOPDIR"
 
-- 
2.18.0

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