Re: [OE-core] [PATCH 3/9] json-glib: convert to meson build

I also encountered this issue. For now, I found it only happened on ubuntu 14.04. Looks like it invokes g-ir-scanner but not g-ir-scanner-wrapper when building gir. In build.ninja: COMMAND =

Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

On 2018-01-11 09:13 PM, Huang, Jie (Jackie) wrote: -Original Message- From: MacLeod, Randy Sent: Friday, January 12, 2018 04:16 To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt On 2018-01-10

Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

> -Original Message- > From: MacLeod, Randy > Sent: Friday, January 12, 2018 04:16 > To: Huang, Jie (Jackie); openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt > > On 2018-01-10 10:07 PM, jackie.hu...@windriver.com

[OE-core] [PATCH] qemu-2.10.1.bb: support mingw build

The patch chardev-connect-socket-to-a-spawned-command.patch calls "socketpair". This function is missing in mingw, so the patch needs to be modified accordingly, otherwise we end up with a broken mingw build. While it is possible to simply remove the patch on a recipe level for mingw platform, it

Re: [OE-core] [PATCH] systemd: add RDEPENDS on util-linux-getopt

On 2018-01-10 10:07 PM, jackie.hu...@windriver.com wrote: From: Jackie Huang 'getopt' is needed by systemd-sysv-install, or it fails with: | kdump.service is not a native service, redirecting to systemd-sysv-install. | Executing: /lib/systemd/systemd-sysv-install

Re: [OE-core] Issues with meson in SDK with cross-file

On 01/11/2018 11:33 AM, Martin Kelly wrote: On 01/11/2018 11:26 AM, Khem Raj wrote: On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly wrote: Khem and Alexander, could you comment on which solution is preferable from an SDK standpoint? Otherwise, could you nominate someone else

Re: [OE-core] [PATCH] receipes-devtools: QEMU: Bump to version 2.11.0

On Mon, Jan 8, 2018 at 3:45 PM, Alistair Francis wrote: > On Sat, Jan 6, 2018 at 2:15 AM, Richard Purdie > wrote: >> On Fri, 2018-01-05 at 18:18 -0800, Alistair Francis wrote: >>> On Fri, Jan 5, 2018 at 4:22 PM, Richard Purdie >>>

Re: [OE-core] Issues with meson in SDK with cross-file

On 01/11/2018 11:26 AM, Khem Raj wrote: On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly wrote: Khem and Alexander, could you comment on which solution is preferable from an SDK standpoint? Otherwise, could you nominate someone else to do so in your place? :) Here are the

[OE-core] ✗ patchtest: failure for recipes-core: move hwclock.sh to util-linux

== Series Details == Series: recipes-core: move hwclock.sh to util-linux Revision: 1 URL : https://patchwork.openembedded.org/series/10505/ 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] Issues with meson in SDK with cross-file

On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly wrote: > Khem and Alexander, could you comment on which solution is preferable from > an SDK standpoint? Otherwise, could you nominate someone else to do so in > your place? :) > > Here are the possible solutions proposed: > > -

[OE-core] [PATCH] recipes-core: move hwclock.sh to util-linux

* Move the hwclock.sh initscript from the busybox recipe to util-linux. This script is generally useful for distros that get their hwclock implementation from sources other than busybox and we follow debian's example by providing it in util-linux. :busybox/* * Remove the busybox-hwclock

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

On 01/11/2018 09:49 AM, Richard Purdie wrote: On Thu, 2018-01-11 at 13:35 +0200, Alexander Kanavin wrote: On 01/10/2018 09:11 PM, Martin Kelly wrote: Yes, to be clear, I'm not griping, as I'm very happy meson landed in OE-core, and I'm working on SDK support now. I have an OE-core thread

Re: [OE-core] Issues with meson in SDK with cross-file

Khem and Alexander, could you comment on which solution is preferable from an SDK standpoint? Otherwise, could you nominate someone else to do so in your place? :) Here are the possible solutions proposed: - Generate meson.cross toolchain file at SDK extraction time. - Wrap meson with a shell

[OE-core] Error do_compile libepoxy

Hello, I am trying to build libepoxy but the do_compile tasks breaks. I found following error messages in the logs: arm-poky-linux-gnueabi-gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard -mtune=arm1176jzf-s -mfpu=vfp

Re: [OE-core] [PATCH 2/2] gettext: rationalise optional dependencies

On Wed, Jan 10, 2018 at 9:28 AM, Ross Burton wrote: > gettext has optional dependencies on libxml2, glib, libcroco and libunistring. > If they're not available then gettext will use internal copies, but it can > also > use system libraries. > > For gettext-native and

Re: [OE-core] uriparser

On Wed, Jan 10, 2018 at 11:20 AM, Trevor Woerner wrote: > Hi Martin, > > Any chance the uriparser recipe from meta-luneui > (https://layers.openembedded.org/layerindex/recipe/32523/) could be added to > openembedded-core (or meta-openembedded?). It's also now needed for the

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

On Thu, 2018-01-11 at 13:35 +0200, Alexander Kanavin wrote: > On 01/10/2018 09:11 PM, Martin Kelly wrote: > > > > Yes, to be clear, I'm not griping, as I'm very happy meson landed > > in  > > OE-core, and I'm working on SDK support now. I have an OE-core > > thread  > > going with meson upstream

Re: [OE-core] [PATCH] gcc: add flex-native explicit dependency

On Thu, 2018-01-11 at 10:02 -0500, Denys Dmytriyenko wrote: > On Thu, Jan 11, 2018 at 02:41:15PM +, Richard Purdie wrote: > > and test results so far imply that we need: > > > > diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc b/meta/recipes- > > devtools/gcc/gcc-7.2.inc > > index

[OE-core] [PATCH 4/4] sstate: Avoid indirect bison/flex-native dependencies

This avoids adding flex-native or bison-native to the sysroot without a specific dependency in the recipe and means indirect dependencies (e.g. X -> Y -> binutils-cross -> flex-native) no longer met the dependency incidentally. This improves determinism and avoid build failures when people switch

[OE-core] [PATCH 2/4] at: Add missing bison-native dependency

Signed-off-by: Richard Purdie --- meta/recipes-extended/at/at_3.1.20.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-extended/at/at_3.1.20.bb b/meta/recipes-extended/at/at_3.1.20.bb index 9b537ee..8fe3b43 100644 ---

[OE-core] [PATCH 3/4] gcc: Add missing flex-native dependency

This is needed for all stages of the cross/target/canadian compilers and without it (and with indirect gcc dependencies disabled), the steps fail. Add missing dependencies. Signed-off-by: Richard Purdie --- meta/recipes-devtools/gcc/gcc-7.2.inc| 4

[OE-core] [PATCH 1/4] perf: Add missing bison-native and flex-native dependencies

Signed-off-by: Richard Purdie --- meta/recipes-kernel/perf/perf.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb index b79b973..eebe755 100644 --- a/meta/recipes-kernel/perf/perf.bb

[OE-core] [PATCH] pax-utils: update SRC_URI

The gentoo.osuosl.org mirror doesn't store all versions of pax-utils, so use the maintainers own mirror which stores them all. This also means we can remove UPSTREAM_CHECK_URI as the defaults work now. Thanks to Maxin John for the initial patch. [ YOCTO #11559 ] Signed-off-by: Ross Burton

[OE-core] [rocko][PATCH] package: Record PE value for shlib dependencies

When downgrading a package or using a substitute with lower version, the way to do it is adding or increasing PE. But it didn't help dependant packages because the shlib records didn't contain PE, only PV. Let's add the PE value into these records for packages where it's set. The in-memory

[OE-core] [PATCH] package: Record PE value for shlib dependencies

When downgrading a package or using a substitute with lower version, the way to do it is adding or increasing PE. But it didn't help dependant packages because the shlib records didn't contain PE, only PV. Let's add the PE value into these records for packages where it's set. The in-memory

Re: [OE-core] [PATCH V2 1/1] coreutils: upgrade to 8.29

On 9 January 2018 at 01:40, Chen Qi wrote: > * hostname is explicitly enabled to keep the same with previous recipe's > behaviour. > But buildhistory-diff: packages/corei7-64-poky-linux/coreutils/coreutils: FILELIST: added "/usr/bin/hostname" So the old coreutils

[OE-core] [rocko][PATCH] webkitgtk: update to 2.18.5 (includes Spectre mitigations; see commit description)

This is the only available stable version with mitigation fixes for Spectre. Webkit upstream developers do not port CVE fixes to earlier stable series, no exception was made in this case. More information: https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/

[OE-core] ✗ patchtest: failure for Record PE value for shlib dependencies (rev2)

== Series Details == Series: Record PE value for shlib dependencies (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/10497/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been

[OE-core] ✗ patchtest: failure for Record PE value for shlib dependencies

== Series Details == Series: Record PE value for shlib dependencies Revision: 1 URL : https://patchwork.openembedded.org/series/10497/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been

[OE-core] [morty][PATCH] kernel.bbclass: Fix symlink creation when using externalsrc

do_unpack is by default in SRCTREECOVEREDTASKS so this append can't run, since this tasks gets removed by externalsrc when it's enabled. However this was hidden because externalsrc does run do_fetch and do_unpack if there are type=kmeta or file:// entries in the SRC_URI value of the kernel

[OE-core] [morty][PATCH] kernelsrc/perf: fix dependency on non existant task when using externalsrc

When externalsrc is enabled for kernel, do_patch doesn't exist since is in SRCTREECOVEREDTASKS, so make these depend on a real task. Fixes: ERROR: Task do_unpack in /data/yocto/poky/meta/recipes-kernel/perf/perf.bb depends upon non-existent task do_patch in

[OE-core] [rocko][PATCH] Record PE value for shlib dependencies

When downgrading a package or using a substitute with lower version, the way to do it is adding or increasing PE. But it didn't help dependant packages because the shlib records didn't contain PE, only PV. Let's add the PE value into these records for packages where it's set. The in-memory

[OE-core] [PATCH] Record PE value for shlib dependencies

When downgrading a package or using a substitute with lower version, the way to do it is adding or increasing PE. But it didn't help dependant packages because the shlib records didn't contain PE, only PV. Let's add the PE value into these records for packages where it's set. The in-memory

Re: [OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

On 01/11/2018 05:42 PM, Burton, Ross wrote: Exactly same patch from Maxin caused failures previously, no? Hm, I knew I remembered seeing this before, and found my patches from 2015, but didn't see the ones from Maxin.  I'll dig the archives again.

Re: [OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

On 11 January 2018 at 15:42, Burton, Ross wrote: > Exactly same patch from Maxin caused failures previously, no? >> > > Hm, I knew I remembered seeing this before, and found my patches from > 2015, but didn't see the ones from Maxin. I'll dig the archives again > Found

Re: [OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

On 11 January 2018 at 15:29, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 01/11/2018 05:18 PM, Ross Burton wrote: > >> We should pass --apparent-size to du when calculating how large the >> rootfs is as >> otherwise we get the actual disk usage, which if the files are

Re: [OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

On 01/11/2018 05:18 PM, Ross Burton wrote: We should pass --apparent-size to du when calculating how large the rootfs is as otherwise we get the actual disk usage, which if the files are compressed by the file system (such as ZFS) may be sufficiently smaller than the space required by the image

[OE-core] [PATCH] image: use du --apparent-size when calculating rootfs size

We should pass --apparent-size to du when calculating how large the rootfs is as otherwise we get the actual disk usage, which if the files are compressed by the file system (such as ZFS) may be sufficiently smaller than the space required by the image that construction will fail. Signed-off-by:

Re: [OE-core] [PATCH] webkitgtk: update to 2.18.5 (includes Spectre mitigations; see commit description)

On 01/11/2018 05:00 PM, Alexander Kanavin wrote: This is the only available stable version with mitigation fixes for Spectre. Webkit upstream developers do not port CVE fixes to earlier stable series, no exception was made in this case. I will now establish whether it's feasible to update

Re: [OE-core] [PATCH] gcc: add flex-native explicit dependency

On Thu, Jan 11, 2018 at 02:41:15PM +, Richard Purdie wrote: > On Wed, 2018-01-10 at 22:15 -0500, Denys Dmytriyenko wrote: > > From: Denys Dmytriyenko > > > > It seems flex is required to build gcc: > > > > > > > > .../work-shared/gcc-7.2.0-r0/gcc-7.2.0/missing: line 81: flex:

[OE-core] [PATCHv2 5/5] classes/populate_sdk_ext: support wic in eSDK

From: Chang Rebecca Swee Fun Make 'wic' image creation tool/command available in eSDK environment. This would allow eSDK users to manipulate images within eSDK environment. [YOCTO #12177] Signed-off-by: Chang Rebecca Swee Fun

[OE-core] [PATCHv2 4/5] scripts/wic: explicitly set BUILDDIR within eSDK

From: Chang Rebecca Swee Fun When we run wic within eSDK: $ wic create mkefidisk -e core-image-minimal ERROR: BUILDDIR not found, exiting. (Did you forget to source oe-init-build-env?) In order to figure out variable values, one must have sourced the OE build

[OE-core] [PATCHv2 3/5] scripts/wic: fix error of import wic module in eSDK environment

From: Chang Rebecca Swee Fun wic modules in scripts/lib/ are needed for wic to work, but path to the python module is not exported in eSDK environment and we were using an absolutized path of wic script within the sysroots. We now changed to use real script

[OE-core] [PATCHv2 2/5] scripts/wic: append bitbake executable file path in eSDK environment

From: Chang Rebecca Swee Fun wic needs a set of tools to be available from sysroots. wic will find bitbake executable within the environment, and wic was unable to locate bitbake executable within eSDK because it wasn't setup with the OE build environment

[OE-core] [PATCHv2 1/5] scripts/wic: use scriptpath module to find bitbake path and oe lib path

From: Chang Rebecca Swee Fun Use the scriptpath module in order to standardize the adding of bitbake and meta/lib path to sys.path. Signed-off-by: Chang Rebecca Swee Fun --- scripts/wic | 7 +++ 1 file changed, 3

[OE-core] [PATCHv2 0/5] Enable wic in eSDK

From: Chang Rebecca Swee Fun Hi all, Resend as v2 as I realized an issue with BUILDDIR being set was not correct. I made the correction on Patch 4 by setting BUILDDIR to sdkroot variable (eSDK base path) before we alter the variable for bitbake executable file

[OE-core] [PATCH] webkitgtk: update to 2.18.5 (includes Spectre mitigations; see commit description)

This is the only available stable version with mitigation fixes for Spectre. Webkit upstream developers do not port CVE fixes to earlier stable series, no exception was made in this case. More information: https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/

Re: [OE-core] [PATCH] gcc: add flex-native explicit dependency

On Wed, 2018-01-10 at 22:15 -0500, Denys Dmytriyenko wrote: > From: Denys Dmytriyenko > > It seems flex is required to build gcc: > > > > > .../work-shared/gcc-7.2.0-r0/gcc-7.2.0/missing: line 81: flex: > > command not found > > WARNING: 'flex' is missing on your system. > >  

Re: [OE-core] [PATCH 4/4] gnupg: use native version for signing, rather than one provided by host

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

Re: [OE-core] [PATCH] tune-i686: Add new tune for better support of 686-class CPUs.

On 11/01/18 11:29, Richard Purdie wrote: > On Thu, 2018-01-11 at 05:08 +0100, Carlos Alberto Lopez Perez wrote: >> There isn't currently any tune available for i686 x86 optimizations. >> The tune for i586 doesn't enable i686 specific optimizations, and the >> one for core2 enables things that

[OE-core] [PATCH v9 00/14] support profile-optimized build for Python

Changes since v8: - rebased onto latest master - fixed a logger naming mistake in python-pgo-image.bb - this mistake caused the targetrunner logs not to be printed at all The following changes since commit e9dfe7eb7f61b909ae7d034e80cfbebc1fad018b: icu-dbg: improve reproducibility

Re: [OE-core] [PATCH 2/9] gnomebase-meson.bbclass: add a meson-specific version

On 01/10/2018 09:11 PM, Martin Kelly wrote: Yes, to be clear, I'm not griping, as I'm very happy meson landed in OE-core, and I'm working on SDK support now. I have an OE-core thread going with meson upstream to get the issue fixed. To be clear though, I'm not sure it even regressed. AFAICT,

Re: [OE-core] [PATCH 4/4] gnupg: use native version for signing, rather than one provided by host

On 01/10/2018 05:01 PM, Leonardo Sandoval wrote: Great that you figure out a solution. So I belive we need to revert this commit: commit 043d9ac0ae441e9a7e2ea8934bfc595a03ef9a52 Author: Leonardo Sandoval Date: Mon Sep 25 13:52:59 2017 -0700

Re: [OE-core] [PATCH] tune-i686: Add new tune for better support of 686-class CPUs.

On Thu, 2018-01-11 at 05:08 +0100, Carlos Alberto Lopez Perez wrote: > There isn't currently any tune available for i686 x86 optimizations. > The tune for i586 doesn't enable i686 specific optimizations, and the > one for core2 enables things that won't work on a i686 CPU (like > SSE3). > > This