[OE-core] [PATCH 4/5] scripts/wic: explicitly set BUILDDIR within eSDK

2018-01-10 Thread rebecca . swee . fun . chang
From: Chang Rebecca Swee Fun 

When we run wic within eSDK:
$ wic create mkefidisk -e core-image-minimal

ERROR: BUILDDIR not found, exiting. (Did you forget to source 
oe-init-build-env?)

In order to figure out variable values, one must have sourced
the OE build environment setup script. However, when we are in
within the eSDK environment which isn't initialised like the
normal OE build environment, we can't use wic utility with eSDK.

Reference:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#wic-requirements

While wic ought to be fixed to be able to run without bitbake
& native tools [YOCTO #11281], but this is a workaround to set
BUILDDIR in the environment so that bitbake environment is setup
for wic to build its required native tools.

Signed-off-by: Chang Rebecca Swee Fun 
---
 scripts/wic | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/wic b/scripts/wic
index d9bea22..b02d907 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -55,6 +55,8 @@ if os.environ.get('SDKTARGETSYSROOT'):
 # If found, initialize bitbake path for eSDK environment and 
append to PATH
 sdkroot = os.path.join(os.path.dirname(scripts_path), 'bitbake', 
'bin')
 os.environ['PATH'] += ":" + sdkroot
+# Set BUILDDIR for wic to work within eSDK
+os.environ['BUILDDIR'] = sdkroot
 break
 sdkroot = os.path.dirname(sdkroot)
 
-- 
2.7.4

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


[OE-core] [PATCH 2/5] scripts/wic: append bitbake executable file path in eSDK environment

2018-01-10 Thread rebecca . swee . fun . chang
From: Chang Rebecca Swee Fun 

wic needs a set of tools to be available from sysroots.
wic will find bitbake executable within the environment,
and wic was unable to locate bitbake executable within eSDK
because it wasn't setup with the OE build environment script.
Hence, we need to add bitbake file path into the environment
PATH for wic to be able to discover it and import bb modules.

Signed-off-by: Chang Rebecca Swee Fun 
---
 scripts/wic | 12 
 1 file changed, 12 insertions(+)

diff --git a/scripts/wic b/scripts/wic
index 0d98875..293a216 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -46,6 +46,18 @@ sys.path.insert(0, lib_path)
 import scriptpath
 scriptpath.add_oe_lib_path()
 
+# Check whether wic is running within eSDK environment
+sdkroot = scripts_path
+if os.environ.get('SDKTARGETSYSROOT'):
+while sdkroot != '' and sdkroot != os.sep:
+if os.path.exists(os.path.join(sdkroot, '.devtoolbase')):
+# .devtoolbase only exists within eSDK
+# If found, initialize bitbake path for eSDK environment and 
append to PATH
+sdkroot = os.path.join(os.path.dirname(scripts_path), 'bitbake', 
'bin')
+os.environ['PATH'] += ":" + sdkroot
+break
+sdkroot = os.path.dirname(sdkroot)
+
 bitbake_exe = spawn.find_executable('bitbake')
 if bitbake_exe:
 bitbake_path = scriptpath.add_bitbake_lib_path()
-- 
2.7.4

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


[OE-core] [PATCH 3/5] scripts/wic: fix error of import wic module in eSDK environment

2018-01-10 Thread rebecca . swee . fun . chang
From: Chang Rebecca Swee Fun 

wic modules in scripts/lib/ are needed for wic to work, but path to
the python module is not exported in eSDK environment and we were
using an absolutized path of wic script within the sysroots.

We now changed to use real script path instead, where the wic modules
are located. This will also resolved the tracebacks found when running
wic from within the eSDK environment.

Traceback (most recent call last):
  File "/tmp/deploy/sdk/poky_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/wic", 
line 58, in 
from wic import WicError
ImportError: No module named 'wic'

Signed-off-by: Chang Rebecca Swee Fun 
---
 scripts/wic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/wic b/scripts/wic
index 293a216..d9bea22 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -40,7 +40,7 @@ from collections import namedtuple
 from distutils import spawn
 
 # External modules
-scripts_path = os.path.abspath(os.path.dirname(__file__))
+scripts_path = os.path.dirname(os.path.realpath(__file__))
 lib_path = scripts_path + '/lib'
 sys.path.insert(0, lib_path)
 import scriptpath
-- 
2.7.4

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


[OE-core] [PATCH 5/5] classes/populate_sdk_ext: support wic in eSDK

2018-01-10 Thread rebecca . swee . fun . chang
From: Chang Rebecca Swee Fun 

Make 'wic' image creation tool/command available in eSDK
environment. This would allow eSDK users to manipulate
images within eSDK environment.

[YOCTO #12177]

Signed-off-by: Chang Rebecca Swee Fun 
---
 meta/classes/populate_sdk_ext.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index eabc365..4f7100d 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -533,7 +533,7 @@ def get_sdk_required_utilities(buildtools_fn, d):
 
 install_tools() {
install -d ${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}
-   scripts="devtool recipetool oe-find-native-sysroot runqemu*"
+   scripts="devtool recipetool oe-find-native-sysroot runqemu* wic"
for script in $scripts; do
for scriptfn in `find ${SDK_OUTPUT}/${SDKPATH}/${scriptrelpath} 
-maxdepth 1 -executable -name "$script"`; do
lnr ${scriptfn} 
${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/`basename $scriptfn`
-- 
2.7.4

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


[OE-core] [PATCH 1/5] scripts/wic: use scriptpath module to find bitbake path and oe lib path

2018-01-10 Thread rebecca . swee . fun . chang
From: Chang Rebecca Swee Fun 

Use the scriptpath module in order to standardize the adding of
bitbake and meta/lib path to sys.path.

Signed-off-by: Chang Rebecca Swee Fun 
---
 scripts/wic | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/scripts/wic b/scripts/wic
index 097084a..0d98875 100755
--- a/scripts/wic
+++ b/scripts/wic
@@ -43,13 +43,12 @@ from distutils import spawn
 scripts_path = os.path.abspath(os.path.dirname(__file__))
 lib_path = scripts_path + '/lib'
 sys.path.insert(0, lib_path)
-oe_lib_path = os.path.join(os.path.dirname(scripts_path), 'meta', 'lib')
-sys.path.insert(0, oe_lib_path)
+import scriptpath
+scriptpath.add_oe_lib_path()
 
 bitbake_exe = spawn.find_executable('bitbake')
 if bitbake_exe:
-bitbake_path = os.path.join(os.path.dirname(bitbake_exe), '../lib')
-sys.path.insert(0, bitbake_path)
+bitbake_path = scriptpath.add_bitbake_lib_path()
 from bb import cookerdata
 from bb.main import bitbake_main, BitBakeConfigParameters
 else:
-- 
2.7.4

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


[OE-core] [PATCH 0/5] Enable wic in eSDK

2018-01-10 Thread rebecca . swee . fun . chang
From: Chang Rebecca Swee Fun 

Hi all,

As the subject called out: this patch series enable wic in eSDK.
The details of what I have done are documented within the commit message.
Basically wic requires an OE build environment, but we are using a
different environment setup script in eSDK. Hence, I have added some
code for wic to explicitly export bitbake variables within eSDK. I
have also make wic to use the shared code in scriptpath for oe lib
and bitbake path addition to sys.path.

I have run the changes on wic oe-selftest and the tests are passing.
What's next: I think it would better to have some test cases
for wic within eSDK if this series are merged.

Thanks.

Regards,
Rebecca


The following changes since commit 205cfd702190026e64eed9cae27c05ff62d1637e:

  bitbake: fetch2/__init__: Disable pseudo in runfetchcmd() (2018-01-08 
08:48:54 +)

are available in the git repository at:

  git://push.yoctoproject.org/poky-contrib rebeccas/wic-dev

Chang Rebecca Swee Fun (5):
  scripts/wic: use scriptpath module to find bitbake path and oe lib
path
  scripts/wic: append bitbake executable file path in eSDK environment
  scripts/wic: fix error of import wic module in eSDK environment
  scripts/wic: explicitly set BUILDDIR within eSDK
  classes/populate_sdk_ext: support wic in eSDK

 meta/classes/populate_sdk_ext.bbclass |  2 +-
 scripts/wic   | 23 ++-
 2 files changed, 19 insertions(+), 6 deletions(-)

-- 
2.7.4

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


[OE-core] [PATCH] tune-i686: Add new tune for better support of 686-class CPUs.

2018-01-10 Thread Carlos Alberto Lopez Perez
There isn't currently any tune available for i686 x86 optimizations.
The tune for i586 doesn't enable i686 specific optimizations, and the
one for core2 enables things that won't work on a i686 CPU (like SSE3).

This patch also changes the default tune for the qemux86 machine from
i586 to i686. This should cause no issue, as "runqemu qemux86" already
defaults to run with "-cpu pentium2".

The tune for core2 now inherits from this one, which allows to remove
the override on the X86ARCH32 definition.

Signed-off-by: Carlos Alberto Lopez Perez 
---
 meta/conf/machine/include/tune-core2.inc |  7 ++-
 meta/conf/machine/include/tune-i686.inc  | 25 +
 meta/conf/machine/qemux86.conf   |  2 +-
 3 files changed, 28 insertions(+), 6 deletions(-)
 create mode 100644 meta/conf/machine/include/tune-i686.inc

diff --git a/meta/conf/machine/include/tune-core2.inc 
b/meta/conf/machine/include/tune-core2.inc
index f4ba43fbfd..6a03466650 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -8,11 +8,8 @@
 #
 DEFAULTTUNE ?= "core2-32"
 
-# Set x86 target arch to i686, so that glibc enables SSE optimised memcpy, etc.
-X86ARCH32 ?= "i686"
-
 # Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
-require conf/machine/include/tune-i586.inc
+require conf/machine/include/tune-i686.inc
 
 # Extra tune features
 TUNEVALID[core2] = "Enable core2 specific processor optimizations"
@@ -23,7 +20,7 @@ AVAILTUNES += "core2-32"
 TUNE_FEATURES_tune-core2-32 = "${TUNE_FEATURES_tune-x86} core2"
 BASE_LIB_tune-core2-32 = "lib"
 TUNE_PKGARCH_tune-core2-32 = "core2-32"
-PACKAGE_EXTRA_ARCHS_tune-core2-32 = "${PACKAGE_EXTRA_ARCHS_tune-i586} core2-32"
+PACKAGE_EXTRA_ARCHS_tune-core2-32 = "${PACKAGE_EXTRA_ARCHS_tune-i686} core2-32"
 
 AVAILTUNES += "core2-64"
 TUNE_FEATURES_tune-core2-64 = "${TUNE_FEATURES_tune-x86-64} core2"
diff --git a/meta/conf/machine/include/tune-i686.inc 
b/meta/conf/machine/include/tune-i686.inc
new file mode 100644
index 00..c2bb534874
--- /dev/null
+++ b/meta/conf/machine/include/tune-i686.inc
@@ -0,0 +1,25 @@
+#
+# The i686 CPU family was introduced with the Intel Pentium Pro in 1995.
+# It has as required feature flags: fpu tsc cx8 cmov.
+#
+# It is the minimum CPU required by the Debian i386 port.
+# https://lists.debian.org/debian-devel-announce/2016/05/msg1.html
+#
+#
+
+DEFAULTTUNE ?= "i686"
+X86ARCH32 ?= "i686"
+
+# Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
+require conf/machine/include/tune-i586.inc
+
+# Extra tune features
+TUNEVALID[i686] = "Enable i686 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'i686', ' -march=i686', 
'', d)}"
+
+# Extra tune selections
+AVAILTUNES += "i686"
+TUNE_FEATURES_tune-i686 = "${TUNE_FEATURES_tune-x86} i686"
+BASE_LIB_tune-i686 = "lib"
+TUNE_PKGARCH_tune-i686 = "i686"
+PACKAGE_EXTRA_ARCHS_tune-i686 = "${PACKAGE_EXTRA_ARCHS_tune-i586} i686"
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index c53f7a92ce..f01cbeeb35 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -8,7 +8,7 @@ PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa"
 
 require conf/machine/include/qemu.inc
-require conf/machine/include/tune-i586.inc
+require conf/machine/include/tune-i686.inc
 require conf/machine/include/qemuboot-x86.inc
 
 KERNEL_IMAGETYPE = "bzImage"
-- 
2.11.0

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


[OE-core] ✗ patchtest: failure for "python3-manifest.json: Add som..." and 1 more

2018-01-10 Thread Patchwork
== Series Details ==

Series: "python3-manifest.json: Add som..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/10489/
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 e9dfe7eb7f)



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 2/2] python3: Fix native compilation of gdbm module and manifest

2018-01-10 Thread Alejandro Enedino Hernandez Samaniego
From: Alejandro Hernandez 

The gdbm module wasnt being built on python3-native showing the following
error during compilation:

Failed to build these modules:
_gdbm

This patch adds the required dependency to fix the compilation problem.

This issue on python3-native caused the manifest creation script to be
unaware of the gdbm library, so this patch also fixes the create_manifest
task for target python, and the manifest file to reflect the changes on
target python as well.

Signed-off-by: Alejandro Hernandez 
---
 meta/recipes-devtools/python/python3-native_3.5.3.bb  |  2 +-
 .../recipes-devtools/python/python3/python3-manifest.json | 15 +--
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-native_3.5.3.bb 
b/meta/recipes-devtools/python/python3-native_3.5.3.bb
index 3053c4b..12f9f24 100644
--- a/meta/recipes-devtools/python/python3-native_3.5.3.bb
+++ b/meta/recipes-devtools/python/python3-native_3.5.3.bb
@@ -38,7 +38,7 @@ UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar"
 S = "${WORKDIR}/Python-${PV}"

 EXTRANATIVEPATH += "bzip2-native"
-DEPENDS = "openssl-native bzip2-replacement-native zlib-native readline-native 
sqlite3-native"
+DEPENDS = "openssl-native bzip2-replacement-native zlib-native readline-native 
sqlite3-native gdbm-native"

 inherit native

diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 031745c..be020f8 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -366,7 +366,8 @@
 "db": {
 "cached": [],
 "files": [
-"${libdir}/python3.5/dbm"
+"${libdir}/python3.5/dbm",
+"${libdir}/python3.5/lib-dynload/_dbm.*.so"
 ],
 "rdepends": [
 "core"
@@ -493,6 +494,16 @@
 ],
 "summary": "Python's fcntl interface"
 },
+"gdbm": {
+"cached": [],
+"files": [
+"${libdir}/python3.5/lib-dynload/_gdbm.*.so"
+],
+"rdepends": [
+"core"
+],
+"summary": "Python GNU database support"
+},
 "html": {
 "cached": [
 "${libdir}/python3.5/__pycache__/formatter.*.pyc"
@@ -1128,4 +1139,4 @@
 ],
 "summary": "Python XML-RPC support"
 }
-}
+}
\ No newline at end of file
--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/2] python3-manifest.json: Add some binaries that were left out

2018-01-10 Thread Alejandro Enedino Hernandez Samaniego
From: Alejandro Hernandez 

With the introduction of a new manifest, since it had to be done manually
some binaries were left out, this patch adds them to their corresponding package
to fix the issue

Signed-off-by: Alejandro Hernandez 
---
 meta/recipes-devtools/python/python3/python3-manifest.json | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 72d95d8..031745c 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -2,6 +2,7 @@
 "2to3": {
 "cached": [],
 "files": [
+"${bindir}/2to3-*",
 "${libdir}/python3.5/lib2to3"
 ],
 "rdepends": [
@@ -508,7 +509,7 @@
 "idle": {
 "cached": [],
 "files": [
-"${bindir}/idle",
+"${bindir}/idle*",
 "${libdir}/python3.5/idlelib"
 ],
 "rdepends": [
@@ -881,7 +882,7 @@
 "${libdir}/python3.5/__pycache__/pydoc.*.pyc"
 ],
 "files": [
-"${bindir}/pydoc",
+"${bindir}/pydoc*",
 "${libdir}/python3.5/pydoc.py",
 "${libdir}/python3.5/pydoc_data"
 ],
--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] gcc: add flex-native explicit dependency

2018-01-10 Thread Denys Dmytriyenko
From: Denys Dmytriyenko 

It seems flex is required to build gcc:

| .../work-shared/gcc-7.2.0-r0/gcc-7.2.0/missing: line 81: flex: command not 
found
| WARNING: 'flex' is missing on your system.
|  You should only need it if you modified a '.l' file.
|  You may want to install the Fast Lexical Analyzer package:
|  
| Makefile:2799: recipe for target 'gengtype-lex.c' failed
| make[1]: [gengtype-lex.c] Error 127 (ignored)

Normally this is handled indirectly throught binutils-cross dependency
pulling in flex-native implicitly. For deterministic builds, this should
be specified explicitly.

Signed-off-by: Denys Dmytriyenko 
---
 meta/recipes-devtools/gcc/gcc-7.2.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
b/meta/recipes-devtools/gcc/gcc-7.2.inc
index 1d40cba..d1fb6de 100644
--- a/meta/recipes-devtools/gcc/gcc-7.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
@@ -10,7 +10,7 @@ BINV = "7.2.0"
 
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc-7.2:${FILE_DIRNAME}/gcc-7.2/backport:"
 
-DEPENDS =+ "mpfr gmp libmpc zlib"
+DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
 NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
 
 LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
-- 
2.7.4

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


[OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

2018-01-10 Thread jackie.huang
From: Jackie Huang 

'getopt' is needed by systemd-sysv-install, or it fails with:
| kdump.service is not a native service, redirecting to systemd-sysv-install.
| Executing: /lib/systemd/systemd-sysv-install enable kdump
| /lib/systemd/systemd-sysv-install: line 15: getopt: command not found

Signed-off-by: Jackie Huang 
---
 meta/recipes-core/systemd/systemd_234.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_234.bb 
b/meta/recipes-core/systemd/systemd_234.bb
index 4132cdf40f..5a0e4c2247 100644
--- a/meta/recipes-core/systemd/systemd_234.bb
+++ b/meta/recipes-core/systemd/systemd_234.bb
@@ -521,7 +521,7 @@ FILES_${PN} = " ${base_bindir}/* \
 
 FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/ 
${sysconfdir}/rpm/macros.systemd"
 
-RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV}) 
util-linux-agetty"
+RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV}) 
util-linux-agetty util-linux-getopt"
 RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 
'serial-getty-generator', '', 'systemd-serialgetty', d)}"
 RDEPENDS_${PN} += "volatile-binds update-rc.d"
 
-- 
2.11.0

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


[OE-core] [PATCH V2] xf86-video-intel: enable graphic and audio support for CFL-S Sku

2018-01-10 Thread Liwei Song
Add PCI IDs for Coffeelake S Skus to enalbe Graphic and audio
support.

Signed-off-by: Liwei Song 
---
 .../0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch   | 116 +
 .../xorg-driver/xf86-video-intel_git.bb|   1 +
 2 files changed, 117 insertions(+)
 create mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch

diff --git 
a/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch
 
b/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch
new file mode 100644
index ..b7ed8d40df80
--- /dev/null
+++ 
b/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch
@@ -0,0 +1,116 @@
+From 96d4e8e7b8a699f0ef77fa7b210d4de5f1c703d0 Mon Sep 17 00:00:00 2001
+From: Liwei Song 
+Date: Wed, 22 Nov 2017 08:59:03 +
+Subject: [PATCH] Add Coffeelake PCI IDs for S Skus
+
+Add the Coffeelake PCI IDs based on the following kernel patches:
+
+commit b056f8f3d6b900e8afd19f312719160346d263b4
+Author: Anusha Srivatsa 
+Date:   Thu Jun 8 16:41:05 2017 -0700
+
+drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.
+
+Upstream-Status: Submitted [https://patchwork.kernel.org/patch/10139905]
+
+Signed-off-by: Liwei Song 
+---
+ src/i915_pciids.h |  7 +++
+ src/intel_module.c| 13 +
+ src/sna/gen9_render.c | 12 
+ 3 files changed, 32 insertions(+)
+
+diff --git a/src/i915_pciids.h b/src/i915_pciids.h
+index 0370f830c541..11ccfa9c047a 100644
+--- a/src/i915_pciids.h
 b/src/i915_pciids.h
+@@ -340,4 +340,11 @@
+   INTEL_VGA_DEVICE(0x3184, info), \
+   INTEL_VGA_DEVICE(0x3185, info)
+ 
++#define INTEL_CFL_S_IDS(info) \
++  INTEL_VGA_DEVICE(0x3E90, info), /* SRV GT1 */ \
++  INTEL_VGA_DEVICE(0x3E93, info), /* SRV GT1 */ \
++  INTEL_VGA_DEVICE(0x3E91, info), /* SRV GT2 */ \
++  INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
++  INTEL_VGA_DEVICE(0x3E96, info)  /* SRV GT2 */
++
+ #endif /* _I915_PCIIDS_H */
+diff --git a/src/intel_module.c b/src/intel_module.c
+index 6b04857e2853..4827a67255f0 100644
+--- a/src/intel_module.c
 b/src/intel_module.c
+@@ -138,6 +138,10 @@ static const struct intel_device_info 
intel_geminilake_info = {
+   .gen = 0113,
+ };
+ 
++static const struct intel_device_info intel_coffeelake_info = {
++  .gen = 0114,
++};
++
+ static const SymTabRec intel_chipsets[] = {
+   {PCI_CHIP_I810, "i810"},
+   {PCI_CHIP_I810_DC100,   "i810-dc100"},
+@@ -303,6 +307,13 @@ static const SymTabRec intel_chipsets[] = {
+   {0x5916, "HD Graphics 620"},
+   {0x591E, "HD Graphics 615"},
+ 
++  /*Coffeelake*/
++  {0x3E90, "HD Graphics"},
++  {0x3E93, "HD Graphics"},
++  {0x3E91, "HD Graphics"},
++  {0x3E92, "HD Graphics"},
++  {0x3E96, "HD Graphics"},
++
+   /* When adding new identifiers, also update:
+* 1. intel_identify()
+* 2. man/intel.man
+@@ -368,6 +379,8 @@ static const struct pci_id_match intel_device_match[] = {
+ 
+   INTEL_GLK_IDS(_geminilake_info),
+ 
++  INTEL_CFL_S_IDS(_coffeelake_info),
++
+   INTEL_VGA_DEVICE(PCI_MATCH_ANY, _generic_info),
+ #endif
+ 
+diff --git a/src/sna/gen9_render.c b/src/sna/gen9_render.c
+index e5f12c723956..7f49052c5ec1 100644
+--- a/src/sna/gen9_render.c
 b/src/sna/gen9_render.c
+@@ -245,6 +245,11 @@ static const struct gt_info glk_gt_info = {
+   .urb = { .max_vs_entries = 320 },
+ };
+ 
++static const struct gt_info cfl_gt_info = {
++  .name = "Coffeelake (gen9)",
++  .urb = { .max_vs_entries = 960 },
++};
++
+ static bool is_skl(struct sna *sna)
+ {
+   return sna->kgem.gen == 0110;
+@@ -265,6 +270,11 @@ static bool is_glk(struct sna *sna)
+   return sna->kgem.gen == 0113;
+ }
+ 
++static bool is_cfl(struct sna *sna)
++{
++  return sna->kgem.gen == 0114;
++}
++
+ 
+ static inline bool too_large(int width, int height)
+ {
+@@ -4040,6 +4050,8 @@ static bool gen9_render_setup(struct sna *sna)
+   state->info = _gt_info;
+   if (is_glk(sna))
+   state->info = _gt_info;
++  if (is_cfl(sna))
++  state->info = _gt_info;
+ 
+   sna_static_stream_init();
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb 
b/meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb
index 138dfddcf34a..9aff9d8c2291 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb
@@ -16,6 +16,7 @@ S = "${WORKDIR}/git"
 SRC_URI = "git://anongit.freedesktop.org/xorg/driver/xf86-video-intel \
file://disable-x11-dri3.patch \
file://always_include_xorg_server.h.patch \
+   

Re: [OE-core] [PATCH] xf86-video-intel: enable graphic and audio support for CFL-S Sku

2018-01-10 Thread Liwei Song


On 01/10/2018 08:43 PM, Alexander Kanavin wrote:
> On 01/10/2018 11:43 AM, Liwei Song wrote:
> 
>> +Upstream-Status: Submitted [intel-...@lists.freedesktop.org]
> 
> Please add a link to the actual submission post in the mailing list archive, 
> so we can track what happened to it.

Got it.

Thanks,
Liwei.


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


Re: [OE-core] [RFC][PATCH] gcc: add flex-native explicit dependency

2018-01-10 Thread Denys Dmytriyenko
Oh, this is against rocko, which should be fine for RFC, but I'll rebase for 
master soon...


On Wed, Jan 10, 2018 at 02:39:03AM -0500, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko 
> 
> It seems flex is required to build gcc:
> 
> | .../work-shared/gcc-7.2.0-r0/gcc-7.2.0/missing: line 81: flex: command not 
> found
> | WARNING: 'flex' is missing on your system.
> |  You should only need it if you modified a '.l' file.
> |  You may want to install the Fast Lexical Analyzer package:
> |  
> | Makefile:2799: recipe for target 'gengtype-lex.c' failed
> | make[1]: [gengtype-lex.c] Error 127 (ignored)
> 
> Normally this is handled indirectly throught binutils-cross dependency
> pulling in flex-native implicitly. For deterministic builds, this should
> be specified explicitly.
> 
> Signed-off-by: Denys Dmytriyenko 
> ---
> RFC: Not sure if versioned .inc is the best place to spefice DEPENDS on 
> flex-native
> 
>  meta/recipes-devtools/gcc/gcc-6.3.inc | 2 +-
>  meta/recipes-devtools/gcc/gcc-7.2.inc | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-6.3.inc 
> b/meta/recipes-devtools/gcc/gcc-6.3.inc
> index e569e02..39aca13 100644
> --- a/meta/recipes-devtools/gcc/gcc-6.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-6.3.inc
> @@ -10,7 +10,7 @@ BINV = "6.3.0"
>  
>  FILESEXTRAPATHS =. 
> "${FILE_DIRNAME}/gcc-6.3:${FILE_DIRNAME}/gcc-6.3/backport:"
>  
> -DEPENDS =+ "mpfr gmp libmpc zlib"
> +DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
>  NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
>  
>  LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
> diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
> b/meta/recipes-devtools/gcc/gcc-7.2.inc
> index 1d40cba..d1fb6de 100644
> --- a/meta/recipes-devtools/gcc/gcc-7.2.inc
> +++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
> @@ -10,7 +10,7 @@ BINV = "7.2.0"
>  
>  FILESEXTRAPATHS =. 
> "${FILE_DIRNAME}/gcc-7.2:${FILE_DIRNAME}/gcc-7.2/backport:"
>  
> -DEPENDS =+ "mpfr gmp libmpc zlib"
> +DEPENDS =+ "mpfr gmp libmpc zlib flex-native"
>  NATIVEDEPS = "mpfr-native gmp-native libmpc-native zlib-native"
>  
>  LICENSE = "GPL-3.0-with-GCC-exception & GPLv3"
> -- 
> 2.7.4
> 
> -- 
> ___
> 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] uriparser

2018-01-10 Thread Trevor Woerner
Hi Martin,

Any chance the uriparser recipe from meta-luneui (
https://layers.openembedded.org/layerindex/recipe/32523/) could be added to
openembedded-core (or meta-openembedded?). It's also now needed for the git
version of tpm2-tss in meta-measured.

Best regards,
 Trevor
-- 
___
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

2018-01-10 Thread 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

2018-01-10 Thread Richard Purdie
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
-- 
___
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

2018-01-10 Thread 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


[OE-core] [PATCH] linux-firmware: Bump revision to 65b1c68c

2018-01-10 Thread Otavio Salvador
The bump includes following changes:

65b1c68 wl18xx: update firmware file 8.9.0.0.76
8650396 wl127x/wl128x: update firmwares
2eefafb rtlwifi: rtl8723de: Add firmware for new driver/device
4a77cab linux-firmware: DMC firmware for cannonlake v1.07
2567e09 nvidia: add GP108 signed firmware
2451bb2 linux-firmware: liquidio: add v1.7.0 vswitch firmware
7f93c9d brcm: add CYW4373 firmwares and Cypress license file
fdee922 linux-firmware: Update firmware patch for Intel Bluetooth 8260
9a843a1 linux-firmware: Update firmware file for Intel Bluetooth 8265
97339b3 linux-firmware: Add firmware file for Intel Bluetooth 9260
db9964e linux-firmware: Add firmware file for Intel Bluetooth 9560
e4252cf Revert commits a42f895, c113d33, 041aff8, 73d13b5
a42f895 linux-firmware: Update firmware patch for Intel Bluetooth 8260
c113d33 linux-firmware: Update firmware file for Intel Bluetooth 8265
041aff8 linux-firmware: Add firmware file for Intel Bluetooth 9260
73d13b5 linux-firmware: Add firmware file for Intel Bluetooth 9560
30946b9 amdgpu: add firmware for Raven
71a4800 amdgpu: update vega10 vce firmware
89c6211 linux-firmware: intel: Add Cannonlake audio firmware
b39260f nfp: add firmware for tc-flower
c752e24 nfp: change firmware directory layout
00a92a3 nfp: update firmware for Agilio CX SmartNICs
02d857e linux-firmware: DMC firmware for skylake v1.27
17e6288 brcm: update firmware for bcm4358
1841cec brcm: update firmware for bcm4356
b3f4e74 brcm: update firmware for bcm4354
cd86989 brcm: introduce firmware for bcm43430 revision 0
5ee46c2 brcm: update firmware for bcm4339
8e864c2 Mellanox: Add new mlxsw_spectrum firmware 13.1530.152
fd45000 WHENCE: Add missing entry for mlxsw_spectrum firmware
7f9bbc7 WHENCE: Fix typo in entry for iwlwifi-8265-34.ucode
284de20 s2255drv: f2255usb: firmware version 1.2.8
7c705a4 amdgpu: add new CP firmware for polaris chips
5582ca4 qed: Add firmware 8.33.1.0
e721933 qcom: add venus firmware files for v4.2
f36a8e2 qcom: add firmware files for Adreno a530
85313b4 iwlwifi: add firmware version 34 for new 9000 series
6c161c5 linux-firmware: liquidio: update firmware to v1.7.0
b964279 linux-firmware: intel: Update Geminilake audio firmware
c4276b6 iwlwifi: add firmware version 33 for new 9000 series
5a05332 iwlwifi: add new firmware version 34 for 8000C and 8265
1a5fd94 iwlwifi: update firmwares for 3160, 3168, 7260, 7265 and 7265D
796c912 iwlwifi: update firmwares for 3160, 3168, 7265D, 8000C and 8265
1156e62 linux-firmware: DMC firmware for kabylake v1.04
db3e185 linux-firmware: update Marvell PCIe-USB8997 firmware image
de81715 linux-firmware: GuC firmware for kabylake v9.39
434e712 linux-firmware: GuC firmware for Broxton v9.29
0aebd9f linux-firmware: GuC firmware for Skylake v9.33
de5b4c2 linux-firmware/i915: Add Cannonlake DMC version 1.06
8e7c787 linux-firmware/i915: Add Geminilake DMC version 1.04
e0494e9 linux-firmware: update Marvell PCIe-USB8997 firmware image
11db131 linux-firmware: update Marvell PCIe-USB8897-A2 firmware image

Included in those changes, two license checksums has been changed:

 - LICENCE.Netronome: minimal change dropping a word in license name;
 - WHENCE: adjustments due the new firmware versions;

Signed-off-by: Otavio Salvador 
---

 meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 8433308a86..b194a59ecb 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -90,7 +90,7 @@ LIC_FILES_CHKSUM = "\
 file://LICENCE.Marvell;md5=9ddea1734a4baf3c78d845151f42a37a \
 file://LICENCE.moxa;md5=1086614767d8ccf744a923289d3d4261 \
 file://LICENCE.myri10ge_firmware;md5=42e32fb89f6b959ca222e25ac8df8fed \
-file://LICENCE.Netronome;md5=cd2a3e6effe3cdf42731575b8e9477ed \
+file://LICENCE.Netronome;md5=4add08f2577086d7996503cddf5f \
 file://LICENCE.nvidia;md5=4428a922ed3ba2ceec95f076a488ce07 \
 file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd \
 
file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 \
@@ -116,7 +116,7 @@ LIC_FILES_CHKSUM = "\
 file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \
 file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
 file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
-file://WHENCE;md5=038edbc9e744171d8b6235e0224028ba \
+file://WHENCE;md5=99d352987a7e29460bcf9b26d146a95a \
 "
 
 # These are not common licenses, set NO_GENERIC_LICENSE for them
@@ -178,7 +178,7 @@ NO_GENERIC_LICENSE[Firmware-xc5000] = "LICENCE.xc5000"
 NO_GENERIC_LICENSE[Firmware-xc5000c] = "LICENCE.xc5000c"
 NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
 
-SRCREV = "bf04291309d3169c0ad3b8db52564235bbd08e30"
+SRCREV = "65b1c68c63f974d72610db38dfae49861117cae2"
 PE = "1"
 PV = 

[OE-core] [PATCH 1/2] glib-2.0: rationalise build dependencies

2018-01-10 Thread Ross Burton
nativesdk-glib-2.0 doesn't build-depend on nativesdk-gettext, but all variations
need to depend on gettext-native as they need msgfmt (so gettext-minimal-native
isn't an option).

Also add virtual/libintl as glib explicitly needs this. Generally this is
provided by glibc but some platforms (such as MinGW) don't.

Signed-off-by: Ross Burton 
---
 meta/recipes-core/glib-2.0/glib.inc | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index cfeb48a5368..b374f6bb2e4 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -3,7 +3,7 @@ DESCRIPTION = "GLib is a general-purpose utility library, which 
provides many us
 HOMEPAGE = "https://developer.gnome.org/glib/;
 
 # pcre is under BSD;
-# docs/reference/COPYING is with a 'public domai'-like license!
+# docs/reference/COPYING is with a 'public domain'-like license!
 LICENSE = "LGPLv2.1+ & BSD & PD"
 LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c \
 
file://glib/glib.h;beginline=4;endline=17;md5=b88abb7f3ad09607e71cb9d530155906 \
@@ -19,10 +19,13 @@ CVE_PRODUCT = "glib"
 
 BBCLASSEXTEND = "native nativesdk"
 
-DEPENDS = "virtual/libiconv libffi zlib glib-2.0-native"
-DEPENDS_append = " ${@bb.utils.contains('PTEST_ENABLED', '1', ' dbus', '', d)}"
-DEPENDS_class-native = "pkgconfig-native gettext-native libffi-native 
zlib-native"
-DEPENDS_class-nativesdk = "nativesdk-libtool nativesdk-gettext 
nativesdk-libffi nativesdk-zlib glib-2.0-native"
+DEPENDS = "glib-2.0-native \
+   gettext-native \
+   virtual/libintl \
+   virtual/libiconv \
+   libffi \
+   zlib \
+   ${@bb.utils.contains('PTEST_ENABLED', '1', 'dbus', '', d)}"
 
 PACKAGES += "${PN}-codegen ${PN}-utils"
 
-- 
2.11.0

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


Re: [OE-core] [PATCH 4/4] gnupg: use native version for signing, rather than one provided by host

2018-01-10 Thread Leonardo Sandoval
Great that you figure out a solution.

So I belive we need to revert this commit:

commit 043d9ac0ae441e9a7e2ea8934bfc595a03ef9a52
Author: Leonardo Sandoval 
Date:   Mon Sep 25 13:52:59 2017 -0700

sign_rpm.bbclass: force rpm serial signing

Newer versions of gpg (at least 2.1.5 and 2.2.1) have issues when signing 
occurs in parallel
so (unfortunately) the signing must be done serially. Once the upstream 
problem is fixed,
this patch must be reverted, otherwise we loose all the intrinsic 
parallelism from
bitbake.

[YOCTO #12022]

(From OE-Core rev: 5301712f9735fcf8d3dec756772668de930e53fe)



On Wed, 10 Jan 2018 14:27:42 +0200
Alexander Kanavin  wrote:

> Using host gpg has been problematic, and particularly this removes
> the need to serialize package creation, as long as --auto-expand-secmem
> is passed to gpg-agent, and gnupg >= 2.2.4 is in use
> (https://dev.gnupg.org/T3530).
> 
> Sadly, gpg-agent itself is single-threaded, so in the longer run
> we might want to seek alternatives:
> https://lwn.net/Articles/742542/
> 
> (a smaller issue is that rpm itself runs the gpg fronted in a serial
> fashion, which slows down the build in cases of recipes with very
> large amount of packages, e.g. glibc-locale)
> 
> Note that sstate signing and verification continues to use host
> gpg, as depending on native gpg would create circular dependencies.
> 
> [YOCTO #12022]
> 
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/classes/sign_package_feed.bbclass | 2 +-
>  meta/classes/sign_rpm.bbclass  | 6 +-
>  meta/lib/oe/gpg_sign.py| 8 ++--
>  meta/recipes-core/meta/signing-keys.bb | 1 +
>  4 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/classes/sign_package_feed.bbclass 
> b/meta/classes/sign_package_feed.bbclass
> index f03c4802d06..7ff3a35a2fa 100644
> --- a/meta/classes/sign_package_feed.bbclass
> +++ b/meta/classes/sign_package_feed.bbclass
> @@ -43,4 +43,4 @@ python () {
>  }
>  
>  do_package_index[depends] += "signing-keys:do_deploy"
> -do_rootfs[depends] += "signing-keys:do_populate_sysroot"
> +do_rootfs[depends] += "signing-keys:do_populate_sysroot 
> gnupg-native:do_populate_sysroot"
> diff --git a/meta/classes/sign_rpm.bbclass b/meta/classes/sign_rpm.bbclass
> index 4961b03618f..64ae7ce30e3 100644
> --- a/meta/classes/sign_rpm.bbclass
> +++ b/meta/classes/sign_rpm.bbclass
> @@ -68,8 +68,4 @@ python sign_rpm () {
>  do_package_index[depends] += "signing-keys:do_deploy"
>  do_rootfs[depends] += "signing-keys:do_populate_sysroot"
>  
> -# Newer versions of gpg (at least 2.1.5 and 2.2.1) have issues when signing 
> occurs in parallel
> -# so unfortunately the signing must be done serially. Once the upstream 
> problem is fixed,
> -# the following line must be removed otherwise we loose all the intrinsic 
> parallelism from
> -# bitbake.  For more information, check 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12022.
> -do_package_write_rpm[lockfiles] += "${TMPDIR}/gpg.lock"
> +PACKAGE_WRITE_DEPS += "gnupg-native"
> diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
> index 9cc88f020c1..b17272928fc 100644
> --- a/meta/lib/oe/gpg_sign.py
> +++ b/meta/lib/oe/gpg_sign.py
> @@ -12,6 +12,7 @@ class LocalSigner(object):
>  self.gpg_path = d.getVar('GPG_PATH')
>  self.gpg_version = self.get_gpg_version()
>  self.rpm_bin = bb.utils.which(os.getenv('PATH'), "rpmsign")
> +self.gpg_agent_bin = bb.utils.which(os.getenv('PATH'), "gpg-agent")
>  
>  def export_pubkey(self, output_file, keyid, armor=True):
>  """Export GPG public key to a file"""
> @@ -31,7 +32,7 @@ class LocalSigner(object):
>  """Sign RPM files"""
>  
>  cmd = self.rpm_bin + " --addsign --define '_gpg_name %s'  " % keyid
> -gpg_args = '--no-permission-warning --batch --passphrase=%s' % 
> passphrase
> +gpg_args = '--no-permission-warning --batch --passphrase=%s 
> --agent-program=%s|--auto-expand-secmem' % (passphrase, self.gpg_agent_bin)
>  if self.gpg_version > (2,1,):
>  gpg_args += ' --pinentry-mode=loopback'
>  cmd += "--define '_gpg_sign_cmd_extra_args %s' " % gpg_args
> @@ -71,6 +72,9 @@ class LocalSigner(object):
>  if self.gpg_version > (2,1,):
>  cmd += ['--pinentry-mode', 'loopback']
>  
> +if self.gpg_agent_bin:
> +cmd += ["--agent-program=%s|--auto-expand-secmem" % 
> (self.gpg_agent_bin)]
> +
>  cmd += [input_file]
>  
>  try:
> @@ -99,7 +103,7 @@ class LocalSigner(object):
>  import subprocess
>  try:
>  ver_str = subprocess.check_output((self.gpg_bin, "--version", 
> "--no-permission-warning")).split()[2].decode("utf-8")
> -return tuple([int(i) for i in ver_str.split('.')])
> +return tuple([int(i) for i 

[OE-core] [PATCH] perf: conditionalise pythonnative and perlnative inherits

2018-01-10 Thread Ross Burton
Only inherit these classes (and so, add perl-native and python-native to
DEPENDS) if the scripting PACKAGECONFIG is actually enabled.

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/perf/perf.bb | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index bb943ecd1c5..1bad6f4e9bf 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -35,9 +35,10 @@ do_configure[depends] += "virtual/kernel:do_shared_workdir"
 
 PROVIDES = "virtual/perf"
 
-inherit linux-kernel-base kernel-arch pythonnative
+inherit linux-kernel-base kernel-arch
 
 # needed for building the tools/perf Python bindings
+inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'pythonnative', '', 
d)}
 inherit python-dir
 export PYTHON_SITEPACKAGES_DIR
 
@@ -47,7 +48,8 @@ export WERROR = "0"
 do_populate_lic[depends] += "virtual/kernel:do_patch"
 
 # needed for building the tools/perf Perl binding
-inherit perlnative cpan-base
+inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'perlnative', '', 
d)}
+inherit cpan-base
 # Env var which tells perl if it should use host (no) or target (yes) settings
 export PERLCONFIGTARGET = "${@is_target(d)}"
 export PERL_INC = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}/CORE"
-- 
2.11.0

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


Re: [OE-core] [PATCH v2] wic: if we can't get from ioctl, try from os.stat()

2018-01-10 Thread Ed Bartosh
On Tue, Jan 09, 2018 at 04:35:24PM +0300, Dogukan Ergun wrote:
> Under some conditions, ioctl FIGETBSZ can't return real value.
> We can try to use fallback via os.stat() to get block size.
> 

Thank you for the patch!

+1


> Source of patch:
> https://github.com/intel/bmap-tools/commit/17365f4fe9089df7ee9800a2a0ced177ec4798a4
> 
> Signed-off-by: Dogukan Ergun 
> ---
>  scripts/lib/wic/filemap.py | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/lib/wic/filemap.py b/scripts/lib/wic/filemap.py
> index 77e32b9..a72fa09 100644
> --- a/scripts/lib/wic/filemap.py
> +++ b/scripts/lib/wic/filemap.py
> @@ -37,7 +37,15 @@ def get_block_size(file_obj):
>  # Get the block size of the host file-system for the image file by 
> calling
>  # the FIGETBSZ ioctl (number 2).
>  binary_data = fcntl.ioctl(file_obj, 2, struct.pack('I', 0))
> -return struct.unpack('I', binary_data)[0]
> +bsize = struct.unpack('I', binary_data)[0]
> +if not bsize:
> +import os
> +stat = os.fstat(file_obj.fileno())
> +if hasattr(stat, 'st_blksize'):
> +bsize = stat.st_blksize
> +else:
> +raise IOError("Unable to determine block size")
> +return bsize
>  
>  class ErrorNotSupp(Exception):
>  """
> -- 
> 2.7.4
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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


Re: [OE-core] [PATCH] xf86-video-intel: enable graphic and audio support for CFL-S Sku

2018-01-10 Thread Alexander Kanavin

On 01/10/2018 11:43 AM, Liwei Song wrote:


+Upstream-Status: Submitted [intel-...@lists.freedesktop.org]


Please add a link to the actual submission post in the mailing list 
archive, so we can track what happened to it.


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 cross-compiling environment

2018-01-10 Thread Alexander Kanavin

On 01/09/2018 11:41 AM, Nirbheek Chauhan wrote:


On a quick scan of the patches I can see the issues you're having but
the solutions are not correct in the general case, so they need some
work. Could you please file separate PRs for each patch? That way our
CI will run on them and show failures, and we'll also be able to work
towards ironing them out and upstreaming them.


Sure; I certainly don't want to claim they're generally correct. Take 
them as an illustration of the issues we faced when using meson in a 
cross-compilation environment against a target sysroot set to something 
else than /.


I'll file them when I have a bit of quiet moment this week.

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

2018-01-10 Thread Alexander Kanavin

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


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


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


I've built on the meta-oe meson recipe created by other people (tried to 
credit them in the commit). My contribution was mostly polish and 
testing, so that the recipe is of sufficient quality to be included in 
oe-core - particularly that it doesn't break anything on the autobuilder 
across architectures and configurations, and switching recipes from 
autotools to meson does not come with feature regressions (e.g. 
gobject-introspection, which is notoriously tricky for us).



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



Would it be possible to tell Yocto to not set those vars when building
a recipe that uses meson?


FWIW, I fully agree. Environment variables are an obsolete technique 
from old Unices, and a notorious source of frustration - because it's 
very easy for software to quietly modify them behind the human's back, 
as opposed to setting things via config files and command line switches, 
which are both a lot more controlled and disciplined. Ideally, I want to 
reduce or eliminate the use of env vars altogether in Yocto (long way to 
go there, I know).



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


[OE-core] [PATCH 4/4] gnupg: use native version for signing, rather than one provided by host

2018-01-10 Thread Alexander Kanavin
Using host gpg has been problematic, and particularly this removes
the need to serialize package creation, as long as --auto-expand-secmem
is passed to gpg-agent, and gnupg >= 2.2.4 is in use
(https://dev.gnupg.org/T3530).

Sadly, gpg-agent itself is single-threaded, so in the longer run
we might want to seek alternatives:
https://lwn.net/Articles/742542/

(a smaller issue is that rpm itself runs the gpg fronted in a serial
fashion, which slows down the build in cases of recipes with very
large amount of packages, e.g. glibc-locale)

Note that sstate signing and verification continues to use host
gpg, as depending on native gpg would create circular dependencies.

[YOCTO #12022]

Signed-off-by: Alexander Kanavin 
---
 meta/classes/sign_package_feed.bbclass | 2 +-
 meta/classes/sign_rpm.bbclass  | 6 +-
 meta/lib/oe/gpg_sign.py| 8 ++--
 meta/recipes-core/meta/signing-keys.bb | 1 +
 4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/meta/classes/sign_package_feed.bbclass 
b/meta/classes/sign_package_feed.bbclass
index f03c4802d06..7ff3a35a2fa 100644
--- a/meta/classes/sign_package_feed.bbclass
+++ b/meta/classes/sign_package_feed.bbclass
@@ -43,4 +43,4 @@ python () {
 }
 
 do_package_index[depends] += "signing-keys:do_deploy"
-do_rootfs[depends] += "signing-keys:do_populate_sysroot"
+do_rootfs[depends] += "signing-keys:do_populate_sysroot 
gnupg-native:do_populate_sysroot"
diff --git a/meta/classes/sign_rpm.bbclass b/meta/classes/sign_rpm.bbclass
index 4961b03618f..64ae7ce30e3 100644
--- a/meta/classes/sign_rpm.bbclass
+++ b/meta/classes/sign_rpm.bbclass
@@ -68,8 +68,4 @@ python sign_rpm () {
 do_package_index[depends] += "signing-keys:do_deploy"
 do_rootfs[depends] += "signing-keys:do_populate_sysroot"
 
-# Newer versions of gpg (at least 2.1.5 and 2.2.1) have issues when signing 
occurs in parallel
-# so unfortunately the signing must be done serially. Once the upstream 
problem is fixed,
-# the following line must be removed otherwise we loose all the intrinsic 
parallelism from
-# bitbake.  For more information, check 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12022.
-do_package_write_rpm[lockfiles] += "${TMPDIR}/gpg.lock"
+PACKAGE_WRITE_DEPS += "gnupg-native"
diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 9cc88f020c1..b17272928fc 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -12,6 +12,7 @@ class LocalSigner(object):
 self.gpg_path = d.getVar('GPG_PATH')
 self.gpg_version = self.get_gpg_version()
 self.rpm_bin = bb.utils.which(os.getenv('PATH'), "rpmsign")
+self.gpg_agent_bin = bb.utils.which(os.getenv('PATH'), "gpg-agent")
 
 def export_pubkey(self, output_file, keyid, armor=True):
 """Export GPG public key to a file"""
@@ -31,7 +32,7 @@ class LocalSigner(object):
 """Sign RPM files"""
 
 cmd = self.rpm_bin + " --addsign --define '_gpg_name %s'  " % keyid
-gpg_args = '--no-permission-warning --batch --passphrase=%s' % 
passphrase
+gpg_args = '--no-permission-warning --batch --passphrase=%s 
--agent-program=%s|--auto-expand-secmem' % (passphrase, self.gpg_agent_bin)
 if self.gpg_version > (2,1,):
 gpg_args += ' --pinentry-mode=loopback'
 cmd += "--define '_gpg_sign_cmd_extra_args %s' " % gpg_args
@@ -71,6 +72,9 @@ class LocalSigner(object):
 if self.gpg_version > (2,1,):
 cmd += ['--pinentry-mode', 'loopback']
 
+if self.gpg_agent_bin:
+cmd += ["--agent-program=%s|--auto-expand-secmem" % 
(self.gpg_agent_bin)]
+
 cmd += [input_file]
 
 try:
@@ -99,7 +103,7 @@ class LocalSigner(object):
 import subprocess
 try:
 ver_str = subprocess.check_output((self.gpg_bin, "--version", 
"--no-permission-warning")).split()[2].decode("utf-8")
-return tuple([int(i) for i in ver_str.split('.')])
+return tuple([int(i) for i in ver_str.split("-")[0].split('.')])
 except subprocess.CalledProcessError as e:
 raise bb.build.FuncFailed("Could not get gpg version: %s" % e)
 
diff --git a/meta/recipes-core/meta/signing-keys.bb 
b/meta/recipes-core/meta/signing-keys.bb
index 2c1cc3845ea..6387d90d474 100644
--- a/meta/recipes-core/meta/signing-keys.bb
+++ b/meta/recipes-core/meta/signing-keys.bb
@@ -41,6 +41,7 @@ python do_get_public_keys () {
 }
 do_get_public_keys[cleandirs] = "${B}"
 addtask get_public_keys before do_install
+do_get_public_keys[depends] += "gnupg-native:do_populate_sysroot"
 
 do_install () {
 if [ -f "${B}/rpm-key" ]; then
-- 
2.15.1

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


[OE-core] [PATCH 2/4] gnupg: upgrade to 2.2.4

2018-01-10 Thread Alexander Kanavin
Signed-off-by: Alexander Kanavin 
---
 meta/recipes-support/gnupg/{gnupg_2.2.0.bb => gnupg_2.2.4.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/gnupg/{gnupg_2.2.0.bb => gnupg_2.2.4.bb} (91%)

diff --git a/meta/recipes-support/gnupg/gnupg_2.2.0.bb 
b/meta/recipes-support/gnupg/gnupg_2.2.4.bb
similarity index 91%
rename from meta/recipes-support/gnupg/gnupg_2.2.0.bb
rename to meta/recipes-support/gnupg/gnupg_2.2.4.bb
index 0176dddad24..e9f19ca8140 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.0.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.4.bb
@@ -16,8 +16,8 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://0004-autogen.sh-fix-find-version-for-beta-checking.patch \
   "
 
-SRC_URI[md5sum] = "789f16949fae2d003d387f49e9da4b74"
-SRC_URI[sha256sum] = 
"d4514a0be0f7a1ff263193330019eb4b53c82f0f5e230af3c14df371271a45e6"
+SRC_URI[md5sum] = "709e5af5bba84d251c520222e720972f"
+SRC_URI[sha256sum] = 
"401a3e64780fdfa6d7670de0880aa5c9d589b3db7a7098979d7606cec546f2ec"
 
 EXTRA_OECONF = "--disable-ldap \
--disable-ccid-driver \
-- 
2.15.1

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


[OE-core] [PATCH 3/4] gnupg: enable native version

2018-01-10 Thread Alexander Kanavin
Signed-off-by: Alexander Kanavin 
---
 meta/recipes-support/gnupg/gnupg_2.2.4.bb   | 2 ++
 meta/recipes-support/libksba/libksba_1.3.5.bb   | 2 ++
 meta/recipes-support/npth/npth_1.5.bb   | 2 ++
 meta/recipes-support/pinentry/pinentry_1.1.0.bb | 2 ++
 4 files changed, 8 insertions(+)

diff --git a/meta/recipes-support/gnupg/gnupg_2.2.4.bb 
b/meta/recipes-support/gnupg/gnupg_2.2.4.bb
index e9f19ca8140..e15bcf298ac 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.4.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.4.bb
@@ -44,3 +44,5 @@ do_install_append() {
 PACKAGECONFIG ??= "gnutls"
 PACKAGECONFIG[gnutls] = "--enable-gnutls, --disable-gnutls, gnutls"
 PACKAGECONFIG[sqlite3] = "--enable-sqlite, --disable-sqlite, sqlite3"
+
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-support/libksba/libksba_1.3.5.bb 
b/meta/recipes-support/libksba/libksba_1.3.5.bb
index 36b66705634..a7ea53fed02 100644
--- a/meta/recipes-support/libksba/libksba_1.3.5.bb
+++ b/meta/recipes-support/libksba/libksba_1.3.5.bb
@@ -24,3 +24,5 @@ do_configure_prepend () {
# Else these could be used in preference to those in aclocal-copy
rm -f ${S}/m4/gpg-error.m4
 }
+
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-support/npth/npth_1.5.bb 
b/meta/recipes-support/npth/npth_1.5.bb
index 54de70c5c08..e7db6ae1b4b 100644
--- a/meta/recipes-support/npth/npth_1.5.bb
+++ b/meta/recipes-support/npth/npth_1.5.bb
@@ -19,3 +19,5 @@ inherit autotools binconfig-disabled
 
 FILES_${PN} = "${libdir}/libnpth.so.*"
 FILES_${PN}-dev += "${bindir}/npth-config"
+
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-support/pinentry/pinentry_1.1.0.bb 
b/meta/recipes-support/pinentry/pinentry_1.1.0.bb
index 3b77709ffb5..1eaa261f75a 100644
--- a/meta/recipes-support/pinentry/pinentry_1.1.0.bb
+++ b/meta/recipes-support/pinentry/pinentry_1.1.0.bb
@@ -34,3 +34,5 @@ PACKAGECONFIG[gtk2] = "--enable-pinentry-gtk2, 
--disable-pinentry-gtk2, gtk+ gli
 
 #To use libsecret, add meta-gnome
 PACKAGECONFIG[secret] = "--enable-libsecret, --disable-libsecret, libsecret"
+
+BBCLASSEXTEND = "native"
-- 
2.15.1

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


[OE-core] [PATCH 1/4] libgcrypt: upgrade to 1.8.2

2018-01-10 Thread Alexander Kanavin
Signed-off-by: Alexander Kanavin 
---
 .../libgcrypt/{libgcrypt_1.8.1.bb => libgcrypt_1.8.2.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/libgcrypt/{libgcrypt_1.8.1.bb => 
libgcrypt_1.8.2.bb} (92%)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.8.1.bb 
b/meta/recipes-support/libgcrypt/libgcrypt_1.8.2.bb
similarity index 92%
rename from meta/recipes-support/libgcrypt/libgcrypt_1.8.1.bb
rename to meta/recipes-support/libgcrypt/libgcrypt_1.8.2.bb
index 5bd815ae55a..b36e653a876 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.8.1.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.8.2.bb
@@ -21,8 +21,8 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.bz2 \

file://0002-libgcrypt-fix-building-error-with-O2-in-sysroot-path.patch \

file://0004-tests-Makefile.am-fix-undefined-reference-to-pthread.patch \
 "
-SRC_URI[md5sum] = "b21817f9d850064d2177285f1073ec55"
-SRC_URI[sha256sum] = 
"7a2875f8b1ae0301732e878c0cca2c9664ff09ef71408f085c50e332656a78b3"
+SRC_URI[md5sum] = "cfb0b5c79eab07686b6898160a407139"
+SRC_URI[sha256sum] = 
"c8064cae7558144b13ef0eb87093412380efa16c4ee30ad12ecb54886a524c07"
 
 BINCONFIG = "${bindir}/libgcrypt-config"
 
-- 
2.15.1

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


Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

2018-01-10 Thread Patrick Ohly
On Tue, 2018-01-09 at 11:51 -0600, Mark Hatle wrote:
> On 1/4/18 4:41 AM, Patrick Ohly wrote:
> > On Thu, 2018-01-04 at 11:18 +0100, José Bollo wrote:
> > > > Do you agree to move the patch to Smack specific layer? Such
> > > > as 
> > > > meta-security?
> > > 
> > > I agree.
> > 
> > Layers like meta-security should not modify recipes from other
> > layers,
> > at least not by default. That would violate the "Yocto Compatible
> > 2.0"
> > rules.
> 
> You can modify (bbappend) to an existing recipe.  You can't change
> the behavior
> (specifically the md5sum) of the function though, unless that new
> functionality
> is enabled.)

That's what I meant with "by default".

> 'smack' should be able to do the same thing, with a similar distro
> feature.

I'm not convinced that building core components differently depending
on such distro features is desirable, because it makes "smack" and
"selinux" mutually exclusive. I'd prefer a solution where support for
both can be enabled and then on the image itself the tools decide what
to do. Whether that's always possible of course is a different
question.

In this case I think it is, by adding the exception for
security.selinux. But I'll leave that up to you and Jose to decide.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


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


[OE-core] [PATCH v2] package.bbclass: variable to influence link style

2018-01-10 Thread Michael Blättler
When using separate debug file, gdb needs to match the debug file and
the binary. To match them, there can either be a .gnu_debuglink section
in the binary or a build-id embedded in the debug file and binary.
Until now, only the debuglink option was available. The problem with the
debuglink is, that it contains a checksum of the debug information.
Since the debug information depends on build path and many other things
reproducible binaries were not possible. The build-id can be set via
compiler flag and can be generated from ${PF} or other variables to
ensure reproducibility.

This commit introduces a new variable PACKAGE_DEBUG_SPLIT_LINK_STYLE
which specifies the link option between debug infos and binary. If
build-id is uesed as link option, the id can be defined with the
BUILD_ID variable.

Signed-off-by: Michael Blättler 
---
 meta/classes/insane.bbclass   | 41 +++
 meta/classes/package.bbclass  | 21 +-
 meta/conf/bitbake.conf|  9 +++-
 meta/recipes-bsp/u-boot/u-boot.inc|  3 +++
 meta/recipes-core/glibc/glibc_2.26.bb |  4 
 5 files changed, 71 insertions(+), 7 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 7407b29f86..4e20a6056e 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -17,6 +17,8 @@
 #  -Check that scripts in base_[bindir|sbindir|libdir] do not reference
 #   files under exec_prefix
 #  -Check if the package name is upper case
+#  -Ensure GDB can link the debug information with the binary by the
+#   specified linkstyle.
 
 QA_SANE = "True"
 
@@ -28,6 +30,7 @@ WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir 
xorg-driver-abi \
 pn-overrides infodir build-deps \
 unknown-configure-option symlink-to-sysroot multilib \
 invalid-packageconfig host-user-contaminated uppercase-pn \
+debug-linkstyle \
 "
 ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
 perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
@@ -514,6 +517,44 @@ def package_qa_hash_style(path, name, d, elf, messages):
 if has_syms and not sane:
 package_qa_add_message(messages, "ldflags", "No GNU_HASH in the elf 
binary: '%s'" % path)
 
+QAPATHTEST[debug-linkstyle] = "package_qa_debug_split_link_style"
+def package_qa_debug_split_link_style(path, name, d, elf, messages):
+"""
+Check if the binary has the correct symbol for GDB to link debug 
information
+to its corresponding binary.
+"""
+
+# Skip if elf file is an object file or static library or if the debug 
information
+# is not splited.
+if not elf or not elf.isDynamic() or 
d.getVar('INHIBIT_PACKAGE_DEBUG_SPLIT') == '1':
+return
+
+if os.path.islink(path):
+return
+
+link_style = d.getVar('PACKAGE_DEBUG_SPLIT_LINK_STYLE')
+
+check_debuglink = True
+if path.find(".debug") != -1:
+check_debuglink = False  # do not check for debuglink in debug binaries
+
+section_headers = elf.run_objdump("-h", d)
+
+has_buildid = False
+has_debuglink = False
+for header in section_headers.split("\n"):
+has_buildid |= ".note.gnu.build-id" in header
+has_debuglink |= ".gnu_debuglink" in header
+
+if link_style == "build-id":
+sane = has_buildid and not has_debuglink
+elif link_style == "both":
+sane = has_buildid and (has_debuglink or not check_debuglink)
+else:
+sane = (has_debuglink or not check_debuglink)
+
+if not sane:
+package_qa_add_message(messages, "debug-linkstyle", "No or invalid 
link type in: '%s'" % path)
 
 QAPATHTEST[buildpaths] = "package_qa_check_buildpaths"
 def package_qa_check_buildpaths(path, name, d, elf, messages):
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 7dc759699f..41b50c199d 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -345,7 +345,7 @@ def 
parse_debugsources_from_dwarfsrcfiles_output(dwarfsrcfiles_output):
 return debugfiles.keys()
 
 
-def splitdebuginfo(file, debugfile, debugsrcdir, sourcefile, d):
+def splitdebuginfo(file, debugfile, debugsrcdir, sourcefile, create_debuglink, 
d):
 # Function to split a single file into two components, one is the stripped
 # target system binary, the other contains any debugging information. The
 # two files are linked to reference each other.
@@ -390,10 +390,11 @@ def splitdebuginfo(file, debugfile, debugsrcdir, 
sourcefile, d):
 bb.fatal("objcopy failed with exit code %s (cmd was %s)%s" % (retval, 
cmd, ":\n%s" % output if output else ""))
 
 # Set the debuglink to have the view of the file path on the target
-cmd = "'%s' --add-gnu-debuglink='%s' '%s'" % (objcopy, debugfile, file)
-(retval, output) = oe.utils.getstatusoutput(cmd)
-if retval:
-

Re: [OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

2018-01-10 Thread wenzong fan



On 01/10/2018 01:01 AM, Patrick Ohly wrote:

On Fri, 2018-01-05 at 01:07 +, Fan, Wenzong wrote:

It works and will override the labels of home dir that SELinux
applied, that's the issue.

For SELinux enabled system, the user's home dir should have lavel
'user_home_dir_t' instead of 'etc_t', it prevents users from creating
files in their home dir.


Sounds like the "copy xattr" function needs to become a bit smarter: it
needs to understand some of the semantic involved and skip those
SELinux xattrs that are always meant to be set dynamically by the
running kernel.

Wenzong, which xattrs are those? Do you agree with the proposed
solution?


The xattr for selinux is "security.selinux":

$ getfattr -n security.selinux /home/t1
security.selinux="user_u:object_r:user_home_dir_t:s0-s15:c0.c1023"

I think the "attr_copy_file()" is doing right thing, but it should be 
used in a limited situation, such as only for Smack ...


Thanks
Wenzong



Jose, can you look into updating your patch accordingly?


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


[OE-core] [PATCH] xf86-video-intel: enable graphic and audio support for CFL-S Sku

2018-01-10 Thread Liwei Song
Add PCI IDs for Coffeelake S Skus to enalbe Graphic and audio
support.

Signed-off-by: Liwei Song 
---
 .../0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch   | 116 +
 .../xorg-driver/xf86-video-intel_git.bb|   1 +
 2 files changed, 117 insertions(+)
 create mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch

diff --git 
a/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch
 
b/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch
new file mode 100644
index ..b7ed8d40df80
--- /dev/null
+++ 
b/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch
@@ -0,0 +1,116 @@
+From 96d4e8e7b8a699f0ef77fa7b210d4de5f1c703d0 Mon Sep 17 00:00:00 2001
+From: Liwei Song 
+Date: Wed, 22 Nov 2017 08:59:03 +
+Subject: [PATCH] Add Coffeelake PCI IDs for S Skus
+
+Add the Coffeelake PCI IDs based on the following kernel patches:
+
+commit b056f8f3d6b900e8afd19f312719160346d263b4
+Author: Anusha Srivatsa 
+Date:   Thu Jun 8 16:41:05 2017 -0700
+
+drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.
+
+Upstream-Status: Submitted [intel-...@lists.freedesktop.org]
+
+Signed-off-by: Liwei Song 
+---
+ src/i915_pciids.h |  7 +++
+ src/intel_module.c| 13 +
+ src/sna/gen9_render.c | 12 
+ 3 files changed, 32 insertions(+)
+
+diff --git a/src/i915_pciids.h b/src/i915_pciids.h
+index 0370f830c541..11ccfa9c047a 100644
+--- a/src/i915_pciids.h
 b/src/i915_pciids.h
+@@ -340,4 +340,11 @@
+   INTEL_VGA_DEVICE(0x3184, info), \
+   INTEL_VGA_DEVICE(0x3185, info)
+ 
++#define INTEL_CFL_S_IDS(info) \
++  INTEL_VGA_DEVICE(0x3E90, info), /* SRV GT1 */ \
++  INTEL_VGA_DEVICE(0x3E93, info), /* SRV GT1 */ \
++  INTEL_VGA_DEVICE(0x3E91, info), /* SRV GT2 */ \
++  INTEL_VGA_DEVICE(0x3E92, info), /* SRV GT2 */ \
++  INTEL_VGA_DEVICE(0x3E96, info)  /* SRV GT2 */
++
+ #endif /* _I915_PCIIDS_H */
+diff --git a/src/intel_module.c b/src/intel_module.c
+index 6b04857e2853..4827a67255f0 100644
+--- a/src/intel_module.c
 b/src/intel_module.c
+@@ -138,6 +138,10 @@ static const struct intel_device_info 
intel_geminilake_info = {
+   .gen = 0113,
+ };
+ 
++static const struct intel_device_info intel_coffeelake_info = {
++  .gen = 0114,
++};
++
+ static const SymTabRec intel_chipsets[] = {
+   {PCI_CHIP_I810, "i810"},
+   {PCI_CHIP_I810_DC100,   "i810-dc100"},
+@@ -303,6 +307,13 @@ static const SymTabRec intel_chipsets[] = {
+   {0x5916, "HD Graphics 620"},
+   {0x591E, "HD Graphics 615"},
+ 
++  /*Coffeelake*/
++  {0x3E90, "HD Graphics"},
++  {0x3E93, "HD Graphics"},
++  {0x3E91, "HD Graphics"},
++  {0x3E92, "HD Graphics"},
++  {0x3E96, "HD Graphics"},
++
+   /* When adding new identifiers, also update:
+* 1. intel_identify()
+* 2. man/intel.man
+@@ -368,6 +379,8 @@ static const struct pci_id_match intel_device_match[] = {
+ 
+   INTEL_GLK_IDS(_geminilake_info),
+ 
++  INTEL_CFL_S_IDS(_coffeelake_info),
++
+   INTEL_VGA_DEVICE(PCI_MATCH_ANY, _generic_info),
+ #endif
+ 
+diff --git a/src/sna/gen9_render.c b/src/sna/gen9_render.c
+index e5f12c723956..7f49052c5ec1 100644
+--- a/src/sna/gen9_render.c
 b/src/sna/gen9_render.c
+@@ -245,6 +245,11 @@ static const struct gt_info glk_gt_info = {
+   .urb = { .max_vs_entries = 320 },
+ };
+ 
++static const struct gt_info cfl_gt_info = {
++  .name = "Coffeelake (gen9)",
++  .urb = { .max_vs_entries = 960 },
++};
++
+ static bool is_skl(struct sna *sna)
+ {
+   return sna->kgem.gen == 0110;
+@@ -265,6 +270,11 @@ static bool is_glk(struct sna *sna)
+   return sna->kgem.gen == 0113;
+ }
+ 
++static bool is_cfl(struct sna *sna)
++{
++  return sna->kgem.gen == 0114;
++}
++
+ 
+ static inline bool too_large(int width, int height)
+ {
+@@ -4040,6 +4050,8 @@ static bool gen9_render_setup(struct sna *sna)
+   state->info = _gt_info;
+   if (is_glk(sna))
+   state->info = _gt_info;
++  if (is_cfl(sna))
++  state->info = _gt_info;
+ 
+   sna_static_stream_init();
+ 
+-- 
+2.13.3
+
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb 
b/meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb
index 138dfddcf34a..9aff9d8c2291 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-intel_git.bb
@@ -16,6 +16,7 @@ S = "${WORKDIR}/git"
 SRC_URI = "git://anongit.freedesktop.org/xorg/driver/xf86-video-intel \
file://disable-x11-dri3.patch \
file://always_include_xorg_server.h.patch \
+   file://0001-Add-Coffeelake-PCI-IDs-for-S-Skus.patch 

[OE-core] ✗ patchtest: failure for gcc: add flex-native explicit dependency

2018-01-10 Thread Patchwork
== Series Details ==

Series: gcc: add flex-native explicit dependency
Revision: 1
URL   : https://patchwork.openembedded.org/series/10465/
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 e9dfe7eb7f)



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