[OE-core] [PATCH V2] libcomps: Fix/optimize building with clang

[Khem Raj]

Signed-off-by: Khem Raj 
---
 ...-Make-__comps_objmrtree_all-static-inline.patch | 35 ++
 meta/recipes-devtools/libcomps/libcomps_git.bb |  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 
meta/recipes-devtools/libcomps/libcomps/0001-Make-__comps_objmrtree_all-static-inline.patch

diff --git 
a/meta/recipes-devtools/libcomps/libcomps/0001-Make-__comps_objmrtree_all-static-inline.patch
 
b/meta/recipes-devtools/libcomps/libcomps/0001-Make-__comps_objmrtree_all-static-inline.patch
new file mode 100644
index 00..88469fb331
--- /dev/null
+++ 
b/meta/recipes-devtools/libcomps/libcomps/0001-Make-__comps_objmrtree_all-static-inline.patch
@@ -0,0 +1,35 @@
+From 91a324f8771818b81017fdf4daaad0c8c4b6987c Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Mon, 20 Mar 2017 11:38:54 -0700
+Subject: [PATCH] Make __comps_objmrtree_all() static inline
+
+This helps compilers to scope the symbol correctly
+and apply the inlining optimizations, clang e.g.
+emits the functions and calls in code which is
+suboptimal, therefore give a little help to compiler
+this function is not used anywhere else to have
+a global scope.
+
+Upstream-Status: Pending
+
+Signed-off-by: Khem Raj 
+---
+ libcomps/src/comps_objmradix.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libcomps/src/comps_objmradix.c b/libcomps/src/comps_objmradix.c
+index 9be6648..55f7793 100644
+--- a/libcomps/src/comps_objmradix.c
 b/libcomps/src/comps_objmradix.c
+@@ -604,7 +604,7 @@ inline void comps_objmrtree_pair_destroy_v(void * pair) {
+ free(pair);
+ }
+ 
+-inline COMPS_HSList* __comps_objmrtree_all(COMPS_ObjMRTree * rt, char 
keyvalpair) {
++static inline COMPS_HSList* __comps_objmrtree_all(COMPS_ObjMRTree * rt, char 
keyvalpair) {
+ COMPS_HSList *to_process, *ret;
+ COMPS_HSListItem *hsit, *oldit;
+ size_t x;
+-- 
+2.12.0
+
diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb 
b/meta/recipes-devtools/libcomps/libcomps_git.bb
index 8ff13b26b6..db4481bc8c 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_git.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 SRC_URI = "git://github.com/rpm-software-management/libcomps.git \
file://0001-Do-not-set-PYTHON_INSTALL_DIR-by-running-python.patch \
file://0002-Set-library-installation-path-correctly.patch \
+   file://0001-Make-__comps_objmrtree_all-static-inline.patch \
"
 
 PV = "0.1.8+git${SRCPV}"
-- 
2.12.0

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

[OE-core] [PATCH] libcomps: Fix/optimize building with clang

[Khem Raj]

Signed-off-by: Khem Raj 
---
 ...-Make-__comps_objmrtree_all-static-inline.patch | 35 ++
 meta/recipes-devtools/libcomps/libcomps_git.bb |  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 
meta/recipes-devtools/libcomps/libcomps/0001-Make-__comps_objmrtree_all-static-inline.patch

diff --git 
a/meta/recipes-devtools/libcomps/libcomps/0001-Make-__comps_objmrtree_all-static-inline.patch
 
b/meta/recipes-devtools/libcomps/libcomps/0001-Make-__comps_objmrtree_all-static-inline.patch
new file mode 100644
index 00..864098e592
--- /dev/null
+++ 
b/meta/recipes-devtools/libcomps/libcomps/0001-Make-__comps_objmrtree_all-static-inline.patch
@@ -0,0 +1,35 @@
+From 91a324f8771818b81017fdf4daaad0c8c4b6987c Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Mon, 20 Mar 2017 11:38:54 -0700
+Subject: [PATCH] Make __comps_objmrtree_all() static inline
+
+This helps compilers to scope the symbol correctly
+and apply the inlining optimizations, clang e.g.
+emits the functions and calls in code which is
+suboptimal, therefore give a little help to compiler
+this function is not used anywhere else to have
+a global scope.
+
+Usptream-Status: Pending
+
+Signed-off-by: Khem Raj 
+---
+ libcomps/src/comps_objmradix.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libcomps/src/comps_objmradix.c b/libcomps/src/comps_objmradix.c
+index 9be6648..55f7793 100644
+--- a/libcomps/src/comps_objmradix.c
 b/libcomps/src/comps_objmradix.c
+@@ -604,7 +604,7 @@ inline void comps_objmrtree_pair_destroy_v(void * pair) {
+ free(pair);
+ }
+ 
+-inline COMPS_HSList* __comps_objmrtree_all(COMPS_ObjMRTree * rt, char 
keyvalpair) {
++static inline COMPS_HSList* __comps_objmrtree_all(COMPS_ObjMRTree * rt, char 
keyvalpair) {
+ COMPS_HSList *to_process, *ret;
+ COMPS_HSListItem *hsit, *oldit;
+ size_t x;
+-- 
+2.12.0
+
diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb 
b/meta/recipes-devtools/libcomps/libcomps_git.bb
index 8ff13b26b6..db4481bc8c 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_git.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 SRC_URI = "git://github.com/rpm-software-management/libcomps.git \
file://0001-Do-not-set-PYTHON_INSTALL_DIR-by-running-python.patch \
file://0002-Set-library-installation-path-correctly.patch \
+   file://0001-Make-__comps_objmrtree_all-static-inline.patch \
"
 
 PV = "0.1.8+git${SRCPV}"
-- 
2.12.0

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

Re: [OE-core] [PATCH 0/5] Fix some issues of kernel/image recipes

[Denys Dmytriyenko]

On Tue, Mar 21, 2017 at 01:54:58AM +0100, liu.min...@gmail.com wrote:
> From: Peter Liu 

What version of the patchset is this?


> The changes include:
> kernel.bbclass: fix some incorrect inter-task dependencies
> kernel.bbclass: introduce INITRAMFS_IMAGE_NAME
> kernel.bbclass: handle kernel-vmlinux in KERNEL_IMAGETYPES
> image.bbclass: remove initramfs bundle related code
> kernel-initramfs: add recipe
> 
> Ming Liu (5):
>   kernel.bbclass: fix some incorrect inter-task dependencies
>   kernel.bbclass: introduce INITRAMFS_IMAGE_NAME
>   kernel.bbclass: handle kernel-vmlinux in KERNEL_IMAGETYPES
>   image.bbclass: remove initramfs bundle related code
>   kernel-initramfs: add recipe
> 
>  meta/classes/image.bbclass|  13 
>  meta/classes/kernel-fitimage.bbclass  |  10 +--
>  meta/classes/kernel.bbclass   |  73 +--
>  meta/recipes-kernel/linux/kernel-initramfs.bb | 100 
> ++
>  meta/recipes-kernel/linux/linux-yocto.inc |   1 -
>  5 files changed, 139 insertions(+), 58 deletions(-)
>  create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb
> 
> -- 
> 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] [PATCH 5/5] kernel-initramfs: add recipe

[liu . ming50]

From: Ming Liu 

To implement initramfs bundled kernel packaging.

The kernel images are copied from DEPLOY_DIR_IMAGE, and a list of
packages will be generated according to KERNEL_IMAGETYPES setting.

For instance:
For KERNEL_IMAGETYPES = "bzImage vmlinux"

the generated packages would be:
- kernel-initramfs (Base package, RDEPENDS on kernel-initramfs-image)
- kernel-initramfs-image (Image package, RDEPENDS on all sub images)
- kernel-initramfs-image-bzimage (Contains bzImage image)
- kernel-initramfs-vmlinux (Contains vmlinux image)

This recipe would be skipped if INITRAMFS_IMAGE_BUNDLE or
INITRAMFS_IMAGE is not being set correctly.

Signed-off-by: Ming Liu 
---
 meta/recipes-kernel/linux/kernel-initramfs.bb | 100 ++
 1 file changed, 100 insertions(+)
 create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb

diff --git a/meta/recipes-kernel/linux/kernel-initramfs.bb 
b/meta/recipes-kernel/linux/kernel-initramfs.bb
new file mode 100644
index 000..56002b6
--- /dev/null
+++ b/meta/recipes-kernel/linux/kernel-initramfs.bb
@@ -0,0 +1,100 @@
+SUMMARY = "Initramfs bundled kernel images"
+DESCRIPTION = "When built, it packages initramfs bundled kernel images of the \
+preferred virtual/kernel provider."
+SECTION = "kernel"
+LICENSE = "GPLv2"
+
+inherit linux-kernel-base
+
+# Whilst not a module, this ensures we don't get multilib extended. (which 
would make no sense)
+inherit module-base
+
+S = "${STAGING_KERNEL_DIR}"
+B = "${WORKDIR}/build"
+
+# we dont need the default dependencies.
+INHIBIT_DEFAULT_DEPS = "1"
+
+KERNEL_ALT_IMAGETYPE ??= ""
+KERNEL_IMAGETYPES_append = " vmlinux"
+KERNEL_IMAGETYPE ?= "zImage"
+KERNEL_IMAGEDEST ?= "boot"
+KERNEL_VERSION = "${@['1.0.0', 
get_kernelversion_file('${STAGING_KERNEL_BUILDDIR}')][get_kernelversion_file('${STAGING_KERNEL_BUILDDIR}')
 != None]}"
+KERNEL_PKG_NAME = "${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
+KERNEL_PRIORITY ?= 
"${@int(d.getVar('KERNEL_VERSION').split('-')[0].split('+')[0].split('.')[0]) * 
1 + \
+   
int(d.getVar('KERNEL_VERSION').split('-')[0].split('+')[0].split('.')[1]) * 100 
+ \
+   
int(d.getVar('KERNEL_VERSION').split('-')[0].split('+')[0].split('.')[-1])}"
+
+PACKAGES = "${PN} ${PN}-image"
+
+FILES_${PN} = ""
+FILES_${PN}-image = ""
+RDEPENDS_${PN} = "${PN}-image"
+PKG_${PN} = "${PN}-${KERNEL_PKG_NAME}"
+PKG_${PN}-image = "${PN}-image-${KERNEL_PKG_NAME}"
+RPROVIDES_${PN} += "${PN}-${KERNEL_VERSION}"
+ALLOW_EMPTY_${PN} = "1"
+ALLOW_EMPTY_${PN}-image = "1"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+PACKAGES_DYNAMIC = "^kernel-initramfs-image-.*"
+
+python __anonymous () {
+# Skip processing of this recipe if INITRAMFS_IMAGE or 
INITRAMFS_IMAGE_BUNDLE
+# is not set correctly, to avoid generating only empty packages which makes
+# no sense.
+if not d.getVar('INITRAMFS_IMAGE') or d.getVar('INITRAMFS_IMAGE_BUNDLE') 
!= '1':
+raise bb.parse.SkipPackage("Set INITRAMFS_IMAGE and 
INITRAMFS_IMAGE_BUNDLE to enable it")
+
+# Merge KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES
+types = set((d.getVar('KERNEL_IMAGETYPES') or "").split())
+types.add(d.getVar('KERNEL_IMAGETYPE') or "")
+types.add(d.getVar('KERNEL_ALT_IMAGETYPE') or "")
+types = ' '.join(sorted(types)).strip()
+d.setVar('KERNEL_IMAGETYPES', types)
+
+for type in types.split():
+pn = d.getVar('PN')
+imagedest = d.getVar('KERNEL_IMAGEDEST')
+if type == "vmlinux":
+typelower = type.lower()
+else:
+typelower = "image-%s" % type.lower()
+
+d.appendVar('PACKAGES', ' %s-%s' % (pn, typelower))
+if type != 'vmlinux' or d.getVar('KERNEL_IMAGETYPE') == 'vmlinux':
+d.appendVar('RDEPENDS_%s-image' % pn, ' %s-%s' % (pn, typelower))
+
+d.setVar('FILES_%s-%s' % (pn, typelower), 
'/%s/%s-initramfs-${KERNEL_VERSION}' % (imagedest, type))
+d.setVar('PKG_%s-%s' % ( pn, typelower), '%s-%s-${KERNEL_PKG_NAME}' % 
(pn, typelower))
+
+priority = d.getVar('KERNEL_PRIORITY')
+postinst = '#!/bin/sh\nupdate-alternatives --install /%s/%s-initramfs 
%s-initramfs %s-initramfs-${KERNEL_VERSION} %s || true\n' % (imagedest, type, 
type, type, priority)
+d.setVar('pkg_postinst_%s-%s' % (pn, typelower), postinst)
+
+postrm = '#!/bin/sh\nupdate-alternatives --remove %s-initramfs 
%s-initramfs-${KERNEL_VERSION} || true\n' % (type, type)
+d.setVar('pkg_postrm_%s-%s' % (pn, typelower), postrm)
+}
+
+# Need the output of deploy.
+do_install[depends] += "virtual/kernel:do_deploy"
+
+# We only need the packaging tasks - disable the rest
+do_fetch[noexec] = "1"
+do_unpack[noexec] = "1"
+do_patch[noexec] = "1"
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+do_populate_sysroot[noexec] = "1"
+
+do_install() {
+   if [ ! -z "${INITRAMFS_IMAGE}" -a 

[OE-core] [PATCH 1/5] kernel.bbclass: fix some incorrect inter-task dependencies

[liu . ming50]

From: Ming Liu 

- Move the addtask statment that kernel_link_images needs run after
  do_compile from linux-yocto.inc to kernel.bbclass. Or else the recipes
  that inheriting kernel.bbclass might run into implicit dependency
  issues.
- Fix a typo, "addtask do_strip" should be "addtask strip".
- Remove some redundant addtask statments, when "addtask A after B" is
  set, then "addtask B before A" is not needed.

Signed-off-by: Ming Liu 
---
 meta/classes/kernel.bbclass   | 5 +++--
 meta/recipes-kernel/linux/linux-yocto.inc | 1 -
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 1e0646a..d39fa24 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -538,6 +538,7 @@ do_kernel_link_images() {
ln -sf ../../../vmlinuz.bin
fi
 }
+addtask kernel_link_images after do_compile
 
 do_strip() {
if [ -n "${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}" ]; then
@@ -566,7 +567,7 @@ do_strip() {
 }
 do_strip[dirs] = "${B}"
 
-addtask do_strip before do_sizecheck after do_kernel_link_images
+addtask strip before do_sizecheck after do_kernel_link_images
 
 # Support checking the kernel size since some kernels need to reside in 
partitions
 # with a fixed length or there is a limit in transferring the kernel to memory
@@ -586,7 +587,7 @@ do_sizecheck() {
 }
 do_sizecheck[dirs] = "${B}"
 
-addtask sizecheck before do_install after do_strip
+addtask sizecheck before do_install
 
 KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
 # Don't include the DATETIME variable in the sstate package signatures
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
b/meta/recipes-kernel/linux/linux-yocto.inc
index 556546f..637506a 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -65,6 +65,5 @@ do_install_append(){
 
 # extra tasks
 addtask kernel_version_sanity_check after do_kernel_metadata 
do_kernel_checkout before do_compile
-addtask kernel_link_images after do_compile before do_strip
 addtask validate_branches before do_patch after do_kernel_checkout
 addtask kernel_configcheck after do_configure before do_compile
-- 
2.7.4

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

[OE-core] [PATCH 4/5] image.bbclass: remove initramfs bundle related code

[liu . ming50]

From: Ming Liu 

The original purpose of these code was to repackage initramfs bundled
kernel before image do_build, but it does not really work because the
initramfs bundled kernel images are not packaged at all after commit
a49569e3a7534779bbe3f01a0647fd076c95798d:
[ kernel.bbclass: do not copy bundled initramfs to /boot ]

Signed-off-by: Ming Liu 
---
 meta/classes/image.bbclass | 13 -
 1 file changed, 13 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 405fd73..bc00884 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -184,10 +184,6 @@ python () {
 d.setVar('IMAGE_FEATURES', ' '.join(sorted(list(remain_features
 
 check_image_features(d)
-initramfs_image = d.getVar('INITRAMFS_IMAGE') or ""
-if initramfs_image != "":
-d.appendVarFlag('do_build', 'depends', " %s:do_bundle_initramfs" %  
d.getVar('PN'))
-d.appendVarFlag('do_bundle_initramfs', 'depends', " 
%s:do_image_complete" % initramfs_image)
 }
 
 IMAGE_CLASSES += "image_types"
@@ -608,12 +604,3 @@ do_packagedata[noexec] = "1"
 do_package_write_ipk[noexec] = "1"
 do_package_write_deb[noexec] = "1"
 do_package_write_rpm[noexec] = "1"
-
-# Allow the kernel to be repacked with the initramfs and boot image file as a 
single file
-do_bundle_initramfs[depends] += "virtual/kernel:do_bundle_initramfs"
-do_bundle_initramfs[nostamp] = "1"
-do_bundle_initramfs[noexec] = "1"
-do_bundle_initramfs () {
-   :
-}
-addtask bundle_initramfs after do_image_complete
-- 
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] kernel.bbclass: handle kernel-vmlinux in KERNEL_IMAGETYPES

[liu . ming50]

From: Ming Liu 

There is a mess after KERNEL_IMAGETYPES was introduced in commit 849b67b2:
[ kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time ]

There are two packages both providing vmlinux image if 'vmlinux' is set in
KERNEL_IMAGETYPES, they are kernel-vmlinux and kernel-image-vmlinux, to
let them to be able to coexist, kernel-image-vmlinux was set to empty
allowable, but its postinst/postrm scripts still remain trying to install/rm
a update-alternatives link to /boot/vmlinux-${KERNEL_VERSION_NAME} but that
file is actually being provided by the other package kernel-vmlinux.

Fixed this mess by appending vmlinux to KERNEL_IMAGETYPES and process it
in anonymous python function. It would not change the original behavior,
all the generated packages would be same with before except that the
ALLOW_EMPTY variable, it is removed in this patch.

Signed-off-by: Ming Liu 
---
 meta/classes/kernel.bbclass | 47 +++--
 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8feb2c1..425f6cb 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -14,6 +14,7 @@ OE_TERMINAL_EXPORTS += "KBUILD_OUTPUT"
 # we include gcc above, we dont need virtual/libc
 INHIBIT_DEFAULT_DEPS = "1"
 
+KERNEL_IMAGETYPES_append = " vmlinux"
 KERNEL_IMAGETYPE ?= "zImage"
 INITRAMFS_IMAGE ?= ""
 INITRAMFS_IMAGE_NAME ?= "${@['${INITRAMFS_IMAGE}-${MACHINE}', 
''][d.getVar('INITRAMFS_IMAGE') == '']}"
@@ -35,38 +36,33 @@ python __anonymous () {
 import re
 
 # Merge KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES
-type = d.getVar('KERNEL_IMAGETYPE') or ""
-alttype = d.getVar('KERNEL_ALT_IMAGETYPE') or ""
-types = d.getVar('KERNEL_IMAGETYPES') or ""
-if type not in types.split():
-types = (type + ' ' + types).strip()
-if alttype not in types.split():
-types = (alttype + ' ' + types).strip()
+types = set((d.getVar('KERNEL_IMAGETYPES') or "").split())
+types.add(d.getVar('KERNEL_IMAGETYPE') or "")
+types.add(d.getVar('KERNEL_ALT_IMAGETYPE') or "")
+types = ' '.join(sorted(types)).strip()
 d.setVar('KERNEL_IMAGETYPES', types)
-
-typeformake = re.sub(r'\.gz', '', types)
-d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', typeformake)
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', re.sub(r'\.gz', '', types))
 
 for type in types.split():
-typelower = type.lower()
 imagedest = d.getVar('KERNEL_IMAGEDEST')
+if type == "vmlinux":
+typelower = type.lower()
+else:
+typelower = "image-%s" % type.lower()
 
-d.appendVar('PACKAGES', ' ' + 'kernel-image-' + typelower)
-
-d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest + '/' + 
type + '-${KERNEL_VERSION_NAME}')
-
-d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' + typelower)
-
-d.setVar('PKG_kernel-image-' + typelower, 'kernel-image-' + typelower 
+ '-${KERNEL_VERSION_PKG_NAME}')
+d.appendVar('PACKAGES', ' kernel-%s' % typelower)
+if type != 'vmlinux' or d.getVar('KERNEL_IMAGETYPE') == 'vmlinux':
+d.appendVar('RDEPENDS_kernel-image', ' kernel-%s' % typelower)
 
-d.setVar('ALLOW_EMPTY_kernel-image-' + typelower, '1')
+d.setVar('FILES_kernel-%s' % typelower, 
'/%s/%s-${KERNEL_VERSION_NAME}' % (imagedest, type))
+d.setVar('PKG_kernel-%s' % typelower, 
'kernel-%s-${KERNEL_VERSION_PKG_NAME}' % typelower)
 
 priority = d.getVar('KERNEL_PRIORITY')
-postinst = '#!/bin/sh\n' + 'update-alternatives --install /' + 
imagedest + '/' + type + ' ' + type + ' ' + type + '-${KERNEL_VERSION_NAME} ' + 
priority + ' || true' + '\n'
-d.setVar('pkg_postinst_kernel-image-' + typelower, postinst)
+postinst = '#!/bin/sh\nupdate-alternatives --install /%s/%s %s 
%s-${KERNEL_VERSION_NAME} %s || true\n' % (imagedest, type, type, type, 
priority)
+d.setVar('pkg_postinst_kernel-%s' % typelower, postinst)
 
-postrm = '#!/bin/sh\n' + 'update-alternatives --remove' + ' ' + type + 
' ' + type + '-${KERNEL_VERSION_NAME} || true' + '\n'
-d.setVar('pkg_postrm_kernel-image-' + typelower, postrm)
+postrm = '#!/bin/sh\nupdate-alternatives --remove %s 
%s-${KERNEL_VERSION_NAME} || true\n' % (type, type)
+d.setVar('pkg_postrm_kernel-%s' % typelower, postrm)
 
 image = d.getVar('INITRAMFS_IMAGE')
 if image:
@@ -319,7 +315,6 @@ kernel_do_install() {
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
-   install -m 0644 vmlinux ${D}/boot/vmlinux-${KERNEL_VERSION}
[ -e Module.symvers ] && install -m 0644 Module.symvers 
${D}/boot/Module.symvers-${KERNEL_VERSION}
install -d 

[OE-core] [PATCH 0/5] Fix some issues of kernel/image recipes

[liu . ming50]

From: Peter Liu 

The changes include:
kernel.bbclass: fix some incorrect inter-task dependencies
kernel.bbclass: introduce INITRAMFS_IMAGE_NAME
kernel.bbclass: handle kernel-vmlinux in KERNEL_IMAGETYPES
image.bbclass: remove initramfs bundle related code
kernel-initramfs: add recipe

Ming Liu (5):
  kernel.bbclass: fix some incorrect inter-task dependencies
  kernel.bbclass: introduce INITRAMFS_IMAGE_NAME
  kernel.bbclass: handle kernel-vmlinux in KERNEL_IMAGETYPES
  image.bbclass: remove initramfs bundle related code
  kernel-initramfs: add recipe

 meta/classes/image.bbclass|  13 
 meta/classes/kernel-fitimage.bbclass  |  10 +--
 meta/classes/kernel.bbclass   |  73 +--
 meta/recipes-kernel/linux/kernel-initramfs.bb | 100 ++
 meta/recipes-kernel/linux/linux-yocto.inc |   1 -
 5 files changed, 139 insertions(+), 58 deletions(-)
 create mode 100644 meta/recipes-kernel/linux/kernel-initramfs.bb

-- 
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] kernel.bbclass: introduce INITRAMFS_IMAGE_NAME

[liu . ming50]

From: Ming Liu 

It defaults to ${INITRAMFS_IMAGE}-${MACHINE} if INITRAMFS_IMAGE is not
empty.

This allows the end users to be able to override the initramfs image
name with a customized value.

Signed-off-by: Ming Liu 
---
 meta/classes/kernel-fitimage.bbclass | 10 +-
 meta/classes/kernel.bbclass  | 21 +++--
 2 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index f9702f8..1be9022 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -362,7 +362,7 @@ fitimage_assemble() {
if [ "x${ramdiskcount}" = "x1" ] ; then
# Find and use the first initramfs image archive type we find
for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz cpio; do
-   
initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.${img}"
+   
initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
echo "Using $initramfs_path"
if [ -e "${initramfs_path}" ]; then
fitimage_emit_section_ramdisk ${1} 
"${ramdiskcount}" "${initramfs_path}"
@@ -445,11 +445,11 @@ kernel_do_deploy_append() {
 
if [ -n "${INITRAMFS_IMAGE}" ]; then
echo "Copying fit-image-${INITRAMFS_IMAGE}.its source 
file..."
-   
its_initramfs_base_name="fitImage-its-${INITRAMFS_IMAGE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   
its_initramfs_symlink_name=fitImage-its-${INITRAMFS_IMAGE}-${MACHINE}
+   
its_initramfs_base_name="fitImage-its-${INITRAMFS_IMAGE_NAME}-${PV}-${PR}-${DATETIME}"
+   
its_initramfs_symlink_name=fitImage-its-${INITRAMFS_IMAGE_NAME}
install -m 0644 fit-image-${INITRAMFS_IMAGE}.its 
${DEPLOYDIR}/${its_initramfs_base_name}.its
-   
fit_initramfs_base_name="fitImage-${INITRAMFS_IMAGE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   
fit_initramfs_symlink_name=fitImage-${INITRAMFS_IMAGE}-${MACHINE}
+   
fit_initramfs_base_name="fitImage-${INITRAMFS_IMAGE_NAME}-${PV}-${PR}-${DATETIME}"
+   
fit_initramfs_symlink_name=fitImage-${INITRAMFS_IMAGE_NAME}
install -m 0644 
arch/${ARCH}/boot/fitImage-${INITRAMFS_IMAGE} 
${DEPLOYDIR}/${fit_initramfs_base_name}.bin
fi
 
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index d39fa24..8feb2c1 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -16,6 +16,7 @@ INHIBIT_DEFAULT_DEPS = "1"
 
 KERNEL_IMAGETYPE ?= "zImage"
 INITRAMFS_IMAGE ?= ""
+INITRAMFS_IMAGE_NAME ?= "${@['${INITRAMFS_IMAGE}-${MACHINE}', 
''][d.getVar('INITRAMFS_IMAGE') == '']}"
 INITRAMFS_TASK ?= ""
 INITRAMFS_IMAGE_BUNDLE ?= ""
 
@@ -167,34 +168,34 @@ copy_initramfs() {
# In case the directory is not created yet from the first pass compile:
mkdir -p ${B}/usr
# Find and use the first initramfs image archive type we find
-   rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+   rm -f ${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
for img in cpio cpio.gz cpio.lz4 cpio.lzo cpio.lzma cpio.xz; do
-   if [ -e 
"${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img" ]; then
-   cp 
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ${B}/usr/.
+   if [ -e "${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.$img" ]; 
then
+   cp ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.$img 
${B}/usr/.
case $img in
*gz)
echo "gzip decompressing image"
-   gunzip -f 
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+   gunzip -f ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
break
;;
*lz4)
echo "lz4 decompressing image"
-   lz4 -df 
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+   lz4 -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
break
;;
*lzo)
echo "lzo decompressing image"
-   lzop -df 
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+   lzop -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
break
;;
*lzma)
echo "lzma decompressing image"
-   lzma -df 

[OE-core] [PATCH] libxslt: Add PACKAGECONFIG support

[Vedang Patel]

Some options like python bindings, debug support, crypto are hardcoded
inside the recipe. Change that to make those option configurable using
PACKAGECONFIG.

Signed-off-by: Vedang Patel 
---
 meta/recipes-support/libxslt/libxslt_1.1.29.bb | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/libxslt/libxslt_1.1.29.bb 
b/meta/recipes-support/libxslt/libxslt_1.1.29.bb
index be747e608d9d..d362118aa307 100644
--- a/meta/recipes-support/libxslt/libxslt_1.1.29.bb
+++ b/meta/recipes-support/libxslt/libxslt_1.1.29.bb
@@ -22,7 +22,7 @@ S = "${WORKDIR}/libxslt-${PV}"
 
 BINCONFIG = "${bindir}/xslt-config"
 
-inherit autotools pkgconfig binconfig-disabled lib_package
+inherit autotools pkgconfig binconfig-disabled lib_package 
distutils-common-base
 
 # We don't DEPEND on binutils for ansidecl.h so ensure we don't use the header
 do_configure_prepend () {
@@ -33,7 +33,12 @@ do_configure_prepend () {
touch ${S}/doc/xsltproc.1
 }
 
-EXTRA_OECONF = "--without-python --without-debug --without-mem-debug 
--without-crypto"
+PACKAGECONFIG ??= "python libxslt-debug libxslt-mem-debug libxslt-crypto"
+PACKAGECONFIG[libxslt-python] = "--with-python=${PYTHON_BASE_VERSION}, 
--without-python"
+PACKAGECONFIG[libxslt-debug] = "--with-debug, --without-debug"
+PACKAGECONFIG[libxslt-mem-debug] = "--with-mem-debug, --without-mem-debug"
+PACKAGECONFIG[libxslt-crypto] = "--with-crypto, --without-crypto"
+
 # older versions of this recipe had ${PN}-utils
 RPROVIDES_${PN}-bin += "${PN}-utils"
 RCONFLICTS_${PN}-bin += "${PN}-utils"
-- 
2.7.3

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

[OE-core] [PATCH 6/7] scripts/yocto-compat-layer.py: Add option to disable layer autodiscovery

[Aníbal Limón]

Sometimes there is a need to only analyze the layer specified by the
command line, the new option -n will disable autodiscovery of layers
and only will try to test specified layers.

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 17 -
 scripts/yocto-compat-layer.py   |  4 +++-
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index 15dc95d..b8ce771 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -108,20 +108,27 @@ def _detect_layer(layer_path):
 
 return layer
 
-def detect_layers(layer_directories):
+def detect_layers(layer_directories, no_auto):
 layers = []
 
 for directory in layer_directories:
 if directory[-1] == '/':
 directory = directory[0:-1]
 
-for root, dirs, files in os.walk(directory):
-dir_name = os.path.basename(root)
-conf_dir = os.path.join(root, 'conf')
+if no_auto:
+conf_dir = os.path.join(directory, 'conf')
 if os.path.isdir(conf_dir):
-layer = _detect_layer(root)
+layer = _detect_layer(directory)
 if layer:
 layers.append(layer)
+else:
+for root, dirs, files in os.walk(directory):
+dir_name = os.path.basename(root)
+conf_dir = os.path.join(root, 'conf')
+if os.path.isdir(conf_dir):
+layer = _detect_layer(root)
+if layer:
+layers.append(layer)
 
 return layers
 
diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index b96f3ca..b4de84a 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -47,6 +47,8 @@ def main():
 help='Layer to test compatibility with Yocto Project')
 parser.add_argument('-o', '--output-log',
 help='File to output log (optional)', action='store')
+parser.add_argument('-n', '--no-auto', help='Disable auto layer discovery',
+action='store_true')
 parser.add_argument('-d', '--debug', help='Enable debug output',
 action='store_true')
 parser.add_argument('-q', '--quiet', help='Print only errors',
@@ -74,7 +76,7 @@ def main():
 builddir = os.environ['BUILDDIR']
 bblayersconf = os.path.join(builddir, 'conf', 'bblayers.conf')
 
-layers = detect_layers(args.layers)
+layers = detect_layers(args.layers, args.no_auto)
 if not layers:
 logger.error("Fail to detect layers")
 return 1
-- 
2.1.4

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

[OE-core] [PATCH 7/7] scripts/yocto-compat-layer.py: Handle layer dependencies when test

[Aníbal Limón]

If some layer depends on other tries to find layer dependency, if the
layer dependency isn't found avoid to test the layer and notice the
user.

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 29 -
 scripts/yocto-compat-layer.py   | 21 +
 2 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index b8ce771..435679e 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -132,10 +132,37 @@ def detect_layers(layer_directories, no_auto):
 
 return layers
 
-def add_layer(bblayersconf, layer):
+def _find_layer_depends(depend, layers):
+for layer in layers:
+for collection in layer['collections']:
+if depend == collection:
+return layer
+return None
+
+def add_layer(bblayersconf, layer, layers, logger):
+logger.info('Adding layer %s' % layer['name'])
+
+for collection in layer['collections']:
+for depend in layer['collections'][collection]['depends'].split():
+# core (oe-core) is suppose to be provided
+if depend == 'core':
+continue
+
+layer_depend = _find_layer_depends(depend, layers)
+if not layer_depend:
+logger.error('Layer %s depends on %s and isn\'t found.' % \
+(layer['name'], depend))
+return False
+
+logger.info('Adding layer dependency %s' % layer_depend['name'])
+with open(bblayersconf, 'a+') as f:
+f.write("\nBBLAYERS += \"%s\"\n" % layer_depend['path'])
+
 with open(bblayersconf, 'a+') as f:
 f.write("\nBBLAYERS += \"%s\"\n" % layer['path'])
 
+return True
+
 def get_signatures(builddir, failsafe=False):
 import subprocess
 import re
diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index b4de84a..9e74033 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -116,6 +116,7 @@ def main():
 td['sigs'] = get_signatures(td['builddir'])
 logger.info('')
 
+layers_tested = 0
 for layer in layers:
 if layer['type'] == LayerType.ERROR_NO_LAYER_CONF or \
 layer['type'] == LayerType.ERROR_BSP_DISTRO:
@@ -123,16 +124,20 @@ def main():
 
 shutil.copyfile(bblayersconf + '.backup', bblayersconf)
 
-add_layer(bblayersconf, layer)
+if not add_layer(bblayersconf, layer, layers, logger):
+continue
+
 result = test_layer_compatibility(td, layer)
 results[layer['name']] = result
-
-logger.info('')
-logger.info('Summary of results:')
-logger.info('')
-for layer_name in results:
-logger.info('%s ... %s' % (layer_name, 'PASS' if \
-results[layer_name].wasSuccessful() else 'FAIL'))
+layers_tested = layers_tested + 1
+
+if layers_tested:
+logger.info('')
+logger.info('Summary of results:')
+logger.info('')
+for layer_name in results:
+logger.info('%s ... %s' % (layer_name, 'PASS' if \
+results[layer_name].wasSuccessful() else 'FAIL'))
 
 cleanup_bblayers(None, None)
 
-- 
2.1.4

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

[OE-core] [PATCH 5/7] scripts/lib/compatlayer: Remove require of meta- in layer dir name

[Aníbal Limón]

The layers isn't required to have a dirctory name start with meta-
so remove the validation.

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index 888d303..15dc95d 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -118,7 +118,7 @@ def detect_layers(layer_directories):
 for root, dirs, files in os.walk(directory):
 dir_name = os.path.basename(root)
 conf_dir = os.path.join(root, 'conf')
-if dir_name.startswith('meta-') and os.path.isdir(conf_dir):
+if os.path.isdir(conf_dir):
 layer = _detect_layer(root)
 if layer:
 layers.append(layer)
-- 
2.1.4

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

[OE-core] [PATCH 3/7] scripts/yocto-compat-layer.py: Make output log argument optional

[Aníbal Limón]

Only create a log file when --output-log option is specified, since
logger is dumping to stdout by default is better to let the user
decide if a log needs to be created.

[YOCTO #11160]

Signed-off-by: Aníbal Limón 
---
 scripts/yocto-compat-layer.py | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index 8996fff..b96f3ca 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -26,9 +26,6 @@ from compatlayer import LayerType, detect_layers, add_layer, 
get_signatures
 from oeqa.utils.commands import get_bb_vars
 
 PROGNAME = 'yocto-compat-layer'
-DEFAULT_OUTPUT_LOG = '%s-%s.log' % (PROGNAME,
-time.strftime("%Y%m%d%H%M%S"))
-OUTPUT_LOG_LINK = "%s.log" % PROGNAME
 CASES_PATHS = [os.path.join(os.path.abspath(os.path.dirname(__file__)),
 'lib', 'compatlayer', 'cases')]
 logger = scriptutils.logger_create(PROGNAME, stream=sys.stdout)
@@ -49,9 +46,7 @@ def main():
 parser.add_argument('layers', metavar='LAYER_DIR', nargs='+',
 help='Layer to test compatibility with Yocto Project')
 parser.add_argument('-o', '--output-log',
-help='Output log default: %s' % DEFAULT_OUTPUT_LOG,
-action='store', default=DEFAULT_OUTPUT_LOG)
-
+help='File to output log (optional)', action='store')
 parser.add_argument('-d', '--debug', help='Enable debug output',
 action='store_true')
 parser.add_argument('-q', '--quiet', help='Print only errors',
@@ -63,16 +58,14 @@ def main():
 
 args = parser.parse_args()
 
-fh = logging.FileHandler(args.output_log)
-fh.setFormatter(logging.Formatter("%(levelname)s: %(message)s"))
-logger.addHandler(fh)
+if args.output_log:
+fh = logging.FileHandler(args.output_log)
+fh.setFormatter(logging.Formatter("%(levelname)s: %(message)s"))
+logger.addHandler(fh)
 if args.debug:
 logger.setLevel(logging.DEBUG)
 elif args.quiet:
 logger.setLevel(logging.ERROR)
-if os.path.exists(OUTPUT_LOG_LINK):
-os.unlink(OUTPUT_LOG_LINK)
-os.symlink(args.output_log, OUTPUT_LOG_LINK)
 
 if not 'BUILDDIR' in os.environ:
 logger.error("You must source the environment before run this script.")
-- 
2.1.4

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

[OE-core] [PATCH 2/7] scripts/yocto-compat-layer.py: Dump log to stdout instead of stderr

[Aníbal Limón]

The common unix tools uses stdout as standard for log output, by default
python logging uses stderr if not stream is specified.

[YOCTO #11160]

Signed-off-by: Aníbal Limón 
---
 scripts/yocto-compat-layer.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index 09dc5bf..8996fff 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -31,7 +31,7 @@ DEFAULT_OUTPUT_LOG = '%s-%s.log' % (PROGNAME,
 OUTPUT_LOG_LINK = "%s.log" % PROGNAME
 CASES_PATHS = [os.path.join(os.path.abspath(os.path.dirname(__file__)),
 'lib', 'compatlayer', 'cases')]
-logger = scriptutils.logger_create(PROGNAME)
+logger = scriptutils.logger_create(PROGNAME, stream=sys.stdout)
 
 def test_layer_compatibility(td, layer):
 from compatlayer.context import CompatLayerTestContext
-- 
2.1.4

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

[OE-core] [PATCH 4/7] scripts/compatlayer: Add exclude of meta-world-pkgdata on get_signatures

[Aníbal Limón]

The meta-world-pkgdata recipe can be modified when a layer is added
may be can add recipes to world target, so exclude by default.

[YOCTO #11162]

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index a7eb862..888d303 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -133,6 +133,11 @@ def get_signatures(builddir, failsafe=False):
 import subprocess
 import re
 
+# some recipes needs to be excluded like meta-world-pkgdata
+# because a layer can add recipes to a world build so signature
+# will be change
+exclude_recipes = ('meta-world-pkgdata',)
+
 sigs = {}
 
 cmd = 'bitbake '
@@ -153,6 +158,15 @@ def get_signatures(builddir, failsafe=False):
 line = line.strip()
 s = sig_regex.match(line)
 if s:
+exclude = False
+for er in exclude_recipes:
+(recipe, task) = s.group('task').split(':')
+if er == recipe:
+exclude = True
+break
+if exclude:
+continue
+
 sigs[s.group('task')] = s.group('hash')
 
 if not sigs:
-- 
2.1.4

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

[OE-core] [PATCH 1/7] scriptutils: Add support for specify stream on logger_create

[Aníbal Limón]

It is a good idea to let the script to choose what stream wants
to dump the logging output.

[YOCTO #11160]

Signed-off-by: Aníbal Limón 
---
 scripts/lib/scriptutils.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/scriptutils.py b/scripts/lib/scriptutils.py
index 4233783..4ccbe5c 100644
--- a/scripts/lib/scriptutils.py
+++ b/scripts/lib/scriptutils.py
@@ -22,9 +22,9 @@ import glob
 import argparse
 import subprocess
 
-def logger_create(name):
+def logger_create(name, stream=None):
 logger = logging.getLogger(name)
-loggerhandler = logging.StreamHandler()
+loggerhandler = logging.StreamHandler(stream=stream)
 loggerhandler.setFormatter(logging.Formatter("%(levelname)s: %(message)s"))
 logger.addHandler(loggerhandler)
 logger.setLevel(logging.INFO)
-- 
2.1.4

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

[OE-core] [PATCH 2/3] scripts/yocto-compat-layer.py: Add option to disable layer autodiscovery

[Aníbal Limón]

Sometimes there is a need to only analyze the layer specified by the
command line, the new option -n will disable autodiscovery of layers
and only will try to test specified layers.

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 17 -
 scripts/yocto-compat-layer.py   |  4 +++-
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index 15dc95d..b8ce771 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -108,20 +108,27 @@ def _detect_layer(layer_path):
 
 return layer
 
-def detect_layers(layer_directories):
+def detect_layers(layer_directories, no_auto):
 layers = []
 
 for directory in layer_directories:
 if directory[-1] == '/':
 directory = directory[0:-1]
 
-for root, dirs, files in os.walk(directory):
-dir_name = os.path.basename(root)
-conf_dir = os.path.join(root, 'conf')
+if no_auto:
+conf_dir = os.path.join(directory, 'conf')
 if os.path.isdir(conf_dir):
-layer = _detect_layer(root)
+layer = _detect_layer(directory)
 if layer:
 layers.append(layer)
+else:
+for root, dirs, files in os.walk(directory):
+dir_name = os.path.basename(root)
+conf_dir = os.path.join(root, 'conf')
+if os.path.isdir(conf_dir):
+layer = _detect_layer(root)
+if layer:
+layers.append(layer)
 
 return layers
 
diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index b96f3ca..b4de84a 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -47,6 +47,8 @@ def main():
 help='Layer to test compatibility with Yocto Project')
 parser.add_argument('-o', '--output-log',
 help='File to output log (optional)', action='store')
+parser.add_argument('-n', '--no-auto', help='Disable auto layer discovery',
+action='store_true')
 parser.add_argument('-d', '--debug', help='Enable debug output',
 action='store_true')
 parser.add_argument('-q', '--quiet', help='Print only errors',
@@ -74,7 +76,7 @@ def main():
 builddir = os.environ['BUILDDIR']
 bblayersconf = os.path.join(builddir, 'conf', 'bblayers.conf')
 
-layers = detect_layers(args.layers)
+layers = detect_layers(args.layers, args.no_auto)
 if not layers:
 logger.error("Fail to detect layers")
 return 1
-- 
2.1.4

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

[OE-core] [PATCH 3/3] scripts/yocto-compat-layer.py: Handle layer dependencies when test

[Aníbal Limón]

If some layer depends on other tries to find layer dependency, if the
layer dependency isn't found avoid to test the layer and notice the
user.

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 29 -
 scripts/yocto-compat-layer.py   | 21 +
 2 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index b8ce771..435679e 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -132,10 +132,37 @@ def detect_layers(layer_directories, no_auto):
 
 return layers
 
-def add_layer(bblayersconf, layer):
+def _find_layer_depends(depend, layers):
+for layer in layers:
+for collection in layer['collections']:
+if depend == collection:
+return layer
+return None
+
+def add_layer(bblayersconf, layer, layers, logger):
+logger.info('Adding layer %s' % layer['name'])
+
+for collection in layer['collections']:
+for depend in layer['collections'][collection]['depends'].split():
+# core (oe-core) is suppose to be provided
+if depend == 'core':
+continue
+
+layer_depend = _find_layer_depends(depend, layers)
+if not layer_depend:
+logger.error('Layer %s depends on %s and isn\'t found.' % \
+(layer['name'], depend))
+return False
+
+logger.info('Adding layer dependency %s' % layer_depend['name'])
+with open(bblayersconf, 'a+') as f:
+f.write("\nBBLAYERS += \"%s\"\n" % layer_depend['path'])
+
 with open(bblayersconf, 'a+') as f:
 f.write("\nBBLAYERS += \"%s\"\n" % layer['path'])
 
+return True
+
 def get_signatures(builddir, failsafe=False):
 import subprocess
 import re
diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index b4de84a..9e74033 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -116,6 +116,7 @@ def main():
 td['sigs'] = get_signatures(td['builddir'])
 logger.info('')
 
+layers_tested = 0
 for layer in layers:
 if layer['type'] == LayerType.ERROR_NO_LAYER_CONF or \
 layer['type'] == LayerType.ERROR_BSP_DISTRO:
@@ -123,16 +124,20 @@ def main():
 
 shutil.copyfile(bblayersconf + '.backup', bblayersconf)
 
-add_layer(bblayersconf, layer)
+if not add_layer(bblayersconf, layer, layers, logger):
+continue
+
 result = test_layer_compatibility(td, layer)
 results[layer['name']] = result
-
-logger.info('')
-logger.info('Summary of results:')
-logger.info('')
-for layer_name in results:
-logger.info('%s ... %s' % (layer_name, 'PASS' if \
-results[layer_name].wasSuccessful() else 'FAIL'))
+layers_tested = layers_tested + 1
+
+if layers_tested:
+logger.info('')
+logger.info('Summary of results:')
+logger.info('')
+for layer_name in results:
+logger.info('%s ... %s' % (layer_name, 'PASS' if \
+results[layer_name].wasSuccessful() else 'FAIL'))
 
 cleanup_bblayers(None, None)
 
-- 
2.1.4

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

[OE-core] [PATCH 1/3] scripts/lib/compatlayer: Remove require of meta- in layer dir name

[Aníbal Limón]

The layers isn't required to have a dirctory name start with meta-
so remove the validation.

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index 888d303..15dc95d 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -118,7 +118,7 @@ def detect_layers(layer_directories):
 for root, dirs, files in os.walk(directory):
 dir_name = os.path.basename(root)
 conf_dir = os.path.join(root, 'conf')
-if dir_name.startswith('meta-') and os.path.isdir(conf_dir):
+if os.path.isdir(conf_dir):
 layer = _detect_layer(root)
 if layer:
 layers.append(layer)
-- 
2.1.4

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

[OE-core] [PATCH] scripts/compatlayer: Add exclude of meta-world-pkgdata on get_signatures

[Aníbal Limón]

The meta-world-pkgdata recipe can be modified when a layer is added
may be can add recipes to world target, so exclude by default.

[YOCTO #11162]

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index a7eb862..888d303 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -133,6 +133,11 @@ def get_signatures(builddir, failsafe=False):
 import subprocess
 import re
 
+# some recipes needs to be excluded like meta-world-pkgdata
+# because a layer can add recipes to a world build so signature
+# will be change
+exclude_recipes = ('meta-world-pkgdata',)
+
 sigs = {}
 
 cmd = 'bitbake '
@@ -153,6 +158,15 @@ def get_signatures(builddir, failsafe=False):
 line = line.strip()
 s = sig_regex.match(line)
 if s:
+exclude = False
+for er in exclude_recipes:
+(recipe, task) = s.group('task').split(':')
+if er == recipe:
+exclude = True
+break
+if exclude:
+continue
+
 sigs[s.group('task')] = s.group('hash')
 
 if not sigs:
-- 
2.1.4

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

[OE-core] ovmf fails to build with musl (was: Re: [PATCH 5/6] musl: Update to latest)

[Patrick Ohly]

On Mon, 2017-03-20 at 07:43 -0700, Khem Raj wrote:
> On Mon, Mar 20, 2017 at 1:32 AM, Jussi Kukkonen
>  wrote:
> >
> > On 15 March 2017 at 01:35, Khem Raj  wrote:
> >>
> >> Rich Felker (11):
> >>   fix ld-behavior-dependent crash in ppc64 ldso startup
> >>   rework ldso handling of global symbol table for consistency
> >>   reorder addend handling before symbol lookup in relocation code
> >>   emulate lazy relocation as deferrable relocation
> >>   fix free of uninitialized buffer pointer on error in regexec
> >>   in static dl_iterate_phdr, fix use of possibly-uninitialized aux
> >> data
> >>   fix possible fd leak, unrestored cancellation state on dns socket
> >> fail
> >>   fix wide scanf's use of a compound literal past its lifetime
> >>   fix one-byte overflow in legacy getpass function
> >>   avoid loading of multiple libc versions via explicit pathname
> >>   remove unused refcnt field for shared libraries
> >>
> >> Szabolcs Nagy (1):
> >>   treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym
> >
> >
> >
> > Could the relocation changes here be responsible for these ovmf build
> > failures:
> >   "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
> > ?
> >
> Dont understand why musl would affect here.
> its using native gcc to build the artifacts its complaining about,

Yes, it is a bit puzzling how the libc on the target can influence the
compilation of ovmf. However, ovmf gets compiled for the target, so
there is at least some correlation.

Why it uses "gcc" is a good question, and I don't know. It happens to
work in practice because there's a long list of additional parameters
which selects the actual target architecture (in particular, -m64 vs.
-m32).

Perhaps this use of the host gcc is the reason why I can't reproduce it
locally.

The recipe has some code which tries to change the "gcc" invocations
into something else. I think it is meant to work like this (don't ask
how long it took me to figure this out):
  * ovmf-native patches BaseTools/Conf/tools_def.template such that
${TARGET_PREFIX}gcc is used (do_fix_toolchain)
  * ovmf picks up the path to that modified tools_def.template and
uses it as Conf/tools_def.txt
(0002-ovmf-update-path-to-native-BaseTools.patch +
do_fix_basetools_location)

Ricardo, is that correct?

However, TARGET_PREFIX is empty in ovmf-native. So instead of
i586-poky-linux-musl-gcc or i586-poky-linux-musl-gcc-ar we end up
building with gcc and gcc-ar from the host, which probably wasn't the
intention.

Below a patch which compiles for me using the right tools. More testing
has to wait until tomorrow.

diff --git a/meta/recipes-core/ovmf/ovmf_git.bb 
b/meta/recipes-core/ovmf/ovmf_git.bb
index a658c9d1154..9ee60feb1f1 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -11,7 +11,6 @@ PACKAGECONFIG ??= ""
 PACKAGECONFIG[secureboot] = ",,,"
 
 SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
-   file://0001-BaseTools-Force-tools-variables-to-host-toolchain.patch \
file://0002-ovmf-update-path-to-native-BaseTools.patch \
file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
file://VfrCompile-increase-path-length-limit.patch \
@@ -53,8 +52,8 @@ OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE 
${OVMF_SECURE_BOOT_EXTRA_FLA
 
 do_patch_append_class-native() {
 bb.build.exec_func('do_fix_iasl', d)
-bb.build.exec_func('do_fix_toolchain', d)
 }
+do_patch[postfuncs] += "do_fix_toolchain"
 
 do_fix_basetools_location() {
 sed -i -e 
's#BBAKE_EDK_TOOLS_PATH#${STAGING_BINDIR_NATIVE}/${EDK_TOOLS_DIR}#' 
${S}/OvmfPkg/build.sh
@@ -69,13 +68,42 @@ do_fix_iasl() {
 sed -i -e 's#/usr/bin/iasl#${STAGING_BINDIR_NATIVE}/iasl#' 
${S}/BaseTools/Conf/tools_def.template
 }
 
-do_fix_toolchain(){
-sed -i -e 's#DEF(ELFGCC_BIN)/#${TARGET_PREFIX}#' 
${S}/BaseTools/Conf/tools_def.template
-sed -i -e 's#DEF(GCC.*PREFIX)#${TARGET_PREFIX}#' 
${S}/BaseTools/Conf/tools_def.template
-sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" 
${S}/BaseTools/Source/C/Makefiles/app.makefile
-sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" 
${S}/BaseTools/Source/C/Makefiles/app.makefile
-sed -i -e "s#^LINKER\(.*\)#LINKER\1\nLFLAGS += ${BUILD_LDFLAGS}#" 
${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
-sed -i -e "s#^LINKER\(.*\)#LINKER\1\nCFLAGS += ${BUILD_CFLAGS}#" 
${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
+# Inject CC and friends into the build. LINKER already is in GNUmakefile.
+# Must be idempotent and thus remove old assignments that were inserted
+# earlier.
+do_fix_toolchain() {
+sed -i \
+-e '/^\(CC\|CXX\|AS\|AR\|LD\|LINKER\) =/d' \
+-e '/^APPLICATION/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = 
${AR}\nLD = ${LD}\nLINKER = $(CC)' \
+

[OE-core] [PATCH 2/3] scripts/yocto-compat-layer.py: Dump log to stdout instead of stderr

[Aníbal Limón]

The common unix tools uses stdout as standard for log output, by default
python logging uses stderr if not stream is specified.

[YOCTO #11160]

Signed-off-by: Aníbal Limón 
---
 scripts/yocto-compat-layer.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index 09dc5bf..8996fff 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -31,7 +31,7 @@ DEFAULT_OUTPUT_LOG = '%s-%s.log' % (PROGNAME,
 OUTPUT_LOG_LINK = "%s.log" % PROGNAME
 CASES_PATHS = [os.path.join(os.path.abspath(os.path.dirname(__file__)),
 'lib', 'compatlayer', 'cases')]
-logger = scriptutils.logger_create(PROGNAME)
+logger = scriptutils.logger_create(PROGNAME, stream=sys.stdout)
 
 def test_layer_compatibility(td, layer):
 from compatlayer.context import CompatLayerTestContext
-- 
2.1.4

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

[OE-core] [PATCH 3/3] scripts/yocto-compat-layer.py: Make output log argument optional

[Aníbal Limón]

Only create a log file when --output-log option is specified, since
logger is dumping to stdout by default is better to let the user
decide if a log needs to be created.

[YOCTO #11160]

Signed-off-by: Aníbal Limón 
---
 scripts/yocto-compat-layer.py | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index 8996fff..b96f3ca 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -26,9 +26,6 @@ from compatlayer import LayerType, detect_layers, add_layer, 
get_signatures
 from oeqa.utils.commands import get_bb_vars
 
 PROGNAME = 'yocto-compat-layer'
-DEFAULT_OUTPUT_LOG = '%s-%s.log' % (PROGNAME,
-time.strftime("%Y%m%d%H%M%S"))
-OUTPUT_LOG_LINK = "%s.log" % PROGNAME
 CASES_PATHS = [os.path.join(os.path.abspath(os.path.dirname(__file__)),
 'lib', 'compatlayer', 'cases')]
 logger = scriptutils.logger_create(PROGNAME, stream=sys.stdout)
@@ -49,9 +46,7 @@ def main():
 parser.add_argument('layers', metavar='LAYER_DIR', nargs='+',
 help='Layer to test compatibility with Yocto Project')
 parser.add_argument('-o', '--output-log',
-help='Output log default: %s' % DEFAULT_OUTPUT_LOG,
-action='store', default=DEFAULT_OUTPUT_LOG)
-
+help='File to output log (optional)', action='store')
 parser.add_argument('-d', '--debug', help='Enable debug output',
 action='store_true')
 parser.add_argument('-q', '--quiet', help='Print only errors',
@@ -63,16 +58,14 @@ def main():
 
 args = parser.parse_args()
 
-fh = logging.FileHandler(args.output_log)
-fh.setFormatter(logging.Formatter("%(levelname)s: %(message)s"))
-logger.addHandler(fh)
+if args.output_log:
+fh = logging.FileHandler(args.output_log)
+fh.setFormatter(logging.Formatter("%(levelname)s: %(message)s"))
+logger.addHandler(fh)
 if args.debug:
 logger.setLevel(logging.DEBUG)
 elif args.quiet:
 logger.setLevel(logging.ERROR)
-if os.path.exists(OUTPUT_LOG_LINK):
-os.unlink(OUTPUT_LOG_LINK)
-os.symlink(args.output_log, OUTPUT_LOG_LINK)
 
 if not 'BUILDDIR' in os.environ:
 logger.error("You must source the environment before run this script.")
-- 
2.1.4

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

[OE-core] [PATCH 1/3] scriptutils: Add support for specify stream on logger_create

[Aníbal Limón]

It is a good idea to let the script to choose what stream wants
to dump the logging output.

[YOCTO #11160]

Signed-off-by: Aníbal Limón 
---
 scripts/lib/scriptutils.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/scriptutils.py b/scripts/lib/scriptutils.py
index 4233783..4ccbe5c 100644
--- a/scripts/lib/scriptutils.py
+++ b/scripts/lib/scriptutils.py
@@ -22,9 +22,9 @@ import glob
 import argparse
 import subprocess
 
-def logger_create(name):
+def logger_create(name, stream=None):
 logger = logging.getLogger(name)
-loggerhandler = logging.StreamHandler()
+loggerhandler = logging.StreamHandler(stream=stream)
 loggerhandler.setFormatter(logging.Formatter("%(levelname)s: %(message)s"))
 logger.addHandler(loggerhandler)
 logger.setLevel(logging.INFO)
-- 
2.1.4

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

Re: [OE-core] [PATCH 2/4] kernel.bbclass: handle kernel-vmlinux in KERNEL_IMAGETYPES

[Andrea Adami]

On Mon, Mar 20, 2017 at 4:45 PM, Peter Liu
 wrote:
> Hi, Andrea:
>
>
> Thanks for your testing.
>
>
> I think you are absolutely right, actually I think you had found a fix for a
> potential defect, do_kernel_link_images needs to run after do_compile, and
> this SHOULD be set up in kernel.bbclass but not in linux-yocto.inc, since a
> dependent chain exists in kernel.bbclass as following:
>
>
> do_package->do_install->do_sizecheck->do_strip->do_kernel_link_vmlinux, so
> do_kernel_link_vmlinux->do_compile needs to set up in kernel.bbclass as
> well, am I correct? Or else the recipes inheriting kernel.bbclass might have
> a explicit dependency between do_kernel_link_vmlinux and do_compile. But why
> this did not show up before? Maybe because there is another incorrect
> addtask statement? As it is in kernel.bbclass:
>
>
> 563 addtask do_strip before do_sizecheck after do_kernel_link_images
>
>
> it should be:
>
> addtask strip before do_sizecheck after do_kernel_link_images
>
>
> I am just curious how it worked before without running into errors, but
> anyway I will send a V2 to also address that issue.



Without your last patchset it worked just fine for the case
KERNEL_IMAGETYPE ?= "zImage"

But for the mips target I discovered recently that the
kernel_link_images task was needed and I actually extended it in order
to consder vmlinuz.bin.

If we apply your patchset then this task is an absolute must and it
should be in kernel.bbclass. Our recipe does skip do_install so we
have to readd the task.


Cheers
Andrea

>
>
> the best,
>
> thank you
>
>
>
> 
> From: Andrea Adami 
> Sent: Monday, March 20, 2017 10:38:19 AM
> To: openembedded-core
> Cc: Bruce Ashfield; Tao, Yue; Peter Liu
> Subject: Re: [OE-core] [PATCH 2/4] kernel.bbclass: handle kernel-vmlinux in
> KERNEL_IMAGETYPES
>
> On Sun, Mar 19, 2017 at 2:13 PM,   wrote:
>> From: Ming Liu 
>>
>> There is a mess after KERNEL_IMAGETYPES was introduced in commit 849b67b2:
>> [ kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time ]
>>
>> There are two packages both providing vmlinux image if 'vmlinux' is set in
>> KERNEL_IMAGETYPES, they are kernel-vmlinux and kernel-image-vmlinux, to
>> let them to be able to coexist, kernel-image-vmlinux was set to empty
>> allowable, but its postinst/postrm scripts still remain trying to
>> install/rm
>> a update-alternatives link to /boot/vmlinux-${KERNEL_VERSION_NAME} but
>> that
>> file is actually being provided by the other package kernel-vmlinux.
>>
>> Fixed this mess by appending vmlinux to KERNEL_IMAGETYPES and process it
>> in anonymous python function. It would not change the original behavior,
>> all the generated packages would be same with before except that the
>> ALLOW_EMPTY variable, it is removed in this patch.
>
> Hi,
>
> I am testing the 'old-style' of embedding the initramfs in the images [1].
> Your patch does add 'vmlinux' even if we have KERNEL_IMAGETYPE ?= "zImage"
> so it leads to the following error:
>
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing shell function do_deploy
> | install: cannot stat 'arch/arm/boot/vmlinux': No such file or director
>
> The solution for our custom kernel recipe is:
>
> inherit kernel
> addtask kernel_link_images after do_compile before do_strip
>
> as done in linux-yocto.inc.
>
> So with this little adjustment it is still possible to build in the old-way.
>
> I didn't test yet the other part of the patchset so I cannot fully ack it.
> FWIW I never liked the *BUNDLE framework for the need of specifying
> the INITRAMFS_IMAGE in a conf file and not in the kernel recipe as
> done with the old framework.
>
> Cheers
> Andrea
>
> [1]
> http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-gcw0-kexecboot_4.7.bb
>
>
>>
>> Signed-off-by: Ming Liu 
>> ---
>>  meta/classes/kernel.bbclass | 47
>> +++--
>>  1 file changed, 20 insertions(+), 27 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 6905a9b..1a4335c 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -14,6 +14,7 @@ OE_TERMINAL_EXPORTS += "KBUILD_OUTPUT"
>>  # we include gcc above, we dont need virtual/libc
>>  INHIBIT_DEFAULT_DEPS = "1"
>>
>> +KERNEL_IMAGETYPES_append = " vmlinux"
>>  KERNEL_IMAGETYPE ?= "zImage"
>>  INITRAMFS_IMAGE ?= ""
>>  INITRAMFS_IMAGE_NAME ?= "${@['${INITRAMFS_IMAGE}-${MACHINE}',
>> ''][d.getVar('INITRAMFS_IMAGE') == '']}"
>> @@ -35,38 +36,33 @@ python __anonymous () {
>>  import re
>>
>>  # Merge KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE into
>> KERNEL_IMAGETYPES
>> -type = d.getVar('KERNEL_IMAGETYPE') or ""
>> -alttype = d.getVar('KERNEL_ALT_IMAGETYPE') or ""
>> -types = d.getVar('KERNEL_IMAGETYPES') 

[OE-core] [morty][PATCH] sstate.bbclass: update .siginfo atime

[Denys Dmytriyenko]

From: Ed Bartosh 

.siginfo files are not being accessed from local or NFS-mounted
sstate mirrors when sstate package is installed, so their atime
is not updated. If sstate mirror is cleaned based on access time,
they get deleted, even though they are still being used.

Updated atime of .siginfo symlinks with 'touch -a'. This command
dereferences symlinks pointing to the local mirror and updates
atime of the .siginfo file on the mirror.

[YOCTO #10857]

Signed-off-by: Ed Bartosh 
Signed-off-by: Ross Burton 
Signed-off-by: Denys Dmytriyenko 
---
 meta/classes/sstate.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 8643f3d..4fdfcc8 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -724,6 +724,8 @@ python sstate_sign_package () {
 #
 sstate_unpack_package () {
tar -xvzf ${SSTATE_PKG}
+   # update .siginfo atime on local/NFS mirror
+   [ -h ${SSTATE_PKG}.siginfo ] && touch -a ${SSTATE_PKG}.siginfo
# Use "! -w ||" to return true for read only files
[ ! -w ${SSTATE_PKG} ] || touch --no-dereference ${SSTATE_PKG}
[ ! -w ${SSTATE_PKG}.sig ] || [ ! -e ${SSTATE_PKG}.sig ] || touch 
--no-dereference ${SSTATE_PKG}.sig
-- 
2.7.4

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

[OE-core] [PATCH 2/2] oeqa/selftest: remove test_sanity_unsafe_binary_references

[Ross Burton]

This test was attempting to exercise a broken test, for some reason this broke
with patches under review but investigation revealed that the test itself is
broken.  The test has been removed, so there's no need to test it.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/selftest/buildoptions.py | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/meta/lib/oeqa/selftest/buildoptions.py 
b/meta/lib/oeqa/selftest/buildoptions.py
index a97257e..7ace747 100644
--- a/meta/lib/oeqa/selftest/buildoptions.py
+++ b/meta/lib/oeqa/selftest/buildoptions.py
@@ -114,25 +114,6 @@ do_install_append_pn-gzip () {
 line = self.getline(res, "QA Issue: gzip")
 self.assertTrue(line and line.startswith("WARNING:"), "WARNING: QA 
Issue: gzip message is not present in bitbake's output: %s" % res.output)
 
-@testcase(1434)
-def test_sanity_unsafe_binary_references(self):
-self.write_config('WARN_QA_append = " unsafe-references-in-binaries"')
-
-#res = bitbake("nfs-utils")
-# FIXME when nfs-utils passes this test
-#line = self.getline(res, "QA Issue: nfs-utils")
-#self.assertFalse(line, "WARNING: QA Issue: nfs-utils message is 
present in bitbake's output and shouldn't be: %s" % res.output)
-
-#self.append_config("""
-#do_install_append_pn-nfs-utils () {
-#  echo "\n${bindir}/test" >> ${D}${base_sbindir}/osd_login
-#}
-#""")
-self.add_command_to_tearDown('bitbake -c clean nfs-utils')
-res = bitbake("nfs-utils -f -c package_qa")
-line = self.getline(res, "QA Issue: nfs-utils")
-self.assertTrue(line and line.startswith("WARNING:"), "WARNING: QA 
Issue: nfs-utils message is not present in bitbake's output: %s" % res.output)
-
 @testcase(1421)
 def test_layer_without_git_dir(self):
 """
-- 
2.8.1

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

[OE-core] [PATCH 2/4] openssl: Fix build with clang

[Khem Raj]

Signed-off-by: Khem Raj 
---
 ...build-with-clang-using-external-assembler.patch | 49 ++
 .../recipes-connectivity/openssl/openssl_1.0.2k.bb |  5 ++-
 2 files changed, 52 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/0001-Fix-build-with-clang-using-external-assembler.patch

diff --git 
a/meta/recipes-connectivity/openssl/openssl/0001-Fix-build-with-clang-using-external-assembler.patch
 
b/meta/recipes-connectivity/openssl/openssl/0001-Fix-build-with-clang-using-external-assembler.patch
new file mode 100644
index 00..47b83a5896
--- /dev/null
+++ 
b/meta/recipes-connectivity/openssl/openssl/0001-Fix-build-with-clang-using-external-assembler.patch
@@ -0,0 +1,49 @@
+From 2f6026cb8b16cf00726e3c5625c023f196680f07 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Fri, 17 Mar 2017 12:52:08 -0700
+Subject: [PATCH] Fix build with clang using external assembler
+
+Cherry-picked from
+https://github.com/openssl/openssl/commit/11208dcfb9105e8afa37233185decefd45e89e17
+https://github.com/openssl/openssl/commit/fbab8baddef8d3346ae40ff068871e2ddaf10270
+https://github.com/openssl/openssl/commit/6cf412c473d8145562b76219ce3da73b201b3255
+
+Fixes
+
+| ghash-armv4.S: Assembler messages:
+| ghash-armv4.S:81: Error: bad instruction `ldrbpl r12,[r2,r3]'
+| ghash-armv4.S:91: Error: bad instruction `ldrbpl r8,[r0,r3]'
+| ghash-armv4.S:137: Error: bad instruction `ldrbne r12,[r2,#15]'
+| ghash-armv4.S:224: Error: bad instruction `ldrbpl r12,[r0,r3]'
+| clang-4.0: error: assembler command failed with exit code 1 (use -v to see 
invocation)
+| make[2]: *** [: ghash-armv4.o] Error 1
+
+Upstream-Status: Backport
+
+Signed-off-by: Khem Raj 
+---
+ crypto/modes/asm/ghash-armv4.pl | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/crypto/modes/asm/ghash-armv4.pl b/crypto/modes/asm/ghash-armv4.pl
+index 8ccc963ef..442fed4da 100644
+--- a/crypto/modes/asm/ghash-armv4.pl
 b/crypto/modes/asm/ghash-armv4.pl
+@@ -124,7 +124,14 @@ $code=<<___;
+ #include "arm_arch.h"
+ 
+ .text
++#if defined(__thumb2__) || defined(__clang__)
++.syntax   unified
++#endif
++#if defined(__thumb2__)
++.thumb
++#else
+ .code 32
++#endif
+ 
+ #ifdef __clang__
+ #define ldrplbldrbpl
+-- 
+2.12.0
+
diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2k.bb 
b/meta/recipes-connectivity/openssl/openssl_1.0.2k.bb
index 922819b3d5..1c1041428c 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.0.2k.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.0.2k.bb
@@ -37,12 +37,13 @@ SRC_URI += "file://find.pl;subdir=${BP}/util/ \
 file://Makefiles-ptest.patch \
 file://ptest-deps.patch \
 file://openssl-1.0.2a-x32-asm.patch \
-file://ptest_makefile_deps.patch  \
+file://ptest_makefile_deps.patch \
 file://configure-musl-target.patch \
 file://parallel.patch \
 file://openssl-util-perlpath.pl-cwd.patch \
 file://Use-SHA256-not-MD5-as-default-digest.patch \
-   "
+file://0001-Fix-build-with-clang-using-external-assembler.patch \
+"
 SRC_URI[md5sum] = "f965fc0bf01bf882b31314b61391ae65"
 SRC_URI[sha256sum] = 
"6b3977c61f2aedf0f96367dcfb5c6e578cf37e7b8d913b4ecb6643c3cb88d8c0"
 
-- 
2.12.0

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

[OE-core] [PATCH 4/4] go-native: Install bootstrap binaries with 1.4 suffix

[Khem Raj]

Currently, bin/go and bin/gofmt collide between go-native
and go-bootstrap-native packages, these are scripts anyway
which call the go compiler proper from right install, in
this case create go1.4 and gofmt1.4 names for these scripts
to avoid namespace collision

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/go/go-native.inc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-devtools/go/go-native.inc 
b/meta/recipes-devtools/go/go-native.inc
index c1ada5121a..c21f8fda78 100644
--- a/meta/recipes-devtools/go/go-native.inc
+++ b/meta/recipes-devtools/go/go-native.inc
@@ -22,14 +22,14 @@ do_compile() {
 }
 
 make_wrapper() {
-   rm -f ${D}${bindir}/$2
-   cat <${D}${bindir}/$2
+   rm -f ${D}${bindir}/$2$3
+   cat <${D}${bindir}/$2$3
 #!/bin/bash
 here=\`dirname \$0\`
-export GOROOT="${GOROOT:-\`readlink -f \$here/../lib/go\`}"
-\$here/../lib/go/bin/$1 "\$@"
+export GOROOT="${GOROOT:-\`readlink -f \$here/../lib/go$3\`}"
+\$here/../lib/go$3/bin/$1 "\$@"
 END
-   chmod +x ${D}${bindir}/$2
+   chmod +x ${D}${bindir}/$2$3
 }
 
 do_install() {
@@ -45,7 +45,7 @@ do_install() {
do
base=`basename $f`
install -m755 $f ${D}${libdir}/go${BOOTSTRAP}/bin
-   make_wrapper $base $base
+   make_wrapper $base $base ${BOOTSTRAP}
done
 }
 
-- 
2.12.0

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

[OE-core] [PATCH 3/4] acpitests: Point Makefile CC to use OE synthesized CC

[Khem Raj]

Default CC is same as used here, there is no need to
duplicate it, as a plus it helps in compiling acpitests with
non-gcc cross compilers

Signed-off-by: Khem Raj 
---
 meta/recipes-extended/acpica/acpitests_20140828.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/acpica/acpitests_20140828.bb 
b/meta/recipes-extended/acpica/acpitests_20140828.bb
index 1f6f190c2e..409da5ccc4 100644
--- a/meta/recipes-extended/acpica/acpitests_20140828.bb
+++ b/meta/recipes-extended/acpica/acpitests_20140828.bb
@@ -18,7 +18,7 @@ SRC_URI[acpica.sha256sum] = 
"01d8867656c5ba41dec307c4383ce676196ad4281ac2c9dec9f
 
 S = "${WORKDIR}/acpitests-unix-${PV}"
 
-EXTRA_OEMAKE = "'CC=${TARGET_PREFIX}gcc ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}' 
'OPT_CFLAGS=-Wall'"
+EXTRA_OEMAKE = "'CC=${CC}' 'OPT_CFLAGS=-Wall'"
 
 # The Makefiles expect a specific layout
 do_compile() {
-- 
2.12.0

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

[OE-core] [PATCH 1/2] insane: remove broken unsafe-references-in-binaries test

[Ross Burton]

This test aims to detect binaries in /bin which link to libraries in /usr/lib,
for the case where the user has /usr on a separate filesystem to /.

However it doesn't scan both image/ and the sysroot, so if a binary in /bin
links to a library in /usr/lib that was built by the same recipe then it will
error out.

This test isn't enabled by default, and because of this serious bug I suspect
nobody else is enabling it either.  As /usr being on a separate partition to /
is a very rare configuration these days I think we should delete the test: if
someone cares sufficiently they should write a test that actually works.

Signed-off-by: Ross Burton 
---
 meta/classes/insane.bbclass | 42 --
 1 file changed, 42 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 6a34bd5..7a86997 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -408,48 +408,6 @@ def package_qa_check_perm(path,name,d, elf, messages):
 """
 return
 
-QAPATHTEST[unsafe-references-in-binaries] = 
"package_qa_check_unsafe_references_in_binaries"
-def package_qa_check_unsafe_references_in_binaries(path, name, d, elf, 
messages):
-"""
-Ensure binaries in base_[bindir|sbindir|libdir] do not link to files under 
exec_prefix
-"""
-if unsafe_references_skippable(path, name, d):
-return
-
-if elf:
-import subprocess as sub
-pn = d.getVar('PN')
-
-exec_prefix = d.getVar('exec_prefix')
-sysroot_path = d.getVar('STAGING_DIR_TARGET')
-sysroot_path_usr = sysroot_path + exec_prefix
-
-try:
-ldd_output = bb.process.Popen(["prelink-rtld", "--root", 
sysroot_path, path], stdout=sub.PIPE).stdout.read().decode("utf-8")
-except bb.process.CmdError:
-error_msg = pn + ": prelink-rtld aborted when processing %s" % path
-package_qa_handle_error("unsafe-references-in-binaries", 
error_msg, d)
-return False
-
-if sysroot_path_usr in ldd_output:
-ldd_output = ldd_output.replace(sysroot_path, "")
-
-pkgdest = d.getVar('PKGDEST')
-packages = d.getVar('PACKAGES')
-
-for package in packages.split():
-short_path = path.replace('%s/%s' % (pkgdest, package), "", 1)
-if (short_path != path):
-break
-
-base_err = pn + ": %s, installed in the base_prefix, requires a 
shared library under exec_prefix (%s)" % (short_path, exec_prefix)
-for line in ldd_output.split('\n'):
-if exec_prefix in line:
-error_msg = "%s: %s" % (base_err, line.strip())
-package_qa_handle_error("unsafe-references-in-binaries", 
error_msg, d)
-
-return False
-
 QAPATHTEST[unsafe-references-in-scripts] = 
"package_qa_check_unsafe_references_in_scripts"
 def package_qa_check_unsafe_references_in_scripts(path, name, d, elf, 
messages):
 """
-- 
2.8.1

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

Re: [OE-core] go-bootstrap / go-native conflict during do_rootfs

[Khem Raj]

On Mon, Mar 20, 2017 at 8:29 AM, Khem Raj  wrote:
> On Mon, Mar 20, 2017 at 8:17 AM, Richard Purdie
>  wrote:
>> On Mon, 2017-03-20 at 07:49 -0700, Khem Raj wrote:
>>> On Mon, Mar 20, 2017 at 6:47 AM, Kristian Amlie
>>>  wrote:
>>> >
>>> > --
>>> >
>>> > Additionally, in the logs I found these two snippets:
>>> >
>>> > --
>>> > Considering setscene task: ['go-native', 'do_populate_sysroot']
>>> >   considering dependency: ['go-native', 'do_populate_sysroot']
>>> >   considering dependency: ['mender-artifact-native',
>>> > 'do_populate_sysroot']
>>> > Adding dependency on go-native
>>> > ...
>>> > Considering setscene task: ['go-bootstrap-native',
>>> > 'do_populate_sysroot']
>>> >   considering dependency: ['go-native', 'do_populate_sysroot']
>>> > Adding dependency on go-bootstrap-native
>>> > --
>>> >
>>> > which lead me to believe that all dependencies are being pulled in
>>> > simultaneously by do_rootfs, but go-native and go-bootstrap-native
>>> > are
>>> > in fact mutually exclusive, since they install to the sysroot in
>>> > the
>>> > same location. Note that both compilers build just fine, it's only
>>> > at
>>> > the do_rootfs stage that this shows up.
>>> >
>>> > I think the oe-meta-go layer solved this by having go-bootstrap-
>>> > native
>>> > install in a different location, but I'm unsure what is the best
>>> > approach for OE.
>>> go-bootstrap is only needed for few recipes. I think we should find
>>> out
>>> a way to keep this dep limited to those recipes and not reflect in
>>> final
>>> image rootfs creation. That seems to be not useful.
>>
>> There is code in sstate.bbclass in setscene_depvalid:
>>
>> # Consider sysroot depending on sysroot tasks
>> if taskdependees[task][1] == 'do_populate_sysroot' and 
>> taskdependees[dep][1] == 'do_populate_sysroot':
>> [...]
>> # Nothing need depend on libc-initial/gcc-cross-initial
>> if "-initial" in taskdependees[task][0]:
>> continue
>>
>> so if go-bootstrap-native were renamed go-native-initial, things might
>> happen to work better...
>
> ah thats right, forgot about that, I think we should rename the recipe
> to go-native-initial
>
>>

Can you try

http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134372.html

and see if this works out for you ?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/4] ltp: Fix __sighandler_t for mips

[Khem Raj]

mips definition of kernel_sigaction was added later
and the patch did not apply to mips part which ended
in ltp failing to compile on mips parts

In file included from rt_sigaction01.c:42:0:
../../../../include/lapi/rt_sigaction.h:39:2: error: unknown type name 
'__sighandler_t'
  __sighandler_t k_sa_handler;
  ^~

Signed-off-by: Khem Raj 
---
 ...n.h-Use-sighandler_t-instead-of-__sighand.patch | 31 --
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git 
a/meta/recipes-extended/ltp/ltp/0028-rt_sigaction.h-Use-sighandler_t-instead-of-__sighand.patch
 
b/meta/recipes-extended/ltp/ltp/0028-rt_sigaction.h-Use-sighandler_t-instead-of-__sighand.patch
index fc82ff9239..b26aa133e9 100644
--- 
a/meta/recipes-extended/ltp/ltp/0028-rt_sigaction.h-Use-sighandler_t-instead-of-__sighand.patch
+++ 
b/meta/recipes-extended/ltp/ltp/0028-rt_sigaction.h-Use-sighandler_t-instead-of-__sighand.patch
@@ -13,23 +13,29 @@ Signed-off-by: Khem Raj 
  testcases/kernel/syscalls/rt_sigsuspend/Makefile | 3 +++
  2 files changed, 4 insertions(+), 1 deletion(-)
 
-diff --git a/include/lapi/rt_sigaction.h b/include/lapi/rt_sigaction.h
-index 3a5a763..870918c 100644
 a/include/lapi/rt_sigaction.h
-+++ b/include/lapi/rt_sigaction.h
-@@ -34,7 +34,7 @@
- #define INVAL_SA_PTR ((void *)-1)
- 
+Index: git/include/lapi/rt_sigaction.h
+===
+--- git.orig/include/lapi/rt_sigaction.h
 git/include/lapi/rt_sigaction.h
+@@ -36,12 +36,12 @@
+ #if defined(__mips__)
+ struct kernel_sigaction {
+   unsigned int sa_flags;
+-  __sighandler_t k_sa_handler;
++  sighandler_t k_sa_handler;
+   sigset_t sa_mask;
+ };
+ #else
  struct kernel_sigaction {
 -  __sighandler_t k_sa_handler;
 +  sighandler_t k_sa_handler;
unsigned long sa_flags;
void (*sa_restorer) (void);
sigset_t sa_mask;
-diff --git a/testcases/kernel/syscalls/rt_sigsuspend/Makefile 
b/testcases/kernel/syscalls/rt_sigsuspend/Makefile
-index 37bc3a9..2ca7f7c 100644
 a/testcases/kernel/syscalls/rt_sigsuspend/Makefile
-+++ b/testcases/kernel/syscalls/rt_sigsuspend/Makefile
+Index: git/testcases/kernel/syscalls/rt_sigsuspend/Makefile
+===
+--- git.orig/testcases/kernel/syscalls/rt_sigsuspend/Makefile
 git/testcases/kernel/syscalls/rt_sigsuspend/Makefile
 @@ -19,4 +19,7 @@
  top_srcdir?= ../../../..
  
@@ -38,6 +44,3 @@ index 37bc3a9..2ca7f7c 100644
 +CFLAGS+= -D_GNU_SOURCE
 +
  include $(top_srcdir)/include/mk/generic_leaf_target.mk
--- 
-2.7.0
-
-- 
2.12.0

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

[OE-core] [PATCH 0/4] misc fixes

[Khem Raj]

Fix install collisions between go-native and go-bootstrap-native
Fix ltp for musl
Other fixes are found by clang but are generic

The following changes since commit b5a595a4be09756b88e91f3353e3b221b165ab44:

  binutils: disable gold on mingw (2017-03-20 15:17:48 +)

are available in the git repository at:

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

Khem Raj (4):
  ltp: Fix __sighandler_t for mips
  openssl: Fix build with clang
  acpitests: Point Makefile CC to use OE synthesized CC
  go-native: Install bootstrap binaries with 1.4 suffix

 ...build-with-clang-using-external-assembler.patch | 49 ++
 .../recipes-connectivity/openssl/openssl_1.0.2k.bb |  5 ++-
 meta/recipes-devtools/go/go-native.inc | 12 +++---
 meta/recipes-extended/acpica/acpitests_20140828.bb |  2 +-
 ...n.h-Use-sighandler_t-instead-of-__sighand.patch | 31 +++---
 5 files changed, 76 insertions(+), 23 deletions(-)
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/0001-Fix-build-with-clang-using-external-assembler.patch

-- 
2.12.0

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

Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30

[Manjukumar Harthikote Matha]

> -Original Message-
> From: Stefano Babic [mailto:sba...@denx.de]
> Sent: Monday, March 20, 2017 5:06 PM
> To: Manjukumar Harthikote Matha; Robert Yang; Stefano Babic; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30
>
> On 20/03/2017 12:29, Manjukumar Harthikote Matha wrote:
> >
> >
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> >> Of Robert Yang
> >> Sent: Monday, March 20, 2017 3:14 PM
> >> To: Stefano Babic; openembedded-core@lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30
> >>
> >> Yes, file's upstream commit ID has changed, Paul has sent a patch for it:
> >>
> >> http://lists.openembedded.org/pipermail/openembedded-core/2017-
> >> March/134261.html
> >>
> >
> > Is it better to use nobranch=1 ?
>
> Is it ? I would prefer to not skip test, just fix the issues.
>
I kind of agree but if this becomes a practice then it will continue to break 
released versions.

> > Changes in this file.git has broken Morty as well, we used nobranch=1 to 
> > resolve
> this issue.
>
> But which revision is taken in your build ? IMHO it is better to fix the 
> revision as Paul
> does in his patch.
>
I agree to use Paul's patch, maybe we should also introduce nobranch=1 was my 
thinking.

Thanks
Manju

> > I haven't tested this for other released versions of Yocto.
>
> I tested -krogoth, -morty and -master, all of them are broken.
>
> Stefano
>
>
> --
> 
> =
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> 
> =


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

Re: [OE-core] go-bootstrap / go-native conflict during do_rootfs

[Khem Raj]

On Mon, Mar 20, 2017 at 8:17 AM, Richard Purdie
 wrote:
> On Mon, 2017-03-20 at 07:49 -0700, Khem Raj wrote:
>> On Mon, Mar 20, 2017 at 6:47 AM, Kristian Amlie
>>  wrote:
>> >
>> > --
>> >
>> > Additionally, in the logs I found these two snippets:
>> >
>> > --
>> > Considering setscene task: ['go-native', 'do_populate_sysroot']
>> >   considering dependency: ['go-native', 'do_populate_sysroot']
>> >   considering dependency: ['mender-artifact-native',
>> > 'do_populate_sysroot']
>> > Adding dependency on go-native
>> > ...
>> > Considering setscene task: ['go-bootstrap-native',
>> > 'do_populate_sysroot']
>> >   considering dependency: ['go-native', 'do_populate_sysroot']
>> > Adding dependency on go-bootstrap-native
>> > --
>> >
>> > which lead me to believe that all dependencies are being pulled in
>> > simultaneously by do_rootfs, but go-native and go-bootstrap-native
>> > are
>> > in fact mutually exclusive, since they install to the sysroot in
>> > the
>> > same location. Note that both compilers build just fine, it's only
>> > at
>> > the do_rootfs stage that this shows up.
>> >
>> > I think the oe-meta-go layer solved this by having go-bootstrap-
>> > native
>> > install in a different location, but I'm unsure what is the best
>> > approach for OE.
>> go-bootstrap is only needed for few recipes. I think we should find
>> out
>> a way to keep this dep limited to those recipes and not reflect in
>> final
>> image rootfs creation. That seems to be not useful.
>
> There is code in sstate.bbclass in setscene_depvalid:
>
> # Consider sysroot depending on sysroot tasks
> if taskdependees[task][1] == 'do_populate_sysroot' and 
> taskdependees[dep][1] == 'do_populate_sysroot':
> [...]
> # Nothing need depend on libc-initial/gcc-cross-initial
> if "-initial" in taskdependees[task][0]:
> continue
>
> so if go-bootstrap-native were renamed go-native-initial, things might
> happen to work better...

ah thats right, forgot about that, I think we should rename the recipe
to go-native-initial

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

[OE-core] [PATCH] gpgme: Avoid requiring a host C++ compiler with C++11 support

[Peter Kjellerstedt]

Building the C++ bindings for native requires a host C++ compiler with
C++11 support. Since these bindings are currently not needed, we can
disable them and thus avoid increasing the requirement for the host C++
compiler.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-support/gpgme/gpgme_1.8.0.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/gpgme/gpgme_1.8.0.bb 
b/meta/recipes-support/gpgme/gpgme_1.8.0.bb
index d3e7880a47..2756ef815d 100644
--- a/meta/recipes-support/gpgme/gpgme_1.8.0.bb
+++ b/meta/recipes-support/gpgme/gpgme_1.8.0.bb
@@ -34,7 +34,11 @@ PACKAGECONFIG[python3] = ",,python3 swig-native,"
 # Supported: "cl cpp python python2 python3 qt"
 # python says 'search and find python2 or python3'
 
-LANGUAGES ?= "cpp"
+# Building the C++ bindings for native requires a C++ compiler with C++11
+# support. Since these bindings are currently not needed, we can disable them.
+DEFAULT_LANGUAGES = ""
+DEFAULT_LANGUAGES_class-target = "cpp"
+LANGUAGES ?= "${DEFAULT_LANGUAGES}"
 LANGUAGES .= "${@bb.utils.contains('PACKAGECONFIG', 'python2', ' python2', '', 
d)}"
 LANGUAGES .= "${@bb.utils.contains('PACKAGECONFIG', 'python3', ' python3', '', 
d)}"
 
-- 
2.12.0

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

Re: [OE-core] go-bootstrap / go-native conflict during do_rootfs

[Richard Purdie]

On Mon, 2017-03-20 at 07:49 -0700, Khem Raj wrote:
> On Mon, Mar 20, 2017 at 6:47 AM, Kristian Amlie
>  wrote:
> > 
> > --
> > 
> > Additionally, in the logs I found these two snippets:
> > 
> > --
> > Considering setscene task: ['go-native', 'do_populate_sysroot']
> >   considering dependency: ['go-native', 'do_populate_sysroot']
> >   considering dependency: ['mender-artifact-native',
> > 'do_populate_sysroot']
> > Adding dependency on go-native
> > ...
> > Considering setscene task: ['go-bootstrap-native',
> > 'do_populate_sysroot']
> >   considering dependency: ['go-native', 'do_populate_sysroot']
> > Adding dependency on go-bootstrap-native
> > --
> > 
> > which lead me to believe that all dependencies are being pulled in
> > simultaneously by do_rootfs, but go-native and go-bootstrap-native
> > are
> > in fact mutually exclusive, since they install to the sysroot in
> > the
> > same location. Note that both compilers build just fine, it's only
> > at
> > the do_rootfs stage that this shows up.
> > 
> > I think the oe-meta-go layer solved this by having go-bootstrap-
> > native
> > install in a different location, but I'm unsure what is the best
> > approach for OE.
> go-bootstrap is only needed for few recipes. I think we should find
> out
> a way to keep this dep limited to those recipes and not reflect in
> final
> image rootfs creation. That seems to be not useful.

There is code in sstate.bbclass in setscene_depvalid:

        # Consider sysroot depending on sysroot tasks
if taskdependees[task][1] == 'do_populate_sysroot' and 
taskdependees[dep][1] == 'do_populate_sysroot':
            [...]
# Nothing need depend on libc-initial/gcc-cross-initial
if "-initial" in taskdependees[task][0]:
continue

so if go-bootstrap-native were renamed go-native-initial, things might
happen to work better...

Cheers,

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

[OE-core] [PATCH] package.bbclass: Add PRIVATE_LIBS to list of package specific variables

[Peter Kjellerstedt]

Changes to PRIVATE_LIBS should change the sstate checksum. To make
that happen, it needs to be listed in the list of package specific
variables, therefore add it.

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/package.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 467f5f1c5a..dd1b316989 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -2011,7 +2011,7 @@ python package_depchains() {
 
 # Since bitbake can't determine which variables are accessed during package
 # iteration, we need to list them here:
-PACKAGEVARS = "FILES RDEPENDS RRECOMMENDS SUMMARY DESCRIPTION RSUGGESTS 
RPROVIDES RCONFLICTS PKG ALLOW_EMPTY pkg_postinst pkg_postrm INITSCRIPT_NAME 
INITSCRIPT_PARAMS DEBIAN_NOAUTONAME ALTERNATIVE PKGE PKGV PKGR USERADD_PARAM 
GROUPADD_PARAM CONFFILES SYSTEMD_SERVICE LICENSE SECTION pkg_preinst pkg_prerm 
RREPLACES GROUPMEMS_PARAM SYSTEMD_AUTO_ENABLE SKIP_FILEDEPS"
+PACKAGEVARS = "FILES RDEPENDS RRECOMMENDS SUMMARY DESCRIPTION RSUGGESTS 
RPROVIDES RCONFLICTS PKG ALLOW_EMPTY pkg_postinst pkg_postrm INITSCRIPT_NAME 
INITSCRIPT_PARAMS DEBIAN_NOAUTONAME ALTERNATIVE PKGE PKGV PKGR USERADD_PARAM 
GROUPADD_PARAM CONFFILES SYSTEMD_SERVICE LICENSE SECTION pkg_preinst pkg_prerm 
RREPLACES GROUPMEMS_PARAM SYSTEMD_AUTO_ENABLE SKIP_FILEDEPS PRIVATE_LIBS"
 
 def gen_packagevar(d):
 ret = []
-- 
2.12.0

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

Re: [OE-core] [morty][PATCH] file: update SRCREV for 5.28 to fix fetch fail on missing commit

[Denys Dmytriyenko]

On Mon, Mar 20, 2017 at 02:55:41PM +, Richard Purdie wrote:
> On Mon, 2017-03-20 at 10:06 -0400, Denys Dmytriyenko wrote:
> > Ping.
> > 
> > This is getting quickly escalated by my teams and customers. Can we
> > merge this 
> > to morty right away? Thanks!
> > 
> > There's another patch for krogoth, that's not as urgent yet, but
> > probably will 
> > be soon too...
> > 
> > BTW, I believe Armin was traveling last week, not sure if he's back
> > yet.
> 
> Thanks for the patches, I'd been away this weekend but having them
> available helped a lot!

Sure, happy to help!

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

Re: [OE-core] [morty][PATCH] file: update SRCREV for 5.28 to fix fetch fail on missing commit

[Richard Purdie]

On Mon, 2017-03-20 at 10:06 -0400, Denys Dmytriyenko wrote:
> Ping.
> 
> This is getting quickly escalated by my teams and customers. Can we
> merge this 
> to morty right away? Thanks!
> 
> There's another patch for krogoth, that's not as urgent yet, but
> probably will 
> be soon too...
> 
> BTW, I believe Armin was traveling last week, not sure if he's back
> yet.

Thanks for the patches, I'd been away this weekend but having them
available helped a lot!

Cheers,

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

Re: [OE-core] [PATCH] binutils: disable gold on mingw

[Khem Raj]

On Mon, Mar 20, 2017 at 5:20 AM, Ross Burton  wrote:
> oe-core 759eed (binutils: Enable threading when gold is enabled and is not
> default linker) causes linking in mingw SDKs to fail:
>
> .../work/i686-nativesdk-mingw32-pokysdk-mingw32/binutils-cross-canadian-x86-64/2.28-r0
> /recipe-sysroot-native/usr/bin/i686-pokysdk-mingw32/../../libexec/i686-pokysdk-mingw32/gcc/i686-pokysdk-mingw32/6.3.0/ld:
> cannot find -lpthread
>

looks ok

> Work around this by disabling gold entirely in mingw SDKs.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/binutils/binutils.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/binutils/binutils.inc 
> b/meta/recipes-devtools/binutils/binutils.inc
> index 37813dd..7efe13f 100644
> --- a/meta/recipes-devtools/binutils/binutils.inc
> +++ b/meta/recipes-devtools/binutils/binutils.inc
> @@ -78,6 +78,7 @@ EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \
>
>  LDGOLD_class-native = ""
>  LDGOLD_class-crosssdk = ""
> +LDGOLD_sdkmingw32 = ""
>  LDGOLD ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
> '--enable-gold=default --enable-threads', '--enable-gold --enable-ld=default 
> --enable-threads', d)}"
>
>  # This is necessary due to a bug in the binutils Makefiles
> --
> 2.8.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] go-bootstrap / go-native conflict during do_rootfs

[Khem Raj]

On Mon, Mar 20, 2017 at 6:47 AM, Kristian Amlie
 wrote:
> First of all, kudos to Khem Raj for the hard work on the go compiler
> support, this will help a lot!
>
> However, I have one problem when my project reaches do_rootfs:
>
> --
> ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Error executing a
> python function in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:extend_recipe_sysroot(d)
>  0003:
> File: '/home/kristian/code/poky/meta/classes/staging.bbclass', lineno:
> 623, function: extend_recipe_sysroot
>  0619:dest = newmanifest[l]
>  0620:if l.endswith("/"):
>  0621:staging_copydir(l, targetdir, dest,
> seendirs)
>  0622:continue
>  *** 0623:staging_copyfile(l, targetdir, dest,
> postinsts, seendirs)
>  0624:
>  0625:for f in fixme:
>  0626:if f == '':
>  0627:staging_processfixme(fixme[f], recipesysroot,
> recipesysroot, recipesysrootnative, d)
> File: '/home/kristian/code/poky/meta/classes/staging.bbclass', lineno:
> 269, function: staging_copyfile
>  0265:os.symlink(linkto, dest)
>  0266:#bb.warn(c)
>  0267:else:
>  0268:try:
>  *** 0269:os.link(c, dest)
>  0270:except OSError as err:
>  0271:if err.errno == errno.EXDEV:
>  0272:bb.utils.copyfile(c, dest)
>  0273:else:
> Exception: FileExistsError: [Errno 17] File exists:
> '/home/kristian/code/poky/build/tmp/sysroots-components/x86_64/go-bootstrap-native/usr/bin/go'
> ->
> '/home/kristian/code/poky/build/tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/go'
>
> ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Function failed:
> extend_recipe_sysroot
> ERROR: Logfile of failure stored in:
> /home/kristian/code/poky/build/tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.18987
> ERROR: Task
> (/home/kristian/code/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 3634 tasks of which 3589 didn't need to
> be rerun and 1 failed.
>
> Summary: 1 task failed:
>
> /home/kristian/code/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs
> Summary: There were 3 WARNING messages shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> --
>
> Additionally, in the logs I found these two snippets:
>
> --
> Considering setscene task: ['go-native', 'do_populate_sysroot']
>   considering dependency: ['go-native', 'do_populate_sysroot']
>   considering dependency: ['mender-artifact-native', 'do_populate_sysroot']
> Adding dependency on go-native
> ...
> Considering setscene task: ['go-bootstrap-native', 'do_populate_sysroot']
>   considering dependency: ['go-native', 'do_populate_sysroot']
> Adding dependency on go-bootstrap-native
> --
>
> which lead me to believe that all dependencies are being pulled in
> simultaneously by do_rootfs, but go-native and go-bootstrap-native are
> in fact mutually exclusive, since they install to the sysroot in the
> same location. Note that both compilers build just fine, it's only at
> the do_rootfs stage that this shows up.
>
> I think the oe-meta-go layer solved this by having go-bootstrap-native
> install in a different location, but I'm unsure what is the best
> approach for OE.

go-bootstrap is only needed for few recipes. I think we should find out
a way to keep this dep limited to those recipes and not reflect in final
image rootfs creation. That seems to be not useful.

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

[OE-core] Yocto Project Status WW12’17

[Jolley, Stephen K]

Current Dev Position: YP 2.3 M4

Next Deadline: YP 2.3 M4 Cutoff is April 10, 2017


*** FEATURE FREEZE for 2.3 is now in effect. ***


SWAT team rotation: Alejandro -> Jussi on Mar. 17, 2017.

SWAT team rotation: Jussi-> Stephano on Mar. 24, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·We ended up merging the smart -> dnf transition for M3 as the build 
issues being encountered were finally resolved. There was a separate email 
about the pros/cons of merging this, we still believe that doing this now was 
better than waiting six months with the transition hanging over our users for 
that length of time.

·M3 is now in QA and all new features have been merged into tree for 
2.3. We have encountered some issues from the HOSTTOOLS change and ended up 
merging a fix to unblock certain QA tests which run in a firewalled  
environment so the exact commit for M3-rc1 is now confused. So far there have 
been a number of issues identified and we believe we will make an rc2 build as 
soon as we’re confident we’ve identified all the key issues and merged fixes 
for them.

·There are a number of ongoing intermittent autobuilder test failures, 
particularly in oe-selftest which we’ve not identified yet. These are looking 
likely from the partially unintended enabling of the sstate cache for the 
selftest runs. We did want to ultimately do this so are choosing to chase down 
the issues rather than disabling it again.

·Since we’re into the stabilization phase of 2.3, planning for 2.4 will 
be beginning soon and we’re starting to plan out 2.4 in the bugzilla. If you 
have suggestions for 2.4, please ensure they are in bugzilla.


Proposed upcoming dot releases:

YP 2.1.3 Cut off May 15, 2017

YP 2.1.3 Release by May 26, 2017

YP 2.2.2 Cut off May 29, 2017

YP 2.2.2 Release by June 9, 2017


Key YP 2.3 Dates:

YP 2.3 M3 Release is Mar. 10, 2017 (Will be a few weeks late.)

YP 2.3 M4 Cutoff is April 10, 2017

YP 2.3 M4 Release is May 5, 2017


Tracking Metrics:

WDD 2751 (last week 2715)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features

[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

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

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

Re: [OE-core] [PATCH 5/6] musl: Update to latest

[Khem Raj]

On Mon, Mar 20, 2017 at 1:32 AM, Jussi Kukkonen
 wrote:
>
> On 15 March 2017 at 01:35, Khem Raj  wrote:
>>
>> Rich Felker (11):
>>   fix ld-behavior-dependent crash in ppc64 ldso startup
>>   rework ldso handling of global symbol table for consistency
>>   reorder addend handling before symbol lookup in relocation code
>>   emulate lazy relocation as deferrable relocation
>>   fix free of uninitialized buffer pointer on error in regexec
>>   in static dl_iterate_phdr, fix use of possibly-uninitialized aux
>> data
>>   fix possible fd leak, unrestored cancellation state on dns socket
>> fail
>>   fix wide scanf's use of a compound literal past its lifetime
>>   fix one-byte overflow in legacy getpass function
>>   avoid loading of multiple libc versions via explicit pathname
>>   remove unused refcnt field for shared libraries
>>
>> Szabolcs Nagy (1):
>>   treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym
>
>
>
> Could the relocation changes here be responsible for these ovmf build
> failures:
>   "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
> ?
>
Dont understand why musl would affect here.
its using native gcc to build the artifacts its complaining about,

> https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio
>
>
> Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [morty][PATCH] file: update SRCREV for 5.28 to fix fetch fail on missing commit

[Denys Dmytriyenko]

On Mon, Mar 20, 2017 at 02:08:58PM +, Burton, Ross wrote:
> On 20 March 2017 at 14:06, Denys Dmytriyenko  wrote:
> 
> > This is getting quickly escalated by my teams and customers. Can we merge
> > this
> > to morty right away? Thanks!
> >
> 
> Morty and Krogoth have been patched now.

Thanks!

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

Re: [OE-core] [morty][PATCH] file: update SRCREV for 5.28 to fix fetch fail on missing commit

[Denys Dmytriyenko]

Ping.

This is getting quickly escalated by my teams and customers. Can we merge this 
to morty right away? Thanks!

There's another patch for krogoth, that's not as urgent yet, but probably will 
be soon too...

BTW, I believe Armin was traveling last week, not sure if he's back yet.

-- 
Denys


On Fri, Mar 17, 2017 at 07:24:00PM -0400, Denys Dmytriyenko wrote:
> From: Paul Gortmaker 
> 
> Machines that cloned a while ago will have the commit, but new
> deployments won't because it seems the upstream changed/rebased
> and the old commit ID has been garbage-collected away.  Hence
> the fetch fails to check out the named commit ID.
> 
> Both the old (gone) commit, and the "new" commit show the same
> dates and commit log and point at 5.28, so hopefully this is
> the right thing to do.  A git diff of the two seems to only show
> a blanket uprev of CVS tags and deletion of a couple autogen'd
> files, and no real source changes.
> 
> (From OE-Core rev: adb71e06768adadda7b69c3b5e81ca3ad67237f4)
> 
> Cc: Christos Zoulas 
> Signed-off-by: Paul Gortmaker 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Denys Dmytriyenko 
> ---
>  meta/recipes-devtools/file/file_5.28.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/file/file_5.28.bb 
> b/meta/recipes-devtools/file/file_5.28.bb
> index e64a89c..048fb8e 100644
> --- a/meta/recipes-devtools/file/file_5.28.bb
> +++ b/meta/recipes-devtools/file/file_5.28.bb
> @@ -19,7 +19,7 @@ SRC_URI = "git://github.com/file/file.git \
>  file://0001-Add-P-prompt-into-Usage-info.patch \
>  "
>  
> -SRCREV = "3c521817322a6bf5160cfeb09b9145ccde587b2a"
> +SRCREV = "acbaf156236cbc54b3cf3bc6cbf05d80cb196451"
>  S = "${WORKDIR}/git"
>  
>  inherit autotools
> -- 
> 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

Re: [OE-core] [morty][PATCH] file: update SRCREV for 5.28 to fix fetch fail on missing commit

[Burton, Ross]

On 20 March 2017 at 14:06, Denys Dmytriyenko  wrote:

> This is getting quickly escalated by my teams and customers. Can we merge
> this
> to morty right away? Thanks!
>

Morty and Krogoth have been patched now.

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

Re: [OE-core] Status of usrmerge merger

[Burton, Ross]

On 18 March 2017 at 22:25, Anton Gerasimov 
wrote:

> what is the current status of the usrmerge patch [1]? It was submitted
> quite a long time ago and I can't find any discussion about it. If there
> is something I can do to help with testing/tweaking to get it merged
> please let me know.
>

The bulk of the patches have been merged now, the only outstanding ones are
the actual changes to bitbake.conf to add a distro feature.

I'm not massively keen on how it's been implemented but right now don't
have a better solution.  Either way, with 2.3 (releasing next month) you
can trivially setup usrmerge by just fidding the paths in your distro.

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

[OE-core] go-bootstrap / go-native conflict during do_rootfs

[Kristian Amlie]

First of all, kudos to Khem Raj for the hard work on the go compiler
support, this will help a lot!

However, I have one problem when my project reaches do_rootfs:

--
ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Error executing a
python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:extend_recipe_sysroot(d)
 0003:
File: '/home/kristian/code/poky/meta/classes/staging.bbclass', lineno:
623, function: extend_recipe_sysroot
 0619:dest = newmanifest[l]
 0620:if l.endswith("/"):
 0621:staging_copydir(l, targetdir, dest,
seendirs)
 0622:continue
 *** 0623:staging_copyfile(l, targetdir, dest,
postinsts, seendirs)
 0624:
 0625:for f in fixme:
 0626:if f == '':
 0627:staging_processfixme(fixme[f], recipesysroot,
recipesysroot, recipesysrootnative, d)
File: '/home/kristian/code/poky/meta/classes/staging.bbclass', lineno:
269, function: staging_copyfile
 0265:os.symlink(linkto, dest)
 0266:#bb.warn(c)
 0267:else:
 0268:try:
 *** 0269:os.link(c, dest)
 0270:except OSError as err:
 0271:if err.errno == errno.EXDEV:
 0272:bb.utils.copyfile(c, dest)
 0273:else:
Exception: FileExistsError: [Errno 17] File exists:
'/home/kristian/code/poky/build/tmp/sysroots-components/x86_64/go-bootstrap-native/usr/bin/go'
->
'/home/kristian/code/poky/build/tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/go'

ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Function failed:
extend_recipe_sysroot
ERROR: Logfile of failure stored in:
/home/kristian/code/poky/build/tmp/work/vexpress_qemu-poky-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.18987
ERROR: Task
(/home/kristian/code/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 3634 tasks of which 3589 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:

/home/kristian/code/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs
Summary: There were 3 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
--

Additionally, in the logs I found these two snippets:

--
Considering setscene task: ['go-native', 'do_populate_sysroot']
  considering dependency: ['go-native', 'do_populate_sysroot']
  considering dependency: ['mender-artifact-native', 'do_populate_sysroot']
Adding dependency on go-native
...
Considering setscene task: ['go-bootstrap-native', 'do_populate_sysroot']
  considering dependency: ['go-native', 'do_populate_sysroot']
Adding dependency on go-bootstrap-native
--

which lead me to believe that all dependencies are being pulled in
simultaneously by do_rootfs, but go-native and go-bootstrap-native are
in fact mutually exclusive, since they install to the sysroot in the
same location. Note that both compilers build just fine, it's only at
the do_rootfs stage that this shows up.

I think the oe-meta-go layer solved this by having go-bootstrap-native
install in a different location, but I'm unsure what is the best
approach for OE.

Thoughts?

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

Re: [OE-core] Error after updating Poky

[Gary Thomas]

On 2017-03-20 13:58, Burton, Ross wrote:


On 20 March 2017 at 12:50, Gary Thomas > wrote:

Thanks, that did fix it.

I see that those recipe-sysroot* trees are kept around (I don't run rm_work)
For one of my builds which has ~475 packages in tmp/work, they amount to 7GB
Is there any way to prune them?


It's all hardlinks, so be careful how you count.


I didn't realize that!  Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 3/3] meta: images: Add fsck to avoid corrupt EXT file systems

[Burton, Ross]

On 20 March 2017 at 13:01, Daniel Schultz  wrote:

> Doesn't mkfs returns an exit code if it wasn't successful?
>>
>> Yes, but it seems like mkfs can't handle everything.
>
> "The htree (hash tree) indexes directory entries by hash to speed up
> random directory accesses.  e2fsck can regenerate the indices, but the
> rest of e2fsprogs cannot create or maintain them."
> [http://www.spinics.net/lists/linux-ext4/msg55702.html]
>
> Currently, our boards have to reboot, because fsck exits with an error
> code of 1 at the first boot.
>

Fair enough, thanks.

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

Re: [OE-core] [PATCH 3/3] meta: images: Add fsck to avoid corrupt EXT file systems

[Daniel Schultz]

Am 20.03.2017 um 13:26 schrieb Burton, Ross:


On 20 March 2017 at 12:18, Daniel Schultz > wrote:

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.


Doesn't mkfs returns an exit code if it wasn't successful?


Yes, but it seems like mkfs can't handle everything.

"The htree (hash tree) indexes directory entries by hash to speed up
random directory accesses.  e2fsck can regenerate the indices, but the
rest of e2fsprogs cannot create or maintain them."
[http://www.spinics.net/lists/linux-ext4/msg55702.html]

Currently, our boards have to reboot, because fsck exits with an error 
code of 1 at the first boot.



Ross


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Error after updating Poky

[Burton, Ross]

On 20 March 2017 at 12:50, Gary Thomas  wrote:

> Thanks, that did fix it.
>
> I see that those recipe-sysroot* trees are kept around (I don't run
> rm_work)
> For one of my builds which has ~475 packages in tmp/work, they amount to
> 7GB
> Is there any way to prune them?
>

It's all hardlinks, so be careful how you count.

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

Re: [OE-core] Error after updating Poky

[Gary Thomas]

On 2017-03-20 13:21, Patrick Ohly wrote:

On Mon, 2017-03-20 at 13:12 +0100, Gary Thomas wrote:

I just updated to the latest Poky master (7e0985bab68547) which
replaced rpm-5.4 with rpm-4.13.90 (git).  My builds in an existing
tree now fail:

|
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so:
file not recognized: File format not recognized
| collect2: error: ld returned 1 exit status
| ext/CMakeFiles/libsolvext.dir/build.make:285: recipe for target 
'ext/libsolvext.so.0' failed
| make[2]: *** [ext/libsolvext.so.0] Error 1
| make[2]: Leaving directory 
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| CMakeFiles/Makefile2:207: recipe for target 
'ext/CMakeFiles/libsolvext.dir/all' failed
| make[1]: *** [ext/CMakeFiles/libsolvext.dir/all] Error 2
| make[1]: Leaving directory 
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| Makefile:163: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/temp/log.do_compile.8183)
ERROR: Task 
(/local/poky-cutting-edge/meta/recipes-extended/libsolv/libsolv_0.6.26.bb:do_compile)
 failed with exit code '1'

Looking at this file shows it's a stale symlink:
$ file
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so:
symbolic link to librpmdb-5.4.so
$ file `readlink
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so`
librpmdb-5.4.so: cannot open `librpmdb-5.4.so' (No such file or directory)

Any ideas how to fix this?


The code maintaining the recipe specific sysroots does not always keep
the sysroots in sync with what they should contain, primarily because it
is limited to updating them instead of (at least sometimes) starting
from scratch.

Probably a "bitbake -c clean libsolv && bitbake libsolv" will help in
your case. If it doesn't, try "rm -rf tmp" next (might be faster and
easier too, if more recipes are affected).



Thanks, that did fix it.

I see that those recipe-sysroot* trees are kept around (I don't run rm_work)
For one of my builds which has ~475 packages in tmp/work, they amount to 7GB
Is there any way to prune them?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 3/3] meta: images: Add fsck to avoid corrupt EXT file systems

[Burton, Ross]

On 20 March 2017 at 12:18, Daniel Schultz  wrote:

> Since there are no checks if a EXT file system was successfully created,
> this should add to prevent possible system failures.
>

Doesn't mkfs returns an exit code if it wasn't successful?

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

[OE-core] [PATCH] image-buildinfo.bbclass: configurable location for build file

[Patrick Ohly]

In a stateless image, /etc is not a good place for the "build"
file. By definining the location with a variable it becomes possible
to have the file created elsewhere on a per-image basis. The default
is the same as before.

Signed-off-by: Patrick Ohly 
---
 meta/classes/image-buildinfo.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image-buildinfo.bbclass 
b/meta/classes/image-buildinfo.bbclass
index 85626f0..213fb9c 100644
--- a/meta/classes/image-buildinfo.bbclass
+++ b/meta/classes/image-buildinfo.bbclass
@@ -12,6 +12,9 @@
 # Desired variables to display 
 IMAGE_BUILDINFO_VARS ?= "DISTRO DISTRO_VERSION"
 
+# Desired location of the output file in the image.
+IMAGE_BUILDINFO_FILE ??= "${sysconfdir}/build"
+
 # From buildhistory.bbclass
 def image_buildinfo_outputvars(vars, listvars, d): 
 vars = vars.split()
@@ -61,7 +64,7 @@ def buildinfo_target(d):
 
 # Write build information to target filesystem
 python buildinfo () {
-with open(d.expand('${IMAGE_ROOTFS}${sysconfdir}/build'), 'w') as build:
+with open(d.expand('${IMAGE_ROOTFS}${IMAGE_BUILDINFO_FILE}'), 'w') as 
build:
 build.writelines((
 '''---
 Build Configuration:  |

base-commit: 6b9dd7a589537b12da648be50298cf7d36461797
-- 
git-series 0.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/6] binutils: Enable threading when gold is enabled and is not default linker

[Burton, Ross]

On 14 March 2017 at 23:35, Khem Raj  wrote:

> Currently we enable threaded linking feature of gold linker only
> when its used as default ld. There is no need to restrict it when
> its not default linker either. As long as gold is enabled, which
> is the case here, we should be able to do threaded linking.
>

Turns out this broke meta-mingw's Windows SDKS (reproducible if you
set SDKMACHINE = "i686-mingw32" and build binutils-cross).  I've sent a
patch to set LDGOLD to '' on mingw, but your comments are welcome on
alternative fixes.

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

Re: [OE-core] Error after updating Poky

[Patrick Ohly]

On Mon, 2017-03-20 at 13:12 +0100, Gary Thomas wrote:
> I just updated to the latest Poky master (7e0985bab68547) which
> replaced rpm-5.4 with rpm-4.13.90 (git).  My builds in an existing
> tree now fail:
> 
> | 
> /build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so:
>  
> file not recognized: File format not recognized
> | collect2: error: ld returned 1 exit status
> | ext/CMakeFiles/libsolvext.dir/build.make:285: recipe for target 
> 'ext/libsolvext.so.0' failed
> | make[2]: *** [ext/libsolvext.so.0] Error 1
> | make[2]: Leaving directory 
> '/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
> | CMakeFiles/Makefile2:207: recipe for target 
> 'ext/CMakeFiles/libsolvext.dir/all' failed
> | make[1]: *** [ext/CMakeFiles/libsolvext.dir/all] Error 2
> | make[1]: Leaving directory 
> '/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
> | Makefile:163: recipe for target 'all' failed
> | make: *** [all] Error 2
> | ERROR: Function failed: do_compile (log file is located at 
> /build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/temp/log.do_compile.8183)
> ERROR: Task 
> (/local/poky-cutting-edge/meta/recipes-extended/libsolv/libsolv_0.6.26.bb:do_compile)
>  failed with exit code '1'
> 
> Looking at this file shows it's a stale symlink:
> $ file 
> /build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so
> /build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so:
>  
> symbolic link to librpmdb-5.4.so
> $ file `readlink 
> /build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so`
> librpmdb-5.4.so: cannot open `librpmdb-5.4.so' (No such file or directory)
> 
> Any ideas how to fix this?

The code maintaining the recipe specific sysroots does not always keep
the sysroots in sync with what they should contain, primarily because it
is limited to updating them instead of (at least sometimes) starting
from scratch.

Probably a "bitbake -c clean libsolv && bitbake libsolv" will help in
your case. If it doesn't, try "rm -rf tmp" next (might be faster and
easier too, if more recipes are affected).

-- 
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] binutils: disable gold on mingw

[Ross Burton]

oe-core 759eed (binutils: Enable threading when gold is enabled and is not
default linker) causes linking in mingw SDKs to fail:

.../work/i686-nativesdk-mingw32-pokysdk-mingw32/binutils-cross-canadian-x86-64/2.28-r0
/recipe-sysroot-native/usr/bin/i686-pokysdk-mingw32/../../libexec/i686-pokysdk-mingw32/gcc/i686-pokysdk-mingw32/6.3.0/ld:
cannot find -lpthread

Work around this by disabling gold entirely in mingw SDKs.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/binutils/binutils.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/binutils/binutils.inc 
b/meta/recipes-devtools/binutils/binutils.inc
index 37813dd..7efe13f 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -78,6 +78,7 @@ EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \
 
 LDGOLD_class-native = ""
 LDGOLD_class-crosssdk = ""
+LDGOLD_sdkmingw32 = ""
 LDGOLD ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
'--enable-gold=default --enable-threads', '--enable-gold --enable-ld=default 
--enable-threads', d)}"
 
 # This is necessary due to a bug in the binutils Makefiles
-- 
2.8.1

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

[OE-core] [PATCH 3/3] meta: images: Add fsck to avoid corrupt EXT file systems

[Daniel Schultz]

This patch avoids the creation of a corrupt EXT file system.

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.

Signed-off-by: Daniel Schultz 
---
 meta/classes/image_types.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index d2eb99d..66c643d 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -74,6 +74,7 @@ oe_mkext234fs () {
# Create a sparse image block
dd if=/dev/zero 
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE 
count=$COUNT bs=1024
mkfs.$fstype -F $extra_imagecmd 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}
+   fsck.$fstype -fy 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype
 }
 
 IMAGE_CMD_ext2 = "oe_mkext234fs ext2 ${EXTRA_IMAGECMD}"
-- 
1.9.1

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

[OE-core] [PATCH 1/3] e2fsprogs: Fix wrong error code after optimization

[Daniel Schultz]

fsck.ext will return an error code of 1 if a file systems was checked
and successfully repaired. Even when an optimization was performed it
will return this error code.

This patch will change the error code to 0 if only optimizations had
changed the file systems.

The reason for this patch is a question I asked at the ext4 ML:
http://www.spinics.net/lists/linux-ext4/msg55700.html

Backport from git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
Based on commit bf9f3b6d5b10d19218b4ed904c12b22e36ec57dd

Signed-off-by: Daniel Schultz 
---
 ...-with-exit-status-0-if-no-errors-were-fix.patch | 255 +
 .../recipes-devtools/e2fsprogs/e2fsprogs_1.43.4.bb |   1 +
 2 files changed, 256 insertions(+)
 create mode 100644 
meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch

diff --git 
a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
new file mode 100644
index 000..1d17520
--- /dev/null
+++ 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch
@@ -0,0 +1,255 @@
+From bf9f3b6d5b10d19218b4ed904c12b22e36ec57dd Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o 
+Date: Thu, 16 Feb 2017 22:02:35 -0500
+Subject: [PATCH] e2fsck: exit with exit status 0 if no errors were fixed
+
+Previously, e2fsck would exit with a status code of 1 even though the
+only changes that it made to the file system were various
+optimziations and not fixing file system corruption.  Since the man
+page states that an exit status of 1 means "file system errors
+corrupted", fix e2fsck to return an exit status of 0.
+
+Upstream-Status: Backport
+
+Signed-off-by: Theodore Ts'o 
+Signed-off-by: Daniel Schultz 
+---
+ e2fsck/e2fsck.conf.5.in |  7 +++
+ e2fsck/journal.c|  1 +
+ e2fsck/problem.c|  8 +---
+ e2fsck/problemP.h   |  1 +
+ e2fsck/unix.c   | 20 
+ tests/f_collapse_extent_tree/expect.1   |  2 +-
+ tests/f_compress_extent_tree_level/expect.1 |  2 +-
+ tests/f_convert_bmap/expect.1   |  2 +-
+ tests/f_convert_bmap_and_extent/expect.1|  2 +-
+ tests/f_extent_htree/expect.1   |  2 +-
+ tests/f_jnl_errno/expect.1  |  2 +-
+ tests/f_journal/expect.1|  2 +-
+ tests/f_orphan/expect.1 |  2 +-
+ tests/f_orphan_extents_inode/expect.1   |  2 +-
+ tests/f_rehash_dir/expect.1 |  2 +-
+ tests/f_unsorted_EAs/expect.1   |  2 +-
+ 16 files changed, 41 insertions(+), 18 deletions(-)
+
+diff --git a/e2fsck/e2fsck.conf.5.in b/e2fsck/e2fsck.conf.5.in
+index 1848bdb..0bfc76a 100644
+--- a/e2fsck/e2fsck.conf.5.in
 b/e2fsck/e2fsck.conf.5.in
+@@ -303,6 +303,13 @@ of 'should this problem be fixed?'.  The
+ option even overrides the
+ .B -y
+ option given on the command-line (just for the specific problem, of course).
++.TP
++.I not_a_fix
++This boolean option, it set to true, marks the problem as
++one where if the user gives permission to make the requested change,
++it does not mean that the file system had a problem which has since
++been fixed.  This is used for requests to optimize the file system's
++data structure, such as pruning an extent tree.
+ @TDB_MAN_COMMENT@.SH THE [scratch_files] STANZA
+ @TDB_MAN_COMMENT@The following relations are defined in the
+ @TDB_MAN_COMMENT@.I [scratch_files]
+diff --git a/e2fsck/journal.c b/e2fsck/journal.c
+index 46fe7b4..c4f58f1 100644
+--- a/e2fsck/journal.c
 b/e2fsck/journal.c
+@@ -572,6 +572,7 @@ static void clear_v2_journal_fields(journal_t *journal)
+   if (!fix_problem(ctx, PR_0_CLEAR_V2_JOURNAL, ))
+   return;
+ 
++  ctx->flags |= E2F_FLAG_PROBLEMS_FIXED;
+   memset(((char *) journal->j_superblock) + V1_SB_SIZE, 0,
+  ctx->fs->blocksize-V1_SB_SIZE);
+   mark_buffer_dirty(journal->j_sb_buffer);
+diff --git a/e2fsck/problem.c b/e2fsck/problem.c
+index 34a671e..4b25069 100644
+--- a/e2fsck/problem.c
 b/e2fsck/problem.c
+@@ -1276,12 +1276,12 @@ static struct e2fsck_problem problem_table[] = {
+   /* Inode extent tree could be shorter */
+   { PR_1E_CAN_COLLAPSE_EXTENT_TREE,
+ N_("@i %i @x tree (at level %b) could be shorter.  "),
+-PROMPT_FIX, PR_NO_OK | PR_PREEN_NO | PR_PREEN_OK },
++PROMPT_FIX, PR_NO_OK | PR_PREEN_NO | PR_PREEN_OK | PR_NOT_A_FIX },
+ 
+   /* Inode extent tree could be narrower */
+   { PR_1E_CAN_NARROW_EXTENT_TREE,
+ N_("@i %i @x tree (at level %b) could be narrower.  "),
+-PROMPT_FIX, PR_NO_OK | PR_PREEN_NO | PR_PREEN_OK },
++PROMPT_FIX, PR_NO_OK | 

[OE-core] [PATCH 2/3] wic: partition.py: Add fsck to avoid corrupt EXT file systems

[Daniel Schultz]

This patch avoids the creation of a corrupt EXT file system.

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.

Signed-off-by: Daniel Schultz 
---
 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 6ef8d7f..8e32afc 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -286,6 +286,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
+mkfs_cmd = "fsck.%s -fy %s" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """
-- 
1.9.1

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

[OE-core] Error after updating Poky

[Gary Thomas]

I just updated to the latest Poky master (7e0985bab68547) which
replaced rpm-5.4 with rpm-4.13.90 (git).  My builds in an existing
tree now fail:

| 
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so: 
file not recognized: File format not recognized

| collect2: error: ld returned 1 exit status
| ext/CMakeFiles/libsolvext.dir/build.make:285: recipe for target 
'ext/libsolvext.so.0' failed
| make[2]: *** [ext/libsolvext.so.0] Error 1
| make[2]: Leaving directory 
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| CMakeFiles/Makefile2:207: recipe for target 
'ext/CMakeFiles/libsolvext.dir/all' failed
| make[1]: *** [ext/CMakeFiles/libsolvext.dir/all] Error 2
| make[1]: Leaving directory 
'/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/build'
| Makefile:163: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at 
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/temp/log.do_compile.8183)

ERROR: Task 
(/local/poky-cutting-edge/meta/recipes-extended/libsolv/libsolv_0.6.26.bb:do_compile)
 failed with exit code '1'

Looking at this file shows it's a stale symlink:
$ file 
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so: 
symbolic link to librpmdb-5.4.so
$ file `readlink 
/build/p7619_2016-02-23/tmp/work/cortexa7hf-neon-amltd-linux-gnueabi/libsolv/0.6.26-r0/recipe-sysroot-native/usr/lib/librpmdb.so`

librpmdb-5.4.so: cannot open `librpmdb-5.4.so' (No such file or directory)

Any ideas how to fix this?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30

[Jussi Kukkonen]

On 20 March 2017 at 13:29, Manjukumar Harthikote Matha <
manjukumar.harthikote-ma...@xilinx.com> wrote:

>
>
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> > Robert Yang
> > Sent: Monday, March 20, 2017 3:14 PM
> > To: Stefano Babic; openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30
> >
> > Yes, file's upstream commit ID has changed, Paul has sent a patch for it:
> >
> > http://lists.openembedded.org/pipermail/openembedded-core/2017-
> > March/134261.html
> >
>
> Is it better to use nobranch=1 ?
> Changes in this file.git has broken Morty as well, we used nobranch=1 to
> resolve this issue.
> I haven't tested this for other released versions of Yocto.
>

This is band-aid at best: If you do a "cleanall" to force a new clone the
commits likely won't be there anymore.

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

Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30

[Stefano Babic]

On 20/03/2017 12:29, Manjukumar Harthikote Matha wrote:
> 
> 
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Robert Yang
>> Sent: Monday, March 20, 2017 3:14 PM
>> To: Stefano Babic; openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30
>>
>> Yes, file's upstream commit ID has changed, Paul has sent a patch for it:
>>
>> http://lists.openembedded.org/pipermail/openembedded-core/2017-
>> March/134261.html
>>
> 
> Is it better to use nobranch=1 ?

Is it ? I would prefer to not skip test, just fix the issues.

> Changes in this file.git has broken Morty as well, we used nobranch=1 to 
> resolve this issue.

But which revision is taken in your build ? IMHO it is better to fix the
revision as Paul does in his patch.

> I haven't tested this for other released versions of Yocto.

I tested -krogoth, -morty and -master, all of them are broken.

Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30

[Manjukumar Harthikote Matha]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Robert Yang
> Sent: Monday, March 20, 2017 3:14 PM
> To: Stefano Babic; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30
>
> Yes, file's upstream commit ID has changed, Paul has sent a patch for it:
>
> http://lists.openembedded.org/pipermail/openembedded-core/2017-
> March/134261.html
>

Is it better to use nobranch=1 ?
Changes in this file.git has broken Morty as well, we used nobranch=1 to 
resolve this issue.
I haven't tested this for other released versions of Yocto.

Thanks
Manju

> // Robert
>
> On 03/20/2017 05:14 PM, Stefano Babic wrote:
> > On 22/02/2017 02:44, Robert Yang wrote:
> >> Signed-off-by: Robert Yang 
> >> ---
> >>  meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>  rename meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} (96%)
> >>
> >> diff --git a/meta/recipes-devtools/file/file_5.29.bb b/meta/recipes-
> devtools/file/file_5.30.bb
> >> similarity index 96%
> >> rename from meta/recipes-devtools/file/file_5.29.bb
> >> rename to meta/recipes-devtools/file/file_5.30.bb
> >> index 29af8748150..0998fcfa899 100644
> >> --- a/meta/recipes-devtools/file/file_5.29.bb
> >> +++ b/meta/recipes-devtools/file/file_5.30.bb
> >> @@ -19,7 +19,7 @@ SRC_URI = "git://github.com/file/file.git \
> >>  file://0001-Add-P-prompt-into-Usage-info.patch \
> >>  "
> >>
> >> -SRCREV = "015b0cdce1a0abb68ab99510e7fc8d2f77e8ec77"
> >> +SRCREV = "79814950aafb81ecd6a910c2a8a3b8ec12f3e4a6"
> >>  S = "${WORKDIR}/git"
> >>
> >>  inherit autotools
> >>
> >
> > Strange enough, it seems that the tree loses the history and all SRCREV
> > are wrong. I tried with -krogoth, -morty, -master, and no revision
> > number is found. In fact, after cloning the tree I see that all revision
> > number were changed, just a couple here:
> >
> > 5.25 is now : 789cfc7d727cee1c7cfb7d29c09162e2399285c5
> >
> > 5.30 (this patch) : 3050419355566d2a96c5be97fef0ffae097bbb96
> >
> > Ok, I fix this in my layer with a .bbappend, but...Of course, all builds
> > are broken - have you seen the same effect ?
> >
> > Best regards,
> > Stefano
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


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] what are OE's options for a PPTP server to use instead of poptop?

[Robert P. J. Day]

  colleague wants to add a PPTP server to image, and is familiar with
poptop which (AFAICT) is not listed in the current "supported" OE
recipes. i found a recipe for it:

http://cgit.openembedded.org/openembedded/plain/recipes/poptop/poptop_1.3.4.bb

but i note that do_install_append() suggests the logwtmp module is
broken.

  while poking at that, are there more current solutions to provide
the same functionality? i can see "connman" with the option:

  PACKAGECONFIG[pptp] = "--enable-pptp
--with-pptp=${sbindir}/pptp,--disable-pptp,,pptp-linux"

  i see also accel-ppp, but it claims to be currently blacklisted:

  http://layers.openembedded.org/layerindex/recipe/2315/

anyway, suggestions for equivalent PPTP servers to poptop? thank you
kindly.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [OE-core] [PATCH 5/6] musl: Update to latest

[Patrick Ohly]

On Mon, 2017-03-20 at 10:32 +0200, Jussi Kukkonen wrote:
> 
> On 15 March 2017 at 01:35, Khem Raj  wrote:
> Rich Felker (11):
>   fix ld-behavior-dependent crash in ppc64 ldso startup
>   rework ldso handling of global symbol table for
> consistency
>   reorder addend handling before symbol lookup in
> relocation code
>   emulate lazy relocation as deferrable relocation
>   fix free of uninitialized buffer pointer on error in
> regexec
>   in static dl_iterate_phdr, fix use of
> possibly-uninitialized aux data
>   fix possible fd leak, unrestored cancellation state on
> dns socket fail
>   fix wide scanf's use of a compound literal past its
> lifetime
>   fix one-byte overflow in legacy getpass function
>   avoid loading of multiple libc versions via explicit
> pathname
>   remove unused refcnt field for shared libraries
> 
> Szabolcs Nagy (1):
>   treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in
> find_sym
> 
> 
> 
> 
> Could the relocation changes here be responsible for these ovmf build
> failures:
>   "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
> ?
> 
> 
> https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio

That looks like a good guess.

I had tried to reproduce that error last week with poky/master-next, but
somehow it didn't trigger in my local setup.

I have no idea how to enhance ovmf such that can handle this, though.
Holding back an update of musl until someone can figure it out does not
very attractive. But nor is disabling the building of ovmf when musl is
selected, because then the wic tests which rely on ovmf will fail or
also need to get disabled.

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

Re: [OE-core] [PATCH 4/6] oeqa/targetcontrol.py: modify it to test runqemu

[Robert Yang]

On 03/17/2017 07:54 PM, Richard Purdie wrote:

On Thu, 2017-03-16 at 03:13 -0700, Robert Yang wrote:

Modify the following files to test runqemu:
targetcontrol.py
utils/commands.py
utils/qemurunner.py

We need simulate how "runqemu" works in command line, so when test
"runqemu", the targetcontrol.py, utils/commands.py and
utils/qemurunner.py don't have to find the rootfs or set env vars.

[YOCTO #10249]

Signed-off-by: Robert Yang 
---
 meta/lib/oeqa/targetcontrol.py| 20 +++-
 meta/lib/oeqa/utils/commands.py   | 13 +++--
 meta/lib/oeqa/utils/qemurunner.py | 28 +---
 3 files changed, 43 insertions(+), 18 deletions(-)


This change breaks "oe-selftest -r wic.Wic.test_qemu_efi" which just
hangs afterwards.


Sorry, I will fix it.

// Robert



Cheers,

Richard


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

Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30

[Robert Yang]

Yes, file's upstream commit ID has changed, Paul has sent a patch for it:

http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134261.html

// Robert

On 03/20/2017 05:14 PM, Stefano Babic wrote:

On 22/02/2017 02:44, Robert Yang wrote:

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} (96%)

diff --git a/meta/recipes-devtools/file/file_5.29.bb 
b/meta/recipes-devtools/file/file_5.30.bb
similarity index 96%
rename from meta/recipes-devtools/file/file_5.29.bb
rename to meta/recipes-devtools/file/file_5.30.bb
index 29af8748150..0998fcfa899 100644
--- a/meta/recipes-devtools/file/file_5.29.bb
+++ b/meta/recipes-devtools/file/file_5.30.bb
@@ -19,7 +19,7 @@ SRC_URI = "git://github.com/file/file.git \
 file://0001-Add-P-prompt-into-Usage-info.patch \
 "

-SRCREV = "015b0cdce1a0abb68ab99510e7fc8d2f77e8ec77"
+SRCREV = "79814950aafb81ecd6a910c2a8a3b8ec12f3e4a6"
 S = "${WORKDIR}/git"

 inherit autotools



Strange enough, it seems that the tree loses the history and all SRCREV
are wrong. I tried with -krogoth, -morty, -master, and no revision
number is found. In fact, after cloning the tree I see that all revision
number were changed, just a couple here:

5.25 is now : 789cfc7d727cee1c7cfb7d29c09162e2399285c5

5.30 (this patch) : 3050419355566d2a96c5be97fef0ffae097bbb96

Ok, I fix this in my layer with a .bbappend, but...Of course, all builds
are broken - have you seen the same effect ?

Best regards,
Stefano


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

Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30

[Jussi Kukkonen]

On 20 March 2017 at 11:14, Stefano Babic  wrote:
>
> On 22/02/2017 02:44, Robert Yang wrote:
> > Signed-off-by: Robert Yang 
> > ---
> >  meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >  rename meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} (96%)
> >
> > diff --git a/meta/recipes-devtools/file/file_5.29.bb
b/meta/recipes-devtools/file/file_5.30.bb
> > similarity index 96%
> > rename from meta/recipes-devtools/file/file_5.29.bb
> > rename to meta/recipes-devtools/file/file_5.30.bb
> > index 29af8748150..0998fcfa899 100644
> > --- a/meta/recipes-devtools/file/file_5.29.bb
> > +++ b/meta/recipes-devtools/file/file_5.30.bb
> > @@ -19,7 +19,7 @@ SRC_URI = "git://github.com/file/file.git \
> >  file://0001-Add-P-prompt-into-Usage-info.patch \
> >  "
> >
> > -SRCREV = "015b0cdce1a0abb68ab99510e7fc8d2f77e8ec77"
> > +SRCREV = "79814950aafb81ecd6a910c2a8a3b8ec12f3e4a6"
> >  S = "${WORKDIR}/git"
> >
> >  inherit autotools
> >
>
> Strange enough, it seems that the tree loses the history and all SRCREV
> are wrong. I tried with -krogoth, -morty, -master, and no revision
> number is found. In fact, after cloning the tree I see that all revision
> number were changed, just a couple here:
>
> 5.25 is now : 789cfc7d727cee1c7cfb7d29c09162e2399285c5
>
> 5.30 (this patch) : 3050419355566d2a96c5be97fef0ffae097bbb96
>
> Ok, I fix this in my layer with a .bbappend, but...Of course, all builds
> are broken - have you seen the same effect ?


Paul Gortmakers fix "update SRCREV for 5.30 to fix fetch fail on missing
commit" is in master. Similar fixes should be sent to release branches as
well.

It may have been a mistake to start using an unofficial git repo as the
source ... but the original reasoning was that the ftp site was unreliable.
The upstream version control being CVS means that we've got three choices,
none of them good.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/4] kernel.bbclass: handle kernel-vmlinux in KERNEL_IMAGETYPES

[Andrea Adami]

On Sun, Mar 19, 2017 at 2:13 PM,   wrote:
> From: Ming Liu 
>
> There is a mess after KERNEL_IMAGETYPES was introduced in commit 849b67b2:
> [ kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time ]
>
> There are two packages both providing vmlinux image if 'vmlinux' is set in
> KERNEL_IMAGETYPES, they are kernel-vmlinux and kernel-image-vmlinux, to
> let them to be able to coexist, kernel-image-vmlinux was set to empty
> allowable, but its postinst/postrm scripts still remain trying to install/rm
> a update-alternatives link to /boot/vmlinux-${KERNEL_VERSION_NAME} but that
> file is actually being provided by the other package kernel-vmlinux.
>
> Fixed this mess by appending vmlinux to KERNEL_IMAGETYPES and process it
> in anonymous python function. It would not change the original behavior,
> all the generated packages would be same with before except that the
> ALLOW_EMPTY variable, it is removed in this patch.

Hi,

I am testing the 'old-style' of embedding the initramfs in the images [1].
Your patch does add 'vmlinux' even if we have KERNEL_IMAGETYPE ?= "zImage"
so it leads to the following error:

| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_deploy
| install: cannot stat 'arch/arm/boot/vmlinux': No such file or director

The solution for our custom kernel recipe is:

inherit kernel
addtask kernel_link_images after do_compile before do_strip

as done in linux-yocto.inc.

So with this little adjustment it is still possible to build in the old-way.

I didn't test yet the other part of the patchset so I cannot fully ack it.
FWIW I never liked the *BUNDLE framework for the need of specifying
the INITRAMFS_IMAGE in a conf file and not in the kernel recipe as
done with the old framework.

Cheers
Andrea

[1] 
http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-gcw0-kexecboot_4.7.bb


>
> Signed-off-by: Ming Liu 
> ---
>  meta/classes/kernel.bbclass | 47 
> +++--
>  1 file changed, 20 insertions(+), 27 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 6905a9b..1a4335c 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -14,6 +14,7 @@ OE_TERMINAL_EXPORTS += "KBUILD_OUTPUT"
>  # we include gcc above, we dont need virtual/libc
>  INHIBIT_DEFAULT_DEPS = "1"
>
> +KERNEL_IMAGETYPES_append = " vmlinux"
>  KERNEL_IMAGETYPE ?= "zImage"
>  INITRAMFS_IMAGE ?= ""
>  INITRAMFS_IMAGE_NAME ?= "${@['${INITRAMFS_IMAGE}-${MACHINE}', 
> ''][d.getVar('INITRAMFS_IMAGE') == '']}"
> @@ -35,38 +36,33 @@ python __anonymous () {
>  import re
>
>  # Merge KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES
> -type = d.getVar('KERNEL_IMAGETYPE') or ""
> -alttype = d.getVar('KERNEL_ALT_IMAGETYPE') or ""
> -types = d.getVar('KERNEL_IMAGETYPES') or ""
> -if type not in types.split():
> -types = (type + ' ' + types).strip()
> -if alttype not in types.split():
> -types = (alttype + ' ' + types).strip()
> +types = set((d.getVar('KERNEL_IMAGETYPES') or "").split())
> +types.add(d.getVar('KERNEL_IMAGETYPE') or "")
> +types.add(d.getVar('KERNEL_ALT_IMAGETYPE') or "")
> +types = ' '.join(sorted(types)).strip()
>  d.setVar('KERNEL_IMAGETYPES', types)
> -
> -typeformake = re.sub(r'\.gz', '', types)
> -d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', typeformake)
> +d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', re.sub(r'\.gz', '', types))
>
>  for type in types.split():
> -typelower = type.lower()
>  imagedest = d.getVar('KERNEL_IMAGEDEST')
> +if type == "vmlinux":
> +typelower = type.lower()
> +else:
> +typelower = "image-%s" % type.lower()
>
> -d.appendVar('PACKAGES', ' ' + 'kernel-image-' + typelower)
> -
> -d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest + '/' + 
> type + '-${KERNEL_VERSION_NAME}')
> -
> -d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' + 
> typelower)
> -
> -d.setVar('PKG_kernel-image-' + typelower, 'kernel-image-' + 
> typelower + '-${KERNEL_VERSION_PKG_NAME}')
> +d.appendVar('PACKAGES', ' kernel-%s' % typelower)
> +if type != 'vmlinux' or d.getVar('KERNEL_IMAGETYPE') == 'vmlinux':
> +d.appendVar('RDEPENDS_kernel-image', ' kernel-%s' % typelower)
>
> -d.setVar('ALLOW_EMPTY_kernel-image-' + typelower, '1')
> +d.setVar('FILES_kernel-%s' % typelower, 
> '/%s/%s-${KERNEL_VERSION_NAME}' % (imagedest, type))
> +d.setVar('PKG_kernel-%s' % typelower, 
> 'kernel-%s-${KERNEL_VERSION_PKG_NAME}' % typelower)
>
>  priority = d.getVar('KERNEL_PRIORITY')
> -postinst = '#!/bin/sh\n' + 'update-alternatives --install /' + 
> imagedest + '/' + type + ' ' + type + ' ' + type + '-${KERNEL_VERSION_NAME} ' 

Re: [OE-core] [PATCH 5/5] file: 5.29 -> 5.30

[Stefano Babic]

On 22/02/2017 02:44, Robert Yang wrote:
> Signed-off-by: Robert Yang 
> ---
>  meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} (96%)
> 
> diff --git a/meta/recipes-devtools/file/file_5.29.bb 
> b/meta/recipes-devtools/file/file_5.30.bb
> similarity index 96%
> rename from meta/recipes-devtools/file/file_5.29.bb
> rename to meta/recipes-devtools/file/file_5.30.bb
> index 29af8748150..0998fcfa899 100644
> --- a/meta/recipes-devtools/file/file_5.29.bb
> +++ b/meta/recipes-devtools/file/file_5.30.bb
> @@ -19,7 +19,7 @@ SRC_URI = "git://github.com/file/file.git \
>  file://0001-Add-P-prompt-into-Usage-info.patch \
>  "
>  
> -SRCREV = "015b0cdce1a0abb68ab99510e7fc8d2f77e8ec77"
> +SRCREV = "79814950aafb81ecd6a910c2a8a3b8ec12f3e4a6"
>  S = "${WORKDIR}/git"
>  
>  inherit autotools
> 

Strange enough, it seems that the tree loses the history and all SRCREV
are wrong. I tried with -krogoth, -morty, -master, and no revision
number is found. In fact, after cloning the tree I see that all revision
number were changed, just a couple here:

5.25 is now : 789cfc7d727cee1c7cfb7d29c09162e2399285c5

5.30 (this patch) : 3050419355566d2a96c5be97fef0ffae097bbb96

Ok, I fix this in my layer with a .bbappend, but...Of course, all builds
are broken - have you seen the same effect ?

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [morty][PATCH] file: update SRCREV for 5.28 to fix fetch fail on missing commit

[Phil Wise]

I hit this issue when doing a build this morning, and filed this bug
before seeing your patches:

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

Cheers,

Phil

On 18.03.2017 00:24, Denys Dmytriyenko wrote:
> From: Paul Gortmaker 
> 
> Machines that cloned a while ago will have the commit, but new
> deployments won't because it seems the upstream changed/rebased
> and the old commit ID has been garbage-collected away.  Hence
> the fetch fails to check out the named commit ID.
> 
> Both the old (gone) commit, and the "new" commit show the same
> dates and commit log and point at 5.28, so hopefully this is
> the right thing to do.  A git diff of the two seems to only show
> a blanket uprev of CVS tags and deletion of a couple autogen'd
> files, and no real source changes.
> 
> (From OE-Core rev: adb71e06768adadda7b69c3b5e81ca3ad67237f4)
> 
> Cc: Christos Zoulas 
> Signed-off-by: Paul Gortmaker 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Denys Dmytriyenko 
> ---
>  meta/recipes-devtools/file/file_5.28.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/file/file_5.28.bb 
> b/meta/recipes-devtools/file/file_5.28.bb
> index e64a89c..048fb8e 100644
> --- a/meta/recipes-devtools/file/file_5.28.bb
> +++ b/meta/recipes-devtools/file/file_5.28.bb
> @@ -19,7 +19,7 @@ SRC_URI = "git://github.com/file/file.git \
>  file://0001-Add-P-prompt-into-Usage-info.patch \
>  "
>  
> -SRCREV = "3c521817322a6bf5160cfeb09b9145ccde587b2a"
> +SRCREV = "acbaf156236cbc54b3cf3bc6cbf05d80cb196451"
>  S = "${WORKDIR}/git"
>  
>  inherit autotools
> 

-- 
Phil Wise, ATS Advanced Telematic Systems GmbH
Kantstrasse 162, 10623 Berlin
Managing Directors: Dirk Pöschl, Armin G. Schmidt
Register Court: HRB 151501 B, Amtsgericht Charlottenburg
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/6] musl: Update to latest

[Jussi Kukkonen]

On 15 March 2017 at 01:35, Khem Raj  wrote:

> Rich Felker (11):
>   fix ld-behavior-dependent crash in ppc64 ldso startup
>   rework ldso handling of global symbol table for consistency
>   reorder addend handling before symbol lookup in relocation code
>   emulate lazy relocation as deferrable relocation
>   fix free of uninitialized buffer pointer on error in regexec
>   in static dl_iterate_phdr, fix use of possibly-uninitialized aux data
>   fix possible fd leak, unrestored cancellation state on dns socket
> fail
>   fix wide scanf's use of a compound literal past its lifetime
>   fix one-byte overflow in legacy getpass function
>   avoid loading of multiple libc versions via explicit pathname
>   remove unused refcnt field for shared libraries
>
> Szabolcs Nagy (1):
>   treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym
>


Could the relocation changes here be responsible for these ovmf build
failures:
  "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation"
?

https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio


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