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

Porting patch from to use _sysconfigdata.py to initialize distutils.sysconfig. Signed-off-by: Li Zhou --- ...-Use-_sysconfigdata.py-to-initialize-dist.patch | 66 ++ meta/recipes-devtools/pyth

[OE-core] [PATCH 0/4] linux-yocto: -stable version bumps

Hi all, This series is a bump of the linux-yocto trees to the latest -stable releases for our supported versions. This should be the last round of updates for the 2.3 release. I'll continue to do updates to the trees, but won't send SRCREVs updates unless required. I've also bumped linux-yocto-d

[OE-core] [PATCH 2/4] linux-yocto/4.9: update to v4.9.21

Updating to the korg -stable release, with the following shortlog summary: 37feaf8095d3 Linux 4.9.21 02b23e059a9d nvme/pci: Disable on removal when disconnected a5e39a7f2985 nvme/core: Fix race kicking freed request_queue eb8c62a3848e padata: avoid race in reordering 5959cded91e3 bl

[OE-core] [PATCH 3/4] linux-yocto/4.4: update to v4.4.60

Updating to the korg stable relase with the following shortlog summary: 8f8ee9706b0a Linux 4.4.60 84bd21a708b8 padata: avoid race in reordering 5cca175b6cda blk: Ensure users for current->bio_list can see the full list. 2cbd78f4239b blk: improve order of bio handling in generic_make_re

[OE-core] [PATCH 4/4] linux-yocto-dev: update to v4.11+

Signed-off-by: Bruce Ashfield --- meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb b/meta/recipes-kernel/linux/linux-yocto-dev.bb index 444ee4111ded..bf67f81f0772 100644 --- a/meta/recipe

[OE-core] [PATCH 1/4] linux-yocto/4.10: update to v4.10.9

Updating to the korg stable release, with the following changes: f6392b77fb91 Linux 4.10.9 59529be9c99e drm/i915: A hotfix for making aliasing PPGTT work for GVT-g 0efab45f7092 drm/i915: Let execlist_update_context() cover !FULL_PPGTT mode. e47bc4fb5db4 drm/i915: Move the release of PT

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

>Upgrade ed from 1.14.1 to 1.14.2. > > Signed-off-by: Huang Qiyu > --- > meta/recipes-extended/ed/{ed_1.14.1.bb => ed_1.14.2.bb} | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes- > extended/ed/{ed_1.14.1.bb => ed_1.14.2.bb} (84%) > > diff --git a/meta/recipes-ext

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

Upgrade ed from 1.14.1 to 1.14.2. Signed-off-by: Huang Qiyu --- meta/recipes-extended/ed/{ed_1.14.1.bb => ed_1.14.2.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-extended/ed/{ed_1.14.1.bb => ed_1.14.2.bb} (84%) diff --git a/meta/recipes-extended/ed/ed_1.14.1

Re: [OE-core] [PATCH] libsdl: enable X11 for nativesdk

On 04/11/2017 10:14 AM, Richard Purdie wrote: On Tue, 2017-04-11 at 09:34 -0700, akuster808 wrote: On 04/06/2017 12:55 PM, Martin Kelly wrote: From: Martin Kelly Currently, the following situation fails: - Build an SDK and image. Make the image support graphics but not X11. - Extract SDK a

Re: [OE-core] [PATCHv3 1/1] native/nativesdk: Use fixed DISTRO_FEATURES

On Tue, 2017-04-11 at 18:06 +, Peter Kjellerstedt wrote: > > > > -Original Message- > > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > > Se > > On Tue, 2017-04-11 at 15:32 +, Peter Kjellerstedt wrote: > > >  > > > > +# Set features here to prevent appends an

[OE-core] [PATCH v4 6/8] yocto-compat-layer: add --additional-layers

The new --addditional-layers parameter takes a list of layer directories and adds them to the build configuration before starting testing. The resulting base configuration then more closely matches a full distro. This is relevant in two cases: 1. some layers like meta-freescale dynamically enable

[OE-core] [PATCH v4 4/8] yocto-compat-layer: include bitbake-diffsigs output

After filtering out potential false positives, it becomes feasible to include the output of bitbake-diffsigs for those tasks which definitely have a change. Depends on bitbake-diffsigs with the "--signature" parameter. Enhanced output now is: AssertionError: False is not true : Layer meta-xxx

[OE-core] [PATCH v4 7/8] 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 use

[OE-core] [PATCH v4 8/8] 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 w

[OE-core] [PATCH v4 3/8] recipes/*-cross recipes: ignore TARGET_ARCH sstate hash

"yocto-compat-layer.py --machines" showed that shared packages like gcc-cross-powerpc64 have a sstate signature that depends on TUNEFLAGS. As a result, there are unnecessary rebuilds and potential conflicts in a multiconfig. That's due to the way how TARGET_ARCH is set. Richard Purdie suggested se

[OE-core] [PATCH v4 5/8] yocto-compat-layer: also determine tune flags for each task

locked-sigs.inc groups tasks according to their tune flags (allarch, i586, etc.). Also retrieve that information while getting signatures, it will be needed to determine when setting a machine changes tasks that aren't machine-specific. Signed-off-by: Patrick Ohly --- scripts/lib/compatlayer/__i

[OE-core] [PATCH v4 2/8] gdb-cross: avoid tune specific paths

gdb-cross used to be specific to the tune flags, but isn't anymore. Therefore it is enough to use TARGET_SYS instead of TUNE_PKGARCH to create a unique path. Fixes a sstate signature difference that was found via yocto-compat-layer.py's test_machine_signatures check. In practice it probably showed

[OE-core] [PATCH v4 0/8] yocto-compat-layer: bitbake-diffsigs support + per machine checks + OE-core fixes

Manually calling bitbake-diffsigs is cumbersome and doesn't work in a CI environment, so now the test itself does it for test_signatures. Regarding the BSP example that I ended up using: it actually was one of the better BSP layers and only had one problem in a "bitbake world" build instead of sev

[OE-core] [PATCH v4 1/8] go-cross: avoid libgcc dependency

libgcc gets compiled differently depending on the tune flags for the target. That dependency would make go-cross also tune specific and prevent sharing it between different machines using the same architecture. For example, MACHINE=intel-corei7-64 and MACHINE=qemux86-64 shared the same go-cross-x8

[OE-core] ✗ patchtest: failure for wic-image-minimal: stop using core-image-minimal

== Series Details == Series: wic-image-minimal: stop using core-image-minimal Revision: 1 URL : https://patchwork.openembedded.org/series/6302/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been

Re: [OE-core] [PATCH v3 3/8] -cross recipes: ignore TARGET_ARCH sstate hash

On Tue, 2017-04-11 at 19:25 +0100, Richard Purdie wrote: > I'd tweak the subject line to recipes/*-cross: > > On Tue, 2017-04-11 at 16:56 +0200, Patrick Ohly wrote: > > "yocto-compat-layer.py --machines" showed that shared packages like > > gcc-cross-powerpc64 have a sstate signature that depends

Re: [OE-core] go-cross: incorrect dependency on tune-specific libgcc

On Tue, 2017-04-11 at 10:01 -0700, Khem Raj wrote: > On Tue, Apr 11, 2017 at 9:52 AM, Patrick Ohly wrote: > > On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote: > >> I think TUNE_PKGARCH is the granularity it needs for setting GOARM > >> anyway. > > > > So you are saying the patch that I had propo

Re: [OE-core] [PATCH v3 3/8] -cross recipes: ignore TARGET_ARCH sstate hash

I'd tweak the subject line to recipes/*-cross: On Tue, 2017-04-11 at 16:56 +0200, Patrick Ohly wrote: > "yocto-compat-layer.py --machines" showed that shared packages like > gcc-cross-powerpc64 have a sstate signature that depends on > TUNEFLAGS. As a result, there are unnecessary rebuilds and pot

[OE-core] [PATCH] wic-image-minimal: stop using core-image-minimal

Removed dependency to core-image-minimal rootfs from the recipe and .wks file. This was a bad idea as recipes are not allowed to use other recipe's rootfs or anything else from workdir. This should also fix test_qemu test case when rm_work is enabled. Signed-off-by: Ed Bartosh --- meta-selftest

Re: [OE-core] go-cross: incorrect dependency on tune-specific libgcc

On Tue, Apr 11, 2017 at 9:57 AM, Richard Purdie wrote: > On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote: >> On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly > > wrote: >> > >> > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote: >> > > >> > > Hello! >> > > >> > > I'm currently extending the yo

Re: [OE-core] [PATCH v3 2/8] gdb-cross: avoid tune specific paths

On 4/11/17 12:19 PM, Richard Purdie wrote: > On Tue, 2017-04-11 at 10:16 -0500, Mark Hatle wrote: >> On 4/11/17 9:56 AM, Patrick Ohly wrote: >>> >>> gdb-cross used to be specific to the tune flags, but isn't >>> anymore. Therefore it is enough to use TARGET_SYS instead of >>> TUNE_PKGARCH to create

Re: [OE-core] [PATCHv3 1/1] native/nativesdk: Use fixed DISTRO_FEATURES

> -Original Message- > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > Sent: den 11 april 2017 19:16 > To: Peter Kjellerstedt ; Jussi Kukkonen > ; openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCHv3 1/1] native/nativesdk: Use fixed > DISTRO_FEATURES

Re: [OE-core] go-cross: incorrect dependency on tune-specific libgcc

On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote: > On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly > wrote: > > > > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote: > > > > > > Hello! > > > > > > I'm currently extending the yocto-compat-layer.py so that it can > > > detect > > > invalid s

Re: [OE-core] [PATCH v3 2/8] gdb-cross: avoid tune specific paths

On Tue, 2017-04-11 at 10:16 -0500, Mark Hatle wrote: > On 4/11/17 9:56 AM, Patrick Ohly wrote: > > > > gdb-cross used to be specific to the tune flags, but isn't > > anymore. Therefore it is enough to use TARGET_SYS instead of > > TUNE_PKGARCH to create a unique path. > Are you sure about this.  O

Re: [OE-core] [PATCH] libsdl: enable X11 for nativesdk

On Tue, 2017-04-11 at 09:34 -0700, akuster808 wrote: > > On 04/06/2017 12:55 PM, Martin Kelly wrote: > > > > From: Martin Kelly > > > > Currently, the following situation fails: > > > > - Build an SDK and image. Make the image support graphics but not > > X11. > > - Extract SDK and copy image

Re: [OE-core] [PATCHv3 1/1] native/nativesdk: Use fixed DISTRO_FEATURES

On Tue, 2017-04-11 at 15:32 +, Peter Kjellerstedt wrote: > > > > -Original Message- > > From: openembedded-core-boun...@lists.openembedded.org > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf > > Of > > Jussi Kukkonen > > Sent: den 11 april 2017 16:36 > > To: ope

Re: [OE-core] go-cross: incorrect dependency on tune-specific libgcc

On Tue, Apr 11, 2017 at 9:52 AM, Patrick Ohly wrote: > On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote: >> On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly wrote: >> > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote: >> >> Hello! >> >> >> >> I'm currently extending the yocto-compat-layer.py

Re: [OE-core] [PATCH v3 2/8] gdb-cross: avoid tune specific paths

On Tue, Apr 11, 2017 at 8:16 AM, Mark Hatle wrote: > On 4/11/17 9:56 AM, Patrick Ohly wrote: >> gdb-cross used to be specific to the tune flags, but isn't >> anymore. Therefore it is enough to use TARGET_SYS instead of >> TUNE_PKGARCH to create a unique path. > > Are you sure about this. On non-i

Re: [OE-core] go-cross: incorrect dependency on tune-specific libgcc

On Tue, 2017-04-11 at 09:39 -0700, Khem Raj wrote: > On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly wrote: > > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote: > >> Hello! > >> > >> I'm currently extending the yocto-compat-layer.py so that it can detect > >> invalid signature changes when cha

Re: [OE-core] go-cross: incorrect dependency on tune-specific libgcc

On Tue, Apr 11, 2017 at 9:34 AM, Patrick Ohly wrote: > On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote: >> Hello! >> >> I'm currently extending the yocto-compat-layer.py so that it can detect >> invalid signature changes when changing MACHINE. go-cross-x86_64 shows >> up as broken when compa

Re: [OE-core] go-cross: incorrect dependency on tune-specific libgcc

On Mon, 2017-04-10 at 14:49 +0200, Patrick Ohly wrote: > Hello! > > I'm currently extending the yocto-compat-layer.py so that it can detect > invalid signature changes when changing MACHINE. go-cross-x86_64 shows > up as broken when comparing signatures for MACHINE=intel-corei7-64 and > MACHINE=qe

Re: [OE-core] [PATCH] libsdl: enable X11 for nativesdk

On 04/06/2017 12:55 PM, Martin Kelly wrote: From: Martin Kelly Currently, the following situation fails: - Build an SDK and image. Make the image support graphics but not X11. - Extract SDK and copy image somewhere outside of the Yocto workspace. Do runqemu on the image. This results in

Re: [OE-core] [PATCH v3 2/8] gdb-cross: avoid tune specific paths

On Tue, 2017-04-11 at 10:16 -0500, Mark Hatle wrote: > On 4/11/17 9:56 AM, Patrick Ohly wrote: > > gdb-cross used to be specific to the tune flags, but isn't > > anymore. Therefore it is enough to use TARGET_SYS instead of > > TUNE_PKGARCH to create a unique path. > > Are you sure about this. It'

Re: [OE-core] M4 rc1 build prerequisites

> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Richard Purdie > Sent: den 11 april 2017 13:11 > To: openembedded-core > Subject: [OE-core] M4 rc1 build prerequisites > > I just wanted

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

On Tue, Apr 11, 2017 at 10:30 AM, Carlos Rafael Giani wrote: > On 2017-04-11 10:26, Alexander Kanavin wrote: > >> On 04/11/2017 10:54 AM, Carlos Rafael Giani wrote: >> >>> This is a useful tool to test KMS and GBM-based EGL & OpenGL ES drawing >>> >> >> Sorry, but the bar for adding recipes to oe

Re: [OE-core] [PATCH] python2/3: Remove building host path from packages

On Tue, 2017-04-11 at 16:03 +0800, Li Zhou wrote: > > Remove building host related path from python2 and python3 packages. > > Signed-off-by: Li Zhou > --- >  meta/recipes-devtools/python/python3_3.5.2.bb | 8 +++- >  meta/recipes-devtools/python/python_2.7.13.bb | 6 ++ >  2 files changed

Re: [OE-core] [PATCH v2] ed: update SRC_URI to yoctoproject mirror

On Tue, Apr 11, 2017 at 3:47 AM, Maxin B. John wrote: > Upstream has removed the 1.14.1 release from ftp.gnu.org and > moved to the latest 1.14.2. Since we don't want to upgrade at > this point of time, temporarily move the SRC_URI to yoctoproject > mirror. > > Signed-off-by: Maxin B. John > ---

Re: [OE-core] [PATCHv3 1/1] native/nativesdk: Use fixed DISTRO_FEATURES

> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Jussi Kukkonen > Sent: den 11 april 2017 16:36 > To: openembedded-core@lists.openembedded.org > Subject: [OE-core] [PATCHv3 1/1] native/na

Re: [OE-core] ✗ patchtest: failure for gstreamer1.0-plugins-bad: Update packageconfigs and config flags (rev2)

On Tue, 2017-04-11 at 11:44 +0300, Jussi Kukkonen wrote: > CCing Leo for patchwork issue (is that correct?) > > O it is not, those two strings are missing in the corresponding patch. -- ___ Openembedded-core mailing list Openembedded-core@lists.open

Re: [OE-core] [PATCH v3 2/8] gdb-cross: avoid tune specific paths

On 4/11/17 9:56 AM, Patrick Ohly wrote: > gdb-cross used to be specific to the tune flags, but isn't > anymore. Therefore it is enough to use TARGET_SYS instead of > TUNE_PKGARCH to create a unique path. Are you sure about this. On non-intel architectures, it used to be VERY common that the speci

[OE-core] [PATCH v3 8/8] 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 w

[OE-core] [PATCH v3 7/8] 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 use

[OE-core] [PATCH v3 6/8] yocto-compat-layer: add --additional-layers

The new --addditional-layers parameter takes a list of layer directories and adds them to the build configuration before starting testing. The resulting base configuration then more closely matches a full distro. This is relevant in two cases: 1. some layers like meta-freescale dynamically enable

[OE-core] [PATCH v3 5/8] yocto-compat-layer: also determine tune flags for each task

locked-sigs.inc groups tasks according to their tune flags (allarch, i586, etc.). Also retrieve that information while getting signatures, it will be needed to determine when setting a machine changes tasks that aren't machine-specific. Signed-off-by: Patrick Ohly --- scripts/lib/compatlayer/__i

[OE-core] [PATCH v3 4/8] yocto-compat-layer: include bitbake-diffsigs output

After filtering out potential false positives, it becomes feasible to include the output of bitbake-diffsigs for those tasks which definitely have a change. Depends on bitbake-diffsigs with the "--signature" parameter. Enhanced output now is: AssertionError: False is not true : Layer meta-xxx

[OE-core] [PATCH v3 3/8] -cross recipes: ignore TARGET_ARCH sstate hash

"yocto-compat-layer.py --machines" showed that shared packages like gcc-cross-powerpc64 have a sstate signature that depends on TUNEFLAGS. As a result, there are unnecessary rebuilds and potential conflicts in a multiconfig. That's due to the way how TARGET_ARCH is set. Richard Purdie suggested se

[OE-core] [PATCH v3 2/8] gdb-cross: avoid tune specific paths

gdb-cross used to be specific to the tune flags, but isn't anymore. Therefore it is enough to use TARGET_SYS instead of TUNE_PKGARCH to create a unique path. Fixes a sstate signature difference that was found via yocto-compat-layer.py's test_machine_signatures check. In practice it probably showed

[OE-core] [PATCH v3 1/8] go-cross: avoid libgcc dependency

libgcc gets compiled differently depending on the tune flags for the target. That dependency would make go-cross also tune specific and prevent sharing it between different machines using the same architecture. For example, MACHINE=intel-corei7-64 and MACHINE=qemux86-64 shared the same go-cross-x8

[OE-core] [PATCH v3 0/8] yocto-compat-layer: bitbake-diffsigs support + per machine checks + OE-core fixes

Manually calling bitbake-diffsigs is cumbersome and doesn't work in a CI environment, so now the test itself does it for test_signatures. Regarding the BSP example that I ended up using: it actually was one of the better BSP layers and only had one problem in a "bitbake world" build instead of sev

[OE-core] [PATCHv3 1/1] native/nativesdk: Use fixed DISTRO_FEATURES

There seems to be little advantage to letting distro features affect native builds. There is a significant disadvantage: a change to DISTRO_FEATURES will trigger a lot of unnecessary native tasks. In a test like this: $ bitbake core-image-minimal # append " systemd" to DISTRO_FEATURES $ bitba

[OE-core] [PATCHv3 0/1] Use fixed DISTRO_FEATURES for native

Avoid signifant native task churn when DISTRO_FEATURES is changed by defining (almost) fixed DISTRO_FEATURES for native recipes. Add DISTRO_FEATURES_FILTER_NATIVE and DISTRO_FEATURES_NATIVE to limit the changes to DISTRO_FEATURES when building native recipes. Changes since V3: * Use both DISTRO_

Re: [OE-core] Fwd: About misappropriation of one of my patches in OpenEmbedded

On 4/10/17 8:19 PM, Trevor Woerner wrote: > First and foremost, yes a patch from Neal was mishandled. However, I > think the dial went up to 11 on this one a bit too quickly. > > As far as I can tell Neal's attribution still appears in the > 0001-Add-fallback-fopencookie-implementation.patch file.

[OE-core] [PATCH] busybox: In defconfig enable ASH_CMDCMD for built-in 'command'

It is common for *ash shells to have 'command' available as a built-in function. POSIX 2008 also documents the availability of this command. Additionally the /etc/profile of base-files requires this command to be available as of commit e77cdb7611 ("base-files: profile: Do not assume that the tty c

Re: [OE-core] [PATCHv2 2/3] base-files: profile: Do not assume that the tty command exists

On Wed, 2017-04-05 at 15:46 +0200, Peter Kjellerstedt wrote: > This avoids the following error when logging in to a host that does > not have the tty command: > > -sh: tty: not found > > Reported-by: Cristian Ionescu-Idbohrn com> > Signed-off-by: Peter Kjellerstedt > --- >  meta/recipes-core/ba

[OE-core] ✗ patchtest: failure for package_manager.py: Add a name for the generated dnf repo.

== Series Details == Series: package_manager.py: Add a name for the generated dnf repo. Revision: 1 URL : https://patchwork.openembedded.org/series/6296/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests

[OE-core] ✗ patchtest: failure for data_smart: Ensure _remove operations on newly set variables are cleared

== Series Details == Series: data_smart: Ensure _remove operations on newly set variables are cleared Revision: 1 URL : https://patchwork.openembedded.org/series/6295/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response.

[OE-core] [PATCH] package_manager.py: Add a name for the generated dnf repo.

This adds repo_name as the name, which is the same as the repo ID and hence a bit pointless, but it stops dnf from complaining that the repo doesn't have a configured name. Signed-off-by: Ian.Arkver --- meta/lib/oe/package_manager.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --

[OE-core] [PATCH] data_smart: Ensure _remove operations on newly set variables are cleared

We clear append/prepend on newly set variables, we should also clear remove operations. If we don't do this, there is no way we can actually delete a remove operation. Bitbake internally uses parsing=True to avoid these side effects when making its own internal calls. Also add a testcase to bitbak

Re: [OE-core] [yocto] [PATCH 1/2] logrotate: Bump to 3.11.0

ping, Le 06/04/2017 à 14:20, Romain Perier a écrit : > Hello, > > > Le 06/04/2017 à 13:38, Richard Purdie a écrit : >> On Wed, 2017-04-05 at 17:05 +0200, Romain Perier wrote: >>> This commit updates the recipe to the last upstream tag. Then, as the >>> tarball no longer contains the pre-generated

[OE-core] M4 rc1 build prerequisites

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 contaminating native/nativesdk builds, we need     separate configuration of t

[OE-core] [PATCHv2 4/4] native.bbclass: Use fixed DISTRO_FEATURES

There seems to be little advantage to letting distro features affect native builds. There is a significant disadvantage: a change to DISTRO_FEATURES will trigger a lot of unnecessary native tasks. In a test like this: $ bitbake core-image-minimal # append " systemd" to DISTRO_FEATURES $ bitba

[OE-core] [PATCHv2 0/4] Use fixed DISTRO_FEATURES for native

Avoid signifant native task churn when DISTRO_FEATURES is changed by defining (almost) fixed DISTRO_FEATURES for native recipes. The DISTRO_FEATURES_FILTER_NATIVE variable lists the features that do change based on DISTRO_FEATURES: currently the default value is "api-documentation". Changes since

[OE-core] [PATCHv2 1/4] mkfontdir: Remove x11 requirement for -native

Make sure we can build native tools without "x11" in features. Signed-off-by: Jussi Kukkonen --- meta/recipes-graphics/xorg-app/mkfontdir_1.0.7.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-graphics/xorg-app/mkfontdir_1.0.7.bb b/meta/recipes-graphics/xorg-app/mkfontdir_

[OE-core] [PATCHv2 3/4] xorg-font-common.inc: Remove x11 requirement for -native

Signed-off-by: Jussi Kukkonen --- meta/recipes-graphics/xorg-font/xorg-font-common.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-graphics/xorg-font/xorg-font-common.inc b/meta/recipes-graphics/xorg-font/xorg-font-common.inc index cdbebcf..520c88a 100644 --- a/meta/recipes-

[OE-core] [PATCHv2 2/4] mkfontscale: Remove x11 requirement for -native

Make sure we can build native tools without "x11" feature. Signed-off-by: Jussi Kukkonen --- meta/recipes-graphics/xorg-app/mkfontscale_1.1.2.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-graphics/xorg-app/mkfontscale_1.1.2.bb b/meta/recipes-graphics/xorg-app/mkfontscale

[OE-core] [PATCH v2] ed: update SRC_URI to yoctoproject mirror

Upstream has removed the 1.14.1 release from ftp.gnu.org and moved to the latest 1.14.2. Since we don't want to upgrade at this point of time, temporarily move the SRC_URI to yoctoproject mirror. Signed-off-by: Maxin B. John --- meta/recipes-extended/ed/ed_1.14.1.bb | 4 +++- 1 file changed, 3 i

Re: [OE-core] [PATCH] libsolv: correctly attribute musl fixing patches

On 04/11/2017 01:15 PM, Paul Eggleton wrote: On Tuesday, 11 April 2017 9:22:43 PM NZST Alexander Kanavin wrote: Also, they were previously squashed into a single patch; restore the original two-patch arrangement. Didn't Mark H just send a patch to fix this? Mark's patch incorrectly changes t

Re: [OE-core] [PATCH] libsolv: correctly attribute musl fixing patches

On Tuesday, 11 April 2017 9:22:43 PM NZST Alexander Kanavin wrote: > Also, they were previously squashed into a single patch; restore > the original two-patch arrangement. Didn't Mark H just send a patch to fix this? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___

[OE-core] [PATCH] staging: Fix sysroot problem with populate_sysroot dependencies on do_fetch

Dependencies on svn:// urls were failing as the cleandirs on do_fetch was destroying any sysroot setup by the extend_recipe_sysroot function. Add code so that if the task do_fetch, we move the cleandirs to a separate function before the extend_recipe_sysroot prefunc else we'd wipe out the sysroo

[OE-core] [PATCH] libsolv: correctly attribute musl fixing patches

Also, they were previously squashed into a single patch; restore the original two-patch arrangement. As requested here: http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135460.html Signed-off-by: Alexander Kanavin --- ...1-Add-fallback-fopencookie-implementation.patch | 60

[OE-core] [PATCH 0/7 V3] fixes for runqemu

* V3: - Fixed wic's test cases. - Remove Qi's patch since it was broken, and there are other solutions in the mailing list: http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135464.html * V2: - Fixed "ERROR - name 'p' is not defined" - Add Qi's patch. // Robert

[OE-core] [PATCH 6/7] wic-image-minimal.wks: vda -> sda

Previously, runqemu grep root=/dev/sd or root=/dev/hd on the image, and would use vda if no grep result, now we have set QB_DRIVE_TYPE to "/dev/sd" by default, and the device will be /dev/sda, so use sda to replace vda in the test case. Signed-off-by: Robert Yang --- meta-selftest/recipes-test/i

[OE-core] [PATCH 5/7] selftest/wic.py: vda -> sda

Previously, runqemu grep root=/dev/sd or root=/dev/hd on the image, and would use vda if no grep result, now we have set QB_DRIVE_TYPE to "/dev/sd" by default, and the device will be /dev/sda, so use sda to replace vda in the test case. Signed-off-by: Robert Yang --- meta/lib/oeqa/selftest/wic.p

[OE-core] [PATCH 7/7] qemux86-directdisk.wks: vda -> sda

Previously, runqemu grep root=/dev/sd or root=/dev/hd on the image, and would use vda if no grep result, now we have set QB_DRIVE_TYPE to "/dev/sd" by default, and the device will be /dev/sda, so use sda to replace vda in the test case. Signed-off-by: Robert Yang --- scripts/lib/wic/canned-wks/q

[OE-core] [PATCH 1/7] runqemu: support env vars explicitly

Use self.env_vars to support get vars from environment explicity. The MACHINE, ROOTFS and KERNEL was supported by shell based runqemu, and the help text says support them from env vars, so add them back. [YOCTO #11141] Signed-off-by: Robert Yang --- scripts/runqemu | 71

[OE-core] [PATCH 3/7] runqemu: run without arguments

Since we can get MACHINE and others from env vars and "bitbake -e", "runqemu" can work without any arguments. Signed-off-by: Robert Yang --- scripts/runqemu | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/runqemu b/scripts/runqemu index 4594173db7..a4036ae091 1007

[OE-core] [PATCH 4/7] runqemu: do not rely on grepping images

Fixed when the image is large and not enough memory: grep: memory exhausted Aborted [YOCTO #11073] Signed-off-by: Robert Yang --- meta/classes/qemuboot.bbclass | 3 +++ scripts/runqemu | 19 +++ 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/m

[OE-core] [PATCH 2/7] runqemu: use self.rootfs to replace self.nfs_dir

We can use self.rootfs as self.nfs_dir when self.fstype is nfs, this can reduce the code's complexity and we can re-use the code of checking ROOTFS conflictions. Signed-off-by: Robert Yang --- scripts/runqemu | 28 +--- 1 file changed, 13 insertions(+), 15 deletions(-) d

[OE-core] [PATCH] coreutils: 8.26 -> 8.27

Upgrade coreutils from 8.26 to 8.27. Signed-off-by: Huang Qiyu --- .../0001-Unset-need_charset_alias-when-building-for-musl.patch| 0 .../0001-local.mk-fix-cross-compiling-problem.patch | 0 .../0001-uname-report-processor-and-hardware-correctly.patch | 0 .../disable-ls-o

Re: [OE-core] [PATCH] binutils: Fix CVE-2017-6965 and CVE-2017-6966

On 04/11/2017 03:28 PM, Richard Purdie wrote: On Tue, 2017-04-11 at 14:18 +0800, Yuanjie Huang wrote: On 04/11/2017 06:10 AM, Richard Purdie wrote: On Mon, 2017-04-10 at 03:34 -0700, Yuanjie Huang wrote: meta/recipes-devtools/binutils/binutils-2.27.inc Given master contains 2.28, I don't th

[OE-core] [PATCH v2] gstreamer1.0-plugins-good: Backport patch for v4l2object videometa

This patch ensures videometa is added to mem2mem decoder output in case the output frames have padding rows/columns Signed-off-by: Carlos Rafael Giani --- ...Also-add-videometa-if-there-is-padding-to.patch | 35 ++ .../gstreamer/gstreamer1.0-plugins-good_1.10.4.bb | 1 + 2

Re: [OE-core] ✗ patchtest: failure for gstreamer1.0-plugins-bad: Update packageconfigs and config flags (rev2)

CCing Leo for patchwork issue (is that correct?) On 11 April 2017 at 11:32, Patchwork wrote: > > == Series Details == > > Series: gstreamer1.0-plugins-bad: Update packageconfigs and config flags (rev2) > Revision: 2 Patchwork gets confused here. The comments are valid but they should be for g

[OE-core] ✗ patchtest: failure for gstreamer1.0-plugins-bad: Update packageconfigs and config flags (rev2)

== Series Details == Series: gstreamer1.0-plugins-bad: Update packageconfigs and config flags (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/6284/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response.

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

On 2017-04-11 10:26, Alexander Kanavin wrote: On 04/11/2017 10:54 AM, Carlos Rafael Giani wrote: This is a useful tool to test KMS and GBM-based EGL & OpenGL ES drawing Sorry, but the bar for adding recipes to oe-core is higher than a single all-purpose word 'useful'. Useful to whom? What doe

Re: [OE-core] [PATCH] ed: update to 1.14.2

Hi Rebecca, On Tue, Apr 11, 2017 at 09:09:23AM +0100, Chang, Rebecca Swee Fun wrote: >Thanks Jussi, Richard was suggesting to add a note in the recipe about >upstream regularly removing releases. Should I push a V2? Is Maxim working on >it? If we were not in a Feature freeze, upgrading would hav

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

On 04/11/2017 10:54 AM, Carlos Rafael Giani wrote: This is a useful tool to test KMS and GBM-based EGL & OpenGL ES drawing Sorry, but the bar for adding recipes to oe-core is higher than a single all-purpose word 'useful'. Useful to whom? What does the tool do? Is it essential for making an e

Re: [OE-core] Fwd: [PATCH V2] python2/3: Move config/Makefile from core package to dev package

Hi, On Tue, 2017-04-11 at 13:31 +0800, Zhou, Li wrote: >          From the mails I received, I think you have merged the 1st > version of this patch, while I have sent out the 2nd version for > fixing the issue mentioned by Jussi . > I just sent this patch in an accessory, because there are lines

Re: [OE-core] [PATCH] binutils: Fix CVE-2017-6965 and CVE-2017-6966

On Tue, 2017-04-11 at 14:18 +0800, Yuanjie Huang wrote: > > On 04/11/2017 06:10 AM, Richard Purdie wrote: > > > > On Mon, 2017-04-10 at 03:34 -0700, Yuanjie Huang wrote: > > > > > > meta/recipes-devtools/binutils/binutils-2.27.inc > > Given master contains 2.28, I don't think this patch was base

Re: [OE-core] [PATCH 0/1] Restore proper attributions to libsolv patch

Hi Mark, On Mon, Apr 10, 2017 at 03:58:27PM -0500, Mark Hatle wrote: > > Per the email: > http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135460.html > > Neal's attribution to the original code was lost. In addition the original > two patches were squashed together. This

[OE-core] [PATCH] gstreamer1.0-plugins-bad: Update packageconfigs and config flags

Signed-off-by: Carlos Rafael Giani --- .../gstreamer/gstreamer1.0-plugins-bad.inc | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plu

[OE-core] [PATCH] gstreamer1.0-plugins-good: Backport patch for v4l2object videometa

This patch ensures videometa is added to mem2mem decoder output in case the output frames have padding rows/columns Signed-off-by: Carlos Rafael Giani --- ...Also-add-videometa-if-there-is-padding-to.patch | 31 ++ .../gstreamer/gstreamer1.0-plugins-good_1.10.4.bb | 1 + 2

Re: [OE-core] [PATCH] ed: update to 1.14.2

Thanks Jussi, Richard was suggesting to add a note in the recipe about upstream regularly removing releases. Should I push a V2? Is Maxim working on it? Rebecca From: Jussi Kukkonen [mailto:jussi.kukko...@intel.com] Sent: Tuesday, April 11, 2017 3:58 PM To: Chang, Rebecca Swee Fun Cc: Patches a

[OE-core] [PATCH] python2/3: Remove building host path from packages

Remove building host related path from python2 and python3 packages. Signed-off-by: Li Zhou --- meta/recipes-devtools/python/python3_3.5.2.bb | 8 +++- meta/recipes-devtools/python/python_2.7.13.bb | 6 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/meta/recipes-devtoo

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

This is a useful tool to test KMS and GBM-based EGL & OpenGL ES drawing Signed-off-by: Carlos Rafael Giani --- meta/recipes-graphics/kmscube/kmscube_git.bb | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 meta/recipes-graphics/kmscube/kmscube_git.bb diff --git a/meta/re

Re: [OE-core] [PATCH] ed: update to 1.14.2

On 11 April 2017 at 10:05, wrote: > From: "Chang, Rebecca Swee Fun" > > The previous version of ed-1.14.1 no longer exist in upstream source > archive at https://ftp.gnu.org/gnu/ed/. Upstream version was being > replaced by a brand new version. > Feature freeze is in effect: version upgrades sh

  1   2   >