[OE-core] [PATCH V2] ruby: Remove __has_include and __has_include_next from preprocessed header file

[Khem Raj]

one of the build steps ruby has is that it generated rb_mjit_header.h
during configure using gcc preprocessor using -dD which emits built-in
defines as well, problem happens when this header is later included in
subsequent compiles, where compiler errors out stating that an existing
internal define is redefined

| /tmp/20200123-2021083-2c601q.h:13849:9: error: "__has_include" cannot be used 
as a macro name
| 13849 | #define __has_include __has_include
|   | ^
| compilation terminated due to -Wfatal-errors.

Since compiler already will take care of it internally we can edit it
out from this header file

Signed-off-by: Khem Raj 
---
v2: Patch makefile instead of running it pre-compile, since this file
can be regenerated during do_compile

 .../ruby/ruby/remove_has_include_macros.patch | 26 +++
 meta/recipes-devtools/ruby/ruby_2.6.5.bb  |  1 +
 2 files changed, 27 insertions(+)
 create mode 100644 
meta/recipes-devtools/ruby/ruby/remove_has_include_macros.patch

diff --git a/meta/recipes-devtools/ruby/ruby/remove_has_include_macros.patch 
b/meta/recipes-devtools/ruby/ruby/remove_has_include_macros.patch
new file mode 100644
index 00..a1e6330445
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/remove_has_include_macros.patch
@@ -0,0 +1,26 @@
+Filter out __has_include* compiler defines
+
+They are internal to compiler and this header is later on includes in C
+files, but newer gcc >= 10 complains about it.
+
+error in initial header file:
+| In file included from /tmp/20200124-86625-14hiju4.c:1:
+| /tmp/20200124-86625-11y6l6i.h:13849:9: error: "__has_include" cannot be used 
as a macro name
+| 13849 | #define __has_include __has_include
+|   | ^
+| compilation terminated due to -Wfatal-errors.
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+
+--- a/common.mk
 b/common.mk
+@@ -221,6 +221,8 @@ $(TIMESTAMPDIR)/$(MJIT_HEADER:.h=)$(MJIT
+   $(TIMESTAMPDIR)/$(arch)/.time
+   $(ECHO) building $(@F:.time=.h)
+   $(Q) $(CPP) -DMJIT_HEADER $(MJIT_HEADER_FLAGS) $(CFLAGS) $(XCFLAGS) 
$(CPPFLAGS) $(srcdir)/vm.c $(CPPOUTFLAG)$(@F:.time=.h).new
++  $(Q)sed -i -e "/#define __has_include __has_include/d" 
$(@F:.time=.h).new
++  $(Q)sed -i -e "/#define __has_include_next __has_include_next/d" 
$(@F:.time=.h).new
+   $(Q) $(IFCHANGE) "--timestamp=$@" $(@F:.time=.h) $(@F:.time=.h).new
+ 
+ $(MJIT_HEADER:.h=)$(MJIT_HEADER_SUFFIX).h: 
$(TIMESTAMPDIR)/$(MJIT_HEADER:.h=)$(MJIT_HEADER_SUFFIX).time
diff --git a/meta/recipes-devtools/ruby/ruby_2.6.5.bb 
b/meta/recipes-devtools/ruby/ruby_2.6.5.bb
index 1828f65d51..0cdf6ee09f 100644
--- a/meta/recipes-devtools/ruby/ruby_2.6.5.bb
+++ b/meta/recipes-devtools/ruby/ruby_2.6.5.bb
@@ -2,6 +2,7 @@ require ruby.inc
 
 SRC_URI += " \

file://0003-configure.ac-check-finite-isinf-isnan-as-macros-firs.patch \
+   file://remove_has_include_macros.patch \
file://run-ptest \
"
 
-- 
2.25.0

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

[OE-core] [PATCH v3] logrotate.py: improve oeqa test implementation

[Trevor Gamblin]

From: Trevor Gamblin 

See bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632

Autobuilder tests occasionally fail, reporting that a new logfile
could not be created. While this failure did occur multiple times, it
could not be manually reproduced. However, there are issues with the
implementation of the logrotate.py script that can be fixed. These
changes will help make the failures clearer, should they continue to
occur.

Previously, the test_2_logrotate test would, after running the
logrotate tool, use "ls -al $HOME/logrotate_dir | wc -l" to count
the number of files in the rotation directory and determine if the
rotation was successful. The test to see if there are at least three
files is problematic, because depending on the version of ls used, it
may report the target value of 3 even when there are only hidden files
in the directory, potentially reporting a pass for the test when it
should actually fail. An example with coreutils:

root@qemux86-64:~# ls -al emptydir/
total 2
drwxr-xr-x 2 root root 1024 Jan 14 19:50 .
drwx-- 3 root root 1024 Jan 14 19:50 ..
root@qemux86-64:~#

Where "total" is the number of blocks used. Compare with busybox ls:

root@qemux86-64:~# ls -al emptydir/
drwxr-xr-x2 root root  1024 Jan 14 19:54 .
drwx--3 root root  1024 Jan 14 19:54 ..
root@qemux86-64:~#

Instead of using ls to verify that a certain number of files exists
in $HOME/logrotate_dir, the tests have been changed to rotate two
specific logs: the log for wtmp and a new logrotate_testfile created
during the second test. Both tests check that the logs are correctly
rotated into $HOME/logrotate_dir by using find and grep on the
expected filename (e.g. "wtmp" when rotated becomes "wtmp.1", so we
check to see that wtmp.1 is present in $HOME/logrotate_dir). In
addition, should the test fail, the output from logrotate -vf is
included in the test log to aid debugging. It has also been seen that
in some cases, the logrotate test fails because the /var/log/wtmp file
is not yet present. Since the objective of the test is to check the
logrotate functionality and not the presence of certain log files,
test_logrotate_wtmp uses the touch command to help ensure that the
file is present before the call to logrotate is issued.

Finally, note that while the autobuilder failures that this patch
addresses were only seen during core-image-full-cmdline tests, these
changes were successfully tested on core-image-minimal and
core-image-sato with the manual addition of logrotate and openssh-sshd
to the images.

Signed-off-by: Trevor Gamblin 
---
 meta/lib/oeqa/runtime/cases/logrotate.py | 62 +---
 1 file changed, 44 insertions(+), 18 deletions(-)

diff --git a/meta/lib/oeqa/runtime/cases/logrotate.py 
b/meta/lib/oeqa/runtime/cases/logrotate.py
index bfa57c534a..3938e91993 100644
--- a/meta/lib/oeqa/runtime/cases/logrotate.py
+++ b/meta/lib/oeqa/runtime/cases/logrotate.py
@@ -18,32 +18,58 @@ class LogrotateTest(OERuntimeTestCase):
 @classmethod
 def tearDownClass(cls):
 cls.tc.target.run('mv -f $HOME/wtmp.oeqabak /etc/logrotate.d/wtmp && 
rm -rf $HOME/logrotate_dir')
+cls.tc.target.run('rm -rf /var/log/logrotate_testfile && rm -rf 
/etc/logrotate.d/logrotate_testfile')
 
 @OETestDepends(['ssh.SSHTest.test_ssh'])
 @OEHasPackage(['logrotate'])
-def test_1_logrotate_setup(self):
+def test_logrotate_wtmp(self):
+
+# /var/log/wtmp may not always exist initially, so use touch to ensure 
it is present
+status, output = self.target.run('touch /var/log/wtmp')
+msg = ('Could not create/update /var/log/wtmp with touch')
+self.assertEqual(status, 0, msg = msg)
+
 status, output = self.target.run('mkdir $HOME/logrotate_dir')
-msg = 'Could not create logrotate_dir. Output: %s' % output
+msg = ('Could not create logrotate_dir. Output: %s' % output)
+self.assertEqual(status, 0, msg = msg)
+
+status, output = self.target.run('echo "create \n olddir 
$HOME/logrotate_dir \n include /etc/logrotate.d/wtmp" > 
/tmp/logrotate-test.conf')
+msg = ('Could not write to /tmp/logrotate-test.conf')
+self.assertEqual(status, 0, msg = msg)
+
+status, output = self.target.run('echo "/var/log/logrotate_test {\\n 
missingok \\n monthly \\n rotate 1" > /etc/logrotate.d/logrotate_test')
+msg = ('Could not write to /etc/logrotate.d/logrotate_test')
+self.assertEqual(status, 0, msg = msg)
+
+# If logrotate fails to rotate the log, view the verbose output of 
logrotate to see what prevented it
+_, logrotate_output = self.target.run('logrotate -vf 
/tmp/logrotate-test.conf')
+status, _ = self.target.run('find $HOME/logrotate_dir -type f | grep 
wtmp.1')
+msg = ("logrotate did not successfully rotate the wtmp log. Output 
from logrotate -vf: \n%s" % (logrotate_output))
+self.assertEqual(status, 0, msg = msg)
+  

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[akuster808]

On 1/23/20 2:17 PM, Ross Burton wrote:
> On 23/01/2020 21:43, Bruce Ashfield wrote:
>> On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko 
>> wrote:
>>>
>>> From: Denys Dmytriyenko 
>>>
>>> Many BSPs require ARM Trusted Firmware (also known as Trusted
>>> Firmware-A).
>>> To avoid duplicating efforts of adding very similar recipes to BSP
>>> layers,
>>> add an upstream reference implementation to openembedded-core, which
>>> can be
>>> customized by BSPs, if needed.
>>
>> Isn't this one of the things that Jon Mason is trying to
>> standardize/support in meta-arm ?
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a
>>
>>
>> What's the delta between the two ?
>
> That was precisely my thought too.  meta-arm isn't exactly well known
> right now, but ideally it should be a central place for common pieces
> that are specific to ARM hardware (unlike anything that is needed for
> qemuarm itself).

Per meta-arm's README:

|meta-arm:
This layer provides support for general recipes for the Arm architecture.
Anything that's not needed explicitly for BSPs, the IOTA distribution,
or destined to be upstreamed belongs here.


So does that package belong in meta-arm based on what Arm is trying to do?

- armin

|




> Ross

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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Richard Purdie]

On Thu, 2020-01-23 at 22:17 +, Ross Burton wrote:
> On 23/01/2020 21:43, Bruce Ashfield wrote:
> > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko 
> > wrote:
> > > From: Denys Dmytriyenko 
> > > 
> > > Many BSPs require ARM Trusted Firmware (also known as Trusted
> > > Firmware-A).
> > > To avoid duplicating efforts of adding very similar recipes to
> > > BSP layers,
> > > add an upstream reference implementation to openembedded-core,
> > > which can be
> > > customized by BSPs, if needed.
> > 
> > Isn't this one of the things that Jon Mason is trying to
> > standardize/support in meta-arm ?
> > 
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a
> > 
> > What's the delta between the two ?
> 
> That was precisely my thought too.  meta-arm isn't exactly well known 
> right now, but ideally it should be a central place for common pieces 
> that are specific to ARM hardware (unlike anything that is needed for 
> qemuarm itself).

If its needed by many platforms, I'm not adverse to it being in core so
I have an open mind on core vs. meta-arm. I'm waiting to see what Jon's
thoughts are on that.

Cheers,

Richard

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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Denys Dmytriyenko]

On Thu, Jan 23, 2020 at 02:39:52PM -0800, Andre McCurdy wrote:
> On Thu, Jan 23, 2020 at 2:17 PM Ross Burton  wrote:
> > On 23/01/2020 21:43, Bruce Ashfield wrote:
> > > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:
> > >>
> > >> From: Denys Dmytriyenko 
> > >>
> > >> Many BSPs require ARM Trusted Firmware (also known as Trusted 
> > >> Firmware-A).
> > >> To avoid duplicating efforts of adding very similar recipes to BSP 
> > >> layers,
> > >> add an upstream reference implementation to openembedded-core, which can 
> > >> be
> > >> customized by BSPs, if needed.
> > >
> > > Isn't this one of the things that Jon Mason is trying to
> > > standardize/support in meta-arm ?
> > >
> > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a
> > >
> > > What's the delta between the two ?
> >
> > That was precisely my thought too.  meta-arm isn't exactly well known
> > right now, but ideally it should be a central place for common pieces
> > that are specific to ARM hardware (unlike anything that is needed for
> > qemuarm itself).
> 
> Such as all the various cortex etc CPU tuning files?

LOL! :) Of course, since ARM is such an inferior arch to x86. Otherwise we 
should move everything that is not needed by qemux86 to meta-intel... JK :)

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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Andre McCurdy]

On Thu, Jan 23, 2020 at 2:17 PM Ross Burton  wrote:
> On 23/01/2020 21:43, Bruce Ashfield wrote:
> > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:
> >>
> >> From: Denys Dmytriyenko 
> >>
> >> Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> >> To avoid duplicating efforts of adding very similar recipes to BSP layers,
> >> add an upstream reference implementation to openembedded-core, which can be
> >> customized by BSPs, if needed.
> >
> > Isn't this one of the things that Jon Mason is trying to
> > standardize/support in meta-arm ?
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a
> >
> > What's the delta between the two ?
>
> That was precisely my thought too.  meta-arm isn't exactly well known
> right now, but ideally it should be a central place for common pieces
> that are specific to ARM hardware (unlike anything that is needed for
> qemuarm itself).

Such as all the various cortex etc CPU tuning files?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] meson: update 0.52.1 -> 0.53.0

[Khem Raj]

On Thu, Jan 23, 2020 at 1:43 PM Alexander Kanavin
 wrote:
>
> I once more suggest we deal with all those special cases where linker 
> customization is desired later on. New meson isn’t going to work without this 
> change.
>
Perhaps I am missing something, what does new version gets us that we
could be willing to accept a regression?
 People are already using ld-is-gold in DISTRO_FEATURES

> Alex
>
> > On 23 Jan 2020, at 20.27, Khem Raj  wrote:
> >
> > On Thu, Jan 23, 2020 at 9:34 AM Alexander Kanavin
> >  wrote:
> >>
> >> Signed-off-by: Alexander Kanavin 
> >> ---
> >> meta/classes/meson.bbclass   |  9 -
> >> meta/recipes-devtools/meson/meson.inc|  4 ++--
> >> .../0001-Make-CPU-family-warnings-fatal.patch| 12 ++--
> >> ...-do-not-manipulate-the-environment-when.patch | 16 
> >> ...-Support-building-allarch-recipes-again.patch |  6 +++---
> >> .../meson/meson/0003-native_bindir.patch | 16 
> >> .../meson/{meson_0.52.1.bb => meson_0.53.0.bb}   |  0
> >> ...meson_0.52.1.bb => nativesdk-meson_0.53.0.bb} |  2 +-
> >> 8 files changed, 36 insertions(+), 29 deletions(-)
> >> rename meta/recipes-devtools/meson/{meson_0.52.1.bb => meson_0.53.0.bb} 
> >> (100%)
> >> rename meta/recipes-devtools/meson/{nativesdk-meson_0.52.1.bb => 
> >> nativesdk-meson_0.53.0.bb} (99%)
> >>
> >> diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> >> index 1ef34a999c8..1837c9468e6 100644
> >> --- a/meta/classes/meson.bbclass
> >> +++ b/meta/classes/meson.bbclass
> >> @@ -85,13 +85,16 @@ addtask write_config before do_configure
> >> do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS CXXFLAGS 
> >> LDFLAGS"
> >> do_write_config() {
> >> # This needs to be Py to split the args into single-element lists
> >> +
> >> +# Meson requires ld to be 'bfd, 'lld' or 'gold' from 0.53 onwards
> >> +# 
> >> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
> >> cat >${WORKDIR}/meson.cross < >> [binaries]
> >> c = ${@meson_array('CC', d)}
> >> cpp = ${@meson_array('CXX', d)}
> >> ar = ${@meson_array('AR', d)}
> >> nm = ${@meson_array('NM', d)}
> >> -ld = ${@meson_array('LD', d)}
> >> +ld = 'bfd'
> >
> > there has to be a way to define it based on DISTRO_FEATURES containing
> > ld-is-gold
> > or ld-is-lld and perhaps also if someone adds
> >
> > LDFLAGS += "-fuse-ld="
> >
> > should work too. I am not sure if all these cases function if we make
> > this change.
> >
> >> strip = ${@meson_array('STRIP', d)}
> >> readelf = ${@meson_array('READELF', d)}
> >> pkgconfig = 'pkg-config'
> >> @@ -122,6 +125,10 @@ EOF
> >> CONFIGURE_FILES = "meson.build"
> >>
> >> meson_do_configure() {
> >> +# Meson requires this to be 'bfd, 'lld' or 'gold' from 0.53 onwards
> >> +# 
> >> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
> >> +unset LD
> >> +
> >> # Work around "Meson fails if /tmp is mounted with noexec #2972"
> >> mkdir -p "${B}/meson-private/tmp"
> >> export TMPDIR="${B}/meson-private/tmp"
> >> diff --git a/meta/recipes-devtools/meson/meson.inc 
> >> b/meta/recipes-devtools/meson/meson.inc
> >> index 881a14c7f0a..c0ce7d338bc 100644
> >> --- a/meta/recipes-devtools/meson/meson.inc
> >> +++ b/meta/recipes-devtools/meson/meson.inc
> >> @@ -17,8 +17,8 @@ SRC_URI = 
> >> "https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> >>
> >> file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \
> >>
> >> file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
> >>"
> >> -SRC_URI[sha256sum] = 
> >> "0c277472e49950a5537e3de3e60c57b80dbf425788470a1a8ed27446128fc035"
> >> -SRC_URI[md5sum] = "a5f0c99567d772508f649a28ded7f8ad"
> >> +SRC_URI[sha256sum] = 
> >> "035e75993ab6fa6c9ebf902b835c64cf397a763eb8e65c9bb6e1cc9730a9d3f6"
> >> +SRC_URI[md5sum] = "3a0313d040ded973d84cbec368c2e1d3"
> >>
> >> SRC_URI_append_class-native = " \
> >> file://0001-Make-CPU-family-warnings-fatal.patch \
> >> diff --git 
> >> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> >>  
> >> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> >> index d4264cee526..74d5b4ca66e 100644
> >> --- 
> >> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> >> +++ 
> >> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> >> @@ -1,4 +1,4 @@
> >> -From cd980c763f11cfd928255346cc7e86f24add985e Mon Sep 17 00:00:00 2001
> >> +From 8ce7a1ddbc9b7775568a98fcd50e39a01513c902 Mon Sep 17 00:00:00 2001
> >> From: Ross Burton 
> >> Date: Tue, 3 Jul 2018 13:59:09 +0100
> >> Subject: [PATCH] Make CPU family warnings fatal
> >> @@ -12,10 +12,10 @@ Signed-off-by: Ross Burton 
> >>  2 files changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/mesonbuild/envconfig.py 

[OE-core] [PATCH] module.bbclass: swap AR and LD order

[Jason Wessel]

The 5.x kernels seem to have made a change to the linker command line 
processing.

When trying to build out of tree kernel modules, such as the
virtualbox guest additions, the following error is printed:

| make[1]: Entering directory 
'/opt/build-x86-64/tmp/work/qemux86_64-poky-linux/vboxguestdrivers/6.1.2-r0/vbox_module/vboxvideo'
| make[3]: Entering directory 
'/opt/build-x86-64/tmp/work-shared/qemux86-64/kernel-build-artifacts'
| make V= CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C 
/opt/build-x86-64/tmp/work/qemux86_64-poky-linux/vboxguestdrivers/6.1.2-r0/5.2.28-yocto-standard/build
 
M=/opt/build-x86-64/tmp/work/qemux86_64-poky-linux/vboxguestdrivers/6.1.2-r0/vbox_module/vboxguest
 
SRCROOT=/opt/build-x86-64/tmp/work/qemux86_64-poky-linux/vboxguestdrivers/6.1.2-r0/vbox_module/vboxguest
 modules
| make[3]: Entering directory 
'/opt/build-x86-64/tmp/work-shared/qemux86-64/kernel-build-artifacts'
|   LD [M]  
/opt/build-x86-64/tmp/work/qemux86_64-poky-linux/vboxguestdrivers/6.1.2-r0/vbox_module/vboxvideo/vboxvideo.o
| x86_64-poky-linux-ld.bfd: cannot find AR=x86_64-poky-linux-ar: No such file 
or directory

The AR arguments passed to the make command are being processed as
command line arguments to the linker due to some changes in the
kernel's Makefile.  For now the easiest fix is to just swap the
arguments in the module.bbclass.

Signed-off-by: Jason Wessel 
---
 meta/classes/module.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index c0dfa35061..e1e5fdaa72 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -38,8 +38,7 @@ module_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
   KERNEL_VERSION=${KERNEL_VERSION}\
-  CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
-  AR="${KERNEL_AR}" \
+  CC="${KERNEL_CC}" AR="${KERNEL_AR}" LD="${KERNEL_LD}" \
   O=${STAGING_KERNEL_BUILDDIR} \
   KBUILD_EXTRA_SYMBOLS="${KBUILD_EXTRA_SYMBOLS}" \
   ${MAKE_TARGETS}
-- 
2.23.0

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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Ross Burton]

On 23/01/2020 21:43, Bruce Ashfield wrote:

On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:


From: Denys Dmytriyenko 

Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
To avoid duplicating efforts of adding very similar recipes to BSP layers,
add an upstream reference implementation to openembedded-core, which can be
customized by BSPs, if needed.


Isn't this one of the things that Jon Mason is trying to
standardize/support in meta-arm ?

http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a

What's the delta between the two ?


That was precisely my thought too.  meta-arm isn't exactly well known 
right now, but ideally it should be a central place for common pieces 
that are specific to ARM hardware (unlike anything that is needed for 
qemuarm itself).


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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Denys Dmytriyenko]

On Thu, Jan 23, 2020 at 04:10:33PM -0600, Joshua Watt wrote:
> 
> On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:
> >On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> >>On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:
> >>>From: Denys Dmytriyenko 
> >>>
> >>>Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> >>>To avoid duplicating efforts of adding very similar recipes to BSP layers,
> >>>add an upstream reference implementation to openembedded-core, which can be
> >>>customized by BSPs, if needed.
> >>Isn't this one of the things that Jon Mason is trying to
> >>standardize/support in meta-arm ?
> >>
> >>http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a
> >Ah, interesting, somehow I totally missed that one! :)
> >
> >What triggered this submission is that we have our own variant in meta-ti and
> >Joshua Watt was adding a very similar one to meta-rockchip:
> >https://lists.yoctoproject.org/g/yocto/topic/70054501#48116
> 
> FWIW, variants of this recipe crop up in pretty much every ARM-based
> BSP layer (e.g. 
> https://github.com/alistair23/meta-pine64/blob/master/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.1.bb);
> it seems common enough that a base recipe that each BSP layer can
> bbappend to suite their needs seems like it would be useful?

Yes, indeed, hence we agreed to submit it to oe-core...

And meta-arm sounds like a good idea and can be used by all those ARM-based 
BSPs as a base, but for some reason I cannot find any announcements for that 
new layer... Jon?

-- 
Denys


> >>What's the delta between the two ?
> >Hmm, that one uses older 2.1 version. Other than that, I'll need to test to
> >see if it's as adaptable and expandable as our more simplistic variants...
> >
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Bruce Ashfield]

On Thu, Jan 23, 2020 at 5:05 PM Denys Dmytriyenko  wrote:
>
> On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:
> > >
> > > From: Denys Dmytriyenko 
> > >
> > > Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> > > To avoid duplicating efforts of adding very similar recipes to BSP layers,
> > > add an upstream reference implementation to openembedded-core, which can 
> > > be
> > > customized by BSPs, if needed.
> >
> > Isn't this one of the things that Jon Mason is trying to
> > standardize/support in meta-arm ?
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a
>
> Ah, interesting, somehow I totally missed that one! :)
>

It hasn't been there that long, and I was talking to Jon about it at
the various conferences late last year, otherwise, I wouldn't have
known either.

> What triggered this submission is that we have our own variant in meta-ti and
> Joshua Watt was adding a very similar one to meta-rockchip:
> https://lists.yoctoproject.org/g/yocto/topic/70054501#48116
>
>
> > What's the delta between the two ?
>
> Hmm, that one uses older 2.1 version. Other than that, I'll need to test to
> see if it's as adaptable and expandable as our more simplistic variants...

Sounds like a good plan.

Cheers,

Bruce

>
> --
> Denys
>
>
> > > Signed-off-by: Denys Dmytriyenko 
> > > Cc: Joshua Watt 
> > > ---
> > >  .../arm-trusted-firmware_2.2.bb| 55 
> > > ++
> > >  1 file changed, 55 insertions(+)
> > >  create mode 100644 
> > > meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
> > >
> > > diff --git 
> > > a/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb 
> > > b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
> > > new file mode 100644
> > > index 000..3079a70
> > > --- /dev/null
> > > +++ b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
> > > @@ -0,0 +1,55 @@
> > > +SUMMARY = "ARM Trusted Firmware"
> > > +DESCRIPTION = "ARM Trusted Firmware provides a reference implementation 
> > > of \
> > > +Secure World software for ARMv8-A, including Exception Level 3 (EL3) 
> > > software. \
> > > +It provides implementations of various ARM interface standards such as 
> > > the \
> > > +Power State Coordination Interface (PSCI), Trusted Board Boot 
> > > Requirements \
> > > +(TBBR) and Secure monitor code."
> > > +HOMEPAGE = 
> > > "http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/CJHIDGJF.html;
> > > +
> > > +LICENSE = "BSD-3-Clause"
> > > +LIC_FILES_CHKSUM = 
> > > "file://docs/license.rst;md5=189505435dbcdcc8caa63c46fe93fa89"
> > > +
> > > +inherit deploy
> > > +
> > > +DEPENDS = "dtc-native openssl-native"
> > > +
> > > +PACKAGE_ARCH = "${MACHINE_ARCH}"
> > > +
> > > +S = "${WORKDIR}/git"
> > > +B = "${WORKDIR}/build"
> > > +
> > > +BRANCH = "master"
> > > +SRC_URI = 
> > > "git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git;protocol=http;branch=${BRANCH}"
> > > +SRCREV = "a04808c16cfc126d9fe572ae7c4b5a3d39de5796"
> > > +
> > > +ATF_BINARY ??= "bl31"
> > > +ATF_SUFFIX ??= "bin"
> > > +ATF_TARGET ??= "all"
> > > +
> > > +CFLAGS[unexport] = "1"
> > > +LDFLAGS[unexport] = "1"
> > > +AS[unexport] = "1"
> > > +LD[unexport] = "1"
> > > +
> > > +do_configure[noexec] = "1"
> > > +
> > > +EXTRA_OEMAKE = '-C ${S} BUILD_BASE=${B} DEBUG=0 
> > > CROSS_COMPILE="${TARGET_PREFIX}" \
> > > +   PLAT="${ATF_PLATFORM}" TARGET_BOARD="${ATF_BOARD}" 
> > > ${PACKAGECONFIG_CONFARGS}'
> > > +
> > > +do_compile() {
> > > +   oe_runmake ${ATF_TARGET}
> > > +}
> > > +
> > > +do_install() {
> > > +   install -d ${D}/boot
> > > +   install -m 0644 
> > > ${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} 
> > > ${D}/boot/
> > > +}
> > > +
> > > +do_deploy() {
> > > +   install -d ${DEPLOYDIR}
> > > +   install -m 0644 
> > > ${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} 
> > > ${DEPLOYDIR}/
> > > +}
> > > +addtask deploy before do_build after do_compile
> > > +
> > > +FILES_${PN} = "/boot"
> > > +SYSROOT_DIRS += "/boot"
> > > --
> > > 2.7.4
> > >
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >



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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Bruce Ashfield]

On Thu, Jan 23, 2020 at 5:10 PM Joshua Watt  wrote:
>
>
> On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:
> > On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> >> On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:
> >>> From: Denys Dmytriyenko 
> >>>
> >>> Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> >>> To avoid duplicating efforts of adding very similar recipes to BSP layers,
> >>> add an upstream reference implementation to openembedded-core, which can 
> >>> be
> >>> customized by BSPs, if needed.
> >> Isn't this one of the things that Jon Mason is trying to
> >> standardize/support in meta-arm ?
> >>
> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a
> > Ah, interesting, somehow I totally missed that one! :)
> >
> > What triggered this submission is that we have our own variant in meta-ti 
> > and
> > Joshua Watt was adding a very similar one to meta-rockchip:
> > https://lists.yoctoproject.org/g/yocto/topic/70054501#48116
>
> FWIW, variants of this recipe crop up in pretty much every ARM-based BSP
> layer (e.g.
> https://github.com/alistair23/meta-pine64/blob/master/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.1.bb);
> it seems common enough that a base recipe that each BSP layer can
> bbappend to suite their needs seems like it would be useful?

Jon had some ideas about that, but I admit to only being an interested
party and since I was aware of what he was up to, that I'd draw him
into the conversation.

Definitely a good thing to get some sort of centralized base recipe,
that can be extended by layers.

Bruce

>
> >
> >
> >> What's the delta between the two ?
> > Hmm, that one uses older 2.1 version. Other than that, I'll need to test to
> > see if it's as adaptable and expandable as our more simplistic variants...
> >



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

Re: [OE-core] [PATCH 1/3] packagegroup-base: only pull in dosfstools if licensing allows

[Ross Burton]

On 23/01/2020 19:49, Andre McCurdy wrote:

Should this be using incompatible_license_contains() instead of
bb.utils.contains()?


Yes, it should.  Thanks for reminding me of that function.

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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Joshua Watt]

On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:

On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:

On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:

From: Denys Dmytriyenko 

Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
To avoid duplicating efforts of adding very similar recipes to BSP layers,
add an upstream reference implementation to openembedded-core, which can be
customized by BSPs, if needed.

Isn't this one of the things that Jon Mason is trying to
standardize/support in meta-arm ?

http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a

Ah, interesting, somehow I totally missed that one! :)

What triggered this submission is that we have our own variant in meta-ti and
Joshua Watt was adding a very similar one to meta-rockchip:
https://lists.yoctoproject.org/g/yocto/topic/70054501#48116


FWIW, variants of this recipe crop up in pretty much every ARM-based BSP 
layer (e.g. 
https://github.com/alistair23/meta-pine64/blob/master/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.1.bb); 
it seems common enough that a base recipe that each BSP layer can 
bbappend to suite their needs seems like it would be useful?






What's the delta between the two ?

Hmm, that one uses older 2.1 version. Other than that, I'll need to test to
see if it's as adaptable and expandable as our more simplistic variants...


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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Denys Dmytriyenko]

On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:
> >
> > From: Denys Dmytriyenko 
> >
> > Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> > To avoid duplicating efforts of adding very similar recipes to BSP layers,
> > add an upstream reference implementation to openembedded-core, which can be
> > customized by BSPs, if needed.
> 
> Isn't this one of the things that Jon Mason is trying to
> standardize/support in meta-arm ?
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a

Ah, interesting, somehow I totally missed that one! :)

What triggered this submission is that we have our own variant in meta-ti and 
Joshua Watt was adding a very similar one to meta-rockchip:
https://lists.yoctoproject.org/g/yocto/topic/70054501#48116


> What's the delta between the two ?

Hmm, that one uses older 2.1 version. Other than that, I'll need to test to 
see if it's as adaptable and expandable as our more simplistic variants...

-- 
Denys


> > Signed-off-by: Denys Dmytriyenko 
> > Cc: Joshua Watt 
> > ---
> >  .../arm-trusted-firmware_2.2.bb| 55 
> > ++
> >  1 file changed, 55 insertions(+)
> >  create mode 100644 
> > meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
> >
> > diff --git 
> > a/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb 
> > b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
> > new file mode 100644
> > index 000..3079a70
> > --- /dev/null
> > +++ b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
> > @@ -0,0 +1,55 @@
> > +SUMMARY = "ARM Trusted Firmware"
> > +DESCRIPTION = "ARM Trusted Firmware provides a reference implementation of 
> > \
> > +Secure World software for ARMv8-A, including Exception Level 3 (EL3) 
> > software. \
> > +It provides implementations of various ARM interface standards such as the 
> > \
> > +Power State Coordination Interface (PSCI), Trusted Board Boot Requirements 
> > \
> > +(TBBR) and Secure monitor code."
> > +HOMEPAGE = 
> > "http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/CJHIDGJF.html;
> > +
> > +LICENSE = "BSD-3-Clause"
> > +LIC_FILES_CHKSUM = 
> > "file://docs/license.rst;md5=189505435dbcdcc8caa63c46fe93fa89"
> > +
> > +inherit deploy
> > +
> > +DEPENDS = "dtc-native openssl-native"
> > +
> > +PACKAGE_ARCH = "${MACHINE_ARCH}"
> > +
> > +S = "${WORKDIR}/git"
> > +B = "${WORKDIR}/build"
> > +
> > +BRANCH = "master"
> > +SRC_URI = 
> > "git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git;protocol=http;branch=${BRANCH}"
> > +SRCREV = "a04808c16cfc126d9fe572ae7c4b5a3d39de5796"
> > +
> > +ATF_BINARY ??= "bl31"
> > +ATF_SUFFIX ??= "bin"
> > +ATF_TARGET ??= "all"
> > +
> > +CFLAGS[unexport] = "1"
> > +LDFLAGS[unexport] = "1"
> > +AS[unexport] = "1"
> > +LD[unexport] = "1"
> > +
> > +do_configure[noexec] = "1"
> > +
> > +EXTRA_OEMAKE = '-C ${S} BUILD_BASE=${B} DEBUG=0 
> > CROSS_COMPILE="${TARGET_PREFIX}" \
> > +   PLAT="${ATF_PLATFORM}" TARGET_BOARD="${ATF_BOARD}" 
> > ${PACKAGECONFIG_CONFARGS}'
> > +
> > +do_compile() {
> > +   oe_runmake ${ATF_TARGET}
> > +}
> > +
> > +do_install() {
> > +   install -d ${D}/boot
> > +   install -m 0644 
> > ${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} 
> > ${D}/boot/
> > +}
> > +
> > +do_deploy() {
> > +   install -d ${DEPLOYDIR}
> > +   install -m 0644 
> > ${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} 
> > ${DEPLOYDIR}/
> > +}
> > +addtask deploy before do_build after do_compile
> > +
> > +FILES_${PN} = "/boot"
> > +SYSROOT_DIRS += "/boot"
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> 
> -- 
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for "procps: enable optional system..." and 2 more (rev3)

[Patchwork]

== Series Details ==

Series: "procps: enable optional system..." and 2 more (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/22252/
State : failure

== Summary ==


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



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 15049c610b)

* Patch[3/3] Allow customising buildhistory tags
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for "procps: enable optional system..." and 2 more (rev4)

[Patchwork]

== Series Details ==

Series: "procps: enable optional system..." and 2 more (rev4)
Revision: 4
URL   : https://patchwork.openembedded.org/series/22252/
State : failure

== Summary ==


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



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 15049c610b)

* Patch[3/3] Allow customising buildhistory tags
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for "procps: enable optional system..." and 2 more (rev2)

[Patchwork]

== Series Details ==

Series: "procps: enable optional system..." and 2 more (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/22252/
State : failure

== Summary ==


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



* Patch[3/3] Allow customising buildhistory tags
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH v2 3/3] buildhistory: Allow customising buildhistory tags

[Dan McGregor]

From: Daniel McGregor 

Allow setting custom buildhistory tag prefixes. This allows multiple
build directories to share one buildhistory git repository with multiple
worktrees.

Signed-off-by: Daniel McGregor 
---
 meta/classes/buildhistory.bbclass | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index affdf272d7..eb7295570d 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -40,6 +40,7 @@ BUILDHISTORY_SDK_FILES ?= "conf/local.conf conf/bblayers.conf 
conf/auto.conf con
 BUILDHISTORY_COMMIT ?= "1"
 BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory "
 BUILDHISTORY_PUSH_REPO ?= ""
+BUILDHISTORY_TAG ?= "build"
 
 SSTATEPOSTINSTFUNCS_append = " buildhistory_emit_pkghistory"
 # We want to avoid influencing the signatures of sstate tasks - first the 
function itself:
@@ -824,9 +825,9 @@ END
if [ ! -e .git ] ; then
git init -q
else
-   git tag -f build-minus-3 build-minus-2 > /dev/null 2>&1 
|| true
-   git tag -f build-minus-2 build-minus-1 > /dev/null 2>&1 
|| true
-   git tag -f build-minus-1 > /dev/null 2>&1 || true
+   git tag -f ${BUILDHISTORY_TAG}-minus-3 
${BUILDHISTORY_TAG}-minus-2 > /dev/null 2>&1 || true
+   git tag -f ${BUILDHISTORY_TAG}-minus-2 
${BUILDHISTORY_TAG}-minus-1 > /dev/null 2>&1 || true
+   git tag -f ${BUILDHISTORY_TAG}-minus-1 > /dev/null 2>&1 
|| true
fi
 
check_git_config
-- 
2.24.1

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

[OE-core] [PATCH v2 2/3] cmake: prefer CMAKE_BUILD_PARALLEL_LEVEL

[Dan McGregor]

From: Daniel McGregor 

cmake 3.12 introduced this environment variable. Prefer it to passing
PARALLEL_MAKE and PARALLEL_MAKEINST on the cmake command line, because
it gets passed to second stage cmake invocations while command-line
arguments do not (for example, multi-stage clang builds)

Signed-off-by: Daniel McGregor 
---
 meta/classes/cmake.bbclass |  5 +++--
 meta/lib/oe/utils.py   | 11 +++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index a046daa6ea..d91cf20130 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -63,8 +63,9 @@ OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
 
 EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
 
-EXTRA_OECMAKE_BUILD_prepend_task-compile = "${PARALLEL_MAKE} "
-EXTRA_OECMAKE_BUILD_prepend_task-install = "${PARALLEL_MAKEINST} "
+export CMAKE_BUILD_PARALLEL_LEVEL
+CMAKE_BUILD_PARALLEL_LEVEL_task-compile = "${@oe.utils.parallel_make(d, 
False)}"
+CMAKE_BUILD_PARALLEL_LEVEL_task-install = "${@oe.utils.parallel_make(d, True)}"
 
 OECMAKE_TARGET_COMPILE ?= "all"
 OECMAKE_TARGET_INSTALL ?= "install"
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 652b2be145..e350b05ddf 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -169,7 +169,7 @@ def any_distro_features(d, features, truevalue="1", 
falsevalue=""):
 """
 return bb.utils.contains_any("DISTRO_FEATURES", features, truevalue, 
falsevalue, d)
 
-def parallel_make(d):
+def parallel_make(d, makeinst=False):
 """
 Return the integer value for the number of parallel threads to use when
 building, scraped out of PARALLEL_MAKE. If no parallelization option is
@@ -177,7 +177,10 @@ def parallel_make(d):
 
 e.g. if PARALLEL_MAKE = "-j 10", this will return 10 as an integer.
 """
-pm = (d.getVar('PARALLEL_MAKE') or '').split()
+if makeinst:
+pm = (d.getVar('PARALLEL_MAKEINST') or '').split()
+else:
+pm = (d.getVar('PARALLEL_MAKE') or '').split()
 # look for '-j' and throw other options (e.g. '-l') away
 while pm:
 opt = pm.pop(0)
@@ -192,7 +195,7 @@ def parallel_make(d):
 
 return None
 
-def parallel_make_argument(d, fmt, limit=None):
+def parallel_make_argument(d, fmt, limit=None, makeinst=False):
 """
 Helper utility to construct a parallel make argument from the number of
 parallel threads specified in PARALLEL_MAKE.
@@ -205,7 +208,7 @@ def parallel_make_argument(d, fmt, limit=None):
 e.g. if PARALLEL_MAKE = "-j 10", parallel_make_argument(d, "-n %d") will 
return
 "-n 10"
 """
-v = parallel_make(d)
+v = parallel_make(d, makeinst)
 if v:
 if limit:
 v = min(limit, v)
-- 
2.24.1

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

[OE-core] [PATCH v2 1/3] procps: enable optional systemd support

[Dan McGregor]

From: Daniel McGregor 

procps includes support for listing the owning unit of a process, but
this support is disabled by default. Enable support using
a PACKAGECONFIG that depends on the systemd DISTRO_FEATURE.

Signed-off-by: Daniel McGregor 
---
 meta/recipes-extended/procps/procps_3.3.15.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-extended/procps/procps_3.3.15.bb 
b/meta/recipes-extended/procps/procps_3.3.15.bb
index f240e54fd8..17abd96dca 100644
--- a/meta/recipes-extended/procps/procps_3.3.15.bb
+++ b/meta/recipes-extended/procps/procps_3.3.15.bb
@@ -24,6 +24,9 @@ S = "${WORKDIR}/procps-ng-${PV}"
 
 EXTRA_OECONF = "--enable-skill --disable-modern-top"
 
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
+PACKAGECONFIG[systemd] = "--with-systemd,--without-systemd,systemd"
+
 do_install_append () {
install -d ${D}${base_bindir}
[ "${bindir}" != "${base_bindir}" ] && for i in ${base_bindir_progs}; 
do mv ${D}${bindir}/$i ${D}${base_bindir}/$i; done
-- 
2.24.1

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

Re: [OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Bruce Ashfield]

On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko  wrote:
>
> From: Denys Dmytriyenko 
>
> Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> To avoid duplicating efforts of adding very similar recipes to BSP layers,
> add an upstream reference implementation to openembedded-core, which can be
> customized by BSPs, if needed.

Isn't this one of the things that Jon Mason is trying to
standardize/support in meta-arm ?

http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a

What's the delta between the two ?

Bruce

>
> Signed-off-by: Denys Dmytriyenko 
> Cc: Joshua Watt 
> ---
>  .../arm-trusted-firmware_2.2.bb| 55 
> ++
>  1 file changed, 55 insertions(+)
>  create mode 100644 
> meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
>
> diff --git 
> a/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb 
> b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
> new file mode 100644
> index 000..3079a70
> --- /dev/null
> +++ b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
> @@ -0,0 +1,55 @@
> +SUMMARY = "ARM Trusted Firmware"
> +DESCRIPTION = "ARM Trusted Firmware provides a reference implementation of \
> +Secure World software for ARMv8-A, including Exception Level 3 (EL3) 
> software. \
> +It provides implementations of various ARM interface standards such as the \
> +Power State Coordination Interface (PSCI), Trusted Board Boot Requirements \
> +(TBBR) and Secure monitor code."
> +HOMEPAGE = 
> "http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/CJHIDGJF.html;
> +
> +LICENSE = "BSD-3-Clause"
> +LIC_FILES_CHKSUM = 
> "file://docs/license.rst;md5=189505435dbcdcc8caa63c46fe93fa89"
> +
> +inherit deploy
> +
> +DEPENDS = "dtc-native openssl-native"
> +
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
> +
> +S = "${WORKDIR}/git"
> +B = "${WORKDIR}/build"
> +
> +BRANCH = "master"
> +SRC_URI = 
> "git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git;protocol=http;branch=${BRANCH}"
> +SRCREV = "a04808c16cfc126d9fe572ae7c4b5a3d39de5796"
> +
> +ATF_BINARY ??= "bl31"
> +ATF_SUFFIX ??= "bin"
> +ATF_TARGET ??= "all"
> +
> +CFLAGS[unexport] = "1"
> +LDFLAGS[unexport] = "1"
> +AS[unexport] = "1"
> +LD[unexport] = "1"
> +
> +do_configure[noexec] = "1"
> +
> +EXTRA_OEMAKE = '-C ${S} BUILD_BASE=${B} DEBUG=0 
> CROSS_COMPILE="${TARGET_PREFIX}" \
> +   PLAT="${ATF_PLATFORM}" TARGET_BOARD="${ATF_BOARD}" 
> ${PACKAGECONFIG_CONFARGS}'
> +
> +do_compile() {
> +   oe_runmake ${ATF_TARGET}
> +}
> +
> +do_install() {
> +   install -d ${D}/boot
> +   install -m 0644 
> ${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} 
> ${D}/boot/
> +}
> +
> +do_deploy() {
> +   install -d ${DEPLOYDIR}
> +   install -m 0644 
> ${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} 
> ${DEPLOYDIR}/
> +}
> +addtask deploy before do_build after do_compile
> +
> +FILES_${PN} = "/boot"
> +SYSROOT_DIRS += "/boot"
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [OE-core] [PATCH 1/5] meson: update 0.52.1 -> 0.53.0

[Alexander Kanavin]

I once more suggest we deal with all those special cases where linker 
customization is desired later on. New meson isn’t going to work without this 
change.

Alex

> On 23 Jan 2020, at 20.27, Khem Raj  wrote:
> 
> On Thu, Jan 23, 2020 at 9:34 AM Alexander Kanavin
>  wrote:
>> 
>> Signed-off-by: Alexander Kanavin 
>> ---
>> meta/classes/meson.bbclass   |  9 -
>> meta/recipes-devtools/meson/meson.inc|  4 ++--
>> .../0001-Make-CPU-family-warnings-fatal.patch| 12 ++--
>> ...-do-not-manipulate-the-environment-when.patch | 16 
>> ...-Support-building-allarch-recipes-again.patch |  6 +++---
>> .../meson/meson/0003-native_bindir.patch | 16 
>> .../meson/{meson_0.52.1.bb => meson_0.53.0.bb}   |  0
>> ...meson_0.52.1.bb => nativesdk-meson_0.53.0.bb} |  2 +-
>> 8 files changed, 36 insertions(+), 29 deletions(-)
>> rename meta/recipes-devtools/meson/{meson_0.52.1.bb => meson_0.53.0.bb} 
>> (100%)
>> rename meta/recipes-devtools/meson/{nativesdk-meson_0.52.1.bb => 
>> nativesdk-meson_0.53.0.bb} (99%)
>> 
>> diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
>> index 1ef34a999c8..1837c9468e6 100644
>> --- a/meta/classes/meson.bbclass
>> +++ b/meta/classes/meson.bbclass
>> @@ -85,13 +85,16 @@ addtask write_config before do_configure
>> do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS CXXFLAGS 
>> LDFLAGS"
>> do_write_config() {
>> # This needs to be Py to split the args into single-element lists
>> +
>> +# Meson requires ld to be 'bfd, 'lld' or 'gold' from 0.53 onwards
>> +# 
>> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
>> cat >${WORKDIR}/meson.cross <> [binaries]
>> c = ${@meson_array('CC', d)}
>> cpp = ${@meson_array('CXX', d)}
>> ar = ${@meson_array('AR', d)}
>> nm = ${@meson_array('NM', d)}
>> -ld = ${@meson_array('LD', d)}
>> +ld = 'bfd'
> 
> there has to be a way to define it based on DISTRO_FEATURES containing
> ld-is-gold
> or ld-is-lld and perhaps also if someone adds
> 
> LDFLAGS += "-fuse-ld="
> 
> should work too. I am not sure if all these cases function if we make
> this change.
> 
>> strip = ${@meson_array('STRIP', d)}
>> readelf = ${@meson_array('READELF', d)}
>> pkgconfig = 'pkg-config'
>> @@ -122,6 +125,10 @@ EOF
>> CONFIGURE_FILES = "meson.build"
>> 
>> meson_do_configure() {
>> +# Meson requires this to be 'bfd, 'lld' or 'gold' from 0.53 onwards
>> +# 
>> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
>> +unset LD
>> +
>> # Work around "Meson fails if /tmp is mounted with noexec #2972"
>> mkdir -p "${B}/meson-private/tmp"
>> export TMPDIR="${B}/meson-private/tmp"
>> diff --git a/meta/recipes-devtools/meson/meson.inc 
>> b/meta/recipes-devtools/meson/meson.inc
>> index 881a14c7f0a..c0ce7d338bc 100644
>> --- a/meta/recipes-devtools/meson/meson.inc
>> +++ b/meta/recipes-devtools/meson/meson.inc
>> @@ -17,8 +17,8 @@ SRC_URI = 
>> "https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
>>
>> file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \
>>
>> file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
>>"
>> -SRC_URI[sha256sum] = 
>> "0c277472e49950a5537e3de3e60c57b80dbf425788470a1a8ed27446128fc035"
>> -SRC_URI[md5sum] = "a5f0c99567d772508f649a28ded7f8ad"
>> +SRC_URI[sha256sum] = 
>> "035e75993ab6fa6c9ebf902b835c64cf397a763eb8e65c9bb6e1cc9730a9d3f6"
>> +SRC_URI[md5sum] = "3a0313d040ded973d84cbec368c2e1d3"
>> 
>> SRC_URI_append_class-native = " \
>> file://0001-Make-CPU-family-warnings-fatal.patch \
>> diff --git 
>> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
>>  
>> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
>> index d4264cee526..74d5b4ca66e 100644
>> --- 
>> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
>> +++ 
>> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
>> @@ -1,4 +1,4 @@
>> -From cd980c763f11cfd928255346cc7e86f24add985e Mon Sep 17 00:00:00 2001
>> +From 8ce7a1ddbc9b7775568a98fcd50e39a01513c902 Mon Sep 17 00:00:00 2001
>> From: Ross Burton 
>> Date: Tue, 3 Jul 2018 13:59:09 +0100
>> Subject: [PATCH] Make CPU family warnings fatal
>> @@ -12,10 +12,10 @@ Signed-off-by: Ross Burton 
>>  2 files changed, 2 insertions(+), 4 deletions(-)
>> 
>> diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py
>> -index 29d7422..5fb00a4 100644
>> +index 0f277a7..24578ea 100644
>> --- a/mesonbuild/envconfig.py
>> +++ b/mesonbuild/envconfig.py
>> -@@ -190,7 +190,7 @@ class MachineInfo:
>> +@@ -192,7 +192,7 @@ class MachineInfo:
>> 
>>  cpu_family = literal['cpu_family']
>>  if cpu_family not in known_cpu_families:
>> @@ -25,15 +25,15 @@ index 29d7422..5fb00a4 100644
>>  endian = literal['endian']
>>  if endian 

[OE-core] [PATCH v2] arm-trusted-firmware: add upstream version 2.2

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
To avoid duplicating efforts of adding very similar recipes to BSP layers,
add an upstream reference implementation to openembedded-core, which can be
customized by BSPs, if needed.

Signed-off-by: Denys Dmytriyenko 
Cc: Joshua Watt 
---
v2 - add new entry to maintainers.inc

 meta/conf/distro/include/maintainers.inc   |  1 +
 .../arm-trusted-firmware_2.2.bb| 55 ++
 2 files changed, 56 insertions(+)
 create mode 100644 
meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 01afc25..2a4121b 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -45,6 +45,7 @@ RECIPE_MAINTAINER_pn-apr-util = "Hongxu Jia 
"
 RECIPE_MAINTAINER_pn-apt = "Aníbal Limón "
 RECIPE_MAINTAINER_pn-apt-native = "Aníbal Limón "
 RECIPE_MAINTAINER_pn-argp-standalone = "Khem Raj "
+RECIPE_MAINTAINER_pn-arm-trusted-firmware = "Denys Dmytriyenko "
 RECIPE_MAINTAINER_pn-asciidoc = "Yi Zhao "
 RECIPE_MAINTAINER_pn-aspell = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-assimp = "Anuj Mittal "
diff --git a/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb 
b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
new file mode 100644
index 000..3079a70
--- /dev/null
+++ b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
@@ -0,0 +1,55 @@
+SUMMARY = "ARM Trusted Firmware"
+DESCRIPTION = "ARM Trusted Firmware provides a reference implementation of \
+Secure World software for ARMv8-A, including Exception Level 3 (EL3) software. 
\
+It provides implementations of various ARM interface standards such as the \
+Power State Coordination Interface (PSCI), Trusted Board Boot Requirements \
+(TBBR) and Secure monitor code."
+HOMEPAGE = 
"http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/CJHIDGJF.html;
+
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = 
"file://docs/license.rst;md5=189505435dbcdcc8caa63c46fe93fa89"
+
+inherit deploy
+
+DEPENDS = "dtc-native openssl-native"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+S = "${WORKDIR}/git"
+B = "${WORKDIR}/build"
+
+BRANCH = "master"
+SRC_URI = 
"git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git;protocol=http;branch=${BRANCH}"
+SRCREV = "a04808c16cfc126d9fe572ae7c4b5a3d39de5796"
+
+ATF_BINARY ??= "bl31"
+ATF_SUFFIX ??= "bin"
+ATF_TARGET ??= "all"
+
+CFLAGS[unexport] = "1"
+LDFLAGS[unexport] = "1"
+AS[unexport] = "1"
+LD[unexport] = "1"
+
+do_configure[noexec] = "1"
+
+EXTRA_OEMAKE = '-C ${S} BUILD_BASE=${B} DEBUG=0 
CROSS_COMPILE="${TARGET_PREFIX}" \
+   PLAT="${ATF_PLATFORM}" TARGET_BOARD="${ATF_BOARD}" 
${PACKAGECONFIG_CONFARGS}'
+
+do_compile() {
+   oe_runmake ${ATF_TARGET}
+}
+
+do_install() {
+   install -d ${D}/boot
+   install -m 0644 
${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} ${D}/boot/
+}
+
+do_deploy() {
+   install -d ${DEPLOYDIR}
+   install -m 0644 
${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} 
${DEPLOYDIR}/
+}
+addtask deploy before do_build after do_compile
+
+FILES_${PN} = "/boot"
+SYSROOT_DIRS += "/boot"
-- 
2.7.4

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

Re: [OE-core] [PATCH 3/5] default-distrovars.inc: add vfat to DISTRO_FEATURES

[Alexander Kanavin]

Sorry but certainly no. It’s already hard enough to make ptests pass with just 
the one standard configuration tested by the autobuilder. I still have a 
handful of components with cryptic failures left to fix, so if you can help 
with valgrind, mdadm or lttng failures I’d appreciate that.

If you want parted test suite to handle things gracefully when vfat is absent, 
work with parted upstream to make it happen.

Alex

> On 23 Jan 2020, at 21.15, André Draszik  wrote:
> 
> Hi,
> 
>> On Thu, 2020-01-23 at 18:34 +0100, Alexander Kanavin wrote:
>> This is beneficial for parted ptests in particular, as
>> they expect vfat functionality to work.
> 
> Could you also update the parted ptests to skip or delete those
> tests that depend on vfat, please? I.e. when the DISTRO_FEATURE
> is not enabled.
> 
> For the benefit of those people that don't need / want vfat, but
> still want to ensure that parted works by running the ptests.
> 
> Is that feasible?
> 
> 
> Cheers,
> Andre'
> 
>> 
>> Signed-off-by: Alexander Kanavin 
>> ---
>> meta/conf/distro/include/default-distrovars.inc | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/meta/conf/distro/include/default-distrovars.inc 
>> b/meta/conf/distro/include/default-distrovars.inc
>> index 10d86cf7b17..433d4b6651d 100644
>> --- a/meta/conf/distro/include/default-distrovars.inc
>> +++ b/meta/conf/distro/include/default-distrovars.inc
>> @@ -10,7 +10,7 @@ LOCALE_UTF8_ONLY ?= "0"
>> LOCALE_UTF8_IS_DEFAULT ?= "1"
>> LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
>> 
>> -DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 ipv4 ipv6 
>> largefile pcmcia usbgadget usbhost wifi xattr nfs
>> zeroconf pci 3g nfc x11"
>> +DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 ipv4 ipv6 
>> largefile pcmcia usbgadget usbhost wifi xattr nfs
>> zeroconf pci 3g nfc x11 vfat"
>> DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
>> IMAGE_FEATURES ?= ""
>> 
>> -- 
>> 2.17.1
>> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tune-cortexa72-cortexa53.inc: Adding missing TUNE_FEATURES

[Jaewon Lee]

Without the proper default tune in TUNE_FEATURES, certain variables
won't expand correctly. MACHINEOVERRIDES won't add cortexa72-cortexa53:
TUNE_CCARGS won't add -mtune=cortexa72.cortexa-53, generating the toolchain
incorrectly.
Adding missing 'cortexa72-cortexa53' to both
TUNE_FEATURES_tune-cortexa72-cortexa53 and
TUNE_FEATURES_tune-cortexa72-cortexa53-crypto

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/conf/machine/include/tune-cortexa72-cortexa53.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
index 0d43531..f208b98 100644
--- a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
@@ -14,8 +14,8 @@ TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", 
"cortexa72-cortexa53", " -
 AVAILTUNES += "cortexa72-cortexa53 cortexa72-cortexa53-crypto"
 ARMPKGARCH_tune-cortexa72-cortexa53  = "cortexa72-cortexa53"
 ARMPKGARCH_tune-cortexa72-cortexa53-crypto   = "cortexa72-cortexa53"
-TUNE_FEATURES_tune-cortexa72-cortexa53   = 
"${TUNE_FEATURES_tune-armv8a-crc}"
-TUNE_FEATURES_tune-cortexa72-cortexa53-crypto= 
"${TUNE_FEATURES_tune-armv8a-crc-crypto}"
+TUNE_FEATURES_tune-cortexa72-cortexa53   = 
"${TUNE_FEATURES_tune-armv8a-crc} cortexa72-cortexa53"
+TUNE_FEATURES_tune-cortexa72-cortexa53-crypto= 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc}cortexa72-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72-cortexa53 
cortexa72-cortexa53-crypto"
 BASE_LIB_tune-cortexa72-cortexa53= "lib64"
-- 
2.7.4

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

[OE-core] ✗ patchtest: failure for "procps: enable optional system..." and 2 more

[Patchwork]

== Series Details ==

Series: "procps: enable optional system..." and 2 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/22252/
State : failure

== Summary ==


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



* Patch[3/3] Allow customising buildhistory tags
 Issue Shortlog does not follow expected format 
[test_shortlog_format] 
  Suggested fixCommit shortlog (first line of commit message) should follow 
the format ": "



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
To avoid duplicating efforts of adding very similar recipes to BSP layers,
add an upstream reference implementation to openembedded-core, which can be
customized by BSPs, if needed.

Signed-off-by: Denys Dmytriyenko 
Cc: Joshua Watt 
---
 .../arm-trusted-firmware_2.2.bb| 55 ++
 1 file changed, 55 insertions(+)
 create mode 100644 
meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb

diff --git a/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb 
b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
new file mode 100644
index 000..3079a70
--- /dev/null
+++ b/meta/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.2.bb
@@ -0,0 +1,55 @@
+SUMMARY = "ARM Trusted Firmware"
+DESCRIPTION = "ARM Trusted Firmware provides a reference implementation of \
+Secure World software for ARMv8-A, including Exception Level 3 (EL3) software. 
\
+It provides implementations of various ARM interface standards such as the \
+Power State Coordination Interface (PSCI), Trusted Board Boot Requirements \
+(TBBR) and Secure monitor code."
+HOMEPAGE = 
"http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/CJHIDGJF.html;
+
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = 
"file://docs/license.rst;md5=189505435dbcdcc8caa63c46fe93fa89"
+
+inherit deploy
+
+DEPENDS = "dtc-native openssl-native"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+S = "${WORKDIR}/git"
+B = "${WORKDIR}/build"
+
+BRANCH = "master"
+SRC_URI = 
"git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git;protocol=http;branch=${BRANCH}"
+SRCREV = "a04808c16cfc126d9fe572ae7c4b5a3d39de5796"
+
+ATF_BINARY ??= "bl31"
+ATF_SUFFIX ??= "bin"
+ATF_TARGET ??= "all"
+
+CFLAGS[unexport] = "1"
+LDFLAGS[unexport] = "1"
+AS[unexport] = "1"
+LD[unexport] = "1"
+
+do_configure[noexec] = "1"
+
+EXTRA_OEMAKE = '-C ${S} BUILD_BASE=${B} DEBUG=0 
CROSS_COMPILE="${TARGET_PREFIX}" \
+   PLAT="${ATF_PLATFORM}" TARGET_BOARD="${ATF_BOARD}" 
${PACKAGECONFIG_CONFARGS}'
+
+do_compile() {
+   oe_runmake ${ATF_TARGET}
+}
+
+do_install() {
+   install -d ${D}/boot
+   install -m 0644 
${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} ${D}/boot/
+}
+
+do_deploy() {
+   install -d ${DEPLOYDIR}
+   install -m 0644 
${B}/${ATF_PLATFORM}/${ATF_BOARD}/release/${ATF_BINARY}.${ATF_SUFFIX} 
${DEPLOYDIR}/
+}
+addtask deploy before do_build after do_compile
+
+FILES_${PN} = "/boot"
+SYSROOT_DIRS += "/boot"
-- 
2.7.4

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

[OE-core] [PATCH 2/3] cmake: prefer CMAKE_BUILD_PARALLEL_LEVEL

[Dan McGregor]

From: Daniel McGregor 

cmake 3.12 introduced this environment variable. Prefer it to passing
PARALLEL_MAKE and PARALLEL_MAKEINST on the cmake command line, because
it gets passed to second stage cmake invocations while command-line
arguments do not (for example, multi-stage clang builds)

Signed-off-by: Daniel McGregor 
---
 meta/classes/cmake.bbclass |  5 +++--
 meta/lib/oe/utils.py   | 11 +++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index a046daa6ea..d91cf20130 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -63,8 +63,9 @@ OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
 
 EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
 
-EXTRA_OECMAKE_BUILD_prepend_task-compile = "${PARALLEL_MAKE} "
-EXTRA_OECMAKE_BUILD_prepend_task-install = "${PARALLEL_MAKEINST} "
+export CMAKE_BUILD_PARALLEL_LEVEL
+CMAKE_BUILD_PARALLEL_LEVEL_task-compile = "${@oe.utils.parallel_make(d, 
False)}"
+CMAKE_BUILD_PARALLEL_LEVEL_task-install = "${@oe.utils.parallel_make(d, True)}"
 
 OECMAKE_TARGET_COMPILE ?= "all"
 OECMAKE_TARGET_INSTALL ?= "install"
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 652b2be145..e350b05ddf 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -169,7 +169,7 @@ def any_distro_features(d, features, truevalue="1", 
falsevalue=""):
 """
 return bb.utils.contains_any("DISTRO_FEATURES", features, truevalue, 
falsevalue, d)
 
-def parallel_make(d):
+def parallel_make(d, makeinst=False):
 """
 Return the integer value for the number of parallel threads to use when
 building, scraped out of PARALLEL_MAKE. If no parallelization option is
@@ -177,7 +177,10 @@ def parallel_make(d):
 
 e.g. if PARALLEL_MAKE = "-j 10", this will return 10 as an integer.
 """
-pm = (d.getVar('PARALLEL_MAKE') or '').split()
+if makeinst:
+pm = (d.getVar('PARALLEL_MAKEINST') or '').split()
+else:
+pm = (d.getVar('PARALLEL_MAKE') or '').split()
 # look for '-j' and throw other options (e.g. '-l') away
 while pm:
 opt = pm.pop(0)
@@ -192,7 +195,7 @@ def parallel_make(d):
 
 return None
 
-def parallel_make_argument(d, fmt, limit=None):
+def parallel_make_argument(d, fmt, limit=None, makeinst=False):
 """
 Helper utility to construct a parallel make argument from the number of
 parallel threads specified in PARALLEL_MAKE.
@@ -205,7 +208,7 @@ def parallel_make_argument(d, fmt, limit=None):
 e.g. if PARALLEL_MAKE = "-j 10", parallel_make_argument(d, "-n %d") will 
return
 "-n 10"
 """
-v = parallel_make(d)
+v = parallel_make(d, makeinst)
 if v:
 if limit:
 v = min(limit, v)
-- 
2.24.1

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

[OE-core] [PATCH 3/3] Allow customising buildhistory tags

[Dan McGregor]

From: Daniel McGregor 

Allow setting custom buildhistory tag prefixes. This allows multiple
build directories to share one buildhistory git repository with multiple
worktrees.

Signed-off-by: Daniel McGregor 
---
 meta/classes/buildhistory.bbclass | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index affdf272d7..eb7295570d 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -40,6 +40,7 @@ BUILDHISTORY_SDK_FILES ?= "conf/local.conf conf/bblayers.conf 
conf/auto.conf con
 BUILDHISTORY_COMMIT ?= "1"
 BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory "
 BUILDHISTORY_PUSH_REPO ?= ""
+BUILDHISTORY_TAG ?= "build"
 
 SSTATEPOSTINSTFUNCS_append = " buildhistory_emit_pkghistory"
 # We want to avoid influencing the signatures of sstate tasks - first the 
function itself:
@@ -824,9 +825,9 @@ END
if [ ! -e .git ] ; then
git init -q
else
-   git tag -f build-minus-3 build-minus-2 > /dev/null 2>&1 
|| true
-   git tag -f build-minus-2 build-minus-1 > /dev/null 2>&1 
|| true
-   git tag -f build-minus-1 > /dev/null 2>&1 || true
+   git tag -f ${BUILDHISTORY_TAG}-minus-3 
${BUILDHISTORY_TAG}-minus-2 > /dev/null 2>&1 || true
+   git tag -f ${BUILDHISTORY_TAG}-minus-2 
${BUILDHISTORY_TAG}-minus-1 > /dev/null 2>&1 || true
+   git tag -f ${BUILDHISTORY_TAG}-minus-1 > /dev/null 2>&1 
|| true
fi
 
check_git_config
-- 
2.24.1

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

[OE-core] [PATCH 1/3] procps: enable optional systemd support

[Dan McGregor]

From: Daniel McGregor 

procps includes support for listing the owning unit of a process, but
this support is disabled by default. Enable support using
a PACKAGECONFIG that depends on the systemd DISTRO_FEATURE.

Signed-off-by: Daniel McGregor 
---
 meta/recipes-extended/procps/procps_3.3.15.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-extended/procps/procps_3.3.15.bb 
b/meta/recipes-extended/procps/procps_3.3.15.bb
index f240e54fd8..17abd96dca 100644
--- a/meta/recipes-extended/procps/procps_3.3.15.bb
+++ b/meta/recipes-extended/procps/procps_3.3.15.bb
@@ -24,6 +24,9 @@ S = "${WORKDIR}/procps-ng-${PV}"
 
 EXTRA_OECONF = "--enable-skill --disable-modern-top"
 
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)}"
+PACKAGECONFIG[systemd] = "--with-systemd,--without-systemd,systemd"
+
 do_install_append () {
install -d ${D}${base_bindir}
[ "${bindir}" != "${base_bindir}" ] && for i in ${base_bindir_progs}; 
do mv ${D}${bindir}/$i ${D}${base_bindir}/$i; done
-- 
2.24.1

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

Re: [OE-core] [PATCH 3/5] default-distrovars.inc: add vfat to DISTRO_FEATURES

[André Draszik]

Hi,

On Thu, 2020-01-23 at 18:34 +0100, Alexander Kanavin wrote:
> This is beneficial for parted ptests in particular, as
> they expect vfat functionality to work.

Could you also update the parted ptests to skip or delete those
tests that depend on vfat, please? I.e. when the DISTRO_FEATURE
is not enabled.

For the benefit of those people that don't need / want vfat, but
still want to ensure that parted works by running the ptests.

Is that feasible?


Cheers,
Andre'

> 
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/conf/distro/include/default-distrovars.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/distro/include/default-distrovars.inc 
> b/meta/conf/distro/include/default-distrovars.inc
> index 10d86cf7b17..433d4b6651d 100644
> --- a/meta/conf/distro/include/default-distrovars.inc
> +++ b/meta/conf/distro/include/default-distrovars.inc
> @@ -10,7 +10,7 @@ LOCALE_UTF8_ONLY ?= "0"
>  LOCALE_UTF8_IS_DEFAULT ?= "1"
>  LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
>  
> -DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 ipv4 ipv6 largefile 
> pcmcia usbgadget usbhost wifi xattr nfs
> zeroconf pci 3g nfc x11"
> +DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 ipv4 ipv6 largefile 
> pcmcia usbgadget usbhost wifi xattr nfs
> zeroconf pci 3g nfc x11 vfat"
>  DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
>  IMAGE_FEATURES ?= ""
>  
> -- 
> 2.17.1
> 

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

[OE-core] [PATCH 3/4] nss: Pass NSS_USE_ARM_HW_CRYPTO as define in CFLAGS

[Khem Raj]

Use NSS_USE_ARM_HW_CRYPTO to detect USE_ARM_GCM, since there are
dependent, without this we control the crypto code function inclusion in
build but do not control the call sites, which can result in undefined
symbols e.g.

Linux_SINGLE_SHLIB/gcm.o: in function `gcmHash_InitContext':
/usr/src/debug/nss/3.49.1-r0/nss-3.49.1/nss/lib/freebl/gcm.c:112: undefined 
reference to `gcm_HashInit_hw'

Signed-off-by: Khem Raj 
---
 ...figure-option-to-disable-ARM-HW-cryp.patch | 25 ---
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git 
a/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
 
b/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
index fe29d19882..803c06b218 100644
--- 
a/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
+++ 
b/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
@@ -12,20 +12,19 @@ Signed-off-by: Alexander Kanavin 
  nss/lib/freebl/Makefile | 3 +++
  1 file changed, 3 insertions(+)
 
-diff --git a/nss/lib/freebl/Makefile b/nss/lib/freebl/Makefile
-index 06506f0..a8b015d 100644
 --- a/nss/lib/freebl/Makefile
 +++ b/nss/lib/freebl/Makefile
-@@ -125,6 +125,8 @@ else
+@@ -125,6 +125,9 @@ else
  DEFINES += -DNSS_X86
  endif
  endif
 +
 +ifdef NSS_USE_ARM_HW_CRYPTO
++DEFINES += -DNSS_USE_ARM_HW_CRYPTO
  ifeq ($(CPU_ARCH),aarch64)
  DEFINES += -DUSE_HW_AES
  EXTRA_SRCS += aes-armv8.c gcm-aarch64.c
-@@ -145,6 +147,7 @@ ifeq ($(CPU_ARCH),arm)
+@@ -146,6 +149,7 @@ ifeq ($(CPU_ARCH),arm)
  endif
  endif
  endif
@@ -33,3 +32,21 @@ index 06506f0..a8b015d 100644
  
  ifeq ($(OS_TARGET),OSF1)
  DEFINES += -DMP_ASSEMBLY_MULTIPLY -DMP_NO_MP_WORD
+--- a/nss/lib/freebl/gcm.c
 b/nss/lib/freebl/gcm.c
+@@ -17,6 +17,7 @@
+ 
+ #include 
+ 
++#ifdef NSS_USE_ARM_HW_CRYPTO
+ /* old gcc doesn't support some poly64x2_t intrinsic */
+ #if defined(__aarch64__) && defined(IS_LITTLE_ENDIAN) && \
+ (defined(__clang__) || defined(__GNUC__) && __GNUC__ > 6)
+@@ -28,6 +29,7 @@
+  * that compiler uses -mfpu=neon only. */
+ #define USE_ARM_GCM
+ #endif
++#endif
+ 
+ /* Forward declarations */
+ SECStatus gcm_HashInit_hw(gcmHashContext *ghash);
-- 
2.25.0

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

[OE-core] [PATCH 4/4] libucontext: Add recipe

[Khem Raj]

Help musl based systems provide ucontext APIs

Signed-off-by: Khem Raj 
---
 .../0001-pass-LDFLAGS-to-link-step.patch  | 31 ++
 meta/recipes-core/musl/libucontext_git.bb | 62 +++
 2 files changed, 93 insertions(+)
 create mode 100644 
meta/recipes-core/musl/libucontext/0001-pass-LDFLAGS-to-link-step.patch
 create mode 100644 meta/recipes-core/musl/libucontext_git.bb

diff --git 
a/meta/recipes-core/musl/libucontext/0001-pass-LDFLAGS-to-link-step.patch 
b/meta/recipes-core/musl/libucontext/0001-pass-LDFLAGS-to-link-step.patch
new file mode 100644
index 00..0ab8caf3e6
--- /dev/null
+++ b/meta/recipes-core/musl/libucontext/0001-pass-LDFLAGS-to-link-step.patch
@@ -0,0 +1,31 @@
+From 12d45d250d08e96e889e38e77273c3ef73e6fc97 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Mon, 25 Nov 2019 15:07:35 -0800
+Subject: [PATCH] pass LDFLAGS to link step
+
+This helps to use OE specific linker flags and fixes
+
+do_package_qa: QA Issue: No GNU_HASH in the ELF binary
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index 8a605fd..d1c9637 100644
+--- a/Makefile
 b/Makefile
+@@ -20,7 +20,7 @@ ${LIBUCONTEXT_STATIC_NAME}: ${LIBUCONTEXT_OBJ}
+ 
+ ${LIBUCONTEXT_NAME}: ${LIBUCONTEXT_OBJ}
+   $(CC) -o ${LIBUCONTEXT_NAME} -Wl,-soname,${LIBUCONTEXT_SONAME} \
+-  -shared ${LIBUCONTEXT_OBJ}
++  -shared ${LIBUCONTEXT_OBJ} ${LDFLAGS}
+ 
+ ${LIBUCONTEXT_SONAME}: ${LIBUCONTEXT_NAME}
+   ln -sf ${LIBUCONTEXT_NAME} ${LIBUCONTEXT_SONAME}
+-- 
+2.24.0
+
diff --git a/meta/recipes-core/musl/libucontext_git.bb 
b/meta/recipes-core/musl/libucontext_git.bb
new file mode 100644
index 00..72e15aa9a4
--- /dev/null
+++ b/meta/recipes-core/musl/libucontext_git.bb
@@ -0,0 +1,62 @@
+# Copyright (C) 2019 Khem Raj 
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SUMMARY = "ucontext implementation featuring glibc-compatible ABI"
+HOMEPAGE = "https://github.com/kaniini/libucontext;
+LICENSE = "ISC"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=864cc1445419406b7093e8e531c9515e"
+SECTION = "libs"
+DEPENDS = ""
+
+PV = "0.1.3+${SRCPV}"
+SRCREV = "e6b4d7516dae9b200e94fcfcb9ebc9331389655f"
+SRC_URI = "git://code.foxkit.us/adelie/libucontext.git;protocol=https \
+   file://0001-pass-LDFLAGS-to-link-step.patch \
+"
+
+S = "${WORKDIR}/git"
+
+COMPATIBLE_HOST = ".*-musl.*"
+
+valid_archs = "\
+i386 x86 \
+ppc powerpc powerpc64 ppc64  \
+arm aarch64 \
+s390 \
+"
+
+def map_kernel_arch(a, d):
+import re
+
+valid_archs = d.getVar('valid_archs').split()
+
+if   re.match('(i.86|athlon)$', a): return 'x86'
+elif re.match('x86.64$', a):return 'x86_64'
+elif re.match('armeb$', a): return 'arm'
+elif re.match('aarch64$', a):   return 'aarch64'
+elif re.match('aarch64_be$', a):return 'aarch64'
+elif re.match('aarch64_ilp32$', a): return 'aarch64'
+elif re.match('aarch64_be_ilp32$', a):  return 'aarch64'
+elif re.match('mips(isa|)(32|64|)(r6|)(el|)$', a):  return 'mips'
+elif re.match('p(pc|owerpc)', a):   return 'ppc'
+elif re.match('p(pc64|owerpc64)', a):   return 'ppc64'
+elif re.match('riscv64$', a):   return 'riscv64'
+elif a in valid_archs:  return a
+else:
+if not d.getVar("TARGET_OS").startswith("linux"):
+return a
+bb.error("cannot map '%s' to a linux kernel architecture" % a)
+
+export ARCH = "${@map_kernel_arch(d.getVar('TARGET_ARCH'), d)}"
+
+CFLAGS += "-Iarch/${ARCH}"
+
+EXTRA_OEMAKE = "CFLAGS='${CFLAGS}' LDFLAGS='${LDFLAGS}'"
+
+do_compile() {
+oe_runmake ARCH=${ARCH}
+}
+
+do_install() {
+oe_runmake ARCH="${ARCH}" DESTDIR="${D}" install
+}
-- 
2.25.0

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

[OE-core] [PATCH 2/4] ruby: Remove __has_include and __has_include_next from preprocessed header file

[Khem Raj]

one of the build steps ruby has is that it generated rb_mjit_header.h
during configure using gcc preprocessor using -dD which emits built-in
defines as well, problem happens when this header is later included in
subsequent compiles, where compiler errors out stating that an existing
internal define is redefined

| /tmp/20200123-2021083-2c601q.h:13849:9: error: "__has_include" cannot be used 
as a macro name
| 13849 | #define __has_include __has_include
|   | ^
| compilation terminated due to -Wfatal-errors.

Since compiler already will take care of it internally we can edit it
out from this header file

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

diff --git a/meta/recipes-devtools/ruby/ruby.inc 
b/meta/recipes-devtools/ruby/ruby.inc
index ce1b02f012..d5cd329e65 100644
--- a/meta/recipes-devtools/ruby/ruby.inc
+++ b/meta/recipes-devtools/ruby/ruby.inc
@@ -38,3 +38,10 @@ do_configure_prepend() {
 sed -i "s#%%TARGET_CFLAGS%%#$CFLAGS#; s#%%TARGET_LDFLAGS%%#$LDFLAGS#" 
${S}/common.mk
 rm -rf ${S}/ruby/
 }
+
+do_compile_prepend() {
+if [ -e ${B}/rb_mjit_header.h ]; then
+sed -i -e "/#define __has_include __has_include/d" 
${B}/rb_mjit_header.h
+sed -i -e "/#define __has_include_next __has_include_next/d" 
${B}/rb_mjit_header.h
+fi
+}
-- 
2.25.0

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

[OE-core] [PATCH 0/4] Fixes found with master versions of clang/gcc

[Khem Raj]

libucontext is library implementation for ucontext APIs which in case of
glibc are bundled into C library but not for musl, this helps compiling
apps needing these APIs on musl, e.g. chromium

The following changes since commit ca3993cc4b13d4e661228cee6fb9448adfd0a4ba:

  bitbake: tests/fetch: Allow wget upgrade tests to run against a local server 
(2020-01-22 15:56:39 +)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib kraj/pu
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=kraj/pu

Khem Raj (4):
  perf: Pass LDSHARED and CCLD via EXTRA_OEMAKE
  ruby: Remove __has_include and __has_include_next from preprocessed
header file
  nss: Pass NSS_USE_ARM_HW_CRYPTO as define in CFLAGS
  libucontext: Add recipe

 .../0001-pass-LDFLAGS-to-link-step.patch  | 31 ++
 meta/recipes-core/musl/libucontext_git.bb | 62 +++
 meta/recipes-devtools/ruby/ruby.inc   |  7 +++
 meta/recipes-kernel/perf/perf.bb  |  2 +
 ...figure-option-to-disable-ARM-HW-cryp.patch | 25 ++--
 5 files changed, 123 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-core/musl/libucontext/0001-pass-LDFLAGS-to-link-step.patch
 create mode 100644 meta/recipes-core/musl/libucontext_git.bb

-- 
2.25.0

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

[OE-core] [PATCH 1/4] perf: Pass LDSHARED and CCLD via EXTRA_OEMAKE

[Khem Raj]

python code underneath is smart and pokes at python installation in
sysroot for compile environment, the overrides from EXTRA_OEMAKE are
ofcourse preferred but it falls back to python3's distutils/sysconfig
for rest of them, and it does use CCLD and LDSHARED for linking, when we
use clang to compile python3 then it encodes these variables to be clang
however, when building perf we inherit kernel which forces gcc to be
used for compiling perf, which then mixes both compilers due to CCLD and
LDSHARED demands. Therefore override CCLD and LDSHARED in make
environment helps python/distutils to use right linker

Signed-off-by: Khem Raj 
---
 meta/recipes-kernel/perf/perf.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 840f3008b5..6d1b06693d 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -73,6 +73,8 @@ EXTRA_OEMAKE = '\
 CROSS_COMPILE=${TARGET_PREFIX} \
 ARCH=${ARCH} \
 CC="${CC}" \
+CCLD="${CC}" \
+LDSHARED="${CC} -shared" \
 AR="${AR}" \
 LD="${LD}" \
 EXTRA_CFLAGS="-ldw" \
-- 
2.25.0

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

Re: [OE-core] [PATCH 1/3] packagegroup-base: only pull in dosfstools if licensing allows

[Andre McCurdy]

On Wed, Jan 22, 2020 at 6:46 AM Ross Burton  wrote:
>
> packagegroup-base-vfat RRECOMMENDS on dosfstools, but this is GPLv3 so
> may be blacklisted.  Respect INCOMPATIBLE_LICENSE and don't recommend if
> GPL-3.0 has been blacklisted.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-core/packagegroups/packagegroup-base.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb 
> b/meta/recipes-core/packagegroups/packagegroup-base.bb
> index 1f802da09b7..3476db09c35 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-base.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
> @@ -168,7 +168,7 @@ RRECOMMENDS_packagegroup-base-vfat = "\
>  kernel-module-vfat \
>  kernel-module-nls-iso8859-1 \
>  kernel-module-nls-cp437 \
> -dosfstools"
> +${@bb.utils.contains("INCOMPATIBLE_LICENSE", "GPL-3.0", "", 
> "dosfstools", d)}"

Should this be using incompatible_license_contains() instead of
bb.utils.contains()?

>  SUMMARY_packagegroup-base-alsa = "ALSA sound support"
>  RDEPENDS_packagegroup-base-alsa = "\
> --
> 2.20.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/5] meson: update 0.52.1 -> 0.53.0

[Khem Raj]

On Thu, Jan 23, 2020 at 9:34 AM Alexander Kanavin
 wrote:
>
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/classes/meson.bbclass   |  9 -
>  meta/recipes-devtools/meson/meson.inc|  4 ++--
>  .../0001-Make-CPU-family-warnings-fatal.patch| 12 ++--
>  ...-do-not-manipulate-the-environment-when.patch | 16 
>  ...-Support-building-allarch-recipes-again.patch |  6 +++---
>  .../meson/meson/0003-native_bindir.patch | 16 
>  .../meson/{meson_0.52.1.bb => meson_0.53.0.bb}   |  0
>  ...meson_0.52.1.bb => nativesdk-meson_0.53.0.bb} |  2 +-
>  8 files changed, 36 insertions(+), 29 deletions(-)
>  rename meta/recipes-devtools/meson/{meson_0.52.1.bb => meson_0.53.0.bb} 
> (100%)
>  rename meta/recipes-devtools/meson/{nativesdk-meson_0.52.1.bb => 
> nativesdk-meson_0.53.0.bb} (99%)
>
> diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> index 1ef34a999c8..1837c9468e6 100644
> --- a/meta/classes/meson.bbclass
> +++ b/meta/classes/meson.bbclass
> @@ -85,13 +85,16 @@ addtask write_config before do_configure
>  do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS CXXFLAGS 
> LDFLAGS"
>  do_write_config() {
>  # This needs to be Py to split the args into single-element lists
> +
> +# Meson requires ld to be 'bfd, 'lld' or 'gold' from 0.53 onwards
> +# 
> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
>  cat >${WORKDIR}/meson.cross <  [binaries]
>  c = ${@meson_array('CC', d)}
>  cpp = ${@meson_array('CXX', d)}
>  ar = ${@meson_array('AR', d)}
>  nm = ${@meson_array('NM', d)}
> -ld = ${@meson_array('LD', d)}
> +ld = 'bfd'

there has to be a way to define it based on DISTRO_FEATURES containing
ld-is-gold
or ld-is-lld and perhaps also if someone adds

LDFLAGS += "-fuse-ld="

should work too. I am not sure if all these cases function if we make
this change.

>  strip = ${@meson_array('STRIP', d)}
>  readelf = ${@meson_array('READELF', d)}
>  pkgconfig = 'pkg-config'
> @@ -122,6 +125,10 @@ EOF
>  CONFIGURE_FILES = "meson.build"
>
>  meson_do_configure() {
> +# Meson requires this to be 'bfd, 'lld' or 'gold' from 0.53 onwards
> +# 
> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
> +unset LD
> +
>  # Work around "Meson fails if /tmp is mounted with noexec #2972"
>  mkdir -p "${B}/meson-private/tmp"
>  export TMPDIR="${B}/meson-private/tmp"
> diff --git a/meta/recipes-devtools/meson/meson.inc 
> b/meta/recipes-devtools/meson/meson.inc
> index 881a14c7f0a..c0ce7d338bc 100644
> --- a/meta/recipes-devtools/meson/meson.inc
> +++ b/meta/recipes-devtools/meson/meson.inc
> @@ -17,8 +17,8 @@ SRC_URI = 
> "https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> 
> file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \
> 
> file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
> "
> -SRC_URI[sha256sum] = 
> "0c277472e49950a5537e3de3e60c57b80dbf425788470a1a8ed27446128fc035"
> -SRC_URI[md5sum] = "a5f0c99567d772508f649a28ded7f8ad"
> +SRC_URI[sha256sum] = 
> "035e75993ab6fa6c9ebf902b835c64cf397a763eb8e65c9bb6e1cc9730a9d3f6"
> +SRC_URI[md5sum] = "3a0313d040ded973d84cbec368c2e1d3"
>
>  SRC_URI_append_class-native = " \
>  file://0001-Make-CPU-family-warnings-fatal.patch \
> diff --git 
> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch 
> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> index d4264cee526..74d5b4ca66e 100644
> --- 
> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> +++ 
> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> @@ -1,4 +1,4 @@
> -From cd980c763f11cfd928255346cc7e86f24add985e Mon Sep 17 00:00:00 2001
> +From 8ce7a1ddbc9b7775568a98fcd50e39a01513c902 Mon Sep 17 00:00:00 2001
>  From: Ross Burton 
>  Date: Tue, 3 Jul 2018 13:59:09 +0100
>  Subject: [PATCH] Make CPU family warnings fatal
> @@ -12,10 +12,10 @@ Signed-off-by: Ross Burton 
>   2 files changed, 2 insertions(+), 4 deletions(-)
>
>  diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py
> -index 29d7422..5fb00a4 100644
> +index 0f277a7..24578ea 100644
>  --- a/mesonbuild/envconfig.py
>  +++ b/mesonbuild/envconfig.py
> -@@ -190,7 +190,7 @@ class MachineInfo:
> +@@ -192,7 +192,7 @@ class MachineInfo:
>
>   cpu_family = literal['cpu_family']
>   if cpu_family not in known_cpu_families:
> @@ -25,15 +25,15 @@ index 29d7422..5fb00a4 100644
>   endian = literal['endian']
>   if endian not in ('little', 'big'):
>  diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
> -index a9bc2b8..b91c8da 100644
> +index dc8b14f..3aab71e 100644
>  --- a/mesonbuild/environment.py
>  +++ b/mesonbuild/environment.py
> -@@ -348,9 +348,7 @@ def detect_cpu_family(compilers: CompilersDict) -> 

Re: [OE-core] Connectivity check uris

[Andre McCurdy]

On Thu, Jan 23, 2020 at 7:24 AM Richard Purdie
 wrote:
> On Thu, 2020-01-23 at 09:59 -0500, Jean-Marie LEMETAYER wrote:
> > On Jan 23, 2020, at 3:37 PM, Richard Purdie
> > richard.pur...@linuxfoundation.org wrote:
> > > On Thu, 2020-01-23 at 09:22 -0500, Jean-Marie LEMETAYER wrote:
> > > > I understand the issue with blocked domains this is why I suggest
> > > > the
> > > > custom domain "connectivitycheck.openembedded.org".
> > > >
> > > > But I dont know if it could be an option. Can OE have a sub-
> > > > domain
> > > > like that? maybe using some cdn to handle the load?
> > >
> > > We can certainly setup domains but we can't easily get a cdn. I'd
> > > be
> > > worried about OE's response time too.
> > >
> > > > Another option will be to provide multiple URIs:
> > > > CONNECTIVITY_CHECK_URIS ?= " \
> > > > https://google.com \
> > > > https://www.bing.com \
> > > > https://www.baidu.com \
> > > > "
> > >
> > > Looking at the code, I wonder if a CONNECTIVITY_CHECK_MIRRORS,
> > > injected
> > > into MIRRORS internally with google as the default and baidu as the
> > > mirror would work?

How about checking github.com? That's probably the host that a network
dependent build needs to access most often.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ruby: Remove __has_include and __has_include_next from preprocessed header file

[Khem Raj]

one of the build steps ruby has is that it generated rb_mjit_header.h
during configure using gcc preprocessor using -dD which emits built-in
defines as well, problem happens when this header is later included in
subsequent compiles, where compiler errors out stating that an existing
internal define is redefined

| /tmp/20200123-2021083-2c601q.h:13849:9: error: "__has_include" cannot be used 
as a macro name
| 13849 | #define __has_include __has_include
|   | ^
| compilation terminated due to -Wfatal-errors.

Since compiler already will take care of it internally we can edit it
out from this header file

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

diff --git a/meta/recipes-devtools/ruby/ruby.inc 
b/meta/recipes-devtools/ruby/ruby.inc
index ce1b02f012..d5cd329e65 100644
--- a/meta/recipes-devtools/ruby/ruby.inc
+++ b/meta/recipes-devtools/ruby/ruby.inc
@@ -38,3 +38,10 @@ do_configure_prepend() {
 sed -i "s#%%TARGET_CFLAGS%%#$CFLAGS#; s#%%TARGET_LDFLAGS%%#$LDFLAGS#" 
${S}/common.mk
 rm -rf ${S}/ruby/
 }
+
+do_compile_prepend() {
+if [ -e ${B}/rb_mjit_header.h ]; then
+sed -i -e "/#define __has_include __has_include/d" 
${B}/rb_mjit_header.h
+sed -i -e "/#define __has_include_next __has_include_next/d" 
${B}/rb_mjit_header.h
+fi
+}
-- 
2.25.0

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

[OE-core] [PATCH 1/5] meson: update 0.52.1 -> 0.53.0

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/classes/meson.bbclass   |  9 -
 meta/recipes-devtools/meson/meson.inc|  4 ++--
 .../0001-Make-CPU-family-warnings-fatal.patch| 12 ++--
 ...-do-not-manipulate-the-environment-when.patch | 16 
 ...-Support-building-allarch-recipes-again.patch |  6 +++---
 .../meson/meson/0003-native_bindir.patch | 16 
 .../meson/{meson_0.52.1.bb => meson_0.53.0.bb}   |  0
 ...meson_0.52.1.bb => nativesdk-meson_0.53.0.bb} |  2 +-
 8 files changed, 36 insertions(+), 29 deletions(-)
 rename meta/recipes-devtools/meson/{meson_0.52.1.bb => meson_0.53.0.bb} (100%)
 rename meta/recipes-devtools/meson/{nativesdk-meson_0.52.1.bb => 
nativesdk-meson_0.53.0.bb} (99%)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 1ef34a999c8..1837c9468e6 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -85,13 +85,16 @@ addtask write_config before do_configure
 do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS CXXFLAGS 
LDFLAGS"
 do_write_config() {
 # This needs to be Py to split the args into single-element lists
+
+# Meson requires ld to be 'bfd, 'lld' or 'gold' from 0.53 onwards
+# 
https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
 cat >${WORKDIR}/meson.cross [OE-core] [PATCH 4/5] mdadm: correctly set up testing location for	ptests


2020-01-23

Thread
Alexander Kanavin

1. Do not clutter /, create a special-purpose dir
2. Clean up the dir after tests are done (if this is not
performed, disk will overflow later in ptesting).
3. Fix up more locations in ptests to use the dir.

Upstream default /var/tmp is not suitable as it is not
big enough (mdadm needs about 500 Mb)

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-extended/mdadm/files/run-ptest | 3 +++
 meta/recipes-extended/mdadm/mdadm_4.1.bb| 3 ++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/mdadm/files/run-ptest 
b/meta/recipes-extended/mdadm/files/run-ptest
index e4a9c2b08b9..7959c055ad5 100644
--- a/meta/recipes-extended/mdadm/files/run-ptest
+++ b/meta/recipes-extended/mdadm/files/run-ptest
@@ -1,4 +1,7 @@
 #!/bin/sh
 
+mkdir -p /mdadm-testing-dir
 # make the test continue to execute even one fail
 ./test --keep-going
+
+rm -rf /mdadm-testing-dir/*
diff --git a/meta/recipes-extended/mdadm/mdadm_4.1.bb 
b/meta/recipes-extended/mdadm/mdadm_4.1.bb
index 64f519e7502..40c5273e005 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.1.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.1.bb
@@ -75,7 +75,8 @@ do_compile_ptest() {
 do_install_ptest() {
cp -R --no-dereference --preserve=mode,links -v ${S}/tests 
${D}${PTEST_PATH}/tests
cp ${S}/test ${D}${PTEST_PATH}
-   sed -e 's!sleep 0.*!sleep 1!g; s!/var/tmp!/!g' -i ${D}${PTEST_PATH}/test
+   sed -e 's!sleep 0.*!sleep 1!g; s!/var/tmp!/mdadm-testing-dir!g' -i 
${D}${PTEST_PATH}/test
+   sed -e 's!/var/tmp!/mdadm-testing-dir!g' -i ${D}${PTEST_PATH}/tests/*
 sed -i -e '/echo -ne "$_script... "/d' \
-e 's/echo "succeeded"/echo -e "PASS: $_script"/g' \
-e '/save_log fail/N; /_fail=1/i\\t\t\techo -ne "FAIL: 
$_script"' \
-- 
2.17.1

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





[OE-core] [PATCH 5/5] elfutils: additional ptest fixes


2020-01-23

Thread
Alexander Kanavin

This should address ARM64 specific failures in particular.

eu-objdump is now installed on all architectures;
ptests fail in its absence and pass when it is present, so it's
useful at least in some scenarios in non-x86 architectures and
fails gracefully otherwise.

The original decision to exclude it was here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5283

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/elfutils/elfutils_0.178.bb | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.178.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.178.bb
index 9393628dd13..8f5deb2c62a 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.178.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.178.bb
@@ -58,11 +58,7 @@ RDEPENDS_${PN}-ptest += "libasm libelf bash make coreutils 
${PN}-binutils"
 
 EXTRA_OECONF_append_class-target += "--disable-tests-rpath"
 
-do_install_append() {
-   if [ "${TARGET_ARCH}" != "x86_64" ] && [ -z `echo "${TARGET_ARCH}"|grep 
'i.86'` ];then
-   rm -f ${D}${bindir}/eu-objdump
-   fi
-}
+RDEPENDS_${PN}-ptest_append_libc-glibc = " glibc-utils"
 
 do_compile_ptest() {
cd ${B}/tests
@@ -139,6 +135,7 @@ INHIBIT_PACKAGE_STRIP_FILES = "\
 ${PKGD}${PTEST_PATH}/tests/elfstrmerge \
 ${PKGD}${PTEST_PATH}/tests/backtrace-child \
 ${PKGD}${PTEST_PATH}/tests/backtrace-data \
+${PKGD}${PTEST_PATH}/tests/backtrace-dwarf \
 ${PKGD}${PTEST_PATH}/tests/deleted \
 ${PKGD}${PTEST_PATH}/src/strip \
 ${PKGD}${PTEST_PATH}/src/addr2line \
-- 
2.17.1

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





[OE-core] [PATCH 3/5] default-distrovars.inc: add vfat to	DISTRO_FEATURES


2020-01-23

Thread
Alexander Kanavin

This is beneficial for parted ptests in particular, as
they expect vfat functionality to work.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/distro/include/default-distrovars.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/default-distrovars.inc 
b/meta/conf/distro/include/default-distrovars.inc
index 10d86cf7b17..433d4b6651d 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -10,7 +10,7 @@ LOCALE_UTF8_ONLY ?= "0"
 LOCALE_UTF8_IS_DEFAULT ?= "1"
 LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
 
-DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 ipv4 ipv6 largefile 
pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11"
+DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 ipv4 ipv6 largefile 
pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat"
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
 IMAGE_FEATURES ?= ""
 
-- 
2.17.1

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





[OE-core] [PATCH 2/5] core-image-sato-sdk-ptest: do not pull in	ptest-pkgs


2020-01-23

Thread
Alexander Kanavin

The lists of ptests are defined via PTESTS_FAST and PTESTS_SLOW;
ptests-pkgs also pulls in additional items that are specifically
excluded from those due to causing issues with ptesting.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-sato/images/core-image-sato-sdk-ptest.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb 
b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
index ff297fe324c..7490b773d2e 100644
--- a/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
+++ b/meta/recipes-sato/images/core-image-sato-sdk-ptest.bb
@@ -3,8 +3,6 @@ require conf/distro/include/ptest-packagelists.inc
 
 DESCRIPTION += "Also includes ptest packages."
 
-IMAGE_FEATURES += "ptest-pkgs"
-
 PROVIDES += "core-image-sato-ptest"
 
 # Also include ptests which may not otherwise be included in a sato image
-- 
2.17.1

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





Re: [OE-core] [PATCH 24/24] meson: update 0.52.1 -> 0.53.0


2020-01-23

Thread
Khem Raj

On Thu, Jan 23, 2020 at 7:48 AM Alexander Kanavin 
wrote:

> New meson more or less forces one of 'bfd', 'lfd' or 'gold' for that
> option (both as 'ld' in cross file and in LD from environment), as it is
> passed directly to -fuse-ld, and that option takes only the three
> variants.You can't place the actual binary name there.
>

That’s fine I guess we don’t need to set it here then
Perhaps. If meson expect compiler driver to be always called as LD that
would be a problem for packages which currently might be using bare linker
but perhaps those packages don’t use meson so it would be fine


> There is a use case for letting meson recipes choose what they want for a
> linker, but that's an enhancement for some other time.
>
> Alex
>
> On Tue, 21 Jan 2020 at 19:44, Khem Raj  wrote:
>
>> On Mon, Jan 20, 2020 at 9:28 AM Alexander Kanavin
>>  wrote:
>> >
>> > Signed-off-by: Alexander Kanavin 
>> > ---
>> >  meta/classes/meson.bbclass   |  9 -
>> >  meta/recipes-devtools/meson/meson.inc|  4 ++--
>> >  .../0001-Make-CPU-family-warnings-fatal.patch| 12 ++--
>> >  ...-do-not-manipulate-the-environment-when.patch | 16 
>> >  ...-Support-building-allarch-recipes-again.patch |  6 +++---
>> >  .../meson/meson/0003-native_bindir.patch | 16 
>> >  .../meson/{meson_0.52.1.bb => meson_0.53.0.bb}   |  0
>> >  ...meson_0.52.1.bb => nativesdk-meson_0.53.0.bb} |  0
>> >  8 files changed, 35 insertions(+), 28 deletions(-)
>> >  rename meta/recipes-devtools/meson/{meson_0.52.1.bb => meson_0.53.0.bb}
>> (100%)
>> >  rename meta/recipes-devtools/meson/{nativesdk-meson_0.52.1.bb =>
>> nativesdk-meson_0.53.0.bb} (100%)
>> >
>> > diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
>> > index 1ef34a999c8..1837c9468e6 100644
>> > --- a/meta/classes/meson.bbclass
>> > +++ b/meta/classes/meson.bbclass
>> > @@ -85,13 +85,16 @@ addtask write_config before do_configure
>> >  do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS
>> CXXFLAGS LDFLAGS"
>> >  do_write_config() {
>> >  # This needs to be Py to split the args into single-element lists
>> > +
>> > +# Meson requires ld to be 'bfd, 'lld' or 'gold' from 0.53 onwards
>> > +#
>> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
>> >  cat >${WORKDIR}/meson.cross <> >  [binaries]
>> >  c = ${@meson_array('CC', d)}
>> >  cpp = ${@meson_array('CXX', d)}
>> >  ar = ${@meson_array('AR', d)}
>> >  nm = ${@meson_array('NM', d)}
>> > -ld = ${@meson_array('LD', d)}
>> > +ld = 'bfd'
>>
>> hardcoding to bfg would ignore gold or lld if users want to use those
>> linkers. Since its a fallback
>> and this expects linker to be invoked by compiler driver, since its
>> simply converting into -fuse-ld=
>> option to compiler, whereas in OE the var LD is set to represent bare
>> linker. Perhaps leaving it unset is
>> better, we already have LD set in env.
>>
>> >  strip = ${@meson_array('STRIP', d)}
>> >  readelf = ${@meson_array('READELF', d)}
>> >  pkgconfig = 'pkg-config'
>> > @@ -122,6 +125,10 @@ EOF
>> >  CONFIGURE_FILES = "meson.build"
>> >
>> >  meson_do_configure() {
>> > +# Meson requires this to be 'bfd, 'lld' or 'gold' from 0.53 onwards
>> > +#
>> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
>> > +unset LD
>> > +
>> >  # Work around "Meson fails if /tmp is mounted with noexec #2972"
>> >  mkdir -p "${B}/meson-private/tmp"
>> >  export TMPDIR="${B}/meson-private/tmp"
>> > diff --git a/meta/recipes-devtools/meson/meson.inc
>> b/meta/recipes-devtools/meson/meson.inc
>> > index 881a14c7f0a..c0ce7d338bc 100644
>> > --- a/meta/recipes-devtools/meson/meson.inc
>> > +++ b/meta/recipes-devtools/meson/meson.inc
>> > @@ -17,8 +17,8 @@ SRC_URI = "
>> https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
>> >
>>  file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \
>> >
>>  file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
>> > "
>> > -SRC_URI[sha256sum] =
>> "0c277472e49950a5537e3de3e60c57b80dbf425788470a1a8ed27446128fc035"
>> > -SRC_URI[md5sum] = "a5f0c99567d772508f649a28ded7f8ad"
>> > +SRC_URI[sha256sum] =
>> "035e75993ab6fa6c9ebf902b835c64cf397a763eb8e65c9bb6e1cc9730a9d3f6"
>> > +SRC_URI[md5sum] = "3a0313d040ded973d84cbec368c2e1d3"
>> >
>> >  SRC_URI_append_class-native = " \
>> >  file://0001-Make-CPU-family-warnings-fatal.patch \
>> > diff --git
>> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
>> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
>> > index d4264cee526..74d5b4ca66e 100644
>> > ---
>> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
>> > +++
>> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
>> > @@ -1,4 +1,4 @@
>> > -From cd980c763f11cfd928255346cc7e86f24add985e Mon 



Re: [OE-core] [PATCH 24/24] meson: update 0.52.1 -> 0.53.0


2020-01-23

Thread
Alexander Kanavin

New meson more or less forces one of 'bfd', 'lfd' or 'gold' for that option
(both as 'ld' in cross file and in LD from environment), as it is passed
directly to -fuse-ld, and that option takes only the three variants.You
can't place the actual binary name there.

There is a use case for letting meson recipes choose what they want for a
linker, but that's an enhancement for some other time.

Alex

On Tue, 21 Jan 2020 at 19:44, Khem Raj  wrote:

> On Mon, Jan 20, 2020 at 9:28 AM Alexander Kanavin
>  wrote:
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  meta/classes/meson.bbclass   |  9 -
> >  meta/recipes-devtools/meson/meson.inc|  4 ++--
> >  .../0001-Make-CPU-family-warnings-fatal.patch| 12 ++--
> >  ...-do-not-manipulate-the-environment-when.patch | 16 
> >  ...-Support-building-allarch-recipes-again.patch |  6 +++---
> >  .../meson/meson/0003-native_bindir.patch | 16 
> >  .../meson/{meson_0.52.1.bb => meson_0.53.0.bb}   |  0
> >  ...meson_0.52.1.bb => nativesdk-meson_0.53.0.bb} |  0
> >  8 files changed, 35 insertions(+), 28 deletions(-)
> >  rename meta/recipes-devtools/meson/{meson_0.52.1.bb => meson_0.53.0.bb}
> (100%)
> >  rename meta/recipes-devtools/meson/{nativesdk-meson_0.52.1.bb =>
> nativesdk-meson_0.53.0.bb} (100%)
> >
> > diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> > index 1ef34a999c8..1837c9468e6 100644
> > --- a/meta/classes/meson.bbclass
> > +++ b/meta/classes/meson.bbclass
> > @@ -85,13 +85,16 @@ addtask write_config before do_configure
> >  do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS
> CXXFLAGS LDFLAGS"
> >  do_write_config() {
> >  # This needs to be Py to split the args into single-element lists
> > +
> > +# Meson requires ld to be 'bfd, 'lld' or 'gold' from 0.53 onwards
> > +#
> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
> >  cat >${WORKDIR}/meson.cross < >  [binaries]
> >  c = ${@meson_array('CC', d)}
> >  cpp = ${@meson_array('CXX', d)}
> >  ar = ${@meson_array('AR', d)}
> >  nm = ${@meson_array('NM', d)}
> > -ld = ${@meson_array('LD', d)}
> > +ld = 'bfd'
>
> hardcoding to bfg would ignore gold or lld if users want to use those
> linkers. Since its a fallback
> and this expects linker to be invoked by compiler driver, since its
> simply converting into -fuse-ld=
> option to compiler, whereas in OE the var LD is set to represent bare
> linker. Perhaps leaving it unset is
> better, we already have LD set in env.
>
> >  strip = ${@meson_array('STRIP', d)}
> >  readelf = ${@meson_array('READELF', d)}
> >  pkgconfig = 'pkg-config'
> > @@ -122,6 +125,10 @@ EOF
> >  CONFIGURE_FILES = "meson.build"
> >
> >  meson_do_configure() {
> > +# Meson requires this to be 'bfd, 'lld' or 'gold' from 0.53 onwards
> > +#
> https://github.com/mesonbuild/meson/commit/ef9aeb188ea2bc7353e59916c18901cde90fa2b3
> > +unset LD
> > +
> >  # Work around "Meson fails if /tmp is mounted with noexec #2972"
> >  mkdir -p "${B}/meson-private/tmp"
> >  export TMPDIR="${B}/meson-private/tmp"
> > diff --git a/meta/recipes-devtools/meson/meson.inc
> b/meta/recipes-devtools/meson/meson.inc
> > index 881a14c7f0a..c0ce7d338bc 100644
> > --- a/meta/recipes-devtools/meson/meson.inc
> > +++ b/meta/recipes-devtools/meson/meson.inc
> > @@ -17,8 +17,8 @@ SRC_URI = "
> https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> >
>  file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \
> >
>  file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
> > "
> > -SRC_URI[sha256sum] =
> "0c277472e49950a5537e3de3e60c57b80dbf425788470a1a8ed27446128fc035"
> > -SRC_URI[md5sum] = "a5f0c99567d772508f649a28ded7f8ad"
> > +SRC_URI[sha256sum] =
> "035e75993ab6fa6c9ebf902b835c64cf397a763eb8e65c9bb6e1cc9730a9d3f6"
> > +SRC_URI[md5sum] = "3a0313d040ded973d84cbec368c2e1d3"
> >
> >  SRC_URI_append_class-native = " \
> >  file://0001-Make-CPU-family-warnings-fatal.patch \
> > diff --git
> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> > index d4264cee526..74d5b4ca66e 100644
> > ---
> a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> > +++
> b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
> > @@ -1,4 +1,4 @@
> > -From cd980c763f11cfd928255346cc7e86f24add985e Mon Sep 17 00:00:00 2001
> > +From 8ce7a1ddbc9b7775568a98fcd50e39a01513c902 Mon Sep 17 00:00:00 2001
> >  From: Ross Burton 
> >  Date: Tue, 3 Jul 2018 13:59:09 +0100
> >  Subject: [PATCH] Make CPU family warnings fatal
> > @@ -12,10 +12,10 @@ Signed-off-by: Ross Burton 
> >   2 files changed, 2 insertions(+), 4 deletions(-)
> >
> >  diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py
> > -index 29d7422..5fb00a4 100644
> > +index 



Re: [OE-core] [PATCH 0/3] virgl: enable in qemu when 'opengl' is in	DISTRO_FEATURES


2020-01-23

Thread
Alexander Kanavin

I forgot to mention that this is all entirely opt-in (via non-default
options to 'runqemu'). By default qemu behaves exactly as before, and does
not use virgl.

Alex

On Thu, 23 Jan 2020 at 16:38, Alexander Kanavin 
wrote:

> virgl is a virtualized accelerated 3D graphics support for the qemu
> guests. This patchset enables virgl in qemu, when 'opengl' is in
> DISTRO_FEATURES.
>
> This adds a few native dependencies to qemu-system-native
> (particularly, libdrm, virglrenderer and a special minimal configuration
> of mesa-native). I tested the impact on build times: it is about 30
> seconds on a 16 core machine. 'bitbake core-image-minimal' goes from
> 25m26s to 25m57s.
>
> The following changes since commit
> ca3993cc4b13d4e661228cee6fb9448adfd0a4ba:
>
>   bitbake: tests/fetch: Allow wget upgrade tests to run against a local
> server (2020-01-22 15:56:39 +)
>
> are available in the Git repository at:
>
>   git://git.yoctoproject.org/poky-contrib akanavin/qemu-split-virgl-gtk
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/qemu-split-virgl-gtk
>
> Alexander Kanavin (3):
>   bitbake.conf: propagate 'opengl' DISTRO_FEATURE to native/nativesdk
> from target
>   libsdl2: enable opengl option for native/nativesdk, subject to
> 'opengl' in DISTRO_FEATURES
>   qemu: enable virglrenderer and glx options subject to 'opengl'
> DISTRO_FEATURE
>
>  meta/conf/bitbake.conf |  4 ++--
>  meta/lib/oeqa/selftest/cases/runtime_test.py   | 18 ++
>  .../qemu/qemu-system-native_4.1.0.bb   |  4 +++-
>  meta/recipes-devtools/qemu/qemu_4.1.0.bb   |  5 -
>  meta/recipes-gnome/gtk+/gtk+3.inc  |  2 ++
>  meta/recipes-graphics/cairo/cairo_1.16.0.bb|  2 ++
>  .../libepoxy/libepoxy_1.5.4.bb |  2 --
>  .../recipes-graphics/libsdl2/libsdl2_2.0.10.bb |  4 ++--
>  .../virglrenderer/virglrenderer_0.8.1.bb   |  2 --
>  9 files changed, 21 insertions(+), 22 deletions(-)
>
> --
> 2.17.1
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core





[OE-core] [PATCH 1/3] bitbake.conf: propagate 'opengl'	DISTRO_FEATURE to native/nativesdk from target


2020-01-23

Thread
Alexander Kanavin

This will allow better control over native virgl/qemu configurations.

Adjust gtk+3/cairo native configurations to actually ignore opengl
when building for -native: we do not need it, and it would cause build
failures as only a limited subset of mesa-native is currently built.

Drop native/nativesdk overrides from virglrenderer/libepoxy recipes
as opengl feature is now correctly set for those variants.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/bitbake.conf | 4 ++--
 meta/recipes-gnome/gtk+/gtk+3.inc  | 2 ++
 meta/recipes-graphics/cairo/cairo_1.16.0.bb| 2 ++
 meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb   | 2 --
 meta/recipes-graphics/virglrenderer/virglrenderer_0.8.1.bb | 2 --
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 2da7c5849a9..15485ae88b2 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -825,8 +825,8 @@ DISTRO_FEATURES_NATIVESDK ?= "x11"
 
 # Normally target distro features will not be applied to native builds:
 # Native distro features on this list will use the target feature value
-DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation"
-DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation"
+DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation opengl"
+DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation opengl"
 
 DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data 
ldconfig"
 MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode"
diff --git a/meta/recipes-gnome/gtk+/gtk+3.inc 
b/meta/recipes-gnome/gtk+/gtk+3.inc
index e1f1e0db314..e525a471efa 100644
--- a/meta/recipes-gnome/gtk+/gtk+3.inc
+++ b/meta/recipes-gnome/gtk+/gtk+3.inc
@@ -47,6 +47,8 @@ do_compile_prepend() {
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'opengl wayland x11', 
d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl x11', 
'glx', '', d)}"
+PACKAGECONFIG_class-native = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
+PACKAGECONFIG_class-nativesdk = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', 
d)}"
 
 PACKAGECONFIG[x11] = "--enable-x11-backend,--disable-x11-backend,at-spi2-atk 
fontconfig libx11 libxext libxcursor libxi libxdamage libxrandr libxrender 
libxcomposite libxfixes"
 # this is provided by oe-core patch that removes epoxy/gl dependency from a 
X11 build
diff --git a/meta/recipes-graphics/cairo/cairo_1.16.0.bb 
b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
index e3de3f6164a..dcca6c1a311 100644
--- a/meta/recipes-graphics/cairo/cairo_1.16.0.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
@@ -41,6 +41,8 @@ X11DEPENDS = "virtual/libx11 libsm libxrender libxext"
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'directfb', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xcb', 
'', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'opengl', '', d)}"
+PACKAGECONFIG_class-native = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
'x11 xcb', '', d)}"
+PACKAGECONFIG_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 
'x11', 'x11 xcb', '', 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/libepoxy/libepoxy_1.5.4.bb 
b/meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb
index af9867407ed..1aa850d0043 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb
@@ -19,8 +19,6 @@ UPSTREAM_CHECK_URI = 
"https://github.com/anholt/libepoxy/releases;
 inherit meson pkgconfig features_check
 
 REQUIRED_DISTRO_FEATURES = "opengl"
-REQUIRED_DISTRO_FEATURES_class-native = ""
-REQUIRED_DISTRO_FEATURES_class-nativesdk = ""
 
 PACKAGECONFIG[egl] = "-Degl=yes, -Degl=no, virtual/egl"
 PACKAGECONFIG[x11] = "-Dglx=yes, -Dglx=no -Dx11=false, virtual/libx11 
virtual/libgl"
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.1.bb 
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.1.bb
index 133618844a9..deaac5e965c 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.1.bb
@@ -22,5 +22,3 @@ inherit meson pkgconfig features_check
 BBCLASSEXTEND = "native nativesdk"
 
 REQUIRED_DISTRO_FEATURES = "opengl"
-REQUIRED_DISTRO_FEATURES_class-native = ""
-REQUIRED_DISTRO_FEATURES_class-nativesdk = ""
-- 
2.17.1

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





[OE-core] [PATCH 3/3] qemu: enable virglrenderer and glx options	subject to 'opengl' DISTRO_FEATURE


2020-01-23

Thread
Alexander Kanavin

Note that to actually use accelerated GL passthrough, there are two options

1) a suitable frontend need to be also enabled - gtk+ and SDL both seem to work 
well.
Previously I struggled to make SDL work, but now it seems fine.

2) it is also possible to render off-screen with -display egl-headless option,
and see the output with a VNC viewer (for which, qemu needs to be started
with a VNC server):

$ runqemu kvm egl-headless publicvnc

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oeqa/selftest/cases/runtime_test.py   | 18 ++
 .../qemu/qemu-system-native_4.1.0.bb   |  4 +++-
 meta/recipes-devtools/qemu/qemu_4.1.0.bb   |  5 -
 3 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py 
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 60cb2e01a60..9b87c04e246 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -186,18 +186,14 @@ class TestImage(OESelftestTestCase):
 self.skipTest('virgl isn\'t working with Opensuse 15.0')
 
 qemu_packageconfig = get_bb_var('PACKAGECONFIG', 'qemu-system-native')
-sdl_packageconfig = get_bb_var('PACKAGECONFIG', 'libsdl2-native')
+qemu_distrofeatures = get_bb_var('DISTRO_FEATURES', 
'qemu-system-native')
 features = 'INHERIT += "testimage"\n'
 if 'gtk+' not in qemu_packageconfig:
 features += 'PACKAGECONFIG_append_pn-qemu-system-native = " 
gtk+"\n'
 if 'sdl' not in qemu_packageconfig:
 features += 'PACKAGECONFIG_append_pn-qemu-system-native = " sdl"\n'
-if 'virglrenderer' not in qemu_packageconfig:
-features += 'PACKAGECONFIG_append_pn-qemu-system-native = " 
virglrenderer"\n'
-if 'glx' not in qemu_packageconfig:
-features += 'PACKAGECONFIG_append_pn-qemu-system-native = " glx"\n'
-if 'opengl' not in sdl_packageconfig:
-features += 'PACKAGECONFIG_append_pn-libsdl2-native = " opengl"\n'
+if 'opengl' not in qemu_distrofeatures:
+features += 'DISTRO_FEATURES_append = " opengl"\n'
 features += 'TEST_SUITES = "ping ssh virgl"\n'
 features += 'IMAGE_FEATURES_append = " ssh-server-dropbear"\n'
 features += 'IMAGE_INSTALL_append = " kmscube"\n'
@@ -229,12 +225,10 @@ class TestImage(OESelftestTestCase):
 dripath = subprocess.check_output("pkg-config 
--variable=dridriverdir dri", shell=True)
 except subprocess.CalledProcessError as e:
 self.skipTest("Could not determine the path to dri drivers on the 
host via pkg-config.\nPlease install Mesa development files (particularly, 
dri.pc) on the host machine.")
-qemu_packageconfig = get_bb_var('PACKAGECONFIG', 'qemu-system-native')
+qemu_distrofeatures = get_bb_var('DISTRO_FEATURES', 
'qemu-system-native')
 features = 'INHERIT += "testimage"\n'
-if 'virglrenderer' not in qemu_packageconfig:
-features += 'PACKAGECONFIG_append_pn-qemu-system-native = " 
virglrenderer"\n'
-if 'glx' not in qemu_packageconfig:
-features += 'PACKAGECONFIG_append_pn-qemu-system-native = " glx"\n'
+if 'opengl' not in qemu_distrofeatures:
+features += 'DISTRO_FEATURES_append = " opengl"\n'
 features += 'TEST_SUITES = "ping ssh virgl"\n'
 features += 'IMAGE_FEATURES_append = " ssh-server-dropbear"\n'
 features += 'IMAGE_INSTALL_append = " kmscube"\n'
diff --git a/meta/recipes-devtools/qemu/qemu-system-native_4.1.0.bb 
b/meta/recipes-devtools/qemu/qemu-system-native_4.1.0.bb
index d83ee59375c..7394385d30b 100644
--- a/meta/recipes-devtools/qemu/qemu-system-native_4.1.0.bb
+++ b/meta/recipes-devtools/qemu/qemu-system-native_4.1.0.bb
@@ -9,7 +9,9 @@ DEPENDS = "glib-2.0-native zlib-native pixman-native 
qemu-native bison-native"
 
 EXTRA_OECONF_append = " --target-list=${@get_qemu_system_target_list(d)}"
 
-PACKAGECONFIG ??= "fdt alsa kvm"
+PACKAGECONFIG ??= "fdt alsa kvm \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', '' 
,d)} \
+"
 
 # Handle distros such as CentOS 5 32-bit that do not have kvm support
 PACKAGECONFIG_remove = "${@'kvm' if not 
os.path.exists('/usr/include/linux/kvm.h') else ''}"
diff --git a/meta/recipes-devtools/qemu/qemu_4.1.0.bb 
b/meta/recipes-devtools/qemu/qemu_4.1.0.bb
index f0c1daabe15..a4018cc4485 100644
--- a/meta/recipes-devtools/qemu/qemu_4.1.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_4.1.0.bb
@@ -21,5 +21,8 @@ do_install_append_class-nativesdk() {
 PACKAGECONFIG ??= " \
 fdt sdl kvm \
 ${@bb.utils.filter('DISTRO_FEATURES', 'alsa xen', d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', '' 
,d)} \
+"
+PACKAGECONFIG_class-nativesdk ??= "fdt sdl kvm \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', '' 
,d)} \
 "
-PACKAGECONFIG_class-nativesdk ??= "fdt sdl kvm"
-- 
2.17.1

-- 




[OE-core] [PATCH 2/3] libsdl2: enable opengl option for	native/nativesdk, subject to 'opengl' in DISTRO_FEATURES


2020-01-23

Thread
Alexander Kanavin

This allows virgl support in qemu with the SDL frontend

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb 
b/meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb
index 413f53476ae..06f9d6ede34 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.10.bb
@@ -44,8 +44,8 @@ EXTRA_OECONF = "--disable-oss --disable-esd --disable-arts \
 # and BSP layers to pick either (desktop) opengl, gles2, or no GL
 PACKAGECONFIG_GL ?= "${@bb.utils.filter('DISTRO_FEATURES', 'opengl', d)}"
 
-PACKAGECONFIG_class-native = "x11"
-PACKAGECONFIG_class-nativesdk = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', 
d)}"
+PACKAGECONFIG_class-native = "x11 ${PACKAGECONFIG_GL}"
+PACKAGECONFIG_class-nativesdk = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', 
d)} ${PACKAGECONFIG_GL}"
 PACKAGECONFIG ??= " \
 ${PACKAGECONFIG_GL} \
 ${@bb.utils.filter('DISTRO_FEATURES', 'alsa directfb pulseaudio x11', d)} \
-- 
2.17.1

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





[OE-core] [PATCH 0/3] virgl: enable in qemu when 'opengl' is in	DISTRO_FEATURES


2020-01-23

Thread
Alexander Kanavin

virgl is a virtualized accelerated 3D graphics support for the qemu
guests. This patchset enables virgl in qemu, when 'opengl' is in
DISTRO_FEATURES.

This adds a few native dependencies to qemu-system-native
(particularly, libdrm, virglrenderer and a special minimal configuration
of mesa-native). I tested the impact on build times: it is about 30
seconds on a 16 core machine. 'bitbake core-image-minimal' goes from
25m26s to 25m57s.

The following changes since commit ca3993cc4b13d4e661228cee6fb9448adfd0a4ba:

  bitbake: tests/fetch: Allow wget upgrade tests to run against a local server 
(2020-01-22 15:56:39 +)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib akanavin/qemu-split-virgl-gtk
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/qemu-split-virgl-gtk

Alexander Kanavin (3):
  bitbake.conf: propagate 'opengl' DISTRO_FEATURE to native/nativesdk
from target
  libsdl2: enable opengl option for native/nativesdk, subject to
'opengl' in DISTRO_FEATURES
  qemu: enable virglrenderer and glx options subject to 'opengl'
DISTRO_FEATURE

 meta/conf/bitbake.conf |  4 ++--
 meta/lib/oeqa/selftest/cases/runtime_test.py   | 18 ++
 .../qemu/qemu-system-native_4.1.0.bb   |  4 +++-
 meta/recipes-devtools/qemu/qemu_4.1.0.bb   |  5 -
 meta/recipes-gnome/gtk+/gtk+3.inc  |  2 ++
 meta/recipes-graphics/cairo/cairo_1.16.0.bb|  2 ++
 .../libepoxy/libepoxy_1.5.4.bb |  2 --
 .../recipes-graphics/libsdl2/libsdl2_2.0.10.bb |  4 ++--
 .../virglrenderer/virglrenderer_0.8.1.bb   |  2 --
 9 files changed, 21 insertions(+), 22 deletions(-)

-- 
2.17.1

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





Re: [OE-core] Connectivity check uris


2020-01-23

Thread
Richard Purdie

On Thu, 2020-01-23 at 09:59 -0500, Jean-Marie LEMETAYER wrote:
> On Jan 23, 2020, at 3:37 PM, Richard Purdie 
> richard.pur...@linuxfoundation.org wrote:
> > On Thu, 2020-01-23 at 09:22 -0500, Jean-Marie LEMETAYER wrote:
> > > I understand the issue with blocked domains this is why I suggest
> > > the
> > > custom domain "connectivitycheck.openembedded.org".
> > > 
> > > But I dont know if it could be an option. Can OE have a sub-
> > > domain
> > > like that? maybe using some cdn to handle the load?
> > 
> > We can certainly setup domains but we can't easily get a cdn. I'd
> > be
> > worried about OE's response time too.
> > 
> > > Another option will be to provide multiple URIs:
> > > CONNECTIVITY_CHECK_URIS ?= " \
> > > https://google.com \
> > > https://www.bing.com \
> > > https://www.baidu.com \
> > > "
> > 
> > Looking at the code, I wonder if a CONNECTIVITY_CHECK_MIRRORS,
> > injected
> > into MIRRORS internally with google as the default and baidu as the
> > mirror would work?
> 
> It should work but it will not be efficient as the tries are serially
> executed. So someone in China should have to wait that the former
> domains failed to be able to start the build.

I'm guessing those wouldn't resolve so it should be pretty fast? 

Maybe we make the configuration more obvious in local.conf?

> I am still thinking that the OE subdomain with CDN could be the best
> option.

Sure, but who is going to pay for and maintain a CDN setup?

Cheers,

Richard

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





Re: [OE-core] Connectivity check uris


2020-01-23

Thread
Jean-Marie LEMETAYER

On Jan 23, 2020, at 3:37 PM, Richard Purdie richard.pur...@linuxfoundation.org 
wrote:
> On Thu, 2020-01-23 at 09:22 -0500, Jean-Marie LEMETAYER wrote:
>> I understand the issue with blocked domains this is why I suggest the
>> custom domain "connectivitycheck.openembedded.org".
>> 
>> But I dont know if it could be an option. Can OE have a sub-domain
>> like that? maybe using some cdn to handle the load?
> 
> We can certainly setup domains but we can't easily get a cdn. I'd be
> worried about OE's response time too.
> 
>> Another option will be to provide multiple URIs:
>> CONNECTIVITY_CHECK_URIS ?= " \
>> https://google.com \
>> https://www.bing.com \
>> https://www.baidu.com \
>> "
> 
> Looking at the code, I wonder if a CONNECTIVITY_CHECK_MIRRORS, injected
> into MIRRORS internally with google as the default and baidu as the
> mirror would work?

It should work but it will not be efficient as the tries are serially executed.
So someone in China should have to wait that the former domains failed
to be able to start the build.

I am still thinking that the OE subdomain with CDN could be the best option.

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





Re: [OE-core] Connectivity check uris


2020-01-23

Thread
Richard Purdie

On Thu, 2020-01-23 at 09:22 -0500, Jean-Marie LEMETAYER wrote:
> I understand the issue with blocked domains this is why I suggest the
> custom domain "connectivitycheck.openembedded.org".
> 
> But I dont know if it could be an option. Can OE have a sub-domain
> like that? maybe using some cdn to handle the load?

We can certainly setup domains but we can't easily get a cdn. I'd be
worried about OE's response time too.

> Another option will be to provide multiple URIs:
> CONNECTIVITY_CHECK_URIS ?= " \
> https://google.com \
> https://www.bing.com \
> https://www.baidu.com \
> "

Looking at the code, I wonder if a CONNECTIVITY_CHECK_MIRRORS, injected
into MIRRORS internally with google as the default and baidu as the
mirror would work?

Cheers,

Richard

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





Re: [OE-core] Connectivity check uris


2020-01-23

Thread
Jean-Marie LEMETAYER

On Jan 23, 2020, at 2:56 PM, Ross Burton ross.bur...@intel.com wrote:
> On 23/01/2020 13:14, Jean-Marie LEMETAYER wrote:
>> So "example.com" is clearly not a good domain to do connectivity checks.
>> 
>> The "openembedded.org" domain is good but have a slow response time.
>> 
>> And finally "google.com" which have all sort of speedy networking stuff is 
>> very
>> efficient.
> 
> Oh my domestic ADSL in the UK I ran your script, example.com finished in
> 1 minute with 100/100.  What internet connectivity to you have?  The
> performance hit with the OE servers isn't ideal, and Google isn't
> suitable as has been said.

I have a fiber connection in france ... and the example.com server seems to be 
in the US.

But my best score is 56% :(




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





Re: [OE-core] Connectivity check uris


2020-01-23

Thread
Jean-Marie LEMETAYER

On Jan 23, 2020, at 2:26 PM, Richard Purdie richard.pur...@linuxfoundation.org 
wrote:
> On Thu, 2020-01-23 at 08:14 -0500, Jean-Marie LEMETAYER wrote:
>> Hi folks,
>> 
>> I have noticed some hang-ups at the beginning of my builds on the
>> master branch.
>> I have search a little and discovered that the connectivity check
>> made by poky
>> was the root cause. In fact connectivity check use the
>> CONNECTIVITY_CHECK_URIS
>> variable which is by default set to "https://www.example.com/;.
>> 
>> So I have made some tests with a little script which gets the URI 100
>> times:
>> 
>>  $ cat connectivity_check.sh
>>  #!/bin/sh
>>  connectivity_check()
>>  {
>>  local ok=0
>>  for i in $(seq 100)
>>  do
>>  $@ > /dev/null && ok=$(($ok + 1))
>>  done
>>  echo $ok $@
>>  }
>>  connectivity_check wget -qO- --timeout=1 --tries=1 $1
>>  connectivity_check curl -s --connect-timeout 1 $1
>> 
>> Note that in the script, I use wget and curl to see if there are any
>> differences
>> but I don't think that's a thing.
>> 
>> Here are the results:
>>  $ time ./connectivity_check.sh https://example.com
>>  45 wget -qO- --timeout=1 --tries=1 https://example.com
>>  45 curl -s --connect-timeout 1 https://example.com
>> 
>>  real2m23.595s
>>  user0m3.352s
>>  sys 0m1.834s
>> 
>>  $ time ./connectivity_check.sh https://openembedded.org
>>  100 wget -qO- --timeout=1 --tries=1 https://openembedded.org
>>  100 curl -s --connect-timeout 1 https://openembedded.org
>> 
>>  real4m36.188s
>>  user0m3.853s
>>  sys 0m1.761s
>> 
>>  $ time ./connectivity_check.sh https://google.com
>>  100 wget -qO- --timeout=1 --tries=1 https://google.com
>>  100 curl -s --connect-timeout 1 https://google.com
>> 
>>  real0m36.328s
>>  user0m4.265s
>>  sys 0m2.028s
>> 
>> So "example.com" is clearly not a good domain to do connectivity
>> checks.
>> 
>> The "openembedded.org" domain is good but have a slow response time.
>> 
>> And finally "google.com" which have all sort of speedy networking
>> stuff is very
>> efficient.
>> 
>> ---
>> 
>> I think the CONNECTIVITY_CHECK_URIS variable must be updated and not
>> use the
>> "example.com" domain anymore. Using "google.com" may be the best
>> option. But
>> eetting up a custom domain like "connectivitycheck.openembedded.org"
>> could be
>> another idea.
>> 
>> Any ideas
> 
> I think if you look at the history we did use google.com however that
> caused problems for people in geos where that is blocked (e.g. PRC).
> 
> We may want to move the default back given the performance isse, not
> sure...

I understand the issue with blocked domains this is why I suggest the
custom domain "connectivitycheck.openembedded.org".

But I dont know if it could be an option. Can OE have a sub-domain like
that? maybe using some cdn to handle the load?

Another option will be to provide multiple URIs:
CONNECTIVITY_CHECK_URIS ?= " \
https://google.com \
https://www.bing.com \
https://www.baidu.com \
"

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





Re: [OE-core] Connectivity check uris


2020-01-23

Thread
Ross Burton


On 23/01/2020 13:14, Jean-Marie LEMETAYER wrote:

So "example.com" is clearly not a good domain to do connectivity checks.

The "openembedded.org" domain is good but have a slow response time.

And finally "google.com" which have all sort of speedy networking stuff is very
efficient.


Oh my domestic ADSL in the UK I ran your script, example.com finished in 
1 minute with 100/100.  What internet connectivity to you have?  The 
performance hit with the OE servers isn't ideal, and Google isn't 
suitable as has been said.


Note that if you're having problems with the check, a quick fix would be 
to just set CONNECTIVITY_CHECK_URIS="" in your distro to turn the check 
off entirely.


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





Re: [OE-core] Connectivity check uris


2020-01-23

Thread
Richard Purdie

On Thu, 2020-01-23 at 08:14 -0500, Jean-Marie LEMETAYER wrote:
> Hi folks,
> 
> I have noticed some hang-ups at the beginning of my builds on the
> master branch.
> I have search a little and discovered that the connectivity check
> made by poky
> was the root cause. In fact connectivity check use the
> CONNECTIVITY_CHECK_URIS
> variable which is by default set to "https://www.example.com/;.
> 
> So I have made some tests with a little script which gets the URI 100
> times:
> 
>   $ cat connectivity_check.sh
>   #!/bin/sh
>   connectivity_check()
>   {
>   local ok=0
>   for i in $(seq 100)
>   do
>   $@ > /dev/null && ok=$(($ok + 1))
>   done
>   echo $ok $@
>   }
>   connectivity_check wget -qO- --timeout=1 --tries=1 $1
>   connectivity_check curl -s --connect-timeout 1 $1
> 
> Note that in the script, I use wget and curl to see if there are any
> differences
> but I don't think that's a thing.
> 
> Here are the results:
>   $ time ./connectivity_check.sh https://example.com
>   45 wget -qO- --timeout=1 --tries=1 https://example.com
>   45 curl -s --connect-timeout 1 https://example.com
> 
>   real2m23.595s
>   user0m3.352s
>   sys 0m1.834s
> 
>   $ time ./connectivity_check.sh https://openembedded.org
>   100 wget -qO- --timeout=1 --tries=1 https://openembedded.org
>   100 curl -s --connect-timeout 1 https://openembedded.org
> 
>   real4m36.188s
>   user0m3.853s
>   sys 0m1.761s
> 
>   $ time ./connectivity_check.sh https://google.com
>   100 wget -qO- --timeout=1 --tries=1 https://google.com
>   100 curl -s --connect-timeout 1 https://google.com
> 
>   real0m36.328s
>   user0m4.265s
>   sys 0m2.028s
> 
> So "example.com" is clearly not a good domain to do connectivity
> checks.
> 
> The "openembedded.org" domain is good but have a slow response time.
> 
> And finally "google.com" which have all sort of speedy networking
> stuff is very
> efficient.
> 
> ---
> 
> I think the CONNECTIVITY_CHECK_URIS variable must be updated and not
> use the
> "example.com" domain anymore. Using "google.com" may be the best
> option. But
> eetting up a custom domain like "connectivitycheck.openembedded.org"
> could be
> another idea.
> 
> Any ideas 

I think if you look at the history we did use google.com however that
caused problems for people in geos where that is blocked (e.g. PRC).

We may want to move the default back given the performance isse, not
sure...

Cheers,

Richard

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





Re: [OE-core] Connectivity check uris


2020-01-23

Thread
Andrey Zhizhikin

On Thu, Jan 23, 2020 at 2:14 PM Jean-Marie LEMETAYER
 wrote:
>
> Hi folks,
>
> I have noticed some hang-ups at the beginning of my builds on the master 
> branch.
> I have search a little and discovered that the connectivity check made by poky
> was the root cause. In fact connectivity check use the CONNECTIVITY_CHECK_URIS
> variable which is by default set to "https://www.example.com/;.
>
> So I have made some tests with a little script which gets the URI 100 times:
>
> $ cat connectivity_check.sh
> #!/bin/sh
> connectivity_check()
> {
> local ok=0
> for i in $(seq 100)
> do
> $@ > /dev/null && ok=$(($ok + 1))
> done
> echo $ok $@
> }
> connectivity_check wget -qO- --timeout=1 --tries=1 $1
> connectivity_check curl -s --connect-timeout 1 $1
>
> Note that in the script, I use wget and curl to see if there are any 
> differences
> but I don't think that's a thing.
>
> Here are the results:
> $ time ./connectivity_check.sh https://example.com
> 45 wget -qO- --timeout=1 --tries=1 https://example.com
> 45 curl -s --connect-timeout 1 https://example.com
>
> real2m23.595s
> user0m3.352s
> sys 0m1.834s
>
> $ time ./connectivity_check.sh https://openembedded.org
> 100 wget -qO- --timeout=1 --tries=1 https://openembedded.org
> 100 curl -s --connect-timeout 1 https://openembedded.org
>
> real4m36.188s
> user0m3.853s
> sys 0m1.761s
>
> $ time ./connectivity_check.sh https://google.com
> 100 wget -qO- --timeout=1 --tries=1 https://google.com
> 100 curl -s --connect-timeout 1 https://google.com
>
> real0m36.328s
> user0m4.265s
> sys 0m2.028s
>
> So "example.com" is clearly not a good domain to do connectivity checks.
>
> The "openembedded.org" domain is good but have a slow response time.
>
> And finally "google.com" which have all sort of speedy networking stuff is 
> very
> efficient.
>
> ---
>
> I think the CONNECTIVITY_CHECK_URIS variable must be updated and not use the
> "example.com" domain anymore. Using "google.com" may be the best option. But
> eetting up a custom domain like "connectivitycheck.openembedded.org" could be
> another idea.

Had this idea long time in the past... Unfortunately, google.com is
not available in all countries worldwide (Say "Nihao" to chinese Great
firewall ).

>
> Any ideas ?
>
> Jean-Marie LEMETAYER
> Passionate embedded systems engineer
> Savoir-faire Linux
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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





[OE-core] Connectivity check uris


2020-01-23

Thread
Jean-Marie LEMETAYER

Hi folks,

I have noticed some hang-ups at the beginning of my builds on the master branch.
I have search a little and discovered that the connectivity check made by poky
was the root cause. In fact connectivity check use the CONNECTIVITY_CHECK_URIS
variable which is by default set to "https://www.example.com/;.

So I have made some tests with a little script which gets the URI 100 times:

$ cat connectivity_check.sh
#!/bin/sh
connectivity_check()
{
local ok=0
for i in $(seq 100)
do
$@ > /dev/null && ok=$(($ok + 1))
done
echo $ok $@
}
connectivity_check wget -qO- --timeout=1 --tries=1 $1
connectivity_check curl -s --connect-timeout 1 $1

Note that in the script, I use wget and curl to see if there are any differences
but I don't think that's a thing.

Here are the results:
$ time ./connectivity_check.sh https://example.com
45 wget -qO- --timeout=1 --tries=1 https://example.com
45 curl -s --connect-timeout 1 https://example.com

real2m23.595s
user0m3.352s
sys 0m1.834s

$ time ./connectivity_check.sh https://openembedded.org
100 wget -qO- --timeout=1 --tries=1 https://openembedded.org
100 curl -s --connect-timeout 1 https://openembedded.org

real4m36.188s
user0m3.853s
sys 0m1.761s

$ time ./connectivity_check.sh https://google.com
100 wget -qO- --timeout=1 --tries=1 https://google.com
100 curl -s --connect-timeout 1 https://google.com

real0m36.328s
user0m4.265s
sys 0m2.028s

So "example.com" is clearly not a good domain to do connectivity checks.

The "openembedded.org" domain is good but have a slow response time.

And finally "google.com" which have all sort of speedy networking stuff is very
efficient.

---

I think the CONNECTIVITY_CHECK_URIS variable must be updated and not use the
"example.com" domain anymore. Using "google.com" may be the best option. But
eetting up a custom domain like "connectivitycheck.openembedded.org" could be
another idea.

Any ideas ?

Jean-Marie LEMETAYER
Passionate embedded systems engineer
Savoir-faire Linux
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core





[OE-core] [PATCH v2] logrotate.py: improve oeqa test implementation


2020-01-23

Thread
Trevor Gamblin

From: Trevor Gamblin 

See bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632

Autobuilder tests occasionally fail, reporting that a new logfile
could not be created. While this failure did occur multiple times, it
could not be manually reproduced. However, there are issues with the
implementation of the logrotate.py script that can be fixed. These
changes will help make the failures clearer, should they continue to
occur.

Previously, the test_2_logrotate test would, after running the
logrotate tool, use "ls -al $HOME/logrotate_dir | wc -l" to count
the number of files in the rotation directory and determine if the
rotation was successful. The test to see if there are at least three
files is problematic, because depending on the version of ls used, it
may report the target value of 3 even when there are only hidden files
in the directory, potentially reporting a pass for the test when it
should actually fail. An example with coreutils:

root@qemux86-64:~# ls -al emptydir/
total 2
drwxr-xr-x 2 root root 1024 Jan 14 19:50 .
drwx-- 3 root root 1024 Jan 14 19:50 ..
root@qemux86-64:~#

Where "total" is the number of blocks used. Compare with busybox ls:

root@qemux86-64:~# ls -al emptydir/
drwxr-xr-x2 root root  1024 Jan 14 19:54 .
drwx--3 root root  1024 Jan 14 19:54 ..
root@qemux86-64:~#

Instead of using ls to verify that a certain number of files exists
in $HOME/logrotate_dir, the tests have been changed to rotate two
specific logs: the log for wtmp and a new logrotate_testfile created
during the second test. Both tests check that the logs are correctly
rotated into $HOME/logrotate_dir by using find and grep on the
expected filename (e.g. "wtmp" when rotated becomes "wtmp.1", so we
check to see that wtmp.1 is present in $HOME/logrotate_dir). In
addition, should the test fail, the output from logrotate -vf is
included in the test log to aid debugging.

Finally, note that while the autobuilder failures that this patch
addresses were only seen during core-image-full-cmdline tests, these
changes were successfully tested on core-image-minimal and
core-image-sato with the manual addition of logrotate and openssh-sshd
to the images.

Signed-off-by: Trevor Gamblin 
---
 meta/lib/oeqa/runtime/cases/logrotate.py | 59 ++--
 1 file changed, 44 insertions(+), 15 deletions(-)

diff --git a/meta/lib/oeqa/runtime/cases/logrotate.py 
b/meta/lib/oeqa/runtime/cases/logrotate.py
index bfa57c534a..6231e5203c 100644
--- a/meta/lib/oeqa/runtime/cases/logrotate.py
+++ b/meta/lib/oeqa/runtime/cases/logrotate.py
@@ -18,32 +18,61 @@ class LogrotateTest(OERuntimeTestCase):
 @classmethod
 def tearDownClass(cls):
 cls.tc.target.run('mv -f $HOME/wtmp.oeqabak /etc/logrotate.d/wtmp && 
rm -rf $HOME/logrotate_dir')
+cls.tc.target.run('rm -rf /var/log/logrotate_testfile && rm -rf 
/etc/logrotate.d/logrotate_testfile')
 
 @OETestDepends(['ssh.SSHTest.test_ssh'])
 @OEHasPackage(['logrotate'])
-def test_1_logrotate_setup(self):
+def test_logrotate_wtmp(self):
+
 status, output = self.target.run('mkdir $HOME/logrotate_dir')
 msg = 'Could not create logrotate_dir. Output: %s' % output
 self.assertEqual(status, 0, msg = msg)
 
-cmd = ('sed -i "s#wtmp {#wtmp {\\nolddir $HOME/logrotate_dir#"'
-   ' /etc/logrotate.d/wtmp')
-status, output = self.target.run(cmd)
-msg = ('Could not write to logrotate.d/wtmp file. Status and output: '
-   ' %s and %s' % (status, output))
+status, output = self.target.run('echo "create \n olddir 
$HOME/logrotate_dir \n include /etc/logrotate.d/wtmp" > 
/tmp/logrotate-test.conf')
+msg = ('Could not write to /tmp/logrotate-test.conf')
+self.assertEqual(status, 0, msg = msg)
+
+status, output = self.target.run('echo "/var/log/logrotate_test {\\n 
missingok \\n monthly \\n rotate 1" > /etc/logrotate.d/logrotate_test')
+msg = ('Could not write to /etc/logrotate.d/logrotate_test')
+self.assertEqual(status, 0, msg = msg)
+
+status, logrotate_output = self.target.run('logrotate -vf 
/tmp/logrotate-test.conf')
+msg = ('logrotate service could not be reloaded. Status and output: '
+'%s and %s' % (status, logrotate_output))
+self.assertEqual(status, 0, msg = msg)
+
+# If logrotate fails to rotate the log, view the verbose output of 
logrotate instead of just listing the files in olddir
+status, output = self.target.run('find $HOME/logrotate_dir -type f | 
grep wtmp.1')
+msg = ("logrotate did not successfully rotate the wtmp log. Output 
from logrotate -vf: \n%s" % (logrotate_output))
+self.assertEqual(status, 0, msg = msg)
+   
+@OETestDepends(['logrotate.LogrotateTest.test_logrotate_wtmp'])
+def test_logrotate_newlog(self):
+
+status, output = self.target.run('echo "oeqa logrotate test 



Re: [OE-core] Could oe-core be infected by virus?


2020-01-23

Thread
JH

Hi Ross,

On 1/23/20, Ross Burton  wrote:
> On 21/01/2020 11:21, JH wrote:
>> The wired
>> thing was that image injected so many new messages, including "Welcome
>> to OpenEmbedded nodistro.0!" I have never seen in previous built image
>> boot.
>
> If you've never seen that before, but now you do, then the problem is
> that you're not setting DISTRO in your build as 'nodistro' is the default.

I do have a DISTRO defined in local.conf, and I do have a distro file
as follows since day one to use OE / Yocto to build the imx6 image, I
have never changed it:

$ cat build/conf/local.conf
...
DISTRO = "solar"


$ cat conf/distro/solar.conf

#TCLIBC = "musl"

DISTRO_FEATURES = "largefile 3g wifi usbhost systemd xattr ext2 ipv4
${DISTRO_FEATURES_LIBC}"

DISTRO_FEATURES_BACKFILL_CONSIDERED = "pulseaudio sysvinit bluez5
gobject-introspection-data"

# Drop WiSPR support from connman to drop GnuTLS dependency
#PACKAGECONFIG_pn-connman = "systemd iptables"
# Use OpenSSL instead of GnuTLS
PACKAGECONFIG_pn-wpa-supplicant = "openssl"

VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""

# If we don't want to build all locales we can select the ones we want here...
# just comment this out in order to build all locales.  These are not
# automatically installed into the image, that is selected elsewhere.
GLIBC_GENERATE_LOCALES = "en_US.UTF-8"

Are there any issues in my distro file?

So my root is root@solar as well, I did not see nodistro.0 before. Let
me further clarify it, in my build system, the source of oe-core,
bitbake, meta-freescal and all configure files are all stored in a
persistent local repository, it has not been changed for a year, the
only changes are those packages downloaded from remote URLs.

This is why I am very concerned, how could the boot sequence and
messages changed dramatically where the source and configure files
have not been changed for a year. But I am more worried that the boot
caused error after 2 - 3 good cycles of booting. Why wasn't the boot
broken in the first boot cycle, only broken after 2 - 3 good bootings?
I cannot comprehend it, appreciate your explanation.

Thank you very much Ross.

Kind regards,

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





Re: [OE-core] Could oe-core be infected by virus?


2020-01-23

Thread
Ross Burton


On 21/01/2020 11:21, JH wrote:

The wired
thing was that image injected so many new messages, including "Welcome
to OpenEmbedded nodistro.0!" I have never seen in previous built image
boot.


If you've never seen that before, but now you do, then the problem is 
that you're not setting DISTRO in your build as 'nodistro' is the default.


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





[OE-core] [PATCH v5 1/2] u-boot-tools: Add capability of building	from out-of-tree


2020-01-23

Thread
Daisuke Yamane

This patch also helps to build with EXTERNALSRC.

Signed-off-by: Daisuke Yamane 
---
 meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
index bede984..414ee33 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
@@ -25,14 +25,14 @@ SED_CONFIG_EFI_armeb = ''
 SED_CONFIG_EFI_aarch64 = ''
 
 do_compile () {
-   oe_runmake sandbox_defconfig
+   oe_runmake -C ${S} sandbox_defconfig O=${B}
 
# Disable CONFIG_CMD_LICENSE, license.h is not used by tools and
# generating it requires bin2header tool, which for target build
# is built with target tools and thus cannot be executed on host.
-   sed -i -e "s/CONFIG_CMD_LICENSE=.*/# CONFIG_CMD_LICENSE is not set/" 
${SED_CONFIG_EFI} .config
+   sed -i -e "s/CONFIG_CMD_LICENSE=.*/# CONFIG_CMD_LICENSE is not set/" 
${SED_CONFIG_EFI} ${B}/.config
 
-   oe_runmake cross_tools NO_SDL=1
+   oe_runmake -C ${S} cross_tools NO_SDL=1 O=${B}
 }
 
 do_install () {
-- 
2.7.4

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





[OE-core] [PATCH v5 2/2] u-boot: Move B from u-boot.inc to	u-boot-common.inc


2020-01-23

Thread
Daisuke Yamane

Use the same value of B between u-boot and u-boot-tools.
This patch also enable the out-of-tree builds of u-boot-tools actually.

Signed-off-by: Daisuke Yamane 
---
 meta/recipes-bsp/u-boot/u-boot-common.inc | 2 ++
 meta/recipes-bsp/u-boot/u-boot.inc| 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
b/meta/recipes-bsp/u-boot/u-boot-common.inc
index ce07055..edd0004 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -18,3 +18,5 @@ SRC_URI = "git://git.denx.de/u-boot.git \
   "
 
 S = "${WORKDIR}/git"
+B = "${WORKDIR}/build"
+do_configure[cleandirs] = "${B}"
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 55d8b47..ec77762 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -1,8 +1,6 @@
 SUMMARY = "Universal Boot Loader for embedded devices"
 PROVIDES = "virtual/bootloader"
 
-B = "${WORKDIR}/build"
-
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 DEPENDS += "kern-tools-native"
-- 
2.7.4

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





[OE-core] ✗ patchtest: failure for "[v4] u-boot-tools: Add capabil..." and 1 more


2020-01-23

Thread
Patchwork

== Series Details ==

Series: "[v4] u-boot-tools: Add capabil..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/22236/
State : failure

== Summary ==


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



* Patch[v4,1/2] u-boot-tools: Add capability of building from 
out-of-tree
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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





[OE-core] [PATCH v4 2/2] u-boot: Move B from u-boot.inc to	u-boot-common.inc


2020-01-23

Thread
Daisuke Yamane

Use the same value of B between u-boot and u-boot-tools.
This patch also enable the out-of-tree builds of u-boot-tools actually.
---
 meta/recipes-bsp/u-boot/u-boot-common.inc | 2 ++
 meta/recipes-bsp/u-boot/u-boot.inc| 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
b/meta/recipes-bsp/u-boot/u-boot-common.inc
index ce07055..edd0004 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -18,3 +18,5 @@ SRC_URI = "git://git.denx.de/u-boot.git \
   "
 
 S = "${WORKDIR}/git"
+B = "${WORKDIR}/build"
+do_configure[cleandirs] = "${B}"
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 55d8b47..ec77762 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -1,8 +1,6 @@
 SUMMARY = "Universal Boot Loader for embedded devices"
 PROVIDES = "virtual/bootloader"
 
-B = "${WORKDIR}/build"
-
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 DEPENDS += "kern-tools-native"
-- 
2.7.4

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





[OE-core] [PATCH v4 1/2] u-boot-tools: Add capability of building	from out-of-tree


2020-01-23

Thread
Daisuke Yamane

This patch also helps to build with EXTERNALSRC.
---
 meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
index bede984..414ee33 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2020.01.bb
@@ -25,14 +25,14 @@ SED_CONFIG_EFI_armeb = ''
 SED_CONFIG_EFI_aarch64 = ''
 
 do_compile () {
-   oe_runmake sandbox_defconfig
+   oe_runmake -C ${S} sandbox_defconfig O=${B}
 
# Disable CONFIG_CMD_LICENSE, license.h is not used by tools and
# generating it requires bin2header tool, which for target build
# is built with target tools and thus cannot be executed on host.
-   sed -i -e "s/CONFIG_CMD_LICENSE=.*/# CONFIG_CMD_LICENSE is not set/" 
${SED_CONFIG_EFI} .config
+   sed -i -e "s/CONFIG_CMD_LICENSE=.*/# CONFIG_CMD_LICENSE is not set/" 
${SED_CONFIG_EFI} ${B}/.config
 
-   oe_runmake cross_tools NO_SDL=1
+   oe_runmake -C ${S} cross_tools NO_SDL=1 O=${B}
 }
 
 do_install () {
-- 
2.7.4

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