Re: [OE-core] [PATCH] cmake: fix Python executable with cmake

[Martin Kelly]

On 4/5/20 8:55 AM, Khem Raj wrote:

On Fri, Apr 3, 2020 at 5:54 PM Khem Raj  wrote:


Hi Martin

I am seeing upm package failures, which I think are related to this change

https://errors.yoctoproject.org/Errors/Details/400570/
https://errors.yoctoproject.org/Errors/Details/400566/
https://errors.yoctoproject.org/Errors/Details/400588/



I looked at it a bit and have sent a fix for upm, hopefully rest of
meta-openembedded packages are ok



Sounds good. Thanks very much for catching and fixing this!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137082): 
https://lists.openembedded.org/g/openembedded-core/message/137082
Mute This Topic: https://lists.openembedded.org/mt/72735244/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] cmake: fix Python executable with cmake

[Martin Kelly]

Currently, CMake has two ways of finding Python executables:
FindPythonInterp and FindPython/FindPython3. FindPythonInterp is
deprecated and may be removed at some point. Currently, python3native
sets PYTHON_EXECUTABLE, which FindPythonInterp uses. This is a problem
for a few reasons:

- Setting PYTHON_EXECUTABLE as an environment variable doesn't work, as
  CMake needs it to be set as an explicit CMake option via -D.
- Projects using the newer FindPython/FindPython3 don't pickup the right
  Python, as the newer routines use Python_EXECUTABLE and
  Python3_EXECUTABLE.

Fix this by setting PYTHON_EXECUTABLE, Python_EXECUTABLE, and
Python3_EXECUTABLE using -D options to EXTRA_OECMAKE.

The CMake routines are documented below:
https://cmake.org/cmake/help/latest/module/FindPythonInterp.html
https://cmake.org/cmake/help/latest/module/FindPython.html
https://cmake.org/cmake/help/latest/module/FindPython3.html

Signed-off-by: Martin Kelly 
---
 meta/classes/cmake.bbclass | 3 +++
 meta/classes/python3native.bbclass | 2 --
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index d91cf20130..94ed8061bb 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -175,6 +175,9 @@ cmake_do_configure() {
  -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'), 
d.getVar('prefix') + '/')} \
  
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'), 
d.getVar('prefix') + '/')} \
  
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix') + '/')} \
+ -DPYTHON_EXECUTABLE:PATH=${PYTHON} \
+ -DPython_EXECUTABLE:PATH=${PYTHON} \
+ -DPython3_EXECUTABLE:PATH=${PYTHON} \
  -DLIB_SUFFIX=${@d.getVar('baselib').replace('lib', '')} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
diff --git a/meta/classes/python3native.bbclass 
b/meta/classes/python3native.bbclass
index 182c11aa2e..d98fb4c758 100644
--- a/meta/classes/python3native.bbclass
+++ b/meta/classes/python3native.bbclass
@@ -1,8 +1,6 @@
 inherit python3-dir
 
 PYTHON="${STAGING_BINDIR_NATIVE}/python3-native/python3"
-# PYTHON_EXECUTABLE is used by cmake
-PYTHON_EXECUTABLE="${PYTHON}"
 EXTRANATIVEPATH += "python3-native"
 DEPENDS_append = " python3-native "
 
-- 
2.25.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#136964): 
https://lists.openembedded.org/g/openembedded-core/message/136964
Mute This Topic: https://lists.openembedded.org/mt/72735244/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 3/7] meson: fix nativesdk-meson for multilib SDKs

[Martin Kelly]

On 1/7/19 8:38 AM, Ross Burton wrote:
> Multilib SDKs differ only in the environment variables set, so 
> nativesdk-meson's
> setup script needs to write a cross file for each environment.
> 
> Rename the shipped meson.cross to meson.cross.template, as it cannot be used
> directly.  Now that post-relocate scripts are called once for each 
> environment,
> the generated meson.cross can be prefixed with TARGET_PREFIX to ensure it is
> unique.
> 
> Finally rewrite the setup script to use string.Template to perform the 
> expansion
> instead of hand-coding the logic.
> 
> Signed-off-by: Ross Burton 
> ---
>   meta/recipes-devtools/meson/meson/meson-setup.py   | 69 
> ++
>   meta/recipes-devtools/meson/meson/meson-wrapper|  2 +-
>   .../meson/nativesdk-meson_0.49.0.bb| 41 +
>   3 files changed, 36 insertions(+), 76 deletions(-)
> 
> diff --git a/meta/recipes-devtools/meson/meson/meson-setup.py 
> b/meta/recipes-devtools/meson/meson/meson-setup.py
> index a9749eae9d4..808e2a062f6 100755
> --- a/meta/recipes-devtools/meson/meson/meson-setup.py
> +++ b/meta/recipes-devtools/meson/meson/meson-setup.py
> @@ -1,62 +1,31 @@
>   #!/usr/bin/env python3
>   
>   import os
> +import string
>   import sys
>   
> -def bail(msg):
> -print(msg, file=sys.stderr)
> -sys.exit(1)
> -
> -_MARKER = '@@'
> -def transform_line(line):
> -# Substitute any special markers of this form:
> -# @@ENV@@
> -# with the value of ENV, split into meson array syntax.
> -start = line.find(_MARKER)
> -if start == -1:
> -return line
> -
> -end = line.rfind(_MARKER)
> -if end == start:
> -return line
> -
> -# Lookup value of the env var.
> -var = line[start+len(_MARKER):end]
> -try:
> -val = os.environ[var]
> -except KeyError:
> -bail('cannot generate meson.cross; env var %s not set' % var)
> +class Template(string.Template):
> +delimiter = "@"
>   
> -# Transform into meson array.
> -val = ["'%s'" % x for x in val.split()]
> -val = ', '.join(val)
> -val = '[%s]' % val
> +class Environ():
> +def __getitem__(self, name):
> +val = os.environ[name]
> +val = ["'%s'" % x for x in val.split()]
> +val = ', '.join(val)
> +val = '[%s]' % val
> +return val
>   
> -before = line[:start]
> -after = line[end+len(_MARKER):]
> -
> -return '%s%s%s' % (before, val, after)
> -
> -# Make sure this is really an SDK extraction environment.
>   try:
>   sysroot = os.environ['OECORE_NATIVE_SYSROOT']
>   except KeyError:
> -bail('OECORE_NATIVE_SYSROOT env var must be set')
> -
> -cross_file = os.path.join(sysroot, 'usr/share/meson/meson.cross')
> -tmp_cross_file = '%s.tmp' % cross_file
> +print("Not in environment setup, bailing")

This should print to sys.stderr as the bail function did.

> +sys.exit(1)
>   
> -# Read through and transform the current meson.cross.
> -lines = []
> -with open(cross_file, 'r') as f:
> -for line in f:
> -lines.append(transform_line(line))
> +template_file = os.path.join(sysroot, 'usr/share/meson/meson.cross.template')
> +cross_file = os.path.join(sysroot, 'usr/share/meson/%smeson.cross' % 
> os.environ["TARGET_PREFIX"])
>   
> -# Write the transformed result to a tmp file and atomically rename it. In 
> case
> -# we crash during the file write, we don't want an invalid meson.cross file.
> -with open(tmp_cross_file, 'w') as f:
> -for line in lines:
> -f.write(line)
> -f.flush()
> -os.fdatasync(f.fileno())
> -os.rename(tmp_cross_file, cross_file)
> +with open(template_file) as in_file:
> +template = in_file.read()
> +output = Template(template).substitute(Environ())
> +with open(cross_file, "w") as out_file:
> +out_file.write(output)

I like using string.Template instead of custom logic, but shouldn't we 
keep the atomic rename logic? If someone hits control-C or the 
extraction process crashes during the write, we don't want a corrupt 
file due to a partial write.

> diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper 
> b/meta/recipes-devtools/meson/meson/meson-wrapper
> index b2e00da513f..d4ffe60f9a1 100755
> --- a/meta/recipes-devtools/meson/meson/meson-wrapper
> +++ b/meta/recipes-devtools/meson/meson/meson-wrapper
> @@ -10,5 +10,5 @@ fi
>   unset CC CXX CPP LD AR NM STRIP
>   
>   exec "$OECORE_NATIVE_SYSROOT/usr/bin/meson.real" \
> - --cross-file "$OECORE_NATIVE_SYSROOT/usr/share/meson/meson.cross" \
> + --cross-file 
> "${OECORE_NATIVE_SYSROOT}/usr/share/meson/${TARGET_PREFIX}meson.cross" \
>"$@"
> diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.49.0.bb 
> b/meta/recipes-devtools/meson/nativesdk-meson_0.49.0.bb
> index 721ee8c8f12..55c57775e06 100644
> --- a/meta/recipes-devtools/meson/nativesdk-meson_0.49.0.bb
> +++ b/meta/recipes-devtools/meson/nativesdk-meson_0.49.0.bb
> @@ -5,9 +5,6 @@ inherit nativesdk
>   SRC_URI += "file:

Re: [OE-core] [PATCH 3/7] meson: fix nativesdk-meson for multilib SDKs

[Martin Kelly]

On 1/7/19 12:02 PM, Burton, Ross wrote:
> On Mon, 7 Jan 2019 at 19:03, Martin Kelly  wrote:
>>> +with open(template_file) as in_file:
>>> +template = in_file.read()
>>> +output = Template(template).substitute(Environ())
>>> +with open(cross_file, "w") as out_file:
>>> +out_file.write(output)
>>
>> I like using string.Template instead of custom logic, but shouldn't we
>> keep the atomic rename logic? If someone hits control-C or the
>> extraction process crashes during the write, we don't want a corrupt
>> file due to a partial write.
> 
> If someone control-c's during SDK unpack, the SDK isn't usable.
> 

I don't think it will break cleanly though; instead, some things will 
work and other things won't. I was trying to avoid cryptic error 
messages such as meson hitting a syntax error. However, I agree that 
this should be addressed globally. Separate from this change, maybe we 
should drop a semaphore at the end of extraction and check it in the env 
setup script, so we can display a nice message if something didn't complete.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 7/7] meson: enable nativesdk

[Martin Kelly]

On 1/7/19 9:55 AM, Burton, Ross wrote:
> On Mon, 7 Jan 2019 at 17:54, Martin Kelly  wrote:
>> Could you elaborate on exactly what is breaking, or do you have a link
>> to the autobuilder breakage?
>>
>> To give a bit of background, cmake handles this by putting env vars
>> directly into the wrapper script. However, meson does not support env
>> vars in its cross toolchain file (and upstream is resistant to adding
>> it), so we are left with generating paths at relocate time.
> 
> A multilib SDK has multiple environment scripts, and its only the
> environment scripts that differs.  By the time I'd figured out what
> the problem was I was close to solving it, so there's patches on the
> list to solve this problem.
> 
> Ross
> 

Got it, thanks!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 7/7] meson: enable nativesdk

[Martin Kelly]

On 1/7/19 4:41 AM, Burton, Ross wrote:
> I added a test case to actually build something with Meson on the
> autobuilder, and this breaks for multilib SDKs.  These ship multiple
> environment files, so the cross generation can't happen at relocate
> time.
> 
> Ross
> 

Could you elaborate on exactly what is breaking, or do you have a link 
to the autobuilder breakage?

To give a bit of background, cmake handles this by putting env vars 
directly into the wrapper script. However, meson does not support env 
vars in its cross toolchain file (and upstream is resistant to adding 
it), so we are left with generating paths at relocate time.

> On Fri, 1 Jun 2018 at 22:04, Martin Kelly  wrote:
>>
>> Currently, we can't build meson into SDKs because we don't autogenerate
>> the required meson.cross file.
>>
>> Enable this by using the post-relocate hooks and generating a
>> meson.cross file based on the SDK environment passed into the
>> post-relocate hook.
>>
>> Signed-off-by: Martin Kelly 
>> ---
>>   meta/recipes-devtools/meson/meson.inc  | 22 +++
>>   meta/recipes-devtools/meson/meson/meson-setup.py   | 62 ++
>>   meta/recipes-devtools/meson/meson/meson-wrapper| 14 
>>   meta/recipes-devtools/meson/meson_0.46.1.bb| 22 +--
>>   .../meson/nativesdk-meson_0.46.1.bb| 74 
>> ++
>>   5 files changed, 173 insertions(+), 21 deletions(-)
>>   create mode 100644 meta/recipes-devtools/meson/meson.inc
>>   create mode 100755 meta/recipes-devtools/meson/meson/meson-setup.py
>>   create mode 100755 meta/recipes-devtools/meson/meson/meson-wrapper
>>   create mode 100644 meta/recipes-devtools/meson/nativesdk-meson_0.46.1.bb
>>
>> diff --git a/meta/recipes-devtools/meson/meson.inc 
>> b/meta/recipes-devtools/meson/meson.inc
>> new file mode 100644
>> index 00..4c113dcaf7
>> --- /dev/null
>> +++ b/meta/recipes-devtools/meson/meson.inc
>> @@ -0,0 +1,22 @@
>> +HOMEPAGE = "http://mesonbuild.com";
>> +SUMMARY = "A high performance build system"
>> +
>> +LICENSE = "Apache-2.0"
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=3b83ef96387f14655fc854ddc3c6bd57"
>> +
>> +SRC_URI = 
>> "https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${PV}.tar.gz
>>  \
>> +   
>> file://0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch \
>> +   
>> file://0002-gobject-introspection-determine-g-ir-scanner-and-g-i.patch \
>> +   
>> file://0001-Linker-rules-move-cross_args-in-front-of-output_args.patch \
>> +   file://0003-native_bindir.patch \
>> +   file://0004-Prettifying-some-output-with-pathlib.patch \
>> +   
>> file://0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch \
>> +   "
>> +
>> +SRC_URI[md5sum] = "1698f6526574839de5dcdc45e3f7d582"
>> +SRC_URI[sha256sum] = 
>> "19497a03e7e5b303d8d11f98789a79aba59b5ad4a81bd00f4d099be0212cee78"
>> +UPSTREAM_CHECK_URI = "https://github.com/mesonbuild/meson/releases";
>> +
>> +inherit setuptools3
>> +
>> +RDEPENDS_${PN} = "ninja python3-core python3-modules"
>> diff --git a/meta/recipes-devtools/meson/meson/meson-setup.py 
>> b/meta/recipes-devtools/meson/meson/meson-setup.py
>> new file mode 100755
>> index 00..a9749eae9d
>> --- /dev/null
>> +++ b/meta/recipes-devtools/meson/meson/meson-setup.py
>> @@ -0,0 +1,62 @@
>> +#!/usr/bin/env python3
>> +
>> +import os
>> +import sys
>> +
>> +def bail(msg):
>> +print(msg, file=sys.stderr)
>> +sys.exit(1)
>> +
>> +_MARKER = '@@'
>> +def transform_line(line):
>> +# Substitute any special markers of this form:
>> +# @@ENV@@
>> +# with the value of ENV, split into meson array syntax.
>> +start = line.find(_MARKER)
>> +if start == -1:
>> +return line
>> +
>> +end = line.rfind(_MARKER)
>> +if end == start:
>> +return line
>> +
>> +# Lookup value of the env var.
>> +var = line[start+len(_MARKER):end]
>> +try:
>> +val = os.environ[var]
>> +except KeyError:
>> +bail('cannot generate meson.cross; env var %s not set' % var)
>> +
>> +# Transform into meson array.
>> +val = ["'%s'" % x for x in val.split()]
>> +val = ', '.join(val)
>> + 

Re: [OE-core] [PATCH] icecc-toolchain: Remove environment setup

[Martin Kelly]

On 06/06/2018 08:24 AM, Joshua Watt wrote:

The handling of the environment setup was moved to the post-relocate
script handler, and so is no longer necessary in the setup script

Signed-off-by: Joshua Watt 
---
  .../icecc-toolchain/icecc-toolchain/icecc-setup.sh   | 5 -
  1 file changed, 5 deletions(-)

diff --git 
a/meta/recipes-devtools/icecc-toolchain/icecc-toolchain/icecc-setup.sh 
b/meta/recipes-devtools/icecc-toolchain/icecc-toolchain/icecc-setup.sh
index 04808265781..25250b7c0e2 100644
--- a/meta/recipes-devtools/icecc-toolchain/icecc-toolchain/icecc-setup.sh
+++ b/meta/recipes-devtools/icecc-toolchain/icecc-toolchain/icecc-setup.sh
@@ -20,11 +20,6 @@
  # SOFTWARE.
  #
  
-# Setup environment

-for env_setup_script in `ls $1/environment-setup-*`; do
-   . $env_setup_script
-done
-
  # ICECC_PATH will have been found icecc-env.sh
  if [ -z "$ICECC_PATH" ]; then
  exit 0



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

Re: [OE-core] [PATCH v3 1/6] toolchain-scripts: retab file

[Martin Kelly]

On 06/05/2018 05:04 AM, Peter Kjellerstedt wrote:

-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
Sent: den 5 juni 2018 12:37
To: Peter Kjellerstedt ; Martin Kelly
; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v3 1/6] toolchain-scripts: retab file

On Tue, 2018-06-05 at 10:09 +, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
Of
Martin Kelly
Sent: den 5 juni 2018 01:06
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH v3 1/6] toolchain-scripts: retab file

Two functions is uses a mix of spaces and tabs. The rest of the
file
uses tabs, so switch to tabs uniformly.

Signed-off-by: Martin Kelly 
---
  meta/classes/toolchain-scripts.bbclass | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index 71da5e5409..a72436167c 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -122,7 +122,7 @@ toolchain_create_post_relocate_script() {
rm -f $script
touch $script

-cat >> $script <> $script <

This part should be indented using tabs as well.


@@ -166,13 +166,13 @@ toolchain_create_sdk_siteconfig () {
  toolchain_create_sdk_siteconfig[vardepsexclude] =
"TOOLCHAIN_CONFIGSITE_SYSROOTCACHE"

  python __anonymous () {
-import oe.classextend
-deps = ""
-for dep in (d.getVar('TOOLCHAIN_NEED_CONFIGSITE_CACHE') or
"").split():
-deps += " %s:do_populate_sysroot" % dep
-for variant in (d.getVar('MULTILIB_VARIANTS') or
"").split():
-clsextend = oe.classextend.ClassExtender(variant, d)
-newdep = clsextend.extend_name(dep)
-deps += " %s:do_populate_sysroot" % newdep
-d.appendVarFlag('do_configure', 'depends', deps)
+   import oe.classextend
+   deps = ""
+   for dep in (d.getVar('TOOLCHAIN_NEED_CONFIGSITE_CACHE') or
"").split():
+   deps += " %s:do_populate_sysroot" % dep
+   for variant in (d.getVar('MULTILIB_VARIANTS') or
"").split():
+   clsextend =
oe.classextend.ClassExtender(variant, d)
+   newdep = clsextend.extend_name(dep)
+   deps += " %s:do_populate_sysroot" %

newdep

+   d.appendVarFlag('do_configure', 'depends', deps)


This is Python code. I believe the OE-Core standard is for Python
code
to be indented using four spaces (whereas shell code should be
indented
using tabs).


I noticed this last bit and simply dropped that patch hunk.

Cheers,

Richard


You might want to update the commit message then as well, as it refers
to the two functions that are modified, which is no longer the case.

//Peter



Thanks all; good point about Python and the commit message. I thought 
about using the one-line || version, but like Richard, I find the 
explicit if statement more readable, and more consistent with what the 
rest of the function does.

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

[OE-core] [PATCH v3 6/6] meson: enable nativesdk

[Martin Kelly]

Currently, we can't build meson into SDKs because we don't autogenerate
the required meson.cross file.

Enable this by using the post-relocate hooks and generating a
meson.cross file based on the SDK environment passed into the
post-relocate hook.

Signed-off-by: Martin Kelly 
---
 meta/recipes-devtools/meson/meson.inc  | 22 +++
 meta/recipes-devtools/meson/meson/meson-setup.py   | 62 ++
 meta/recipes-devtools/meson/meson/meson-wrapper| 14 
 meta/recipes-devtools/meson/meson_0.46.1.bb| 22 +--
 .../meson/nativesdk-meson_0.46.1.bb| 74 ++
 5 files changed, 173 insertions(+), 21 deletions(-)
 create mode 100644 meta/recipes-devtools/meson/meson.inc
 create mode 100755 meta/recipes-devtools/meson/meson/meson-setup.py
 create mode 100755 meta/recipes-devtools/meson/meson/meson-wrapper
 create mode 100644 meta/recipes-devtools/meson/nativesdk-meson_0.46.1.bb

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
new file mode 100644
index 00..4c113dcaf7
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -0,0 +1,22 @@
+HOMEPAGE = "http://mesonbuild.com";
+SUMMARY = "A high performance build system"
+
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://COPYING;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${PV}.tar.gz 
\
+   file://0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch 
\
+   
file://0002-gobject-introspection-determine-g-ir-scanner-and-g-i.patch \
+   
file://0001-Linker-rules-move-cross_args-in-front-of-output_args.patch \
+   file://0003-native_bindir.patch \
+   file://0004-Prettifying-some-output-with-pathlib.patch \
+   
file://0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch \
+   "
+
+SRC_URI[md5sum] = "1698f6526574839de5dcdc45e3f7d582"
+SRC_URI[sha256sum] = 
"19497a03e7e5b303d8d11f98789a79aba59b5ad4a81bd00f4d099be0212cee78"
+UPSTREAM_CHECK_URI = "https://github.com/mesonbuild/meson/releases";
+
+inherit setuptools3
+
+RDEPENDS_${PN} = "ninja python3-core python3-modules"
diff --git a/meta/recipes-devtools/meson/meson/meson-setup.py 
b/meta/recipes-devtools/meson/meson/meson-setup.py
new file mode 100755
index 00..a9749eae9d
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/meson-setup.py
@@ -0,0 +1,62 @@
+#!/usr/bin/env python3
+
+import os
+import sys
+
+def bail(msg):
+print(msg, file=sys.stderr)
+sys.exit(1)
+
+_MARKER = '@@'
+def transform_line(line):
+# Substitute any special markers of this form:
+# @@ENV@@
+# with the value of ENV, split into meson array syntax.
+start = line.find(_MARKER)
+if start == -1:
+return line
+
+end = line.rfind(_MARKER)
+if end == start:
+return line
+
+# Lookup value of the env var.
+var = line[start+len(_MARKER):end]
+try:
+val = os.environ[var]
+except KeyError:
+bail('cannot generate meson.cross; env var %s not set' % var)
+
+# Transform into meson array.
+val = ["'%s'" % x for x in val.split()]
+val = ', '.join(val)
+val = '[%s]' % val
+
+before = line[:start]
+after = line[end+len(_MARKER):]
+
+return '%s%s%s' % (before, val, after)
+
+# Make sure this is really an SDK extraction environment.
+try:
+sysroot = os.environ['OECORE_NATIVE_SYSROOT']
+except KeyError:
+bail('OECORE_NATIVE_SYSROOT env var must be set')
+
+cross_file = os.path.join(sysroot, 'usr/share/meson/meson.cross')
+tmp_cross_file = '%s.tmp' % cross_file
+
+# Read through and transform the current meson.cross.
+lines = []
+with open(cross_file, 'r') as f:
+for line in f:
+lines.append(transform_line(line))
+
+# Write the transformed result to a tmp file and atomically rename it. In case
+# we crash during the file write, we don't want an invalid meson.cross file.
+with open(tmp_cross_file, 'w') as f:
+for line in lines:
+f.write(line)
+f.flush()
+os.fdatasync(f.fileno())
+os.rename(tmp_cross_file, cross_file)
diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper 
b/meta/recipes-devtools/meson/meson/meson-wrapper
new file mode 100755
index 00..b2e00da513
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/meson-wrapper
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+if [ -z "$OECORE_NATIVE_SYSROOT" ]; then
+echo "OECORE_NATIVE_SYSROOT not set; are you in a Yocto SDK environment?" 
>&2
+fi
+
+# If these are set to a cross-compile path, meson will get confused and try to
+# use them as native tools. Unset them to prevent this, as all the 
cross-compile
+# config is alread

[OE-core] [PATCH v3 4/6] toolchain-scripts: pass env to post-relocate

[Martin Kelly]

It's useful for the post-relocate scripts to be able to see the SDK
environment, for example to see the values of CC, CXX etc. in order to
dynamically generate toolchain files.

To enable this, source the SDK environment script prior to calling the
relocate scripts.

Signed-off-by: Martin Kelly 
---
v3:
- Source all top-level env setup scripts instead of just one.

 meta/classes/toolchain-scripts.bbclass | 20 
 meta/recipes-core/meta/meta-environment.bb |  2 +-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index ef190a69ec..727bdab4a0 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -118,11 +118,23 @@ EOF
 }
 
 toolchain_create_post_relocate_script() {
-   script=$1
-   rm -f $script
-   touch $script
+   relocate_script=$1
+   env_dir=$2
+   rm -f $relocate_script
+   touch $relocate_script
+
+   cat >> $relocate_script <> $script <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 5/6] meson: handle exe wrappers

[Martin Kelly]

Add patches to enable meson to handle being wrapped with a shell script.  This
will enable us to do so for supporting the SDK, which requires us to setup env
vars and point to a meson.cross file inside the SDK.

These patches are all merged upstream, so we can drop them soon.

Signed-off-by: Martin Kelly 
---
v2:
- Switch to new version of patches to fix exe wrappers, as upstream tweaked the
  previous patch.

 ...0004-Prettifying-some-output-with-pathlib.patch | 188 +
 ...on-command-to-use-when-we-know-what-it-is.patch | 851 +
 meta/recipes-devtools/meson/meson_0.46.1.bb|   2 +
 3 files changed, 1041 insertions(+)
 create mode 100644 
meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch

diff --git 
a/meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
 
b/meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
new file mode 100644
index 00..e75633beb9
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
@@ -0,0 +1,188 @@
+From 253ab5bf6d6d925abcf625b72f5fcacf99be13bd Mon Sep 17 00:00:00 2001
+From: Niklas Claesson 
+Date: Wed, 18 Apr 2018 15:25:03 +0200
+Subject: [PATCH] Prettifying some output with pathlib
+
+This is a backport required in order to make
+0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch apply.
+
+Upstream-Status: Accepted [https://github.com/mesonbuild/meson/pull/3423]
+Should be in the 0.47.0 release.
+
+Signed-off-by: Martin Kelly 
+---
+ run_cross_test.py|  6 --
+ run_project_tests.py | 51 +--
+ 2 files changed, 33 insertions(+), 24 deletions(-)
+
+diff --git a/run_cross_test.py b/run_cross_test.py
+index e285e218..71914028 100755
+--- a/run_cross_test.py
 b/run_cross_test.py
+@@ -22,13 +22,15 @@ Not part of the main test suite because of two reasons:
+ 
+ Eventually migrate to something fancier.'''
+ 
+-import sys, os
++import sys
++import os
++from pathlib import Path
+ 
+ from run_project_tests import gather_tests, run_tests, StopException, 
setup_commands
+ from run_project_tests import failing_logs
+ 
+ def runtests(cross_file):
+-commontests = [('common', gather_tests('test cases/common'), False)]
++commontests = [('common', gather_tests(Path('test cases', 'common')), 
False)]
+ try:
+ (passing_tests, failing_tests, skipped_tests) = 
run_tests(commontests, 'meson-cross-test-run', ['--cross', cross_file])
+ except StopException:
+diff --git a/run_project_tests.py b/run_project_tests.py
+index 8c02a9ee..3c516240 100755
+--- a/run_project_tests.py
 b/run_project_tests.py
+@@ -14,14 +14,22 @@
+ # See the License for the specific language governing permissions and
+ # limitations under the License.
+ 
+-from glob import glob
+ import itertools
+-import os, subprocess, shutil, sys, signal
++import os
++import subprocess
++import shutil
++import sys
++import signal
+ from io import StringIO
+ from ast import literal_eval
+ from enum import Enum
+ import tempfile
+-from mesonbuild import build, environment, mesonlib, mlog, mtest
++from pathlib import Path, PurePath
++from mesonbuild import build
++from mesonbuild import environment
++from mesonbuild import mesonlib
++from mesonbuild import mlog
++from mesonbuild import mtest
+ from mesonbuild.mesonlib import stringlistify, Popen_safe
+ from mesonbuild.coredata import backendlist
+ import argparse
+@@ -198,7 +206,7 @@ def validate_install(srcdir, installdir, compiler, env):
+ 
+ def log_text_file(logfile, testdir, stdo, stde):
+ global stop, executor, futures
+-logfile.write('%s\nstdout\n\n---\n' % testdir)
++logfile.write('%s\nstdout\n\n---\n' % testdir.as_posix())
+ logfile.write(stdo)
+ logfile.write('\n\n---\n\nstderr\n\n---\n')
+ logfile.write(stde)
+@@ -245,11 +253,11 @@ def run_test_inprocess(testdir):
+ sys.stderr = mystderr = StringIO()
+ old_cwd = os.getcwd()
+ os.chdir(testdir)
+-test_log_fname = 'meson-logs/testlog.txt'
++test_log_fname = Path('meson-logs', 'testlog.txt')
+ try:
+ returncode_test = mtest.run(['--no-rebuild'])
+-if os.path.exists(test_log_fname):
+-test_log = open(test_log_fname, errors='ignore').read()
++if test_log_fname.exists():
++test_log = test_log_fname.open(errors='ignore').read()
+ else:
+ test_log = ''
+ returncode_benchmark = mtest.run(['--no-rebuild', '--benchmark', 
'--logbase', 'benchmarklog'])
+@@ -318,9 +326,8 @@ def _run_test(testdir, test_build_dir, install_di

[OE-core] [PATCH v3 3/6] toolchain-scripts: print post-relocate error

[Martin Kelly]

Currently, if a post-relocate script fails, it fails silently. We should
be louder about this, as it likely indicates a broken SDK.

Print a message if a post-relocate script fails.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index da8a57f24b..ef190a69ec 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -129,6 +129,11 @@ if [ -d "${SDKPATHNATIVE}/post-relocate-setup.d/" ]; then
 continue
 fi
 \$s "\$1"
+status=\$?
+if [ \$status != 0 ]; then
+echo "post-relocate command \"\$s \$1\" failed with status 
\$status" >&2
+exit \$status
+fi
 done
 rm -rf "${SDKPATHNATIVE}/post-relocate-setup.d"
 fi
-- 
2.11.0

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

[OE-core] [PATCH v3 1/6] toolchain-scripts: retab file

[Martin Kelly]

Two functions is uses a mix of spaces and tabs. The rest of the file
uses tabs, so switch to tabs uniformly.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index 71da5e5409..a72436167c 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -122,7 +122,7 @@ toolchain_create_post_relocate_script() {
rm -f $script
touch $script
 
-cat >> $script <> $script <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3 0/6] meson: implement nativesdk support

[Martin Kelly]

This patch series implements nativesdk support fer meson. In order to do so, it
adds a few features to the toolchain-shar-extract functionality, which enables
a script to run prior to the SDK being extracted. This is important because the
meson.cross file (which meson uses to find its cross toolchain) allows for only
absolute paths. Thus, it is important to customize those paths to point to the
SDK at SDK extraction time. For comparison, cmake did not need this
functionality because it supports referencing environment variables in the
toolchain file, so we can just reference the SDK root environment variables.
The meson maintainers did not want to take that approach, so this seemed like
the best option.

If curious, see the following threads for more background information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146210.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146225.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146236.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146241.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146261.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146262.html

v3:
- Implement review feedback from Joshua Watt (thanks!).
v2:
- Switch to new version of patches to fix exe wrappers, as upstream tweaked the
  previous patch.

Martin Kelly (6):
  toolchain-scripts: retab file
  toolchain-scripts: allow non-sh post-relocate
  toolchain-scripts: print post-relocate error
  toolchain-scripts: pass env to post-relocate
  meson: handle exe wrappers
  meson: enable nativesdk

 meta/classes/toolchain-scripts.bbclass |  48 +-
 meta/recipes-core/meta/meta-environment.bb |   2 +-
 meta/recipes-devtools/meson/meson.inc  |  22 +
 ...0004-Prettifying-some-output-with-pathlib.patch | 188 +
 ...on-command-to-use-when-we-know-what-it-is.patch | 851 +
 meta/recipes-devtools/meson/meson/meson-setup.py   |  62 ++
 meta/recipes-devtools/meson/meson/meson-wrapper|  14 +
 meta/recipes-devtools/meson/meson_0.46.1.bb|  20 +-
 .../meson/nativesdk-meson_0.46.1.bb|  74 ++
 9 files changed, 1247 insertions(+), 34 deletions(-)
 create mode 100644 meta/recipes-devtools/meson/meson.inc
 create mode 100644 
meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch
 create mode 100755 meta/recipes-devtools/meson/meson/meson-setup.py
 create mode 100755 meta/recipes-devtools/meson/meson/meson-wrapper
 create mode 100644 meta/recipes-devtools/meson/nativesdk-meson_0.46.1.bb

-- 
2.11.0

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

[OE-core] [PATCH v3 2/6] toolchain-scripts: allow non-sh post-relocate

[Martin Kelly]

Currently, we look only for scripts matching *.sh, which means we can't
write post-relocate scripts in other languages.

Expand this to allow any type of script.

Signed-off-by: Martin Kelly 
---
v3:
- Test for executability prior to running each script.

 meta/classes/toolchain-scripts.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index a72436167c..da8a57f24b 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -124,7 +124,10 @@ toolchain_create_post_relocate_script() {
 
cat >> $script <http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

[Martin Kelly]

On 06/04/2018 11:42 AM, Joshua Watt wrote:

On Mon, 2018-06-04 at 11:24 -0700, Martin Kelly wrote:

On 06/04/2018 11:20 AM, Joshua Watt wrote:

On Mon, 2018-06-04 at 11:10 -0700, Martin Kelly wrote:

On 06/04/2018 10:20 AM, Joshua Watt wrote:

On Fri, 2018-06-01 at 15:24 -0700, Martin Kelly wrote:

On 06/01/2018 03:08 PM, Joshua Watt wrote:

On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote:

It's useful for the post-relocate scripts to be able to
see
the
SDK
environment, for example to see the values of CC, CXX
etc. in
order
to
dynamically generate toolchain files.

To enable this, source the SDK environment script prior
to
calling
the
relocate scripts.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 17
+

 meta/recipes-core/meta/meta-environment.bb |  5 +++--
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index ae7bbef034..5f99fd8c03 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -118,11 +118,20 @@ EOF
 }
 
 toolchain_create_post_relocate_script() {

-   script=$1
-   rm -f $script
-   touch $script
+   relocate_script=$1
+   sdk_script=$2
+   rm -f $relocate_script
+   touch $relocate_script
+
+cat >> $relocate_script <

I had originally done something similar to this when I
added
support
for the post-relocate scripts with icecream. However, it is
insufficent
because there can be multiple SDK environment scripts that
need
to
be
sourced. In order to get a fully correct environment, I had
to
do:

 # Setup environment
 for env_setup_script in `ls $1/environment-setup-*`; do
. $env_setup_script
 done

see meta/recipes-devtools/icecc-toolchain/icecc-
toolchain/icecc-
setup.sh




There's one overall "SDK environment" script (the one you
source
as
a
user to enter the SDK environment), and also customizable
ones
installed
by nativesdk-* packages (e.g. one that cmake uses). In this
patch, I
had
not intended that post-relocate scripts should be able to see
the
environment scripts for every project but instead just for
the
global
SDK enivorment (to get at variables like
OECORE_NATIVE_SYSROOT).


(Almost) All of the code I can find that deals with the SDK
environment
supports multiple top level environment-setup-* files. If you
happen to
have more than one, the relocation script will relocate all of
them
(meta/files/toolchain-shar-relocate.sh), and the extraction
script
will
give you instructions to source them all (meta/files/toolchain-
shar-
extract.sh).

It's possible this is some left over anachronism and it has no
actual
use, but we should either fix it everywhere else or be
consistent
here.



OK, that's good to know.



Let me know if I have missed something and not including the
other
environments could cause breakage.

Here's what I mean from an example extracted SDK:

martin@columbia:~$ ls /opt/xos/nanopi-neo-plus2/*environment*
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-
linux

martin@columbia:~$ ls
/opt/xos/nanopi-neo-plus2/sysroots/x86_64-xevo-
linux/environment-
setup.d/
cmake.sh

In the above example, we are currently sourcing only
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-
linux
and
not
cmake.sh.


Sort of environment-setup-aarch64-poky-linux is going to
implicitly
source the cmake.sh script (see the for loop at the end of the
script)



Yes, I see that now. Given that the top-level environment-setup
script
implicitly sources the individual project sh scripts, isn't it
correct
to source only the top-level one? In that way, if the path to the
individual sh scripts changes, this code won't break, and it
leaves
the
top-level script to the single source of truth with regard to
environment setup scripts.


Yes I agree. I think there was some miscommunication, I wasn't
suggesting that we should be sourcing those manually. I just wanted
to
handle the top level environment-setup-* scripts in a consistent
manner
to the rest of the code (i.e. make sure we source all of them).



OK, before I move to the next revision, let me make sure I
understand
you correctly:

- There may be multiple top-level environment setup scripts.

- The environment setup script that is always created
(environment-setup-aarch64-poky-linux in our example) sources all
the
project-specific files.

- Thus, we should source all top-level environment scripts, but not
any
project-specific ones, as they will be pulled in implicitly.

Is that correct?


That sounds correct



OK, I'll send a v3 soon.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

[Martin Kelly]

On 06/04/2018 11:20 AM, Joshua Watt wrote:

On Mon, 2018-06-04 at 11:10 -0700, Martin Kelly wrote:

On 06/04/2018 10:20 AM, Joshua Watt wrote:

On Fri, 2018-06-01 at 15:24 -0700, Martin Kelly wrote:

On 06/01/2018 03:08 PM, Joshua Watt wrote:

On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote:

It's useful for the post-relocate scripts to be able to see
the
SDK
environment, for example to see the values of CC, CXX etc. in
order
to
dynamically generate toolchain files.

To enable this, source the SDK environment script prior to
calling
the
relocate scripts.

Signed-off-by: Martin Kelly 
---
meta/classes/toolchain-scripts.bbclass | 17
+

meta/recipes-core/meta/meta-environment.bb |  5 +++--
2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index ae7bbef034..5f99fd8c03 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -118,11 +118,20 @@ EOF
}

toolchain_create_post_relocate_script() {

-   script=$1
-   rm -f $script
-   touch $script
+   relocate_script=$1
+   sdk_script=$2
+   rm -f $relocate_script
+   touch $relocate_script
+
+cat >> $relocate_script <

I had originally done something similar to this when I added
support
for the post-relocate scripts with icecream. However, it is
insufficent
because there can be multiple SDK environment scripts that need
to
be
sourced. In order to get a fully correct environment, I had to
do:

# Setup environment
for env_setup_script in `ls $1/environment-setup-*`; do
. $env_setup_script
done

see meta/recipes-devtools/icecc-toolchain/icecc-
toolchain/icecc-
setup.sh




There's one overall "SDK environment" script (the one you source
as
a
user to enter the SDK environment), and also customizable ones
installed
by nativesdk-* packages (e.g. one that cmake uses). In this
patch, I
had
not intended that post-relocate scripts should be able to see the
environment scripts for every project but instead just for the
global
SDK enivorment (to get at variables like OECORE_NATIVE_SYSROOT).


(Almost) All of the code I can find that deals with the SDK
environment
supports multiple top level environment-setup-* files. If you
happen to
have more than one, the relocation script will relocate all of them
(meta/files/toolchain-shar-relocate.sh), and the extraction script
will
give you instructions to source them all (meta/files/toolchain-
shar-
extract.sh).

It's possible this is some left over anachronism and it has no
actual
use, but we should either fix it everywhere else or be consistent
here.



OK, that's good to know.



Let me know if I have missed something and not including the
other
environments could cause breakage.

Here's what I mean from an example extracted SDK:

martin@columbia:~$ ls /opt/xos/nanopi-neo-plus2/*environment*
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-linux

martin@columbia:~$ ls
/opt/xos/nanopi-neo-plus2/sysroots/x86_64-xevo-linux/environment-
setup.d/
cmake.sh

In the above example, we are currently sourcing only
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-linux
and
not
cmake.sh.


Sort of environment-setup-aarch64-poky-linux is going to
implicitly
source the cmake.sh script (see the for loop at the end of the
script)



Yes, I see that now. Given that the top-level environment-setup
script
implicitly sources the individual project sh scripts, isn't it
correct
to source only the top-level one? In that way, if the path to the
individual sh scripts changes, this code won't break, and it leaves
the
top-level script to the single source of truth with regard to
environment setup scripts.


Yes I agree. I think there was some miscommunication, I wasn't
suggesting that we should be sourcing those manually. I just wanted to
handle the top level environment-setup-* scripts in a consistent manner
to the rest of the code (i.e. make sure we source all of them).



OK, before I move to the next revision, let me make sure I understand 
you correctly:


- There may be multiple top-level environment setup scripts.

- The environment setup script that is always created 
(environment-setup-aarch64-poky-linux in our example) sources all the 
project-specific files.


- Thus, we should source all top-level environment scripts, but not any 
project-specific ones, as they will be pulled in implicitly.


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

Re: [OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

[Martin Kelly]

On 06/04/2018 10:20 AM, Joshua Watt wrote:

On Fri, 2018-06-01 at 15:24 -0700, Martin Kelly wrote:

On 06/01/2018 03:08 PM, Joshua Watt wrote:

On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote:

It's useful for the post-relocate scripts to be able to see the
SDK
environment, for example to see the values of CC, CXX etc. in
order
to
dynamically generate toolchain files.

To enable this, source the SDK environment script prior to
calling
the
relocate scripts.

Signed-off-by: Martin Kelly 
---
   meta/classes/toolchain-scripts.bbclass | 17 +

   meta/recipes-core/meta/meta-environment.bb |  5 +++--
   2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index ae7bbef034..5f99fd8c03 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -118,11 +118,20 @@ EOF
   }
   
   toolchain_create_post_relocate_script() {

-   script=$1
-   rm -f $script
-   touch $script
+   relocate_script=$1
+   sdk_script=$2
+   rm -f $relocate_script
+   touch $relocate_script
+
+cat >> $relocate_script <

I had originally done something similar to this when I added
support
for the post-relocate scripts with icecream. However, it is
insufficent
because there can be multiple SDK environment scripts that need to
be
sourced. In order to get a fully correct environment, I had to do:

   # Setup environment
   for env_setup_script in `ls $1/environment-setup-*`; do
. $env_setup_script
   done

see meta/recipes-devtools/icecc-toolchain/icecc-toolchain/icecc-
setup.sh




There's one overall "SDK environment" script (the one you source as
a
user to enter the SDK environment), and also customizable ones
installed
by nativesdk-* packages (e.g. one that cmake uses). In this patch, I
had
not intended that post-relocate scripts should be able to see the
environment scripts for every project but instead just for the
global
SDK enivorment (to get at variables like OECORE_NATIVE_SYSROOT).


(Almost) All of the code I can find that deals with the SDK environment
supports multiple top level environment-setup-* files. If you happen to
have more than one, the relocation script will relocate all of them
(meta/files/toolchain-shar-relocate.sh), and the extraction script will
give you instructions to source them all (meta/files/toolchain-shar-
extract.sh).

It's possible this is some left over anachronism and it has no actual
use, but we should either fix it everywhere else or be consistent here.



OK, that's good to know.



Let me know if I have missed something and not including the other
environments could cause breakage.

Here's what I mean from an example extracted SDK:

martin@columbia:~$ ls /opt/xos/nanopi-neo-plus2/*environment*
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-linux

martin@columbia:~$ ls
/opt/xos/nanopi-neo-plus2/sysroots/x86_64-xevo-linux/environment-
setup.d/
cmake.sh

In the above example, we are currently sourcing only
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-linux and
not
cmake.sh.


Sort of environment-setup-aarch64-poky-linux is going to implicitly
source the cmake.sh script (see the for loop at the end of the script)



Yes, I see that now. Given that the top-level environment-setup script 
implicitly sources the individual project sh scripts, isn't it correct 
to source only the top-level one? In that way, if the path to the 
individual sh scripts changes, this code won't break, and it leaves the 
top-level script to the single source of truth with regard to 
environment setup scripts.

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

Re: [OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

[Martin Kelly]

On 06/01/2018 03:08 PM, Joshua Watt wrote:

On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote:

It's useful for the post-relocate scripts to be able to see the SDK
environment, for example to see the values of CC, CXX etc. in order
to
dynamically generate toolchain files.

To enable this, source the SDK environment script prior to calling
the
relocate scripts.

Signed-off-by: Martin Kelly 
---
  meta/classes/toolchain-scripts.bbclass | 17 +
  meta/recipes-core/meta/meta-environment.bb |  5 +++--
  2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index ae7bbef034..5f99fd8c03 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -118,11 +118,20 @@ EOF
  }
  
  toolchain_create_post_relocate_script() {

-   script=$1
-   rm -f $script
-   touch $script
+   relocate_script=$1
+   sdk_script=$2
+   rm -f $relocate_script
+   touch $relocate_script
+
+cat >> $relocate_script <

I had originally done something similar to this when I added support
for the post-relocate scripts with icecream. However, it is insufficent
because there can be multiple SDK environment scripts that need to be
sourced. In order to get a fully correct environment, I had to do:

  # Setup environment
  for env_setup_script in `ls $1/environment-setup-*`; do
. $env_setup_script
  done

see meta/recipes-devtools/icecc-toolchain/icecc-toolchain/icecc-
setup.sh




There's one overall "SDK environment" script (the one you source as a 
user to enter the SDK environment), and also customizable ones installed 
by nativesdk-* packages (e.g. one that cmake uses). In this patch, I had 
not intended that post-relocate scripts should be able to see the 
environment scripts for every project but instead just for the global 
SDK enivorment (to get at variables like OECORE_NATIVE_SYSROOT).


Let me know if I have missed something and not including the other 
environments could cause breakage.


Here's what I mean from an example extracted SDK:

martin@columbia:~$ ls /opt/xos/nanopi-neo-plus2/*environment*
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-linux

martin@columbia:~$ ls 
/opt/xos/nanopi-neo-plus2/sysroots/x86_64-xevo-linux/environment-setup.d/

cmake.sh

In the above example, we are currently sourcing only 
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-linux and not 
cmake.sh.

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

Re: [OE-core] [PATCH v2 4/7] toolchain-shar-extract: print post-relocate error

[Martin Kelly]

On 06/01/2018 02:57 PM, Joshua Watt wrote:

On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote:

Currently, if a post-relocate script fails, it fails silently. We
should
be louder about this, as it likely indicates a broken SDK.

Print a message if a post-relocate script fails.

Signed-off-by: Martin Kelly 
---
  meta/classes/toolchain-scripts.bbclass | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
index cbba07838a..ae7bbef034 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -126,6 +126,11 @@ toolchain_create_post_relocate_script() {
  if [ -d "${SDKPATHNATIVE}/post-relocate-setup.d/" ]; then
  for s in ${SDKPATHNATIVE}/post-relocate-setup.d/*; do


Perhaps worth adding:

  [ -x \$s ] || continue

?



Yes, good idea. I will add it in the next revision, after I wait a day 
or two more for other reviews.



  \$s "\$1"
+status=\$?
+if [ \$status != 0 ]; then
+echo "post-relocate command \"\$s \$1\" failed with
status \$status" >&2
+exit \$status
+fi
  done
  rm -rf "${SDKPATHNATIVE}/post-relocate-setup.d"
  fi

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

[OE-core] [PATCH v2 6/7] meson: handle exe wrappers

[Martin Kelly]

Add patches to enable meson to handle being wrapped with a shell script.  This
will enable us to do so for supporting the SDK, which requires us to setup env
vars and point to a meson.cross file inside the SDK.

These patches are all merged upstream, so we can drop them soon.

Signed-off-by: Martin Kelly 
---
v2:
- Switch to new version of patches to fix exe wrappers, as upstream tweaked the
  previous patch.

 ...0004-Prettifying-some-output-with-pathlib.patch | 188 +
 ...on-command-to-use-when-we-know-what-it-is.patch | 851 +
 meta/recipes-devtools/meson/meson_0.46.1.bb|   2 +
 3 files changed, 1041 insertions(+)
 create mode 100644 
meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch

diff --git 
a/meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
 
b/meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
new file mode 100644
index 00..e75633beb9
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
@@ -0,0 +1,188 @@
+From 253ab5bf6d6d925abcf625b72f5fcacf99be13bd Mon Sep 17 00:00:00 2001
+From: Niklas Claesson 
+Date: Wed, 18 Apr 2018 15:25:03 +0200
+Subject: [PATCH] Prettifying some output with pathlib
+
+This is a backport required in order to make
+0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch apply.
+
+Upstream-Status: Accepted [https://github.com/mesonbuild/meson/pull/3423]
+Should be in the 0.47.0 release.
+
+Signed-off-by: Martin Kelly 
+---
+ run_cross_test.py|  6 --
+ run_project_tests.py | 51 +--
+ 2 files changed, 33 insertions(+), 24 deletions(-)
+
+diff --git a/run_cross_test.py b/run_cross_test.py
+index e285e218..71914028 100755
+--- a/run_cross_test.py
 b/run_cross_test.py
+@@ -22,13 +22,15 @@ Not part of the main test suite because of two reasons:
+ 
+ Eventually migrate to something fancier.'''
+ 
+-import sys, os
++import sys
++import os
++from pathlib import Path
+ 
+ from run_project_tests import gather_tests, run_tests, StopException, 
setup_commands
+ from run_project_tests import failing_logs
+ 
+ def runtests(cross_file):
+-commontests = [('common', gather_tests('test cases/common'), False)]
++commontests = [('common', gather_tests(Path('test cases', 'common')), 
False)]
+ try:
+ (passing_tests, failing_tests, skipped_tests) = 
run_tests(commontests, 'meson-cross-test-run', ['--cross', cross_file])
+ except StopException:
+diff --git a/run_project_tests.py b/run_project_tests.py
+index 8c02a9ee..3c516240 100755
+--- a/run_project_tests.py
 b/run_project_tests.py
+@@ -14,14 +14,22 @@
+ # See the License for the specific language governing permissions and
+ # limitations under the License.
+ 
+-from glob import glob
+ import itertools
+-import os, subprocess, shutil, sys, signal
++import os
++import subprocess
++import shutil
++import sys
++import signal
+ from io import StringIO
+ from ast import literal_eval
+ from enum import Enum
+ import tempfile
+-from mesonbuild import build, environment, mesonlib, mlog, mtest
++from pathlib import Path, PurePath
++from mesonbuild import build
++from mesonbuild import environment
++from mesonbuild import mesonlib
++from mesonbuild import mlog
++from mesonbuild import mtest
+ from mesonbuild.mesonlib import stringlistify, Popen_safe
+ from mesonbuild.coredata import backendlist
+ import argparse
+@@ -198,7 +206,7 @@ def validate_install(srcdir, installdir, compiler, env):
+ 
+ def log_text_file(logfile, testdir, stdo, stde):
+ global stop, executor, futures
+-logfile.write('%s\nstdout\n\n---\n' % testdir)
++logfile.write('%s\nstdout\n\n---\n' % testdir.as_posix())
+ logfile.write(stdo)
+ logfile.write('\n\n---\n\nstderr\n\n---\n')
+ logfile.write(stde)
+@@ -245,11 +253,11 @@ def run_test_inprocess(testdir):
+ sys.stderr = mystderr = StringIO()
+ old_cwd = os.getcwd()
+ os.chdir(testdir)
+-test_log_fname = 'meson-logs/testlog.txt'
++test_log_fname = Path('meson-logs', 'testlog.txt')
+ try:
+ returncode_test = mtest.run(['--no-rebuild'])
+-if os.path.exists(test_log_fname):
+-test_log = open(test_log_fname, errors='ignore').read()
++if test_log_fname.exists():
++test_log = test_log_fname.open(errors='ignore').read()
+ else:
+ test_log = ''
+ returncode_benchmark = mtest.run(['--no-rebuild', '--benchmark', 
'--logbase', 'benchmarklog'])
+@@ -318,9 +326,8 @@ def _run_test(testdir, test_build_dir, install_di

[OE-core] [PATCH v2 7/7] meson: enable nativesdk

[Martin Kelly]

Currently, we can't build meson into SDKs because we don't autogenerate
the required meson.cross file.

Enable this by using the post-relocate hooks and generating a
meson.cross file based on the SDK environment passed into the
post-relocate hook.

Signed-off-by: Martin Kelly 
---
 meta/recipes-devtools/meson/meson.inc  | 22 +++
 meta/recipes-devtools/meson/meson/meson-setup.py   | 62 ++
 meta/recipes-devtools/meson/meson/meson-wrapper| 14 
 meta/recipes-devtools/meson/meson_0.46.1.bb| 22 +--
 .../meson/nativesdk-meson_0.46.1.bb| 74 ++
 5 files changed, 173 insertions(+), 21 deletions(-)
 create mode 100644 meta/recipes-devtools/meson/meson.inc
 create mode 100755 meta/recipes-devtools/meson/meson/meson-setup.py
 create mode 100755 meta/recipes-devtools/meson/meson/meson-wrapper
 create mode 100644 meta/recipes-devtools/meson/nativesdk-meson_0.46.1.bb

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
new file mode 100644
index 00..4c113dcaf7
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -0,0 +1,22 @@
+HOMEPAGE = "http://mesonbuild.com";
+SUMMARY = "A high performance build system"
+
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://COPYING;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${PV}.tar.gz 
\
+   file://0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch 
\
+   
file://0002-gobject-introspection-determine-g-ir-scanner-and-g-i.patch \
+   
file://0001-Linker-rules-move-cross_args-in-front-of-output_args.patch \
+   file://0003-native_bindir.patch \
+   file://0004-Prettifying-some-output-with-pathlib.patch \
+   
file://0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch \
+   "
+
+SRC_URI[md5sum] = "1698f6526574839de5dcdc45e3f7d582"
+SRC_URI[sha256sum] = 
"19497a03e7e5b303d8d11f98789a79aba59b5ad4a81bd00f4d099be0212cee78"
+UPSTREAM_CHECK_URI = "https://github.com/mesonbuild/meson/releases";
+
+inherit setuptools3
+
+RDEPENDS_${PN} = "ninja python3-core python3-modules"
diff --git a/meta/recipes-devtools/meson/meson/meson-setup.py 
b/meta/recipes-devtools/meson/meson/meson-setup.py
new file mode 100755
index 00..a9749eae9d
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/meson-setup.py
@@ -0,0 +1,62 @@
+#!/usr/bin/env python3
+
+import os
+import sys
+
+def bail(msg):
+print(msg, file=sys.stderr)
+sys.exit(1)
+
+_MARKER = '@@'
+def transform_line(line):
+# Substitute any special markers of this form:
+# @@ENV@@
+# with the value of ENV, split into meson array syntax.
+start = line.find(_MARKER)
+if start == -1:
+return line
+
+end = line.rfind(_MARKER)
+if end == start:
+return line
+
+# Lookup value of the env var.
+var = line[start+len(_MARKER):end]
+try:
+val = os.environ[var]
+except KeyError:
+bail('cannot generate meson.cross; env var %s not set' % var)
+
+# Transform into meson array.
+val = ["'%s'" % x for x in val.split()]
+val = ', '.join(val)
+val = '[%s]' % val
+
+before = line[:start]
+after = line[end+len(_MARKER):]
+
+return '%s%s%s' % (before, val, after)
+
+# Make sure this is really an SDK extraction environment.
+try:
+sysroot = os.environ['OECORE_NATIVE_SYSROOT']
+except KeyError:
+bail('OECORE_NATIVE_SYSROOT env var must be set')
+
+cross_file = os.path.join(sysroot, 'usr/share/meson/meson.cross')
+tmp_cross_file = '%s.tmp' % cross_file
+
+# Read through and transform the current meson.cross.
+lines = []
+with open(cross_file, 'r') as f:
+for line in f:
+lines.append(transform_line(line))
+
+# Write the transformed result to a tmp file and atomically rename it. In case
+# we crash during the file write, we don't want an invalid meson.cross file.
+with open(tmp_cross_file, 'w') as f:
+for line in lines:
+f.write(line)
+f.flush()
+os.fdatasync(f.fileno())
+os.rename(tmp_cross_file, cross_file)
diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper 
b/meta/recipes-devtools/meson/meson/meson-wrapper
new file mode 100755
index 00..b2e00da513
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/meson-wrapper
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+if [ -z "$OECORE_NATIVE_SYSROOT" ]; then
+echo "OECORE_NATIVE_SYSROOT not set; are you in a Yocto SDK environment?" 
>&2
+fi
+
+# If these are set to a cross-compile path, meson will get confused and try to
+# use them as native tools. Unset them to prevent this, as all the 
cross-compile
+# config is alread

[OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

[Martin Kelly]

It's useful for the post-relocate scripts to be able to see the SDK
environment, for example to see the values of CC, CXX etc. in order to
dynamically generate toolchain files.

To enable this, source the SDK environment script prior to calling the
relocate scripts.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 17 +
 meta/recipes-core/meta/meta-environment.bb |  5 +++--
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index ae7bbef034..5f99fd8c03 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -118,11 +118,20 @@ EOF
 }
 
 toolchain_create_post_relocate_script() {
-   script=$1
-   rm -f $script
-   touch $script
+   relocate_script=$1
+   sdk_script=$2
+   rm -f $relocate_script
+   touch $relocate_script
+
+cat >> $relocate_script <> $script <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 3/7] toolchain-shar-extract: allow non-sh post-relocate

[Martin Kelly]

Currently, we look only for scripts matching *.sh, which means we can't
write post-relocate scripts in other languages.

Expand this to allow any type of script.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index 71da5e5409..cbba07838a 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -124,7 +124,7 @@ toolchain_create_post_relocate_script() {
 
 cat >> $script <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 4/7] toolchain-shar-extract: print post-relocate error

[Martin Kelly]

Currently, if a post-relocate script fails, it fails silently. We should
be louder about this, as it likely indicates a broken SDK.

Print a message if a post-relocate script fails.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index cbba07838a..ae7bbef034 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -126,6 +126,11 @@ toolchain_create_post_relocate_script() {
 if [ -d "${SDKPATHNATIVE}/post-relocate-setup.d/" ]; then
 for s in ${SDKPATHNATIVE}/post-relocate-setup.d/*; do
 \$s "\$1"
+status=\$?
+if [ \$status != 0 ]; then
+echo "post-relocate command \"\$s \$1\" failed with status 
\$status" >&2
+exit \$status
+fi
 done
 rm -rf "${SDKPATHNATIVE}/post-relocate-setup.d"
 fi
-- 
2.11.0

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

[OE-core] [PATCH v2 1/7] meson.bbclass: refactor native override

[Martin Kelly]

The native override is specified in two different places, so let's move
it into a function to reduce code duplication.

Signed-off-by: Martin Kelly 
---
 meta/classes/meson.bbclass | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 2d7ee4fffc..5881765abb 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -90,7 +90,7 @@ meson_do_configure() {
 fi
 }
 
-meson_do_configure_prepend_class-target() {
+override_native_tools() {
 # Set these so that meson uses the native tools for its build sanity tests,
 # which require executables to be runnable. The cross file will still
 # override these for the target build. Note that we do *not* set CFLAGS,
@@ -100,18 +100,15 @@ meson_do_configure_prepend_class-target() {
 export CXX="${BUILD_CXX}"
 export LD="${BUILD_LD}"
 export AR="${BUILD_AR}"
+
+}
+
+meson_do_configure_prepend_class-target() {
+override_native_tools
 }
 
 meson_do_configure_prepend_class-nativesdk() {
-# Set these so that meson uses the native tools for its build sanity tests,
-# which require executables to be runnable. The cross file will still
-# override these for the nativesdk build. Note that we do *not* set CFLAGS,
-# LDFLAGS, etc. as they will be slurped in by meson and applied to the
-# nativesdk build, causing errors.
-export CC="${BUILD_CC}"
-export CXX="${BUILD_CXX}"
-export LD="${BUILD_LD}"
-export AR="${BUILD_AR}"
+override_native_tools
 }
 
 meson_do_configure_prepend_class-native() {
-- 
2.11.0

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

[OE-core] [PATCH v2 2/7] nativesdk-python*: suppress user site dirs

[Martin Kelly]

Currently, $HOME/.local is being added into sys.path in the Python SDK
causing subtle host contamination. Suppress this by exporting
PYTHONNOUSERSITE = "1" as documented in PEP 370.

This issue occurred in the past for python*-native and was fixed
similarly in OE-core commit 8fe9fb4d5a61dcbcb3fc5b9ee0234cc135af873f
("python*native.bbclass: suppress user site dirs").

Signed-off-by: Martin Kelly 
---
 meta/recipes-devtools/python/python-scons-native_3.0.1.bb | 2 +-
 meta/recipes-devtools/python/python3_3.5.5.bb | 2 +-
 meta/recipes-devtools/python/python_2.7.14.bb | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python-scons-native_3.0.1.bb 
b/meta/recipes-devtools/python/python-scons-native_3.0.1.bb
index dae89ab5d2..68b63c9357 100644
--- a/meta/recipes-devtools/python/python-scons-native_3.0.1.bb
+++ b/meta/recipes-devtools/python/python-scons-native_3.0.1.bb
@@ -4,5 +4,5 @@ DEPENDS = "python-native"
 RDEPENDS_${PN} = ""
 
 do_install_append() {
-create_wrapper ${D}${bindir}/scons 
SCONS_LIB_DIR='${STAGING_DIR_HOST}/${PYTHON_SITEPACKAGES_DIR}'
+create_wrapper ${D}${bindir}/scons 
SCONS_LIB_DIR='${STAGING_DIR_HOST}/${PYTHON_SITEPACKAGES_DIR}' 
PYTHONNOUSERSITE='1'
 }
diff --git a/meta/recipes-devtools/python/python3_3.5.5.bb 
b/meta/recipes-devtools/python/python3_3.5.5.bb
index f893b846ad..4dae4fa4c6 100644
--- a/meta/recipes-devtools/python/python3_3.5.5.bb
+++ b/meta/recipes-devtools/python/python3_3.5.5.bb
@@ -176,7 +176,7 @@ do_install() {
 }
 
 do_install_append_class-nativesdk () {
-   create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
+   create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
 }
 
 SSTATE_SCAN_FILES += "Makefile"
diff --git a/meta/recipes-devtools/python/python_2.7.14.bb 
b/meta/recipes-devtools/python/python_2.7.14.bb
index 41a8609b15..b923b9237b 100644
--- a/meta/recipes-devtools/python/python_2.7.14.bb
+++ b/meta/recipes-devtools/python/python_2.7.14.bb
@@ -130,7 +130,7 @@ do_install() {
 }
 
 do_install_append_class-nativesdk () {
-   create_wrapper ${D}${bindir}/python2.7 PYTHONHOME='${prefix}' 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
+   create_wrapper ${D}${bindir}/python2.7 PYTHONHOME='${prefix}' 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
 }
 
 SSTATE_SCAN_FILES += "Makefile"
-- 
2.11.0

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

[OE-core] [PATCH v2 0/7] meson: implement nativesdk support

[Martin Kelly]

This patch series implements nativesdk support fer meson. In order to do so, it
adds a few features to the toolchain-shar-extract functionality, which enables a
script to run prior to the SDK being extracted. This is important because the
meson.cross file (which meson uses to find its cross toolchain) allows for only
absolute paths. Thus, it is important to customize those paths to point to the
SDK at SDK extraction time. For comparison, cmake did not need this
functionality because it supports referencing environment variables in the
toolchain file, so we can just reference the SDK root environment variables. The
meson maintainers did not want to take that approach, so this seemed like the
best option.

If curious, see the following threads for more background information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146210.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146225.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146236.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146241.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146261.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146262.html

v2:
- Switch to new version of patches to fix exe wrappers, as upstream tweaked the
  previous patch.

Martin Kelly (7):
  meson.bbclass: refactor native override
  nativesdk-python*: suppress user site dirs
  toolchain-shar-extract: allow non-sh post-relocate
  toolchain-shar-extract: print post-relocate error
  toolchain-shar-extract: pass env to post-relocate
  meson: handle exe wrappers
  meson: enable nativesdk

 meta/classes/meson.bbclass |  17 +-
 meta/classes/toolchain-scripts.bbclass |  24 +-
 meta/recipes-core/meta/meta-environment.bb |   5 +-
 meta/recipes-devtools/meson/meson.inc  |  22 +
 ...0004-Prettifying-some-output-with-pathlib.patch | 188 +
 ...on-command-to-use-when-we-know-what-it-is.patch | 851 +
 meta/recipes-devtools/meson/meson/meson-setup.py   |  62 ++
 meta/recipes-devtools/meson/meson/meson-wrapper|  14 +
 meta/recipes-devtools/meson/meson_0.46.1.bb|  20 +-
 .../meson/nativesdk-meson_0.46.1.bb|  74 ++
 .../python/python-scons-native_3.0.1.bb|   2 +-
 meta/recipes-devtools/python/python3_3.5.5.bb  |   2 +-
 meta/recipes-devtools/python/python_2.7.14.bb  |   2 +-
 13 files changed, 1244 insertions(+), 39 deletions(-)
 create mode 100644 meta/recipes-devtools/meson/meson.inc
 create mode 100644 
meta/recipes-devtools/meson/meson/0004-Prettifying-some-output-with-pathlib.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0005-Set-the-meson-command-to-use-when-we-know-what-it-is.patch
 create mode 100755 meta/recipes-devtools/meson/meson/meson-setup.py
 create mode 100755 meta/recipes-devtools/meson/meson/meson-wrapper
 create mode 100644 meta/recipes-devtools/meson/nativesdk-meson_0.46.1.bb

-- 
2.11.0

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

[OE-core] [PATCH 6/7] meson: handle exe wrappers

[Martin Kelly]

Add patches to enable meson to handle being wrapped with a shell script.  This
will enable us to do so for supporting the SDK, which requires us to setup env
vars and point to a meson.cross file inside the SDK.

These patches are all merged upstream, so we can drop them soon.

Signed-off-by: Martin Kelly 
---
 ...ke-ExternalProgram-get_path-a-bit-smarter.patch |  58 ++
 ...mandrunner-make-run-handle-python-options.patch |  53 +
 .../0006-mesonlib-handle-meson-exe-wrappers.patch  | 231 +
 meta/recipes-devtools/meson/meson_0.46.1.bb|   3 +
 4 files changed, 345 insertions(+)
 create mode 100644 
meta/recipes-devtools/meson/meson/0004-make-ExternalProgram-get_path-a-bit-smarter.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0005-commandrunner-make-run-handle-python-options.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0006-mesonlib-handle-meson-exe-wrappers.patch

diff --git 
a/meta/recipes-devtools/meson/meson/0004-make-ExternalProgram-get_path-a-bit-smarter.patch
 
b/meta/recipes-devtools/meson/meson/0004-make-ExternalProgram-get_path-a-bit-smarter.patch
new file mode 100644
index 00..fdab7e67dc
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0004-make-ExternalProgram-get_path-a-bit-smarter.patch
@@ -0,0 +1,58 @@
+From 2c0273abecbdcef8411a6e513c7435ca4e7bd620 Mon Sep 17 00:00:00 2001
+From: Martin Kelly 
+Date: Tue, 24 Apr 2018 16:53:18 -0700
+Subject: [PATCH] make ExternalProgram get_path() a bit smarter
+
+Currently, ExternalProgram get_path() assumes the last component in the
+path is always the actual command path. However, this is not always
+right. For example, in the command "python -u", we should return
+"python" and not "-u". However, in other cases, like "python script.py",
+then the last component is the right one.
+
+The heuristic that seems to capture this is to use the last argument
+that is still a file. This means options get ignored, but "python
+script.py" still works. Let's use this heuristic, at least for now.
+
+Upstream-Status: Accepted [https://github.com/mesonbuild/meson/pull/3393]
+Should be in the 0.47.0 release.
+
+Signed-off-by: Martin Kelly 
+---
+ mesonbuild/dependencies/base.py | 17 -
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
+index f4f19c57..18f04892 100644
+--- a/mesonbuild/dependencies/base.py
 b/mesonbuild/dependencies/base.py
+@@ -745,6 +745,17 @@ class ExternalProgram:
+ self.command = listify(command)
+ else:
+ self.command = self._search(name, search_dir)
++
++# Set path to be the last item that is actually a file (in order to
++# skip options in something like ['python', '-u', 'file.py']. If we
++# can't find any components, default to the last component of the 
path.
++self.path = self.command[-1]
++for i in range(len(self.command) - 1, -1, -1):
++arg = self.command[i]
++if arg is not None and os.path.isfile(arg):
++self.path = arg
++break
++
+ if not silent:
+ if self.found():
+ mlog.log('Program', mlog.bold(name), 'found:', 
mlog.green('YES'),
+@@ -892,11 +903,7 @@ class ExternalProgram:
+ return self.command[:]
+ 
+ def get_path(self):
+-if self.found():
+-# Assume that the last element is the full path to the script or
+-# binary being run
+-return self.command[-1]
+-return None
++return self.path
+ 
+ def get_name(self):
+ return self.name
diff --git 
a/meta/recipes-devtools/meson/meson/0005-commandrunner-make-run-handle-python-options.patch
 
b/meta/recipes-devtools/meson/meson/0005-commandrunner-make-run-handle-python-options.patch
new file mode 100644
index 00..876ace22f8
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0005-commandrunner-make-run-handle-python-options.patch
@@ -0,0 +1,53 @@
+From 0f54849523c812bca57d2182af92afe58c44f850 Mon Sep 17 00:00:00 2001
+From: Martin Kelly 
+Date: Tue, 24 Apr 2018 16:55:12 -0700
+Subject: [PATCH] commandrunner: make run handle python options
+
+Currently, commandrunner breaks when we give options to python because
+it assumes python commands are in the form "python script.py", rather
+than "python -u script.py" or "python -u -m module script.py". Extend it
+to be more resilient and correctly parse python options.
+
+Upstream-Status: Accepted [https://github.com/mesonbuild/meson/pull/3393]
+Should be in the 0.47.0 release.
+
+Signed-off-by: Martin Kelly 
+---
+ mesonbuild/scripts/commandrunner.py | 24 +---
+ 1 file changed, 21 insertions(+), 3 deletions(-)
+
+diff --git a/mesonbuild/scripts/command

[OE-core] [PATCH 1/7] meson.bbclass: refactor native override

[Martin Kelly]

The native override is specified in two different places, so let's move
it into a function to reduce code duplication.

Signed-off-by: Martin Kelly 
---
 meta/classes/meson.bbclass | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 2d7ee4fffc..5881765abb 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -90,7 +90,7 @@ meson_do_configure() {
 fi
 }
 
-meson_do_configure_prepend_class-target() {
+override_native_tools() {
 # Set these so that meson uses the native tools for its build sanity tests,
 # which require executables to be runnable. The cross file will still
 # override these for the target build. Note that we do *not* set CFLAGS,
@@ -100,18 +100,15 @@ meson_do_configure_prepend_class-target() {
 export CXX="${BUILD_CXX}"
 export LD="${BUILD_LD}"
 export AR="${BUILD_AR}"
+
+}
+
+meson_do_configure_prepend_class-target() {
+override_native_tools
 }
 
 meson_do_configure_prepend_class-nativesdk() {
-# Set these so that meson uses the native tools for its build sanity tests,
-# which require executables to be runnable. The cross file will still
-# override these for the nativesdk build. Note that we do *not* set CFLAGS,
-# LDFLAGS, etc. as they will be slurped in by meson and applied to the
-# nativesdk build, causing errors.
-export CC="${BUILD_CC}"
-export CXX="${BUILD_CXX}"
-export LD="${BUILD_LD}"
-export AR="${BUILD_AR}"
+override_native_tools
 }
 
 meson_do_configure_prepend_class-native() {
-- 
2.11.0

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

[OE-core] [PATCH 0/7] meson: implement nativesdk support

[Martin Kelly]

This patch series implements nativesdk support fer meson. In order to do so, it
adds a few features to the toolchain-shar-extract functionality, which enables a
script to run prior to the SDK being extracted. This is important because the
meson.cross file (which meson uses to find its cross toolchain) allows for only
absolute paths. Thus, it is important to customize those paths to point to the
SDK at SDK extraction time. For comparison, cmake did not need this
functionality because it supports referencing environment variables in the
toolchain file, so we can just reference the SDK root environment variables. The
meson maintainers did not want to take that approach, so this seemed like the
best option.

If curious, see the following threads for more background information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146210.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146225.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146236.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146241.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146261.html
http://lists.openembedded.org/pipermail/openembedded-core/2018-January/146262.html

Martin Kelly (7):
  meson.bbclass: refactor native override
  nativesdk-python*: suppress user site dirs
  toolchain-shar-extract: allow non-sh post-relocate
  toolchain-shar-extract: print post-relocate error
  toolchain-shar-extract: pass env to post-relocate
  meson: handle exe wrappers
  meson: enable nativesdk

 meta/classes/meson.bbclass |  17 +-
 meta/classes/toolchain-scripts.bbclass |  24 ++-
 meta/recipes-core/meta/meta-environment.bb |   5 +-
 meta/recipes-devtools/meson/meson.inc  |  23 ++
 ...ke-ExternalProgram-get_path-a-bit-smarter.patch |  58 ++
 ...mandrunner-make-run-handle-python-options.patch |  53 +
 .../0006-mesonlib-handle-meson-exe-wrappers.patch  | 231 +
 meta/recipes-devtools/meson/meson/meson-setup.py   |  62 ++
 meta/recipes-devtools/meson/meson/meson-wrapper|  14 ++
 meta/recipes-devtools/meson/meson_0.46.1.bb|  20 +-
 .../meson/nativesdk-meson_0.46.1.bb|  74 +++
 .../python/python-scons-native_3.0.1.bb|   2 +-
 meta/recipes-devtools/python/python3_3.5.5.bb  |   2 +-
 meta/recipes-devtools/python/python_2.7.14.bb  |   2 +-
 14 files changed, 548 insertions(+), 39 deletions(-)
 create mode 100644 meta/recipes-devtools/meson/meson.inc
 create mode 100644 
meta/recipes-devtools/meson/meson/0004-make-ExternalProgram-get_path-a-bit-smarter.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0005-commandrunner-make-run-handle-python-options.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0006-mesonlib-handle-meson-exe-wrappers.patch
 create mode 100755 meta/recipes-devtools/meson/meson/meson-setup.py
 create mode 100755 meta/recipes-devtools/meson/meson/meson-wrapper
 create mode 100644 meta/recipes-devtools/meson/nativesdk-meson_0.46.1.bb

-- 
2.11.0

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

[OE-core] [PATCH 5/7] toolchain-shar-extract: pass env to post-relocate

[Martin Kelly]

It's useful for the post-relocate scripts to be able to see the SDK
environment, for example to see the values of CC, CXX etc. in order to
dynamically generate toolchain files.

To enable this, source the SDK environment script prior to calling the
relocate scripts.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 17 +
 meta/recipes-core/meta/meta-environment.bb |  5 +++--
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index ae7bbef034..5f99fd8c03 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -118,11 +118,20 @@ EOF
 }
 
 toolchain_create_post_relocate_script() {
-   script=$1
-   rm -f $script
-   touch $script
+   relocate_script=$1
+   sdk_script=$2
+   rm -f $relocate_script
+   touch $relocate_script
+
+cat >> $relocate_script <> $script <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/7] toolchain-shar-extract: allow non-sh post-relocate

[Martin Kelly]

Currently, we look only for scripts matching *.sh, which means we can't
write post-relocate scripts in other languages.

Expand this to allow any type of script.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index 71da5e5409..cbba07838a 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -124,7 +124,7 @@ toolchain_create_post_relocate_script() {
 
 cat >> $script <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/7] toolchain-shar-extract: print post-relocate error

[Martin Kelly]

Currently, if a post-relocate script fails, it fails silently. We should
be louder about this, as it likely indicates a broken SDK.

Print a message if a post-relocate script fails.

Signed-off-by: Martin Kelly 
---
 meta/classes/toolchain-scripts.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index cbba07838a..ae7bbef034 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -126,6 +126,11 @@ toolchain_create_post_relocate_script() {
 if [ -d "${SDKPATHNATIVE}/post-relocate-setup.d/" ]; then
 for s in ${SDKPATHNATIVE}/post-relocate-setup.d/*; do
 \$s "\$1"
+status=\$?
+if [ \$status != 0 ]; then
+echo "post-relocate command \"\$s \$1\" failed with status 
\$status" >&2
+exit \$status
+fi
 done
 rm -rf "${SDKPATHNATIVE}/post-relocate-setup.d"
 fi
-- 
2.11.0

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

[OE-core] [PATCH 2/7] nativesdk-python*: suppress user site dirs

[Martin Kelly]

Currently, $HOME/.local is being added into sys.path in the Python SDK
causing subtle host contamination. Suppress this by exporting
PYTHONNOUSERSITE = "1" as documented in PEP 370.

This issue occurred in the past for python*-native and was fixed
similarly in OE-core commit 8fe9fb4d5a61dcbcb3fc5b9ee0234cc135af873f
("python*native.bbclass: suppress user site dirs").

Signed-off-by: Martin Kelly 
---
 meta/recipes-devtools/python/python-scons-native_3.0.1.bb | 2 +-
 meta/recipes-devtools/python/python3_3.5.5.bb | 2 +-
 meta/recipes-devtools/python/python_2.7.14.bb | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python-scons-native_3.0.1.bb 
b/meta/recipes-devtools/python/python-scons-native_3.0.1.bb
index dae89ab5d2..68b63c9357 100644
--- a/meta/recipes-devtools/python/python-scons-native_3.0.1.bb
+++ b/meta/recipes-devtools/python/python-scons-native_3.0.1.bb
@@ -4,5 +4,5 @@ DEPENDS = "python-native"
 RDEPENDS_${PN} = ""
 
 do_install_append() {
-create_wrapper ${D}${bindir}/scons 
SCONS_LIB_DIR='${STAGING_DIR_HOST}/${PYTHON_SITEPACKAGES_DIR}'
+create_wrapper ${D}${bindir}/scons 
SCONS_LIB_DIR='${STAGING_DIR_HOST}/${PYTHON_SITEPACKAGES_DIR}' 
PYTHONNOUSERSITE='1'
 }
diff --git a/meta/recipes-devtools/python/python3_3.5.5.bb 
b/meta/recipes-devtools/python/python3_3.5.5.bb
index f893b846ad..4dae4fa4c6 100644
--- a/meta/recipes-devtools/python/python3_3.5.5.bb
+++ b/meta/recipes-devtools/python/python3_3.5.5.bb
@@ -176,7 +176,7 @@ do_install() {
 }
 
 do_install_append_class-nativesdk () {
-   create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
+   create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
 }
 
 SSTATE_SCAN_FILES += "Makefile"
diff --git a/meta/recipes-devtools/python/python_2.7.14.bb 
b/meta/recipes-devtools/python/python_2.7.14.bb
index 41a8609b15..b923b9237b 100644
--- a/meta/recipes-devtools/python/python_2.7.14.bb
+++ b/meta/recipes-devtools/python/python_2.7.14.bb
@@ -130,7 +130,7 @@ do_install() {
 }
 
 do_install_append_class-nativesdk () {
-   create_wrapper ${D}${bindir}/python2.7 PYTHONHOME='${prefix}' 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
+   create_wrapper ${D}${bindir}/python2.7 PYTHONHOME='${prefix}' 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
 }
 
 SSTATE_SCAN_FILES += "Makefile"
-- 
2.11.0

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

[OE-core] [PATCH 7/7] meson: enable nativesdk

[Martin Kelly]

Currently, we can't build meson into SDKs because we don't autogenerate
the required meson.cross file.

Enable this by using the post-relocate hooks and generating a
meson.cross file based on the SDK environment passed into the
post-relocate hook.

Signed-off-by: Martin Kelly 
---
 meta/recipes-devtools/meson/meson.inc  | 23 +++
 meta/recipes-devtools/meson/meson/meson-setup.py   | 62 ++
 meta/recipes-devtools/meson/meson/meson-wrapper| 14 
 meta/recipes-devtools/meson/meson_0.46.1.bb| 23 +--
 .../meson/nativesdk-meson_0.46.1.bb| 74 ++
 5 files changed, 174 insertions(+), 22 deletions(-)
 create mode 100644 meta/recipes-devtools/meson/meson.inc
 create mode 100755 meta/recipes-devtools/meson/meson/meson-setup.py
 create mode 100755 meta/recipes-devtools/meson/meson/meson-wrapper
 create mode 100644 meta/recipes-devtools/meson/nativesdk-meson_0.46.1.bb

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
new file mode 100644
index 00..cf5af430e6
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -0,0 +1,23 @@
+HOMEPAGE = "http://mesonbuild.com";
+SUMMARY = "A high performance build system"
+
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://COPYING;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${PV}.tar.gz 
\
+   file://0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch 
\
+   
file://0002-gobject-introspection-determine-g-ir-scanner-and-g-i.patch \
+   
file://0001-Linker-rules-move-cross_args-in-front-of-output_args.patch \
+   file://0003-native_bindir.patch \
+   file://0004-make-ExternalProgram-get_path-a-bit-smarter.patch \
+   file://0005-commandrunner-make-run-handle-python-options.patch \
+   file://0006-mesonlib-handle-meson-exe-wrappers.patch \
+   "
+
+SRC_URI[md5sum] = "1698f6526574839de5dcdc45e3f7d582"
+SRC_URI[sha256sum] = 
"19497a03e7e5b303d8d11f98789a79aba59b5ad4a81bd00f4d099be0212cee78"
+UPSTREAM_CHECK_URI = "https://github.com/mesonbuild/meson/releases";
+
+inherit setuptools3
+
+RDEPENDS_${PN} = "ninja python3-core python3-modules"
diff --git a/meta/recipes-devtools/meson/meson/meson-setup.py 
b/meta/recipes-devtools/meson/meson/meson-setup.py
new file mode 100755
index 00..a9749eae9d
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/meson-setup.py
@@ -0,0 +1,62 @@
+#!/usr/bin/env python3
+
+import os
+import sys
+
+def bail(msg):
+print(msg, file=sys.stderr)
+sys.exit(1)
+
+_MARKER = '@@'
+def transform_line(line):
+# Substitute any special markers of this form:
+# @@ENV@@
+# with the value of ENV, split into meson array syntax.
+start = line.find(_MARKER)
+if start == -1:
+return line
+
+end = line.rfind(_MARKER)
+if end == start:
+return line
+
+# Lookup value of the env var.
+var = line[start+len(_MARKER):end]
+try:
+val = os.environ[var]
+except KeyError:
+bail('cannot generate meson.cross; env var %s not set' % var)
+
+# Transform into meson array.
+val = ["'%s'" % x for x in val.split()]
+val = ', '.join(val)
+val = '[%s]' % val
+
+before = line[:start]
+after = line[end+len(_MARKER):]
+
+return '%s%s%s' % (before, val, after)
+
+# Make sure this is really an SDK extraction environment.
+try:
+sysroot = os.environ['OECORE_NATIVE_SYSROOT']
+except KeyError:
+bail('OECORE_NATIVE_SYSROOT env var must be set')
+
+cross_file = os.path.join(sysroot, 'usr/share/meson/meson.cross')
+tmp_cross_file = '%s.tmp' % cross_file
+
+# Read through and transform the current meson.cross.
+lines = []
+with open(cross_file, 'r') as f:
+for line in f:
+lines.append(transform_line(line))
+
+# Write the transformed result to a tmp file and atomically rename it. In case
+# we crash during the file write, we don't want an invalid meson.cross file.
+with open(tmp_cross_file, 'w') as f:
+for line in lines:
+f.write(line)
+f.flush()
+os.fdatasync(f.fileno())
+os.rename(tmp_cross_file, cross_file)
diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper 
b/meta/recipes-devtools/meson/meson/meson-wrapper
new file mode 100755
index 00..b2e00da513
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/meson-wrapper
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+if [ -z "$OECORE_NATIVE_SYSROOT" ]; then
+echo "OECORE_NATIVE_SYSROOT not set; are you in a Yocto SDK environment?" 
>&2
+fi
+
+# If these are set to a cross-compile path, meson will get confused and try to
+# use them as native tools. Unset them to

Re: [OE-core] [meta-oe][PATCH 2/3] modemmanager: upgrade to 1.7.991

[Martin Kelly]

On 05/08/2018 12:29 PM, Martin Jansa wrote:

Hi Martin,

all meta-oe patches need to go to openembedded-devel ML.

Thanks



Of course, my bad. Resent now to oe-devel.

On Tue, May 8, 2018 at 8:49 PM, Martin Kelly <mailto:mke...@xevo.com>> wrote:


This version has a ublox plugin for expanded modem support. The
underlying issue
that enum-conversion.patch fixes appears to already have been fixed
upstream, so
we can drop the patch.

Signed-off-by: Martin Kelly mailto:mke...@xevo.com>>
---
  .../modemmanager/modemmanager/enum-conversion.patch | 21
-
  ...odemmanager_1.6.4.bb <http://odemmanager_1.6.4.bb> =>
modemmanager_1.7.991.bb <http://modemmanager_1.7.991.bb>} |  9 -
  2 files changed, 4 insertions(+), 26 deletions(-)
  delete mode 100644
meta-oe/recipes-connectivity/modemmanager/modemmanager/enum-conversion.patch
  rename
meta-oe/recipes-connectivity/modemmanager/{modemmanager_1.6.4.bb
<http://modemmanager_1.6.4.bb> => modemmanager_1.7.991.bb
<http://modemmanager_1.7.991.bb>} (88%)

diff --git

a/meta-oe/recipes-connectivity/modemmanager/modemmanager/enum-conversion.patch

b/meta-oe/recipes-connectivity/modemmanager/modemmanager/enum-conversion.patch
deleted file mode 100644
index a3fb0f3eb..0
---

a/meta-oe/recipes-connectivity/modemmanager/modemmanager/enum-conversion.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-Fixes errors found bt Clang
-
-| ../../ModemManager-1.6.4/src/mm-bearer-qmi.c:774:50: error:
implicit conversion from enumeration type 'MMBearerStatus' to
different enumeration type 'MMBearerConnectionStatus'
[-Werror,-Wenum-conversion]
-|         MMBearerConnectionStatus bearer_status =
mm_base_bearer_get_status (MM_BASE_BEARER (self));
-|                                  ~ 
  ^

-| 1 error generated.
-
-
-Index: ModemManager-1.6.4/src/mm-bearer-qmi.c
-===
 ModemManager-1.6.4.orig/src/mm-bearer-qmi.c
-+++ ModemManager-1.6.4/src/mm-bearer-qmi.c
-@@ -771,7 +771,7 @@ packet_service_status_indication_cb (Qmi
-             &connection_status,
-             NULL,
-             NULL)) {
--        MMBearerConnectionStatus bearer_status =
mm_base_bearer_get_status (MM_BASE_BEARER (self));
-+        MMBearerConnectionStatus bearer_status =
(MMBearerConnectionStatus)mm_base_bearer_get_status (MM_BASE_BEARER
(self));
-
-         if (connection_status ==
QMI_WDS_CONNECTION_STATUS_DISCONNECTED &&
-             bearer_status !=
MM_BEARER_CONNECTION_STATUS_DISCONNECTED &&
diff --git
a/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.6.4.bb
<http://modemmanager_1.6.4.bb>
b/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
<http://modemmanager_1.7.991.bb>
similarity index 88%
rename from
meta-oe/recipes-connectivity/modemmanager/modemmanager_1.6.4.bb
<http://modemmanager_1.6.4.bb>
rename to
meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
<http://modemmanager_1.7.991.bb>
index e60cd4b74..4f9400169 100644
---
a/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.6.4.bb
<http://modemmanager_1.6.4.bb>
+++
b/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
<http://modemmanager_1.7.991.bb>
@@ -11,11 +11,10 @@ inherit gnomebase gettext systemd vala
gobject-introspection bash-completion

  DEPENDS = "glib-2.0 libgudev dbus-glib intltool-native"

-SRC_URI =
"http://www.freedesktop.org/software/ModemManager/ModemManager-${PV}.tar.xz
<http://www.freedesktop.org/software/ModemManager/ModemManager-${PV}.tar.xz>
\
-           file://enum-conversion.patch \
-"
-SRC_URI[md5sum] = "06488186c7dd53f8104183b86f7a1568"
-SRC_URI[sha256sum] =
"cdd5b4cb1e4d7643643a28ccbfc4bb354bfa9cb89a77ea160ebdf7926171c668"
+SRC_URI =
"http://www.freedesktop.org/software/ModemManager/ModemManager-${PV}.tar.xz

<http://www.freedesktop.org/software/ModemManager/ModemManager-${PV}.tar.xz>"
+
+SRC_URI[md5sum] = "4efe6a240cef212bf8855c95424e7c7f"
+SRC_URI[sha256sum] =
"4e366243bd4983f2e6efe35cb901cf5da51939307b5d6299fe622a9fcf411745"

  S = "${WORKDIR}/ModemManager-${PV}"

-- 
2.11.0


-- 
___

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

[OE-core] [meta-oe][PATCH 3/3] modemmanager: fix mbim disable string

[Martin Kelly]

The current string used to disable mbim is "--enable-mbim=no", which is
producing a warning. It should be "--with-mdim=no", so change it.

Signed-off-by: Martin Kelly 
---
 meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb 
b/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
index 4f9400169..b1a718dbf 100644
--- a/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
+++ b/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
@@ -25,7 +25,7 @@ PACKAGECONFIG ??= "mbim qmi polkit \
 PACKAGECONFIG[systemd] = 
"--with-systemdsystemunitdir=${systemd_unitdir}/system/,,"
 PACKAGECONFIG[polkit] = "--with-polkit=yes,--with-polkit=no,polkit"
 # Support WWAN modems and devices which speak the Mobile Interface Broadband 
Model (MBIM) protocol.
-PACKAGECONFIG[mbim] = "--with-mbim,--enable-mbim=no,libmbim"
+PACKAGECONFIG[mbim] = "--with-mbim,--with-mbim=no,libmbim"
 # Support WWAN modems and devices which speak the Qualcomm MSM Interface (QMI) 
protocol.
 PACKAGECONFIG[qmi] = "--with-qmi,--without-qmi,libqmi"
 
-- 
2.11.0

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

[OE-core] [meta-oe][PATCH 1/3] libmbim: upgrade to 1.16

[Martin Kelly]

This is needed for the next version of modemmanager.

Signed-off-by: Martin Kelly 
---
A similar patch was also sent by Khem Raj; that patch is just as good, but I
wanted to send this in the same series because the modemmanager upgrade requires
a libmbim upgrade.

 .../libmbim/{libmbim_1.14.0.bb => libmbim_1.16.0.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta-oe/recipes-connectivity/libmbim/{libmbim_1.14.0.bb => 
libmbim_1.16.0.bb} (82%)

diff --git a/meta-oe/recipes-connectivity/libmbim/libmbim_1.14.0.bb 
b/meta-oe/recipes-connectivity/libmbim/libmbim_1.16.0.bb
similarity index 82%
rename from meta-oe/recipes-connectivity/libmbim/libmbim_1.14.0.bb
rename to meta-oe/recipes-connectivity/libmbim/libmbim_1.16.0.bb
index f89ef9d57..5260c0f14 100644
--- a/meta-oe/recipes-connectivity/libmbim/libmbim_1.14.0.bb
+++ b/meta-oe/recipes-connectivity/libmbim/libmbim_1.16.0.bb
@@ -14,5 +14,5 @@ inherit autotools pkgconfig bash-completion
 SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BPN}-${PV}.tar.xz \
file://clang.patch \
 "
-SRC_URI[md5sum] = "2ed809e65c85353d3ab59e372890e549"
-SRC_URI[sha256sum] = 
"ca8d52a95a18cbabae8f15f83f1572316e888b6504f946e6645d24405127ab5b"
+SRC_URI[md5sum] = "76ea4d8381989919b1d9b91c818fed80"
+SRC_URI[sha256sum] = 
"c8ca50beeddd4b43309df5b698917268303bf176cea58fe4fe53d5bf0e93fac2"
-- 
2.11.0

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

[OE-core] [meta-oe][PATCH 2/3] modemmanager: upgrade to 1.7.991

[Martin Kelly]

This version has a ublox plugin for expanded modem support. The underlying issue
that enum-conversion.patch fixes appears to already have been fixed upstream, so
we can drop the patch.

Signed-off-by: Martin Kelly 
---
 .../modemmanager/modemmanager/enum-conversion.patch | 21 -
 ...odemmanager_1.6.4.bb => modemmanager_1.7.991.bb} |  9 -
 2 files changed, 4 insertions(+), 26 deletions(-)
 delete mode 100644 
meta-oe/recipes-connectivity/modemmanager/modemmanager/enum-conversion.patch
 rename meta-oe/recipes-connectivity/modemmanager/{modemmanager_1.6.4.bb => 
modemmanager_1.7.991.bb} (88%)

diff --git 
a/meta-oe/recipes-connectivity/modemmanager/modemmanager/enum-conversion.patch 
b/meta-oe/recipes-connectivity/modemmanager/modemmanager/enum-conversion.patch
deleted file mode 100644
index a3fb0f3eb..0
--- 
a/meta-oe/recipes-connectivity/modemmanager/modemmanager/enum-conversion.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-Fixes errors found bt Clang
-
-| ../../ModemManager-1.6.4/src/mm-bearer-qmi.c:774:50: error: implicit 
conversion from enumeration type 'MMBearerStatus' to different enumeration type 
'MMBearerConnectionStatus' [-Werror,-Wenum-conversion]
-| MMBearerConnectionStatus bearer_status = mm_base_bearer_get_status 
(MM_BASE_BEARER (self));
-|  ~   
^
-| 1 error generated.
-
-
-Index: ModemManager-1.6.4/src/mm-bearer-qmi.c
-===
 ModemManager-1.6.4.orig/src/mm-bearer-qmi.c
-+++ ModemManager-1.6.4/src/mm-bearer-qmi.c
-@@ -771,7 +771,7 @@ packet_service_status_indication_cb (Qmi
- &connection_status,
- NULL,
- NULL)) {
--MMBearerConnectionStatus bearer_status = mm_base_bearer_get_status 
(MM_BASE_BEARER (self));
-+MMBearerConnectionStatus bearer_status = 
(MMBearerConnectionStatus)mm_base_bearer_get_status (MM_BASE_BEARER (self));
- 
- if (connection_status == QMI_WDS_CONNECTION_STATUS_DISCONNECTED &&
- bearer_status != MM_BEARER_CONNECTION_STATUS_DISCONNECTED &&
diff --git a/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.6.4.bb 
b/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
similarity index 88%
rename from meta-oe/recipes-connectivity/modemmanager/modemmanager_1.6.4.bb
rename to meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
index e60cd4b74..4f9400169 100644
--- a/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.6.4.bb
+++ b/meta-oe/recipes-connectivity/modemmanager/modemmanager_1.7.991.bb
@@ -11,11 +11,10 @@ inherit gnomebase gettext systemd vala 
gobject-introspection bash-completion
 
 DEPENDS = "glib-2.0 libgudev dbus-glib intltool-native"
 
-SRC_URI = 
"http://www.freedesktop.org/software/ModemManager/ModemManager-${PV}.tar.xz \
-   file://enum-conversion.patch \
-"
-SRC_URI[md5sum] = "06488186c7dd53f8104183b86f7a1568"
-SRC_URI[sha256sum] = 
"cdd5b4cb1e4d7643643a28ccbfc4bb354bfa9cb89a77ea160ebdf7926171c668"
+SRC_URI = 
"http://www.freedesktop.org/software/ModemManager/ModemManager-${PV}.tar.xz";
+
+SRC_URI[md5sum] = "4efe6a240cef212bf8855c95424e7c7f"
+SRC_URI[sha256sum] = 
"4e366243bd4983f2e6efe35cb901cf5da51939307b5d6299fe622a9fcf411745"
 
 S = "${WORKDIR}/ModemManager-${PV}"
 
-- 
2.11.0

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

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

On 04/25/2018 04:11 PM, Martin Jansa wrote:

There are actually 3 we need to consider for lowest common denominator.

The one we build for, the one we build on and the one where we will run 
the qemu in the end.


I mean the core2duo is probably best match for core2-64 DEFAULT used by 
qemux86-64 MACHINE. But it's not good match to emulate with QEmu and KVM 
enabled on the host like my.


It's easy to work around this, we probably don't need to change the 
default values, but it would be good to document this case and how to 
override QB_CPU_KVM if your host doesn't match the features of core2duo.




Agreed. I just sent a patch to yocto-docs to add some documentation for 
this.

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

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

On 04/25/2018 12:54 PM, Martin Jansa wrote:

On Thu, Jun 15, 2017 at 05:37:50PM +0100, Burton, Ross wrote:

On 15 June 2017 at 17:17, Martin Kelly  wrote:


I am no expert, but running qemu -cpu help just says:

kvm32 - "Common 32-bit KVM processor"
kvm64 - "Common 64-bit KVM processor"

My best guess is that, running on qemu without kvm, both cases will be
slow (since it's all software emulation). But, using qemu -kvm, it should
be fast as long as you run on a native CPU that is core2duo or better, as
the native instructions can just be exposed and passed through to the host.
Since core2duo is very old by now, it should be fast for virtually everyone
building on x86.



Right, I did some digging.  Assuming you have KVM enabled then in the
general case the -cpu option is irrelevant as the instructions are handled
natively.  -cpu just changes what CPUID flags the userspace sees, and so
this is the Right Thing To Do.


Sorry for replying to such old thread, but today I've noticed interesting 
side-effect of this change.

Today I was checking why starting qtbase examples in qemu fails with
message about missing ssse3 support which which qtbase as compiled.

The DEFAULT_TUNE in qemux86-64 is indeed set to core2-64 which supports
ssse3, so qtbase is right to expect it in runtime.

But then I was starting qemu manually (not with runqemu) with:
qemu-system-x86_64 -M q35 -smp 4 -m 4G -net nic,model=virtio -net 
user,hostfwd=tcp::-:22 -vga virtio -display sdl,gl=on -hda 
luneui-example-image-qemux86-64-20180425152329-jama.rootfs.wic.vmdk -enable-kvm

which defaults to using this kvm64 generic CPU which doesn't support ssse3

Changing it to
qemu-system-x86_64 -M q35 -cpu core2duo -smp 4 -m 4G -net nic,model=virtio -net 
user,hostfwd=tcp::-:22 -vga virtio -display sdl,gl=on -hda 
luneui-example-image-qemux86-64-20180425152329-jama.rootfs.wic.vmdk -enable-kvm

gets rid of the message from qtbase, because core2duo supports ssse3 and 
matches with qemux86-64,
but my host CPU (AMD Bulldozer FX(tm)-8120), doesn't support the same cpu flags 
like core2due and qemu shows following
message when starting:
qemu-system-x86_64: warning: host doesn't support requested feature: 
CPUID.01H:EDX.ss [bit 27]

EDX.ss is Self Snoop feature which is enabled in core2duo and few other QEmu 
emulated CPUs, so I was looking
on some other cpu I can emulate which has ssse3 while having the same flags as 
my host's AMD cpu

e.g. -cpu phenom is relatively close, but Bulldozer CPUs don't support 3dnow, 
3dnowext, so similar warning is shown.

In the end I've switched to using -cpu Nehalem, which has ssse3, but doesn't 
enable CPUID_SS flag, now it starts without any warnings:
qemu-system-x86_64 -M q35 -cpu Nehalem -smp 4 -m 4G -net nic,model=virtio -net 
user,hostfwd=tcp::-:22 -vga virtio -display sdl,gl=on -hda 
luneui-example-image-qemux86-64-20180425152329-jama.rootfs.wic.vmdk -enable-kvm

Regards,



Heh, this is bringing back memories of when I wrote the patch. It's 
tricky to say what CPU we should pick here; we want whatever is the 
closest to a lowest common denominator. I don't know enough to say what 
the right choice is, though it is important that the CPU we build for 
and the one we run for are the same.


Prior to this patch, we built for core2duo and then ran with kvm64, 
causing issues. Good follow-up work would be to see if core2duo is 
really the best CPU to be targeting for a lowest common denominator. If 
Nehalem is a better match, we might as well switch to that, as long as 
we switch in both build and runtime consistently.

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

[OE-core] [pyro][PATCH] python3-setuptools: extend to nativesdk

[Martin Kelly]

From: Chen Qi 

Extend python3-setuptools to nativesdk because nativesdk-python3-pip needs
it.

Also, adjust RDEPENDS variable setting to keep the runtime dependencies
for nativesdk package the same with the target one. The native package and
the target package's dependencies remain the same as before.

Signed-off-by: Chen Qi 
Signed-off-by: Ross Burton 
Signed-off-by: Martin Kelly 
---
 meta/recipes-devtools/python/python3-setuptools_32.1.1.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-setuptools_32.1.1.bb 
b/meta/recipes-devtools/python/python3-setuptools_32.1.1.bb
index 65af6f0dad..63f241809e 100644
--- a/meta/recipes-devtools/python/python3-setuptools_32.1.1.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_32.1.1.bb
@@ -2,6 +2,7 @@ require python-setuptools.inc
 
 DEPENDS += "python3"
 DEPENDS_class-native += "python3-native"
+DEPENDS_class-nativesdk += "nativesdk-python3"
 
 inherit distutils3
 
@@ -14,11 +15,11 @@ do_install_append() {
 echo "./${SRCNAME}-${PV}-py${PYTHON_BASEVERSION}.egg" > 
${D}${PYTHON_SITEPACKAGES_DIR}/setuptools.pth
 }
 
-RDEPENDS_${PN} = "\
+RDEPENDS_${PN}_class-native = "\
   python3-distutils \
   python3-compression \
 "
-RDEPENDS_${PN}_class-target = "\
+RDEPENDS_${PN} = "\
   python3-ctypes \
   python3-distutils \
   python3-email \
@@ -34,4 +35,4 @@ RDEPENDS_${PN}_class-target = "\
   python3-unittest \
   python3-xml \
 "
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
2.11.0

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

On 02/06/2018 06:28 PM, Joshua Watt wrote:

On Tue, 2018-02-06 at 15:39 -0800, Martin Kelly wrote:

(ping)

Paul, what do you about the options we have here for making meson
work
properly in the SDK?

To recap, here are the available options. I'm wondering if you could
give your opinion on the best fit for how OE SDKs work:

- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a
toolchain


FWIW, I *just* pushed up a patch to add support for this to so that I
could have Icecream distributed compiling support in the SDK. I called
them post-relocation scripts, see http://lists.openembedded.org/piperma
il/openembedded-core/2018-February/147282.html

This patch show how you install a post-relocation script from a recipe:
http://lists.openembedded.org/pipermail/openembedded-core/2018-February
/147283.html (look at icecc-setup.sh). It's pretty easy and modeled
after the environment setup scripts. The issue that meson is having
sounds similar to what I encountered with Icecream: something needed in
the SDK can only really be generated by host system when the SDK is
installed. There isn't enough information or the ability to generate it
beforehand when the SDK is constructed by Yocto.

Granted, this patch has not yet gone through the rigors of code review
so it will likely change, but I think that it is safe to say that such
a feature would be useful for more that just meson.



I think this is exactly what we need, thanks so much! When your patches 
get merged, I'll try this out with meson.

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

(ping)

Paul, what do you about the options we have here for making meson work 
properly in the SDK?


To recap, here are the available options. I'm wondering if you could 
give your opinion on the best fit for how OE SDKs work:


- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a toolchain 
file and then runs meson pointing to it.

- Change meson to support pulling in env vars in meson.cross, and use a
fixed meson.cross file that references the env vars.

On 01/17/2018 09:47 AM, Martin Kelly wrote:

Paul, any opinion?

On 01/12/2018 04:35 AM, Alexander Kanavin wrote:

On 01/11/2018 09:22 PM, Martin Kelly wrote:
Khem and Alexander, could you comment on which solution is preferable 
from an SDK standpoint? Otherwise, could you nominate someone else to 
do so in your place? :)


I'm not sure who is the resident SDK expert, perhaps Paul Eggleton?

Alex

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

[OE-core] [pyro][PATCH] python3-nose: rename ${bindir}/nosetests into ${bindir}/nosetests3

[Martin Kelly]

From: Denys Dmytriyenko 

This resolves a conflict when both python-nose and python3-nose are pulled
into an image and try to install ${bindir}/nosetests binary.

This matches with how other distros are solving this problem, e.g. Debian:
https://packages.debian.org/jessie/all/python3-nose/filelist

Also, other packages like python3-setuptools are already doing the same with
their binaries.

Signed-off-by: Denys Dmytriyenko 
Signed-off-by: Ross Burton 
Signed-off-by: Martin Kelly 
---
 meta/recipes-devtools/python/python3-nose_1.3.7.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-nose_1.3.7.bb 
b/meta/recipes-devtools/python/python3-nose_1.3.7.bb
index 99bba4403f..1e2ff74f57 100644
--- a/meta/recipes-devtools/python/python3-nose_1.3.7.bb
+++ b/meta/recipes-devtools/python/python3-nose_1.3.7.bb
@@ -17,6 +17,10 @@ S = "${WORKDIR}/nose-${PV}"
 
 inherit setuptools3
 
+do_install_append() {
+mv ${D}${bindir}/nosetests ${D}${bindir}/nosetests3
+}
+
 RDEPENDS_${PN}_class-target = "\
   python3-unittest \
   "
-- 
2.11.0

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

[OE-core] [pyro][PATCH] distutils-base.bbclass: Do not use -pie with hardening

[Martin Kelly]

From: Khem Raj 

Fix build when PIE is turned on. It tries to build
.so file using -pie and -shared flags together because
its doing compile and link in same step CFLAGS and LDFLAGS
are combined and does not work, ending in errors e.g.

| 
/mnt/a/oe/build/tmp/work/cortexa7t2hf-neon-vfpv4-bec-linux-musleabi/python-pygpgme/0.3-r0/recipe-sysroot/usr/l
ib/Scrt1.o: In function `_start_c':
| /usr/src/debug/musl/1.1.16+gitAUTOINC+179766aa2e-r0/git/crt/crt1.c:17: 
undefined reference to `main'
| collect2: error: ld returned 1 exit status

This error while cryptic is due to the fact that we are
building a shared library but also pass -pie flag to the link
step after specify LDHSARED ( which is -shared linker flags )

we can not use -pie when doing shared libs. This is true for all the python
modules inheriting setup tools

Disable the pie flags thusly for all modules using setuptools since
this setting is done in setuptools makefiles which are then used
during module compiles

Backport notes:
In master, this commit is reverted in master in favor of using GCCPIE =
"--enable-default-pie" in security_flags.inc. However, backporting that change
introduces many merge conflicts and will be a serious maintenance issue, so I
think it's safest to just backport this small change, which fixes build failures
in python-cffi and likely other recipes.

For completeness, this is the list of commits in OE-core master that will
supersede this change:

- 1c7e195c94764d680a12a49b870f04cd58860f81
  "gcc: Introduce a knob to configure gcc to default to PIE"
- e93765ffb5718b0fce84f0b8123963176dea95e4
  "security_flags.inc: Delete pinnings for SECURITY_NO_PIE_CFLAGS"
- fcfe6d4ab4460f8358e13023022a5e909941ca93
  distutils,setuptools: Delete use of SECURITY_NO_PIE_CFLAGS

Signed-off-by: Khem Raj 
Signed-off-by: Ross Burton 
Signed-off-by: Martin Kelly 
---
 meta/classes/distutils-common-base.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/distutils-common-base.bbclass 
b/meta/classes/distutils-common-base.bbclass
index 824a1b68b1..fa733c672c 100644
--- a/meta/classes/distutils-common-base.bbclass
+++ b/meta/classes/distutils-common-base.bbclass
@@ -11,3 +11,5 @@ FILES_${PN}-dev += "\
   ${libdir}/pkgconfig \
   ${PYTHON_SITEPACKAGES_DIR}/*.la \
 "
+
+SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
-- 
2.11.0

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

[OE-core] [PATCH 3/3] meson.bbclass: add MESON_LINK_ARGS to vardeps

[Martin Kelly]

Currently, we include MESON_C_ARGS in write_config[vardeps], but we
don't include MESON_LINK_ARGS, which also affects meson.cross. In
addition, we include TOOLCHAIN_OPTIONS, from which both are derived.

Add MESON_LINK_ARGS, and remove TOOLCHAIN_OPTIONS, which does not
directly appear in meson.cross and should be pulled in indirectly by
MESON_C_ARGS and MESON_LINK_ARGS.

Signed-off-by: Martin Kelly 
---
 meta/classes/meson.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 4ab242dcfd..91ac652651 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -44,7 +44,7 @@ def meson_array(var, d):
 return "', '".join(d.getVar(var).split()).join(("'", "'"))
 
 addtask write_config before do_configure
-do_write_config[vardeps] += "MESON_C_ARGS MESON_CPP_ARGS TOOLCHAIN_OPTIONS"
+do_write_config[vardeps] += "MESON_C_ARGS MESON_CPP_ARGS MESON_LINK_ARGS"
 do_write_config() {
 # This needs to be Py to split the args into single-element lists
 cat >${WORKDIR}/meson.cross <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] meson.bbclass: include C{, XX}FLAGS in cross args

[Martin Kelly]

Currently, CFLAGS and CXXFLAGS are not making it into the compile line.
This is because meson appends CFLAGS/CXXFLAGS from the environment only
for native but not for cross builds (probably to keep cross-builds more
isolated). As a result, we need to make sure these vars goes into
meson.cross. This is similar to what cmake.bbclass does with
OECMAKE_C_FLAGS and OECMAKE_CXX_FLAGS.

Change c_args and cpp_args in meson.cross to include these vars, and
update write_config[vardeps] accordingly.

Signed-off-by: Martin Kelly 
---
 meta/classes/meson.bbclass | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index f9cee00c07..4ab242dcfd 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -26,8 +26,10 @@ MESONOPTS = " --prefix ${prefix} \
   --localstatedir ${localstatedir} \
   --sharedstatedir ${sharedstatedir}"
 
-MESON_C_ARGS = "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-MESON_LINK_ARGS = "${MESON_C_ARGS} ${LDFLAGS}"
+MESON_TOOLCHAIN_ARGS = "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
+MESON_C_ARGS = "${MESON_TOOLCHAIN_ARGS} ${CFLAGS}"
+MESON_CPP_ARGS = "${MESON_TOOLCHAIN_ARGS} ${CXXFLAGS}"
+MESON_LINK_ARGS = "${MESON_TOOLCHAIN_ARGS} ${LDFLAGS}"
 
 # both are required but not used by meson
 MESON_HOST_ENDIAN = "bogus-endian"
@@ -42,7 +44,7 @@ def meson_array(var, d):
 return "', '".join(d.getVar(var).split()).join(("'", "'"))
 
 addtask write_config before do_configure
-do_write_config[vardeps] += "MESON_C_ARGS TOOLCHAIN_OPTIONS"
+do_write_config[vardeps] += "MESON_C_ARGS MESON_CPP_ARGS TOOLCHAIN_OPTIONS"
 do_write_config() {
 # This needs to be Py to split the args into single-element lists
 cat >${WORKDIR}/meson.cross <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] meson.bbclass: compile with --buildtype plain

[Martin Kelly]

OE manages all the compile flags, so we don't want meson to inject its
own flags. Currently, it's injecting -O0 and causing build breaks when
security flags are enabled (because _FORTIFY_SOURCE requires an
optimized build and meson defaults to a debug -O0 build).

Add --buildtype plain so meson will not add its own optimization flags.

Signed-off-by: Martin Kelly 
---
 meta/classes/meson.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 4a4c51f840..f9cee00c07 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -13,6 +13,7 @@ def noprefix(var, d):
 return d.getVar(var).replace(d.getVar('prefix') + '/', '', 1)

 MESONOPTS = " --prefix ${prefix} \
+  --buildtype plain \
   --bindir ${@noprefix('bindir', d)} \
   --sbindir ${@noprefix('sbindir', d)} \
   --datadir ${@noprefix('datadir', d)} \
--
2.11.0

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

Paul, any opinion?

On 01/12/2018 04:35 AM, Alexander Kanavin wrote:

On 01/11/2018 09:22 PM, Martin Kelly wrote:
Khem and Alexander, could you comment on which solution is preferable 
from an SDK standpoint? Otherwise, could you nominate someone else to 
do so in your place? :)


I'm not sure who is the resident SDK expert, perhaps Paul Eggleton?

Alex

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

On 01/11/2018 11:33 AM, Martin Kelly wrote:

On 01/11/2018 11:26 AM, Khem Raj wrote:

On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly  wrote:
Khem and Alexander, could you comment on which solution is preferable 
from
an SDK standpoint? Otherwise, could you nominate someone else to do 
so in

your place? :)

Here are the possible solutions proposed:

- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a 
toolchain file

and then runs meson pointing to it.
- Change meson to support pulling in env vars in meson.cross, and use a
fixed meson.cross file that references the env vars.



We already have environment file, could it be used for meson as well 
and needed

bits be generated during build time for SDK.



Yes, it is certainly technically possible. I'm wondering whether or not 
that involves ugly special-casing, as I'm not familiar with the SDK 
extraction code. If not, it's probably the best solution.




Specifically, looking at script meta/files/toolchain-shar-extract.sh, I 
don't see a clean way to do something special for a single meson 
package. There is no per-package hook or similar logic.




On 01/09/2018 12:33 PM, Martin Kelly wrote:


On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:


On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly  wrote:


Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue 
is to
ignore $CC for internal sanity checking when a cross file is 
specified.

In
that way, meson would probe the system and use the normal gcc for 
sanity

checking while still using the cross file for the actual build.



That breaks the whole reason the sanity check is there in the first
place. Its point is to test "is the native compiler the user has
specified working and capable of creating executables". If we change
it then that becomes "is the system default compiler (which we might
or might not use) working". We need to be able to support the case of
users defining both the cross compiler and the native compiler. So
something like this:

CC=/some/native/cc meson --cross-file=mycross.txt 



Yeah, that makes sense. The issue here is that the OE SDK sets CC, 
CXX etc
to point to the cross compiler, not to the native compiler, so when 
meson
assumes it's native, things will break. I think we need a way to 
specify
both cross and host compilers separately from the env vars. For 
example, if

the binaries section were split in two: "host-binaries" and
"target-binaries", then in the cross-file case, meson could use
"host-binaries" instead of looking at CC and other vars.

Right now, the SDK contains fixed contents, and there is some 
top-level

logic
for rewriting a few paths to make everything relocatable. I don't 
think

OE
wants to inject a special-case one-time generation of the 
toolchain file

at SDK
extraction time, as it circumvents the normal build process,



Would it not be possible to generate the cross file when creating the
SDK contents originally? The only change it would need is the same
kind of path fixing. The setup does not really change.



I think it would be possible, but I'm guessing it would require some
special-casing that we may not want to do. Khem probably has a better
informed opinion on this than I.


Another approach would be to generate the toolchain file truly
"on-the-fly",
such that the meson command points to a script that first generates a
toolchain file based on the contents of CC, CXX, etc. and then runs
meson. I
think this is a bad idea because it is complex (will definitely 
surprise

people) and slow. It also breaks people in surprising ways when they
accidentally use a meson from outside the SDK due to the PATH setup.



This is, roughly, what Debian does currently.



That's too bad :).

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

On 01/11/2018 11:26 AM, Khem Raj wrote:

On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly  wrote:

Khem and Alexander, could you comment on which solution is preferable from
an SDK standpoint? Otherwise, could you nominate someone else to do so in
your place? :)

Here are the possible solutions proposed:

- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a toolchain file
and then runs meson pointing to it.
- Change meson to support pulling in env vars in meson.cross, and use a
fixed meson.cross file that references the env vars.



We already have environment file, could it be used for meson as well and needed
bits be generated during build time for SDK.



Yes, it is certainly technically possible. I'm wondering whether or not 
that involves ugly special-casing, as I'm not familiar with the SDK 
extraction code. If not, it's probably the best solution.




On 01/09/2018 12:33 PM, Martin Kelly wrote:


On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:


On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly  wrote:


Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue is to
ignore $CC for internal sanity checking when a cross file is specified.
In
that way, meson would probe the system and use the normal gcc for sanity
checking while still using the cross file for the actual build.



That breaks the whole reason the sanity check is there in the first
place. Its point is to test "is the native compiler the user has
specified working and capable of creating executables". If we change
it then that becomes "is the system default compiler (which we might
or might not use) working". We need to be able to support the case of
users defining both the cross compiler and the native compiler. So
something like this:

CC=/some/native/cc meson --cross-file=mycross.txt 



Yeah, that makes sense. The issue here is that the OE SDK sets CC, CXX etc
to point to the cross compiler, not to the native compiler, so when meson
assumes it's native, things will break. I think we need a way to specify
both cross and host compilers separately from the env vars. For example, if
the binaries section were split in two: "host-binaries" and
"target-binaries", then in the cross-file case, meson could use
"host-binaries" instead of looking at CC and other vars.


Right now, the SDK contains fixed contents, and there is some top-level
logic
for rewriting a few paths to make everything relocatable. I don't think
OE
wants to inject a special-case one-time generation of the toolchain file
at SDK
extraction time, as it circumvents the normal build process,



Would it not be possible to generate the cross file when creating the
SDK contents originally? The only change it would need is the same
kind of path fixing. The setup does not really change.



I think it would be possible, but I'm guessing it would require some
special-casing that we may not want to do. Khem probably has a better
informed opinion on this than I.


Another approach would be to generate the toolchain file truly
"on-the-fly",
such that the meson command points to a script that first generates a
toolchain file based on the contents of CC, CXX, etc. and then runs
meson. I
think this is a bad idea because it is complex (will definitely surprise
people) and slow. It also breaks people in surprising ways when they
accidentally use a meson from outside the SDK due to the PATH setup.



This is, roughly, what Debian does currently.



That's too bad :).

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

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

[Martin Kelly]

On 01/11/2018 09:49 AM, Richard Purdie wrote:

On Thu, 2018-01-11 at 13:35 +0200, Alexander Kanavin wrote:

On 01/10/2018 09:11 PM, Martin Kelly wrote:


Yes, to be clear, I'm not griping, as I'm very happy meson landed
in
OE-core, and I'm working on SDK support now. I have an OE-core
thread
going with meson upstream to get the issue fixed.

To be clear though, I'm not sure it even regressed. AFAICT, it
never
quite worked.

Where would I add SDK tests for this?

meta/lib/oeqa/selftest/cases is the place. Not sure what existing
SDK
tests are already there.


Actually, no. See:

$ ls meta/lib/oeqa/sdk/cases/
buildcpio.py
buildgalculator.py
buildlzip.py
gcc.py
perl.py
python.py

There is also "sdkext" for the eSDK.

You'd run these with:

INHERIT += "testimage"

and then

bitbake  -c testsdk

Cheers,

Richard



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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

Khem and Alexander, could you comment on which solution is preferable 
from an SDK standpoint? Otherwise, could you nominate someone else to do 
so in your place? :)


Here are the possible solutions proposed:

- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a toolchain 
file and then runs meson pointing to it.
- Change meson to support pulling in env vars in meson.cross, and use a 
fixed meson.cross file that references the env vars.


On 01/09/2018 12:33 PM, Martin Kelly wrote:

On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:

On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly  wrote:


Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue is to
ignore $CC for internal sanity checking when a cross file is 
specified. In

that way, meson would probe the system and use the normal gcc for sanity
checking while still using the cross file for the actual build.


That breaks the whole reason the sanity check is there in the first
place. Its point is to test "is the native compiler the user has
specified working and capable of creating executables". If we change
it then that becomes "is the system default compiler (which we might
or might not use) working". We need to be able to support the case of
users defining both the cross compiler and the native compiler. So
something like this:

CC=/some/native/cc meson --cross-file=mycross.txt 



Yeah, that makes sense. The issue here is that the OE SDK sets CC, CXX 
etc to point to the cross compiler, not to the native compiler, so when 
meson assumes it's native, things will break. I think we need a way to 
specify both cross and host compilers separately from the env vars. For 
example, if the binaries section were split in two: "host-binaries" and 
"target-binaries", then in the cross-file case, meson could use 
"host-binaries" instead of looking at CC and other vars.


Right now, the SDK contains fixed contents, and there is some 
top-level logic
for rewriting a few paths to make everything relocatable. I don't 
think OE
wants to inject a special-case one-time generation of the toolchain 
file at SDK

extraction time, as it circumvents the normal build process,


Would it not be possible to generate the cross file when creating the
SDK contents originally? The only change it would need is the same
kind of path fixing. The setup does not really change.



I think it would be possible, but I'm guessing it would require some 
special-casing that we may not want to do. Khem probably has a better 
informed opinion on this than I.


Another approach would be to generate the toolchain file truly 
"on-the-fly",

such that the meson command points to a script that first generates a
toolchain file based on the contents of CC, CXX, etc. and then runs 
meson. I

think this is a bad idea because it is complex (will definitely surprise
people) and slow. It also breaks people in surprising ways when they
accidentally use a meson from outside the SDK due to the PATH setup.


This is, roughly, what Debian does currently.



That's too bad :).

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

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

[Martin Kelly]

On 01/10/2018 10:48 AM, Richard Purdie wrote:

On Wed, 2018-01-10 at 09:55 -0800, Martin Kelly wrote:

On 01/05/2018 06:57 AM, Alexander Kanavin wrote:


On 01/05/2018 01:47 PM, Burton, Ross wrote:


Do we even need gnomebase-meson with this?  I can see a future
where
GNOME is entirely Meson and then we could just switch the
default
GNOMEBASEBUILDCLASS from autotools to meson.

(prior art being the tarball compression type)


I'm fine with this. Just so everyone else knows: RP has actually
made
the change already, and merged everything to master, so the YP
supports
meson as a first class citizen now.

Alex

Technically I'd call it a 0.9-class citizen, as the SDK doesn't work
yet
:), but still a whole lot better than 0.


We'll get there and patches are very welcome.

Also *very* welcome would be some SDK tests which illustrate the
problem so we can a) fix it and b) ensure it doesn't regress again!

Cheers,

Richard



Yes, to be clear, I'm not griping, as I'm very happy meson landed in 
OE-core, and I'm working on SDK support now. I have an OE-core thread 
going with meson upstream to get the issue fixed.


To be clear though, I'm not sure it even regressed. AFAICT, it never 
quite worked.


Where would I add SDK tests for this?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

[Martin Kelly]

On 01/05/2018 06:57 AM, Alexander Kanavin wrote:

On 01/05/2018 01:47 PM, Burton, Ross wrote:
Do we even need gnomebase-meson with this?  I can see a future where 
GNOME is entirely Meson and then we could just switch the default 
GNOMEBASEBUILDCLASS from autotools to meson.


(prior art being the tarball compression type)



I'm fine with this. Just so everyone else knows: RP has actually made 
the change already, and merged everything to master, so the YP supports 
meson as a first class citizen now.


Alex


Technically I'd call it a 0.9-class citizen, as the SDK doesn't work yet 
:), but still a whole lot better than 0.

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:

On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly  wrote:


Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue is to
ignore $CC for internal sanity checking when a cross file is specified. In
that way, meson would probe the system and use the normal gcc for sanity
checking while still using the cross file for the actual build.


That breaks the whole reason the sanity check is there in the first
place. Its point is to test "is the native compiler the user has
specified working and capable of creating executables". If we change
it then that becomes "is the system default compiler (which we might
or might not use) working". We need to be able to support the case of
users defining both the cross compiler and the native compiler. So
something like this:

CC=/some/native/cc meson --cross-file=mycross.txt 



Yeah, that makes sense. The issue here is that the OE SDK sets CC, CXX 
etc to point to the cross compiler, not to the native compiler, so when 
meson assumes it's native, things will break. I think we need a way to 
specify both cross and host compilers separately from the env vars. For 
example, if the binaries section were split in two: "host-binaries" and 
"target-binaries", then in the cross-file case, meson could use 
"host-binaries" instead of looking at CC and other vars.



Right now, the SDK contains fixed contents, and there is some top-level logic
for rewriting a few paths to make everything relocatable. I don't think OE
wants to inject a special-case one-time generation of the toolchain file at SDK
extraction time, as it circumvents the normal build process,


Would it not be possible to generate the cross file when creating the
SDK contents originally? The only change it would need is the same
kind of path fixing. The setup does not really change.



I think it would be possible, but I'm guessing it would require some 
special-casing that we may not want to do. Khem probably has a better 
informed opinion on this than I.



Another approach would be to generate the toolchain file truly "on-the-fly",
such that the meson command points to a script that first generates a
toolchain file based on the contents of CC, CXX, etc. and then runs meson. I
think this is a bad idea because it is complex (will definitely surprise
people) and slow. It also breaks people in surprising ways when they
accidentally use a meson from outside the SDK due to the PATH setup.


This is, roughly, what Debian does currently.



That's too bad :).
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

On 01/09/2018 02:06 AM, Nirbheek Chauhan wrote:

On Tue, Jan 9, 2018 at 3:20 PM, Nirbheek Chauhan
 wrote:

If we want to setup a cross-file to use these arguments, we would have to
generate the cross-file on-the-fly (not good).


Out of interest, why is that not good? That is precisely what Gentoo
does and it has to solve the same problems here that Yocto is facing.



To expand on this, the reason why meson requires a cross file for
cross-compilation is because we allow build files to use both native
and cross compilers within the same build. This is quite useful when
you want to build a tool (or generator) as part of the project that
you then use to build/generate other things that are used in the cross
build.



To be clear, I think the cross-file is extremely important for correct 
cross-compilation, and I'm fully sold on its benefits. I believe OE sets 
CC, CXX, LD not because it's the best way to do cross compilation but 
because it needs to support all possible tools, including straight 
Makefiles with no wrappers.

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

Re: [OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

+CC Khem Raj, who has done a lot of work on the SDK and may have an 
opinion about handling relocatable cross files.


On 01/09/2018 01:50 AM, Nirbheek Chauhan wrote:

On Tue, Jan 9, 2018 at 5:21 AM, Martin Kelly  wrote:

[Jussi Pakkanen, Nirbheek Chauhan, I know you may not be on the list; I
added you to get Yocto/OE and meson upstream all on the same thread to
discuss integrating the two]

Hi all,

Recently, we got meson added to OE-core as part of Yocto (thanks Alexander
Kanavin!).


Great to hear that! Thanks for your work, Alexander :)

[snip]

- The cross-file does not support relocatable cross-tools. This is an issue
because OE SDKs are self-extracting shell scripts that can be installed
anywhere on a machine. Once installed, they populate the env with --sysroot=
and other flags pointing into the installed SDK location. For example, if I
install an ARM SDK into /tmp/sdk, I would get something like this:



It does support that as of 0.43:

http://mesonbuild.com/Release-notes-for-0-43-0.html#can-override-executables-in-the-cross-file

I believe this should solve your problems with cross-tools at least.
Note that this also works for pkg-config, g-ir-compiler, g-ir-scanner,
etc.



This sounds like the right idea, but in its current form I'm not sure if 
it will solve the problem. The issue I hit when building actually were 
not caused by anything in the meson build file itself; they were caused 
by the meson sanity checker. meson appears to assume that anything found 
in CC, CXX, etc. are all native tools:


$ . /tmp/sdk/environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi

$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon-vfpv4 
-mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi


$ meson --cross-file /tmp/meson.cross build .
The Meson build system
Version: 0.43.0
Source dir: /home/martin/xlib
Build dir: /home/martin/xlib/build
Build type: cross build
Project name: xlib
Native C compiler: arm-poky-linux-gnueabi-gcc -march=armv7ve -marm 
-mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi 
(gcc 7.2.0)
Appending CFLAGS from environment: ' -O2 -pipe -g 
-feliminate-unused-debug-types '
Appending LDFLAGS from environment: '-Wl,-O1 -Wl,--hash-style=gnu 
-Wl,--as-needed'

Cross C compiler: arm-poky-linux-gnueabi-gcc (gcc 7.2.0)
/home/martin/xlib/build/meson-private/sanitycheckcpp.exe: error while 
loading shared libraries: libstdc++.so.6: cannot open shared object 
file: No such file or directory


Meson encountered an error in file meson.build, line 1, column 0:
Executables created by cpp compiler arm-poky-linux-gnueabi-g++ 
-march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi are 
not runnable.


Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue is to 
ignore $CC for internal sanity checking when a cross file is specified. 
In that way, meson would probe the system and use the normal gcc for 
sanity checking while still using the cross file for the actual build.



$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon-vfpv4
-mfloat-abi=hard -mcpu=cortex-a7
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi

If we want to setup a cross-file to use these arguments, we would have to
generate the cross-file on-the-fly (not good).


Out of interest, why is that not good? That is precisely what Gentoo
does and it has to solve the same problems here that Yocto is facing.



Right now, the SDK contains fixed contents, and there is some top-level 
logic for rewriting a few paths to make everything relocatable. I don't 
think OE wants to inject a special-case one-time generation of the 
toolchain file at SDK extraction time, as it circumvents the normal 
build process, which normally sets up the right environment for 
generating the right toolchain file. For example, cmake generates its 
toolchain as part of the build process and the SDK just extracts it 
without special knowledge of cmake or its contents. To my knowledge, 
nothing else in the OE special-cases its extraction logic, so it would 
be a special-case that would likely cause us problems in the future. At 
the very least, we would need to get more OE maintainers to voice an 
opinion on this.


Another approach would be to generate the toolchain file truly 
"on-the-fly", such that the meson command points to a script that first 
generates a toolchain file based on the contents of CC, CXX, etc. and 
then runs meson. I think this is a bad idea because it is complex (will 
definitely surprise people) and slow. It also breaks people in 
surprising ways when they accidentally use a meson from outside the SDK 
due to the PATH setup.

--
___

[OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

[Jussi Pakkanen, Nirbheek Chauhan, I know you may not be on the list; I 
added you to get Yocto/OE and meson upstream all on the same thread to 
discuss integrating the two]


Hi all,

Recently, we got meson added to OE-core as part of Yocto (thanks 
Alexander Kanavin!). That said, it doesn't yet work with the Yocto SDK. 
I tried adding SDK support to the existing meson recipe (BBCLASSEXTEND = 
"nativesdk") and hit some issues that require some thought.


I wanted to get OE and meson upstream on one thread to discuss the 
issues and come up with clean solutions for solving them.


The issues I'm seeing arise because meson and OE appear to have 
differing views of how a cross-compile should look. Specifically:


- meson assumes that CC, CXX, CFLAGS, and other vars point to native 
tools. However, in an OE SDK, they point to cross-tools. Thus meson 
fails under the SDK when because it tries to use the cross-tools for 
native tasks (I get the error "nm does not work" because meson tried to 
use the cross-nm for symbol extraction).


- The cross-file does not support relocatable cross-tools. This is an 
issue because OE SDKs are self-extracting shell scripts that can be 
installed anywhere on a machine. Once installed, they populate the env 
with --sysroot= and other flags pointing into the installed SDK 
location. For example, if I install an ARM SDK into /tmp/sdk, I would 
get something like this:


$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon-vfpv4 
-mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi


If we want to setup a cross-file to use these arguments, we would have 
to generate the cross-file on-the-fly (not good). The way the cmake 
toolchain file solves this is by encoding env vars into the toolchain 
file, which then picks up the dynamically set CC, CXX, CFLAGS that point 
to the cross-tools:


https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake

I'm not a meson expert, so I don't know if these are the right 
solutions, but here are my proposed solutions just so I can get the 
discussion started:


- When --cross-file is specified, make meson not assume that env vars 
like CC and CXX and similar point to native tools. Instead, just ignore 
them and look for native tools in the normal way that meson does when 
these vars are unspecified. We still may wan to inject CFLAGS, LDFLAGS, 
etc into the build because people may mess with them interactively 
during development.


- Add the ability to reference env vars in cross files to support 
relocatable toolchains.


This would basically make meson behave the way cmake does today.

Of course, others may have better ideas; I welcome thoughts.

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

Re: [OE-core] [PATCH 1/1] meson: export native env only for native build

[Martin Kelly]

On 11/16/2017 09:52 AM, Alexander Kanavin wrote:

On 11/15/2017 07:53 PM, Martin Kelly wrote:


+meson_do_configure_prepend_class-native() {
+    export PKG_CONFIG="pkg-config-native"
+}
+


What does this bit do? Should it go to a separate patch?

Alex


This is from Ross Burton's patch to meta-oe 
6e2d975fc16f4228a2d952bde1a874f337281ada ("meson: export PKG_CONFIG to 
use pkg-config-native for native builds").


Since it's already present in meta-oe, this logic doesn't need a 
separate patch for meta-oe; I just moved the line into 
meson_do_configure instead of making it global. However, your branch 
doesn't have Ross's patch. Ideally, I think you should first cherry-pick 
Ross Burton's patch into your branch and then put my patch on top of it.

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

Re: [OE-core] [PATCH 1/2] systemctl-native: add target.wants to target regex

[Martin Kelly]

I looked again at the log failures, and it's hard to conclude anything 
without more information.


Is it possible to get a baseline without this patch? For example, step 
53 fails with SSH refusing the connection. Does this ever happen without 
the patch? Step 47 fails because connman is not running and because 
test_check_rpm_install_removal_log_file_size fails. I'm wondering if 
that ever happens in normal test runs.


Another useful thing would be getting the output of the rootfs creation 
logs, which would list the exact systemctl-native commands used so we 
could see if some service wasn't enabled when it should be. Again, 
systemctl *should* fail and cause a build failure if that happens, but 
there could be some bug.


On 11/09/2017 05:01 PM, Martin Kelly wrote:
Got it, thanks. My patch *should* just convert runtime failures into 
compile-time failures, but it looks like we're seeing actual runtime 
failures, so I'll try to figure out what happened.


On 11/08/2017 12:31 PM, Burton, Ross wrote:

Thanks for reminding me.  :)

1/2 is queued but 2/2 was implicated in a number of systemd-related 
boot failures on the autobuilder 
(https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/553).


I've not yet got around to looking at exactly what sanity test 5 and 7 
do to trigger this.


Ross

On 8 November 2017 at 17:40, Martin Kelly <mailto:mke...@xevo.com>> wrote:


    (ping) for this patch series.

    On 10/16/2017 09:31 AM, Martin Kelly wrote:

    The regex for acceptable systemd WantedBy/RequiredBy targets
    does not include
    target.wants, so a line like this:

    WantedBy=multi-user.target.wants

    gets silently ignored, even though it works fine on a real 
system.


    Signed-off-by: Martin Kelly mailto:mke...@xevo.com>>
    ---
   meta/recipes-core/systemd/systemd-systemctl/systemctl | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

    diff --git
    a/meta/recipes-core/systemd/systemd-systemctl/systemctl
    b/meta/recipes-core/systemd/systemd-systemctl/systemctl
    index efad14ce17..6e5a1b7181 100755
    --- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
    +++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
    @@ -108,7 +108,7 @@ for service in $services; do
         # If any new unit types are added to systemd they
    should be added
         # to this regular expression.
    -  
 unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|path\|timer\|snapshot\)\s*$' 

    +  
 unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|target\.wants\|path\|timer\|snapshot\)\s*$' 


         if [ "$action" = "preset" ]; then
                 action=`egrep -sh  $service
    $ROOT/etc/systemd/user-preset/*.preset | cut -f1 -d' '`
                 if [ -z "$action" ]; then

    --     ___
    Openembedded-core mailing list
    Openembedded-core@lists.openembedded.org
    <mailto:Openembedded-core@lists.openembedded.org>
    http://lists.openembedded.org/mailman/listinfo/openembedded-core
    <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] [morty backport][PATCH 0/2] tcf-agent fixes

[Martin Kelly]

I'm not a maintainer, but both of these look good to me, thanks!

On 11/14/2017 11:56 AM, Javier Viguera wrote:

Hi all,

There are a couple of commits in master fixing the tcf-agent bootscript and 
systemd service files so the daemon is properly kill on reboot/shutdown.

These patches backport the fixes to Morty.

Regards,

Javier Viguera



--
Jan Kiszka (1):
   tcf-agent: Fix daemon termination

Martin Kelly (1):
   tcf-agent: kill with USR2 in systemd stop

  meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init| 12 +---
  meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service |  2 ++
  2 files changed, 3 insertions(+), 11 deletions(-)


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

Re: [OE-core] ✗ patchtest: failure for meson bugfix

[Martin Kelly]

This is expected, as the patch is intended to apply to Alexander 
Kanavin's poky-contrib akanavin/meson branch, not oe-core master.


On 11/15/2017 10:02 AM, Patchwork wrote:

== Series Details ==

Series: meson bugfix
Revision: 1
URL   : https://patchwork.openembedded.org/series/9809/
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 a17f3ec910)



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 0/1] [poky-contrib] meson bugfix

[Martin Kelly]

This patch is intended to be applied on top of Alexander Kanavin's poky-contrib
branch akanavin/meson in preparation for meson moving into OE-core.

Martin Kelly (1):
  meson: export native env only for native build

 meta/classes/meson.bbclass | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

--
2.11.0

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

[OE-core] [PATCH 1/1] meson: export native env only for native build

[Martin Kelly]

Although the meson crossfile should take care of setting the right cross
environment for a target build, meson slurps any set CFLAGS, CXXFLAGS,
LDFLAGS, and CPPFLAGS from the environment and injects them into the
build (see mesonbuild/environment.py:get_args_from_envvars for details).

This means that we are seeing native CFLAGS, CXXFLAGS, LDFLAGS, and
CPPFLAGS in the target build, which is wrong and causes build failures
when target and native have libraries in common (the linker gets
confused and bails).

That said, we *do* need to set certain vars for all builds so that meson
can find the right build tools. Without this, meson will fail during its
sanity checking step because it will determine the build tools to be
unrunnable since they output target instead of native artifacts.

The solution to all of this is to set CC, CXX, LD, and AR globally to
the native tools while setting the other native vars *only* for the
native build. For target builds, these vars will get overridden by the
cross file as we expect.

Signed-off-by: Martin Kelly 
---
 meta/classes/meson.bbclass | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index f6cf24c33a7..f64377efcba 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -9,13 +9,6 @@ do_configure[cleandirs] = "${B}"
 # Where the meson.build build configuration is
 MESON_SOURCEPATH = "${S}"
 
-# These variables in the environment override meson's *native* tools settings.
-# We have to unset them, so that meson doesn't pick up the cross tools and
-# use them for native builds.
-unset CC
-unset CXX
-unset AR
-
 def noprefix(var, d):
 return d.getVar(var, True).replace(d.getVar('prefix', True) + '/', '', 1)
 
@@ -91,6 +84,22 @@ meson_do_configure() {
 fi
 }
 
+meson_do_configure_prepend_class-target() {
+# Set these so that meson uses the native tools for its build sanity tests,
+# which require executables to be runnable. The cross file will still
+# override these for the target build. Note that we do *not* set CFLAGS,
+# LDFLAGS, etc. as they will be slurped in by meson and applied to the
+# target build, causing errors.
+export CC="${BUILD_CC}"
+export CXX="${BUILD_CXX}"
+export LD="${BUILD_LD}"
+export AR="${BUILD_AR}"
+}
+
+meson_do_configure_prepend_class-native() {
+export PKG_CONFIG="pkg-config-native"
+}
+
 do_compile[progress] = "outof:^\[(\d+)/(\d+)\]\s+"
 meson_do_compile() {
 ninja ${PARALLEL_MAKE}
-- 
2.11.0

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

Re: [OE-core] [PATCH 1/7] meson: add a recipe and class from meta-oe

[Martin Kelly]

Hi,

It looks to me like there are some changes here on top of a forked 
meson.bbclass from meta-oe. Did you rebase the changes on top of current 
meta-oe's meson? From a look at the git logs and file contents, it looks 
like it needs a rebase or we may drop some patches.


On 11/15/2017 03:08 AM, Alexander Kanavin wrote:

The original recipe has been provided and improved by:

Ross Burton 
Ricardo Ribalda Delgado 
Adam C. Foltzer 
Peter Kjellerstedt 
Linus Svensson 

I have added a couple patches to fix up gtk-doc and
gobject-introspection in cross-compilation environments.

Signed-off-by: Alexander Kanavin 
---
  meta/classes/meson.bbclass | 103 +++
  ...ix-issues-that-arise-when-cross-compiling.patch | 113 +
  ...rospection-determine-g-ir-scanner-and-g-i.patch |  41 
  meta/recipes-devtools/meson/meson_0.43.0.bb|  19 
  4 files changed, 276 insertions(+)
  create mode 100644 meta/classes/meson.bbclass
  create mode 100644 
meta/recipes-devtools/meson/meson/0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch
  create mode 100644 
meta/recipes-devtools/meson/meson/0002-gobject-introspection-determine-g-ir-scanner-and-g-i.patch
  create mode 100644 meta/recipes-devtools/meson/meson_0.43.0.bb

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
new file mode 100644
index 000..f6cf24c33a7
--- /dev/null
+++ b/meta/classes/meson.bbclass
@@ -0,0 +1,103 @@
+inherit python3native
+
+DEPENDS_append = " meson-native ninja-native"
+
+# As Meson enforces out-of-tree builds we can just use cleandirs
+B = "${WORKDIR}/build"
+do_configure[cleandirs] = "${B}"
+
+# Where the meson.build build configuration is
+MESON_SOURCEPATH = "${S}"
+
+# These variables in the environment override meson's *native* tools settings.
+# We have to unset them, so that meson doesn't pick up the cross tools and
+# use them for native builds.
+unset CC
+unset CXX
+unset AR
+
+def noprefix(var, d):
+return d.getVar(var, True).replace(d.getVar('prefix', True) + '/', '', 1)
+
+MESONOPTS = " --prefix ${prefix} \
+  --bindir ${@noprefix('bindir', d)} \
+  --sbindir ${@noprefix('sbindir', d)} \
+  --datadir ${@noprefix('datadir', d)} \
+  --libdir ${@noprefix('libdir', d)} \
+  --libexecdir ${@noprefix('libexecdir', d)} \
+  --includedir ${@noprefix('includedir', d)} \
+  --mandir ${@noprefix('mandir', d)} \
+  --infodir ${@noprefix('infodir', d)} \
+  --sysconfdir ${sysconfdir} \
+  --localstatedir ${localstatedir} \
+  --sharedstatedir ${sharedstatedir}"
+
+MESON_C_ARGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS}"
+MESON_LINK_ARGS = "${MESON_C_ARGS} ${LDFLAGS}"
+
+MESON_HOST_ENDIAN = "${@bb.utils.contains('SITEINFO_ENDIANNESS', 'be', 'big', 
'little', d)}"
+MESON_TARGET_ENDIAN = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'big', 
'little', d)}"
+
+EXTRA_OEMESON += "${PACKAGECONFIG_CONFARGS}"
+
+MESON_CROSS_FILE = ""
+MESON_CROSS_FILE_class-target = "--cross-file ${WORKDIR}/meson.cross"
+
+def meson_array(var, d):
+return "', '".join(d.getVar(var, True).split()).join(("'", "'"))
+
+addtask write_config before do_configure
+do_write_config[vardeps] += "MESON_C_ARGS TOOLCHAIN_OPTIONS"
+do_write_config() {
+# This needs to be Py to split the args into single-element lists
+cat >${WORKDIR}/meson.cross <
+Date: Fri, 4 Aug 2017 16:16:41 +0300
+Subject: [PATCH 1/3] gtkdoc: fix issues that arise when cross-compiling
+
+Specifically:
+1) Make it possible to specify a wrapper for executing binaries
+(usually, some kind of target hardware emulator, such as qemu)
+2) Explicitly provide CC and LD via command line, as otherwise gtk-doc will
+try to guess them, incorrectly.
+3) If things break down, print the full command with arguments,
+not just the binary name.
+4) Correctly determine the compiler/linker executables and cross-options when 
cross-compiling
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+
+---
+ mesonbuild/modules/gnome.py| 18 +++---
+ mesonbuild/scripts/gtkdochelper.py |  9 +++--
+ 2 files changed, 22 insertions(+), 5 deletions(-)
+
+diff --git a/mesonbuild/modules/gnome.py b/mesonbuild/modules/gnome.py
+index 6ec7040..4cfaefd 100644
+--- a/mesonbuild/modules/gnome.py
 b/mesonbuild/modules/gnome.py
+@@ -713,6 +713,10 @@ class GnomeModule(ExtensionModule):
+ '--mode=' + mode]
+ if namespace:
+ args.append('--namespace=' + namespace)
++gtkdoc_exe_wrapper = 
state.environment.cross_info.config["properties"].get('gtkdoc_exe_wrapper', 
None)
++if gtkdoc_exe_wrapper is not None:
++args.append('--gtkdoc-exe-wrapper=' + gtkdoc_exe_wrapper)
++
+ args += self._unpack_args('--htmlargs=', 'html_args', kwargs)
+ args += self._unpack_args('--scanargs=', 'scan_args', kwargs)

Re: [OE-core] [PATCH 1/7] meson: add a recipe and class from meta-oe

[Martin Kelly]

Correction: I took another look after merging in my meson patch, and I 
think your branch is fully current.


On 11/15/2017 09:27 AM, Martin Kelly wrote:

Hi,

It looks to me like there are some changes here on top of a forked 
meson.bbclass from meta-oe. Did you rebase the changes on top of current 
meta-oe's meson? From a look at the git logs and file contents, it looks 
like it needs a rebase or we may drop some patches.


On 11/15/2017 03:08 AM, Alexander Kanavin wrote:

The original recipe has been provided and improved by:

Ross Burton 
Ricardo Ribalda Delgado 
Adam C. Foltzer 
Peter Kjellerstedt 
Linus Svensson 

I have added a couple patches to fix up gtk-doc and
gobject-introspection in cross-compilation environments.

Signed-off-by: Alexander Kanavin 
---
  meta/classes/meson.bbclass | 103 
+++
  ...ix-issues-that-arise-when-cross-compiling.patch | 113 
+

  ...rospection-determine-g-ir-scanner-and-g-i.patch |  41 
  meta/recipes-devtools/meson/meson_0.43.0.bb    |  19 
  4 files changed, 276 insertions(+)
  create mode 100644 meta/classes/meson.bbclass
  create mode 100644 
meta/recipes-devtools/meson/meson/0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch 

  create mode 100644 
meta/recipes-devtools/meson/meson/0002-gobject-introspection-determine-g-ir-scanner-and-g-i.patch 


  create mode 100644 meta/recipes-devtools/meson/meson_0.43.0.bb

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
new file mode 100644
index 000..f6cf24c33a7
--- /dev/null
+++ b/meta/classes/meson.bbclass
@@ -0,0 +1,103 @@
+inherit python3native
+
+DEPENDS_append = " meson-native ninja-native"
+
+# As Meson enforces out-of-tree builds we can just use cleandirs
+B = "${WORKDIR}/build"
+do_configure[cleandirs] = "${B}"
+
+# Where the meson.build build configuration is
+MESON_SOURCEPATH = "${S}"
+
+# These variables in the environment override meson's *native* tools 
settings.
+# We have to unset them, so that meson doesn't pick up the cross 
tools and

+# use them for native builds.
+unset CC
+unset CXX
+unset AR
+
+def noprefix(var, d):
+    return d.getVar(var, True).replace(d.getVar('prefix', True) + 
'/', '', 1)

+
+MESONOPTS = " --prefix ${prefix} \
+  --bindir ${@noprefix('bindir', d)} \
+  --sbindir ${@noprefix('sbindir', d)} \
+  --datadir ${@noprefix('datadir', d)} \
+  --libdir ${@noprefix('libdir', d)} \
+  --libexecdir ${@noprefix('libexecdir', d)} \
+  --includedir ${@noprefix('includedir', d)} \
+  --mandir ${@noprefix('mandir', d)} \
+  --infodir ${@noprefix('infodir', d)} \
+  --sysconfdir ${sysconfdir} \
+  --localstatedir ${localstatedir} \
+  --sharedstatedir ${sharedstatedir}"
+
+MESON_C_ARGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS}"
+MESON_LINK_ARGS = "${MESON_C_ARGS} ${LDFLAGS}"
+
+MESON_HOST_ENDIAN = "${@bb.utils.contains('SITEINFO_ENDIANNESS', 
'be', 'big', 'little', d)}"
+MESON_TARGET_ENDIAN = "${@bb.utils.contains('TUNE_FEATURES', 
'bigendian', 'big', 'little', d)}"

+
+EXTRA_OEMESON += "${PACKAGECONFIG_CONFARGS}"
+
+MESON_CROSS_FILE = ""
+MESON_CROSS_FILE_class-target = "--cross-file ${WORKDIR}/meson.cross"
+
+def meson_array(var, d):
+    return "', '".join(d.getVar(var, True).split()).join(("'", "'"))
+
+addtask write_config before do_configure
+do_write_config[vardeps] += "MESON_C_ARGS TOOLCHAIN_OPTIONS"
+do_write_config() {
+    # This needs to be Py to split the args into single-element lists
+    cat >${WORKDIR}/meson.cross <+    if ! meson ${MESONOPTS} "${MESON_SOURCEPATH}" "${B}" 
${MESON_CROSS_FILE} ${EXTRA_OEMESON}; then

+    cat ${B}/meson-logs/meson-log.txt
+    bbfatal_log meson failed
+    fi
+}
+
+do_compile[progress] = "outof:^\[(\d+)/(\d+)\]\s+"
+meson_do_compile() {
+    ninja ${PARALLEL_MAKE}
+}
+
+meson_do_install() {
+    DESTDIR='${D}' ninja ${PARALLEL_MAKEINST} install
+}
+
+EXPORT_FUNCTIONS do_configure do_compile do_install
diff --git 
a/meta/recipes-devtools/meson/meson/0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch 
b/meta/recipes-devtools/meson/meson/0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch 


new file mode 100644
index 000..ca3d7095066
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch 


@@ -0,0 +1,113 @@
+From 15e054dce6ff11d2cb219c8c09a31b26f0e58b62 Mon Sep 17 00:00:00 2001
+Fro

Re: [OE-core] [PATCH 1/2] systemctl-native: add target.wants to target regex

[Martin Kelly]

Got it, thanks. My patch *should* just convert runtime failures into 
compile-time failures, but it looks like we're seeing actual runtime 
failures, so I'll try to figure out what happened.


On 11/08/2017 12:31 PM, Burton, Ross wrote:

Thanks for reminding me.  :)

1/2 is queued but 2/2 was implicated in a number of systemd-related boot 
failures on the autobuilder 
(https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/553).


I've not yet got around to looking at exactly what sanity test 5 and 7 
do to trigger this.


Ross

On 8 November 2017 at 17:40, Martin Kelly <mailto:mke...@xevo.com>> wrote:


(ping) for this patch series.

On 10/16/2017 09:31 AM, Martin Kelly wrote:

The regex for acceptable systemd WantedBy/RequiredBy targets
does not include
target.wants, so a line like this:

WantedBy=multi-user.target.wants

gets silently ignored, even though it works fine on a real system.

    Signed-off-by: Martin Kelly mailto:mke...@xevo.com>>
---
   meta/recipes-core/systemd/systemd-systemctl/systemctl | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/meta/recipes-core/systemd/systemd-systemctl/systemctl
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index efad14ce17..6e5a1b7181 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -108,7 +108,7 @@ for service in $services; do
         # If any new unit types are added to systemd they
should be added
         # to this regular expression.
- 
  unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|path\|timer\|snapshot\)\s*$'
+ 
  unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|target\.wants\|path\|timer\|snapshot\)\s*$'

         if [ "$action" = "preset" ]; then
                 action=`egrep -sh  $service
$ROOT/etc/systemd/user-preset/*.preset | cut -f1 -d' '`
                 if [ -z "$action" ]; then

-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
<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/2] systemctl-native: add target.wants to target regex

[Martin Kelly]

(ping) for this patch series.

On 10/16/2017 09:31 AM, Martin Kelly wrote:

The regex for acceptable systemd WantedBy/RequiredBy targets does not include
target.wants, so a line like this:

WantedBy=multi-user.target.wants

gets silently ignored, even though it works fine on a real system.

Signed-off-by: Martin Kelly 
---
  meta/recipes-core/systemd/systemd-systemctl/systemctl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl 
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index efad14ce17..6e5a1b7181 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -108,7 +108,7 @@ for service in $services; do
  
  	# If any new unit types are added to systemd they should be added

# to this regular expression.
-   
unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|path\|timer\|snapshot\)\s*$'
+   
unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|target\.wants\|path\|timer\|snapshot\)\s*$'
if [ "$action" = "preset" ]; then
action=`egrep -sh  $service 
$ROOT/etc/systemd/user-preset/*.preset | cut -f1 -d' '`
if [ -z "$action" ]; then


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

[OE-core] [PATCH 1/2] systemctl-native: add target.wants to target regex

[Martin Kelly]

The regex for acceptable systemd WantedBy/RequiredBy targets does not include
target.wants, so a line like this:

WantedBy=multi-user.target.wants

gets silently ignored, even though it works fine on a real system.

Signed-off-by: Martin Kelly 
---
 meta/recipes-core/systemd/systemd-systemctl/systemctl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl 
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index efad14ce17..6e5a1b7181 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -108,7 +108,7 @@ for service in $services; do
 
# If any new unit types are added to systemd they should be added
# to this regular expression.
-   
unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|path\|timer\|snapshot\)\s*$'
+   
unit_types_re='\.\(service\|socket\|device\|mount\|automount\|swap\|target\|target\.wants\|path\|timer\|snapshot\)\s*$'
if [ "$action" = "preset" ]; then
action=`egrep -sh  $service 
$ROOT/etc/systemd/user-preset/*.preset | cut -f1 -d' '`
if [ -z "$action" ]; then
-- 
2.11.0

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

[OE-core] [PATCH 2/2] systemctl-native: explicitly check target validity

[Martin Kelly]

Currently, we parse systemd service files looking for valid WantedBy and
RequiredBy lines. However, invalid lines get silently rejected, causing recipes
to build correctly but then not get enabled in the rootfs.

Add explicit checks for validity and print a message when an invalid target is
found so that the user can fix these issues.

Signed-off-by: Martin Kelly 
---
 .../systemd/systemd-systemctl/systemctl| 37 ++
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl 
b/meta/recipes-core/systemd/systemd-systemctl/systemctl
index 6e5a1b7181..3bed407d9e 100755
--- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
+++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
@@ -1,4 +1,24 @@
 #!/bin/sh
+
+check_target_validity() {
+local line_reg="$1"
+local service_file="$2"
+local unit_types_re="$3"
+
+local line="$(sed $line_reg "$service_file")"
+if [ -z "$line" ]; then
+# Line was not found; there's nothing to check.
+return
+fi
+
+if ! echo $line | grep -q $unit_types_re; then
+echo "One or more of the target types in the service were not 
recognized as valid."
+echo "Service: $service_file"
+echo "Targets: $line"
+exit 1
+fi
+}
+
 echo "Started $0 $*"
 
 ROOT=
@@ -120,15 +140,18 @@ for service in $services; do
fi
fi
fi
-   # create the required symbolic links
-   wanted_by=$(sed '/^WantedBy[[:space:]]*=/s,[^=]*=,,p;d' 
"$ROOT/$service_file" \
-   | tr ',' '\n' \
-   | grep "$unit_types_re")
 
-   required_by=$(sed '/^RequiredBy[[:space:]]*=/s,[^=]*=,,p;d' 
"$ROOT/$service_file" \
-   | tr ',' '\n' \
-   | grep "$unit_types_re")
+check_target_validity \
+'/^WantedBy[[:space:]]*=/s,[^=]*=,,p;d' \
+"$ROOT/$service_file" \
+"$unit_types_re"
 
+check_target_validity \
+'/^RequiredBy[[:space:]]*=/s,[^=]*=,,p;d' \
+"$ROOT/$service_file" \
+"$unit_types_re"
+
+   # create the required symbolic links
for dependency in WantedBy RequiredBy; do
if [ "$dependency" = "WantedBy" ]; then
suffix="wants"
-- 
2.11.0

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

[OE-core] [PATCH] python*native.bbclass: suppress user site dirs

[Martin Kelly]

Currently, $HOME/.local is being added into sys.path for the native
Python, causing subtle host contamination. Suppress this by exporting
PYTHONNOUSERSITE = "1" as documented in PEP 370.

Signed-off-by: Martin Kelly 
---
 meta/classes/python3native.bbclass | 3 +++
 meta/classes/pythonnative.bbclass  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/meta/classes/python3native.bbclass 
b/meta/classes/python3native.bbclass
index ef468b3fde..89665efee8 100644
--- a/meta/classes/python3native.bbclass
+++ b/meta/classes/python3native.bbclass
@@ -9,5 +9,8 @@ DEPENDS_append = " ${PYTHON_PN}-native "
 export STAGING_INCDIR
 export STAGING_LIBDIR
 
+# suppress host user's site-packages dirs.
+export PYTHONNOUSERSITE = "1"
+
 # autoconf macros will use their internal default preference otherwise
 export PYTHON
diff --git a/meta/classes/pythonnative.bbclass 
b/meta/classes/pythonnative.bbclass
index 4e0381b568..4cc8b2769c 100644
--- a/meta/classes/pythonnative.bbclass
+++ b/meta/classes/pythonnative.bbclass
@@ -12,5 +12,8 @@ DEPENDS_append = " ${PYTHON_PN}-native "
 export STAGING_INCDIR
 export STAGING_LIBDIR
 
+# suppress host user's site-packages dirs.
+export PYTHONNOUSERSITE = "1"
+
 # autoconf macros will use their internal default preference otherwise
 export PYTHON
-- 
2.11.0

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

Re: [OE-core] [PATCH] gstreamer1.0-python: add new recipe

[Martin Kelly]

On 07/18/2017 11:37 AM, Khem Raj wrote:

On Tue, Jul 18, 2017 at 12:21 PM, Martin Kelly  wrote:

On 07/17/2017 07:47 PM, Khem Raj wrote:


On Mon, Jul 17, 2017 at 8:21 PM, Martin Kelly  wrote:


Previously, we had a gst-python recipe, but it supported only GStreamer
0.1. After GStreamer switched the Python bindings to use GObject
introspection, we were no longer able to build the bindings, and they
were dropped in this patch:

https://patchwork.openembedded.org/patch/93793/

However, at this point, we have a gobject-introspection class, so we can
use the bindings again, this time with GStreamer 1.0.

Signed-off-by: Martin Kelly 
---
 .../gstreamer/gstreamer1.0-python.inc  | 35
++
 .../gstreamer/gstreamer1.0-python_1.10.4.bb|  7 +
 2 files changed, 42 insertions(+)
 create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
 create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb



I think everything in single file would be better



I'm fine with that, but I was just following the convention that the rest of
the gstreamer packaging uses; all the recipes in
meta/recipes-multimedia/gstreamer use the same convention. I figured it's
cleaner to keep all of it consistent. Would you prefer I diverge anyway?



I dont have strong preference here.



OK, I sent a new version with just the license change.



diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
new file mode 100644
index 00..3299b89daa
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
@@ -0,0 +1,35 @@
+SUMMARY = "Python bindings for GStreamer 1.0"
+HOMEPAGE = "http://cgit.freedesktop.org/gstreamer/gst-python/";
+SECTION = "multimedia"
+LICENSE = "LGPLv2"
+



this should be 2.1 most probably



Yes you're right, I'll change it.



+DEPENDS = "gstreamer1.0 python3-pygobject"
+RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
+
+PNREAL = "gst-python"
+
+SRC_URI =
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
+
+S = "${WORKDIR}/${PNREAL}-${PV}"
+
+inherit autotools pkgconfig distutils3-base upstream-version-is-even
gobject-introspection
+
+do_install_append() {
+# gstpythonplugin hardcodes the location of the libpython from the
build
+# workspace and then fails at runtime. We can override it using
+# --with-libpython-dir=${libdir}, but it still fails because it
looks for a
+# symlinked library ending in .so instead of the actually library
with
+# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use
the path
+# we want, it will break again if the library version ever changes.
We need
+# to think about the best way of handling this and possibly consult
+# upstream.
+#
+# Note that this particular find line is taken from the Debian
packaging for
+# gst-python1.0.
+find "${D}" \
+-name '*.pyc' -o \
+-name '*.pyo' -o \
+-name '*.la' -o \
+-name 'libgstpythonplugin*' \
+-delete
+}
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
new file mode 100644
index 00..1365f7c6dd
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
@@ -0,0 +1,7 @@
+require gstreamer1.0-python.inc
+
+SRC_URI =
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
+SRC_URI[md5sum] = "adcdb74f713e28d0b22a0a1e4f831573"
+SRC_URI[sha256sum] =
"59508174b8bc86c05290aa9a7c5d480ac556a6f36306ddbc1d0eacf4f7868212"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
--
2.11.0

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

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

[OE-core] [PATCH v2] gstreamer1.0-python: add new recipe

[Martin Kelly]

Previously, we had a gst-python recipe, but it supported only GStreamer
0.1. After GStreamer switched the Python bindings to use GObject
introspection, we were no longer able to build the bindings, and they
were dropped in this patch:

https://patchwork.openembedded.org/patch/93793/

However, at this point, we have a gobject-introspection class, so we can
use the bindings again, this time with GStreamer 1.0.

Signed-off-by: Martin Kelly 
---
 .../gstreamer/gstreamer1.0-python.inc  | 35 ++
 .../gstreamer/gstreamer1.0-python_1.10.4.bb|  7 +
 2 files changed, 42 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
new file mode 100644
index 00..961b93017e
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
@@ -0,0 +1,35 @@
+SUMMARY = "Python bindings for GStreamer 1.0"
+HOMEPAGE = "http://cgit.freedesktop.org/gstreamer/gst-python/";
+SECTION = "multimedia"
+LICENSE = "LGPLv2.1"
+
+DEPENDS = "gstreamer1.0 python3-pygobject"
+RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
+
+PNREAL = "gst-python"
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
+
+S = "${WORKDIR}/${PNREAL}-${PV}"
+
+inherit autotools pkgconfig distutils3-base upstream-version-is-even 
gobject-introspection
+
+do_install_append() {
+# gstpythonplugin hardcodes the location of the libpython from the build
+# workspace and then fails at runtime. We can override it using
+# --with-libpython-dir=${libdir}, but it still fails because it looks for a
+# symlinked library ending in .so instead of the actually library with
+# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
+# we want, it will break again if the library version ever changes. We need
+# to think about the best way of handling this and possibly consult
+# upstream.
+#
+# Note that this particular find line is taken from the Debian packaging 
for
+# gst-python1.0.
+find "${D}" \
+-name '*.pyc' -o \
+-name '*.pyo' -o \
+-name '*.la' -o \
+-name 'libgstpythonplugin*' \
+-delete
+}
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
new file mode 100644
index 00..1365f7c6dd
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
@@ -0,0 +1,7 @@
+require gstreamer1.0-python.inc
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
+SRC_URI[md5sum] = "adcdb74f713e28d0b22a0a1e4f831573"
+SRC_URI[sha256sum] = 
"59508174b8bc86c05290aa9a7c5d480ac556a6f36306ddbc1d0eacf4f7868212"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
-- 
2.11.0

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

Re: [OE-core] [PATCH] gstreamer1.0-python: add new recipe

[Martin Kelly]

On 07/17/2017 07:47 PM, Khem Raj wrote:

On Mon, Jul 17, 2017 at 8:21 PM, Martin Kelly  wrote:

Previously, we had a gst-python recipe, but it supported only GStreamer
0.1. After GStreamer switched the Python bindings to use GObject
introspection, we were no longer able to build the bindings, and they
were dropped in this patch:

https://patchwork.openembedded.org/patch/93793/

However, at this point, we have a gobject-introspection class, so we can
use the bindings again, this time with GStreamer 1.0.

Signed-off-by: Martin Kelly 
---
 .../gstreamer/gstreamer1.0-python.inc  | 35 ++
 .../gstreamer/gstreamer1.0-python_1.10.4.bb|  7 +
 2 files changed, 42 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb


I think everything in single file would be better



I'm fine with that, but I was just following the convention that the 
rest of the gstreamer packaging uses; all the recipes in 
meta/recipes-multimedia/gstreamer use the same convention. I figured 
it's cleaner to keep all of it consistent. Would you prefer I diverge 
anyway?




diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
new file mode 100644
index 00..3299b89daa
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
@@ -0,0 +1,35 @@
+SUMMARY = "Python bindings for GStreamer 1.0"
+HOMEPAGE = "http://cgit.freedesktop.org/gstreamer/gst-python/";
+SECTION = "multimedia"
+LICENSE = "LGPLv2"
+


this should be 2.1 most probably



Yes you're right, I'll change it.


+DEPENDS = "gstreamer1.0 python3-pygobject"
+RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
+
+PNREAL = "gst-python"
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
+
+S = "${WORKDIR}/${PNREAL}-${PV}"
+
+inherit autotools pkgconfig distutils3-base upstream-version-is-even 
gobject-introspection
+
+do_install_append() {
+# gstpythonplugin hardcodes the location of the libpython from the build
+# workspace and then fails at runtime. We can override it using
+# --with-libpython-dir=${libdir}, but it still fails because it looks for a
+# symlinked library ending in .so instead of the actually library with
+# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
+# we want, it will break again if the library version ever changes. We need
+# to think about the best way of handling this and possibly consult
+# upstream.
+#
+# Note that this particular find line is taken from the Debian packaging 
for
+# gst-python1.0.
+find "${D}" \
+-name '*.pyc' -o \
+-name '*.pyo' -o \
+-name '*.la' -o \
+-name 'libgstpythonplugin*' \
+-delete
+}
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
new file mode 100644
index 00..1365f7c6dd
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
@@ -0,0 +1,7 @@
+require gstreamer1.0-python.inc
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
+SRC_URI[md5sum] = "adcdb74f713e28d0b22a0a1e4f831573"
+SRC_URI[sha256sum] = 
"59508174b8bc86c05290aa9a7c5d480ac556a6f36306ddbc1d0eacf4f7868212"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
--
2.11.0

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

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

[OE-core] [PATCH] gstreamer1.0-python: add new recipe

[Martin Kelly]

Previously, we had a gst-python recipe, but it supported only GStreamer
0.1. After GStreamer switched the Python bindings to use GObject
introspection, we were no longer able to build the bindings, and they
were dropped in this patch:

https://patchwork.openembedded.org/patch/93793/

However, at this point, we have a gobject-introspection class, so we can
use the bindings again, this time with GStreamer 1.0.

Signed-off-by: Martin Kelly 
---
 .../gstreamer/gstreamer1.0-python.inc  | 35 ++
 .../gstreamer/gstreamer1.0-python_1.10.4.bb|  7 +
 2 files changed, 42 insertions(+)
 create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
new file mode 100644
index 00..3299b89daa
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
@@ -0,0 +1,35 @@
+SUMMARY = "Python bindings for GStreamer 1.0"
+HOMEPAGE = "http://cgit.freedesktop.org/gstreamer/gst-python/";
+SECTION = "multimedia"
+LICENSE = "LGPLv2"
+
+DEPENDS = "gstreamer1.0 python3-pygobject"
+RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
+
+PNREAL = "gst-python"
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
+
+S = "${WORKDIR}/${PNREAL}-${PV}"
+
+inherit autotools pkgconfig distutils3-base upstream-version-is-even 
gobject-introspection
+
+do_install_append() {
+# gstpythonplugin hardcodes the location of the libpython from the build
+# workspace and then fails at runtime. We can override it using
+# --with-libpython-dir=${libdir}, but it still fails because it looks for a
+# symlinked library ending in .so instead of the actually library with
+# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
+# we want, it will break again if the library version ever changes. We need
+# to think about the best way of handling this and possibly consult
+# upstream.
+#
+# Note that this particular find line is taken from the Debian packaging 
for
+# gst-python1.0.
+find "${D}" \
+-name '*.pyc' -o \
+-name '*.pyo' -o \
+-name '*.la' -o \
+-name 'libgstpythonplugin*' \
+-delete
+}
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
new file mode 100644
index 00..1365f7c6dd
--- /dev/null
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.10.4.bb
@@ -0,0 +1,7 @@
+require gstreamer1.0-python.inc
+
+SRC_URI = 
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
+SRC_URI[md5sum] = "adcdb74f713e28d0b22a0a1e4f831573"
+SRC_URI[sha256sum] = 
"59508174b8bc86c05290aa9a7c5d480ac556a6f36306ddbc1d0eacf4f7868212"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
-- 
2.11.0

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

Re: [OE-core] [PATCH] licenses.conf: enable CDDLv1 license

[Martin Kelly]

(ping)

On 07/10/2017 03:18 PM, Martin Kelly wrote:

The CDDL license is now used by open-vm-tools in meta-openembedded, so
we need to add it in order to prevent warnings.

Signed-off-by: Martin Kelly 
---
 meta/conf/licenses.conf | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index d210a0e940..3e2d2589ab 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -105,6 +105,10 @@ SPDXLICENSEMAP[AFL-1] = "AFL-1.2"
 SPDXLICENSEMAP[AFLv2] = "AFL-2.0"
 SPDXLICENSEMAP[AFLv1] = "AFL-1.2"

+#CDDL variations
+SPDXLICENSEMAP[CDDLv1] = "CDDL-1.0"
+SPDXLICENSEMAP[CDDL-1] = "CDDL-1.0"
+
 #Other variations
 SPDXLICENSEMAP[EPLv1.0] = "EPL-1.0"



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

Re: [OE-core] [morty][PATCH 1/1] openssl-native: Compile with -fPIC

[Martin Kelly]

Hi Armin,

Could we backport this patch to morty?

On 07/11/2017 12:39 PM, Khem Raj wrote:

On Tue, Jul 11, 2017 at 12:07 PM, Martin Kelly  wrote:

Hi,

Is there any issue with backporting this to morty? It would help me fix a
build crash I'm seeing on morty, and I'm currently using the backport in a
separate repo with no issue.



there should be no issues. Let Armin know of your request.



On 06/28/2017 11:06 AM, Martin Kelly wrote:


On 05/26/2017 12:03 AM, Mirza Krak wrote:


From: Khem Raj 

Fixes
| /usr/bin/ld: libcrypto.a(sha1-x86_64.o): relocation R_X86_64_PC32
against undefined symbol `OPENSSL_ia32cap_P' can not be used when
making a shared object; recompile with -fPIC
| /usr/bin/ld: final link failed: Bad value

Signed-off-by: Khem Raj 
(cherry picked from commit 0a19e72081771fca8ed94fb2a2a8996fd3dce00c)
Signed-off-by: Mirza Krak 
---

I hit the same compiler error as in above commit message when running
on morty branch.

I simply cherry-picked that fix in to morty branch. I looked in the
git log of oe-core and it seems to me that it shall be ok to do that?

This is a re-send since I messed up Subject the first time around [1]



I want to put in my $0.02 that I have hit the same issue and would also
like the fix to be cherry-picked into morty. I tested and agree that it
seems to work with no issue.


[1].

http://lists.openembedded.org/pipermail/openembedded-core/2017-May/136489.html


 meta/recipes-connectivity/openssl/openssl_1.0.2j.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
b/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
index 9a7cdedd05..b6fb126349 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
@@ -5,6 +5,7 @@ require openssl.inc
 DEPENDS += "cryptodev-linux"

 CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS"
+CFLAG_append_class-native = " -fPIC"

 LIC_FILES_CHKSUM = "file://LICENSE;md5=27ffa5d74bb5a337056c14b2ef93fbf6"

--
2.13.0


--
___
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] [morty][PATCH 1/1] openssl-native: Compile with -fPIC

[Martin Kelly]

Hi,

Is there any issue with backporting this to morty? It would help me fix 
a build crash I'm seeing on morty, and I'm currently using the backport 
in a separate repo with no issue.


On 06/28/2017 11:06 AM, Martin Kelly wrote:

On 05/26/2017 12:03 AM, Mirza Krak wrote:

From: Khem Raj 

Fixes
| /usr/bin/ld: libcrypto.a(sha1-x86_64.o): relocation R_X86_64_PC32
against undefined symbol `OPENSSL_ia32cap_P' can not be used when
making a shared object; recompile with -fPIC
| /usr/bin/ld: final link failed: Bad value

Signed-off-by: Khem Raj 
(cherry picked from commit 0a19e72081771fca8ed94fb2a2a8996fd3dce00c)
Signed-off-by: Mirza Krak 
---

I hit the same compiler error as in above commit message when running
on morty branch.

I simply cherry-picked that fix in to morty branch. I looked in the
git log of oe-core and it seems to me that it shall be ok to do that?

This is a re-send since I messed up Subject the first time around [1]



I want to put in my $0.02 that I have hit the same issue and would also
like the fix to be cherry-picked into morty. I tested and agree that it
seems to work with no issue.


[1].
http://lists.openembedded.org/pipermail/openembedded-core/2017-May/136489.html


 meta/recipes-connectivity/openssl/openssl_1.0.2j.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
b/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
index 9a7cdedd05..b6fb126349 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
@@ -5,6 +5,7 @@ require openssl.inc
 DEPENDS += "cryptodev-linux"

 CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS"
+CFLAG_append_class-native = " -fPIC"

 LIC_FILES_CHKSUM = "file://LICENSE;md5=27ffa5d74bb5a337056c14b2ef93fbf6"

--
2.13.0


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

[OE-core] [PATCH] licenses.conf: enable CDDLv1 license

[Martin Kelly]

The CDDL license is now used by open-vm-tools in meta-openembedded, so
we need to add it in order to prevent warnings.

Signed-off-by: Martin Kelly 
---
 meta/conf/licenses.conf | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index d210a0e940..3e2d2589ab 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -105,6 +105,10 @@ SPDXLICENSEMAP[AFL-1] = "AFL-1.2"
 SPDXLICENSEMAP[AFLv2] = "AFL-2.0"
 SPDXLICENSEMAP[AFLv1] = "AFL-1.2"
 
+#CDDL variations
+SPDXLICENSEMAP[CDDLv1] = "CDDL-1.0"
+SPDXLICENSEMAP[CDDL-1] = "CDDL-1.0"
+
 #Other variations
 SPDXLICENSEMAP[EPLv1.0] = "EPL-1.0"
 
-- 
2.11.0

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

Re: [OE-core] [morty][PATCH 1/1] openssl-native: Compile with -fPIC

[Martin Kelly]

On 05/26/2017 12:03 AM, Mirza Krak wrote:

From: Khem Raj 

Fixes
| /usr/bin/ld: libcrypto.a(sha1-x86_64.o): relocation R_X86_64_PC32 against 
undefined symbol `OPENSSL_ia32cap_P' can not be used when making a shared 
object; recompile with -fPIC
| /usr/bin/ld: final link failed: Bad value

Signed-off-by: Khem Raj 
(cherry picked from commit 0a19e72081771fca8ed94fb2a2a8996fd3dce00c)
Signed-off-by: Mirza Krak 
---

I hit the same compiler error as in above commit message when running on morty 
branch.

I simply cherry-picked that fix in to morty branch. I looked in the git log of 
oe-core and it seems to me that it shall be ok to do that?

This is a re-send since I messed up Subject the first time around [1]



I want to put in my $0.02 that I have hit the same issue and would also 
like the fix to be cherry-picked into morty. I tested and agree that it 
seems to work with no issue.



[1]. 
http://lists.openembedded.org/pipermail/openembedded-core/2017-May/136489.html

 meta/recipes-connectivity/openssl/openssl_1.0.2j.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb 
b/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
index 9a7cdedd05..b6fb126349 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.2j.bb
@@ -5,6 +5,7 @@ require openssl.inc
 DEPENDS += "cryptodev-linux"

 CFLAG += "-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS"
+CFLAG_append_class-native = " -fPIC"

 LIC_FILES_CHKSUM = "file://LICENSE;md5=27ffa5d74bb5a337056c14b2ef93fbf6"

--
2.13.0


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

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

On 06/15/2017 04:45 AM, Burton, Ross wrote:


On 2 May 2017 at 20:20, Martin Kelly mailto:mke...@xevo.com>> wrote:

-QB_CPU_KVM_x86-64 = "-cpu kvm64"
+QB_CPU_KVM_x86-64 = "-cpu core2duo"


What's the actual meaning of the "kvm64" and "kvm32" CPUs?  Is there a
performance hit?  Should we be instead changing the qemu machine to
target a different instruction set?



I am no expert, but running qemu -cpu help just says:

kvm32 - "Common 32-bit KVM processor"
kvm64 - "Common 64-bit KVM processor"

My best guess is that, running on qemu without kvm, both cases will be 
slow (since it's all software emulation). But, using qemu -kvm, it 
should be fast as long as you run on a native CPU that is core2duo or 
better, as the native instructions can just be exposed and passed 
through to the host. Since core2duo is very old by now, it should be 
fast for virtually everyone building on x86.


Regardless, the core issue here is not performance but merely making 
sure that binaries run without crashing in the emulated environment. We 
need to upgrade the emulation to match the binaries or downgrade the 
binaries to match the emulation (aka building against something even 
more ancient than core2duo). Further downgrading the CPU seems wrong to 
me because core2duo is already quite old.

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

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

On 05/22/2017 11:09 AM, Martin Kelly wrote:

On 05/22/2017 10:53 AM, Randy Witt wrote:

On 05/22/2017 10:29 AM, Martin Kelly wrote:

(friendly ping)

On 05/02/2017 12:20 PM, Martin Kelly wrote:

Currently, the qemu CPUs for are specified as generic, but the built
artifacts are not. For example, we build x86-64 artifacts targeting
core2duo but run them in qemu with generic qemu/kvm CPUs. This causes
some packages that take advantage of the host architecture to crash
because they try to use CPU features not advertised by qemu. As an
example, Qt uses ssse3. When artifacts linked against Qt and built
targeting core2duo attempt to run on a generic qemu/kvm CPU, we get
the following crash:

Incompatible processor. This Qt build requires the following features:
 ssse3

We could fix this by making packages like Qt not take advantage of CPU
features. However, we will probably keep facing similar issues over
time, so it's better to resolve them in a more enduring way.


If the MACHINE is a generic qemu, it seems more correct to build without
the extensions. For instance, what happens when core2duo doesn't have
all the necessary instructions that some package decided to use?

I like the idea of being able to exercise the code, but I only see this
fix as pushing the maintenance until the problem appears again later.



Currently, I believe we're passing in all the right flags (e.g. -march)
to specify a core2duo build, so GCC should not issue any instructions
that a core2duo wouldn't support. By passing in these flags, we're
allowing recipes to issue core2duo instructions and then creating a
runtime environment that doesn't support those same instructions (bug).

I don't think we're deferring any maintenance; unless we change the
-march and similar flags to be something other than core2duo, I think
the problems should go away. If we make that change, we should update
the qemu CPUs at the same time.

We can solve the problem in one of two ways:

- Make qemu run as core2duo
- Make recipes build as something even more basic

The second change is much more involved than the first. I don't which
-march (and similar) flags are the closest match to the generic qemu
32/qemu64 CPUs. However, I suspect there may not be a perfect match.
And, core2duo is already quite old and basic by today's standards
anyway, so I think bringing the qemu CPUs up to match is the simplest
and best way to fix the issue.



(ping)



Fix this by making the qemu -cpu arguments match the built artifacts.

Signed-off-by: Martin Kelly 
---

I sent this to p...@yoctoproject.org but it should have gone to
OE-core,
so I'm resending it now to restart the discussion on the right mailing
list. There were some comments about it in a previous mail thread on
the
poky mailing list:

https://lists.yoctoproject.org/pipermail/poky/2017-April/010956.html

 meta/conf/machine/include/qemuboot-x86.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-x86.inc
b/meta/conf/machine/include/qemuboot-x86.inc
index 06ac983..acd03a1 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -1,12 +1,12 @@
 # For runqemu
 IMAGE_CLASSES += "qemuboot"
 QB_SYSTEM_NAME_x86 = "qemu-system-i386"
-QB_CPU_x86 = "-cpu qemu32"
-QB_CPU_KVM_x86 = "-cpu kvm32"
+QB_CPU_x86 = "-cpu pentium2"
+QB_CPU_KVM_x86 = "-cpu pentium2"

 QB_SYSTEM_NAME_x86-64 = "qemu-system-x86_64"
 QB_CPU_x86-64 = "-cpu core2duo"
-QB_CPU_KVM_x86-64 = "-cpu kvm64"
+QB_CPU_KVM_x86-64 = "-cpu core2duo"

 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"




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

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Martin Kelly]

On 06/13/2017 09:52 AM, Burton, Ross wrote:


On 13 June 2017 at 17:46, Martin Kelly mailto:mke...@xevo.com>> wrote:

Ah, I was checking meta-openembedded by mistake. Thanks.


The Best Known Method is to have a oe-core clone that you use for
pushing stuff upstream, and then you can just rebase to see what has
been merged or what hasn't yet merged and needs rebasing.



Yep, I normally do that, but I have a few patches in flight between 
OE-core and meta-oe and I had forgotten which went where :).

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

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Martin Kelly]

On 06/13/2017 09:38 AM, Burton, Ross wrote:


On 13 June 2017 at 17:35, Martin Kelly mailto:mke...@xevo.com>> wrote:

Alright, makes sense. Do the patches look OK to you?


Yes, they're both in master now.



Ah, I was checking meta-openembedded by mistake. Thanks.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Martin Kelly]

On 06/07/2017 12:09 PM, Burton, Ross wrote:


On 7 June 2017 at 17:33, Martin Kelly mailto:mke...@xevo.com>> wrote:

Which patch are you referring to? I used git send-email for the
systemd patch, and it applies just fine for me on OE-core master
(using patch -p1).


Sorry, forgot to trim recipients.  Yes, it was Jan's patch.



Alright, makes sense. Do the patches look OK to you?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Martin Kelly]

On 06/07/2017 09:08 AM, Burton, Ross wrote:


On 6 June 2017 at 18:28, Martin Kelly mailto:mke...@xevo.com>> wrote:

I sent a separate patch for fixing the systemd issue, so I think we
can merge the two patches separately (they're both needed):

https://patchwork.openembedded.org/patch/140355/
<https://patchwork.openembedded.org/patch/140355/>

Neither of our patches have been merged yet.


Sorry, somehow slipped through the net.

This patch doesn't apply as it's been corrupted by the mailer.  Please
use git-send-email instead of copy/pasting (I've managed to apply it
manually as it's a simple patch this time).

Ross



Which patch are you referring to? I used git send-email for the systemd 
patch, and it applies just fine for me on OE-core master (using patch -p1).

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

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Martin Kelly]

On 06/06/2017 03:11 AM, Jan Kiszka wrote:

On 2017-06-01 02:17, Martin Kelly wrote:

On 05/02/2017 01:41 AM, Martin Kelly wrote:

On 04/30/2017 08:28 AM, Jan Kiszka wrote:

From: Jan Kiszka 

The upstream init script uses SIGUSR2 to terminate that daemon because
SIGTERM is ignored. As the killproc function does not support specifying
a signal, switch to start-stop-daemon. Drop the retry loop because
SIGUSR2 is lethal for agent.

Signed-off-by: Jan Kiszka 


Thanks! I noticed this bug and was planning to look into it, but it
looks like you found the issue first! This was bringing shutdowns to a
crawl for me.


I just noticed, I think we need to fix the same bug in the systemd
service script too.


Does this block this patch, or should this be done in a separate one? I
noticed that it's still not merged.



I sent a separate patch for fixing the systemd issue, so I think we can 
merge the two patches separately (they're both needed):


https://patchwork.openembedded.org/patch/140355/

Neither of our patches have been merged yet.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Martin Kelly]

On 06/01/2017 09:17 AM, Martin Kelly wrote:

On 05/02/2017 01:41 AM, Martin Kelly wrote:

On 04/30/2017 08:28 AM, Jan Kiszka wrote:

From: Jan Kiszka 

The upstream init script uses SIGUSR2 to terminate that daemon because
SIGTERM is ignored. As the killproc function does not support specifying
a signal, switch to start-stop-daemon. Drop the retry loop because
SIGUSR2 is lethal for agent.

Signed-off-by: Jan Kiszka 


Thanks! I noticed this bug and was planning to look into it, but it
looks like you found the issue first! This was bringing shutdowns to a
crawl for me.


I just noticed, I think we need to fix the same bug in the systemd
service script too.


OK, I sent a patch to fix the same issue in the systemd service script.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tcf-agent: kill with USR2 in systemd stop

[Martin Kelly]

tcf-agent ignores SIGTERM, so upstream uses USR2 instead. This issue was noticed
by Jan Kiszka and Brian Avery around the same time:

https://patchwork.openembedded.org/patch/139546/
https://patchwork.openembedded.org/patch/139560/

However, these patches fixed only the init scripts, not the systemd service
file. This patch fixes the systemd file.

Signed-off-by: Martin Kelly 
---
 meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service 
b/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service
index fd9a6c4..a486ac7 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.service
@@ -5,6 +5,8 @@ After=network.target
 [Service]
 Type=forking
 ExecStart=@SBINDIR@/tcf-agent -d -L- -l0
+KillSignal=USR2
+SuccessExitStatus=USR2
 
 [Install]
 WantedBy=multi-user.target
-- 
2.1.4

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

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Martin Kelly]

On 05/02/2017 01:41 AM, Martin Kelly wrote:

On 04/30/2017 08:28 AM, Jan Kiszka wrote:

From: Jan Kiszka 

The upstream init script uses SIGUSR2 to terminate that daemon because
SIGTERM is ignored. As the killproc function does not support specifying
a signal, switch to start-stop-daemon. Drop the retry loop because
SIGUSR2 is lethal for agent.

Signed-off-by: Jan Kiszka 


Thanks! I noticed this bug and was planning to look into it, but it
looks like you found the issue first! This was bringing shutdowns to a
crawl for me.


I just noticed, I think we need to fix the same bug in the systemd 
service script too.

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

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

On 05/22/2017 10:53 AM, Randy Witt wrote:

On 05/22/2017 10:29 AM, Martin Kelly wrote:

(friendly ping)

On 05/02/2017 12:20 PM, Martin Kelly wrote:

Currently, the qemu CPUs for are specified as generic, but the built
artifacts are not. For example, we build x86-64 artifacts targeting
core2duo but run them in qemu with generic qemu/kvm CPUs. This causes
some packages that take advantage of the host architecture to crash
because they try to use CPU features not advertised by qemu. As an
example, Qt uses ssse3. When artifacts linked against Qt and built
targeting core2duo attempt to run on a generic qemu/kvm CPU, we get
the following crash:

Incompatible processor. This Qt build requires the following features:
 ssse3

We could fix this by making packages like Qt not take advantage of CPU
features. However, we will probably keep facing similar issues over
time, so it's better to resolve them in a more enduring way.


If the MACHINE is a generic qemu, it seems more correct to build without
the extensions. For instance, what happens when core2duo doesn't have
all the necessary instructions that some package decided to use?

I like the idea of being able to exercise the code, but I only see this
fix as pushing the maintenance until the problem appears again later.



Currently, I believe we're passing in all the right flags (e.g. -march) 
to specify a core2duo build, so GCC should not issue any instructions 
that a core2duo wouldn't support. By passing in these flags, we're 
allowing recipes to issue core2duo instructions and then creating a 
runtime environment that doesn't support those same instructions (bug).


I don't think we're deferring any maintenance; unless we change the 
-march and similar flags to be something other than core2duo, I think 
the problems should go away. If we make that change, we should update 
the qemu CPUs at the same time.


We can solve the problem in one of two ways:

- Make qemu run as core2duo
- Make recipes build as something even more basic

The second change is much more involved than the first. I don't which 
-march (and similar) flags are the closest match to the generic qemu 
32/qemu64 CPUs. However, I suspect there may not be a perfect match. 
And, core2duo is already quite old and basic by today's standards 
anyway, so I think bringing the qemu CPUs up to match is the simplest 
and best way to fix the issue.




Fix this by making the qemu -cpu arguments match the built artifacts.

Signed-off-by: Martin Kelly 
---

I sent this to p...@yoctoproject.org but it should have gone to OE-core,
so I'm resending it now to restart the discussion on the right mailing
list. There were some comments about it in a previous mail thread on the
poky mailing list:

https://lists.yoctoproject.org/pipermail/poky/2017-April/010956.html

 meta/conf/machine/include/qemuboot-x86.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-x86.inc
b/meta/conf/machine/include/qemuboot-x86.inc
index 06ac983..acd03a1 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -1,12 +1,12 @@
 # For runqemu
 IMAGE_CLASSES += "qemuboot"
 QB_SYSTEM_NAME_x86 = "qemu-system-i386"
-QB_CPU_x86 = "-cpu qemu32"
-QB_CPU_KVM_x86 = "-cpu kvm32"
+QB_CPU_x86 = "-cpu pentium2"
+QB_CPU_KVM_x86 = "-cpu pentium2"

 QB_SYSTEM_NAME_x86-64 = "qemu-system-x86_64"
 QB_CPU_x86-64 = "-cpu core2duo"
-QB_CPU_KVM_x86-64 = "-cpu kvm64"
+QB_CPU_KVM_x86-64 = "-cpu core2duo"

 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"




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

Re: [OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

(friendly ping)

On 05/02/2017 12:20 PM, Martin Kelly wrote:

Currently, the qemu CPUs for are specified as generic, but the built
artifacts are not. For example, we build x86-64 artifacts targeting
core2duo but run them in qemu with generic qemu/kvm CPUs. This causes
some packages that take advantage of the host architecture to crash
because they try to use CPU features not advertised by qemu. As an
example, Qt uses ssse3. When artifacts linked against Qt and built
targeting core2duo attempt to run on a generic qemu/kvm CPU, we get
the following crash:

Incompatible processor. This Qt build requires the following features:
 ssse3

We could fix this by making packages like Qt not take advantage of CPU
features. However, we will probably keep facing similar issues over
time, so it's better to resolve them in a more enduring way.

Fix this by making the qemu -cpu arguments match the built artifacts.

Signed-off-by: Martin Kelly 
---

I sent this to p...@yoctoproject.org but it should have gone to OE-core,
so I'm resending it now to restart the discussion on the right mailing
list. There were some comments about it in a previous mail thread on the
poky mailing list:

https://lists.yoctoproject.org/pipermail/poky/2017-April/010956.html

 meta/conf/machine/include/qemuboot-x86.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-x86.inc 
b/meta/conf/machine/include/qemuboot-x86.inc
index 06ac983..acd03a1 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -1,12 +1,12 @@
 # For runqemu
 IMAGE_CLASSES += "qemuboot"
 QB_SYSTEM_NAME_x86 = "qemu-system-i386"
-QB_CPU_x86 = "-cpu qemu32"
-QB_CPU_KVM_x86 = "-cpu kvm32"
+QB_CPU_x86 = "-cpu pentium2"
+QB_CPU_KVM_x86 = "-cpu pentium2"

 QB_SYSTEM_NAME_x86-64 = "qemu-system-x86_64"
 QB_CPU_x86-64 = "-cpu core2duo"
-QB_CPU_KVM_x86-64 = "-cpu kvm64"
+QB_CPU_KVM_x86-64 = "-cpu core2duo"

 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"


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

[OE-core] [PATCH] scripts/runqemu.README: fix typo

[Martin Kelly]

Signed-off-by: Martin Kelly 
---
 scripts/runqemu.README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/runqemu.README b/scripts/runqemu.README
index 5908d83..da9abd7 100644
--- a/scripts/runqemu.README
+++ b/scripts/runqemu.README
@@ -35,7 +35,7 @@ Notes
run as non root. The runqemu-gen-tapdevs script can also be used by
root to prepopulate the appropriate network devices.
  - You can access the host computer at 192.168.7.1 within the image.
- - Your qemu system will be accessible as 192.16.7.2.
+ - Your qemu system will be accessible as 192.168.7.2.
  - The script extracts the root filesystem specified under pseudo and sets up 
a userspace
NFS server to share the image over by default meaning the filesystem can be 
accessed by
both the host and guest systems.
-- 
2.1.4

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

[OE-core] [PATCH resend] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

Currently, the qemu CPUs for are specified as generic, but the built
artifacts are not. For example, we build x86-64 artifacts targeting
core2duo but run them in qemu with generic qemu/kvm CPUs. This causes
some packages that take advantage of the host architecture to crash
because they try to use CPU features not advertised by qemu. As an
example, Qt uses ssse3. When artifacts linked against Qt and built
targeting core2duo attempt to run on a generic qemu/kvm CPU, we get
the following crash:

Incompatible processor. This Qt build requires the following features:
 ssse3

We could fix this by making packages like Qt not take advantage of CPU
features. However, we will probably keep facing similar issues over
time, so it's better to resolve them in a more enduring way.

Fix this by making the qemu -cpu arguments match the built artifacts.

Signed-off-by: Martin Kelly 
---

I sent this to p...@yoctoproject.org but it should have gone to OE-core,
so I'm resending it now to restart the discussion on the right mailing
list. There were some comments about it in a previous mail thread on the
poky mailing list:

https://lists.yoctoproject.org/pipermail/poky/2017-April/010956.html

 meta/conf/machine/include/qemuboot-x86.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-x86.inc 
b/meta/conf/machine/include/qemuboot-x86.inc
index 06ac983..acd03a1 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -1,12 +1,12 @@
 # For runqemu
 IMAGE_CLASSES += "qemuboot"
 QB_SYSTEM_NAME_x86 = "qemu-system-i386"
-QB_CPU_x86 = "-cpu qemu32"
-QB_CPU_KVM_x86 = "-cpu kvm32"
+QB_CPU_x86 = "-cpu pentium2"
+QB_CPU_KVM_x86 = "-cpu pentium2"
 
 QB_SYSTEM_NAME_x86-64 = "qemu-system-x86_64"
 QB_CPU_x86-64 = "-cpu core2duo"
-QB_CPU_KVM_x86-64 = "-cpu kvm64"
+QB_CPU_KVM_x86-64 = "-cpu core2duo"
 
 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"
-- 
2.7.4

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

Re: [OE-core] [PATCH 1/1] tcf-agent: add -USR2 to stop/kill initscript

[Martin Kelly]

Looks like this is addressing the same problem as Jan's patch from 
earlier today. I think the differences are:


- kill vs start-stop-daemon

- Jan removed the retry loop while this patch does not

On 05/01/2017 02:59 PM, brian avery wrote:

The current initscript was lacking a -USR2 signal in the stop section.
This resulted in /etc/init.d/tcf-agent stop; taking roughly 10 seconds
then failing to kill the tcf-agent process. This patch brings us in line
with how upstream stops the agent.

Fixes [YOCTO #10858]

Signed-off-by: brian avery 
---
 meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init 
b/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init
index 6303280..13497cc 100755
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/tcf-agent.init
@@ -35,7 +35,7 @@ case "$1" in
 echo -n "Stopping $DAEMON_NAME: "
 count=0
 while [ -n "`/bin/pidof $DAEMON_PATH`" -a $count -lt 10 ] ; do
-killproc $DAEMON_PATH >& /dev/null
+kill -USR2 `pidofproc $DAEMON_PATH`  >& /dev/null
 sleep 1
 RETVAL=$?
 if [ $RETVAL != 0 -o -n "`/bin/pidof $DAEMON_PATH`" ] ; then
@@ -72,4 +72,3 @@ case "$1" in
 esac

 exit $RETVAL
-


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

Re: [OE-core] [PATCH] tcf-agent: Fix daemon termination

[Martin Kelly]

On 04/30/2017 08:28 AM, Jan Kiszka wrote:

From: Jan Kiszka 

The upstream init script uses SIGUSR2 to terminate that daemon because
SIGTERM is ignored. As the killproc function does not support specifying
a signal, switch to start-stop-daemon. Drop the retry loop because
SIGUSR2 is lethal for agent.

Signed-off-by: Jan Kiszka 


Thanks! I noticed this bug and was planning to look into it, but it 
looks like you found the issue first! This was bringing shutdowns to a 
crawl for me.

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

Re: [OE-core] [PATCH] qemuboot.conf: make cpus match built artifacts

[Martin Kelly]

On 04/24/2017 09:50 AM, Aníbal Limón wrote:

Hi Martin,

It looks that we need to improve the alignment between compiler flags
and runqemu configurations. I don't know if is the right way to change
the cpu's to pentium and core2due may be could cause side-effects.

I think will be better to review the qemuboot profiles and to provide a
mechanism to modify it.


If we go this route, it seems like we should make it modifiable by 
distro layers. Currently, the qemuboot.conf settings live in OE-core, so 
I did not find a way to override the settings in a distro file. When I 
tried manually changing them, the setting did not take effect because 
the setting in OE-core got parsed last.


That said, I think it would be more ideal to make sure the settings work 
by default everywhere, without each layer having to tweak anything. As 
long as the compiled and runtime features match, I think we can achieve 
this goal.




I want to know, what was your build settings?


To test the patch, I did:

git clone git://git.yoctoproject.org/poky
source oe-init-build-env
# manually edit MACHINE to be qemux86 or qemux86-64
bitbake core-image-minimal

I hit the initial bug when building AGL (Automotive Grade Linux), which 
pulls in meta-qt5, which surfaced the issue.




Finally this patch needs to be send to oe-core mailing list.



Sorry, adding oe-core now.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core