Re: [OE-core] [PATCH] mesa: potentially enable texture float for gallium

Hi Richard, Thanks for your review. On Mon, May 29, 2017 at 7:25 PM, Richard Purdie wrote: > On Fri, 2017-05-26 at 17:22 -0400, Trevor Woerner wrote: >> Somewhere along the path from OpenGL ES 2.0 to OpenGL ES 3.0 are some >> algorithms that are encumbered by

[OE-core] [PATCH] ltp: upgrade to 20170516

1. Upgrade ltp from 20170116 to 20170516 2. Rename and Rebase patch file on 20170516 0034-periodic_output.patch to 0034-Add-periodic-output-for-long-time-test.patch 3. Delete the unnecessary patch 0039-fcntl-fix-the-time-def-to-use-time_t.patch 4. Update the md5sum of licesce file

[OE-core] [PATCHv3 0/2] devshell: make sure toolchains are populated in sysroot

From: Chang Rebecca Swee Fun Rework on PATCHv2. addtask do_prepare_recipe_sysroot is having the same effect on building more dependencies for devshell. The 2nd patch in series is to clean up some trailing whitespaces within devshell.bbclass. I have done some

Re: [OE-core] [PATCH 1/2] devshell.bbclass: ensure toolchains available for do_devshell

Hi Richard, On Tuesday, 30 May 2017 11:31:36 AM NZST Richard Purdie wrote: > On Mon, 2017-05-29 at 13:16 +0800, Chang Rebecca Swee Fun wrote: > > Toolchains are required to be prepopulated in sysroot before > > entering devshell. > > > > [YOCTO #11464] > > > > Signed-off-by: Chang Rebecca Swee

Re: [OE-core] [PATCH 1/2] devshell.bbclass: ensure toolchains available for do_devshell

On Mon, 2017-05-29 at 13:16 +0800, Chang Rebecca Swee Fun wrote: > Toolchains are required to be prepopulated in sysroot before > entering devshell. > > [YOCTO #11464] > > Signed-off-by: Chang Rebecca Swee Fun > --- >  meta/classes/devshell.bbclass | 11 ++- >  1 file changed, 10

Re: [OE-core] [PATCH] mesa: potentially enable texture float for gallium

On Fri, 2017-05-26 at 17:22 -0400, Trevor Woerner wrote: > Somewhere along the path from OpenGL ES 2.0 to OpenGL ES 3.0 are some > algorithms that are encumbered by patents. These algorithms are > enabled with > mesa's --enable-texture-float configure flag. However, if hardware > acceleration is

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

On Mon, 2017-05-29 at 18:54 +0300, Alexander Kanavin wrote: > I see. You are right here. I admit I don't fully understand if it's  > generally okay for -native recipes to look around in (and later use)  > host include  directories like that, as we're striving towards  > reproducible builds, and

Re: [OE-core] [PATCH 2/2] import: new plugin to import the devtool workspace

On Friday, 26 May 2017 9:31:48 AM NZST leonardo.sandoval.gonza...@linux.intel.com wrote: > From: Leonardo Sandoval > > Takes a tar archive created by 'devtool export' and export it (untar) to > workspace. By default, the whole tar archive is imported,

Re: [OE-core] [PATCH 1/2] export: new plugin to export the devtool workspace

Hi Leo, A few notes below. On Friday, 26 May 2017 9:31:47 AM NZST leonardo.sandoval.gonza...@linux.intel.com wrote: > From: Leonardo Sandoval > > By default, exports the whole workspace (all recipes) including the source > code. > User can also

Re: [OE-core] [PATCH v3] package_ipk: correct ipk multiline descriptions

On Mon, 29 May 2017 10:36:47 -0700 leonardo.sandoval.gonza...@linux.intel.com wrote: > From: Leonardo Sandoval > > Empty descriptions lines are set with a space following by a dot and > the multiline ones require a leading space. Also, for non-empty

[OE-core] KERNEL_IMAGETYPES and Image.gz

hi, i am trying to set KERNEL_IMAGETYPES="Image.gz" in my machine conf file. But it doesn't work. I am seeing this error during kernel_do_compile(): run.do_compile.30019: cannot open Image: No such file In fact the code snippet that tries to compress the Image file into Image.gz expects the

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

Ping on this series (#6793 in Patchwork). -- ddiaz On 18 May 2017 at 13:22, Daniel Díaz wrote: > While building for Hikey using Mali 450 driver (r6p0), an > error like the following appears while linking: > > [ 1%] Linking C shared library

Re: [OE-core] [PATCH 3/6] yocto-compat-layer.py: apply test_signatures to all layers

On Mon, May 29, 2017 at 12:26 PM, Aníbal Limón wrote: > > > > Changing software versions is indeed a bit more problematic. One could > > argue that layers shouldn't fight over who provides a certain recipe in > > the first place. If they do, perhaps the "additional

Re: [OE-core] [PATCH 3/6] yocto-compat-layer.py: apply test_signatures to all layers

On 05/29/2017 02:18 PM, Patrick Ohly wrote: > On Mon, 2017-05-29 at 11:13 -0500, Aníbal Limón wrote: >> On 05/29/2017 10:32 AM, Patrick Ohly wrote: >>> Software layers were previously allowed to change signatures, but >>> that's not desired for those layers either. The rule that a layer >>>

Re: [OE-core] [PATCH 3/6] yocto-compat-layer.py: apply test_signatures to all layers

On Mon, 2017-05-29 at 11:13 -0500, Aníbal Limón wrote: > On 05/29/2017 10:32 AM, Patrick Ohly wrote: > > Software layers were previously allowed to change signatures, but > > that's not desired for those layers either. The rule that a layer > > which is "Yocto Compatible 2.0" must not change

[OE-core] [PATCH v3] package_ipk: correct ipk multiline descriptions

From: Leonardo Sandoval Empty descriptions lines are set with a space following by a dot and the multiline ones require a leading space. Also, for non-empty lines, there is no need for formating with textwrap, so remove the logic for the latter. The

Re: [OE-core] [PATCH v2] package_ipk: correct ipk descriptions

On Wed, 2017-05-24 at 23:08 +0100, Burton, Ross wrote: > > On 24 May 2017 at 21:47, Leonardo Sandoval > wrote: > I will check that particular recipe and bb world just so see > if some > other recipe is broken with this change,

Re: [OE-core] [PATCH 0/6] yocto-compat-layer.py: various enhancements

Most of the patches looks good, i only have comments on: - yocto-compat-layer.py: apply test_signatures to all layers For the rest: Acked-by: Aníbal Limón Cheers, Anibal On 05/29/2017 10:32 AM, Patrick Ohly wrote: > While enhancing the layer structure in

Re: [OE-core] [PATCH 3/6] yocto-compat-layer.py: apply test_signatures to all layers

On 05/29/2017 10:32 AM, Patrick Ohly wrote: > Software layers were previously allowed to change signatures, but > that's not desired for those layers either. The rule that a layer > which is "Yocto Compatible 2.0" must not change signatures unless > explicitly requested holds for all kinds of

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

On 05/29/2017 04:06 PM, Max Krummenacher wrote: +- # check if rpm contains a bundled berkeley db +- CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H) ++ set(HAVE_RPM_DB_H 0) Have you looked into what CHECK_INCLUDE_FILE does, and whether it can be fixed? I'd like to hear about your findings.

[OE-core] [PATCH 2/6] yocto-compat-layer.py: tolerate broken world builds during signature diff

The "test_signatures" test ignored a broken world build when getting signatures, but the code which then tried to analyze a difference found by the test didn't, which prevented printing the difference. Signed-off-by: Patrick Ohly --- scripts/lib/compatlayer/__init__.py

[OE-core] [PATCH 3/6] yocto-compat-layer.py: apply test_signatures to all layers

Software layers were previously allowed to change signatures, but that's not desired for those layers either. The rule that a layer which is "Yocto Compatible 2.0" must not change signatures unless explicitly requested holds for all kinds of layers. Signed-off-by: Patrick Ohly

[OE-core] [PATCH 1/6] yocto-compat-layer.py: avoid adding layers more than once

add_layer_dependencies() might get called more than once, or one of the layer dependencies might already be present. The function should not add layers again because doing so can cause warnings like: WARNING: Duplicate inclusion for

[OE-core] [PATCH 5/6] yocto-compat-layer.py: allow README with suffix

It may be useful to append a suffix denoting the file format. For example, README.rst is rendered differently when viewed on Github, and also helps editors to switch to a mode more suitable for the format. The tests uses a file pattern to find the README file(s) and treats the one with the

[OE-core] [PATCH 6/6] yocto-compat-layer.py: make signature check code reusable

This moves the main content of test_signature into a helper function. It can be reused by arbitrary tests that need to do a before/after signature comparison. Long-term this might even be useful in oeqa itself. Signed-off-by: Patrick Ohly ---

[OE-core] [PATCH 4/6] yocto-compat-layer.py: add test_world

"test_signatures" ignores wold build breakage for the sake of reporting differences also when a world build is broken. Therefore we need a dedicated test that a world build at least theoretically can proceed without obvious parse time problems (dependencies, parse errors, dangling .bbappends,

[OE-core] [PATCH 0/6] yocto-compat-layer.py: various enhancements

While enhancing the layer structure in intel-iot-refkit I ran into various cases where enhancements to the tool were necessary. intel-iot-refkit now has oe-selftests that check all layers using this tool. In addition, the signature checking utility code is imported into a custom test that also

[OE-core] [PATCH 0/1] bblayers sanity: bblayers.conf.sample specific update code

In an experimental branch of refkit I bumped LCONF_VERSION from 4 to 5 and ran into the problem mentioned in the commit message: instead of raising an error as before, the code (incorrectly) claimed to have updated the bblayers.conf file. Perhaps refkit should have started with LCONF_VERSION as

[OE-core] [PATCH 1/1] bblayers sanity: bblayers.conf.sample specific update code

The code in sanity.bbclass was executed for all distros, regardless whether they use the same numbering of bblayers.conf.sample as OE-core. This is problematic for distros which started at LCONF_VERSION=1: once they reach the 5 to 7 (inclusive) number range, the code from sanity.bbclass kicks in

[OE-core] [PATCH 1/2] mmc-utils: Upgrade to latest git version

Updates in the new version: 37c86e6 : mmc-utils: Check for ext_csd_rev only once c22a92f : mmc-utils: feature spec 5.0+, Pre EOL information 34a954b : mmc-utils: feature spec 5.0+, device life time estimation for MLC and pSLC mode Signed-off-by: Maxin B. John

[OE-core] [PATCH 2/2] bluez5: Upgrade 5.44 -> 5.45

Signed-off-by: Maxin B. John --- meta/recipes-connectivity/bluez5/{bluez5_5.44.bb => bluez5_5.45.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-connectivity/bluez5/{bluez5_5.44.bb => bluez5_5.45.bb} (91%) diff --git

Re: [OE-core] [PATCH 00/36] OEQA threading support and selftest migration

On Mon, 2017-05-29 at 14:19 +0100, Richard Purdie wrote: > On Mon, 2017-05-29 at 08:15 -0500, Leonardo Sandoval wrote: > > On Sat, 2017-05-27 at 00:32 +0100, Richard Purdie wrote: > > > > > > On Fri, 2017-05-26 at 15:37 -0500, Aníbal Limón wrote: > > > > > > > > This series is the integration of

Re: [OE-core] [PATCH 00/36] OEQA threading support and selftest migration

On Mon, 2017-05-29 at 08:15 -0500, Leonardo Sandoval wrote: > On Sat, 2017-05-27 at 00:32 +0100, Richard Purdie wrote: > > > > On Fri, 2017-05-26 at 15:37 -0500, Aníbal Limón wrote: > > > > > > This series is the integration of tree main changes into the OEQA > > > module, > > > > > > *

Re: [OE-core] [PATCH 00/36] OEQA threading support and selftest migration

On Sat, 2017-05-27 at 00:32 +0100, Richard Purdie wrote: > On Fri, 2017-05-26 at 15:37 -0500, Aníbal Limón wrote: > > This series is the integration of tree main changes into the OEQA > > module, > > > > * Implement threading support into OEQA core module > > * Enables OEQA threaded mode into

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

2017-05-29 15:00 GMT+02:00 Max Krummenacher : > 2017-05-29 12:50 GMT+02:00 Alexander Kanavin > : >> On 05/26/2017 11:35 PM, Max Krummenacher wrote: >>> >>> +- # check if rpm contains a bundled berkeley db >>> +- CHECK_INCLUDE_FILE(rpm/db.h

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

2017-05-29 12:50 GMT+02:00 Alexander Kanavin : > On 05/26/2017 11:35 PM, Max Krummenacher wrote: >> >> +- # check if rpm contains a bundled berkeley db >> +- CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H) >> ++ set(HAVE_RPM_DB_H 0) > > > Have you looked into what

[OE-core] [PATCH] ghostscript: CVE-2016-7977, CVE-2016-7978, CVE-2016-7979, CVE-2017-9216

Ghostscript before 9.21 might allow remote attackers to bypass the SAFER mode protection mechanism and consequently read arbitrary files via the use of the .libfile operator in a crafted postscript document. Use-after-free vulnerability in Ghostscript 9.20 might allow remote attackers to execute

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

On 05/26/2017 11:35 PM, Max Krummenacher wrote: +- # check if rpm contains a bundled berkeley db +- CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H) ++ set(HAVE_RPM_DB_H 0) Have you looked into what CHECK_INCLUDE_FILE does, and whether it can be fixed? I'd like to hear about your findings.

Re: [OE-core] [PATCH] boost: backport a regression fix for forgotten header

On Mon, 2017-05-15 at 14:54 +0300, Dmitry Rozhkov wrote: > The v1.64 release has broken array serialization code with issues > reported in > > https://svn.boost.org/trac/boost/ticket/12516 > https://github.com/bmwcarit/meta-ros/issues/505 > > Backport the fix from boost::serialization's master.

[OE-core] [PATCH] libdrm: upgrade to 2.4.81

Signed-off-by: Nicolas Dechesne --- meta/recipes-graphics/drm/{libdrm_2.4.80.bb => libdrm_2.4.81.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/drm/{libdrm_2.4.80.bb => libdrm_2.4.81.bb} (93%) diff --git

[OE-core] [PATCH] kmscube: upgrade version

Upgrade to a more recent kmscube commit from git. Tested on DB410c and DB820c with s/w and h/w codecs (v4l2). Signed-off-by: Nicolas Dechesne --- meta/recipes-graphics/kmscube/kmscube_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [OE-core] [pyro] [PATCH] cryptodev-linux: update SRC_URI

Hi Maxin, > -Original Message- > From: John, Maxin > Sent: Monday, May 29, 2017 3:50 PM > To: Chang, Rebecca Swee Fun > Cc: OpenEmbedded Core Mailing List c...@lists.openembedded.org> > Subject: Re: [OE-core] [pyro] [PATCH] cryptodev-linux: update

Re: [OE-core] [pyro] [PATCH] cryptodev-linux: update SRC_URI

Hi Rebecca, On Fri, May 26, 2017 at 03:07:01PM +0800, Chang Rebecca Swee Fun wrote: > Gna! project announced that the download site from gna.org HTTP server > will soon be closing down. We have verified that the site is no longer > accessible without network proxy cache. We need to update SRC_URI

Re: [OE-core] What's the "proper" way to start WiFi networking?

On 24-05-17 14:58, Mike Looijmans wrote: For boards that offer WiFi, I'd want them to connect more or less automatically. I was wondering if there were better ways than handcrafting shell scripts to do this on a headless embedded board? If I put wpa-conf into /etc/network/interfaces it

[OE-core] [PATCH v2] elfutils: Upgrade 0.168 to 0.169

1) Upgrade elfutils from 0.168 to 0.169 2) Delete unnecessary patches which has been merged into 0.169 3) Rebase the patch files for 0.169 Signed-off-by: Fan Xin --- .../elfutils-0.168/Fix_one_GCC7_warning.patch | 44 ---

[OE-core] [PATCH v2 2/4] masterimage.py: rename parameter "params" in start() to "extra_bootparams"

This matches how it is called, and how it is named in qmeu target. [YOCTO #11524] Signed-off-by: Erik Botö --- meta/lib/oeqa/controllers/masterimage.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oeqa/controllers/masterimage.py

[OE-core] [PATCH v2 1/4] masterimage.py: fix issue with calling reboot on masterimage/DUT

On systemd systems calling reboot over an ssh connection doesn't return as expected causing an exception, therefore wrap the call to reboot in order to avoid this issue. [YOCTO #11524] Signed-off-by: Erik Botö --- meta/lib/oeqa/controllers/masterimage.py | 2 +- 1

[OE-core] [PATCH v2 3/4] masterimage.py: fix stop()

The stop() function is called in the context of the masterimage, so self.master should be used instead of self.connection which is undefined at that time. [YOCTO #11524] Signed-off-by: Erik Botö --- meta/lib/oeqa/controllers/masterimage.py | 2 +- 1 file changed, 1

[OE-core] [PATCH v2 4/4] sshcontrol.py: in copy_to() always use scp

The current implementation is broken when the localpath is a link. Then only a symlink would be created on the target, instead of copying the actual file. [YOCTO #11524] Signed-off-by: Erik Botö --- meta/lib/oeqa/utils/sshcontrol.py | 9 +++-- 1 file changed, 3

[OE-core] [PATCH v2 0/4] oeqa: fix runtime testing using systemd-boot target

When I was setting up automated runtime testing using the systemd-boot target I hit a couple of bugs that I addressed. There is an open bug on this in Yocto Bugzilla #11524. Changes since v1: Added cover letter and references bug from commit msgs Cheers, Erik

Re: [OE-core] What's the "proper" way to start WiFi networking?

On 24-05-17 15:12, Nicolas Dechesne wrote: On Wed, May 24, 2017 at 2:58 PM, Mike Looijmans wrote: I was wondering if there were better ways than handcrafting shell scripts to do this on a headless embedded board? If I put wpa-conf into /etc/network/interfaces it

Re: [OE-core] What's the "proper" way to start WiFi networking?

On 24-05-17 15:12, Nicolas Dechesne wrote: On Wed, May 24, 2017 at 2:58 PM, Mike Looijmans wrote: I was wondering if there were better ways than handcrafting shell scripts to do this on a headless embedded board? If I put wpa-conf into /etc/network/interfaces it