[OE-core] [PATCH v2 0/2] bind: 2 CVE fixes

Fix CVE-2016-8864, CVE-2016-6170 Changes from V1: Add CVE tag in patch file Yi Zhao (2): bind: Security fix CVE-2016-8864 bind: Security fix CVE-2016-6170 .../bind/bind/CVE-2016-6170.patch | 1090 .../bind/bind/CVE-2016-8864.patch |

[OE-core] [PATCH v2 1/2] bind: Security fix CVE-2016-8864

CVE-2016-8864: named in ISC BIND 9.x before 9.9.9-P4, 9.10.x before 9.10.4-P4, and 9.11.x before 9.11.0-P1 allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a DNAME record in the answer section of a response to a recursive query, related to db.c and

[OE-core] [PATCH v2 2/2] bind: Security fix CVE-2016-6170

CVE-2016-6170: ISC BIND through 9.9.9-P1, 9.10.x through 9.10.4-P1, and 9.11.x through 9.11.0b1 allows primary DNS servers to cause a denial of service (secondary DNS server crash) via a large AXFR response, and possibly allows IXFR servers to cause a denial of service (IXFR client crash) via a

[OE-core] ✗ patchtest: failure for bind: 2 CVE fixes

== Series Details == Series: bind: 2 CVE fixes Revision: 1 URL : https://patchwork.openembedded.org/series/6337/ 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

[OE-core] [PATCH 2/2] bind: Security fix CVE-2016-6170

CVE-2016-6170: ISC BIND through 9.9.9-P1, 9.10.x through 9.10.4-P1, and 9.11.x through 9.11.0b1 allows primary DNS servers to cause a denial of service (secondary DNS server crash) via a large AXFR response, and possibly allows IXFR servers to cause a denial of service (IXFR client crash) via a

[OE-core] [PATCH 0/2] bind: 2 CVE fixes

Fix CVE-2016-8864, CVE-2016-6170 Yi Zhao (2): bind: Security fix CVE-2016-8864 bind: Security fix CVE-2016-6170 .../bind/bind/CVE-2016-6170.patch | 1088 .../bind/bind/CVE-2016-8864.patch | 217

[OE-core] [PATCH 1/2] bind: Security fix CVE-2016-8864

CVE-2016-8864: named in ISC BIND 9.x before 9.9.9-P4, 9.10.x before 9.10.4-P4, and 9.11.x before 9.11.0-P1 allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a DNAME record in the answer section of a response to a recursive query, related to db.c and

[OE-core] [PATCH] byacc: 20161202 -> 20170201

Upgrade byacc from 20161202 to 20170201. Signed-off-by: Huang Qiyu --- .../recipes-extended/byacc/{byacc_20161202.bb => byacc_20170201.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-extended/byacc/{byacc_20161202.bb =>

Re: [OE-core] [PATCH] gnome-common: add EXTRA_OECONF "--with-autoconf-archive"

On 04/13/2017 05:19 AM, Zhixiong Chi wrote: autoconf-archive is not in oe-core, is it? Yes,it is. As Alex said, it shouldn't depend the recipe from the other layers. I will try to move autoconf-archive into oe-core next step. First research other ways to fix the issue please; we try to

Re: [OE-core] [PATCH v3 0/3] Set linux-firmware to correct license

On Wed, 2017-04-12 at 16:25 +0100, Richard Purdie wrote: > On Sun, 2017-04-09 at 18:58 -0700, wei.tee...@intel.com wrote: > > > > From: "Ng, Wei Tee" > > > > This is the revised version to fix the ipk packaging error as > > below: > > ERROR:

Re: [OE-core] [PATCH] gnome-common: add EXTRA_OECONF "--with-autoconf-archive"

On 2017年04月12日 19:04, Jussi Kukkonen wrote: On 12 April 2017 at 13:52, Zhixiong Chi > wrote: After updating the autoconf-archive version to 2016.09.16, autoconf-archive installs the same ax_*.m4 macros that

[OE-core] [oe-core] [PATCH] harfbuzz: 1.4.1 -> 1.4.5

Upgrade harfbuzz from 1.4.1 to 1.4.5. Signed-off-by: Huang Qiyu --- .../harfbuzz/{harfbuzz_1.4.1.bb => harfbuzz_1.4.5.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/harfbuzz/{harfbuzz_1.4.1.bb =>

Re: [OE-core] [PATCH] ed: 1.14.1 -> 1.14.2

Sorry,I didn't see it before. Thanks for your feedback. huangqy > -Original Message- > From: Chang, Rebecca Swee Fun [mailto:rebecca.swee.fun.ch...@intel.com] > Sent: Wednesday, April 12, 2017 11:44 AM > To: Huang, Qiyu/黄 琦宇 ; >

[OE-core] [PATCH] python3-git: upgrade from 2.1.1 to 2.1.3

This is a minimal update for git module of python 3 Signed-off-by: Edwin Plauchu --- meta/recipes-devtools/python/python-git.inc | 4 ++-- .../python/{python3-git_2.1.1.bb => python3-git_2.1.3.bb} | 0 2 files changed,

[OE-core] [PATCH 2/4] oe-find-native-sysroot: work with RSS

From: Robert Yang The generic STAGING_DIR_NATIVE is gone since RSS, so when find OECORE_NATIVE_SYSROOT, the user has to specify which recipe's STAGING_DIR_NATIVE will be used as OECORE_NATIVE_SYSROOT. * The usage is changed from ". oe-find-native-sysroot" to ".

[OE-core] [PATCH 3/4] oe-find-native-sysroot: add appopriate suggestion

right now, if it fails, the script tells the user to run bitbake foo -caddto_recipe_sysroot. This works for native recipes but not things like meta-ide. This patch checks whether the recipe is native and gives out the appopriate warning. Signed-off-by: brian avery ---

[OE-core] [PATCH 1/4] Revert "scripts: change way we find native tools (pseudo)"

From: Ed Bartosh This reverts commit f200f37699031cd98f4594b2992e6b0d8f753440. This reverts the patch that fixed runqemu-extract-sdk. It failed to fix other issues in the script/tools that were introduced by RSS. The following patch from Robert Yang fixes both.

[OE-core] [PATCH 4/4] oe-run-native: explicitly use bash

This script sources another script (oe-find-native-sysroot) with arguments. It was using /bin/sh. Sourcing with arguments works only in bash so it was failing in dash. This commit makes it dash proof. Signed-off-by: brian avery --- scripts/oe-run-native | 2 +- 1 file

[OE-core] [PATCH 0/4] scripts: rss fixes for oe-find-sysroot and oe-run-native

This patch set does a couple of things: 1) revert brian's runqemu-extract-sdk patch and add in Robert's more generically useful patch. 2) Correct the suggestion oe-find-native gives if bitbake meta-ide-support has not been run 3) fix a /bin/sh to bin/bash since the script used bashisms and was

Re: [OE-core] [PATCH] base-passwd/useradd: Various improvements to useradd with RSS

This looks great. It is very close to how I had envisioned how this needed to be solved. I will put it to the test tomorrow. Some comments below. > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On

[OE-core] [PATCH] sstate.bbclass: check if mirror directory is writable

Commit 51edde653707e7a3cd2186082458f01f32cd1996 makes a wrong assumption that SSTATE_MIRRORS have write permissions. A mirror is by definition outside of it's user control. In my use case it happens I does not have permissions to update the access time of the dereferenced symbolic-link file.

[OE-core] [PATCH 3/5] runqemu: add bindir_native property

Isolated logic of getting path to native bin directory in new bindir_native property method. This property is going to be used to obtain location of qemu-sytem and tunctl. Signed-off-by: Ed Bartosh --- scripts/runqemu | 37 - 1

[OE-core] [PATCH 2/5] runqemu: get qemu from qemu-helper-native sysroot

If rm_work is enabled image native sysroot can be removed. This makes runqemu to fail trying to find qemu binary. Used native sysroot of qemu-helper-native to find system qemu binary. Signed-off-by: Ed Bartosh --- scripts/runqemu | 13 - 1 file changed,

[OE-core] [PATCH 4/5] runqemu: use bindir_native property to run ifup/down scripts

Used self.bindir_native to point out to the native sysroot when running runqemu-ifup and runqemu-ifdown scripts. [YOCTO #11266] [YOCTO #11193] Signed-off-by: Ed Bartosh --- scripts/runqemu| 4 ++-- scripts/runqemu-ifdown | 6 +++--- scripts/runqemu-ifup |

[OE-core] [PATCH 5/5] qemuboot: write native sysroot of qemu-helper into qemuboot.conf

Native sysroot of qemu-helper contains all required tools (qemu-system and tunctl atm) for runqemu to work. It's not removed by rm_dir and should always exist. It makes sense to write it into qemuboot.conf to make runqemu to use it as a default directory for native tools. This should also speed

[OE-core] [PATCH 1/5] qemu-helper-native: prepare native sysroot for runqemu

From: brian avery Make sure that native sysroot contains qemu and tunctl binaries for runqemu usage: - excluded native sysroot from rm_work - added qemu-native to DEPENDS to put qemu binaries into native sysroot - forced addto_recipe_sysroot task [YOCTO #11266]

[OE-core] [PATCH 0/5] Make runqemu to work when rm_work is enabled

Hi, runqemu fails when rm_work is enabled as it can't get qemu-system and tunctl binaries from the native sysroot as it's removed by rm_work. This is fixed by disabling removal of the qemu-helper-native sysroot directory and changing runqemu code to run qemu-system and tunctl from it. [YOCTO

[OE-core] [PATCH] meta: classes: Add building dir to uImage creation

On the do_uboot_mkimage task from kernel-uimage.bbclass, in case KEEPUIMAGE is different than the default "yes" value, the uboot-mkimage command fails because the path of the created uImage does not exist. On this task, we are under the BUILDDIR so there is no folder arch//boot. Add the ${B} (for

[OE-core] [PATCH] oe-build-perf-report-email.py: use pwd for getting user name

Use pwd data instead of os.getlogin() to get the username for fallback email address. os.getlogin() basically returns the name of the user logged in on the controlling terminal of the process and raises an exception on some systems if the process does not have a controlling terminal - when

[OE-core] [PATCH] oe-selftest: Error if known problem variables are set

Setting SANITY_TESTED_DISTROS or PRSERV_HOST are known to break oe-selftest. Rather than have the user experience this, refuse to execute unless the environment is correct. Ideally we'd try and unset these but that is a more invasive change and this at least makes people aware of the problem.

[OE-core] [PATCH] base-passwd/useradd: Various improvements to useradd with RSS

Currently there are multiple issues with useradd: * If base-passwd rebuilds, it wipes out recipe specific user/group additions to sysroots and causes errors * If recipe A adds a user and recipe B depends on A, it can't see any of the users/groups A adds. This patch changes base-passwd so it

Re: [OE-core] [PATCH v2] kmscube: add recipe

On 04/12/2017 03:14 PM, Carlos Rafael Giani wrote: This is a demo application that draws a three-dimensional spinning cube using EGL on top of KMS, via Mesa's GBM library. A rough counterpart to glxgears, it is a useful tool for BSP makers to try the 3D rendering functionality based on EGL and

[OE-core] [PATCH] oeqa/core/runner: Append PID in the test result folder name

From: Leonardo Sandoval It was found a case (see the bugzilla entry) where two runners were running at the same second, creating identical test result folders, so one of them (the second runner) was not able to create the folder because the other has

[OE-core] [PATCH v5 1/2] yocto-compat-layer: test signature differences when setting MACHINE

Selecting a machine is only allowed to affect the signature of tasks that are specific to that machine. In other words, when MACHINE=A and MACHINE=B share a recipe foo and the output of foo, then both machine configurations must build foo in exactly the same way. Otherwise it is not possible to

[OE-core] [PATCH v5 0/2] yocto-compat-layer: per machine checks

It is important to test with real MACHINE values, otherwise changes introduced by layers only when their machines are selected wouldn't show up. The new test_machine_signatures and test_machine_world tests cover two aspects of that (signature differences and world build failures). V2: - use

[OE-core] [PATCH v5 2/2] yocto-compat-layer: better handling of per-machine world build breakage

It is fairly common that BSP layers enable recipes when choosing machines from that layer without checking whether the recipe actually builds in the current distro. That breaks "bitbake world", retrieving signatures and thus the test_machine_signatures test. It's better to let that test continue

Re: [OE-core] [PATCH v3 0/3] Set linux-firmware to correct license

On Sun, 2017-04-09 at 18:58 -0700, wei.tee...@intel.com wrote: > From: "Ng, Wei Tee" > > This is the revised version to fix the ipk packaging error as below: > ERROR: linux-firmware-1_0.0+gitAUTOINC+b14134583c-r0 > do_package_write_ipk: Function failed: do_package_ipk > >

[OE-core] Using boost-program-options and native

Hey all! I want to build a tool which makes use of boost-program-options lib. As long as I compile for the target, all is fine, but when I add > BBCLASSEXTEND += "native" to my recipe, I a bitbake error "Nothing Provides" ... :( > ERROR: Required build target 'mytool-native' has no buildable

Re: [OE-core] [PATCH] python3: Use _sysconfigdata.py to initialize distutils.sysconfig

On 2017-04-12 14:51, Bruce Ashfield wrote: On Wed, Apr 12, 2017 at 1:15 AM, Li Zhou > wrote: Porting patch from

Re: [OE-core] [PATCH] python3: Use _sysconfigdata.py to initialize distutils.sysconfig

On Wed, Apr 12, 2017 at 1:15 AM, Li Zhou wrote: > Porting patch from > b23d934159> > to use _sysconfigdata.py to initialize distutils.sysconfig. > But what does this actually do ? I'm sure it is

[OE-core] [PATCH v2] kmscube: add recipe

This is a demo application that draws a three-dimensional spinning cube using EGL on top of KMS, via Mesa's GBM library. A rough counterpart to glxgears, it is a useful tool for BSP makers to try the 3D rendering functionality based on EGL and OpenGL ES in a KMS environment, without having to set

Re: [OE-core] [PATCH] gnome-common: add EXTRA_OECONF "--with-autoconf-archive"

On 04/12/2017 01:52 PM, Zhixiong Chi wrote: At the same time, set the RDEPENDS for gnome-common. --- a/meta/recipes-gnome/gnome/gnome-common_3.18.0.bb +++ b/meta/recipes-gnome/gnome/gnome-common_3.18.0.bb +RDEPENDS_${PN} = "autoconf-archive" You cannot make oe-core recipes depend on recipes

[OE-core] [PATCH] gnome-common: add EXTRA_OECONF "--with-autoconf-archive"

After updating the autoconf-archive version to 2016.09.16, autoconf-archive installs the same ax_*.m4 macros that gnome-common installs. So there will be the conflict occurs. The option '--with-autoconf-archive' is passed to configure, the macros are not installed, and gnome-common will not

[OE-core] [PATCH 2/4] devtool: add: fix node.js/npm handling with recipe specific sysroots

The change over to recipe specific sysroots means that we can no longer get a known location simply from configuration for the npm binary - we need to get the recipe sysroot for nodejs-native, look there for npm if we need to check it's present, and add that to PATH when calling out to npm.

[OE-core] [PATCH 4/4] recipetool: create: hide missing npm error when called from devtool

If devtool is called with a URL to a source repository containing a node.js module, we don't know that until recipetool has fetched it, and due to the structure of the code we have to exit with a special code in order to let devtool know it needs to build nodejs-native. We also want to suppress

[OE-core] [PATCH 1/4] recipetool: create: fix for regression in npm license handling

OE-Core commit c0cfd9b1d54b05ad048f444d6fe248aa0500159e added handling for AND / OR in license strings coming from npm, but made the assumption that an & would always be present in the license value. Check if it's there first so we don't fail if it isn't. Signed-off-by: Paul Eggleton

[OE-core] [PATCH 3/4] devtool: add: prevent repeatedly running recipetool

If recipetool returns with exit code 14 this means devtool needs to build nodejs-native and then call it again. If recipetool returns exit code 14 again then clearly something has gone wrong and we should just quit with an error. Signed-off-by: Paul Eggleton ---

[OE-core] [PATCH 0/4] devtool / recipetool fixes for node.js modules

This fixes a few regressions in master in handling devtool add on node.js modules relative to morty. The following changes since commit 210c518ba8f8d6ec6e9d34e0df8b963a3b2e0593: ptest-runner: Upgrade to minor version 2.0.2 (2017-04-11 18:09:21 +0100) are available in the git repository at:

[OE-core] [PATCH 1/1] blacklist.bbclass: fix for multilib

* Fixed: The netmap has been blacklisted in meta-networking/recipes-kernel/netmap/netmap_git.bb, but lib32-netmap still can be built (suppose it doesn't depend on another broken recipe netmap-modules, it is a little complicated, will talk below): $ bitbake lib32-netmap This is

[OE-core] [PATCH 0/1] blacklist.bbclass: fix for multilib

The following changes since commit 210c518ba8f8d6ec6e9d34e0df8b963a3b2e0593: ptest-runner: Upgrade to minor version 2.0.2 (2017-04-11 18:09:21 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/blacklist

Re: [OE-core] M4 rc1 build prerequisites

On Tuesday, 11 April 2017 11:10:40 PM NZST Richard Purdie wrote: > I just wanted to give people an idea of where we're at with 2.3. I'm > aware of and would like to see the following issues fixed: > > a) runqemu and other tools failing in various circumstances due to RSS. > > b) DISTRO_FEATURES

Re: [OE-core] [PATCH] kernel.bbclass: Use the correct path of kernel build image file except for vmlinux

[Adding the maintainer - Richard P] The log is a bit descriptive. In short, we would like to compress and use the arch/arm/boot/Image for cases like AARCH64. Best Regards Kunihiko Hayashi On Thu, 30 Mar 2017 00:57:23 + wrote: > Use the correct path of kernel

Re: [OE-core] having llvm available for gallium

On Wed, Apr 12, 2017 at 03:22:52AM -0400, Trevor Woerner wrote: > On Tue, Apr 11, 2017 at 2:52 AM, Martin Jansa wrote: > > Check this: > > > > http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135050.html > > Excellent! That works for me :-) > > Is

Re: [OE-core] having llvm available for gallium

On Tue, Apr 11, 2017 at 2:52 AM, Martin Jansa wrote: > Check this: > > http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135050.html Excellent! That works for me :-) Is this a fix, or a work-around? Is this something that's going to be applied, or is a