[OE-core] [PATCH] libnss-nis: upgrade 3.0 -> 3.1

[Yuan Chao]

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(-)
 delete mode 100644 
meta/recipes-extended/libnss-nis/libnss-nis/0001-nis-hosts-Remove-use-of-RES_USE_INET6.patch

diff --git a/meta/recipes-extended/libnss-nis/libnss-nis.bb 
b/meta/recipes-extended/libnss-nis/libnss-nis.bb
index 4fbd4b1f6a..a1d914e871 100644
--- a/meta/recipes-extended/libnss-nis/libnss-nis.bb
+++ b/meta/recipes-extended/libnss-nis/libnss-nis.bb
@@ -13,12 +13,11 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 SECTION = "libs"
 DEPENDS += "libtirpc libnsl2"
 
-PV = "3.0+git${SRCPV}"
+PV = "3.1+git${SRCPV}"
 
-SRCREV = "d4aea48657a8e90d7922574b8021ee03915a36cb"
+SRCREV = "062f31999b35393abf7595cb89dfc9590d5a42ad"
 
 SRC_URI = "git://github.com/thkukuk/libnss_nis \
-   file://0001-nis-hosts-Remove-use-of-RES_USE_INET6.patch \
   "
 
 S = "${WORKDIR}/git"
diff --git 
a/meta/recipes-extended/libnss-nis/libnss-nis/0001-nis-hosts-Remove-use-of-RES_USE_INET6.patch
 
b/meta/recipes-extended/libnss-nis/libnss-nis/0001-nis-hosts-Remove-use-of-RES_USE_INET6.patch
deleted file mode 100644
index 348c8c94b6..00
--- 
a/meta/recipes-extended/libnss-nis/libnss-nis/0001-nis-hosts-Remove-use-of-RES_USE_INET6.patch
+++ /dev/null
@@ -1,162 +0,0 @@
-From e41ddbd89a4bb042ac00469fa5880ba584c25c05 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 25 Jul 2019 12:10:56 -0700
-Subject: [PATCH] nis-hosts: Remove use of RES_USE_INET6
-
-Upstream glibc dropped it starting glibc 2.30
-see
-https://sourceware.org/git/?p=glibc.git;a=commit;h=3f8b44be0a658266adff5ece1e4bc3ce097a5dbe
-
-Fixes issue #6
-
-Upstream-Status: Submitted [https://github.com/thkukuk/libnss_nis/pull/7]
-
-Signed-off-by: Khem Raj 

- src/nis-hosts.c | 55 -
- 1 file changed, 13 insertions(+), 42 deletions(-)
-
-diff --git a/src/nis-hosts.c b/src/nis-hosts.c
-index 307b46e..bd3c4ad 100644
 a/src/nis-hosts.c
-+++ b/src/nis-hosts.c
-@@ -35,15 +35,12 @@
- #include "libc-lock.h"
- #include "nss-nis.h"
- 
--/* Get implementation for some internal functions. */
--#include "mapv4v6addr.h"
--
- #define ENTNAME hostent
- #define DATABASE"hosts"
- #define NEED_H_ERRNO
- 
--#define EXTRA_ARGS  , af, flags
--#define EXTRA_ARGS_DECL , int af, int flags
-+#define EXTRA_ARGS  , af
-+#define EXTRA_ARGS_DECL , int af
- 
- #define ENTDATA hostent_data
- struct hostent_data
-@@ -67,19 +64,8 @@ LINE_PARSER
-/* Parse address.  */
-if (af != AF_INET6 && inet_pton (AF_INET, addr, entdata->host_addr) > 0)
-  {
--   assert ((flags & AI_V4MAPPED) == 0 || af != AF_UNSPEC);
--   if (flags & AI_V4MAPPED)
--   {
-- map_v4v6_address ((char *) entdata->host_addr,
--   (char *) entdata->host_addr);
-- result->h_addrtype = AF_INET6;
-- result->h_length = IN6ADDRSZ;
--   }
--   else
--   {
-- result->h_addrtype = AF_INET;
-- result->h_length = INADDRSZ;
--   }
-+   result->h_addrtype = AF_INET;
-+   result->h_length = INADDRSZ;
-  }
-else if (af != AF_INET
-   && inet_pton (AF_INET6, addr, entdata->host_addr) > 0)
-@@ -134,7 +120,7 @@ strong_alias (_nss_nis_sethostent, _nss_nis_endhostent)
- static enum nss_status
- internal_nis_gethostent_r (struct hostent *host, char *buffer,
-  size_t buflen, int *errnop, int *h_errnop,
-- int af, int flags)
-+ int af)
- {
-   char *domain;
-   if (yp_get_default_domain ())
-@@ -203,7 +189,7 @@ internal_nis_gethostent_r (struct hostent *host, char 
*buffer,
-   ++p;
-   free (result);
- 
--  parse_res = parse_line (p, host, data, buflen, errnop, af, flags);
-+  parse_res = parse_line (p, host, data, buflen, errnop, af);
-   if (parse_res == -1)
-   {
- free (outkey);
-@@ -232,8 +218,7 @@ _nss_nis_gethostent_r (struct hostent *host, char *buffer, 
size_t buflen,
-   __libc_lock_lock (lock);
- 
-   status = internal_nis_gethostent_r (host, buffer, buflen, errnop, h_errnop,
--  ((_res.options & RES_USE_INET6) ? AF_INET6 : AF_INET),
--  ((_res.options & RES_USE_INET6) ? AI_V4MAPPED : 0 ));
-+  AF_INET);
- 
-   __libc_lock_unlock (lock);
- 
-@@ -244,7 +229,7 @@ _nss_nis_gethostent_r (struct hostent *host, char *buffer, 
size_t buflen,
- static enum nss_status
- internal_gethostbyname2_r (const char *name, int af, struct hostent *host,
-  char *buffer, size_t buflen, int *errnop,
-- int *h_errnop, int flags)
-+ int *h_errnop)
- {
-   uintptr_t pad = -(uintptr_t) 

[OE-core] [PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[Hongxu Jia]

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 memory according to
RLIMIT_NOFILE, so decrease it to 4k to keep sync with sysvinit

After applying the patch, the memory cost is the same with sysvinit:

root@qemux86-64:~# systemctl status nfs-statd
* nfs-statd.service - NFS status monitor for NFSv2/3 locking.
   Loaded: loaded (/lib/systemd/system/nfs-statd.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Tue 2019-08-20 03:16:18 UTC; 3min 26s ago
 Main PID: 343 (rpc.statd)
Tasks: 1 (limit: 271)
   Memory: 1.0M

root@qemux86-64:~# systemctl status nfs-mountd
* nfs-mountd.service - NFS Mount Daemon
   Loaded: loaded (/etc/systemd/system/nfs-mountd.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Tue 2019-08-20 03:19:01 UTC; 1min 21s ago
 Main PID: 451 (rpc.mountd)
Tasks: 1 (limit: 271)
   Memory: 736.0K

Suggested-by: Chen Qi 
Signed-off-by: Hongxu Jia 
---
 meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service | 1 +
 meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service  | 1 +
 meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb   | 4 
 3 files changed, 6 insertions(+)

diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
index 3c3a802..c01415d 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
@@ -11,6 +11,7 @@ ConditionPathExists=@SYSCONFDIR@/exports
 [Service]
 EnvironmentFile=-@SYSCONFDIR@/nfs-utils.conf
 ExecStart=@SBINDIR@/rpc.mountd -F $MOUNTD_OPTS
+LimitNOFILE=@HIGH_RLIMIT_NOFILE@
 
 [Install]
 WantedBy=multi-user.target
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
index 6e196b8..4fa64e1 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
@@ -8,6 +8,7 @@ After=network.target nss-lookup.target rpcbind.service
 [Service]
 EnvironmentFile=-@SYSCONFDIR@/nfs-utils.conf
 ExecStart=@SBINDIR@/rpc.statd -F $STATD_OPTS
+LimitNOFILE=@HIGH_RLIMIT_NOFILE@
 
 [Install]
 WantedBy=multi-user.target
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
index ac4437b..28f9898 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
@@ -119,6 +119,9 @@ do_compile_prepend() {
make clean
 }
 
+# Works on systemd only
+HIGH_RLIMIT_NOFILE ??= "4096"
+
 do_install_append () {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/nfsserver ${D}${sysconfdir}/init.d/nfsserver
@@ -133,6 +136,7 @@ do_install_append () {
install -m 0644 ${WORKDIR}/nfs-statd.service 
${D}${systemd_unitdir}/system/
sed -i -e 's,@SBINDIR@,${sbindir},g' \
-e 's,@SYSCONFDIR@,${sysconfdir},g' \
+   -e 's,@HIGH_RLIMIT_NOFILE@,${HIGH_RLIMIT_NOFILE},g' \
${D}${systemd_unitdir}/system/*.service
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
install -m 0644 ${WORKDIR}/proc-fs-nfsd.mount 
${D}${systemd_unitdir}/system/
-- 
2.8.1

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

[OE-core] [PATCH] qemumips/qemumips64: move QB_SYSTEM_NAME to corresponding conf

[changqing.li]

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

Signed-off-by: Changqing Li 
---
 meta/conf/machine/include/qemuboot-mips.inc | 1 -
 meta/conf/machine/qemumips.conf | 2 ++
 meta/conf/machine/qemumips64.conf   | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/qemuboot-mips.inc 
b/meta/conf/machine/include/qemuboot-mips.inc
index 75bb988..a5f9ed8 100644
--- a/meta/conf/machine/include/qemuboot-mips.inc
+++ b/meta/conf/machine/include/qemuboot-mips.inc
@@ -6,4 +6,3 @@ QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty"
 QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -device usb-tablet"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
-QB_SYSTEM_NAME = "qemu-system-${TUNE_ARCH}"
diff --git a/meta/conf/machine/qemumips.conf b/meta/conf/machine/qemumips.conf
index 48d9f41..31ad754 100644
--- a/meta/conf/machine/qemumips.conf
+++ b/meta/conf/machine/qemumips.conf
@@ -10,3 +10,5 @@ KERNEL_IMAGETYPE = "vmlinux"
 KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
 
 SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"
+
+QB_SYSTEM_NAME = "qemu-system-mips"
diff --git a/meta/conf/machine/qemumips64.conf 
b/meta/conf/machine/qemumips64.conf
index 1872e7b..6d51746 100644
--- a/meta/conf/machine/qemumips64.conf
+++ b/meta/conf/machine/qemumips64.conf
@@ -12,3 +12,5 @@ KERNEL_IMAGETYPE = "vmlinux"
 KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
 
 SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"
+
+QB_SYSTEM_NAME = "qemu-system-mips64"
-- 
2.7.4

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

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

[Martin Jansa]

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 remove icecc.bbclass inherit (because it does things
> > > while parsing and RP probably doesn't have it inherited), but that
> > > didn't save much time.
> > > 
> > > All 3 tests were with bitbake
> > > 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7
> > > 94m19.081s  8 BB_NUMBER_THREADS and icecc
> > > 82m59.574s  8 BB_NUMBER_THREADS no icecc
> > > 68m3.556s72 BB_NUMBER_THREADS no icecc
> > > 
> > > Still don't know how to get to sub 10min world runs RP was seeing,
> > > but at least it's as slow as it was before runqeueu changes (or even
> > > a bit faster in lastest master).
> > 
> > Just thinking out loud, other things which can influence timings:
> > 
> > Is SSTATE_DIR on NFS or local disk?
> 
> SSTATE_DIR is empty directory on local disk
> /dev/mapper/vg00-jenkins on /jenkins type ext4 
> (rw,noatime,nobarrier,commit=6000,stripe=128,data=ordered)
> 
> > Are sstate mirrors configured?
> 
> None, normally I have SSTATE_MIRRORS over sshfs in this case, but I've
> removed it before any performance testing.
> 
> > Is there an existing build or not, if so, how much is valid?
> 
> Nothing, I remove whole TMPDIR and cache before each run. Then let it
> recreate the cache before starting the profile:
> bitbake -p; time bitbake world -P -n
> 
> > Underlying filesystem of the build?
> 
> ext4, everything is pretty much generic Ubuntu 18.04
> 
> There is plenty of ram, I'll try to test this from tmpfs as well.

I did the same "bitbake -p; time bitbake world -P -n" on the same build with 
thud, warrior and zeus:

thud/profile.log.processed: 2803894450 function calls (2803191143 
primitive calls) in 3340.784 seconds
thud/profile-worker.log.processed: 27005515 function calls (26944030 
primitive calls) in 3243.139 seconds
warrior/profile.log.processed: 2804294486 function calls (2803446296 
primitive calls) in 3604.226 seconds
warrior/profile-worker.log.processed: 27649679 function calls (27591220 
primitive calls) in 3503.772 seconds
zeus/profile.log.processed: 2327031298 function calls (2326396186 
primitive calls) in 4433.851 seconds
zeus/profile-worker.log.processed: 28829453 function calls (28771730 
primitive calls) in 4331.257 seconds

thud/time:real55m41.595s
warrior/time:real60m4.954s
zeus/time:real72m23.053s

with multilib disabled I got
zeus-no-multilib/profile.log.processed: 1232798107 function calls 
(1232447521 primitive calls) in 1773.164 seconds
zeus-no-multilib/profile-worker.log.processed: 15561565 function calls 
(1044 primitive calls) in 1716.234 seconds
real29m33.658s

Which seems reasonable as the number of tasks was cut in half.

Let me know if it's worth uploading these profiles somewhere.

Cheers,

> > Your build seems especially slow at executing through the tasks which
> > is effectively a test on how fast the system can fork() and return in
> > some ways. It would be interesting to block dry-run on the server side,
> > skip the fork and see how the numbers compare.
> 
> As discussed on IRC, it's slower than yours (8 minutes from 68), but the
> most significant chunk of time is lost somewhere else.
> 
> > My build manages some parts of the tasklist faster than others, perhaps
> > because there are more "free" tasks to execute at some points in the
> > task graph than others.
> > 
> > Also, I have some patches which improve performance a bit which I'm
> > still testing.
> 
> Thanks for all the work on this!
> 
> Cheers,
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[sjolley.yp.pm]

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#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 297
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "2.8", "2.9', "2.99" and "Future", the more pressing/urgent
issues being in "2.8" and then "2.9".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

 

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

Re: [OE-core] [PATCH V2] systemd: add menson option to decrease RLIMIT_NOFILE on qemu bsp

[Andre McCurdy]

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 allocates memory according to RLIMIT_NOFILE,
> so decrease RLIMIT_NOFILE to 4k to keep sync with sysvinit
>
> After applying the patch, the memory cost is the same with sysvinit
> rpcuser340  0.0  1.0   3212  2588 ?Ss   13:20   0:00 
> /usr/sbin/rpc.statd -F
> root   473  0.0  0.2   3464   496 ?Ss   13:23   0:00 
> /usr/sbin/rpc.mountd
>
> For other bsp, still keep RLIMIT_NOFILE to 512k by default
>
> Signed-off-by: Hongxu Jia 
> ---
>  ...001-meson-add-option-to-set-RLIMIT_NOFILE.patch | 50 
> ++
>  meta/recipes-core/systemd/systemd_242.bb   |  5 +++
>  2 files changed, 55 insertions(+)
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
>
> diff --git 
> a/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
>  
> b/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
> new file mode 100644
> index 000..e822238
> --- /dev/null
> +++ 
> b/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
> @@ -0,0 +1,50 @@
> +From d42d1512402de0d2249e2d68040c5c3887e7ea99 Mon Sep 17 00:00:00 2001
> +From: Hongxu Jia 
> +Date: Mon, 19 Aug 2019 12:06:59 -0400
> +Subject: [PATCH] meson: add option to set RLIMIT_NOFILE
> +
> +Add option to set RLIMIT_NOFILE and keep 512*1024 by default
> +
> +It is helpful for embedded device which has memory limitation
> +to decrease RLIMIT_NOFILE
> +
> +Upstream-Status: Submitted [https://github.com/systemd/systemd/pull/13359]
> +
> +Signed-off-by: Hongxu Jia 
> +---
> + meson.build   | 2 +-
> + meson_options.txt | 5 +
> + 2 files changed, 6 insertions(+), 1 deletion(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 18a7cc5..26d9cf0 100644
> +--- a/meson.build
>  b/meson.build
> +@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and 
> sysvrcnd_path != '',
> +
> + conf.set10('BUMP_PROC_SYS_FS_FILE_MAX', 
> get_option('bump-proc-sys-fs-file-max'))
> + conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',  
> get_option('bump-proc-sys-fs-nr-open'))
> +-conf.set('HIGH_RLIMIT_NOFILE',  512*1024)
> ++conf.set('HIGH_RLIMIT_NOFILE',  get_option('high-rlimit-nofile'))
> +
> + # join_paths ignores the preceding arguments if an absolute component is
> + # encountered, so this should canonicalize various paths when they are
> +diff --git a/meson_options.txt b/meson_options.txt
> +index d4ec37d..5d4ee18 100644
> +--- a/meson_options.txt
>  b/meson_options.txt
> +@@ -56,6 +56,11 @@ option('bump-proc-sys-fs-file-max', type : 'boolean',
> +description : 'bump /proc/sys/fs/file-max to ULONG_MAX')
> + option('bump-proc-sys-fs-nr-open', type : 'boolean',
> +description : 'bump /proc/sys/fs/nr_open to INT_MAX')
> ++
> ++# Default is 512*1024
> ++option('high-rlimit-nofile', type : 'integer', value : 524288,
> ++   description : 'set RLIMIT_NOFILE')
> ++
> + option('valgrind', type : 'boolean', value : false,
> +description : 'do extra operations to avoid valgrind warnings')
> + option('log-trace', type : 'boolean', value : false,
> +--
> +2.8.1
> +
> diff --git a/meta/recipes-core/systemd/systemd_242.bb 
> b/meta/recipes-core/systemd/systemd_242.bb
> index 1953fef..96a53dc 100644
> --- a/meta/recipes-core/systemd/systemd_242.bb
> +++ b/meta/recipes-core/systemd/systemd_242.bb
> @@ -28,6 +28,7 @@ SRC_URI += "file://touchscreen.rules \
> 
> file://0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch \
> file://0001-networkd-fix-link-up.patch \
> file://0002-network-do-not-send-ipv6.patch \
> +   file://0001-meson-add-option-to-set-RLIMIT_NOFILE.patch \
> "
>
>  # patches needed by musl
> @@ -211,6 +212,10 @@ EXTRA_OEMESON += "-Dkexec-path=${sbindir}/kexec \
>-Dsulogin-path=${base_sbindir}/sulogin \
>-Dumount-path=${base_bindir}/umount"
>
> +EXTRA_OEMESON += "-Dhigh-rlimit-nofile=${RLIMIT_NOFILE}"
> +RLIMIT_NOFILE ??= "524288"
> +RLIMIT_NOFILE_qemuall ?= "4096"

This doesn't look right. By making the fix qemu specific you're
effectively changing the QA tests to pass - but leaving the underlying
issue there for all real world use cases.

Better to set the safe value by default and let users with lots of
memory change it if they need to.

> +
>  do_install() {
> meson_do_install
> install -d ${D}/${base_sbindir}
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 

Re: [OE-core] Conflict of systemd and sysvinit

[Mark Hatle]

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:
> 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.
>>>
>>> The autobuilder should be exercising this, so when it's fixed we need to
>>> ensure the AB covers the case Otavio is hitting.
>>
>> If they are both enabled what is the expected functionality of the system?
>> (which is init, etc...)
> 
> The image needs to pick the desired ones.
> 
> 

Ok.. so build both packages.. and then come install time, one or the other must
be in the PACKAGE_INSTALL (however the image chooses to do this), and the other
should NOT be included.

This could be problematic, as I've seen recipes build with systemd dependencies
in them.  (Both initscripts as well as system health monitoring and such..  That
would conflict with a sysvinit [or systemd] if configured for the other.)
Someone may need to review dependencies in the system looking for things that
depend on systemd... or have a systemd/sysvinit 'conflict' of some kind.  (I've
not attempted such an audit before.)

I would be interested in seeing dependency graphs on this.  In my own work I've
selected one or the other at the distribution level, not image level.

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

Re: [OE-core] Conflict of systemd and sysvinit

[Otavio Salvador]

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 the error occurred? And
> >>> what's extra settings in you local.conf please?
> >>
> >> I had sysvinit and systemd enabled.
> >
> > The autobuilder should be exercising this, so when it's fixed we need to
> > ensure the AB covers the case Otavio is hitting.
>
> If they are both enabled what is the expected functionality of the system?
> (which is init, etc...)

The image needs to pick the desired ones.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Conflict of systemd and sysvinit

[Mark Hatle]

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 local.conf please?
>>
>> I had sysvinit and systemd enabled.
> 
> The autobuilder should be exercising this, so when it's fixed we need to 
> ensure the AB covers the case Otavio is hitting.

If they are both enabled what is the expected functionality of the system?
(which is init, etc...)

--Mark

> Ross
> 

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

[OE-core] [PATCH 2/2] opensbi: Disable SECURITY_CFLAGS since it cant link with libssp

[Khem Raj]

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/recipes-bsp/opensbi/opensbi_0.4.bb
@@ -49,3 +49,5 @@ FILES_${PN} += 
"/platform/${RISCV_SBI_PLAT}/firmware/fw_dynamic.*"
 
 COMPATIBLE_HOST = "(riscv64|riscv32).*"
 INHIBIT_PACKAGE_STRIP = "1"
+
+SECURITY_CFLAGS = ""
-- 
2.22.1

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

[OE-core] [PATCH V4 1/2] libffi: Upgrade to 3.3-rc0

[Khem Raj]

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 without PE bump

fix the multilib header conflict

file /usr/include/ffi.h from install of libffi-dev-3.2.1+3.3+rc0-r0.core2_32 
conflicts with file from package lib64-libffi-dev-3.2.1+3.3+rc0-r0.x86_64

Signed-off-by: Khem Raj 
---
v2: Set PV = 3.2.1+3.3-rc0
v3: fix ffi.h multilib header conflict
v3: Use ~ instead of + in PV, set it to 3.3~rc0

 .../libffi/0001-New-RISC-V-port-281.patch | 827 --
 .../0001-libffi-Support-musl-x32-build.patch  |  30 -
 ...e-compiler-internal-define-for-linux.patch |  32 -
 ...-mips-fix-MIPS-softfloat-build-issue.patch | 177 
 .../libffi/libffi/not-win32.patch |  10 +-
 .../{libffi_3.2.1.bb => libffi_3.3~rc0.bb}|  19 +-
 6 files changed, 14 insertions(+), 1081 deletions(-)
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-libffi-Support-musl-x32-build.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-mips-Use-compiler-internal-define-for-linux.patch
 delete mode 100644 
meta/recipes-support/libffi/libffi/0001-mips-fix-MIPS-softfloat-build-issue.patch
 rename meta/recipes-support/libffi/{libffi_3.2.1.bb => libffi_3.3~rc0.bb} (71%)

diff --git a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch 
b/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
deleted file mode 100644
index 589c4d3c44..00
--- a/meta/recipes-support/libffi/libffi/0001-New-RISC-V-port-281.patch
+++ /dev/null
@@ -1,827 +0,0 @@
-From 8ac73103bf12ce4f776940cb17f3ced15a362f23 Mon Sep 17 00:00:00 2001
-From: Stef O'Rear 
-Date: Sun, 11 Mar 2018 05:55:15 -0700
-Subject: [PATCH] New RISC-V port (#281)
-
-* Add RISC-V support
-
-This patch adds support for the RISC-V architecture (https://riscv.org).
-
-This patch has been tested using QEMU user-mode emulation and GCC 7.2.0
-in the following configurations:
-
-* -march=rv32imac -mabi=ilp32
-* -march=rv32g -mabi=ilp32d
-* -march=rv64imac -mabi=lp64
-* -march=rv64g -mabi=lp64d
-
-The ABI currently can be found at
-https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md .
-
-* Add RISC-V to README
-
-* RISC-V: fix configure.host
-
-Upstream-Status: Backport 
[https://github.com/libffi/libffi/commit/3840d49aaa831d649b1597518a2903dfed0d57f3]
-Signed-off-by: Alistair Francis 

- Makefile.am   |   4 +
- configure.ac  |   5 +
- src/riscv/ffi.c   | 445 ++
- src/riscv/ffitarget.h |  68 +++
- src/riscv/sysv.S  | 214 
- 5 files changed, 736 insertions(+)
- create mode 100644 src/riscv/ffi.c
- create mode 100644 src/riscv/ffitarget.h
- create mode 100644 src/riscv/sysv.S
-
-diff --git a/Makefile.am b/Makefile.am
-index 0e40451..3837650 100644
 a/Makefile.am
-+++ b/Makefile.am
-@@ -32,6 +32,7 @@ EXTRA_DIST = LICENSE ChangeLog.v1 ChangeLog.libgcj   
\
-src/powerpc/asm.h src/powerpc/aix.S src/powerpc/darwin.S   \
-src/powerpc/aix_closure.S src/powerpc/darwin_closure.S \
-src/powerpc/ffi_darwin.c src/powerpc/ffitarget.h   \
-+   src/riscv/ffi.c src/riscv/ffitarget.h src/riscv/sysv.S \
-src/s390/ffi.c src/s390/sysv.S src/s390/ffitarget.h\
-src/sh/ffi.c src/sh/sysv.S src/sh/ffitarget.h src/sh64/ffi.c   \
-src/sh64/sysv.S src/sh64/ffitarget.h src/sparc/v8.S\
-@@ -122,6 +123,9 @@ endif
- if MIPS
- nodist_libffi_la_SOURCES += src/mips/ffi.c src/mips/o32.S src/mips/n32.S
- endif
-+if RISCV
-+nodist_libffi_la_SOURCES += src/riscv/ffi.c src/riscv/sysv.S
-+endif
- if BFIN
- nodist_libffi_la_SOURCES += src/bfin/ffi.c src/bfin/sysv.S
- endif
-diff --git a/configure.ac b/configure.ac
-index ce30853..33375aa 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -226,6 +226,10 @@ case "$host" in
-   TARGET=MIPS; TARGETDIR=mips
-   ;;
- 
-+  riscv*-*-*)
-+  TARGET=RISCV; TARGETDIR=riscv
-+  ;;
-+
-   nios2*-linux*)
-   TARGET=NIOS2; TARGETDIR=nios2
-   ;;
-@@ -298,6 +302,7 @@ if test $TARGETDIR = unknown; then
- fi
- 
- AM_CONDITIONAL(MIPS, test x$TARGET = xMIPS)
-+AM_CONDITIONAL(RISCV, test x$TARGET = xRISCV)
- AM_CONDITIONAL(BFIN, test x$TARGET = xBFIN)
- AM_CONDITIONAL(SPARC, test x$TARGET = xSPARC)
- AM_CONDITIONAL(X86, test x$TARGET = xX86)
-diff --git a/src/riscv/ffi.c b/src/riscv/ffi.c
-new file mode 100644
-index 000..b744fdd
 /dev/null
-+++ b/src/riscv/ffi.c
-@@ -0,0 +1,445 @@
-+/* ---
-+   ffi.c - Copyright (c) 2015 Michael Knyszek 
-+ 2015 Andrew 

Re: [OE-core] [PATCH] libffi: Upgrade to 3.3-rc0

[Khem Raj]

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 used by
> Fedora, Debian, etc), so please let's use ~ instead of messing around
> with fake PV numbers.
>
> ~ is basically - but it sorts before alphanumerics, so 3.2 < 3.3~beta < 3.3.
>

if you insist will send a v3

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

[OE-core] [PATCH V2] systemd: add menson option to decrease RLIMIT_NOFILE on qemu bsp

[Hongxu Jia]

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 to 4k to keep sync with sysvinit

After applying the patch, the memory cost is the same with sysvinit
rpcuser340  0.0  1.0   3212  2588 ?Ss   13:20   0:00 
/usr/sbin/rpc.statd -F
root   473  0.0  0.2   3464   496 ?Ss   13:23   0:00 
/usr/sbin/rpc.mountd

For other bsp, still keep RLIMIT_NOFILE to 512k by default

Signed-off-by: Hongxu Jia 
---
 ...001-meson-add-option-to-set-RLIMIT_NOFILE.patch | 50 ++
 meta/recipes-core/systemd/systemd_242.bb   |  5 +++
 2 files changed, 55 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
 
b/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
new file mode 100644
index 000..e822238
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-meson-add-option-to-set-RLIMIT_NOFILE.patch
@@ -0,0 +1,50 @@
+From d42d1512402de0d2249e2d68040c5c3887e7ea99 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia 
+Date: Mon, 19 Aug 2019 12:06:59 -0400
+Subject: [PATCH] meson: add option to set RLIMIT_NOFILE
+
+Add option to set RLIMIT_NOFILE and keep 512*1024 by default
+
+It is helpful for embedded device which has memory limitation
+to decrease RLIMIT_NOFILE
+
+Upstream-Status: Submitted [https://github.com/systemd/systemd/pull/13359]
+
+Signed-off-by: Hongxu Jia 
+---
+ meson.build   | 2 +-
+ meson_options.txt | 5 +
+ 2 files changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index 18a7cc5..26d9cf0 100644
+--- a/meson.build
 b/meson.build
+@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and 
sysvrcnd_path != '',
+ 
+ conf.set10('BUMP_PROC_SYS_FS_FILE_MAX', 
get_option('bump-proc-sys-fs-file-max'))
+ conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',  
get_option('bump-proc-sys-fs-nr-open'))
+-conf.set('HIGH_RLIMIT_NOFILE',  512*1024)
++conf.set('HIGH_RLIMIT_NOFILE',  get_option('high-rlimit-nofile'))
+ 
+ # join_paths ignores the preceding arguments if an absolute component is
+ # encountered, so this should canonicalize various paths when they are
+diff --git a/meson_options.txt b/meson_options.txt
+index d4ec37d..5d4ee18 100644
+--- a/meson_options.txt
 b/meson_options.txt
+@@ -56,6 +56,11 @@ option('bump-proc-sys-fs-file-max', type : 'boolean',
+description : 'bump /proc/sys/fs/file-max to ULONG_MAX')
+ option('bump-proc-sys-fs-nr-open', type : 'boolean',
+description : 'bump /proc/sys/fs/nr_open to INT_MAX')
++
++# Default is 512*1024
++option('high-rlimit-nofile', type : 'integer', value : 524288,
++   description : 'set RLIMIT_NOFILE')
++
+ option('valgrind', type : 'boolean', value : false,
+description : 'do extra operations to avoid valgrind warnings')
+ option('log-trace', type : 'boolean', value : false,
+-- 
+2.8.1
+
diff --git a/meta/recipes-core/systemd/systemd_242.bb 
b/meta/recipes-core/systemd/systemd_242.bb
index 1953fef..96a53dc 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -28,6 +28,7 @@ SRC_URI += "file://touchscreen.rules \

file://0001-core-set-fs.file-max-sysctl-to-LONG_MAX-rather-than-.patch \
file://0001-networkd-fix-link-up.patch \
file://0002-network-do-not-send-ipv6.patch \
+   file://0001-meson-add-option-to-set-RLIMIT_NOFILE.patch \
"
 
 # patches needed by musl
@@ -211,6 +212,10 @@ EXTRA_OEMESON += "-Dkexec-path=${sbindir}/kexec \
   -Dsulogin-path=${base_sbindir}/sulogin \
   -Dumount-path=${base_bindir}/umount"
 
+EXTRA_OEMESON += "-Dhigh-rlimit-nofile=${RLIMIT_NOFILE}"
+RLIMIT_NOFILE ??= "524288"
+RLIMIT_NOFILE_qemuall ?= "4096"
+
 do_install() {
meson_do_install
install -d ${D}/${base_sbindir}
-- 
2.8.1

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

Re: [OE-core] Conflict of systemd and sysvinit

[Ross Burton]

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.


The autobuilder should be exercising this, so when it's fixed we need to 
ensure the AB covers the case Otavio is hitting.


Ross

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

Re: [OE-core] [PATCH] libffi: Upgrade to 3.3-rc0

[Ross Burton]

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 messing around 
with fake PV numbers.


~ is basically - but it sorts before alphanumerics, so 3.2 < 3.3~beta < 3.3.

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

Re: [OE-core] [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Alexander Kanavin]

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 do realize runqueue work is making you less
available).

I have basically one objection: trying to understand what went wrong in a
OOM situation, where the symptoms and error messages are unhelpful and
tools to diagnose the issue are missing from the target image, is just as
frustrating. Having a tighter limit makes this more likely to occur when
users experiment with images and add or change things in them (e.g. via
local.conf). You, me or Hongxu would dig deeper and get to the bottom of
it, but someone just starting out with the project could simply give up and
move to alternatives.

Other than that, I am fine with raising the memory in a more targeted way
(e.g. core-image-sato, subject to 'opengl' in DISTRO_FEATURES and elsewhere
where X would otherwise fail to start), and will rework the patches
accordingly.

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

Re: [OE-core] [PATCH] libffi: Upgrade to 3.3-rc0

[Khem Raj]

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 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.
> >>
> >> Will the RC part cause the PE to be invoked when 3.3 comes out?  I did
> >> this on wireshark and shot myself in the foot.
> >>
> >
> > I am expecting the releases to be 3.3.0  but looking into the history
> > of releases it
> > could be 3.3 so yes you are right, Probably I will renable the recipe
> > to libffi_3.2+3.3-rc0.bb
> > and that should fix this
>
> 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

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

Re: [OE-core] [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[richard . purdie]

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 to deprecated configurations isn't
> the right thing to do, I think.

What kind of devices/uses are we meant to be targeting?

I believe OE is suited to optimised used cases where constraints on
size and performance are quite likely and supported.

This is *exactly* the kind of thing we should be exploring and
supporting. systemd is not designed for some of the systems we target.
Changing some of its configuration shouldn't be a surprise.

Having NFS taking up half the available memory doesn't make sense,
particularly when the sysvinit limits have worked for us for years. I
therefore appreciate Hongxu figuring out what the difference was and I
believe we should change this to something more suited for our target
audience, unless someone can explain why this is a bad idea.

Similarly, forcing everyone to full GL stacks under qemu simply is not
acceptable. For example I might have a single container type image
which I want to load/test under qemu. Forcing such usage to require
512MB memory for what could be a headless system also isn't right and
will just frustrate users. Users need to be able to access headless or
2D configurations of it.

I'm sorry I haven't been as active with general patch review recently
as I'd like. I did say that trying to change runqueue would distract me
from the usual day to day running of the project. We need to sort this
problem out but not the way you keep trying to.

Where images have specific memory needs, we should increase the
headroom for those images. Images with SDK tools, or stap make sense to
have more memory.

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.

Cheers,

Richard


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

Re: [OE-core] [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Alexander Kanavin]

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 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.
>
> The modification of set default RLIMIT_NOFILE(4k) just keeps sync with the
> one in sysvinit,
>
> if the fronts you mentioned are working fine on sysvinit, I think it
> should be OK on systemd
>
> but whether it has side effect or not still depends on the result of image
> test
>
>
> The fix is trying to fix the blocking issue while switching init manager
> from sysvinit to systemd for poky
>
>
> Hi RP,
>
> Should we make HIGH_RLIMIT_NOFILE configurable from local.conf?
>
> Then we could modify it according to the requirement, such as set it to 4k
> at image test
>
> //Hongxu
>
>
> Alex
>
> On Mon, 19 Aug 2019 at 15:34, 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 allocates memory according to RLIMIT_NOFILE,
>> so decrease it to 4k to keep sync with sysvinit
>>
>> After applying the patch, the memory cost is the same with sysvinit
>> rpcuser340  0.0  1.0   3212  2588 ?Ss   13:20   0:00
>> /usr/sbin/rpc.statd -F
>> root   473  0.0  0.2   3464   496 ?Ss   13:23   0:00
>> /usr/sbin/rpc.mountd
>>
>> Signed-off-by: Hongxu Jia 
>> ---
>>  ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35
>> ++
>>  meta/recipes-core/systemd/systemd_242.bb   |  4 +++
>>  2 files changed, 39 insertions(+)
>>  create mode 100644
>> meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>>
>> diff --git
>> a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>> new file mode 100644
>> index 000..fb8e2c9
>> --- /dev/null
>> +++
>> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>> @@ -0,0 +1,35 @@
>> +From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00 2001
>> +From: Hongxu Jia 
>> +Date: Mon, 19 Aug 2019 07:16:47 -0400
>> +Subject: [PATCH] decreasing the default RLIMIT_NOFILE
>> +
>> +Since do_testimage for core-image-sato-sdk has memory limits (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 which keep sync with sysvinit
>> +
>> +Upstream-Status: Inappropriate [oe specific]
>> +
>> +Signed-off-by: Hongxu Jia 
>> +---
>> + meson.build | 2 +-
>> + 1 file changed, 1 insertion(+), 1 deletion(-)
>> +
>> +diff --git a/meson.build b/meson.build
>> +index 18a7cc5..e30894b 100644
>> +--- a/meson.build
>>  b/meson.build
>> +@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and
>> sysvrcnd_path != '',
>> +
>> + conf.set10('BUMP_PROC_SYS_FS_FILE_MAX',
>> get_option('bump-proc-sys-fs-file-max'))
>> + conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',
>> get_option('bump-proc-sys-fs-nr-open'))
>> +-conf.set('HIGH_RLIMIT_NOFILE',  512*1024)
>> ++conf.set('HIGH_RLIMIT_NOFILE',  4*1024)
>> +
>> + # join_paths ignores the preceding arguments if an absolute component is
>> + # encountered, so this should canonicalize various paths when they are
>> +--
>> +2.8.1
>> +
>> diff --git a/meta/recipes-core/systemd/systemd_242.bb
>> b/meta/recipes-core/systemd/systemd_242.bb
>> index 1953fef..ab15ad2 100644
>> --- a/meta/recipes-core/systemd/systemd_242.bb
>> +++ b/meta/recipes-core/systemd/systemd_242.bb
>> @@ -58,6 +58,10 @@ SRC_URI_MUSL = "
>> file://0001-Use-getenv-when-secure-versions-are-not-available.pa
>> file://0001-do-not-disable-buffer-in-writing-files.patch
>> \
>> "
>>
>> +SRC_URI_append_qemuall = " \
>> +   file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
>> +"
>> +
>>  PAM_PLUGINS = " \
>>  pam-plugin-unix \
>>  pam-plugin-loginuid \
>> --
>> 2.8.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

Re: [OE-core] [PATCH] libffi: Upgrade to 3.3-rc0

[Ross Burton]

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 use the latest 3.3 rc0 which has lot of these
issues handled and is in good shape.


Will the RC part cause the PE to be invoked when 3.3 comes out?  I did
this on wireshark and shot myself in the foot.



I am expecting the releases to be 3.3.0  but looking into the history
of releases it
could be 3.3 so yes you are right, Probably I will renable the recipe
to libffi_3.2+3.3-rc0.bb
and that should fix this


Set the PV to 3.3~rc0 and 3.3 will sort after it.

Ross

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

Re: [OE-core] [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Hongxu Jia]

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 configurations 
isn't the right thing to do, I think.


The modification of set default RLIMIT_NOFILE(4k) just keeps sync with 
the one in sysvinit,


if the fronts you mentioned are working fine on sysvinit, I think it 
should be OK on systemd


but whether it has side effect or not still depends on the result of 
image test



The fix is trying to fix the blocking issue while switching init manager 
from sysvinit to systemd for poky



Hi RP,

Should we make HIGH_RLIMIT_NOFILE configurable from local.conf?

Then we could modify it according to the requirement, such as set it to 
4k at image test


//Hongxu



Alex

On Mon, 19 Aug 2019 at 15:34, 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 allocates memory according to RLIMIT_NOFILE,
so decrease it to 4k to keep sync with sysvinit

After applying the patch, the memory cost is the same with sysvinit
rpcuser    340  0.0  1.0   3212  2588 ?        Ss   13:20  0:00
/usr/sbin/rpc.statd -F
root       473  0.0  0.2   3464   496 ?        Ss   13:23  0:00
/usr/sbin/rpc.mountd

Signed-off-by: Hongxu Jia mailto:hongxu@windriver.com>>
---
 ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35
++
 meta/recipes-core/systemd/systemd_242.bb 
         |  4 +++
 2 files changed, 39 insertions(+)
 create mode 100644

meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch

diff --git

a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch

b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
new file mode 100644
index 000..fb8e2c9
--- /dev/null
+++

b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
@@ -0,0 +1,35 @@
+From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00
2001
+From: Hongxu Jia mailto:hongxu@windriver.com>>
+Date: Mon, 19 Aug 2019 07:16:47 -0400
+Subject: [PATCH] decreasing the default RLIMIT_NOFILE
+
+Since do_testimage for core-image-sato-sdk has memory limits (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 which keep sync with sysvinit
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia mailto:hongxu@windriver.com>>
+---
+ meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index 18a7cc5..e30894b 100644
+--- a/meson.build
 b/meson.build
+@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path !=
'' and sysvrcnd_path != '',
+
+ conf.set10('BUMP_PROC_SYS_FS_FILE_MAX',
get_option('bump-proc-sys-fs-file-max'))
+ conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',
get_option('bump-proc-sys-fs-nr-open'))
+-conf.set('HIGH_RLIMIT_NOFILE',          512*1024)
++conf.set('HIGH_RLIMIT_NOFILE',          4*1024)
+
+ # join_paths ignores the preceding arguments if an absolute
component is
+ # encountered, so this should canonicalize various paths when
they are
+--
+2.8.1
+
diff --git a/meta/recipes-core/systemd/systemd_242.bb
 b/meta/recipes-core/systemd/systemd_242.bb

index 1953fef..ab15ad2 100644
--- a/meta/recipes-core/systemd/systemd_242.bb 
+++ b/meta/recipes-core/systemd/systemd_242.bb 
@@ -58,6 +58,10 @@ SRC_URI_MUSL =
"file://0001-Use-getenv-when-secure-versions-are-not-available.pa

file://0001-do-not-disable-buffer-in-writing-files.patch \
                "

+SRC_URI_append_qemuall = " \
+  file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
+"
+
 PAM_PLUGINS = " \
     pam-plugin-unix \
     pam-plugin-loginuid \
-- 
2.8.1


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 

Re: [OE-core] ✗ patchtest: failure for "[warrior] binutils: fix CVE-20..." and 2 more

[Mittal, Anuj]

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 patches should apply cleanly on top of
current stable/warrior-nmut.

Thanks,

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

[OE-core] ✗ patchtest: failure for "[warrior] binutils: fix CVE-20..." and 2 more

[Patchwork]

== 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 executed on the proposed
series by patchtest resulting in the following failures:



* 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)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

Re: [OE-core] [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Alexander Kanavin]

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.

Alex

On Mon, 19 Aug 2019 at 15:34, 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 allocates memory according to RLIMIT_NOFILE,
> so decrease it to 4k to keep sync with sysvinit
>
> After applying the patch, the memory cost is the same with sysvinit
> rpcuser340  0.0  1.0   3212  2588 ?Ss   13:20   0:00
> /usr/sbin/rpc.statd -F
> root   473  0.0  0.2   3464   496 ?Ss   13:23   0:00
> /usr/sbin/rpc.mountd
>
> Signed-off-by: Hongxu Jia 
> ---
>  ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35
> ++
>  meta/recipes-core/systemd/systemd_242.bb   |  4 +++
>  2 files changed, 39 insertions(+)
>  create mode 100644
> meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>
> diff --git
> a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> new file mode 100644
> index 000..fb8e2c9
> --- /dev/null
> +++
> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> @@ -0,0 +1,35 @@
> +From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00 2001
> +From: Hongxu Jia 
> +Date: Mon, 19 Aug 2019 07:16:47 -0400
> +Subject: [PATCH] decreasing the default RLIMIT_NOFILE
> +
> +Since do_testimage for core-image-sato-sdk has memory limits (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 which keep sync with sysvinit
> +
> +Upstream-Status: Inappropriate [oe specific]
> +
> +Signed-off-by: Hongxu Jia 
> +---
> + meson.build | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 18a7cc5..e30894b 100644
> +--- a/meson.build
>  b/meson.build
> +@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and
> sysvrcnd_path != '',
> +
> + conf.set10('BUMP_PROC_SYS_FS_FILE_MAX',
> get_option('bump-proc-sys-fs-file-max'))
> + conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',
> get_option('bump-proc-sys-fs-nr-open'))
> +-conf.set('HIGH_RLIMIT_NOFILE',  512*1024)
> ++conf.set('HIGH_RLIMIT_NOFILE',  4*1024)
> +
> + # join_paths ignores the preceding arguments if an absolute component is
> + # encountered, so this should canonicalize various paths when they are
> +--
> +2.8.1
> +
> diff --git a/meta/recipes-core/systemd/systemd_242.bb
> b/meta/recipes-core/systemd/systemd_242.bb
> index 1953fef..ab15ad2 100644
> --- a/meta/recipes-core/systemd/systemd_242.bb
> +++ b/meta/recipes-core/systemd/systemd_242.bb
> @@ -58,6 +58,10 @@ SRC_URI_MUSL =
> "file://0001-Use-getenv-when-secure-versions-are-not-available.pa
> file://0001-do-not-disable-buffer-in-writing-files.patch \
> "
>
> +SRC_URI_append_qemuall = " \
> +   file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
> +"
> +
>  PAM_PLUGINS = " \
>  pam-plugin-unix \
>  pam-plugin-loginuid \
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 2/2] ltp: Fix ustat02 failure

[zhe.he]

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.bb  |  1 +
 2 files changed, 37 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-ustat02-Fix-EFAULT-in-32bit-compatibility-mode.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-ustat02-Fix-EFAULT-in-32bit-compatibility-mode.patch
 
b/meta/recipes-extended/ltp/ltp/0001-ustat02-Fix-EFAULT-in-32bit-compatibility-mode.patch
new file mode 100644
index 000..c936b78
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0001-ustat02-Fix-EFAULT-in-32bit-compatibility-mode.patch
@@ -0,0 +1,36 @@
+From 156776a3e29491b363fdc9811912e1298655d060 Mon Sep 17 00:00:00 2001
+From: Steven Price 
+Date: Fri, 19 Jul 2019 13:48:17 +0100
+Subject: [PATCH] ustat02: Fix EFAULT in 32bit compatibility mode
+
+The size of dev_t is larger than 32 bits which causes the dev argument
+to be passed incorrectly. On Arm this means that the EFAULT test case
+actually returns EINVAL because the device number isn't recognised.
+
+Signed-off-by: Steven Price 
+Acked-by: Li Wang 
+
+Upstream-Status: Backport
+[https://github.com/linux-test-project/ltp/commit/156776a3e29491b363fdc9811912e1298655d060]
+
+Signed-off-by: He Zhe 
+---
+ testcases/kernel/syscalls/ustat/ustat02.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/testcases/kernel/syscalls/ustat/ustat02.c 
b/testcases/kernel/syscalls/ustat/ustat02.c
+index 9bbe4f3..1a0e9e0 100644
+--- a/testcases/kernel/syscalls/ustat/ustat02.c
 b/testcases/kernel/syscalls/ustat/ustat02.c
+@@ -36,7 +36,7 @@ int TST_TOTAL = ARRAY_SIZE(tc);
+ 
+ void run(unsigned int test)
+ {
+-  TEST(tst_syscall(__NR_ustat, *tc[test].dev, tc[test].buf));
++  TEST(tst_syscall(__NR_ustat, (unsigned int)*tc[test].dev, 
tc[test].buf));
+ 
+   if ((TST_RET == -1) && (TST_ERR == tc[test].exp_errno))
+   tst_res(TPASS | TTERRNO, "ustat(2) expected failure");
+-- 
+2.7.4
+
diff --git a/meta/recipes-extended/ltp/ltp_20190517.bb 
b/meta/recipes-extended/ltp/ltp_20190517.bb
index f6c7de6..b0e2f96 100644
--- a/meta/recipes-extended/ltp/ltp_20190517.bb
+++ b/meta/recipes-extended/ltp/ltp_20190517.bb
@@ -44,6 +44,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \

file://0001-Add-configure-time-check-for-getdents-getdents64-API.patch \
file://0002-check-for-RES_USE_INET6-during-configure.patch \

file://0001-syscalls-tgkill03-wait-for-defunct-tid-to-get-detach.patch \
+   file://0001-ustat02-Fix-EFAULT-in-32bit-compatibility-mode.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.7.4

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

[OE-core] [oe-core][PATCH 1/2] ltp: Fix tgkill03 failure

[zhe.he]

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 +
 2 files changed, 76 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-syscalls-tgkill03-wait-for-defunct-tid-to-get-detach.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-syscalls-tgkill03-wait-for-defunct-tid-to-get-detach.patch
 
b/meta/recipes-extended/ltp/ltp/0001-syscalls-tgkill03-wait-for-defunct-tid-to-get-detach.patch
new file mode 100644
index 000..6ea2615
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0001-syscalls-tgkill03-wait-for-defunct-tid-to-get-detach.patch
@@ -0,0 +1,75 @@
+From e747d0456adc080a1d31fb653bda9dc491795c80 Mon Sep 17 00:00:00 2001
+From: Jan Stancek 
+Date: Sun, 16 Jun 2019 11:14:16 +0200
+Subject: [PATCH] syscalls/tgkill03: wait for defunct tid to get detached
+
+Case where defunct tid is used has been observed to sporadically fail:
+  tgkill03.c:96: FAIL: Defunct tid should have failed with ESRCH: SUCCESS
+
+glibc __pthread_timedjoin_ex() waits for CLONE_CHILD_CLEARTID to clear tid,
+and then resumes. Kernel clears it (glibc pd->tid) at:
+  do_exit
+exit_mm
+  mm_release
+put_user(0, tsk->clear_child_tid);
+
+but kernel tid is still valid, presumably until:
+  release_task
+__exit_signal
+  __unhash_process
+detach_pid
+
+To avoid race wait until /proc//task/ disappears.
+
+Signed-off-by: Jan Stancek 
+Reviewed-by: Li Wang 
+Acked-by: Sumit Garg 
+
+Upstream-Status: Backport
+[https://github.com/linux-test-project/ltp/commit/e747d0456adc080a1d31fb653bda9dc491795c80]
+
+Signed-off-by: He Zhe 
+---
+ testcases/kernel/syscalls/tgkill/tgkill03.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/testcases/kernel/syscalls/tgkill/tgkill03.c 
b/testcases/kernel/syscalls/tgkill/tgkill03.c
+index f5bbdc5..593a217 100644
+--- a/testcases/kernel/syscalls/tgkill/tgkill03.c
 b/testcases/kernel/syscalls/tgkill/tgkill03.c
+@@ -7,6 +7,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #include "tst_safe_pthread.h"
+@@ -42,6 +43,7 @@ static void setup(void)
+ {
+   sigset_t sigusr1;
+   pthread_t defunct_thread;
++  char defunct_tid_path[PATH_MAX];
+ 
+   sigemptyset();
+   sigaddset(, SIGUSR1);
+@@ -55,8 +57,9 @@ static void setup(void)
+   TST_CHECKPOINT_WAIT(0);
+ 
+   SAFE_PTHREAD_CREATE(_thread, NULL, defunct_thread_func, NULL);
+-
+   SAFE_PTHREAD_JOIN(defunct_thread, NULL);
++  sprintf(defunct_tid_path, "/proc/%d/task/%d", getpid(), defunct_tid);
++  TST_RETRY_FN_EXP_BACKOFF(access(defunct_tid_path, R_OK), -1, 15);
+ }
+ 
+ static void cleanup(void)
+@@ -108,4 +111,5 @@ static struct tst_test test = {
+   .setup = setup,
+   .cleanup = cleanup,
+   .test = run,
++  .timeout = 20,
+ };
+-- 
+2.7.4
+
diff --git a/meta/recipes-extended/ltp/ltp_20190517.bb 
b/meta/recipes-extended/ltp/ltp_20190517.bb
index c62f261..f6c7de6 100644
--- a/meta/recipes-extended/ltp/ltp_20190517.bb
+++ b/meta/recipes-extended/ltp/ltp_20190517.bb
@@ -43,6 +43,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \

file://0012-getrlimit03-adjust-a-bit-of-code-to-compatiable-with.patch \

file://0001-Add-configure-time-check-for-getdents-getdents64-API.patch \
file://0002-check-for-RES_USE_INET6-during-configure.patch \
+   
file://0001-syscalls-tgkill03-wait-for-defunct-tid-to-get-detach.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.7.4

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

[OE-core] [warrior][PATCH 2/3] pango: fix CVE-2019-1010238

[Anuj Mittal]

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

diff --git a/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch 
b/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch
new file mode 100644
index 000..5b0c342
--- /dev/null
+++ b/meta/recipes-graphics/pango/pango/CVE-2019-1010238.patch
@@ -0,0 +1,38 @@
+From 490f8979a260c16b1df055eab386345da18a2d54 Mon Sep 17 00:00:00 2001
+From: Matthias Clasen 
+Date: Wed, 10 Jul 2019 20:26:23 -0400
+Subject: [PATCH] bidi: Be safer against bad input
+
+Don't run off the end of an array that we
+allocated to certain length.
+
+Closes: https://gitlab.gnome.org/GNOME/pango/issues/342
+
+Upstream-Status: Backport 
[https://gitlab.gnome.org/GNOME/pango/commit/490f8979a260c16b1df055eab386345da18a2d54]
+CVE: CVE-2019-1010238
+Signed-off-by: Anuj Mittal 
+---
+ pango/pango-bidi-type.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/pango/pango-bidi-type.c b/pango/pango-bidi-type.c
+index 3e46b66c..5c02dbbb 100644
+--- a/pango/pango-bidi-type.c
 b/pango/pango-bidi-type.c
+@@ -181,8 +181,11 @@ pango_log2vis_get_embedding_levels (const gchar*text,
+   for (i = 0, p = text; p < text + length; p = g_utf8_next_char(p), i++)
+ {
+   gunichar ch = g_utf8_get_char (p);
+-  FriBidiCharType char_type;
+-  char_type = fribidi_get_bidi_type (ch);
++  FriBidiCharType char_type = fribidi_get_bidi_type (ch);
++
++  if (i == n_chars)
++break;
++
+   bidi_types[i] = char_type;
+   ored_types |= char_type;
+   if (FRIBIDI_IS_STRONG (char_type))
+-- 
+2.21.0
+
diff --git a/meta/recipes-graphics/pango/pango_1.42.4.bb 
b/meta/recipes-graphics/pango/pango_1.42.4.bb
index f3be9f4..1e1a5b8 100644
--- a/meta/recipes-graphics/pango/pango_1.42.4.bb
+++ b/meta/recipes-graphics/pango/pango_1.42.4.bb
@@ -16,7 +16,9 @@ GNOMEBASEBUILDCLASS = "meson"
 inherit gnomebase gtk-doc ptest-gnome upstream-version-is-even 
gobject-introspection
 
 SRC_URI += "file://run-ptest \
-file://insensitive-diff.patch"
+file://insensitive-diff.patch \
+file://CVE-2019-1010238.patch \
+"
 
 SRC_URI[archive.md5sum] = "deb171a31a3ad76342d5195a1b5bbc7c"
 SRC_URI[archive.sha256sum] = 
"1d2b74cd63e8bd41961f2f8d952355aa0f9be6002b52c8aa7699d9f5da597c9d"
-- 
2.7.4

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

[OE-core] [warrior][PATCH 3/3] glib-2.0: fix CVE-2019-13012

[Anuj Mittal]

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/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch 
b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch
new file mode 100644
index 000..c882cba
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-13012.patch
@@ -0,0 +1,40 @@
+From 9fd6b4b21891adc318784f6a141f40d767b0d73c Mon Sep 17 00:00:00 2001
+From: Matthias Clasen 
+Date: Tue, 22 Jan 2019 13:26:31 -0500
+Subject: [PATCH] keyfile settings: Use tighter permissions
+
+When creating directories, create them with 700 permissions,
+instead of 777.
+
+Closes: #1658
+CVE: CVE-2019-13012
+Upstream-Status: Backport 
[https://gitlab.gnome.org/GNOME/glib/commit/5e4da714f00f6bfb2ccd6d73d61329c6f3a08429]
+Signed-off-by: Anuj Mittal 
+
+---
+ gio/gkeyfilesettingsbackend.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/gio/gkeyfilesettingsbackend.c b/gio/gkeyfilesettingsbackend.c
+index a37978e..580a0b0 100644
+--- a/gio/gkeyfilesettingsbackend.c
 b/gio/gkeyfilesettingsbackend.c
+@@ -89,7 +89,8 @@ g_keyfile_settings_backend_keyfile_write 
(GKeyfileSettingsBackend *kfsb)
+ 
+   contents = g_key_file_to_data (kfsb->keyfile, , NULL);
+   g_file_replace_contents (kfsb->file, contents, length, NULL, FALSE,
+-   G_FILE_CREATE_REPLACE_DESTINATION,
++   G_FILE_CREATE_REPLACE_DESTINATION |
++   G_FILE_CREATE_PRIVATE,
+NULL, NULL, NULL);
+ 
+   compute_checksum (kfsb->digest, contents, length);
+@@ -640,7 +641,7 @@ g_keyfile_settings_backend_new (const gchar *filename,
+ 
+   kfsb->file = g_file_new_for_path (filename);
+   kfsb->dir = g_file_get_parent (kfsb->file);
+-  g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
++  g_mkdir_with_parents (g_file_peek_path (kfsb->dir), 0700);
+ 
+   kfsb->file_monitor = g_file_monitor (kfsb->file, 0, NULL, NULL);
+   kfsb->dir_monitor = g_file_monitor (kfsb->dir, 0, NULL, NULL);
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.58.3.bb 
b/meta/recipes-core/glib-2.0/glib-2.0_2.58.3.bb
index 733a2d4..2286d03 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.58.3.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.58.3.bb
@@ -18,6 +18,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz 
\

file://0001-meson.build-do-not-hardcode-linux-as-the-host-system.patch \

file://0001-meson-do-a-build-time-check-for-strlcpy-before-attem.patch \
file://glib-meson.cross \
+   file://CVE-2019-13012.patch \
"
 
 SRC_URI_append_class-native = " file://relocate-modules.patch"
-- 
2.7.4

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

[OE-core] [warrior][PATCH 1/3] binutils: fix CVE-2019-14250 CVE-2019-14444

[Anuj Mittal]

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 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-14250.patch
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-1.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc 
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 31c24a3..d3c5293 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -50,6 +50,8 @@ SRC_URI = "\
  file://CVE-2019-9077.patch \
  file://CVE-2019-9071.patch \
  file://CVE-2019-12972.patch \
+ file://CVE-2019-14250.patch \
+ file://CVE-2019-1.patch \
 "
 S  = "${WORKDIR}/git"
 
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2019-14250.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2019-14250.patch
new file mode 100644
index 000..c915a83
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2019-14250.patch
@@ -0,0 +1,33 @@
+From df78be05daf4eb07f60f50ec1080cb979af32ec0 Mon Sep 17 00:00:00 2001
+From: marxin 
+Date: Tue, 23 Jul 2019 07:33:32 +
+Subject: [PATCH] libiberty: Check zero value shstrndx in simple-object-elf.c
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@273718 
138bc75d-0d04-0410-961f-82ee72b054a4
+
+CVE: CVE-2019-14250
+Upstream-Status: Backport [from gcc: 
https://gcc.gnu.org/viewcvs/gcc?view=revision=273718]
+[Removed Changelog entry]
+Signed-off-by: Anuj Mittal 
+---
+diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
+index 502388991a08..bdee963634d6 100644
+--- a/libiberty/simple-object-elf.c
 b/libiberty/simple-object-elf.c
+@@ -548,7 +548,15 @@ simple_object_elf_match (unsigned char 
header[SIMPLE_OBJECT_MATCH_HEADER_LEN],
+   XDELETE (eor);
+   return NULL;
+ }
+-
++  
++  if (eor->shstrndx == 0)
++{
++  *errmsg = "invalid ELF shstrndx == 0";
++  *err = 0;
++  XDELETE (eor);
++  return NULL;
++}
++  
+   return (void *) eor;
+ }
+ 
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2019-1.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2019-1.patch
new file mode 100644
index 000..85b9a9f
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2019-1.patch
@@ -0,0 +1,28 @@
+From e17869db99195849826eaaf5d2d0eb2cfdd7a2a7 Mon Sep 17 00:00:00 2001
+From: Nick Clifton 
+Date: Mon, 5 Aug 2019 10:40:35 +0100
+Subject: [PATCH] Catch potential integer overflow in readelf when processing
+ corrupt binaries.
+
+   PR 24829
+   * readelf.c (apply_relocations): Catch potential integer overflow
+   whilst checking reloc location against section size.
+
+CVE: CVE-2019-1
+Upstream-Status: Backport 
[https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e17869db99195849826eaaf5d2d0eb2cfdd7a2a7]
+[Removed Changelog entry]
+Signed-off-by: Anuj Mittal 
+---
+diff --git a/binutils/readelf.c b/binutils/readelf.c
+index b896ad9f406..e785fde43e7 100644
+--- a/binutils/readelf.c
 b/binutils/readelf.c
+@@ -13366,7 +13366,7 @@ apply_relocations (Filedata * filedata,
+   }
+ 
+ rloc = start + rp->r_offset;
+-if ((rloc + reloc_size) > end || (rloc < start))
++if (rloc >= end || (rloc + reloc_size) > end || (rloc < start))
+   {
+ warn (_("skipping invalid relocation offset 0x%lx in section 
%s\n"),
+   (unsigned long) rp->r_offset,
-- 
2.7.4

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

[OE-core] [PATCH] binutils: fix CVE-2019-14250 CVE-2019-14444

[Anuj Mittal]

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 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-14250.patch
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-1.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc 
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 31c24a3..d3c5293 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -50,6 +50,8 @@ SRC_URI = "\
  file://CVE-2019-9077.patch \
  file://CVE-2019-9071.patch \
  file://CVE-2019-12972.patch \
+ file://CVE-2019-14250.patch \
+ file://CVE-2019-1.patch \
 "
 S  = "${WORKDIR}/git"
 
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2019-14250.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2019-14250.patch
new file mode 100644
index 000..c915a83
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2019-14250.patch
@@ -0,0 +1,33 @@
+From df78be05daf4eb07f60f50ec1080cb979af32ec0 Mon Sep 17 00:00:00 2001
+From: marxin 
+Date: Tue, 23 Jul 2019 07:33:32 +
+Subject: [PATCH] libiberty: Check zero value shstrndx in simple-object-elf.c
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@273718 
138bc75d-0d04-0410-961f-82ee72b054a4
+
+CVE: CVE-2019-14250
+Upstream-Status: Backport [from gcc: 
https://gcc.gnu.org/viewcvs/gcc?view=revision=273718]
+[Removed Changelog entry]
+Signed-off-by: Anuj Mittal 
+---
+diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
+index 502388991a08..bdee963634d6 100644
+--- a/libiberty/simple-object-elf.c
 b/libiberty/simple-object-elf.c
+@@ -548,7 +548,15 @@ simple_object_elf_match (unsigned char 
header[SIMPLE_OBJECT_MATCH_HEADER_LEN],
+   XDELETE (eor);
+   return NULL;
+ }
+-
++  
++  if (eor->shstrndx == 0)
++{
++  *errmsg = "invalid ELF shstrndx == 0";
++  *err = 0;
++  XDELETE (eor);
++  return NULL;
++}
++  
+   return (void *) eor;
+ }
+ 
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2019-1.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2019-1.patch
new file mode 100644
index 000..85b9a9f
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2019-1.patch
@@ -0,0 +1,28 @@
+From e17869db99195849826eaaf5d2d0eb2cfdd7a2a7 Mon Sep 17 00:00:00 2001
+From: Nick Clifton 
+Date: Mon, 5 Aug 2019 10:40:35 +0100
+Subject: [PATCH] Catch potential integer overflow in readelf when processing
+ corrupt binaries.
+
+   PR 24829
+   * readelf.c (apply_relocations): Catch potential integer overflow
+   whilst checking reloc location against section size.
+
+CVE: CVE-2019-1
+Upstream-Status: Backport 
[https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e17869db99195849826eaaf5d2d0eb2cfdd7a2a7]
+[Removed Changelog entry]
+Signed-off-by: Anuj Mittal 
+---
+diff --git a/binutils/readelf.c b/binutils/readelf.c
+index b896ad9f406..e785fde43e7 100644
+--- a/binutils/readelf.c
 b/binutils/readelf.c
+@@ -13366,7 +13366,7 @@ apply_relocations (Filedata * filedata,
+   }
+ 
+ rloc = start + rp->r_offset;
+-if ((rloc + reloc_size) > end || (rloc < start))
++if (rloc >= end || (rloc + reloc_size) > end || (rloc < start))
+   {
+ warn (_("skipping invalid relocation offset 0x%lx in section 
%s\n"),
+   (unsigned long) rp->r_offset,
-- 
2.7.4

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

[OE-core] [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

[Hongxu Jia]

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 keep sync with sysvinit

After applying the patch, the memory cost is the same with sysvinit
rpcuser340  0.0  1.0   3212  2588 ?Ss   13:20   0:00 
/usr/sbin/rpc.statd -F
root   473  0.0  0.2   3464   496 ?Ss   13:23   0:00 
/usr/sbin/rpc.mountd

Signed-off-by: Hongxu Jia 
---
 ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35 ++
 meta/recipes-core/systemd/systemd_242.bb   |  4 +++
 2 files changed, 39 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch

diff --git 
a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
 
b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
new file mode 100644
index 000..fb8e2c9
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
@@ -0,0 +1,35 @@
+From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia 
+Date: Mon, 19 Aug 2019 07:16:47 -0400
+Subject: [PATCH] decreasing the default RLIMIT_NOFILE
+
+Since do_testimage for core-image-sato-sdk has memory limits (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 which keep sync with sysvinit
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia 
+---
+ meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index 18a7cc5..e30894b 100644
+--- a/meson.build
 b/meson.build
+@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and 
sysvrcnd_path != '',
+ 
+ conf.set10('BUMP_PROC_SYS_FS_FILE_MAX', 
get_option('bump-proc-sys-fs-file-max'))
+ conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',  
get_option('bump-proc-sys-fs-nr-open'))
+-conf.set('HIGH_RLIMIT_NOFILE',  512*1024)
++conf.set('HIGH_RLIMIT_NOFILE',  4*1024)
+ 
+ # join_paths ignores the preceding arguments if an absolute component is
+ # encountered, so this should canonicalize various paths when they are
+-- 
+2.8.1
+
diff --git a/meta/recipes-core/systemd/systemd_242.bb 
b/meta/recipes-core/systemd/systemd_242.bb
index 1953fef..ab15ad2 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -58,6 +58,10 @@ SRC_URI_MUSL = 
"file://0001-Use-getenv-when-secure-versions-are-not-available.pa
file://0001-do-not-disable-buffer-in-writing-files.patch \
"
 
+SRC_URI_append_qemuall = " \
+   file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
+"
+
 PAM_PLUGINS = " \
 pam-plugin-unix \
 pam-plugin-loginuid \
-- 
2.8.1

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

Re: [OE-core] Yocto Project Summit at ELCE Call for Particpation

[Nicolas Dechesne]

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 sponsored by the
> Yocto Project that provides a chance for people to talk about the Yocto
> Project and OpenEmbedded. The CFP is a bit buried on the page and I like
> to get it more exposure, so here the direct link:

all information about the Summit is also available here now:

https://wiki.yoctoproject.org/wiki/Yocto_Project_Summit_2019

>
> https://events.linuxfoundation.org/wp-content/uploads/2019/08/Yocto-Project-Summit-2019-CFP-1.pdf
>
> We'd like to see new faces talking. We know there are a lot of good
> stories out there, that will help lots of people become better users and
> developers.
>
> The link to the event is here:
>
> https://events.linuxfoundation.org/events/embedded-linux-conference-europe-2019/program/co-located-events/
>
> Follow the path to the Yocto Project Summit. If you are alrady signed up
> for ELCE, you should be able to update your registration to include the
> Summit.
>
> Philip
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] mesa: Upgrade 19.1.1 -> 19.1.4

[Alexander Kanavin]

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 'python3' to DEPENDS of mesa, and see if that helps
please?

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

Re: [OE-core] Conflict of systemd and sysvinit

[Otavio Salvador]

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 O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Summit at ELCE Call for Particpation

[Philip Balister]

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 OpenEmbedded. The CFP is a bit buried on the page and I like
to get it more exposure, so here the direct link:

https://events.linuxfoundation.org/wp-content/uploads/2019/08/Yocto-Project-Summit-2019-CFP-1.pdf

We'd like to see new faces talking. We know there are a lot of good
stories out there, that will help lots of people become better users and
developers.

The link to the event is here:

https://events.linuxfoundation.org/events/embedded-linux-conference-europe-2019/program/co-located-events/

Follow the path to the Yocto Project Summit. If you are alrady signed up
for ELCE, you should be able to update your registration to include the
Summit.

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

[OE-core] ✗ patchtest: failure for psplash: Avoid mount the psplash tmpfs twice

[Patchwork]

== 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 executed on the proposed
series by patchtest resulting in the following failures:



* Patchpsplash: Avoid mount the psplash tmpfs twice
 Issue Yocto Project bugzilla tag is not correctly formatted 
[test_bugzilla_entry_format] 
  Suggested fixSpecify bugzilla ID in commit description with format: 
"[YOCTO #]"



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] psplash: Avoid mount the psplash tmpfs twice

[Kevin Hao]

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 do the twice mount.
So also fix it.

[Yocto 13461]

[1] 
https://lore.kernel.org/util-linux/20190819083022.12289-1-kexin@windriver.com/T/#u

Signed-off-by: Kevin Hao 
---
 meta/recipes-core/psplash/files/psplash-init | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/psplash/files/psplash-init 
b/meta/recipes-core/psplash/files/psplash-init
index fee23e681cfb..dcb751907f41 100755
--- a/meta/recipes-core/psplash/files/psplash-init
+++ b/meta/recipes-core/psplash/files/psplash-init
@@ -25,7 +25,9 @@ done
 
 export TMPDIR=/mnt/.psplash
 [ -d $TMPDIR ] || mkdir -p $TMPDIR
-mount tmpfs -t tmpfs $TMPDIR -o,size=40k
+if [ ! mountpoint -q $TMPDIR ]; then
+   mount tmpfs -t tmpfs $TMPDIR -o,size=40k
+fi
 
 rotation=0
 if [ -e /etc/rotation ]; then
-- 
2.14.4

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

Re: [OE-core] [PATCH] core-image-sato-sdk: test image with 512M memory

[ChenQi]

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-image-sato-sdk, it fails to pass test
case:


RESULTS - systemd.SystemdBasicTests.test_systemd_failed: FAILED
(0.43s)

It is OOM issue and daemon rpc.statd is killed:


  [  531.306146] Out of memory: Kill process 193 (rpc.statd) score
200 or sacrifice child

Increase the memory of qemu to 512M to avoid such OOM issue.

Signed-off-by: Kai Kang 
---
  meta/recipes-sato/images/core-image-sato-sdk.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-sato/images/core-image-sato-sdk.bb
b/meta/recipes-sato/images/core-image-sato-sdk.bb
index d7cc52b52b..f7963d018e 100644
--- a/meta/recipes-sato/images/core-image-sato-sdk.bb
+++ b/meta/recipes-sato/images/core-image-sato-sdk.bb
@@ -9,3 +9,4 @@ IMAGE_FEATURES += "dev-pkgs tools-sdk \
IMAGE_INSTALL += "kernel-devsrc"
  +TEST_QEMUPARAMS = "-m 512"

Any idea what is using so much memory in the image when this happens?

Its rather sad that we can't have NFS+systemd with 256MB memory...


It caused by stap test case. I minimized the test cases to

TEST_SUITES = "ping date ssh systemd stap kernelmodule gcc "

which could reproduce the error.

And it PASSes testimage that remove stap test from default TEST_SUITES:

TEST_SUITES_remove = 'stap'

But I can't reproduce the OOM failure to run stap tests manually.


Hi Richard,

The root cause of test case stap fails is available memory is too 
low. Compare systemd with sysvinit, memory status are listed:


systemd:
root@qemux86:~# free -h
  totalusedfree  shared buff/cache   
available

Mem:  239Mi   120Mi23Mi   8.0Mi 94Mi 100Mi
Swap:0B  0B  0B

sysvinit:
root@qemux86:~# free -h
  totalusedfree  shared buff/cache   
available

Mem:  239Mi45Mi   111Mi   0.0Ki 82Mi 184Mi
Swap:0B  0B  0B


With systemd, processes of rpc.statd and rpc.mountd take about less 
than 80M memories.

And I compared with Debian 10, they take similar size of memories.

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
464 rpcuser   20   0   56316  51336   2192 S   0.0  20.9 0:00.09 
rpc.statd
  186 root  20   0   30136  27024   2280 S   0.0  11.0 0:00.02 
rpc.mountd



Compare to sysvinit, they take only about 2M and 448K:

 PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
  567 rpcuser   20   03444   2372   1792 S   0.0   1.0 0:00.00 
rpc.statd
  677 root  20   03700448  0 S   0.0   0.2 0:00.00 
rpc.mountd



I didn't figure out the differences between these 2 ways to start the 
commands:


ExecStart=/usr/sbin/rpc.statd -F $STATD_OPTS

Vs.

test -x "$NFS_STATD" || NFS_STATD=/usr/sbin/rpc.statd
start-stop-daemon --start --exec "$NFS_STATD" --pidfile "$STATD_PID"


Hi Richard,

Any more comment here please?

Regards,
Kai




Hi Richard,

Do you think it's acceptable to use swap as part of this test case? For 
example, enable 100M swap before running `stap' and disable it 
afterwards? This ensure no oom caused by other software using too much 
memory.


Best Regards,
Chen Qi






Regards,
Kai







Regards,
Kai



Cheers,

Richard










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

[OE-core] [PATCH] acpid:upgrade 2.0.31 -> 2.0.32

[Zang Ruochen]

Signed-off-by: Zang Ruochen 
---
 meta/recipes-bsp/acpid/{acpid_2.0.31.bb => acpid_2.0.32.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-bsp/acpid/{acpid_2.0.31.bb => acpid_2.0.32.bb} (55%)

diff --git a/meta/recipes-bsp/acpid/acpid_2.0.31.bb 
b/meta/recipes-bsp/acpid/acpid_2.0.32.bb
similarity index 55%
rename from meta/recipes-bsp/acpid/acpid_2.0.31.bb
rename to meta/recipes-bsp/acpid/acpid_2.0.32.bb
index 4074921..227e4a4 100644
--- a/meta/recipes-bsp/acpid/acpid_2.0.31.bb
+++ b/meta/recipes-bsp/acpid/acpid_2.0.32.bb
@@ -3,5 +3,5 @@ require acpid.inc
 LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
 
file://acpid.h;endline=24;md5=324a9cf225ae69ddaad1bf9d942115b5"
 
-SRC_URI[md5sum] = "599dd38681b5917eeeafb58176793952"
-SRC_URI[sha256sum] = 
"fc9dc669ed85d9a1739aa76915e0667c6697c5431160f8dfb253046c6a072cc3"
+SRC_URI[md5sum] = "248995264b9d1cd8bdb923d5b190fd44"
+SRC_URI[sha256sum] = 
"f2d2d30b3edc3234bd82f6f7186699a6aa3c85c8d20bc4e30e9b3c68a1ed157e"
-- 
2.7.4



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