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

[Koen Kooi]

> Op 12 jul. 2018, om 12:03 heeft Chen Qi  het volgende 
> geschreven:
> 
> Upgrade systemd to 239.



When enabling importd I get:

WARNING: systemd-1_239-r0 do_package: QA Issue: systemd: Files/directories were 
installed but not shipped in any package:
  /usr/share/dbus-1/system.d/org.freedesktop.import1.conf

So you need something like this on top of your patchset:

@@ -379,6 +379,7 @@ FILES_${PN}-container = 
"${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.c
  ${libdir}/libnss_mymachines.so.2 \
  
${datadir}/dbus-1/system-services/org.freedesktop.import1.service \
  
${datadir}/dbus-1/system-services/org.freedesktop.machine1.service \
+ 
${datadir}/dbus-1/system.d/org.freedesktop.import1.conf \
  
${datadir}/dbus-1/system.d/org.freedesktop.machine1.conf \
  
${datadir}/polkit-1/actions/org.freedesktop.import1.policy \
  
${datadir}/polkit-1/actions/org.freedesktop.machine1.policy \

regards,

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

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Koen Kooi]

> Op 9 jun. 2018, om 08:26 heeft Randy Li  het volgende 
> geschreven:
> 
> I read the ARMv8 manual again, it looks the hardware float is mandatory
> in Linux Distributions and toolchain libraries. Even some cortex
> processors can be configured without FPU/NEON hardware, but I don't
> think they would be used in openembeded core.
> 
> So I can assume the NEON(SIMD) would exist all the time. Leaving only the
> crc and crypto instructions are optional here.
> 
> 
> Randy Li (4):
>  arch-armv8a.inc: add tune include for armv8
>  tune-cortexa35: add tunes for ARM Cortex-A35
>  tune-cortexa32: add tunes for ARM Cortex-A32
>  tune-cortexa72: add tunes for ARM Cortex-A72

Having been forced to deal with the mess that’s 32-bit arm tunes: Let’s only 
add an implementation specific tunes *after* having seem conclusive, repeatable 
benchmark results. 90% of the 32 bit tune files are placebo effect and just 
explode number of package archs in your distro feed. The goal of aarch64 was to 
stop being different for the sake of being different, let’s not make a mess 
because we are used to messes.

regards,

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

[OE-core] [PATCH v2 2/4] libcap: fix (base_)libdir usage

[Koen Kooi]

The recipe wants to install libs into base_libdir, but uses "basename $libdir" 
to derive that. That breaks in a multiarch setup. Use the proper variable and 
remove the inline python usage.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libcap/libcap_2.25.bb 
b/meta/recipes-support/libcap/libcap_2.25.bb
index d619a2e..47ecf34 100644
--- a/meta/recipes-support/libcap/libcap_2.25.bb
+++ b/meta/recipes-support/libcap/libcap_2.25.bb
@@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
 
 EXTRA_OEMAKE = " \
   INDENT=  \
-  lib=${@os.path.basename('${libdir}')} \
+  lib='${base_libdir}' \
   RAISE_SETFCAP=no \
   DYNAMIC=yes \
   BUILD_GPERF=yes \
-- 
2.9.5

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

[OE-core] [PATCH v2 1/4] native bbclass: handle base_libdir as well

[Koen Kooi]

Native.bbclass needs to fixup both base_libdir and libdir to handle things like 
multiarch. This fixes wic and ext4.* image failures during do_rootfs where 
mkfs.ext4 can't find its libraries.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/classes/native.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index a911f2a..7f2df17 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -78,6 +78,7 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
 
 bindir = "${STAGING_BINDIR_NATIVE}"
 sbindir = "${STAGING_SBINDIR_NATIVE}"
+base_libdir = "${STAGING_LIBDIR_NATIVE}"
 libdir = "${STAGING_LIBDIR_NATIVE}"
 includedir = "${STAGING_INCDIR_NATIVE}"
 sysconfdir = "${STAGING_ETCDIR_NATIVE}"
@@ -89,6 +90,7 @@ export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} 
${base_libdir} /lib /lib64
 
 NATIVE_PACKAGE_PATH_SUFFIX ?= ""
 bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
+base_libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libexecdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 
-- 
2.9.5

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

[OE-core] [PATCH v2 3/4] bind: fix openSSL detection when using multiarch

[Koen Kooi]

In multiarch /usr/include and /usr/lib/
---
 meta/recipes-connectivity/bind/bind_9.10.6.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bind/bind_9.10.6.bb 
b/meta/recipes-connectivity/bind/bind_9.10.6.bb
index 8b8835b..20c8d7b 100644
--- a/meta/recipes-connectivity/bind/bind_9.10.6.bb
+++ b/meta/recipes-connectivity/bind/bind_9.10.6.bb
@@ -35,7 +35,7 @@ EXTRA_OECONF = " ${ENABLE_IPV6} --with-libtool 
--enable-threads \
  --disable-devpoll --enable-epoll --with-gost=no \
  --with-gssapi=no --with-ecdsa=yes \
  --sysconfdir=${sysconfdir}/bind \
- --with-openssl=${STAGING_LIBDIR}/.. \
+ --with-openssl=${STAGING_DIR_HOST}${prefix} \
"
 
 inherit autotools update-rc.d systemd useradd pkgconfig python3-dir
-- 
2.9.5

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

[OE-core] [PATCH v2 4/4] python 2.7: fix multilib patch to accept multiarch style paths

[Koen Kooi]

Using 'basename' to strip the prefix fails when using multiarch style paths.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-devtools/python/python.inc| 6 ++
 meta/recipes-devtools/python/python/multilib.patch | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python.inc 
b/meta/recipes-devtools/python/python.inc
index 979b601..84bcb6a 100644
--- a/meta/recipes-devtools/python/python.inc
+++ b/meta/recipes-devtools/python/python.inc
@@ -33,6 +33,12 @@ EXTRA_OECONF = "\
   ${PYTHONLSBOPTS} \
 "
 
+do_configure_prepend() {
+   libdirleaf="$(echo ${libdir} | sed -e 's:${prefix}/::')"
+   sed -i -e "s:SEDMELIBLEAF:${libdirleaf}:g" \
+   ${S}/configure.ac
+}
+
 do_install_append () {
sed -i -e 's:${HOSTTOOLS_DIR}/install:install:g' \
-e 's:${HOSTTOOLS_DIR}/mkdir:mkdir:g' \
diff --git a/meta/recipes-devtools/python/python/multilib.patch 
b/meta/recipes-devtools/python/python/multilib.patch
index 1116dd5..d24bc15 100644
--- a/meta/recipes-devtools/python/python/multilib.patch
+++ b/meta/recipes-devtools/python/python/multilib.patch
@@ -11,7 +11,7 @@ Index: Python-2.7.14/configure.ac
  
 +AC_SUBST(LIB)
 +AC_MSG_CHECKING(LIB)
-+LIB=`basename ${libdir}`
++LIB="SEDMELIBLEAF"
 +AC_MSG_RESULT($LIB)
  
  AC_SUBST(LIBRARY)
-- 
2.9.5

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

Re: [OE-core] [PATCH 2/3] bind: fix openSSL detection when using multiarch

[Koen Kooi]

> Op 11 apr. 2018, om 11:25 heeft Koen Kooi <k...@dominion.thruhere.net> het 
> volgende geschreven:

[..]

> There is one change that will need careful consideration if it is meant for 
> sumo, it looks like the sysroot code treats libdir differently from 
> base_libdir:
> 
>   [koen@fedora-vm build-rpb]$ ls 
> tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/lib/
>   x86_64-linux
> 
>   [koen@fedora-vm build-rpb]$ ls 
> tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/usr/lib/
>   aarch64-linaro-linux   libcomps.solibexpat.a  
> libgdbm_compat.so libgthread-2.0.so.0.5400.3  libmpc.so.3.1.0 
>   libparted-fs-resize.so.0.0.1  libpython3.so  libtermcap.so
>   [..]
>   libcheck.so.0.0.0  libelf.so.1libgdbm_compat.a
> libgthread-2.0.so.0   libmpc.so.3 
> libparted-fs-resize.so.0  libpython3.5m.so.1.0  libssl.so.1.0.2
> 
> E2fsprogs installs into base_libdir, which gets the multiarch treatment, and 
> mkfs.ext4 fails to find its libs during image generation. 

The assumption seems to have been correct, trying a build with this change:

[koen@fedora-vm openembedded-core]$ git diff
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index a911f2a..7f2df17 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -78,6 +78,7 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
 
 bindir = "${STAGING_BINDIR_NATIVE}"
 sbindir = "${STAGING_SBINDIR_NATIVE}"
+base_libdir = "${STAGING_LIBDIR_NATIVE}"
 libdir = "${STAGING_LIBDIR_NATIVE}"
 includedir = "${STAGING_INCDIR_NATIVE}"
 sysconfdir = "${STAGING_ETCDIR_NATIVE}"
@@ -89,6 +90,7 @@ export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} 
${base_libdir} /lib /lib64
 
 NATIVE_PACKAGE_PATH_SUFFIX ?= ""
 bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
+base_libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libexecdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 


regards,

Koen

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

Re: [OE-core] [PATCH 2/3] bind: fix openSSL detection when using multiarch

[Koen Kooi]

> Op 9 apr. 2018, om 18:36 heeft Richard Purdie 
> <richard.pur...@linuxfoundation.org> het volgende geschreven:
> 
> On Mon, 2018-04-09 at 13:56 +0200, Koen Kooi wrote:
>> In multiarch /usr/include and /usr/lib/> level anymore. This change will pass a correct includedir, but a
>> wrong libdir, but the linker picks it up anyway.
>> 
>> Tested on multiarch and regular build.
> 
> How far off working is mulitarch for OE-Core?

With the current state of OE-core ‘bitbake bash’ does the right things. I have 
a few patches that make more things work, but those need more testing.

> The reason I ask is I'd like to understand the scope of the changes
> needed to support it. It also influences whether these are sumo or post
> 2.5 changes.

So far all the changes are real bugfixes, like stopping recipes from doing  
‘basename libdir’ to get base_libdir. For things like python I’m running into 
problems where upstream does the right thing, but the OE multilib patches break 
that.

There is one change that will need careful consideration if it is meant for 
sumo, it looks like the sysroot code treats libdir differently from base_libdir:

[koen@fedora-vm build-rpb]$ ls 
tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/lib/
x86_64-linux

[koen@fedora-vm build-rpb]$ ls 
tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/usr/lib/
aarch64-linaro-linux   libcomps.solibexpat.a  
libgdbm_compat.so libgthread-2.0.so.0.5400.3  libmpc.so.3.1.0   
libparted-fs-resize.so.0.0.1  libpython3.so  libtermcap.so
[..]
libcheck.so.0.0.0  libelf.so.1libgdbm_compat.a
libgthread-2.0.so.0   libmpc.so.3 
libparted-fs-resize.so.0  libpython3.5m.so.1.0  libssl.so.1.0.2

E2fsprogs installs into base_libdir, which gets the multiarch treatment, and 
mkfs.ext4 fails to find its libs during image generation. 

Regardless of all that,  a lot  of recipes 
will need packaging fixes, which should not go into a release branch like sumo, 
so, personally, I’d move it post sumo.

regards,

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

Re: [OE-core] [PATCH 3/3] python 2.7: fix multilib patch to accept multiarch style paths

[Koen Kooi]

Please ignore "[PATCH 3/3] python 2.7: fix multilib patch to accept
multiarch style paths" for now, a rebuild from scratch shows a build
failure :/

2018-04-09 13:56 GMT+02:00 Koen Kooi <k...@dominion.thruhere.net>:
>
> Using 'basename' to strip the prefix fails when using multiarch style
paths.
>
> Signed-off-by: Koen Kooi <koen.k...@linaro.org>
> ---
>  meta/recipes-devtools/python/python/multilib.patch | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/python/python/multilib.patch
b/meta/recipes-devtools/python/python/multilib.patch
> index 1116dd5..3577eda 100644
> --- a/meta/recipes-devtools/python/python/multilib.patch
> +++ b/meta/recipes-devtools/python/python/multilib.patch
> @@ -11,7 +11,7 @@ Index: Python-2.7.14/configure.ac
>
>  +AC_SUBST(LIB)
>  +AC_MSG_CHECKING(LIB)
> -+LIB=`basename ${libdir}`
> ++LIB=`echo ${libdir} | sed -e 's:${prefix}::'`
>  +AC_MSG_RESULT($LIB)
>
>   AC_SUBST(LIBRARY)
> --
> 2.9.5
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] libcap: fix (base_)libdir usage

[Koen Kooi]

The recipe wants to install libs into base_libdir, but uses "basename $libdir" 
to derive that. That breaks in a multiarch setup. Use the proper variable and 
remove the inline python usage.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libcap/libcap_2.25.bb 
b/meta/recipes-support/libcap/libcap_2.25.bb
index d619a2e..47ecf34 100644
--- a/meta/recipes-support/libcap/libcap_2.25.bb
+++ b/meta/recipes-support/libcap/libcap_2.25.bb
@@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
 
 EXTRA_OEMAKE = " \
   INDENT=  \
-  lib=${@os.path.basename('${libdir}')} \
+  lib='${base_libdir}' \
   RAISE_SETFCAP=no \
   DYNAMIC=yes \
   BUILD_GPERF=yes \
-- 
2.9.5

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

[OE-core] [PATCH 3/3] python 2.7: fix multilib patch to accept multiarch style paths

[Koen Kooi]

Using 'basename' to strip the prefix fails when using multiarch style paths.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-devtools/python/python/multilib.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python/multilib.patch 
b/meta/recipes-devtools/python/python/multilib.patch
index 1116dd5..3577eda 100644
--- a/meta/recipes-devtools/python/python/multilib.patch
+++ b/meta/recipes-devtools/python/python/multilib.patch
@@ -11,7 +11,7 @@ Index: Python-2.7.14/configure.ac
  
 +AC_SUBST(LIB)
 +AC_MSG_CHECKING(LIB)
-+LIB=`basename ${libdir}`
++LIB=`echo ${libdir} | sed -e 's:${prefix}::'`
 +AC_MSG_RESULT($LIB)
  
  AC_SUBST(LIBRARY)
-- 
2.9.5

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

[OE-core] [PATCH 2/3] bind: fix openSSL detection when using multiarch

[Koen Kooi]

In multiarch /usr/include and /usr/lib/
---
 meta/recipes-connectivity/bind/bind_9.10.6.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bind/bind_9.10.6.bb 
b/meta/recipes-connectivity/bind/bind_9.10.6.bb
index 8b8835b..20c8d7b 100644
--- a/meta/recipes-connectivity/bind/bind_9.10.6.bb
+++ b/meta/recipes-connectivity/bind/bind_9.10.6.bb
@@ -35,7 +35,7 @@ EXTRA_OECONF = " ${ENABLE_IPV6} --with-libtool 
--enable-threads \
  --disable-devpoll --enable-epoll --with-gost=no \
  --with-gssapi=no --with-ecdsa=yes \
  --sysconfdir=${sysconfdir}/bind \
- --with-openssl=${STAGING_LIBDIR}/.. \
+ --with-openssl=${STAGING_DIR_HOST}${prefix} \
"
 
 inherit autotools update-rc.d systemd useradd pkgconfig python3-dir
-- 
2.9.5

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

[OE-core] [PATCH] glibc-package: fix locale cleanup logic

[Koen Kooi]

If ${libdir} is a subdirectory of ${prefix}/lib, e.g. /usr/lib/aarch64-linux, 
the cleanup logic will delete libc.so.

This bit of code was added in 2012 (git show b744f4cc) to remove 
/usr/lib/locale, this commit makes it remove that directory recursively and 
afterwards remove /usr/lib, erroring out if it's non-empty.

Tested with a plain (/usr/lib), a 64-bit (/usr/lib64) and a multiarch 
(/usr/lib/aarch64-linux) build. I strongly suspect this whole bit of cleanup 
isn't needed anymore, but my testing is too limited to be certain.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-core/glibc/glibc-package.inc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 824b185..ff45dfe 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -207,8 +207,11 @@ do_poststash_install_cleanup () {
rm -rf ${D}/${localedir}
rm -rf ${D}${datadir}/locale
if [ "${libdir}" != "${exec_prefix}/lib" ]; then
-   # This dir only exists to hold locales
-   rm -rf ${D}${exec_prefix}/lib
+   if [ -d ${D}${exec_prefix}/lib/locale ] ; then
+   rm -rf ${D}${exec_prefix}/lib/locale
+   # error out if directory isn't empty
+   rm -f ${D}${exec_prefix}/lib
+   fi
fi
 }
 addtask do_poststash_install_cleanup after do_stash_locale do_install before 
do_populate_sysroot do_package
-- 
2.9.5

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

[OE-core] [PATCH] ncurses: fix deletion of /usr/lib/terminfo

[Koen Kooi]

Ncurses doesn't honour ${libdir} for terminfo, so try more options to remove it.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-core/ncurses/ncurses.inc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/ncurses/ncurses.inc 
b/meta/recipes-core/ncurses/ncurses.inc
index 106dcb0..0bfd644 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -201,7 +201,10 @@ do_install() {
 ln -sf xterm-color ${D}${sysconfdir}/terminfo/x/xterm
 fi
 
-rm -f ${D}${libdir}/terminfo
+# When changing ${libdir} to e.g. /usr/lib/myawesomelib/ ncurses 
+# still installs '/usr/lib/terminfo', so try to rm both 
+# the proper path and a slightly hardcoded one
+rm -f ${D}${libdir}/terminfo ${D}${prefix}/lib/terminfo
 
 # create linker scripts for libcurses.so and libncurses to
 # link against -ltinfo when needed. Some builds might break
-- 
2.9.5

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

[OE-core] [PATCH] openssl: fix libdir logic to allow multiarch style paths

[Koen Kooi]

The recipes were using 'basename' to turn '/usr/lib' into 'lib', which breaks 
when libdir is '/usr/lib/tuple', leading to libraries ending up in 
'/usr/tuple', which isn't in FILES_*. Change the logic to use sed to strip the 
prefix instead.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-connectivity/openssl/openssl10.inc | 3 ++-
 meta/recipes-connectivity/openssl/openssl_1.1.0g.bb | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl10.inc 
b/meta/recipes-connectivity/openssl/openssl10.inc
index 02a0e16..a65f80c 100644
--- a/meta/recipes-connectivity/openssl/openssl10.inc
+++ b/meta/recipes-connectivity/openssl/openssl10.inc
@@ -157,7 +157,8 @@ do_configure () {
 if [ "x$useprefix" = "x" ]; then
 useprefix=/
 fi
-   perl ./Configure ${EXTRA_OECONF} shared --prefix=$useprefix 
--openssldir=${libdir}/ssl --libdir=`basename ${libdir}` $target
+   libdirleaf="$(echo ${libdir} | sed s:$useprefix::)"
+   perl ./Configure ${EXTRA_OECONF} shared --prefix=$useprefix 
--openssldir=${libdir}/ssl --libdir=${libdirleaf} $target
 }
 
 do_compile_prepend_class-target () {
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
index 53f397a..0fd6819 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
@@ -116,7 +116,8 @@ do_configure () {
 if [ "x$useprefix" = "x" ]; then
 useprefix=/
 fi
-   perl ./Configure ${EXTRA_OECONF} --prefix=$useprefix 
--openssldir=${libdir}/ssl-1.1 --libdir=`basename ${libdir}` $target
+   libdirleaf="$(echo ${libdir} | sed s:$useprefix::)"
+   perl ./Configure ${EXTRA_OECONF} --prefix=$useprefix 
--openssldir=${libdir}/ssl-1.1 --libdir=${libdirleaf} $target
 }
 
 #| engines/afalg/e_afalg.c: In function 'eventfd':
-- 
2.9.5

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

[OE-core] [PATCH] ncurses: fix do_install failure when base_libdir has more than one level

[Koen Kooi]

Other sections of the .inc already use mkdir -p, so use it here as well.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-core/ncurses/ncurses.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/ncurses/ncurses.inc 
b/meta/recipes-core/ncurses/ncurses.inc
index 1f21cd4..106dcb0 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -227,7 +227,7 @@ do_install() {
 if [ ! -d "${D}${base_libdir}" ]; then
 # Setting base_libdir to libdir as is done in the -native
 # case will skip this code
-mkdir ${D}${base_libdir}
+mkdir -p ${D}${base_libdir}
 mv ${D}${libdir}/libncurses.so.* ${D}${base_libdir}
 ! ${ENABLE_WIDEC} || \
 mv ${D}${libdir}/libncursesw.so.* ${D}${base_libdir}
-- 
2.9.5

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

Re: [OE-core] [rocko][PATCH v3 4/4] openssl: fix runtime errors with Thumb2 when using binutils 2.29

[Koen Kooi]

> Op 19 dec. 2017, om 22:26 heeft Stefan Agner <ste...@agner.ch> het volgende 
> geschreven:
> 
> From: Stefan Agner <stefan.ag...@toradex.com>
> 
> When compiling OpenSSL with binutils 2.29 for ARM with Thumb2 enabled
> crashes and unexpected behavior occurs. E.g. connecting to a OpenSSH
> server using the affected binary fails with:
>  ssh_dispatch_run_fatal: Connection to 192.168.10.171 port 22: incorrect 
> signature
> 
> Backport upstream bugfix:
> https://github.com/openssl/openssl/issues/4659
> 
> Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
> Acked-by: Otavio Salvador <ota...@ossystems.com.br>

Tested-by: Koen Kooi <k...@dominion.thruhere.net>


> ---
> ...-armv4-bsaes-armv7-.pl-make-it-work-with-.patch | 88 ++
> .../recipes-connectivity/openssl/openssl_1.1.0g.bb |  1 +
> 2 files changed, 89 insertions(+)
> create mode 100644 
> meta/recipes-connectivity/openssl/openssl/0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch
> 
> diff --git 
> a/meta/recipes-connectivity/openssl/openssl/0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch
>  
> b/meta/recipes-connectivity/openssl/openssl/0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch
> new file mode 100644
> index 00..bb0a1689ed
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/openssl/openssl/0001-aes-asm-aes-armv4-bsaes-armv7-.pl-make-it-work-with-.patch
> @@ -0,0 +1,88 @@
> +From bcc096a50811bf0f0c4fd34b2993fed7a7015972 Mon Sep 17 00:00:00 2001
> +From: Andy Polyakov <ap...@openssl.org>
> +Date: Fri, 3 Nov 2017 23:30:01 +0100
> +Subject: [PATCH] aes/asm/{aes-armv4|bsaes-armv7}.pl: make it work with
> + binutils-2.29.
> +
> +It's not clear if it's a feature or bug, but binutils-2.29[.1]
> +interprets 'adr' instruction with Thumb2 code reference differently,
> +in a way that affects calculation of addresses of constants' tables.
> +
> +Upstream-Status: Backport
> +
> +Reviewed-by: Tim Hudson <t...@openssl.org>
> +Reviewed-by: Bernd Edlinger <bernd.edlin...@hotmail.de>
> +Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
> +(Merged from https://github.com/openssl/openssl/pull/4669)
> +
> +(cherry picked from commit b82acc3c1a7f304c9df31841753a0fa76b5b3cda)
> +---
> + crypto/aes/asm/aes-armv4.pl   | 6 +++---
> + crypto/aes/asm/bsaes-armv7.pl | 6 +++---
> + 2 files changed, 6 insertions(+), 6 deletions(-)
> +
> +diff --git a/crypto/aes/asm/aes-armv4.pl b/crypto/aes/asm/aes-armv4.pl
> +index 16d79aae53..c6474b8aad 100644
> +--- a/crypto/aes/asm/aes-armv4.pl
>  b/crypto/aes/asm/aes-armv4.pl
> +@@ -200,7 +200,7 @@ AES_encrypt:
> + #ifndef __thumb2__
> + sub r3,pc,#8@ AES_encrypt
> + #else
> +-adr r3,AES_encrypt
> ++adr r3,.
> + #endif
> + stmdb   sp!,{r1,r4-r12,lr}
> + #ifdef  __APPLE__
> +@@ -450,7 +450,7 @@ _armv4_AES_set_encrypt_key:
> + #ifndef __thumb2__
> + sub r3,pc,#8@ AES_set_encrypt_key
> + #else
> +-adr r3,AES_set_encrypt_key
> ++adr r3,.
> + #endif
> + teq r0,#0
> + #ifdef  __thumb2__
> +@@ -976,7 +976,7 @@ AES_decrypt:
> + #ifndef __thumb2__
> + sub r3,pc,#8@ AES_decrypt
> + #else
> +-adr r3,AES_decrypt
> ++adr r3,.
> + #endif
> + stmdb   sp!,{r1,r4-r12,lr}
> + #ifdef  __APPLE__
> +diff --git a/crypto/aes/asm/bsaes-armv7.pl b/crypto/aes/asm/bsaes-armv7.pl
> +index 9f288660ef..a27bb4a179 100644
> +--- a/crypto/aes/asm/bsaes-armv7.pl
>  b/crypto/aes/asm/bsaes-armv7.pl
> +@@ -744,7 +744,7 @@ $code.=<<___;
> + .type   _bsaes_decrypt8,%function
> + .align  4
> + _bsaes_decrypt8:
> +-adr $const,_bsaes_decrypt8
> ++adr $const,.
> + vldmia  $key!, {@XMM[9]}@ round 0 key
> + #ifdef  __APPLE__
> + adr $const,.LM0ISR
> +@@ -843,7 +843,7 @@ _bsaes_const:
> + .type   _bsaes_encrypt8,%function
> + .align  4
> + _bsaes_encrypt8:
> +-adr $const,_bsaes_encrypt8
> ++adr $const,.
> + vldmia  $key!, {@XMM[9]}@ round 0 key
> + #ifdef  __APPLE__
> + adr $const,.LM0SR
> +@@ -951,7 +951,7 @@ $code.=<<___;
> + .type   _bsaes_key_convert,%function
> + .align  4
> + _bsaes_key_convert:
> +-adr $const,_bsaes_key_convert
> ++adr $const,.
> + vld1.8  {@XMM[7]},  [$inp]! @ load round 0 key
> + #ifdef  __APPLE__
> + adr $const,.LM0
> +-- 
> +2.15.0
> +
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb 
> b/meta/recipes-

Re: [OE-core] [rocko][PATCH v3 3/4] openssl: Upgrade 1.1.0f -> 1.1.0g

[Koen Kooi]

> Op 19 dec. 2017, om 22:26 heeft Stefan Agner <ste...@agner.ch> het volgende 
> geschreven:
> 
> From: Stefan Agner <stefan.ag...@toradex.com>
> 
> Deals with two CVEs:
> * bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
> * Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
> 
> Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
> Acked-by: Otavio Salvador <ota...@ossystems.com.br>

Tested-by: Koen Kooi <k...@dominion.thruhere.net>

> ---
> .../openssl/{openssl_1.1.0f.bb => openssl_1.1.0g.bb}  | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-connectivity/openssl/{openssl_1.1.0f.bb => 
> openssl_1.1.0g.bb} (96%)
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
> similarity index 96%
> rename from meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
> rename to meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
> index 711a95985a..5f3e9a9dfa 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.0g.bb
> @@ -10,8 +10,8 @@ LIC_FILES_CHKSUM = 
> "file://LICENSE;md5=cae6da10f4ffd9703214776d2aabce32"
> 
> BBCLASSEXTEND = "native nativesdk"
> 
> -SRC_URI[md5sum] = "7b521dea79ab159e8ec879d269fa"
> -SRC_URI[sha256sum] = 
> "12f746f3f2493b2f39da7ecf63d7ee19c6ac9ec6a4fcd8c229da8a522cb12765"
> +SRC_URI[md5sum] = "ba5f1b8b835b88cadbce9b35ed9531a6"
> +SRC_URI[sha256sum] = 
> "de4d501267da39310905cb6dc8c6121f7a2cad45a7707f76df828fe1b85073af"
> 
> SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
>file://run-ptest \
> -- 
> 2.13.6
> 
> -- 
> ___
> 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] [rocko][PATCH v3 1/4] openssl10: Upgrade 1.0.2l -> 1.0.2m

[Koen Kooi]

> Op 19 dec. 2017, om 22:26 heeft Stefan Agner <ste...@agner.ch> het volgende 
> geschreven:
> 
> From: Stefan Agner <stefan.ag...@toradex.com>
> 
> Deals with two CVEs:
> * bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
> * Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
> 
> Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
> Acked-by: Otavio Salvador <ota...@ossystems.com.br>

Tested-by: Koen Kooi <k...@dominion.thruhere.net>

> ---
> Changes since v2:
> - Rebased to rocko-next
> 
> .../0001-Fix-build-with-clang-using-external-assembler.patch  | 0
> .../0001-openssl-force-soft-link-to-avoid-rare-race.patch | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/Makefiles-ptest.patch  | 0
> .../Use-SHA256-not-MD5-as-default-digest.patch| 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/configure-musl-target.patch| 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/configure-targets.patch| 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/debian/c_rehash-compat.patch   | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/debian/ca.patch| 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/debian/debian-targets.patch| 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/debian/man-dir.patch   | 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/debian/man-section.patch   | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/debian/no-rpath.patch  | 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/debian/no-symbolic.patch   | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/debian/pic.patch   | 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/debian/version-script.patch| 0
> .../debian1.0.2/block_digicert_malaysia.patch | 0
> .../debian1.0.2/block_diginotar.patch | 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/debian1.0.2/soname.patch   | 0
> .../debian1.0.2/version-script.patch  | 0
> .../engines-install-in-libdir-ssl.patch   | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/find.pl| 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/oe-ldflags.patch   | 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/openssl-1.0.2a-x32-asm.patch   | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/openssl-c_rehash.sh| 0
> .../openssl-fix-des.pod-error.patch   | 0
> .../openssl-util-perlpath.pl-cwd.patch| 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/openssl_fix_for_x32.patch  | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/parallel.patch | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/ptest-deps.patch   | 0
> .../{openssl-1.0.2l => openssl-1.0.2m}/ptest_makefile_deps.patch  | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/run-ptest  | 0
> .../openssl/{openssl-1.0.2l => openssl-1.0.2m}/shared-libs.patch  | 0
> .../openssl/{openssl_1.0.2l.bb => openssl_1.0.2m.bb}  | 4 ++--
> 33 files changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/0001-Fix-build-with-clang-using-external-assembler.patch 
> (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/0001-openssl-force-soft-link-to-avoid-rare-race.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/Makefiles-ptest.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/Use-SHA256-not-MD5-as-default-digest.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/configure-musl-target.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/configure-targets.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/debian/c_rehash-compat.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/debian/ca.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/debian/debian-targets.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/debian/man-dir.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/debian/man-section.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/debian/no-rpath.patch (100%)
> rename meta/recipes-connectivity/openssl/{openssl-1.0.2l => 
> openssl-1.0.2m}/debian/no-symbolic.patch (1

Re: [OE-core] [rocko][PATCH v3 2/4] openssl10: fix runtime errors with Thumb2 when using binutils 2.29

[Koen Kooi]

> Op 19 dec. 2017, om 22:26 heeft Stefan Agner <ste...@agner.ch> het volgende 
> geschreven:
> 
> From: Stefan Agner <stefan.ag...@toradex.com>
> 
> When compiling OpenSSL with binutils 2.29 for ARM with Thumb2 enabled
> crashes and unexpected behavior occurs. E.g. connecting to a OpenSSH
> server using the affected binary fails with:
>  ssh_dispatch_run_fatal: Connection to 192.168.10.171 port 22: incorrect 
> signature
> 
> Backport upstream bugfix:
> https://github.com/openssl/openssl/issues/4659
> 
> Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
> Acked-by: Otavio Salvador <ota...@ossystems.com.br>

Tested-by: Koen Kooi <k...@dominion.thruhere.net>


> ---
> ...saes-armv7-sha256-armv4-.pl-make-it-work-.patch | 100 +
> .../recipes-connectivity/openssl/openssl_1.0.2m.bb |   1 +
> 2 files changed, 101 insertions(+)
> create mode 100644 
> meta/recipes-connectivity/openssl/openssl-1.0.2m/0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
> 
> diff --git 
> a/meta/recipes-connectivity/openssl/openssl-1.0.2m/0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
>  
> b/meta/recipes-connectivity/openssl/openssl-1.0.2m/0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
> new file mode 100644
> index 00..2ce0320c49
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/openssl/openssl-1.0.2m/0001-aes-armv4-bsaes-armv7-sha256-armv4-.pl-make-it-work-.patch
> @@ -0,0 +1,100 @@
> +From d1d6c69b6fd25e71dbae67fad17b2c7737f6b2dc Mon Sep 17 00:00:00 2001
> +From: Andy Polyakov <ap...@openssl.org>
> +Date: Sun, 5 Nov 2017 17:08:16 +0100
> +Subject: [PATCH] {aes-armv4|bsaes-armv7|sha256-armv4}.pl: make it work with
> + binutils-2.29
> +
> +It's not clear if it's a feature or bug, but binutils-2.29[.1]
> +interprets 'adr' instruction with Thumb2 code reference differently,
> +in a way that affects calculation of addresses of constants' tables.
> +
> +Upstream-Status: Backport
> +
> +Reviewed-by: Bernd Edlinger <bernd.edlin...@hotmail.de>
> +Reviewed-by: Kurt Roeckx <k...@roeckx.be>
> +Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
> +(Merged from https://github.com/openssl/openssl/pull/4673)
> +---
> + crypto/aes/asm/aes-armv4.pl| 6 +++---
> + crypto/aes/asm/bsaes-armv7.pl  | 6 +++---
> + crypto/sha/asm/sha256-armv4.pl | 2 +-
> + 3 files changed, 7 insertions(+), 7 deletions(-)
> +
> +diff --git a/crypto/aes/asm/aes-armv4.pl b/crypto/aes/asm/aes-armv4.pl
> +index 4f8917089f..c1b5e352d7 100644
> +--- a/crypto/aes/asm/aes-armv4.pl
>  b/crypto/aes/asm/aes-armv4.pl
> +@@ -184,7 +184,7 @@ AES_encrypt:
> + #if __ARM_ARCH__<7
> + sub r3,pc,#8@ AES_encrypt
> + #else
> +-adr r3,AES_encrypt
> ++adr r3,.
> + #endif
> + stmdb   sp!,{r1,r4-r12,lr}
> + mov $rounds,r0  @ inp
> +@@ -430,7 +430,7 @@ _armv4_AES_set_encrypt_key:
> + #if __ARM_ARCH__<7
> + sub r3,pc,#8@ AES_set_encrypt_key
> + #else
> +-adr r3,private_AES_set_encrypt_key
> ++adr r3,.
> + #endif
> + teq r0,#0
> + #if __ARM_ARCH__>=7
> +@@ -952,7 +952,7 @@ AES_decrypt:
> + #if __ARM_ARCH__<7
> + sub r3,pc,#8@ AES_decrypt
> + #else
> +-adr r3,AES_decrypt
> ++adr r3,.
> + #endif
> + stmdb   sp!,{r1,r4-r12,lr}
> + mov $rounds,r0  @ inp
> +diff --git a/crypto/aes/asm/bsaes-armv7.pl b/crypto/aes/asm/bsaes-armv7.pl
> +index 70b3f9656f..ec66b0502a 100644
> +--- a/crypto/aes/asm/bsaes-armv7.pl
>  b/crypto/aes/asm/bsaes-armv7.pl
> +@@ -724,7 +724,7 @@ $code.=<<___;
> + .type   _bsaes_decrypt8,%function
> + .align  4
> + _bsaes_decrypt8:
> +-adr $const,_bsaes_decrypt8
> ++adr $const,.
> + vldmia  $key!, {@XMM[9]}@ round 0 key
> + add $const,$const,#.LM0ISR-_bsaes_decrypt8
> + 
> +@@ -819,7 +819,7 @@ _bsaes_const:
> + .type   _bsaes_encrypt8,%function
> + .align  4
> + _bsaes_encrypt8:
> +-adr $const,_bsaes_encrypt8
> ++adr $const,.
> + vldmia  $key!, {@XMM[9]}@ round 0 key
> + sub $const,$const,#_bsaes_encrypt8-.LM0SR
> + 
> +@@ -923,7 +923,7 @@ $code.=<<___;
> + .type   _bsaes_key_convert,%function
> + .align  4
> + _bsaes_key_convert:
> +-adr $const,_bsaes_key_convert
> ++adr $const,.
> + vld1.8  {@XMM[7]},  [$inp]! @ load round 0 key
> + sub $const,$const,#_bsaes_key_convert-.LM0
> + vld1.8  {@XMM[15]}, [$inp]! @ load rou

Re: [OE-core] State of bitbake world, Failed tasks 2017-03-01

[Koen Kooi]

Op 02-03-17 om 00:14 schreef Andreas Müller:
> On Wed, Mar 1, 2017 at 8:55 PM, Martin Jansa  wrote:
>> * 
>> openembedded-core/meta/recipes-extended/parted/parted_3.2.bb:do_compile_ptest_base
> Before Martin blacklists gparted for dependency :)
> 
> 1. Autobuilder error log says:
> 
> | ../libparted/fs/.libs/libparted-fs-resize.so: error: undefined
> reference to 'uuid_generate'
> | collect2: error: ld returned 1 exit status
> | Makefile:1422: recipe for target 'fs-resize' failed
> | make: *** [fs-resize] Error 1
> | make: Leaving directory
> '/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/parted/3.2-r1/build/tests'
> | ERROR: Function failed: do_compile_ptest_base (log file is located
> at 
> /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/parted/3.2-r1/temp/log.do_compile_ptest_base.7114)
> 
> 2. grepping in gparted's source
> [superandy@very-old-builder parted-3.2]$ grep -r uuid_generate
> configure.ac:AC_CHECK_LIB([uuid], [uuid_generate], [UUID_LIBS="-luuid"],
> <...>
> 
> I think adding ossp-uuid to DEPENDS will do. 

Util-linux is the preferred provider for libuuid (it moved from e2fsprogs to
util-linux a few years ago).

regards,

Koen


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

Re: [OE-core] [PATCH 1/1] recipes-extended: Move efivar from meta-openembedded to oe-core

[Koen Kooi]

Op 28-02-17 om 09:58 schreef Martin Jansa:
> Agreed with Koen.
> 
> Everything outside oe-core is meant to be nice little colorful boxes which
> don't depend on each other (as discussed on OEDAM), but whatever intel needs
> has to go to oe-core.
> 
>> We are aware that this was recently blacklisted in meta-oe, but we
> were unable to reproduce the issue under any circumstances.
> 
> And it still fails to build and it will continue to fail even from oe-core.

I suspect it's host-gcc related, it's on my plate to fix, but it will take a
few weeks before I can really look at it :/


> 
> On Tue, Feb 28, 2017 at 9:33 AM, Koen Kooi <k...@dominion.thruhere.net
> <mailto:k...@dominion.thruhere.net>> wrote:
> 
> Op 28-02-17 om 02:09 schreef California Sullivan:
> > BSPs for platforms using UEFI, such as meta-intel, would like to have
> > this more widely available
> 
> I guess you're saying "one less git repo to clone"? I don't think that's a
> good enough reason to move it to OE-core.
> 
> > for future support enhancements.
> 
> I'm having trouble parsing this, it seems like you're saying that having 
> it
> in meta-oe precludes you from contributing to it?
> 
> >
> > This is a direct copy of the recipe from meta-openembedded/meta-oe.
> >
> > Signed-off-by: California Sullivan
> > <california.l.sulli...@intel.com
> <mailto:california.l.sulli...@intel.com>> --- We
> > are aware that this was recently blacklisted in meta-oe, but we were
> > unable to reproduce the issue under any circumstances.
> >
> > .../efivar/0001-efivar-fix-for-cross-compile.patch | 35
> > + .../efivar/efivar/0002-disable-static-build.patch  | 
> 33
> >  .../efivar/0003-efivar-fix-for-cross-compile.patch | 44
> > + .../0004-fix-unknow-option-for-gold-linker.patch
> > | 38 ++ .../allow-multi-definitions-for-native.patch
> > | 23 +++ .../fix-compile-failure-with-host-gcc-4.6.patch| 45
> > ++ meta/recipes-extended/efivar/efivar_0.24.bb
> <http://efivar_0.24.bb>
> > | 43 + 7 files changed, 261 insertions(+) create 
> mode
> > 100644
> > 
> meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
> >
> >
> create mode 100644
> meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch
> > create mode 100644
> > 
> meta/recipes-extended/efivar/efivar/0003-efivar-fix-for-cross-compile.patch
> >
> >
> create mode 100644
> 
> meta/recipes-extended/efivar/efivar/0004-fix-unknow-option-for-gold-linker.patch
> > create mode 100644
> > 
> meta/recipes-extended/efivar/efivar/allow-multi-definitions-for-native.patch
> >
> >
> create mode 100644
> 
> meta/recipes-extended/efivar/efivar/fix-compile-failure-with-host-gcc-4.6.patch
> > create mode 100644 meta/recipes-extended/efivar/efivar_0.24.bb
> <http://efivar_0.24.bb>
> >
> > diff --git
> >
> 
> a/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
> >
> 
> b/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
> >
> >
> new file mode 100644
> > index 000..6f6ca64 --- /dev/null +++
> >
> 
> b/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
> >
> >
> @@ -0,0 +1,35 @@
> > +From 9a3c480af653b37e62d1be04d49fe7a60a80168f Mon Sep 17 00:00:00 2001
> > +From: Kai Kang <kai.k...@windriver.com
> <mailto:kai.k...@windriver.com>> +Date:
> > Fri, 25 Sep 2015 18:14:31 +0800 +Subject: [PATCH 1/2] efivar: fix for
> > cross compile + +It builds and calls elf file makeguids to generate a
> > header file which +doesn't work for cross compile. Fix it. +
> > +Signed-off-by: Kai Kang
> > <kai.k...@windriver.com
> <mailto:kai.k...@windriver.com>> + +Upstream-Status:
> > Pending +Signed-off-by: Hongxu Jia
> > <hongxu@windriver.com
> <mailto:hongxu@windriver.com>> + +--- +
> > src/Makefile | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-)
> > + +diff --git a/src/Makefile b/src/Makefile +index 5fc7887..1829d22
> > 100644 +--- a/src/Makefile  b/src/Makefile +@@ -29,8 +29,8 @@ all :
> > deps $(TARGETS) + ./guid-symbols.c : include/e

Re: [OE-core] [PATCH 1/1] recipes-extended: Move efivar from meta-openembedded to oe-core

[Koen Kooi]

Op 28-02-17 om 02:09 schreef California Sullivan:
> BSPs for platforms using UEFI, such as meta-intel, would like to have 
> this more widely available

I guess you're saying "one less git repo to clone"? I don't think that's a
good enough reason to move it to OE-core.

> for future support enhancements.

I'm having trouble parsing this, it seems like you're saying that having it
in meta-oe precludes you from contributing to it?

> 
> This is a direct copy of the recipe from meta-openembedded/meta-oe.
> 
> Signed-off-by: California Sullivan
> <california.l.sulli...@intel.com> --- We
> are aware that this was recently blacklisted in meta-oe, but we were 
> unable to reproduce the issue under any circumstances.
> 
> .../efivar/0001-efivar-fix-for-cross-compile.patch | 35
> + .../efivar/efivar/0002-disable-static-build.patch  | 33
>  .../efivar/0003-efivar-fix-for-cross-compile.patch | 44
> + .../0004-fix-unknow-option-for-gold-linker.patch
> | 38 ++ .../allow-multi-definitions-for-native.patch
> | 23 +++ .../fix-compile-failure-with-host-gcc-4.6.patch| 45
> ++ meta/recipes-extended/efivar/efivar_0.24.bb
> | 43 + 7 files changed, 261 insertions(+) create mode
> 100644
> meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
>
> 
create mode 100644
meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch
> create mode 100644
> meta/recipes-extended/efivar/efivar/0003-efivar-fix-for-cross-compile.patch
>
> 
create mode 100644
meta/recipes-extended/efivar/efivar/0004-fix-unknow-option-for-gold-linker.patch
> create mode 100644
> meta/recipes-extended/efivar/efivar/allow-multi-definitions-for-native.patch
>
> 
create mode 100644
meta/recipes-extended/efivar/efivar/fix-compile-failure-with-host-gcc-4.6.patch
> create mode 100644 meta/recipes-extended/efivar/efivar_0.24.bb
> 
> diff --git
> a/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
> b/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
>
> 
new file mode 100644
> index 000..6f6ca64 --- /dev/null +++
> b/meta/recipes-extended/efivar/efivar/0001-efivar-fix-for-cross-compile.patch
>
> 
@@ -0,0 +1,35 @@
> +From 9a3c480af653b37e62d1be04d49fe7a60a80168f Mon Sep 17 00:00:00 2001 
> +From: Kai Kang <kai.k...@windriver.com> +Date:
> Fri, 25 Sep 2015 18:14:31 +0800 +Subject: [PATCH 1/2] efivar: fix for
> cross compile + +It builds and calls elf file makeguids to generate a
> header file which +doesn't work for cross compile. Fix it. + 
> +Signed-off-by: Kai Kang
> <kai.k...@windriver.com> + +Upstream-Status:
> Pending +Signed-off-by: Hongxu Jia
> <hongxu@windriver.com> + +--- +
> src/Makefile | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) 
> + +diff --git a/src/Makefile b/src/Makefile +index 5fc7887..1829d22
> 100644 +--- a/src/Makefile  b/src/Makefile +@@ -29,8 +29,8 @@ all :
> deps $(TARGETS) + ./guid-symbols.c : include/efivar/efivar-guids.h +
> ./guids.bin : include/efivar/efivar-guids.h + ./names.bin :
> include/efivar/efivar-guids.h +-include/efivar/efivar-guids.h : makeguids
> guids.txt +-  ./makeguids guids.txt guids.bin names.bin \ 
> ++include/efivar/efivar-guids.h : guids.txt ++makeguids guids.txt
> guids.bin names.bin \ +   guid-symbols.c 
> include/efivar/efivar-guids.h +
>  + makeguids : CPPFLAGS+=-DEFIVAR_BUILD_ENVIRONMENT +-- +2.4.3 + diff
> --git
> a/meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch
> b/meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch new
> file mode 100644 index 000..951b159 --- /dev/null +++
> b/meta/recipes-extended/efivar/efivar/0002-disable-static-build.patch @@
> -0,0 +1,33 @@ +From 126e0d3c1ad74cf5b0abe9e98ec444bcc3c83159 Mon Sep 17
> 00:00:00 2001 +From: Koen Kooi
> <koen.k...@linaro.org> +Date: Fri, 4 Mar
> 2016 14:53:55 +0100 +Subject: [PATCH 2/2] disable static build + 
> +Signed-off-by: Koen Kooi
> <koen.k...@linaro.org> + +Upstream-Status:
> Inappropriate [meta-oe specific] +Signed-off-by: Hongxu Jia
> <hongxu@windriver.com> + +--- +
> src/Makefile | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) 
> + +diff --git a/src/Makefile b/src/Makefile +index 1829d22..c7a0ca3
> 100644 +--- a/src/Makefile  b/src/Makefile +@@ -8,9 +8,9 @@ include
> $(TOPDIR)/Make.defaults + + LIBTARGETS=libefivar.so libefiboot.so +
> STATICLIBTARGETS=libefivar.a libefiboot.a +-BINTARGETS=efivar
> efivar-static ++BINTARGETS=efivar + PCTARGETS=efivar.pc efiboot.pc 
> +-TARGETS=$(LIBTARGETS) $(STATICLIBTARGETS) $(BINTARGETS) $(PCTARGETS) 
> ++TARGETS=$(L

[OE-core] [PATCH] gdb 7.12: fix armv8b build

[Koen Kooi]

Backport fix from GDB upstream to fix big-endian aarch64 build.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-devtools/gdb/gdb-7.12.inc |  1 +
 .../cb93dc7f262978bafe36397a41a56e409a302042.patch | 42 ++
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e409a302042.patch

diff --git a/meta/recipes-devtools/gdb/gdb-7.12.inc 
b/meta/recipes-devtools/gdb/gdb-7.12.inc
index 2faddc5..7eea65f 100644
--- a/meta/recipes-devtools/gdb/gdb-7.12.inc
+++ b/meta/recipes-devtools/gdb/gdb-7.12.inc
@@ -15,6 +15,7 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://0008-Use-exorted-definitions-of-SIGRTMIN.patch \
file://0009-Change-order-of-CFLAGS.patch \
file://0010-resolve-restrict-keyword-conflict.patch \
+  file://cb93dc7f262978bafe36397a41a56e409a302042.patch \
 "
 SRC_URI[md5sum] = "a0a3a00f7499b0c5278ba8676745d180"
 SRC_URI[sha256sum] = 
"834ff3c5948b30718343ea57b11cbc3235d7995c6a4f3a5cecec8c8114164f94"
diff --git 
a/meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e409a302042.patch 
b/meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e409a302042.patch
new file mode 100644
index 000..a3f488a
--- /dev/null
+++ 
b/meta/recipes-devtools/gdb/gdb/cb93dc7f262978bafe36397a41a56e409a302042.patch
@@ -0,0 +1,42 @@
+From cb93dc7f262978bafe36397a41a56e409a302042 Mon Sep 17 00:00:00 2001
+From: Yao Qi <yao...@linaro.org>
+Date: Mon, 24 Oct 2016 10:59:11 +0100
+Subject: [PATCH] [GDBserver] Fix conversion warning
+
+I got the following warning if I build GDBserver for aarch64_be-linux-gnu,
+
+git/gdb/gdbserver/linux-aarch64-low.c:1539:39: error: invalid conversion from 
'void*' to 'uint32_t* {aka unsigned int*}' [-fpermissive]
+   uint32_t *le_buf = xmalloc (byte_len);
+   ^
+The patch is to fix the warning.
+
+gdb/gdbserver:
+
+2016-10-24  Yao Qi  <yao...@linaro.org>
+
+   PR server/20733
+   * linux-aarch64-low.c (append_insns): Cast the return value to
+   'uint32_t *'.
+
+Upstream-status: Backport
+
+---
+ gdb/gdbserver/linux-aarch64-low.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gdb/gdbserver/linux-aarch64-low.c 
b/gdb/gdbserver/linux-aarch64-low.c
+index e54a8ba..ae80cdd 100644
+--- a/gdb/gdbserver/linux-aarch64-low.c
 b/gdb/gdbserver/linux-aarch64-low.c
+@@ -1536,7 +1536,7 @@ append_insns (CORE_ADDR *to, size_t len, const uint32_t 
*buf)
+ {
+   size_t byte_len = len * sizeof (uint32_t);
+ #if (__BYTE_ORDER == __BIG_ENDIAN)
+-  uint32_t *le_buf = xmalloc (byte_len);
++  uint32_t *le_buf = (uint32_t *) xmalloc (byte_len);
+   size_t i;
+ 
+   for (i = 0; i < len; i++)
+-- 
+2.9.3
+
-- 
2.9.3

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

Re: [OE-core] [Openembedded-architecture] Enabling uninative by default in oe-core?

[Koen Kooi]

> Op 18 nov. 2016, om 19:06 heeft Richard Purdie 
>  het volgende geschreven:
> 
> On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote:
>> On 11/17/2016 09:31 AM, Burton, Ross wrote:
>>> Background: uninative is a class that downloads a precompiled host
>>> glibc for use in the sysroot, thus isolating the native sysroot
>>> from the host environment.  This means greater sstate reuse, as
>>> instead of native builds being dependent on the host system they're
>>> able to be shared between all hosts.  There is a reference tarball
>>> hosted on www.yoctoproject.org, and the URL can be overridden by
>>> distros if you would prefer to build your own.
>>> 
>>> We enable this in Poky so that we get greater reuse on the
>>> autobuilders, and due to some issues with the C++ ABI the eSDK
>>> generation in master now requires uninative to be enabled.  The
>>> question is: do we now enable uninative by default in oe-core's
>>> nodistro (pointing at the yoctoproject tarball), or do we keep it
>>> disabled by default and require the user to enable uninative if
>>> they wish to build an eSDK?
>>  
>> If Poky wants the default to use a prebuilt uninative that is fine,
>> but it should be not be the default in OE.  In the spirit of Bitbake,
>> uninative should be a build dependency for eSDK with the option of
>> using a prebuilt one.
> 
> Its not that simple. Using uninative requires certain options passed in
> when compiling native recipes for example, e.g. to pick particular C++
> abis. If you start the build without those set (since uninative is
> disabled), you can't get native sstate built in the right way for it to
> work with eSDK. We could of course add a new BBCLASSEXTEND, "native2"
> which is native specially for use in the eSDK but that seems silly.
> 
> I guess we could move the configuration uninative requires into global
> bitbake.conf but not require the actual binary shim to be enabled. That
> would let eSDK work in OE-Core just not make OE-Core require uninative.
> It would mean the compiler options for native would be a little
> different. That might be an acceptable compromise?

It would be for me.

regards,

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

Re: [OE-core] Enabling uninative by default in oe-core?

[Koen Kooi]

> Op 17 nov. 2016, om 18:31 heeft Burton, Ross  het 
> volgende geschreven:
> 
> Hi,
> 
> Background: uninative is a class that downloads a precompiled host glibc 

Why can’t OE build it on-demand? What’s next, requiring prebuilt toolchains?

regards,

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

[OE-core] [PATCH] libbsd 0.8.3: BBCLASSEXTEND to native and nativesdk

[Koen Kooi]

Android-tools depends on it and to build the native versions of fastboot, adb, 
mkbootimg and others libbsd needs to support native builds.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-support/libbsd/libbsd_0.8.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/libbsd/libbsd_0.8.3.bb 
b/meta/recipes-support/libbsd/libbsd_0.8.3.bb
index 92121ef..6f734ab 100644
--- a/meta/recipes-support/libbsd/libbsd_0.8.3.bb
+++ b/meta/recipes-support/libbsd/libbsd_0.8.3.bb
@@ -41,3 +41,5 @@ SRC_URI[md5sum] = "e935c1bb6cc98a4a43cb1da22795493a"
 SRC_URI[sha256sum] = 
"934b634f4dfd865b6482650b8f522c70ae65c463529de8be907b53c89c3a34a8"
 
 inherit autotools pkgconfig
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.4.11

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

Re: [OE-core] [PATCH] The CMake recipes contain a mismatch between the environmental variable which defines where the Modules are installed and the location where they actually are. This patch fixes t

[Koen Kooi]

> Op 16 jun. 2016, om 16:27 heeft Jose Pardeiro 
>  het volgende geschreven:
> 
> Signed-off-by: Jose Pardeiro 
> ---
> meta/classes/cmake.patch | 20 
> 1 file changed, 20 insertions(+)
> create mode 100644 meta/classes/cmake.patch
> 
> diff --git a/meta/classes/cmake.patch b/meta/classes/cmake.patch
> new file mode 100644
> index 000..c9cc9f2
> --- /dev/null
> +++ b/meta/classes/cmake.patch
> @@ -0,0 +1,20 @@
> +The CMake recipes contain a mismatch between the environmental variable
> +which defines where the Modules are installed and the location where they
> +actually are. This patch fixes the environmental variable to point to the
> +proper folder defined according to the cmake version.
> +
> +Signed-off-by: Jose Pardeiro 
> +
> +diff --git a/cmake.bbclass b/cmake.bbclass
> +index 995ddf1..6de4247 100644
> +--- a/meta/classes/cmake.bbclass
>  b/meta/classes/cmake.bbclass
> +@@ -60,7 +60,7 @@ set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
> + set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
> +
> + # Use native cmake modules
> +-set( CMAKE_MODULE_PATH ${STAGING_DATADIR}/cmake/Modules/ )
> ++set( CMAKE_MODULE_PATH 
> ${STAGING_DATADIR}/cmake-\${CMAKE_MAJOR_VERSION}.\${CMAKE_MINOR_VERSION}/Modules/
>  )

CMAKE_MINOR_VERSION doesn’t exist in OE, and the escaping is wrong, leading to:

|   Syntax error in cmake code at
|
| 
/build/linaro/build/build/tmp-glibc/work/aarch64-oe-linux/cmake/3.5.2-r0/toolchain.cmake:34
|
|   when parsing string
|
| 
/build/linaro/build/build/tmp-glibc/sysroots/genericarmv8/usr/share/cmake-\3.5.${CMAKE_MINOR_VERSION}/Modules/
|
|   Invalid character escape '\3'.
| Call Stack (most recent call first):
|   
/build/linaro/build/build/tmp-glibc/sysroots/x86_64-linux/usr/share/cmake-3.5/Modules/CMakeDetermineSystem.cmake:98
 (include)
|   CMakeLists.txt:19 (project)

And I can’t find the patch that was committed in the mailinglist folder 
locally, otherwise I would have responded to that.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Revert "image.bbclass: don't execute compression commands multiple times"

[Koen Kooi]

On 19 June 2016 at 09:50, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> On Sun, 2016-06-19 at 09:46 +0200, Koen Kooi wrote:
>>
>>
>> > Op 18 jun. 2016, om 20:21 heeft Richard Purdie <
>> > richard.pur...@linuxfoundation.org> het volgende geschreven:
>> >
>> > On Sat, 2016-06-18 at 15:08 +0200, Koen Kooi wrote:
>> > > > Op 4 jun. 2016, om 15:09 heeft Richard Purdie <
>> > > > richard.pur...@linuxfoundation.org> het volgende geschreven:
>> > > >
>> > > > On Sat, 2016-06-04 at 10:41 +0200, Koen Kooi wrote:
>> > > > > ping 2
>> > > >
>> > > > It would be helpful if you'd cc'd the person who's patch you
>> > > > were
>> > > > suggesting we revert. I added Sasha to cc.
>> > >
>> > > Since the original committer has shown zero interest in
>> > > responding
>> > > here or fixing the problem in the past month, can you please
>> > > commit
>> > > this? This fixes a clear regression, which alone should have been
>> > > reason enough to commit this.
>> >
>> > Did
>> > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7028192246552f
>> > d9e4aa3674da9c30670fd4ec86 fix this?
>>
>> Don’t know since I use OE, not poky.
>
> Ok. Let me paste the hash in "From OE-Core rev: 
> 46bc438374de74af76d288520c6252c9b7840767"
> into a new url. I obviously have nothing better to do with my time.
>
> Did 
> http://git.openembedded.org/openembedded-core/commit/?id=46bc438374de74af76d288520c6252c9b7840767
> fix this?
>
> Or in case you also don't have a web browser, did revision in the
> openembedded-core repository with hash
> 46bc438374de74af76d288520c6252c9b7840767 fix this issue?

With that included and the overlayed image.bbclass dropped the build
succeeds. So the revert isn't needed anymore.

-- 
Koen Kooi

Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Revert "image.bbclass: don't execute compression commands multiple times"

[Koen Kooi]

> Op 18 jun. 2016, om 20:21 heeft Richard Purdie 
> <richard.pur...@linuxfoundation.org> het volgende geschreven:
> 
> On Sat, 2016-06-18 at 15:08 +0200, Koen Kooi wrote:
>>> Op 4 jun. 2016, om 15:09 heeft Richard Purdie <
>>> richard.pur...@linuxfoundation.org> het volgende geschreven:
>>> 
>>> On Sat, 2016-06-04 at 10:41 +0200, Koen Kooi wrote:
>>>> ping 2
>>> 
>>> It would be helpful if you'd cc'd the person who's patch you were
>>> suggesting we revert. I added Sasha to cc.
>> 
>> Since the original committer has shown zero interest in responding
>> here or fixing the problem in the past month, can you please commit
>> this? This fixes a clear regression, which alone should have been
>> reason enough to commit this.
> 
> Did http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7028192246552f
> d9e4aa3674da9c30670fd4ec86 fix this?

Don’t know since I use OE, not poky.

—
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Revert "image.bbclass: don't execute compression commands multiple times"

[Koen Kooi]

> Op 4 jun. 2016, om 15:09 heeft Richard Purdie 
> <richard.pur...@linuxfoundation.org> het volgende geschreven:
> 
> On Sat, 2016-06-04 at 10:41 +0200, Koen Kooi wrote:
>> ping 2
> 
> It would be helpful if you'd cc'd the person who's patch you were
> suggesting we revert. I added Sasha to cc.

Since the original committer has shown zero interest in responding here or 
fixing the problem in the past month, can you please commit this? This fixes a 
clear regression, which alone should have been reason enough to commit this.


> 
> I've seen multiple different conflicting patches regarding the image
> types code and I've not had a chance to try and figure out what the
> real set of problems are and which of the various proposed patches make
> things worse or better.
> 
> Until someone can explain clearly to me what the problems are and how
> we move forward, or I find time to dig into it myself, we're a bit
> stuck :/. I just mention this since I expect you're getting frustrated
> hearing nothing. This has been flagged in my inbox, I'm just lacking
> the time to do everything I'd like :(
> 
> Cheers,
> 
> Richard
> 
>>> Op 30 mei 2016, om 13:28 heeft Koen Kooi <
>>> k...@dominion.thruhere.net> het volgende geschreven:
>>> 
>>> ping
>>> 
>>>> Op 23 mei 2016, om 19:50 heeft Koen Kooi <koen.k...@linaro.org>
>>>> het volgende geschreven:
>>>> 
>>>> The commit breaks image_types_uboot.bbclass:
>>>> 
>>>> ERROR: Logfile of failure stored in:
>>>> /build/linaro/build/build/tmp-glibc/work/genericarmv8-oe
>>>> -linux/linaro-image-minimal-initramfs/1.0
>>>> -r0/temp/log.do_image_cpio.16506
>>>> Log data follows:
>>>>> DEBUG: Executing python function set_image_size
>>>>> DEBUG: Python function set_image_size finished
>>>>> DEBUG: Executing shell function do_image_cpio
>>>>> 31373 blocks
>>>>> Image Name:   linaro-image-minimal-initramfs-g
>>>>> Created:  Mon May 23 19:38:56 2016
>>>>> Image Type:   ARM Linux RAMDisk Image (gzip compressed)
>>>>> Data Size:7326620 Bytes = 7154.90 kB = 6.99 MB
>>>>> Load Address: 
>>>>> Entry Point:  
>>>>> mkimage: Can't open /build/linaro/build/build/tmp
>>>>> -glibc/deploy/images/genericarmv8/linaro-image-minimal
>>>>> -initramfs-genericarmv8-20160523173835.rootfs.cpio.gz: No such
>>>>> file or directory
>>>> 
>>>> This reverts commit 94f61c2682e5cfd819ac84535650c3e0a654415a.
>>>> 
>>>> Signed-off-by: Koen Kooi <koen.k...@linaro.org>
>>>> ---
>>>> meta/classes/image.bbclass | 8 ++--
>>>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>>> 
>>>> diff --git a/meta/classes/image.bbclass
>>>> b/meta/classes/image.bbclass
>>>> index 9f4c83f..df3bd3a 100644
>>>> --- a/meta/classes/image.bbclass
>>>> +++ b/meta/classes/image.bbclass
>>>> @@ -410,13 +410,9 @@ python () {
>>>>   # Create input image first.
>>>>   gen_conversion_cmds(type)
>>>>   localdata.setVar('type', type)
>>>> -cmd = "\t" +
>>>> localdata.getVar("COMPRESS_CMD_" + ctype, True)
>>>> -if cmd not in cmds:
>>>> -cmds.append(cmd)
>>>> +cmds.append("\t" +
>>>> localdata.getVar("COMPRESS_CMD_" + ctype, True))
>>>>   vardeps.add('COMPRESS_CMD_' + ctype)
>>>> -subimage = type + "." + ctype
>>>> -if subimage not in subimages:
>>>> -subimages.append(subimage)
>>>> +subimages.append(type + "." + ctype)
>>>>   if type not in alltypes:
>>>> 
>>>> rm_tmp_images.add(localdata.expand("${IMAGE_NAME}${IMAGE_NAME_SU
>>>> FFIX}.${type}"))
>>>> 
>>>> -- 
>>>> 2.4.3
>>>> 
>>>> -- 
>>>> ___
>>>> 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

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

Re: [OE-core] [PATCH] Revert "image.bbclass: don't execute compression commands multiple times"

[Koen Kooi]

On 4 June 2016 at 15:09, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> On Sat, 2016-06-04 at 10:41 +0200, Koen Kooi wrote:
>> ping 2
>
> It would be helpful if you'd cc'd the person who's patch you were
> suggesting we revert. I added Sasha to cc.

Sorry about that, I had expected 'git revert' to automatically add the
original sign-off somewhere.

> I've seen multiple different conflicting patches regarding the image
> types code and I've not had a chance to try and figure out what the
> real set of problems are

Disclaimer: it's all incomprehensible python to me.

The problem I'm running into is that I want a something.gz inside
something-else.gz, the patch that I reverted seems to say "Hey, gz is
mentioned twice, let's optimize that out". Patricks patches seem to
solve the same thing but not break things.

> and which of the various proposed patches make
> things worse or better.
>
> Until someone can explain clearly to me what the problems are and how
> we move forward

I'm not sure what problems the compression patches are trying to fix,
just that this single patches breaks an oe-core class and reverts
cleanly.

>, or I find time to dig into it myself, we're a bit
> stuck :/. I just mention this since I expect you're getting frustrated
> hearing nothing. This has been flagged in my inbox, I'm just lacking
> the time to do everything I'd like :(

Sure, thanks for the heads-up, a response makes the bean counters at
work happy :)

regards,

Koen

>
> Cheers,
>
> Richard
>
>> > Op 30 mei 2016, om 13:28 heeft Koen Kooi <
>> > k...@dominion.thruhere.net> het volgende geschreven:
>> >
>> > ping
>> >
>> > > Op 23 mei 2016, om 19:50 heeft Koen Kooi <koen.k...@linaro.org>
>> > > het volgende geschreven:
>> > >
>> > > The commit breaks image_types_uboot.bbclass:
>> > >
>> > > ERROR: Logfile of failure stored in:
>> > > /build/linaro/build/build/tmp-glibc/work/genericarmv8-oe
>> > > -linux/linaro-image-minimal-initramfs/1.0
>> > > -r0/temp/log.do_image_cpio.16506
>> > > Log data follows:
>> > > > DEBUG: Executing python function set_image_size
>> > > > DEBUG: Python function set_image_size finished
>> > > > DEBUG: Executing shell function do_image_cpio
>> > > > 31373 blocks
>> > > > Image Name:   linaro-image-minimal-initramfs-g
>> > > > Created:  Mon May 23 19:38:56 2016
>> > > > Image Type:   ARM Linux RAMDisk Image (gzip compressed)
>> > > > Data Size:7326620 Bytes = 7154.90 kB = 6.99 MB
>> > > > Load Address: 
>> > > > Entry Point:  
>> > > > mkimage: Can't open /build/linaro/build/build/tmp
>> > > > -glibc/deploy/images/genericarmv8/linaro-image-minimal
>> > > > -initramfs-genericarmv8-20160523173835.rootfs.cpio.gz: No such
>> > > > file or directory
>> > >
>> > > This reverts commit 94f61c2682e5cfd819ac84535650c3e0a654415a.
>> > >
>> > > Signed-off-by: Koen Kooi <koen.k...@linaro.org>
>> > > ---
>> > > meta/classes/image.bbclass | 8 ++--
>> > > 1 file changed, 2 insertions(+), 6 deletions(-)
>> > >
>> > > diff --git a/meta/classes/image.bbclass
>> > > b/meta/classes/image.bbclass
>> > > index 9f4c83f..df3bd3a 100644
>> > > --- a/meta/classes/image.bbclass
>> > > +++ b/meta/classes/image.bbclass
>> > > @@ -410,13 +410,9 @@ python () {
>> > ># Create input image first.
>> > >gen_conversion_cmds(type)
>> > >localdata.setVar('type', type)
>> > > -cmd = "\t" +
>> > > localdata.getVar("COMPRESS_CMD_" + ctype, True)
>> > > -if cmd not in cmds:
>> > > -cmds.append(cmd)
>> > > +cmds.append("\t" +
>> > > localdata.getVar("COMPRESS_CMD_" + ctype, True))
>> > >vardeps.add('COMPRESS_CMD_' + ctype)
>> > > -subimage = type + "." + ctype
>> > > -if subimage not in subimages:
>> > > -subimages.append(subimage)
>> > > +subimages.append(type + "." + ctype)
>> > >if type not in alltypes:
>> > >
>> > >  rm_tmp_images.add(localdata.expand("${IMAGE_NAME}${IMAGE_NAME_SU
>> > > FFIX}.${type}"))
>> > >
>> > > --
>> > > 2.4.3
>> > >
>> > > --
>> > > ___
>> > > Openembedded-core mailing list
>> > > Openembedded-core@lists.openembedded.org
>> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> > >
>> >
>>



-- 
Koen Kooi

Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Revert "image.bbclass: don't execute compression commands multiple times"

[Koen Kooi]

ping 2

> Op 30 mei 2016, om 13:28 heeft Koen Kooi <k...@dominion.thruhere.net> het 
> volgende geschreven:
> 
> ping
> 
>> Op 23 mei 2016, om 19:50 heeft Koen Kooi <koen.k...@linaro.org> het volgende 
>> geschreven:
>> 
>> The commit breaks image_types_uboot.bbclass:
>> 
>> ERROR: Logfile of failure stored in: 
>> /build/linaro/build/build/tmp-glibc/work/genericarmv8-oe-linux/linaro-image-minimal-initramfs/1.0-r0/temp/log.do_image_cpio.16506
>> Log data follows:
>> | DEBUG: Executing python function set_image_size
>> | DEBUG: Python function set_image_size finished
>> | DEBUG: Executing shell function do_image_cpio
>> | 31373 blocks
>> | Image Name:   linaro-image-minimal-initramfs-g
>> | Created:  Mon May 23 19:38:56 2016
>> | Image Type:   ARM Linux RAMDisk Image (gzip compressed)
>> | Data Size:7326620 Bytes = 7154.90 kB = 6.99 MB
>> | Load Address: 
>> | Entry Point:  
>> | mkimage: Can't open 
>> /build/linaro/build/build/tmp-glibc/deploy/images/genericarmv8/linaro-image-minimal-initramfs-genericarmv8-20160523173835.rootfs.cpio.gz:
>>  No such file or directory
>> 
>> This reverts commit 94f61c2682e5cfd819ac84535650c3e0a654415a.
>> 
>> Signed-off-by: Koen Kooi <koen.k...@linaro.org>
>> ---
>> meta/classes/image.bbclass | 8 ++--
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>> 
>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>> index 9f4c83f..df3bd3a 100644
>> --- a/meta/classes/image.bbclass
>> +++ b/meta/classes/image.bbclass
>> @@ -410,13 +410,9 @@ python () {
>># Create input image first.
>>gen_conversion_cmds(type)
>>localdata.setVar('type', type)
>> -cmd = "\t" + localdata.getVar("COMPRESS_CMD_" + ctype, 
>> True)
>> -if cmd not in cmds:
>> -cmds.append(cmd)
>> +cmds.append("\t" + localdata.getVar("COMPRESS_CMD_" + 
>> ctype, True))
>>vardeps.add('COMPRESS_CMD_' + ctype)
>> -subimage = type + "." + ctype
>> -if subimage not in subimages:
>> -subimages.append(subimage)
>> +subimages.append(type + "." + ctype)
>>if type not in alltypes:
>>
>> rm_tmp_images.add(localdata.expand("${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"))
>> 
>> -- 
>> 2.4.3
>> 
>> -- 
>> ___
>> 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] Revert "image.bbclass: don't execute compression commands multiple times"

[Koen Kooi]

ping

> Op 23 mei 2016, om 19:50 heeft Koen Kooi <koen.k...@linaro.org> het volgende 
> geschreven:
> 
> The commit breaks image_types_uboot.bbclass:
> 
> ERROR: Logfile of failure stored in: 
> /build/linaro/build/build/tmp-glibc/work/genericarmv8-oe-linux/linaro-image-minimal-initramfs/1.0-r0/temp/log.do_image_cpio.16506
> Log data follows:
> | DEBUG: Executing python function set_image_size
> | DEBUG: Python function set_image_size finished
> | DEBUG: Executing shell function do_image_cpio
> | 31373 blocks
> | Image Name:   linaro-image-minimal-initramfs-g
> | Created:  Mon May 23 19:38:56 2016
> | Image Type:   ARM Linux RAMDisk Image (gzip compressed)
> | Data Size:7326620 Bytes = 7154.90 kB = 6.99 MB
> | Load Address: 
> | Entry Point:  
> | mkimage: Can't open 
> /build/linaro/build/build/tmp-glibc/deploy/images/genericarmv8/linaro-image-minimal-initramfs-genericarmv8-20160523173835.rootfs.cpio.gz:
>  No such file or directory
> 
> This reverts commit 94f61c2682e5cfd819ac84535650c3e0a654415a.
> 
> Signed-off-by: Koen Kooi <koen.k...@linaro.org>
> ---
> meta/classes/image.bbclass | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 9f4c83f..df3bd3a 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -410,13 +410,9 @@ python () {
> # Create input image first.
> gen_conversion_cmds(type)
> localdata.setVar('type', type)
> -cmd = "\t" + localdata.getVar("COMPRESS_CMD_" + ctype, 
> True)
> -if cmd not in cmds:
> -cmds.append(cmd)
> +cmds.append("\t" + localdata.getVar("COMPRESS_CMD_" + 
> ctype, True))
> vardeps.add('COMPRESS_CMD_' + ctype)
> -subimage = type + "." + ctype
> -if subimage not in subimages:
> -subimages.append(subimage)
> +subimages.append(type + "." + ctype)
> if type not in alltypes:
> 
> rm_tmp_images.add(localdata.expand("${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"))
> 
> -- 
> 2.4.3
> 
> -- 
> ___
> 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] image.bbclass: don't execute compression commands multiple times

[Koen Kooi]

> Op 21 apr. 2016, om 11:47 heeft Alexander D. Kanevskiy  het 
> volgende geschreven:
> 
> In case of chained conversion methods are used via COMPRESS_CMD_*
> there is chance that some of steps would be executed multiple times.

And this breaks image_types_uboot.bbclass:

ERROR: Logfile of failure stored in: 
/build/linaro/build/build/tmp-glibc/work/genericarmv8-oe-linux/linaro-image-minimal-initramfs/1.0-r0/temp/log.do_image_cpio.16506
Log data follows:
| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_cpio
| 31373 blocks
| Image Name:   linaro-image-minimal-initramfs-g
| Created:  Mon May 23 19:38:56 2016
| Image Type:   ARM Linux RAMDisk Image (gzip compressed)
| Data Size:7326620 Bytes = 7154.90 kB = 6.99 MB
| Load Address: 
| Entry Point:  
| mkimage: Can't open 
/build/linaro/build/build/tmp-glibc/deploy/images/genericarmv8/linaro-image-minimal-initramfs-genericarmv8-20160523173835.rootfs.cpio.gz:
 No such file or directory

And I suspect this problem is better fixed with 
https://github.com/openembedded/openembedded-core/commit/85855af359c2c3bfc1eaa942c95f1f7d7cc6698e

> 
> [YOCTO #9482]
> 
> Signed-off-by: Alexander D. Kanevskiy 
> ---
> meta/classes/image.bbclass | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 8bfd241..5d6f4a3 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -398,9 +398,13 @@ python () {
> # Create input image first.
> gen_conversion_cmds(type)
> localdata.setVar('type', type)
> -cmds.append("\t" + localdata.getVar("COMPRESS_CMD_" + 
> ctype, True))
> +cmd = "\t" + localdata.getVar("COMPRESS_CMD_" + ctype, 
> True)
> +if cmd not in cmds:
> +cmds.append(cmd)
> vardeps.add('COMPRESS_CMD_' + ctype)
> -subimages.append(type + "." + ctype)
> +subimage = type + "." + ctype
> +if subimage not in subimages:
> +subimages.append(subimage)
> if type not in alltypes:
> 
> rm_tmp_images.add(localdata.expand("${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"))
> 
> -- 
> 2.8.1
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 

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

[OE-core] [PATCH] Revert "image.bbclass: don't execute compression commands multiple times"

[Koen Kooi]

The commit breaks image_types_uboot.bbclass:

ERROR: Logfile of failure stored in: 
/build/linaro/build/build/tmp-glibc/work/genericarmv8-oe-linux/linaro-image-minimal-initramfs/1.0-r0/temp/log.do_image_cpio.16506
Log data follows:
| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_cpio
| 31373 blocks
| Image Name:   linaro-image-minimal-initramfs-g
| Created:  Mon May 23 19:38:56 2016
| Image Type:   ARM Linux RAMDisk Image (gzip compressed)
| Data Size:7326620 Bytes = 7154.90 kB = 6.99 MB
| Load Address: 
| Entry Point:  
| mkimage: Can't open 
/build/linaro/build/build/tmp-glibc/deploy/images/genericarmv8/linaro-image-minimal-initramfs-genericarmv8-20160523173835.rootfs.cpio.gz:
 No such file or directory

This reverts commit 94f61c2682e5cfd819ac84535650c3e0a654415a.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/classes/image.bbclass | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 9f4c83f..df3bd3a 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -410,13 +410,9 @@ python () {
 # Create input image first.
 gen_conversion_cmds(type)
 localdata.setVar('type', type)
-cmd = "\t" + localdata.getVar("COMPRESS_CMD_" + ctype, 
True)
-if cmd not in cmds:
-cmds.append(cmd)
+cmds.append("\t" + localdata.getVar("COMPRESS_CMD_" + 
ctype, True))
 vardeps.add('COMPRESS_CMD_' + ctype)
-subimage = type + "." + ctype
-if subimage not in subimages:
-subimages.append(subimage)
+subimages.append(type + "." + ctype)
 if type not in alltypes:
 
rm_tmp_images.add(localdata.expand("${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"))
 
-- 
2.4.3

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

Re: [OE-core] xinput-calibrator startup question

[Koen Kooi]

> Op 19 apr. 2016, om 17:12 heeft Jussi Kukkonen <jussi.kukko...@intel.com> het 
> volgende geschreven:
> 
> Hi Koen,
> 
> I was looking at xinput-calibrator in preparation for bug 9365 "Remove
> xtscal in preference of xinput-calibrator", and I'm wondering if you
> remember the logic behind this commit:
> 
> commit 6464bcd67d10ab9967ac83c27c413c1014be707e
> Author: Koen Kooi <k...@dominion.thruhere.net>
> Date:   Wed Apr 30 11:33:23 2014 +0200
> 
>xinput-calibrator: fix XDG launch
> 
>In the move from meta-oe to OE-core XDG based launched was dropped
>without noting it in the commit message, so fix that regression.
> 
>Gnome-session will now launch the calibrator again.
> 
> The commit installs the app desktop file in the XDG autostart
> directory. But we already have a XSession script for a similar purpose
> -- the result in Sato is that xinput-calibrator runs twice (and I
> would expect that to happen in gnome as well)?
> 
> I'd like to either not install the desktop file or install it in
> applications directory, so please let me know if the reasons for the
> above commit might still be valid.

They are still valid, XDG is still the right place to launch it.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] toasterconf.json: Set default distro to nodistro

[Koen Kooi]

> Op 24 okt. 2015, om 16:39 heeft Khem Raj  het volgende 
> geschreven:
> 
> This makes it self-sufficient with OE-Core
> Generate ext4 instead of ext3, most of Qemu
> targets in oe-core now use ext4

Any reason this still hasn’t been applied yet?


> 
> Signed-off-by: Khem Raj 
> ---
> meta/conf/toasterconf.json | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/conf/toasterconf.json b/meta/conf/toasterconf.json
> index c8e42ef..1ee6d29 100644
> --- a/meta/conf/toasterconf.json
> +++ b/meta/conf/toasterconf.json
> @@ -1,8 +1,8 @@
> {
> "config": {
> "MACHINE"  : "qemux86",
> -"DISTRO"   : "poky",
> -"IMAGE_FSTYPES": "ext3 jffs2 tar.bz2",
> +"DISTRO"   : "nodistro",
> +"IMAGE_FSTYPES": "ext4 jffs2 tar.bz2",
> "IMAGE_INSTALL_append": "",
> "PACKAGE_CLASSES": "package_rpm",
> "SDKMACHINE"   : "x86_64"
> -- 
> 2.6.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

[OE-core] [dizzy][PATCH] glibc 2.20: Security fix CVE-2015-7547

[Koen Kooi]

CVE-2015-7547: getaddrinfo() stack-based buffer overflow

Signed-off-by: Koen Kooi <k...@dominion.thruhere.net>
---
 meta/recipes-core/glibc/glibc/CVE-2015-7547.patch | 583 ++
 meta/recipes-core/glibc/glibc_2.20.bb |   1 +
 2 files changed, 584 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-7547.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch 
b/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch
new file mode 100644
index 000..d877408
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch
@@ -0,0 +1,583 @@
+From e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca Mon Sep 17 00:00:00 2001
+From: Carlos O'Donell <car...@systemhalted.org>
+Date: Tue, 16 Feb 2016 21:26:37 -0500
+Subject: [PATCH] CVE-2015-7547: getaddrinfo() stack-based buffer overflow (Bug
+ 18665).
+
+* A stack-based buffer overflow was found in libresolv when invoked from
+  libnss_dns, allowing specially crafted DNS responses to seize control
+  of execution flow in the DNS client.  The buffer overflow occurs in
+  the functions send_dg (send datagram) and send_vc (send TCP) for the
+  NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC
+  family.  The use of AF_UNSPEC triggers the low-level resolver code to
+  send out two parallel queries for A and .  A mismanagement of the
+  buffers used for those queries could result in the response of a query
+  writing beyond the alloca allocated buffer created by
+  _nss_dns_gethostbyname4_r.  Buffer management is simplified to remove
+  the overflow.  Thanks to the Google Security Team and Red Hat for
+  reporting the security impact of this issue, and Robert Holiday of
+  Ciena for reporting the related bug 18665. (CVE-2015-7547)
+
+See also:
+https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
+https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html
+
+Upstream-Status: Backport
+CVE: CVE-2015-7547
+
+https://sourceware.org/git/?p=glibc.git;a=commit;h=e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca
+minor tweaking to remove Changelog and NEWS
+
+---
+ resolv/nss_dns/dns-host.c | 111 +++-
+ resolv/res_query.c|   3 +
+ resolv/res_send.c | 260 +++---
+ 3 files changed, 339 insertions(+), 66 deletions(-)
+
+diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
+index 3258e70..755832e 100644
+--- a/resolv/nss_dns/dns-host.c
 b/resolv/nss_dns/dns-host.c
+@@ -1031,7 +1031,10 @@ gaih_getanswer_slice (const querybuf *answer, int 
anslen, const char *qname,
+   int h_namelen = 0;
+ 
+   if (ancount == 0)
+-return NSS_STATUS_NOTFOUND;
++{
++  *h_errnop = HOST_NOT_FOUND;
++  return NSS_STATUS_NOTFOUND;
++}
+ 
+   while (ancount-- > 0 && cp < end_of_message && had_error == 0)
+ {
+@@ -1208,7 +1211,14 @@ gaih_getanswer_slice (const querybuf *answer, int 
anslen, const char *qname,
+   /* Special case here: if the resolver sent a result but it only
+  contains a CNAME while we are looking for a T_A or T_ record,
+  we fail with NOTFOUND instead of TRYAGAIN.  */
+-  return canon == NULL ? NSS_STATUS_TRYAGAIN : NSS_STATUS_NOTFOUND;
++  if (canon != NULL)
++{
++  *h_errnop = HOST_NOT_FOUND;
++  return NSS_STATUS_NOTFOUND;
++}
++
++  *h_errnop = NETDB_INTERNAL;
++  return NSS_STATUS_TRYAGAIN;
+ }
+ 
+ 
+@@ -1222,11 +1232,101 @@ gaih_getanswer (const querybuf *answer1, int anslen1, 
const querybuf *answer2,
+ 
+   enum nss_status status = NSS_STATUS_NOTFOUND;
+ 
++  /* Combining the NSS status of two distinct queries requires some
++ compromise and attention to symmetry (A or  queries can be
++ returned in any order).  What follows is a breakdown of how this
++ code is expected to work and why. We discuss only SUCCESS,
++ TRYAGAIN, NOTFOUND and UNAVAIL, since they are the only returns
++ that apply (though RETURN and MERGE exist).  We make a distinction
++ between TRYAGAIN (recoverable) and TRYAGAIN' (not-recoverable).
++ A recoverable TRYAGAIN is almost always due to buffer size issues
++ and returns ERANGE in errno and the caller is expected to retry
++ with a larger buffer.
++
++ Lastly, you may be tempted to make significant changes to the
++ conditions in this code to bring about symmetry between responses.
++ Please don't change anything without due consideration for
++ expected application behaviour.  Some of the synthesized responses
++ aren't very well thought out and sometimes appear to imply that
++ IPv4 responses are always answer 1, and IPv6 responses are always
++ answer 2, but that's not true (see the implementation of send_dg
++ and send_vc to see response can arrive in any order, particularly
++ for UDP). However, we expect it holds roughly enough of the time
++ that this code works, but certainly needs to be fixed to make this
+

[OE-core] [PATCH] e2fsprogs: disable libblkid again

[Koen Kooi]

We use the util-linux one and do_install deletes it anyway.

See OE-core commit fb8e776ea91c39d586b46400ad30aeea8dead1c4 for more info.

Signed-off-by: Koen Kooi <koen.k...@linaro.org>
---
 meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
index c82e99a..f244473 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
@@ -14,7 +14,7 @@ UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+\.\d+(\.\d+)*)$"
 
 EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir} \
 --enable-elf-shlibs --disable-libuuid --disable-uuidd \
---enable-libblkid --enable-verbose-makecmds"
+--disable-libblkid --enable-verbose-makecmds"
 
 EXTRA_OECONF_darwin = "--libdir=${base_libdir} --sbindir=${base_sbindir} 
--enable-bsd-shlibs"
 
-- 
2.4.3

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

Re: [OE-core] [PATCH 1/1] e2fsprogs: 1.42.9 -> 1.43-WIP

[Koen Kooi]

> Op 15 jan. 2016, om 03:05 heeft Robert Yang  het 
> volgende geschreven:
> 
> Upgrade to 1.43-WIP to make "mke2fs -d" support xattr, so that the layer
> which requires xattr such as meta-selinux can populate images easily.
> 
> 
> * Add --enable-libblkid to EXTRA_OECONF since libblkid is not created by
>  default.

*ahem*

commit fb8e776ea91c39d586b46400ad30aeea8dead1c4
Author: Richard Purdie 
Date:   Sat Aug 25 16:45:33 2012 +0100

e2fsprogs: Fully remove/disable blkid

We've removed libblkid from e2fsprogs as it was being provided by 
util-linux. The blkid
binary is also provided there and providing it within e2fsprogs too, linked 
against
a different and potentially incompatible library we're likely asking for 
trouble.

It also leads to inconsistencies in the native sysroot since we don't 
consistently
get one given provider of blkid (but always the liblibid from util-linux).

To clean this up, fully remove/disable the blkid binary and package.

Signed-off-by: Richard Purdie 

And the do_install in the recipe:

# We use blkid from util-linux now so remove from here
rm -f ${D}${base_libdir}/libblkid*
rm -rf ${D}${includedir}/blkid
rm -f ${D}${base_libdir}/pkgconfig/blkid.pc
rm -f ${D}${base_sbindir}/blkid
rm -f ${D}${base_sbindir}/fsck
rm -f ${D}${base_sbindir}/findfs


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

Re: [OE-core] [PATCH] e2fsprogs: disable libblkid again

[Koen Kooi]

On 21 January 2016 at 08:42, Robert Yang <liezhi.y...@windriver.com> wrote:
>
>
> On 01/21/2016 03:20 PM, Koen Kooi wrote:
>>
>> We use the util-linux one and do_install deletes it anyway.
>>
>> See OE-core commit fb8e776ea91c39d586b46400ad30aeea8dead1c4 for more info.
>>
>> Signed-off-by: Koen Kooi <koen.k...@linaro.org>
>> ---
>>   meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
>> b/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
>> index c82e99a..f244473 100644
>> --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
>> +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_git.bb
>> @@ -14,7 +14,7 @@ UPSTREAM_CHECK_GITTAGREGEX =
>> "v(?P\d+\.\d+(\.\d+)*)$"
>>
>>   EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir} \
>>   --enable-elf-shlibs --disable-libuuid --disable-uuidd \
>> ---enable-libblkid --enable-verbose-makecmds"
>> +--disable-libblkid --enable-verbose-makecmds"
>
>
> Thanks, maybe we also need cleanup other codes like:
>
> # We use blkid from util-linux now so remove from here
> rm -f ${D}${base_libdir}/libblkid*

That one should stay in, because we *really* don't want it to end up
in packages.

>
> And:
>
> ALTERNATIVE_${PN}-doc = "libblkid.3 blkid.8"
> ALTERNATIVE_LINK_NAME[libblkid.3] = "${mandir}/man3/libblkid.3"
> ALTERNATIVE_LINK_NAME[blkid.8] = "${mandir}/man8/blkid.8"

I don't have a strong opinion on those, RP?

>
> // Robert
>
>
>>
>>   EXTRA_OECONF_darwin = "--libdir=${base_libdir} --sbindir=${base_sbindir}
>> --enable-bsd-shlibs"
>>
>>
>



-- 
Koen Kooi

Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH 2/9] bash-completion: build nativesdk variant

[Koen Kooi]

> Op 14 jan. 2016, om 21:56 heeft George McCollister 
>  het volgende geschreven:
> 
> The nativesdk variant is required for some recipes like git to use the class.

Squash this into 1/9 to avoid mid-series breakage.

regards,

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

Re: [OE-core] fido -> jethro switching problem

[Koen Kooi]

> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz <sl...@dresearch-fe.de> het 
> volgende geschreven:
> 
> On 15.01.2016 15:29, Koen Kooi wrote:
>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sl...@dresearch-fe.de> het 
>>> volgende geschreven:
>>> It seems that all machines based on armv5e are affected.
>> 
>> FWIW, I'm seeing the same problem. The last time it happened it was due to 
>> the fixup angstrom does for broken arm BSPs
> 
> What commits do you talking about ("last time it happened")?
> 
> https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d
>  ?
> https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8
>  ?
> 
> Or something else?

Yes, those ones. 

regards,

Koen

> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058

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

Re: [OE-core] fido -> jethro switching problem

[Koen Kooi]

> Op 18 jan. 2016 om 11:10 heeft Steffen Sledz <sl...@dresearch-fe.de> het 
> volgende geschreven:
> 
> On 18.01.2016 09:41, Koen Kooi wrote:
>>> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz <sl...@dresearch-fe.de> het 
>>> volgende geschreven:
>>> On 15.01.2016 15:29, Koen Kooi wrote:
>>>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sl...@dresearch-fe.de> het 
>>>>> volgende geschreven:
>>>>> It seems that all machines based on armv5e are affected.
>>>> 
>>>> FWIW, I'm seeing the same problem. The last time it happened it was due to 
>>>> the fixup angstrom does for broken arm BSPs
>>> 
>>> What commits do you talking about ("last time it happened")?
>>> 
>>> https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d
>>>  ?
>>> https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8
>>>  ?
>>> 
>>> Or something else?
>> 
>> Yes, those ones.
> 
> If I understand right you only introduced an own DEFAULTUNE override for 
> angstrom to work around the problem. Right?

right

> 
> Did you identify the parts of meta-fsl-arm which were responsible for these 
> problems?

The machine includes that tune to cortex-foo instead of armvX. I don't need 5 
different versions of bash for 5 'different' armv7 machines.

> 
> Steffen
> 
> PS: Hi Otavio, I've added you to this discussion as the official meta-fsl-arm 
> maintainer.
> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

[Koen Kooi]

> Op 18 jan. 2016, om 12:55 heeft Steffen Sledz <sl...@dresearch-fe.de> het 
> volgende geschreven:
> 
> On 15.01.2016 15:29, Koen Kooi wrote:
>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz <sl...@dresearch-fe.de> het 
>>> volgende geschreven:
>>>> On 15.01.2016 14:24, Steffen Sledz wrote:
>>>> And I made another interesting discovery: The exception appears on certain 
>>>> machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 
>>>> not.
>>> 
>>> It seems that all machines based on armv5e are affected.
>> 
>> FWIW, I'm seeing the same problem. The last time it happened it was due to 
>> the fixup angstrom does for broken arm BSPs
> 
> I've identified this line from 
> meta-angstrom/conf/distro/include/angstrom.inc[1] as "trigger" for the 
> exception in the way, that commenting out this line avoids the exception.
> 
> --> snip <
> # Add FEED_ARCH to machine overrides so we get access to e.g. 'armv7a' and 
> 'sh4'
> # Hopefully we'll never see a machine or arch with 'all' as substring
> MACHINEOVERRIDES .= ":${@bb.data.getVar('FEED_ARCH', 
> d,1).replace('all','noarch')}"
> --> snip <

So that bit doesn’t do what it says it does anymore, this diff after removing 
it:

-# $MACHINEOVERRIDES [10 operations]
+# $MACHINEOVERRIDES [9 operations]
 #   set? /build/v2015.12/sources/openembedded-core/meta/conf/bitbake.conf:688
 # "${MACHINE}"
 #   set /build/v2015.12/sources/openembedded-core/meta/conf/bitbake.conf:689
@@ -9106,15 +9106,13 @@
 # "${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" ,d)}"
 #   predot 
/build/v2015.12/sources/openembedded-core/meta/conf/machine/include/arm/arch-armv4.inc:13
 # "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" ,d)}"
-#   postdot 
/build/v2015.12/sources/meta-angstrom/conf/distro/include/angstrom.inc:30
-# ":${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}"
 #   append 
/build/v2015.12/sources/meta-angstrom/conf/distro/include/angstrom-core-tweaks.inc:27
 # [vardepsexclude] "SOC_FAMILY"
 #   set 
/build/v2015.12/sources/openembedded-core/meta/conf/documentation.conf:282
 # [doc] "Lists overrides specific to the current machine. By default, this 
list includes the value of MACHINE."
 # pre-expansion value:
-#   "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv6", "armv6:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv7a", "armv7a:", "" ,d)}${@['', 
'${SOC_FAMILY}:']['${SOC_FAMILY}' != 
'']}${MACHINE}:${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}"
-MACHINEOVERRIDES="armv7a:ti33x:beaglebone:armv7at2hf-vfp-neon"
+#   "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv6", "armv6:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv7a", "armv7a:", "" ,d)}${@['', 
'${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}${MACHINE}"
+MACHINEOVERRIDES=“armv7a:ti33x:beaglebone"

So ‘armv7a’ is already there, 'armv7at2hf-vfp-neon’ isn’t needed since that 
information is availble from MACHINE_FEATURES already. I’ll drop the bit in 
jethro and master.

Thanks for tracking this down!

regards,

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

Re: [OE-core] fido -> jethro switching problem

[Koen Kooi]

> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz  het 
> volgende geschreven:
> 
>> On 15.01.2016 14:24, Steffen Sledz wrote:
>> And I made another interesting discovery: The exception appears on certain 
>> machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 
>> not.
> 
> It seems that all machines based on armv5e are affected.

FWIW, I'm seeing the same problem. The last time it happened it was due to the 
fixup angstrom does for broken arm BSPs


> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Patchwork & patch handling improvements

[Koen Kooi]

Op 26-11-15 om 22:00 schreef Paul Eggleton:
> Hi all,
> 
> Over the past several years one of the regular complaints people have made 
> about our project has been that patches sometimes take a long time to make it 
> into master, and it's not always clear what the state of a patch is during 
> that time. On the other side of things, maintainers are finding it 
> increasingly 
> hard to keep up with testing and integrating incoming patches. Additionally, 
> trivial mistakes sometimes creep in that would be fairly easy to catch with 
> an 
> automated process. We've been talking about this for a while and now I'd like 
> to propose a plan to finally address this:
> 
> 1) Upgrade the OE Patchwork instance [0] to a newer release; this should fix 
> some of the problems we are having [1] plus give us additional features. I 
> propose using the fork that freedesktop.org are using [2] [3] which is moving 
> a bit faster than upstream Patchwork; whilst the changes there may eventually 
> make it upstream (and work is ongoing there) we have a much greater ability 
> to 
> influence the fork given that it's being worked on by one of my colleagues 
> who 
> is pushing it in the direction we need it to go e.g. proper support for 
> series 
> as opposed to treating every patch individually, improved UI, etc.

I very much support upgrading patchwork to the fdo version, the set-aware
feature removes a lot of visual clutter.

regards,

Koen

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

Re: [OE-core] How to handle mesa customization in BSP layers

[Koen Kooi]

> Op 20 okt. 2015, om 11:32 heeft Nicolas Dechesne 
>  het volgende geschreven:
> 
> hi there,
> 
> in the meta-qcom BSP layer, I need to customize mesa to enable
> Gallium/freedreno driver which is not enabled in OE-core by default. I
> have been using a bbappend , see [1] so far.
> 
> However it was reported by Koen that his is causing issues, at least
> in Angstrom, though it's not specific to this distro.. See github
> comments on [2].
> 
> The issue is that mesa is arch specific, not machine specific. So if
> you start mixing machines from the same arch, we are getting
> unexpected/wrong rebuilds.
> 
> How am I supposed to handle that properly in a BSP layer? I don't
> think that enabling the freedreno driver should be a distro config, am
> i right?

I agree that making it a DISTRO thing is not the right answer, but it is 
exactly what I ended up doing: 
https://github.com/Angstrom-distribution/meta-angstrom/commit/549d58dd00cd0683d92b942e9574ef0d1e347e51

In this specific case I think we should enable freedreno for armv7/armv8 in 
OE-core, but the problem remains for other recipes like this.

regards,

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

[OE-core] [PATCH] gnu-efi: BBCLASSEXTEND to native

[Koen Kooi]

Sbsigntool depends on gnu-efi and we need sbsigntool-native to do some signing, 
so extend gnu-efi to support that.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb 
b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
index 27cc6c1..9ad258e 100644
--- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
+++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
@@ -39,3 +39,5 @@ do_install() {
 }
 
 FILES_${PN} += ${libdir}/*.lds
+
+BBCLASSEXTEND = native
-- 
2.1.0

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

Re: [OE-core] RFC: libav vs. ffmpeg, redux

[Koen Kooi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Eggleton schreef op 09-07-15 om 12:24:
 Hi all,
 
 A few years ago we made the switch from ffmpeg to libav (a mostly drop-in
  compatible fork), with fairly good justification at the time. However,
 it looks like Debian has just made the switch back to ffmpeg, citing a
 number of reasons - most notably more responsive security issue patching
 in recent history. Here's a page with their full reasoning:
 
 https://wiki.debian.org/Debate/libav-provider/ffmpeg
 
 Gstreamer (gst-libav, specifically) has also just recently made the
 switch back for its internal copy:
 
 https://bugzilla.gnome.org/show_bug.cgi?id=751607
 
 What do people think? Should we be looking to make the switch back in OE
 as well?

As much as I like the libav guys, ffmpeg seems to win the popular vote which
makes it easier to use. Kodi/xbmc has been named, opencv is another.

regards,

Koen

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFVn9RlMkyGM64RGpERAqwwAJ9SXkQ8WFLRlweCx2CenlK3L1F34ACfZo+R
pQzjY9o32AwZTC+OCqpNLXE=
=HCXC
-END PGP SIGNATURE-

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

[OE-core] [PATCH v2] cmake bbclass: fix support for native builds

[Koen Kooi]

For native builds  of recipes (e.g. mariadb-native) cmake *must* look outside 
of its sysroot to find the compiler, so instruct it to do so.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/classes/cmake.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b0a3972..c174246 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -27,6 +27,9 @@ OECMAKE_RPATH ?= 
 OECMAKE_PERLNATIVE_DIR ??= 
 OECMAKE_EXTRA_ROOT_PATH ?= 
 
+OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = ONLY
+OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = BOTH
+
 cmake_do_generate_toolchain_file() {
cat  ${WORKDIR}/toolchain.cmake EOF
 # CMake system name must be something like Linux.
@@ -50,7 +53,7 @@ set( CMAKE_CXX_LINK_FLAGS ${OECMAKE_CXX_LINK_FLAGS} CACHE 
STRING LDFLAGS )
 # up libraries and tools from the native build machine
 set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
 set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
-set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
+set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM} )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
 
-- 
1.9.3

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

Re: [OE-core] [PATCH] cmake bbclass: fix support for native builds

[Koen Kooi]

 Op 30 jun. 2015, om 15:28 heeft Stefan Herbrechtsmeier 
 ste...@herbrechtsmeier.net het volgende geschreven:
 
 Am 30.06.2015 um 15:18 schrieb Koen Kooi:
 For native builds  of recipes (e.g. mariadb-native) cmake *must* look 
 outside of its sysroot to find the compiler, so instruct it to do so.
 
 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
  meta/classes/cmake.bbclass | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
 index b0a3972..29a78e5 100644
 --- a/meta/classes/cmake.bbclass
 +++ b/meta/classes/cmake.bbclass
 @@ -27,6 +27,9 @@ OECMAKE_RPATH ?= 
  OECMAKE_PERLNATIVE_DIR ??= 
  OECMAKE_EXTRA_ROOT_PATH ?= 
  +OECMAKE_PATHS ?= 
 +OECMAKE_PATHS_class-native = set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH )
 +
  cmake_do_generate_toolchain_file() {
  cat  ${WORKDIR}/toolchain.cmake EOF
  # CMake system name must be something like Linux.
 @@ -67,6 +70,8 @@ list(APPEND CMAKE_MODULE_PATH 
 ${STAGING_DATADIR}/cmake/Modules/)
  # add for non /usr/lib libdir, e.g. /usr/lib64
  set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
  +${OECMAKE_PATHS}
 +
  EOF
  }
  
 This would generate a second set of the CMAKE_FIND_ROOT_PATH_MODE_PROGRAM 
 with a different value.
 
 Why not add a new variable and use it in the existing set:
 
 +OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = ONLY
 +OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = BOTH
 
 -set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
 +set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM 
 ${OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM})

That’s a much better solution, v2 coming up. Thanks for the feedback!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] cmake update broke mariadb

[Koen Kooi]

 Op 30 jun. 2015, om 12:32 heeft Stefan Herbrechtsmeier 
 ste...@herbrechtsmeier.net het volgende geschreven:
 
 Am 30.06.2015 um 11:59 schrieb Koen Kooi:
 Burton, Ross schreef op 30-06-15 om 11:44:
 On 30 June 2015 at 01:39, akuster808 akuster...@gmail.com wrote:
 
 eo-core commit f8661aa cmake: Upgrade 2.8.12.2 - 3.2.2 broke mariadb
 in meta-oe.
 
 DOes  the person who updated cmake need to fix this or the person who
 is feeling the pain will be fixing it ?
 
 Depends on what the breakage is really.  Can you provide build logs?
 ERROR: Function failed: do_configure (log file is located at
 /build/linaro/build/build/tmp-glibc/work/x86_64-linux/mariadb-native/5.5.44-r0/temp/log.do_configure.25603)
 ERROR: Logfile of failure stored in:
 /build/linaro/build/build/tmp-glibc/work/x86_64-linux/mariadb-native/5.5.44-r0/temp/log.do_configure.25603
 Log data follows:
 | DEBUG: Executing python function sysroot_cleansstate
 | DEBUG: Python function sysroot_cleansstate finished
 | DEBUG: Executing shell function autotools_preconfigure
 | DEBUG: Shell function autotools_preconfigure finished
 | DEBUG: Executing python function autotools_copy_aclocals
 | DEBUG: Python function autotools_copy_aclocals finished
 | DEBUG: Executing shell function do_configure
 | -- Running cmake version 3.2.2
 | -- The C compiler identification is GNU 4.8.3
 | -- The CXX compiler identification is GNU 4.8.3
 | CMake Error at CMakeLists.txt:86 (PROJECT):
 |   The CMAKE_C_COMPILER:
 |
 | gcc
 |
 |   is not a full path and was not found in the PATH.
 |
 |   Tell CMake where to find the compiler by setting either the environment
 |   variable CC or the CMake cache entry CMAKE_C_COMPILER to the full path 
 to
 |   the compiler, or to the compiler name if it is in the PATH.
 |
 |
 | CMake Error at CMakeLists.txt:86 (PROJECT):
 |   The CMAKE_CXX_COMPILER:
 |
 | g++
 |
 |   is not a full path and was not found in the PATH.
 |
 |   Tell CMake where to find the compiler by setting either the environment
 |   variable CXX or the CMake cache entry CMAKE_CXX_COMPILER to the full 
 path
 |   to the compiler, or to the compiler name if it is in the PATH.
 |
 |
 | -- Configuring incomplete, errors occurred!
 The problem should be the usage of cmake for a native package.
 
 The cmake.bbclass disables the host path and thereby CMake could not find the 
 gcc binary.
 
 I think the cmake.bbclass need to distinguish between cross and native build 
 and set the following for native build:
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH )
 set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH )
 
 This allows CMake to search the binaries, libraries and includes first in the 
 CMAKE_FIND_ROOT_PATH, then in the CMAKE_SYSROOT and then in the non-rooted 
 directories.

THanks for the hint, I’m going to test something like this:

[koen@thinkpad classes]$ git diff
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b0a3972..ead4a26 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -27,6 +27,13 @@ OECMAKE_RPATH ?= 
 OECMAKE_PERLNATIVE_DIR ??= 
 OECMAKE_EXTRA_ROOT_PATH ?= 
 
+OECMAKE_PATHS ?= 
+OECMAKE_PATHS_class-native =  \
+set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH ) \
+set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH ) \
+set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH ) \
+
+
 cmake_do_generate_toolchain_file() {
cat  ${WORKDIR}/toolchain.cmake EOF
 # CMake system name must be something like Linux.
@@ -67,7 +74,10 @@ list(APPEND CMAKE_MODULE_PATH 
${STAGING_DATADIR}/cmake/Modules/)
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
 
+${OECMAKE_PATHS}
+
 EOF
+
 }
 
 addtask generate_toolchain_file after do_patch before do_configure

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

[OE-core] [PATCH] cmake bbclass: fix support for native builds

[Koen Kooi]

For native builds  of recipes (e.g. mariadb-native) cmake *must* look outside 
of its sysroot to find the compiler, so instruct it to do so.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/classes/cmake.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b0a3972..29a78e5 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -27,6 +27,9 @@ OECMAKE_RPATH ?= 
 OECMAKE_PERLNATIVE_DIR ??= 
 OECMAKE_EXTRA_ROOT_PATH ?= 
 
+OECMAKE_PATHS ?= 
+OECMAKE_PATHS_class-native = set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH )
+
 cmake_do_generate_toolchain_file() {
cat  ${WORKDIR}/toolchain.cmake EOF
 # CMake system name must be something like Linux.
@@ -67,6 +70,8 @@ list(APPEND CMAKE_MODULE_PATH 
${STAGING_DATADIR}/cmake/Modules/)
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
 
+${OECMAKE_PATHS}
+
 EOF
 }
 
-- 
1.9.3

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

Re: [OE-core] cmake update broke mariadb

[Koen Kooi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

akuster808 schreef op 30-06-15 om 02:39:
 
 Hello,
 
 eo-core commit f8661aa cmake: Upgrade 2.8.12.2 - 3.2.2 broke mariadb
 in meta-oe.
 
 DOes  the person who updated cmake need to fix this or the person who is 
 feeling the pain will be fixing it ?

I've been looking at this mariadb error and I've made no progress beyond
upgrading it to the latest 5.5.x, which shows the same cmake problem

regards,

Koen

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFVkmi6MkyGM64RGpERAmrsAJ0bCkH5omgOzpnB0dT8A6amMrYH6gCfU50x
ZObEl6kQHbI+QDeiui3GxfU=
=E2ZF
-END PGP SIGNATURE-

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

[OE-core] [PATCH] bootimg bbclass: don't hardcode 'bzImage' name

[Koen Kooi]

In the EFI case there are 2 more architectures besides x86(_64) that may use 
this class: aarch32, which tends to use 'zImage' and aarch64, which uses 
'Image'. Instead of hardcoding those values like the luvOS fork does, use the 
proper variable.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/classes/bootimg.bbclass | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index b1c03ba..d248321 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -47,6 +47,8 @@ EFI = ${@bb.utils.contains(MACHINE_FEATURES, efi, 1, 
0, d)}
 EFI_PROVIDER ?= grub-efi
 EFI_CLASS = ${@bb.utils.contains(MACHINE_FEATURES, efi, 
${EFI_PROVIDER}, , d)}
 
+KERNEL_IMAGETYPE ??= bzImage
+
 # Include legacy boot if MACHINE_FEATURES includes pcbios or if it does not
 # contain efi. This way legacy is supported by default if neither is
 # specified, maintaining the original behavior.
@@ -66,8 +68,8 @@ populate() {
DEST=$1
install -d ${DEST}
 
-   # Install bzImage, initrd, and rootfs.img in DEST for all loaders to 
use.
-   install -m 0644 ${DEPLOY_DIR_IMAGE}/bzImage ${DEST}/vmlinuz
+   # Install kernel, initrd, and rootfs.img in DEST for all loaders to use.
+   install -m 0644 ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE} ${DEST}/vmlinuz

# initrd is made of concatenation of multiple filesystem images
if [ -n ${INITRD} ]; then
-- 
1.9.3

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

Re: [OE-core] [fido] orphaned bbappend in meta-angstrom

[Koen Kooi]

 Op 4 mei 2015, om 07:46 heeft Steffen Sledz sl...@dresearch-fe.de het 
 volgende geschreven:
 
 On 30.04.2015 08:07, Steffen Sledz wrote:
 The angstrom-v2015.06-yocto1.8 branch of meta-angstrom contains 
 recipes-tweaks/linux/linux-yocto_3.10.bbappend. But the fido branch of 
 openembedded-core does not have a recipe for linux-yocto_3.10 (just 3.14 and 
 3.19).
 
 So the bbappend should be removed or updated.
 
 Ping!


https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2350b1fdcffd31717c4ce256403fe2b391bb8d
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Revert kernel-arch.bbclass: add arm64 support to U-Boot architecture map

[Koen Kooi]

 Op 19 feb. 2015, om 04:34 heeft Nathan Rossi nathan.ro...@xilinx.com het 
 volgende geschreven:
 
 This reverts commit 0b891265716c414ade29d587fc1a3c4ea7beadbe.
 
 U-Boot does support AArch64, this however was only added to newer
 versions of U-Boot and at the time of this original commit the U-Boot in
 OE-Core did not support the 'arm64' architecture. OE-Core now has a
 newer version of U-Boot for the mkimage recipe and thus supports the
 'arm64' architecture.
 
 Signed-off-by: Nathan Rossi nathan.ro...@xilinx.com
 ---
 meta/classes/kernel-arch.bbclass | 1 -
 1 file changed, 1 deletion(-)
 
 diff --git a/meta/classes/kernel-arch.bbclass 
 b/meta/classes/kernel-arch.bbclass
 index bbcfa15..6a6ad91 100644
 --- a/meta/classes/kernel-arch.bbclass
 +++ b/meta/classes/kernel-arch.bbclass
 @@ -40,7 +40,6 @@ def map_uboot_arch(a, d):
 
 if   re.match('p(pc|owerpc)(|64)', a): return 'ppc'
 elif re.match('i.86$', a): return 'x86'
 -elif re.match('arm64$', a): return 'arm'
 return a

I just debugged a boot failure to this revert. The machine in question is using 
u-boot 2013.04 + vendor patches and can’t be replaced at this time.  I get that 
OE doesn’t care about vendor trees using obsolete versions, but this case is 
extra annoying because a few lines later this bbclass does:

 export UBOOT_ARCH = ${@map_uboot_arch(d.getVar('ARCH', True), d)}

instead of:

 export UBOOT_ARCH ?= ${@map_uboot_arch(d.getVar('ARCH', True), d)}

So now I’m forced to overlay kernel-arch.bbclass with the revert reverted and 
hope I don’t get any machines with a recent u-boot. Having said all that, 
modern uboots should default to zImage for arm32 and Image for aarch64 and have 
CONFIG_SUPPORT_RAW_INITRD enabled so mkimage isn;t needed anymore.

So, opinions on weakly assigning UBOOT_ARCH?

--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs



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

Re: [OE-core] [PATCH] Revert kernel-arch.bbclass: add arm64 support to U-Boot architecture map

[Koen Kooi]

 Op 22 apr. 2015, om 09:18 heeft Koen Kooi koen.k...@linaro.org het volgende 
 geschreven:
 
 
 Op 19 feb. 2015, om 04:34 heeft Nathan Rossi nathan.ro...@xilinx.com het 
 volgende geschreven:
 
 This reverts commit 0b891265716c414ade29d587fc1a3c4ea7beadbe.
 
 U-Boot does support AArch64, this however was only added to newer
 versions of U-Boot and at the time of this original commit the U-Boot in
 OE-Core did not support the 'arm64' architecture. OE-Core now has a
 newer version of U-Boot for the mkimage recipe and thus supports the
 'arm64' architecture.
 
 Signed-off-by: Nathan Rossi nathan.ro...@xilinx.com
 ---
 meta/classes/kernel-arch.bbclass | 1 -
 1 file changed, 1 deletion(-)
 
 diff --git a/meta/classes/kernel-arch.bbclass 
 b/meta/classes/kernel-arch.bbclass
 index bbcfa15..6a6ad91 100644
 --- a/meta/classes/kernel-arch.bbclass
 +++ b/meta/classes/kernel-arch.bbclass
 @@ -40,7 +40,6 @@ def map_uboot_arch(a, d):
 
if   re.match('p(pc|owerpc)(|64)', a): return 'ppc'
elif re.match('i.86$', a): return 'x86'
 -elif re.match('arm64$', a): return 'arm'
return a
 
 I just debugged a boot failure to this revert. The machine in question is 
 using u-boot 2013.04 + vendor patches and can’t be replaced at this time.  I 
 get that OE doesn’t care about vendor trees using obsolete versions, but this 
 case is extra annoying because a few lines later this bbclass does:
 
 export UBOOT_ARCH = ${@map_uboot_arch(d.getVar('ARCH', True), d)}
 
 instead of:
 
 export UBOOT_ARCH ?= ${@map_uboot_arch(d.getVar('ARCH', True), d)}
 
 So now I’m forced to overlay kernel-arch.bbclass with the revert reverted and 
 hope I don’t get any machines with a recent u-boot. Having said all that, 
 modern uboots should default to zImage for arm32 and Image for aarch64 and 
 have CONFIG_SUPPORT_RAW_INITRD enabled so mkimage isn;t needed anymore.
 
 So, opinions on weakly assigning UBOOT_ARCH?

Nathan corrected my thinko:

09:25  nrossi just curious around the UBOOT_ARCH, does overriding it work? as 
in  UBOOT_ARCH_machine = foo
09:26  * koen tries
09:38  nrossi koen: i think changing it to a ?= for the future is probably 
worth it. But i imagine getting that change backported would be a pain
09:40  koen UBOOT_ARCH_aarch64 = arm in local.conf also seems to work
09:41  koen I never realized that would take precedence over python methods
09:41  nrossi well its not the python method that is setting it
09:42  koen ah, right
09:42  koen it's set using a method, not by the method

So I don’t need the class overlay anymore!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] strace: fix build for aarch64

[Koen Kooi]

 Op 15 apr. 2015, om 15:29 heeft Richard Purdie 
 richard.pur...@linuxfoundation.org het volgende geschreven:
 
 On Wed, 2015-04-15 at 14:32 +0200, Koen Kooi wrote:
 Upstream added aarch64 support but forgot to update 'make dist' leading to 
 missing files in the tarball.
 
 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
 .../0001-Add-linux-aarch64-arch_regs.h.patch   | 25 
 ++
 meta/recipes-devtools/strace/strace_4.10.bb|  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 
 meta/recipes-devtools/strace/strace/0001-Add-linux-aarch64-arch_regs.h.patch
 
 I'm guessing this is a better fix than Robert's fix for strace?

This shrinks the diff between strace.git and ${S}, Roberts version increases 
it. It’s the same one-liner type fix, though.

 Let me know if they're different issues…

It’s the same issue.

regards,

Koen.

 
 Cheers,
 
 Richard
 
 diff --git 
 a/meta/recipes-devtools/strace/strace/0001-Add-linux-aarch64-arch_regs.h.patch
  
 b/meta/recipes-devtools/strace/strace/0001-Add-linux-aarch64-arch_regs.h.patch
 new file mode 100644
 index 000..f70766b
 --- /dev/null
 +++ 
 b/meta/recipes-devtools/strace/strace/0001-Add-linux-aarch64-arch_regs.h.patch
 @@ -0,0 +1,25 @@
 +From f85854131c8265f2eb59c714dcea5c4b3dc09bed Mon Sep 17 00:00:00 2001
 +From: Koen Kooi koen.k...@linaro.org
 +Date: Wed, 15 Apr 2015 14:29:37 +0200
 +Subject: [PATCH] Add linux/aarch64/arch_regs.h
 +
 +It is missing from the tarball, but it is present in git for v4.10
 +
 +Signed-off-by: Koen Kooi koen.k...@linaro.org
 +Upstream-status: Pending
 +---
 + linux/aarch64/arch_regs.h | 2 ++
 + 1 file changed, 2 insertions(+)
 + create mode 100644 linux/aarch64/arch_regs.h
 +
 +diff --git a/linux/aarch64/arch_regs.h b/linux/aarch64/arch_regs.h
 +new file mode 100644
 +index 000..9a5e33e
 +--- /dev/null
  b/linux/aarch64/arch_regs.h
 +@@ -0,0 +1,2 @@
 ++extern uint64_t *const aarch64_sp_ptr;
 ++extern uint32_t *const arm_sp_ptr;
 +-- 
 +1.9.3
 +
 diff --git a/meta/recipes-devtools/strace/strace_4.10.bb 
 b/meta/recipes-devtools/strace/strace_4.10.bb
 index 416c387..707cb76 100644
 --- a/meta/recipes-devtools/strace/strace_4.10.bb
 +++ b/meta/recipes-devtools/strace/strace_4.10.bb
 @@ -5,6 +5,7 @@ LICENSE = BSD
 LIC_FILES_CHKSUM = file://COPYING;md5=124500c21e856f0912df29295ba104c7
 
 SRC_URI = ${SOURCEFORGE_MIRROR}/strace/strace-${PV}.tar.xz \
 +   file://0001-Add-linux-aarch64-arch_regs.h.patch \
file://git-version-gen \
file://strace-add-configure-options.patch \
file://Makefile-ptest.patch \
 -- 
 1.9.3
 
 
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core
 

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

[OE-core] [PATCH] strace: fix build for aarch64

[Koen Kooi]

Upstream added aarch64 support but forgot to update 'make dist' leading to 
missing files in the tarball.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 .../0001-Add-linux-aarch64-arch_regs.h.patch   | 25 ++
 meta/recipes-devtools/strace/strace_4.10.bb|  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 
meta/recipes-devtools/strace/strace/0001-Add-linux-aarch64-arch_regs.h.patch

diff --git 
a/meta/recipes-devtools/strace/strace/0001-Add-linux-aarch64-arch_regs.h.patch 
b/meta/recipes-devtools/strace/strace/0001-Add-linux-aarch64-arch_regs.h.patch
new file mode 100644
index 000..f70766b
--- /dev/null
+++ 
b/meta/recipes-devtools/strace/strace/0001-Add-linux-aarch64-arch_regs.h.patch
@@ -0,0 +1,25 @@
+From f85854131c8265f2eb59c714dcea5c4b3dc09bed Mon Sep 17 00:00:00 2001
+From: Koen Kooi koen.k...@linaro.org
+Date: Wed, 15 Apr 2015 14:29:37 +0200
+Subject: [PATCH] Add linux/aarch64/arch_regs.h
+
+It is missing from the tarball, but it is present in git for v4.10
+
+Signed-off-by: Koen Kooi koen.k...@linaro.org
+Upstream-status: Pending
+---
+ linux/aarch64/arch_regs.h | 2 ++
+ 1 file changed, 2 insertions(+)
+ create mode 100644 linux/aarch64/arch_regs.h
+
+diff --git a/linux/aarch64/arch_regs.h b/linux/aarch64/arch_regs.h
+new file mode 100644
+index 000..9a5e33e
+--- /dev/null
 b/linux/aarch64/arch_regs.h
+@@ -0,0 +1,2 @@
++extern uint64_t *const aarch64_sp_ptr;
++extern uint32_t *const arm_sp_ptr;
+-- 
+1.9.3
+
diff --git a/meta/recipes-devtools/strace/strace_4.10.bb 
b/meta/recipes-devtools/strace/strace_4.10.bb
index 416c387..707cb76 100644
--- a/meta/recipes-devtools/strace/strace_4.10.bb
+++ b/meta/recipes-devtools/strace/strace_4.10.bb
@@ -5,6 +5,7 @@ LICENSE = BSD
 LIC_FILES_CHKSUM = file://COPYING;md5=124500c21e856f0912df29295ba104c7
 
 SRC_URI = ${SOURCEFORGE_MIRROR}/strace/strace-${PV}.tar.xz \
+   file://0001-Add-linux-aarch64-arch_regs.h.patch \
file://git-version-gen \
file://strace-add-configure-options.patch \
file://Makefile-ptest.patch \
-- 
1.9.3

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

[OE-core] [PATCH] libgpg-error 1.18: simplify tupple handling and add armv8b support

[Koen Kooi]

Add a default option to the case statement and remove the duplicates. Also add 
support for armv8b architectures.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/recipes-support/libgpg-error/libgpg-error_1.18.bb | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-support/libgpg-error/libgpg-error_1.18.bb 
b/meta/recipes-support/libgpg-error/libgpg-error_1.18.bb
index 268066b..c9a47a3 100644
--- a/meta/recipes-support/libgpg-error/libgpg-error_1.18.bb
+++ b/meta/recipes-support/libgpg-error/libgpg-error_1.18.bb
@@ -27,18 +27,14 @@ do_compile_prepend() {
fi
 
case ${TARGET_ARCH} in
- aarch64)TUPLE=aarch64-unknown-linux-gnu ;;
+ aarch64_be) TUPLE=aarch64-unknown-linux-gnu ;;
  arm)TUPLE=arm-unknown-linux-gnueabi ;;
  armeb)  TUPLE=arm-unknown-linux-gnueabi ;;
  i586|i686)  TUPLE=i486-pc-linux-gnu ;;
- mipsel) TUPLE=mipsel-unknown-linux-gnu ;;
  mips64el)   TUPLE=mipsel-unknown-linux-gnu ;;
  mips64) TUPLE=mips-unknown-linux-gnu ;;
- mips)   TUPLE=mips-unknown-linux-gnu ;;
- powerpc64)  TUPLE=powerpc64-unknown-linux-gnu ;;
- powerpc)TUPLE=powerpc-unknown-linux-gnu ;;
- sh4)TUPLE=sh4-unknown-linux-gnu ;;
  x86_64) TUPLE=x86_64-pc-linux-gnu ;;
+ *)  TUPLE=${TARGET_ARCH}-unknown-linux-gnu ;; 
esac
 
cp ${S}/src/syscfg/lock-obj-pub.$TUPLE.h \
-- 
1.9.3

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

[OE-core] [PATCH 2/3] gst-ffmpeg: remove bogus patch that leads to build failures

[Koen Kooi]

'0001-huffyuvdec-check-width-more-completely-avoid-out-of-.patch'
patches the internal copy of ffmpeg with a hunk that generates a compile
failure because AV_PIX_FMT_YUV422P is undefined.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 ...check-width-more-completely-avoid-out-of-.patch | 30 --
 .../gstreamer/gst-ffmpeg_0.10.13.bb|  1 -
 2 files changed, 31 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/0001-huffyuvdec-check-width-more-completely-avoid-out-of-.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/0001-huffyuvdec-check-width-more-completely-avoid-out-of-.patch
 
b/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/0001-huffyuvdec-check-width-more-completely-avoid-out-of-.patch
deleted file mode 100644
index 6b60d16..000
--- 
a/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/0001-huffyuvdec-check-width-more-completely-avoid-out-of-.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-gst-ffmpeg: huffyuvdec: check width more completely, avoid out of array
- accesses
-
-Found-by: Mateusz j00ru Jurczyk and Gynvael Coldwind
-
-Upstream-Status: Backport 
-
-Signed-off-by: Michael Niedermayer michae...@gmx.at

- libavcodec/huffyuv.c |5 -
- 1 files changed, 4 insertions(+), 1 deletions(-)
-
-diff --git a/libavcodec/huffyuv.c b/libavcodec/huffyuv.c
-index 6e88114..ca5bcd8 100644
 a/gst-libs/ext/libav/libavcodec/huffyuv.c
-+++ b/gst-libs/ext/libav/libavcodec/huffyuv.c
-@@ -526,6 +526,10 @@ s-bgr32=1;
- assert(0);
- }
- 
-+if (s-predictor == MEDIAN  avctx-pix_fmt == AV_PIX_FMT_YUV422P  
avctx-width%4) {
-+av_log(avctx, AV_LOG_ERROR, width must be a multiple of 4 this 
colorspace and predictor\n);
-+return AVERROR_INVALIDDATA;
-+}
- alloc_temp(s);
- 
- //av_log(NULL, AV_LOG_DEBUG, pred:%d bpp:%d hbpp:%d il:%d\n, 
s-predictor, s-bitstream_bpp, avctx-bits_per_coded_sample, s-interlaced);
--- 
-1.7.5.4
-
diff --git a/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb 
b/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
index 219feaa..e1a13c4 100644
--- a/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
@@ -46,7 +46,6 @@ SRC_URI = 
http://gstreamer.freedesktop.org/src/${BPN}/${BPN}-${PV}.tar.bz2 \

file://0001-avcodec-rpza-Perform-pointer-advance-and-checks-befo.patch \
file://gst-ffmpeg-CVE-2013-0855.patch \
file://0001-qdm2dec-fix-buffer-overflow.patch \
-   
file://0001-huffyuvdec-check-width-more-completely-avoid-out-of-.patch \

file://0001-smackerdec-Check-that-the-last-indexes-are-within-th.patch \

file://0001-avcodec-dsputil-fix-signedness-in-sizeof-comparissio.patch \
file://0001-error-concealment-initialize-block-index.patch \
-- 
1.9.0

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

[OE-core] [PATCH 3/3] gst-ffmpeg: fix internal-libav builds with inherit autotools-brokensep

[Koen Kooi]

Building the internal copy of ffmpeg is broken when using S!=B, so
inherit autotools-brokensep

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb 
b/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
index e1a13c4..b5c838f 100644
--- a/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
@@ -14,7 +14,7 @@ LICENSE_FLAGS = commercial
 HOMEPAGE = http://www.gstreamer.net/;
 DEPENDS = gstreamer gst-plugins-base zlib bzip2 yasm-native libpostproc
 
-inherit autotools pkgconfig
+inherit autotools-brokensep pkgconfig
 
 SRC_URI = http://gstreamer.freedesktop.org/src/${BPN}/${BPN}-${PV}.tar.bz2 \
file://lower-rank.diff \
-- 
1.9.0

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

[OE-core] [PATCH 1/3] gst-ffmpeg: fix libav-9.patch

[Koen Kooi]

The patch has a stray '' in an #incude directive leading to build
failures when used.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/libav-9.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/libav-9.patch 
b/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/libav-9.patch
index 9055b34..1860752 100644
--- a/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/libav-9.patch
+++ b/meta/recipes-multimedia/gstreamer/gst-ffmpeg-0.10.13/libav-9.patch
@@ -111,7 +111,7 @@ diff -uNr 
gst-ffmpeg-0.10.13.orig/ext/ffmpeg/gstffmpegcodecmap.c gst-ffmpeg-0.10
  #include gst/gst.h
  #ifdef HAVE_FFMPEG_UNINSTALLED
  #include avcodec.h
-+#include channel_layout.h
++#include channel_layout.h
  #else
  #include libavcodec/avcodec.h
 +#include libavutil/channel_layout.h
-- 
1.9.0

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

[OE-core] [PATCH] sysprof: fix arm big-endian build.

[Koen Kooi]

Applying the existing ARM patch for armeb makes it work.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/recipes-kernel/sysprof/sysprof_git.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/sysprof/sysprof_git.bb 
b/meta/recipes-kernel/sysprof/sysprof_git.bb
index e18aebf..19c3e10 100644
--- a/meta/recipes-kernel/sysprof/sysprof_git.bb
+++ b/meta/recipes-kernel/sysprof/sysprof_git.bb
@@ -12,6 +12,7 @@ SRC_URI = git://git.gnome.org/sysprof \
   
 
 SRC_URI_append_arm  =  file://rmb-arm.patch
+SRC_URI_append_armeb  =  file://rmb-arm.patch
 SRC_URI_append_mips =  file://rmb-mips.patch
 SRC_URI_append_mips64 =  file://rmb-mips.patch
 SRC_URI_append_mips64n32 =  file://rmb-mips.patch
-- 
1.9.3

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

[OE-core] [PATCH] bitbake.conf: use http:// for GNU_MIRROR instead of ftp://

[Koen Kooi]

The past few weeks ftp://ftp.gnu.org has been intermittently giving errors like 
this:

WARNING: Failed to fetch URL 
ftp://ftp.gnu.org/gnu/emacs/emacs-23.4.tar.gz;name=tarball, attempting MIRRORS 
if available
ERROR: Fetcher failure: Fetch command failed with exit code 4, output:
Cannot parse PASV response.
accept: Connection timed out
Cannot parse PASV response.
Error in server response, closing control connection.

Which is annoying because binutils lives there. Using http://ftp.gnu.org hasn't 
given any problems so far.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 10ee42a..f3586da 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -565,7 +565,7 @@ DEBIAN_MIRROR = ftp://ftp.debian.org/debian/pool;
 GENTOO_MIRROR = http://distfiles.gentoo.org/distfiles;
 GNOME_GIT = git://git.gnome.org
 GNOME_MIRROR = http://ftp.gnome.org/pub/GNOME/sources;
-GNU_MIRROR = ftp://ftp.gnu.org/gnu;
+GNU_MIRROR = http://ftp.gnu.org/gnu;
 GPE_MIRROR = http://gpe.linuxtogo.org/download/source;
 KERNELORG_MIRROR = http://kernel.org/pub;
 SOURCEFORGE_MIRROR = http://downloads.sourceforge.net;
-- 
1.9.3

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

[OE-core] [PATCH] linux-dummy: provide empty shared_workdir method

[Koen Kooi]

Perf.bb (among others) requires access to the kernel source, so have 
linux-dummy fake that as well. As before, perf will fail to build, but there 
are use cases where this patch is needed. For example a perf.bbappend that will 
always build it from the debian linux-tools tarball.

Using linux-dummy is still a bad, bad idea, but it shouldn't start breaking 
existing use cases.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/recipes-kernel/linux/linux-dummy.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-dummy.bb 
b/meta/recipes-kernel/linux/linux-dummy.bb
index 8f25f17..cc0e4e6 100644
--- a/meta/recipes-kernel/linux/linux-dummy.bb
+++ b/meta/recipes-kernel/linux/linux-dummy.bb
@@ -33,6 +33,10 @@ do_compile () {
:
 }
 
+do_shared_workdir () {
+   :
+}
+
 do_install() {
:
 }
@@ -47,4 +51,4 @@ do_deploy() {
 
 addtask bundle_initramfs after do_install before do_deploy
 addtask deploy after do_install
-
+addtask shared_workdir after do_compile before do_install
-- 
1.9.3

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

[OE-core] [PATCH] libgpg-error 1.17: simplify tupple handling and add armv8b support

[Koen Kooi]

Add a default option to the case statement and remove the duplicates. Also add 
support for armv8b architectures.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/recipes-support/libgpg-error/libgpg-error_1.17.bb | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-support/libgpg-error/libgpg-error_1.17.bb 
b/meta/recipes-support/libgpg-error/libgpg-error_1.17.bb
index c905bd1..843b9ae 100644
--- a/meta/recipes-support/libgpg-error/libgpg-error_1.17.bb
+++ b/meta/recipes-support/libgpg-error/libgpg-error_1.17.bb
@@ -28,18 +28,14 @@ do_compile_prepend() {
fi
 
case ${TARGET_ARCH} in
- aarch64)TUPLE=aarch64-unknown-linux-gnu ;;
+ aarch64_be) TUPLE=aarch64-unknown-linux-gnu ;;
  arm)TUPLE=arm-unknown-linux-gnueabi ;;
  armeb)  TUPLE=arm-unknown-linux-gnueabi ;;
  i586)   TUPLE=i486-pc-linux-gnu ;;
- mipsel) TUPLE=mipsel-unknown-linux-gnu ;;
  mips64el)   TUPLE=mipsel-unknown-linux-gnu ;;
  mips64) TUPLE=mips-unknown-linux-gnu ;;
- mips)   TUPLE=mips-unknown-linux-gnu ;;
- powerpc64)  TUPLE=powerpc64-unknown-linux-gnu ;;
- powerpc)TUPLE=powerpc-unknown-linux-gnu ;;
- sh4)TUPLE=sh4-unknown-linux-gnu ;;
  x86_64) TUPLE=x86_64-pc-linux-gnu ;;
+ *)  TUPLE=${TARGET_ARCH}-unknown-linux-gnu ;; 
esac
 
cp ${S}/src/syscfg/lock-obj-pub.$TUPLE.h \
-- 
1.9.3

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

Re: [OE-core] [PATCH] gstreamer1.0-omx: use mulitple SCMs to fetch submodules

[Koen Kooi]

 Op 29 dec. 2014, om 13:41 heeft Nicolas Dechesne 
 nicolas.deche...@linaro.org het volgende geschreven:
 
 On Mon, Dec 29, 2014 at 10:46 AM, Awais Belal awais_be...@mentor.com wrote:
 The gstreamer omx package uses a submodule 'common' which
 is fetched by the configure script. This approach fails
 on non-network builds as the fetcher tries to look upstream
 for the submodule.
 We now use multiple SCMs, one for the main omx package and
 the other for the 'common' submodule so it is available in
 the downloads_dir for later use.
 
 
 we have the same issues with all the others gstreamer1.0-*_git.bb
 recipes, don't we? maybe we should fix them all. i am not sure if
 there is a nice way to do it for all recipes, like with a .inc file,
 to avoid duplication..

Why not use the 'gitsm' fetcher, that's what it's there for after all?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 09/24] libpng: add neon option for aarch64

[Koen Kooi]

 Op 7 nov. 2014, om 09:51 heeft Kai Kang kai.k...@windriver.com het volgende 
 geschreven:
 
 Add neon option for aarch64 just as for arm. It fails with:
 
 | ./.libs/libpng16.so: undefined reference to `png_init_filter_functions_neon'
 | collect2: error: ld returned 1 exit status
 
 Signed-off-by: Kai Kang kai.k...@windriver.com
 ---
 meta/recipes-multimedia/libpng/libpng_1.6.13.bb | 1 +
 1 file changed, 1 insertion(+)
 
 diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.13.bb 
 b/meta/recipes-multimedia/libpng/libpng_1.6.13.bb
 index 0c6fd1f..3d32bfe 100644
 --- a/meta/recipes-multimedia/libpng/libpng_1.6.13.bb
 +++ b/meta/recipes-multimedia/libpng/libpng_1.6.13.bb
 @@ -20,6 +20,7 @@ inherit autotools binconfig-disabled pkgconfig
 
 # Work around missing symbols
 EXTRA_OECONF_append_arm =  ${@bb.utils.contains(TUNE_FEATURES, neon, 
 --enable-arm-neon=on, --enable-arm-neon=off ,d)}
 +EXTRA_OECONF_append_aarch64 =  ${@bb.utils.contains(TUNE_FEATURES, 
 neon, --enable-arm-neon=on, --enable-arm-neon=off ,d)}

You're introducing the same bug in a different way: overeager use of 
qualifiers. Just drop the _arm bit and it works.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libpng 1.6.13: fix build for aarch64

[Koen Kooi]

 Op 22 sep. 2014, om 14:12 heeft Koen Kooi koen.k...@linaro.org het volgende 
 geschreven:
 
 The configure override was too restrictive, it needed both 'arm' and 'neon' 
 to trigger, which breaks on aarch64. Since TUNE_FEATURES is the only 
 qualifier that matters, drop the 'arm' override.
 
 Buildtested for 'genericarmv8' and 'qemux86' machines.

Ping, libpng is still broken and I'm still not clear why this bugfix hasn't 
been applied for the past 3 months. I'd like to get this in so it can be 
backported to dizzy ASAP.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHi v3] procps: Upgrade to 3.3.10

[Koen Kooi]

 Op 8 dec. 2014, om 19:06 heeft Saul Wold s...@linux.intel.com het volgende 
 geschreven:
 
 On 12/08/2014 05:46 AM, Burton, Ross wrote:
 On 6 December 2014 at 14:37, Koen Kooi k...@dominion.thruhere.net wrote:
 
 If you feel bored, there's a stray backslash in DESCRIPTION and the '+='
 for EXTRA_OECONF can be a regular '='. Next time I'll try to catch
 everything in one go :)
 
 
 I thought a v4 was getting silly so fixed these as I merged it... but:
 
 ERROR: Function failed: Fetcher failure for URL:
 'file://fix-configure.patch'. Unable to fetch URL from any source.
 
 Sorry Saul!
 
 Wow!  I just can't seem to get this one right, thought I all the bits, but I 
 guess I did not commit that patch.
 
 Anything else?  Koen?

Not that I can see right now :)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] dtc: don't use autotools as this doesn't use autotools

[Koen Kooi]

 Op 5 dec. 2014, om 21:46 heeft Ross Burton ross.bur...@intel.com het 
 volgende geschreven:
 
 Signed-off-by: Ross Burton ross.bur...@intel.com
 ---
 meta/recipes-kernel/dtc/dtc.inc |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)
 
 diff --git a/meta/recipes-kernel/dtc/dtc.inc b/meta/recipes-kernel/dtc/dtc.inc
 index 95023b6..0c409b0 100644
 --- a/meta/recipes-kernel/dtc/dtc.inc
 +++ b/meta/recipes-kernel/dtc/dtc.inc

[..]

 +do_install () {
 + oe_runmake install
 +}

I'm wondering if it makes sense to have base.bbclass do this the default 
do_install. Having a virtually empty recipe with only a do_install always makes 
me a bit uneasy.

regards,

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

Re: [OE-core] [PATCHi v3] procps: Upgrade to 3.3.10

[Koen Kooi]

 Op 6 dec. 2014, om 08:38 heeft Saul Wold s...@linux.intel.com het volgende 
 geschreven:
 
 This is now the procps-ng version
 
 cleaned up patches
 added to fix up usrbin_execprefix in OE-Core
 
 Add CPPFLAGS to allow seperate build directory works
 
 [YOCTO #6952]
 
 Signed-off-by: Saul Wold s...@linux.intel.com
 ---
 
 Thanks for Koen for keeping me honest ;-)

If you feel bored, there's a stray backslash in DESCRIPTION and the '+=' for 
EXTRA_OECONF can be a regular '='. Next time I'll try to catch everything in 
one go :)


 
 Sau!
 
 .../procps-3.2.8/0001-Fix-musl-build-failure.patch |  29 --
 .../procps-3.2.8/60_linux_version_init.patch   |  54 --
 .../procps/procps-3.2.8/detect_bitness.patch   |  26 -
 .../procps/procps-3.2.8/gnu-kbsd-version.patch |  44 
 .../procps/procps-3.2.8/install.patch  |  39 
 .../procps/procps-3.2.8/linux-limits.patch |  15 ---
 .../procps/procps-3.2.8/procmodule.patch   |  38 ---
 .../procps-3.2.8/procps-3.2.7-top-remcpu.patch | 111 -
 .../procps-3.2.8/procps-3.2.8+gmake-3.82.patch |  19 
 .../procps-3.2.8/procps-3.2.8-ps-cgroup.patch  |  82 ---
 .../procps/procps-3.2.8/psmodule.patch |  23 -
 meta/recipes-extended/procps/procps.inc|  31 --
 .../procps/{procps-3.2.8 = procps}/sysctl.conf|   0
 meta/recipes-extended/procps/procps_3.2.8.bb   |  37 ---
 meta/recipes-extended/procps/procps_3.3.10.bb  |  62 
 15 files changed, 62 insertions(+), 548 deletions(-)
 delete mode 100644 
 meta/recipes-extended/procps/procps-3.2.8/0001-Fix-musl-build-failure.patch
 delete mode 100644 
 meta/recipes-extended/procps/procps-3.2.8/60_linux_version_init.patch
 delete mode 100644 
 meta/recipes-extended/procps/procps-3.2.8/detect_bitness.patch
 delete mode 100644 
 meta/recipes-extended/procps/procps-3.2.8/gnu-kbsd-version.patch
 delete mode 100644 meta/recipes-extended/procps/procps-3.2.8/install.patch
 delete mode 100644 
 meta/recipes-extended/procps/procps-3.2.8/linux-limits.patch
 delete mode 100644 meta/recipes-extended/procps/procps-3.2.8/procmodule.patch
 delete mode 100644 
 meta/recipes-extended/procps/procps-3.2.8/procps-3.2.7-top-remcpu.patch
 delete mode 100644 
 meta/recipes-extended/procps/procps-3.2.8/procps-3.2.8+gmake-3.82.patch
 delete mode 100644 
 meta/recipes-extended/procps/procps-3.2.8/procps-3.2.8-ps-cgroup.patch
 delete mode 100644 meta/recipes-extended/procps/procps-3.2.8/psmodule.patch
 delete mode 100644 meta/recipes-extended/procps/procps.inc
 rename meta/recipes-extended/procps/{procps-3.2.8 = procps}/sysctl.conf 
 (100%)
 delete mode 100644 meta/recipes-extended/procps/procps_3.2.8.bb
 create mode 100644 meta/recipes-extended/procps/procps_3.3.10.bb
 
 diff --git 
 a/meta/recipes-extended/procps/procps-3.2.8/0001-Fix-musl-build-failure.patch 
 b/meta/recipes-extended/procps/procps-3.2.8/0001-Fix-musl-build-failure.patch
 deleted file mode 100644
 index 71dc3f0..000
 --- 
 a/meta/recipes-extended/procps/procps-3.2.8/0001-Fix-musl-build-failure.patch
 +++ /dev/null
 @@ -1,29 +0,0 @@
 -From 6f2fd55ef7621fd7ab7897aee2c2651b6faf9e6a Mon Sep 17 00:00:00 2001
 -From: Paul Barker p...@paulbarker.me.uk
 -Date: Wed, 20 Aug 2014 11:56:11 +0200
 -Subject: [PATCH] Fix musl build failure
 -
 -Include limits.h for PATH_MAX.
 -
 -Signed-off-by: Paul Barker p...@paulbarker.me.uk
 -
 -Upstream-status: Pending
 
 - proc/readproc.c | 1 +
 - 1 file changed, 1 insertion(+)
 -
 -diff --git a/proc/readproc.c b/proc/readproc.c
 -index 4fad11d..c5b1869 100644
  a/proc/readproc.c
 -+++ b/proc/readproc.c
 -@@ -26,6 +26,7 @@
 - #include sys/dir.h
 - #include sys/types.h
 - #include sys/stat.h
 -+#include limits.h
 - 
 - // sometimes it's easier to do this manually, w/o gcc helping
 - #ifdef PROF
 --- 
 -1.9.1
 -
 diff --git 
 a/meta/recipes-extended/procps/procps-3.2.8/60_linux_version_init.patch 
 b/meta/recipes-extended/procps/procps-3.2.8/60_linux_version_init.patch
 deleted file mode 100644
 index 203ccb3..000
 --- a/meta/recipes-extended/procps/procps-3.2.8/60_linux_version_init.patch
 +++ /dev/null
 @@ -1,54 +0,0 @@
 -## 60_linux_init.dpatch by  david.su...@canonical.com
 -##
 -## All lines beginning with `## DP:' are a description of the patch.
 -## DP: Fix Linux version detection which relied on elf loader side-effect.
 -## DP: This patch also depends on 40_gnu-kbsd-version, which modified
 -## DP: init_Linux_version().
 -
 -@DPATCH@
 -
 -Upstream-Status: inappropriate [upstream unmaintained]
 
 - proc/sysinfo.c |1 +
 - proc/version.c |5 +++--
 - proc/version.h |1 +
 - 3 files changed, 5 insertions(+), 2 deletions(-)
 -
 -Index: procps-3.2.8/proc/sysinfo.c
 -===
  procps-3.2.8.orig/proc/sysinfo.c
 -+++ procps-3.2.8/proc/sysinfo.c
 -@@ -212,6 +212,7 @@ static int check_for_privs(void){
 - static 

Re: [OE-core] [PATCH v2] procps: Upgrade to 3.3.10

[Koen Kooi]

 Op 4 dec. 2014, om 20:55 heeft Saul Wold s...@linux.intel.com het volgende 
 geschreven:
 
 This is now the procps-ng version
 
 cleaned up patches
 added to fix up usrbin_execprefix in OE-Core
 
 Added --enable-skill to ensure snice and skill where built to match
 the buildhistory from the older version
 
 Add CPPFLAGS to allow seperate build directory works
 
 [YOCTO #6952]
 
 Signed-off-by: Saul Wold s...@linux.intel.com
 ---
 
 Double checked with buildhistory this time!

Awesome, two small nitpicks left:

 +#inherit autotools-brokensep gettext pkgconfig update-alternatives
 +inherit autotools gettext pkgconfig update-alternatives

[..]

 +inherit update-alternatives

Drop the commented line and the duplicate inherit below do_install
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tcmode-default.inc: use GCCVERSION for gcc-source

[Koen Kooi]

This was missing leading to gcc-source-foo being built when using 
gcc-cross-bar with GCCVERSION=bar.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 meta/conf/distro/include/tcmode-default.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index 26785e3..99d6df9 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -36,6 +36,7 @@ PREFERRED_VERSION_gcc-crosssdk-${SDK_ARCH} ?= 
${SDKGCCVERSION}
 PREFERRED_VERSION_gcc-crosssdk-initial-${SDK_ARCH} ?= ${SDKGCCVERSION}
 PREFERRED_VERSION_gcc-cross-canadian-${TRANSLATED_TARGET_ARCH} ?= 
${GCCVERSION}
 PREFERRED_VERSION_gcc-runtime ?= ${GCCVERSION}
+PREFERRED_VERSION_gcc-source ?= ${GCCVERSION}
 PREFERRED_VERSION_nativesdk-gcc-runtime ?= ${SDKGCCVERSION}
 PREFERRED_VERSION_libgcc ?= ${GCCVERSION}
 PREFERRED_VERSION_libgcc-initial ?= ${GCCVERSION}
-- 
1.9.3

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

Re: [OE-core] [PATCH] procps: Upgrade to 3.3.10

[Koen Kooi]

 Op 4 dec. 2014, om 03:43 heeft Saul Wold s...@linux.intel.com het volgende 
 geschreven:
 
 This is now the procps-ng version
 
 cleaned up patches
 added to fix up usrbin_execprefix in OE-Core
 
 Add CPPFLAGS to allow seperate build directory works
 
 [YOCTO #6952]
 
 Signed-off-by: Saul Wold s...@linux.intel.com
 ---
 Git was not able to detect a rename unfortunatly in this case.
 
 .../procps/{procps-3.2.8 = procps}/sysctl.conf|   0

So a rename instead of a deletion, good, but...

 
 +++ b/meta/recipes-extended/procps/procps_3.3.10.bb

[..]

 +
 +SRC_URI = 
 http://downloads.sourceforge.net/project/procps-ng/Production/procps-ng-${PV}.tar.xz
  \
 +   file://fix-configure.patch \
 +  

... sysctl.conf not in SRC_URI, nor is it being installed in 
do_install(_append).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][RFC] procps: Upgrade to 3.3.10 (procps-ng version)

[Koen Kooi]

 Op 3 dec. 2014, om 02:18 heeft Saul Wold s...@linux.intel.com het volgende 
 geschreven:
 
 This is an update to procps-ng version, cleaned up patches
 added to fix up usrbin_execprefix in OE-Core.

Why are you dropping sysctl.conf? And can you please send v2 as a -M formatted 
patch?

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

Re: [OE-core] [PATCH] lzo: add debian patch for alignment issue

[Koen Kooi]

 Op 3 dec. 2014, om 02:24 heeft Saul Wold s...@linux.intel.com het volgende 
 geschreven:
 
 [YOCTO #6994]
 
 Signed-off-by: Saul Wold s...@linux.intel.com
 ---
 ...0001-Use-memcpy-instead-of-reinventing-it.patch | 69 ++
 meta/recipes-support/lzo/lzo_2.08.bb   |  1 +
 2 files changed, 70 insertions(+)
 create mode 100644 
 meta/recipes-support/lzo/lzo/0001-Use-memcpy-instead-of-reinventing-it.patch
 
 diff --git 
 a/meta/recipes-support/lzo/lzo/0001-Use-memcpy-instead-of-reinventing-it.patch
  
 b/meta/recipes-support/lzo/lzo/0001-Use-memcpy-instead-of-reinventing-it.patch
 new file mode 100644
 index 000..f978f1b
 --- /dev/null
 +++ 
 b/meta/recipes-support/lzo/lzo/0001-Use-memcpy-instead-of-reinventing-it.patch
 @@ -0,0 +1,69 @@
 +From: Simon McVittie s...@debian.org
 +Date: Sun, 23 Nov 2014 22:50:33 +
 +Subject: Use memcpy() instead of reinventing it
 +
 +gcc inlines memcpy() with results as fast as handwritten code (at
 +least in my brief testing with lzop), and knows the alignment
 +constraints for our architectures.
 +
 +Change suggested by Julian Taylor.
 +
 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757037
 +---
 + minilzo/minilzo.c | 14 ++
 + src/lzo_func.h| 14 ++
 + 2 files changed, 28 insertions(+)
 +
 +Upstream-Status: Pending
 +Signed-off-by: Saul Wold s...@linux.intel.com

Please move those above the '---' so they get preserved when rediffing the 
patches


 +
 +diff --git a/minilzo/minilzo.c b/minilzo/minilzo.c
 +index ab2be5f..6913c2f 100644
 +--- a/minilzo/minilzo.c
  b/minilzo/minilzo.c
 +@@ -3523,6 +3523,20 @@ 
 LZO_COMPILE_TIME_ASSERT_HEADER(sizeof(*(lzo_memops_TU8p)0)==8)
 + if ((void)0, n__n  0) do { *d__n++ = *s__n++; } while (--n__n  0); \
 + LZO_BLOCK_END
 + 
 ++/* Debian-specific change: we know that our compiler inlines memcpy() with
 ++ * constant n to be as fast as handwritten code, and knows which 
 architectures
 ++ * need things correctly aligned. */
 ++#undef LZO_MEMOPS_COPY1
 ++#undef LZO_MEMOPS_COPY2
 ++#undef LZO_MEMOPS_COPY4
 ++#undef LZO_MEMOPS_COPY8
 ++#undef LZO_MEMOPS_COPYN
 ++#define LZO_MEMOPS_COPY1(dd,ss) memcpy(dd, ss, 1)
 ++#define LZO_MEMOPS_COPY2(dd,ss) memcpy(dd, ss, 2)
 ++#define LZO_MEMOPS_COPY4(dd,ss) memcpy(dd, ss, 4)
 ++#define LZO_MEMOPS_COPY8(dd,ss) memcpy(dd, ss, 8)
 ++#define LZO_MEMOPS_COPYN(dd,ss,nn) memcpy(dd, ss, nn)
 ++
 + __lzo_static_forceinline lzo_uint16_t lzo_memops_get_le16(const lzo_voidp 
 ss)
 + {
 + lzo_uint16_t v;
 +diff --git a/src/lzo_func.h b/src/lzo_func.h
 +index dfaa676..1cc1b53 100644
 +--- a/src/lzo_func.h
  b/src/lzo_func.h
 +@@ -333,6 +333,20 @@ 
 LZO_COMPILE_TIME_ASSERT_HEADER(sizeof(*(lzo_memops_TU8p)0)==8)
 + if ((void)0, n__n  0) do { *d__n++ = *s__n++; } while (--n__n  0); \
 + LZO_BLOCK_END
 + 
 ++/* Debian-specific change: we know that our compiler inlines memcpy() with
 ++ * constant n to be as fast as handwritten code, and knows which 
 architectures
 ++ * need things correctly aligned. */
 ++#undef LZO_MEMOPS_COPY1
 ++#undef LZO_MEMOPS_COPY2
 ++#undef LZO_MEMOPS_COPY4
 ++#undef LZO_MEMOPS_COPY8
 ++#undef LZO_MEMOPS_COPYN
 ++#define LZO_MEMOPS_COPY1(dd,ss) memcpy(dd, ss, 1)
 ++#define LZO_MEMOPS_COPY2(dd,ss) memcpy(dd, ss, 2)
 ++#define LZO_MEMOPS_COPY4(dd,ss) memcpy(dd, ss, 4)
 ++#define LZO_MEMOPS_COPY8(dd,ss) memcpy(dd, ss, 8)
 ++#define LZO_MEMOPS_COPYN(dd,ss,nn) memcpy(dd, ss, nn)
 ++
 + __lzo_static_forceinline lzo_uint16_t lzo_memops_get_le16(const lzo_voidp 
 ss)
 + {
 + lzo_uint16_t v;
 diff --git a/meta/recipes-support/lzo/lzo_2.08.bb 
 b/meta/recipes-support/lzo/lzo_2.08.bb
 index 7d7d1f3..af06e29 100644
 --- a/meta/recipes-support/lzo/lzo_2.08.bb
 +++ b/meta/recipes-support/lzo/lzo_2.08.bb
 @@ -6,6 +6,7 @@ LIC_FILES_CHKSUM = 
 file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
 
 file://src/lzo_init.c;beginline=5;endline=25;md5=a6e25df9a83b24629e847846ccdd8054
 
 SRC_URI = http://www.oberhumer.com/opensource/lzo/download/lzo-${PV}.tar.gz \
 +   file://0001-Use-memcpy-instead-of-reinventing-it.patch \
file://acinclude.m4 \

 
 -- 
 1.8.3.1
 
 -- 
 ___
 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 0/4][RFC] Change libexecdir to ${prefix}/libexec

[Koen Kooi]

 Op 2 dec. 2014, om 16:53 heeft Ross Burton ross.bur...@intel.com het 
 volgende geschreven:
 
 Hi,
 
 First, this is VERY MUCH A RFC!
 
 There's numerous problems with setting ${libexecdir} to ${libdir}/${BPN}, but
 the a easy argument in my opinion is that nobody else does this.
 
 The Debian world sets libexecdir to ${exec_prefix}/lib, and the Red Hat world
 uses ${exec_prefix}/libexec.  The FHS says either are fine.  Nobody puts the
 package name into the definition of libexecdir, as automake provides
 pkglibexecdir ($libexec/$package) for package-specific binaries.
 
 This branch changes bitbake.conf to use ${exec_prefix}/libexec and a few 
 patches
 to fix (or hack around) any problems this has revealed so far.
 
 Comments and testing (especially with other layers, and multilib 
 configurations)
 much appreciated.

In the past I've patched things like gdm to look in ${libdir}/${BPN} for helper 
binaries (which are from a different recipe), so not only recipes need to be 
inspected, but patches as well.

regards,

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

Re: [OE-core] [PATCH 00/24] V2: Add machine qemuarm64

[Koen Kooi]

CC:ing Steve M. from ARM who went through various arm naming issues for debian.

 Op 7 nov. 2014, om 15:27 heeft Mark Hatle mark.ha...@windriver.com het 
 volgende geschreven:
 
 On 11/7/14, 3:18 AM, Koen Kooi wrote:
 
 Op 7 nov. 2014, om 09:51 heeft Kai Kang kai.k...@windriver.com het 
 volgende geschreven:
 
 V2:
 * rebase on master and drop qemu upgrade commit
 * built for lib32-core-image-sato core-image-sato-sdk meta-toolchain and 
 world
 
 V1:
 The original configuration files and tune fils for arm arch64 are from 
 linaro.
 And we rename it to qemuarm64 for consistency.
 
 Consistent to what? All current qemu machines are named after the qemu arch, 
 so consistent would be 'qemuaarch64'. The 'arm64' moniker is *only* used in 
 the kernel and that was caused by Linus being grumpy, everything else is 
 'aarch64' or 'armv8'
 
 
 The arm64 name -did- come from Linaro:
 
 http://git.linaro.org/openembedded/meta-linaro.git/tree/HEAD:/meta-aarch64/conf/machine/include
 
 The arch-armv8.inc file (that arch-arm64.inc was based on) is located in the 
 directly arm64.
 
 In addition, the tune file that forms the basis of the ARM tunes is called 
 'arch-arm.inc'.  Not arch-aarch32.inc.  If you want to rename that, we can 
 discuss it.. but to match that naming I chose 'arch-arm64.inc'.

'aarch32' is not the same as 'arm', the arch-arm.inc covers armv4..armv7a with 
it various includes. aarch32 is s subset of armv7a, so please don't use that to 
denote 32bit arms.

 (arch-armv8.inc was kept, but only includes the arch-arm64.inc file since 
 there are no custom optimizations for 'v8' that I can find.)
 
 As far as the machine name goes the original Linaro version, 
 genericarmv8.conf and genericarmv8b.conf, don't match any of the naming 
 conventions that are currently used by QEMU BSPs.
 
 Looking at the existing machine names:
 
 qemuarm.conf  qemumips64.conf  qemumips.conf  qemuppc.conf  qemux86-64.conf 
 qemux86.conf
 
 Each of the suffix names used match the Linux kernel arch naming.

It seems to be following the qemu architecture name, which tends to match the 
kernel arch name, but not always.

Apart from the naming issues, aarch64 support is incomplete in meta-aarch64 
since things like ILP32 are missing as well as agreement over page size options.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] avahi.inc: rename package to use avahi to instead of avahi-daemon

[Koen Kooi]

 Op 11 nov. 2014, om 11:52 heeft Hongxu Jia hongxu@windriver.com het 
 volgende geschreven:
 
 The package avahi does not exist, as SUMMARY said, we should
 use avahi-daemon to instead. It avoids the do_rootfs failure
 while IMAGE_INSTALL += avahi
 
 For compatibility, let avahi to provide avahi-daemon.

As stated before:

1) Fix your IMAGE_INSTALL
2) This breaks upgrade paths

Do you *really* want to break existing installs just so you can pretend that 
your recipename==package name assumption isn't wrong?


 
 [YOCTO #6937]
 
 Signed-off-by: Hongxu Jia hongxu@windriver.com
 ---
 meta/recipes-connectivity/avahi/avahi.inc | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)
 
 diff --git a/meta/recipes-connectivity/avahi/avahi.inc 
 b/meta/recipes-connectivity/avahi/avahi.inc
 index b060437..581d51b 100644
 --- a/meta/recipes-connectivity/avahi/avahi.inc
 +++ b/meta/recipes-connectivity/avahi/avahi.inc
 @@ -29,8 +29,8 @@ SRC_URI = http://avahi.org/download/avahi-${PV}.tar.gz \
   file://reuseport-check.patch \
   
 
 -USERADD_PACKAGES = avahi-daemon avahi-autoipd
 -USERADD_PARAM_avahi-daemon = --system --home /var/run/avahi-daemon \
 +USERADD_PACKAGES = avahi avahi-autoipd
 +USERADD_PARAM_avahi = --system --home /var/run/avahi-daemon \
   --no-create-home --shell /bin/false \
   --user-group avahi
 
 @@ -71,11 +71,10 @@ do_configure_prepend() {
 }
 
 
 -PACKAGES =+ avahi-daemon libavahi-common libavahi-core libavahi-client 
 avahi-dnsconfd libavahi-glib libavahi-ui avahi-autoipd avahi-utils
 +PACKAGES =+ libavahi-common libavahi-core libavahi-client avahi-dnsconfd 
 libavahi-glib libavahi-ui avahi-autoipd avahi-utils
 
 -# As avahi doesn't put any files into PN, clear the files list to avoid 
 problems
 -# if extra libraries appear.
 -FILES_avahi = 
 +# For compatibility, let avahi to provide avahi-daemon
 +RPROVIDES_${PN} = ${PN}-daemon
 FILES_avahi-autoipd = ${sbindir}/avahi-autoipd \
${sysconfdir}/avahi/avahi-autoipd.action \
${sysconfdir}/dhcp/*/avahi-autoipd \
 @@ -83,7 +82,7 @@ FILES_avahi-autoipd = ${sbindir}/avahi-autoipd \
${sysconfdir}/udhcpc.d/99avahi-autoipd
 FILES_libavahi-common = ${libdir}/libavahi-common.so.*
 FILES_libavahi-core = ${libdir}/libavahi-core.so.*
 -FILES_avahi-daemon = ${sbindir}/avahi-daemon \
 +FILES_${PN} = ${sbindir}/avahi-daemon \
   ${sysconfdir}/avahi/avahi-daemon.conf \
   ${sysconfdir}/avahi/hosts \
   ${sysconfdir}/avahi/services \
 @@ -102,10 +101,10 @@ FILES_libavahi-glib = ${libdir}/libavahi-glib.so.*
 FILES_libavahi-gobject = ${libdir}/libavahi-gobject.so.*
 FILES_avahi-utils = ${bindir}/avahi-*
 
 -RDEPENDS_${PN}-dev = avahi-daemon (= ${EXTENDPKGV}) libavahi-core (= 
 ${EXTENDPKGV}) libavahi-client (= ${EXTENDPKGV})
 +RDEPENDS_${PN}-dev = avahi (= ${EXTENDPKGV}) libavahi-core (= 
 ${EXTENDPKGV}) libavahi-client (= ${EXTENDPKGV})
 
 # uclibc has no nss
 -RRECOMMENDS_avahi-daemon_append_libc-glibc =  libnss-mdns
 +RRECOMMENDS_avahi_append_libc-glibc =  libnss-mdns
 RRECOMMENDS_${PN}_append_libc-glibc =  libnss-mdns
 
 RRECOMMENDS_avahi-dev = expat-dev libcap-dev libdaemon-dev dbus-dev 
 glib-2.0-dev update-rc.d-dev
 @@ -113,11 +112,11 @@ RRECOMMENDS_avahi-dev_append_libc-glibc =  gettext-dev
 
 RRECOMMENDS_avahi-dev[nodeprrecs] = 1
 
 -CONFFILES_avahi-daemon = ${sysconfdir}/avahi/avahi-daemon.conf
 +CONFFILES_avahi = ${sysconfdir}/avahi/avahi-daemon.conf
 
 -INITSCRIPT_PACKAGES = avahi-daemon avahi-dnsconfd
 -INITSCRIPT_NAME_avahi-daemon = avahi-daemon
 -INITSCRIPT_PARAMS_avahi-daemon = defaults 21 19
 +INITSCRIPT_PACKAGES = avahi avahi-dnsconfd
 +INITSCRIPT_NAME_avahi = avahi-daemon
 +INITSCRIPT_PARAMS_avahi = defaults 21 19
 INITSCRIPT_NAME_avahi-dnsconfd = avahi-dnsconfd
 INITSCRIPT_PARAMS_avahi-dnsconfd = defaults 22 19
 
 @@ -141,13 +140,13 @@ do_install() {
 # At the time the postinst runs, dbus might not be setup so only restart if 
 running 
 # Don't exit early, because update-rc.d needs to run subsequently.
 
 -pkg_postinst_avahi-daemon () {
 +pkg_postinst_avahi () {
 if [ -z $D ]; then
   killall -q -HUP dbus-daemon || true
 fi
 }
 
 -pkg_postrm_avahi-daemon () {
 +pkg_postrm_avahi () {
   deluser avahi || true
   delgroup avahi || true
 }
 -- 
 1.9.1
 
 -- 
 ___
 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/1] systemd: add bash to RDEPENDS

[Koen Kooi]

 Op 11 nov. 2014, om 03:17 heeft Chong Lu chong...@windriver.com het 
 volgende geschreven:
 
 ping

Anders has 2 questions, you only answered one, maybe you can try answering the 
second one before pinging?

 
 //Chong
 
 On 10/27/2014 03:16 PM, Chong Lu wrote:
 This solves the following warning:
 
 systemd-216+gitAUTOINC+5d0ae62c66: systemd-kernel-install requires /bin/bash,
 but no providers in its RDEPENDS [file-rdeps]
 
 Signed-off-by: Chong Lu chong...@windriver.com
 ---
  meta/recipes-core/systemd/systemd_216.bb | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/meta/recipes-core/systemd/systemd_216.bb 
 b/meta/recipes-core/systemd/systemd_216.bb
 index 6d3e47f..8bc1cc8 100644
 --- a/meta/recipes-core/systemd/systemd_216.bb
 +++ b/meta/recipes-core/systemd/systemd_216.bb
 @@ -202,6 +202,7 @@ FILES_${PN}-vconsole-setup = 
 ${rootlibexecdir}/systemd/systemd-vconsole-setup \

 ${systemd_unitdir}/system/systemd-vconsole-setup.service \

 ${systemd_unitdir}/system/sysinit.target.wants/systemd-vconsole-setup.service
  +RDEPENDS_${PN}-kernel-install += bash
  FILES_${PN}-kernel-install = ${bindir}/kernel-install \
${sysconfdir}/kernel/ \
${exec_prefix}/lib/kernel \
 
 -- 
 ___
 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] [RFC] Replace procps with procps-ng

[Koen Kooi]

 Op 10 nov. 2014, om 11:38 heeft Paul Barker p...@paulbarker.me.uk het 
 volgende geschreven:
 
 Hi all,
 
 I've tried upstreaming a patch against procps by sending it to the
 listed maintainer and the mailing list and I've had no reply from
 either. The last change to the CVS repository seems to be 3 years old
 and the mailing list archive is mostly just full of spam.
 
 It looks like Arch Linux, Debian, Fedora and openSUSE have moved on to
 procps-ng. I suggest we do the same during the v1.8 development cycle
 if possible. procps-ng is actively developed and looks to be open to
 patches.
 
 I'm sadly pretty limited on development time at the minute but I may
 be able to give this a go in December. I'd rather focus the time I do
 have on opkg though so if anyone else wants to pick this up that'd be
 great.

With the util-linux - util-linux-ng - util-linux change in mind I strongly 
encourage to keep using 'procps' are package name or ensure that the 
appropriate (R)PROVIDES are in place.

regards,

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

Re: [OE-core] [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Koen Kooi]

 Op 10 nov. 2014, om 08:35 heeft Hongxu Jia hongxu@windriver.com het 
 volgende geschreven:
 
 On 11/10/2014 02:42 PM, Martin Jansa wrote:
 The docs say that IMAGE_INSTALL is for package_name. So I think it's
 correct that it fails when you put recipe_name in it and sometimes
 there isn't any package with the same name. It's the same as trying to
 make RDEPENDS/DEPENDS entries to be interchangeable (putting
 recipe_names to RDEPENDS and package_names to DEPENDS).
 
 Especially with that patch for xinput-pointercal, if user explicitly
 asks for installing xinput-pointercal, what's the reason to create him
 completely empty package? IMHO it's only hiding that issue from him and
 instead of discovering the issue in do_rootfs task, he has to check
 generated rootfs or even boot the device.
 
 For most recipes, they generate packages with recipe name, it is not
 convenience to figure out the different between package_name and
 recipe_name, especially for newbies, which I means we should reduce
 that convenience, build relationship between recipe and package,
 especially when the recipe doesn't generate the same name package.

It is not a bug when recipe foo.bb doesn't generate foo.ipk. Your changes 
introduce needless churn and break upgrade paths only to cater to people making 
wrong assumptions.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] procps: install symlink under /etc/sysctl.d in case of systemd

[Koen Kooi]

 Op 9 nov. 2014, om 08:03 heeft Chen Qi qi.c...@windriver.com het volgende 
 geschreven:
 
 Install /etc/sysctl.d/99-sysctl.conf symlink in case of systemd so
 that /etc/sysctl.conf is taken into consideration by systemd-sysctl.
 
 Signed-off-by: Chen Qi qi.c...@windriver.com

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

[OE-core] [PATCH][daisy][backport] kernel: Prevent from installing so files into source dir

[Koen Kooi]

From: Yang Shi yang@windriver.com

vdso build could generate so files, avoid installing such so files into kernel
source dir, otherwise the below package QA error might be hit:

ERROR: QA Issue: File '/usr/src/kernel/arch/x86/vdso/vdso64.so' from
linux-yocto was already stripped, this will prevent future
debugging! [already-stripped]

Signed-off-by: Yang Shi yang@windriver.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---

This is needed to build 3.6.16+ on the daisy branch

 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 58b0ec8..acb2bbd 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -232,7 +232,7 @@ kernel_do_install() {
# dir. This ensures the original Makefiles are used and not the
# redirecting Makefiles in the build directory.
#
-   find . -depth -not -name *.cmd -not -name *.o -not -name *.so.dbg 
-not -path ./Documentation* -not -path ./source* -not -path ./.* -print0 
| cpio --null -pdlu $kerneldir
+   find . -depth -not -name *.cmd -not -name *.o -not -name *.so.dbg 
-not -name *.so -not -path ./Documentation* -not -path ./source* -not 
-path ./.* -print0 | cpio --null -pdlu $kerneldir
cp .config $kerneldir
if [ ${S} != ${B} ]; then
pwd=$PWD
-- 
1.9.0

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

[OE-core] [PATCHv2] gptfdisk: add 0.8.10+git version

[Koen Kooi]

Besides from being useful as fdisk replacement this gives us 'sgdisk'
which can be used to set the GUID for partitions, e.g.

sgdisk -t 1:C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/mmcblk0p1

To mark it as ESP in scripts like mkefidisk.sh.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---

Changes:
v2: bindir - sbindir 

 meta/recipes-devtools/fdisk/gptfdisk_git.bb | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/recipes-devtools/fdisk/gptfdisk_git.bb

diff --git a/meta/recipes-devtools/fdisk/gptfdisk_git.bb 
b/meta/recipes-devtools/fdisk/gptfdisk_git.bb
new file mode 100644
index 000..477c1d9
--- /dev/null
+++ b/meta/recipes-devtools/fdisk/gptfdisk_git.bb
@@ -0,0 +1,22 @@
+DESCRIPTION = GPT fdisk is a disk partitioning tool loosely modeled on Linux 
fdisk, but used for modifying GUID Partition Table (GPT) disks. The related 
FixParts utility fixes some common problems on Master Boot Record (MBR) disks.
+
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552
+
+DEPENDS = util-linux popt ncurses
+
+PV = 0.8.10+git${SRCPV}
+SRCREV = a920398fa393f9d6301b32b191bc01e086ab8bc8
+SRC_URI = git://git.code.sf.net/p/gptfdisk/code
+
+S = ${WORKDIR}/git
+
+do_install() {
+install -d ${D}${sbindir}
+install -m 0755 cgdisk ${D}${sbindir}
+install -m 0755 gdisk ${D}${sbindir}
+install -m 0755 sgdisk ${D}${sbindir}
+install -m 0755 fixparts ${D}${sbindir}
+}
+
+BBCLASSEXTEND = native nativesdk
-- 
1.9.0

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

Re: [OE-core] [RFC][PATCH] u-boot-mkimage: allow building target version of the tool

[Koen Kooi]

 Op 9 nov. 2014, om 08:51 heeft Denys Dmytriyenko de...@denix.org het 
 volgende geschreven:
 
 On Sat, Nov 08, 2014 at 05:12:36PM -0200, Otavio Salvador wrote:
 On Fri, Nov 7, 2014 at 8:24 PM, Denys Dmytriyenko de...@denix.org wrote:
 From: Denys Dmytriyenko de...@ti.com
 
 u-boot doesn't really support building its tools for the target, as they are
 built with HOSTCC compiler, which is also used to compile fixdep utility
 that gets executed during the build. Since it might be beneficial to have a
 target version of mkimage, let's hack it to build fixdep in a separate step.
 
 Signed-off-by: Denys Dmytriyenko de...@ti.com
 ...
 +   make HOSTCC=${BUILD_CC} HOSTLD=${BUILD_LD} 
 HOSTLDFLAGS=${BUILD_LDFLAGS} HOSTSTRIP=true dot-config=0 scripts_basic
 ...
 
 We do it in meta-fsl-arm as below:
 
 That still doesn't work when building tools for the target:
 /bin/sh: scripts/basic/fixdep: cannot execute binary file: Exec format error
 
 I guess you are missing the point of this patch, as sandbox_defconfig will 
 only eliminate dot-config=0 parameter, but not the need to build fixdep 
 separately with a different host compiler...
 
 On the other hand - is it a real requirement to build mkimage for the target?

I use it a lot when regenerating initramfses on the target.

regards,

Koen

 
 
 ESCRIPTION = U-boot bootloader mxsboot tool
 LICENSE = GPLv2+
 LIC_FILES_CHKSUM = 
 file://Licenses/README;md5=c7383a594871c03da76b3707929d2919
 SECTION = bootloader
 DEPENDS = openssl
 PROVIDES = u-boot-mxsboot
 
 PV = v2014.10+git${SRCPV}
 
 SRCREV = 75ce95e627609c9b9e537e935e69c4ecef26c8f7
 SRCBRANCH = patches-2014.10
 SRC_URI = git://github.com/Freescale/u-boot-imx.git;branch=${SRCBRANCH}
 
 S = ${WORKDIR}/git
 
 inherit fsl-u-boot-localversion
 
 EXTRA_OEMAKE = 'HOSTCC=${CC} ${CPPFLAGS} HOSTLDFLAGS=-L${libdir}
 -L${base_libdir} HOSTSTRIP=true CONFIG_MX28=y'
 
 do_configure () {
oe_runmake sandbox_defconfig
 }
 
 do_compile () {
oe_runmake tools-only
 }
 
 do_install () {
install -d ${D}${bindir}
install -m 0755 tools/mxsboot ${D}${bindir}/uboot-mxsboot
ln -sf uboot-mxsboot ${D}${bindir}/mxsboot
 }
 
 BBCLASSEXTEND = native nativesdk
 
 
 -- 
 Otavio Salvador O.S. Systems
 http://www.ossystems.com.brhttp://code.ossystems.com.br
 Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

Re: [OE-core] [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Koen Kooi]

 Op 7 nov. 2014, om 15:38 heeft Martin Jansa martin.ja...@gmail.com het 
 volgende geschreven:
 
 On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
 The package avahi does not exist, so we use avahi-daemon as the provider.
 It avoids the do_rootfs failure while IMAGE_INSTALL += avahi
 
 Why don't you fix your IMAGE_INSTALL instead?

I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL. 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gptfdisk: add 0.8.10+git version

[Koen Kooi]

 Op 7 nov. 2014, om 19:10 heeft Joshua Hernstrom joshua.hernst...@ni.com het 
 volgende geschreven:
 
 Hi Koen,
 
 Besides from being useful as fdisk replacement this gives us 'sgdisk'
 which can be used to set the GUID for partitions, e.g.
 
  sgdisk -t 1:C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/mmcblk0p1
 
 To mark it as ESP in scripts like mkefidisk.sh.
 
 Signed-off-by: Koen Kooi koen@...
 ---
 meta/recipes-devtools/fdisk/gptfdisk_git.bb | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/recipes-devtools/fdisk/gptfdisk_git.bb
 
 diff --git a/meta/recipes-devtools/fdisk/gptfdisk_git.bb
 b/meta/recipes-devtools/fdisk/gptfdisk_git.bb new file mode 100644
 index 000..62c32c3
 --- /dev/null
 +++ b/meta/recipes-devtools/fdisk/gptfdisk_git.bb
 at  at  -0,0 +1,22  at  at 
 ...
 +S = ${WORKDIR}/git
 +
 +do_install() {
 +install -d ${D}${bindir}
 +install -m 0755 cgdisk ${D}${bindir}
 +install -m 0755 gdisk ${D}${bindir}
 +install -m 0755 sgdisk ${D}${bindir}
 +install -m 0755 fixparts ${D}${bindir}
 
 Have you considered splitting this package into separate sub-packages? The 
 util-linux recipe does something similar for the fdisk family of utilities.

I can if you'd like that, the utils were few and small, so I put them all in 
${PN}, let me know if you still want them seperate.

regards,

Koen

 I had a not-yet-submitted recipe along the same line as yours - the relevant 
 snippets follow for reference:
 
 snip
 PACKAGES =+ ${PN}-gdisk ${PN}-cgdisk ${PN}-sgdisk ${PN}-fixparts
 FILES_${PN}-gdisk = ${sbindir}/gdisk
 FILES_${PN}-cgdisk = ${sbindir}/cgdisk
 FILES_${PN}-sgdisk = ${sbindir}/sgdisk
 FILES_${PN}-fixparts = ${sbindir}/fixparts
 
 do_install() {
   install -m 0755 -d ${D}${sbindir}
   sbinprogs=gdisk cgdisk sgdisk fixparts
   for f in ${sbinprogs}; do
   install -m 0755 ${S}/${f} ${D}${sbindir}
   done
 }
 /snip
 
 Cheers,
 Josh
 --
 Joshua Hernstrom
 National Instruments
 -- 
 ___
 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 00/24] V2: Add machine qemuarm64

[Koen Kooi]

 Op 7 nov. 2014, om 09:51 heeft Kai Kang kai.k...@windriver.com het volgende 
 geschreven:
 
 V2:
 * rebase on master and drop qemu upgrade commit
 * built for lib32-core-image-sato core-image-sato-sdk meta-toolchain and world
 
 V1:
 The original configuration files and tune fils for arm arch64 are from linaro.
 And we rename it to qemuarm64 for consistency.

Consistent to what? All current qemu machines are named after the qemu arch, so 
consistent would be 'qemuaarch64'. The 'arm64' moniker is *only* used in the 
kernel and that was caused by Linus being grumpy, everything else is 'aarch64' 
or 'armv8' 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Moving llvm to oe-core?

[Koen Kooi]

 Op 6 nov. 2014, om 18:42 heeft Burton, Ross ross.bur...@intel.com het 
 volgende geschreven:
 
 Hi,
 
 So I think it's fair to say that neither GCC nor LLVM are going away anytime 
 soon, both having their respective niches.  Because of this I'm wondering if 
 we should be adding LLVM to oe-core (taking the meta-oe recipes).  GCC will 
 still be the cross-compiler used but LLVM will be available out of the box, 
 for example the Gallium LLVM-based Mesa drivers can be enabled without 
 requiring meta-oe.
 
 Anyone have thoughts/comments/objections?

Having llvm enabled by default in mesa would save me a few distro overrides. 
Just try to enable r600 support and you'll see how painful the current 
situation is.

regards,

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

Re: [OE-core] [PATCH 1/1] systemd: make /etc/sysctl.conf have real effect

[Koen Kooi]

 Op 6 nov. 2014, om 08:59 heeft ChenQi qi.c...@windriver.com het volgende 
 geschreven:
 
 On 11/06/2014 03:48 PM, Koen Kooi wrote:
 Op 6 nov. 2014, om 08:32 heeft Chen Qi qi.c...@windriver.com het volgende 
 geschreven:
 
 In systemd, /etc/sysctl.conf is actually ignored by systemd-sysctl,
 because this command only examine *.conf files under a bunch of directories
 like /etc/sysctl.d or /usr/lib/sysctl.d.
 
 The problem is we are used to configuring kernel parameters in 
 /etc/sysctl.conf,
 so it would be really strange if the configuration in that file doesn't 
 have any
 effect.
 
 This patch reference Fedora's solution to this problem, creating a symlink 
 to
 /etc/sysctl.conf under /etc/sysctl.d/.
 Shouldn't this be done in procps instead?
 
 
 Actually, the problem is not about `sysctl' command.
 procps provides `sysctl', but busybox also provides this command.
 It's very possible that on our generated image, procps is not installed but 
 `sysctl' command is available.
 Both busybox's and procps's `sysctl' command takes /etc/sysctl.conf into 
 consideration.

Right, but only procps installs that file.

 Now, systemd provides a similar utility called `systemd-sysctl' which is 
 executed at boot time via systemd-sysctl.service.
 
 So our actually problem is that systemd-sysctl ignores /etc/sysctl.conf, 
 which makes it somewhat strange, especially to users who are used to 
 configuring parameters in sysctl.conf.
 And this patch solves this problem by adding a symlink under /etc/sysctl.d/.
 
 That's why I think we should put this in systemd.

You're adding a symlink to a file which only exists if you install procps, 
which isn't in RDEPENDS.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] gptfdisk: add 0.8.10+git version

[Koen Kooi]

Op 6 nov. 2014, om 12:27 heeft Paul Eggleton paul.eggle...@linux.intel.com 
het volgende geschreven:

 Hi Koen,
 
 On Thursday 06 November 2014 08:37:56 Koen Kooi wrote:
 Besides from being useful as fdisk replacement this gives us 'sgdisk'
 which can be used to set the GUID for partitions, e.g.
 
  sgdisk -t 1:C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/mmcblk0p1
 
 To mark it as ESP in scripts like mkefidisk.sh.
 
 Signed-off-by: Koen Kooi k...@dominion.thruhere.net
 ---
 meta/recipes-devtools/fdisk/gptfdisk_git.bb | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/recipes-devtools/fdisk/gptfdisk_git.bb
 
 diff --git a/meta/recipes-devtools/fdisk/gptfdisk_git.bb
 b/meta/recipes-devtools/fdisk/gptfdisk_git.bb new file mode 100644
 index 000..62c32c3
 --- /dev/null
 +++ b/meta/recipes-devtools/fdisk/gptfdisk_git.bb
 @@ -0,0 +1,22 @@
 ...
 +S = ${WORKDIR}/git
 +
 +do_install() {
 +install -d ${D}${bindir}
 +install -m 0755 cgdisk ${D}${bindir}
 +install -m 0755 gdisk ${D}${bindir}
 +install -m 0755 sgdisk ${D}${bindir}
 +install -m 0755 fixparts ${D}${bindir}
 
 Technically shouldn't these be in ${sbindir} ?

Personally I think sbindir is a misguided idea, PATH is a very easy to get 
around security measure. Having said that, I have no objection to installing 
these things in $sbindir if it's requiered to get this into OE-core.

regards,

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

Re: [OE-core] [PATCH 1/1] systemd: make /etc/sysctl.conf have real effect

[Koen Kooi]

Op 6 nov. 2014, om 12:59 heeft ChenQi qi.c...@windriver.com het volgende 
geschreven:

 
 
 On 11/06/2014 06:33 PM, Koen Kooi wrote:
 Op 6 nov. 2014, om 08:59 heeft ChenQi qi.c...@windriver.com het volgende 
 geschreven:
 
 On 11/06/2014 03:48 PM, Koen Kooi wrote:
 Op 6 nov. 2014, om 08:32 heeft Chen Qi qi.c...@windriver.com het 
 volgende geschreven:
 
 In systemd, /etc/sysctl.conf is actually ignored by systemd-sysctl,
 because this command only examine *.conf files under a bunch of 
 directories
 like /etc/sysctl.d or /usr/lib/sysctl.d.
 
 The problem is we are used to configuring kernel parameters in 
 /etc/sysctl.conf,
 so it would be really strange if the configuration in that file doesn't 
 have any
 effect.
 
 This patch reference Fedora's solution to this problem, creating a 
 symlink to
 /etc/sysctl.conf under /etc/sysctl.d/.
 Shouldn't this be done in procps instead?
 
 Actually, the problem is not about `sysctl' command.
 procps provides `sysctl', but busybox also provides this command.
 It's very possible that on our generated image, procps is not installed but 
 `sysctl' command is available.
 Both busybox's and procps's `sysctl' command takes /etc/sysctl.conf into 
 consideration.
 Right, but only procps installs that file.
 
 As busybox provides `sysctl' utility, is it reasonable that it also provides 
 a corresponding configuration file (/etc/sysctl.conf)? Should we make a patch 
 for busybox?
 
 
 Now, systemd provides a similar utility called `systemd-sysctl' which is 
 executed at boot time via systemd-sysctl.service.
 
 So our actually problem is that systemd-sysctl ignores /etc/sysctl.conf, 
 which makes it somewhat strange, especially to users who are used to 
 configuring parameters in sysctl.conf.
 And this patch solves this problem by adding a symlink under /etc/sysctl.d/.
 
 That's why I think we should put this in systemd.
 You're adding a symlink to a file which only exists if you install procps, 
 which isn't in RDEPENDS.
 
 
 As I said before, procps is *not* necessary for the sysctl mechanism to have 
 effect.
 (Think about systemd-based core-image-minimal image.)
 
 Busybox provides `sysctl', systemd provides `systemd-sysctl'.
 (It's an easy program, there might exist other packages that provide it too.)
 
 /etc/sysctl.conf is a configuration file which is very likely to be modified 
 or created by administrators to configure kernel parameters.
 (You can't expect administrators to all start learning systemd, trying to 
 understand the gap and differences. In addition, they may have scripts that 
 edit /etc/sysctl.conf to automate their work.)
 
 The point of the symlink is to ensure that when users edit /etc/sysctl.conf 
 (or create one), configurations in that file will have effect at boot time.
 
 Just think about this problem from a standpoint of user experience.

You still haven't convinced me that shipping a broken symlink is a good idea. 
I'm pretty sure it's not even allowed in out commit guidelines.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] gptfdisk: add 0.8.10+git version

[Koen Kooi]

Besides from being useful as fdisk replacement this gives us 'sgdisk'
which can be used to set the GUID for partitions, e.g.

sgdisk -t 1:C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/mmcblk0p1

To mark it as ESP in scripts like mkefidisk.sh.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 meta/recipes-devtools/fdisk/gptfdisk_git.bb | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/recipes-devtools/fdisk/gptfdisk_git.bb

diff --git a/meta/recipes-devtools/fdisk/gptfdisk_git.bb 
b/meta/recipes-devtools/fdisk/gptfdisk_git.bb
new file mode 100644
index 000..62c32c3
--- /dev/null
+++ b/meta/recipes-devtools/fdisk/gptfdisk_git.bb
@@ -0,0 +1,22 @@
+DESCRIPTION = GPT fdisk is a disk partitioning tool loosely modeled on Linux 
fdisk, but used for modifying GUID Partition Table (GPT) disks. The related 
FixParts utility fixes some common problems on Master Boot Record (MBR) disks.
+
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552
+
+DEPENDS = util-linux popt ncurses
+
+PV = 0.8.10+git${SRCPV}
+SRCREV = a920398fa393f9d6301b32b191bc01e086ab8bc8
+SRC_URI = git://git.code.sf.net/p/gptfdisk/code
+
+S = ${WORKDIR}/git
+
+do_install() {
+install -d ${D}${bindir}
+install -m 0755 cgdisk ${D}${bindir}
+install -m 0755 gdisk ${D}${bindir}
+install -m 0755 sgdisk ${D}${bindir}
+install -m 0755 fixparts ${D}${bindir}
+}
+
+BBCLASSEXTEND = native nativesdk
-- 
1.9.0

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

Re: [OE-core] [PATCH 1/1] systemd: make /etc/sysctl.conf have real effect

[Koen Kooi]

Op 6 nov. 2014, om 08:32 heeft Chen Qi qi.c...@windriver.com het volgende 
geschreven:

 In systemd, /etc/sysctl.conf is actually ignored by systemd-sysctl,
 because this command only examine *.conf files under a bunch of directories
 like /etc/sysctl.d or /usr/lib/sysctl.d.
 
 The problem is we are used to configuring kernel parameters in 
 /etc/sysctl.conf,
 so it would be really strange if the configuration in that file doesn't have 
 any
 effect.
 
 This patch reference Fedora's solution to this problem, creating a symlink to
 /etc/sysctl.conf under /etc/sysctl.d/.

Shouldn't this be done in procps instead?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core