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 =
'/buildarea/build/tmp/work/core2-64-poky-linux/json-glib/1.2.8-r0/recipe-sysroot-native/usr/bin/g-ir
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 10:
> -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 wrote:
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 m
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 enable kdump
| /lib/systemd/sys
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 to do
so in
your
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
>>> wrote:
>>> > > Do you have an easy way to reproduce this hang?
>>
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 possible solutions prop
== 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 exe
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:
>
> - Generate meson.cross t
* 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 pack
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
going
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
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
--sysroot=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-li
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 nativesdk-gettext continue to
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 git
> version of tpm2-t
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 t
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 1d40cba731
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
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
--- a/meta/recipes-extended/at/at_3.1.20.bb
+++
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 ++--
meta/recipes-devtools/gcc/gcc-
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
+++ b/meta/recipes-kernel/perf/perf.bb
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
---
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 variab
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 variab
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 wasn't building hostname at
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/
https://webkitgtk.o
== 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 e
== 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 executed
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
recipe
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
/data/yocto/poky/meta/recipes-k
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 variab
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 variab
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.
http://lists.openembedded.org/pipermail
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 it, bad search. Lets see
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 compres
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 t
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: R
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 curre
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:
> > > command
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
---
meta/classes/populate_sdk_ext.bbclass | 2 +-
1 file changed, 1
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 environment setup script. However,
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 path instead, where the wic modules
ar
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 script.
Hence, we need to add bitbake fil
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 insertions(+), 4 deletions(-)
diff --git a/scripts/wic b/scripts/wic
index 0
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 path.
Regards,
Rebecca
-
Hi
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/
https://webkitgtk.o
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.
> > You should
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
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 won't
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 (2018-01-08
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, i
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
sign_rpm.bbclass: force rpm serial signing
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 p
54 matches
Mail list logo
