Re: [OE-core] [PATCH] libjpeg-turbo: fix build on aarch64 or non-intel build hosts

[Tristan Van Berkom]

On Thu, 2017-03-30 at 12:21 +0100, Burton, Ross wrote:
> 
> > Agree with Andre here. I would suggest to update nasm recipe to
> > support
> > build for other archs as well (tested on arm and it works as
> > expected. Will
> > require more testing on other archs).
> 
> Yes.  Simply deleting the COMPATIBLE_HOST in nasm.bb should be
> sufficient, Debian builds nasm for every architecture so that
> demonstrates that it builds just fine.
> 

Ok, I had this concern too when originally discussing the approach in
#yocto, this sounds better.

So just to get things straight, does this mean we no longer need the
patch to remove nasm-native from the jpeg turbo dependencies on non-
intel targets ?

I think "-native" here only means "build an nasm that I can run on the
host architecture" then I think this is fine, as jpeg-turbo will just
ignore the needlessly built nasm when targetting non-intel platforms.

Cheers,
    -Tristan

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

Re: [OE-core] [PATCH] libjpeg-turbo: fix build on aarch64 or non-intel build hosts

[Burton, Ross]

On 31 March 2017 at 08:43, Tristan Van Berkom <
tristan.vanber...@codethink.co.uk> wrote:

> So just to get things straight, does this mean we no longer need the
> patch to remove nasm-native from the jpeg turbo dependencies on non-
> intel targets ?
>
> I think "-native" here only means "build an nasm that I can run on the
> host architecture" then I think this is fine, as jpeg-turbo will just
> ignore the needlessly built nasm when targetting non-intel platforms.
>

Both have been merged, as nasm-native is only required on x86 targets so
there's no point building it needlessly.

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

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

[Burton, Ross]

On 30 March 2017 at 20:20, Martin Kelly  wrote:

> I'm trying to integrate the meta-clang version of LLVM 4.0 (used for
> recipes that need a newer LLVM version) alongside the oe-core version of
> LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0 and some to
> use LLVM 3.3 and for them not to collide with each other.
>

Not that presumably you mean meta-oe, not oe-core.

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

[OE-core] [PATCH] openssl: add a "openssl10" PROVIDES

[Alexander Kanavin]

In 2.4 development cycle openssl 1.1 will replace openssl 1.0 as the
default openssl version. Openssl 1.0 will stay but will be renamed
to openssl10, and eventually it will be removed (hopefully much
sooner than the official end of support date of Dec 2019, as we do not
want an unsupported openssl version in supported Yocto releases).

There are several recipes that are not API compatible with 1.1; some
of them will eventually be fixed, but others will never be (such as Qt4).
To avoid breaking such recipes when openssl 1.1 is added to oe-core,
let's provide "openssl10" already now and change the recipes to depend
on that where necessary; Qt4 is a particularly pressing issue as it is
causing failures on the autobuilder with my work in progress
openssl 1.1 branch, and so I'm not able to see what else would fail
later in the build process.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-connectivity/openssl/openssl.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/openssl/openssl.inc 
b/meta/recipes-connectivity/openssl/openssl.inc
index 28421dab338..481a4445605 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -37,6 +37,8 @@ FILES_${PN} =+ " ${libdir}/ssl/*"
 FILES_${PN}-misc = "${libdir}/ssl/misc"
 RDEPENDS_${PN}-misc = "${@bb.utils.filter('PACKAGECONFIG', 'perl', d)}"
 
+PROVIDES += "openssl10"
+
 # Add the openssl.cnf file to the openssl-conf package.  Make the libcrypto
 # package RRECOMMENDS on this package.  This will enable the configuration
 # file to be installed for both the base openssl package and the libcrypto
-- 
2.11.0

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

Re: [OE-core] [PATCH] busybox: drop unmaintained _git recipe

[Burton, Ross]

On 31 March 2017 at 02:57, ChenQi  wrote:

> This git recipe is maintained as far as I know. It was added so that it
> would be easier to hack with busybox. As busybox is broadly used in our
> project, an easier way to hack with it seems reasonable.
>

git log doesn't really agree with you.  It's touched, but occasionally to
sync it with the versioned recipe.

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

Re: [OE-core] [PATCH] glibc: Support building with 2.6.32 kernels on x86 / x86_64

[Serhii Popovych]

> 
>>
>>
>> On 3/28/17 11:57 AM, Serhii Popovych wrote:
>>> While glibc states that 2.6.32 kernels still supported
>>> for x86 / x86_64 builds are failing due to out of date
>>> LIBC_LINUX_VERSION macro checks for such architectures.
>>>
>>> This macro statically defined to 3.2.0 with commit 5b4ecd3
>>> (Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere.)
>>> and additionally checked before --enable-kernel.
>>>
>>> Since both --enable-kernel and LIBC_LINUX_VERSION checks
>>> are the same and there is no users of last one we can
>>> safely get rid of it enabling glibc builds with 2.6.32
>>> kernel headers.
>>>
>>> Also add --enable-kernel to glibc-initial build so that we
>>> build it correctly with old headers.
>>>
>>> Cc: XE-Linux 
>>> Signed-off-by: Serhii Popovych 
>>> ---
>>>  meta/recipes-core/glibc/glibc-initial.inc  |   1 +
>>>  .../glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch | 113 
>>> +
>>>  meta/recipes-core/glibc/glibc_2.25.bb  |   1 +
>>>  3 files changed, 115 insertions(+)
>>>  create mode 100644 
>>> meta/recipes-core/glibc/glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch
>>>
>>> diff --git a/meta/recipes-core/glibc/glibc-initial.inc 
>>> b/meta/recipes-core/glibc/glibc-initial.inc
>>> index f94603c..60b25dd 100644
>>> --- a/meta/recipes-core/glibc/glibc-initial.inc
>>> +++ b/meta/recipes-core/glibc/glibc-initial.inc
>>> @@ -12,6 +12,7 @@ do_configure () {
>>> find ${S} -name "configure" | xargs touch
>>> cfgscript=`python3 -c "import os; print(os.path.relpath('${S}', 
>>> '.'))"`/configure
>>> $cfgscript --host=${TARGET_SYS} --build=${BUILD_SYS} \
>>> +   --enable-kernel=${OLDEST_KERNEL} \
>>> --prefix=/usr \
>>> --without-cvs --disable-sanity-checks \
>>> --with-headers=${STAGING_DIR_TARGET}${includedir} \
>>> diff --git 
>>> a/meta/recipes-core/glibc/glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch 
>>> b/meta/recipes-core/glibc/glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch
>>> new file mode 100644
>>> index 000..f5eaf1c
>>> --- /dev/null
>>> +++ b/meta/recipes-core/glibc/glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch
>>> @@ -0,0 +1,113 @@
>>> +From 88f83e4b5a8929dac9095ed264700fcb62d5e4dd Mon Sep 17 00:00:00 2001
>>> +From: Serhii Popovych 
>>> +Date: Fri, 17 Mar 2017 15:48:34 +
>>> +Subject: Kill LIBC_LINUX_VERSION macro
>>> +
>>> +After commit 5b4ecd3 (Require Linux 3.2 except on x86 / x86_64,
>>> +3.2 headers everywhere.) minimal kernel version raised from
>>> +2.6.32 to 3.2.0 for all architectures except x86 and x86_64
>>> +unless newer already used for architecture.
>>> +
>>> +However LIBC_LINUX_VERSION macro still is in effect and fails
>>> +configure even with --enable-kernel=2.6.32.
>>> +
>>> +While it is present in configure.ac it does not affect anything
>>> +except LINUX_VERSION_CODE check which already performed by
>>> +--enable-kernel.
>>> +
>>
>> --enable-kernel is forces the minimum kernel for glibc to configure for
>> kernel interfaces if not set it defaults to arch specific value but it
>> wont check for version of linux headers during compile time. Whereas
>> this check is checking and errors out during build time if minimum
>> kernel version is not met.
> 
> But why in configure.ac
> define([LIBC_LINUX_VERSION],[3.2.0])
> sets to version 3.2.0?
> 
> and then AC_TRY_COMPILE() sets libc_cv_linuxVER='missing or too old!'
> causing configure to fail due to missing kheaders >= 3.2.0, not 2.6.32.
> 
> Later in configure.ac I see minimum_kernel being checked with
> AC_TRY_COMPILE() and same code as for LIBC_LINUX_VERSION.
> 
> So we check for 3.2.0 and then check for minimum_kernel (--enable-
> kernel) 2.6.32 after this?

By looking at commit 5b4ecd3 (Require Linux 3.2 except on x86 / x86_64,
3.2 headers everywhere.) contents closer I found answer for this
question.

In NEWS file we have:

+  unchanged).  Linux 3.2 or later kernel headers are required on all
+  architectures.

For me that means we should use kernel headers from 3.2 to build glibc,
but for x86 / x86_64 we still may force minimum supported kernel version
of 2.6.32 with --enable-kernel.

I will submit v2 without patch to remove LIBC_LINUX_VERSION check (i.e.
just add --enable-kernel=${OLDEST_KERNEL}.

Thanks,
Serhii

> 
> 
>> If you were to make the LIBC_LINUX_VERSION
>> have a value that matches the arch_minimum_kernel version that would be
>> an improvement.
> 
> configure.ac (and thus configure) is only place where
> LIBC_LINUX_VERSION is used, so I decided to remove it as remnant from
> pre --enable-kernel option ages.
> 
>>
>> As such if you want to do quick fix then lower the value of
>> LIBC_LINUX_VERSION to 2.6.32 when building for x86/x86_64, we can accept
>> such a patch with a bit less happiness.
> 
> I do not want to get quick fix. I want to find way to fix it right.
> 
> Thanks.
> 
>>
>>
>>> +Upstream-Status: Pending
>>> +Signed-off-by: Serhii Popovych 
>>> +---
>>> + sysdeps/unix/s

Re: [OE-core] [PATCH] ca-certificates: Fix symlinks to the certificates in nativesdk

[Serhii Popovych]

> 
> On Thu, Mar 30, 2017 at 11:30 AM, Serhii Popovych  > wrote:
> 
> >
> > On 29 March 2017 at 13:51, Serhii Popovych  
> > >> wrote:
> >
> > That's great. What the subject of this change in openembedded-core?
> > I wish to test it.
> >
> > Because with current *master* I see problem is still here.
> >
> >
> > "sysroot-relativelinks: also consider links to dirs on the host"
> > oe-core c5b522378fff13962a5187d9d09979866f805cb5, now in master.
> 
> Tested, works for SDK, but does not work for buildtools-tarball
> (e.g. bitbake buildtools-tarball).
> 
> 
> Ah, that makes sense, sysroot-relativelinks being run is handled by
> image.bbclass at this time, which wouldn’t be inherited for that recipe.
> Perhaps add this to the recipe:
> 
> POPULATE_SDK_POST_TARGET_COMMAND += “rootfs_sysroot_relativelinks;"
Still no luck.

Added inherit rootfs-postcommands, which provides
rootfs_sysroot_relativelinks, and command you mentioned above to
buildtools-tarball recipe.


> -- 
> 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] busybox: make SYSLOGD optionnal

[Romain Perier]

Some distros might choose another syslogd provider like rsyslogd.
update-alternative will update the link from syslogd to the right
provider. However the syslogd feature is still present and enabled
in busybox.

This commit adds a new configuration fragment to make syslogd
optionnal in busybox.

Signed-off-by: Romain Perier 
---
 meta/recipes-core/busybox/busybox.inc|  6 +++---
 meta/recipes-core/busybox/busybox/defconfig  | 20 +---
 meta/recipes-core/busybox/busybox/syslog.cfg | 11 +++
 meta/recipes-core/busybox/busybox_1.24.1.bb  |  1 +
 meta/recipes-core/busybox/busybox_git.bb |  1 +
 5 files changed, 25 insertions(+), 14 deletions(-)
 create mode 100644 meta/recipes-core/busybox/busybox/syslog.cfg

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index b2f1960..a60b7a9 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -40,7 +40,7 @@ INITSCRIPT_NAME_${PN}-syslog = "syslog"
 INITSCRIPT_NAME_${PN}-udhcpd = "busybox-udhcpd"
 
 SYSTEMD_PACKAGES = "${PN}-syslog"
-SYSTEMD_SERVICE_${PN}-syslog = "busybox-syslog.service"
+SYSTEMD_SERVICE_${PN}-syslog = "${@bb.utils.contains('SRC_URI', 
'file://syslog.cfg', 'busybox-syslog.service', '', d)}"
 
 CONFFILES_${PN}-syslog = "${sysconfdir}/syslog-startup.conf.${BPN}"
 CONFFILES_${PN}-mdev = "${sysconfdir}/mdev.conf"
@@ -326,8 +326,8 @@ inherit update-alternatives
 
 ALTERNATIVE_PRIORITY = "50"
 
-ALTERNATIVE_${PN}-syslog += "syslog-conf"
-ALTERNATIVE_LINK_NAME[syslog-conf] = "${sysconfdir}/syslog.conf"
+ALTERNATIVE_${PN}-syslog += "${@bb.utils.contains('SRC_URI', 
'file://syslog.cfg', 'syslog-conf', '', d)}"
+ALTERNATIVE_LINK_NAME[syslog-conf] = "${@bb.utils.contains('SRC_URI', 
'file://syslog.cfg', "${sysconfdir}/syslog.conf", '', d)}"
 
 python () {
 if bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
diff --git a/meta/recipes-core/busybox/busybox/defconfig 
b/meta/recipes-core/busybox/busybox/defconfig
index c0459d5..387dcc0 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -1049,17 +1049,15 @@ CONFIG_FEATURE_SH_HISTFILESIZE=y
 #
 # System Logging Utilities
 #
-CONFIG_SYSLOGD=y
-CONFIG_FEATURE_ROTATE_LOGFILE=y
-CONFIG_FEATURE_REMOTE_LOG=y
-CONFIG_FEATURE_SYSLOGD_DUP=y
-CONFIG_FEATURE_SYSLOGD_CFG=y
-CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256
-CONFIG_FEATURE_IPC_SYSLOG=y
-CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=64
-CONFIG_LOGREAD=y
-CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
-CONFIG_FEATURE_KMSG_SYSLOG=y
+# CONFIG_SYSLOGD is not set
+# CONFIG_FEATURE_ROTATE_LOGFILE is not set
+# CONFIG_FEATURE_REMOTE_LOG is not set
+# CONFIG_FEATURE_SYSLOGD_DUP is not set
+# CONFIG_FEATURE_SYSLOGD_CFG is not set
+# CONFIG_FEATURE_IPC_SYSLOG is not set
+# CONFIG_LOGREAD is not set
+# CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING is not set
+# CONFIG_FEATURE_KMSG_SYSLOG is not set
 CONFIG_KLOGD=y
 
 #
diff --git a/meta/recipes-core/busybox/busybox/syslog.cfg 
b/meta/recipes-core/busybox/busybox/syslog.cfg
new file mode 100644
index 000..e2425ed
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/syslog.cfg
@@ -0,0 +1,11 @@
+CONFIG_SYSLOGD=y
+CONFIG_FEATURE_ROTATE_LOGFILE=y
+CONFIG_FEATURE_REMOTE_LOG=y
+CONFIG_FEATURE_SYSLOGD_DUP=y
+CONFIG_FEATURE_SYSLOGD_CFG=y
+CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256
+CONFIG_FEATURE_IPC_SYSLOG=y
+CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=64
+CONFIG_LOGREAD=y
+CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
+CONFIG_FEATURE_KMSG_SYSLOG=y
diff --git a/meta/recipes-core/busybox/busybox_1.24.1.bb 
b/meta/recipes-core/busybox/busybox_1.24.1.bb
index df0e131..1b8a1a3 100644
--- a/meta/recipes-core/busybox/busybox_1.24.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.24.1.bb
@@ -40,6 +40,7 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://resize.cfg \
${@["", 
"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager', True) == 
'busybox')]} \
${@["", "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager', 
True) == 'busybox-mdev')]} \
+   file://syslog.cfg \
file://inittab \
file://rcS \
file://rcK \
diff --git a/meta/recipes-core/busybox/busybox_git.bb 
b/meta/recipes-core/busybox/busybox_git.bb
index c29b894..f666517 100644
--- a/meta/recipes-core/busybox/busybox_git.bb
+++ b/meta/recipes-core/busybox/busybox_git.bb
@@ -42,6 +42,7 @@ SRC_URI = "git://busybox.net/busybox.git \
file://resize.cfg \
${@["", 
"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager', True) == 
'busybox')]} \
${@["", "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager', 
True) == 'busybox-mdev')]} \
+   file://syslog.cfg \
file://inittab \
file://rcS \
file://rcK \
-- 
1.8.3.1

-- 
___
Openembedded-core mailing list
Openembedded-core@

[OE-core] [PATCH v4 1/2] autoconf: Adjust shebang lines to remove interpreter path hardcode

[Serhii Popovych]

If build host perl (and other tools) is old and we use some kind
of toolchain to provide recent perl/python/etc to the OE build
we still locked to use build host perl due to hardcoded shebang
lines in autoconf scripts.

Behaviour was observed with Enterprise Linux 6 and devtoolset
toolchain from SCL (Software Collections) used to provide recent
version of perl (not provided with default buildtools-tarball).

Pass /usr/bin/env perl in ac_cv_path_PERL configuration variables
for class-native and class-nativesdk. Use patch to autoconf to replace
-w option in shebang line with modern way to enable warnings on perl
(i.e. "use warnings").

Also add nativesdk-m4 and nativesdk-gnu-config to RDEPENDS to bring
runtime dependencies inline with other targets.

Note that ac_cv_path_PERL must be valid perl interpreter path
since configure will check perl version and Flock implementation.
It is not possible currently to use nativeperl from native
sysroot because autoconf does not DEPENDS on perl-native (and
doing so fails due to circular dependencies). Only possible
solution is to overwrite shebangs with nativeperl somewhere at
do_install() and update RDEPENDS for class-native. Or add perl
symlinks to nativeperl in sysroot.

For now it seems good to use perl found by /usr/bin/env from
autoconf-native.

Cc: XE-Linux 
Signed-off-by: Serhii Popovych 
---
v4: Address typo, and remnants of nativesdk-perl in RDEPENDS
left from internal imlementation part.
Thanks to Richard Purdie 
v3: Corrected Upstream-Status tag.
v2: Just realized that files in quilt directory (.pc) patched
unnecessarily.

 meta/recipes-devtools/autoconf/autoconf.inc|   7 +-
 ...tion-in-shebangs-with-modern-use-warnings.patch | 120 +
 meta/recipes-devtools/autoconf/autoconf_2.69.bb|   1 +
 3 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch

diff --git a/meta/recipes-devtools/autoconf/autoconf.inc 
b/meta/recipes-devtools/autoconf/autoconf.inc
index b4e3356..f1b2dfc 100644
--- a/meta/recipes-devtools/autoconf/autoconf.inc
+++ b/meta/recipes-devtools/autoconf/autoconf.inc
@@ -27,13 +27,18 @@ RDEPENDS_${PN} = "m4 gnu-config \
  perl-module-data-dumper \
 "
 RDEPENDS_${PN}_class-native = "m4-native gnu-config-native"
+RDEPENDS_${PN}_class-nativesdk = "nativesdk-m4 nativesdk-gnu-config"
 
 SRC_URI = "${GNU_MIRROR}/autoconf/autoconf-${PV}.tar.gz \
   file://program_prefix.patch"
 
 inherit autotools texinfo
 
-CACHED_CONFIGUREVARS += "ac_cv_path_PERL=${USRBINPATH}/perl"
+PERL = "${USRBINPATH}/perl"
+PERL_class-native = "/usr/bin/env perl"
+PERL_class-nativesdk = "/usr/bin/env perl"
+
+CACHED_CONFIGUREVARS += "ac_cv_path_PERL='${PERL}'"
 
 do_configure() {
oe_runconf
diff --git 
a/meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch
 
b/meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch
new file mode 100644
index 000..ae0e382
--- /dev/null
+++ 
b/meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch
@@ -0,0 +1,120 @@
+From 236552ff5b9f1ebf666d8d0e9850007dcce03d26 Mon Sep 17 00:00:00 2001
+From: Serhii Popovych 
+Date: Wed, 10 Feb 2016 16:32:44 +
+Subject: [PATCH] perl: Replace -w option in shebangs with modern "use
+ warnings"
+
+In some builds we might provide ac_cv_path_PERL as /usr/bin/env perl
+to use newer version of the perl from users PATH rather than
+older from standard system path.
+
+However using /usr/bin/env perl -w from shebang line isn't
+possible because it translates to something like
+/usr/bin/env -w perl and env complains about illegal option.
+
+To address this we can remove -w option from perl shebang
+line and add "use warnings" statement.
+
+Upstream-Status: Pending
+Signed-off-by: Serhii Popovych 
+---
+ bin/autom4te.in  | 3 ++-
+ bin/autoreconf.in| 3 ++-
+ bin/autoscan.in  | 3 ++-
+ bin/autoupdate.in| 3 ++-
+ bin/ifnames.in   | 3 ++-
+ 5 files changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/bin/autom4te.in b/bin/autom4te.in
+index 11773c9..a8f5e41 100644
+--- a/bin/autom4te.in
 b/bin/autom4te.in
+@@ -1,4 +1,4 @@
+-#! @PERL@ -w
++#! @PERL@
+ # -*- perl -*-
+ # @configure_input@
+ 
+@@ -42,6 +42,7 @@ use Autom4te::General;
+ use Autom4te::XFile;
+ use File::Basename;
+ use strict;
++use warnings;
+ 
+ # Data directory.
+ my $pkgdatadir = $ENV{'AC_MACRODIR'} || '@pkgdatadir@';
+diff --git a/bin/autoreconf.in b/bin/autoreconf.in
+index e245db4..1a318cb 100644
+--- a/bin/autoreconf.in
 b/bin/autoreconf.in
+@@ -1,4 +1,4 @@
+-#! @PERL@ -w
++#!

[OE-core] [PATCH v3 2/2] automake: Adjust shebang lines to remove interpreter path hardcode

[Serhii Popovych]

If build host perl (and other tools) is old and we use some kind
of toolchain to provide recent perl/python/etc to the OE build
we still locked to use build host perl due to hardcoded shebang
lines in automake scripts.

Behaviour was observed with Enterprise Linux 6 and devtoolset
toolchain from SCL (Software Collections) used to provide recent
version of perl (not provided with default buildtools-tarball).

Pass /usr/bin/env perl in ac_cv_path_PERL configuration variables
for class-native and class-nativesdk. Use patch to automake to replace
-w option in shebang line with modern way to enable warnings on perl
(i.e. "use warnings").

Also add nativesdk-autoconf to RDEPENDS to bring runtime dependencies
inline with other targets.

Note that ac_cv_path_PERL must be valid perl interpreter path
since configure will check perl version and Flock implementation.
It is not possible currently to use nativeperl from native
sysroot because automake does not DEPENDS on perl-native (and
doing so fails due to circular dependencies). Only possible
solution is to overwrite shebangs with nativeperl somewhere at
do_install() and update RDEPENDS for class-native. Or add perl
symlinks to nativeperl in sysroot.

For now it seems good to use perl found by /usr/bin/env from
automake-native.

Cc: XE-Linux 
Signed-off-by: Serhii Popovych 
---
v3: Kill remnants of nativesdk-perl in RDEPENDS left from internal
imlementation part.
Thanks to Richard Purdie 
v2: Corrected Upstream-Status tag.

 ...tion-in-shebangs-with-modern-use-warnings.patch | 99 ++
 meta/recipes-devtools/automake/automake_1.15.bb| 13 ++-
 2 files changed, 109 insertions(+), 3 deletions(-)
 create mode 100644 
meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch

diff --git 
a/meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch
 
b/meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch
new file mode 100644
index 000..64eb253
--- /dev/null
+++ 
b/meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch
@@ -0,0 +1,99 @@
+From 41e06b7a354774913dcd2e32a35440e407843357 Mon Sep 17 00:00:00 2001
+From: Serhii Popovych 
+Date: Wed, 10 Feb 2016 17:07:32 +
+Subject: [PATCH] perl: Replace -w option in shebangs with modern "use
+ warnings" In some builds we might provide ac_cv_path_PERL as /usr/bin/env
+ perl to use newer version of the perl from users PATH rather than older from
+ standard system path.
+
+However using /usr/bin/env perl -w from shebang line isn't
+possible because it translates to something like
+/usr/bin/env -w perl and env complains about illegal option.
+
+To address this we can remove -w option from perl shebang
+line and add "use warnings" statement.
+
+Upstream-Status: Pending
+Signed-off-by: Serhii Popovych 
+---
+ bin/aclocal.in | 3 ++-
+ bin/automake.in| 3 ++-
+ t/wrap/aclocal.in  | 3 ++-
+ t/wrap/automake.in | 3 ++-
+ 4 files changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/bin/aclocal.in b/bin/aclocal.in
+index 349f24a..50cb8d3 100644
+--- a/bin/aclocal.in
 b/bin/aclocal.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!@PERL@
+ # -*- perl -*-
+ # @configure_input@
+ 
+@@ -33,6 +33,7 @@ BEGIN
+ }
+ 
+ use strict;
++use warnings;
+ 
+ use Automake::Config;
+ use Automake::General;
+diff --git a/bin/automake.in b/bin/automake.in
+index eedc8bc..e0a01cf 100644
+--- a/bin/automake.in
 b/bin/automake.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!@PERL@
+ # -*- perl -*-
+ # @configure_input@
+ 
+@@ -28,6 +28,7 @@ eval 'case $# in 0) exec @PERL@ -S "$0";; *) exec @PERL@ -S 
"$0" "$@";; esac'
+ package Automake;
+ 
+ use strict;
++use warnings;
+ 
+ BEGIN
+ {
+diff --git a/t/wrap/aclocal.in b/t/wrap/aclocal.in
+index e64b546..9996899 100644
+--- a/t/wrap/aclocal.in
 b/t/wrap/aclocal.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!@PERL@
+ # @configure_input@
+ 
+ # Copyright (C) 2012-2014 Free Software Foundation, Inc.
+@@ -19,6 +19,7 @@
+ BEGIN
+ {
+   use strict;
++  use warnings;
+   @Aclocal::perl_libdirs = ('@abs_top_srcdir@/lib');
+   unshift @Aclocal::perl_libdirs, '@abs_top_builddir@/lib'
+ if '@srcdir@' ne '.';
+diff --git a/t/wrap/automake.in b/t/wrap/automake.in
+index 8b943b1..be61226 100644
+--- a/t/wrap/automake.in
 b/t/wrap/automake.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!@PERL@
+ # @configure_input@
+ 
+ # Copyright (C) 2012-2014 Free Software Foundation, Inc.
+@@ -19,6 +19,7 @@
+ BEGIN
+ {
+   use strict;
++  use warnings;
+   @Automake::perl_libdirs = ('@abs_top_srcdir@/lib');
+   unshift @Automake::perl_libdirs, '@abs_top_builddir@/lib'
+ if '@srcdir@' ne '.';
+-- 
+2.3.0
+
diff --git a/meta/recipes-devtools/automake/automake_1.15.bb 
b/meta/recipes-devtools/automake/automake_1.15.bb
index a3c72fd..a6904c8 100644
--- a/meta/recipes-devtools/automake/automake_1.15.bb
+++ b/meta

[OE-core] [PATCH v3 0/2] automake/autoconf: avoid path to perl interpreter hardcoding

[Serhii Popovych]

Hi,

This is updated series of changes to autoconf/automake
where I address all questions from previous review session.

Please review again.

Thanks.

Cc: XE-Linux 
Serhii Popovych (2):
  autoconf: Adjust shebang lines to remove interpreter path hardcode
  automake: Adjust shebang lines to remove interpreter path hardcode

 meta/recipes-devtools/autoconf/autoconf.inc|   7 +-
 ...tion-in-shebangs-with-modern-use-warnings.patch | 120 +
 meta/recipes-devtools/autoconf/autoconf_2.69.bb|   1 +
 ...tion-in-shebangs-with-modern-use-warnings.patch |  99 +
 meta/recipes-devtools/automake/automake_1.15.bb|  13 ++-
 5 files changed, 236 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch
 create mode 100644 
meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch

-- 
2.5.0

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

Re: [OE-core] [PATCH] u-boot: Update to 2017.03 release

[Burton, Ross]

On 30 March 2017 at 19:06, Denys Dmytriyenko  wrote:

> "Known devil is better than unknown angel"? :)
>

Agreed, fwiw.  It's late and u-boot is quite important: cherry-pick the
patch for Pyro and master can upgrade once it has branched.

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

Re: [OE-core] [PATCH] systemd: check 'efi' in MACHINE_FEATURES

[Mikko Ylinen]

On 30/03/17 19:15, Burton, Ross wrote:


On 30 March 2017 at 07:59, Mikko Ylinen > wrote:


I'm fine. Perhaps 'efi' should not be a PACKAGECONFIG at all (and
unconditionally disabled here) and
the functionality (just bootctl?) is moved in systemd-boot. Thoughts?


I'm not fully aware of the details here but this seems like a good 
idea.  Can you prepare a patch?




Looks like it's not very easy to build bootctl part of systemd-boot 
(without re-building the whole

systemd there too).

Therefore, I'd just:

-   ${@bb.utils.filter('DISTRO_FEATURES', 'efi pam 
selinux ldconfig', d)} \
+   ${@bb.utils.filter('DISTRO_FEATURES', 'pam selinux 
ldconfig', d)} \


and perhaps:

-PACKAGECONFIG[efi] = "--enable-efi,--disable-efi"
+PACKAGECONFIG[bootctl] = "--enable-efi,--disable-efi"

efi/bootctl can then be added in PACKAGECONFIG by those who need bootctl.

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

[OE-core] ✗ patchtest: failure for "[v3,1/2] autoconf: Adjust sheb..." and 1 more (rev2)

[Patchwork]

== Series Details ==

Series: "[v3,1/2] autoconf: Adjust sheb..." and 1 more (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/6033/
State : failure

== Summary ==


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



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



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

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for busybox: make SYSLOGD optionnal

[Patchwork]

== Series Details ==

Series: busybox: make SYSLOGD optionnal
Revision: 1
URL   : https://patchwork.openembedded.org/series/6101/
State : failure

== Summary ==


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



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



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

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH morty v2] wic: partition: Run fsck on EXT file systems

[Daniel Schultz]

Mkfs may create EXT file systems which can only be optimized by fsck
and not by itself, e.g. directory optimization (in Pass 3A).

To prevent those optimizations during runtime, it will be performed after
the creation of an EXT file system.

Signed-off-by: Daniel Schultz 
---
 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3b3bd2d..152eb7b 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -239,6 +239,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
+mkfs_cmd = "fsck.%s -pvfD %s" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """
-- 
1.9.1

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

Re: [OE-core] [PATCH] openssl: add a "openssl10" PROVIDES

[akuster808]

Alexander,


On 03/31/2017 02:31 AM, Alexander Kanavin wrote:

In 2.4 development cycle openssl 1.1 will replace openssl 1.0 as the
default openssl version. Openssl 1.0 will stay but will be renamed
to openssl10, and eventually it will be removed (hopefully much
sooner than the official end of support date of Dec 2019, as we do not
want an unsupported openssl version in supported Yocto releases).

Sounds like a plan.


There are several recipes that are not API compatible with 1.1; some
of them will eventually be fixed, but others will never be (such as Qt4).
To avoid breaking such recipes when openssl 1.1 is added to oe-core,
let's provide "openssl10" already now and change the recipes to depend
on that where necessary; Qt4 is a particularly pressing issue as it is
causing failures on the autobuilder with my work in progress
openssl 1.1 branch, and so I'm not able to see what else would fail
later in the build process.

nice writeup.

- armin



Signed-off-by: Alexander Kanavin 
---
  meta/recipes-connectivity/openssl/openssl.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/openssl/openssl.inc 
b/meta/recipes-connectivity/openssl/openssl.inc
index 28421dab338..481a4445605 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -37,6 +37,8 @@ FILES_${PN} =+ " ${libdir}/ssl/*"
  FILES_${PN}-misc = "${libdir}/ssl/misc"
  RDEPENDS_${PN}-misc = "${@bb.utils.filter('PACKAGECONFIG', 'perl', d)}"
  
+PROVIDES += "openssl10"

+
  # Add the openssl.cnf file to the openssl-conf package.  Make the libcrypto
  # package RRECOMMENDS on this package.  This will enable the configuration
  # file to be installed for both the base openssl package and the libcrypto


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

[OE-core] [PATCH 2/2] scripts/contrib: add oe-build-perf-report-email

[Markus Lehtonen]

Script for sending build perf test reports as an email. Mangles an html
report, generated by oe-build-perf-report, into a format suitable for
html emails. Supports multipart emails where a plaintext alternative can
be included in the same email.

Dependencies required to be installed on the host:
- phantomjs
- optipng

[YOCTO #10931]

Signed-off-by: Markus Lehtonen 
---
 scripts/contrib/oe-build-perf-report-email.py | 266 ++
 scripts/lib/build_perf/scrape-html-report.js  |  56 ++
 2 files changed, 322 insertions(+)
 create mode 100755 scripts/contrib/oe-build-perf-report-email.py
 create mode 100644 scripts/lib/build_perf/scrape-html-report.js

diff --git a/scripts/contrib/oe-build-perf-report-email.py 
b/scripts/contrib/oe-build-perf-report-email.py
new file mode 100755
index 000..7f4274e
--- /dev/null
+++ b/scripts/contrib/oe-build-perf-report-email.py
@@ -0,0 +1,266 @@
+#!/usr/bin/python3
+#
+# Send build performance test report emails
+#
+# Copyright (c) 2017, Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+# more details.
+#
+import argparse
+import base64
+import logging
+import os
+import pwd
+import re
+import shutil
+import smtplib
+import subprocess
+import sys
+import tempfile
+from email.mime.multipart import MIMEMultipart
+from email.mime.text import MIMEText
+
+
+# Setup logging
+logging.basicConfig(level=logging.INFO, format="%(levelname)s: %(message)s")
+log = logging.getLogger('oe-build-perf-report')
+
+
+# Find js scaper script
+SCRAPE_JS = os.path.join(os.path.dirname(__file__), '..', 'lib', 'build_perf',
+ 'scrape-html-report.js')
+if not os.path.isfile(SCRAPE_JS):
+log.error("Unableto find oe-build-perf-report-scrape.js")
+sys.exit(1)
+
+
+class ReportError(Exception):
+"""Local errors"""
+pass
+
+
+def check_utils():
+"""Check that all needed utils are installed in the system"""
+missing = []
+for cmd in ('phantomjs', 'optipng'):
+if not shutil.which(cmd):
+missing.append(cmd)
+if missing:
+log.error("The following tools are missing: %s", ' '.join(missing))
+sys.exit(1)
+
+
+def parse_args(argv):
+"""Parse command line arguments"""
+description = """Email build perf test report"""
+parser = argparse.ArgumentParser(
+formatter_class=argparse.ArgumentDefaultsHelpFormatter,
+description=description)
+
+parser.add_argument('--debug', '-d', action='store_true',
+help="Verbose logging")
+parser.add_argument('--quiet', '-q', action='store_true',
+help="Only print errors")
+parser.add_argument('--to', action='append',
+help="Recipients of the email")
+parser.add_argument('--subject', default="Yocto build perf test report",
+help="Email subject")
+parser.add_argument('--outdir', '-o',
+help="Store files in OUTDIR. Can be used to preserve "
+ "the email parts")
+parser.add_argument('--text',
+help="Plain text message")
+parser.add_argument('--html',
+help="HTML peport generated by oe-build-perf-report")
+parser.add_argument('--phantomjs-args', action='append',
+help="Extra command line arguments passed to 
PhantomJS")
+
+args = parser.parse_args(argv)
+
+if not args.html and not args.text:
+parser.error("Please specify --html and/or --text")
+
+return args
+
+
+def decode_png(infile, outfile):
+"""Parse/decode/optimize png data from a html element"""
+with open(infile) as f:
+raw_data = f.read()
+
+# Grab raw base64 data
+b64_data = re.sub('^.*href="data:image/png;base64,', '', raw_data, 1)
+b64_data = re.sub('">.+$', '', b64_data, 1)
+
+# Replace file with proper decoded png
+with open(outfile, 'wb') as f:
+f.write(base64.b64decode(b64_data))
+
+subprocess.check_output(['optipng', outfile], stderr=subprocess.STDOUT)
+
+
+def encode_png(pngfile):
+"""Encode png into a  html element"""
+with open(pngfile, 'rb') as f:
+data = f.read()
+
+b64_data = base64.b64encode(data)
+return '\n'
+
+
+def mangle_html_report(infile, outfile, pngs):
+"""Mangle html file into a email compatible format"""
+paste = True
+png_dir = os.path.dirname(outfile)
+with open(infile) as f_in:
+with open(outfile, 'w') as f_out:
+for line in f_in.readlines():
+stripped = line.strip()
+ 

[OE-core] [PATCH 0/2] Tools for visualizing build performance test results

[Markus Lehtonen]

This patchset implements two new scripts for analyzing and reporting build
performance test results. The first script is a tool that is able to generate
test reports from build perf test data stored in a Git repository. Both
plain text and html output formats are supported. The second script is a helper
for converting these (HTML) reports into a format suitable for emails and
sending them.


The following changes since commit 49772e1a1f291d1cacce27b381009dbb441c483e:

  distutils3.bbclass: Fix path to python for scripts (2017-03-31 10:09:58 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib marquiz/buildperf/scripts
  
http://git.openembedded.org/openembedded-core-contrib/log/?h=marquiz/buildperf/scripts



Markus Lehtonen (2):
  scripts: add oe-build-perf-report script
  scripts/contrib: add oe-build-perf-report-email

 scripts/contrib/oe-build-perf-report-email.py  | 266 +++
 scripts/lib/build_perf/__init__.py |  31 ++
 scripts/lib/build_perf/html.py |  19 +
 scripts/lib/build_perf/html/measurement_chart.html |  50 ++
 scripts/lib/build_perf/html/report.html| 209 
 scripts/lib/build_perf/report.py   | 342 +
 scripts/lib/build_perf/scrape-html-report.js   |  56 +++
 scripts/oe-build-perf-report   | 531 +
 8 files changed, 1504 insertions(+)
 create mode 100755 scripts/contrib/oe-build-perf-report-email.py
 create mode 100644 scripts/lib/build_perf/__init__.py
 create mode 100644 scripts/lib/build_perf/html.py
 create mode 100644 scripts/lib/build_perf/html/measurement_chart.html
 create mode 100644 scripts/lib/build_perf/html/report.html
 create mode 100644 scripts/lib/build_perf/report.py
 create mode 100644 scripts/lib/build_perf/scrape-html-report.js
 create mode 100755 scripts/oe-build-perf-report

-- 
2.10.2

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

[OE-core] [PATCH 1/2] scripts: add oe-build-perf-report script

[Markus Lehtonen]

A new tool for pretty-printing build perf test results stored in a Git
repository. The scripts is able to produce either simple plaintext
report showing the difference between two commits, or, an html report
that also displays trendcharts of the test results. The script uses
Jinja2 templates for generating HTML reports so it requires
python3-jinja2 to be installed on the system.

[YOCTO #10931]

Signed-off-by: Markus Lehtonen 
---
 scripts/lib/build_perf/__init__.py |  31 ++
 scripts/lib/build_perf/html.py |  19 +
 scripts/lib/build_perf/html/measurement_chart.html |  50 ++
 scripts/lib/build_perf/html/report.html| 209 
 scripts/lib/build_perf/report.py   | 342 +
 scripts/oe-build-perf-report   | 531 +
 6 files changed, 1182 insertions(+)
 create mode 100644 scripts/lib/build_perf/__init__.py
 create mode 100644 scripts/lib/build_perf/html.py
 create mode 100644 scripts/lib/build_perf/html/measurement_chart.html
 create mode 100644 scripts/lib/build_perf/html/report.html
 create mode 100644 scripts/lib/build_perf/report.py
 create mode 100755 scripts/oe-build-perf-report

diff --git a/scripts/lib/build_perf/__init__.py 
b/scripts/lib/build_perf/__init__.py
new file mode 100644
index 000..1f8b729
--- /dev/null
+++ b/scripts/lib/build_perf/__init__.py
@@ -0,0 +1,31 @@
+#
+# Copyright (c) 2017, Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+# more details.
+#
+"""Build performance test library functions"""
+
+def print_table(rows, row_fmt=None):
+"""Print data table"""
+if not rows:
+return
+if not row_fmt:
+row_fmt = ['{:{wid}} '] * len(rows[0])
+
+# Go through the data to get maximum cell widths
+num_cols = len(row_fmt)
+col_widths = [0] * num_cols
+for row in rows:
+for i, val in enumerate(row):
+col_widths[i] = max(col_widths[i], len(str(val)))
+
+for row in rows:
+print(*[row_fmt[i].format(col, wid=col_widths[i]) for i, col in 
enumerate(row)])
+
diff --git a/scripts/lib/build_perf/html.py b/scripts/lib/build_perf/html.py
new file mode 100644
index 000..578bb16
--- /dev/null
+++ b/scripts/lib/build_perf/html.py
@@ -0,0 +1,19 @@
+#
+# Copyright (c) 2017, Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+# more details.
+#
+"""Helper module for HTML reporting"""
+from jinja2 import Environment, PackageLoader
+
+
+env = Environment(loader=PackageLoader('build_perf', 'html'))
+
+template = env.get_template('report.html')
diff --git a/scripts/lib/build_perf/html/measurement_chart.html 
b/scripts/lib/build_perf/html/measurement_chart.html
new file mode 100644
index 000..26fe145
--- /dev/null
+++ b/scripts/lib/build_perf/html/measurement_chart.html
@@ -0,0 +1,50 @@
+
+  google.charts.setOnLoadCallback(drawChart_{{ chart_elem_id }});
+  function drawChart_{{ chart_elem_id }}() {
+var data = new google.visualization.DataTable();
+
+// Chart options
+var options = {
+  theme : 'material',
+  legend: 'none',
+  hAxis: { format: '', title: 'Commit number',
+   minValue: {{ chart_opts.haxis.min }},
+   maxValue: {{ chart_opts.haxis.max }} },
+  {% if measurement.type == 'time' %}
+  vAxis: { format: 'h:mm:ss' },
+  {% else %}
+  vAxis: { format: '' },
+  {% endif %}
+  pointSize: 5,
+  chartArea: { left: 80, right: 15 },
+};
+
+// Define data columns
+data.addColumn('number', 'Commit');
+data.addColumn('{{ measurement.value_type.gv_data_type }}',
+   '{{ measurement.value_type.quantity }}');
+// Add data rows
+data.addRows([
+  {% for sample in measurement.samples %}
+[{{ sample.commit_num }}, {{ sample.mean.gv_value() }}],
+  {% endfor %}
+]);
+
+// Finally, draw the chart
+chart_div = document.getElementById('{{ chart_elem_id }}');
+var chart = new google.visualization.LineChart(chart_div);
+google.visualization.events.addListener(chart, 'ready', function () {
+  //chart_div = document.getElementById('{{ chart_elem_id }}');
+  //chart_div.innerHTML = '

[OE-core] [PATCH] dpkg: Add PACKAGECONFIG for liblzma and enable it

[Richard Purdie]

liblzma is part of xz and we already build it but configure it out. This makes
no sense. Enabling it means we gain multithreaded compression and it speeds
dpkg-deb up massively. It also removes the fork overhead of separate xz 
processes.

Turning the existing config into a PACKAGECONFIG and turning it on by default
therefore makes best use of what we have available.

The manual RDEPENDS are no longer needed since it uses liblzma which is picked
up by the shlibs code magically.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/dpkg/dpkg.inc | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/dpkg/dpkg.inc 
b/meta/recipes-devtools/dpkg/dpkg.inc
index 6abe3ae..870117a 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -4,8 +4,8 @@ SECTION = "base"
 
 DEPENDS = "zlib bzip2 perl ncurses"
 DEPENDS_class-native = "bzip2-replacement-native zlib-native 
virtual/update-alternatives-native gettext-native perl-native"
-RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} xz perl"
-RDEPENDS_${PN}_class-native = "xz-native"
+RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} perl"
+RDEPENDS_${PN}_class-native = ""
 
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/dpkg/"
 
@@ -28,10 +28,12 @@ EXTRA_OECONF = "\
--enable-start-stop-daemon \
--with-libz \
--with-libbz2 \
-   --without-liblzma \
--without-libselinux \
"
 
+PACKAGECONFIG = "liblzma"
+PACKAGECONFIG[liblzma] = "--with-liblzma,--without-liblzma, xz"
+
 EXTRA_OECONF += "TAR=tar"
 EXTRA_OECONF_append_class-target = " DEB_HOST_ARCH=${DPKG_ARCH}"
 
-- 
2.7.4

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

Re: [OE-core] Subscribing to openembedded-architecture list

[Konopelko, Pavel (P.)]

Philip,

Philip Balister wrote on 2017-03-30:
> You should be able to join. Did you get any messages at all?

No responses at all.  Neither for web interface nor for mail requests to 
openembedded-architecture-{request|join}.  The only time I've got a response 
was when I tried to send the question below to openembedded-architecture and 
the message bounced.

Regards,
--Pavel Konopelko

> On 03/30/2017 06:32 AM, Konopelko, Pavel (P.) wrote:
>> Hello everybody,
>> 
>> I wonder if openembedded-architecture list is closed, invitation-only
> or something.  The OE wiki [1] does not mention any restrictions.
> Nevertheless I seem to be unable to subscribe via the web interface or
> via an e-mail request (tried several times over the last couple of
> weeks).
>> 
>> What am I missing?
>> 
>> 
>> Thanks,
>> --Pavel Konopelko
>> 
>> [1] http://openembedded.org/wiki/Mailing_lists
>> 
>>


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

Re: [OE-core] [PATCH 0/1] mesa: Contain configure search for llvm

[Martin Jansa]

On Thu, Mar 23, 2017 at 10:31:07AM -0700, Khem Raj wrote:
> On Thu, Mar 23, 2017 at 12:51 AM, Martin Jansa  wrote:
> > I'm not sure if this is the root cause, but last qemux86 build shows:
> >
> >
> > | configure: error: --enable-gallium-llvm selected but llvm-config is not
> > found
> > | ERROR: Function failed: do_configure (log file is located at
> > /home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/mesa/2_17.0.1-r0/temp/log.do_configure.11359)
> >
> 
> can you point where is llvm-config installed in sysroot ? its possible
> its not in native sysroot location ${STAGING_BINDIR_NATIVE}

OE qemux86@ ~/build/oe-core $ find 
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot* -name llvm\*
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/bin/crossscripts/llvm-config
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/bin/crossscripts/llvm-config3.3
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/include/llvm3.3
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/include/llvm3.3/llvm-c
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/include/llvm3.3/llvm
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/include/llvm3.3/llvm/Config/llvm-config.h
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/lib/llvm3.3
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/sysroot-providers/llvm-common
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/sysroot-providers/llvm3.3
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm3.3.complete
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm-common.complete
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm-common.6be6a4ae98ee0dff7c2a4c4df17f026a
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm-common
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm3.3.388adaa288ab3b1d35e01a43b6542368
tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm3.3

> 
> >
> > I've noticed some llvm changes for meta-clang, do we need similar changes
> > for meta-oe version of llvm?
> >
> >
> > On Sun, Mar 12, 2017 at 12:16 AM, Khem Raj  wrote:
> >>
> >>
> >>
> >> On 3/11/17 1:30 PM, Khem Raj wrote:
> >> > The following changes since commit
> >> > a47e64d985a610535449730806651f5bfd75d9ec:
> >> >
> >> >   libcomps: add a recipe (2017-03-11 16:08:50 +)
> >> >
> >> > are available in the git repository at:
> >> >
> >> >   git://git.openembedded.org/openembedded-core-contrib kraj/pu
> >> >   http://cgit.openembedded.org/openembedded-core-contrib/log/?h=kraj/pu
> >> >
> >> > Khem Raj (1):
> >> >   mesa: Contain configure search for llvm
> >> >
> >>
> >> I added another fix for mesa-gl to remove one of obsolete packageconfigs
> >> and its on the same pull branch now.
> >>
> >> >  meta/recipes-graphics/mesa/mesa.inc | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >

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


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

Re: [OE-core] [PATCH] glibc: Support building with 2.6.32 kernels on x86 / x86_64

[Serhii Popovych]

> 
>>
>>>
>>>
>>> On 3/28/17 11:57 AM, Serhii Popovych wrote:
 While glibc states that 2.6.32 kernels still supported
 for x86 / x86_64 builds are failing due to out of date
 LIBC_LINUX_VERSION macro checks for such architectures.

 This macro statically defined to 3.2.0 with commit 5b4ecd3
 (Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere.)
 and additionally checked before --enable-kernel.

 Since both --enable-kernel and LIBC_LINUX_VERSION checks
 are the same and there is no users of last one we can
 safely get rid of it enabling glibc builds with 2.6.32
 kernel headers.

 Also add --enable-kernel to glibc-initial build so that we
 build it correctly with old headers.

 Cc: XE-Linux 
 Signed-off-by: Serhii Popovych 
 ---
  meta/recipes-core/glibc/glibc-initial.inc  |   1 +
  .../glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch | 113 
 +
  meta/recipes-core/glibc/glibc_2.25.bb  |   1 +
  3 files changed, 115 insertions(+)
  create mode 100644 
 meta/recipes-core/glibc/glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch

 diff --git a/meta/recipes-core/glibc/glibc-initial.inc 
 b/meta/recipes-core/glibc/glibc-initial.inc
 index f94603c..60b25dd 100644
 --- a/meta/recipes-core/glibc/glibc-initial.inc
 +++ b/meta/recipes-core/glibc/glibc-initial.inc
 @@ -12,6 +12,7 @@ do_configure () {
find ${S} -name "configure" | xargs touch
cfgscript=`python3 -c "import os; print(os.path.relpath('${S}', 
 '.'))"`/configure
$cfgscript --host=${TARGET_SYS} --build=${BUILD_SYS} \
 +  --enable-kernel=${OLDEST_KERNEL} \
--prefix=/usr \
--without-cvs --disable-sanity-checks \
--with-headers=${STAGING_DIR_TARGET}${includedir} \
 diff --git 
 a/meta/recipes-core/glibc/glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch 
 b/meta/recipes-core/glibc/glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch
 new file mode 100644
 index 000..f5eaf1c
 --- /dev/null
 +++ 
 b/meta/recipes-core/glibc/glibc/0028-Kill-LIBC_LINUX_VERSION-macro.patch
 @@ -0,0 +1,113 @@
 +From 88f83e4b5a8929dac9095ed264700fcb62d5e4dd Mon Sep 17 00:00:00 2001
 +From: Serhii Popovych 
 +Date: Fri, 17 Mar 2017 15:48:34 +
 +Subject: Kill LIBC_LINUX_VERSION macro
 +
 +After commit 5b4ecd3 (Require Linux 3.2 except on x86 / x86_64,
 +3.2 headers everywhere.) minimal kernel version raised from
 +2.6.32 to 3.2.0 for all architectures except x86 and x86_64
 +unless newer already used for architecture.
 +
 +However LIBC_LINUX_VERSION macro still is in effect and fails
 +configure even with --enable-kernel=2.6.32.
 +
 +While it is present in configure.ac it does not affect anything
 +except LINUX_VERSION_CODE check which already performed by
 +--enable-kernel.
 +
>>>
>>> --enable-kernel is forces the minimum kernel for glibc to configure for
>>> kernel interfaces if not set it defaults to arch specific value but it
>>> wont check for version of linux headers during compile time. Whereas
>>> this check is checking and errors out during build time if minimum
>>> kernel version is not met.
>>
>> But why in configure.ac
>> define([LIBC_LINUX_VERSION],[3.2.0])
>> sets to version 3.2.0?
>>
>> and then AC_TRY_COMPILE() sets libc_cv_linuxVER='missing or too old!'
>> causing configure to fail due to missing kheaders >= 3.2.0, not 2.6.32.
>>
>> Later in configure.ac I see minimum_kernel being checked with
>> AC_TRY_COMPILE() and same code as for LIBC_LINUX_VERSION.
>>
>> So we check for 3.2.0 and then check for minimum_kernel (--enable-
>> kernel) 2.6.32 after this?
> 
> By looking at commit 5b4ecd3 (Require Linux 3.2 except on x86 / x86_64,
> 3.2 headers everywhere.) contents closer I found answer for this
> question.
> 
> In NEWS file we have:
> 
> +  unchanged).  Linux 3.2 or later kernel headers are required on all
> +  architectures.
> 
> For me that means we should use kernel headers from 3.2 to build glibc,
> but for x86 / x86_64 we still may force minimum supported kernel version
> of 2.6.32 with --enable-kernel.
> 
> I will submit v2 without patch to remove LIBC_LINUX_VERSION check (i.e.
> just add --enable-kernel=${OLDEST_KERNEL}.

It seems even change to add --enable-kernel=${OLDEST_KERNEL} for
glibc-initial isn't necessary.

This whole patch *should* be skipped.

> 
> Thanks,
> Serhii
> 
>>
>>
>>> If you were to make the LIBC_LINUX_VERSION
>>> have a value that matches the arch_minimum_kernel version that would be
>>> an improvement.
>>
>> configure.ac (and thus configure) is only place where
>> LIBC_LINUX_VERSION is used, so I decided to remove it as remnant from
>> pre --enable-kernel option ages.
>>
>>>
>>> As such if you want to do quick fix then lower the value of
>>> LIBC_LINUX_VERSION to 2.6.32 when b

[OE-core] [PATCH v5 1/2] autoconf: Adjust shebang lines to remove interpreter path hardcode

[Serhii Popovych]

If build host perl (and other tools) is old and we use some kind
of toolchain to provide recent perl/python/etc to the OE build
we still locked to use build host perl due to hardcoded shebang
lines in autoconf scripts.

Behaviour was observed with Enterprise Linux 6 and devtoolset
toolchain from SCL (Software Collections) used to provide recent
version of perl (not provided with default buildtools-tarball).

Pass /usr/bin/env perl in ac_cv_path_PERL configuration variables
for class-native and class-nativesdk. Use patch to autoconf to replace
-w option in shebang line with modern way to enable warnings on perl
(i.e. "use warnings").

Also add nativesdk-m4 and nativesdk-gnu-config to RDEPENDS to bring
runtime dependencies inline with other targets.

Note that ac_cv_path_PERL must be valid perl interpreter path
since configure will check perl version and Flock implementation.
It is not possible currently to use nativeperl from native
sysroot because autoconf does not DEPENDS on perl-native (and
doing so fails due to circular dependencies). Only possible
solution is to overwrite shebangs with nativeperl somewhere at
do_install() and update RDEPENDS for class-native. Or add perl
symlinks to nativeperl in sysroot.

For now it seems good to use perl found by /usr/bin/env from
autoconf-native.

Cc: XE-Linux 
Signed-off-by: Serhii Popovych 
---
v5: Rebase against current master
v4: Address typo, and remnants of nativesdk-perl in RDEPENDS
left from internal imlementation part.
Thanks to Richard Purdie 
v3: Corrected Upstream-Status tag.
v2: Just realized that files in quilt directory (.pc) patched
unnecessarily.

 meta/recipes-devtools/autoconf/autoconf.inc|   7 +-
 ...tion-in-shebangs-with-modern-use-warnings.patch | 120 +
 meta/recipes-devtools/autoconf/autoconf_2.69.bb|   1 +
 3 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch

diff --git a/meta/recipes-devtools/autoconf/autoconf.inc 
b/meta/recipes-devtools/autoconf/autoconf.inc
index b4e3356..f1b2dfc 100644
--- a/meta/recipes-devtools/autoconf/autoconf.inc
+++ b/meta/recipes-devtools/autoconf/autoconf.inc
@@ -27,13 +27,18 @@ RDEPENDS_${PN} = "m4 gnu-config \
  perl-module-data-dumper \
 "
 RDEPENDS_${PN}_class-native = "m4-native gnu-config-native"
+RDEPENDS_${PN}_class-nativesdk = "nativesdk-m4 nativesdk-gnu-config"
 
 SRC_URI = "${GNU_MIRROR}/autoconf/autoconf-${PV}.tar.gz \
   file://program_prefix.patch"
 
 inherit autotools texinfo
 
-CACHED_CONFIGUREVARS += "ac_cv_path_PERL=${USRBINPATH}/perl"
+PERL = "${USRBINPATH}/perl"
+PERL_class-native = "/usr/bin/env perl"
+PERL_class-nativesdk = "/usr/bin/env perl"
+
+CACHED_CONFIGUREVARS += "ac_cv_path_PERL='${PERL}'"
 
 do_configure() {
oe_runconf
diff --git 
a/meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch
 
b/meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch
new file mode 100644
index 000..ae0e382
--- /dev/null
+++ 
b/meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch
@@ -0,0 +1,120 @@
+From 236552ff5b9f1ebf666d8d0e9850007dcce03d26 Mon Sep 17 00:00:00 2001
+From: Serhii Popovych 
+Date: Wed, 10 Feb 2016 16:32:44 +
+Subject: [PATCH] perl: Replace -w option in shebangs with modern "use
+ warnings"
+
+In some builds we might provide ac_cv_path_PERL as /usr/bin/env perl
+to use newer version of the perl from users PATH rather than
+older from standard system path.
+
+However using /usr/bin/env perl -w from shebang line isn't
+possible because it translates to something like
+/usr/bin/env -w perl and env complains about illegal option.
+
+To address this we can remove -w option from perl shebang
+line and add "use warnings" statement.
+
+Upstream-Status: Pending
+Signed-off-by: Serhii Popovych 
+---
+ bin/autom4te.in  | 3 ++-
+ bin/autoreconf.in| 3 ++-
+ bin/autoscan.in  | 3 ++-
+ bin/autoupdate.in| 3 ++-
+ bin/ifnames.in   | 3 ++-
+ 5 files changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/bin/autom4te.in b/bin/autom4te.in
+index 11773c9..a8f5e41 100644
+--- a/bin/autom4te.in
 b/bin/autom4te.in
+@@ -1,4 +1,4 @@
+-#! @PERL@ -w
++#! @PERL@
+ # -*- perl -*-
+ # @configure_input@
+ 
+@@ -42,6 +42,7 @@ use Autom4te::General;
+ use Autom4te::XFile;
+ use File::Basename;
+ use strict;
++use warnings;
+ 
+ # Data directory.
+ my $pkgdatadir = $ENV{'AC_MACRODIR'} || '@pkgdatadir@';
+diff --git a/bin/autoreconf.in b/bin/autoreconf.in
+index e245db4..1a318cb 100644
+--- a/bin/autoreconf.in
 b/bin/autoreconf.in
+@

[OE-core] [PATCH v5 0/2] automake/autoconf: avoid path to perl interpreter hardcoding

[Serhii Popovych]

Hi,

This is updated series of changes to autoconf/automake
where I address all questions from previous review session.

Sorry for noise. Please review again.

Thanks.

Cc: XE-Linux 
Serhii Popovych (2):
  autoconf: Adjust shebang lines to remove interpreter path hardcode
  automake: Adjust shebang lines to remove interpreter path hardcode

 meta/recipes-devtools/autoconf/autoconf.inc|   7 +-
 ...tion-in-shebangs-with-modern-use-warnings.patch | 120 +
 meta/recipes-devtools/autoconf/autoconf_2.69.bb|   1 +
 ...tion-in-shebangs-with-modern-use-warnings.patch | 101 +
 meta/recipes-devtools/automake/automake_1.15.bb|  13 ++-
 5 files changed, 238 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-devtools/autoconf/autoconf/autoconf-replace-w-option-in-shebangs-with-modern-use-warnings.patch
 create mode 100644 
meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch

-- 
2.7.4

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

[OE-core] [PATCH v5 2/2] automake: Adjust shebang lines to remove interpreter path hardcode

[Serhii Popovych]

If build host perl (and other tools) is old and we use some kind
of toolchain to provide recent perl/python/etc to the OE build
we still locked to use build host perl due to hardcoded shebang
lines in automake scripts.

Behaviour was observed with Enterprise Linux 6 and devtoolset
toolchain from SCL (Software Collections) used to provide recent
version of perl (not provided with default buildtools-tarball).

Pass /usr/bin/env perl in ac_cv_path_PERL configuration variables
for class-native and class-nativesdk. Use patch to automake to replace
-w option in shebang line with modern way to enable warnings on perl
(i.e. "use warnings").

Also add nativesdk-autoconf to RDEPENDS to bring runtime dependencies
inline with other targets.

Note that ac_cv_path_PERL must be valid perl interpreter path
since configure will check perl version and Flock implementation.
It is not possible currently to use nativeperl from native
sysroot because automake does not DEPENDS on perl-native (and
doing so fails due to circular dependencies). Only possible
solution is to overwrite shebangs with nativeperl somewhere at
do_install() and update RDEPENDS for class-native. Or add perl
symlinks to nativeperl in sysroot.

For now it seems good to use perl found by /usr/bin/env from
automake-native.

Cc: XE-Linux 
Signed-off-by: Serhii Popovych 
---
v5: Rebase against current master
v4: - skipped -
v3: Kill remnants of nativesdk-perl in RDEPENDS left from internal
imlementation part.
Thanks to Richard Purdie 
v2: Corrected Upstream-Status tag.

 ...tion-in-shebangs-with-modern-use-warnings.patch | 101 +
 meta/recipes-devtools/automake/automake_1.15.bb|  13 ++-
 2 files changed, 111 insertions(+), 3 deletions(-)
 create mode 100644 
meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch

diff --git 
a/meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch
 
b/meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch
new file mode 100644
index 000..fe1d3d0
--- /dev/null
+++ 
b/meta/recipes-devtools/automake/automake/automake-replace-w-option-in-shebangs-with-modern-use-warnings.patch
@@ -0,0 +1,101 @@
+From 41e06b7a354774913dcd2e32a35440e407843357 Mon Sep 17 00:00:00 2001
+From: Serhii Popovych 
+Date: Wed, 10 Feb 2016 17:07:32 +
+Subject: [PATCH] perl: Replace -w option in shebangs with modern "use
+ warnings"
+
+In some builds we might provide ac_cv_path_PERL as /usr/bin/env
+perl to use newer version of the perl from users PATH rather than older from
+standard system path.
+
+However using /usr/bin/env perl -w from shebang line isn't
+possible because it translates to something like
+/usr/bin/env -w perl and env complains about illegal option.
+
+To address this we can remove -w option from perl shebang
+line and add "use warnings" statement.
+
+Upstream-Status: Pending
+Signed-off-by: Serhii Popovych 
+---
+ bin/aclocal.in | 3 ++-
+ bin/automake.in| 3 ++-
+ t/wrap/aclocal.in  | 3 ++-
+ t/wrap/automake.in | 3 ++-
+ 4 files changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/bin/aclocal.in b/bin/aclocal.in
+index 349f24a..50cb8d3 100644
+--- a/bin/aclocal.in
 b/bin/aclocal.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!@PERL@
+ # -*- perl -*-
+ # @configure_input@
+ 
+@@ -33,6 +33,7 @@ BEGIN
+ }
+ 
+ use strict;
++use warnings;
+ 
+ use Automake::Config;
+ use Automake::General;
+diff --git a/bin/automake.in b/bin/automake.in
+index eedc8bc..e0a01cf 100644
+--- a/bin/automake.in
 b/bin/automake.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!@PERL@
+ # -*- perl -*-
+ # @configure_input@
+ 
+@@ -28,6 +28,7 @@ eval 'case $# in 0) exec @PERL@ -S "$0";; *) exec @PERL@ -S 
"$0" "$@";; esac'
+ package Automake;
+ 
+ use strict;
++use warnings;
+ 
+ BEGIN
+ {
+diff --git a/t/wrap/aclocal.in b/t/wrap/aclocal.in
+index e64b546..9996899 100644
+--- a/t/wrap/aclocal.in
 b/t/wrap/aclocal.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!@PERL@
+ # @configure_input@
+ 
+ # Copyright (C) 2012-2014 Free Software Foundation, Inc.
+@@ -19,6 +19,7 @@
+ BEGIN
+ {
+   use strict;
++  use warnings;
+   @Aclocal::perl_libdirs = ('@abs_top_srcdir@/lib');
+   unshift @Aclocal::perl_libdirs, '@abs_top_builddir@/lib'
+ if '@srcdir@' ne '.';
+diff --git a/t/wrap/automake.in b/t/wrap/automake.in
+index 8b943b1..be61226 100644
+--- a/t/wrap/automake.in
 b/t/wrap/automake.in
+@@ -1,4 +1,4 @@
+-#!@PERL@ -w
++#!@PERL@
+ # @configure_input@
+ 
+ # Copyright (C) 2012-2014 Free Software Foundation, Inc.
+@@ -19,6 +19,7 @@
+ BEGIN
+ {
+   use strict;
++  use warnings;
+   @Automake::perl_libdirs = ('@abs_top_srcdir@/lib');
+   unshift @Automake::perl_libdirs, '@abs_top_builddir@/lib'
+ if '@srcdir@' ne '.';
+-- 
+2.3.0
+
diff --git a/meta/recipes-devtools/automake/automake_1.15.bb 
b/meta/recipes-devtools/automake/automake_1.15.bb
index a3c72fd..a6904c8 100644
--- a/meta/

Re: [OE-core] [PATCH 0/1] mesa: Contain configure search for llvm

[Khem Raj]

On Fri, Mar 31, 2017 at 8:08 AM, Martin Jansa  wrote:
> On Thu, Mar 23, 2017 at 10:31:07AM -0700, Khem Raj wrote:
>> On Thu, Mar 23, 2017 at 12:51 AM, Martin Jansa  
>> wrote:
>> > I'm not sure if this is the root cause, but last qemux86 build shows:
>> >
>> >
>> > | configure: error: --enable-gallium-llvm selected but llvm-config is not
>> > found
>> > | ERROR: Function failed: do_configure (log file is located at
>> > /home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-linux/mesa/2_17.0.1-r0/temp/log.do_configure.11359)
>> >
>>
>> can you point where is llvm-config installed in sysroot ? its possible
>> its not in native sysroot location ${STAGING_BINDIR_NATIVE}
>
> OE qemux86@ ~/build/oe-core $ find 
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot* -name llvm\*
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/bin/crossscripts/llvm-config
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/bin/crossscripts/llvm-config3.3
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/include/llvm3.3
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/include/llvm3.3/llvm-c
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/include/llvm3.3/llvm
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/include/llvm3.3/llvm/Config/llvm-config.h
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/usr/lib/llvm3.3
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/sysroot-providers/llvm-common
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot/sysroot-providers/llvm3.3
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm3.3.complete
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm-common.complete
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm-common.6be6a4ae98ee0dff7c2a4c4df17f026a
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm-common
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm3.3.388adaa288ab3b1d35e01a43b6542368
> tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-sysroot-native/installeddeps/llvm3.3
>

so it seems it should point to /usr/bin/crossscripts
can you try changing -with-llvm-prefix to point to this dir ?

>>
>> >
>> > I've noticed some llvm changes for meta-clang, do we need similar changes
>> > for meta-oe version of llvm?
>> >
>> >
>> > On Sun, Mar 12, 2017 at 12:16 AM, Khem Raj  wrote:
>> >>
>> >>
>> >>
>> >> On 3/11/17 1:30 PM, Khem Raj wrote:
>> >> > The following changes since commit
>> >> > a47e64d985a610535449730806651f5bfd75d9ec:
>> >> >
>> >> >   libcomps: add a recipe (2017-03-11 16:08:50 +)
>> >> >
>> >> > are available in the git repository at:
>> >> >
>> >> >   git://git.openembedded.org/openembedded-core-contrib kraj/pu
>> >> >   http://cgit.openembedded.org/openembedded-core-contrib/log/?h=kraj/pu
>> >> >
>> >> > Khem Raj (1):
>> >> >   mesa: Contain configure search for llvm
>> >> >
>> >>
>> >> I added another fix for mesa-gl to remove one of obsolete packageconfigs
>> >> and its on the same pull branch now.
>> >>
>> >> >  meta/recipes-graphics/mesa/mesa.inc | 2 +-
>> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> --
>> >> ___
>> >> Openembedded-core mailing list
>> >> Openembedded-core@lists.openembedded.org
>> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> >
>> >
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

[Martin Kelly]

On 03/31/2017 01:51 AM, Burton, Ross wrote:


On 30 March 2017 at 20:20, Martin Kelly mailto:mke...@xevo.com>> wrote:

I'm trying to integrate the meta-clang version of LLVM 4.0 (used for
recipes that need a newer LLVM version) alongside the oe-core
version of LLVM 3.3 (used for mesa). I'd like some recipes to use
LLVM 4.0 and some to use LLVM 3.3 and for them not to collide with
each other.


Not that presumably you mean meta-oe, not oe-core.

Ross


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

Re: [OE-core] [PATCH v2 1/2] runqemu: Automatically add a TFTP directory for slirp boot

[Alistair Francis]

On Fri, Mar 24, 2017 at 1:38 PM, Alistair Francis
 wrote:
> When booting QEMU with slirp networking we want to use QEMUs TFTP server
> to make the images in deploy accessible to the guest.
>
> Signed-off-by: Alistair Francis 

Ping?

> ---
>  scripts/runqemu | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index 23c9efb..f76d976 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -832,7 +832,7 @@ class BaseConfig(object):
>  self.kernel_cmdline_script += ' ip=dhcp'
>  # Port mapping
>  hostfwd = ",hostfwd=tcp::-:22,hostfwd=tcp::2323-:23"
> -qb_slirp_opt_default = "-netdev user,id=net0%s" % hostfwd
> +qb_slirp_opt_default = "-netdev user,id=net0%s,tftp=%s" % (hostfwd, 
> self.get('DEPLOY_DIR_IMAGE'))
>  qb_slirp_opt = self.get('QB_SLIRP_OPT') or qb_slirp_opt_default
>  # Figure out the port
>  ports = re.findall('hostfwd=[^-]*:([0-9]+)-[^,-]*', qb_slirp_opt)
> --
> 2.9.3
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH morty v2] wic: partition: Run fsck on EXT file systems

[Khem Raj]

On 3/31/17 5:51 AM, Daniel Schultz wrote:
> Mkfs may create EXT file systems which can only be optimized by fsck
> and not by itself, e.g. directory optimization (in Pass 3A).
> 
> To prevent those optimizations during runtime, it will be performed after
> the creation of an EXT file system.
> 
> Signed-off-by: Daniel Schultz 
> ---
>  scripts/lib/wic/partition.py | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> index 3b3bd2d..152eb7b 100644
> --- a/scripts/lib/wic/partition.py
> +++ b/scripts/lib/wic/partition.py
> @@ -239,6 +239,9 @@ class Partition():
>  (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
>  exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
>  
> +mkfs_cmd = "fsck.%s -pvfD %s" % (self.fstype, rootfs)
> +exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
> +

is this required on master too ? if yes I would suggest to propose it
for master and then do a backport.

>  def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
>   native_sysroot, pseudo):
>  """
> 



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

[OE-core] [PATCH] binutils: Detect 64bit mips target for gold

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/binutils/binutils-2.28.inc   |  1 +
 .../binutils/0016-Detect-64-bit-MIPS-targets.patch | 50 ++
 2 files changed, 51 insertions(+)
 create mode 100644 
meta/recipes-devtools/binutils/binutils/0016-Detect-64-bit-MIPS-targets.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.28.inc 
b/meta/recipes-devtools/binutils/binutils-2.28.inc
index fcf30357f69..76b81b04cae 100644
--- a/meta/recipes-devtools/binutils/binutils-2.28.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.28.inc
@@ -34,6 +34,7 @@ SRC_URI = "\
  file://0013-Add-support-for-Netlogic-XLP.patch \
  file://0014-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch \
  file://0015-sync-with-OE-libtool-changes.patch \
+ file://0016-Detect-64-bit-MIPS-targets.patch \
 "
 S  = "${WORKDIR}/git"
 
diff --git 
a/meta/recipes-devtools/binutils/binutils/0016-Detect-64-bit-MIPS-targets.patch 
b/meta/recipes-devtools/binutils/binutils/0016-Detect-64-bit-MIPS-targets.patch
new file mode 100644
index 000..1b2eb8485c5
--- /dev/null
+++ 
b/meta/recipes-devtools/binutils/binutils/0016-Detect-64-bit-MIPS-targets.patch
@@ -0,0 +1,50 @@
+From c3ebde5d8cc3b0092966b4d725cad7cfd074fd8d Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Fri, 31 Mar 2017 11:42:03 -0700
+Subject: [PATCH 16/16] Detect 64-bit MIPS targets
+
+Add mips64 target triplets and default to N64
+
+Upstream-Status: Submitted
+https://sourceware.org/ml/binutils/2016-08/msg00048.html
+
+Signed-off-by: Khem Raj 
+---
+ gold/configure.tgt | 14 ++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/gold/configure.tgt b/gold/configure.tgt
+index 3d63027297..c1f92a1360 100644
+--- a/gold/configure.tgt
 b/gold/configure.tgt
+@@ -153,6 +153,13 @@ aarch64*-*)
+  targ_big_endian=false
+  targ_extra_big_endian=true
+  ;;
++mips*64*el*-*-*|mips*64*le*-*-*)
++ targ_obj=mips
++ targ_machine=EM_MIPS_RS3_LE
++ targ_size=64
++ targ_big_endian=false
++ targ_extra_big_endian=true
++ ;;
+ mips*el*-*-*|mips*le*-*-*)
+  targ_obj=mips
+  targ_machine=EM_MIPS_RS3_LE
+@@ -160,6 +167,13 @@ mips*el*-*-*|mips*le*-*-*)
+  targ_big_endian=false
+  targ_extra_big_endian=true
+  ;;
++mips*64*-*-*)
++ targ_obj=mips
++ targ_machine=EM_MIPS
++ targ_size=64
++ targ_big_endian=true
++ targ_extra_big_endian=false
++ ;;
+ mips*-*-*)
+  targ_obj=mips
+  targ_machine=EM_MIPS
+-- 
+2.12.1
+
-- 
2.12.1

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

Re: [OE-core] [PATCH] dpkg: Add PACKAGECONFIG for liblzma and enable it

[Matt Madison]

On Fri, Mar 31, 2017 at 7:09 AM, Richard Purdie
 wrote:
> liblzma is part of xz and we already build it but configure it out. This makes
> no sense. Enabling it means we gain multithreaded compression and it speeds
> dpkg-deb up massively. It also removes the fork overhead of separate xz 
> processes.
>
> Turning the existing config into a PACKAGECONFIG and turning it on by default
> therefore makes best use of what we have available.
>
> The manual RDEPENDS are no longer needed since it uses liblzma which is picked
> up by the shlibs code magically.
>
> Signed-off-by: Richard Purdie 

Yes, please.  I've been using dpkg configured this way for a month or
so on my deb-based distro, and was going to submit a patch for this
myself.  The performance improvement during packaging is significant,
and I haven't seen any downsides.

Thanks,
-Matt

> ---
>  meta/recipes-devtools/dpkg/dpkg.inc | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-devtools/dpkg/dpkg.inc 
> b/meta/recipes-devtools/dpkg/dpkg.inc
> index 6abe3ae..870117a 100644
> --- a/meta/recipes-devtools/dpkg/dpkg.inc
> +++ b/meta/recipes-devtools/dpkg/dpkg.inc
> @@ -4,8 +4,8 @@ SECTION = "base"
>
>  DEPENDS = "zlib bzip2 perl ncurses"
>  DEPENDS_class-native = "bzip2-replacement-native zlib-native 
> virtual/update-alternatives-native gettext-native perl-native"
> -RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} xz perl"
> -RDEPENDS_${PN}_class-native = "xz-native"
> +RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} perl"
> +RDEPENDS_${PN}_class-native = ""
>
>  UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/dpkg/"
>
> @@ -28,10 +28,12 @@ EXTRA_OECONF = "\
> --enable-start-stop-daemon \
> --with-libz \
> --with-libbz2 \
> -   --without-liblzma \
> --without-libselinux \
> "
>
> +PACKAGECONFIG = "liblzma"
> +PACKAGECONFIG[liblzma] = "--with-liblzma,--without-liblzma, xz"
> +
>  EXTRA_OECONF += "TAR=tar"
>  EXTRA_OECONF_append_class-target = " DEB_HOST_ARCH=${DPKG_ARCH}"
>
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ncurses_6.0: Improve reproducibility

[Juro Bystricky]

Build static libraries without the binutils "ar" -U option.
This option deliberately breaks deterministic mode.
The option seems to be a relic from 2015, intended as a workaround
for some unspecified build problems.

[YOCTO#11247]

Signed-off-by: Juro Bystricky 
---
 .../ncurses/files/configure-reproducible.patch   | 20 
 meta/recipes-core/ncurses/ncurses_6.0+20161126.bb|  1 +
 2 files changed, 21 insertions(+)
 create mode 100644 meta/recipes-core/ncurses/files/configure-reproducible.patch

diff --git a/meta/recipes-core/ncurses/files/configure-reproducible.patch 
b/meta/recipes-core/ncurses/files/configure-reproducible.patch
new file mode 100644
index 000..54a8bdc
--- /dev/null
+++ b/meta/recipes-core/ncurses/files/configure-reproducible.patch
@@ -0,0 +1,20 @@
+"configure" enforces -U for ar flags, breaking deterministic builds.
+The flag was added to fix some vaguely specified "recent POSIX binutil
+build problems" in 2015. 
+
+Upstream-Status: Pending
+Signed-off-by: Juro Bystricky 
+
+diff --git a/configure b/configure
+index 7f31208..aa80911 100755
+--- a/configure
 b/configure
+@@ -4428,7 +4428,7 @@ if test "${cf_cv_ar_flags+set}" = set; then
+ else
+ 
+   cf_cv_ar_flags=unknown
+-  for cf_ar_flags in -curvU -curv curv -crv crv -cqv cqv -rv rv
++  for cf_ar_flags in -curv curv -crv crv -cqv cqv -rv rv
+   do
+ 
+   # check if $ARFLAGS already contains this choice
diff --git a/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb 
b/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
index e95741f..ace3108 100644
--- a/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
+++ b/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
@@ -3,6 +3,7 @@ require ncurses.inc
 SRC_URI += "file://tic-hang.patch \
 file://fix-cflags-mangle.patch \
 file://config.cache \
+file://configure-reproducible.patch \
 "
 # commit id corresponds to the revision in package version
 SRCREV = "3db0bd19cb50e3d9b4f2cf15b7a102fe11302068"
-- 
2.7.4

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

Re: [OE-core] [PATCH] ncurses_6.0: Improve reproducibility

[Khem Raj]

On Fri, Mar 31, 2017 at 2:29 PM Juro Bystricky 
wrote:

> Build static libraries without the binutils "ar" -U option.
> This option deliberately breaks deterministic mode.


While this patch is ok it would be better if we configured binutils with
enable-deterministic-archives option please file a ticket for it

>
> The option seems to be a relic from 2015, intended as a workaround
> for some unspecified build problems.
>
> [YOCTO#11247]
>
> Signed-off-by: Juro Bystricky 
> ---
>  .../ncurses/files/configure-reproducible.patch   | 20
> 
>  meta/recipes-core/ncurses/ncurses_6.0+20161126.bb|  1 +
>  2 files changed, 21 insertions(+)
>  create mode 100644
> meta/recipes-core/ncurses/files/configure-reproducible.patch
>
> diff --git a/meta/recipes-core/ncurses/files/configure-reproducible.patch
> b/meta/recipes-core/ncurses/files/configure-reproducible.patch
> new file mode 100644
> index 000..54a8bdc
> --- /dev/null
> +++ b/meta/recipes-core/ncurses/files/configure-reproducible.patch
> @@ -0,0 +1,20 @@
> +"configure" enforces -U for ar flags, breaking deterministic builds.
> +The flag was added to fix some vaguely specified "recent POSIX binutil
> +build problems" in 2015.
> +
> +Upstream-Status: Pending
> +Signed-off-by: Juro Bystricky 
> +
> +diff --git a/configure b/configure
> +index 7f31208..aa80911 100755
> +--- a/configure
>  b/configure
> +@@ -4428,7 +4428,7 @@ if test "${cf_cv_ar_flags+set}" = set; then
> + else
> +
> +   cf_cv_ar_flags=unknown
> +-  for cf_ar_flags in -curvU -curv curv -crv crv -cqv cqv -rv rv
> ++  for cf_ar_flags in -curv curv -crv crv -cqv cqv -rv rv
> +   do
> +
> +   # check if $ARFLAGS already contains this choice
> diff --git a/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
> b/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
> index e95741f..ace3108 100644
> --- a/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
> +++ b/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
> @@ -3,6 +3,7 @@ require ncurses.inc
>  SRC_URI += "file://tic-hang.patch \
>  file://fix-cflags-mangle.patch \
>  file://config.cache \
> +file://configure-reproducible.patch \
>  "
>  # commit id corresponds to the revision in package version
>  SRCREV = "3db0bd19cb50e3d9b4f2cf15b7a102fe11302068"
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ncurses_6.0: Improve reproducibility

[Richard Purdie]

On Fri, 2017-03-31 at 22:27 +, Khem Raj wrote:
> 
> On Fri, Mar 31, 2017 at 2:29 PM Juro Bystricky  com> wrote:
> > Build static libraries without the binutils "ar" -U option.
> > This option deliberately breaks deterministic mode.
> While this patch is ok it would be better if we configured binutils
> with enable-deterministic-archives option please file a ticket for
> it 

ncurses is specifically asking binutils to make a non-deterministic
archive here so I'm not sure that would help in this specific case.

Cheers,

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

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

[Martin Kelly]

On 03/30/2017 04:58 PM, Martin Kelly wrote:

On 03/30/2017 12:31 PM, Khem Raj wrote:



On 3/30/17 12:20 PM, Martin Kelly wrote:

Hi,

I'm trying to integrate the meta-clang version of LLVM 4.0 (used for
recipes that need a newer LLVM version) alongside the oe-core version of
LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0 and some
to use LLVM 3.3 and for them not to collide with each other.

Right now, once the meta-clang layer is enabled, the recipes collide
because they both provide llvm-common.bb. I tried explicitly versioning
llvm-common, which makes them no longer collide. However, mesa then
fails to build because the meta-clang version of LLVM installs
llvm-config into the native common sysroot in


merging all llvm-common into a single recipe might be good




I thought more about this issue. Absent some clever solution that allows 
us to unify the wrappers (which is difficult due to the issues I 
mentioned in the last mail), I think we have three routes that could 
work to at least allow meta-clang and meta-oe to exist in the same Yocto 
workspace without breakage:


(a) Instead of installing llvm-config into 
${SYSROOT_DESTDIR}${bindir_crossscripts} -- which causes collisions when 
meta-clang and meta-oe both try to overwrite the same shared file -- 
install into ${D}{bindir}llvm-config, and install the binary llvm-config 
into ${D}${bindir}/llvm-config${PV}. Recipes requiring LLVM will then 
need to depend on either llvm-common3.3 or llvm-common4.0, but at least 
there will be no collision or ambiguity which one gets used.


(b) Use a common wrapper in 
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config that does what the 
meta-oe current version does; just exec 
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config${WANT_LLVM_RELEASE}. 
Let the meta-oe LLVM 3.3 install the binary llvm-config into 
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config3.3 and let the 
meta-clang LLVM 4.0 install its wrapper llvm-config into 
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config4.0. meta-clang will 
have to use the second wrapper script because it needs to edit 
TARGET_CFLAGS and similar to avoid compiling target binaries using 
native flags (due to the CMake LLVM build which appears not to respect 
cross-compile).


(c) Use a common llvm-config wrapper in 
${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config that does a 
hardcoded check for WANT_LLVM_RELEASE. If the version is 4.0 or greater, 
then edit the TARGET_CFLAGS and similar, otherwise don't.


It seems to me that all these options are undesireable, but (a) is 
probably least so.


Khem and others: which option would you like me to pursue, or do you 
have an alternate suggestion?


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

Re: [OE-core] [PATCH] ncurses_6.0: Improve reproducibility

[Andre McCurdy]

On Fri, Mar 31, 2017 at 3:27 PM, Khem Raj  wrote:
>
> On Fri, Mar 31, 2017 at 2:29 PM Juro Bystricky 
> wrote:
>>
>> Build static libraries without the binutils "ar" -U option.
>> This option deliberately breaks deterministic mode.
>
> While this patch is ok it would be better if we configured binutils with
> enable-deterministic-archives option please file a ticket for it

We already do that:

  
http://git.openembedded.org/openembedded-core/commit/?id=df0d525c02780b5a0bd7a177a249c55f41797476

>>
>> The option seems to be a relic from 2015, intended as a workaround
>> for some unspecified build problems.
>>
>> [YOCTO#11247]
>>
>> Signed-off-by: Juro Bystricky 
>> ---
>>  .../ncurses/files/configure-reproducible.patch   | 20
>> 
>>  meta/recipes-core/ncurses/ncurses_6.0+20161126.bb|  1 +
>>  2 files changed, 21 insertions(+)
>>  create mode 100644
>> meta/recipes-core/ncurses/files/configure-reproducible.patch
>>
>> diff --git a/meta/recipes-core/ncurses/files/configure-reproducible.patch
>> b/meta/recipes-core/ncurses/files/configure-reproducible.patch
>> new file mode 100644
>> index 000..54a8bdc
>> --- /dev/null
>> +++ b/meta/recipes-core/ncurses/files/configure-reproducible.patch
>> @@ -0,0 +1,20 @@
>> +"configure" enforces -U for ar flags, breaking deterministic builds.
>> +The flag was added to fix some vaguely specified "recent POSIX binutil
>> +build problems" in 2015.
>> +
>> +Upstream-Status: Pending
>> +Signed-off-by: Juro Bystricky 
>> +
>> +diff --git a/configure b/configure
>> +index 7f31208..aa80911 100755
>> +--- a/configure
>>  b/configure
>> +@@ -4428,7 +4428,7 @@ if test "${cf_cv_ar_flags+set}" = set; then
>> + else
>> +
>> +   cf_cv_ar_flags=unknown
>> +-  for cf_ar_flags in -curvU -curv curv -crv crv -cqv cqv -rv rv
>> ++  for cf_ar_flags in -curv curv -crv crv -cqv cqv -rv rv
>> +   do
>> +
>> +   # check if $ARFLAGS already contains this choice
>> diff --git a/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
>> b/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
>> index e95741f..ace3108 100644
>> --- a/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
>> +++ b/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb
>> @@ -3,6 +3,7 @@ require ncurses.inc
>>  SRC_URI += "file://tic-hang.patch \
>>  file://fix-cflags-mangle.patch \
>>  file://config.cache \
>> +file://configure-reproducible.patch \
>>  "
>>  # commit id corresponds to the revision in package version
>>  SRCREV = "3db0bd19cb50e3d9b4f2cf15b7a102fe11302068"
>> --
>> 2.7.4
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ncurses_6.0: Improve reproducibility

[Khem Raj]

On Fri, Mar 31, 2017 at 3:50 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Fri, 2017-03-31 at 22:27 +, Khem Raj wrote:
> >
> > On Fri, Mar 31, 2017 at 2:29 PM Juro Bystricky  > com> wrote:
> > > Build static libraries without the binutils "ar" -U option.
> > > This option deliberately breaks deterministic mode.
> > While this patch is ok it would be better if we configured binutils
> > with enable-deterministic-archives option please file a ticket for
> > it
>
> ncurses is specifically asking binutils to make a non-deterministic
> archive here so I'm not sure that would help in this specific case
> Cheers,


Not this case obviously but I was reminded that this should be default
option from tool gain if not specified

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

[OE-core] [PATCH] python: remove stale link to "Python for Embedded Systems Site"

[Bob Cochran]

Reference url is a stale, non existent site that returns a 404, so get rid of it

Change impacts both the manifest files and the scripts that generate the 
manifests

Run the following from within recipes-devtools/python

../../../scripts/contrib/python/generate-manifest-2.7.py > 
python-2.7-manifest.inc
../../../scripts/contrib/python/generate-manifest-2.7.py -n > 
python-native-2.7-manifest.inc

../../../scripts/contrib/python/generate-manifest-3.5.py > 
python-3.5-manifest.inc
../../../scripts/contrib/python/generate-manifest-3.5.py -n > 
python-native-3.5-manifest.inc

Signed-off-by: Bob Cochran 
---
 meta/recipes-devtools/python/python-2.7-manifest.inc| 1 -
 meta/recipes-devtools/python/python-3.5-manifest.inc| 1 -
 meta/recipes-devtools/python/python-native-2.7-manifest.inc | 1 -
 meta/recipes-devtools/python/python-native-3.5-manifest.inc | 1 -
 scripts/contrib/python/generate-manifest-2.7.py | 1 -
 scripts/contrib/python/generate-manifest-3.5.py | 1 -
 6 files changed, 6 deletions(-)

diff --git a/meta/recipes-devtools/python/python-2.7-manifest.inc 
b/meta/recipes-devtools/python/python-2.7-manifest.inc
index 621024f..413405a 100644
--- a/meta/recipes-devtools/python/python-2.7-manifest.inc
+++ b/meta/recipes-devtools/python/python-2.7-manifest.inc
@@ -1,7 +1,6 @@
 
 # WARNING: This file is AUTO GENERATED: Manual edits will be lost next time I 
regenerate the file.
 # Generator: '../../../scripts/contrib/python/generate-manifest-2.7.py' 
Version 20110222.2 (C) 2002-2010 Michael 'Mickey' Lauer 

-# Visit the Python for Embedded Systems Site => 
http://www.Vanille.de/projects/python.spy
 
  
 
diff --git a/meta/recipes-devtools/python/python-3.5-manifest.inc 
b/meta/recipes-devtools/python/python-3.5-manifest.inc
index a53a8d5..55bcc4b 100644
--- a/meta/recipes-devtools/python/python-3.5-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.5-manifest.inc
@@ -1,7 +1,6 @@
 
 # WARNING: This file is AUTO GENERATED: Manual edits will be lost next time I 
regenerate the file.
 # Generator: '../../../scripts/contrib/python/generate-manifest-3.5.py' 
Version 20140131 (C) 2002-2010 Michael 'Mickey' Lauer 
-# Visit the Python for Embedded Systems Site => 
http://www.Vanille.de/projects/python.spy
 
  
 
diff --git a/meta/recipes-devtools/python/python-native-2.7-manifest.inc 
b/meta/recipes-devtools/python/python-native-2.7-manifest.inc
index f45147b..581a37a 100644
--- a/meta/recipes-devtools/python/python-native-2.7-manifest.inc
+++ b/meta/recipes-devtools/python/python-native-2.7-manifest.inc
@@ -1,7 +1,6 @@
 
 # WARNING: This file is AUTO GENERATED: Manual edits will be lost next time I 
regenerate the file.
 # Generator: '../../../scripts/contrib/python/generate-manifest-2.7.py 
--native' Version 20110222.2 (C) 2002-2010 Michael 'Mickey' Lauer 

-# Visit the Python for Embedded Systems Site => 
http://www.Vanille.de/projects/python.spy
 
  
 
diff --git a/meta/recipes-devtools/python/python-native-3.5-manifest.inc 
b/meta/recipes-devtools/python/python-native-3.5-manifest.inc
index aa4c4f5..10be3e9 100644
--- a/meta/recipes-devtools/python/python-native-3.5-manifest.inc
+++ b/meta/recipes-devtools/python/python-native-3.5-manifest.inc
@@ -1,7 +1,6 @@
 
 # WARNING: This file is AUTO GENERATED: Manual edits will be lost next time I 
regenerate the file.
 # Generator: '../../../scripts/contrib/python/generate-manifest-3.5.py 
--native' Version 20140131 (C) 2002-2010 Michael 'Mickey' Lauer 

-# Visit the Python for Embedded Systems Site => 
http://www.Vanille.de/projects/python.spy
 
  
 
diff --git a/scripts/contrib/python/generate-manifest-2.7.py 
b/scripts/contrib/python/generate-manifest-2.7.py
index b5941a0..5504b62 100755
--- a/scripts/contrib/python/generate-manifest-2.7.py
+++ b/scripts/contrib/python/generate-manifest-2.7.py
@@ -34,7 +34,6 @@ class MakefileMaker:
 self.out( """
 # WARNING: This file is AUTO GENERATED: Manual edits will be lost next time I 
regenerate the file.
 # Generator: '%s%s' Version %s (C) 2002-2010 Michael 'Mickey' Lauer 

-# Visit the Python for Embedded Systems Site => 
http://www.Vanille.de/projects/python.spy
 """ % ( sys.argv[0], ' --native' if isNative else '', __version__ ) )
 
 #
diff --git a/scripts/contrib/python/generate-manifest-3.5.py 
b/scripts/contrib/python/generate-manifest-3.5.py
index a7fc8ba..386bdfc 100755
--- a/scripts/contrib/python/generate-manifest-3.5.py
+++ b/scripts/contrib/python/generate-manifest-3.5.py
@@ -37,7 +37,6 @@ class MakefileMaker:
 self.out( """
 # WARNING: This file is AUTO GENERATED: Manual edits will be lost next time I 
regenerate the file.
 # Generator: '%s%s' Version %s (C) 2002-2010 Michael 'Mickey' Lauer 

-# Visit the Python for Embedded Systems Site => 
http://www.Vanille.de/projects/python.spy
 """ % ( sys.argv[0], ' --native' if isNative else '', __version__ ) )
 
 #
-- 
2.7.4

-- 
___
Openembedded-core mailing l

Re: [OE-core] [PATCH 0/1] mesa: Contain configure search for llvm

[Martin Jansa]

Why is it needed?
Without this change mesa was finding llvm-config correctly, that's why I've
just reverted this to continue building.

On Fri, Mar 31, 2017 at 5:57 PM, Khem Raj  wrote:

> On Fri, Mar 31, 2017 at 8:08 AM, Martin Jansa 
> wrote:
> > On Thu, Mar 23, 2017 at 10:31:07AM -0700, Khem Raj wrote:
> >> On Thu, Mar 23, 2017 at 12:51 AM, Martin Jansa 
> wrote:
> >> > I'm not sure if this is the root cause, but last qemux86 build shows:
> >> >
> >> >
> >> > | configure: error: --enable-gallium-llvm selected but llvm-config is
> not
> >> > found
> >> > | ERROR: Function failed: do_configure (log file is located at
> >> > /home/jenkins/oe/world/shr-core/tmp-glibc/work/i586-oe-
> linux/mesa/2_17.0.1-r0/temp/log.do_configure.11359)
> >> >
> >>
> >> can you point where is llvm-config installed in sysroot ? its possible
> >> its not in native sysroot location ${STAGING_BINDIR_NATIVE}
> >
> > OE qemux86@ ~/build/oe-core $ find tmp-glibc/work/i586-oe-linux/
> mesa/2_17.0.2-r0/recipe-sysroot* -name llvm\*
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/usr/bin/crossscripts/llvm-config
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/usr/bin/crossscripts/llvm-config3.3
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/usr/include/llvm3.3
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/usr/include/llvm3.3/llvm-c
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/usr/include/llvm3.3/llvm
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/usr/include/llvm3.3/llvm/Config/llvm-config.h
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/usr/lib/llvm3.3
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/sysroot-providers/llvm-common
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot/sysroot-providers/llvm3.3
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot-native/installeddeps/llvm3.3.complete
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot-native/installeddeps/llvm-common.complete
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot-native/installeddeps/llvm-common.6be6a4ae98ee0dff7c2a4c4df17f026a
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot-native/installeddeps/llvm-common
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot-native/installeddeps/llvm3.3.388adaa288ab3b1d35e01a43b6542368
> > tmp-glibc/work/i586-oe-linux/mesa/2_17.0.2-r0/recipe-
> sysroot-native/installeddeps/llvm3.3
> >
>
> so it seems it should point to /usr/bin/crossscripts
> can you try changing -with-llvm-prefix to point to this dir ?
>
> >>
> >> >
> >> > I've noticed some llvm changes for meta-clang, do we need similar
> changes
> >> > for meta-oe version of llvm?
> >> >
> >> >
> >> > On Sun, Mar 12, 2017 at 12:16 AM, Khem Raj 
> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On 3/11/17 1:30 PM, Khem Raj wrote:
> >> >> > The following changes since commit
> >> >> > a47e64d985a610535449730806651f5bfd75d9ec:
> >> >> >
> >> >> >   libcomps: add a recipe (2017-03-11 16:08:50 +)
> >> >> >
> >> >> > are available in the git repository at:
> >> >> >
> >> >> >   git://git.openembedded.org/openembedded-core-contrib kraj/pu
> >> >> >   http://cgit.openembedded.org/openembedded-core-contrib/log/
> ?h=kraj/pu
> >> >> >
> >> >> > Khem Raj (1):
> >> >> >   mesa: Contain configure search for llvm
> >> >> >
> >> >>
> >> >> I added another fix for mesa-gl to remove one of obsolete
> packageconfigs
> >> >> and its on the same pull branch now.
> >> >>
> >> >> >  meta/recipes-graphics/mesa/mesa.inc | 2 +-
> >> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >
> >> >> --
> >> >> ___
> >> >> Openembedded-core mailing list
> >> >> Openembedded-core@lists.openembedded.org
> >> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >> >
> >> >
> >
> > --
> > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] State of bitbake world, Failed tasks 2017-03-30

[Martin Jansa]

opencv issue is fixed by removing one of pending master-next changes:
gflags: correct S and update library install directory

and ovmf was fixed in newer oe-core, so next report should be clean, unless
one of 50+ new changes break more stuff.

== Number of issues - stats ==
{| class='wikitable'
!|Date   !!colspan='3'|Failed tasks 
!!colspan='6'|Failed depencencies!!|Signatures
!!colspan='12'|QA !!Comment
|-
||  ||qemuarm   ||qemux86   ||qemux86_64
||qemuarm||max||min ||qemux86||max||min ||all   ||already-stripped  
||libdir||textrel   ||build-deps||file-rdeps
||version-going-backwards   ||host-user-contaminated
||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot
||invalid-pkgconfig ||pkgname   ||  
|-
||2017-03-30||1 ||2 ||2 ||N/A   ||N/A   ||N/A   ||N/A   ||N/A   
||N/A   ||0 ||0 ||0 ||1 ||0 
||0 ||12||0 ||0 ||0 
||0 ||0 ||0 ||  
|}

http://www.openembedded.org/wiki/Bitbake_World_Status

== Failed tasks 2017-03-30 ==

INFO: jenkins-job.sh-1.8.19 Complete log available at 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.report.20170331_204116.log

=== common (1) ===
* 
meta-openembedded/meta-oe/recipes-support/opencv/opencv_3.2.bb:do_configure

=== common-x86 (1) ===
* openembedded-core/meta/recipes-core/ovmf/ovmf_git.bb:do_compile

=== qemuarm (0) ===

=== qemux86 (0) ===

=== qemux86_64 (0) ===

=== Number of failed tasks (5) ===
{| class=wikitable
|-
|| qemuarm  || 1 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemuarm.20170330_025101.log/
 || http://errors.yoctoproject.org/Errors/Build/35115/
|-
|| qemux86  || 2 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemux86.20170330_024616.log/
 || http://errors.yoctoproject.org/Errors/Build/35130/
|-
|| qemux86_64   || 2 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.world.qemux86-64.20170330_063010.log/
 || http://errors.yoctoproject.org/Errors/Build/35208/
|}

=== PNBLACKLISTs (442) ===

=== QA issues (13) ===
{| class=wikitable
!| Count||Issue
|-
||0 ||already-stripped
|-
||0 ||build-deps
|-
||0 ||file-rdeps
|-
||0 ||host-user-contaminated
|-
||0 ||installed-vs-shipped
|-
||0 ||invalid-pkgconfig
|-
||0 ||libdir
|-
||0 ||pkgname
|-
||0 ||symlink-to-sysroot
|-
||0 ||unknown-configure-option
|-
||12||version-going-backwards
|-
||1 ||textrel
|}



=== Incorrect PACKAGE_ARCH or sstate signatures (0) ===

Complete log: 
http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.signatures.20170330_054036.log/

No issues detected

== Tested changes (not included in master yet) - bitbake ==
latest upstream commit: 
9215920 main: Improve -v and -D option documentation
not included in master yet: 
c7be363 world-image: add extra target

== Tested changes (not included in master yet) - openembedded-core ==
latest upstream commit: 
d68a86d dnf: remove systemd units in nativesdk builds
not included in master yet: 
4dfe9c0 qemux86: Add identical qemux86copy variant for tests
3922e66 sstate-sysroot-cruft.sh: Extend the whitelist
0a0a528 recipes: Replace "cp -a" with "cp -R --no-dereference 
--preserve=mode,links"
11a6716 buildhistory.bbclass: metadata-revs show repo parent
aed4adf8 metadata-revs: provide more information
efc1cfd report-error: Allow to upload reports automatically
6b52f4f Revert "openssl: Fix build with clang"
64c0a37 Revert "mesa: Contain configure search for llvm"

== Tested changes (not included in master yet) - meta-openembedded ==
latest upstream commit: 
f2dfae5 curlpp: 0.7.3 -> 0.8.1
not included in master yet: 
cd99d41 dnsmasq: disable the service by default
433ed04 gperftools: fix do_compile failure for qemuppc
99d4ea4 nginx: make user in nginx.conf consistent with the default value
9530df7 rapidjson: Update to 1.1.0 + git
c9efffc libtorrent, rtorrent: Update to latest
18095f4 sgio: Fix missing GNU_HASH errors
7246f84 libmatroska: Fix missing GNU_HASH errors
7bc10f5 smstools3: Fix GNU_HASH errors
3cd99b3 procmail: Fix GNU_HASH errors, pass LDFLAGS
2f26ed1 gradm: Fix GNU_HASH QA errors
1ce4dfb zile: Fix build with musl
9be90ec samsung-soc-utils: Remove -static
dc02354 digitemp: Update past 3.7.1 release
cf6f125 memstat: Fix build with musl
472a76d lvm2: Avoid an unnecessary dependency on bash
31520bf lvm2: libdevicemapper package needs udev rules and dmsetup
380ddf2 lvm2: fix lvm2-native RRECOMMENDS problem
ac7f99b gflags: correct S and update library install directory
c9070de libssh: Force to use gcc toolchain
9274e39 libnice: Upgrade to 0.1.13
83b9800 lio-utils: Fix GNU_HASH QA errors
ae26da7 nginx: set sane defaults for temp directories
f16faf7 nginx: make sure t