Re: [OE-core] [jethro][PATCH] gcc-multilib-config: make aarch64 support multilib

[Khem Raj]

On Wed, Mar 15, 2017 at 2:36 AM zhengrq  wrote:

>   Fixed:
>   MACHINE = qemuarm64
>   require conf/multilib.conf
>   MULTILIBS = "multilib:lib32"
>   DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
>
>   $ bitbake core-image-minimal -cpopulate_sdk
>
>   WARNING: gcc multilib setup is not supported for TARGET_ARCH=aarch64
>   WARNING: gcc multilib setup is not supported for TARGET_ARCH=aarch64
>
>   [YOCTO #8638]


Gcc backend for aarch64 is separate from arm targets how have you tested
the generated compiler sdk

>
>
>   (From OE-Core rev: 0ae52c8b2c1d7d7cdbcfeeae6ff42e64f16bc41d)
>
> Signed-off-by: Robert Yang 
> Signed-off-by: Ross Burton 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Zheng Ruoqin 
> ---
>  meta/recipes-devtools/gcc/gcc-multilib-config.inc | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
> b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
> index 1c0a45a..a0a2ac0 100644
> --- a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
> +++ b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
> @@ -29,6 +29,9 @@ python gcc_multilib_setup() {
>  bb.utils.remove(build_conf_dir, True)
>  ml_globs = ('%s/*/t-linux64' % src_conf_dir,
>  '%s/*/linux64.h' % src_conf_dir,
> +'%s/aarch64/t-aarch64' % src_conf_dir,
> +'%s/aarch64/aarch64.h' % src_conf_dir,
> +'%s/aarch64/aarch64-cores.def' % src_conf_dir,
>  '%s/*/linux.h' % src_conf_dir,
>  '%s/linux.h' % src_conf_dir)
>
> @@ -130,6 +133,8 @@ python gcc_multilib_setup() {
>  'mips64': ['gcc/config/mips/t-linux64'],
>  'powerpc'   : ['gcc/config/rs6000/t-linux64'],
>  'powerpc64' : ['gcc/config/rs6000/t-linux64'],
> +'aarch64'   : ['gcc/config/aarch64/t-aarch64'],
> +'arm'   : ['gcc/config/aarch64/t-aarch64'],
>  }
>
>  gcc_header_config_files = {
> @@ -140,6 +145,8 @@ python gcc_multilib_setup() {
>  'mips64': ['gcc/config/mips/linux.h',
> 'gcc/config/mips/linux64.h'],
>  'powerpc'   : ['gcc/config/rs6000/linux64.h'],
>  'powerpc64' : ['gcc/config/rs6000/linux64.h'],
> +'aarch64'   : ['gcc/config/aarch64/aarch64.h'],
> +'arm'   : ['gcc/config/aarch64/aarch64.h'],
>  }
>
>  libdir32 = 'SYSTEMLIBS_DIR'
> --
> 2.7.4
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [morty][PATCH 1/1] sanity.bbclass: modify check for shell

[akuster808]

On 03/15/2017 12:39 PM, Juro Bystricky wrote:

Due to the recently implemented update-alternatives for bash binary,
sanity checker may end up with a (false-positive) error such as:

Error, /bin/sh links to /bin/bash.bash, must be dash or bash

This patch modifies the test: presence of "/bash" or "/dash" in shell binary
name results in pass.

ok. got it in my pre-stagging.
thanks
- armin


[YOCTO#11108]

Signed-off-by: Juro Bystricky 
---
  meta/classes/sanity.bbclass | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 7682ffb..a11b581 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -929,7 +929,9 @@ def check_sanity_everybuild(status, d):
  # If /bin/sh is a symlink, check that it points to dash or bash
  if os.path.islink('/bin/sh'):
  real_sh = os.path.realpath('/bin/sh')
-if not real_sh.endswith('/dash') and not real_sh.endswith('/bash'):
+# Due to update-alternatives, the shell name may take various
+# forms, such as /bin/dash, bin/bash, /bin/bash.bash ...
+if '/dash' not in real_sh and '/bash' not in real_sh:
  status.addresult("Error, /bin/sh links to %s, must be dash or 
bash\n" % real_sh)
  
  def check_sanity(sanity_data):


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

Re: [OE-core] [PATCH 1/3] build-appliance-image: use pip3-native

[Bystricky, Juro]

sure, no problem


From: Richard Purdie [richard.pur...@linuxfoundation.org]
Sent: Wednesday, March 15, 2017 3:16 PM
To: Bystricky, Juro; openembedded-core@lists.openembedded.org
Cc: jurobystri...@hotmail.com
Subject: Re: [PATCH 1/3] build-appliance-image: use pip3-native

On Wed, 2017-03-15 at 15:13 -0700, Juro Bystricky wrote:
> Do not rely on pip3 being installed on the host.
> Use pip3-native instead.
>
> [YOCTO#10909]
> [YOCTO#11022]
>
> Signed-off-by: Juro Bystricky 
> ---
>  meta/recipes-core/images/build-appliance-image_15.0.0.bb | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> index 0db1fb0..730989e 100644
> --- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> +++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> @@ -18,10 +18,10 @@ IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
>  # Do a quiet boot with limited console messages
>  APPEND += "rootfstype=ext4 quiet"
>
> -DEPENDS = "zip-native"
> +DEPENDS = "zip-native python3-pip-native"
>  IMAGE_FSTYPES = "vmdk"
>
> -inherit core-image module-base
> +inherit core-image module-base setuptools3
>
>  SRCREV ?= "8343ed93c4278715aa1582d3cadedf8f197b4089"
>  SRC_URI = "git://git.yoctoproject.org/poky;branch=master \
> @@ -95,6 +95,8 @@ fakeroot do_populate_poky_src () {
>   echo 'gtk-theme-name = "Clearlooks"' >
> ${IMAGE_ROOTFS}/etc/gtk-2.0/gtkrc
>
>   # Install modules needed for toaster
> + export STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}
> + export STAGING_INCDIR=${STAGING_INCDIR_NATIVE}
>   export HOME=${IMAGE_ROOTFS}/home/builder
>   mkdir -p ${IMAGE_ROOTFS}/home/builder/.cache/pip
>   pip3 install --user -I -U -v -r
> ${IMAGE_ROOTFS}/home/builder/poky/bitbake/toaster-requirements.txt


Looks good, thanks. Can you also drop "pip" from bitbake.conf's
HOSTTOOLS_NONFATAL please?

Cheers,

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

Re: [OE-core] [PATCH 1/3] build-appliance-image: use pip3-native

[Richard Purdie]

On Wed, 2017-03-15 at 15:13 -0700, Juro Bystricky wrote:
> Do not rely on pip3 being installed on the host.
> Use pip3-native instead.
> 
> [YOCTO#10909]
> [YOCTO#11022]
> 
> Signed-off-by: Juro Bystricky 
> ---
>  meta/recipes-core/images/build-appliance-image_15.0.0.bb | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb 
> b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> index 0db1fb0..730989e 100644
> --- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> +++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> @@ -18,10 +18,10 @@ IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
>  # Do a quiet boot with limited console messages
>  APPEND += "rootfstype=ext4 quiet"
>  
> -DEPENDS = "zip-native"
> +DEPENDS = "zip-native python3-pip-native"
>  IMAGE_FSTYPES = "vmdk"
>  
> -inherit core-image module-base
> +inherit core-image module-base setuptools3
>  
>  SRCREV ?= "8343ed93c4278715aa1582d3cadedf8f197b4089"
>  SRC_URI = "git://git.yoctoproject.org/poky;branch=master \
> @@ -95,6 +95,8 @@ fakeroot do_populate_poky_src () {
>   echo 'gtk-theme-name = "Clearlooks"' >
> ${IMAGE_ROOTFS}/etc/gtk-2.0/gtkrc
>  
>   # Install modules needed for toaster
> + export STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}
> + export STAGING_INCDIR=${STAGING_INCDIR_NATIVE}
>   export HOME=${IMAGE_ROOTFS}/home/builder
>   mkdir -p ${IMAGE_ROOTFS}/home/builder/.cache/pip
>   pip3 install --user -I -U -v -r
> ${IMAGE_ROOTFS}/home/builder/poky/bitbake/toaster-requirements.txt


Looks good, thanks. Can you also drop "pip" from bitbake.conf's
HOSTTOOLS_NONFATAL please?

Cheers,

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

[OE-core] [PATCH 2/3] build-appliance-image: fix build errors

[Juro Bystricky]

Remove any symlinks before creating new ones to avoid potential build
errors such as:

FileExistsError: [Errno 17] File exists: '../../usr/src/kernel' -> ... '

Signed-off-by: Juro Bystricky 
---
 meta/recipes-core/images/build-appliance-image_15.0.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb 
b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
index 730989e..b1d2250 100644
--- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
+++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
@@ -60,6 +60,7 @@ fakeroot do_populate_poky_src () {
cp ${WORKDIR}/README_VirtualBox_Toaster.txt 
${IMAGE_ROOTFS}/home/builder/
 
# Create a symlink, needed for out-of-tree kernel modules build
+   rm -f  ${IMAGE_ROOTFS}/lib/modules/${KERNEL_VERSION}/build
lnr ${IMAGE_ROOTFS}${KERNEL_SRC_PATH} 
${IMAGE_ROOTFS}/lib/modules/${KERNEL_VERSION}/build
 
echo "INHERIT += \"rm_work\"" >> 
${IMAGE_ROOTFS}/home/builder/poky/build/conf/auto.conf
@@ -87,6 +88,7 @@ fakeroot do_populate_poky_src () {
echo "builder ALL=(ALL) NOPASSWD: ALL" >> ${IMAGE_ROOTFS}/etc/sudoers
 
# Load tap/tun at startup
+   rm -f ${IMAGE_ROOTFS}/sbin/iptables
lnr ${IMAGE_ROOTFS}/usr/sbin/iptables ${IMAGE_ROOTFS}/sbin/iptables
echo "tun" >> ${IMAGE_ROOTFS}/etc/modules
 
-- 
2.7.4

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

[OE-core] [PATCH 3/3] build-appliance-image: ensure pod2man present in BA

[Juro Bystricky]

"pod2man" went missing from BA, but it is required.
This patch fixes the Toaster error:

<...>
ERROR: These tools appear to be unavailable in PATH, please install
   them in order to proceed:
   pod2man
<...>

[YOCTO#11144]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-core/images/build-appliance-image_15.0.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb 
b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
index b1d2250..5107246 100644
--- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
+++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d
 
 IMAGE_INSTALL = "packagegroup-core-boot packagegroup-core-ssh-openssh 
packagegroup-self-hosted \
  kernel-dev kernel-devsrc connman connman-plugin-ethernet 
dhcp-client \
- tzdata python3-pip"
+ tzdata python3-pip perl-misc"
 
 IMAGE_FEATURES += "x11-base package-management splash"
 
-- 
2.7.4

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

[OE-core] [PATCH 1/3] build-appliance-image: use pip3-native

[Juro Bystricky]

Do not rely on pip3 being installed on the host.
Use pip3-native instead.

[YOCTO#10909]
[YOCTO#11022]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-core/images/build-appliance-image_15.0.0.bb | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb 
b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
index 0db1fb0..730989e 100644
--- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
+++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
@@ -18,10 +18,10 @@ IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
 # Do a quiet boot with limited console messages
 APPEND += "rootfstype=ext4 quiet"
 
-DEPENDS = "zip-native"
+DEPENDS = "zip-native python3-pip-native"
 IMAGE_FSTYPES = "vmdk"
 
-inherit core-image module-base
+inherit core-image module-base setuptools3
 
 SRCREV ?= "8343ed93c4278715aa1582d3cadedf8f197b4089"
 SRC_URI = "git://git.yoctoproject.org/poky;branch=master \
@@ -95,6 +95,8 @@ fakeroot do_populate_poky_src () {
echo 'gtk-theme-name = "Clearlooks"' > ${IMAGE_ROOTFS}/etc/gtk-2.0/gtkrc
 
# Install modules needed for toaster
+   export STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}
+   export STAGING_INCDIR=${STAGING_INCDIR_NATIVE}
export HOME=${IMAGE_ROOTFS}/home/builder
mkdir -p ${IMAGE_ROOTFS}/home/builder/.cache/pip
pip3 install --user -I -U -v -r 
${IMAGE_ROOTFS}/home/builder/poky/bitbake/toaster-requirements.txt
-- 
2.7.4

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

[OE-core] [PATCH 0/3] Build Appliance tweaks

[Juro Bystricky]

The Build Appliance recipe needs several tweaks in order for the BA to build and
to function.

1. Use native pip3: Do not rely on pip3 being installed on host.
   This, of course, assumes there is already python-pip3-native support 
available.
   (a previous patch)

2. Remove symlinks before creating them to avid build errors, otherwise we may 
run
   into "File already exists" build errors. 

3. Ensure pod2man is present in the BA image, toaster will not run without it.
   

Even with all these changes, it may not be possible to use BA to build any 
image, unless
the sanity.bbclass accepts /bin/bash.bash as a viable shell. This has already 
been addressed
in another patch. The BA then needs to be rebuilt with SRCREV containing the 
sanity.bbclass patch.




Juro Bystricky (3):
  build-appliance-image: use pip3-native
  build-appliance-image: fix build errors
  build-appliance-image: ensure pod2man present in BA

 meta/recipes-core/images/build-appliance-image_15.0.0.bb | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

-- 
2.7.4

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

Re: [OE-core] RSS-related problem after update to OE-Core with dnf

[Richard Purdie]

On Wed, 2017-03-15 at 09:29 +, Peter Kjellerstedt wrote:
> I update my Poky to the latest on master yesterday (i.e., I went
> from 
> a version using smart to one using dnf) and when I rebuilt my image
> I 
> got the following error:
> [...]
> I.e., it is trying to link a MIPS library with an x86_64 one...
> 
> After I did a "bitbake libsolv -c cleansstate", the problem went
> away, 
> and checking the log.do_compile afterwards it seems it is not even 
> trying to link with librpmdb.so at all any more.
> 
> My guess is that the librpmdb.so (which was a link to librpmdb-
> 5.4.so) 
> was a leftover from before the switch from smart to dnf. However,
> the 
> fact that it remained in ${WORKDIR}/recipe-sysroot-native AND that
> it 
> was picked up by the build indicates both a problem with the 
> determinism of RSS, and the with the build of libsolv itself.

FWIW I have read this and it is a concern. Unfortunately RSS is just
that, *recipe* specific, not task specific and therefore as I mentioned
in the original commits, it can't be perfect as it doesn't know
anything about the dependencies of other tasks this recipe may have and
which may be running in parallel.

I'm contiuing to see if there are better ways we can ensure stale
things get removed from the sysroots but its a hard problem due to the
parallelism. I do have some ideas though.

Distilling an easy to reproduce test case would help if someone has the
time.

Cheers,

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

Re: [OE-core] [oe-core][PATCH 1/1] build-compare: add date to PV

[Richard Purdie]

On Wed, 2017-03-15 at 11:16 -0700, Joe Slater wrote:
> We want PV values to be easily ordered, so
> use the latest entry in build-compare.changes which
> will also match the date of SRCREV.
> 
> Signed-off-by: Joe Slater 
> ---
>  .../build-compare/build-compare_git.bb |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/build-compare/build-compare_git.bb 
> b/meta/recipes-devtools/build-compare/build-compare_git.bb
> index eb12e40..c80ebd4 100644
> --- a/meta/recipes-devtools/build-compare/build-compare_git.bb
> +++ b/meta/recipes-devtools/build-compare/build-compare_git.bb
> @@ -17,8 +17,10 @@ SRC_URI = "git://github.com/openSUSE/build-
> compare.git \
> file://functions.sh-improve-deb-and-ipk-checking.patch \
> "
>  
> +# Date matches entry in build-compare.changes and date of SRCREV.
> +#
>  SRCREV = "c5352c054c6ef15735da31b76d6d88620f4aff0a"
> -PV = "git+${SRCPV}"
> +PV = "2015.02.10+git"

I think you either want:

"2015.02.10"
or
"2015.02.10+git${SRCPV}"

but not the one above! :)

(since this matches the style in the other git recipes)

Cheers,

Richard




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

[OE-core] [PATCH 1/1] tivesdk-packagegroup-sdk-host.bb: add cmake

[brian avery]

The Eclipse plugin uses cmake from the SDK and currently has issues
because cmake is not installed as a host tool.  This patch adds cmake as
a host tool for the sdk/esdk.

Signed-off-by: brian avery 
---
 meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index 3283e73..2ca6392 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -23,6 +23,7 @@ RDEPENDS_${PN} = "\
 nativesdk-shadow \
 nativesdk-makedevs \
 nativesdk-dnf \
+nativesdk-cmake \
 nativesdk-postinst-intercept \
 ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'nativesdk-wayland', 
'', d)} \
 "
-- 
2.7.4

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

[OE-core] [PATCH 0/1] add cmake host tool to sdk and esdk

[brian avery]

The Eclipse plugin uses cmake from the SDK and currently has issues
because cmake is not installed as a host tool.  This patch adds cmake as
a host tool for the sdk/esdk.
This adds ~ 20M to the sdk/esdk which is not alot given the functionality.

-brian

The following changes since commit 812fabbd30a062f6e726e6ae0399d87e85bf7fa3:

  bitbake: runqueue: minor typo fix (2017-03-15 17:38:33 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib bavery/add-cmake-to-sdk-and-esdl
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=bavery/add-cmake-to-sdk-and-esdl

brian avery (1):
  tivesdk-packagegroup-sdk-host.bb: add cmake

 meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
 1 file changed, 1 insertion(+)

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

[OE-core] [PATCH] python3-pip: support native builds

[Juro Bystricky]

Add native pip3 support.

[YOCTO#11049]
[YOCTO#11022]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-devtools/python/python3-pip_9.0.1.bb | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-pip_9.0.1.bb 
b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
index b6dbb6e..4456b9b 100644
--- a/meta/recipes-devtools/python/python3-pip_9.0.1.bb
+++ b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
@@ -34,6 +34,11 @@ do_install_append() {
 
 # Installed eggs need to be passed directly to the interpreter via a pth 
file
 echo "./${SRCNAME}-${PV}-py${PYTHON_BASEVERSION}.egg" > 
${D}${PYTHON_SITEPACKAGES_DIR}/${SRCNAME}-${PV}.pth
+
+# Make sure we use /usr/bin/env python3
+for PYTHSCRIPT in `grep -rIl ${bindir} ${D}${bindir}/pip3*`; do
+sed -i -e '1s|^#!.*|#!/usr/bin/env python3|' $PYTHSCRIPT
+done
 }
 
 RDEPENDS_${PN} = "\
@@ -47,3 +52,5 @@ RDEPENDS_${PN} = "\
   python3-unixadmin \
   python3-xmlrpc \
 "
+
+BBCLASSEXTEND = "native"
-- 
2.7.4

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

[OE-core] [morty][PATCH 0/1] relaxed testing for shell

[Juro Bystricky]

Due to the recently implemented update-alternatives for bash binary,
sanity checker may end up with a (false-positive) error such as:

Error, /bin/sh links to /bin/bash.bash, must be dash or bash

This patch is also desired for "morty", even if it may not support
update-alternatives for bash, otherwise, for example builds using
"master" toaster will fail when using "morty" release.


Juro Bystricky (1):
  sanity.bbclass: modify check for shell

 meta/classes/sanity.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.7.4

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

[OE-core] [morty][PATCH 1/1] sanity.bbclass: modify check for shell

[Juro Bystricky]

Due to the recently implemented update-alternatives for bash binary,
sanity checker may end up with a (false-positive) error such as:

Error, /bin/sh links to /bin/bash.bash, must be dash or bash

This patch modifies the test: presence of "/bash" or "/dash" in shell binary
name results in pass.

[YOCTO#11108]

Signed-off-by: Juro Bystricky 
---
 meta/classes/sanity.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 7682ffb..a11b581 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -929,7 +929,9 @@ def check_sanity_everybuild(status, d):
 # If /bin/sh is a symlink, check that it points to dash or bash
 if os.path.islink('/bin/sh'):
 real_sh = os.path.realpath('/bin/sh')
-if not real_sh.endswith('/dash') and not real_sh.endswith('/bash'):
+# Due to update-alternatives, the shell name may take various
+# forms, such as /bin/dash, bin/bash, /bin/bash.bash ...
+if '/dash' not in real_sh and '/bash' not in real_sh:
 status.addresult("Error, /bin/sh links to %s, must be dash or 
bash\n" % real_sh)
 
 def check_sanity(sanity_data):
-- 
2.7.4

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

[OE-core] [PATCH] runqemu: independent network and rootfs setup

[Juro Bystricky]

Presently, runqemu sets up rootfs as part of network setup.
In case there is no network desired we will end up without rootfs
as well.
This patch sets up network and rootfs independently.
It is also possible to bypass setup of rootfs if QB_ROOTFS is set to "none".

Signed-off-by: Juro Bystricky 
---
 scripts/runqemu | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/runqemu b/scripts/runqemu
index c5fa88e..3e21724 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -935,6 +935,9 @@ class BaseConfig(object):
 else:
 self.setup_tap()
 
+def setup_rootfs(self):
+if self.get('QB_ROOTFS') == 'none':
+return
 rootfs_format = self.fstype if self.fstype in ('vmdk', 'qcow2', 'vdi') 
else 'raw'
 
 qb_rootfs_opt = self.get('QB_ROOTFS_OPT')
@@ -1167,6 +1170,7 @@ def main():
 config.print_config()
 try:
 config.setup_network()
+config.setup_rootfs()
 config.setup_final()
 config.start_qemu()
 finally:
-- 
2.7.4

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

[OE-core] [oe-core][PATCH 1/1] build-compare: add date to PV

[Joe Slater]

We want PV values to be easily ordered, so
use the latest entry in build-compare.changes which
will also match the date of SRCREV.

Signed-off-by: Joe Slater 
---
 .../build-compare/build-compare_git.bb |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/build-compare/build-compare_git.bb 
b/meta/recipes-devtools/build-compare/build-compare_git.bb
index eb12e40..c80ebd4 100644
--- a/meta/recipes-devtools/build-compare/build-compare_git.bb
+++ b/meta/recipes-devtools/build-compare/build-compare_git.bb
@@ -17,8 +17,10 @@ SRC_URI = "git://github.com/openSUSE/build-compare.git \
file://functions.sh-improve-deb-and-ipk-checking.patch \
"
 
+# Date matches entry in build-compare.changes and date of SRCREV.
+#
 SRCREV = "c5352c054c6ef15735da31b76d6d88620f4aff0a"
-PV = "git+${SRCPV}"
+PV = "2015.02.10+git"
 
 S = "${WORKDIR}/git"
 
-- 
1.7.9.5

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

Re: [OE-core] [PATCH 1/3] rpm: add support for remote package feeds via PACKAGE_FEED_URIS variable

[Ibarra Lopez, Humberto]

Yeah, it does sound off but we could use it. We could put a mock value in the 
ip to the PACKAGE_FEED_URIS var to build this image and once it boths update 
that value with the real one. We would have to check that the mock value was 
correctly set before updating so we can test the var being correctly set; and 
then check that the feeds are updated correctly once a valid ip is there. I 
will look into this.

Humberto

-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] 
Sent: Wednesday, March 15, 2017 10:08 AM
To: Ibarra Lopez, Humberto ; Alexander Kanavin 
; Burton, Ross 
Cc: OE-core 
Subject: Re: [OE-core] [PATCH 1/3] rpm: add support for remote package feeds 
via PACKAGE_FEED_URIS variable

On Wed, 2017-03-15 at 15:38 +, Ibarra Lopez, Humberto wrote:
> Sorry, missed the previous mail.
> 
> I am not sure how to improve the hardcoding there, I don't like it 
> either, but couldn't find an alternative. The thing is that we need 
> the ip of the host as seen from the target to run testimage, but we 
> don’t have the exact value for that one until qemu is up. The issue 
> here is that we need to give this ip to the conf in the 
> PACKAGE_FEED_URIS before building so we can get an image with this var 
> to later use in testimage.
> 
> If someone has a better idea to get rid of this hardcoding, it would 
> be great to know.

We could run a sed command inside the image after it boots but before 
triggering the tests to put the correct IP/port number into the file?

Not a perfect test but simple and probably good enough for this?

Cheers,

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

Re: [OE-core] [PATCH] yocto-compat-layer: improve error handling in signature creation

[Aníbal Limón]

Acked-by:  Aníbal Limón 

On 03/15/2017 04:01 AM, Patrick Ohly wrote:
> When "bitbake -k -S none world" failed, the error printed by
> yocto-compat-layer.py contained the stack trace multiple times and did not
> contain the stderr output from bitbake, making the error hard to understand
> and debug:
> 
>   INFO: ==
>   INFO: ERROR: test_signatures (common.CommonCompatLayer)
>   INFO: --
>   INFO: Traceback (most recent call last):
> File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 144, in 
> get_signatures
>   stderr=subprocess.PIPE)
> File "/usr/lib/python3.4/subprocess.py", line 620, in check_output
>   raise CalledProcessError(retcode, process.args, output=output)
>   subprocess.CalledProcessError: Command 'bitbake -k -S none world' returned 
> non-zero exit status 1
> 
>   During handling of the above exception, another exception occurred:
> 
>   Traceback (most recent call last):
> File "/fast/work/poky/scripts/lib/compatlayer/cases/common.py", line 51, 
> in test_signatures
>   curr_sigs = get_signatures(self.td['builddir'], failsafe=True)
> File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 149, in 
> get_signatures
>   raise RuntimeError(msg)
>   RuntimeError: Traceback (most recent call last):
> File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 144, in 
> get_signatures
>   stderr=subprocess.PIPE)
> File "/usr/lib/python3.4/subprocess.py", line 620, in check_output
>   raise CalledProcessError(retcode, process.args, output=output)
>   subprocess.CalledProcessError: Command 'bitbake -k -S none world' returned 
> non-zero exit status 1
> 
>   Loading cache...done.
>   Loaded 1328 entries from dependency cache.
>   NOTE: Resolving any missing task queue dependencies
>   NOTE: Runtime target 'zlib-qat' is unbuildable, removing...
>   Missing or unbuildable dependency chain was: ['zlib-qat']
>   ...
>   Summary: There were 5 ERROR messages shown, returning a non-zero exit code.
> 
> The yocto-compat-layer.log was incomplete, it only had the first part
> without the command output.
> 
> stderr was missing due to stderr=subprocess.PIPE.
> 
> Instead of the complicated try/except construct it's better to check
> the return code ourselves and raise just a single exception. The
> output (both on stderr and in the yocto-compat-layer.log) now is:
> 
>   INFO: ==
>   INFO: ERROR: test_signatures (common.CommonCompatLayer)
>   INFO: --
>   INFO: Traceback (most recent call last):
> File "/fast/work/poky/scripts/lib/compatlayer/cases/common.py", line 51, 
> in test_signatures
>   curr_sigs = get_signatures(self.td['builddir'], failsafe=True)
> File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 147, in 
> get_signatures
>   raise RuntimeError(msg)
>   RuntimeError: Generating signatures failed. This might be due to some parse 
> error and/or general layer incompatibilities.
>   Command: bitbake -k -S none world
>   Output:
>   Loading cache...done.
>   Loaded 1328 entries from dependency cache.
>   NOTE: Resolving any missing task queue dependencies
>   ERROR: Nothing PROVIDES 'qat16' (but 
> /fast/work/meta-intel/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb
>  DEPENDS on or otherwise requires it)
>   ERROR: qat16 was skipped: incompatible with machine qemux86 (not in 
> COMPATIBLE_MACHINE)
>   ...
>   Missing or unbuildable dependency chain was: ['openssl-qat-dev']
>   ...
>   Summary: There were 5 ERROR messages shown, returning a non-zero exit code.
> 
> Signed-off-by: Patrick Ohly 
> ---
>  scripts/lib/compatlayer/__init__.py | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/scripts/lib/compatlayer/__init__.py 
> b/scripts/lib/compatlayer/__init__.py
> index b3a166aa9ab..a7eb8625310 100644
> --- a/scripts/lib/compatlayer/__init__.py
> +++ b/scripts/lib/compatlayer/__init__.py
> @@ -135,17 +135,15 @@ def get_signatures(builddir, failsafe=False):
>  
>  sigs = {}
>  
> -try:
> -cmd = 'bitbake '
> -if failsafe:
> -cmd += '-k '
> -cmd += '-S none world'
> -output = subprocess.check_output(cmd, shell=True,
> -stderr=subprocess.PIPE)
> -except subprocess.CalledProcessError as e:
> -import traceback
> -exc = traceback.format_exc()
> -msg = '%s\n%s\n' % (exc, e.output.decode('utf-8'))
> +cmd = 'bitbake '
> +if failsafe:
> +cmd += '-k '
> +cmd += '-S none world'
> +p = subprocess.Popen(cmd, shell=True,
> + stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
> +output, _ = 

[OE-core] [PATCH] sanity.bbclass: modify check for shell

[Juro Bystricky]

Due to the recently implemented update-alternatives for bash binary,
sanity checker may end up with a (false-positive) error such as:

Error, /bin/sh links to /bin/bash.bash, must be dash or bash

This patch modifies the test: presence of "/bash" or "/dash" in shell binary
name results in pass.

[YOCTO#11108]

Signed-off-by: Juro Bystricky 
---
 meta/classes/sanity.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index b5f4756..e3be40b 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -935,7 +935,9 @@ def check_sanity_everybuild(status, d):
 # If /bin/sh is a symlink, check that it points to dash or bash
 if os.path.islink('/bin/sh'):
 real_sh = os.path.realpath('/bin/sh')
-if not real_sh.endswith('/dash') and not real_sh.endswith('/bash'):
+# Due to update-alternatives, the shell name may take various
+# forms, such as /bin/dash, bin/bash, /bin/bash.bash ...
+if '/dash' not in real_sh and '/bash' not in real_sh:
 status.addresult("Error, /bin/sh links to %s, must be dash or 
bash\n" % real_sh)
 
 def check_sanity(sanity_data):
-- 
2.7.4

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

Re: [OE-core] [krogoth][PATCH] gstreamer1.0-libav: Add 'valgrind' config option

[Denys Dmytriyenko]

FWIW, it still doesn't seem to fully work...

I just got this exact error in my morty build. My packageconfigs are:

PACKAGECONFIG="orc yasm"
PACKAGECONFIG_CONFARGS=" --disable-gpl --enable-orc --disable-valgrind 
--enable-yasm"


On Thu, Nov 10, 2016 at 03:44:09PM +0100, Martin Jansa wrote:
> From: Otavio Salvador 
> 
> This fixes following error:
> 
> ,
> | src/libavutil/log.c:51:31: fatal error: valgrind/valgrind.h: No such file 
> or directory
> |  #include 
> `
> 
> Signed-off-by: Otavio Salvador 
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
> index 363101e..2814a58 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav.inc
> @@ -18,6 +18,7 @@ PACKAGECONFIG[gpl] = "--enable-gpl,--disable-gpl,"
>  PACKAGECONFIG[libav] = "--with-system-libav,,libav"
>  PACKAGECONFIG[orc] = "--enable-orc,--disable-orc,orc"
>  PACKAGECONFIG[yasm] = "--enable-yasm,--disable-yasm,yasm-native"
> +PACKAGECONFIG[valgrind] = "--enable-valgrind,--disable-valgrind,valgrind"
>  
>  GSTREAMER_1_0_DEBUG ?= "--disable-debug"
>  
> -- 
> 2.10.2
> 
> -- 
> ___
> 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 1/3] rpm: add support for remote package feeds via PACKAGE_FEED_URIS variable

[Richard Purdie]

On Wed, 2017-03-15 at 15:38 +, Ibarra Lopez, Humberto wrote:
> Sorry, missed the previous mail.
> 
> I am not sure how to improve the hardcoding there, I don't like it
> either, but couldn't find an alternative. The thing is that we need
> the ip of the host as seen from the target to run testimage, but we
> don’t have the exact value for that one until qemu is up. The issue
> here is that we need to give this ip to the conf in the
> PACKAGE_FEED_URIS before building so we can get an image with this
> var to later use in testimage.
> 
> If someone has a better idea to get rid of this hardcoding, it would
> be great to know.

We could run a sed command inside the image after it boots but before
triggering the tests to put the correct IP/port number into the file?

Not a perfect test but simple and probably good enough for this?

Cheers,

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

Re: [OE-core] [PATCH 1/3] rpm: add support for remote package feeds via PACKAGE_FEED_URIS variable

[Ibarra Lopez, Humberto]

Sorry, missed the previous mail.

I am not sure how to improve the hardcoding there, I don't like it either, but 
couldn't find an alternative. The thing is that we need the ip of the host as 
seen from the target to run testimage, but we don’t have the exact value for 
that one until qemu is up. The issue here is that we need to give this ip to 
the conf in the PACKAGE_FEED_URIS before building so we can get an image with 
this var to later use in testimage.

If someone has a better idea to get rid of this hardcoding, it would be great 
to know.

-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Sent: Wednesday, March 15, 2017 5:19 AM
To: Burton, Ross 
Cc: OE-core ; Ibarra Lopez, Humberto 

Subject: Re: [OE-core] [PATCH 1/3] rpm: add support for remote package feeds 
via PACKAGE_FEED_URIS variable

On 03/15/2017 01:13 PM, Burton, Ross wrote:
>
> +cls.repo_server.port = 8080
>
>
> What if parallel selftests are running at once?  Can this service be 
> started before the image is created, so the right port can be written 
> into the image?

I don't know. I only followed what Humberto wrote in the original patch; we 
need to ask him. I'm also not entirely certain that hardcoding the ip address 
will always work, and did not get an answer to that.

Another, more hackish option is to monkey patch the ephemeral port before 
running dnf into the repo config on the image.

Alex

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

Re: [OE-core] Create more than one image with WIC

[Patrick Ohly]

On Wed, 2017-03-15 at 16:47 +0200, Ed Bartosh wrote:
> On Wed, Mar 15, 2017 at 04:01:43PM +0200, Ed Bartosh wrote:
> > On Wed, Mar 15, 2017 at 02:41:34PM +0100, Patrick Ohly wrote:
> > > On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> > > > On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> > > > > Regarding do_rm_work. It should not touch rootfs directories, I 
> > > > > believe.
> > > > 
> > 
> > > It does, and it should by default because a rootfs can be quite large.
> > > If it's not going to be reused in another recipe, then it is worthwhile
> > > to remove it.
> > This is true unless we're going to use wic as a stand-alone tool, which some
> > people still do.
> > 
> > > I should add that RM_WORK_EXCLUDE_ITEMS += "rootfs" can be used in image
> > > recipes which know that their rootfs is going to be needed elsewhere -
> > > it's just not the default.
> > 
> > Isn't rootfs going to be rebuilt if one rootfs recipe depends on another 
> > one?
> 
> Here is an example of dependency I'm talking about:
> wic-image-minimal can be built just fine with enabled rm_work.
> Its .wks uses 2 rootfs: core-image-minimal and wic-image-minimal.
> 
> I didn't use any RM_WORK_EXCLUDE_ITEMS. I did specified dependency to
> core-image-minimal in wic-image-minimal recipe:
> 
> # core-image-minimal is referenced in .wks, so we need its rootfs
> # to be ready before our rootfs
> do_rootfs[depends] += "core-image-minimal:do_image 
> core-image-minimal:do_rootfs_wicenv"
> 
> Am I missing something here?

I'm pretty sure you have a race condition, you just haven't triggered
the failure case.

Perhaps you were also lucky because my "rm_work.bbclass: re-enable
recursive do_rm_work_all" is pending and thus
core-image-minimal:do_rm_work never ran at all.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] Create more than one image with WIC

[Patrick Ohly]

On Wed, 2017-03-15 at 16:01 +0200, Ed Bartosh wrote:
> On Wed, Mar 15, 2017 at 02:41:34PM +0100, Patrick Ohly wrote:
> > On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> > > On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> > > > Regarding do_rm_work. It should not touch rootfs directories, I believe.
> > > 
> 
> > It does, and it should by default because a rootfs can be quite large.
> > If it's not going to be reused in another recipe, then it is worthwhile
> > to remove it.
> This is true unless we're going to use wic as a stand-alone tool, which some
> people still do.
> 
> > I should add that RM_WORK_EXCLUDE_ITEMS += "rootfs" can be used in image
> > recipes which know that their rootfs is going to be needed elsewhere -
> > it's just not the default.
> 
> Isn't rootfs going to be rebuilt if one rootfs recipe depends on another one?

No, that's now how it works. Suppose there's a
image-a:do_image_wic->image-b:do_rootfs task dependency. That dependency
ensures that image-b:do_rootfs runs before image-a:do_image_wic. But it
does not delay image-b:do_rm_work until image-a:do_image_wic is done.

That could be fixed by also adding a
image-b:do_rm_work->image-a:do_image_wic dependency. As I said,
something that works out of the box for this use case would be nice...
we can't expect developers to figure all of this out themselves.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] Create more than one image with WIC

[Ed Bartosh]

On Wed, Mar 15, 2017 at 04:01:43PM +0200, Ed Bartosh wrote:
> On Wed, Mar 15, 2017 at 02:41:34PM +0100, Patrick Ohly wrote:
> > On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> > > On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> > > > Regarding do_rm_work. It should not touch rootfs directories, I believe.
> > > 
> 
> > It does, and it should by default because a rootfs can be quite large.
> > If it's not going to be reused in another recipe, then it is worthwhile
> > to remove it.
> This is true unless we're going to use wic as a stand-alone tool, which some
> people still do.
> 
> > I should add that RM_WORK_EXCLUDE_ITEMS += "rootfs" can be used in image
> > recipes which know that their rootfs is going to be needed elsewhere -
> > it's just not the default.
> 
> Isn't rootfs going to be rebuilt if one rootfs recipe depends on another one?

Here is an example of dependency I'm talking about:
wic-image-minimal can be built just fine with enabled rm_work.
Its .wks uses 2 rootfs: core-image-minimal and wic-image-minimal.

I didn't use any RM_WORK_EXCLUDE_ITEMS. I did specified dependency to
core-image-minimal in wic-image-minimal recipe:

# core-image-minimal is referenced in .wks, so we need its rootfs
# to be ready before our rootfs
do_rootfs[depends] += "core-image-minimal:do_image 
core-image-minimal:do_rootfs_wicenv"

Am I missing something here?

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

Re: [OE-core] what shell programming constructs can we count on in .bbclass files?

[Burton, Ross]

On 15 March 2017 at 12:40, Patrick Ohly  wrote:

> Unfortunately bitbake has problems parsing useful things like $( ). Are
> there open bugs about that and/or is it worth filing enhancement
> requests?
>

Absolutely worth filing bugs.  Worst case, they get marked as duplicates.

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

Re: [OE-core] Create more than one image with WIC

[Ed Bartosh]

On Wed, Mar 15, 2017 at 02:41:34PM +0100, Patrick Ohly wrote:
> On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> > On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> > > Regarding do_rm_work. It should not touch rootfs directories, I believe.
> > 

> It does, and it should by default because a rootfs can be quite large.
> If it's not going to be reused in another recipe, then it is worthwhile
> to remove it.
This is true unless we're going to use wic as a stand-alone tool, which some
people still do.

> I should add that RM_WORK_EXCLUDE_ITEMS += "rootfs" can be used in image
> recipes which know that their rootfs is going to be needed elsewhere -
> it's just not the default.

Isn't rootfs going to be rebuilt if one rootfs recipe depends on another one?

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

[OE-core] [PATCH] selftest: Disable SSTATE_MIRRORS for sstate signing test

[Richard Purdie]

Building ed into an sstate mirror, then leaving it enabled for
oe-selftest -r signing.Signing.test_signing_sstate_archive results in:

NOTE: recipe ed-1.14.1-r0: task do_populate_lic_setscene: Started
WARNING: ed-1.14.1-r0 do_populate_lic_setscene: Failed to fetch URL 
file://29/sstate:ed::1.14.1:r0::3:290bbc39f3b25cc27028dafce4b5aa48_populate_lic.tgz.sig;downloadfilename=29/sstate:ed::1.14.1:r0::3:290bbc39f3b25cc27028dafce4b5aa48_populate_lic.tgz.sig,
 attempting MIRRORS if available
ERROR: ed-1.14.1-r0 do_populate_lic_setscene: Fetcher failure: Unable to find 
file 
file://29/sstate:ed::1.14.1:r0::3:290bbc39f3b25cc27028dafce4b5aa48_populate_lic.tgz.sig;downloadfilename=29/sstate:ed::1.14.1:r0::3:290bbc39f3b25cc27028dafce4b5aa48_populate_lic.tgz.sig
 anywhere. The paths that were searched were:
/media/build1/poky/build/test-sstate
/media/build1/poky/build/test-sstate
WARNING: ed-1.14.1-r0 do_populate_lic_setscene: Cannot verify signature on 
sstate package 
/media/build1/poky/build/test-sstate/29/sstate:ed::1.14.1:r0::3:290bbc39f3b25cc27028dafce4b5aa48_populate_lic.tgz
NOTE: recipe ed-1.14.1-r0: task do_populate_lic_setscene: Succeeded

so we need to disable SSTATE_MIRRORS for this test.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/signing.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/lib/oeqa/selftest/signing.py 
b/meta/lib/oeqa/selftest/signing.py
index 38b2fca..ba44c79 100644
--- a/meta/lib/oeqa/selftest/signing.py
+++ b/meta/lib/oeqa/selftest/signing.py
@@ -108,6 +108,8 @@ class Signing(oeSelfTest):
 feature += 'SSTATE_VERIFY_SIG ?= "1"\n'
 feature += 'GPG_PATH = "%s"\n' % self.gpg_dir
 feature += 'SSTATE_DIR = "%s"\n' % sstatedir
+# Any mirror might have partial sstate without .sig files, triggering 
failures
+feature += 'SSTATE_MIRRORS_forcevariable = ""\n'
 
 self.write_config(feature)
 
-- 
2.7.4

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

Re: [OE-core] Create more than one image with WIC

[Patrick Ohly]

On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> > Regarding do_rm_work. It should not touch rootfs directories, I believe.
> 
> It does, and it should by default because a rootfs can be quite large.
> If it's not going to be reused in another recipe, then it is worthwhile
> to remove it.

I should add that RM_WORK_EXCLUDE_ITEMS += "rootfs" can be used in image
recipes which know that their rootfs is going to be needed elsewhere -
it's just not the default.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] Create more than one image with WIC

[Patrick Ohly]

On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> Regarding do_rm_work. It should not touch rootfs directories, I believe.

It does, and it should by default because a rootfs can be quite large.
If it's not going to be reused in another recipe, then it is worthwhile
to remove it.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] what shell programming constructs can we count on in .bbclass files?

[Robert P. J. Day]

On Wed, 15 Mar 2017, Patrick Ohly wrote:

> On Wed, 2017-03-15 at 11:05 +, Burton, Ross wrote:
> > Our shell parser *should* be POSIX compliant.  There are a few
> > places where it isn't, but I believe those should be considered
> > bugs.  At the end of the day the shell is actually executed by
> > /bin/sh or /bin/bash anyway, so as long as bitbake can parse it
> > you can use anything.
>
> Unfortunately bitbake has problems parsing useful things like $( ).
> Are there open bugs about that and/or is it worth filing enhancement
> requests?

  on a more basic level, there's quite a lot of, i guess, bourne
shell'isms (and other weirdnesses) still lying around. in
meta/classes/, some examples (hoping i didn't screw them up):

  "if test" rather then "if ["

  all that 'if [ "x${VAR} = "x" ]' i mentioned earlier

  if [ "x${ICE_PATH}" = "x" ]   rather than   if [ -z "${ICE_PATH}" ]

  if [ ! -z "${conf_sign_keyname}" ]  ... ?? :-)

none of this is a big deal, but there sure are some historical
holdovers and strangely-chosen constructs.

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] Create more than one image with WIC

[Ed Bartosh]

On Wed, Mar 15, 2017 at 08:24:34AM +0100, Patrick Ohly wrote:
> On Tue, 2017-03-14 at 20:06 +0200, Ed Bartosh wrote:
> > On Tue, Mar 14, 2017 at 06:49:45PM +0100, Patrick Ohly wrote:
> > > 
> > > > It's not a big deal to run wic sequentially to produce multiple images,
> > > > but it will create more problems than it solves I believe. It will be 
> > > > slower and
> > > > will make a mess in image naming in deploy directory.
> > > 
> > > I personally would prefer to support generating more than one wic image
> > > per image recipe. The different output files could be distinguished with
> > > an additional suffix (".efi.wic", ".live.wiC", etc.) where the suffix is
> > > either specified by the WKS file or the configuration where the WKS file
> > > is selected - the latter might be a bit more flexible.
> > >
> > 
> > From my point of view ths would be against the current design of oe
> > image building susbsystem. It would be also more complex and slower
> > unless we'll find a way to dynamically generate multiple image creation
> > tasks per one recipe and run them in parallel. In this case it will be
> > even more complex.
> 
> That's a good point. However, directly sharing the content of the build
> directory from different recipes is also against the OE design and
> requires special attention, for example to suppressing the do_rootfs
> task in one recipe and preventing do_rm_work in the other.
> 
> Either way, something that works out of the box might be useful.

I'm going to address this in near future when I'll be working on
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10073
Feel free to comment on it, btw.

So far the plan is to treat EFI boot partition as a rootfs. wic job
would be to simply put content of multiple rootfs-es into partitions of
the final image. No suppressing of do_rootfs would be needed, I hope.

Regarding do_rm_work. It should not touch rootfs directories, I believe.

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

Re: [OE-core] [PATCH 1/3] rpm: add support for remote package feeds via PACKAGE_FEED_URIS variable

[Patrick Ohly]

On Wed, 2017-03-15 at 13:19 +0200, Alexander Kanavin wrote:
> On 03/15/2017 01:13 PM, Burton, Ross wrote:
> >
> > +cls.repo_server.port = 8080
> >
> >
> > What if parallel selftests are running at once?  Can this service be
> > started before the image is created, so the right port can be written
> > into the image?
> 
> I don't know. I only followed what Humberto wrote in the original patch; 
> we need to ask him. I'm also not entirely certain that hardcoding the ip 
> address will always work, and did not get an answer to that.
> 
> Another, more hackish option is to monkey patch the ephemeral port 
> before running dnf into the repo config on the image.

Or perhaps use ssh with port forwarding? Then the host-side port can be
picked randomly, while on the target side it can be fixed.

I was about to suggest qemu slirp networking because that also does port
mapping, but I think ssh port forwarding is better.

-- 
Best Regards, Patrick Ohly

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



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

Re: [OE-core] what shell programming constructs can we count on in .bbclass files?

[Patrick Ohly]

On Wed, 2017-03-15 at 11:05 +, Burton, Ross wrote:
> Our shell parser *should* be POSIX compliant.  There are a few places
> where it isn't, but I believe those should be considered bugs.  At the
> end of the day the shell is actually executed by /bin/sh or /bin/bash
> anyway, so as long as bitbake can parse it you can use anything.

Unfortunately bitbake has problems parsing useful things like $( ). Are
there open bugs about that and/or is it worth filing enhancement
requests?



-- 
Best Regards, Patrick Ohly

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



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

[OE-core] [PATCHv2] ccache: Disable CCACHE_HASHDIR by default

[Mike Crowe]

As of ccache-3.3, ccache tries to ensure that the paths in the debug
information are always correct. It does this by including the current
directory in the hash if debug output is enabled. It includes support for
detecting remapping via a single -fdebug-prefix-map argument uses the
remapped directory in the hash instead.

The DEBUG_PREFIX_MAP in bitbake.conf remaps the source directory, target
sysroot and native sysroot separately which results in multiple
-fdebug-prefix-map arguments. Although ccache passes all these arguments
through to the compiler, it only enables the special behaviour described
above if the last one matches the current directory. (See
https://github.com/ccache/ccache/issues/163 )

Even if ccache did correctly honour each of the remapping arguments, the
hashes would still be different every time ${PV} or ${PR} change because
the default DEBUG_PREFIX_MAP contains maps to paths including them.

So it seems that for ccache to be of any use with this configuration,
CCACHE_NOHASHDIR needs to be set.

Signed-off-by: Mike Crowe 
Helped-by: Ross Burton 
---
 meta/classes/ccache.bbclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass
index 76c8828..9713fea 100644
--- a/meta/classes/ccache.bbclass
+++ b/meta/classes/ccache.bbclass
@@ -2,6 +2,12 @@ CCACHE = "${@bb.utils.which(d.getVar('PATH'), 'ccache') and 
'ccache '}"
 export CCACHE_DIR ?= "${TMPDIR}/ccache/${MULTIMACH_HOST_SYS}/${PN}"
 CCACHE_DISABLE[unexport] = "1"
 
+# We need to stop ccache considering the current directory or the
+# debug-prefix-map target directory to be significant when calculating
+# its hash. Without this the cache would be invalidated every time
+# ${PV} or ${PR} change.
+export CCACHE_NOHASHDIR ?= "1"
+
 DEPENDS_append_class-target = " ccache-native"
 DEPENDS[vardepvalueexclude] = " ccache-native"
 
-- 
2.1.4

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

Re: [OE-core] [PATCH] ccache: Disable CCACHE_HASHDIR by default

[Mike Crowe]

On Monday 13 March 2017 at 13:51:46 +, Mike Crowe wrote:
> On Monday 13 March 2017 at 13:33:27 +, Burton, Ross wrote:
> > On 11 March 2017 at 16:54, Mike Crowe  wrote:
> > 
> > > ccache apparently does this so that paths in the debug information will
> > > always be correct. In an OE world these paths may already be missing or
> > > incorrect due to rm_work or the use of a shared sstate cache, so it 
> > > doesn't
> > > seem as if we're losing much by disabling this feature.
> > >
> > 
> > In an OE world we tell GCC to rewrite them to be target paths anyway, so
> > this isn't a problem.  Maybe worth rewriting the commit message?
> > 
> > (see bitbake.conf, -fdebug-prefix-map)
> 
> I wasn't aware of that.
> 
> ccache does have some technology to detect this situation:
> 
>   Exception: The CWD will not be included in the hash if *base_dir* is set
>   (and matches the CWD) and the compiler option *-fdebug-prefix-map* is
>   used.
> 
> I think this means that if CCACHE_BASEDIR is set appropriately then it
> wouldn't be necessary to set CCACHE_NOHASHDIR. (Looking at the ccache code,
> I think that "matches the CWD" means "CWD is under *base_dir*" rather than
> the two needing to be identical.)
> 
> I shall investigate why things weren't working correctly for us. In the
> meantime I don't think my patch is yet proven to be doing the right thing.

Unfortunately ccache only supports this special behaviour for the last
-fdebug-prefix-map argument. All the arguments make it through to the
compiler, but the last one isn't enough to stop the current directory being
hashed by default.

I've raised this as https://github.com/ccache/ccache/issues/163 .

It seems that for the time being setting CCACHE_NOHASHDIR is required to
make ccache effective for us. I'll reword the commit message based on
Ross's input and this information.

Thanks.

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

Re: [OE-core] [PATCH 1/3] rpm: add support for remote package feeds via PACKAGE_FEED_URIS variable

[Alexander Kanavin]

On 03/15/2017 01:13 PM, Burton, Ross wrote:


+cls.repo_server.port = 8080


What if parallel selftests are running at once?  Can this service be
started before the image is created, so the right port can be written
into the image?


I don't know. I only followed what Humberto wrote in the original patch; 
we need to ask him. I'm also not entirely certain that hardcoding the ip 
address will always work, and did not get an answer to that.


Another, more hackish option is to monkey patch the ephemeral port 
before running dnf into the repo config on the image.


Alex

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

Re: [OE-core] [PATCH 1/3] rpm: add support for remote package feeds via PACKAGE_FEED_URIS variable

[Burton, Ross]

On 14 March 2017 at 17:27, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> +cls.repo_server.port = 8080
>

What if parallel selftests are running at once?  Can this service be
started before the image is created, so the right port can be written into
the image?

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

Re: [OE-core] what shell programming constructs can we count on in .bbclass files?

[Burton, Ross]

On 15 March 2017 at 10:44, Robert P. J. Day  wrote:

>   what shell (or level of POSIX compatibility) does one assume for
> writing shell functions in .bbclass files?
>
>   i'm looking at kernel-fitimage.bbclass and i see this:
>
>   #
>   # Step 7: Sign the image and add public key to U-Boot dtb
>   #
>   if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ] ; then
>
> surely we don't still need to use that ugly "x" prefix hack for string
> comparisons, do we?
>
>   a bit further down:
>
>   do_assemble_fitimage_initramfs() {
> if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
> test -n "${INITRAMFS_IMAGE}" ; then
>
> would it not be equivalent to write that second test as:
>
>   [ -n "${INITRAMFS_IMAGE}"]
>
> and so on. what are we allowed to count on?
>

xFOO = xBAR appears to be a long-standing hangover from the 70s, any POSIX
shell should be safe with quoted instead.

Our shell parser *should* be POSIX compliant.  There are a few places where
it isn't, but I believe those should be considered bugs.  At the end of the
day the shell is actually executed by /bin/sh or /bin/bash anyway, so as
long as bitbake can parse it you can use anything.

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

[OE-core] what shell programming constructs can we count on in .bbclass files?

[Robert P. J. Day]

  what shell (or level of POSIX compatibility) does one assume for
writing shell functions in .bbclass files?

  i'm looking at kernel-fitimage.bbclass and i see this:

  #
  # Step 7: Sign the image and add public key to U-Boot dtb
  #
  if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ] ; then

surely we don't still need to use that ugly "x" prefix hack for string
comparisons, do we?

  a bit further down:

  do_assemble_fitimage_initramfs() {
if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
test -n "${INITRAMFS_IMAGE}" ; then

would it not be equivalent to write that second test as:

  [ -n "${INITRAMFS_IMAGE}"]

and so on. what are we allowed to count on?

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] yocto-compat-layer: improve error handling in signature creation

[Patrick Ohly]

When "bitbake -k -S none world" failed, the error printed by
yocto-compat-layer.py contained the stack trace multiple times and did not
contain the stderr output from bitbake, making the error hard to understand
and debug:

  INFO: ==
  INFO: ERROR: test_signatures (common.CommonCompatLayer)
  INFO: --
  INFO: Traceback (most recent call last):
File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 144, in 
get_signatures
  stderr=subprocess.PIPE)
File "/usr/lib/python3.4/subprocess.py", line 620, in check_output
  raise CalledProcessError(retcode, process.args, output=output)
  subprocess.CalledProcessError: Command 'bitbake -k -S none world' returned 
non-zero exit status 1

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/fast/work/poky/scripts/lib/compatlayer/cases/common.py", line 51, in 
test_signatures
  curr_sigs = get_signatures(self.td['builddir'], failsafe=True)
File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 149, in 
get_signatures
  raise RuntimeError(msg)
  RuntimeError: Traceback (most recent call last):
File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 144, in 
get_signatures
  stderr=subprocess.PIPE)
File "/usr/lib/python3.4/subprocess.py", line 620, in check_output
  raise CalledProcessError(retcode, process.args, output=output)
  subprocess.CalledProcessError: Command 'bitbake -k -S none world' returned 
non-zero exit status 1

  Loading cache...done.
  Loaded 1328 entries from dependency cache.
  NOTE: Resolving any missing task queue dependencies
  NOTE: Runtime target 'zlib-qat' is unbuildable, removing...
  Missing or unbuildable dependency chain was: ['zlib-qat']
  ...
  Summary: There were 5 ERROR messages shown, returning a non-zero exit code.

The yocto-compat-layer.log was incomplete, it only had the first part
without the command output.

stderr was missing due to stderr=subprocess.PIPE.

Instead of the complicated try/except construct it's better to check
the return code ourselves and raise just a single exception. The
output (both on stderr and in the yocto-compat-layer.log) now is:

  INFO: ==
  INFO: ERROR: test_signatures (common.CommonCompatLayer)
  INFO: --
  INFO: Traceback (most recent call last):
File "/fast/work/poky/scripts/lib/compatlayer/cases/common.py", line 51, in 
test_signatures
  curr_sigs = get_signatures(self.td['builddir'], failsafe=True)
File "/fast/work/poky/scripts/lib/compatlayer/__init__.py", line 147, in 
get_signatures
  raise RuntimeError(msg)
  RuntimeError: Generating signatures failed. This might be due to some parse 
error and/or general layer incompatibilities.
  Command: bitbake -k -S none world
  Output:
  Loading cache...done.
  Loaded 1328 entries from dependency cache.
  NOTE: Resolving any missing task queue dependencies
  ERROR: Nothing PROVIDES 'qat16' (but 
/fast/work/meta-intel/common/recipes-extended/openssl-qat/openssl-qat_0.4.9-009.bb
 DEPENDS on or otherwise requires it)
  ERROR: qat16 was skipped: incompatible with machine qemux86 (not in 
COMPATIBLE_MACHINE)
  ...
  Missing or unbuildable dependency chain was: ['openssl-qat-dev']
  ...
  Summary: There were 5 ERROR messages shown, returning a non-zero exit code.

Signed-off-by: Patrick Ohly 
---
 scripts/lib/compatlayer/__init__.py | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index b3a166aa9ab..a7eb8625310 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -135,17 +135,15 @@ def get_signatures(builddir, failsafe=False):
 
 sigs = {}
 
-try:
-cmd = 'bitbake '
-if failsafe:
-cmd += '-k '
-cmd += '-S none world'
-output = subprocess.check_output(cmd, shell=True,
-stderr=subprocess.PIPE)
-except subprocess.CalledProcessError as e:
-import traceback
-exc = traceback.format_exc()
-msg = '%s\n%s\n' % (exc, e.output.decode('utf-8'))
+cmd = 'bitbake '
+if failsafe:
+cmd += '-k '
+cmd += '-S none world'
+p = subprocess.Popen(cmd, shell=True,
+ stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+output, _ = p.communicate()
+if p.returncode:
+msg = "Generating signatures failed. This might be due to some parse 
error and/or general layer incompatibilities.\nCommand: %s\nOutput:\n%s" % 
(cmd, output.decode('utf-8'))
 raise RuntimeError(msg)
 sigs_file = os.path.join(builddir, 'locked-sigs.inc')
 
-- 

[OE-core] is there a bitbake command/task for removing just KERNEL_IMAGETYPES?

[Robert P. J. Day]

  sort of related to an earlier question i asked on YP list ... i'm
playing with introducing and generating different KERNEL_IMAGETYPES,
and i want to be able to remove *just* those generated kernel image
types before trying a different variation by setting:

  KERNEL_CLASSES
  KERNEL_IMAGETYPES

to different values.

  if i run:

  $ bitbake -c cleansstate virtual/kernel

that *seems* to get rid of the raw kernel binary as well, so it has to
be recompiled. all i want to do is get rid of any uImage, zImage,
fitImage files and not have to recompile the entire kernel.

  is there a kernel task for that, or can i just manually "rm" them to
get the same effect?

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] [jethro][PATCH] gcc-multilib-config: make aarch64 support multilib

[zhengrq]

  Fixed:
  MACHINE = qemuarm64
  require conf/multilib.conf
  MULTILIBS = "multilib:lib32"
  DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"

  $ bitbake core-image-minimal -cpopulate_sdk

  WARNING: gcc multilib setup is not supported for TARGET_ARCH=aarch64
  WARNING: gcc multilib setup is not supported for TARGET_ARCH=aarch64

  [YOCTO #8638]

  (From OE-Core rev: 0ae52c8b2c1d7d7cdbcfeeae6ff42e64f16bc41d)

Signed-off-by: Robert Yang 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-devtools/gcc/gcc-multilib-config.inc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-multilib-config.inc 
b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
index 1c0a45a..a0a2ac0 100644
--- a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
+++ b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
@@ -29,6 +29,9 @@ python gcc_multilib_setup() {
 bb.utils.remove(build_conf_dir, True)
 ml_globs = ('%s/*/t-linux64' % src_conf_dir,
 '%s/*/linux64.h' % src_conf_dir,
+'%s/aarch64/t-aarch64' % src_conf_dir,
+'%s/aarch64/aarch64.h' % src_conf_dir,
+'%s/aarch64/aarch64-cores.def' % src_conf_dir,
 '%s/*/linux.h' % src_conf_dir,
 '%s/linux.h' % src_conf_dir)
 
@@ -130,6 +133,8 @@ python gcc_multilib_setup() {
 'mips64': ['gcc/config/mips/t-linux64'],
 'powerpc'   : ['gcc/config/rs6000/t-linux64'],
 'powerpc64' : ['gcc/config/rs6000/t-linux64'],
+'aarch64'   : ['gcc/config/aarch64/t-aarch64'],
+'arm'   : ['gcc/config/aarch64/t-aarch64'],
 }
 
 gcc_header_config_files = {
@@ -140,6 +145,8 @@ python gcc_multilib_setup() {
 'mips64': ['gcc/config/mips/linux.h', 'gcc/config/mips/linux64.h'],
 'powerpc'   : ['gcc/config/rs6000/linux64.h'],
 'powerpc64' : ['gcc/config/rs6000/linux64.h'],
+'aarch64'   : ['gcc/config/aarch64/aarch64.h'],
+'arm'   : ['gcc/config/aarch64/aarch64.h'],
 }
 
 libdir32 = 'SYSTEMLIBS_DIR'
-- 
2.7.4



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

[OE-core] RSS-related problem after update to OE-Core with dnf

[Peter Kjellerstedt]

I update my Poky to the latest on master yesterday (i.e., I went from 
a version using smart to one using dnf) and when I rebuilt my image I 
got the following error:

| cd ${WORKDIR}/build/ext && ${WORKDIR}/recipe-sysroot-native/usr/bin/cmake -E 
cmake_link_script CMakeFiles/libsolvext.dir/link.txt --verbose=1
| 
${WORKDIR}/recipe-sysroot-native/usr/bin/mipsel-poky-linux/mipsel-poky-linux-gcc
  -fPIC -mel -mabi=32 -msoft-float -march=34kc -msynci  
--sysroot=${WORKDIR}/recipe-sysroot  -O2 -pipe -g 
-feliminate-unused-debug-types 
-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/libsolv/0.6.26-r0 
-fdebug-prefix-map=${WORKDIR}/recipe-sysroot-native= 
-fdebug-prefix-map=${WORKDIR}/recipe-sysroot=  -fstack-protector-strong 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -mel 
-mabi=32 -msoft-float -march=34kc -msynci  --sysroot=${WORKDIR}/recipe-sysroot 
-Wall -fPIC -Wl,-O1  -Wl,--as-needed -fstack-protector-strong 
-Wl,-z,relro,-z,now  -Wl,--version-script=${WORKDIR}/git/ext/libsolvext.ver 
-shared -Wl,-soname,libsolvext.so.0 -o libsolvext.so.0 
CMakeFiles/libsolvext.dir/solv_xfopen.o CMakeFiles/libsolvext.dir/testcase.o 
CMakeFiles/libsolvext.dir/pool_fileconflicts.o 
CMakeFiles/libsolvext.dir/repo_rpmdb.o 
CMakeFiles/libsolvext.dir/repo_repomdxml.o CMakeFiles/libsolvext.dir/rep
 o_rpmmd.o CMakeFiles/libsolvext.dir/repo_deltainfoxml.o 
CMakeFiles/libsolvext.dir/repo_updateinfoxml.o 
-Wl,-rpath,${WORKDIR}/build/src:${WORKDIR}/recipe-sysroot-native/usr/lib: 
../src/libsolv.so.0 -Wl,--as-needed -ldb -lrpmio 
${WORKDIR}/recipe-sysroot-native/usr/lib/librpmdb.so -lexpat -lz
| ${WORKDIR}/recipe-sysroot-native/usr/lib/librpmdb.so: error adding symbols: 
File in wrong format

When I ran file on librpmdb.so it showed:

$ file ${WORKDIR}/recipe-sysroot-native/usr/lib/librpmdb-5.4.so
${WORKDIR}/recipe-sysroot-native/usr/lib/librpmdb-5.4.so: ELF 64-bit LSB shared 
object, x86-64, version 1 (SYSV), dynamically linked, 
BuildID[sha1]=0xb49c3f89085d16c65bb443622e68cbbfdae605cb, stripped

I.e., it is trying to link a MIPS library with an x86_64 one...

After I did a "bitbake libsolv -c cleansstate", the problem went away, 
and checking the log.do_compile afterwards it seems it is not even 
trying to link with librpmdb.so at all any more.

My guess is that the librpmdb.so (which was a link to librpmdb-5.4.so) 
was a leftover from before the switch from smart to dnf. However, the 
fact that it remained in ${WORKDIR}/recipe-sysroot-native AND that it 
was picked up by the build indicates both a problem with the 
determinism of RSS, and the with the build of libsolv itself.

//Peter

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

Re: [OE-core] [PATCH 00/44] Replace Smart package manager with DNF package manager

[Alexander Kanavin]

On 03/14/2017 11:12 PM, Robert P. J. Day wrote:

  is there, somewhere, a short writeup/summary on this? i can see
emails to this list back in october of last year, just wondering if
there is a wrap-up to this that one can read to pull all the threads
together to understand the consequences.


Yes there is. It's in the cover letter of the patchset (look at the 
latest version, so the information is most up to date). There's also a 
link there to the more detailed writeup I posted to 
openembedded-architecture.


Alex

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

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

[José Bollo]

On Thu, 09 Mar 2017 18:18:05 +0100
Patrick Ohly  wrote:

> On Thu, 2017-03-09 at 17:48 +0100, José Bollo wrote:
> > On Thu, 09 Mar 2017 17:07:54 +0100
> > Patrick Ohly  wrote:  
> > > Can't you reorder and rebase the patches so that this
> > > 0001-useradd.c-create-parent-directories-when-necessary.patch
> > > applies on top of the patch which was submitted upstream?  
> > 
> > I agree that it would be better to reorder. Better but less
> > conservative because an existing patch must be upgraded.  
> 
> If upstream merges the proposed patch, then rebasing will be
> inevitable at some point, so we might as well do the cleaner solution
> now, even if the diff becomes larger.
> 
> > > "devtool modify shadow-native" might be useful for that. "git
> > > rebase -i" in workspace/sources/shadow-native", then finish with
> > > "devtool update-recipe shadow-native". I haven't tried whether
> > > "update-recipe" handles re-ordering patches. If it doesn't, just
> > > fix it manually.  
> > 
> > I'll do and propose the new version soon.  
> 
> Thanks!
> 

I pushed a new version of the patch this monday. I suppose that it is
waiting for approval.

Best regards
José Bollo

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

Re: [OE-core] Create more than one image with WIC

[Patrick Ohly]

On Tue, 2017-03-14 at 20:06 +0200, Ed Bartosh wrote:
> On Tue, Mar 14, 2017 at 06:49:45PM +0100, Patrick Ohly wrote:
> > 
> > > It's not a big deal to run wic sequentially to produce multiple images,
> > > but it will create more problems than it solves I believe. It will be 
> > > slower and
> > > will make a mess in image naming in deploy directory.
> > 
> > I personally would prefer to support generating more than one wic image
> > per image recipe. The different output files could be distinguished with
> > an additional suffix (".efi.wic", ".live.wiC", etc.) where the suffix is
> > either specified by the WKS file or the configuration where the WKS file
> > is selected - the latter might be a bit more flexible.
> >
> 
> From my point of view ths would be against the current design of oe
> image building susbsystem. It would be also more complex and slower
> unless we'll find a way to dynamically generate multiple image creation
> tasks per one recipe and run them in parallel. In this case it will be
> even more complex.

That's a good point. However, directly sharing the content of the build
directory from different recipes is also against the OE design and
requires special attention, for example to suppressing the do_rootfs
task in one recipe and preventing do_rm_work in the other.

Either way, something that works out of the box might be useful.

-- 
Best Regards, Patrick Ohly

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



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