[OE-core] [PATCH] gnutls: 3.5.9 -> 3.5.11

[Huang Qiyu]

1) Upgrade gnutls from 3.5.9 to 3.5.11.
2) Delete one patch "use-pkg-config-to-locate-zlib.patch", since it is 
integrated upstream.

Signed-off-by: Huang Qiyu 
---
 .../gnutls/use-pkg-config-to-locate-zlib.patch | 67 --
 .../gnutls/{gnutls_3.5.9.bb => gnutls_3.5.11.bb}   |  5 +-
 2 files changed, 2 insertions(+), 70 deletions(-)
 delete mode 100644 
meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
 rename meta/recipes-support/gnutls/{gnutls_3.5.9.bb => gnutls_3.5.11.bb} (53%)

diff --git 
a/meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch 
b/meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
deleted file mode 100644
index 0e1b7c8..000
--- a/meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-From cee80af1fe93f5b76765afeebfcc3b902768f5d6 Mon Sep 17 00:00:00 2001
-From: Andre McCurdy 
-Date: Tue, 26 May 2015 21:41:24 -0700
-Subject: [PATCH] use pkg-config to locate zlib
-
-AC_LIB_HAVE_LINKFLAGS can sometimes find host libs and is therefore not
-robust when cross-compiling. Remove it for zlib and use PKG_CHECK_MODULES
-instead.
-
-Removing AC_LIB_HAVE_LINKFLAGS for zlib also removes the --with-libz-prefix
-configure option. If zlib support is enabled, then failure to find zlib via
-pkg-config is now treated as a fatal error.
-
-Change based on ChromeOS gnutls 2.12.23 cross-compile fixes patch:
-
-  https://chromium-review.googlesource.com/#/c/271661/
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Andre McCurdy 

- configure.ac | 24 ++--
- 1 file changed, 10 insertions(+), 14 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 1b561d5..0c787dc 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -508,25 +508,21 @@ AC_ARG_WITH(zlib, AS_HELP_STRING([--without-zlib],
- AC_MSG_CHECKING([whether to include zlib compression support])
- if test x$ac_zlib != xno; then
-  AC_MSG_RESULT(yes)
-- AC_LIB_HAVE_LINKFLAGS(z,, [#include ], [compress (0, 0, 0, 0);])
-- if test x$ac_cv_libz != xyes; then
--   AC_MSG_WARN(
--*** 
--*** ZLIB was not found. You will not be able to use ZLIB compression.)
-- fi
- else
-  AC_MSG_RESULT(no)
- fi
- 
--PKG_CHECK_EXISTS(zlib, ZLIB_HAS_PKGCONFIG=y, ZLIB_HAS_PKGCONFIG=n)
--
- if test x$ac_zlib != xno; then
--  if test "$ZLIB_HAS_PKGCONFIG" = "y" ; then
--if test "x$GNUTLS_REQUIRES_PRIVATE" = x; then
--  GNUTLS_REQUIRES_PRIVATE="Requires.private: zlib"
--else
--  GNUTLS_REQUIRES_PRIVATE="$GNUTLS_REQUIRES_PRIVATE, zlib"
--fi
-+  PKG_CHECK_MODULES(ZLIB, zlib)
-+  HAVE_LIBZ=yes
-+  AC_DEFINE([HAVE_LIBZ], [1], [zlib is enabled])
-+  AC_SUBST(HAVE_LIBZ)
-+  LTLIBZ=$ZLIB_LIBS
-+  AC_SUBST(LTLIBZ)
-+  if test "x$GNUTLS_REQUIRES_PRIVATE" = x; then
-+GNUTLS_REQUIRES_PRIVATE="Requires.private: zlib"
-+  else
-+GNUTLS_REQUIRES_PRIVATE="$GNUTLS_REQUIRES_PRIVATE, zlib"
-   fi
- fi
- AC_SUBST(GNUTLS_REQUIRES_PRIVATE)
--- 
-1.9.1
-
diff --git a/meta/recipes-support/gnutls/gnutls_3.5.9.bb 
b/meta/recipes-support/gnutls/gnutls_3.5.11.bb
similarity index 53%
rename from meta/recipes-support/gnutls/gnutls_3.5.9.bb
rename to meta/recipes-support/gnutls/gnutls_3.5.11.bb
index 92e58b1..5e92f79 100644
--- a/meta/recipes-support/gnutls/gnutls_3.5.9.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.5.11.bb
@@ -2,10 +2,9 @@ require gnutls.inc
 
 SRC_URI += "file://correct_rpl_gettimeofday_signature.patch \
 file://0001-configure.ac-fix-sed-command.patch \
-file://use-pkg-config-to-locate-zlib.patch \
 file://arm_eabi.patch \
"
-SRC_URI[md5sum] = "0ab25eb6a1509345dd085bc21a387951"
-SRC_URI[sha256sum] = 
"82b10f0c4ef18f4e64ad8cef5dbaf14be732f5095a41cf366b4ecb4050382951"
+SRC_URI[md5sum] = "a3ff8cf5ca7522e3ba14f487e6326e11"
+SRC_URI[sha256sum] = 
"51765cc5579e250da77fbd7871507c517d01b15353cc40af7b67e9ec7b6fe28f"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.7.4



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

[OE-core] [PATCH 1/1] scriptutils: fix fetch_uri() to work with RSS

[Paul Eggleton]

Since recipe-specific sysroots were implemented, devtool add and devtool
upgrade operations that fetch from a URL that requires native sysroot
dependencies will fail to work as there is no recipe-specific sysroot
set up for them during fetching. An example was any URL pointing to a
tarball compressed with xz, e.g. devtool upgrade on gnutls.

The most expedient way to fix this is to set up a dummy recipe-specific
sysroot to use for the fetch/unpack operations. We do this in the same
manner as bitbake -b does, so we're just taking all of the sysroot
components available and creating a sysroot from those rather than
ensuring the correct dependencies are there - this means that we're
still going to have problems if e.g. xz-native hasn't been built yet,
but that issue will be trickier to solve and is tracked separately.

Fixes [YOCTO #11474].

Signed-off-by: Paul Eggleton 
---
 scripts/lib/scriptutils.py | 65 +-
 1 file changed, 41 insertions(+), 24 deletions(-)

diff --git a/scripts/lib/scriptutils.py b/scripts/lib/scriptutils.py
index 4ccbe5c..92b601c 100644
--- a/scripts/lib/scriptutils.py
+++ b/scripts/lib/scriptutils.py
@@ -21,6 +21,8 @@ import logging
 import glob
 import argparse
 import subprocess
+import tempfile
+import shutil
 
 def logger_create(name, stream=None):
 logger = logging.getLogger(name)
@@ -78,32 +80,47 @@ def git_convert_standalone_clone(repodir):
 
 def fetch_uri(d, uri, destdir, srcrev=None):
 """Fetch a URI to a local directory"""
-import bb.data
-bb.utils.mkdirhier(destdir)
-localdata = bb.data.createCopy(d)
-localdata.setVar('BB_STRICT_CHECKSUM', '')
-localdata.setVar('SRCREV', srcrev)
-ret = (None, None)
-olddir = os.getcwd()
+import bb
+tmpparent = d.getVar('BASE_WORKDIR')
+bb.utils.mkdirhier(tmpparent)
+tmpworkdir = tempfile.mkdtemp(dir=tmpparent)
 try:
-fetcher = bb.fetch2.Fetch([uri], localdata)
-for u in fetcher.ud:
-ud = fetcher.ud[u]
-ud.ignore_checksums = True
-fetcher.download()
-for u in fetcher.ud:
-ud = fetcher.ud[u]
-if ud.localpath.rstrip(os.sep) == 
localdata.getVar('DL_DIR').rstrip(os.sep):
-raise Exception('Local path is download directory - please 
check that the URI "%s" is correct' % uri)
-fetcher.unpack(destdir)
-for u in fetcher.ud:
-ud = fetcher.ud[u]
-if ud.method.recommends_checksum(ud):
-md5value = bb.utils.md5_file(ud.localpath)
-sha256value = bb.utils.sha256_file(ud.localpath)
-ret = (md5value, sha256value)
+bb.utils.mkdirhier(destdir)
+localdata = bb.data.createCopy(d)
+
+# Set some values to allow extend_recipe_sysroot to work here we're we 
are not running from a task
+localdata.setVar('WORKDIR', tmpworkdir)
+localdata.setVar('BB_RUNTASK', 'do_fetch')
+localdata.setVar('PN', 'dummy')
+localdata.setVar('BB_LIMITEDDEPS', '1')
+bb.build.exec_func("extend_recipe_sysroot", localdata)
+
+# Set some values for the benefit of the fetcher code
+localdata.setVar('BB_STRICT_CHECKSUM', '')
+localdata.setVar('SRCREV', srcrev)
+ret = (None, None)
+olddir = os.getcwd()
+try:
+fetcher = bb.fetch2.Fetch([uri], localdata)
+for u in fetcher.ud:
+ud = fetcher.ud[u]
+ud.ignore_checksums = True
+fetcher.download()
+for u in fetcher.ud:
+ud = fetcher.ud[u]
+if ud.localpath.rstrip(os.sep) == 
localdata.getVar('DL_DIR').rstrip(os.sep):
+raise Exception('Local path is download directory - please 
check that the URI "%s" is correct' % uri)
+fetcher.unpack(destdir)
+for u in fetcher.ud:
+ud = fetcher.ud[u]
+if ud.method.recommends_checksum(ud):
+md5value = bb.utils.md5_file(ud.localpath)
+sha256value = bb.utils.sha256_file(ud.localpath)
+ret = (md5value, sha256value)
+finally:
+os.chdir(olddir)
 finally:
-os.chdir(olddir)
+shutil.rmtree(tmpworkdir)
 return ret
 
 def run_editor(fn):
-- 
2.9.4

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

[OE-core] [PATCH 0/1] scriptutils: fix fetch_uri() to work with RSS

[Paul Eggleton]

The following changes since commit ee55b5685aaa4be92d6d51f8641a559d4e34ce64:

  cve-check-tool: backport a patch to make CVE checking work (2017-05-18 
14:01:41 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/devtool-fetch-fix
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/devtool-fetch-fix

Paul Eggleton (1):
  scriptutils: fix fetch_uri() to work with RSS

 scripts/lib/scriptutils.py | 65 +-
 1 file changed, 41 insertions(+), 24 deletions(-)

-- 
2.9.4

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

Re: [OE-core] [PATCH] u-boot-mkimage: fix nativesdk build

[Tim Harvey]

On Wed, May 17, 2017 at 1:11 PM, Max Krummenacher  wrote:
> If building for nativesdk the wrong rss sysroot is used leading the
> following error message.
>
> | ERROR: oe_runmake failed
> | In file included from tools/imximage.c:13:0:
> | include/image.h:1024:27: fatal error: openssl/evp.h: No such file or 
> directory
> |  # include  
>
> Tools needed on the build host (script/basic/fixdep) and code compiled
> for the SDK machine are both built with the build host's compiler,
> leading to additinal errors.
>
> Adding CROSS_COMPILE="${HOST_PREFIX}" and using the cross-compiler for
> the SDK_ARCH fixes the build error.
> The resulting binary in the SDK is working.
>
> Signed-off-by: Max Krummenacher 
> ---
>  meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb 
> b/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb
> index 1aa95e7..de999e7 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb
> +++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb
> @@ -7,7 +7,7 @@ DEPENDS = "openssl"
>
>  EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} 
> ${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
> STRIP=true V=1'
>  EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} 
> ${BUILD_LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
> STRIP=true V=1'
> -EXTRA_OEMAKE_class-nativesdk = 'CC="${BUILD_CC} ${BUILD_CFLAGS} 
> ${BUILD_LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
> STRIP=true V=1'
> +EXTRA_OEMAKE_class-nativesdk = 'CROSS_COMPILE="${HOST_PREFIX}" CC="${CC} 
> ${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
> STRIP=true V=1'
>
>  do_compile () {
> oe_runmake sandbox_defconfig
> --

This resolved build sdk issues on pyro

Tested-by: Tim Harvey  - pyro branch
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tzcode-native: quote ${CC}

[Enrico Scholz]

Denys Dmytriyenko  writes:

>> -EXTRA_OEMAKE += "cc=${CC}"
>> +EXTRA_OEMAKE += "cc='${CC}'"
>
> Should these be double-quotes around ${CC}?

I wrote it in this way:

- to 60%, because '' is more correct than "" in this context (see below)

- to 40%, because "" would clutter code too much and I can not say
  whether it must be quoted as \", \\" or whether perhaps plain " works
  too


A yet more correct solution would be

| export cc = "${CC}"

in the recipe (outside of do_*()) and perhaps adding '-e' to EXTRA_OEMAKE.


This handles additionally the case when 'CC' contains a single quote
(which causes misbehavior in my patch).

Double quotes are much more worse because CC must not contain '$', '`'
or '\\' (which is not uncommon in flags like '-DFOO()=\"bar\"').  In OE,
it is not expected that these characters are interpreted directly by the
shell (${CC} is passed properly quoted in the environment).

But all this does not matter... correct quoting is neglactted in OE and
bitbake; when you are lucky, commands are written as "foo '%s'" % path.
But nobody uses functions like 'pipes.quote()' or a non-shell variants
like subprocess.call(['foo', path]).

So, you can assume that '${FOO}' expands to the same value like "${FOO}".


Enrico
-- 
SIGMA Chemnitz GmbH   Registergericht:   Amtsgericht Chemnitz HRB 1750
Am Erlenwald 13   Geschaeftsfuehrer: Grit Freitag, Frank Pyritz
09128 Chemnitz
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] conf/bitbake.conf: include ed in hosttools

[Khem Raj]

On Thu, May 18, 2017 at 4:12 PM, Richard Purdie
 wrote:
> On Thu, 2017-05-18 at 17:28 -0500, Jose Lamego wrote:
>> Some recipes build fail due to missing ed command.
>>
>> This change includes ed to the hosttools required to
>> run builds with oe-core.
>>
>> Signed-off-by: Jose Lamego 
>> Signed-off-by: Leonardo Sandoval > tel.com>
>
> We really don't want to add ed here. Which recipes are failing and why
> do we need ed to build them?

we also need whoami which kernel uses to identify the build user id

>
> Cheers,
>
> Richard
>
>
> --
> ___
> 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/2] conf/bitbake.conf: include ed in hosttools

[Richard Purdie]

On Thu, 2017-05-18 at 17:28 -0500, Jose Lamego wrote:
> Some recipes build fail due to missing ed command.
> 
> This change includes ed to the hosttools required to
> run builds with oe-core.
> 
> Signed-off-by: Jose Lamego 
> Signed-off-by: Leonardo Sandoval  tel.com>

We really don't want to add ed here. Which recipes are failing and why
do we need ed to build them? 

Cheers,

Richard


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

Re: [OE-core] [PATCH] tzcode-native: quote ${CC}

[Christopher Larson]

On Thu, May 18, 2017 at 2:54 PM, Denys Dmytriyenko  wrote:

> On Thu, May 18, 2017 at 02:37:29PM -0700, Christopher Larson wrote:
> > On Thu, May 18, 2017 at 11:57 AM, Khem Raj  wrote:
> >
> > > On Thu, May 18, 2017 at 11:19 AM, Denys Dmytriyenko 
> > > wrote:
> > > > On Thu, May 18, 2017 at 07:34:23PM +0200, Enrico Scholz wrote:
> > > >> build fails else with
> > > >>
> > > >> | + make -j 8 -l 6 cc=ccache gcc
> > > >> | make: *** No rule to make target 'gcc'.  Stop.
> > > >>
> > > >> Signed-off-by: Enrico Scholz 
> > > >> ---
> > > >>  meta/recipes-extended/tzcode/tzcode-native_2017b.bb | 2 +-
> > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> > > b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> > > >> index 2084f79..165d2c6 100644
> > > >> --- a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> > > >> +++ b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> > > >> @@ -18,7 +18,7 @@ S = "${WORKDIR}"
> > > >>
> > > >>  inherit native
> > > >>
> > > >> -EXTRA_OEMAKE += "cc=${CC}"
> > > >> +EXTRA_OEMAKE += "cc='${CC}'"
> > > >
> > > > Should these be double-quotes around ${CC}?
> > >
> > > I think this should work as such.
> >
> > Indeed, it’s expanded by bitbake, not the shell, so which quotes don’t
> > matter in that regard, and it’s syntactically cleaner to use different
> > quotes than those used for the variable as a whole.
>
> Unless ${CC} has shell variables inside for later expansion, isn't it?


IMO doing so is a bug, as it relies on particulars of precisely when and
where the shell variable is expanded. Doing so often results in having to
escape it a precise number of times, depending on what context where you
want it expanded. More trouble than it’s worth, in my opinion. *shrug*
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] bc: upgrade 1.06 to 1.07.1

[Jose Lamego]

bc recipe must be upgraded to latest version in upstream.

bc license changed from "GPLv2+ & LGPLv2.1" to "GPLv3+ & LGPLv3"
The new version exhibits a Parallel Make Race that required
unsetting PARALLEL_MAKE variable.
This change was tested with core-image-minimal in qemux86.

Signed-off-by: Jose Lamego 
Signed-off-by: Leonardo Sandoval 
Signed-off-by: Alejandro Hernandez 
---
 .../bc/{bc_1.06.bb => bc_1.07.1.bb}| 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)
 rename meta/recipes-extended/bc/{bc_1.06.bb => bc_1.07.1.bb} (28%)

diff --git a/meta/recipes-extended/bc/bc_1.06.bb 
b/meta/recipes-extended/bc/bc_1.07.1.bb
similarity index 28%
rename from meta/recipes-extended/bc/bc_1.06.bb
rename to meta/recipes-extended/bc/bc_1.07.1.bb
index d8c8a86..55b4422 100644
--- a/meta/recipes-extended/bc/bc_1.06.bb
+++ b/meta/recipes-extended/bc/bc_1.07.1.bb
@@ -1,25 +1,25 @@
 SUMMARY = "Arbitrary precision calculator language"
 HOMEPAGE = "http://www.gnu.org/software/bc/bc.html;
 
-LICENSE = "GPLv2+ & LGPLv2.1"
-LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
-file://COPYING.LIB;md5=d8045f3b8f929c1cb29a1e3fd737b499 \
-
file://bc/bcdefs.h;endline=31;md5=46dffdaf10a99728dd8ce358e45d46d8 \
-
file://dc/dc.h;endline=25;md5=2f9c558cdd80e31b4d904e48c2374328 \
-
file://lib/number.c;endline=31;md5=99434a0898abca7784acfd36b8191199"
+LICENSE = "GPLv3+ & LGPLv3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.LIB;md5=6a6a8e020838b23406c81b19c1d46df6 \
+
file://bc/bcdefs.h;endline=27;md5=1bf4215734d4b9002ffda7b90b14e8e9 \
+
file://dc/dc.h;endline=20;md5=be0fc95c3503cb8116eea6acb63a5922 \
+
file://lib/number.c;endline=31;md5=5c437fc63f83a46d4d769d4dd1e74525"
 
 SECTION = "base"
 DEPENDS = "flex"
-PR = "r3"
 
-SRC_URI = "${GNU_MIRROR}/bc/bc-${PV}.tar.gz \
-   file://fix-segment-fault.patch "
+SRC_URI = "${GNU_MIRROR}/bc/bc-${PV}.tar.gz"
 
-SRC_URI[md5sum] = "d44b5dddebd8a7a7309aea6c36fda117"
-SRC_URI[sha256sum] = 
"4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea72c0e33"
+SRC_URI[md5sum] = "cda93857418655ea43590736fc3ca9fc"
+SRC_URI[sha256sum] = 
"62adfca89b0a1c0164c2cdca59ca210c1d44c3ffc46daf9931cf4942664cb02a"
 
 inherit autotools texinfo update-alternatives
 
+PARALLEL_MAKE = ""
+
 ALTERNATIVE_${PN} = "dc"
 ALTERNATIVE_PRIORITY = "100"
 
-- 
2.7.4

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

[OE-core] [PATCH 1/2] conf/bitbake.conf: include ed in hosttools

[Jose Lamego]

Some recipes build fail due to missing ed command.

This change includes ed to the hosttools required to
run builds with oe-core.

Signed-off-by: Jose Lamego 
Signed-off-by: Leonardo Sandoval 
---
 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 8e4f4bb..64f1a54 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -459,7 +459,7 @@ HOSTTOOLS_DIR = "${TMPDIR}/hosttools"
 # Tools needed to run builds with OE-Core
 HOSTTOOLS += " \
 [ ar as awk basename bash bzip2 cat chgrp chmod chown chrpath cmp cp cpio \
-cpp cut date dd diff diffstat dirname du echo egrep env expand expr false \
+cpp cut date dd diff diffstat dirname du echo ed egrep env expand expr 
false \
 fgrep file find flock g++ gawk gcc getconf getopt git grep gunzip gzip \
 head hostname install ld ldd ln ls make makeinfo md5sum mkdir mknod \
 mktemp mv nm objcopy objdump od patch perl pod2man pr printf pwd python 
python2 \
-- 
2.7.4

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

[OE-core] [PATCH 0/2] bc: upgrade 1.06 to 1.07.1

[Jose Lamego]

bc recipe must be upgraded to latest version in upstream.

Changes in this series:
include ed to the hosttools required to run builds with oe-core,
since the new bc version requires the ed command during build

upgrade bc version from 1.06 to 1.07.1

update bc license from "GPLv2+ & LGPLv2.1" to "GPLv3+ & LGPLv3"

unset PARALLEL_MAKE variable in bc recipe to prevent a
Parallel Make Race during build

Jose Lamego (2):
  conf/bitbake.conf: include ed in hosttools
  bc: upgrade 1.06 to 1.07.1

 meta/conf/bitbake.conf |  2 +-
 .../bc/{bc_1.06.bb => bc_1.07.1.bb}| 22 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)
 rename meta/recipes-extended/bc/{bc_1.06.bb => bc_1.07.1.bb} (28%)

-- 
2.7.4

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

Re: [OE-core] [PATCH] tzcode-native: quote ${CC}

[Denys Dmytriyenko]

On Thu, May 18, 2017 at 02:37:29PM -0700, Christopher Larson wrote:
> On Thu, May 18, 2017 at 11:57 AM, Khem Raj  wrote:
> 
> > On Thu, May 18, 2017 at 11:19 AM, Denys Dmytriyenko 
> > wrote:
> > > On Thu, May 18, 2017 at 07:34:23PM +0200, Enrico Scholz wrote:
> > >> build fails else with
> > >>
> > >> | + make -j 8 -l 6 cc=ccache gcc
> > >> | make: *** No rule to make target 'gcc'.  Stop.
> > >>
> > >> Signed-off-by: Enrico Scholz 
> > >> ---
> > >>  meta/recipes-extended/tzcode/tzcode-native_2017b.bb | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> > b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> > >> index 2084f79..165d2c6 100644
> > >> --- a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> > >> +++ b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> > >> @@ -18,7 +18,7 @@ S = "${WORKDIR}"
> > >>
> > >>  inherit native
> > >>
> > >> -EXTRA_OEMAKE += "cc=${CC}"
> > >> +EXTRA_OEMAKE += "cc='${CC}'"
> > >
> > > Should these be double-quotes around ${CC}?
> >
> > I think this should work as such.
> 
> Indeed, it’s expanded by bitbake, not the shell, so which quotes don’t
> matter in that regard, and it’s syntactically cleaner to use different
> quotes than those used for the variable as a whole.

Unless ${CC} has shell variables inside for later expansion, isn't it?

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

Re: [OE-core] [PATCH] libsolv: don't pick up bundled db from host rpm

[Max Krummenacher]

Hi Alex

Am Donnerstag, den 18.05.2017, 08:37 +0300 schrieb Alexander Kanavin:
> On 05/17/2017 11:16 PM, Max Krummenacher wrote:
> > With rpm v4 in openembedded but on a host with existing 
> > /usr/include/rpm/db.h
> > the build fails to compile.
> > +-  # check if rpm contains a bundled berkeley db
> > +-  CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H)
> > ++  set(HAVE_RPM_DB_H 0)
> 
> The problem seems to be that CHECK_INCLUDE_FILE is incorrectly looking 
> for headers in host's /usr/include. Perhaps you could look into why that 
> is happening and if it can be fixed, rather than fix one specific 
> instance in libsolv where it is known to cause trouble?

Ok, will try to find a more generic solution.

Max

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

Re: [OE-core] [PATCH] tzcode-native: quote ${CC}

[Christopher Larson]

On Thu, May 18, 2017 at 11:57 AM, Khem Raj  wrote:

> On Thu, May 18, 2017 at 11:19 AM, Denys Dmytriyenko 
> wrote:
> > On Thu, May 18, 2017 at 07:34:23PM +0200, Enrico Scholz wrote:
> >> build fails else with
> >>
> >> | + make -j 8 -l 6 cc=ccache gcc
> >> | make: *** No rule to make target 'gcc'.  Stop.
> >>
> >> Signed-off-by: Enrico Scholz 
> >> ---
> >>  meta/recipes-extended/tzcode/tzcode-native_2017b.bb | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> >> index 2084f79..165d2c6 100644
> >> --- a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> >> +++ b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> >> @@ -18,7 +18,7 @@ S = "${WORKDIR}"
> >>
> >>  inherit native
> >>
> >> -EXTRA_OEMAKE += "cc=${CC}"
> >> +EXTRA_OEMAKE += "cc='${CC}'"
> >
> > Should these be double-quotes around ${CC}?
>
> I think this should work as such.


Indeed, it’s expanded by bitbake, not the shell, so which quotes don’t
matter in that regard, and it’s syntactically cleaner to use different
quotes than those used for the variable as a whole.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel.bbclass: improve reproducibility

[Bystricky, Juro]

Quite possibly. However, the biggest abuser of __FILE__ seems to be kernel and 
kernel_modules.


From: Burton, Ross [ross.bur...@intel.com]
Sent: Thursday, May 18, 2017 2:10 PM
To: Bystricky, Juro
Cc: OE-core; Purdie, Richard; Joshua G Lock; Juro Bystricky
Subject: Re: [PATCH] kernel.bbclass: improve reproducibility


On 18 May 2017 at 22:05, Juro Bystricky 
> wrote:
Kernel and kernel modules contain hard coded paths referencing the host
build system. This is usually because the source code contains __FILE__
at some place. This prevents binary reproducibility. However, some compilers
allow remapping of the __FILE__ value. If we detect the compiler is capable
of doing this, we replace the source path $(S) part of __FILE__ by a string 
"/kernel-source".
For example:

Is this not something we should do globally?

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

Re: [OE-core] [PATCH] kernel.bbclass: improve reproducibility

[Burton, Ross]

On 18 May 2017 at 22:05, Juro Bystricky  wrote:

> Kernel and kernel modules contain hard coded paths referencing the host
> build system. This is usually because the source code contains __FILE__
> at some place. This prevents binary reproducibility. However, some
> compilers
> allow remapping of the __FILE__ value. If we detect the compiler is capable
> of doing this, we replace the source path $(S) part of __FILE__ by a
> string "/kernel-source".
> For example:
>

Is this not something we should do globally?

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

[OE-core] [PATCH] kernel.bbclass: improve reproducibility

[Juro Bystricky]

Kernel and kernel modules contain hard coded paths referencing the host
build system. This is usually because the source code contains __FILE__
at some place. This prevents binary reproducibility. However, some compilers
allow remapping of the __FILE__ value. If we detect the compiler is capable
of doing this, we replace the source path $(S) part of __FILE__ by a string 
"/kernel-source".
For example:

​/​data/​master/​build-​repro/​tmp/​work-​shared/​qemux86/​kernel-​source/​drivers/​media/​v4l2-​core/​videobuf2-​core.​c

will be replaced by a reproducible value:

/kernel-source/drivers/media/v4l2-core/videobuf2-core.c.

Signed-off-by: Juro Bystricky 
---
 meta/classes/kernel.bbclass | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8954b28..0a2cd3d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -249,6 +249,18 @@ python do_devshell_prepend () {
 
 addtask bundle_initramfs after do_install before do_deploy
 
+get_cc_option () {
+   # Check if KERNEL_CC supports the option "file-prefix-map".
+   # This option allows us to build images with __FILE__ values 
that do not
+   # contain the host build path.
+   cc_option_supported=`${KERNEL_CC} -Q --help=joined | grep 
ffile-prefix-map`
+   cc_extra=""
+   if [ $cc_option_supported = 

Re: [OE-core] [PATCH 02/11] trace-cmd: update to 2.6.1

[Burton, Ross]

On 10 May 2017 at 10:35, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> License change is due to update in FSF address.
>
> Library path needs to be specified in absolute form now.
>
> Remove bash completion file from kernelshark package as it will cause
> a conflict with trace-cmd package.
>

This breaks under musl:

https://autobuilder.yoctoproject.org/main/builders/nightly-musl/builds/459/steps/BuildImages/logs/stdio

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

Re: [OE-core] [PATCH v3 1/2] libx11: 1.6.4 -> 1.6.5

[Trevor Woerner]

Hi Zheng,

On Thu, May 18, 2017 at 3:40 AM, zhengrq  wrote:
>  meta/recipes-graphics/xorg-lib/{libx11_1.6.4.bb => libx11_1.6.5.bb} | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-graphics/xorg-lib/{libx11_1.6.4.bb => libx11_1.6.5.bb} 
> (47%)
>
> diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb 
> b/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
> similarity index 47%
> rename from meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb
> rename to meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb

This is much better; thank you!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tzcode-native: quote ${CC}

[Khem Raj]

On Thu, May 18, 2017 at 11:19 AM, Denys Dmytriyenko  wrote:
> On Thu, May 18, 2017 at 07:34:23PM +0200, Enrico Scholz wrote:
>> build fails else with
>>
>> | + make -j 8 -l 6 cc=ccache gcc
>> | make: *** No rule to make target 'gcc'.  Stop.
>>
>> Signed-off-by: Enrico Scholz 
>> ---
>>  meta/recipes-extended/tzcode/tzcode-native_2017b.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb 
>> b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
>> index 2084f79..165d2c6 100644
>> --- a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
>> +++ b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
>> @@ -18,7 +18,7 @@ S = "${WORKDIR}"
>>
>>  inherit native
>>
>> -EXTRA_OEMAKE += "cc=${CC}"
>> +EXTRA_OEMAKE += "cc='${CC}'"
>
> Should these be double-quotes around ${CC}?

I think this should work as such.

>
>
>>  do_install () {
>>  install -d ${D}${bindir}/
>> --
>> 2.9.4
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] piglit: add patches for unbuildable surfaceless Mesa test

[Daniel Díaz]

Some EGL implementations do not actually ship all Khronos-
extensions. As it turns out, the Mali 450 driver does not
include any of the following symbols, used by the
egl_mesa_platform_surfaceless.c spec test:
* eglGetPlatformDisplay
* eglCreatePlatformPixmapSurface
* eglCreatePlatformWindowSurface

The Right Thing To Do was to obtain the implementation of
these functions (via eglGetProcAddress), as is provided
by their EXT counterparts. These are guaranteed to exist
since they are required by EGL_EXT_platform_base.

Upstream-Status: Submitted [pig...@lists.freedesktop.org]

Signed-off-by: Daniel Díaz 
---
 ...nour-Surfaceless-MESA-in-get_default_disp.patch | 48 ++
 ...atform_surfaceless-Don-t-use-eglGetPlatfo.patch | 30 +
 ...atform_surfaceless-Use-EXT-functions-for-.patch | 75 ++
 3 files changed, 153 insertions(+)
 create mode 100644 
meta/recipes-graphics/piglit/piglit/0002-util-egl-Honour-Surfaceless-MESA-in-get_default_disp.patch
 create mode 100644 
meta/recipes-graphics/piglit/piglit/0003-egl_mesa_platform_surfaceless-Don-t-use-eglGetPlatfo.patch
 create mode 100644 
meta/recipes-graphics/piglit/piglit/0004-egl_mesa_platform_surfaceless-Use-EXT-functions-for-.patch

diff --git 
a/meta/recipes-graphics/piglit/piglit/0002-util-egl-Honour-Surfaceless-MESA-in-get_default_disp.patch
 
b/meta/recipes-graphics/piglit/piglit/0002-util-egl-Honour-Surfaceless-MESA-in-get_default_disp.patch
new file mode 100644
index 000..734de2b
--- /dev/null
+++ 
b/meta/recipes-graphics/piglit/piglit/0002-util-egl-Honour-Surfaceless-MESA-in-get_default_disp.patch
@@ -0,0 +1,48 @@
+From aa6728cc4941a87e3933c2aa770ab8ae3080b870 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Daniel=20D=C3=ADaz?= 
+Date: Tue, 16 May 2017 12:37:07 -0500
+Subject: [PATCH 2/4] util/egl: Honour Surfaceless MESA in get_default_display
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Daniel Díaz 
+---
+ tests/util/piglit-util-egl.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/tests/util/piglit-util-egl.c b/tests/util/piglit-util-egl.c
+index 106c735..389fe12 100644
+--- a/tests/util/piglit-util-egl.c
 b/tests/util/piglit-util-egl.c
+@@ -85,6 +85,7 @@ piglit_egl_get_default_display(EGLenum platform)
+   static bool has_x11 = false;
+   static bool has_wayland = false;
+   static bool has_gbm = false;
++  static bool has_surfaceless_mesa = false;
+ 
+   static EGLDisplay (*peglGetPlatformDisplayEXT)(EGLenum platform, void 
*native_display, const EGLint *attrib_list);
+ 
+@@ -99,6 +100,7 @@ piglit_egl_get_default_display(EGLenum platform)
+   has_x11 = piglit_is_egl_extension_supported(EGL_NO_DISPLAY, 
"EGL_EXT_platform_x11");
+   has_wayland = piglit_is_egl_extension_supported(EGL_NO_DISPLAY, 
"EGL_EXT_platform_wayland");
+   has_gbm = piglit_is_egl_extension_supported(EGL_NO_DISPLAY, 
"EGL_EXT_platform_gbm");
++  has_surfaceless_mesa = 
piglit_is_egl_extension_supported(EGL_NO_DISPLAY, 
"EGL_MESA_platform_surfaceless");
+ 
+   peglGetPlatformDisplayEXT = (void*) 
eglGetProcAddress("eglGetPlatformDisplayEXT");
+   }
+@@ -123,6 +125,11 @@ piglit_egl_get_default_display(EGLenum platform)
+   return EGL_NO_DISPLAY;
+   }
+   break;
++  case EGL_PLATFORM_SURFACELESS_MESA:
++  if (!has_surfaceless_mesa) {
++  return EGL_NO_DISPLAY;
++  }
++  break;
+   default:
+   fprintf(stderr, "%s: unrecognized platform %#x\n", __func__, 
platform);
+   return EGL_NO_DISPLAY;
+-- 
+1.9.1
+
diff --git 
a/meta/recipes-graphics/piglit/piglit/0003-egl_mesa_platform_surfaceless-Don-t-use-eglGetPlatfo.patch
 
b/meta/recipes-graphics/piglit/piglit/0003-egl_mesa_platform_surfaceless-Don-t-use-eglGetPlatfo.patch
new file mode 100644
index 000..7ec71dd
--- /dev/null
+++ 
b/meta/recipes-graphics/piglit/piglit/0003-egl_mesa_platform_surfaceless-Don-t-use-eglGetPlatfo.patch
@@ -0,0 +1,30 @@
+From b02bdbfdba3464ce47f87c04bcd1d35a8fef3f54 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Daniel=20D=C3=ADaz?= 
+Date: Wed, 17 May 2017 17:53:10 -0500
+Subject: [PATCH 3/4] egl_mesa_platform_surfaceless: Don't use
+ eglGetPlatformDisplay directly
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Daniel Díaz 
+---
+ .../spec/egl_mesa_platform_surfaceless/egl_mesa_platform_surfaceless.c  | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git 
a/tests/egl/spec/egl_mesa_platform_surfaceless/egl_mesa_platform_surfaceless.c 
b/tests/egl/spec/egl_mesa_platform_surfaceless/egl_mesa_platform_surfaceless.c
+index 3bbd6aa..81a3919 100644
+--- 

[OE-core] [PATCH 2/3] piglit: add patch for lack of gbm_bo_map

[Daniel Díaz]

[Piglit Bug #100978] -- https://bugs.freedesktop.org/show_bug.cgi?id=100978

When linking against Mali 450 r6, errors like the following
can be seen:
  ../../../../lib/libpiglitutil_gl.so.0: undefined reference to `gbm_bo_unmap'
  ../../../../lib/libpiglitutil_gl.so.0: undefined reference to `gbm_bo_map'
  collect2: error: ld returned 1 exit status
  make[2]: *** [bin/point-sprite] Error 1

This is due to gbm_bo_map() and gbm_bo_unmap() being recently
added but not yet implemented by all graphics drivers.

Instead of relying on GBM's version, actually try to link
against those symbols.

Upstream-Status: Submitted [pig...@lists.freedesktop.org]

Signed-off-by: Daniel Díaz 
---
 ...fine-GBM_BO_MAP-only-when-symbol-is-found.patch | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
meta/recipes-graphics/piglit/piglit/0001-CMake-define-GBM_BO_MAP-only-when-symbol-is-found.patch

diff --git 
a/meta/recipes-graphics/piglit/piglit/0001-CMake-define-GBM_BO_MAP-only-when-symbol-is-found.patch
 
b/meta/recipes-graphics/piglit/piglit/0001-CMake-define-GBM_BO_MAP-only-when-symbol-is-found.patch
new file mode 100644
index 000..0750676
--- /dev/null
+++ 
b/meta/recipes-graphics/piglit/piglit/0001-CMake-define-GBM_BO_MAP-only-when-symbol-is-found.patch
@@ -0,0 +1,48 @@
+From 6b6acee8841d092e5066b1bec2ba1c49cce4f91f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Daniel=20D=C3=ADaz?= 
+Date: Thu, 4 May 2017 00:57:39 -0500
+Subject: [PATCH 1/4] CMake: define GBM_BO_MAP only when symbol is found
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+gbm_bo_map() and _unmap() have been added recently to Mesa,
+and this update may not have reached all implementations of
+GBM, such as the one provided by Mali r6, where said
+definitions can be found in the header file but not in the
+library itself. This leads to errors like the following when
+linking:
+  ../../../../lib/libpiglitutil_gl.so.0: undefined reference to `gbm_bo_unmap'
+  ../../../../lib/libpiglitutil_gl.so.0: undefined reference to `gbm_bo_map'
+  collect2: error: ld returned 1 exit status
+  make[2]: *** [bin/point-sprite] Error 1
+
+Instead of relying on the header file, actually try to link
+using that symbol to determine if PIGLIT_HAS_GBM_BO_MAP
+should be defined.
+
+Signed-off-by: Daniel Díaz 
+Reviewed-by: Jan Vesely 
+---
+ CMakeLists.txt | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index a4ff99e..cc26fa8 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -141,8 +141,9 @@ IF(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
+   if(GBM_FOUND)
+   set(PIGLIT_HAS_GBM True)
+   add_definitions(-DPIGLIT_HAS_GBM)
+-  if (GBM_VERSION VERSION_EQUAL "12.1" OR GBM_VERSION 
VERSION_GREATER "12.1")
+-  set(PIGLIT_HAS_GBM_BO_MAP True)
++  set(CMAKE_REQUIRED_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES} 
${GBM_LIBRARIES})
++  CHECK_FUNCTION_EXISTS(gbm_bo_map PIGLIT_HAS_GBM_BO_MAP)
++  if (PIGLIT_HAS_GBM_BO_MAP)
+   add_definitions(-DPIGLIT_HAS_GBM_BO_MAP)
+   endif()
+   endif(GBM_FOUND)
+-- 
+1.9.1
+
-- 
1.9.1

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

[OE-core] [PATCH 1/3] piglit: depend on virtual/egl

[Daniel Díaz]

While building for Hikey using Mali 450 driver (r6p0), an
error like the following appears while linking:

  [  1%] Linking C shared library ../../../../lib/libpiglitutil.so
  [...]
  [...]/aarch64-linaro-linux/gcc/aarch64-linaro-linux/6.3.1/ld: cannot find 
-lEGL
  collect2: error: ld returned 1 exit status
  make[2]: *** [lib/libpiglitutil.so.0] Error 1

Mesa generally provides virtual/egl (along with virtual/libgl,
which satisfies Piglit's current DEPENDS) but that is not the
implementation to use with Mali.

Signed-off-by: Daniel Díaz 
---
 meta/recipes-graphics/piglit/piglit_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/piglit/piglit_git.bb 
b/meta/recipes-graphics/piglit/piglit_git.bb
index d6bfb14..eae3eed 100644
--- a/meta/recipes-graphics/piglit/piglit_git.bb
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -14,7 +14,7 @@ PV = "1.0+gitr${SRCPV}"
 
 S = "${WORKDIR}/git"
 
-DEPENDS = "libpng virtual/libx11 libxkbcommon libxrender waffle virtual/libgl 
libglu python3-mako-native python3-numpy-native python3-six-native"
+DEPENDS = "libpng virtual/libx11 libxkbcommon libxrender waffle virtual/libgl 
libglu python3-mako-native python3-numpy-native python3-six-native virtual/egl"
 
 inherit cmake python3native distro_features_check bash-completion
 # depends on virtual/libx11
-- 
1.9.1

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

Re: [OE-core] [PATCH] tzcode-native: quote ${CC}

[Denys Dmytriyenko]

On Thu, May 18, 2017 at 07:34:23PM +0200, Enrico Scholz wrote:
> build fails else with
> 
> | + make -j 8 -l 6 cc=ccache gcc
> | make: *** No rule to make target 'gcc'.  Stop.
> 
> Signed-off-by: Enrico Scholz 
> ---
>  meta/recipes-extended/tzcode/tzcode-native_2017b.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb 
> b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> index 2084f79..165d2c6 100644
> --- a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> +++ b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
> @@ -18,7 +18,7 @@ S = "${WORKDIR}"
>  
>  inherit native
>  
> -EXTRA_OEMAKE += "cc=${CC}"
> +EXTRA_OEMAKE += "cc='${CC}'"

Should these be double-quotes around ${CC}?


>  do_install () {
>  install -d ${D}${bindir}/
> -- 
> 2.9.4
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tzcode-native: quote ${CC}

[Enrico Scholz]

build fails else with

| + make -j 8 -l 6 cc=ccache gcc
| make: *** No rule to make target 'gcc'.  Stop.

Signed-off-by: Enrico Scholz 
---
 meta/recipes-extended/tzcode/tzcode-native_2017b.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb 
b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
index 2084f79..165d2c6 100644
--- a/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
+++ b/meta/recipes-extended/tzcode/tzcode-native_2017b.bb
@@ -18,7 +18,7 @@ S = "${WORKDIR}"
 
 inherit native
 
-EXTRA_OEMAKE += "cc=${CC}"
+EXTRA_OEMAKE += "cc='${CC}'"
 
 do_install () {
 install -d ${D}${bindir}/
-- 
2.9.4

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

Re: [OE-core] [PATCH v4] libnl: 3.2.29 -> 3.3.0

[Denys Dmytriyenko]

On Thu, May 18, 2017 at 11:19:09AM +0100, Burton, Ross wrote:
> On 18 May 2017 at 11:03, Huang, Qiyu  wrote:
> 
> > I fixed this error by myself, so it don't have Upstream-Status.
> >
> >
> Yes, you do.  Have you submitted it upstream? (then, Submitted).  Is it
> appropriate upstream at all, or is it customisation (Inappropriate).  If
> you wrote the patch, it needs to go upstream but you haven't yet, then
> Pending.
> 
> Ideally we want Submitted/Backport/Inappropriate, but we've a worrying
> number of Pending.  Please send it upstream.

We have a nice Wiki with all this explained:

https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations

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

Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as desired

[Belal, Awais]

> In this case:
> http://git.savannah.gnu.org/cgit/grub.git/tree/NEWS#n159

Ooooh, thanks :)

BR,
Awais


From: Alexander Kanavin 
Sent: Thursday, May 18, 2017 6:24 PM
To: Belal, Awais; Robert Yang; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as 
desired

On 05/18/2017 04:20 PM, Belal, Awais wrote:
>> I just checked why is autogen in oe-core in the first place. The
>> only thing that needs it now is grub, and it will no longer be
>> necessary when Khem's grub 2.02 patch shows up in master. So then
>> we can remove the whole thing. But thanks for fixing! :)
>
> I went through Khem's grub2 changes:
> http://cgit.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master=0af89270aa83d6ad0a4859e18643b53191567c8b
> and in those changes the grub2.inc still reads
>
> DEPENDS = "flex-native bison-native autogen-native"
>
> So I think this can be valuable :)

Don't take what DEPENDS says as authoritative on the subject. :) The
only way to tell if some dependency is no longer needed is careful
inspection of upstream code.

In this case:
http://git.savannah.gnu.org/cgit/grub.git/tree/NEWS#n159

Alex

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

[OE-core] [oe-core][PATCH] eudev: Add RREPLACES/RCONFLICTS/PE for udev migration

[Bryan Evenson]

Commit e5e540513665105b963262c2eaf33f197a0a36c replaced
udev with eudev on system's using sysvinit for init.
For clean upgrades, some extra variables are needed to
appropriately mark eudev as an update to udev.

 * Add RREPLACES/RCONFLICTS for udev so udev is removed on
   upgrade and the new files are replaced.
 * Commit ca2948a1d4e408bccdfcd43fc8833ea356a74bca added
   RREPLACES/RCONFLICTS for udev-utils when the udev-utils
   package was merged into udev.  Inherit this RREPLACES
   and RCONFLICTS so older systems with udev-utils will
   still upgrade cleanly.
 * The version numbering changed with eudev from a single
   version number to an x.y.z format with a lower version
   number.  The RREPLACES/RCONFLICTS takes care of upgrading
   udev to eudev, but both eudev and udev add the udev-cache
   package.  Since udev-cache can't replace/conflict with
   itself, the PE needs to be incremented for udev-cache
   to upgrade.

Signed-off-by: Bryan Evenson 
---
 meta/recipes-core/udev/eudev_3.2.1.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-core/udev/eudev_3.2.1.bb 
b/meta/recipes-core/udev/eudev_3.2.1.bb
index bdfb544..539945e 100644
--- a/meta/recipes-core/udev/eudev_3.2.1.bb
+++ b/meta/recipes-core/udev/eudev_3.2.1.bb
@@ -8,6 +8,8 @@ DEPENDS = "glib-2.0 glib-2.0-native gperf-native kmod 
libxslt-native util-linux"
 
 PROVIDES = "udev"
 
+PE = "1"
+
 SRC_URI = 
"https://github.com/gentoo/${BPN}/archive/v${PV}.tar.gz;downloadfilename=${BP}.tar.gz
 \
file://0014-Revert-rules-remove-firmware-loading-rules.patch \
file://Revert-udev-remove-userspace-firmware-loading-suppor.patch \
@@ -86,6 +88,10 @@ RRECOMMENDS_${PN} += "udev-cache"
 RPROVIDES_${PN} = "hotplug udev"
 RPROVIDES_eudev-hwdb += "udev-hwdb"
 
+RCONFLICTS_${PN} += "udev udev-utils"
+
+RREPLACES_${PN} += "udev udev-utils"
+
 python () {
 if bb.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
 raise bb.parse.SkipPackage("'systemd' in DISTRO_FEATURES")
-- 
1.9.1

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

[OE-core] [PATCH] systemd: fix lz4 build

[Stefan Müller-Klieser]

Updating lz4 in oe-core required back porting 3d4cf7de48a from master,
as versioning scheme changed.

Signed-off-by: Stefan Müller-Klieser 
---
 ...heck-for-lz4-in-the-old-and-new-numbering.patch | 51 ++
 meta/recipes-core/systemd/systemd_232.bb   |  1 +
 2 files changed, 52 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0021-build-sys-check-for-lz4-in-the-old-and-new-numbering.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0021-build-sys-check-for-lz4-in-the-old-and-new-numbering.patch
 
b/meta/recipes-core/systemd/systemd/0021-build-sys-check-for-lz4-in-the-old-and-new-numbering.patch
new file mode 100644
index 000..a7d7461
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0021-build-sys-check-for-lz4-in-the-old-and-new-numbering.patch
@@ -0,0 +1,51 @@
+From 822233bd40acda4bbfb991a31d87f4224fea Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= 
+Date: Wed, 23 Nov 2016 10:18:30 -0500
+Subject: [PATCH 21/21] build-sys: check for lz4 in the old and new numbering
+ scheme (#4717)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+lz4 upstream decided to switch to an incompatible numbering scheme
+(1.7.3 follows 131, to match the so version).
+PKG_CHECK_MODULES does not allow two version matches for the same package,
+so e.g. lz4 < 10 || lz4 >= 125 cannot be used. Check twice, once for
+"new" numbers (anything below 10 is assume to be new), once for the "old"
+numbers (anything above >= 125). This assumes that the "new" versioning
+will not get to 10 to quickly. I think that's a safe assumption, lz4 is a
+mature project.
+
+Fixed #4690.
+
+Upstream-Status: Backport
+
+Signed-off-by: Stefan Müller-Klieser 
+---
+ configure.ac | 9 ++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 279ce28..782b5d7 100644
+--- a/configure.ac
 b/configure.ac
+@@ -640,10 +640,13 @@ AM_CONDITIONAL(HAVE_BZIP2, [test "$have_bzip2" = "yes"])
+ have_lz4=no
+ AC_ARG_ENABLE(lz4, AS_HELP_STRING([--disable-lz4], [Disable optional LZ4 
support]))
+ AS_IF([test "x$enable_lz4" != "xno"], [
+-PKG_CHECK_MODULES(LZ4, [ liblz4 >= 125 ],
+-   [AC_DEFINE(HAVE_LZ4, 1, [Define in LZ4 is available])
++PKG_CHECK_MODULES(LZ4, [ liblz4 < 10 ],
++   [AC_DEFINE(HAVE_LZ4, 1, [Define if LZ4 is available])
+ have_lz4=yes],
+-have_lz4=no)
++[PKG_CHECK_MODULES(LZ4, [ liblz4 >= 125 ],
++  [AC_DEFINE(HAVE_LZ4, 1, [Define if LZ4 is available])
++  have_lz4=yes],
++  have_lz4=no)])
+ AS_IF([test "x$have_lz4" = xno -a "x$enable_lz4" = xyes],
+   [AC_MSG_ERROR([*** LZ4 support requested but libraries not 
found])])
+ ])
+-- 
+1.9.1
+
diff --git a/meta/recipes-core/systemd/systemd_232.bb 
b/meta/recipes-core/systemd/systemd_232.bb
index 398cb46..6513054 100644
--- a/meta/recipes-core/systemd/systemd_232.bb
+++ b/meta/recipes-core/systemd/systemd_232.bb
@@ -33,6 +33,7 @@ SRC_URI += " \
file://0018-check-for-uchar.h-in-configure.patch \

file://0019-socket-util-don-t-fail-if-libc-doesn-t-support-IDN.patch \

file://0020-back-port-233-don-t-use-the-unified-hierarchy-for-the-systemd.patch 
\
+   
file://0021-build-sys-check-for-lz4-in-the-old-and-new-numbering.patch \
 "
 SRC_URI_append_libc-uclibc = "\

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

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

Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as desired

[Alexander Kanavin]

On 05/18/2017 04:20 PM, Belal, Awais wrote:

I just checked why is autogen in oe-core in the first place. The
only thing that needs it now is grub, and it will no longer be
necessary when Khem's grub 2.02 patch shows up in master. So then
we can remove the whole thing. But thanks for fixing! :)


I went through Khem's grub2 changes:
http://cgit.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master=0af89270aa83d6ad0a4859e18643b53191567c8b
and in those changes the grub2.inc still reads

DEPENDS = "flex-native bison-native autogen-native"

So I think this can be valuable :)


Don't take what DEPENDS says as authoritative on the subject. :) The 
only way to tell if some dependency is no longer needed is careful 
inspection of upstream code.


In this case:
http://git.savannah.gnu.org/cgit/grub.git/tree/NEWS#n159

Alex

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

Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as desired

[Belal, Awais]

> I just checked why is autogen in oe-core in the first place. The only
> thing that needs it now is grub, and it will no longer be necessary when
> Khem's grub 2.02 patch shows up in master. So then we can remove the
> whole thing. But thanks for fixing! :)

I went through Khem's grub2 changes: 
http://cgit.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master=0af89270aa83d6ad0a4859e18643b53191567c8b
 and in those changes the grub2.inc still reads

DEPENDS = "flex-native bison-native autogen-native"

So I think this can be valuable :)

BR,
Awais


From: Alexander Kanavin 
Sent: Thursday, May 18, 2017 5:32 PM
To: Belal, Awais; Robert Yang; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as 
desired

On 05/18/2017 02:23 PM, Belal, Awais wrote:
>> That's right. The file is generated from libopts.def in the same
>> directory. I now looked at the code finally :) and I think it's
>> better to leave the POSIX_SHELL variable alone (and not set it from
>> the recipe either because it has no effect), and go back to the
>> original idea of patching the place where it's used to make a
>> shebang line - I think there's only one such place in the source
>> code.
>
>> But fixing libopts.def is okay too, I just think it's more
>> trouble.
>
> The usage of libopts.def has been deprecated upstream:
> git://git.sv.gnu.org/autogen.git #
> 5cbe233387d7f7b36752736338d1cd4f71287daa but they've still kept
> libopts.m4 so I think this patch will do for future use as well and
> shouldn't have a problem.

I just checked why is autogen in oe-core in the first place. The only
thing that needs it now is grub, and it will no longer be necessary when
Khem's grub 2.02 patch shows up in master. So then we can remove the
whole thing. But thanks for fixing! :)

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

[OE-core] [PATCH v2] linux-yocto/4.1: fix gcc7 compilation and v4.1.39

[Bruce Ashfield]

Porting the mainline commit, to fix gcc7 builds:

  474c90156c [give up on gcc ilog2() constant optimizations]

We also integrate the 4.1.39 -stable update to pick up additional
fixes.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 20 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index 21cc635bf4f8..d69b9ade2ce1 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "f793c71d51277bdb14d6854c8cbcc09b4f5936b4"
-SRCREV_meta ?= "7140ddb86e4b01529185e6d4a606001ad152b8f3"
+SRCREV_machine ?= "ec0bfadaeac24cc63fa05521c6608b79b26a5e5d"
+SRCREV_meta ?= "82aa97b3ebb3cd7eec8296a7cb090dfc67c2d382"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.1.38"
+LINUX_VERSION ?= "4.1.39"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index ce8aea628b2c..f7c969a1bece 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "4.1.38"
+LINUX_VERSION ?= "4.1.39"
 
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "2ce56d130ddff67f43ec857cc51cd347666a0078"
-SRCREV_meta ?= "7140ddb86e4b01529185e6d4a606001ad152b8f3"
+SRCREV_machine ?= "398d1785c6bde0085b99f00f346e199a15fbdcef"
+SRCREV_meta ?= "82aa97b3ebb3cd7eec8296a7cb090dfc67c2d382"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index bf7f266ee6f2..c6cdcab95030 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "4d2c95e78cdc7d312b7ab231ce90dce317f45df9"
-SRCREV_machine_qemuarm64 ?= "2ce56d130ddff67f43ec857cc51cd347666a0078"
-SRCREV_machine_qemumips ?= "81454f95166056a253c8950980e025ee243d8074"
-SRCREV_machine_qemuppc ?= "42c41e606b70fd73a202f4146c0480f5624b0a0e"
-SRCREV_machine_qemux86 ?= "2ce56d130ddff67f43ec857cc51cd347666a0078"
-SRCREV_machine_qemux86-64 ?= "2ce56d130ddff67f43ec857cc51cd347666a0078"
-SRCREV_machine_qemumips64 ?= "8a481005da41f82d2a40bf8cb40334547160ab5b"
-SRCREV_machine ?= "2ce56d130ddff67f43ec857cc51cd347666a0078"
-SRCREV_meta ?= "7140ddb86e4b01529185e6d4a606001ad152b8f3"
+SRCREV_machine_qemuarm ?= "3b0fd24797cb11aae54010b1bbc09dd2ae8a108e"
+SRCREV_machine_qemuarm64 ?= "398d1785c6bde0085b99f00f346e199a15fbdcef"
+SRCREV_machine_qemumips ?= "7420516ff545f8ab3e2471cf08bf851744264a6a"
+SRCREV_machine_qemuppc ?= "6952f5a70bc8a84a4c4d926cdec93e7a39878f32"
+SRCREV_machine_qemux86 ?= "398d1785c6bde0085b99f00f346e199a15fbdcef"
+SRCREV_machine_qemux86-64 ?= "398d1785c6bde0085b99f00f346e199a15fbdcef"
+SRCREV_machine_qemumips64 ?= "59727538774860381f42bcfb6ec05fe21facd319"
+SRCREV_machine ?= "398d1785c6bde0085b99f00f346e199a15fbdcef"
+SRCREV_meta ?= "82aa97b3ebb3cd7eec8296a7cb090dfc67c2d382"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.1.38"
+LINUX_VERSION ?= "4.1.39"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.5.0

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

Re: [OE-core] volatile-binds and DNS

[Kristian Amlie]

On 18/05/17 14:30, Andrea Galbusera wrote:
> On Thu, May 18, 2017 at 9:16 AM, Kristian Amlie
> > wrote:
> 
> We've discovered that one of the recent commits to poky has broken DNS
> resolution in our image. The commit in questions is this one:
> 
> ---
> commit fcd48092d7bcab0cad2606e65332da62420935ad
> Author: Joe Slater  >
> Date:   Fri Mar 31 03:06:33 2017
> 
> volatile-binds: correct some errors reported by systemd
> 
> systemd-tmpfiles-setup will fail at boot, so we suppress
> the default versions of etc.conf and home.conf.
> 
> We also make sure that /var/{cache,spool} and /srv are writeable
> if they exist.
> ...
> ---
> 
> The problem is that this suppresses the creation of a /etc/resolv.conf
> file, and without that DNS does not work.
> 
> The file is a symlink to the resolv.conf that systemd provides in
> /run/systemd/resolve/resolv.conf, so it could potentially be
> prepopulated, but I admit I don't fully understand how this fits
> together.
> 
> Any advice?
> 
> 
> There's a bug open on this [1]. My workaround as for now is to apply
> [2], but I'm not completely aware of the issue that suggested the
> original commit you mention, hence there might be a better approach to
> fix this...
> 
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11331
> [2] 
> http://lists.openembedded.org/pipermail/openembedded-core/2017-April/136074.html

Thanks. Yes, that looks like the same issue. Reverting the line seems to
work, but this should ideally work out of the box. Unfortunately I don't
know enough about volatile-binds to suggest a proper fix...

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

Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as desired

[Alexander Kanavin]

On 05/18/2017 02:23 PM, Belal, Awais wrote:

That's right. The file is generated from libopts.def in the same
directory. I now looked at the code finally :) and I think it's
better to leave the POSIX_SHELL variable alone (and not set it from
the recipe either because it has no effect), and go back to the
original idea of patching the place where it's used to make a
shebang line - I think there's only one such place in the source
code.



But fixing libopts.def is okay too, I just think it's more
trouble.


The usage of libopts.def has been deprecated upstream:
git://git.sv.gnu.org/autogen.git #
5cbe233387d7f7b36752736338d1cd4f71287daa but they've still kept
libopts.m4 so I think this patch will do for future use as well and
shouldn't have a problem.


I just checked why is autogen in oe-core in the first place. The only 
thing that needs it now is grub, and it will no longer be necessary when 
Khem's grub 2.02 patch shows up in master. So then we can remove the 
whole thing. But thanks for fixing! :)


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

Re: [OE-core] [PATCH 1/4] linux-yocto/4.1: fix gcc7 compilation

[Bruce Ashfield]

On Thu, May 18, 2017 at 7:47 AM, Burton, Ross  wrote:

>
> On 15 May 2017 at 13:51, Bruce Ashfield 
> wrote:
> > Porting the mainline commit, to fix gcc7 builds:
> >
> >   474c90156c [give up on gcc ilog2() constant optimizations]
>
> Sorry but:
>
> ERROR: linux-yocto-4.1.38+gitAUTOINC+a867edab41_3b0fd24797-r0
> do_kernel_version_sanity_check: Package Version
> (4.1.38+gitAUTOINC+a867edab41_3b0fd24797) does not match of kernel being
> built (4.1.39). Please update the PV variable to match the kernel source or
> set KERNEL_VERSION_SANITY_SKIP="1" in your recipe.
>
>
Well bugger, I did that patch and then a -stable updated, decided to squash
them and then
blew away the version number bump.

I sent that as part of a queue, did you want the queue again, or just that
gcc7 patch resent as
a v2 of it ?

Bruce


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


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

Re: [OE-core] volatile-binds and DNS

[Andrea Galbusera]

On Thu, May 18, 2017 at 9:16 AM, Kristian Amlie 
wrote:

> We've discovered that one of the recent commits to poky has broken DNS
> resolution in our image. The commit in questions is this one:
>
> ---
> commit fcd48092d7bcab0cad2606e65332da62420935ad
> Author: Joe Slater 
> Date:   Fri Mar 31 03:06:33 2017
>
> volatile-binds: correct some errors reported by systemd
>
> systemd-tmpfiles-setup will fail at boot, so we suppress
> the default versions of etc.conf and home.conf.
>
> We also make sure that /var/{cache,spool} and /srv are writeable
> if they exist.
> ...
> ---
>
> The problem is that this suppresses the creation of a /etc/resolv.conf
> file, and without that DNS does not work.
>
> The file is a symlink to the resolv.conf that systemd provides in
> /run/systemd/resolve/resolv.conf, so it could potentially be
> prepopulated, but I admit I don't fully understand how this fits together.
>
> Any advice?
>

There's a bug open on this [1]. My workaround as for now is to apply [2],
but I'm not completely aware of the issue that suggested the original
commit you mention, hence there might be a better approach to fix this...

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11331
[2]
http://lists.openembedded.org/pipermail/openembedded-core/2017-April/136074.html



>
> --
> Kristian
> --
> ___
> 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] linux-yocto/4.1: fix gcc7 compilation

[Burton, Ross]

On 15 May 2017 at 13:51, Bruce Ashfield 
wrote:
> Porting the mainline commit, to fix gcc7 builds:
>
>   474c90156c [give up on gcc ilog2() constant optimizations]

Sorry but:

ERROR: linux-yocto-4.1.38+gitAUTOINC+a867edab41_3b0fd24797-r0
do_kernel_version_sanity_check: Package Version
(4.1.38+gitAUTOINC+a867edab41_3b0fd24797) does not match of kernel being
built (4.1.39). Please update the PV variable to match the kernel source or
set KERNEL_VERSION_SANITY_SKIP="1" in your recipe.

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

Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as desired

[Belal, Awais]

> That's right. The file is generated from libopts.def in the same
> directory. I now looked at the code finally :) and I think it's better
> to leave the POSIX_SHELL variable alone (and not set it from the recipe
> either because it has no effect), and go back to the original idea of
> patching the place where it's used to make a shebang line - I think
> there's only one such place in the source code.

> But fixing libopts.def is okay too, I just think it's more trouble.

The usage of libopts.def has been deprecated upstream: 
git://git.sv.gnu.org/autogen.git # 5cbe233387d7f7b36752736338d1cd4f71287daa but 
they've still kept libopts.m4 so I think this patch will do for future use as 
well and shouldn't have a problem.

BR,
Awais


From: Alexander Kanavin 
Sent: Thursday, May 18, 2017 1:36 PM
To: Robert Yang; Belal, Awais; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as 
desired

On 05/18/2017 10:23 AM, Robert Yang wrote:
>> +-  test -x "$POSIX_SHELL" && break
>> ++  test -n "$POSIX_SHELL" && break
>
> The problem is libopts.m4 is auto generated, so it may override
> when upgrade autogen-native.

That's right. The file is generated from libopts.def in the same
directory. I now looked at the code finally :) and I think it's better
to leave the POSIX_SHELL variable alone (and not set it from the recipe
either because it has no effect), and go back to the original idea of
patching the place where it's used to make a shebang line - I think
there's only one such place in the source code.

But fixing libopts.def is okay too, I just think it's more trouble.

Alex

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

Re: [OE-core] [PATCH v4] libnl: 3.2.29 -> 3.3.0

[Burton, Ross]

On 18 May 2017 at 11:03, Huang, Qiyu  wrote:

> I fixed this error by myself, so it don't have Upstream-Status.
>
>
Yes, you do.  Have you submitted it upstream? (then, Submitted).  Is it
appropriate upstream at all, or is it customisation (Inappropriate).  If
you wrote the patch, it needs to go upstream but you haven't yet, then
Pending.

Ideally we want Submitted/Backport/Inappropriate, but we've a worrying
number of Pending.  Please send it upstream.

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

Re: [OE-core] [PATCH v4] libnl: 3.2.29 -> 3.3.0

[Huang, Qiyu]

I fixed this error by myself, so it don't have Upstream-Status.

huangqy

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, May 18, 2017 5:27 PM
To: Huang, Qiyu/黄 琦宇 
Cc: OE-core 
Subject: Re: [OE-core] [PATCH v4] libnl: 3.2.29 -> 3.3.0


On 18 May 2017 at 10:15, Huang Qiyu 
> wrote:
+++ b/meta/recipes-support/libnl/libnl/musl-header-conflict.patch
@@ -0,0 +1,59 @@
+From e1f2827673d9d45fe69ca912628bbb90d4003f49 Mon Sep 17 00:00:00 2001
+From: Zheng Ruoqin 
>
+Date: Mon, 15 May 2017 02:09:08 +0900
+Subject: [PATCH] Fix musl compile error like:
+
+In file included from ../libnl-3.3.0/include/linux-private/linux/ipv6.h:5:0,
+ from ../libnl-3.3.0/include/netlink-private/netlink.h:54,
+ from ../libnl-3.3.0/lib/nl.c:28:
+../libnl-3.3.0/include/linux-private/linux/in6.h:32:8: error:
+redefinition of 'struct in6_addr'
+ struct in6_addr {
+^~~~
+
+Signed-off-by: Zheng Ruoqin 
>

This patch needs an Upstream-Status tag.

Ross


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

Re: [OE-core] [PATCH v4] libnl: 3.2.29 -> 3.3.0

[Burton, Ross]

On 18 May 2017 at 10:15, Huang Qiyu  wrote:

> +++ b/meta/recipes-support/libnl/libnl/musl-header-conflict.patch
> @@ -0,0 +1,59 @@
> +From e1f2827673d9d45fe69ca912628bbb90d4003f49 Mon Sep 17 00:00:00 2001
> +From: Zheng Ruoqin 
> +Date: Mon, 15 May 2017 02:09:08 +0900
> +Subject: [PATCH] Fix musl compile error like:
> +
> +In file included from ../libnl-3.3.0/include/linux-
> private/linux/ipv6.h:5:0,
> + from ../libnl-3.3.0/include/
> netlink-private/netlink.h:54,
> + from ../libnl-3.3.0/lib/nl.c:28:
> +../libnl-3.3.0/include/linux-private/linux/in6.h:32:8: error:
> +redefinition of 'struct in6_addr'
> + struct in6_addr {
> +^~~~
> +
> +Signed-off-by: Zheng Ruoqin 
>

This patch needs an Upstream-Status tag.

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

[OE-core] [PATCH v4] libnl: 3.2.29 -> 3.3.0

[Huang Qiyu]

1) Upgrade libnl from 3.2.29 to 3.3.0.
2) Delete patch "fix-pktloc_syntax_h-race.patch", since it is  integrated 
upstream.
3) Add patch "musl-header-conflict.patch" to fix musl compile error.

Signed-off-by: Huang Qiyu 
---
 .../libnl/libnl/fix-pktloc_syntax_h-race.patch | 36 -
 .../libnl/libnl/musl-header-conflict.patch | 59 ++
 .../libnl/{libnl_3.2.29.bb => libnl_3.3.0.bb}  |  6 +--
 3 files changed, 62 insertions(+), 39 deletions(-)
 delete mode 100644 
meta/recipes-support/libnl/libnl/fix-pktloc_syntax_h-race.patch
 create mode 100644 meta/recipes-support/libnl/libnl/musl-header-conflict.patch
 rename meta/recipes-support/libnl/{libnl_3.2.29.bb => libnl_3.3.0.bb} (88%)

diff --git a/meta/recipes-support/libnl/libnl/fix-pktloc_syntax_h-race.patch 
b/meta/recipes-support/libnl/libnl/fix-pktloc_syntax_h-race.patch
deleted file mode 100644
index 79aa0bd..000
--- a/meta/recipes-support/libnl/libnl/fix-pktloc_syntax_h-race.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-Upstream-Status: Inappropriate [configuration]
-
-libnl has progressed to 0.3.2 and there does not appear to be any
-"make -j" issues with this build after my limited testing on that
-newer version so we can assume this issue is fixed upstream
-
-Signed-off-by: Martin Jansa 
-
-Index: libnl-3.2.25/lib/Makefile.am
-===
 libnl-3.2.25.orig/lib/Makefile.am
-+++ libnl-3.2.25/lib/Makefile.am
-@@ -46,9 +46,12 @@ CLEANFILES = \
- 
- # Hack to avoid using ylwrap. It does not function correctly in combination
- # with --header-file=
-+route/pktloc.lo: route/pktloc_syntax.h route/pktloc_grammar.h
-+route/pktloc_grammar.h: route/pktloc_grammar.c
- route/pktloc_grammar.c: route/pktloc_grammar.l
-   $(AM_V_GEN) $(MKDIR_P) route; $(FLEX) 
--header-file=route/pktloc_grammar.h $(LFLAGS) -o $@ $^
- 
-+route/pktloc_syntax.h: route/pktloc_syntax.c
- route/pktloc_syntax.c: route/pktloc_syntax.y
-   $(AM_V_GEN) $(MKDIR_P) route; $(YACC) -d $(YFLAGS) -o $@ $^
- 
-@@ -102,7 +105,9 @@ BUILT_SOURCES = \
-   route/cls/ematch_grammar.c \
-   route/cls/ematch_syntax.c \
-   route/pktloc_grammar.c \
--  route/pktloc_syntax.c
-+   route/pktloc_syntax.c \
-+   route/pktloc_syntax.h \
-+   route/pktloc_grammar.h
- 
- EXTRA_DIST = \
-   route/pktloc_grammar.l \
diff --git a/meta/recipes-support/libnl/libnl/musl-header-conflict.patch 
b/meta/recipes-support/libnl/libnl/musl-header-conflict.patch
new file mode 100644
index 000..dfe4cb8
--- /dev/null
+++ b/meta/recipes-support/libnl/libnl/musl-header-conflict.patch
@@ -0,0 +1,59 @@
+From e1f2827673d9d45fe69ca912628bbb90d4003f49 Mon Sep 17 00:00:00 2001
+From: Zheng Ruoqin 
+Date: Mon, 15 May 2017 02:09:08 +0900
+Subject: [PATCH] Fix musl compile error like:
+
+In file included from ../libnl-3.3.0/include/linux-private/linux/ipv6.h:5:0,
+ from ../libnl-3.3.0/include/netlink-private/netlink.h:54,
+ from ../libnl-3.3.0/lib/nl.c:28:
+../libnl-3.3.0/include/linux-private/linux/in6.h:32:8: error:
+redefinition of 'struct in6_addr'
+ struct in6_addr {
+^~~~
+
+Signed-off-by: Zheng Ruoqin 
+---
+ include/linux-private/linux/if_bridge.h | 1 -
+ include/linux-private/linux/ipv6.h  | 1 -
+ include/netlink-private/netlink.h   | 1 -
+ 3 files changed, 3 deletions(-)
+
+diff --git a/include/linux-private/linux/if_bridge.h 
b/include/linux-private/linux/if_bridge.h
+index f24050b..8f7490c 100644
+--- a/include/linux-private/linux/if_bridge.h
 b/include/linux-private/linux/if_bridge.h
+@@ -15,7 +15,6 @@
+ 
+ #include 
+ #include 
+-#include 
+ 
+ #define SYSFS_BRIDGE_ATTR "bridge"
+ #define SYSFS_BRIDGE_FDB  "brforward"
+diff --git a/include/linux-private/linux/ipv6.h 
b/include/linux-private/linux/ipv6.h
+index e05e684..f16349d 100644
+--- a/include/linux-private/linux/ipv6.h
 b/include/linux-private/linux/ipv6.h
+@@ -2,7 +2,6 @@
+ #define _IPV6_H
+ 
+ #include 
+-#include 
+ 
+ /* The latest drafts declared increase in minimal mtu up to 1280. */
+ 
+diff --git a/include/netlink-private/netlink.h 
b/include/netlink-private/netlink.h
+index 728ca5c..a73115b 100644
+--- a/include/netlink-private/netlink.h
 b/include/netlink-private/netlink.h
+@@ -29,7 +29,6 @@
+ #include 
+ #include 
+ 
+-#include 
+ #include 
+ 
+ #include 
+-- 
+2.7.4
+
diff --git a/meta/recipes-support/libnl/libnl_3.2.29.bb 
b/meta/recipes-support/libnl/libnl_3.3.0.bb
similarity index 88%
rename from meta/recipes-support/libnl/libnl_3.2.29.bb
rename to meta/recipes-support/libnl/libnl_3.3.0.bb
index 7d4839b..b070416 100644
--- a/meta/recipes-support/libnl/libnl_3.2.29.bb
+++ b/meta/recipes-support/libnl/libnl_3.3.0.bb
@@ -10,13 +10,13 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 DEPENDS = "flex-native bison-native"
 
 

[OE-core] [PATCH] openssh: Remove deprecated sshd option

[Gary Thomas]

The UsePrivilegeSeparation is no longer supported (recent SSHD always runs
with previlege separation), so remove this option from the default config
file to avoid this warning:
  /etc/ssh/sshd_config line 110: Deprecated option UsePrivilegeSeparation

Signed-off-by: Gary Thomas 
---
 meta/recipes-connectivity/openssh/openssh/sshd_config | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssh/openssh/sshd_config 
b/meta/recipes-connectivity/openssh/openssh/sshd_config
index d48bd2b..31fe5d9 100644
--- a/meta/recipes-connectivity/openssh/openssh/sshd_config
+++ b/meta/recipes-connectivity/openssh/openssh/sshd_config
@@ -107,7 +107,6 @@ ChallengeResponseAuthentication no
 #PrintLastLog yes
 #TCPKeepAlive yes
 #UseLogin no
-UsePrivilegeSeparation sandbox # Default for new installations.
 #PermitUserEnvironment no
 Compression no
 ClientAliveInterval 15
-- 
2.7.4

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

[OE-core] [PATCH v3 4/8] devtools/images: add python-pgo-image

[Markus Lehtonen]

This is a special image for profiling Python 3.x in order to utilize
profile-guided-optimization. Profile data can be obtained by by running
bitbake python-pgo-image -c profile. Profile data will be copied into a
directory pointed by PYTHON3_PROFILE_DIR on the host system. The profile
task may be specified with PYTHON3_PROFILE_TASK.

The default profile task is pybench, although an example for using
test.regrtest is included in the recipe.

[YOCTO #9338]

Signed-off-by: Markus Lehtonen 
---
 meta/recipes-devtools/images/python-pgo-image.bb | 85 
 1 file changed, 85 insertions(+)
 create mode 100644 meta/recipes-devtools/images/python-pgo-image.bb

diff --git a/meta/recipes-devtools/images/python-pgo-image.bb 
b/meta/recipes-devtools/images/python-pgo-image.bb
new file mode 100644
index 00..76733a8c61
--- /dev/null
+++ b/meta/recipes-devtools/images/python-pgo-image.bb
@@ -0,0 +1,85 @@
+SUMMARY = "Minimal image for doing Python profiling (for PGO)"
+
+IMAGE_FEATURES += "ssh-server-dropbear"
+IMAGE_INSTALL = "packagegroup-core-boot"
+IMAGE_INSTALL += "python3-profile-opt python3-profile-opt-tests 
python3-profile-opt-tools"
+
+LICENSE = "MIT"
+
+inherit core-image
+
+PROFILE_DATA_WORKDIR = "${WORKDIR}/profile-data"
+
+PYTHON3_PROFILE_DIR ?= "${TMPDIR}/work-shared/${MACHINE}/python3/pgo-data"
+PYTHON3_PROFILE_TASK_DEFAULT = "-m test.regrtest --pgo -w -x test_asyncore 
test_gdb test_multiprocessing_fork test_multiprocessing_forkserver 
test_multiprocessing_main_handling test_multiprocessing_spawn test_subprocess"
+# Exclude tests that are failing on qemux86
+PYTHON3_PROFILE_TASK_DEFAULT += "test_builtin test_cmath 
test_concurrent_futures test_difflib test_distutils test_float test_format 
test_math test_optparse test_shutil test_statistics test_types test_unicode"
+# Exclude tests that are taking very long on qemux86
+PYTHON3_PROFILE_TASK_DEFAULT += "test_lib2to3 test_buffer test_pickle test_io 
test_threading test_asyncio test_urllib2_localnet test_itertools test_tuple 
test_trace test_tarfile test_unicodedata test_decimal test_long test_zipfile 
test_deque test_descr test_email test_venv test_bytes test_compileall test_ast 
test_multibytecodec"change python3 profile target to pybenchchange python3 
profile target to pybench
+
+# Change default profile target to pybench. Running test.regrtest takes
+# ridiculously long, i.e. around 4 hours in qemux86 on i7-3770K desktop
+# machine. Pybench "only" takes around 55 minutes.
+PYTHON3_PROFILE_TASK_DEFAULT = 
"${docdir}/python3-profile-opt/Tools/pybench/pybench.py -n 2 --with-gc 
--with-syscheck"
+
+PYTHON3_PROFILE_TASK ?= "${PYTHON3_PROFILE_TASK_DEFAULT}"
+
+# We need these because we're utilizing the runtime test helpers from oeqa
+TEST_TARGET ?= "qemu"
+TEST_QEMUBOOT_TIMEOUT ?= "1000"
+TEST_LOG_DIR ?= "${WORKDIR}/qemulogs"
+FIND_ROOTFS = "1"
+
+def run_profile(d, profile_bin, profile_task, tgt_in_dir, host_out_dir):
+from oeqa.targetcontrol import get_target_controller
+from oe.utils import getstatusoutput
+
+target = get_target_controller(d)
+target.deploy()
+try:
+# Boot target
+bootparams = None
+if d.getVar('VIRTUAL-RUNTIME_init_manager', True) == 'systemd':
+bootparams = 'systemd.log_level=debug systemd.log_target=console'
+target.start(extra_bootparams=bootparams)
+
+# Run profile task
+ret, output = target.run(profile_bin + ' ' + profile_task, 
timeout=7200)
+if ret:
+bb.fatal("Failed to run profile task on target: %s" % output)
+ret, output = target.run('tar czf pgo-data.tgz -C %s .' % tgt_in_dir)
+if ret:
+bb.fatal("Failed to archive profile data on target: %s" % output)
+
+# Retrieve and unpack profile data
+target.copy_from('/home/root/pgo-data.tgz', host_out_dir)
+
+profile_tarball = os.path.join(host_out_dir, 'pgo-data.tgz')
+ret, output = getstatusoutput('tar xf %s -C %s' % (profile_tarball, 
host_out_dir))
+os.unlink(profile_tarball)
+if ret:
+bb.fatal("Failed to unpack python profile data: %s" % output)
+finally:
+target.stop()
+
+
+# Profile task for Python 3.x
+python do_profile() {
+run_profile(d, 'python3',
+d.getVar('PYTHON3_PROFILE_TASK', True),
+'/home/root/python3-pgo-profiles/',
+os.path.join(d.getVar("PROFILE_DATA_WORKDIR", True), 
'python3'))
+}
+
+addtask profile after do_build
+do_profile[depends] += "qemu-native:do_populate_sysroot 
qemu-helper-native:do_populate_sysroot"
+do_profile[cleandirs] = "${PROFILE_DATA_WORKDIR}/python3"
+
+python do_profile_setscene () {
+sstate_setscene(d)
+}
+
+SSTATETASKS += "do_profile"
+do_profile[sstate-inputdirs] = "${PROFILE_DATA_WORKDIR}/python3"
+do_profile[sstate-outputdirs] = "${PYTHON3_PROFILE_DIR}"
+addtask do_profile_setscene
-- 
2.12.0

-- 

[OE-core] [PATCH v3 1/8] python3-native: support profile optimized build

[Markus Lehtonen]

Make it possible to build python3-native with profile directed optimization
enabled. The feature is enabled by specifying
PYTHON3_NATIVE_PROFILE_OPT = "1" in local.conf.

The profile task to be run may be specified with PYTHON3_NATIVE_PROFILE_TASK
variable in local.conf, e.g.
PYTHON3_NATIVE_PROFILE_TASK = "${S}/Tools/pybench/pybench.py -n 2 --with-gc 
--with-syscheck"

[YOCTO #9338]

Signed-off-by: Markus Lehtonen 
---
 meta/recipes-devtools/python/python3-native_3.5.2.bb | 9 +
 meta/recipes-devtools/python/python3/000-cross-compile.patch | 9 -
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-devtools/python/python3-native_3.5.2.bb 
b/meta/recipes-devtools/python/python3-native_3.5.2.bb
index edcf2244f5..1d99e56054 100644
--- a/meta/recipes-devtools/python/python3-native_3.5.2.bb
+++ b/meta/recipes-devtools/python/python3-native_3.5.2.bb
@@ -56,10 +56,19 @@ EXTRA_OEMAKE = '\
 # No ctypes option for python 3
 PYTHONLSBOPTS = ""
 
+PYTHON3_NATIVE_MAKE_TARGET ?= "${@'profile-opt' if 
d.getVar('PYTHON3_NATIVE_PROFILE_OPT', True) == '1' else ''}"
+
 do_configure_append() {
autoreconf --verbose --install --force --exclude=autopoint 
../Python-${PV}/Modules/_ctypes/libffi
 }
 
+do_compile() {
+if [ -n "${PYTHON3_NATIVE_PROFILE_TASK}" ]; then
+sed -i -e 
's,^PROFILE_TASK=.*,PROFILE_TASK=${PYTHON3_NATIVE_PROFILE_TASK},g' Makefile
+fi
+oe_runmake ${PYTHON3_NATIVE_MAKE_TARGET}
+}
+
 do_install() {
install -d ${D}${libdir}/pkgconfig
oe_runmake 'DESTDIR=${D}' install
diff --git a/meta/recipes-devtools/python/python3/000-cross-compile.patch 
b/meta/recipes-devtools/python/python3/000-cross-compile.patch
index 2d822218f4..d6d7820ee8 100644
--- a/meta/recipes-devtools/python/python3/000-cross-compile.patch
+++ b/meta/recipes-devtools/python/python3/000-cross-compile.patch
@@ -29,15 +29,6 @@ Index: Python-3.5.2/Makefile.pre.in
  
  PSRCS=\
Parser/acceler.c \
-@@ -509,7 +511,7 @@ build_all_generate_profile:
- 
- run_profile_task:
-   : # FIXME: can't run for a cross build
--  $(LLVM_PROF_FILE) $(RUNSHARED) ./$(BUILDPYTHON) $(PROFILE_TASK) || true
-+  $(LLVM_PROF_FILE) $(RUNSHARED) $(HOSTPYTHON) $(PROFILE_TASK) || true
- 
- build_all_merge_profile:
-   $(LLVM_PROF_MERGER)
 @@ -792,7 +794,7 @@ $(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN)
@$(MKDIR_P) Include
# Avoid copying the file onto itself for an in-tree build
-- 
2.12.0

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

[OE-core] [PATCH v3 0/8] support profile-optimized build for Python

[Markus Lehtonen]

Third incarnation of enabling profile-guided-optimization (PGO) for Python. The
patchset is significantly simplified from the previous version, mainly because
Python 2.x is not supported, and because of that, there is no need to install
packages under modified (opt/) prefix. Also, RSS made libpython soname mangling
unnecessary.

The last patch of this changeset is not obligatory after the changes since v2.
However, it will remove some hacks that should not be needed.

Changes since v2:
- support for Python 2.x dropped
- profiling recipe name changed from python-profile-opt3 to python3-profile-opt
- python3-profile-opt now uses standard 'usr/' prefix, and thus, it now also
  rconflicts with "regular" python3
- libpython name mangling in python3-profile-opt removed
- all patches to python-pgo-image squashed into one

[YOCTO #9338]

The following changes since commit 138f3e3f81d866e8272b01dd88c164b367adc4cd:

  byacc: remove the recipe (2017-05-16 14:08:19 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib marquiz/fixes-9338
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=marquiz/fixes-9338

Markus Lehtonen (8):
  python3-native: support profile optimized build
  python3: fix depends of python3-tests
  python3: add python3-profile-opt recipe
  devtools/images: add python-pgo-image
  python3: support profile optimized build
  python3: fix profile-optimized build of modules
  python3: add python3-tools subpackage
  python3: remove two setup.py cross-compile hacks

 meta/recipes-devtools/images/python-pgo-image.bb   | 85 ++
 .../python/python-3.5-manifest.inc | 10 ++-
 .../python/python3-native_3.5.2.bb |  9 +++
 meta/recipes-devtools/python/python3-profile-opt   |  1 +
 .../python/python3-profile-opt_3.5.2.bb| 15 
 .../python/python3/000-cross-compile.patch |  9 ---
 ...efile-add-install_generate_profile-target.patch | 25 +++
 ...-CFLAGS-for-extensions-when-cross-compili.patch | 56 ++
 .../python3-setup.py-no-host-headers-libs.patch| 33 -
 .../setup.py-find-libraries-in-staging-dirs.patch  | 30 
 meta/recipes-devtools/python/python3_3.5.2.bb  | 58 +++
 11 files changed, 239 insertions(+), 92 deletions(-)
 create mode 100644 meta/recipes-devtools/images/python-pgo-image.bb
 create mode 12 meta/recipes-devtools/python/python3-profile-opt
 create mode 100644 meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb
 create mode 100644 
meta/recipes-devtools/python/python3/Makefile-add-install_generate_profile-target.patch
 create mode 100644 
meta/recipes-devtools/python/python3/Use-correct-CFLAGS-for-extensions-when-cross-compili.patch
 delete mode 100644 
meta/recipes-devtools/python/python3/python3-setup.py-no-host-headers-libs.patch
 delete mode 100644 
meta/recipes-devtools/python/python3/setup.py-find-libraries-in-staging-dirs.patch

-- 
2.12.0

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

[OE-core] [PATCH v3 3/8] python3: add python3-profile-opt recipe

[Markus Lehtonen]

This patch adds a new recipe that builds a special version of python3 that
produces profile data used for optimization.  The new recipe directly includes
the base python recipe so that they are build in as similar way as possible and
this hopefully decreases the recipe maintenance burden, too. Also, its files
clash with the "normal" python3 so they cannot be installed in an image at the
same time.

Normally, profile-guided-optimization in Python is done simply by doing "make
profile-opt" which first builds python with profile instrumentation enabled,
then runs a profile task to get the profile data, and last, re-builds python
with profile data guiding the optimization. However, in our cross-build
environment this gets a lot trickier. We need to split out the steps as
building is done on the build host but we need to run the second step (i.e. run
the profile task) on the target hardware. This patch enables the first step,
i.e.  building python with profile instrumentation enabled

[YOCTO #9338]

Signed-off-by: Markus Lehtonen 
---
 meta/recipes-devtools/python/python3-profile-opt   |  1 +
 .../python/python3-profile-opt_3.5.2.bb| 12 +
 ...efile-add-install_generate_profile-target.patch | 25 ++
 meta/recipes-devtools/python/python3_3.5.2.bb  | 30 --
 4 files changed, 54 insertions(+), 14 deletions(-)
 create mode 12 meta/recipes-devtools/python/python3-profile-opt
 create mode 100644 meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb
 create mode 100644 
meta/recipes-devtools/python/python3/Makefile-add-install_generate_profile-target.patch

diff --git a/meta/recipes-devtools/python/python3-profile-opt 
b/meta/recipes-devtools/python/python3-profile-opt
new file mode 12
index 00..b8a0adbbb9
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-profile-opt
@@ -0,0 +1 @@
+python3
\ No newline at end of file
diff --git a/meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb 
b/meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb
new file mode 100644
index 00..bd8889cbed
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb
@@ -0,0 +1,12 @@
+require python3_${PV}.bb
+
+SRC_URI += "file://Makefile-add-install_generate_profile-target.patch \
+   "
+
+PYTHON3_MAKE_TARGET = "build_all_generate_profile"
+
+# Prevent a clash with libpython3
+EXCLUDE_FROM_SHLIBS = "1"
+RDEPENDS_${PN}-core += "lib${BPN}"
+DEBIAN_NOAUTONAME_lib${BPN} = "1"
+DEBIAN_NOAUTONAME_lib${BPN}-staticdev = "1"
diff --git 
a/meta/recipes-devtools/python/python3/Makefile-add-install_generate_profile-target.patch
 
b/meta/recipes-devtools/python/python3/Makefile-add-install_generate_profile-target.patch
new file mode 100644
index 00..7aee7fb799
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/Makefile-add-install_generate_profile-target.patch
@@ -0,0 +1,25 @@
+Makefile: add install_generate_profile target
+
+Making it possible to install the binaries with profile generation
+enabled. We need this as linking is also performed at the install stage.
+
+Upstream-Status: Inappropriate [oe-specific]
+
+Signed-off-by: Markus Lehtonen 
+
+diff --git a/Makefile.pre.in b/Makefile.pre.in
+index 2b87614..826155b 100644
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -1046,6 +1046,8 @@ QUICKTESTOPTS=   $(TESTOPTS) -x test_subprocess test_io 
test_lib2to3 \
+ quicktest:all platform
+   $(TESTRUNNER) $(QUICKTESTOPTS)
+ 
++install_generate_profile:
++  $(MAKE) install LDFLAGS="$(LDFLAGS) $(PGO_PROF_GEN_FLAG) @LTOFLAGS@" 
LIBS="$(LIBS)"
+ 
+ install: @FRAMEWORKINSTALLFIRST@ commoninstall bininstall maninstall 
@FRAMEWORKINSTALLLAST@
+   if test "x$(ENSUREPIP)" != "xno"  ; then \
+-- 
+2.6.6
+
diff --git a/meta/recipes-devtools/python/python3_3.5.2.bb 
b/meta/recipes-devtools/python/python3_3.5.2.bb
index 7f2bc7186f..97ecbab5e3 100644
--- a/meta/recipes-devtools/python/python3_3.5.2.bb
+++ b/meta/recipes-devtools/python/python3_3.5.2.bb
@@ -112,14 +112,10 @@ do_compile() {
# then call do_install twice we get Makefile.orig == Makefile.sysroot
install -m 0644 Makefile Makefile.sysroot
 
-   oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/python3-native/pgen \
-   HOSTPYTHON=${STAGING_BINDIR_NATIVE}/python3-native/python3 \
-   STAGING_LIBDIR=${STAGING_LIBDIR} \
-   STAGING_BASELIBDIR=${STAGING_BASELIBDIR} \
-   STAGING_INCDIR=${STAGING_INCDIR} \
-   LIB=${baselib} \
-   ARCH=${TARGET_ARCH} \
-   OPT="${CFLAGS}" libpython3.so
+if [ "${PYTHON3_MAKE_TARGET}" = "build_all_generate_profile" ]; then
+# This is only used in PGO profiling by python3-profile-opt package
+export EXTRA_CFLAGS="-fprofile-dir=./python3-pgo-profiles/"
+fi
 
oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/python3-native/pgen \
   

[OE-core] [PATCH v3 8/8] python3: remove two setup.py cross-compile hacks

[Markus Lehtonen]

Remove two unneeded hacks. The first hack ("setup.py: no host headers
libs" patch) is not needed because we use cross-compiler (e.g.
i586-oe-linux-gcc) which has not been configured with any host system
include or library directories, and thus, we don't get any host system
directories when running "gcc -E -v".

The second hack becomes useless after the first hack has been removed
and we get the standard include and lib directories normally from gcc.

Signed-off-by: Markus Lehtonen 
---
 .../python/python3-profile-opt_3.5.2.bb|  3 ++
 .../python3-setup.py-no-host-headers-libs.patch| 33 --
 .../setup.py-find-libraries-in-staging-dirs.patch  | 30 
 meta/recipes-devtools/python/python3_3.5.2.bb  |  2 --
 4 files changed, 3 insertions(+), 65 deletions(-)
 delete mode 100644 
meta/recipes-devtools/python/python3/python3-setup.py-no-host-headers-libs.patch
 delete mode 100644 
meta/recipes-devtools/python/python3/setup.py-find-libraries-in-staging-dirs.patch

diff --git a/meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb 
b/meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb
index bd8889cbed..d752cd8fd7 100644
--- a/meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb
+++ b/meta/recipes-devtools/python/python3-profile-opt_3.5.2.bb
@@ -5,6 +5,9 @@ SRC_URI += 
"file://Makefile-add-install_generate_profile-target.patch \
 
 PYTHON3_MAKE_TARGET = "build_all_generate_profile"
 
+RCONFLICTS_${PN}-core = "python3-core"
+RCONFLICTS_lib${BPN} = "libpython3"
+
 # Prevent a clash with libpython3
 EXCLUDE_FROM_SHLIBS = "1"
 RDEPENDS_${PN}-core += "lib${BPN}"
diff --git 
a/meta/recipes-devtools/python/python3/python3-setup.py-no-host-headers-libs.patch
 
b/meta/recipes-devtools/python/python3/python3-setup.py-no-host-headers-libs.patch
deleted file mode 100644
index 2bc8b8c460..00
--- 
a/meta/recipes-devtools/python/python3/python3-setup.py-no-host-headers-libs.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From 43238e1ac13e32984d015c92a5841f3de1fe1d15 Mon Sep 17 00:00:00 2001
-From: Jackie Huang 
-Date: Tue, 18 Nov 2014 00:07:07 -0500
-Subject: [PATCH] setup.py: no host headers libs
-
-When we are cross-compiling, setup.py should never look in /usr
-or /usr/local to find headers or libraries.
-
-Upstream-Status: Inappropriate [Cross compile specific]
-
-Signed-off-by: Jackie Huang 

- setup.py | 3 ---
- 1 file changed, 3 deletions(-)
-
-diff --git a/setup.py b/setup.py
-index f020b28..e8339cd 100644
 a/setup.py
-+++ b/setup.py
-@@ -444,10 +444,7 @@ class PyBuildExt(build_ext):
- if not cross_compiling:
- add_dir_to_list(self.compiler.library_dirs, 
os.path.join('/usr/local', sys.lib))
- add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')
--# only change this for cross builds for 3.3, issues on Mageia
--if cross_compiling:
- self.add_gcc_paths()
--if not cross_compiling:
- self.add_multiarch_paths()
- 
- # Add paths specified in the environment variables LDFLAGS and
--- 
-2.0.0
-
diff --git 
a/meta/recipes-devtools/python/python3/setup.py-find-libraries-in-staging-dirs.patch
 
b/meta/recipes-devtools/python/python3/setup.py-find-libraries-in-staging-dirs.patch
deleted file mode 100644
index f26bd38b02..00
--- 
a/meta/recipes-devtools/python/python3/setup.py-find-libraries-in-staging-dirs.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-Patch setup.py so that the detect_modules() function looks for required
-libraries and headers in STAGING_LIBDIR / STAGING_INCDIR.
-
-Without this patch, several extension modules are not built, even though
-their dependencies are present in the compiler's search paths.
-The result is the following warning, and ultimately incomplete packages:
-
-| The necessary bits to build these optional modules were not found:
-| _bz2  _curses_panel _dbm
-| _gdbm _lzma _sqlite3
-| nis   readline  zlib
-| To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.
-
-Upstream-Status:  Inappropriate [Cross compile specific]
-
-Signed-off-by: Dominic Sacré 
-
-Index: Python-3.4.3/setup.py
-===
 Python-3.4.3.orig/setup.py
-+++ Python-3.4.3/setup.py
-@@ -521,6 +521,8 @@ class PyBuildExt(build_ext):
- else:
- lib_dirs = self.compiler.library_dirs[:]
- inc_dirs = self.compiler.include_dirs[:]
-+lib_dirs.append(os.environ.get('STAGING_LIBDIR'))
-+inc_dirs.append(os.environ.get('STAGING_INCDIR'))
- exts = []
- missing = []
- 
diff --git a/meta/recipes-devtools/python/python3_3.5.2.bb 
b/meta/recipes-devtools/python/python3_3.5.2.bb
index 757909a893..9512a4d4a9 100644
--- 

[OE-core] [PATCH v3 6/8] python3: fix profile-optimized build of modules

[Markus Lehtonen]

Without this the pgo-related compiler flags are not used in
cross-builds.

[YOCTO #9338]

Signed-off-by: Markus Lehtonen 
---
 ...-CFLAGS-for-extensions-when-cross-compili.patch | 56 ++
 meta/recipes-devtools/python/python3_3.5.2.bb  |  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3/Use-correct-CFLAGS-for-extensions-when-cross-compili.patch

diff --git 
a/meta/recipes-devtools/python/python3/Use-correct-CFLAGS-for-extensions-when-cross-compili.patch
 
b/meta/recipes-devtools/python/python3/Use-correct-CFLAGS-for-extensions-when-cross-compili.patch
new file mode 100644
index 00..bf239c6261
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/Use-correct-CFLAGS-for-extensions-when-cross-compili.patch
@@ -0,0 +1,56 @@
+From 0fd8b986888ddf1995b503edf46ac827e83114d9 Mon Sep 17 00:00:00 2001
+From: Markus Lehtonen 
+Date: Wed, 23 Nov 2016 16:08:04 +0200
+Subject: [PATCH] Use correct CFLAGS for extensions when cross-compiling
+
+Take PY_CFLAGS_NODIST into account, like in native build. This is needed
+in order to to profile-optimized build. Also, pass EXTRA_CFLAGS to
+profile-optimized build.
+
+Upstream-Status: Pending
+
+Signed-off-by: Markus Lehtonen 
+---
+ Makefile.pre.in | 4 ++--
+ setup.py| 3 ++-
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/Makefile.pre.in b/Makefile.pre.in
+index bace00e..9635aa4 100644
+--- a/Makefile.pre.in
 b/Makefile.pre.in
+@@ -509,7 +509,7 @@ profile-opt:
+   $(MAKE) profile-removal
+ 
+ build_all_generate_profile:
+-  $(MAKE) all CFLAGS_NODIST="$(CFLAGS) $(PGO_PROF_GEN_FLAG) @LTOFLAGS@" 
LDFLAGS="$(LDFLAGS) $(PGO_PROF_GEN_FLAG) @LTOFLAGS@" LIBS="$(LIBS)"
++  $(MAKE) all CFLAGS_NODIST="$(CFLAGS) $(EXTRA_CFLAGS) 
$(PGO_PROF_GEN_FLAG) @LTOFLAGS@" LDFLAGS="$(LDFLAGS) $(PGO_PROF_GEN_FLAG) 
@LTOFLAGS@" LIBS="$(LIBS)"
+ 
+ run_profile_task:
+   : # FIXME: can't run for a cross build
+@@ -519,7 +519,7 @@ build_all_merge_profile:
+   $(LLVM_PROF_MERGER)
+ 
+ build_all_use_profile:
+-  $(MAKE) all CFLAGS_NODIST="$(CFLAGS) $(PGO_PROF_USE_FLAG) @LTOFLAGS@" 
LDFLAGS="$(LDFLAGS) @LTOFLAGS@"
++  $(MAKE) all CFLAGS_NODIST="$(CFLAGS) $(EXTRA_CFLAGS) 
$(PGO_PROF_USE_FLAG) @LTOFLAGS@" LDFLAGS="$(LDFLAGS) @LTOFLAGS@"
+ 
+ # Compile and run with gcov
+ .PHONY=coverage coverage-lcov coverage-report
+diff --git a/setup.py b/setup.py
+index c1ce87e..72d37cf 100644
+--- a/setup.py
 b/setup.py
+@@ -271,7 +271,8 @@ class PyBuildExt(build_ext):
+ # compilers
+ if compiler is not None:
+ if cross_compiling:
+-(ccshared,cflags) = (os.environ.get('CCSHARED') or '', 
os.environ.get('CFLAGS') or '')
++(ccshared,cflags) = (os.environ.get('CCSHARED') or '',
++ (os.environ.get('CFLAGS') or '') + ' ' + 
sysconfig.get_config_var('PY_CFLAGS_NODIST'))
+ else:
+ (ccshared,cflags) = 
sysconfig.get_config_vars('CCSHARED','CFLAGS')
+ args['compiler_so'] = compiler + ' ' + ccshared + ' ' + cflags
+-- 
+2.6.6
+
diff --git a/meta/recipes-devtools/python/python3_3.5.2.bb 
b/meta/recipes-devtools/python/python3_3.5.2.bb
index d40bc14d93..e3fe674cd7 100644
--- a/meta/recipes-devtools/python/python3_3.5.2.bb
+++ b/meta/recipes-devtools/python/python3_3.5.2.bb
@@ -37,6 +37,7 @@ SRC_URI += "\
 file://configure.ac-fix-LIBPL.patch \
 file://python3-fix-CVE-2016-1000110.patch \
 file://upstream-random-fixes.patch \
+file://Use-correct-CFLAGS-for-extensions-when-cross-compili.patch \
"
 SRC_URI[md5sum] = "8906efbacfcdc7c3c9198aeefafd159e"
 SRC_URI[sha256sum] = 
"0010f56100b9b74259ebcd5d4b295a32324b58b517403a10d1a2aa7cb22bca40"
-- 
2.12.0

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

[OE-core] [PATCH v3 5/8] python3: support profile optimized build

[Markus Lehtonen]

This patch makes it possible to build python3 with profile directed
optimization. That is, feed python build process with profile data to
guide optimization. This is the third (and the last) step in profile
directed optimization for Python 3.x.

In order to do a profile-optimized build you need to specify
PYTHON3_PROFILE_OPT = "1" in your local.conf, and, have profile data available
in the location pointed to by PYTHON3_PROFILE_DIR. Profile data can be
obtainen e.g. by running bitbake python-pgo-image -c profile3.

[YOCTO #9338]

Signed-off-by: Markus Lehtonen 
---
 meta/recipes-devtools/python/python3_3.5.2.bb | 20 
 1 file changed, 20 insertions(+)

diff --git a/meta/recipes-devtools/python/python3_3.5.2.bb 
b/meta/recipes-devtools/python/python3_3.5.2.bb
index 97ecbab5e3..d40bc14d93 100644
--- a/meta/recipes-devtools/python/python3_3.5.2.bb
+++ b/meta/recipes-devtools/python/python3_3.5.2.bb
@@ -76,6 +76,17 @@ export CROSSPYTHONPATH = 
"${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dy
 # No ctypes option for python 3
 PYTHONLSBOPTS = ""
 
+# Automatic profile guided optimization
+PYTHON3_MAKE_TARGET ?= "${@'build_all_use_profile' if 
d.getVar('PYTHON3_PROFILE_OPT', True) == '1' else ''}"
+PYTHON3_PROFILE_DIR ?= "${@'${TMPDIR}/work-shared/${MACHINE}/python3/pgo-data' 
if d.getVar('PYTHON3_PROFILE_OPT', True) == '1' else ''}"
+python () {
+if (d.getVar('PYTHON3_PROFILE_OPT', True) == '1' and
+d.getVar('PYTHON3_MAKE_TARGET', True) == 'build_all_use_profile'):
+profile_dir = d.getVar('PYTHON3_PROFILE_DIR', True)
+bb.utils.mkdirhier(profile_dir)
+d.setVarFlag('do_compile', 'file-checksums', '%s:True' % profile_dir)
+}
+
 do_configure_append() {
rm -f ${S}/Makefile.orig
autoreconf -Wcross --verbose --install --force --exclude=autopoint 
../Python-${PV}/Modules/_ctypes/libffi
@@ -115,6 +126,10 @@ do_compile() {
 if [ "${PYTHON3_MAKE_TARGET}" = "build_all_generate_profile" ]; then
 # This is only used in PGO profiling by python3-profile-opt package
 export EXTRA_CFLAGS="-fprofile-dir=./python3-pgo-profiles/"
+elif [ -n "${PYTHON3_PROFILE_DIR}" ]; then
+export EXTRA_CFLAGS="-fprofile-dir=${PYTHON3_PROFILE_DIR}"
+# Remove non-optimized build artefacts
+oe_runmake clean
 fi
 
oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/python3-native/pgen \
@@ -135,6 +150,11 @@ do_install() {
install -d ${D}${libdir}/pkgconfig
install -d ${D}${libdir}/python${PYTHON_MAJMIN}/config
 
+# This only has effect if we build with -fprofile-use, e.g. when make
+# target is build_all_use_profile
+if [ -n "${PYTHON3_PROFILE_DIR}" ]; then
+export EXTRA_CFLAGS="-fprofile-dir=${PYTHON3_PROFILE_DIR}"
+fi
# rerun the build once again with original makefile this time
# run install in a separate step to avoid compile/install race
oe_runmake HOSTPGEN=${STAGING_BINDIR_NATIVE}/python3-native/pgen \
-- 
2.12.0

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

[OE-core] [PATCH v3 7/8] python3: add python3-tools subpackage

[Markus Lehtonen]

Useful in developing Python, e.g. in benchmarking.

[YOCTO #9338]

Signed-off-by: Markus Lehtonen 
---
 meta/recipes-devtools/python/python-3.5-manifest.inc | 8 +---
 meta/recipes-devtools/python/python3_3.5.2.bb| 5 +
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python-3.5-manifest.inc 
b/meta/recipes-devtools/python/python-3.5-manifest.inc
index 3f29b53a73..8e40aec9c9 100644
--- a/meta/recipes-devtools/python/python-3.5-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.5-manifest.inc
@@ -4,9 +4,9 @@
 
  
 
-PROVIDES+="${PN}-2to3 ${PN}-argparse ${PN}-asyncio ${PN}-audio ${PN}-codecs 
${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes 
${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib 
${PN}-distutils ${PN}-distutils-staticdev ${PN}-doctest ${PN}-email ${PN}-enum 
${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image ${PN}-importlib 
${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math 
${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient ${PN}-netserver 
${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc 
${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource ${PN}-selectors 
${PN}-shell ${PN}-signal ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests 
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests 
${PN}-textutils ${PN}-threading ${PN}-tkinter ${PN}-typing ${PN}-unittest 
${PN}-unixadmin ${PN}-xml ${PN}-xmlrpc "
+PROVIDES+="${PN}-2to3 ${PN}-argparse ${PN}-asyncio ${PN}-audio ${PN}-codecs 
${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt ${PN}-ctypes 
${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev ${PN}-difflib 
${PN}-distutils ${PN}-distutils-staticdev ${PN}-doctest ${PN}-email ${PN}-enum 
${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image ${PN}-importlib 
${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math 
${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient ${PN}-netserver 
${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc 
${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource ${PN}-selectors 
${PN}-shell ${PN}-signal ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests 
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests 
${PN}-textutils ${PN}-threading ${PN}-tkinter ${PN}-typing ${PN}-unittest 
${PN}-unixadmin ${PN}-xml ${PN}-xmlrpc ${PN}-tools "
 
-PACKAGES="${PN}-dbg ${PN}-2to3 ${PN}-argparse ${PN}-asyncio ${PN}-audio 
${PN}-codecs ${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt 
${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev 
${PN}-difflib ${PN}-distutils-staticdev ${PN}-distutils ${PN}-doctest 
${PN}-email ${PN}-enum ${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image 
${PN}-importlib ${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox 
${PN}-math ${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient 
${PN}-netserver ${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint 
${PN}-profile ${PN}-pydoc ${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource 
${PN}-selectors ${PN}-shell ${PN}-signal ${PN}-smtpd ${PN}-sqlite3 
${PN}-sqlite3-tests ${PN}-stringold ${PN}-subprocess ${PN}-syslog 
${PN}-terminal ${PN}-tests ${PN}-textutils ${PN}-threading ${PN}-tkinter 
${PN}-typing ${PN}-unittest ${PN}-unixadmin ${PN}-xml ${PN}-xmlrpc 
${PN}-modules"
+PACKAGES="${PN}-dbg ${PN}-2to3 ${PN}-argparse ${PN}-asyncio ${PN}-audio 
${PN}-codecs ${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt 
${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-dev 
${PN}-difflib ${PN}-distutils-staticdev ${PN}-distutils ${PN}-doctest 
${PN}-email ${PN}-enum ${PN}-fcntl ${PN}-gdbm ${PN}-html ${PN}-idle ${PN}-image 
${PN}-importlib ${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox 
${PN}-math ${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient 
${PN}-netserver ${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-pprint 
${PN}-profile ${PN}-pydoc ${PN}-re ${PN}-readline ${PN}-reprlib ${PN}-resource 
${PN}-selectors ${PN}-shell ${PN}-signal ${PN}-smtpd ${PN}-sqlite3 
${PN}-sqlite3-tests ${PN}-stringold ${PN}-subprocess ${PN}-syslog 
${PN}-terminal ${PN}-tests ${PN}-textutils ${PN}-threading ${PN}-tkinter 
${PN}-typing ${PN}-unittest ${PN}-unixadmin ${PN}-xml ${PN}-xmlrpc 
${PN}-modules ${PN}-tools"
 
 SUMMARY_${PN}-2to3="Python automated Python 2 to 3 code translator"
 RDEPENDS_${PN}-2to3="${PN}-core"
@@ -280,4 +280,6 @@ SUMMARY_${PN}-modules="All Python modules"
 RDEPENDS_${PN}-modules="${PN}-2to3 ${PN}-argparse ${PN}-asyncio ${PN}-audio 
${PN}-codecs ${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt 
${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-difflib 
${PN}-distutils ${PN}-doctest ${PN}-email ${PN}-enum ${PN}-fcntl ${PN}-gdbm 
${PN}-html ${PN}-idle ${PN}-image ${PN}-importlib ${PN}-io ${PN}-json 

[OE-core] [PATCH v3 2/8] python3: fix depends of python3-tests

[Markus Lehtonen]

Similar to an earlier fix for Python 2.7. Make the tests subpackage
depend on all modules as test.regrtest uses most (if not all) of them.

Some tests also depend on libgcc so add that as a runtime dependency as
well.

[YOCTO #9338]

Signed-off-by: Markus Lehtonen 
---
 meta/recipes-devtools/python/python-3.5-manifest.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python-3.5-manifest.inc 
b/meta/recipes-devtools/python/python-3.5-manifest.inc
index 1e20f00c64..3f29b53a73 100644
--- a/meta/recipes-devtools/python/python-3.5-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.5-manifest.inc
@@ -241,7 +241,7 @@ RDEPENDS_${PN}-terminal="${PN}-core ${PN}-io"
 FILES_${PN}-terminal="${libdir}/python3.5/pty.* 
${libdir}/python3.5/__pycache__/pty.* ${libdir}/python3.5/tty.* 
${libdir}/python3.5/__pycache__/tty.* "
 
 SUMMARY_${PN}-tests="Python tests"
-RDEPENDS_${PN}-tests="${PN}-core"
+RDEPENDS_${PN}-tests="${PN}-core ${PN}-modules libgcc"
 FILES_${PN}-tests="${libdir}/python3.5/test 
${libdir}/python3.5/test/__pycache__ "
 
 SUMMARY_${PN}-textutils="Python option parsing, text wrapping and CSV support"
-- 
2.12.0

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

Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as desired

[Alexander Kanavin]

On 05/18/2017 10:23 AM, Robert Yang wrote:

+-  test -x "$POSIX_SHELL" && break
++  test -n "$POSIX_SHELL" && break


The problem is libopts.m4 is auto generated, so it may override
when upgrade autogen-native.


That's right. The file is generated from libopts.def in the same 
directory. I now looked at the code finally :) and I think it's better 
to leave the POSIX_SHELL variable alone (and not set it from the recipe 
either because it has no effect), and go back to the original idea of 
patching the place where it's used to make a shebang line - I think 
there's only one such place in the source code.


But fixing libopts.def is okay too, I just think it's more trouble.

Alex

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

[OE-core] [PATCH v3 1/2] libx11: 1.6.4 -> 1.6.5

[zhengrq]

Upgrade libx11 from 1.6.4 to 1.6.5

Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-graphics/xorg-lib/{libx11_1.6.4.bb => libx11_1.6.5.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-lib/{libx11_1.6.4.bb => libx11_1.6.5.bb} 
(47%)

diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb 
b/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
similarity index 47%
rename from meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb
rename to meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
index caa95fb..71cbf67 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.6.4.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.6.5.bb
@@ -6,5 +6,5 @@ BBCLASSEXTEND = "native nativesdk"
 SRC_URI += "file://disable_tests.patch \
"
 
-SRC_URI[md5sum] = "6d54227082f3aa2c596f0b3a3fbb9175"
-SRC_URI[sha256sum] = 
"b7c748be3aa16ec2cbd81edc847e9b6ee03f88143ab270fb59f58a044d34e441"
+SRC_URI[md5sum] = "0f618db70c4054ca67cee0cc156a4255"
+SRC_URI[sha256sum] = 
"4d3890db2ba225ba8c55ca63c6409c1ebb078a2806de59fb16342768ae63435d"
-- 
2.7.4



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

[OE-core] [PATCH v3 2/2] libx11-diet: 1.6.4 -> 1.6.5

[zhengrq]

Upgrade libx11-diet from 1.6.4 to 1.6.5

Signed-off-by: Zheng Ruoqin 
---
 .../xorg-lib/{libx11-diet_1.6.4.bb => libx11-diet_1.6.5.bb}   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-lib/{libx11-diet_1.6.4.bb => 
libx11-diet_1.6.5.bb} (73%)

diff --git a/meta/recipes-graphics/xorg-lib/libx11-diet_1.6.4.bb 
b/meta/recipes-graphics/xorg-lib/libx11-diet_1.6.5.bb
similarity index 73%
rename from meta/recipes-graphics/xorg-lib/libx11-diet_1.6.4.bb
rename to meta/recipes-graphics/xorg-lib/libx11-diet_1.6.5.bb
index 0c761d7..295f96a2 100644
--- a/meta/recipes-graphics/xorg-lib/libx11-diet_1.6.4.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11-diet_1.6.5.bb
@@ -11,8 +11,8 @@ SRC_URI += "file://X18NCMSstubs.diff \
 RPROVIDES_${PN}-dev = "libx11-dev"
 RPROVIDES_${PN}-locale = "libx11-locale"
 
-SRC_URI[md5sum] = "6d54227082f3aa2c596f0b3a3fbb9175"
-SRC_URI[sha256sum] = 
"b7c748be3aa16ec2cbd81edc847e9b6ee03f88143ab270fb59f58a044d34e441"
+SRC_URI[md5sum] = "0f618db70c4054ca67cee0cc156a4255"
+SRC_URI[sha256sum] = 
"4d3890db2ba225ba8c55ca63c6409c1ebb078a2806de59fb16342768ae63435d"
 
 EXTRA_OECONF += "--disable-xlocale"
 
-- 
2.7.4



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

[OE-core] [PATCH v3 0/2] upgrade libx11 and libx11-diet

[zhengrq]

1)Upgrade libx11 from 1.6.4 to 1.6.5

2)Upgrade libx11-diet from 1.6.4 to 1.6.5

 .../xorg-lib/{libx11-diet_1.6.4.bb => libx11-diet_1.6.5.bb}   | 4 ++--
 meta/recipes-graphics/xorg-lib/{libx11_1.6.4.bb => libx11_1.6.5.bb}   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-graphics/xorg-lib/{libx11-diet_1.6.4.bb => 
libx11-diet_1.6.5.bb} (73%)
 rename meta/recipes-graphics/xorg-lib/{libx11_1.6.4.bb => libx11_1.6.5.bb} 
(47%)

-- 
2.7.4



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

Re: [OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as desired

[Robert Yang]

Hi Awais,

On 05/18/2017 02:50 PM, Awais Belal wrote:

Using 'test -x' is only viable in situations where
POSIX_SHELL is directly set to an executable whereas
there are scenarios where a user might want to set
it to "env sh" so that it can be used in places
where there's a problem with shebang lengths etc. This
is exactly how it is being used in OE so build failures
are seen in cases where deep directory hierarchies are
used for the builddir.
We now use 'test -n' just to make sure if POSIX_SHELL
is set by the user or not and then move forward to
other tests in case it is unset.

Signed-off-by: Awais Belal 
---
 .../autogen/autogen-native_5.18.12.bb  |  1 +
 ...pts-allow-user-to-set-POSIX_SHELL-as-desi.patch | 37 ++
 2 files changed, 38 insertions(+)
 create mode 100644 
meta/recipes-devtools/autogen/autogen/0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch

diff --git a/meta/recipes-devtools/autogen/autogen-native_5.18.12.bb 
b/meta/recipes-devtools/autogen/autogen-native_5.18.12.bb
index 853477cf7c..37571e3358 100644
--- a/meta/recipes-devtools/autogen/autogen-native_5.18.12.bb
+++ b/meta/recipes-devtools/autogen/autogen-native_5.18.12.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"${GNU_MIRROR}/autogen/rel${PV}/autogen-${PV}.tar.gz \
file://fix-script-err-when-processing-libguile.patch \

file://0001-config-libopts.m4-regenerate-it-from-config-libopts..patch \
file://0002-autoopts-mk-tpl-config.sh-fix-perl-path.patch \
+   
file://0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch \
 "

 SRC_URI[md5sum] = "551d15ccbf5b5fc5658da375d5003389"
diff --git 
a/meta/recipes-devtools/autogen/autogen/0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch
 
b/meta/recipes-devtools/autogen/autogen/0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch
new file mode 100644
index 00..bfbf6621e1
--- /dev/null
+++ 
b/meta/recipes-devtools/autogen/autogen/0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch
@@ -0,0 +1,37 @@
+From dfb30e438a051993c69357c5069170ec779e91e4 Mon Sep 17 00:00:00 2001
+From: Awais Belal 
+Date: Wed, 17 May 2017 15:06:48 +0500
+Subject: [PATCH] config/libopts: allow user to set POSIX_SHELL as desired
+
+Using 'test -x' is only viable in situations where
+POSIX_SHELL is directly set to an executable whereas
+there are scenarios where a user might want to set
+it to "env sh" so that it can be used in places
+where there's a problem with shebang lengths etc.
+We now use 'test -n' just to make sure if POSIX_SHELL
+is set by the user or not and then move forward to
+other tests in case it is unset.
+
+Upstream-Status: Pending
+
+Signed-off-by: Awais Belal 
+---
+ config/libopts.m4 | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/config/libopts.m4 b/config/libopts.m4
+index 51e6a39..efabc7f 100644
+--- a/config/libopts.m4
 b/config/libopts.m4
+@@ -114,7 +114,7 @@ AC_DEFUN([INVOKE_LIBOPTS_MACROS_FIRST],[
+   AC_PROG_SED
+   [while :
+   do
+-  test -x "$POSIX_SHELL" && break
++  test -n "$POSIX_SHELL" && break


The problem is libopts.m4 is auto generated, so it may override
when upgrade autogen-native.

// Robert


+   POSIX_SHELL=`which bash`
+   test -x "$POSIX_SHELL" && break
+   POSIX_SHELL=`which dash`
+--
+2.11.1
+


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

[OE-core] volatile-binds and DNS

[Kristian Amlie]

We've discovered that one of the recent commits to poky has broken DNS
resolution in our image. The commit in questions is this one:

---
commit fcd48092d7bcab0cad2606e65332da62420935ad
Author: Joe Slater 
Date:   Fri Mar 31 03:06:33 2017

volatile-binds: correct some errors reported by systemd

systemd-tmpfiles-setup will fail at boot, so we suppress
the default versions of etc.conf and home.conf.

We also make sure that /var/{cache,spool} and /srv are writeable
if they exist.
...
---

The problem is that this suppresses the creation of a /etc/resolv.conf
file, and without that DNS does not work.

The file is a symlink to the resolv.conf that systemd provides in
/run/systemd/resolve/resolv.conf, so it could potentially be
prepopulated, but I admit I don't fully understand how this fits together.

Any advice?

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

[OE-core] [PATCH] autogen-native: allow user to set POSIX_SHELL as desired

[Awais Belal]

Using 'test -x' is only viable in situations where
POSIX_SHELL is directly set to an executable whereas
there are scenarios where a user might want to set
it to "env sh" so that it can be used in places
where there's a problem with shebang lengths etc. This
is exactly how it is being used in OE so build failures
are seen in cases where deep directory hierarchies are
used for the builddir.
We now use 'test -n' just to make sure if POSIX_SHELL
is set by the user or not and then move forward to
other tests in case it is unset.

Signed-off-by: Awais Belal 
---
 .../autogen/autogen-native_5.18.12.bb  |  1 +
 ...pts-allow-user-to-set-POSIX_SHELL-as-desi.patch | 37 ++
 2 files changed, 38 insertions(+)
 create mode 100644 
meta/recipes-devtools/autogen/autogen/0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch

diff --git a/meta/recipes-devtools/autogen/autogen-native_5.18.12.bb 
b/meta/recipes-devtools/autogen/autogen-native_5.18.12.bb
index 853477cf7c..37571e3358 100644
--- a/meta/recipes-devtools/autogen/autogen-native_5.18.12.bb
+++ b/meta/recipes-devtools/autogen/autogen-native_5.18.12.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"${GNU_MIRROR}/autogen/rel${PV}/autogen-${PV}.tar.gz \
file://fix-script-err-when-processing-libguile.patch \

file://0001-config-libopts.m4-regenerate-it-from-config-libopts..patch \
file://0002-autoopts-mk-tpl-config.sh-fix-perl-path.patch \
+   
file://0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch \
 "
 
 SRC_URI[md5sum] = "551d15ccbf5b5fc5658da375d5003389"
diff --git 
a/meta/recipes-devtools/autogen/autogen/0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch
 
b/meta/recipes-devtools/autogen/autogen/0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch
new file mode 100644
index 00..bfbf6621e1
--- /dev/null
+++ 
b/meta/recipes-devtools/autogen/autogen/0001-config-libopts-allow-user-to-set-POSIX_SHELL-as-desi.patch
@@ -0,0 +1,37 @@
+From dfb30e438a051993c69357c5069170ec779e91e4 Mon Sep 17 00:00:00 2001
+From: Awais Belal 
+Date: Wed, 17 May 2017 15:06:48 +0500
+Subject: [PATCH] config/libopts: allow user to set POSIX_SHELL as desired
+
+Using 'test -x' is only viable in situations where
+POSIX_SHELL is directly set to an executable whereas
+there are scenarios where a user might want to set
+it to "env sh" so that it can be used in places
+where there's a problem with shebang lengths etc.
+We now use 'test -n' just to make sure if POSIX_SHELL
+is set by the user or not and then move forward to
+other tests in case it is unset.
+
+Upstream-Status: Pending
+
+Signed-off-by: Awais Belal 
+---
+ config/libopts.m4 | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/config/libopts.m4 b/config/libopts.m4
+index 51e6a39..efabc7f 100644
+--- a/config/libopts.m4
 b/config/libopts.m4
+@@ -114,7 +114,7 @@ AC_DEFUN([INVOKE_LIBOPTS_MACROS_FIRST],[
+   AC_PROG_SED
+   [while :
+   do
+-  test -x "$POSIX_SHELL" && break
++  test -n "$POSIX_SHELL" && break
+   POSIX_SHELL=`which bash`
+   test -x "$POSIX_SHELL" && break
+   POSIX_SHELL=`which dash`
+-- 
+2.11.1
+
-- 
2.11.1

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