Add the necessary parts to qemuarm64.conf for graphics to be shown in
the SDL window, and USB so that it is possible to interact with it.
Signed-off-by: Jon Mason
---
meta/conf/machine/qemuarm64.conf | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
This series is dependent on the yocto-kernel-cache RFC series similarly
named. See
https://lists.yoctoproject.org/pipermail/linux-yocto/2019-February/007580.html
This series cleans up the hvc0 respawning issue, by removing the
reference in meta/conf/machine/qemuarm64.conf. So virtio console
The following error is being frequently posted
INIT: Id "hvc0" respawning too fast: disabled for 5 minutes
Remove the references to hvc0 to work around this error. Also, add some
comments to describe what is going on.
Signed-off-by: Jon Mason
---
meta/conf/machine/qemuarm64.conf | 13
Sorted regression results to provide friendly viewing of report.
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/regression.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/lib/resulttool/regression.py
b/scripts/lib/resulttool/regression.py
index
Ping.
Thanks,
On 2019年02月26日 10:50, mingli...@windriver.com wrote:
From: Mingli Yu
When do world buid, there comes below error:
| ERROR: Nothing PROVIDES 'gtk+3' (but
/build/layers/oe-core/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb DEPENDS
on or otherwise requires it)
| gtk+3 was
On Mon, Feb 25, 2019 at 7:19 PM Denys Dmytriyenko wrote:
>
> Khem, Richard,
>
> Sorry for belated reply. I haven't had time for master yet, but since this
> just got backported to thud, I'm seeing a similar breakage.
>
> First of all, BN_LLONG not being defined does seem to be "fixed" by this
>
Just to provide some feedback.
Even with this patch, this annoying QA issue is still there.
WARNING: glibc-locale-2.29-r0 do_package_qa: QA Issue: glibc-locale:
/glibc-binary-localedata-wo-sn/usr/lib/locale/wo_SN/LC_CTYPE is owned by
uid 1001, which is the same as the user running bitbake. This
Ping. Any comments here? Thanks!
On Mon, Feb 25, 2019 at 10:19:51PM -0500, Denys Dmytriyenko wrote:
> Khem, Richard,
>
> Sorry for belated reply. I haven't had time for master yet, but since this
> just got backported to thud, I'm seeing a similar breakage.
>
> First of all, BN_LLONG not
On Wed, Feb 27, 2019 at 4:46 PM Andre McCurdy wrote:
>
> On Wed, Feb 27, 2019 at 4:31 PM Khem Raj wrote:
> >
> > On Wed, Feb 27, 2019 at 2:32 PM Martin Jansa wrote:
> > >
> > > On Wed, Feb 27, 2019 at 02:01:06PM -0800, Andre McCurdy wrote:
> > > > On Wed, Feb 27, 2019 at 12:51 PM Khem Raj
On Wed, Feb 27, 2019 at 4:31 PM Khem Raj wrote:
>
> On Wed, Feb 27, 2019 at 2:32 PM Martin Jansa wrote:
> >
> > On Wed, Feb 27, 2019 at 02:01:06PM -0800, Andre McCurdy wrote:
> > > On Wed, Feb 27, 2019 at 12:51 PM Khem Raj wrote:
> > > >
> > > > Since compiler does not optimize away a lot of
We have been duplicating few variables in glibc recipes which could
actually be defined once, therefore move them to glibc-common.inc which is
included by all glibc family of recipes
Signed-off-by: Khem Raj
---
v2: Correct typo gcc-common.inc -> glibc-common.inc in commit msg
On Wed, Feb 27, 2019 at 2:32 PM Martin Jansa wrote:
>
> On Wed, Feb 27, 2019 at 02:01:06PM -0800, Andre McCurdy wrote:
> > On Wed, Feb 27, 2019 at 12:51 PM Khem Raj wrote:
> > >
> > > Since compiler does not optimize away a lot of stuff we end up with
> > > Werrors e.g.
> > >
> > >
On Wed, Feb 27, 2019 at 2:01 PM Andre McCurdy wrote:
>
> On Wed, Feb 27, 2019 at 12:51 PM Khem Raj wrote:
> >
> > Since compiler does not optimize away a lot of stuff we end up with
> > Werrors e.g.
> >
> > ./sysdeps/ieee754/flt-32/s_log1pf.c: In function '__log1pf':
> >
On Wed, Feb 27, 2019 at 1:48 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Wed, 2019-02-27 at 13:29 -0800, Khem Raj wrote:
> > We have been duplicating few variables in glibc recipes which could
> > actually be defined once, therefore move them to gcc-common.inc which
>
>
On Wed, Feb 27, 2019 at 02:01:06PM -0800, Andre McCurdy wrote:
> On Wed, Feb 27, 2019 at 12:51 PM Khem Raj wrote:
> >
> > Since compiler does not optimize away a lot of stuff we end up with
> > Werrors e.g.
> >
> > ./sysdeps/ieee754/flt-32/s_log1pf.c: In function '__log1pf':
> >
On Wed, 27 Feb 2019 at 12:10, Vincent Prince
wrote:
>
> Hello everyone,
>
> I'm trying to add node_exporter from Prometheus project to an Intel x86-64
> machine.
> I made the following recipe:
>
>
On Wed, Feb 27, 2019 at 12:51 PM Khem Raj wrote:
>
> Since compiler does not optimize away a lot of stuff we end up with
> Werrors e.g.
>
> ./sysdeps/ieee754/flt-32/s_log1pf.c: In function '__log1pf':
> ../sysdeps/ieee754/flt-32/s_log1pf.c:114:22: error: 'c' may be used
> uninitialized in this
On Wed, 2019-02-27 at 13:29 -0800, Khem Raj wrote:
> We have been duplicating few variables in glibc recipes which could
> actually be defined once, therefore move them to gcc-common.inc which
gcc-common.inc for glibc? :)
Cheers,
Richard
--
___
We have been duplicating few variables in glibc recipes which could
actually be defined once, therefore move them to gcc-common.inc which is
included by all glibc family of recipes
Signed-off-by: Khem Raj
---
meta/recipes-core/glibc/glibc-collateral.inc | 18 +++---
Since compiler does not optimize away a lot of stuff we end up with
Werrors e.g.
./sysdeps/ieee754/flt-32/s_log1pf.c: In function '__log1pf':
../sysdeps/ieee754/flt-32/s_log1pf.c:114:22: error: 'c' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
114 |+ (k *
-Og is for optimized debugging experience.
this makes this consistent across different compilers especially gcc and
clang, -O in clang is equal to -O2 where as in gcc its similar to -O1
so it was not giving consistent debugging experience across compilers
Signed-off-by: Khem Raj
---
v2: Change
Sounds like good potential for a section or chapter in the user docs.
Scott
On Wed, Feb 27, 2019 at 12:01 PM Philip Balister
wrote:
> During the last OpenEmbedded developer meeting, it became clear that
> people are using the Yocto project/OpenEmbedded in spaces outside what
> we think of as
During the last OpenEmbedded developer meeting, it became clear that
people are using the Yocto project/OpenEmbedded in spaces outside what
we think of as traditional embedded. Lieu Ta is working on a
presentation for the Linux Foundation Leadership Summit and we would
like to collect as many
On Tue, Feb 26, 2019 at 11:19 PM Adrian Bunk wrote:
>
> On Tue, Feb 26, 2019 at 11:04:20PM -0800, Khem Raj wrote:
> > -Og is for optimized debugging experience.
> > this makes this consistent across different compilers especially gcc and
> > clang, -O in clang is equal to -O2 where as in gcc its
PCRE has an optional JIT for performance.
Add a PACKAGECONFIG for this, enabled by default.
Also add a patch so that auto-detection of JIT availablity, which is required to
enable the JIT by default, works with out-of-tree builds.
Signed-off-by: Ross Burton
---
The following options are the defaults, so remove them:
--enable-newline-is-lf
--with-match-size=2
--with-match-limit=1000
We don't appear to need to pass -D_REENTRANT anymore (added with no explanation
to oe-classic in 2006).
Explicitly adding -lstdc++ doesn't appear to be required anymore
Signed-off-by: Khem Raj
---
v2: Add checksums and fix version
meta/recipes-devtools/gcc/gcc-8.2.inc | 115 -
...bgcc-Add-knob-to-use-ldbl-128-on-ppc.patch | 465 --
.../gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch | 44 --
meta/recipes-devtools/gcc/gcc-8.3.inc
Signed-off-by: Khem Raj
---
meta/recipes-devtools/gcc/gcc-8.2.inc | 115 -
...bgcc-Add-knob-to-use-ldbl-128-on-ppc.patch | 465 --
.../gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch | 44 --
meta/recipes-devtools/gcc/gcc-8.3.inc | 109
Signed-off-by: Richard Purdie
---
scripts/lib/resulttool/template/test_report_full_text.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/lib/resulttool/template/test_report_full_text.txt
b/scripts/lib/resulttool/template/test_report_full_text.txt
index
ptest suites with no results don't show up on the reports even though we have
a duration for them. Fix this so the fact they report no tests is visible.
Signed-off-by: Richard Purdie
---
scripts/lib/resulttool/report.py | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff
Currently some older results files cause the code to give tracebacks.
Handle these missing sections more cleanly.
Signed-off-by: Richard Purdie
---
scripts/lib/resulttool/report.py | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/scripts/lib/resulttool/report.py
Currently we cant store results if the results files span multiple
different build revisons. Remove this limitation by iterating.
Signed-off-by: Richard Purdie
---
scripts/lib/resulttool/store.py | 39 +++--
1 file changed, 23 insertions(+), 16 deletions(-)
diff
openssl-ptest was recording now results, despite most tests passing. Fix
so that the successes/skips/failures are reported correctly.
Signed-off-by: Richard Purdie
---
meta/recipes-connectivity/openssl/openssl/run-ptest | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
qemu-helper-native would erroneously pull in the qemu system
parts, where we only want usermode parts for pgo.
Signed-off-by: Alexander Kanavin
---
meta/recipes-devtools/python/python3_3.7.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Signed-off-by: Alexander Kanavin
---
meta-poky/conf/local.conf.sample | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-poky/conf/local.conf.sample b/meta-poky/conf/local.conf.sample
index 267108d6850..9068e567dcd 100644
--- a/meta-poky/conf/local.conf.sample
+++
The rationale is to streamline the overall build.
The system parts are only needed to run target images, and so can be
built towards the end of the build process. At the same time, the
system parts may need gtk+-native and mesa-native which add significantly
to the build time.
On the other hand,
Hello everyone,
I'm trying to add node_exporter from Prometheus project to an Intel x86-64
machine.
I made the following recipe:
https://github.com/nefethael/meta-random/blob/master/recipes-connectivity/prometheus/go-nodeexporter_0.18.0.bb
node_exporter is crashing with multiple different
On Wed, Feb 27, 2019 at 5:50 AM Alexander Kanavin
wrote:
>
> The rationale is to streamline the overall build.
>
> The system parts are only needed to run target images, and so can be
> built towards the end of the build process. At the same time, the
> system parts need gtk+-native and
From: Chunrong Guo
Leaving bits/procfs-id.h,bits/procfs.h,bits/shmlba.h out of being multilibbed
introduced a problem in building the SDK for arm64:
Error: Transaction check error:
file /usr/include/bits/procfs-id.h conflicts between attempted installs of
lib64-libc6-dev-2.29-r0.aarch64 and
It is only needed by 95-test_external_pyca_data which is
actually skipped on the target.
[YOCTO #13204]
Signed-off-by: Alexander Kanavin
---
meta/recipes-connectivity/openssl/openssl_1.1.1a.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
qemu-helper-native would erroneously pull in the qemu system
parts, where we only want usermode parts for pgo.
Signed-off-by: Alexander Kanavin
---
meta/recipes-devtools/python/python3_3.7.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The rationale is to streamline the overall build.
The system parts are only needed to run target images, and so can be
built towards the end of the build process. At the same time, the
system parts need gtk+-native and mesa-native which add significantly
to the build time.
On the other hand, the
Signed-off-by: Alexander Kanavin
---
meta-poky/conf/local.conf.sample | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-poky/conf/local.conf.sample b/meta-poky/conf/local.conf.sample
index 98ff5c23256..eee65b5875a 100644
--- a/meta-poky/conf/local.conf.sample
+++
From: Kai Kang
Update RCONFLICTS and RREPLACES for util-linux to fix 'multilib' qa issue:
| ERROR: lib32-util-linux-2.32.1-r0 do_package: QA Issue: lib32-util-linux
package lib32-util-linux-blkid - suspicious values 'e2fsprogs-blkid' in
RREPLACES [multilib]
| ERROR:
On Wed, 2019-02-27 at 09:10 +, Olaf Mandel wrote:
> The bosybox version of tar in sumo considers symlink targets that
> start
> with / or with ../ to be unsafe and refuses to unpack them unless the
> EXTRACT_UNSAFE_SYMLINKS environment variable is set to 1.
>
> As even many core packages
The bosybox version of tar in sumo considers symlink targets that start
with / or with ../ to be unsafe and refuses to unpack them unless the
EXTRACT_UNSAFE_SYMLINKS environment variable is set to 1.
As even many core packages legitimately contain such links (e.g.
coreutils-locale-*, dropbear,
46 matches
Mail list logo
