On 08/16/2019 02:53 PM, Kang Kai wrote:
On 2019/8/12 下午4:57, Kang Kai wrote:
On 2019/7/27 下午4:42, Kang Kai wrote:
On 2019/7/27 上午5:40, richard.pur...@linuxfoundation.org wrote:
On Fri, 2019-07-26 at 05:23 -0400, kai.k...@windriver.com wrote:
From: Kai Kang
When run do_testimage for core-ima
The /etc/init.d/psplash.sh will be invoked both in boot and
shutdown/reboot. And the psplash tmpfs will be mounted twice. This
will trigger a bug in umount and let the system hang when
shutdown/reboot. I already made a patch [1] to fix the issue in
umount, but there is no reason for the psplash to
== Series Details ==
Series: psplash: Avoid mount the psplash tmpfs twice
Revision: 1
URL : https://patchwork.openembedded.org/series/19350/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been ex
At the past few OopenEmbedded developer meetings, people have been
asking for more developer and user focused events like a miniconf.
Partly based on this feedback, there is a two day event sponsored by the
Yocto Project that provides a chance for people to talk about the Yocto
Project and OpenEmbe
On Sun, Aug 18, 2019 at 11:00 PM Kang Kai wrote:
> On 2019/8/18 上午3:27, Otavio Salvador wrote:
> Would you like to give more detailed steps how the error occurred? And
> what's extra settings in you local.conf please?
I had sysvinit and systemd enabled.
--
Otavio Salvador
On Sat, 17 Aug 2019 at 20:49, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:
> I tried but couldn't figure out how to fix it and as I am not a meson
> expect, I preferred to rather revert it and succeed with the upgrade.
>
> Can you send a patch fixing it?
>
Can you try adding 'python
hi Philip,
thanks for sending this out!
On Mon, Aug 19, 2019 at 3:17 AM Philip Balister wrote:
>
> At the past few OopenEmbedded developer meetings, people have been
> asking for more developer and user focused events like a miniconf.
> Partly based on this feedback, there is a two day event spo
Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
which caused rpc.statd failed with out of memory.
[ 531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
sacrifice child
The rpc.statd allocates memory according to RLIMIT_NOFILE,
so decrease it to 4k to ke
Signed-off-by: Anuj Mittal
---
meta/recipes-devtools/binutils/binutils-2.32.inc | 2 ++
.../binutils/binutils/CVE-2019-14250.patch | 33 ++
.../binutils/binutils/CVE-2019-1.patch | 28 ++
3 files changed, 63 insertions(+)
create mode 100
Signed-off-by: Anuj Mittal
---
.../pango/pango/CVE-2019-1010238.patch | 38 ++
meta/recipes-graphics/pango/pango_1.42.4.bb| 4 ++-
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch
Signed-off-by: Anuj Mittal
---
.../glib-2.0/glib-2.0/CVE-2019-13012.patch | 40 ++
meta/recipes-core/glib-2.0/glib-2.0_2.58.3.bb | 1 +
2 files changed, 41 insertions(+)
create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch
diff --git a/me
Signed-off-by: Anuj Mittal
---
meta/recipes-devtools/binutils/binutils-2.32.inc | 2 ++
.../binutils/binutils/CVE-2019-14250.patch | 33 ++
.../binutils/binutils/CVE-2019-1.patch | 28 ++
3 files changed, 63 insertions(+)
create mode 100
From: He Zhe
Backport a patch to fix the followig failure.
tgkill03.c:94: FAIL: Defunct tid should have failed with ESRCH: SUCCESS
Signed-off-by: He Zhe
---
...kill03-wait-for-defunct-tid-to-get-detach.patch | 75 ++
meta/recipes-extended/ltp/ltp_20190517.bb | 1 +
From: He Zhe
Backport a patch to fix the following failure.
ustat02.c:44: FAIL: ustat(2) failed to produce expected error; 14, errno:
EFAULT: EINVAL
Signed-off-by: He Zhe
---
...02-Fix-EFAULT-in-32bit-compatibility-mode.patch | 36 ++
meta/recipes-extended/ltp/ltp_20190517
Should the limit be simply raised? The 256M setup is crumbling on several
fronts (runtime tests, modernisation of X, various non-x86 qemu targets).
Adding per-image/target exceptions, custom non-upstreamable patches, or
sticking to deprecated configurations isn't the right thing to do, I think.
Al
== Series Details ==
Series: "[warrior] binutils: fix CVE-20..." and 2 more
Revision: 1
URL : https://patchwork.openembedded.org/series/19354/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
On Mon, 2019-08-19 at 14:02 +, Patchwork wrote:
> * Issue Series does not apply on top of target branch
> [test_series_merge_on_head]
> Suggested fixRebase your series on top of targeted branch
> Targeted branch warrior (currently at 952bfcc3f4)
This is intentional. These
On 8/19/19 10:01 PM, Alexander Kanavin wrote:
Should the limit be simply raised? The 256M setup is crumbling on
several fronts (runtime tests, modernisation of X, various non-x86
qemu targets). Adding per-image/target exceptions, custom
non-upstreamable patches, or sticking to deprecated config
On 14/08/2019 23:46, Khem Raj wrote:
On Wed, Aug 14, 2019 at 3:42 PM akuster808 wrote:
On 8/14/19 3:29 PM, Khem Raj wrote:
libffi 3.1 release has been a bit aged and new architectures, compilers
have since been come on stage to compile it, we have been carrying
patches, but its better to us
Probably in this case it is better to add a patch that allows
HIGH_RLIMIT_NOFILE to be configured from the systemd recipe via meson
switches, and offer that to systemd upstream.
Alex
On Mon, 19 Aug 2019 at 16:25, Hongxu Jia wrote:
> On 8/19/19 10:01 PM, Alexander Kanavin wrote:
>
> Should the l
On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
> Should the limit be simply raised? The 256M setup is crumbling on
> several fronts (runtime tests, modernisation of X, various non-x86
> qemu targets). Adding per-image/target exceptions, custom non-
> upstreamable patches, or sticking t
On Mon, Aug 19, 2019 at 7:31 AM Ross Burton wrote:
> On 14/08/2019 23:46, Khem Raj wrote:
> > On Wed, Aug 14, 2019 at 3:42 PM akuster808 wrote:
> >>
> >>
> >>
> >> On 8/14/19 3:29 PM, Khem Raj wrote:
> >>> libffi 3.1 release has been a bit aged and new architectures, compilers
> >>> have since b
On Mon, 19 Aug 2019 at 16:55, wrote:
> I'd even possibly accept a case for higher memory defaults for graphics
> images when GL is enabled. Pushing the default qemu memory size to
> 512MB everywhere is wrong though and sends out the wrong message for
> the project.
>
Thanks for the response (I d
On 19/08/2019 16:09, Khem Raj wrote:
Set the PV to 3.3~rc0 and 3.3 will sort after it.
I thinking using + terminology is familiar in OE world let’s stick to it
I worked on adding ~ explicitly for this exact problem (as used by
Fedora, Debian, etc), so please let's use ~ instead of messin
On 19/08/2019 11:37, Otavio Salvador wrote:
On Sun, Aug 18, 2019 at 11:00 PM Kang Kai wrote:
On 2019/8/18 上午3:27, Otavio Salvador wrote:
Would you like to give more detailed steps how the error occurred? And
what's extra settings in you local.conf please?
I had sysvinit and systemd enabled.
Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
which caused rpc.statd failed with out of memory.
[ 531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
sacrifice child
The rpc.statd allocates memory according to RLIMIT_NOFILE,
so decrease RLIMIT_NOFILE
On Mon, Aug 19, 2019 at 9:20 AM Ross Burton wrote:
>
> On 19/08/2019 16:09, Khem Raj wrote:
> > Set the PV to 3.3~rc0 and 3.3 will sort after it.
> >
> >
> > I thinking using + terminology is familiar in OE world let’s stick to it
>
> I worked on adding ~ explicitly for this exact problem (as
libffi 3.1 release has been a bit aged and new architectures, compilers
have since been come on stage to compile it, we have been carrying
patches, but its better to use the latest 3.3 rc0 which has lot of these
issues handled and is in good shape.
Use 3.3~rc0 for PV to keep room for upgrade path
Signed-off-by: Khem Raj
---
meta/recipes-bsp/opensbi/opensbi_0.4.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-bsp/opensbi/opensbi_0.4.bb
b/meta/recipes-bsp/opensbi/opensbi_0.4.bb
index 382752895c..b030436688 100644
--- a/meta/recipes-bsp/opensbi/opensbi_0.4.bb
+++ b/meta
On 8/19/19 11:27 AM, Ross Burton wrote:
> On 19/08/2019 11:37, Otavio Salvador wrote:
>> On Sun, Aug 18, 2019 at 11:00 PM Kang Kai wrote:
>>> On 2019/8/18 上午3:27, Otavio Salvador wrote:
>>> Would you like to give more detailed steps how the error occurred? And
>>> what's extra settings in you loca
On Mon, Aug 19, 2019 at 1:48 PM Mark Hatle wrote:
> On 8/19/19 11:27 AM, Ross Burton wrote:
> > On 19/08/2019 11:37, Otavio Salvador wrote:
> >> On Sun, Aug 18, 2019 at 11:00 PM Kang Kai wrote:
> >>> On 2019/8/18 上午3:27, Otavio Salvador wrote:
> >>> Would you like to give more detailed steps how
On 8/19/19 11:49 AM, Otavio Salvador wrote:
> On Mon, Aug 19, 2019 at 1:48 PM Mark Hatle wrote:
>> On 8/19/19 11:27 AM, Ross Burton wrote:
>>> On 19/08/2019 11:37, Otavio Salvador wrote:
On Sun, Aug 18, 2019 at 11:00 PM Kang Kai wrote:
> On 2019/8/18 上午3:27, Otavio Salvador wrote:
>
On Mon, Aug 19, 2019 at 9:38 AM Hongxu Jia wrote:
>
> Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
> which caused rpc.statd failed with out of memory.
> [ 531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
> sacrifice child
>
> The rpc.statd allocat
All,
The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#N
On Fri, Aug 16, 2019 at 07:22:55PM +0200, Martin Jansa wrote:
> On Fri, Aug 16, 2019 at 04:54:48PM +0100, richard.pur...@linuxfoundation.org
> wrote:
> > On Fri, 2019-08-16 at 17:00 +0200, Martin Jansa wrote:
> > > > Will try to bump BB_NUMBER_THREADS from 8 to 72.
> > >
> > > I've tried to remov
From: Changqing Li
Configuration:
MACHINE = qemumips64
bitbake lib32-core-image-minimal
runqemu slirp nographic qemumips64 ext4
Error:
ERROR - Failed to run qemu: qemu-system-mips: unable to find CPU model
'MIPS64R2-generic'
Fixed by moving QB_SYSTEM_NAME to Respective configuration file
Sig
On systemd, it set RLIMIT_NOFILE to 512k, since do_testimage
for core-image-sato-sdk has memory limitation (256Mib) which
caused rpc.statd failed with out of memory.
[ 531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
sacrifice child
The rpc.statd and rpc.mountd allocates memo
Remove patch 0001-nis-hosts-Remove-use-of-RES_USE_INET6.patch
since this is included in 3.1
Signed-off-by: Yuan Chao
---
.../recipes-extended/libnss-nis/libnss-nis.bb | 5 +-
...is-hosts-Remove-use-of-RES_USE_INET6.patch | 162 --
2 files changed, 2 insertions(+), 165 deletions
-License-Update: Copyright year updated to 2019.
-libbsd/0001-flopen-Add-missing-fcntl.h-include.patch
Removed since these are included in 0.10.0.
Signed-off-by: Zang Ruochen
---
.../0001-flopen-Add-missing-fcntl.h-include.patch | 46 --
.../libbsd/{libbsd_0.9.1.bb => lib
39 matches
Mail list logo
