[OE-core] [PATCH 1/2] devtool: sdk-update: drop support for local updates

[Paul Eggleton]

Having two code paths here makes maintenance difficult, and it doesn't
seem likely that you would use the local case in real usage anyway, so
drop the local support entirely.

This should allow us to resolve [YOCTO #9301].

Signed-off-by: Paul Eggleton 
---
 scripts/lib/devtool/sdk.py | 188 ++---
 1 file changed, 76 insertions(+), 112 deletions(-)

diff --git a/scripts/lib/devtool/sdk.py b/scripts/lib/devtool/sdk.py
index 46fd12b..922277b 100644
--- a/scripts/lib/devtool/sdk.py
+++ b/scripts/lib/devtool/sdk.py
@@ -107,7 +107,7 @@ def check_manifest(fn, basepath):
 return changedfiles
 
 def sdk_update(args, config, basepath, workspace):
-# Fetch locked-sigs.inc file from remote/local destination
+"""Entry point for devtool sdk-update command"""
 updateserver = args.updateserver
 if not updateserver:
 updateserver = config.get('SDK', 'updateserver', '')
@@ -122,10 +122,9 @@ def sdk_update(args, config, basepath, workspace):
 else:
 logger.debug("Found conf/locked-sigs.inc in %s" % basepath)
 
-if ':' in updateserver:
-is_remote = True
-else:
-is_remote = False
+if not '://' in updateserver:
+logger.error("Update server must be a URL")
+return -1
 
 layers_dir = os.path.join(basepath, 'layers')
 conf_dir = os.path.join(basepath, 'conf')
@@ -139,120 +138,85 @@ def sdk_update(args, config, basepath, workspace):
 finally:
 tinfoil.shutdown()
 
-if not is_remote:
-# devtool sdk-update /local/path/to/latest/sdk
-new_locked_sig_file_path = os.path.join(updateserver, 
'conf/locked-sigs.inc')
-if not os.path.exists(new_locked_sig_file_path):
-logger.error("%s doesn't exist or is not an extensible SDK" % 
updateserver)
-return -1
-else:
-logger.debug("Found conf/locked-sigs.inc in %s" % updateserver)
-update_dict = generate_update_dict(new_locked_sig_file_path, 
old_locked_sig_file_path)
-logger.debug("update_dict = %s" % update_dict)
-newsdk_path = updateserver
-sstate_dir = os.path.join(newsdk_path, 'sstate-cache')
-if not os.path.exists(sstate_dir):
-logger.error("sstate-cache directory not found under %s" % 
newsdk_path)
-return 1
-sstate_objects = get_sstate_objects(update_dict, sstate_dir)
-logger.debug("sstate_objects = %s" % sstate_objects)
-if len(sstate_objects) == 0:
-logger.info("No need to update.")
+tmpsdk_dir = tempfile.mkdtemp()
+try:
+os.makedirs(os.path.join(tmpsdk_dir, 'conf'))
+new_locked_sig_file_path = os.path.join(tmpsdk_dir, 'conf', 
'locked-sigs.inc')
+# Fetch manifest from server
+tmpmanifest = os.path.join(tmpsdk_dir, 'conf', 'sdk-conf-manifest')
+ret = subprocess.call("wget -q -O %s %s/conf/sdk-conf-manifest" % 
(tmpmanifest, updateserver), shell=True)
+changedfiles = check_manifest(tmpmanifest, basepath)
+if not changedfiles:
+logger.info("Already up-to-date")
 return 0
-logger.info("Installing sstate objects into %s", basepath)
-install_sstate_objects(sstate_objects, updateserver.rstrip('/'), 
basepath)
-logger.info("Updating configuration files")
-new_conf_dir = os.path.join(updateserver, 'conf')
-shutil.rmtree(conf_dir)
-shutil.copytree(new_conf_dir, conf_dir)
-logger.info("Updating layers")
-new_layers_dir = os.path.join(updateserver, 'layers')
-shutil.rmtree(layers_dir)
-ret = subprocess.call("cp -a %s %s" % (new_layers_dir, layers_dir), 
shell=True)
-if ret != 0:
-logger.error("Copying %s to %s failed" % (new_layers_dir, 
layers_dir))
-return ret
-else:
-# devtool sdk-update http://myhost/sdk
-tmpsdk_dir = tempfile.mkdtemp()
-try:
-os.makedirs(os.path.join(tmpsdk_dir, 'conf'))
-new_locked_sig_file_path = os.path.join(tmpsdk_dir, 'conf', 
'locked-sigs.inc')
-# Fetch manifest from server
-tmpmanifest = os.path.join(tmpsdk_dir, 'conf', 'sdk-conf-manifest')
-ret = subprocess.call("wget -q -O %s %s/conf/sdk-conf-manifest" % 
(tmpmanifest, updateserver), shell=True)
-changedfiles = check_manifest(tmpmanifest, basepath)
-if not changedfiles:
-logger.info("Already up-to-date")
-return 0
-# Update metadata
-logger.debug("Updating metadata via git ...")
-#Check for the status before doing a fetch and reset
-if os.path.exists(os.path.join(basepath, 'layers/.git')):
-out = subprocess.check_output("git status --porcelain", 
shell=True, cwd=layers_dir)
-if not out:
-ret = subprocess.call("git fetch --all; git reset 

[OE-core] [PATCH 2/2] classes/populate_sdk_ext: adjust variable blacklisting

[Paul Eggleton]

* Blacklist SSTATE_DIR, DL_DIR and TMPDIR by default to avoid problems
  such as the one mentioned in [YOCTO #9605].
* Blacklist BB_NUMBER_PARSE_THREADS since we already blacklist
  BB_NUMBER_THREADS and they may be set separately.

Fixes [YOCTO #9605].

Signed-off-by: Paul Eggleton 
---
 meta/classes/populate_sdk_ext.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 87518d1..a975d87 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -26,9 +26,13 @@ SDK_RECRDEP_TASKS ?= ""
 SDK_LOCAL_CONF_WHITELIST ?= ""
 SDK_LOCAL_CONF_BLACKLIST ?= "CONF_VERSION \
  BB_NUMBER_THREADS \
+ BB_NUMBER_PARSE_THREADS \
  PARALLEL_MAKE \
  PRSERV_HOST \
  SSTATE_MIRRORS \
+ DL_DIR \
+ SSTATE_DIR \
+ TMPDIR \
 "
 SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
 SDK_UPDATE_URL ?= ""
-- 
2.5.5

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

[OE-core] [PATCH 0/2] Extensible SDK fixes

[Paul Eggleton]

The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:

  test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/extsdkfixes11-oe
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/extsdkfixes11-oe

Paul Eggleton (2):
  devtool: sdk-update: drop support for local updates
  classes/populate_sdk_ext: adjust variable blacklisting

 meta/classes/populate_sdk_ext.bbclass |   4 +
 scripts/lib/devtool/sdk.py| 188 ++
 2 files changed, 80 insertions(+), 112 deletions(-)

-- 
2.5.5

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

[OE-core] [PATCH] systemd: re-enable mount propagation for udevd

[rongqing.li]

From: Roy Li 

With MountFlags=slave, those mounts then become private to the systemd-udevd
namespace and are no longer accessible from outside the namespace, which is
not expected

Signed-off-by: Roy Li 
---
 ...dev-re-enable-mount-propagation-for-udevd.patch | 31 ++
 meta/recipes-core/systemd/systemd_229.bb   |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/udev-re-enable-mount-propagation-for-udevd.patch

diff --git 
a/meta/recipes-core/systemd/systemd/udev-re-enable-mount-propagation-for-udevd.patch
 
b/meta/recipes-core/systemd/systemd/udev-re-enable-mount-propagation-for-udevd.patch
new file mode 100644
index 000..23e22d4
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/udev-re-enable-mount-propagation-for-udevd.patch
@@ -0,0 +1,31 @@
+From: Michael Biebl 
+Date: Sat, 27 Sep 2014 04:19:24 +0200
+Subject: udev: re-enable mount propagation for udevd
+
+Upstream-Status: Backport 
[http://http.debian.net/debian/pool/main/s/systemd/systemd_215-17+deb8u4.debian.tar.xz]
+
+laptop-mode-tools remounts file systems from within a udev rule to apply
+certain mount options. With MountFlags=slave, those mounts then become private
+to the systemd-udevd namespace and are no longer accessible from outside the
+namespace.
+While the root cause is the broken behaviour of laptop-mode-tools, with mount
+propagation turned off, this can result in a read-only root file system.
+Therefore revert the relevant parts from commit
+c2c13f2df42e0691aecabe3979ea81cd7faa35c7 to re-enable mount propagation for
+udevd.
+
+Once affected packages have been fixed, this patch should be dropped
+again.
+
+Closes: #762018
+diff --git a/units/systemd-udevd.service.in b/units/systemd-udevd.service.in
+index e7216d6..1e9a600 100644
+--- a/units/systemd-udevd.service.in
 b/units/systemd-udevd.service.in
+@@ -21,6 +21,5 @@ Sockets=systemd-udevd-control.socket 
systemd-udevd-kernel.socket
+ Restart=always
+ RestartSec=0
+ ExecStart=@rootlibexecdir@/systemd-udevd
+-MountFlags=slave
+ KillMode=mixed
+ WatchdogSec=1min
diff --git a/meta/recipes-core/systemd/systemd_229.bb 
b/meta/recipes-core/systemd/systemd_229.bb
index c23c749..78692c4 100644
--- a/meta/recipes-core/systemd/systemd_229.bb
+++ b/meta/recipes-core/systemd/systemd_229.bb
@@ -54,6 +54,7 @@ SRC_URI = "git://github.com/systemd/systemd.git;protocol=git \

file://0021-include-missing.h-for-getting-secure_getenv-definiti.patch \

file://0022-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch \
file://0023-build-sys-fix-build-with-libgrcypt-disabled.patch \
+   file://udev-re-enable-mount-propagation-for-udevd.patch \
 "
 SRC_URI_append_libc-uclibc = "\

file://0002-units-Prefer-getty-to-agetty-in-console-setup-system.patch \
-- 
2.8.1

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

Re: [OE-core] [PATCH v2 2/2] systemd: add users/groups at build rather than runtime

[Khem Raj]

> On May 9, 2016, at 5:55 PM, Stephano Cetola  
> wrote:
> 
> On 05/09, Khem Raj wrote:
>> 
>>> On May 9, 2016, at 4:42 PM, Stephano Cetola 
>>>  wrote:
>>> 
>>> This fix ensures that systemd users are created at build and that any
>>> staticids for the users or groups are preserved. This functionality only
>>> existed for readonly filesystems, however it seems wise to be sure these
>>> users are added rather than relying on systemd to create them.
>> 
>> We need to cover the case where online package management is used. If you 
>> were to fix
>> it in systemd recipe itself which takes care of creating these users in post 
>> installs
>> that will fix it for this case too.
> I'm not sure I follow you. I can see how this could be done in a post
> install script, but I'm missing how this would help online package
> management. Could you please point me in the right direction?

Lets say, I did not install microhttpserver in default image. But later on I 
decided to install it via
O_P_M feeds. or remove for that matter.

>> 
>>> 
>>> [ YOCTO #9497 ]
>>> 
>>> Signed-off-by: Stephano Cetola 
>>> ---
>>> meta/classes/rootfs-postcommands.bbclass | 66 
>>> +---
>>> meta/classes/useradd-staticids.bbclass   | 56 +--
>>> useradd-staticids-list.bbclass   | 56 +++
>>> 3 files changed, 100 insertions(+), 78 deletions(-)
>>> create mode 100644 useradd-staticids-list.bbclass
>>> 
>>> diff --git a/meta/classes/rootfs-postcommands.bbclass 
>>> b/meta/classes/rootfs-postcommands.bbclass
>>> index 95d28af..db4cc75 100644
>>> --- a/meta/classes/rootfs-postcommands.bbclass
>>> +++ b/meta/classes/rootfs-postcommands.bbclass
>>> @@ -1,4 +1,4 @@
>>> -
>>> +inherit useradd-staticids-list
>>> # Zap the root password if debug-tweaks feature is not enabled
>>> ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
>>> 'debug-tweaks', 'empty-root-password' ], "", "zap_empty_root_password ; 
>>> ",d)}'
>>> 
>>> @@ -23,6 +23,9 @@ POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
>>> SYSTEMD_DEFAULT_TARGET ?= '${@bb.utils.contains("IMAGE_FEATURES", 
>>> "x11-base", "graphical.target", "multi-user.target", d)}'
>>> ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
>>> "systemd", "set_systemd_default_target; ", "", d)}'
>>> 
>>> +# Create systemd users at build rather than at runtime
>>> +ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
>>> "systemd", "create_systemd_sysusers; ", "", d)}'
>>> +
>>> ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
>>> 
>>> # Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
>>> @@ -30,7 +33,45 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
>>> SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
>>> ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
>>> 
>>> -
>>> +# Add systemd users checking for any staticids
>>> +python create_systemd_sysusers () {
>>> +import shlex
>>> +import subprocess
>>> +s_users = merge_files(get_passwd_list(d), 7)
>>> +s_groups = merge_files(get_group_list(d), 4)
>>> +confs = ['%s/usr/lib/sysusers.d/systemd.conf' % 
>>> d.getVar('IMAGE_ROOTFS', d), '%s/usr/lib/sysusers.d/systemd-remote.conf' % 
>>> d.getVar('IMAGE_ROOTFS', d)]
>>> +for conf in confs:
>>> +if os.path.isfile(conf):
>>> +with open(conf, 'r') as f:
>>> +for line in f:
>>> +if line.startswith('#'):
>>> +continue
>>> +fields = shlex.split(line.rstrip())
>>> +if not fields:
>>> +continue
>>> +if fields[0] == 'u':
>>> +useradd_params = ''
>>> +if fields[1] in s_users:
>>> +useradd_params += '--uid %s' % 
>>> s_users[fields[1]][2]
>>> +bb.warn("Changing user %s's uid to (%s), 
>>> verify configuration files!" % (fields[1], s_users[fields[1]][2]))
>>> +elif fields[2] != '-':
>>> +useradd_params += '--uid %s' % fields[2]
>>> +if fields[3] != '-':
>>> +useradd_params += ' --comment "%s"' % fields[3]
>>> +useradd_params += ' --root "%s" --shell 
>>> /sbin/nologin  --system %s' % (d.getVar("IMAGE_ROOTFS", d), fields[1])
>>> +code = subprocess.call('useradd %s' % 
>>> useradd_params, shell=True)
>>> +elif fields[0] == 'g':
>>> +groupadd_params = ""
>>> +if fields[1] in s_groups:
>>> +groupadd_params += '--gid %s' % 
>>> s_groups[fields[1]][2]
>>> +

Re: [OE-core] [PATCH v2 2/2] systemd: add users/groups at build rather than runtime

[Stephano Cetola]

On 05/09, Khem Raj wrote:
> 
> > On May 9, 2016, at 4:42 PM, Stephano Cetola 
> >  wrote:
> > 
> > This fix ensures that systemd users are created at build and that any
> > staticids for the users or groups are preserved. This functionality only
> > existed for readonly filesystems, however it seems wise to be sure these
> > users are added rather than relying on systemd to create them.
> 
> We need to cover the case where online package management is used. If you 
> were to fix
> it in systemd recipe itself which takes care of creating these users in post 
> installs
> that will fix it for this case too.
I'm not sure I follow you. I can see how this could be done in a post
install script, but I'm missing how this would help online package
management. Could you please point me in the right direction?
> 
> > 
> > [ YOCTO #9497 ]
> > 
> > Signed-off-by: Stephano Cetola 
> > ---
> > meta/classes/rootfs-postcommands.bbclass | 66 
> > +---
> > meta/classes/useradd-staticids.bbclass   | 56 +--
> > useradd-staticids-list.bbclass   | 56 +++
> > 3 files changed, 100 insertions(+), 78 deletions(-)
> > create mode 100644 useradd-staticids-list.bbclass
> > 
> > diff --git a/meta/classes/rootfs-postcommands.bbclass 
> > b/meta/classes/rootfs-postcommands.bbclass
> > index 95d28af..db4cc75 100644
> > --- a/meta/classes/rootfs-postcommands.bbclass
> > +++ b/meta/classes/rootfs-postcommands.bbclass
> > @@ -1,4 +1,4 @@
> > -
> > +inherit useradd-staticids-list
> > # Zap the root password if debug-tweaks feature is not enabled
> > ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
> > 'debug-tweaks', 'empty-root-password' ], "", "zap_empty_root_password ; 
> > ",d)}'
> > 
> > @@ -23,6 +23,9 @@ POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
> > SYSTEMD_DEFAULT_TARGET ?= '${@bb.utils.contains("IMAGE_FEATURES", 
> > "x11-base", "graphical.target", "multi-user.target", d)}'
> > ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
> > "systemd", "set_systemd_default_target; ", "", d)}'
> > 
> > +# Create systemd users at build rather than at runtime
> > +ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
> > "systemd", "create_systemd_sysusers; ", "", d)}'
> > +
> > ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
> > 
> > # Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
> > @@ -30,7 +33,45 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
> > SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
> > ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
> > 
> > -
> > +# Add systemd users checking for any staticids
> > +python create_systemd_sysusers () {
> > +import shlex
> > +import subprocess
> > +s_users = merge_files(get_passwd_list(d), 7)
> > +s_groups = merge_files(get_group_list(d), 4)
> > +confs = ['%s/usr/lib/sysusers.d/systemd.conf' % 
> > d.getVar('IMAGE_ROOTFS', d), '%s/usr/lib/sysusers.d/systemd-remote.conf' % 
> > d.getVar('IMAGE_ROOTFS', d)]
> > +for conf in confs:
> > +if os.path.isfile(conf):
> > +with open(conf, 'r') as f:
> > +for line in f:
> > +if line.startswith('#'):
> > +continue
> > +fields = shlex.split(line.rstrip())
> > +if not fields:
> > +continue
> > +if fields[0] == 'u':
> > +useradd_params = ''
> > +if fields[1] in s_users:
> > +useradd_params += '--uid %s' % 
> > s_users[fields[1]][2]
> > +bb.warn("Changing user %s's uid to (%s), 
> > verify configuration files!" % (fields[1], s_users[fields[1]][2]))
> > +elif fields[2] != '-':
> > +useradd_params += '--uid %s' % fields[2]
> > +if fields[3] != '-':
> > +useradd_params += ' --comment "%s"' % fields[3]
> > +useradd_params += ' --root "%s" --shell 
> > /sbin/nologin  --system %s' % (d.getVar("IMAGE_ROOTFS", d), fields[1])
> > +code = subprocess.call('useradd %s' % 
> > useradd_params, shell=True)
> > +elif fields[0] == 'g':
> > +groupadd_params = ""
> > +if fields[1] in s_groups:
> > +groupadd_params += '--gid %s' % 
> > s_groups[fields[1]][2]
> > +bb.warn("Changing group %s's gid to (%s), 
> > verify configuration files!" % (fields[1], s_groups[fields[1]][2]))
> > +elif fields[2] != '-':
> > +groupadd_params += '--gid %s' % fields[2]
> > +  

[OE-core] [PATCH 2/2] edgerouter: libffi: fix build with soft-float tune

[Ruslan Babayev]

Signed-off-by: Ruslan Babayev 
---
 .../recipes-support/libffi/libffi/mips-n32-soft-float.patch | 13 +
 meta/recipes-support/libffi/libffi_3.2.1.bb |  1 +
 2 files changed, 14 insertions(+)
 create mode 100644 meta/recipes-support/libffi/libffi/mips-n32-soft-float.patch

diff --git a/meta/recipes-support/libffi/libffi/mips-n32-soft-float.patch 
b/meta/recipes-support/libffi/libffi/mips-n32-soft-float.patch
new file mode 100644
index 000..c901614
--- /dev/null
+++ b/meta/recipes-support/libffi/libffi/mips-n32-soft-float.patch
@@ -0,0 +1,13 @@
+Index: libffi-3.2.1/src/mips/n32.S
+===
+--- libffi-3.2.1.orig/src/mips/n32.S
 libffi-3.2.1/src/mips/n32.S
+@@ -30,7 +30,7 @@
+ 
+ /* Only build this code if we are compiling for n32 */
+ 
+-#if defined(FFI_MIPS_N32)
++#if defined(FFI_MIPS_N32) && !defined(__mips_soft_float)
+ 
+ #define callback a0
+ #define bytes  a2
diff --git a/meta/recipes-support/libffi/libffi_3.2.1.bb 
b/meta/recipes-support/libffi/libffi_3.2.1.bb
index 72e25fb..5b57e79 100644
--- a/meta/recipes-support/libffi/libffi_3.2.1.bb
+++ b/meta/recipes-support/libffi/libffi_3.2.1.bb
@@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=3610bb17683a0089ed64055416b2ae1b"
 SRC_URI = "ftp://sourceware.org/pub/libffi/${BP}.tar.gz \
file://not-win32.patch \
   file://0001-mips-Use-compiler-internal-define-for-linux.patch \
+   file://mips-n32-soft-float.patch \
   "
 
 SRC_URI[md5sum] = "83b89587607e3eb65c70d361f13bab43"
-- 
2.7.4

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

[OE-core] [PATCH 1/2] edgerouter: fix machine tune

[Ruslan Babayev]

Octeon+ lacks FPU

Signed-off-by: Ruslan Babayev 
---
 meta-yocto-bsp/conf/machine/edgerouter.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta-yocto-bsp/conf/machine/edgerouter.conf 
b/meta-yocto-bsp/conf/machine/edgerouter.conf
index 6343dfc..062d896 100644
--- a/meta-yocto-bsp/conf/machine/edgerouter.conf
+++ b/meta-yocto-bsp/conf/machine/edgerouter.conf
@@ -2,6 +2,7 @@
 #@NAME: Edgerouter
 #@DESCRIPTION: Edgerouter
 
+DEFAULTTUNE ?= "mips64-nf"
 require conf/machine/include/tune-mips64.inc
 
 MACHINE_FEATURES = "pci ext2 ext3 serial"
-- 
2.7.4

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

[OE-core] [PATCH 0/2] fix edgerouter default tune

[Ruslan Babayev]

Fixes building core-image-minimal with the following in local.conf:

MACHINE = "edgerouter"
TCLIBC = "musl"

Ruslan Babayev (2):
  edgerouter: fix machine tune
  edgerouter: libffi: fix build with soft-float tune

 meta-yocto-bsp/conf/machine/edgerouter.conf |  1 +
 .../recipes-support/libffi/libffi/mips-n32-soft-float.patch | 13 +
 meta/recipes-support/libffi/libffi_3.2.1.bb |  1 +
 3 files changed, 15 insertions(+)
 create mode 100644 meta/recipes-support/libffi/libffi/mips-n32-soft-float.patch

-- 
2.7.4

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

Re: [OE-core] [RFC PATCH 5/6] classes/kernel: check OLDEST_KERNEL at configure time

[Khem Raj]

> On May 8, 2016, at 9:43 PM, Paul Eggleton  
> wrote:
> 
> If the kernel being built is older than OLDEST_KERNEL and we're building
> with glibc, then the C library we're building is probably not going to
> be compatible with the kernel and we should warn the user. (This is
> easier to do here rather than when building glibc, because we don't
> necessarily have the information we need to determine the kernel version
> there, whereas we do here.)
> 
> Fixes [YOCTO #8653].
> 
> Signed-off-by: Paul Eggleton 
> ---
> meta/classes/kernel.bbclass | 14 ++
> 1 file changed, 14 insertions(+)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index fa0864c..af88cc0 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -330,6 +330,20 @@ sysroot_stage_all () {
> 
> KERNEL_CONFIG_COMMAND ?= "oe_runmake_call -C ${S} O=${B} oldnoconfig || yes 
> '' | oe_runmake -C ${S} O=${B} oldconfig"
> 
> +python check_oldest_kernel() {
> +oldest_kernel = d.getVar('OLDEST_KERNEL', True)
> +kernel_version = d.getVar('KERNEL_VERSION', True)
> +tclibc = d.getVar('TCLIBC', True)
> +if tclibc == 'glibc':
> +kernel_version = kernel_version.split('-', 1)[0]
> +if oldest_kernel and kernel_version:
> +if bb.utils.vercmp_string(kernel_version, oldest_kernel) < 0:
> +bb.warn('%s: OLDEST_KERNEL is "%s" but the version of the 
> kernel you are building is "%s" - therefore %s as built may not be compatible 
> with this kernel. Either set OLDEST_KERNEL to an older version, or build a 
> newer kernel.' % (d.getVar('PN', True), oldest_kernel, kernel_version, 
> tclibc))
> +}

this should be an error infact. system may not boot properly if someone ignored 
the warning.

> +
> +check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
> +do_configure[prefuncs] += "check_oldest_kernel"
> +
> kernel_do_configure() {
>   # fixes extra + in /lib/modules/2.6.37+
>   # $ scripts/setlocalversion . => +
> --
> 2.5.5
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 3/6] systemd: check for required kernel config options

[Khem Raj]

> On May 8, 2016, at 9:43 PM, Paul Eggleton  
> wrote:
> 
> Use the list in the systemd 225 README to set required Linux kernel
> config options.
> 
> Fixes [YOCTO #5574].
> 
> Signed-off-by: Paul Eggleton 
> ---
> meta/recipes-core/systemd/systemd_229.bb | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_229.bb 
> b/meta/recipes-core/systemd/systemd_229.bb
> index c23c749..d64b3cd 100644
> --- a/meta/recipes-core/systemd/systemd_229.bb
> +++ b/meta/recipes-core/systemd/systemd_229.bb
> @@ -22,7 +22,7 @@ DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native 
> gperf-native acl rea
> 
> SECTION = "base/shell"
> 
> -inherit useradd pkgconfig autotools perlnative update-rc.d 
> update-alternatives qemu systemd ptest gettext bash-completion
> +inherit useradd pkgconfig autotools perlnative update-rc.d 
> update-alternatives qemu systemd ptest gettext bash-completion kernel-check
> 
> SRCREV = "714c62b46379abb7558c544665522aca91691e10"
> 
> @@ -192,6 +192,23 @@ CFLAGS .= "${@bb.utils.contains('PACKAGECONFIG', 
> 'valgrind', ' -DVALGRIND=1', ''
> # disable problematic GCC 5.2 optimizations [YOCTO #8291]
> FULL_OPTIMIZATION_append_arm = " -fno-schedule-insns -fno-schedule-insns2"
> 
> +# All the required options from the systemd README
> +REQUIRED_KERNEL_OPTIONS = "\
> +   CONFIG_DEVTMPFS \
> +   CONFIG_CGROUPS \
> +   CONFIG_INOTIFY_USER \
> +   CONFIG_SIGNALFD \
> +   CONFIG_TIMERFD \
> +   CONFIG_EPOLL \
> +   CONFIG_NET \
> +   CONFIG_SYSFS \
> +   CONFIG_PROC_FS \
> +   CONFIG_FHANDLE \
> +   CONFIG_SYSFS_DEPRECATED=n \
> +   CONFIG_UEVENT_HELPER_PATH='' \
> +   CONFIG_FW_LOADER_USER_HELPER=n \

We still carry the patch for user fw loader. So this may be removed.

> +   "
> +
> do_configure_prepend() {
>   export NM="${HOST_PREFIX}gcc-nm"
>   export AR="${HOST_PREFIX}gcc-ar"
> --
> 2.5.5
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 1/2] systemd: add sysusers config option to defaults

[Stephano Cetola]

On 05/09, Khem Raj wrote:
> 
> > On May 9, 2016, at 4:42 PM, Stephano Cetola 
> >  wrote:
> > 
> > Without the sysusers config option, the build will not know which users
> > need to be added for systemd. This is especially necessary if the
> > filesystem is readonly, as these users cannot be added at runtime.
> > 
> > Signed-off-by: Stephano Cetola 
> > ---
> > meta/recipes-core/systemd/systemd_229.bb | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-core/systemd/systemd_229.bb 
> > b/meta/recipes-core/systemd/systemd_229.bb
> > index c23c749..aba73df 100644
> > --- a/meta/recipes-core/systemd/systemd_229.bb
> > +++ b/meta/recipes-core/systemd/systemd_229.bb
> > @@ -23,6 +23,7 @@ DEPENDS = "kmod docbook-sgml-dtd-4.1-native 
> > intltool-native gperf-native acl rea
> > SECTION = "base/shell"
> > 
> > inherit useradd pkgconfig autotools perlnative update-rc.d 
> > update-alternatives qemu systemd ptest gettext bash-completion
> > +USERADDEXTENSION += " useradd-staticids"
> > 
> > SRCREV = "714c62b46379abb7558c544665522aca91691e10"
> > 
> > @@ -80,7 +81,8 @@ PACKAGECONFIG ??= "xz \
> >quotacheck \
> >bootchart \
> >hostnamed \
> > -   ${@bb.utils.contains('TCLIBC', 'glibc', 'myhostname 
> > sysusers', '', d)} \
> > +   sysusers \
> > +   ${@bb.utils.contains('TCLIBC', 'glibc', 'myhostname', 
> > '', d)} \
> 
> sysusers did not compile with uclibc, did you test this patch with uclibc?
You are correct, it still fails. Sorry, you can drop this from the
series.
> 
> >hibernate \
> >timedated \
> >timesyncd \
> > --
> > 2.8.0
> > 
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 


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

Re: [OE-core] [master][krogoth][PATCH] gcc: backport gperf fixes

[Khem Raj]

> On May 9, 2016, at 2:14 PM, Dan McGregor  wrote:
> 
> From: Daniel McGregor 
> 
> gperf was being used in a way that generated files don't conform to
> the language standard. Backport the fix from upstream.
> 
> This is required to build these GCC versions when the host compiler
> is GCC 6.
> 

this is ok for krogoth. Although for master most likely we will remove gcc 4.9

> Signed-off-by: Daniel McGregor 
> ---
> meta/recipes-devtools/gcc/gcc-4.9.inc  |   1 +
> .../gcc/gcc-4.9/0075-remove-prototypes-cfns.patch  | 153 +
> meta/recipes-devtools/gcc/gcc-5.3.inc  |   1 +
> .../gcc/gcc-5.3/0059-remove-prototypes-cfns.patch  | 153 +
> 4 files changed, 308 insertions(+)
> create mode 100644 
> meta/recipes-devtools/gcc/gcc-4.9/0075-remove-prototypes-cfns.patch
> create mode 100644 
> meta/recipes-devtools/gcc/gcc-5.3/0059-remove-prototypes-cfns.patch
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
> b/meta/recipes-devtools/gcc/gcc-4.9.inc
> index 7e03f31..2be0599 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.9.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
> @@ -90,6 +90,7 @@ SRC_URI = "\
> file://0072-support-ffile-prefix-map.patch \
> file://0073-Reuse-fdebug-prefix-map-to-replace-ffile-prefix-map.patch \
> file://0074-fdebug-prefix-map-support-to-remap-relative-path.patch \
> +file://0075-remove-prototypes-cfns.patch \
> "
> SRC_URI[md5sum] = "6f831b4d251872736e8e9cc09746f327"
> SRC_URI[sha256sum] = 
> "2332b2a5a321b57508b9031354a8503af6fdfb868b8c1748d33028d100a8b67e"
> diff --git 
> a/meta/recipes-devtools/gcc/gcc-4.9/0075-remove-prototypes-cfns.patch 
> b/meta/recipes-devtools/gcc/gcc-4.9/0075-remove-prototypes-cfns.patch
> new file mode 100644
> index 000..2954f2e
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-4.9/0075-remove-prototypes-cfns.patch
> @@ -0,0 +1,153 @@
> +Upstream-Status: backport
> +
> +From 8c3fa311caa86f61b4e28d1563d1110b44340fb2 Mon Sep 17 00:00:00 2001
> +From: edlinger 
> +Date: Thu, 25 Feb 2016 15:36:41 +
> +Subject: [PATCH] 2016-02-25  Bernd Edlinger  
> +
> +Backported from mainline
> +2016-02-19  Jakub Jelinek  
> +Bernd Edlinger  
> +
> +* Make-lang.in: Invoke gperf with -L C++.
> +* cfns.gperf: Remove prototypes for hash and libc_name_p
> +inlines.
> +* cfns.h: Regenerated.
> +* except.c (nothrow_libfn_p): Adjust.
> +
> +
> +---
> + gcc/cp/Make-lang.in |  2 +-
> + gcc/cp/cfns.gperf   | 10 ++
> + gcc/cp/cfns.h   | 41 ++---
> + gcc/cp/except.c |  3 ++-
> + 5 files changed, 31 insertions(+), 37 deletions(-)
> +
> +diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
> +index bd1c1d7..a0ea0d4 100644
> +--- a/gcc/cp/Make-lang.in
>  b/gcc/cp/Make-lang.in
> +@@ -111,7 +111,7 @@ else
> + # deleting the $(srcdir)/cp/cfns.h file.
> + $(srcdir)/cp/cfns.h:
> + endif
> +-gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \
> ++gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L C++ \
> + $(srcdir)/cp/cfns.gperf --output-file $(srcdir)/cp/cfns.h
> +
> + #
> +diff --git a/gcc/cp/cfns.gperf b/gcc/cp/cfns.gperf
> +index 05ca753..d9b16b8 100644
> +--- a/gcc/cp/cfns.gperf
>  b/gcc/cp/cfns.gperf
> +@@ -1,3 +1,5 @@
> ++%language=C++
> ++%define class-name libc_name
> + %{
> + /* Copyright (C) 2000-2014 Free Software Foundation, Inc.
> +
> +@@ -16,14 +18,6 @@ for more details.
> + You should have received a copy of the GNU General Public License
> + along with GCC; see the file COPYING3.  If not see
> + .  */
> +-#ifdef __GNUC__
> +-__inline
> +-#endif
> +-static unsigned int hash (const char *, unsigned int);
> +-#ifdef __GNUC__
> +-__inline
> +-#endif
> +-const char * libc_name_p (const char *, unsigned int);
> + %}
> + %%
> + # The standard C library functions, for feeding to gperf; the result is used
> +diff --git a/gcc/cp/cfns.h b/gcc/cp/cfns.h
> +index c845ddf..65801d1 100644
> +--- a/gcc/cp/cfns.h
>  b/gcc/cp/cfns.h
> +@@ -1,5 +1,5 @@
> +-/* ANSI-C code produced by gperf version 3.0.3 */
> +-/* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L ANSI-C 
> cfns.gperf  */
> ++/* C++ code produced by gperf version 3.0.4 */
> ++/* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L C++ 
> --output-file cfns.h cfns.gperf  */
> +
> + #if !((' ' == 32) && ('!' == 33) && ('"' == 34) && ('#' == 35) \
> +   && ('%' == 37) && ('&' == 38) && ('\'' == 39) && ('(' == 40) \
> +@@ -28,7 +28,7 @@
> + #error "gperf generated tables don't work with this execution character 
> set. Please report a bug to ."
> + #endif
> +
> +-#line 1 "cfns.gperf"
> 

Re: [OE-core] [PATCH v2 1/2] systemd: add sysusers config option to defaults

[Khem Raj]

> On May 9, 2016, at 4:42 PM, Stephano Cetola  
> wrote:
> 
> Without the sysusers config option, the build will not know which users
> need to be added for systemd. This is especially necessary if the
> filesystem is readonly, as these users cannot be added at runtime.
> 
> Signed-off-by: Stephano Cetola 
> ---
> meta/recipes-core/systemd/systemd_229.bb | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_229.bb 
> b/meta/recipes-core/systemd/systemd_229.bb
> index c23c749..aba73df 100644
> --- a/meta/recipes-core/systemd/systemd_229.bb
> +++ b/meta/recipes-core/systemd/systemd_229.bb
> @@ -23,6 +23,7 @@ DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native 
> gperf-native acl rea
> SECTION = "base/shell"
> 
> inherit useradd pkgconfig autotools perlnative update-rc.d 
> update-alternatives qemu systemd ptest gettext bash-completion
> +USERADDEXTENSION += " useradd-staticids"
> 
> SRCREV = "714c62b46379abb7558c544665522aca91691e10"
> 
> @@ -80,7 +81,8 @@ PACKAGECONFIG ??= "xz \
>quotacheck \
>bootchart \
>hostnamed \
> -   ${@bb.utils.contains('TCLIBC', 'glibc', 'myhostname 
> sysusers', '', d)} \
> +   sysusers \
> +   ${@bb.utils.contains('TCLIBC', 'glibc', 'myhostname', '', 
> d)} \

sysusers did not compile with uclibc, did you test this patch with uclibc?

>hibernate \
>timedated \
>timesyncd \
> --
> 2.8.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 2/2] systemd: add users/groups at build rather than runtime

[Khem Raj]

> On May 9, 2016, at 4:42 PM, Stephano Cetola  
> wrote:
> 
> This fix ensures that systemd users are created at build and that any
> staticids for the users or groups are preserved. This functionality only
> existed for readonly filesystems, however it seems wise to be sure these
> users are added rather than relying on systemd to create them.

We need to cover the case where online package management is used. If you were 
to fix
it in systemd recipe itself which takes care of creating these users in post 
installs
that will fix it for this case too.

> 
> [ YOCTO #9497 ]
> 
> Signed-off-by: Stephano Cetola 
> ---
> meta/classes/rootfs-postcommands.bbclass | 66 +---
> meta/classes/useradd-staticids.bbclass   | 56 +--
> useradd-staticids-list.bbclass   | 56 +++
> 3 files changed, 100 insertions(+), 78 deletions(-)
> create mode 100644 useradd-staticids-list.bbclass
> 
> diff --git a/meta/classes/rootfs-postcommands.bbclass 
> b/meta/classes/rootfs-postcommands.bbclass
> index 95d28af..db4cc75 100644
> --- a/meta/classes/rootfs-postcommands.bbclass
> +++ b/meta/classes/rootfs-postcommands.bbclass
> @@ -1,4 +1,4 @@
> -
> +inherit useradd-staticids-list
> # Zap the root password if debug-tweaks feature is not enabled
> ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
> 'debug-tweaks', 'empty-root-password' ], "", "zap_empty_root_password ; ",d)}'
> 
> @@ -23,6 +23,9 @@ POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
> SYSTEMD_DEFAULT_TARGET ?= '${@bb.utils.contains("IMAGE_FEATURES", "x11-base", 
> "graphical.target", "multi-user.target", d)}'
> ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
> "systemd", "set_systemd_default_target; ", "", d)}'
> 
> +# Create systemd users at build rather than at runtime
> +ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
> "systemd", "create_systemd_sysusers; ", "", d)}'
> +
> ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
> 
> # Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
> @@ -30,7 +33,45 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
> SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
> ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
> 
> -
> +# Add systemd users checking for any staticids
> +python create_systemd_sysusers () {
> +import shlex
> +import subprocess
> +s_users = merge_files(get_passwd_list(d), 7)
> +s_groups = merge_files(get_group_list(d), 4)
> +confs = ['%s/usr/lib/sysusers.d/systemd.conf' % d.getVar('IMAGE_ROOTFS', 
> d), '%s/usr/lib/sysusers.d/systemd-remote.conf' % d.getVar('IMAGE_ROOTFS', d)]
> +for conf in confs:
> +if os.path.isfile(conf):
> +with open(conf, 'r') as f:
> +for line in f:
> +if line.startswith('#'):
> +continue
> +fields = shlex.split(line.rstrip())
> +if not fields:
> +continue
> +if fields[0] == 'u':
> +useradd_params = ''
> +if fields[1] in s_users:
> +useradd_params += '--uid %s' % 
> s_users[fields[1]][2]
> +bb.warn("Changing user %s's uid to (%s), verify 
> configuration files!" % (fields[1], s_users[fields[1]][2]))
> +elif fields[2] != '-':
> +useradd_params += '--uid %s' % fields[2]
> +if fields[3] != '-':
> +useradd_params += ' --comment "%s"' % fields[3]
> +useradd_params += ' --root "%s" --shell 
> /sbin/nologin  --system %s' % (d.getVar("IMAGE_ROOTFS", d), fields[1])
> +code = subprocess.call('useradd %s' % 
> useradd_params, shell=True)
> +elif fields[0] == 'g':
> +groupadd_params = ""
> +if fields[1] in s_groups:
> +groupadd_params += '--gid %s' % 
> s_groups[fields[1]][2]
> +bb.warn("Changing group %s's gid to (%s), verify 
> configuration files!" % (fields[1], s_groups[fields[1]][2]))
> +elif fields[2] != '-':
> +groupadd_params += '--gid %s' % fields[2]
> +if fields[3] != '-':
> +groupadd_params += ' --comment "%s"' % 
> (d.getVar("IMAGE_ROOTFS", d), fields[3])
> +groupadd_params += ' --root "%s" --system %s' % 
> (d.getVar("IMAGE_ROOTFS", d), fields[1])
> +code = subprocess.call('groupadd %s' % 
> groupadd_params, shell=True)
> +}
> 
> #
> # A hook function to support read-only-rootfs IMAGE_FEATURES
> @@ 

[OE-core] [PATCH v2 2/2] systemd: add users/groups at build rather than runtime

[Stephano Cetola]

This fix ensures that systemd users are created at build and that any
staticids for the users or groups are preserved. This functionality only
existed for readonly filesystems, however it seems wise to be sure these
users are added rather than relying on systemd to create them.

[ YOCTO #9497 ]

Signed-off-by: Stephano Cetola 
---
 meta/classes/rootfs-postcommands.bbclass | 66 +---
 meta/classes/useradd-staticids.bbclass   | 56 +--
 useradd-staticids-list.bbclass   | 56 +++
 3 files changed, 100 insertions(+), 78 deletions(-)
 create mode 100644 useradd-staticids-list.bbclass

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 95d28af..db4cc75 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -1,4 +1,4 @@
-
+inherit useradd-staticids-list
 # Zap the root password if debug-tweaks feature is not enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
'debug-tweaks', 'empty-root-password' ], "", "zap_empty_root_password ; ",d)}'
 
@@ -23,6 +23,9 @@ POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
 SYSTEMD_DEFAULT_TARGET ?= '${@bb.utils.contains("IMAGE_FEATURES", "x11-base", 
"graphical.target", "multi-user.target", d)}'
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "set_systemd_default_target; ", "", d)}'
 
+# Create systemd users at build rather than at runtime
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "create_systemd_sysusers; ", "", d)}'
+
 ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 
 # Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
@@ -30,7 +33,45 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
 ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
 
-
+# Add systemd users checking for any staticids 
+python create_systemd_sysusers () {
+import shlex
+import subprocess
+s_users = merge_files(get_passwd_list(d), 7)
+s_groups = merge_files(get_group_list(d), 4)
+confs = ['%s/usr/lib/sysusers.d/systemd.conf' % d.getVar('IMAGE_ROOTFS', 
d), '%s/usr/lib/sysusers.d/systemd-remote.conf' % d.getVar('IMAGE_ROOTFS', d)]
+for conf in confs:
+if os.path.isfile(conf):
+with open(conf, 'r') as f:
+for line in f:
+if line.startswith('#'):
+continue
+fields = shlex.split(line.rstrip())
+if not fields:
+continue
+if fields[0] == 'u':
+useradd_params = ''
+if fields[1] in s_users:
+useradd_params += '--uid %s' % 
s_users[fields[1]][2]
+bb.warn("Changing user %s's uid to (%s), verify 
configuration files!" % (fields[1], s_users[fields[1]][2]))
+elif fields[2] != '-':
+useradd_params += '--uid %s' % fields[2]
+if fields[3] != '-':
+useradd_params += ' --comment "%s"' % fields[3]
+useradd_params += ' --root "%s" --shell /sbin/nologin  
--system %s' % (d.getVar("IMAGE_ROOTFS", d), fields[1])
+code = subprocess.call('useradd %s' % useradd_params, 
shell=True)
+elif fields[0] == 'g':
+groupadd_params = ""
+if fields[1] in s_groups:
+groupadd_params += '--gid %s' % 
s_groups[fields[1]][2]
+bb.warn("Changing group %s's gid to (%s), verify 
configuration files!" % (fields[1], s_groups[fields[1]][2]))
+elif fields[2] != '-':
+groupadd_params += '--gid %s' % fields[2]
+if fields[3] != '-':
+groupadd_params += ' --comment "%s"' % 
(d.getVar("IMAGE_ROOTFS", d), fields[3])
+groupadd_params += ' --root "%s" --system %s' % 
(d.getVar("IMAGE_ROOTFS", d), fields[1])
+code = subprocess.call('groupadd %s' % 
groupadd_params, shell=True)
+}
 
 #
 # A hook function to support read-only-rootfs IMAGE_FEATURES
@@ -73,27 +114,6 @@ read_only_rootfs_hook () {
${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh
fi
fi
-
-   if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", "false", 
d)}; then
-   # Update user database files so that services don't fail for a 
read-only systemd system
-   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
-   

[OE-core] [PATCH v2 1/2] systemd: add sysusers config option to defaults

[Stephano Cetola]

Without the sysusers config option, the build will not know which users
need to be added for systemd. This is especially necessary if the
filesystem is readonly, as these users cannot be added at runtime.

Signed-off-by: Stephano Cetola 
---
 meta/recipes-core/systemd/systemd_229.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_229.bb 
b/meta/recipes-core/systemd/systemd_229.bb
index c23c749..aba73df 100644
--- a/meta/recipes-core/systemd/systemd_229.bb
+++ b/meta/recipes-core/systemd/systemd_229.bb
@@ -23,6 +23,7 @@ DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native 
gperf-native acl rea
 SECTION = "base/shell"
 
 inherit useradd pkgconfig autotools perlnative update-rc.d update-alternatives 
qemu systemd ptest gettext bash-completion
+USERADDEXTENSION += " useradd-staticids"
 
 SRCREV = "714c62b46379abb7558c544665522aca91691e10"
 
@@ -80,7 +81,8 @@ PACKAGECONFIG ??= "xz \
quotacheck \
bootchart \
hostnamed \
-   ${@bb.utils.contains('TCLIBC', 'glibc', 'myhostname 
sysusers', '', d)} \
+   sysusers \
+   ${@bb.utils.contains('TCLIBC', 'glibc', 'myhostname', '', 
d)} \
hibernate \
timedated \
timesyncd \
-- 
2.8.0

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

[OE-core] [PATCH 2/2] systemd: add users/groups at build rather than runtime

[Stephano Cetola]

This fix ensures that systemd users are created at build and that any
staticids for the users or groups are preserved. This functionality only
existed for readonly filesystems, however it seems wise to be sure these
users are added rather than relying on systemd to create them.

[ YOCTO #9497 ]

Signed-off-by: Stephano Cetola 
---
 meta/classes/rootfs-postcommands.bbclass | 66 +---
 meta/classes/useradd-staticids.bbclass   | 56 +--
 useradd-staticids-list.bbclass   | 56 +++
 3 files changed, 100 insertions(+), 78 deletions(-)
 create mode 100644 useradd-staticids-list.bbclass

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 95d28af..db4cc75 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -1,4 +1,4 @@
-
+inherit useradd-staticids-list
 # Zap the root password if debug-tweaks feature is not enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
'debug-tweaks', 'empty-root-password' ], "", "zap_empty_root_password ; ",d)}'
 
@@ -23,6 +23,9 @@ POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
 SYSTEMD_DEFAULT_TARGET ?= '${@bb.utils.contains("IMAGE_FEATURES", "x11-base", 
"graphical.target", "multi-user.target", d)}'
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "set_systemd_default_target; ", "", d)}'
 
+# Create systemd users at build rather than at runtime
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "create_systemd_sysusers; ", "", d)}'
+
 ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 
 # Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
@@ -30,7 +33,45 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
 ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
 
-
+# Add systemd users checking for any staticids 
+python create_systemd_sysusers () {
+import shlex
+import subprocess
+s_users = merge_files(get_passwd_list(d), 7)
+s_groups = merge_files(get_group_list(d), 4)
+confs = ['%s/usr/lib/sysusers.d/systemd.conf' % d.getVar('IMAGE_ROOTFS', 
d), '%s/usr/lib/sysusers.d/systemd-remote.conf' % d.getVar('IMAGE_ROOTFS', d)]
+for conf in confs:
+if os.path.isfile(conf):
+with open(conf, 'r') as f:
+for line in f:
+if line.startswith('#'):
+continue
+fields = shlex.split(line.rstrip())
+if not fields:
+continue
+if fields[0] == 'u':
+useradd_params = ''
+if fields[1] in s_users:
+useradd_params += '--uid %s' % 
s_users[fields[1]][2]
+bb.warn("Changing user %s's uid to (%s), verify 
configuration files!" % (fields[1], s_users[fields[1]][2]))
+elif fields[2] != '-':
+useradd_params += '--uid %s' % fields[2]
+if fields[3] != '-':
+useradd_params += ' --comment "%s"' % fields[3]
+useradd_params += ' --root "%s" --shell /sbin/nologin  
--system %s' % (d.getVar("IMAGE_ROOTFS", d), fields[1])
+code = subprocess.call('useradd %s' % useradd_params, 
shell=True)
+elif fields[0] == 'g':
+groupadd_params = ""
+if fields[1] in s_groups:
+groupadd_params += '--gid %s' % 
s_groups[fields[1]][2]
+bb.warn("Changing group %s's gid to (%s), verify 
configuration files!" % (fields[1], s_groups[fields[1]][2]))
+elif fields[2] != '-':
+groupadd_params += '--gid %s' % fields[2]
+if fields[3] != '-':
+groupadd_params += ' --comment "%s"' % 
(d.getVar("IMAGE_ROOTFS", d), fields[3])
+groupadd_params += ' --root "%s" --system %s' % 
(d.getVar("IMAGE_ROOTFS", d), fields[1])
+code = subprocess.call('groupadd %s' % 
groupadd_params, shell=True)
+}
 
 #
 # A hook function to support read-only-rootfs IMAGE_FEATURES
@@ -73,27 +114,6 @@ read_only_rootfs_hook () {
${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh
fi
fi
-
-   if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", "false", 
d)}; then
-   # Update user database files so that services don't fail for a 
read-only systemd system
-   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
-   

[OE-core] [PATCH 1/2] systemd: add sysusers config option to defaults

[Stephano Cetola]

Without the sysusers config option, the build will not know which users
need to be added for systemd. This is especially necessary if the
filesystem is readonly, as these users cannot be added at runtime.

Signed-off-by: Stephano Cetola 
---
 meta/recipes-core/systemd/systemd_229.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_229.bb 
b/meta/recipes-core/systemd/systemd_229.bb
index c23c749..aba73df 100644
--- a/meta/recipes-core/systemd/systemd_229.bb
+++ b/meta/recipes-core/systemd/systemd_229.bb
@@ -23,6 +23,7 @@ DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native 
gperf-native acl rea
 SECTION = "base/shell"
 
 inherit useradd pkgconfig autotools perlnative update-rc.d update-alternatives 
qemu systemd ptest gettext bash-completion
+USERADDEXTENSION += " useradd-staticids"
 
 SRCREV = "714c62b46379abb7558c544665522aca91691e10"
 
@@ -80,7 +81,8 @@ PACKAGECONFIG ??= "xz \
quotacheck \
bootchart \
hostnamed \
-   ${@bb.utils.contains('TCLIBC', 'glibc', 'myhostname 
sysusers', '', d)} \
+   sysusers \
+   ${@bb.utils.contains('TCLIBC', 'glibc', 'myhostname', '', 
d)} \
hibernate \
timedated \
timesyncd \
-- 
2.8.0

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

[OE-core] [PATCH 0/2] Create systemd users at build time

[Stephano Cetola]

Systemd has a config option sysusers which creates any users or groups that
systemd needs on first boot. There is a rootfs-postcommand that creates these
users in case the filesystem is readonly, however it does not take into
account any staicids that the user may have set.

By adding these users at build time, we allow a check for staticids, which would
otherwise have been skipped.

This issue was initially raised by a fix that was added to Ostro OS. See
Patrick's comments for more info on that.

[ YOCTO #9497 ]

Stephano Cetola (2):
  systemd: add sysusers config option to defaults
  systemd: add users/groups at build rather than runtime

 meta/classes/rootfs-postcommands.bbclass | 66 +---
 meta/classes/useradd-staticids.bbclass   | 56 +--
 meta/recipes-core/systemd/systemd_229.bb |  4 +-
 useradd-staticids-list.bbclass   | 56 +++
 4 files changed, 103 insertions(+), 79 deletions(-)
 create mode 100644 useradd-staticids-list.bbclass

-- 
2.8.0

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

Re: [OE-core] [PATCH v2 1/2] classes/insane: do not force LIC_FILES_CHKSUM unless SRC_URI is set

[Mark Hatle]

On 5/9/16 5:25 PM, Paul Eggleton wrote:
> Recipes such as images and packagegroups don't actually fetch or build
> any source, so there's really no point having LIC_FILES_CHKSUM set.
> Forcing users to set it (as we have done for images inheriting
> image.bbclass) just makes things more difficult for the user for no
> discernable benefit. The easiest way to adjust this check is simply to
> skip it if SRC_URI is not set since this is a pretty good indicator that
> no source is being pulled in.
> 
> Signed-off-by: Paul Eggleton 

I think this is a good idea.  I'd not considered empty SRC_URI as a pointer to
no LIC_FILES_CHKSUM, but it makes sense to me.

--Mark

> ---
>  meta/classes/insane.bbclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 097dc3a..0b151c2 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -681,15 +681,15 @@ python populate_lic_qa_checksum() {
>  import tempfile
>  sane = True
>  
> -lic_files = d.getVar('LIC_FILES_CHKSUM', True)
> +lic_files = d.getVar('LIC_FILES_CHKSUM', True) or ''
>  lic = d.getVar('LICENSE', True)
>  pn = d.getVar('PN', True)
>  
>  if lic == "CLOSED":
>  return
>  
> -if not lic_files:
> -package_qa_handle_error("license-checksum", pn + ": Recipe file does 
> not have license file information (LIC_FILES_CHKSUM)", d)
> +if not lic_files and d.getVar('SRC_URI', True):
> +package_qa_handle_error("license-checksum", pn + ": Recipe file 
> fetches files and does not have license file information (LIC_FILES_CHKSUM)", 
> d)
>  return
>  
>  srcdir = d.getVar('S', True)
> 

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

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Richard Purdie]

On Mon, 2016-05-09 at 15:41 -0700, Christopher Larson wrote:

> I have to say, I didn't realize oe-core patches require testing with
> meta-qt3. I can't remember the last time I touched qt that old. I'll
> have to add more non-core layers to my local testing in the future.

The version of lsb we have requires qt3 so it gets pulled into poky-lsb
only. Personally, I can't wait to upgrade lsb and then drop it. I'm
hoping that happens this cycle, finally.

Cheers,

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

[OE-core] [PATCH v3] devtool: Fix build-sdk when pn doesn't match filename

[Paul Eggleton]

From: Randy Witt 

If an image with the filename foo.bb could be built using the name "bar"
instead, then build-sdk would fail to create the derivative sdk.

This was because the code assumed that the file name matched the target,
which is not necessarily the case.

Signed-off-by: Randy Witt 
Signed-off-by: Paul Eggleton 
---

Changes since v2:
 * Ensure we create the config section in ConfigHandler.set() if it
   doesn't already exist

 scripts/devtool|  5 +
 scripts/lib/devtool/build_image.py | 24 +++-
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/scripts/devtool b/scripts/devtool
index 4780390..9ac6e79 100755
--- a/scripts/devtool
+++ b/scripts/devtool
@@ -86,6 +86,11 @@ class ConfigHandler(object):
 with open(self.config_file, 'w') as f:
 self.config_obj.write(f)
 
+def set(self, section, option, value):
+if not self.config_obj.has_section(section):
+self.config_obj.add_section(section)
+self.config_obj.set(section, option, value)
+
 class Context:
 def __init__(self, **kwargs):
 self.__dict__.update(kwargs)
diff --git a/scripts/lib/devtool/build_image.py 
b/scripts/lib/devtool/build_image.py
index e51d766..1e5d09b 100644
--- a/scripts/lib/devtool/build_image.py
+++ b/scripts/lib/devtool/build_image.py
@@ -18,6 +18,7 @@
 """Devtool plugin containing the build-image subcommand."""
 
 import os
+import errno
 import logging
 
 from bb.process import ExecutionError
@@ -72,13 +73,17 @@ def build_image(args, config, basepath, workspace):
 return result
 
 def build_image_task(config, basepath, workspace, image, add_packages=None, 
task=None, extra_append=None):
-appendfile = os.path.join(config.workspace_path, 'appends',
-  '%s.bbappend' % image)
-
 # remove .bbappend to make sure setup_tinfoil doesn't
 # break because of it
-if os.path.isfile(appendfile):
-os.unlink(appendfile)
+target_basename = config.get('SDK', 'target_basename', '')
+if target_basename:
+appendfile = os.path.join(config.workspace_path, 'appends',
+  '%s.bbappend' % target_basename)
+try:
+os.unlink(appendfile)
+except OSError as exc:
+if exc.errno != errno.ENOENT:
+raise
 
 tinfoil = setup_tinfoil(basepath=basepath)
 rd = parse_recipe(config, tinfoil, image, True)
@@ -88,6 +93,15 @@ def build_image_task(config, basepath, workspace, image, 
add_packages=None, task
 if not bb.data.inherits_class('image', rd):
 raise TargetNotImageError()
 
+# Get the actual filename used and strip the .bb and full path
+target_basename = rd.getVar('FILE', True)
+target_basename = os.path.splitext(os.path.basename(target_basename))[0]
+config.set('SDK', 'target_basename', target_basename)
+config.write()
+
+appendfile = os.path.join(config.workspace_path, 'appends',
+  '%s.bbappend' % target_basename)
+
 outputdir = None
 try:
 if workspace or add_packages:
-- 
2.5.5

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

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

On Mon, May 9, 2016 at 3:34 PM, Christopher Larson 
wrote:

> On Mon, May 9, 2016 at 3:16 PM, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
>
>> On Mon, 2016-05-09 at 09:39 -0700, Christopher Larson wrote:
>> >
>> >
>> > On Mon, May 9, 2016 at 9:35 AM, Bystricky, Juro <
>> > juro.bystri...@intel.com> wrote:
>> > > Two additional GNU_HASH related errors were observed (breaking some
>> > > builds) that seem to be related to the patch:
>> > >
>> > > ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the
>> > > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
>> > > -non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48
>> > > -r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
>> > > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
>> > > -autobuilder/yocto-worker/nightly-non
>> > > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
>> > > -split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
>> > > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
>> > > -autobuilder/yocto-worker/nightly-non
>> > > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
>> > > -split/bash-ptest/usr/lib/bash/ptest/tests/printenv' [ldflags]
>> > > ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors.
>> > > Please consider fixing them.
>> > >
>> > >
>> > > ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
>> > > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
>> > > -qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1
>> > > -r0/packages-split/service/usr/sbin/skeleton-test' [ldflags]
>> > >
>> > Huh, I must not have had ptest enabled in my test builds. Thanks,
>> > will take a look.
>>
>> The above is an older gplv2 recipe failure which is probably why you
>> didn't see it.
>>
>> I'm afraid there were more. pseudo:
>>
>> https://autobuilder.yoctoproject.org/main/builders/build-appliance/buil
>> ds/747/steps/BuildImages_1/logs/stdio
>> 
>>
>> qt-x11-free:
>>
>> https://autobuilder.yoctoproject.or
>> g/main/builders/nightly-arm-lsb/builds/734/steps/BuildImages/logs/stdio
>> https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/buil
>> ds/744/steps/BuildImages/logs/stdio
>> 
>> https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/b
>> uilds/779/steps/BuildImages/logs/stdio
>> 
>>
>> service in qa-skeleton:
>>
>> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/
>> builds/753/steps/BuildImages/logs/stdio
>> 
>>
>> ruby and mkefiimage:
>>
>> https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/build
>> s/104/steps/BuildImages/logs/stdio
>> 
>>
>> (selftest also showed mkefimage failure)
>
>
> I'll take a look asap, unless someone else gets to it first. As mentioned,
> ruby, mkelfimage and one other were already on the list as of last thursday.
>

I have to say, I didn't realize oe-core patches require testing with
meta-qt3. I can't remember the last time I touched qt that old. I'll have
to add more non-core layers to my local testing in the future.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

On Mon, May 9, 2016 at 3:16 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Mon, 2016-05-09 at 09:39 -0700, Christopher Larson wrote:
> >
> >
> > On Mon, May 9, 2016 at 9:35 AM, Bystricky, Juro <
> > juro.bystri...@intel.com> wrote:
> > > Two additional GNU_HASH related errors were observed (breaking some
> > > builds) that seem to be related to the patch:
> > >
> > > ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the
> > > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
> > > -non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48
> > > -r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
> > > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
> > > -autobuilder/yocto-worker/nightly-non
> > > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
> > > -split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
> > > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
> > > -autobuilder/yocto-worker/nightly-non
> > > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
> > > -split/bash-ptest/usr/lib/bash/ptest/tests/printenv' [ldflags]
> > > ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors.
> > > Please consider fixing them.
> > >
> > >
> > > ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
> > > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
> > > -qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1
> > > -r0/packages-split/service/usr/sbin/skeleton-test' [ldflags]
> > >
> > Huh, I must not have had ptest enabled in my test builds. Thanks,
> > will take a look.
>
> The above is an older gplv2 recipe failure which is probably why you
> didn't see it.
>
> I'm afraid there were more. pseudo:
>
> https://autobuilder.yoctoproject.org/main/builders/build-appliance/buil
> ds/747/steps/BuildImages_1/logs/stdio
>
> qt-x11-free:
>
> https://autobuilder.yoctoproject.or
> g/main/builders/nightly-arm-lsb/builds/734/steps/BuildImages/logs/stdio
> https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/buil
> ds/744/steps/BuildImages/logs/stdio
> https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/b
> uilds/779/steps/BuildImages/logs/stdio
>
> service in qa-skeleton:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/
> builds/753/steps/BuildImages/logs/stdio
>
> ruby and mkefiimage:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/build
> s/104/steps/BuildImages/logs/stdio
>
> (selftest also showed mkefimage failure)


I'll take a look asap, unless someone else gets to it first. As mentioned,
ruby, mkelfimage and one other were already on the list as of last thursday.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 0/2] More reasonable LIC_FILES_CHKSUM enforcement

[Paul Eggleton]

Requiring every image recipe to set LIC_FILES_CHKSUM is a bit extreme. Here's
a better way to handle the check as well as a patch dropping LIC_FILES_CHKSUM
where it isn't needed afterwards.

Changes since v1:
* Preserve the LIC_FILES_CHKSUM value in wic-image-minimal since I missed
  that it does in fact have SRC_URI set.


The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:

  test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/lic-files-chksum
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/lic-files-chksum

Paul Eggleton (2):
  classes/insane: do not force LIC_FILES_CHKSUM unless SRC_URI is set
  Drop unneeded LIC_FILES_CHKSUM values

 meta-selftest/recipes-test/images/test-empty-image.bb | 1 -
 meta/classes/core-image.bbclass   | 3 ---
 meta/classes/insane.bbclass   | 6 +++---
 meta/classes/packagegroup.bbclass | 3 ---
 meta/recipes-core/meta/meta-world-pkgdata.bb  | 1 -
 meta/recipes-graphics/images/core-image-directfb.bb   | 4 
 6 files changed, 3 insertions(+), 15 deletions(-)

-- 
2.5.5

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

[OE-core] [PATCH v2 2/2] Drop unneeded LIC_FILES_CHKSUM values

[Paul Eggleton]

With the changes to insane.bbclass we don't need LIC_FILES_CHKSUM to be
set for recipes that don't actually pull in any source.

Signed-off-by: Paul Eggleton 
---
 meta-selftest/recipes-test/images/test-empty-image.bb | 1 -
 meta/classes/core-image.bbclass   | 3 ---
 meta/classes/packagegroup.bbclass | 3 ---
 meta/recipes-core/meta/meta-world-pkgdata.bb  | 1 -
 meta/recipes-graphics/images/core-image-directfb.bb   | 4 
 5 files changed, 12 deletions(-)

diff --git a/meta-selftest/recipes-test/images/test-empty-image.bb 
b/meta-selftest/recipes-test/images/test-empty-image.bb
index 7847f83..88d8d61 100644
--- a/meta-selftest/recipes-test/images/test-empty-image.bb
+++ b/meta-selftest/recipes-test/images/test-empty-image.bb
@@ -2,6 +2,5 @@ SUMMARY = "An empty image."
 IMAGE_INSTALL = ""
 IMAGE_LINGUAS = ""
 PACKAGE_INSTALL = ""
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
 inherit image
diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass
index 705cad8..8431440 100644
--- a/meta/classes/core-image.bbclass
+++ b/meta/classes/core-image.bbclass
@@ -2,9 +2,6 @@
 #
 # Copyright (C) 2007-2011 Linux Foundation
 
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
-
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-
 # IMAGE_FEATURES control content of the core reference images
 # 
 # By default we install packagegroup-core-boot and packagegroup-base-extended 
packages;
diff --git a/meta/classes/packagegroup.bbclass 
b/meta/classes/packagegroup.bbclass
index 3674894..3928c8a 100644
--- a/meta/classes/packagegroup.bbclass
+++ b/meta/classes/packagegroup.bbclass
@@ -15,9 +15,6 @@ PACKAGE_ARCH ?= "all"
 PACKAGE_ARCH_EXPANDED := "${PACKAGE_ARCH}"
 
 LICENSE ?= "MIT"
-LIC_FILES_CHKSUM ?= "${@oe.utils.ifelse(d.getVar('LICENSE', True) == 'MIT', \
- 
'file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420', \
-'')}"
 
 inherit ${@oe.utils.ifelse(d.getVar('PACKAGE_ARCH_EXPANDED', True) == 'all', 
'allarch', '')}
 
diff --git a/meta/recipes-core/meta/meta-world-pkgdata.bb 
b/meta/recipes-core/meta/meta-world-pkgdata.bb
index b3989cd..81c8647 100644
--- a/meta/recipes-core/meta/meta-world-pkgdata.bb
+++ b/meta/recipes-core/meta/meta-world-pkgdata.bb
@@ -1,6 +1,5 @@
 SUMMARY = "Pulls in pkgdata for world"
 LICENSE = "MIT"
-LIC_FILES_CHKSUM ?= 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
 INHIBIT_DEFAULT_DEPS = "1"
 
diff --git a/meta/recipes-graphics/images/core-image-directfb.bb 
b/meta/recipes-graphics/images/core-image-directfb.bb
index 5641195..c6ce658 100644
--- a/meta/recipes-graphics/images/core-image-directfb.bb
+++ b/meta/recipes-graphics/images/core-image-directfb.bb
@@ -1,10 +1,6 @@
 SUMMARY = "An image that uses DirectFB instead of X11"
 LICENSE = "MIT"
 
-
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
-
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-
 inherit core-image distro_features_check
 
 REQUIRED_DISTRO_FEATURES = "directfb"
-- 
2.5.5

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

[OE-core] [PATCH v2 1/2] classes/insane: do not force LIC_FILES_CHKSUM unless SRC_URI is set

[Paul Eggleton]

Recipes such as images and packagegroups don't actually fetch or build
any source, so there's really no point having LIC_FILES_CHKSUM set.
Forcing users to set it (as we have done for images inheriting
image.bbclass) just makes things more difficult for the user for no
discernable benefit. The easiest way to adjust this check is simply to
skip it if SRC_URI is not set since this is a pretty good indicator that
no source is being pulled in.

Signed-off-by: Paul Eggleton 
---
 meta/classes/insane.bbclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 097dc3a..0b151c2 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -681,15 +681,15 @@ python populate_lic_qa_checksum() {
 import tempfile
 sane = True
 
-lic_files = d.getVar('LIC_FILES_CHKSUM', True)
+lic_files = d.getVar('LIC_FILES_CHKSUM', True) or ''
 lic = d.getVar('LICENSE', True)
 pn = d.getVar('PN', True)
 
 if lic == "CLOSED":
 return
 
-if not lic_files:
-package_qa_handle_error("license-checksum", pn + ": Recipe file does 
not have license file information (LIC_FILES_CHKSUM)", d)
+if not lic_files and d.getVar('SRC_URI', True):
+package_qa_handle_error("license-checksum", pn + ": Recipe file 
fetches files and does not have license file information (LIC_FILES_CHKSUM)", d)
 return
 
 srcdir = d.getVar('S', True)
-- 
2.5.5

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

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Richard Purdie]

On Mon, 2016-05-09 at 09:39 -0700, Christopher Larson wrote:
> 
> 
> On Mon, May 9, 2016 at 9:35 AM, Bystricky, Juro <
> juro.bystri...@intel.com> wrote:
> > Two additional GNU_HASH related errors were observed (breaking some
> > builds) that seem to be related to the patch:
> >  
> > ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the
> > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
> > -non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48
> > -r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
> > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
> > -autobuilder/yocto-worker/nightly-non
> > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
> > -split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
> > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
> > -autobuilder/yocto-worker/nightly-non
> > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
> > -split/bash-ptest/usr/lib/bash/ptest/tests/printenv' [ldflags]
> > ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors.
> > Please consider fixing them.
> >  
> >  
> > ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
> > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
> > -qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1
> > -r0/packages-split/service/usr/sbin/skeleton-test' [ldflags]
> > 
> Huh, I must not have had ptest enabled in my test builds. Thanks,
> will take a look.

The above is an older gplv2 recipe failure which is probably why you
didn't see it.

I'm afraid there were more. pseudo:

https://autobuilder.yoctoproject.org/main/builders/build-appliance/buil
ds/747/steps/BuildImages_1/logs/stdio

qt-x11-free:

https://autobuilder.yoctoproject.or
g/main/builders/nightly-arm-lsb/builds/734/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/buil
ds/744/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/b
uilds/779/steps/BuildImages/logs/stdio

service in qa-skeleton:

https://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/
builds/753/steps/BuildImages/logs/stdio

ruby and mkefiimage:

https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/build
s/104/steps/BuildImages/logs/stdio

(selftest also showed mkefimage failure)

Cheers,

Richard

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

Re: [OE-core] [master][krogoth][PATCH 1/2] qemu: Security fix CVE-2016-2857

[akuster808]

On 5/6/16 8:51 AM, Alexander Kanavin wrote:
> On 05/06/2016 06:47 PM, akuster808 wrote:
>
>> I can not reproduce this issue. I have used two different build systems.
>> I have another I will try.
>>
>> so the testcase be?
>>
>> 1) bitbake core-image-sato
>> 2) runqemu qemux86
>
> 3) verify that you have a bunch of .gir and .typelib files on that
> image (or in target sysroot)

yeah. they are there. wonder how to reproduce this issue?? host os release??

- armin
>
>
> Alex
>

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

[OE-core] [master][krogoth][PATCH] gcc: backport gperf fixes

[Dan McGregor]

From: Daniel McGregor 

gperf was being used in a way that generated files don't conform to
the language standard. Backport the fix from upstream.

This is required to build these GCC versions when the host compiler
is GCC 6.

Signed-off-by: Daniel McGregor 
---
 meta/recipes-devtools/gcc/gcc-4.9.inc  |   1 +
 .../gcc/gcc-4.9/0075-remove-prototypes-cfns.patch  | 153 +
 meta/recipes-devtools/gcc/gcc-5.3.inc  |   1 +
 .../gcc/gcc-5.3/0059-remove-prototypes-cfns.patch  | 153 +
 4 files changed, 308 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-4.9/0075-remove-prototypes-cfns.patch
 create mode 100644 
meta/recipes-devtools/gcc/gcc-5.3/0059-remove-prototypes-cfns.patch

diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc 
b/meta/recipes-devtools/gcc/gcc-4.9.inc
index 7e03f31..2be0599 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -90,6 +90,7 @@ SRC_URI = "\
 file://0072-support-ffile-prefix-map.patch \
 file://0073-Reuse-fdebug-prefix-map-to-replace-ffile-prefix-map.patch \
 file://0074-fdebug-prefix-map-support-to-remap-relative-path.patch \
+file://0075-remove-prototypes-cfns.patch \
 "
 SRC_URI[md5sum] = "6f831b4d251872736e8e9cc09746f327"
 SRC_URI[sha256sum] = 
"2332b2a5a321b57508b9031354a8503af6fdfb868b8c1748d33028d100a8b67e"
diff --git 
a/meta/recipes-devtools/gcc/gcc-4.9/0075-remove-prototypes-cfns.patch 
b/meta/recipes-devtools/gcc/gcc-4.9/0075-remove-prototypes-cfns.patch
new file mode 100644
index 000..2954f2e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-4.9/0075-remove-prototypes-cfns.patch
@@ -0,0 +1,153 @@
+Upstream-Status: backport
+
+From 8c3fa311caa86f61b4e28d1563d1110b44340fb2 Mon Sep 17 00:00:00 2001
+From: edlinger 
+Date: Thu, 25 Feb 2016 15:36:41 +
+Subject: [PATCH] 2016-02-25  Bernd Edlinger  
+
+Backported from mainline
+2016-02-19  Jakub Jelinek  
+Bernd Edlinger  
+
+* Make-lang.in: Invoke gperf with -L C++.
+* cfns.gperf: Remove prototypes for hash and libc_name_p
+inlines.
+* cfns.h: Regenerated.
+* except.c (nothrow_libfn_p): Adjust.
+
+
+---
+ gcc/cp/Make-lang.in |  2 +-
+ gcc/cp/cfns.gperf   | 10 ++
+ gcc/cp/cfns.h   | 41 ++---
+ gcc/cp/except.c |  3 ++-
+ 5 files changed, 31 insertions(+), 37 deletions(-)
+
+diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
+index bd1c1d7..a0ea0d4 100644
+--- a/gcc/cp/Make-lang.in
 b/gcc/cp/Make-lang.in
+@@ -111,7 +111,7 @@ else
+ # deleting the $(srcdir)/cp/cfns.h file.
+ $(srcdir)/cp/cfns.h:
+ endif
+-  gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \
++  gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L C++ \
+   $(srcdir)/cp/cfns.gperf --output-file $(srcdir)/cp/cfns.h
+ 
+ #
+diff --git a/gcc/cp/cfns.gperf b/gcc/cp/cfns.gperf
+index 05ca753..d9b16b8 100644
+--- a/gcc/cp/cfns.gperf
 b/gcc/cp/cfns.gperf
+@@ -1,3 +1,5 @@
++%language=C++
++%define class-name libc_name
+ %{
+ /* Copyright (C) 2000-2014 Free Software Foundation, Inc.
+ 
+@@ -16,14 +18,6 @@ for more details.
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING3.  If not see
+ .  */
+-#ifdef __GNUC__
+-__inline
+-#endif
+-static unsigned int hash (const char *, unsigned int);
+-#ifdef __GNUC__
+-__inline
+-#endif
+-const char * libc_name_p (const char *, unsigned int);
+ %}
+ %%
+ # The standard C library functions, for feeding to gperf; the result is used
+diff --git a/gcc/cp/cfns.h b/gcc/cp/cfns.h
+index c845ddf..65801d1 100644
+--- a/gcc/cp/cfns.h
 b/gcc/cp/cfns.h
+@@ -1,5 +1,5 @@
+-/* ANSI-C code produced by gperf version 3.0.3 */
+-/* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L ANSI-C 
cfns.gperf  */
++/* C++ code produced by gperf version 3.0.4 */
++/* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L C++ 
--output-file cfns.h cfns.gperf  */
+ 
+ #if !((' ' == 32) && ('!' == 33) && ('"' == 34) && ('#' == 35) \
+   && ('%' == 37) && ('&' == 38) && ('\'' == 39) && ('(' == 40) \
+@@ -28,7 +28,7 @@
+ #error "gperf generated tables don't work with this execution character set. 
Please report a bug to ."
+ #endif
+ 
+-#line 1 "cfns.gperf"
++#line 3 "cfns.gperf"
+ 
+ /* Copyright (C) 2000-2014 Free Software Foundation, Inc.
+ 
+@@ -47,25 +47,18 @@ for more details.
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING3.  If not see
+ .  */
+-#ifdef __GNUC__
+-__inline
+-#endif
+-static unsigned int hash (const char *, unsigned int);
+-#ifdef 

Re: [OE-core] [RFC PATCH 1/6] classes/kernel-check: add a class to check kernel config options

[Bruce Ashfield]

On Mon, May 9, 2016 at 4:53 PM, Paul Eggleton  wrote:

> On Mon, 09 May 2016 07:59:43 Bruce Ashfield wrote:
> > On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> > paul.eggle...@linux.intel.com> wrote:
> > > Some user-space software has specific requirements about the kernel
> > > configuration options selected. This class allows a recipe to
> explicitly
> > > state the kernel configuration options it needs (through a
> > > REQUIRED_KERNEL_OPTIONS variable). This is a space separated list,
> where
> > >
> > > each item is one of:
> > >   (a) an option name (e.g. CONFIG_FHANDLE, in which case CONFIG_FHANDLE
> > >
> > >   must be set to y or m to match)
> > >
> > >   (b) optionname=value (e.g. CONFIG_FHANDLE=y, in which case
> > >
> > >   CONFIG_FHANDLE must be set to y). If the specified value is n,
> > >   it will also match if the option is not present.
> > >
> > >   (c) optionname1|optionname2|... (e.g.
> > >
> > >   CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23, meaning that either
> > >   CONFIG_EXT2_FS or CONFIG_EXT4_USE_FOR_EXT23 must be set to y or
> > >   m to match).
> >
> > This duplicates code that is already in the kconf_check routines, which
> > I've already made generic (and added dependency information) for the 2.2
> > release ... so call me confused that I've never heard about this until
> now
> > :(
>
> I guess I didn't look hard enough, I'll have to take a look at that. This
> is
> why the series is RFC (and I included you on CC ;)
>

Noted :) I read the patches before the 0/N .. and it was Monday morning
before coffee.

Don't look TOO closely as your eyes will bleed, but the basics are there.
My recent
work has been to clean it up so I can apply it to an arbitrary kernel.

Bruce


>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>



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

Re: [OE-core] [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Bruce Ashfield]

On Mon, May 9, 2016 at 4:45 PM, Paul Eggleton  wrote:

> Hi Bruce,
>
> On Mon, 09 May 2016 08:05:06 Bruce Ashfield wrote:
> > On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> > paul.eggle...@linux.intel.com> wrote:
> > > A lot of the IMAGE_FSTYPES items require the appropriate filesystem
> > > driver to be enabled in the kernel configuration; e.g. in order to read
> > > a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
> > > to ensure that is the case.
> >
> > So what's the overall design for this ? Is it documented anywhere ? This
> is
> > something that we talked about a couple of years and I have reservations
> and
> > objections to the current implementation.
> >
> > .. but since I can only see bits and chunks of patches, I'd rather read
> > something complete and offer some more detailed feedback.
> >
> > Bottom line: I see a slippery slope to tightly specified option that
> depend
> > on kernel versions, I see kernel options sprayed all over layers, etc,
> etc.
> > Which is exactly what we've been trying to avoid with the centralized
> kernel
> > meta-data, and again, there's a mechanism that I finished early this
> year to
> > extend those options to any kernel, enforce, warn, error, etc .. but now,
> > I'll just toss it into the bin.
>
> There's no design written out beyond what you see in the associated bug:
>
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=5574
>
> The situation I am trying to avoid is the exact one mentioned by a
> commenter
> on that bug - which is that if I build my rootfs in a particular way, and
> couple it with a particular kernel configuration, I want the build system
> to
> tell me if those are going to be incompatible. The current situation where
> the
> you don't find out until the system doesn't boot (and you may not get any
> meaningful error message at that point anyway) isn't great.
>
> You mention hardware in your reply to Chris, but this mostly isn't about
> hardware - it's about dependencies on software features of the kernel from
>

I only brought up h/w to point out the slippery slope, and that if you are
going to
solve one class of options, eventually it will lead to someone asking for
others
and then the ability to set them. We then have a tight binding and
distributed
knowledge of the kernel specifics.


> userspace. I'm perfectly happy if we go for alternative solution, but to my
> mind whatever solution we come up with needs to be something whereby if you
> enable something in userspace that the kernel as currently configured isn't
> going to be able to support, you at least get a warning at build time.
>

What you describe is almost exactly what KERNEL_FEATURES + the existing
Kconfig
audit does. That mechanism does the audit for software and h/w features via
a level
of abstraction (the name of the feature, versus the kernel options
themselves).

I'm about 75% of the way to extended that to any kernel (not just
linux-yocto) and
exposing the "required" and "optional" kconfig support (that has been
around for
about 1.5 years .. just no one has asked for it :D

That's why I'm trying to understand what exactly is missing and is being
solved
here, so I can decide whether to drop my changes or not.

Bruce


>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>



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

Re: [OE-core] [RFC PATCH 0/6] Kernel configuration check for recipes

[Paul Eggleton]

On Mon, 09 May 2016 08:08:55 Bruce Ashfield wrote:
> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> 
> paul.eggle...@linux.intel.com> wrote:
> > Add the capability for other recipes to verify that kernel
> > configuration options they depend upon at runtime are present, and warn
> > if they are missing. This seems functional enough to me but is still in
> > RFC - please let me know if it looks OK to you or I've missed anything
> > (no doubt there are recipes we could add the checks to, I refer mainly
> > to the mechanism itself).
> > 
> > 
> > Please review the following changes for suitability for inclusion. If you
> > have
> > any objections or suggestions for improvement, please respond to the
> > patches. If
> > you agree with the changes, please provide your Acked-by.
> 
> See my replies to the patches. I'm sure it won't matter in the end, but
> this is a duplication of the mechanisms that we already have in the kernel
> config check phase. I have a whole set of changes that I completed early
> this year that extends that mechanism to any kernel (not just kernel-yocto)
> classes. In that mechanism there's the concept of "required" and
> "optional" Kconfig options. If they aren't present in the final .config, we
> warn and optionally error (this is versus the currently mechanism of only
> warning if boot critical options are dropped).

OK - so I guess this gets down to the question of whether we can practically 
define all of these userspace dependencies on the kernel side rather than 
individual recipes. I actually couldn't tell you how many other recipes this 
might be useful in - systemd and udev are where it's come up numerous times 
for users, and IMAGE_FSTYPES was one that I could think of. Perhaps we ought 
to analyse that in greater detail before proceeding.

> I'm betting that the follow on to this series will be "Hey recipes should
> set the options for the kernel if they really need them" .. which IMHO is an
> incredibly bad idea.

We'll never be getting to that level. Fundamentally one recipe cannot 
influence the configuration of another, at least not directly, and I agree in 
this case it wouldn't make any sense. I'm just proposing a check here.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 1/6] classes/kernel-check: add a class to check kernel config options

[Paul Eggleton]

On Mon, 09 May 2016 07:59:43 Bruce Ashfield wrote:
> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
> > Some user-space software has specific requirements about the kernel
> > configuration options selected. This class allows a recipe to explicitly
> > state the kernel configuration options it needs (through a
> > REQUIRED_KERNEL_OPTIONS variable). This is a space separated list, where
> > 
> > each item is one of:
> >   (a) an option name (e.g. CONFIG_FHANDLE, in which case CONFIG_FHANDLE
> >   
> >   must be set to y or m to match)
> >   
> >   (b) optionname=value (e.g. CONFIG_FHANDLE=y, in which case
> >   
> >   CONFIG_FHANDLE must be set to y). If the specified value is n,
> >   it will also match if the option is not present.
> >   
> >   (c) optionname1|optionname2|... (e.g.
> >   
> >   CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23, meaning that either
> >   CONFIG_EXT2_FS or CONFIG_EXT4_USE_FOR_EXT23 must be set to y or
> >   m to match).
> 
> This duplicates code that is already in the kconf_check routines, which
> I've already made generic (and added dependency information) for the 2.2
> release ... so call me confused that I've never heard about this until now 
> :(

I guess I didn't look hard enough, I'll have to take a look at that. This is 
why the series is RFC (and I included you on CC ;)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Paul Eggleton]

Hi Bruce,

On Mon, 09 May 2016 08:05:06 Bruce Ashfield wrote:
> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
> > A lot of the IMAGE_FSTYPES items require the appropriate filesystem
> > driver to be enabled in the kernel configuration; e.g. in order to read
> > a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
> > to ensure that is the case.
> 
> So what's the overall design for this ? Is it documented anywhere ? This is
> something that we talked about a couple of years and I have reservations and
> objections to the current implementation.
> 
> .. but since I can only see bits and chunks of patches, I'd rather read
> something complete and offer some more detailed feedback.
> 
> Bottom line: I see a slippery slope to tightly specified option that depend
> on kernel versions, I see kernel options sprayed all over layers, etc, etc.
> Which is exactly what we've been trying to avoid with the centralized kernel
> meta-data, and again, there's a mechanism that I finished early this year to
> extend those options to any kernel, enforce, warn, error, etc .. but now,
> I'll just toss it into the bin.

There's no design written out beyond what you see in the associated bug:

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

The situation I am trying to avoid is the exact one mentioned by a commenter 
on that bug - which is that if I build my rootfs in a particular way, and 
couple it with a particular kernel configuration, I want the build system to 
tell me if those are going to be incompatible. The current situation where the 
you don't find out until the system doesn't boot (and you may not get any 
meaningful error message at that point anyway) isn't great.

You mention hardware in your reply to Chris, but this mostly isn't about 
hardware - it's about dependencies on software features of the kernel from 
userspace. I'm perfectly happy if we go for alternative solution, but to my 
mind whatever solution we come up with needs to be something whereby if you 
enable something in userspace that the kernel as currently configured isn't 
going to be able to support, you at least get a warning at build time.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] mesa-demos: OpenVG demos with single frame need eglSwapBuffer

[Tom Hochstein]

sp and text demos rendering single frame. to display the
single frame rendered needed a eglSwapBuffer to diplay to window.
Hence added eglutPostRedisplay to display the frame.

Signed-off-by: Tom Hochstein 
---
 ...OpenVG-demos-with-single-frame-need-eglSw.patch | 44 ++
 meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb |  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 
meta/recipes-graphics/mesa/mesa-demos/0012-mesa-demos-OpenVG-demos-with-single-frame-need-eglSw.patch

diff --git 
a/meta/recipes-graphics/mesa/mesa-demos/0012-mesa-demos-OpenVG-demos-with-single-frame-need-eglSw.patch
 
b/meta/recipes-graphics/mesa/mesa-demos/0012-mesa-demos-OpenVG-demos-with-single-frame-need-eglSw.patch
new file mode 100644
index 000..0fae9ca
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/mesa-demos/0012-mesa-demos-OpenVG-demos-with-single-frame-need-eglSw.patch
@@ -0,0 +1,44 @@
+From 3aa84c47e88a4c38446ce1323abf6f2c77389104 Mon Sep 17 00:00:00 2001
+From: Prabhu 
+Date: Mon, 16 Nov 2015 17:09:32 -0600
+Subject: [PATCH] mesa-demos: OpenVG demos with single frame need eglSwapBuffer
+
+sp and text demos rendering single frame. to display the
+single frame rendered needed a eglSwapBuffer to diplay to window.
+Hence added eglutPostRedisplay to display the frame
+
+Upstream status: Pending
+
+Signed-off-by: Prabhu 
+---
+ src/egl/openvg/sp.c   | 1 +
+ src/egl/openvg/text.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/src/egl/openvg/sp.c b/src/egl/openvg/sp.c
+index a20c0a3..468e91e 100644
+--- a/src/egl/openvg/sp.c
 b/src/egl/openvg/sp.c
+@@ -500,6 +500,7 @@ draw(void)
+}
+ 
+vgFlush();
++   eglutPostRedisplay();
+ }
+ 
+ 
+diff --git a/src/egl/openvg/text.c b/src/egl/openvg/text.c
+index f5c6de8..492581c 100644
+--- a/src/egl/openvg/text.c
 b/src/egl/openvg/text.c
+@@ -360,6 +360,7 @@ display(void)
+ {
+vgClear(0, 0, width, height);
+glyph_string_draw(10.0, 10.0);
++   eglutPostRedisplay();
+ }
+ 
+ 
+-- 
+2.5.1
+
diff --git a/meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb 
b/meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb
index 2df9bba..034e01d 100644
--- a/meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb
+++ b/meta/recipes-graphics/mesa/mesa-demos_8.2.0.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"ftp://ftp.freedesktop.org/pub/mesa/demos/${PV}/${BPN}-${PV}.tar.bz2 \
 file://0009-glsl-perf-Install-.glsl-.vert-.frag-files.patch \
 file://0010-sharedtex_mt-fix-rendering-thread-hang.patch \
 file://0011-drop-demos-dependant-on-obsolete-MESA_screen_surface.patch \
+file://0012-mesa-demos-OpenVG-demos-with-single-frame-need-eglSw.patch \
 "
 SRC_URI[md5sum] = "72613a2c8c013716db02e3ff59d29061"
 SRC_URI[sha256sum] = 
"e4bfecb5816ddd4b7b37c1bc876b63f1f7f06fda5879221a9774d0952f90ba92"
-- 
1.9.1

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

Re: [OE-core] [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Bruce Ashfield]

On Mon, May 9, 2016 at 12:57 PM, Christopher Larson 
wrote:

>
> On Mon, May 9, 2016 at 5:05 AM, Bruce Ashfield 
> wrote:
>
>> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
>> paul.eggle...@linux.intel.com> wrote:
>>
>>> A lot of the IMAGE_FSTYPES items require the appropriate filesystem
>>> driver to be enabled in the kernel configuration; e.g. in order to read
>>> a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
>>> to ensure that is the case.
>>>
>>
>>
>> So what's the overall design for this ? Is it documented anywhere ? This
>> is something
>> that we talked about a couple of years and I have reservations and
>> objections to
>> the current implementation.
>>
>> .. but since I can only see bits and chunks of patches, I'd rather read
>> something
>> complete and offer some more detailed feedback.
>>
>> Bottom line: I see a slippery slope to tightly specified option that
>> depend on kernel
>> versions, I see kernel options sprayed all over layers, etc, etc. Which
>> is exactly
>> what we've been trying to avoid with the centralized kernel meta-data,
>> and again,
>> there's a mechanism that I finished early this year to extend those
>> options to any
>> kernel, enforce, warn, error, etc .. but now, I'll just toss it into the
>> bin.
>>
>
> Perhaps this functionality should be by feature or capability rather than
> individual options, and let the kernel build determine what features it
> provides based on its configuration.
>

You hit the nail on the head with that comment. There are some old bugzilla
lurking around
about distro -> kernel options (aka kernel features) that I've suggested a
similar concept
(or even machine features -> kernel).

IMHO some level of abstraction is needed for both, since otherwise we end
up tightly
coupling recipes to a machine and kernel combination.

Someone can ask for a specific option all they like, but unless they know
the details
of the kernel provider .. they are basically making a guess, and someone
working with
many different types of recipes shouldn't have to know the details of every
kernel tree
they are building. Sure it isn't widespread, or a lot of recipes, but again
.. I see a slippery
slope.

In the case kernel doesn't have it they fail (or if they've specified
something wrong), but
there are often substitutions that can be performed .. or optional
features, etc.  If there's some
level of abstraction, the kernel provider itself can turn on the right
options, avoid common / minor
errors, make suggestions and ensure that the h/w (and kernel) actually has
the capability.

The h/w actually having the capability is a significant issue for me as
well, since asking for
something .. but not actually having the required h/w (or arch) support,
and having no way
to abstractly figure out if something is supported .. means that even more
knowledge of
the kernel and the machine starts slipping into recipes and ends up being
spread all around
the layer stack.

Cheers,

Bruce




>
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>



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

Re: [OE-core] [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Christopher Larson]

On Mon, May 9, 2016 at 5:05 AM, Bruce Ashfield 
wrote:

> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
>
>> A lot of the IMAGE_FSTYPES items require the appropriate filesystem
>> driver to be enabled in the kernel configuration; e.g. in order to read
>> a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
>> to ensure that is the case.
>>
>
>
> So what's the overall design for this ? Is it documented anywhere ? This
> is something
> that we talked about a couple of years and I have reservations and
> objections to
> the current implementation.
>
> .. but since I can only see bits and chunks of patches, I'd rather read
> something
> complete and offer some more detailed feedback.
>
> Bottom line: I see a slippery slope to tightly specified option that
> depend on kernel
> versions, I see kernel options sprayed all over layers, etc, etc. Which is
> exactly
> what we've been trying to avoid with the centralized kernel meta-data, and
> again,
> there's a mechanism that I finished early this year to extend those
> options to any
> kernel, enforce, warn, error, etc .. but now, I'll just toss it into the
> bin.
>

Perhaps this functionality should be by feature or capability rather than
individual options, and let the kernel build determine what features it
provides based on its configuration.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] distro_check: Allows to use proxy vars of OS env

[edwin . plauchu . camacho]

From: Edwin Plauchu 

This improve allows to fetch values from OS env. Covering an scenario where 
proxy variables have no value within data storage.

Signed-off-by: Edwin Plauchu 
---
 meta/lib/oe/distro_check.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/distro_check.py b/meta/lib/oe/distro_check.py
index 8655a6f..6e87323 100644
--- a/meta/lib/oe/distro_check.py
+++ b/meta/lib/oe/distro_check.py
@@ -11,7 +11,7 @@ def create_socket(url, d):
 def get_proxies(d):
 proxies = {}
 for key in ['http', 'https', 'ftp', 'ftps', 'no', 'all']:
-proxy = d.getVar(key + '_proxy', True)
+proxy = os.environ.get( key + '_proxy' ) or d.getVar(key + '_proxy', 
True)
 if proxy:
 proxies[key] = proxy
 return proxies
-- 
1.9.1

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

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

On Mon, May 9, 2016 at 9:35 AM, Bystricky, Juro 
wrote:

> Two additional GNU_HASH related errors were observed (breaking some
> builds) that seem to be related to the patch:
>
>
>
> ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the elf
> binary:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
>
> No GNU_HASH in the elf binary:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
>
> No GNU_HASH in the elf binary:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/printenv'
> [ldflags]
>
> ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors. Please
> consider fixing them.
>
>
>
>
>
> ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the elf
> binary:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1-r0/packages-split/service/usr/sbin/skeleton-test'
> [ldflags]
>

Huh, I must not have had ptest enabled in my test builds. Thanks, will take
a look.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Bystricky, Juro]

Two additional GNU_HASH related errors were observed (breaking some builds) 
that seem to be related to the patch:

ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
No GNU_HASH in the elf binary: 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
No GNU_HASH in the elf binary: 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/printenv'
 [ldflags]
ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors. Please 
consider fixing them.


ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1-r0/packages-split/service/usr/sbin/skeleton-test'
 [ldflags]

Juro



From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of 
Christopher Larson
Sent: Wednesday, May 4, 2016 12:11 PM
To: Burton, Ross 
Cc: OE-core 
Subject: Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove 
--with-linker-hash-style



On Wed, May 4, 2016 at 2:01 PM, Burton, Ross 
> wrote:

On 2 May 2016 at 21:09, Christopher Larson 
> wrote:
This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
which is what's often seen with external toolchains. This brings us all on the
same page, and makes sure a failure to obey LDFLAGS is seen early.

I love the idea, but:

ERROR: libgcc-5.3.0-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 
'/data/poky-master/tmp-glibc/work/corei7-64-poky-linux/libgcc/5.3.0-r0/packages-split/libgcc/lib/libgcc_s.so.1'
 [ldflags]

Ross

No idea how I missed this, since I did test builds, but I'll submit a patch to 
oe-core shortly. Thanks :)
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] Allows to use proxy vars of OS env

[edwin . plauchu . camacho]

From: Edwin Plauchu 

This improve allows to fetch values from OS env. Covering an scenario where 
proxy variables have no value within data storage.
---
 meta/lib/oe/distro_check.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/distro_check.py b/meta/lib/oe/distro_check.py
index 8655a6f..6e87323 100644
--- a/meta/lib/oe/distro_check.py
+++ b/meta/lib/oe/distro_check.py
@@ -11,7 +11,7 @@ def create_socket(url, d):
 def get_proxies(d):
 proxies = {}
 for key in ['http', 'https', 'ftp', 'ftps', 'no', 'all']:
-proxy = d.getVar(key + '_proxy', True)
+proxy = os.environ.get( key + '_proxy' ) or d.getVar(key + '_proxy', 
True)
 if proxy:
 proxies[key] = proxy
 return proxies
-- 
1.9.1

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

[OE-core] OE Changelog since 2016-05-01 until 2016-05-08

[cliff . brake]

Changelog since 2016-05-01 until 2016-05-08.  Projects included in this report:

bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-angstrom: git://github.com/Angstrom-distribution/meta-angstrom.git
meta-arago: git://arago-project.org/git/meta-arago.git
meta-atmel: https://github.com/linux4sam/meta-atmel.git
meta-beagleboard: git://github.com/beagleboard/meta-beagleboard.git
meta-browser: git://github.com/OSSystems/meta-browser.git
meta-bug: git://github.com/buglabs/meta-bug.git
meta-chicken: git://github.com/OSSystems/meta-chicken
meta-efikamx: git://github.com/kraj/meta-efikamx.git
meta-ettus: http://github.com/koenkooi/meta-ettus.git
meta-fsl-arm: git://git.yoctoproject.org/meta-fsl-arm
meta-fsl-arm-extra: git://github.com/Freescale/meta-fsl-arm-extra.git
meta-fsl-ppc: git://git.yoctoproject.org/meta-fsl-ppc
meta-guacamayo: git://github.com/Guacamayo/meta-guacamayo.git
meta-gumstix: git://github.com/gumstix/meta-gumstix.git
meta-gumstix-community: 
https://github.com/schnitzeltony/meta-gumstix-community.git
meta-handheld: git://git.openembedded.org/meta-handheld
meta-igep: http://github.com/ebutera/meta-igep.git
meta-intel: git://git.yoctoproject.org/meta-intel
meta-ivi: git://git.yoctoproject.org/meta-ivi
meta-java: git://github.com/woglinde/meta-java
meta-jetson-tk1: https://github.com/cubicool/meta-jetson-tk1.git
meta-kde: git://gitorious.org/openembedded-core-layers/meta-kde.git
meta-micro: git://git.openembedded.org/meta-micro
meta-mono: git://git.yoctoproject.org/meta-mono.git
meta-netbookpro: git://github.com/tworaz/meta-netbookpro
meta-nodejs: https://github.com/imyller/meta-nodejs.git
meta-nslu2: git://github.com/kraj/meta-nslu2
meta-opie: git://git.openembedded.org/meta-opie
meta-qt3: git://git.yoctoproject.org/meta-qt3
meta-qt5: git://github.com/meta-qt5/meta-qt5.git
meta-slugos: git://github.com/kraj/meta-slugos
meta-systemd: git://git.yoctoproject.org/meta-systemd
meta-raspberrypi: git://github.com/djwillis/meta-raspberrypi.git
meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git
meta-ti: git://git.yoctoproject.org/meta-ti
meta-webos: git://github.com/openwebos/meta-webos.git
meta-xilinx: git://git.yoctoproject.org/meta-xilinx
meta-yocto: git://git.yoctoproject.org/meta-yocto
openembedded: git://git.openembedded.org/openembedded


Changelog for bitbake:

Christopher Larson (7):
  bb.build: handle __builtins__ as a module
  bb.event: handle __builtins__ as a module
  bb.data_smart: use iter() for __len__
  bb.utils: add load_plugins from scriptutils
  bb.utils: use imp.get_suffixes for load_plugins
  bb.utils: let loaded plugins provide a plugin object
  bb.{cooker, data}: only emit a var as python if 'func' is set

Leonardo Sandoval (1):
  bitbake: fetch2: Safer check for BB_ORIGENV datastore


Changelog for openembedded-core:

Alexander Kanavin (1):
  arch-powerpc64.inc: disable the use of qemu usermode on ppc64

André Draszik (1):
  tune-mips32r2.inc: add soft-float variants

Awais Belal (1):
  mesa-demos: remove demos using obsolete screen surface

Carlos Rafael Giani (3):
  gstreamer1.0-plugins-ugly: upgrade to version 1.8.1
  gstreamer1.0-libav: upgrade to version 1.8.1
  gstreamer1.0-rtsp-server: upgrade to version 1.8.1

Christopher Larson (5):
  scripts/lib/argparse_oe: show self.prog in the error message
  scripts/lib/argparse_oe: show subparser help for unrecognized args
  scripts/lib/argparse_oe: simplify options title change
  scripts/lib/argparse_oe: also change 'positional arguments' to 'arguments'
  ddimage: if 'pv' is installed, use it

Denys Dmytriyenko (1):
  arch-armv7ve: inherit armv7a tunes file

Ed Bartosh (8):
  wic: use truncate utility to create sparse files
  wic: get rid of inheritance Disk->DiskImage
  wic: get rid of fs_related.makedirs
  wic: moved DiskImage to direct.py
  wic: add FIEMAP and SEEK_HOLE / SEEK_DATA APIs
  wic: add sparse_copy API
  wic: use sparse_copy to copy partitions
  wic: use sparse_copy to preserve sparseness

Joshua Lock (2):
  security_flags: turn potential string format security issues into an error
  packagegroup-core-lsb: fix whitespace in meta-qt* warnings

Maxin B. John (3):
  popt: fix dependencies and QA Issue
  bash: fix dependencies and QA Issue
  libxml2: fix dependencies and QA Issues

Paul Eggleton (2):
  recipetool: create: fix picking up false npm package directories
  recipetool: create: fix falling back to declared license for npm packages

Richard Purdie (2):
  meta-selftest/images: Add LIC_FILES_CHKSUM to images using image.bbclass
  test-empty-image: Fix LIC_FILES_CHKSUM typo

Robert Yang (6):
  insane.bbclass: remove workdir from package_qa_check_license()
  insane.bbclass: package_qa_check_license -> populate_lic_qa_checksum
  packagegroup.bbclass: set LICENSE and 

[OE-core] [PATCH] lib/classextend: Fix determinism issue

[Richard Purdie]

The ordering of dependency variables needs to be deterministic to avoid task 
checksums
changing. Use an OrderedDict to achieve this.

Signed-off-by: Richard Purdie 

diff --git a/meta/lib/oe/classextend.py b/meta/lib/oe/classextend.py
index 5107ecd..4c8a000 100644
--- a/meta/lib/oe/classextend.py
+++ b/meta/lib/oe/classextend.py
@@ -1,3 +1,5 @@
+import collections
+
 class ClassExtender(object):
 def __init__(self, extname, d):
 self.extname = extname
@@ -77,7 +79,7 @@ class ClassExtender(object):
 self.d.setVar("EXTENDPKGV", orig)
 return
 deps = bb.utils.explode_dep_versions2(deps)
-newdeps = {}
+newdeps = collections.OrderedDict()
 for dep in deps:
 newdeps[self.map_depends(dep)] = deps[dep]
 


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

[OE-core] [PATCH] update-alternatives: Fix determinism issue

[Richard Purdie]

getVarFlags returns a dict and there is therefore no sort order. This
means the order of the X_VARDEPS_X variables can change and hence the 
task checksums can change. This can lead to rebuilds of any parts of 
the system using update-alternatives and their dependees. This is a
particular issue under python v3.

Add in a sort to make the order of the variables deterministic.

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/update-alternatives.bbclass 
b/meta/classes/update-alternatives.bbclass
index 70a8185..1fdd681 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -71,14 +71,14 @@ def gen_updatealternativesvardeps(d):
 
 # First compute them for non_pkg versions
 for v in vars:
-for flag in (d.getVarFlags(v) or {}):
+for flag in sorted((d.getVarFlags(v) or {}).keys()):
 if flag == "doc" or flag == "vardeps" or flag == "vardepsexp":
 continue
 d.appendVar('%s_VARDEPS' % (v), ' %s:%s' % (flag, d.getVarFlag(v, 
flag, False)))
 
 for p in pkgs:
 for v in vars:
-for flag in (d.getVarFlags("%s_%s" % (v,p)) or {}):
+for flag in sorted((d.getVarFlags("%s_%s" % (v,p)) or {}).keys()):
 if flag == "doc" or flag == "vardeps" or flag == "vardepsexp":
 continue
 d.appendVar('%s_VARDEPS_%s' % (v,p), ' %s:%s' % (flag, 
d.getVarFlag('%s_%s' % (v,p), flag, False)))
-- 
cgit v0.10.2

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

[OE-core] [PATCH] image: Fix IMAGE_FEATURES determinism issue

[Richard Purdie]

remain_features uses a dict which means the order is not deterministic. This
can lead to the task hash changing depending on the state of the memory at
parse time. This is particularly noticeable under python v3.

Since the dict is helpful in constructing the data, pass the data through 
sort() so the order is always deterministic.

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 1fb1964..a1772ad 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -166,7 +166,7 @@ python () {
 if temp:
 bb.fatal("%s contains conflicting IMAGE_FEATURES %s %s" % 
(d.getVar('PN', True), feature, ' '.join(list(temp
 
-d.setVar('IMAGE_FEATURES', ' '.join(list(remain_features)))
+d.setVar('IMAGE_FEATURES', ' '.join(sorted(list(remain_features
 
 check_image_features(d)
 initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or ""


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

Re: [OE-core] should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

[Robert P. J. Day]

On Mon, 9 May 2016, Bruce Ashfield wrote:

>
>
> On Mon, May 9, 2016 at 6:39 AM, Robert P. J. Day  
> wrote:
>
>     (aside: this is with wind river linux 8 and i dropped bruce a note
>   about it, but i really should keep this stuff on the mailing list.)
>
>     not sure if this is a WRL issue, or more general OE or YP issue, but
>   i was doing a kernel config yesterday, and my SRC_URI included, say,
>   "rday.scc", which incorporated both kernel config fragments and
>   patches, and that worked fine.
>
>     eventually, after massive refactoring, all that was left of that
>   item was some kernel configuration which was already in "rday.cfg", so
>   i edited SRC_URI and replaced "rday.scc" with "rday.cfg", but i left
>   that old "rday.scc" in that directory (with its referent patches),
>   assuming it would be ignored.
>
>     did a clean and configure and got:
>
>     | DEBUG: Executing shell function do_kernel_metadata
>   | ERROR: could not find patch rday.patch, included from
>   .../rday.scc ...
>
>     it *appears* that, even though SRC_URI now refers to (among other
>   things) just "rday.cfg", it looks like the configure step is *still*
>   trying to process "rday.scc", which contains a reference to a now
>   non-existent patch, hence the failure.
>
>     if i just remove (or rename) "rday.scc", then things work fine. is
>   this expected behaviour? is there some reason that if SRC_URI
>   includes, say "derf.cfg", the configuration will automatically look
>   for and try to process "derf.scc"? or am i just doing something silly?
>
>
> There's no automatic inclusions like that. Take a look at your
> meta-series and see if there's an explicit reference to the .scc
> file.
>
> Otherwise, I'll have to try and reproduce it here.

  i suspect it's some remnant of an older configure that's still
hiding somewhere. i'll try to reproduce it, but i'm guessing if i
totally blew away my project directory and tried again, it would work.

  still, shouldn't doing a "clean" step on the kernel target get rid
of remnants like that?

rday

-- 


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

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/6] [jethro] Consolidated pull

[Robert Yang]

ping.

On 04/25/2016 09:10 AM, Robert Yang wrote:

The following changes since commit 28032d8c3122b75ceb3f4a664a2b478c9a9a6a2c:

   tzcode: update to 2016c (2016-04-11 22:03:01 +0100)

are available in the git repository at:

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

Armin Kuster (2):
   tzcode: update to 2016d
   tzdata: update to 2016d

Bjørn Forsman (1):
   license.bbclass: fix warnings when run in unprivileged "container" env

Robert Yang (1):
   boot-directdisk.bbclass: remove HDDIMG before create

Sona Sarmadi (1):
   bind: CVE-2016-1285 CVE-2016-1286

Stefan Agner (1):
   opkg: backport fix for double remove of packges

  meta/classes/boot-directdisk.bbclass   |   2 +
  meta/classes/license.bbclass   |   8 +-
  .../bind/bind/CVE-2016-1285.patch  | 138 +
  .../bind/bind/CVE-2016-1286_1.patch|  79 +
  .../bind/bind/CVE-2016-1286_2.patch| 318 +
  meta/recipes-connectivity/bind/bind_9.10.2-P4.bb   |   3 +
  ...vider_replacees-do-not-add-installed-pkg-.patch | 112 
  meta/recipes-devtools/opkg/opkg_0.3.0.bb   |   1 +
  ...code-native_2016c.bb => tzcode-native_2016d.bb} |   8 +-
  .../tzdata/{tzdata_2016c.bb => tzdata_2016d.bb}|   4 +-
  10 files changed, 664 insertions(+), 9 deletions(-)
  create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2016-1285.patch
  create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2016-1286_1.patch
  create mode 100644 meta/recipes-connectivity/bind/bind/CVE-2016-1286_2.patch
  create mode 100644 
meta/recipes-devtools/opkg/opkg/0001-pkg_get_provider_replacees-do-not-add-installed-pkg-.patch
  rename meta/recipes-extended/tzcode/{tzcode-native_2016c.bb => 
tzcode-native_2016d.bb} (68%)
  rename meta/recipes-extended/tzdata/{tzdata_2016c.bb => tzdata_2016d.bb} (98%)


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

Re: [OE-core] should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

[Bruce Ashfield]

On Mon, May 9, 2016 at 6:39 AM, Robert P. J. Day 
wrote:

>
>   (aside: this is with wind river linux 8 and i dropped bruce a note
> about it, but i really should keep this stuff on the mailing list.)
>
>   not sure if this is a WRL issue, or more general OE or YP issue, but
> i was doing a kernel config yesterday, and my SRC_URI included, say,
> "rday.scc", which incorporated both kernel config fragments and
> patches, and that worked fine.
>
>   eventually, after massive refactoring, all that was left of that
> item was some kernel configuration which was already in "rday.cfg", so
> i edited SRC_URI and replaced "rday.scc" with "rday.cfg", but i left
> that old "rday.scc" in that directory (with its referent patches),
> assuming it would be ignored.
>
>   did a clean and configure and got:
>
>   | DEBUG: Executing shell function do_kernel_metadata
> | ERROR: could not find patch rday.patch, included from
> .../rday.scc ...
>
>   it *appears* that, even though SRC_URI now refers to (among other
> things) just "rday.cfg", it looks like the configure step is *still*
> trying to process "rday.scc", which contains a reference to a now
> non-existent patch, hence the failure.
>
>   if i just remove (or rename) "rday.scc", then things work fine. is
> this expected behaviour? is there some reason that if SRC_URI
> includes, say "derf.cfg", the configuration will automatically look
> for and try to process "derf.scc"? or am i just doing something silly?
>

There's no automatic inclusions like that. Take a look at your meta-series
and see if
there's an explicit reference to the .scc file.

Otherwise, I'll have to try and reproduce it here.

Bruce


>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



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

Re: [OE-core] [PATCH][master][krogoth][jethro][fido 2/2] tzdata: update to 2016d

[Martin Jansa]

On Tue, Apr 19, 2016 at 04:51:02PM -0700, Armin Kuster wrote:
> From: Armin Kuster 
> 
> Changes affecting future time stamps
> 

Please get this into jethro soon, now version in fido is newer (2016d)
than in jethro (2016c)

> Signed-off-by: Armin Kuster 
> ---
>  meta/recipes-extended/tzdata/{tzdata_2016c.bb => tzdata_2016d.bb} | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-extended/tzdata/{tzdata_2016c.bb => tzdata_2016d.bb} 
> (98%)
> 
> diff --git a/meta/recipes-extended/tzdata/tzdata_2016c.bb 
> b/meta/recipes-extended/tzdata/tzdata_2016d.bb
> similarity index 98%
> rename from meta/recipes-extended/tzdata/tzdata_2016c.bb
> rename to meta/recipes-extended/tzdata/tzdata_2016d.bb
> index 5eb85b7..627a31a 100644
> --- a/meta/recipes-extended/tzdata/tzdata_2016c.bb
> +++ b/meta/recipes-extended/tzdata/tzdata_2016d.bb
> @@ -8,8 +8,8 @@ DEPENDS = "tzcode-native"
>  
>  SRC_URI = 
> "http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata;
>  
> -SRC_URI[tzdata.md5sum] = "0330ccd16140d3b6438a18dae9b34b93"
> -SRC_URI[tzdata.sha256sum] = 
> "8700d981e6f2007ac037dabb5d2b12f390e8629bbc30e564bc21cf0c069a2d48"
> +SRC_URI[tzdata.md5sum] = "14bf84b6c2cdab0a9428991e0150ebe6"
> +SRC_URI[tzdata.sha256sum] = 
> "d9554dfba0efd76053582bd89e8c7036ef12eee14fdd506675b08a5b59f0a1b4"
>  
>  inherit allarch
>  
> -- 
> 2.3.5
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

Re: [OE-core] [RFC PATCH 0/6] Kernel configuration check for recipes

[Bruce Ashfield]

On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> Add the capability for other recipes to verify that kernel
> configuration options they depend upon at runtime are present, and warn
> if they are missing. This seems functional enough to me but is still in
> RFC - please let me know if it looks OK to you or I've missed anything
> (no doubt there are recipes we could add the checks to, I refer mainly
> to the mechanism itself).
>
>
> Please review the following changes for suitability for inclusion. If you
> have
> any objections or suggestions for improvement, please respond to the
> patches. If
> you agree with the changes, please provide your Acked-by.
>
>
See my replies to the patches. I'm sure it won't matter in the end, but
this is a duplication
of the mechanisms that we already have in the kernel config check phase. I
have a whole
set of changes that I completed early this year that extends that mechanism
to any kernel
(not just kernel-yocto) classes. In that mechanism there's the concept of
"required" and
"optional" Kconfig options. If they aren't present in the final .config, we
warn and optionally
error (this is versus the currently mechanism of only warning if boot
critical options are
dropped).

I'm betting that the follow on to this series will be "Hey recipes should
set the options for the kernel if
they really need them" .. which IMHO is an incredibly bad idea.

Cheers,

Bruce


> The following changes since commit
> ece101be5158beee709cdfbb85ecdbdc8d9fb864:
>
>   test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)
>
> are available in the git repository at:
>
>   git://git.openembedded.org/openembedded-core-contrib paule/kernel-check
>
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/kernel-check
>
> Paul Eggleton (6):
>   classes/kernel-check: add a class to check kernel config options
>   eudev: check for required kernel config options
>   systemd: check for required kernel config options
>   classes/kernel: fix typo
>   classes/kernel: check OLDEST_KERNEL at configure time
>   classes/image: check kernel config supports IMAGE_FSTYPES items
>
>  meta/classes/image.bbclass   | 23 
>  meta/classes/image_types.bbclass | 11 
>  meta/classes/kernel-check.bbclass| 97
> 
>  meta/classes/kernel.bbclass  | 16 +-
>  meta/recipes-core/systemd/systemd_229.bb | 19 ++-
>  meta/recipes-core/udev/eudev_3.1.5.bb| 22 +++-
>  6 files changed, 185 insertions(+), 3 deletions(-)
>  create mode 100644 meta/classes/kernel-check.bbclass
>
> --
> 2.5.5
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



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

Re: [OE-core] [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Bruce Ashfield]

On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> A lot of the IMAGE_FSTYPES items require the appropriate filesystem
> driver to be enabled in the kernel configuration; e.g. in order to read
> a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
> to ensure that is the case.
>


So what's the overall design for this ? Is it documented anywhere ? This is
something
that we talked about a couple of years and I have reservations and
objections to
the current implementation.

.. but since I can only see bits and chunks of patches, I'd rather read
something
complete and offer some more detailed feedback.

Bottom line: I see a slippery slope to tightly specified option that depend
on kernel
versions, I see kernel options sprayed all over layers, etc, etc. Which is
exactly
what we've been trying to avoid with the centralized kernel meta-data, and
again,
there's a mechanism that I finished early this year to extend those options
to any
kernel, enforce, warn, error, etc .. but now, I'll just toss it into the
bin.

Cheers,

Bruce


>
> Fixes [YOCTO #5574].
>
> Signed-off-by: Paul Eggleton 
> ---
>  meta/classes/image.bbclass   | 23 +++
>  meta/classes/image_types.bbclass | 11 +++
>  2 files changed, 34 insertions(+)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 4542e95..c56b053 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -238,9 +238,32 @@ do_rootfs[cleandirs] += "${S}"
>  do_rootfs[umask] = "022"
>  addtask rootfs before do_build
>
> +inherit kernel-check
> +
> +def check_image_fstypes_kernel(d):
> +"""
> +Check that the kernel we have built has the appropriate config
> options enabled
> +to support the image formats specified in IMAGE_FSTYPES
> +"""
> +fstypes = (d.getVar('IMAGE_FSTYPES', True) or '').split()
> +ctypes = (d.getVar('COMPRESSIONTYPES', True) or '').split()
> +for fstype in fstypes:
> +kernconfig = (d.getVar('IMAGE_TYPE_KERNEL_OPTIONS_' + fstype,
> True) or '').split()
> +for ctype in ctypes:
> +if fstype.endswith("." + ctype):
> +basetype = fstype[:-len("." + ctype)]
> +kernconfig.extend((d.getVar('IMAGE_TYPE_KERNEL_OPTIONS_'
> + basetype, True) or '').split())
> +kernconfig = list(set(kernconfig))
> +if kernconfig:
> +missing, diffvalue = check_kernel_config_options(kernconfig,
> d)
> +if missing or diffvalue:
> +bb.warn('IMAGE_FSTYPES contains %s, but the following
> required kernel configuration items are not present in the kernel
> configuration:\n  %s' % (fstype, '\n  '.join(missing + ['%s=%s (actual
> value %s)' % item for item in diffvalue])))
> +
>  fakeroot python do_image () {
>  from oe.utils import execute_pre_post_process
>
> +check_image_fstypes_kernel(d)
> +
>  pre_process_cmds = d.getVar("IMAGE_PREPROCESS_COMMAND", True)
>
>  execute_pre_post_process(d, pre_process_cmds)
> diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> index 53af7ca..dd79726 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -240,6 +240,17 @@ IMAGE_DEPENDS_ubifs = "mtd-utils-native"
>  IMAGE_DEPENDS_multiubi = "mtd-utils-native"
>  IMAGE_DEPENDS_wic = "parted-native"
>
> +IMAGE_TYPE_KERNEL_OPTIONS_jffs2 = "CONFIG_JFFS2_FS"
> +IMAGE_TYPE_KERNEL_OPTIONS_jffs2.sum = "CONFIG_JFFS2_SUMMARY"
> +IMAGE_TYPE_KERNEL_OPTIONS_cramfs = "CONFIG_CRAMFS"
> +IMAGE_TYPE_KERNEL_OPTIONS_ext2 =
> "CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23"
> +IMAGE_TYPE_KERNEL_OPTIONS_ext3 =
> "CONFIG_EXT3_FS|CONFIG_EXT4_USE_FOR_EXT23"
> +IMAGE_TYPE_KERNEL_OPTIONS_ext4 = "CONFIG_EXT4_FS"
> +IMAGE_TYPE_KERNEL_OPTIONS_btrfs = "CONFIG_BTRFS_FS"
> +IMAGE_TYPE_KERNEL_OPTIONS_squashfs = "CONFIG_SQUASHFS"
> +IMAGE_TYPE_KERNEL_OPTIONS_squashfs-xz = "CONFIG_SQUASHFS_XZ"
> +IMAGE_TYPE_KERNEL_OPTIONS_squashfs-lzo = "CONFIG_SQUASHFS_LZO"
> +
>  # This variable is available to request which values are suitable for
> IMAGE_FSTYPES
>  IMAGE_TYPES = " \
>  jffs2 jffs2.sum \
> --
> 2.5.5
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



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

[OE-core] [PATCH] package: handle package name with spaces

[Felipe F. Tonello]

Gracefuly handle the odd case when a desired file name used to build a package
or used as path for files in a package has spaces.

In that case, this patch ensures that do_split_packages adds files, even with
spaces, to the package.

Signed-off-by: Felipe F. Tonello 
---
 meta/classes/package.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index ffd4eff7b140..98206e4ce859 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -69,7 +69,7 @@ def legitimize_package_name(s):
 s = re.sub('', fixutf, s)
 
 # Remaining package name validity fixes
-return s.lower().replace('_', '-').replace('@', '+').replace(',', 
'+').replace('/', '-')
+return s.lower().replace(' ', '-').replace('_', '-').replace('@', 
'+').replace(',', '+').replace('/', '-')
 
 def do_split_packages(d, root, file_regex, output_pattern, description, 
postinst=None, recursive=False, hook=None, extra_depends=None, 
aux_files_pattern=None, postrm=None, allow_dirs=False, prepend=False, 
match_path=False, aux_files_pattern_verbatim=None, allow_links=False, 
summary=None):
 """
@@ -119,6 +119,7 @@ def do_split_packages(d, root, file_regex, output_pattern, 
description, postinst
   defaults to description if not set.
 
 """
+import re
 
 dvar = d.getVar('PKGD', True)
 root = d.expand(root)
@@ -193,8 +194,11 @@ def do_split_packages(d, root, file_regex, output_pattern, 
description, postinst
 newfile = os.path.join(root, o)
 # These names will be passed through glob() so if the filename actually
 # contains * or ? (rare, but possible) we need to handle that specially
+# Also, in order to support filename with spaces, we have to replace it
+# with * wildcard character
 newfile = newfile.replace('*', '[*]')
 newfile = newfile.replace('?', '[?]')
+newfile = re.sub(' +', '*', newfile) # Support spaces in packages
 if not oldfiles:
 the_files = [newfile]
 if aux_files_pattern:
-- 
2.8.2

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

Re: [OE-core] [RFC PATCH 1/6] classes/kernel-check: add a class to check kernel config options

[Bruce Ashfield]

On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> Some user-space software has specific requirements about the kernel
> configuration options selected. This class allows a recipe to explicitly
> state the kernel configuration options it needs (through a
> REQUIRED_KERNEL_OPTIONS variable). This is a space separated list, where
> each item is one of:
>   (a) an option name (e.g. CONFIG_FHANDLE, in which case CONFIG_FHANDLE
>   must be set to y or m to match)
>   (b) optionname=value (e.g. CONFIG_FHANDLE=y, in which case
>   CONFIG_FHANDLE must be set to y). If the specified value is n,
>   it will also match if the option is not present.
>   (c) optionname1|optionname2|... (e.g.
>   CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23, meaning that either
>   CONFIG_EXT2_FS or CONFIG_EXT4_USE_FOR_EXT23 must be set to y or
>   m to match).
>


This duplicates code that is already in the kconf_check routines, which
I've already
made generic (and added dependency information) for the 2.2 release ... so
call
me confused that I've never heard about this until now :(

Bruce


>
> Inheriting the class will also add a dependency from do_configure on
> virtual/kernel:do_shared_workdir so that the kernel config is there to
> check. If one or more items are not matched, then a warning will be
> printed at do_configure time. (This is a warning rather than an error
> in case you are using linux-dummy with an externally built kernel).
>
> A separate function is also provided should you wish to check a config
> option from python code - but note you must only call this in a place
> where you can guarantee that the kernel config has been written to the
> sysroot (i.e. from a task that has virtual/kernel:do_shared_workdir in
> its depends varflag value).
>
> Fixes [YOCTO #5574].
>
> Signed-off-by: Paul Eggleton 
> ---
>  meta/classes/kernel-check.bbclass | 97
> +++
>  1 file changed, 97 insertions(+)
>  create mode 100644 meta/classes/kernel-check.bbclass
>
> diff --git a/meta/classes/kernel-check.bbclass
> b/meta/classes/kernel-check.bbclass
> new file mode 100644
> index 000..d202f4e
> --- /dev/null
> +++ b/meta/classes/kernel-check.bbclass
> @@ -0,0 +1,97 @@
> +# Provides a means of checking within a recipe if particular kernel
> +# config options are enabled
> +#
> +# Copyright (C) 2016 Intel Corporation
> +#
> +# Example usage (within a recipe):
> +#
> +# inherit kernel-check
> +# REQUIRED_KERNEL_OPTIONS = "CONFIG_CGROUPS CONFIG_NAMESPACES"
> +#
> +# If one or more of the options aren't in the built kernel configuration
> +# you will get a warning at do_configure time.
> +#
> +# You can also use the check_kernel_config_options() function to do
> +# explicit checks yourself (and perform a different action).
> +
> +def check_kernel_config_options(options, d):
> +"""
> +A function you can use to do explicit checks for kernel config
> +options from python code
> +"""
> +
> +if isinstance(options, basestring):
> +required = options.split()
> +else:
> +required = options[:]
> +missing = []
> +diffvalue = []
> +if required:
> +with open(d.expand('${STAGING_KERNEL_BUILDDIR}/.config'), 'r') as
> f:
> +for line in f:
> +if line.startswith('#'):
> +continue
> +linesplit = line.rstrip().split('=', 1)
> +if len(linesplit) < 2:
> +continue
> +linevalue = linesplit[1]
> +for req in required:
> +found = False
> +if '|' in req:
> +for reqitem in req.split('|'):
> +if reqitem == linesplit[0]:
> +if linevalue in ['y', 'm']:
> +found = True
> +break
> +else:
> +reqsplit = req.split('=', 1)
> +# Can check for CONFIG_OPTION or
> CONFIG_OPTION=value
> +if len(reqsplit) > 1:
> +reqvalue = reqsplit[1]
> +else:
> +reqvalue = None
> +if reqsplit[0] == linesplit[0]:
> +if reqvalue is None:
> +if linevalue not in ['y', 'm']:
> +diffvalue.append((reqsplit[0], 'y or
> m', linevalue))
> +elif reqvalue.strip("'\"") !=
> linevalue.strip("'\""):
> +diffvalue.append((reqsplit[0], reqvalue,
> linevalue))
> +found = True
> +
> +if found:
> +required.remove(req)
> +break
> +
> +for req in required:
> +   

[OE-core] should a SRC_URI referring to "rday.cfg" look for "rday.scc"?

[Robert P. J. Day]

  (aside: this is with wind river linux 8 and i dropped bruce a note
about it, but i really should keep this stuff on the mailing list.)

  not sure if this is a WRL issue, or more general OE or YP issue, but
i was doing a kernel config yesterday, and my SRC_URI included, say,
"rday.scc", which incorporated both kernel config fragments and
patches, and that worked fine.

  eventually, after massive refactoring, all that was left of that
item was some kernel configuration which was already in "rday.cfg", so
i edited SRC_URI and replaced "rday.scc" with "rday.cfg", but i left
that old "rday.scc" in that directory (with its referent patches),
assuming it would be ignored.

  did a clean and configure and got:

  | DEBUG: Executing shell function do_kernel_metadata
| ERROR: could not find patch rday.patch, included from
.../rday.scc ...

  it *appears* that, even though SRC_URI now refers to (among other
things) just "rday.cfg", it looks like the configure step is *still*
trying to process "rday.scc", which contains a reference to a now
non-existent patch, hence the failure.

  if i just remove (or rename) "rday.scc", then things work fine. is
this expected behaviour? is there some reason that if SRC_URI
includes, say "derf.cfg", the configuration will automatically look
for and try to process "derf.scc"? or am i just doing something silly?

rday

-- 


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

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




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

[OE-core] [PATCH 0/1] linux-dummy: set INHIBIT_DEFAULT_DEPS

[Robert Yang]

The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:

  test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)

are available in the git repository at:

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

Robert Yang (1):
  linux-dummy: set INHIBIT_DEFAULT_DEPS

 meta/recipes-kernel/linux/linux-dummy.bb | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.8.0

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

[OE-core] [PATCH 1/1] linux-dummy: set INHIBIT_DEFAULT_DEPS

[Robert Yang]

It doesn't need them.

Signed-off-by: Robert Yang 
---
 meta/recipes-kernel/linux/linux-dummy.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-kernel/linux/linux-dummy.bb 
b/meta/recipes-kernel/linux/linux-dummy.bb
index cc0e4e6..994ac74 100644
--- a/meta/recipes-kernel/linux/linux-dummy.bb
+++ b/meta/recipes-kernel/linux/linux-dummy.bb
@@ -18,6 +18,8 @@ FILES_kernel-modules = ""
 ALLOW_EMPTY_kernel-modules = "1"
 DESCRIPTION_kernel-modules = "Kernel modules meta package"
 
+INHIBIT_DEFAULT_DEPS = "1"
+
 #COMPATIBLE_MACHINE = "your_machine"
 
 PR = "r1"
-- 
2.8.0

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

Re: [OE-core] [PATCH] gst-player: Remove recipe: gstplayer is part of -bad package since 1.8

[Burton, Ross]

gst-player the API is, but not the applications gtk-player or gst-player
which is the main reason this recipe exists in oe-core.

Current gst-player HEAD is now using non-trivial parts of GTK+ 3, so I
started to backport the API changes to gst-player so we could ship a GTK+ 2
gtk-player that links to the API in -bad 1.8, but didn't finish the work.
We plan on merging the GTK+ 3 Sato patches fairly soon so it may be that
the -bad 1.8 upgrade waits for that, then gst-player can switch to git HEAD
with GTK+ 3, and everything works again.


Ross

On 8 May 2016 at 18:33, Carlos Rafael Giani  wrote:

> Signed-off-by: Carlos Rafael Giani 
> ---
>  .../recipes-multimedia/gstreamer/gst-player_git.bb | 39
> --
>  1 file changed, 39 deletions(-)
>  delete mode 100644 meta/recipes-multimedia/gstreamer/gst-player_git.bb
>
> diff --git a/meta/recipes-multimedia/gstreamer/gst-player_git.bb
> b/meta/recipes-multimedia/gstreamer/gst-player_git.bb
> deleted file mode 100644
> index 8129169..000
> --- a/meta/recipes-multimedia/gstreamer/gst-player_git.bb
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -SUMMARY = "GStreamer playback helper library and examples"
> -LICENSE = "LGPL-2.0+"
> -LIC_FILES_CHKSUM =
> "file://lib/gst/player/gstplayer.c;beginline=1;endline=19;md5=03aeca9d8295f811817909075a15ff65"
> -
> -DEPENDS = "glib-2.0 gstreamer1.0 gstreamer1.0-plugins-base gtk+"
> -
> -SRC_URI = "git://github.com/sdroege/gst-player.git \
> -   file://filechooser.patch \
> -   file://gtk2.patch \
> -   file://Fix-pause-play.patch \
> -   file://Add-error-signal-emission-for-missing-plugins.patch \
> -   file://gst-player.desktop"
> -
> -SRCREV = "5386c5b984d40ef5434673ed62204e69aaf52645"
> -
> -S = "${WORKDIR}/git"
> -
> -inherit autotools gtk-doc lib_package pkgconfig distro_features_check
> gobject-introspection
> -
> -ANY_OF_DISTRO_FEATURES = "${GTK2DISTROFEATURES}"
> -
> -do_configure_prepend() {
> -   touch ${S}/ChangeLog
> -}
> -
> -EXTRA_OECONF += "ac_cv_path_VALGRIND=no ac_cv_path_GDB=no"
> -
> -do_install_append() {
> -   install -m 0644 -D ${WORKDIR}/gst-player.desktop
> ${D}${datadir}/applications/gst-player.desktop
> -}
> -
> -FILES_${PN}-bin += "${datadir}/applications/*.desktop"
> -
> -RDEPENDS_${PN}-bin = "gstreamer1.0-plugins-base-playback"
> -RRECOMMENDS_${PN}-bin = "gstreamer1.0-plugins-base-meta \
> - gstreamer1.0-plugins-good-meta \
> - gstreamer1.0-plugins-bad-meta \
> - ${@bb.utils.contains("LICENSE_FLAGS_WHITELIST",
> "commercial", "gstreamer1.0-libav", "", d)} \
> - ${@bb.utils.contains("LICENSE_FLAGS_WHITELIST",
> "commercial", "gstreamer1.0-plugins-ugly-meta", "", d)}"
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gst-player: Remove recipe: gstplayer is part of -bad package since 1.8

[Jussi Kukkonen]

I assume -bad only contains the gst-player library? We also want the
"gtk-play" UI for testing purposes.

Also note that without patches gst-player requires GTK+3 -- it may
make sense to hold the 1.8 update until the GTK+3 transition is done
(which I'm hoping happens during May) so we don't end up with both
GTK+ versions on sato images.

 - Jussi

On 8 May 2016 at 20:33, Carlos Rafael Giani  wrote:
> Signed-off-by: Carlos Rafael Giani 
> ---
>  .../recipes-multimedia/gstreamer/gst-player_git.bb | 39 
> --
>  1 file changed, 39 deletions(-)
>  delete mode 100644 meta/recipes-multimedia/gstreamer/gst-player_git.bb
>
> diff --git a/meta/recipes-multimedia/gstreamer/gst-player_git.bb 
> b/meta/recipes-multimedia/gstreamer/gst-player_git.bb
> deleted file mode 100644
> index 8129169..000
> --- a/meta/recipes-multimedia/gstreamer/gst-player_git.bb
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -SUMMARY = "GStreamer playback helper library and examples"
> -LICENSE = "LGPL-2.0+"
> -LIC_FILES_CHKSUM = 
> "file://lib/gst/player/gstplayer.c;beginline=1;endline=19;md5=03aeca9d8295f811817909075a15ff65"
> -
> -DEPENDS = "glib-2.0 gstreamer1.0 gstreamer1.0-plugins-base gtk+"
> -
> -SRC_URI = "git://github.com/sdroege/gst-player.git \
> -   file://filechooser.patch \
> -   file://gtk2.patch \
> -   file://Fix-pause-play.patch \
> -   file://Add-error-signal-emission-for-missing-plugins.patch \
> -   file://gst-player.desktop"
> -
> -SRCREV = "5386c5b984d40ef5434673ed62204e69aaf52645"
> -
> -S = "${WORKDIR}/git"
> -
> -inherit autotools gtk-doc lib_package pkgconfig distro_features_check 
> gobject-introspection
> -
> -ANY_OF_DISTRO_FEATURES = "${GTK2DISTROFEATURES}"
> -
> -do_configure_prepend() {
> -   touch ${S}/ChangeLog
> -}
> -
> -EXTRA_OECONF += "ac_cv_path_VALGRIND=no ac_cv_path_GDB=no"
> -
> -do_install_append() {
> -   install -m 0644 -D ${WORKDIR}/gst-player.desktop 
> ${D}${datadir}/applications/gst-player.desktop
> -}
> -
> -FILES_${PN}-bin += "${datadir}/applications/*.desktop"
> -
> -RDEPENDS_${PN}-bin = "gstreamer1.0-plugins-base-playback"
> -RRECOMMENDS_${PN}-bin = "gstreamer1.0-plugins-base-meta \
> - gstreamer1.0-plugins-good-meta \
> - gstreamer1.0-plugins-bad-meta \
> - ${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
> "commercial", "gstreamer1.0-libav", "", d)} \
> - ${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
> "commercial", "gstreamer1.0-plugins-ugly-meta", "", d)}"
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core