[OE-core] [PATCH 8/8] staging.bbclass: extend_recipe_sysroot: fix multilib manifest

[Robert Yang]

Fixed:
MACHINE = "qemux86-64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

$ bitbake  -cpopulate_sdk_ext
[snip]
Exception: subprocess.CalledProcessError: Command 'sed -e [snip]'
[snip]

Subprocess output:
[snip]
sed: can't read 
/path/to/work/qemux86_64-wrs-linux/wrlinux-image-glibc-small/1.0-r1/recipe-sysroot/usr/lib/perl/5.24.1/ExtUtils/Liblist/Kid.pm:
 No such file or directory
[snip]

It was failed because "/usr/lib" is in qemux86_64-wrsmllib32-linux/, not in
qemux86_64-wrs-linux. The code has considered mutitlib, but seems not
completed, the multilib "variant" was not in fixme, so it wasn't handled
correctly, this patch fixes the problem.

Signed-off-by: Robert Yang 
---
 meta/classes/staging.bbclass | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index c45ada4..1c2028c 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -492,11 +492,21 @@ python extend_recipe_sysroot() {
 if c.endswith("-native") or "-cross-" in c or "-crosssdk" in c:
 native = True
 
+multilib = False
+if setscenedeps[dep][2].startswith("virtual:multilib"):
+variant = setscenedeps[dep][2].split(":")[2]
+if variant not in fixme:
+fixme[variant] = []
+multilib = True
+
 if manifest:
 newmanifest = collections.OrderedDict()
 if native:
 fm = fixme['native']
 targetdir = recipesysrootnative
+elif multilib:
+fm = fixme[variant]
+targetdir = destsysroot
 else:
 fm = fixme['']
 targetdir = destsysroot
-- 
2.7.4

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

[OE-core] [PATCH 7/8] populate_sdk_ext.bbclass: remove the try...finally

[Robert Yang]

The "sdkbasepath + '/conf/local.conf.bak" doesn't exist when
"oe.copy_buildsystem.check_sstate_task_list()" fails, then os.replace() would
raise FileNotFoundError, which overcomes the real error. Keep the error status
makes debug easier, so remove the try..finally.

Signed-off-by: Robert Yang 
---
 meta/classes/populate_sdk_ext.bbclass | 70 +--
 1 file changed, 34 insertions(+), 36 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 057c495..43823bf 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -142,43 +142,41 @@ def create_filtered_tasklist(d, sdkbasepath, 
tasklistfile, conf_initpath):
 
 # Create a temporary build directory that we can pass to the env setup 
script
 shutil.copyfile(sdkbasepath + '/conf/local.conf', sdkbasepath + 
'/conf/local.conf.bak')
+with open(sdkbasepath + '/conf/local.conf', 'a') as f:
+# Force the use of sstate from the build system
+f.write('\nSSTATE_DIR_forcevariable = "%s"\n' % d.getVar('SSTATE_DIR'))
+f.write('SSTATE_MIRRORS_forcevariable = "file://universal/(.*) 
file://universal-4.9/\\1 file://universal-4.9/(.*) file://universal-4.8/\\1"\n')
+# Ensure TMPDIR is the default so that clean_esdk_builddir() can 
delete it
+f.write('TMPDIR_forcevariable = "${TOPDIR}/tmp"\n')
+f.write('TCLIBCAPPEND_forcevariable = ""\n')
+# Drop uninative if the build isn't using it (or else NATIVELSBSTRING 
will
+# be different and we won't be able to find our native sstate)
+if not bb.data.inherits_class('uninative', d):
+f.write('INHERIT_remove = "uninative"\n')
+
+# Unfortunately the default SDKPATH (or even a custom value) may contain 
characters that bitbake
+# will not allow in its COREBASE path, so we need to rename the directory 
temporarily
+temp_sdkbasepath = d.getVar('SDK_OUTPUT') + '/tmp-renamed-sdk'
+# Delete any existing temp dir
 try:
-with open(sdkbasepath + '/conf/local.conf', 'a') as f:
-# Force the use of sstate from the build system
-f.write('\nSSTATE_DIR_forcevariable = "%s"\n' % 
d.getVar('SSTATE_DIR'))
-f.write('SSTATE_MIRRORS_forcevariable = "file://universal/(.*) 
file://universal-4.9/\\1 file://universal-4.9/(.*) file://universal-4.8/\\1"\n')
-# Ensure TMPDIR is the default so that clean_esdk_builddir() can 
delete it
-f.write('TMPDIR_forcevariable = "${TOPDIR}/tmp"\n')
-f.write('TCLIBCAPPEND_forcevariable = ""\n')
-# Drop uninative if the build isn't using it (or else 
NATIVELSBSTRING will
-# be different and we won't be able to find our native sstate)
-if not bb.data.inherits_class('uninative', d):
-f.write('INHERIT_remove = "uninative"\n')
-
-# Unfortunately the default SDKPATH (or even a custom value) may 
contain characters that bitbake
-# will not allow in its COREBASE path, so we need to rename the 
directory temporarily
-temp_sdkbasepath = d.getVar('SDK_OUTPUT') + '/tmp-renamed-sdk'
-# Delete any existing temp dir
-try:
-shutil.rmtree(temp_sdkbasepath)
-except FileNotFoundError:
-pass
-os.rename(sdkbasepath, temp_sdkbasepath)
-cmdprefix = '. %s .; ' % conf_initpath
-logfile = d.getVar('WORKDIR') + '/tasklist_bb_log.txt'
-try:
-oe.copy_buildsystem.check_sstate_task_list(d, 
get_sdk_install_targets(d), tasklistfile, cmdprefix=cmdprefix, 
cwd=temp_sdkbasepath, logfile=logfile)
-except bb.process.ExecutionError as e:
-msg = 'Failed to generate filtered task list for extensible 
SDK:\n%s' %  e.stdout.rstrip()
-if 'attempted to execute unexpectedly and should have been 
setscened' in e.stdout:
-msg += '\n--\n\nNOTE: "attempted to execute 
unexpectedly and should have been setscened" errors indicate this may be caused 
by missing sstate artifacts that were likely produced in earlier builds, but 
have been subsequently deleted for some reason.\n'
-bb.fatal(msg)
-os.rename(temp_sdkbasepath, sdkbasepath)
-# Clean out residue of running bitbake, which check_sstate_task_list()
-# will effectively do
-clean_esdk_builddir(d, sdkbasepath)
-finally:
-os.replace(sdkbasepath + '/conf/local.conf.bak', sdkbasepath + 
'/conf/local.conf')
+shutil.rmtree(temp_sdkbasepath)
+except FileNotFoundError:
+pass
+os.rename(sdkbasepath, temp_sdkbasepath)
+cmdprefix = '. %s .; ' % conf_initpath
+logfile = d.getVar('WORKDIR') + '/tasklist_bb_log.txt'
+try:
+oe.copy_buildsystem.check_sstate_task_list(d, 
get_sdk_install_targets(d), tasklistfile, cmdprefix=cmdprefix, 
cwd=temp_sdkbasepath, logfile=logfile)
+except 

[OE-core] [PATCH 6/8] toolchain-scripts.bbclass: only install all MULTILIB_VARIANTS for image

[Robert Yang]

Install all MULTILIB_VARIANTS to sysroot and pack them only makes sense to
image recipe, so limit it to image recipe only, and it can fix:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"

$ bitbake lib32-meta-ide-support
WARNING: lib32-meta-ide-support-1.0-r3 do_configure: Manifest for ncurses not 
found, searched manifests:
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-qemux86_64-ncurses.populate_sysroot
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-core2-32-ncurses.populate_sysroot
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-i586-ncurses.populate_sysroot
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-x86-ncurses.populate_sysroot
/workspace2/lyang1/test_mlwarn/tmp-glibc/sstate-control/manifest-allarch-ncurses.populate_sysroot

This is because core2-64 is not in lib32-meta-ide-support's
PACKAGE_ARCHS which doesn't like image recipe (lib32-image recipe's
DEFAULTTUNE is not overridded)

[YOCTO #12298]

Signed-off-by: Robert Yang 
---
 meta/classes/toolchain-scripts.bbclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index eeb320d..52d8f83 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -166,6 +166,12 @@ toolchain_create_sdk_siteconfig[vardepsexclude] = 
"TOOLCHAIN_CONFIGSITE_SYSROOTC
 
 python __anonymous () {
 import oe.classextend
+
+# Install all MULTILIB_VARIANTS to sysroot and pack them only makes sense 
to
+# image recipe.
+if not bb.data.inherits_class('image', d):
+return
+
 deps = ""
 for dep in (d.getVar('TOOLCHAIN_NEED_CONFIGSITE_CACHE') or "").split():
 deps += " %s:do_populate_sysroot" % dep
-- 
2.7.4

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

[OE-core] [PATCH 5/8] multilib.bbclass: extend allarch recipes

[Robert Yang]

This can fix do_rootfs and depends chaos when multilib, for example
ca-certificates is an allarch recipe:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " ca-certificates"
$ bitbake ca-certificates
$ rpm -qpR tmp-glibc/deploy/rpm/noarch/ca-certificates-20170717-r0.noarch.rpm
[snip]
openssl
[snip]

It requires openssl, but lib32-openssl doesn't proivide it:
$ rpm -qp --provides 
tmp-glibc/deploy/rpm/core2_32/lib32-openssl-1.0.2l-r0.core2_32.rpm
lib32-openssl = 1.0.2l-r0

So openssl-1.0.2l-r0.core2_64.rpm would be installed when install
ca-certificates, e.g.:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " ca-certificates"
$ bitbake lib32-core-image-minimal
The openssl-1.0.2l-r0.core2_64.rpm and other 64 bit packages are installed,
this is incorrect.

We have two solutions on this:
1) Let lib32-openssl provide openssl, but this would cause more problems when
   building since more than one providers for openssl.

Or

2) Extend allarch recipes, there would be ca-certificates-20170717-r0.noarch.rpm
   and lib32-ca-certificates-20170717-r0.noarch.rpm, then ca-certificates
   requires openssl, and lib32-ca-certificates requires lib32-openssl, the
   packages will be installed correctly, this is the best solution that I can
   find.

The problem has existed for years for deb and ipk (rpm did work since it didn't
use lib32-BPN in rpm filename before changed to dnf, for example, there was no
lib32-openssl.core2_32.rpm, but openssl.core2_32.rpm), this patch can fix the
problem for rpm, ipk and deb.

[YOCTO #12288]

Signed-off-by: Robert Yang 
---
 meta/classes/allarch.bbclass | 3 ---
 meta/classes/multilib.bbclass| 4 
 meta/classes/multilib_global.bbclass | 4 +---
 meta/classes/package.bbclass | 9 -
 4 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 51ba509..b4f694d 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -42,9 +42,6 @@ python () {
 d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
 d.setVar("INHIBIT_PACKAGE_STRIP", "1")
 
-# These multilib values shouldn't change allarch packages so exclude 
them
-d.appendVarFlag("emit_pkgdata", "vardepsexclude", " MULTILIB_VARIANTS")
-d.appendVarFlag("write_specfile", "vardepsexclude", " MULTILIBS")
 elif bb.data.inherits_class('packagegroup', d) and not 
bb.data.inherits_class('nativesdk', d):
 bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit 
packagegroup" % d.getVar("FILE"))
 }
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index fbb6980..b517dde 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -46,10 +46,6 @@ python multilib_virtclass_handler () {
 if bb.data.inherits_class('nativesdk', e.data) or 
bb.data.inherits_class('crosssdk', e.data):
 raise bb.parse.SkipRecipe("We can't extend nativesdk recipes")
 
-if bb.data.inherits_class('allarch', e.data) and not 
bb.data.inherits_class('packagegroup', e.data):
-raise bb.parse.SkipRecipe("Don't extend allarch recipes which are not 
packagegroups")
-
-
 # Expand this since this won't work correctly once we set a multilib into 
place
 e.data.setVar("ALL_MULTILIB_PACKAGE_ARCHS", 
e.data.getVar("ALL_MULTILIB_PACKAGE_ARCHS"))
  
diff --git a/meta/classes/multilib_global.bbclass 
b/meta/classes/multilib_global.bbclass
index d2ec1ad..1bb6242 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -165,9 +165,7 @@ python multilib_virtclass_handler_global () {
 return
 
 if bb.data.inherits_class('kernel', e.data) or \
-bb.data.inherits_class('module-base', e.data) or \
-(bb.data.inherits_class('allarch', e.data) and\
- not bb.data.inherits_class('packagegroup', e.data)):
+bb.data.inherits_class('module-base', e.data):
 variants = (e.data.getVar("MULTILIB_VARIANTS") or "").split()
 
 import oe.classextend
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 317c775..0e26b46 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -475,9 +475,6 @@ def get_package_mapping (pkg, basepkg, d):
 key = "PKG_%s" % pkg
 
 if key in data:
-# Have to avoid undoing the write_extra_pkgs(global_variants...)
-if bb.data.inherits_class('allarch', d) and data[key] == basepkg:
-return pkg
 return data[key]
 
 return pkg
@@ -1391,9 +1388,6 @@ fi
 if bb.data.inherits_class('kernel', d) or 
bb.data.inherits_class('module-base', d):
 write_extra_pkgs(variants, pn, packages, pkgdatadir)
 
-   

[OE-core] [PATCH 4/8] package_manager.py: reverse archs correctly

[Robert Yang]

It had reversed all the archs, which mixed multilib and common archs, e.g.:
"all any noarch x86_64 core2-64 qemux86_64 x86 i586 core2-32"
After reversed:
"core2-32 i586 x86 qemux86_64 core2-64 x86_64 noarch any all"
The core2-32 has a higher priority than core2-64 after reversed which is
incorrect. Don't mix with mulitlib when reverse can fix the problem, and let
multilib archs have a higher priority for multilib image.

Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " ca-certificates"

$ bitbake wrlinux-image-glibc-small
Check rootfs.manifest, no core_32 packages is installed, this is
correct, but after we build lib32-bash, it will be incorrect:
$ bitbake lib32-bash
$ bitbake wrlinux-image-glibc-small
Check rootfs.manifest, a few lib32 packages are installed, such as
lib32-bash, this is incorrect. It was because ca-certificates is
allarch, and requires /bin/sh, which is provided by both bash and
lib32-bash, and lib32-bash has a higher priority than bash, so it would
be installed.

[YOCTO #12288]

Signed-off-by: Robert Yang 
---
 meta/lib/oe/package_manager.py | 57 ++
 1 file changed, 52 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index c10efb8..d4dc174 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -572,10 +572,10 @@ class RpmPM(PackageManager):
 self.target_rootfs = target_rootfs
 self.target_vendor = target_vendor
 self.task_name = task_name
-if arch_var == None:
-self.archs = 
self.d.getVar('ALL_MULTILIB_PACKAGE_ARCHS').replace("-","_")
-else:
-self.archs = self.d.getVar(arch_var).replace("-","_")
+
+self.archs = self._determine_archs(arch_var)
+bb.note("The archs used by package manager: %s" % self.archs)
+
 if task_name == "host":
 self.primary_arch = self.d.getVar('SDK_ARCH')
 else:
@@ -593,9 +593,56 @@ class RpmPM(PackageManager):
 if not os.path.exists(self.d.expand('${T}/saved')):
 bb.utils.mkdirhier(self.d.expand('${T}/saved'))
 
+def _determine_archs(self, arch_var):
+if arch_var:
+archs = self.d.getVar(arch_var).replace("-","_").split()
+else:
+archs = 
self.d.getVar('ALL_MULTILIB_PACKAGE_ARCHS').replace("-","_").split()
+# Reverse archs to ensure the -best- match is listed firstly, but need
+# make sure not mixed with multilib archs, and let multilib archs have
+# higher a priority for multilib image:
+# For non-multilib image: (e.g., core-image-minimal)
+# machine_arch:package_archs:multilib_archs:allarch_archs
+# For multilib image: (e.g., lib32-core-image-minimal)
+# machine_arch:multilib_archs:package_archs:allarch_archs
+package_archs_var = 
self.d.getVar('PACKAGE_ARCHS').replace("-","_").split()
+machine_arch_var = [self.d.getVar('MACHINE_ARCH').replace("-","_")]
+package_archs = []
+allarch_archs = []
+ml_archs = []
+machine_arch = []
+for arch in archs:
+if arch in machine_arch_var:
+bb.note("Found MACHINE_ARCH: %s" % arch)
+machine_arch.append(arch)
+elif arch in package_archs_var:
+bb.note("Found PACKAGE_ARCH: %s" % arch)
+package_archs.append(arch)
+elif arch in 'all any noarch'.split():
+bb.note("Found allarch: %s" % arch)
+allarch_archs.append(arch)
+else:
+bb.note("Found multilib arch: %s" % arch)
+ml_archs.append(arch)
+package_archs.reverse()
+if machine_arch:
+archs = machine_arch
+mlprefix = self.d.getVar('MLPREFIX')
+if ml_archs:
+ml_archs.reverse()
+if mlprefix:
+archs += ml_archs + package_archs
+else:
+archs += package_archs + ml_archs
+else:
+archs += package_archs
+
+archs += allarch_archs
+return ' '.join(archs)
+
 def _configure_dnf(self):
 # libsolv handles 'noarch' internally, we don't need to specify it 
explicitly
-archs = [i for i in reversed(self.archs.split()) if i not in ["any", 
"all", "noarch"]]
+archs = [i for i in self.archs.split() if i not in ["any", "all", 
"noarch"]]
 # This prevents accidental matching against libsolv's built-in policies
 if len(archs) <= 1:
 archs = archs + ["bogusarch"]
-- 
2.7.4

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

[OE-core] [PATCH 3/8] staging.bbclass: print searched manifest when not found

[Robert Yang]

The old warning was:
WARNING: lib32-wrlinux-image-glibc-small-1.0-r1 do_prepare_recipe_sysroot: 
Manifest 
/path/to/tmp/sstate-control/manifest-allarch-lib32-qemuwrapper-cross.populate_sysroot
 not found?

The message wasn't clear enough, it searched a few manifests, but only
reported the last one, which confused user.

Now the warning is:
WARNING: lib32-wrlinux-image-glibc-small-1.0-r1 do_rootfs: Manifest for 
lib32-qemuwrapper-cross not found, searched manifests:
/path/to/tmp/sstate-control/manifest-qemux86_64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-core2-64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-x86_64-lib32-qemuwrapper-cross.populate_sysroot
/path/to/tmp/sstate-control/manifest-allarch-lib32-qemuwrapper-cross.populate_sysroot

Whick makes debug easier.

Signed-off-by: Robert Yang 
---
 meta/lib/oe/sstatesig.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index b82e0f4..0c90ffe 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -394,11 +394,14 @@ def find_sstate_manifest(taskdata, taskdata2, taskname, 
d, multilibcache):
 pkgarchs.append('allarch')
 pkgarchs.append('${SDK_ARCH}_${SDK_ARCH}-${SDKPKGSUFFIX}')
 
+searched_manifest = []
 for pkgarch in pkgarchs:
 manifest = d2.expand("${SSTATE_MANIFESTS}/manifest-%s-%s.%s" % 
(pkgarch, taskdata, taskname))
 if os.path.exists(manifest):
 return manifest, d2
+searched_manifest.append(manifest)
 bb.warn("Manifest %s not found in %s (variant '%s')?" % (manifest, 
d2.expand(" ".join(pkgarchs)), variant))
+bb.warn("Searched manifests:\n%s" % '\n'.join(searched_manifest))
 return None, d2
 
 
-- 
2.7.4

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

[OE-core] [PATCH 1/8] populate_sdk_ext.bbclass: fix for multilib

[Robert Yang]

Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

$ bitbake  -cpopulate_sdk_ext
$ bitbake  -ctestsdkext
[snip]
Standard Output: /bin/sh: 1: i686-wrsmllib32-linux-gcc: not found
[snip]

It was failed because no lib32 toolchain or lib installed.

This patch fixes:
* Set SDK_TARGETS correctly
* Return multilib depends in get_ext_sdk_depends()
* Write information to all environment-setup-* scripts.

Signed-off-by: Robert Yang 
---
 meta/classes/populate_sdk_ext.bbclass | 72 +++
 1 file changed, 47 insertions(+), 25 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 6553754..057c495 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -38,7 +38,7 @@ SDK_LOCAL_CONF_BLACKLIST ?= "CONF_VERSION \
 SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
 SDK_UPDATE_URL ?= ""
 
-SDK_TARGETS ?= "${PN}"
+SDK_TARGETS ?= "${@multilib_pkg_extend(d, d.getVar('BPN', True))}"
 
 def get_sdk_install_targets(d, images_only=False):
 sdk_install_targets = ''
@@ -55,9 +55,11 @@ def get_sdk_install_targets(d, images_only=False):
 
 if not images_only:
 if d.getVar('SDK_INCLUDE_PKGDATA') == '1':
-sdk_install_targets += ' meta-world-pkgdata:do_allpackagedata'
+for pn in multilib_pkg_extend(d, 'meta-world-pkgdata').split():
+sdk_install_targets += ' %s:do_allpackagedata' % pn
 if d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1':
-sdk_install_targets += ' meta-extsdk-toolchain:do_populate_sysroot'
+for pn in multilib_pkg_extend(d, 'meta-extsdk-toolchain').split():
+sdk_install_targets += ' %s:do_populate_sysroot' % pn
 
 return sdk_install_targets
 
@@ -601,40 +603,55 @@ SDK_PRE_INSTALL_COMMAND_task-populate-sdk-ext = 
"${sdk_ext_preinst}"
 sdk_ext_postinst() {
printf "\nExtracting buildtools...\n"
cd $target_sdk_dir
-   
env_setup_script="$target_sdk_dir/environment-setup-${REAL_MULTIMACH_TARGET_SYS}"
-   printf "buildtools\ny" | ./${SDK_BUILDTOOLS_INSTALLER} > buildtools.log 
|| { printf 'ERROR: buildtools installation failed:\n' ; cat buildtools.log ; 
echo "printf 'ERROR: this SDK was not fully installed and needs 
reinstalling\n'" >> $env_setup_script ; exit 1 ; }
+   env_setup_scripts="`ls $target_sdk_dir/environment-setup-*`"
+   ./${SDK_BUILDTOOLS_INSTALLER} -d buildtools -y > buildtools.log
+   if [ $? -ne 0 ]; then
+   echo 'ERROR: buildtools installation failed:'
+   cat buildtools.log
+   for e in $env_setup_scripts; do
+   echo "echo 'ERROR: this SDK was not fully installed and 
needs reinstalling'" >> $e
+   done
+   exit 1
+   fi
 
# Delete the buildtools tar file since it won't be used again
rm -f ./${SDK_BUILDTOOLS_INSTALLER}
# We don't need the log either since it succeeded
rm -f buildtools.log
 
-   # Make sure when the user sets up the environment, they also get
-   # the buildtools-tarball tools in their path.
-   echo ". $target_sdk_dir/buildtools/environment-setup*" >> 
$env_setup_script
-
-   # Allow bitbake environment setup to be ran as part of this sdk.
-   echo "export OE_SKIP_SDK_CHECK=1" >> $env_setup_script
-   # Work around runqemu not knowing how to get this information within 
the eSDK
-   echo "export 
DEPLOY_DIR_IMAGE=$target_sdk_dir/tmp/${@os.path.relpath(d.getVar('DEPLOY_DIR_IMAGE'),
 d.getVar('TMPDIR'))}" >> $env_setup_script
+   for e in $env_setup_scripts; do
+   # Make sure when the user sets up the environment, they also get
+   # the buildtools-tarball tools in their path.
+   echo ". $target_sdk_dir/buildtools/environment-setup*" >> $e
 
-   # A bit of another hack, but we need this in the path only for devtool
-   # so put it at the end of $PATH.
-   echo "export 
PATH=$target_sdk_dir/sysroots/${SDK_SYS}${bindir_nativesdk}:\$PATH" >> 
$env_setup_script
+   # Allow bitbake environment setup to be ran as part of this sdk.
+   echo "export OE_SKIP_SDK_CHECK=1" >> $e
 
-   echo "printf 'SDK environment now set up; additionally you may now run 
devtool to perform development tasks.\nRun devtool --help for further 
details.\n'" >> $env_setup_script
+   # Work around runqemu not knowing how to get this information 
within the eSDK
+   echo "export 
DEPLOY_DIR_IMAGE=$target_sdk_dir/tmp/${@os.path.relpath(d.getVar('DEPLOY_DIR_IMAGE'),
 d.getVar('TMPDIR'))}" >> $e
 
-   # Warn if trying to use external bitbake and the ext SDK together
-   echo "(which bitbake > /dev/null 2>&1 && echo 'WARNING: attempting to 
use the extensible SDK in an environment set up to run bitbake - this may 

[OE-core] [PATCH 2/8] staging.bbclass: staging_populate_sysroot_dir(): fix for multilib

[Robert Yang]

Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

$ bitbake core-image-sato lib32-core-image-sato
$ bitbake build-sysroots

All lib32 manifests which had been built should be installed, but only a few
such as qemux86_64-lib32-base-files were installed (it was installed because
MACHINE_ARCH was still qemux86-64 when multilib), but others such as
x86-lib32-zlib were not installed, this was incorrect. For multilib builds,
fix-up overrides to prepend :virtclass-multilib- and then again append
additional multilib arches from the PACKAGE_EXTRA_ARCHS list if needed can fix
the problem.

Signed-off-by: Robert Yang 
---
 meta/classes/staging.bbclass | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 3fcbc9f..c45ada4 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -190,8 +190,23 @@ def staging_populate_sysroot_dir(targetsysroot, 
nativesysroot, native, d):
 pkgarchs = ['${MACHINE_ARCH}']
 pkgarchs = pkgarchs + 
list(reversed(d.getVar("PACKAGE_EXTRA_ARCHS").split()))
 pkgarchs.append('allarch')
+
+# Handle multilib archs
+variants = d.getVar("MULTILIB_VARIANTS", True) or ""
+for variant in variants.split():
+localdata = bb.data.createCopy(d)
+overrides = localdata.getVar("OVERRIDES", False) + 
":virtclass-multilib-" + variant
+localdata.setVar("OVERRIDES", overrides)
+bb.data.update_data(localdata)
+pkgarchs_ml = localdata.getVar('PACKAGE_EXTRA_ARCHS').split()
+for arch in pkgarchs_ml:
+if arch not in pkgarchs:
+pkgarchs.append(arch)
+
 targetdir = targetsysroot
 
+bb.debug(1, 'pkgarchs: %s' % pkgarchs)
+
 bb.utils.mkdirhier(targetdir)
 for pkgarch in pkgarchs:
 for manifest in 
glob.glob(d.expand("${SSTATE_MANIFESTS}/manifest-%s-*.populate_sysroot" % 
pkgarch)):
-- 
2.7.4

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

[OE-core] [PATCH 0/8] [rebase and resend] fixes for multilib

[Robert Yang]

Hi RP,

The multilib is still broken without these patches, I'd like to add oeqa test
cases for them after it works.

// Robert

The following changes since commit 073d8d001033471d7fe44f52212c72a6c3541313:

  dbus-test-ptest: improve reproducibility (2018-03-12 15:05:58 -0700)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/mlib
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/mlib

Robert Yang (8):
  populate_sdk_ext.bbclass: fix for multilib
  staging.bbclass: staging_populate_sysroot_dir(): fix for multilib
  staging.bbclass: print searched manifest when not found
  package_manager.py: reverse archs correctly
  multilib.bbclass: extend allarch recipes
  toolchain-scripts.bbclass: only install all MULTILIB_VARIANTS for
image
  populate_sdk_ext.bbclass: remove the try...finally
  staging.bbclass: extend_recipe_sysroot: fix multilib manifest

 meta/classes/allarch.bbclass   |   3 -
 meta/classes/multilib.bbclass  |   4 -
 meta/classes/multilib_global.bbclass   |   4 +-
 meta/classes/package.bbclass   |   9 ---
 meta/classes/populate_sdk_ext.bbclass  | 142 +++--
 meta/classes/staging.bbclass   |  25 ++
 meta/classes/toolchain-scripts.bbclass |   6 ++
 meta/lib/oe/package_manager.py |  57 +++--
 meta/lib/oe/sstatesig.py   |   3 +
 9 files changed, 168 insertions(+), 85 deletions(-)

-- 
2.7.4

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

[OE-core] [PATCH 3/3] python3: Fix purelib install and runtime paths

[Jason Wessel]

oe-core commit: 45afadf0b6 fixed the pip problem with purelib for
python2, even though the the patch stated it was for python3.  This
patch addresses the purelib problem for python3.

If you install the package python3-pip you will have a pip3 binary
where you can see the problem on the device easily where the modules
install into the incorrect area and are not able to be referenced by
python3 at all.

Example error:
   pip3 install imutils
   pip3 list |grep imutils || echo ERROR no imutils
  ERROR no imutils
   python3 -c 'import imutils'
 Traceback (most recent call last):
   File "", line 1, in 
 ImportError: No module named 'imutils'

Signed-off-by: Jason Wessel 
---
 .../python/python3/python-3.3-multilib.patch| 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-devtools/python/python3/python-3.3-multilib.patch 
b/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
index 77da615..cc35dc1 100644
--- a/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
+++ b/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
@@ -52,11 +52,13 @@ Index: Python-3.5.4/Lib/distutils/command/install.py
  WINDOWS_SCHEME = {
  'purelib': '$base/Lib/site-packages',
  'platlib': '$base/Lib/site-packages',
-@@ -30,7 +32,7 @@ WINDOWS_SCHEME = {
+@@ -29,8 +31,8 @@ WINDOWS_SCHEME = {
+ 
  INSTALL_SCHEMES = {
  'unix_prefix': {
- 'purelib': '$base/lib/python$py_version_short/site-packages',
+-'purelib': '$base/lib/python$py_version_short/site-packages',
 -'platlib': '$platbase/lib/python$py_version_short/site-packages',
++'purelib': 
'$platbase/'+libname+'/python$py_version_short/site-packages',
 +'platlib': 
'$platbase/'+libname+'/python$py_version_short/site-packages',
  'headers': 
'$base/include/python$py_version_short$abiflags/$dist_name',
  'scripts': '$base/bin',
@@ -103,10 +105,11 @@ Index: Python-3.5.4/Lib/sysconfig.py
  'posix_prefix': {
 -'stdlib': '{installed_base}/lib/python{py_version_short}',
 -'platstdlib': '{platbase}/lib/python{py_version_short}',
+-'purelib': '{base}/lib/python{py_version_short}/site-packages',
+-'platlib': '{platbase}/lib/python{py_version_short}/site-packages',
 +'stdlib': '{installed_base}/'+sys.lib+'/python{py_version_short}',
 +'platstdlib': '{platbase}/'+sys.lib+'/python{py_version_short}',
- 'purelib': '{base}/lib/python{py_version_short}/site-packages',
--'platlib': '{platbase}/lib/python{py_version_short}/site-packages',
++'purelib': 
'{platbase}/'+sys.lib+'/python{py_version_short}/site-packages',
 +'platlib': 
'{platbase}/'+sys.lib+'/python{py_version_short}/site-packages',
  'include':
  '{installed_base}/include/python{py_version_short}{abiflags}',
@@ -117,10 +120,11 @@ Index: Python-3.5.4/Lib/sysconfig.py
  'posix_home': {
 -'stdlib': '{installed_base}/lib/python',
 -'platstdlib': '{base}/lib/python',
+-'purelib': '{base}/lib/python',
+-'platlib': '{base}/lib/python',
 +'stdlib': '{installed_base}/'+sys.lib+'/python',
 +'platstdlib': '{base}/'+sys.lib+'/python',
- 'purelib': '{base}/lib/python',
--'platlib': '{base}/lib/python',
++'purelib': '{base}/'+sys.lib+'/python',
 +'platlib': '{base}/'+sys.lib+'/python',
  'include': '{installed_base}/include/python',
  'platinclude': '{installed_base}/include/python',
@@ -131,10 +135,11 @@ Index: Python-3.5.4/Lib/sysconfig.py
  'posix_user': {
 -'stdlib': '{userbase}/lib/python{py_version_short}',
 -'platstdlib': '{userbase}/lib/python{py_version_short}',
+-'purelib': '{userbase}/lib/python{py_version_short}/site-packages',
+-'platlib': '{userbase}/lib/python{py_version_short}/site-packages',
 +'stdlib': '{userbase}/'+sys.lib+'/python{py_version_short}',
 +'platstdlib': '{userbase}/'+sys.lib+'/python{py_version_short}',
- 'purelib': '{userbase}/lib/python{py_version_short}/site-packages',
--'platlib': '{userbase}/lib/python{py_version_short}/site-packages',
++'purelib': 
'{userbase}/'+sys.lib+'/python{py_version_short}/site-packages',
 +'platlib': 
'{userbase}/'+sys.lib+'/python{py_version_short}/site-packages',
  'include': '{userbase}/include/python{py_version_short}',
  'scripts': '{userbase}/bin',
-- 
2.7.4

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

[OE-core] [PATCH 2/3] boost: Fix link problems with caffe and Movidius SDK

[Jason Wessel]

When using an image built with the Yocto Project which has a compiler
and all the required libraries, projects such as caffe for the
Movidius SDK which use python3 and boost fail to build because they
look for libboost_python.so.  The error that cmake returns doesn't
even point to the fact that this is why the configuration fails.

Example showing the problem with the missing symlink:

  git clone https://github.com/weiliu89/caffe.git
  cd caffe
  mkdir build
  cd build
  cmake -DBLAS=Open ..

-- Configuring done
CMake Error at CMakeLists.txt:85 (add_dependencies):
  The dependency target "pycaffe" of target "pytest" does not exist.


Conditionally creating the link when building python3 support into
boost is all that is needed.

Signed-off-by: Jason Wessel 
---
 meta/recipes-support/boost/boost.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 0461ec6..c53edf7 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -195,6 +195,9 @@ do_install() {
fi
done
 
+   if [ -e ${D}${libdir}/libboost_python3.so ]; then
+   ln -s libboost_python3.so ${D}${libdir}/libboost_python.so
+   fi
 }
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.7.4

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

[OE-core] [PATCH 1/3] alsa-lib: Add an RPROVIDES for alsa-lib

[Jason Wessel]

There are a number of other recipes outside oe-core that depend on
alsa-lib and the rpm4 dependencies resolve sometimes to include
alsa-lib and the packages in the other layers fail to install because
the dependency cannot be resolved, despite the fact that libasound is
installed.

The simple is to add an RPROVIDES for alsa-lib to libasound which
provides all the shared objects for alsa.

Signed-off-by: Jason Wessel 
---
 meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
index c5bf107..f7f01e8 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
@@ -25,6 +25,7 @@ FILES_alsa-server = "${bindir}/*"
 FILES_alsa-conf = "${datadir}/alsa/"
 
 RDEPENDS_libasound = "alsa-conf"
+RPROVIDES_libasound = "alsa-lib"
 
 # alsa-lib gets automatically added to alsa-lib-dev dependencies, but the
 # alsa-lib package doesn't exist. libasound is the real library package.
-- 
2.7.4

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

Re: [OE-core] [PATCH V2] insane.bbclass: skip opening symlinks in package_qa_check_libdir

[Yi Zhao]

Ping


//Yi



在 2018年03月07日 08:15, Yi Zhao 写道:

If the library is installed in a non-standard location and don't set
INSANE_SKIP, e.g. libfoo.so is installed in /usr/local/lib. The
package_qa_check_libdir will cause a traceback because it will try to
open the .so link in package-dev to check if it's an ELF:
The stack trace of python calls that resulted in this exception/failure
was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:do_package_qa(d)
  [snip]
  0048:def open(self):
  *** 0049:with open(self.name, "rb") as f:
  0050:try:
  0051:self.data = mmap.mmap(f.fileno(), 0, 
access=mmap.ACCESS_READ)
  0052:except ValueError:
  0053:# This means the file is empty
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/buildarea1/build/tmp/work/i586-poky-linux/foo/1.0-r0/packages-split/foo-dev/usr/local/lib/libfoo.so'

For .so sysmlinks, we don't need to open it and report it directly.

[YOCTO #11862]

Signed-off-by: Yi Zhao 
---
  meta/classes/insane.bbclass | 30 ++
  1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 7407b29..b5689b7 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -358,22 +358,28 @@ def package_qa_check_libdir(d):
  rel_path = os.sep + rel_path
  if lib_re.match(rel_path):
  if base_libdir not in rel_path:
-# make sure it's an actual ELF file
-elf = oe.qa.ELFFile(full_path)
-try:
-elf.open()
+if os.path.islink(full_path):
  messages.append("%s: found library in wrong location: 
%s" % (package, rel_path))
-except (oe.qa.NotELFFileError):
-pass
+else:
+# make sure it's an actual ELF file
+elf = oe.qa.ELFFile(full_path)
+try:
+elf.open()
+messages.append("%s: found library in wrong 
location: %s" % (package, rel_path))
+except (oe.qa.NotELFFileError):
+pass
  if exec_re.match(rel_path):
  if libdir not in rel_path and libexecdir not in rel_path:
-# make sure it's an actual ELF file
-elf = oe.qa.ELFFile(full_path)
-try:
-elf.open()
+if os.path.islink(full_path):
  messages.append("%s: found library in wrong location: 
%s" % (package, rel_path))
-except (oe.qa.NotELFFileError):
-pass
+else:
+# make sure it's an actual ELF file
+elf = oe.qa.ELFFile(full_path)
+try:
+elf.open()
+messages.append("%s: found library in wrong 
location: %s" % (package, rel_path))
+except (oe.qa.NotELFFileError):
+pass
  
  if messages:

  package_qa_handle_error("libdir", "\n".join(messages), d)


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

Re: [OE-core] [rocko][PATCH 0/8] Backports for rocko

[Cal Sullivan]

Hi Juro, Khem,

A rocko-next build including this patchset had a couple gcc-sanitizers 
do_compile failures:

https://autobuilder.yocto.io/builders/nightly-x86-64-lsb/builds/865/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-no-x11/builds/853/steps/BuildImages/logs/stdio

At the time the only changes in rocko-next were this patchset and a 
patch to default gcc 6.x for testing.


If you could take a look it would be much appreciated.

Thanks,
Cal

On 03/10/2018 04:43 PM, Martin Jansa wrote:

The following changes since commit cb7cf1d12377d3b9a1cc159b68fc1d841004e6dd:

   glibc: Update to tip of 2.26 (2018-02-27 14:46:17 +)

are available in the Git repository at:

   git://git.openembedded.org/openembedded-core-contrib jansa/rocko-backports
   
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=jansa/rocko-backports

Andre McCurdy (1):
   gcc6: enable FL_LPAE flag for armv7ve cores

Juro Bystricky (1):
   gcc6: Backport few more patches

Khem Raj (5):
   gcc-runtime: Disable libitm on riscv
   gcc: Link libssp_nonshared.a only on musl targets
   gcc: Fix libssh_nonshared linker specs for ppc/musl
   gcc6: Upgrade to 6.4
   gcc7/gcc6: Fix unaligned STRD issue on ARM

Martin Jansa (1):
   Revert "waf.bbclass: explicitly pass bindir and libdir if supported"

  meta/classes/waf.bbclass   |   17 +-
  .../gcc/gcc-6.3/0041-ssp_nonshared.patch   |   28 -
  .../gcc/gcc-6.3/ubsan-fix-check-empty-string.patch |   28 -
  .../gcc/{gcc-6.3.inc => gcc-6.4.inc}   |   30 +-
  .../0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch |0
  .../0008-missing-execinfo_h.patch  |0
  .../{gcc-6.3 => gcc-6.4}/0009-c99-snprintf.patch   |0
  .../0010-gcc-poison-system-directories.patch   |0
  .../0011-gcc-poison-dir-extend.patch   |0
  .../0012-gcc-4.3.3-SYSROOT_CFLAGS_FOR_TARGET.patch |0
  .../0013-64-bit-multilib-hack.patch|0
  .../0014-optional-libstdc.patch|0
  ...0015-gcc-disable-MASK_RELAX_PIC_CALLS-bit.patch |0
  .../0016-COLLECT_GCC_OPTIONS.patch |0
  ...efaults.h-in-B-instead-of-S-and-t-oe-in-B.patch |0
  .../0018-fortran-cross-compile-hack.patch  |0
  .../0019-cpp-honor-sysroot.patch   |0
  .../0020-MIPS64-Default-to-N64-ABI.patch   |0
  ...C_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch |0
  ...0022-gcc-Fix-argument-list-too-long-error.patch |0
  .../{gcc-6.3 => gcc-6.4}/0023-Disable-sdt.patch|0
  .../gcc/{gcc-6.3 => gcc-6.4}/0024-libtool.patch|0
  ...4-pass-fix-v4bx-to-linker-to-support-EABI.patch |0
  ...tilib-config-files-from-B-instead-of-usin.patch |0
  ...-libdir-from-.la-which-usually-points-to-.patch |0
  .../gcc/{gcc-6.3 => gcc-6.4}/0028-export-CPP.patch |0
  ...AltiVec-generation-on-powepc-linux-target.patch |0
  ...-MULTILIB_OSDIRNAMES-and-other-multilib-o.patch |0
  ...Ensure-target-gcc-headers-can-be-included.patch |0
  ...-t-build-with-disable-dependency-tracking.patch |0
  ...h-host-directory-during-relink-if-inst_pr.patch |0
  ...IBS_DIR-replacement-instead-of-hardcoding.patch |0
  .../0035-aarch64-Add-support-for-musl-ldso.patch   |0
  ...ibcc1-fix-libcc1-s-install-path-and-rpath.patch |0
  ...-handle-sysroot-support-for-nativesdk-gcc.patch |0
  ...et-sysroot-gcc-version-specific-dirs-with.patch |0
  ...-various-_FOR_BUILD-and-related-variables.patch |0
  .../0040-nios2-Define-MUSL_DYNAMIC_LINKER.patch|0
  ...shared-to-link-commandline-for-musl-targe.patch |   87 +
  ...c-libcpp-support-ffile-prefix-map-old-new.patch |0
  ...ug-prefix-map-to-replace-ffile-prefix-map.patch |0
  ...-fdebug-prefix-map-support-to-remap-sourc.patch |0
  ...45-libgcc-Add-knob-to-use-ldbl-128-on-ppc.patch |0
  ...bgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch |0
  ...e-alias-for-__cpu_indicator_init-instead-.patch |0
  .../0048-sync-gcc-stddef.h-with-musl.patch |0
  .../0054_all_nopie-all-flags.patch |0
  .../0055-unwind_h-glibc26.patch|0
  ...-relax-the-restriction-on-subreg-reload-f.patch |0
  ...5-suppress-32-bit-aligned-ldrd-strd-peeph.patch |  194 ++
  ...001-enable-FL_LPAE-flag-for-armv7ve-cores.patch |   67 +
  ...ove-struct-ix86_frame-to-machine_function.patch |  247 +++
  ...ference-of-struct-ix86_frame-to-avoid-cop.patch |   74 +
  ...nst-reference-of-struct-ix86_frame-to-avo.patch |  131 ++
  .../backport/0004-x86-Add-mindirect-branch.patch   | 2154 
  .../backport/0005-x86-Add-mfunction-return.patch   | 1570 ++
  .../0006-x86-Add-mindirect-branch-register.patch   |  946 +
  .../0007-x86-Add-V-register-operand-modifier.patch |  139 ++
  ...w-mindirect-branch-mfunction-return-with-.patch |  304 +++
  ...VALID_REGNUM-in-indirect-thunk-processing.patch |  126 

Re: [OE-core] [PATCH] x86-base.inc: use xf86-video-modesettings as default xserver

[Cal Sullivan]

It looks like Fedora doesn't patch the -intel driver anymore, instead 
they patch xserver to fiddle with the defaults.


https://src.fedoraproject.org/rpms/xorg-x11-server/c/ee515e44b07e37689abf48cf2fffb41578f3bc1d?branch=master

Given the comment and commit description, I'm guessing that list is 
everything older than gen4 (haswell) not already defaulting to something 
else.


I can't find any attempts to upstream the patch... Also, given the 
different formatting, what would be the proper way to bring this into 
OE? Rewrite the commit message, leave Author field intact and add a link?


Thanks,
Cal

On 03/10/2018 09:55 AM, Burton, Ross wrote:
From memory there are some chipsets which the Intel driver *is* better 
on.  I recommend we look at the Fedora patches for the intel driver, I 
believe that massively reduces the chips that the intel driver will be 
the primary driver for. We can then continue to ship both and not 
break anything.


Ross

On 10 March 2018 at 00:23, California Sullivan 
> wrote:


Most distros have switched to this, and we're seeing better results in
some areas as well. E.g., on a NUC6CAYS the x11perf -aa10text and
-rgb10text results see a 20x increase.

[YOCTO #12019].
[YOCTO #12590].

Signed-off-by: California Sullivan
>
---
 meta/conf/machine/include/x86-base.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/include/x86-base.inc
b/meta/conf/machine/include/x86-base.inc
index f8aacea64cc..e6bfdc6f770 100644
--- a/meta/conf/machine/include/x86-base.inc
+++ b/meta/conf/machine/include/x86-base.inc
@@ -34,11 +34,11 @@ XSERVER_X86_EXT = " \
            xserver-xorg-module-libint10 \
            "

-XSERVER_X86_I915 = "xf86-video-intel \
+XSERVER_X86_I915 = "xf86-video-modesetting \
            ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
'mesa-driver-i915', '', d)} \
            "

-XSERVER_X86_I965 = "xf86-video-intel \
+XSERVER_X86_I965 = "xf86-video-modesetting \
            ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
'mesa-driver-i965', '', d)} \
            "

--
2.14.3




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

[OE-core] [PATCH] kernel.bbclass: avoid duplicates in KERNEL_IMAGETYPE_FOR_MAKE

[Andre McCurdy]

Currently if KERNEL_IMAGETYPES contains both vmlinux and vmlinux.gz,
KERNEL_IMAGETYPE_FOR_MAKE will end up containing two copies of
vmlinux, which will result in two calls to "make vmlinux" from
kernel_do_compile().

Avoid duplicating vmlinux in KERNEL_IMAGETYPE_FOR_MAKE plus some
minor non-functional updates to formatting and comments.

Signed-off-by: Andre McCurdy 
---
 meta/classes/kernel.bbclass | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index dc0152f..4bcaa61 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -62,31 +62,37 @@ python __anonymous () {
 type = d.getVar('KERNEL_IMAGETYPE') or ""
 alttype = d.getVar('KERNEL_ALT_IMAGETYPE') or ""
 types = d.getVar('KERNEL_IMAGETYPES') or ""
-kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
 if type not in types.split():
 types = (type + ' ' + types).strip()
 if alttype not in types.split():
 types = (alttype + ' ' + types).strip()
 d.setVar('KERNEL_IMAGETYPES', types)
 
-# some commonly used kernel images aren't generated by the kernel build 
system, such as vmlinux.gz
-# typeformake lists only valid kernel make targets, and post processing 
can be done after the kernel
-# is built (such as using gzip to compress vmlinux)
-typeformake = types.replace('vmlinux.gz', 'vmlinux')
+# KERNEL_IMAGETYPES may contain a mixture of image types supported directly
+# by the kernel build system and others which are created by 
post-processing
+# (e.g. compressing vmlinux -> vmlinux.gz in kernel_do_compile()).
+# KERNEL_IMAGETYPE_FOR_MAKE should contain only image types supported
+# directly by the kernel build system.
+
+typeformake = ""
+for type in types.split():
+if type == 'vmlinux.gz':
+type = 'vmlinux'
+if type in types.split():
+continue
+typeformake = (typeformake + ' ' + type).strip()
+
 d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', typeformake)
 
+kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
+imagedest = d.getVar('KERNEL_IMAGEDEST')
+
 for type in types.split():
 typelower = type.lower()
-imagedest = d.getVar('KERNEL_IMAGEDEST')
-
 d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
-
 d.setVar('FILES_' + kname + '-image-' + typelower, '/' + imagedest + 
'/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
-
 d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname, 
typelower))
-
 d.setVar('PKG_%s-image-%s' % (kname,typelower), 
'%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
-
 d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
 
 image = d.getVar('INITRAMFS_IMAGE')
-- 
1.9.1

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

Re: [OE-core] [oe-core][PATCH 1/7] eudev: fix file conflict when multilib enabled

[Mark Hatle]

On 3/12/18 11:55 AM, Alexander Kanavin wrote:
> On 03/12/2018 08:38 PM, Mark Hatle wrote:
>> In this case, because the user specifically asked for BOTH 32-bit and 64-bit
>> development components to be installed onto the target for their application
>> development.  (This isn't a theoretical problem, but a specific problem from 
>> one
>> of our customers.)
> 
> Fair enough, but you should explain to the customer that Unix-type 
> systems are not designed for this. There are hardcoded assumptions 
> everywhere, that for each component there's only one set of header 
> files, one .pc file, and one -config-style helper binary. Desktop 
> distributions mutually exclude multilib -dev packages for this reason.

The desktop distribution I used (CentOS and Fedora) support this type of
multilib-dev.  I have to use the header file stuff all the time.  I don't know
how they handle the -config case.

But for the .pc files, they are typically installing in the libdir (not the
datadir) for anything that is arch specific.  So that resolves the multilib
issue for that piece.

>> The under the hood it can rename the 'python3.5m-config' to a nonconflicting
>> name (based on the base_libdir, since we know that will be unique)... and 
>> then
>> invoke a post-install script that will define an appropriate priority to 
>> ensure
>> that python3.5m-config will match the final 'python3.5m' version.  (Possibly
>> using update-alternatives to manage this.)
> 
> Here's something I don't get. When the user starts actual development, 
> and calls python3.5-config to fetch configuration values, how do we 
> ensure that the 'right' python3.5m-config is called, from the two that 
> are installed? Same question for pkgconfig - how do we make sure it 
> would look in the 'right' library directory of the two that are available?

For the pkgconfig side, pkgconfig (used to) check gcc for the libdir.  I say
used to cause, I don't know if this was implemented in OE or not.  I don't
remember.  At one time, I believe this was done using "PKG_CONFIG_LIBDIR" and
re-execing the program... but it's been a long time since I looked or cared
specifically.  Most '.pc' files I know of are identical for all multilibs..
having differences is really strange, and makes me really wonder if there are
other issues with the package producing them.

For the python3.5m-config stuff, (assuming we create a general purpose system to
resolve this).  It should be able to query the executable that was installed and
figure out which base_libdir it is associated with, and then use that
information to switch to the correct '-config'.  If the user knows they want a
specific libdir version, then that would be up to the specific user to invoke.

This way the user can run a version of the default with reasonable expectations
the default will match their running system -- or manually specific the file and
type they want to execute and get the exact version they care about.


I think my objective is, primarily, that the 'default' behavior of the system
needs to be reasonable.   So for any user who does not declare a specific
'version to be used', the 'right thing happens automatically'.   Where the right
thing would be:

*) Use a common configuration that works everywhere.
*) Determine [automatically] the configuration that matches the system.
*) Stop and tell the user that it does not know the right solution. (Error)

Then an advanced user to select a specific version of the 'alternatives'.  The
key with all of this is that it needs to be 'reasonable' for both the recipe
maintainer and the end user.  Having to manually rename things, use the existing
update-alternatives, etc really isn't a good idea -- even if it solves (some of)
the user issues.

--Mark

> Alex
> 

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

Re: [OE-core] [oe-core][PATCH 1/7] eudev: fix file conflict when multilib enabled

[Alexander Kanavin]

On 03/12/2018 08:38 PM, Mark Hatle wrote:

In this case, because the user specifically asked for BOTH 32-bit and 64-bit
development components to be installed onto the target for their application
development.  (This isn't a theoretical problem, but a specific problem from one
of our customers.)


Fair enough, but you should explain to the customer that Unix-type 
systems are not designed for this. There are hardcoded assumptions 
everywhere, that for each component there's only one set of header 
files, one .pc file, and one -config-style helper binary. Desktop 
distributions mutually exclude multilib -dev packages for this reason.



The under the hood it can rename the 'python3.5m-config' to a nonconflicting
name (based on the base_libdir, since we know that will be unique)... and then
invoke a post-install script that will define an appropriate priority to ensure
that python3.5m-config will match the final 'python3.5m' version.  (Possibly
using update-alternatives to manage this.)


Here's something I don't get. When the user starts actual development, 
and calls python3.5-config to fetch configuration values, how do we 
ensure that the 'right' python3.5m-config is called, from the two that 
are installed? Same question for pkgconfig - how do we make sure it 
would look in the 'right' library directory of the two that are available?


Alex

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

Re: [OE-core] [oe-core][PATCH 1/7] eudev: fix file conflict when multilib enabled

[Mark Hatle]

On 3/12/18 3:13 AM, Alexander Kanavin wrote:
> On 03/12/2018 11:12 AM, Zhang Xiao wrote:
>> Config file udev.pc conflicts between 32 and 64 bit packages.
>> Use update-alternatives to add base_libdir as suffix to avoid it.
>> -inherit autotools update-rc.d qemu pkgconfig distro_features_check
>> +inherit autotools update-rc.d qemu pkgconfig distro_features_check 
>> update-alternatives
>> +
>> +MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
>> +
>> +ALTERNATIVE_${PN}-dev = "udev.pc"
>> +ALTERNATIVE_LINK_NAME[udev.pc] = "${datadir}/pkgconfig/udev.pc"
>> +ALTERNATIVE_TARGET[udev.pc] = 
>> "${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}"
>> +
>> +PACKAGE_PREPROCESS_FUNCS += "eudev_alternative_rename"
>> +
>> +eudev_alternative_rename() {
>> +   # rename udev.pc
>> +   mv ${PKGD}${datadir}/pkgconfig/udev.pc 
>> ${PKGD}${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}
>> +}
> 
> I'm afraid, I have to say no to the entire patchset. It's abusing 
> update-alternatives to do what it was never meant for, and effectively 
> renders one of the -dev packages broken, just so that package manager 
> can satisfy dependencies.
> 
> Let's first take a look at why dnf wants to install two different -dev 
> packages in the first place, and why these seven recipes need to be 
> fixed in particular. My understanding is multilib feature should be used 
> only for libraries, and not for supporting development files.

In this case, because the user specifically asked for BOTH 32-bit and 64-bit
development components to be installed onto the target for their application
development.  (This isn't a theoretical problem, but a specific problem from one
of our customers.)

I had a chance to talk to RP a bit about this today at ELC.  We agree we need a
generic mechanism to handle these types of problems.

For a '.pc' file, there really should be no reason (under normal circumstances)
for them to conflict.  Since if they are are specific they don't belong in the
datadir, but belong in the libdir.

For non-.pc files, if they are 'pkgconfig like', they should be converted to
package config (for the most part this seems to have happened, with a few things
'missed'.)

The remainder then are things that can't be converted for some reason.  So the
'config', or helper or whatever files really need to 'match' the installed 
binary.

There is no way to predict ahead of time which binary is going to be installed
-- so we really need some type of automated processing that can be used to say:

1) This is a known multilib issue.
2) This file is related to this other file, and should be installed to match.

Under the hood if it uses update-alternatives or anything else doesn't matter --
but in the recipe it should not explicitly require the rename, the ALTERNATIVE
and related declarations etc...

Perhaps something like:

MULTILIB_CONFLICT = "${bindir}/python3.5m-config:${bindir}/python3.5m"

The under the hood it can rename the 'python3.5m-config' to a nonconflicting
name (based on the base_libdir, since we know that will be unique)... and then
invoke a post-install script that will define an appropriate priority to ensure
that python3.5m-config will match the final 'python3.5m' version.  (Possibly
using update-alternatives to manage this.)

--Mark

> Alex
> 

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

Re: [OE-core] [rocko][PATCH 1/1] go: Upgrade 1.9 to 1.9.4 stable release

[Otavio Salvador]

On Mon, Mar 12, 2018 at 8:44 AM, Burton, Ross  wrote:
> Note that stable branch policy is to cherry-pick security fixes unless
> they're too complicated/risky to pick (openssl is the notable example here).

I strong believe Go should be dealt in same way; it is known to be
good at supporting forwarding upgrades easily and it does fix some
security and other bugs. Picking them would be pointless and risky.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [rocko][PATCH 0/1] backport go 1.9.4 update to rocko

[Otavio Salvador]

On Mon, Mar 12, 2018 at 8:29 AM, Matt Madison  wrote:
> One of the changes included in this point release update
> fixes an issue with the construction of Go's shared runtim
> library, so it would be great to backport this to rocko
> to fix [YOCTO 12592].

Acked-by: Otavio Salvador 

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] core-image-minimal-initramfs: prepare initramfs for NFS boot

[André Draszik]

Hi.

It'd be nice if this was part of initramfs-framework instead.

In particular some devices need a bit more than ifconfig & route, e.g.
configuration of SoC internal Ethernet switches.

As it is, this patch is not very generic, whereas if it was integrated with
the initramfs-framework, another module could take care of the driver /
hardware specifics, and this module would just do the actual mounting of the
ROOTFS.

The remaining bits, like mount --move of /proc are also already part of
initramfs-framework.

That way, this new addition would be useful on a wide range of devices.


Cheers,
Andre'

On Mon, 2018-03-12 at 16:33 +0200, Oleksii Konoplitskyi wrote:
> It helps to boot device by mounting rootfs via NFS when network
> drivers are built as modules.
> We include modules in core-image-minimal-initramfs image
> and start kernel with specifying custom rdinit in cmdline:
>rdinit=/init-nfs.sh
> 
> NFS and IP parameters should be passed to kernel as usual.
> For example:
>ip=192.168.0.11::192.168.0.1:255.255.255.0:linux:eth0:off
>nfsroot=192.168.0.10:/exported_nfs,nfsvers=3,tcp
>root=/dev/nfs rw loglevel=7 rdinit=/init-nfs.sh
> 
> To use this initramfs, one could put the following
> to conf/local.conf:
>INITRAMFS_LOAD_KERNEL_MODULES = "kernel-module-igb"
>INITRAMFS_IMAGE_BUNDLE = "1"
>INITRAMFS_IMAGE = "core-image-minimal-initramfs"
> 
> INITRAMFS_LOAD_KERNEL_MODULES is a space-separated list of
> modules that will be added to initramfs.
> 
> Signed-off-by: Andrii Bordunov 
> Signed-off-by: Oleksii Konoplitskyi 
> ---
>  .../images/core-image-minimal-initramfs.bb |   2 +-
>  meta/recipes-core/initrdscripts/files/init-nfs.sh  | 108
> +
>  .../initrdscripts/initramfs-nfs-boot_1.0.bb|  14 +++
>  3 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-core/initrdscripts/files/init-nfs.sh
>  create mode 100644 meta/recipes-core/initrdscripts/initramfs-nfs-
> boot_1.0.bb
> 
> diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb
> b/meta/recipes-core/images/core-image-minimal-initramfs.bb
> index c446e87..bf794bf 100644
> --- a/meta/recipes-core/images/core-image-minimal-initramfs.bb
> +++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb
> @@ -3,7 +3,7 @@ DESCRIPTION = "Small image capable of booting a device.
> The kernel includes \
>  the Minimal RAM-based Initial Root Filesystem (initramfs), which finds
> the \
>  first 'init' program more efficiently."
>  
> -PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install initramfs-
> live-install-efi ${VIRTUAL-RUNTIME_base-utils} udev base-passwd
> ${ROOTFS_BOOTSTRAP_INSTALL}"
> +PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install initramfs-
> live-install-efi ${VIRTUAL-RUNTIME_base-utils} udev base-passwd
> ${ROOTFS_BOOTSTRAP_INSTALL} initramfs-nfs-boot"
>  
>  # Do not pollute the initrd image with rootfs features
>  IMAGE_FEATURES = ""
> diff --git a/meta/recipes-core/initrdscripts/files/init-nfs.sh
> b/meta/recipes-core/initrdscripts/files/init-nfs.sh
> new file mode 100644
> index 000..31a55ec
> --- /dev/null
> +++ b/meta/recipes-core/initrdscripts/files/init-nfs.sh
> @@ -0,0 +1,108 @@
> +#!/bin/sh
> +
> +CONSOLE="/dev/console"
> +PATH=/sbin:/bin:/usr/sbin:/usr/bin
> +ROOT_MOUNT="/rootfs"
> +
> +fatal()
> +{
> + echo $1 >$CONSOLE
> + echo >$CONSOLE
> + exec sh
> +}
> +
> +net_up()
> +{
> + [ "$(ifconfig $PARAM_IFNAME | awk '/inet addr/{print
> substr($2,6)}')" = "$PARAM_IP" ] && return
> + #load all ethernet drivers if network interface is not configured
> + MODULES="$(find /lib/modules/*/kernel/drivers/net/ethernet -name
> \*.ko | sed -e 's,^.*/,,' -e 's,\.ko$,,')"
> + [ -z "$MODULES" ] && fatal "Ethernet drivers list is emty.
> Nothing to load."
> + modprobe -a $MODULES
> +
> + ifconfig $PARAM_IFNAME $PARAM_IP netmask $PARAM_NETMASK ||
> + fatal "Failed to configure ethernet interface"
> + route add default gw $PARAM_GW ||
> + fatal "Failed to set default gateway"
> +}
> +
> +
> +#TODO: IPv6 is not supported yet
> +mount_nfs()
> +{
> + mkdir $ROOT_MOUNT
> + for i in $(seq 1 10)
> + do
> + mount -t nfs "$PARAM_NFSROOT_PATH" -o
> nolock,"$PARAM_NFSROOT_OPTS" $ROOT_MOUNT && return
> + sleep 1
> + done
> + fatal "Could not mount rootfs via nfs"
> +}
> +
> +
> +early_setup()
> +{
> + mkdir -p /proc
> + mkdir -p /sys
> + mount -t proc proc /proc
> + mount -t sysfs sysfs /sys
> + mount -t devtmpfs none /dev
> +
> + mkdir -p /run
> + mkdir -p /var/run
> +}
> +
> +
> +#TODO: IPv6 is not supported yet
> +read_args()
> +{
> + [ -z "$CMDLINE" ] && CMDLINE=$(cat /proc/cmdline)
> + for arg in $CMDLINE; do
> + optarg=$(expr "x$arg" : 'x[^=]*=\(.*\)'$)
> + case $arg in
> + ip=*)
> + 

[OE-core] [PATCH 4/4] lib/oe/patch.py: add a warning if patch context was ignored

[Alexander Kanavin]

Ignoring patch context increases the chances of patches being
applied incorrectly. Depending on what code is being patched, this can go
completely unnoticed and create subtle bugs, sometimes with security 
implications.

Please see here for a specific example:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450

On the other hand, we cannot simply force all patch context to match exactly:
doing this would break a lot of recipes suddenly, across all layers.

So let's try a softer approach: issue a warning, and gently update
patches over a longer span of time. When most of the warnings are eliminated,
we can start enforcing a strict patch application policy.

I do understand that this patch creates a lot of warnings all of a sudden, 
however
I believe the problem does need to be addressed. All of oe-core recipes have 
their
context already fixed.

Sample warning:

WARNING: vulkan-1.0.61.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly 
applied patches.
The context lines in the patches can be updated with devtool:

devtool modify 
devtool finish --force-patch-refresh  

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored).
Details:
Applying patch demos-Don-t-build-tri-or-cube.patch
patching file demos/CMakeLists.txt
Hunk #1 succeeded at 63 (offset 2 lines).
Hunk #2 succeeded at 76 with fuzz 1 (offset 2 lines).

[YOCTO #10450]

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/patch.py | 16 
 1 file changed, 16 insertions(+)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index f02dee8d27d..bfa7d218792 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -36,6 +36,22 @@ def runcmd(args, dir = None):
 (exitstatus, output) = oe.utils.getstatusoutput(cmd)
 if exitstatus != 0:
 raise CmdError(cmd, exitstatus >> 8, output)
+if " fuzz " in output:
+bb.warn("""
+Some of the context lines in patches were ignored. This can lead to 
incorrectly applied patches.
+The context lines in the patches can be updated with devtool:
+
+devtool modify 
+devtool finish --force-patch-refresh  
+
+Then the updated patches and the source tree (in devtool's workspace)
+should be reviewed to make sure the patches apply in the correct place
+and don't introduce duplicate lines (which can, and does happen
+when some of the context is ignored). Further information:
+http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
+https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
+Details:
+{}""".format(output))
 return output
 
 finally:
-- 
2.16.1

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

[OE-core] [PATCH 3/4] oe-selftest: add a test for failing package post-installation scriptlets

[Alexander Kanavin]

The test runs a scriptlet that has an intentionally failing command in the 
middle
and checks for two things:
1) that bitbake does warn the user about the failure
2) that scriptlet execution stops at that point.

The test is run for all three package types: rpm, deb, ipk.

Signed-off-by: Alexander Kanavin 
---
 .../recipes-test/postinst/postinst_1.0.bb  | 14 +++-
 meta/lib/oeqa/selftest/cases/runtime_test.py   | 37 ++
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/meta-selftest/recipes-test/postinst/postinst_1.0.bb 
b/meta-selftest/recipes-test/postinst/postinst_1.0.bb
index d4bab6dcc22..913bfabf89e 100644
--- a/meta-selftest/recipes-test/postinst/postinst_1.0.bb
+++ b/meta-selftest/recipes-test/postinst/postinst_1.0.bb
@@ -3,11 +3,12 @@ LICENSE = "MIT"
 
 inherit allarch
 
-PACKAGES = "${PN}-rootfs ${PN}-delayed-a ${PN}-delayed-b"
+PACKAGES = "${PN}-rootfs ${PN}-delayed-a ${PN}-delayed-b ${PN}-rootfs-failing"
 
 ALLOW_EMPTY_${PN}-rootfs = "1"
 ALLOW_EMPTY_${PN}-delayed-a = "1"
 ALLOW_EMPTY_${PN}-delayed-b = "1"
+ALLOW_EMPTY_${PN}-rootfs-failing = "1"
 
 RDEPENDS_${PN}-delayed-a = "${PN}-rootfs"
 RDEPENDS_${PN}-delayed-b = "${PN}-delayed-a"
@@ -58,3 +59,14 @@ pkg_postinst_ontarget_${PN}-delayed-b () {
 
 touch ${TESTDIR}/delayed-b
 }
+
+# This scriptlet intentionally includes a bogus command in the middle to test 
+# that we catch and report such errors properly.
+pkg_postinst_${PN}-rootfs-failing () {
+mkdir -p $D${TESTDIR}
+touch $D${TESTDIR}/rootfs-before-failure
+run_a_really_broken_command
+# Scriptlet execution should stop here; the following commands are NOT 
supposed to run.
+# (oe-selftest checks for it).
+touch $D${TESTDIR}/rootfs-after-failure
+}
diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py 
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 1c69255b568..9c9b4b34111 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -221,3 +221,40 @@ class Postinst(OESelftestTestCase):
 for filename in ("rootfs", "delayed-a", "delayed-b"):
 status, output = qemu.run_serial("test -f %s && 
echo found" % os.path.join(targettestdir, filename))
 self.assertEqual(output, "found", "%s was not 
present on boot" % filename)
+
+
+
+def test_failing_postinst(self):
+"""
+Summary:The purpose of this test case is to verify that 
post-installation
+scripts that contain errors are properly reported.
+Expected:   The scriptlet failure is properly reported.
+The file that is created after the error in the 
scriptlet is not present.
+Product: oe-core
+Author: Alexander Kanavin 
+"""
+
+import oe.path
+
+vars = get_bb_vars(("IMAGE_ROOTFS", "sysconfdir"), 
"core-image-minimal")
+rootfs = vars["IMAGE_ROOTFS"]
+self.assertIsNotNone(rootfs)
+sysconfdir = vars["sysconfdir"]
+self.assertIsNotNone(sysconfdir)
+# Need to use oe.path here as sysconfdir starts with /
+hosttestdir = oe.path.join(rootfs, sysconfdir, "postinst-test")
+
+for classes in ("package_rpm", "package_deb", "package_ipk"):
+with self.subTest(package_class=classes):
+features = 'CORE_IMAGE_EXTRA_INSTALL = 
"postinst-rootfs-failing"\n'
+features += 'PACKAGE_CLASSES = "%s"\n' % classes
+self.write_config(features)
+bb_result = bitbake('core-image-minimal')
+self.assertGreaterEqual(bb_result.output.find("Intentionally 
failing postinstall scriptlets of ['postinst-rootfs-failing'] to defer them to 
first boot is deprecated."), 0,
+"Warning about a failed scriptlet not found in bitbake 
output: %s" %(bb_result.output))
+
+self.assertTrue(os.path.isfile(os.path.join(hosttestdir, 
"rootfs-before-failure")),
+"rootfs-before-failure file was not 
created")
+self.assertFalse(os.path.isfile(os.path.join(hosttestdir, 
"rootfs-after-failure")),
+"rootfs-after-failure file was created")
+
-- 
2.16.1

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

[OE-core] [PATCH 2/4] meta/lib/oe/package_manager.py: warn about failing scriptlets for all package types

[Alexander Kanavin]

Previously this was done only for rpm packages; now also ipk/deb scriptlet
failures are reported.

In the future this will become a hard error, but it can't yet happen
due to the legacy 'exit 1' way of deferring scriptlet execution to first boot 
which
needs a deprecation period.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/package_manager.py | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index c10efb8df4c..0c5cf3cf7f3 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -83,6 +83,11 @@ def opkg_query(cmd_output):
 
 return output
 
+# Note: this should be bb.fatal in the future.
+def failed_postinsts_warn(pkgs, log_path):
+bb.warn("""Intentionally failing postinstall scriptlets of %s to defer 
them to first boot is deprecated. Please place them into 
pkg_postinst_ontarget_${PN} ().
+If deferring to first boot wasn't the intent, then scriptlet failure may mean 
an issue in the recipe, or a regression elsewhere.
+Details of the failure are in %s.""" %(pkgs, log_path))
 
 class Indexer(object, metaclass=ABCMeta):
 def __init__(self, d, deploy_dir):
@@ -709,8 +714,7 @@ class RpmPM(PackageManager):
 failed_scriptlets_pkgnames[line.split()[-1]] = True
 
 if len(failed_scriptlets_pkgnames) > 0:
-bb.warn("Intentionally failing postinstall scriptlets of %s to 
defer them to first boot is deprecated. Please place them into 
pkg_postinst_ontarget_${PN} ()." %(list(failed_scriptlets_pkgnames.keys(
-bb.warn("If deferring to first boot wasn't the intent, then 
scriptlet failure may mean an issue in the recipe, or a regression elsewhere.")
+failed_postinsts_warn(list(failed_scriptlets_pkgnames.keys()), 
self.d.expand("${T}/log.do_rootfs"))
 for pkg in failed_scriptlets_pkgnames.keys():
 self.save_rpmpostinst(pkg)
 
@@ -1172,6 +1176,13 @@ class OpkgPM(OpkgDpkgPM):
 bb.note(cmd)
 output = subprocess.check_output(cmd.split(), 
stderr=subprocess.STDOUT).decode("utf-8")
 bb.note(output)
+failed_pkgs = []
+for line in output.split('\n'):
+if line.endswith("configuration required on target."):
+bb.warn(line)
+failed_pkgs.append(line.split(".")[0])
+if failed_pkgs:
+failed_postinsts_warn(failed_pkgs, 
self.d.expand("${T}/log.do_rootfs"))
 except subprocess.CalledProcessError as e:
 (bb.fatal, bb.warn)[attempt_only]("Unable to install packages. "
   "Command '%s' returned %d:\n%s" %
@@ -1435,9 +1446,10 @@ class DpkgPM(OpkgDpkgPM):
 stderr=subprocess.STDOUT).decode("utf-8")
 bb.note(output)
 except subprocess.CalledProcessError as e:
-bb.note("%s for package %s failed with %d:\n%s" %
+bb.warn("%s for package %s failed with %d:\n%s" %
 (control_script.name, pkg_name, e.returncode,
 e.output.decode("utf-8")))
+failed_postinsts_warn([pkg_name], 
self.d.expand("${T}/log.do_rootfs"))
 failed_pkgs.append(pkg_name)
 break
 
-- 
2.16.1

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

[OE-core] [PATCH 1/4] package.bbclass: run pre/post installation/removal scriptlets using sh -e

[Alexander Kanavin]

This allows catching errors in the scriptlets which would otherwise
go unnoticed, e.g. this sequence:

bogus_command
proper_command

would work just fine without any visible warnings or errors.

This was previously done only for rpm packages; this patch replaces
the rpm-specific tweak with one that works for all package types.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/package.bbclass | 12 
 meta/classes/package_rpm.bbclass |  8 
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 317c77585fc..83f53a49ef6 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1343,6 +1343,17 @@ fi
 postinst += postinst_ontarget
 d.setVar('pkg_postinst_%s' % pkg, postinst)
 
+def add_set_e_to_scriptlets(pkg):
+for scriptlet_name in ('pkg_preinst', 'pkg_postinst', 'pkg_prerm', 
'pkg_postrm'):
+scriptlet = d.getVar('%s_%s' % (scriptlet_name, pkg))
+if scriptlet:
+scriptlet_split = scriptlet.split('\n')
+if scriptlet_split[0].startswith("#!"):
+scriptlet = scriptlet_split[0] + "\nset -e\n" + 
"\n".join(scriptlet_split[1:])
+else:
+scriptlet = "set -e\n" + "\n".join(scriptlet_split[0:])
+d.setVar('%s_%s' % (scriptlet_name, pkg), scriptlet)
+
 def write_if_exists(f, pkg, var):
 def encode(str):
 import codecs
@@ -1439,6 +1450,7 @@ fi
 write_if_exists(sf, pkg, 'FILES')
 write_if_exists(sf, pkg, 'CONFFILES')
 process_postinst_on_target(pkg, d.getVar("MLPREFIX"))
+add_set_e_to_scriptlets(pkg)
 write_if_exists(sf, pkg, 'pkg_postinst')
 write_if_exists(sf, pkg, 'pkg_postrm')
 write_if_exists(sf, pkg, 'pkg_preinst')
diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index e26b2ad6625..af64ef62c58 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -470,12 +470,12 @@ python write_specfile () {
 
 # Now process scriptlets
 if splitrpreinst:
-spec_scriptlets_bottom.append('%%pre -n %s -p "/bin/sh -e"' % 
splitname)
+spec_scriptlets_bottom.append('%%pre -n %s' % splitname)
 spec_scriptlets_bottom.append('# %s - preinst' % splitname)
 spec_scriptlets_bottom.append(splitrpreinst)
 spec_scriptlets_bottom.append('')
 if splitrpostinst:
-spec_scriptlets_bottom.append('%%post -n %s -p "/bin/sh -e"' % 
splitname)
+spec_scriptlets_bottom.append('%%post -n %s' % splitname)
 spec_scriptlets_bottom.append('# %s - postinst' % splitname)
 spec_scriptlets_bottom.append(splitrpostinst)
 spec_scriptlets_bottom.append('')
@@ -564,12 +564,12 @@ python write_specfile () {
 spec_preamble_top.append('')
 
 if srcrpreinst:
-spec_scriptlets_top.append('%pre -p "/bin/sh -e"')
+spec_scriptlets_top.append('%pre')
 spec_scriptlets_top.append('# %s - preinst' % srcname)
 spec_scriptlets_top.append(srcrpreinst)
 spec_scriptlets_top.append('')
 if srcrpostinst:
-spec_scriptlets_top.append('%post -p "/bin/sh -e"')
+spec_scriptlets_top.append('%post')
 spec_scriptlets_top.append('# %s - postinst' % srcname)
 spec_scriptlets_top.append(srcrpostinst)
 spec_scriptlets_top.append('')
-- 
2.16.1

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

[OE-core] [PATCH 2/2] build-recipe-list: build universe instead of world

[Ross Burton]

Building world means recipes that are excluded from world build for whatever
reason get skipped from the manifests, which isn't useful.  Instead building
universe and pass -k so that the expected dependency failures are not fatal.

Signed-off-by: Ross Burton 
---
 scripts/distro/build-recipe-list.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/distro/build-recipe-list.py 
b/scripts/distro/build-recipe-list.py
index 407debaa76a..3f5f7c2fcc9 100755
--- a/scripts/distro/build-recipe-list.py
+++ b/scripts/distro/build-recipe-list.py
@@ -45,7 +45,7 @@ def generate_recipe_list():
 
 # doing bitbake distrodata
 for machine in machine_list:
-os.system('MACHINE='+ machine + ' bitbake world -c distrodata')
+os.system('MACHINE='+ machine + ' bitbake -k universe -c distrodata')
 shutil.copy('tmp/log/distrodata.csv', 'distrodata/' + fnformat % 
machine)
 
 for machine in machine_list:
-- 
2.11.0

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

[OE-core] [PATCH 1/2] meta: remove some EXCLUDE_FROM_WORLD assignments

[Ross Burton]

Now that we have recipe-specific-sysroots we don't need to exclude recipes from
world builds because they conflict with other recipes, as they'll all be built
with their own sysroots.

Signed-off-by: Ross Burton 
---
 meta/recipes-connectivity/bluez5/bluez5.inc  | 2 --
 meta/recipes-graphics/mesa/mesa.inc  | 3 ---
 meta/recipes-graphics/xorg-lib/libx11.inc| 4 
 meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb | 6 --
 4 files changed, 15 deletions(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index a73d9568e58..ae2a833c0cb 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -136,8 +136,6 @@ SYSTEMD_SERVICE_${PN} = 
"${@bb.utils.contains('PACKAGECONFIG', 'systemd', 'bluet
 INITSCRIPT_PACKAGES = "${PN}"
 INITSCRIPT_NAME_${PN} = "bluetooth"
 
-EXCLUDE_FROM_WORLD = "1"
-
 do_compile_ptest() {
oe_runmake buildtests
 }
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 88ba0050d5e..23ae651f7d1 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -99,9 +99,6 @@ FULL_OPTIMIZATION_append = " -fno-omit-frame-pointer"
 
 CFLAGS_append_armv5 = " -DMISSING_64BIT_ATOMICS"
 
-# Multiple virtual/gl providers being built breaks staging
-EXCLUDE_FROM_WORLD = "1"
-
 # Remove the mesa dependency on mesa-dev, as mesa is empty
 RDEPENDS_${PN}-dev = ""
 
diff --git a/meta/recipes-graphics/xorg-lib/libx11.inc 
b/meta/recipes-graphics/xorg-lib/libx11.inc
index b04eafbdf2f..4af40ab8a1c 100644
--- a/meta/recipes-graphics/xorg-lib/libx11.inc
+++ b/meta/recipes-graphics/xorg-lib/libx11.inc
@@ -35,7 +35,3 @@ PACKAGES =+ "${PN}-xcb"
 FILES_${PN} += "${datadir}/X11/XKeysymDB ${datadir}/X11/XErrorDB 
${datadir}/X11/Xcms.txt"
 FILES_${PN}-xcb += "${libdir}/libX11-xcb.so.*"
 FILES_${PN}-locale += "${datadir}/X11/locale ${libdir}/X11/locale"
-
-# Multiple libx11 derivatives from from this file and are selected by 
virtual/libx11
-# A world build should only build the correct version, not all of them.
-EXCLUDE_FROM_WORLD = "1"
diff --git a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb 
b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 889878ddc00..d63701e5a05 100644
--- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -24,9 +24,3 @@ do_configure() {
oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
   -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts
 }
-
-
-# There is no reason to build this on its own.
-#
-EXCLUDE_FROM_WORLD = "1"
-
-- 
2.11.0

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

[OE-core] [PATCH] iproute2: fix rebuild failures

[Trevor Woerner]

When rebuilding iproute2, many such instances of the following build failure
occur:

| make[1]: Entering directory 
'.../iproute2/4.14.1-r0/iproute2-4.14.1/lib'
| Makefile:1: ../config.mk: No such file or directory
| make[1]: *** No rule to make target '../config.mk'.  Stop.

Signed-off-by: Trevor Woerner 
---
 meta/recipes-connectivity/iproute2/iproute2.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/iproute2/iproute2.inc 
b/meta/recipes-connectivity/iproute2/iproute2.inc
index b404eedbfb..4fbfec6f08 100644
--- a/meta/recipes-connectivity/iproute2/iproute2.inc
+++ b/meta/recipes-connectivity/iproute2/iproute2.inc
@@ -13,6 +13,8 @@ DEPENDS = "flex-native bison-native iptables elfutils"
 
 inherit update-alternatives bash-completion pkgconfig
 
+CLEANBROKEN = "1"
+
 PACKAGECONFIG ??= "tipc"
 PACKAGECONFIG[tipc] = ",,libmnl,"
 
-- 
2.14.1.459.g238e487ea

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

[OE-core] IMPORTANT: do_patch() fuzz warnings and how to deal with them

[Alexander Kanavin]

*Executive summary*

do_patch() will shortly start issuing warnings when recipe patches are 
applied with some of the patch context ignored. This email explains why 
this is necessary, and how the warnings can be eliminated.


*What is patch fuzz?*

Patch fuzz is a situation when the patch tool ignores some of the 
context lines in order to apply the patch. Consider this example:


Patch to be applied:


context line 1
context line 2
context line 3
+newly added line
context line 4
context line 5
context line 6


Original source code:


different context line 1
different context line 2
context line 3
context line 4
different context line 5
different context line 6


Outcome:


different context line 1
different context line 2
context line 3
newly added line
context line 4
different context line 5
different context line 6


Chances are, the newly added line was actually added in a completely 
wrong location, or it was already in the original source, and was added 
for the second time. This is especially possible, if the context line 3 
and 4 are blank or have only generic things in them like #endif or }. 
Even worse, there is currently no warning when this happens, and 
depending on the patched code, it can (and does) still compile without 
errors.


*What is changing*

When patch fuzz is detected, there will be a warning printed, similar to 
this:


WARNING: vulkan-1.0.61.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to 
incorrectly applied patches.

The context lines in the patches can be updated with devtool:

devtool modify 
devtool finish --force-patch-refresh  

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored).
Details:
Applying patch demos-Don-t-build-tri-or-cube.patch
patching file demos/CMakeLists.txt
Hunk #1 succeeded at 63 (offset 2 lines).
Hunk #2 succeeded at 76 with fuzz 1 (offset 2 lines).

*How to elimimate the warnings?*

Use devtool command as explained by the warning. First, unpack the 
source into devtool workspace:


devtool modify 

This will apply all the patches, and create new commits out of them in 
the workspace - with the patch context updated.


Then, replace the patches in the recipe layer:

devtool finish --force-patch-refresh  

The patch updates need be reviewed (preferably, with a side-by-side diff 
tool) to ensure they are indeed doing the right thing:


1) they get applied in the correct location;
2) they do not introduce duplicate lines, or otherwise do things that 
are not anymore necessary.


To confirm these things, you can also review the patched source code in 
devtool's workspace, typically in /workspace/sources//


Once the review is done, you can create and publish a layer commit with 
the patch updates that modify the context. Devtool may also refresh 
other things in the patches, those can be discarded.



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

[OE-core] Yocto Project Status WW11’18

[Jordan, Robin L]

Current Dev Position: YP 2.5 M3 final close out.

Next Deadline: YP 2.5 M3 cut off was 2/19/18

*** FEATURE FREEZE for 2.5 has passed ***


SWAT lead is currently Cal.

SWAT team rotation: Cal -> Armin on March 16, 2018

SWAT team rotation: Armin -> Ross on March 23, 2018

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


Key Status/Updates:

  *   The Embedded Linux Conference is in Portland this week!
  *   YP 2.4.2 RC2 QA report is being discussed and is expected to be released 
this week. 
(https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2).
  *   We are changing the planning process and Milestone tracking in Bugzilla.  
More details can be found here:  
https://lists.yoctoproject.org/pipermail/yocto/2018-March/040226.html
  *   A new uninative release was made (1.8) because distributions are moving 
to glibc 2.27 and this broke the old uninative. People using uninative should 
upgrade to this.
  *   GCC 6.x with the latest security fixes is currently in rocko/pyro/morty 
-next thanks to Martin and Juro. They are undergoing autobuilder testing now 
but we hope they’ll be merged soon.

  *   Performance metrics indicate that a recent merge has caused a slowdown in 
build times.  It is suspected that the glibc upgrade is the cause of this 
although help would be appreciated to verify and possibly mitigate this.
  *   Flood of last-minute upgrades continuing to be reviewed and merged if 
high reward or low impact.
  *   Go upgrade/improvements were merged.  For 2.5 we will be shipping both 
1.9.4 and 1.10, but plan to drop 1.9.x from master once 1.10 doesn’t present 
compatibility problems.
  *   EFI image refactoring patches were merged. The gist of these are that 
/boot is now under package manager control instead of injected at image 
creation.
  *   A number of patch refresh patches were merged. These are to solve 
problems with patches applied with “fuzz”, where patch will note that the 
context isn’t correct anymore but the differences are hopefully small enough to 
apply anyway.  Sometimes this is useful (other changes causing the target lines 
to move), sometimes it’s actively harmful (patch applied incorrectly, silently 
breaking behaviour). We hope to warn when fuzz is detected during the 2.6 cycle 
so these patches are removing fuzz from oe-core.  Expect a mail to the lists 
soon explaining how to find and remove fuzz.
  *   We are continuing to work on the autobuilder changes and for various 
reasons (inc. changes in people).  We would be in much better shape to switch 
to the new codebase before release, rather than waiting until early 2.6 to pick 
this work up again by which time we would have lost people and context. If we 
are to switch, we need to build M3 with the new infrastructure. We plan to make 
this switch for M3.


Planned upcoming dot releases:

YP 2.3.4 (Pyro) will be built when GCC backports are merged.

YP 2.2.4 (Morty) will be built when GCC backports are merged.

YP 2.4.3 (Roko) is planned for post YP 2.5.


Key YP 2.5 Dates are:

YP 2.5 M3 is in feature freeze.  See status above.

YP 2.5 M3 was scheduled for release 3/2/18

YP 2.5 M4 cut off of 4/2/18

YP 2.5 M4 release of 4/27/18


Tracking Metrics:

WDD 2673 (last week 2663)

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


Key Status Links for YP:

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

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

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


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


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


Robin Jordan
Yocto Project Program Manager
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] core-image-minimal-initramfs: prepare initramfs for NFS boot

[Oleksii Konoplitskyi]

It helps to boot device by mounting rootfs via NFS when network
drivers are built as modules.
We include modules in core-image-minimal-initramfs image
and start kernel with specifying custom rdinit in cmdline:
   rdinit=/init-nfs.sh

NFS and IP parameters should be passed to kernel as usual.
For example:
   ip=192.168.0.11::192.168.0.1:255.255.255.0:linux:eth0:off
   nfsroot=192.168.0.10:/exported_nfs,nfsvers=3,tcp
   root=/dev/nfs rw loglevel=7 rdinit=/init-nfs.sh

To use this initramfs, one could put the following
to conf/local.conf:
   INITRAMFS_LOAD_KERNEL_MODULES = "kernel-module-igb"
   INITRAMFS_IMAGE_BUNDLE = "1"
   INITRAMFS_IMAGE = "core-image-minimal-initramfs"

INITRAMFS_LOAD_KERNEL_MODULES is a space-separated list of
modules that will be added to initramfs.

Signed-off-by: Andrii Bordunov 
Signed-off-by: Oleksii Konoplitskyi 
---
 .../images/core-image-minimal-initramfs.bb |   2 +-
 meta/recipes-core/initrdscripts/files/init-nfs.sh  | 108 +
 .../initrdscripts/initramfs-nfs-boot_1.0.bb|  14 +++
 3 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-core/initrdscripts/files/init-nfs.sh
 create mode 100644 meta/recipes-core/initrdscripts/initramfs-nfs-boot_1.0.bb

diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb 
b/meta/recipes-core/images/core-image-minimal-initramfs.bb
index c446e87..bf794bf 100644
--- a/meta/recipes-core/images/core-image-minimal-initramfs.bb
+++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb
@@ -3,7 +3,7 @@ DESCRIPTION = "Small image capable of booting a device. The 
kernel includes \
 the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \
 first 'init' program more efficiently."
 
-PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install 
initramfs-live-install-efi ${VIRTUAL-RUNTIME_base-utils} udev base-passwd 
${ROOTFS_BOOTSTRAP_INSTALL}"
+PACKAGE_INSTALL = "initramfs-live-boot initramfs-live-install 
initramfs-live-install-efi ${VIRTUAL-RUNTIME_base-utils} udev base-passwd 
${ROOTFS_BOOTSTRAP_INSTALL} initramfs-nfs-boot"
 
 # Do not pollute the initrd image with rootfs features
 IMAGE_FEATURES = ""
diff --git a/meta/recipes-core/initrdscripts/files/init-nfs.sh 
b/meta/recipes-core/initrdscripts/files/init-nfs.sh
new file mode 100644
index 000..31a55ec
--- /dev/null
+++ b/meta/recipes-core/initrdscripts/files/init-nfs.sh
@@ -0,0 +1,108 @@
+#!/bin/sh
+
+CONSOLE="/dev/console"
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+ROOT_MOUNT="/rootfs"
+
+fatal()
+{
+   echo $1 >$CONSOLE
+   echo >$CONSOLE
+   exec sh
+}
+
+net_up()
+{
+   [ "$(ifconfig $PARAM_IFNAME | awk '/inet addr/{print substr($2,6)}')" = 
"$PARAM_IP" ] && return
+   #load all ethernet drivers if network interface is not configured
+   MODULES="$(find /lib/modules/*/kernel/drivers/net/ethernet -name \*.ko 
| sed -e 's,^.*/,,' -e 's,\.ko$,,')"
+   [ -z "$MODULES" ] && fatal "Ethernet drivers list is emty. Nothing to 
load."
+   modprobe -a $MODULES
+
+   ifconfig $PARAM_IFNAME $PARAM_IP netmask $PARAM_NETMASK ||
+   fatal "Failed to configure ethernet interface"
+   route add default gw $PARAM_GW ||
+   fatal "Failed to set default gateway"
+}
+
+
+#TODO: IPv6 is not supported yet
+mount_nfs()
+{
+   mkdir $ROOT_MOUNT
+   for i in $(seq 1 10)
+   do
+   mount -t nfs "$PARAM_NFSROOT_PATH" -o 
nolock,"$PARAM_NFSROOT_OPTS" $ROOT_MOUNT && return
+   sleep 1
+   done
+   fatal "Could not mount rootfs via nfs"
+}
+
+
+early_setup()
+{
+   mkdir -p /proc
+   mkdir -p /sys
+   mount -t proc proc /proc
+   mount -t sysfs sysfs /sys
+   mount -t devtmpfs none /dev
+
+   mkdir -p /run
+   mkdir -p /var/run
+}
+
+
+#TODO: IPv6 is not supported yet
+read_args()
+{
+   [ -z "$CMDLINE" ] && CMDLINE=$(cat /proc/cmdline)
+   for arg in $CMDLINE; do
+   optarg=$(expr "x$arg" : 'x[^=]*=\(.*\)'$)
+   case $arg in
+   ip=*)
+   PARAM_IFNAME=$(echo "$optarg" | cut -d: -f6)
+   PARAM_IP_ALL=$(echo "$optarg" | grep -Eo 
'([0-9]{1,3}\.){3}[0-9]{1,3}')
+   PARAM_IP=$(echo "$PARAM_IP_ALL" | sed -n 1p)
+   PARAM_GW=$(echo "$PARAM_IP_ALL" | sed -n 2p)
+   PARAM_NETMASK=$(echo "$PARAM_IP_ALL" | sed -n 3p)
+   ;;
+   nfsroot=*)
+   PARAM_NFSROOT_PATH=$(echo "$optarg" | cut -d, -f1)
+   PARAM_NFSROOT_OPTS=$(echo "$optarg" | cut -d, -f2-)
+   ;;
+   debugshell)
+   DEBUGSHELL=1
+   ;;
+   esac
+   done
+}
+
+boot_nfs()
+{
+   touch $ROOT_MOUNT/bin || fatal "Rootfs is not writeable"
+
+   mount -n --move /proc ${ROOT_MOUNT}/proc
+   mount -n 

[OE-core] uninative and recipe parsing

[Cuero Bugot]

Hi all,

When you add several layers, recipe parsing can take a (very) long time. In our 
case it takes more than a couple minutes [1]. Fortunately it is supposed to 
happens once, except when you use uninative (poky's default) where it happens 
twice (the two first times you build).
I think this is not an intentional behavior so I dug it a little bit and here 
is what I found:

When inheriting meta/classes/uninative.bbclass, it registers 2 functions on 
build events: one to fetch the uninative tarball (at bb.event.BuildStarted) and 
the other one to set variables in the datastore (at bb.event.ConfigParsed).
The function that set the variables [2] to the datastore first check that the 
uninative blob is in the build tree, so even though it is supposed to happen at 
recipe parsing, the variable are only really set when the build really start 
(bb.event.BuildStarted), after the recipes have been parsed!

So I think there is bug in the current behavior as:
* Either the uninative variables are not important for the recipe 
parsing, and then they should be added in BB_HASHCONFIG_WHITELIST
* Or the variables should matter for the recipe parsing so they should 
be set before the parsing and not in between parsing and build.

I assumed the later, so a simple fix is to register the two functions on the 
same event: bb.event.ConfigParsed.

Note: We are currently using pyro, but I checked that the master branch should 
exhibit the same behavior (same code).

[1]: it matters to us as we are doing Continuous Integration and do clean 
builds (with sstate cache) on every pull requests and master branch commits. 
The automatic test full cycle take about 20 minutes. We launch 2 bitbake 
commands during that process. Parsing recipe take about 2-4 minutes, which is 
significant enough when trying to reduce the waiting and parallel builds/tests.
[2]: the uninative changed variables are: NATIVELSBSTRING, SSTATEPOSTUNPACKFUNCS

Proposed patch:

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index a410647..5713bb8 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -9,7 +9,7 @@ UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.bz2"
 UNINATIVE_DLDIR ?= "${DL_DIR}/uninative/"
 
 addhandler uninative_event_fetchloader
-uninative_event_fetchloader[eventmask] = "bb.event.BuildStarted"
+uninative_event_fetchloader[eventmask] = "bb.event.ConfigParsed"
 
 addhandler uninative_event_enable
 uninative_event_enable[eventmask] = "bb.event.ConfigParsed"

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

Re: [OE-core] [rocko][PATCH 1/1] go: Upgrade 1.9 to 1.9.4 stable release

[Burton, Ross]

Note that stable branch policy is to cherry-pick security fixes unless
they're too complicated/risky to pick (openssl is the notable example here).

Ross

On 12 March 2018 at 11:29, Matt Madison  wrote:

> From: Otavio Salvador 
>
> The 1.9.4 fixes a number of issues in the Go compiler and is important
> to get in before we start working on 1.10 inclusion.
>
>  - go1.9.1 (released 2017/10/04) includes two security fixes.
>
>  - go1.9.2 (released 2017/10/25) includes fixes to the compiler,
>linker, runtime, documentation, go command, and the crypto/x509,
>database/sql, log, and net/smtp packages. It includes a fix to a
>bug introduced in Go 1.9.1 that broke go get of non-Git
>repositories under certain conditions.
>
>  - go1.9.3 (released 2018/01/22) includes fixes to the compiler,
>runtime, and the database/sql, math/big, net/http, and net/url
>packages.
>
>  - go1.9.4 (released 2018/02/07) includes a security fix to “go get”.
>
> Signed-off-by: Otavio Salvador 
> Signed-off-by: Ross Burton 
> Signed-off-by: Matt Madison 
> ---
>  meta/recipes-devtools/go/go-1.9.inc | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/go/go-1.9.inc
> b/meta/recipes-devtools/go/go-1.9.inc
> index 7f12241dc1..2823304b7c 100644
> --- a/meta/recipes-devtools/go/go-1.9.inc
> +++ b/meta/recipes-devtools/go/go-1.9.inc
> @@ -1,6 +1,9 @@
>  require go-common.inc
>
>  GO_BASEVERSION = "1.9"
> +GO_MINOR = ".4"
> +PV .= "${GO_MINOR}"
> +
>  FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
>
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"
> @@ -19,5 +22,5 @@ SRC_URI += "\
>  "
>  SRC_URI_append_libc-musl = " file://set-external-linker.patch"
>
> -SRC_URI[main.md5sum] = "da2d44ea384076efec43ee1f8b7d45d2"
> -SRC_URI[main.sha256sum] = "a4ab229028ed167ba1986825751463
> 605264e44868362ca8e7accc8be057e993"
> +SRC_URI[main.md5sum] = "6816441fd6680c63865cdd5cb8bc1960"
> +SRC_URI[main.sha256sum] = "0573a8df33168977185aa44173305e
> 5a0450f55213600e94541604b75d46dc06"
> --
> 2.14.1
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image_types.bbclass: Rename lz4_legacy to lz4

[Maxin B. John]

LZ4 format currently used by the Linux kernel is the 'legacy' format.

In order to avoid creating an image that can't be used as a compressed
initial ramdisk with Linux kernel, rename lz4_legacy to lz4.

[YOCTO #12461]
[YOCTO #12149]

Signed-off-by: Maxin B. John 
---
 meta/classes/image_types.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index cde27e5..e872ae2 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -284,8 +284,7 @@ CONVERSION_CMD_lzma = "lzma -k -f -7 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 CONVERSION_CMD_gz = "gzip -f -9 -n -c 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
 CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS} 
--check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.xz"
-CONVERSION_CMD_lz4 = "lz4 -9 -z ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
-CONVERSION_CMD_lz4_legacy = "lz4 -9 -z -l 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
+CONVERSION_CMD_lz4 = "lz4 -9 -z -l ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
 CONVERSION_CMD_lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 CONVERSION_CMD_zip = "zip ${ZIP_COMPRESSION_LEVEL} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.zip 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 CONVERSION_CMD_sum = "sumtool -i ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sum ${JFFS2_SUM_EXTRA_ARGS}"
-- 
2.4.0

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

[OE-core] [rocko][PATCH 1/1] go: Upgrade 1.9 to 1.9.4 stable release

[Matt Madison]

From: Otavio Salvador 

The 1.9.4 fixes a number of issues in the Go compiler and is important
to get in before we start working on 1.10 inclusion.

 - go1.9.1 (released 2017/10/04) includes two security fixes.

 - go1.9.2 (released 2017/10/25) includes fixes to the compiler,
   linker, runtime, documentation, go command, and the crypto/x509,
   database/sql, log, and net/smtp packages. It includes a fix to a
   bug introduced in Go 1.9.1 that broke go get of non-Git
   repositories under certain conditions.

 - go1.9.3 (released 2018/01/22) includes fixes to the compiler,
   runtime, and the database/sql, math/big, net/http, and net/url
   packages.

 - go1.9.4 (released 2018/02/07) includes a security fix to “go get”.

Signed-off-by: Otavio Salvador 
Signed-off-by: Ross Burton 
Signed-off-by: Matt Madison 
---
 meta/recipes-devtools/go/go-1.9.inc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/go/go-1.9.inc 
b/meta/recipes-devtools/go/go-1.9.inc
index 7f12241dc1..2823304b7c 100644
--- a/meta/recipes-devtools/go/go-1.9.inc
+++ b/meta/recipes-devtools/go/go-1.9.inc
@@ -1,6 +1,9 @@
 require go-common.inc
 
 GO_BASEVERSION = "1.9"
+GO_MINOR = ".4"
+PV .= "${GO_MINOR}"
+
 FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
 
 LIC_FILES_CHKSUM = "file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"
@@ -19,5 +22,5 @@ SRC_URI += "\
 "
 SRC_URI_append_libc-musl = " file://set-external-linker.patch"
 
-SRC_URI[main.md5sum] = "da2d44ea384076efec43ee1f8b7d45d2"
-SRC_URI[main.sha256sum] = 
"a4ab229028ed167ba1986825751463605264e44868362ca8e7accc8be057e993"
+SRC_URI[main.md5sum] = "6816441fd6680c63865cdd5cb8bc1960"
+SRC_URI[main.sha256sum] = 
"0573a8df33168977185aa44173305e5a0450f55213600e94541604b75d46dc06"
-- 
2.14.1

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

[OE-core] [rocko][PATCH 0/1] backport go 1.9.4 update to rocko

[Matt Madison]

One of the changes included in this point release update
fixes an issue with the construction of Go's shared runtim
library, so it would be great to backport this to rocko
to fix [YOCTO 12592].

Thanks,
-Matt

Otavio Salvador (1):
  go: Upgrade 1.9 to 1.9.4 stable release

 meta/recipes-devtools/go/go-1.9.inc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

-- 
2.14.1

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

Re: [OE-core] [oe-core][PATCH 1/7] eudev: fix file conflict when multilib enabled

[Alexander Kanavin]

On 03/12/2018 11:12 AM, Zhang Xiao wrote:

Config file udev.pc conflicts between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.
-inherit autotools update-rc.d qemu pkgconfig distro_features_check
+inherit autotools update-rc.d qemu pkgconfig distro_features_check 
update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+ALTERNATIVE_${PN}-dev = "udev.pc"
+ALTERNATIVE_LINK_NAME[udev.pc] = "${datadir}/pkgconfig/udev.pc"
+ALTERNATIVE_TARGET[udev.pc] = "${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "eudev_alternative_rename"
+
+eudev_alternative_rename() {
+   # rename udev.pc
+   mv ${PKGD}${datadir}/pkgconfig/udev.pc 
${PKGD}${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}
+}


I'm afraid, I have to say no to the entire patchset. It's abusing 
update-alternatives to do what it was never meant for, and effectively 
renders one of the -dev packages broken, just so that package manager 
can satisfy dependencies.


Let's first take a look at why dnf wants to install two different -dev 
packages in the first place, and why these seven recipes need to be 
fixed in particular. My understanding is multilib feature should be used 
only for libraries, and not for supporting development files.


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

[OE-core] ✗ patchtest: failure for pkcs11-helper: 1.11 -> 1.22

[Patchwork]

== Series Details ==

Series: pkcs11-helper: 1.11 -> 1.22
Revision: 1
URL   : https://patchwork.openembedded.org/series/11358/
State : failure

== Summary ==


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



* Issue Series sent to the wrong mailing list or some patches from 
the series correspond to different mailing lists [test_target_mailing_list] 
  Suggested fixSend the series again to the correct mailing list (ML)
  Suggested ML openembedded-de...@lists.openembedded.org 
[http://git.openembedded.org/meta-openembedded/]
  Patch's path:meta-oe/recipes-crypto/pkcs11-helper/pkcs11-helper_1.11.bb

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



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

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

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

[OE-core] [oe][meta-oe][PATCH] pkcs11-helper: 1.11 -> 1.22

[Huang Qiyu]

Upgrade pkcs11-helper from 1.11 to 1.22.

Signed-off-by: Huang Qiyu 
---
 .../pkcs11-helper/{pkcs11-helper_1.11.bb => pkcs11-helper_1.22.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta-oe/recipes-crypto/pkcs11-helper/{pkcs11-helper_1.11.bb => 
pkcs11-helper_1.22.bb} (95%)

diff --git a/meta-oe/recipes-crypto/pkcs11-helper/pkcs11-helper_1.11.bb 
b/meta-oe/recipes-crypto/pkcs11-helper/pkcs11-helper_1.22.bb
similarity index 95%
rename from meta-oe/recipes-crypto/pkcs11-helper/pkcs11-helper_1.11.bb
rename to meta-oe/recipes-crypto/pkcs11-helper/pkcs11-helper_1.22.bb
index db71bd0..51ccf37 100644
--- a/meta-oe/recipes-crypto/pkcs11-helper/pkcs11-helper_1.11.bb
+++ b/meta-oe/recipes-crypto/pkcs11-helper/pkcs11-helper_1.22.bb
@@ -20,7 +20,7 @@ SRC_URI[md5sum] = "9f62af9f475901b89355266141306673"
 SRC_URI[sha256sum] = 
"494ec59c93e7c56c528f335d9353849e2e7c94a6b1b41c89604694e738113386"
 
 S = "${WORKDIR}/git"
-SRCREV = "e7adf8f35be232a4f04c53b4ac409be52792093e"
+SRCREV = "a6e54e9bdd57dd4e98a2fbf984fe7fe4a9d60171"
 
 DEPENDS = "zlib nettle gnutls gmp openssl nss nspr"
 
-- 
2.7.4



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

[OE-core] [PATCH 0/1] btrfs-tools: set CLEANBROKEN to 1 to avoid rebuild failure

[Chen Qi]

The following changes since commit 5350ee317740751f2417c1794dd39d3880347dbf:

  yocto-uninative: Upgrade to 1.8 version with glibc 2.27 (2018-03-11 06:27:02 
-0700)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/btrfs-tools-rebuild
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/btrfs-tools-rebuild

Chen Qi (1):
  btrfs-tools: set CLEANBROKEN to 1 to avoid rebuild failure

 meta/recipes-devtools/btrfs-tools/btrfs-tools_4.13.3.bb | 2 ++
 1 file changed, 2 insertions(+)

-- 
1.9.1

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

[OE-core] [PATCH 1/1] btrfs-tools: set CLEANBROKEN to 1 to avoid rebuild failure

[Chen Qi]

When rebuilding btrfs-tools, we would sometimes meet the following error.

  Makefile:43: *** Makefile.inc not generated, please configure first.

Set CLEANBROKEN to "1" to solve this problem.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/btrfs-tools/btrfs-tools_4.13.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.13.3.bb 
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.13.3.bb
index 263fc65..31bbdb8 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.13.3.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.13.3.bb
@@ -22,6 +22,8 @@ SRC_URI = 
"git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git \
 
 inherit autotools-brokensep pkgconfig manpages
 
+CLEANBROKEN = "1"
+
 PACKAGECONFIG[manpages] = "--enable-documentation, --disable-documentation, 
asciidoc-native xmlto-native"
 EXTRA_OECONF_append_libc-musl = " --disable-backtrace "
 
-- 
1.9.1

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

Re: [OE-core] [PATCH 1/3] systemd: upgrade to 237

[ChenQi]

On 03/12/2018 04:52 PM, Maxin B. John wrote:

Hi,

On Mon, Mar 12, 2018 at 04:38:51PM +0800, Chen Qi wrote:

Upgrade systemd to 237.

Note that this version has dropped autotools support.

Very minor nit-picking :

Even with this patch, "systemd_237.bb" and "systemd.inc" contains duplicated

SRC_URI = "git://github.com/systemd/systemd.git;protocol=git"

Probably a good idea to keep it only in "systemd.inc" file.



Hi Maxin,

Thanks for pointing it out.
I've fixed this problem and updated the remote branch.

Best Regards,
Chen Qi


The following patches are rebased:
0004-Use-getenv-when-secure-versions-are-not-available.patch
0005-binfmt-Don-t-install-dependency-links-at-install-tim.patch
0007-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch
0015-Revert-udev-remove-userspace-firmware-loading-suppor.patch
0018-check-for-uchar.h-in-configure.patch
0019-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch
0001-add-fallback-parse_printf_format-implementation.patch
0002-src-basic-missing.h-check-for-missing-strndupa.patch
0007-check-for-missing-canonicalize_file_name.patch
0008-Do-not-enable-nss-tests.patch
0010-test-sizeof.c-Disable-tests-for-missing-typedefs-in-.patch
0011-nss-mymachines-Build-conditionally-when-HAVE_MYHOSTN.patch

The following backported patches are dropped:
0001-core-evaluate-presets-after-generators-have-run-6526.patch
0001-main-skip-many-initialization-steps-when-running-in-.patch
0001-meson-update-header-file-to-detect-memfd_create.patch
0003-fileio-include-sys-mman.h.patch

The following patch is dropped as autotools support is dropped:
0002-configure.ac-Check-if-memfd_create-is-already-define.patch

The following patches are newly added to fix problems:
0027-remove-nobody-user-group-checking.patch
0028-add-missing-FTW_-macros-for-musl.patch
0030-fix-missing-of-__register_atfork-for-non-glibc-build.patch
0031-fix-missing-ULONG_LONG_MAX-definition-in-case-of-mus.patch

Best Regards,
Maxin



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

[OE-core] [oe-core][PATCH 6/7] xtrans: fix file conflict when multilib enabled

[Zhang Xiao]

Script file xtrans.pc conflicts between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.

Signed-off-by: Zhang Xiao 
---
 meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb 
b/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
index d5b7f1a2c6..ef64f1fcfc 100644
--- a/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
+++ b/meta/recipes-graphics/xorg-lib/xtrans_1.3.5.bb
@@ -16,7 +16,20 @@ PE = "1"
 
 RDEPENDS_${PN}-dev = ""
 
-inherit gettext
+inherit gettext  update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+FILES_${PN}-dev += "${datadir}/pkgconfig/xtrans.pc-${MULTILIB_SUFFIX}"
+ALTERNATIVE_${PN}-dev = "xtrans.pc"
+ALTERNATIVE_LINK_NAME[xtrans.pc] = "${datadir}/pkgconfig/xtrans.pc"
+ALTERNATIVE_TARGET[xtrans.pc] = 
"${datadir}/pkgconfig/xtrans.pc-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "xtrans_alternative_rename"
+
+xtrans_alternative_rename() {
+mv ${PKGD}${datadir}/pkgconfig/xtrans.pc 
${PKGD}${datadir}/pkgconfig/xtrans.pc-${MULTILIB_SUFFIX}
+}
 
 BBCLASSEXTEND = "native nativesdk"
 
-- 
2.11.0

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

[OE-core] [oe-core][PATCH 7/7] icu: fix file conflict when multilib enabled

[Zhang Xiao]

Script icu-config conflicts between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.

Signed-off-by: Zhang Xiao 
---
 meta/recipes-support/icu/icu.inc | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/icu/icu.inc b/meta/recipes-support/icu/icu.inc
index 983118cd61..5dc4e1dbb9 100644
--- a/meta/recipes-support/icu/icu.inc
+++ b/meta/recipes-support/icu/icu.inc
@@ -19,7 +19,19 @@ BINCONFIG = "${bindir}/icu-config"
 
 ICU_MAJOR_VER = "${@d.getVar('PV').split('.')[0]}"
 
-inherit autotools pkgconfig binconfig
+inherit autotools pkgconfig binconfig update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+ALTERNATIVE_${PN}-dev = "icu-config"
+ALTERNATIVE_LINK_NAME[icu-config] = "${bindir}/icu-config"
+ALTERNATIVE_TARGET[icu-config] = "${bindir}/icu-config-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "alternatives_rename"
+
+alternatives_rename() {
+mv ${PKGD}/${bindir}/icu-config 
${PKGD}/${bindir}/icu-config-${MULTILIB_SUFFIX}
+}
 
 # ICU needs the native build directory as an argument to its 
--with-cross-build option when
 # cross-compiling. Taken the situation that different builds may share a 
common sstate-cache
@@ -76,7 +88,7 @@ do_install_append_class-target() {
 
 PACKAGES =+ "libicudata libicuuc libicui18n libicutu libicuio"
 
-FILES_${PN}-dev += "${libdir}/${BPN}/"
+FILES_${PN}-dev += "${libdir}/${BPN}/ ${bindir}/icu-config-${MULTILIB_SUFFIX}"
 
 FILES_libicudata = "${libdir}/libicudata.so.*"
 FILES_libicuuc = "${libdir}/libicuuc.so.*"
-- 
2.11.0

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

[OE-core] [oe-core][PATCH 2/7] python3: fix file conflict when multilib enabled

[Zhang Xiao]

Config file python3.5m-config conflicts between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.

Signed-off-by: Zhang Xiao 
---
 meta/recipes-devtools/python/python3_3.5.4.bb | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3_3.5.4.bb 
b/meta/recipes-devtools/python/python3_3.5.4.bb
index a94d0096f1..7544e3318c 100644
--- a/meta/recipes-devtools/python/python3_3.5.4.bb
+++ b/meta/recipes-devtools/python/python3_3.5.4.bb
@@ -48,7 +48,13 @@ UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P\d+(\.\d+)+).tar"
 
 S = "${WORKDIR}/Python-${PV}"
 
-inherit autotools multilib_header python3native pkgconfig
+inherit autotools multilib_header python3native pkgconfig update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+ALTERNATIVE_${PN}-core = "python3.5m-config"
+ALTERNATIVE_LINK_NAME[python3.5m-config] = "${bindir}/python3.5m-config"
+ALTERNATIVE_TARGET[python3.5m-config] = 
"${bindir}/python3.5m-config-${MULTILIB_SUFFIX}"
 
 CONFIGUREOPTS += " --with-system-ffi "
 
@@ -204,6 +210,8 @@ py_package_preprocess () {
${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} \
 -c "from py_compile import compile; 
compile('./${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata.py', optimize=2)"
cd -
+
+   mv ${PKGD}/${bindir}/python3.5m-config 
${PKGD}/${bindir}/python3.5m-config-${MULTILIB_SUFFIX}
 }
 
 # manual dependency additions
-- 
2.11.0

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

[OE-core] [oe-core][PATCH 5/7] cairo: fix file conflict when multilib enabled

[Zhang Xiao]

Script file cairo-trace conflict between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.

Signed-off-by: Zhang Xiao 
---
 meta/recipes-graphics/cairo/cairo_1.14.12.bb | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cairo/cairo_1.14.12.bb 
b/meta/recipes-graphics/cairo/cairo_1.14.12.bb
index 075ca1ed34..1f2d68c0de 100644
--- a/meta/recipes-graphics/cairo/cairo_1.14.12.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.14.12.bb
@@ -10,6 +10,20 @@ SRC_URI = 
"http://cairographics.org/releases/cairo-${PV}.tar.xz \
 SRC_URI[md5sum] = "9f0db9dbfca0966be8acd682e636d165"
 SRC_URI[sha256sum] = 
"8c90f00c500b2299c0a323dd9beead2a00353752b2092ead558139bd67f7bf16"
 
+inherit update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+ALTERNATIVE_${PN}-perf-utils="cairo-trace"
+ALTERNATIVE_LINK_NAME[cairo-trace] = "${bindir}/cairo-trace"
+ALTERNATIVE_TARGET[cairo-trace] = "${bindir}/cairo-trace-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "alternatives_rename"
+
+alternatives_rename() {
+   mv ${PKGD}${bindir}/cairo-trace 
${PKGD}${bindir}/cairo-trace-${MULTILIB_SUFFIX}
+}
+
 PACKAGES =+ "cairo-gobject cairo-script-interpreter cairo-perf-utils"
 
 SUMMARY_${PN} = "The Cairo 2D vector graphics library"
@@ -35,7 +49,7 @@ FILES_${PN} = "${libdir}/libcairo.so.*"
 FILES_${PN}-dev += "${libdir}/cairo/*.so"
 FILES_${PN}-gobject = "${libdir}/libcairo-gobject.so.*"
 FILES_${PN}-script-interpreter = "${libdir}/libcairo-script-interpreter.so.*"
-FILES_${PN}-perf-utils = "${bindir}/cairo-trace ${libdir}/cairo/*.la 
${libdir}/cairo/libcairo-trace.so.*"
+FILES_${PN}-perf-utils = "${bindir}/cairo-trace* ${libdir}/cairo/*.la 
${libdir}/cairo/libcairo-trace.so.*"
 
 do_install_append () {
rm -rf ${D}${bindir}/cairo-sphinx
-- 
2.11.0

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

[OE-core] [oe-core][PATCH 3/7] vala: fix file conflict when multilib enabled

[Zhang Xiao]

Config file vala-gen-introspect-${SHRT_VER} conflicts between 32 and
64 bit packages. Use update-alternatives to add base_libdir as suffix
to avoid it.

Signed-off-by: Zhang Xiao 
---
 meta/recipes-devtools/vala/vala.inc | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/vala/vala.inc 
b/meta/recipes-devtools/vala/vala.inc
index b22faad780..5c958cdbf0 100644
--- a/meta/recipes-devtools/vala/vala.inc
+++ b/meta/recipes-devtools/vala/vala.inc
@@ -19,7 +19,20 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=fbc093901857fcd118f065f900982c24"
 SHRT_VER = "${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}"
 
 SRC_URI = 
"http://ftp.gnome.org/pub/GNOME/sources/${BPN}/${SHRT_VER}/${BP}.tar.xz;
-inherit autotools pkgconfig upstream-version-is-even
+inherit autotools pkgconfig upstream-version-is-even update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+ALTERNATIVE_${PN} = "vala-gen-introspect"
+ALTERNATIVE_LINK_NAME[vala-gen-introspect] = 
"${bindir}/vala-gen-introspect-${SHRT_VER}"
+ALTERNATIVE_TARGET[vala-gen-introspect] = 
"${bindir}/vala-gen-introspect-${SHRT_VER}-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "alternative_rename"
+
+alternative_rename() {
+mv ${PKGD}${bindir}/vala-gen-introspect-${SHRT_VER} \
+   ${PKGD}${bindir}/vala-gen-introspect-${SHRT_VER}-${MULTILIB_SUFFIX}
+}
+
 
 FILES_${PN} += "${datadir}/${BPN}-${SHRT_VER}/vapi 
${libdir}/${BPN}-${SHRT_VER}/"
 FILES_${PN}-doc += "${datadir}/devhelp"
-- 
2.11.0

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

[OE-core] [oe-core][PATCH 4/7] gobject-introspection: fix file conflict when multilib enabled

[Zhang Xiao]

Script files conflict between 32 and 64 bit packages:
${bindir}/g-ir-annotation-tool
${bindir}/g-ir-compiler-wrapper
${bindir}/g-ir-scanner
${bindir}/g-ir-scanner-lddwrapper
${bindir}/g-ir-scanner-qemuwrapper
${bindir}/g-ir-scanner-wrapper
${datadir}/gir-1.0/GLib-2.0.gir

Use update-alternatives to add base_libdir as suffix to avoid it.

Signed-off-by: Zhang Xiao 
---
 .../gobject-introspection_1.54.1.bb| 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git 
a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb 
b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb
index 85c8001dea..d9d5825a78 100644
--- a/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb
+++ b/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.54.1.bb
@@ -19,9 +19,41 @@ SRC_URI = "${GNOME_MIRROR}/${BPN}/1.54/${BPN}-${PV}.tar.xz \
 SRC_URI[md5sum] = "126c29e4d54adbed2ed4e2b04483de41"
 SRC_URI[sha256sum] = 
"b88ded5e5f064ab58a93aadecd6d58db2ec9d970648534c63807d4f9a7bb877e"
 
-inherit autotools pkgconfig gtk-doc python3native qemu 
gobject-introspection-data upstream-version-is-even
+inherit autotools pkgconfig gtk-doc python3native qemu 
gobject-introspection-data upstream-version-is-even update-alternatives
 BBCLASSEXTEND = "native"
 
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+ALTERNATIVE_${PN} = "annotation-tool compiler-wrapper scanner 
scanner-lddwrapper scanner-qemuwrapper scanner-wrapper"
+ALTERNATIVE_${PN}-dev = "GLib-2.0.gir"
+ALTERNATIVE_LINK_NAME[annotation-tool] = "${bindir}/g-ir-annotation-tool"
+ALTERNATIVE_TARGET[annotation-tool] = 
"${bindir}/g-ir-annotation-tool-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[compiler-wrapper] = "${bindir}/g-ir-compiler-wrapper"
+ALTERNATIVE_TARGET[compiler-wrapper] = 
"${bindir}/g-ir-compiler-wrapper-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[scanner] = "${bindir}/g-ir-scanner"
+ALTERNATIVE_TARGET[scanner] = "${bindir}/g-ir-scanner-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[scanner-lddwrapper] = "${bindir}/g-ir-scanner-lddwrapper"
+ALTERNATIVE_TARGET[scanner-lddwrapper] = 
"${bindir}/g-ir-scanner-lddwrapper-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[scanner-qemuwrapper] = 
"${bindir}/g-ir-scanner-qemuwrapper"
+ALTERNATIVE_TARGET[scanner-qemuwrapper] = 
"${bindir}/g-ir-scanner-qemuwrapper-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[scanner-wrapper] = "${bindir}/g-ir-scanner-wrapper"
+ALTERNATIVE_TARGET[scanner-wrapper] = 
"${bindir}/g-ir-scanner-wrapper-${MULTILIB_SUFFIX}"
+ALTERNATIVE_LINK_NAME[GLib-2.0.gir] = "${datadir}/gir-1.0/GLib-2.0.gir"
+ALTERNATIVE_TARGET[GLib-2.0.gir] = 
"${datadir}/gir-1.0/GLib-2.0.gir-${MULTILIB_SUFFIX}"
+
+FILES_${PN}-dev += "${datadir}/gir-1.0/GLib-2.0.gir-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "gobject_alternative_rename"
+
+gobject_alternative_rename() {
+mv ${PKGD}${bindir}/g-ir-annotation-tool 
${PKGD}${bindir}/g-ir-annotation-tool-${MULTILIB_SUFFIX}
+mv ${PKGD}${bindir}/g-ir-compiler-wrapper 
${PKGD}${bindir}/g-ir-compiler-wrapper-${MULTILIB_SUFFIX}
+mv ${PKGD}${bindir}/g-ir-scanner 
${PKGD}${bindir}/g-ir-scanner-${MULTILIB_SUFFIX}
+mv ${PKGD}${bindir}/g-ir-scanner-lddwrapper 
${PKGD}${bindir}/g-ir-scanner-lddwrapper-${MULTILIB_SUFFIX}
+mv ${PKGD}${bindir}/g-ir-scanner-qemuwrapper 
${PKGD}${bindir}/g-ir-scanner-qemuwrapper-${MULTILIB_SUFFIX}
+mv ${PKGD}${bindir}/g-ir-scanner-wrapper 
${PKGD}${bindir}/g-ir-scanner-wrapper-${MULTILIB_SUFFIX}
+mv ${PKGD}${datadir}/gir-1.0/GLib-2.0.gir 
${PKGD}${datadir}/gir-1.0/GLib-2.0.gir-${MULTILIB_SUFFIX}
+}
+
 # needed for writing out the qemu wrapper script
 export STAGING_DIR_HOST
 export B
-- 
2.11.0

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

[OE-core] [oe-core][PATCH 1/7] eudev: fix file conflict when multilib enabled

[Zhang Xiao]

Config file udev.pc conflicts between 32 and 64 bit packages.
Use update-alternatives to add base_libdir as suffix to avoid it.

Signed-off-by: Zhang Xiao 
---
 meta/recipes-core/udev/eudev_3.2.5.bb | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/udev/eudev_3.2.5.bb 
b/meta/recipes-core/udev/eudev_3.2.5.bb
index 88ad8f1b37..d567c11272 100644
--- a/meta/recipes-core/udev/eudev_3.2.5.bb
+++ b/meta/recipes-core/udev/eudev_3.2.5.bb
@@ -23,7 +23,20 @@ SRC_URI = 
"http://dev.gentoo.org/~blueness/${BPN}/${BP}.tar.gz \
 SRC_URI[md5sum] = "6ca08c0e14380f87df8e8aceac123671"
 SRC_URI[sha256sum] = 
"49c2d04105cad2526302627e040fa24b1916a9a3e059539bc8bb919b973890af"
 
-inherit autotools update-rc.d qemu pkgconfig distro_features_check
+inherit autotools update-rc.d qemu pkgconfig distro_features_check 
update-alternatives
+
+MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
+
+ALTERNATIVE_${PN}-dev = "udev.pc"
+ALTERNATIVE_LINK_NAME[udev.pc] = "${datadir}/pkgconfig/udev.pc"
+ALTERNATIVE_TARGET[udev.pc] = "${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}"
+
+PACKAGE_PREPROCESS_FUNCS += "eudev_alternative_rename"
+
+eudev_alternative_rename() {
+   # rename udev.pc
+   mv ${PKGD}${datadir}/pkgconfig/udev.pc 
${PKGD}${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX}
+}
 
 CONFLICT_DISTRO_FEATURES = "systemd"
 
@@ -65,7 +78,7 @@ PACKAGES =+ "eudev-hwdb"
 
 
 FILES_${PN} += "${libexecdir} ${base_libdir}/udev ${bindir}/udevadm"
-FILES_${PN}-dev = "${datadir}/pkgconfig/udev.pc \
+FILES_${PN}-dev = "${datadir}/pkgconfig/udev.pc-${MULTILIB_SUFFIX} \
${includedir}/libudev.h ${libdir}/libudev.so \
${includedir}/udev.h ${libdir}/libudev.la \
${libdir}/libudev.a ${libdir}/pkgconfig/libudev.pc"
-- 
2.11.0

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

Re: [OE-core] [PATCH 1/3] systemd: upgrade to 237

[Maxin B. John]

Hi,

On Mon, Mar 12, 2018 at 04:38:51PM +0800, Chen Qi wrote:
> Upgrade systemd to 237.
> 
> Note that this version has dropped autotools support.

Very minor nit-picking : 

Even with this patch, "systemd_237.bb" and "systemd.inc" contains duplicated

SRC_URI = "git://github.com/systemd/systemd.git;protocol=git"

Probably a good idea to keep it only in "systemd.inc" file.

> 
> The following patches are rebased:
> 0004-Use-getenv-when-secure-versions-are-not-available.patch
> 0005-binfmt-Don-t-install-dependency-links-at-install-tim.patch
> 0007-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch
> 0015-Revert-udev-remove-userspace-firmware-loading-suppor.patch
> 0018-check-for-uchar.h-in-configure.patch
> 0019-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch
> 0001-add-fallback-parse_printf_format-implementation.patch
> 0002-src-basic-missing.h-check-for-missing-strndupa.patch
> 0007-check-for-missing-canonicalize_file_name.patch
> 0008-Do-not-enable-nss-tests.patch
> 0010-test-sizeof.c-Disable-tests-for-missing-typedefs-in-.patch
> 0011-nss-mymachines-Build-conditionally-when-HAVE_MYHOSTN.patch
> 
> The following backported patches are dropped:
> 0001-core-evaluate-presets-after-generators-have-run-6526.patch
> 0001-main-skip-many-initialization-steps-when-running-in-.patch
> 0001-meson-update-header-file-to-detect-memfd_create.patch
> 0003-fileio-include-sys-mman.h.patch
> 
> The following patch is dropped as autotools support is dropped:
> 0002-configure.ac-Check-if-memfd_create-is-already-define.patch
> 
> The following patches are newly added to fix problems:
> 0027-remove-nobody-user-group-checking.patch
> 0028-add-missing-FTW_-macros-for-musl.patch
> 0030-fix-missing-of-__register_atfork-for-non-glibc-build.patch
> 0031-fix-missing-ULONG_LONG_MAX-definition-in-case-of-mus.patch

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

Re: [OE-core] [PATCH 0/3] systemd & systemd-boot: upgrade to 237

[ChenQi]

Hi Ross,

This patchset has been rebased against latest master to resolve conflicts.

Best Regards,
Chen Qi

On 03/12/2018 04:38 PM, Chen Qi wrote:

Changes in V2:
* Rebase against latest master to resolve conflicts


The following changes since commit 5350ee317740751f2417c1794dd39d3880347dbf:

   yocto-uninative: Upgrade to 1.8 version with glibc 2.27 (2018-03-11 06:27:02 
-0700)

are available in the git repository at:

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

Chen Qi (3):
   systemd: upgrade to 237
   systemd: fix build failure for qemux86 and qemuppc with musl
   systemd-boot: upgrade to 237

  .../{systemd-boot_234.bb => systemd-boot_237.bb}   |  31 ++-
  meta/recipes-core/systemd/systemd.inc  |   2 +-
  ...01-Also-check-i386-i586-and-i686-for-ia32.patch |  28 +++
  ...efi_cc-and-efi_ld-correctly-when-cross-co.patch |  62 +
  ...ck-protector-flags-to-workaround-musl-bui.patch |  33 +++
  ...v-when-secure-versions-are-not-available.patch} |  21 +-
  ...te-presets-after-generators-have-run-6526.patch |  69 --
  ...any-initialization-steps-when-running-in-.patch | 163 -
  ...update-header-file-to-detect-memfd_create.patch |  28 ---
  ...t-install-dependency-links-at-install-tim.patch |  81 +++
  ...c-Check-if-memfd_create-is-already-define.patch |  27 ---
  .../systemd/0003-fileio-include-sys-mman.h.patch   |  26 --
  ...pper-instead-of-looking-for-relative-opti.patch |  64 +
  ...004-implment-systemd-sysv-install-for-OE.patch} |   8 +-
  ...t-install-dependency-links-at-install-tim.patch |  74 --
  ...patch => 0005-rules-whitelist-hd-devices.patch} |   9 +-
  ...6-Make-root-s-home-directory-configurable.patch |  78 ++
  ...vert-rules-remove-firmware-loading-rules.patch} |   8 +-
  ...-check-for-missing-canonicalize_file_name.patch |  63 -
  ...pper-instead-of-looking-for-relative-opti.patch |  40 ---
  .../systemd/0008-Do-not-enable-nss-tests.patch |  35 ---
  ...remove-userspace-firmware-loading-suppor.patch} | 204 +---
  ...=> 0009-remove-duplicate-include-uchar.h.patch} |  14 +-
  .../0010-check-for-uchar.h-in-meson.build.patch|  45 
  ...nes-Build-conditionally-when-HAVE_MYHOSTN.patch |  38 ---
  ...l-don-t-fail-if-libc-doesn-t-support-IDN.patch} |  26 +-
  ...es-watch-metadata-changes-in-ide-devices.patch} |   8 +-
  ...3-Make-root-s-home-directory-configurable.patch | 155 
  ...lback-parse_printf_format-implementation.patch} |  86 ---
  ...sic-missing.h-check-for-missing-strndupa.patch} |  96 
  ...f-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch} |  30 +--
  ...ssing.h-check-for-missing-__compar_fn_t-.patch} |  18 +-
  ...patch => 0017-Include-netinet-if_ether.h.patch} |  55 +++--
  ...-check-for-missing-canonicalize_file_name.patch |  47 
  .../0018-check-for-uchar.h-in-configure.patch  |  44 
  ...le-nss-tests-if-nss-systemd-is-not-enable.patch |  29 +++
  ...xdecoct.c-Include-missing.h-for-strndupa.patch} |  15 +-
  ...c-Disable-tests-for-missing-typedefs-in-.patch} |  39 ++-
  ...=> 0022-don-t-use-glibc-specific-qsort_r.patch} |  26 +-
  ...ss-AT_SYMLINK_NOFOLLOW-flag-to-faccessat.patch} |  22 +-
  ...n_t-is-glibc-specific-use-raw-signature-.patch} |  14 +-
  ...ATH_WTMPX-and-_PATH_UTMPX-if-not-defined.patch} |  16 +-
  ...> 0026-Use-uintmax_t-for-handling-rlim_t.patch} |  22 +-
  .../0027-remove-nobody-user-group-checking.patch   |  63 +
  .../0028-add-missing-FTW_-macros-for-musl.patch|  50 
  ...nes-Build-conditionally-when-ENABLE_MYHOS.patch |  43 
  ...-of-__register_atfork-for-non-glibc-build.patch |  45 
  ...-ULONG_LONG_MAX-definition-in-case-of-mus.patch |  30 +++
  meta/recipes-core/systemd/systemd/run-ptest|   6 -
  .../systemd/{systemd_234.bb => systemd_237.bb} | 270 +
  50 files changed, 1211 insertions(+), 1295 deletions(-)
  rename meta/recipes-core/systemd/{systemd-boot_234.bb => systemd-boot_237.bb} 
(58%)
  create mode 100644 
meta/recipes-core/systemd/systemd/0001-Also-check-i386-i586-and-i686-for-ia32.patch
  create mode 100644 
meta/recipes-core/systemd/systemd/0001-Fix-to-run-efi_cc-and-efi_ld-correctly-when-cross-co.patch
  create mode 100644 
meta/recipes-core/systemd/systemd/0001-Remove-fstack-protector-flags-to-workaround-musl-bui.patch
  rename 
meta/recipes-core/systemd/systemd/{0004-Use-getenv-when-secure-versions-are-not-available.patch
 => 0001-Use-getenv-when-secure-versions-are-not-available.patch} (53%)
  delete mode 100644 
meta/recipes-core/systemd/systemd/0001-core-evaluate-presets-after-generators-have-run-6526.patch
  delete mode 100644 
meta/recipes-core/systemd/systemd/0001-main-skip-many-initialization-steps-when-running-in-.patch
  delete mode 100644 
meta/recipes-core/systemd/systemd/0001-meson-update-header-file-to-detect-memfd_create.patch
  create mode 100644 

[OE-core] [PATCH 2/3] systemd: fix build failure for qemux86 and qemuppc with musl

[Chen Qi]

Remove the 'fstack-protector' and 'fstack-protector-strong' flags
as a workaround to fix the following error when building for qemux86
and qemuppc with musl.

  undefined reference to `__stack_chk_fail_local'

Signed-off-by: Chen Qi 
---
 ...ck-protector-flags-to-workaround-musl-bui.patch | 33 ++
 meta/recipes-core/systemd/systemd_237.bb   |  4 +++
 2 files changed, 37 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-Remove-fstack-protector-flags-to-workaround-musl-bui.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-Remove-fstack-protector-flags-to-workaround-musl-bui.patch
 
b/meta/recipes-core/systemd/systemd/0001-Remove-fstack-protector-flags-to-workaround-musl-bui.patch
new file mode 100644
index 000..e913e3f
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-Remove-fstack-protector-flags-to-workaround-musl-bui.patch
@@ -0,0 +1,33 @@
+From e361f6b4aefae57efff7e457df8db4d1067bec23 Mon Sep 17 00:00:00 2001
+From: Chen Qi 
+Date: Wed, 28 Feb 2018 21:50:23 -0800
+Subject: [PATCH] Remove fstack-protector flags to workaround musl build
+
+Remove fstack-protector and fstack-protector-strong flags to fix
+the following build failure for qemux86 and qemuppc with musl.
+
+  undefined reference to `__stack_chk_fail_local'
+
+Upstream-Status: Inappropriate [OE Specific]
+
+Signed-off-by: Chen Qi 
+---
+ meson.build | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/meson.build b/meson.build
+index 7610ab12b..591b9cbab 100644
+--- a/meson.build
 b/meson.build
+@@ -329,8 +329,6 @@ foreach arg : ['-Wextra',
+'-fdiagnostics-show-option',
+'-fno-strict-aliasing',
+'-fvisibility=hidden',
+-   '-fstack-protector',
+-   '-fstack-protector-strong',
+'--param=ssp-buffer-size=4',
+   ]
+ if cc.has_argument(arg)
+-- 
+2.13.0
+
diff --git a/meta/recipes-core/systemd/systemd_237.bb 
b/meta/recipes-core/systemd/systemd_237.bb
index ae6e455..dfa43ea 100644
--- a/meta/recipes-core/systemd/systemd_237.bb
+++ b/meta/recipes-core/systemd/systemd_237.bb
@@ -53,6 +53,10 @@ SRC_URI = "git://github.com/systemd/systemd.git;protocol=git 
\
"
 SRC_URI_append_qemuall = " 
file://0001-core-device.c-Change-the-default-device-timeout-to-2.patch"
 
+# Workaround undefined reference to `__stack_chk_fail_local' on qemux86 and 
qemuppc for musl
+SRC_URI_append_libc-musl_qemux86 = " 
file://0001-Remove-fstack-protector-flags-to-workaround-musl-bui.patch"
+SRC_URI_append_libc-musl_qemuppc = " 
file://0001-Remove-fstack-protector-flags-to-workaround-musl-bui.patch"
+
 PAM_PLUGINS = " \
 pam-plugin-unix \
 pam-plugin-loginuid \
-- 
1.9.1

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

[OE-core] [PATCH 3/3] systemd-boot: upgrade to 237

[Chen Qi]

Upgrade systemd-boot to 237.

As systemd has dropped autotools support, fix configure and compile
failures related to meson.

Signed-off-by: Chen Qi 
---
 .../{systemd-boot_234.bb => systemd-boot_237.bb}   | 31 ++-
 ...01-Also-check-i386-i586-and-i686-for-ia32.patch | 28 ++
 ...efi_cc-and-efi_ld-correctly-when-cross-co.patch | 62 ++
 3 files changed, 108 insertions(+), 13 deletions(-)
 rename meta/recipes-core/systemd/{systemd-boot_234.bb => systemd-boot_237.bb} 
(58%)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-Also-check-i386-i586-and-i686-for-ia32.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-Fix-to-run-efi_cc-and-efi_ld-correctly-when-cross-co.patch

diff --git a/meta/recipes-core/systemd/systemd-boot_234.bb 
b/meta/recipes-core/systemd/systemd-boot_237.bb
similarity index 58%
rename from meta/recipes-core/systemd/systemd-boot_234.bb
rename to meta/recipes-core/systemd/systemd-boot_237.bb
index 2d29df8..afd3848 100644
--- a/meta/recipes-core/systemd/systemd-boot_234.bb
+++ b/meta/recipes-core/systemd/systemd-boot_237.bb
@@ -3,20 +3,25 @@ FILESEXTRAPATHS =. "${FILE_DIRNAME}/systemd:"
 
 DEPENDS = "intltool-native libcap util-linux gnu-efi gperf-native"
 
-SRC_URI += 
"file://0007-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch"
+SRC_URI += 
"file://0003-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch \
+file://0027-remove-nobody-user-group-checking.patch \
+file://0001-Also-check-i386-i586-and-i686-for-ia32.patch \
+
file://0001-Fix-to-run-efi_cc-and-efi_ld-correctly-when-cross-co.patch \
+"
 
-inherit autotools pkgconfig gettext
+inherit meson pkgconfig gettext
 inherit deploy
 
 EFI_CC ?= "${CC}"
-# Man pages are packaged through the main systemd recipe
-EXTRA_OECONF = " --enable-gnuefi \
- --with-efi-includedir=${STAGING_INCDIR} \
- --with-efi-ldsdir=${STAGING_LIBDIR} \
- --with-efi-libdir=${STAGING_LIBDIR} \
- --disable-manpages \
- EFI_CC='${EFI_CC}' \
-   "
+EXTRA_OEMESON += "-Defi=true \
+  -Dgnu-efi=true \
+  -Defi-includedir=${STAGING_INCDIR}/efi \
+  -Defi-ldsdir=${STAGING_LIBDIR} \
+  -Defi-libdir=${STAGING_LIBDIR} \
+  -Dman=false \
+  -Defi-cc='${EFI_CC}' \
+  -Defi-ld='${LD}' \
+  "
 
 # install to the image as boot*.efi if its the EFI_PROVIDER,
 # otherwise install as the full name.
@@ -49,17 +54,17 @@ do_compile() {
SYSTEMD_BOOT_EFI_ARCH="x64"
fi
 
-   oe_runmake ${SYSTEMD_BOOT_IMAGE_PREFIX}${SYSTEMD_BOOT_IMAGE}
+   ninja src/boot/efi/${SYSTEMD_BOOT_IMAGE_PREFIX}${SYSTEMD_BOOT_IMAGE}
 }
 
 do_install() {
install -d ${D}/boot
install -d ${D}/boot/EFI
install -d ${D}/boot/EFI/BOOT
-   install ${B}/systemd-boot*.efi ${D}/boot/EFI/BOOT/${SYSTEMD_BOOT_IMAGE}
+   install ${B}/src/boot/efi/systemd-boot*.efi 
${D}/boot/EFI/BOOT/${SYSTEMD_BOOT_IMAGE}
 }
 
 do_deploy () {
-   install ${B}/systemd-boot*.efi ${DEPLOYDIR}
+   install ${B}/src/boot/efi/systemd-boot*.efi ${DEPLOYDIR}
 }
 addtask deploy before do_build after do_compile
diff --git 
a/meta/recipes-core/systemd/systemd/0001-Also-check-i386-i586-and-i686-for-ia32.patch
 
b/meta/recipes-core/systemd/systemd/0001-Also-check-i386-i586-and-i686-for-ia32.patch
new file mode 100644
index 000..877bb1c
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-Also-check-i386-i586-and-i686-for-ia32.patch
@@ -0,0 +1,28 @@
+From 3e8c19bb1bbc4493c591f75c00c1fefe3b1c8a69 Mon Sep 17 00:00:00 2001
+From: Chen Qi 
+Date: Tue, 27 Feb 2018 20:42:41 -0800
+Subject: [PATCH] Also check i386, i586 and i686 for ia32
+
+Upstream-Status: Pending
+
+Signed-off-by: Chen Qi 
+---
+ meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index 28cb8b60e..489531a43 100644
+--- a/meson.build
 b/meson.build
+@@ -1217,7 +1217,7 @@ conf.set10('SYSTEMD_SLOW_TESTS_DEFAULT', slow_tests)
+ if get_option('efi')
+ efi_arch = host_machine.cpu_family()
+ 
+-if efi_arch == 'x86'
++if efi_arch == 'x86' or efi_arch == 'i386' or efi_arch == 'i586' or 
efi_arch == 'i686'
+ EFI_MACHINE_TYPE_NAME = 'ia32'
+ gnu_efi_arch = 'ia32'
+ elif efi_arch == 'x86_64'
+-- 
+2.13.0
+
diff --git 
a/meta/recipes-core/systemd/systemd/0001-Fix-to-run-efi_cc-and-efi_ld-correctly-when-cross-co.patch
 
b/meta/recipes-core/systemd/systemd/0001-Fix-to-run-efi_cc-and-efi_ld-correctly-when-cross-co.patch
new file mode 100644
index 000..e2e19ba
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-Fix-to-run-efi_cc-and-efi_ld-correctly-when-cross-co.patch
@@ -0,0 +1,62 @@
+From 

[OE-core] [PATCH 0/3] systemd & systemd-boot: upgrade to 237

[Chen Qi]

Changes in V2:
* Rebase against latest master to resolve conflicts


The following changes since commit 5350ee317740751f2417c1794dd39d3880347dbf:

  yocto-uninative: Upgrade to 1.8 version with glibc 2.27 (2018-03-11 06:27:02 
-0700)

are available in the git repository at:

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

Chen Qi (3):
  systemd: upgrade to 237
  systemd: fix build failure for qemux86 and qemuppc with musl
  systemd-boot: upgrade to 237

 .../{systemd-boot_234.bb => systemd-boot_237.bb}   |  31 ++-
 meta/recipes-core/systemd/systemd.inc  |   2 +-
 ...01-Also-check-i386-i586-and-i686-for-ia32.patch |  28 +++
 ...efi_cc-and-efi_ld-correctly-when-cross-co.patch |  62 +
 ...ck-protector-flags-to-workaround-musl-bui.patch |  33 +++
 ...v-when-secure-versions-are-not-available.patch} |  21 +-
 ...te-presets-after-generators-have-run-6526.patch |  69 --
 ...any-initialization-steps-when-running-in-.patch | 163 -
 ...update-header-file-to-detect-memfd_create.patch |  28 ---
 ...t-install-dependency-links-at-install-tim.patch |  81 +++
 ...c-Check-if-memfd_create-is-already-define.patch |  27 ---
 .../systemd/0003-fileio-include-sys-mman.h.patch   |  26 --
 ...pper-instead-of-looking-for-relative-opti.patch |  64 +
 ...004-implment-systemd-sysv-install-for-OE.patch} |   8 +-
 ...t-install-dependency-links-at-install-tim.patch |  74 --
 ...patch => 0005-rules-whitelist-hd-devices.patch} |   9 +-
 ...6-Make-root-s-home-directory-configurable.patch |  78 ++
 ...vert-rules-remove-firmware-loading-rules.patch} |   8 +-
 ...-check-for-missing-canonicalize_file_name.patch |  63 -
 ...pper-instead-of-looking-for-relative-opti.patch |  40 ---
 .../systemd/0008-Do-not-enable-nss-tests.patch |  35 ---
 ...remove-userspace-firmware-loading-suppor.patch} | 204 +---
 ...=> 0009-remove-duplicate-include-uchar.h.patch} |  14 +-
 .../0010-check-for-uchar.h-in-meson.build.patch|  45 
 ...nes-Build-conditionally-when-HAVE_MYHOSTN.patch |  38 ---
 ...l-don-t-fail-if-libc-doesn-t-support-IDN.patch} |  26 +-
 ...es-watch-metadata-changes-in-ide-devices.patch} |   8 +-
 ...3-Make-root-s-home-directory-configurable.patch | 155 
 ...lback-parse_printf_format-implementation.patch} |  86 ---
 ...sic-missing.h-check-for-missing-strndupa.patch} |  96 
 ...f-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch} |  30 +--
 ...ssing.h-check-for-missing-__compar_fn_t-.patch} |  18 +-
 ...patch => 0017-Include-netinet-if_ether.h.patch} |  55 +++--
 ...-check-for-missing-canonicalize_file_name.patch |  47 
 .../0018-check-for-uchar.h-in-configure.patch  |  44 
 ...le-nss-tests-if-nss-systemd-is-not-enable.patch |  29 +++
 ...xdecoct.c-Include-missing.h-for-strndupa.patch} |  15 +-
 ...c-Disable-tests-for-missing-typedefs-in-.patch} |  39 ++-
 ...=> 0022-don-t-use-glibc-specific-qsort_r.patch} |  26 +-
 ...ss-AT_SYMLINK_NOFOLLOW-flag-to-faccessat.patch} |  22 +-
 ...n_t-is-glibc-specific-use-raw-signature-.patch} |  14 +-
 ...ATH_WTMPX-and-_PATH_UTMPX-if-not-defined.patch} |  16 +-
 ...> 0026-Use-uintmax_t-for-handling-rlim_t.patch} |  22 +-
 .../0027-remove-nobody-user-group-checking.patch   |  63 +
 .../0028-add-missing-FTW_-macros-for-musl.patch|  50 
 ...nes-Build-conditionally-when-ENABLE_MYHOS.patch |  43 
 ...-of-__register_atfork-for-non-glibc-build.patch |  45 
 ...-ULONG_LONG_MAX-definition-in-case-of-mus.patch |  30 +++
 meta/recipes-core/systemd/systemd/run-ptest|   6 -
 .../systemd/{systemd_234.bb => systemd_237.bb} | 270 +
 50 files changed, 1211 insertions(+), 1295 deletions(-)
 rename meta/recipes-core/systemd/{systemd-boot_234.bb => systemd-boot_237.bb} 
(58%)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-Also-check-i386-i586-and-i686-for-ia32.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-Fix-to-run-efi_cc-and-efi_ld-correctly-when-cross-co.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-Remove-fstack-protector-flags-to-workaround-musl-bui.patch
 rename 
meta/recipes-core/systemd/systemd/{0004-Use-getenv-when-secure-versions-are-not-available.patch
 => 0001-Use-getenv-when-secure-versions-are-not-available.patch} (53%)
 delete mode 100644 
meta/recipes-core/systemd/systemd/0001-core-evaluate-presets-after-generators-have-run-6526.patch
 delete mode 100644 
meta/recipes-core/systemd/systemd/0001-main-skip-many-initialization-steps-when-running-in-.patch
 delete mode 100644 
meta/recipes-core/systemd/systemd/0001-meson-update-header-file-to-detect-memfd_create.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0002-binfmt-Don-t-install-dependency-links-at-install-tim.patch
 delete mode 100644 
meta/recipes-core/systemd/systemd/0002-configure.ac-Check-if-memfd_create-is-already-define.patch
 delete mode 100644