[OE-core] [dunfell][PATCH] libtirpc: CVE-2021-46828 DoS vulnerability with lots of connections

2022-07-27 Thread Hitendra Prajapati
Source: http://git.linux-nfs.org/?p=steved/libtirpc.git;
MR: 120231
Type: Security Fix
Disposition: Backport from 
http://git.linux-nfs.org/?p=steved/libtirpc.git;a=commit;h=86529758570cef4c73fb9b9c4104fdc510f701ed
ChangeID: 544120a5f10a4717cd2c7291821a012e26b14b7f
Description:
CVE-2021-46828 libtirpc: DoS vulnerability with lots of connections.

Signed-off-by: Hitendra Prajapati 
---
 .../libtirpc/libtirpc/CVE-2021-46828.patch| 155 ++
 .../libtirpc/libtirpc_1.2.6.bb|   4 +-
 2 files changed, 158 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/libtirpc/libtirpc/CVE-2021-46828.patch

diff --git a/meta/recipes-extended/libtirpc/libtirpc/CVE-2021-46828.patch 
b/meta/recipes-extended/libtirpc/libtirpc/CVE-2021-46828.patch
new file mode 100644
index 00..c78e7ef4d5
--- /dev/null
+++ b/meta/recipes-extended/libtirpc/libtirpc/CVE-2021-46828.patch
@@ -0,0 +1,155 @@
+From 48309e7cb230fc539c3edab0b3363f8ce973194f Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Thu, 28 Jul 2022 09:11:04 +0530
+Subject: [PATCH] CVE-2021-46828
+
+Upstream-Status: Backport 
[http://git.linux-nfs.org/?p=steved/libtirpc.git;a=commit;h=86529758570cef4c73fb9b9c4104fdc510f701ed}
+CVE: CVE-2021-46828
+Signed-off-by: Hitendra Prajapati 
+---
+ src/svc.c| 17 +-
+ src/svc_vc.c | 62 +++-
+ 2 files changed, 77 insertions(+), 2 deletions(-)
+
+diff --git a/src/svc.c b/src/svc.c
+index 6db164b..3a8709f 100644
+--- a/src/svc.c
 b/src/svc.c
+@@ -57,7 +57,7 @@
+ 
+ #define max(a, b) (a > b ? a : b)
+ 
+-static SVCXPRT **__svc_xports;
++SVCXPRT **__svc_xports;
+ int __svc_maxrec;
+ 
+ /*
+@@ -194,6 +194,21 @@ __xprt_do_unregister (xprt, dolock)
+ rwlock_unlock (_fd_lock);
+ }
+ 
++int
++svc_open_fds()
++{
++  int ix;
++  int nfds = 0;
++
++  rwlock_rdlock (_fd_lock);
++  for (ix = 0; ix < svc_max_pollfd; ++ix) {
++  if (svc_pollfd[ix].fd != -1)
++  nfds++;
++  }
++  rwlock_unlock (_fd_lock);
++  return (nfds);
++}
++
+ /*
+  * Add a service program to the callout list.
+  * The dispatch routine will be called when a rpc request for this
+diff --git a/src/svc_vc.c b/src/svc_vc.c
+index c23cd36..1729963 100644
+--- a/src/svc_vc.c
 b/src/svc_vc.c
+@@ -64,6 +64,8 @@
+ 
+ 
+ extern rwlock_t svc_fd_lock;
++extern SVCXPRT **__svc_xports;
++extern int svc_open_fds();
+ 
+ static SVCXPRT *makefd_xprt(int, u_int, u_int);
+ static bool_t rendezvous_request(SVCXPRT *, struct rpc_msg *);
+@@ -82,6 +84,7 @@ static void svc_vc_ops(SVCXPRT *);
+ static bool_t svc_vc_control(SVCXPRT *xprt, const u_int rq, void *in);
+ static bool_t svc_vc_rendezvous_control (SVCXPRT *xprt, const u_int rq,
+void *in);
++static int __svc_destroy_idle(int timeout);
+ 
+ struct cf_rendezvous { /* kept in xprt->xp_p1 for rendezvouser */
+   u_int sendsize;
+@@ -312,13 +315,14 @@ done:
+   return (xprt);
+ }
+ 
++
+ /*ARGSUSED*/
+ static bool_t
+ rendezvous_request(xprt, msg)
+   SVCXPRT *xprt;
+   struct rpc_msg *msg;
+ {
+-  int sock, flags;
++  int sock, flags, nfds, cnt;
+   struct cf_rendezvous *r;
+   struct cf_conn *cd;
+   struct sockaddr_storage addr;
+@@ -378,6 +382,16 @@ again:
+ 
+   gettimeofday(>last_recv_time, NULL);
+ 
++  nfds = svc_open_fds();
++  if (nfds >= (_rpc_dtablesize() / 5) * 4) {
++  /* destroy idle connections */
++  cnt = __svc_destroy_idle(15);
++  if (cnt == 0) {
++  /* destroy least active */
++  __svc_destroy_idle(0);
++  }
++  }
++
+   return (FALSE); /* there is never an rpc msg to be processed */
+ }
+ 
+@@ -819,3 +833,49 @@ __svc_clean_idle(fd_set *fds, int timeout, bool_t 
cleanblock)
+ {
+   return FALSE;
+ }
++
++static int
++__svc_destroy_idle(int timeout)
++{
++  int i, ncleaned = 0;
++  SVCXPRT *xprt, *least_active;
++  struct timeval tv, tdiff, tmax;
++  struct cf_conn *cd;
++
++  gettimeofday(, NULL);
++  tmax.tv_sec = tmax.tv_usec = 0;
++  least_active = NULL;
++  rwlock_wrlock(_fd_lock);
++
++  for (i = 0; i <= svc_max_pollfd; i++) {
++  if (svc_pollfd[i].fd == -1)
++  continue;
++  xprt = __svc_xports[i];
++  if (xprt == NULL || xprt->xp_ops == NULL ||
++  xprt->xp_ops->xp_recv != svc_vc_recv)
++  continue;
++  cd = (struct cf_conn *)xprt->xp_p1;
++  if (!cd->nonblock)
++  continue;
++  if (timeout == 0) {
++  timersub(, >last_recv_time, );
++  if (timercmp(, , >)) {
++  tmax = tdiff;
++  least_active = xprt;
++  }
++  

[OE-core] [PATCH] gstreamer1.0-plugins-bad: add PACKAGECONFIG for onevpl

2022-07-27 Thread Naveen Saini
Allow user to build this plugin against MFX version 2.2+ (oneVPL)

https://github.com/GStreamer/gst-plugins-bad/commit/beda9a73339bef878e95798f629a868c647627ce

Signed-off-by: Naveen Saini 
---
 .../gstreamer/gstreamer1.0-plugins-bad_1.20.3.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.3.bb
index 2dd42395f7..6048e17214 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.20.3.bb
@@ -97,6 +97,7 @@ PACKAGECONFIG[webrtcdsp]   = 
"-Dwebrtcdsp=enabled,-Dwebrtcdsp=disabled,webrt
 PACKAGECONFIG[zbar]= "-Dzbar=enabled,-Dzbar=disabled,zbar"
 PACKAGECONFIG[x11] = "-Dx11=enabled,-Dx11=disabled,libxcb 
libxkbcommon"
 PACKAGECONFIG[x265]= "-Dx265=enabled,-Dx265=disabled,x265"
+PACKAGECONFIG[onevpl]  = "-Dmsdk=enabled 
-Dmfx_api=oneVPL,-Dmsdk=disabled,onevpl onevpl-intel-gpu"
 
 GSTREAMER_GPL = "${@bb.utils.filter('PACKAGECONFIG', 'faad resindvd x265', d)}"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168593): 
https://lists.openembedded.org/g/openembedded-core/message/168593
Mute This Topic: https://lists.openembedded.org/mt/92664604/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v2] classes: rootfs-postcommands: autologin root on serial-getty

2022-07-27 Thread Johannes Schneider via lists.openembedded.org
good question, haven't had a sysvinit system in ages... so no easy "let's test 
it on this platform" :-s
do you happen to have one?


should the patch include a warning to sysvinit users like "not supported" 
"config switch only applies to systemd" ... suggestions? (-:

the only sysvinit+getty reference i see in the code is 
./meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
which relies on a symlinked getty - possibly provided by busybox or others?

regards

From: Ross Burton 
Sent: Wednesday, July 27, 2022 17:30
To: SCHNEIDER Johannes 
Cc: openembedded-core@lists.openembedded.org 

Subject: Re: [OE-core] [meta-oe][PATCH v2] classes: rootfs-postcommands: 
autologin root on serial-getty

[You don't often get email from ross.bur...@arm.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

This email is not from Hexagon’s Office 365 instance. Please be careful while 
clicking links, opening attachments, or replying to this email.


> +serial_autologin_root () {
> + if [ -e ${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service 
> ]; then
> + sed -i '/^\s*ExecStart\b/ s/getty /&--autologin root /' \
> + 
> "${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service"
> + fi
> +}

What about images using sysvinit?

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168592): 
https://lists.openembedded.org/g/openembedded-core/message/168592
Mute This Topic: https://lists.openembedded.org/mt/92623778/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCHv2]] recipes-support: rng-tools change systemd service name

2022-07-27 Thread Khem Raj



On 7/27/22 10:51 AM, An?bal Lim?n wrote:



On Wed, Jul 27, 2022 at 5:44 AM Luca Ceresoli > wrote:


Hello Aníbal,

On Tue, 26 Jul 2022 14:33:22 -0500
"An?bal Lim?n" mailto:limon.ani...@gmail.com>> wrote:

 > From: Aníbal Limón mailto:limon.ani...@gmail.com>>
 >
 > Change systemd service name from rngd -> rng-tools to avoid load
twice
 > the service when sysvinit compatibility is enabled,
 >
 > ...
 > root@:~# ps  | grep rng
 >    23 root         0 SW   [hwrng]
 > 13109 root      3528 R    /usr/sbin/rngd -f -r /dev/hwrng
 > 13117 root      2348 S    grep rng
 > 29418 root     12756 S    /usr/sbin/rngd -r /dev/hwrng
 > ...
 >
 > Signed-off-by: Aníbal Limón mailto:limon.ani...@gmail.com>>
 > ---
 >  .../rng-tools/{rngd.service => rng-tools.service}    |  0
 >  meta/recipes-support/rng-tools/rng-tools_6.15.bb
     | 12 ++--
 >  2 files changed, 6 insertions(+), 6 deletions(-)
 >  rename meta/recipes-support/rng-tools/rng-tools/{rngd.service =>
rng-tools.service} (100%)
 >
 > diff --git
a/meta/recipes-support/rng-tools/rng-tools/rngd.service
b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
 > similarity index 100%
 > rename from meta/recipes-support/rng-tools/rng-tools/rngd.service
 > rename to meta/recipes-support/rng-tools/rng-tools/rng-tools.service
 > diff --git a/meta/recipes-support/rng-tools/rng-tools_6.15.bb

b/meta/recipes-support/rng-tools/rng-tools_6.15.bb

 > index 0696351903..efc08b5e0a 100644
 > --- a/meta/recipes-support/rng-tools/rng-tools_6.15.bb

 > +++ b/meta/recipes-support/rng-tools/rng-tools_6.15.bb

 > @@ -11,7 +11,7 @@ DEPENDS = "sysfsutils openssl"
 >  SRC_URI =
"git://github.com/nhorman/rng-tools.git;branch=master;protocol=https
 \
 >             file://init \
 >             file://default \
 > -           file://rngd.service \
 > +           file://rng-tools.service \

This feels strange to me: "rng-tools" does not look like a daemon name,
but rather a, well, tools name. Maybe "rng-daemon" would clarify?


Another option is to change the init daemon to be called rngd.


I think yet another way is to check for condition when sysvinit 
compatibility is enabled during install time and decide if we need to 
install both sysvinit script and systemd service or not. I do not think

renaming .service file is a good solution here.



Regards,
Anibal


Still I'm taking this patch for testing, I'll replace it with v2 should
you send one.

However please note there is an extra ']' in the subject: [PATCHv2]]
should be [PATCHv2]. This leads 'git am' to produce a commit starting
with a "] " prefix. I fixed it while applying, however you should check
that in the future.

Best regards.
-- 
Luca Ceresoli, Bootlin

Embedded Linux and Kernel engineering
https://bootlin.com 






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168591): 
https://lists.openembedded.org/g/openembedded-core/message/168591
Mute This Topic: https://lists.openembedded.org/mt/92635255/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [kirkstone][master][PATCH] apt: fix do_package_qa failure

2022-07-27 Thread Changqing Li


On 7/27/22 19:51, Alexander Kanavin wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

What is actually being installed in there? Is it really right to remove it?


An empty dir apt is installed under /var/log/. It should be ok to remove 
it since apt could create it when it doesn't exist.


We have remove it for target. So I do the same for nativesdk. Another 
solution could be INSANE_SKIP the empty-dirs.


How do you think?

Changqing



Alex

On Wed, 27 Jul 2022 at 07:39, Changqing Li  wrote:

From: Changqing Li 

bitbake nativesdk-apt failed with error:
ERROR: nativesdk-apt-2.4.5-r0 do_package_qa: QA Issue: nativesdk-apt installs 
files in 
/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var/volatile,
 but it is expected to be empty [empty-dirs]

Signed-off-by: Changqing Li 
---
  meta/recipes-devtools/apt/apt_2.4.5.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/apt/apt_2.4.5.bb 
b/meta/recipes-devtools/apt/apt_2.4.5.bb
index 1d94dd118c..d79a33857a 100644
--- a/meta/recipes-devtools/apt/apt_2.4.5.bb
+++ b/meta/recipes-devtools/apt/apt_2.4.5.bb
@@ -123,6 +123,7 @@ do_install:append:class-native() {

  do_install:append:class-nativesdk() {
 customize_apt_conf_sample
+   rm -rf ${D}${localstatedir}/log
  }

  do_install:append:class-target() {
--
2.25.1





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168590): 
https://lists.openembedded.org/g/openembedded-core/message/168590
Mute This Topic: https://lists.openembedded.org/mt/92643987/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [kirkstone][PATCH] libtirpc: CVE-2021-46828 DoS vulnerability with lots of connections

2022-07-27 Thread Hitendra Prajapati
Source: http://git.linux-nfs.org/?p=steved/libtirpc.git;
MR: 120225
Type: Security Fix
Disposition: Backport from 
http://git.linux-nfs.org/?p=steved/libtirpc.git;a=commit;h=86529758570cef4c73fb9b9c4104fdc510f701ed
ChangeID: 29c32ee171a6a47e06c788e5c608fac9bb3a64b2
Description:
CVE-2021-46828 libtirpc: DoS vulnerability with lots of connections.

Signed-off-by: Hitendra Prajapati 
---
 .../libtirpc/libtirpc/CVE-2021-46828.patch| 155 ++
 .../libtirpc/libtirpc_1.3.2.bb|   4 +-
 2 files changed, 158 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/libtirpc/libtirpc/CVE-2021-46828.patch

diff --git a/meta/recipes-extended/libtirpc/libtirpc/CVE-2021-46828.patch 
b/meta/recipes-extended/libtirpc/libtirpc/CVE-2021-46828.patch
new file mode 100644
index 00..3d5e5b8db9
--- /dev/null
+++ b/meta/recipes-extended/libtirpc/libtirpc/CVE-2021-46828.patch
@@ -0,0 +1,155 @@
+From 3ee23a0a5a8c2261e788acbee67722fcbecbea28 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Wed, 27 Jul 2022 17:34:21 +0530
+Subject: [PATCH] CVE-2021-46828
+
+Upstream-Status: Backport 
[http://git.linux-nfs.org/?p=steved/libtirpc.git;a=commit;h=86529758570cef4c73fb9b9c4104fdc510f701ed}
+CVE: CVE-2021-46828
+Signed-off-by: Hitendra Prajapati 
+---
+ src/svc.c| 17 +-
+ src/svc_vc.c | 62 +++-
+ 2 files changed, 77 insertions(+), 2 deletions(-)
+
+diff --git a/src/svc.c b/src/svc.c
+index 6db164b..3a8709f 100644
+--- a/src/svc.c
 b/src/svc.c
+@@ -57,7 +57,7 @@
+ 
+ #define max(a, b) (a > b ? a : b)
+ 
+-static SVCXPRT **__svc_xports;
++SVCXPRT **__svc_xports;
+ int __svc_maxrec;
+ 
+ /*
+@@ -194,6 +194,21 @@ __xprt_do_unregister (xprt, dolock)
+ rwlock_unlock (_fd_lock);
+ }
+ 
++int
++svc_open_fds()
++{
++  int ix;
++  int nfds = 0;
++
++  rwlock_rdlock (_fd_lock);
++  for (ix = 0; ix < svc_max_pollfd; ++ix) {
++  if (svc_pollfd[ix].fd != -1)
++  nfds++;
++  }
++  rwlock_unlock (_fd_lock);
++  return (nfds);
++}
++
+ /*
+  * Add a service program to the callout list.
+  * The dispatch routine will be called when a rpc request for this
+diff --git a/src/svc_vc.c b/src/svc_vc.c
+index f1d9f00..3dc8a75 100644
+--- a/src/svc_vc.c
 b/src/svc_vc.c
+@@ -64,6 +64,8 @@
+ 
+ 
+ extern rwlock_t svc_fd_lock;
++extern SVCXPRT **__svc_xports;
++extern int svc_open_fds();
+ 
+ static SVCXPRT *makefd_xprt(int, u_int, u_int);
+ static bool_t rendezvous_request(SVCXPRT *, struct rpc_msg *);
+@@ -82,6 +84,7 @@ static void svc_vc_ops(SVCXPRT *);
+ static bool_t svc_vc_control(SVCXPRT *xprt, const u_int rq, void *in);
+ static bool_t svc_vc_rendezvous_control (SVCXPRT *xprt, const u_int rq,
+void *in);
++static int __svc_destroy_idle(int timeout);
+ 
+ struct cf_rendezvous { /* kept in xprt->xp_p1 for rendezvouser */
+   u_int sendsize;
+@@ -313,13 +316,14 @@ done:
+   return (xprt);
+ }
+ 
++
+ /*ARGSUSED*/
+ static bool_t
+ rendezvous_request(xprt, msg)
+   SVCXPRT *xprt;
+   struct rpc_msg *msg;
+ {
+-  int sock, flags;
++  int sock, flags, nfds, cnt;
+   struct cf_rendezvous *r;
+   struct cf_conn *cd;
+   struct sockaddr_storage addr;
+@@ -379,6 +383,16 @@ again:
+ 
+   gettimeofday(>last_recv_time, NULL);
+ 
++  nfds = svc_open_fds();
++  if (nfds >= (_rpc_dtablesize() / 5) * 4) {
++  /* destroy idle connections */
++  cnt = __svc_destroy_idle(15);
++  if (cnt == 0) {
++  /* destroy least active */
++  __svc_destroy_idle(0);
++  }
++  }
++
+   return (FALSE); /* there is never an rpc msg to be processed */
+ }
+ 
+@@ -820,3 +834,49 @@ __svc_clean_idle(fd_set *fds, int timeout, bool_t 
cleanblock)
+ {
+   return FALSE;
+ }
++
++static int
++__svc_destroy_idle(int timeout)
++{
++  int i, ncleaned = 0;
++  SVCXPRT *xprt, *least_active;
++  struct timeval tv, tdiff, tmax;
++  struct cf_conn *cd;
++
++  gettimeofday(, NULL);
++  tmax.tv_sec = tmax.tv_usec = 0;
++  least_active = NULL;
++  rwlock_wrlock(_fd_lock);
++
++  for (i = 0; i <= svc_max_pollfd; i++) {
++  if (svc_pollfd[i].fd == -1)
++  continue;
++  xprt = __svc_xports[i];
++  if (xprt == NULL || xprt->xp_ops == NULL ||
++  xprt->xp_ops->xp_recv != svc_vc_recv)
++  continue;
++  cd = (struct cf_conn *)xprt->xp_p1;
++  if (!cd->nonblock)
++  continue;
++  if (timeout == 0) {
++  timersub(, >last_recv_time, );
++  if (timercmp(, , >)) {
++  tmax = tdiff;
++  least_active = xprt;
++  }
++  

[OE-core][PATCH] grub2: fix several CVEs

2022-07-27 Thread Yongxin Liu
Backport CVE patches from upstream to fix:
  CVE-2021-3695
  CVE-2021-3696
  CVE-2021-3697
  CVE-2022-28733
  CVE-2022-28734
  CVE-2022-28735
  CVE-2022-28736

Backport the following 5 patches to make CVE patches be applied smoothly.
  video-Remove-trailing-whitespaces.patch
  video-readers-jpeg-Abort-sooner-if-a-read-operation-.patch
  video-readers-jpeg-Refuse-to-handle-multiple-start-o.patch
  loader-efi-chainloader-Simplify-the-loader-state.patch
  commands-boot-Add-API-to-pass-context-to-loader.patch

Signed-off-by: Yongxin Liu 
---
 ...g-Drop-greyscale-support-to-fix-heap.patch | 179 +
 ...ng-Avoid-heap-OOB-R-W-inserting-huff.patch |  50 ++
 ...peg-Block-int-underflow-wild-pointer.patch |  84 +++
 ...3-net-ip-Do-IP-fragment-maths-safely.patch |  63 ++
 ...or-out-on-headers-with-LF-without-CR.patch |  58 ++
 ...Fix-OOB-write-for-split-http-headers.patch |  56 ++
 ...ct-non-kernel-files-in-the-shim_lock.patch | 111 +++
 ...i-chainloader-Use-grub_loader_set_ex.patch |  86 +++
 ...ot-Add-API-to-pass-context-to-loader.patch | 168 +
 ...hainloader-Simplify-the-loader-state.patch | 129 
 .../video-Remove-trailing-whitespaces.patch   | 693 ++
 ...eg-Abort-sooner-if-a-read-operation-.patch | 264 +++
 ...eg-Refuse-to-handle-multiple-start-o.patch |  53 ++
 meta/recipes-bsp/grub/grub2.inc   |  13 +
 14 files changed, 2007 insertions(+)
 create mode 100644 
meta/recipes-bsp/grub/files/CVE-2021-3695-video-readers-png-Drop-greyscale-support-to-fix-heap.patch
 create mode 100644 
meta/recipes-bsp/grub/files/CVE-2021-3696-video-readers-png-Avoid-heap-OOB-R-W-inserting-huff.patch
 create mode 100644 
meta/recipes-bsp/grub/files/CVE-2021-3697-video-readers-jpeg-Block-int-underflow-wild-pointer.patch
 create mode 100644 
meta/recipes-bsp/grub/files/CVE-2022-28733-net-ip-Do-IP-fragment-maths-safely.patch
 create mode 100644 
meta/recipes-bsp/grub/files/CVE-2022-28734-net-http-Error-out-on-headers-with-LF-without-CR.patch
 create mode 100644 
meta/recipes-bsp/grub/files/CVE-2022-28734-net-http-Fix-OOB-write-for-split-http-headers.patch
 create mode 100644 
meta/recipes-bsp/grub/files/CVE-2022-28735-kern-efi-sb-Reject-non-kernel-files-in-the-shim_lock.patch
 create mode 100644 
meta/recipes-bsp/grub/files/CVE-2022-28736-loader-efi-chainloader-Use-grub_loader_set_ex.patch
 create mode 100644 
meta/recipes-bsp/grub/files/commands-boot-Add-API-to-pass-context-to-loader.patch
 create mode 100644 
meta/recipes-bsp/grub/files/loader-efi-chainloader-Simplify-the-loader-state.patch
 create mode 100644 
meta/recipes-bsp/grub/files/video-Remove-trailing-whitespaces.patch
 create mode 100644 
meta/recipes-bsp/grub/files/video-readers-jpeg-Abort-sooner-if-a-read-operation-.patch
 create mode 100644 
meta/recipes-bsp/grub/files/video-readers-jpeg-Refuse-to-handle-multiple-start-o.patch

diff --git 
a/meta/recipes-bsp/grub/files/CVE-2021-3695-video-readers-png-Drop-greyscale-support-to-fix-heap.patch
 
b/meta/recipes-bsp/grub/files/CVE-2021-3695-video-readers-png-Drop-greyscale-support-to-fix-heap.patch
new file mode 100644
index 00..7f7bb1acfe
--- /dev/null
+++ 
b/meta/recipes-bsp/grub/files/CVE-2021-3695-video-readers-png-Drop-greyscale-support-to-fix-heap.patch
@@ -0,0 +1,179 @@
+From e623866d9286410156e8b9d2c82d6253a1b22d08 Mon Sep 17 00:00:00 2001
+From: Daniel Axtens 
+Date: Tue, 6 Jul 2021 18:51:35 +1000
+Subject: [PATCH] video/readers/png: Drop greyscale support to fix heap
+ out-of-bounds write
+
+A 16-bit greyscale PNG without alpha is processed in the following loop:
+
+  for (i = 0; i < (data->image_width * data->image_height);
+  i++, d1 += 4, d2 += 2)
+   {
+ d1[R3] = d2[1];
+ d1[G3] = d2[1];
+ d1[B3] = d2[1];
+   }
+
+The increment of d1 is wrong. d1 is incremented by 4 bytes per iteration,
+but there are only 3 bytes allocated for storage. This means that image
+data will overwrite somewhat-attacker-controlled parts of memory - 3 bytes
+out of every 4 following the end of the image.
+
+This has existed since greyscale support was added in 2013 in commit
+3ccf16dff98f (grub-core/video/readers/png.c: Support grayscale).
+
+Saving starfield.png as a 16-bit greyscale image without alpha in the gimp
+and attempting to load it causes grub-emu to crash - I don't think this code
+has ever worked.
+
+Delete all PNG greyscale support.
+
+Fixes: CVE-2021-3695
+
+Signed-off-by: Daniel Axtens 
+Reviewed-by: Daniel Kiper 
+
+Upstream-Status: Backport
+CVE: CVE-2021-3695
+
+Reference to upstream patch:
+https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e623866d9286410156e8b9d2c82d6253a1b22d08
+
+Signed-off-by: Yongxin Liu 
+---
+ grub-core/video/readers/png.c | 87 +++
+ 1 file changed, 7 insertions(+), 80 deletions(-)
+
+diff --git a/grub-core/video/readers/png.c b/grub-core/video/readers/png.c
+index 35ae553c8..a3161e25b 100644
+--- a/grub-core/video/readers/png.c
 b/grub-core/video/readers/png.c

Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Ross Burton
> The patch sanity check should warn about it as it does for the status header. 
> I said, RP can add it.

Easier said than done when a patch already contains S-o-b and we want to allow 
people to S-o-b from their corporate accounts whilst posting patches from their 
personal account.

Ross
--
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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168587): 
https://lists.openembedded.org/g/openembedded-core/message/168587
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [oe-core][kirkstone][PATCH 1/1] lua: Backport fix for CVE-2022-33099

2022-07-27 Thread Steve Sakoman
This patch is in the set currently out for review:

https://lists.openembedded.org/g/openembedded-core/message/168524

So it should hit kirkstone in the next few days.

Steve




On Wed, Jul 27, 2022 at 7:48 AM Joe Slater  wrote:
>
> From: Khem Raj 
>
> Fixes stack overflow while handling recurring errors in Lua-stack
>
> Signed-off-by: Khem Raj 
> Signed-off-by: Richard Purdie 
> (cherry picked from commit caad9d5f7184f0fa60fa7770e5d3da3f533647cb)
> Signed-off-by: Joe Slater 
> ---
>  .../lua/lua/CVE-2022-33099.patch  | 61 +++
>  meta/recipes-devtools/lua/lua_5.4.4.bb|  1 +
>  2 files changed, 62 insertions(+)
>  create mode 100644 meta/recipes-devtools/lua/lua/CVE-2022-33099.patch
>
> diff --git a/meta/recipes-devtools/lua/lua/CVE-2022-33099.patch 
> b/meta/recipes-devtools/lua/lua/CVE-2022-33099.patch
> new file mode 100644
> index 00..fe7b6065c2
> --- /dev/null
> +++ b/meta/recipes-devtools/lua/lua/CVE-2022-33099.patch
> @@ -0,0 +1,61 @@
> +From 42d40581dd919fb134c07027ca1ce0844c670daf Mon Sep 17 00:00:00 2001
> +From: Roberto Ierusalimschy 
> +Date: Fri, 20 May 2022 13:14:33 -0300
> +Subject: [PATCH] Save stack space while handling errors
> +
> +Because error handling (luaG_errormsg) uses slots from EXTRA_STACK,
> +and some errors can recur (e.g., string overflow while creating an
> +error message in 'luaG_runerror', or a C-stack overflow before calling
> +the message handler), the code should use stack slots with parsimony.
> +
> +This commit fixes the bug "Lua-stack overflow when C stack overflows
> +while handling an error".
> +
> +CVE: CVE-2022-33099
> +
> +Upstream-Status: Backport 
> [https://github.com/lua/lua/commit/42d40581dd919fb134c07027ca1ce0844c670daf]
> +
> +Signed-off-by: Khem Raj 
> +---
> + ldebug.c | 5 -
> + lvm.c| 6 --
> + 2 files changed, 8 insertions(+), 3 deletions(-)
> +
> +--- a/src/ldebug.c
>  b/src/ldebug.c
> +@@ -824,8 +824,11 @@ l_noret luaG_runerror (lua_State *L, con
> +   va_start(argp, fmt);
> +   msg = luaO_pushvfstring(L, fmt, argp);  /* format message */
> +   va_end(argp);
> +-  if (isLua(ci))  /* if Lua function, add source:line information */
> ++  if (isLua(ci)) {  /* if Lua function, add source:line information */
> + luaG_addinfo(L, msg, ci_func(ci)->p->source, getcurrentline(ci));
> ++setobjs2s(L, L->top - 2, L->top - 1);  /* remove 'msg' from the stack */
> ++L->top--;
> ++  }
> +   luaG_errormsg(L);
> + }
> +
> +--- a/src/lvm.c
>  b/src/lvm.c
> +@@ -656,8 +656,10 @@ void luaV_concat (lua_State *L, int tota
> +   /* collect total length and number of strings */
> +   for (n = 1; n < total && tostring(L, s2v(top - n - 1)); n++) {
> + size_t l = vslen(s2v(top - n - 1));
> +-if (l_unlikely(l >= (MAX_SIZE/sizeof(char)) - tl))
> ++if (l_unlikely(l >= (MAX_SIZE/sizeof(char)) - tl)) {
> ++  L->top = top - total;  /* pop strings to avoid wasting stack */
> +   luaG_runerror(L, "string length overflow");
> ++}
> + tl += l;
> +   }
> +   if (tl <= LUAI_MAXSHORTLEN) {  /* is result a short string? */
> +@@ -672,7 +674,7 @@ void luaV_concat (lua_State *L, int tota
> +   setsvalue2s(L, top - n, ts);  /* create result */
> + }
> + total -= n-1;  /* got 'n' strings to create 1 new */
> +-L->top -= n-1;  /* popped 'n' strings and pushed one */
> ++L->top = top - (n - 1);  /* popped 'n' strings and pushed one */
> +   } while (total > 1);  /* repeat until only 1 result left */
> + }
> +
> diff --git a/meta/recipes-devtools/lua/lua_5.4.4.bb 
> b/meta/recipes-devtools/lua/lua_5.4.4.bb
> index 6f2cea5314..0b2e754b31 100644
> --- a/meta/recipes-devtools/lua/lua_5.4.4.bb
> +++ b/meta/recipes-devtools/lua/lua_5.4.4.bb
> @@ -7,6 +7,7 @@ HOMEPAGE = "http://www.lua.org/;
>  SRC_URI = "http://www.lua.org/ftp/lua-${PV}.tar.gz;name=tarballsrc \
> file://lua.pc.in \
> file://CVE-2022-28805.patch \
> +   file://CVE-2022-33099.patch \
> ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 
> 'http://www.lua.org/tests/lua-${PV_testsuites}-tests.tar.gz;name=tarballtest 
> file://run-ptest ', '', d)} \
> "
>
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168586): 
https://lists.openembedded.org/g/openembedded-core/message/168586
Mute This Topic: https://lists.openembedded.org/mt/92654482/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Alexander Kanavin
Adding s-o-b in behalf of others is not allowed, it's akin to a
signature - it literally says 'signed off by me'. The only s-o-b you
can add is your own.

Besides, RP should not be fixing up things for you, and when he does
it's a favour and not an entitlement.

Alex

On Wed, 27 Jul 2022 at 18:56, Otavio Salvador
 wrote:
>
> Sent :-)
>
> Em qua., 27 de jul. de 2022 às 13:45, Khem Raj  escreveu:
>>
>>
>>
>> On 7/27/22 12:41 PM, Otavio Salvador wrote:
>> >
>> >
>> > Em qua., 27 de jul. de 2022 às 13:35, Ross Burton > > > escreveu:
>> >
>> > Whoever adds the patch needs to add their S-o-b.
>> >
>> >
>> > The patch sanity check should warn about it as it does for the status
>> > header. I said, RP can add it.
>>
>> RP can do, but he can only do so much :) lets try to help him.
>> Its not something that can be added during applying patch which could be
>> done, this needs to change the libusb1 patch and then final patch
>> regenerated, its better if it can be done by you and resend a v2.
>>
>> > --
>> > Otavio Salvador O.S. Systems
>> > http://www.ossystems.com.br 
>> > http://code.ossystems.com.br 
>> > Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
>> >
>> >
>> >
>> >
>>
>>
>>
>
>
> --
> 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
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168585): 
https://lists.openembedded.org/g/openembedded-core/message/168585
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[oe-core][kirkstone][PATCH 1/1] lua: Backport fix for CVE-2022-33099

2022-07-27 Thread Joe Slater
From: Khem Raj 

Fixes stack overflow while handling recurring errors in Lua-stack

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
(cherry picked from commit caad9d5f7184f0fa60fa7770e5d3da3f533647cb)
Signed-off-by: Joe Slater 
---
 .../lua/lua/CVE-2022-33099.patch  | 61 +++
 meta/recipes-devtools/lua/lua_5.4.4.bb|  1 +
 2 files changed, 62 insertions(+)
 create mode 100644 meta/recipes-devtools/lua/lua/CVE-2022-33099.patch

diff --git a/meta/recipes-devtools/lua/lua/CVE-2022-33099.patch 
b/meta/recipes-devtools/lua/lua/CVE-2022-33099.patch
new file mode 100644
index 00..fe7b6065c2
--- /dev/null
+++ b/meta/recipes-devtools/lua/lua/CVE-2022-33099.patch
@@ -0,0 +1,61 @@
+From 42d40581dd919fb134c07027ca1ce0844c670daf Mon Sep 17 00:00:00 2001
+From: Roberto Ierusalimschy 
+Date: Fri, 20 May 2022 13:14:33 -0300
+Subject: [PATCH] Save stack space while handling errors
+
+Because error handling (luaG_errormsg) uses slots from EXTRA_STACK,
+and some errors can recur (e.g., string overflow while creating an
+error message in 'luaG_runerror', or a C-stack overflow before calling
+the message handler), the code should use stack slots with parsimony.
+
+This commit fixes the bug "Lua-stack overflow when C stack overflows
+while handling an error".
+
+CVE: CVE-2022-33099
+
+Upstream-Status: Backport 
[https://github.com/lua/lua/commit/42d40581dd919fb134c07027ca1ce0844c670daf]
+
+Signed-off-by: Khem Raj 
+---
+ ldebug.c | 5 -
+ lvm.c| 6 --
+ 2 files changed, 8 insertions(+), 3 deletions(-)
+
+--- a/src/ldebug.c
 b/src/ldebug.c
+@@ -824,8 +824,11 @@ l_noret luaG_runerror (lua_State *L, con
+   va_start(argp, fmt);
+   msg = luaO_pushvfstring(L, fmt, argp);  /* format message */
+   va_end(argp);
+-  if (isLua(ci))  /* if Lua function, add source:line information */
++  if (isLua(ci)) {  /* if Lua function, add source:line information */
+ luaG_addinfo(L, msg, ci_func(ci)->p->source, getcurrentline(ci));
++setobjs2s(L, L->top - 2, L->top - 1);  /* remove 'msg' from the stack */
++L->top--;
++  }
+   luaG_errormsg(L);
+ }
+ 
+--- a/src/lvm.c
 b/src/lvm.c
+@@ -656,8 +656,10 @@ void luaV_concat (lua_State *L, int tota
+   /* collect total length and number of strings */
+   for (n = 1; n < total && tostring(L, s2v(top - n - 1)); n++) {
+ size_t l = vslen(s2v(top - n - 1));
+-if (l_unlikely(l >= (MAX_SIZE/sizeof(char)) - tl))
++if (l_unlikely(l >= (MAX_SIZE/sizeof(char)) - tl)) {
++  L->top = top - total;  /* pop strings to avoid wasting stack */
+   luaG_runerror(L, "string length overflow");
++}
+ tl += l;
+   }
+   if (tl <= LUAI_MAXSHORTLEN) {  /* is result a short string? */
+@@ -672,7 +674,7 @@ void luaV_concat (lua_State *L, int tota
+   setsvalue2s(L, top - n, ts);  /* create result */
+ }
+ total -= n-1;  /* got 'n' strings to create 1 new */
+-L->top -= n-1;  /* popped 'n' strings and pushed one */
++L->top = top - (n - 1);  /* popped 'n' strings and pushed one */
+   } while (total > 1);  /* repeat until only 1 result left */
+ }
+ 
diff --git a/meta/recipes-devtools/lua/lua_5.4.4.bb 
b/meta/recipes-devtools/lua/lua_5.4.4.bb
index 6f2cea5314..0b2e754b31 100644
--- a/meta/recipes-devtools/lua/lua_5.4.4.bb
+++ b/meta/recipes-devtools/lua/lua_5.4.4.bb
@@ -7,6 +7,7 @@ HOMEPAGE = "http://www.lua.org/;
 SRC_URI = "http://www.lua.org/ftp/lua-${PV}.tar.gz;name=tarballsrc \
file://lua.pc.in \
file://CVE-2022-28805.patch \
+   file://CVE-2022-33099.patch \
${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 
'http://www.lua.org/tests/lua-${PV_testsuites}-tests.tar.gz;name=tarballtest 
file://run-ptest ', '', d)} \
"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168584): 
https://lists.openembedded.org/g/openembedded-core/message/168584
Mute This Topic: https://lists.openembedded.org/mt/92654482/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH 2/3] oeqa/sdk: Add basic rust cargo test

2022-07-27 Thread Otavio Salvador
Em qua., 27 de jul. de 2022 às 13:48, Luca Ceresoli via
lists.openembedded.org 
escreveu:

> On Tue, 26 Jul 2022 15:24:12 +0100
> "Richard Purdie"  wrote:
>
> > From: Otavio Salvador 
> >
> > Add a QA test to the SDK to test that a basic cargo build works.
> >
> > [RP: Tweaked to work for multilibs and updated to match toolchain
> changes]
> >
> > Signed-off-by: Otavio Salvador 
> > Signed-off-by: Richard Purdie 
>
> We have a build failure with this series applied:
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/5615/steps/26/logs/stdio
>
> Attached is the do_testsdk log.
>

It seems the SDK test directory is being reused, so it failed as file
already exists.

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168583): 
https://lists.openembedded.org/g/openembedded-core/message/168583
Mute This Topic: https://lists.openembedded.org/mt/92628459/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH] create-spdx: Fix supplier field

2022-07-27 Thread Mihai Lindner
The correct field name is "supplier" according to SPDX schema.
The "supplier" field translates to "PackageSupplier", but that's for
tag-value format.

Signed-off-by: Mihai Lindner 
---
 meta/classes/create-spdx.bbclass | 6 +++---
 meta/lib/oe/spdx.py  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index 15cccac84b..21cd5be3cb 100644
--- a/meta/classes/create-spdx.bbclass
+++ b/meta/classes/create-spdx.bbclass
@@ -451,7 +451,7 @@ python do_create_spdx() {
 recipe.name = d.getVar("PN")
 recipe.versionInfo = d.getVar("PV")
 recipe.SPDXID = oe.sbom.get_recipe_spdxid(d)
-recipe.packageSupplier = d.getVar("SPDX_SUPPLIER")
+recipe.supplier = d.getVar("SPDX_SUPPLIER")
 if bb.data.inherits_class("native", d) or bb.data.inherits_class("cross", 
d):
 recipe.annotations.append(create_annotation(d, "isNative"))
 
@@ -561,7 +561,7 @@ python do_create_spdx() {
 spdx_package.name = pkg_name
 spdx_package.versionInfo = d.getVar("PV")
 spdx_package.licenseDeclared = 
convert_license_to_spdx(package_license, package_doc, d, found_licenses)
-spdx_package.packageSupplier = d.getVar("SPDX_SUPPLIER")
+spdx_package.supplier = d.getVar("SPDX_SUPPLIER")
 
 package_doc.packages.append(spdx_package)
 
@@ -901,7 +901,7 @@ def combine_spdx(d, rootfs_name, rootfs_deploydir, 
rootfs_spdxid, packages):
 image.name = d.getVar("PN")
 image.versionInfo = d.getVar("PV")
 image.SPDXID = rootfs_spdxid
-image.packageSupplier = d.getVar("SPDX_SUPPLIER")
+image.supplier = d.getVar("SPDX_SUPPLIER")
 
 doc.packages.append(image)
 
diff --git a/meta/lib/oe/spdx.py b/meta/lib/oe/spdx.py
index 14ca706895..6d56ed90df 100644
--- a/meta/lib/oe/spdx.py
+++ b/meta/lib/oe/spdx.py
@@ -218,7 +218,7 @@ class SPDXPackage(SPDXObject):
 SPDXID = _String()
 versionInfo = _String()
 downloadLocation = _String(default="NOASSERTION")
-packageSupplier = _String(default="NOASSERTION")
+supplier = _String(default="NOASSERTION")
 homepage = _String()
 licenseConcluded = _String(default="NOASSERTION")
 licenseDeclared = _String(default="NOASSERTION")
-- 
2.35.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168582): 
https://lists.openembedded.org/g/openembedded-core/message/168582
Mute This Topic: https://lists.openembedded.org/mt/92653678/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH] wic/direct.py: ignore root mountpoint in fstab updater

2022-07-27 Thread Markus Volk
But looking at the commit that introduced the problem, I see that it 
completely undoes it.
In general, I like the idea of having the fstab_updater create the root 
entry, but for this to work without duplication, the /dev/root entry 
would have to be removed from fstab.
This would force any wic image to use the fstab_updater (which can also 
be disabled) and would otherwise result in an fstab file with no root 
entry.
Probably removing the /dev/root entry would also break the boot of 
images that do not use wic


Translated with www.DeepL.com/Translator (free version)

Am Mi, 27. Jul 2022 um 18:31:38 +0200 schrieb Markus Volk 
:

Yes. With the patch the warning disappears from dmesg

Am Mi, 27. Jul 2022 um 15:44:48 + schrieb Ross Burton 
:
This looks like a fix for 
, can you 
confirm that?


Ross

 On 27 Jul 2022, at 14:45, Markus Volk via lists.openembedded.org 
> wrote:


 We already have a root entry in fstab. This commit prevents 
processing root
 mountpoint in fstab_updater and thus avoids duplicate entries for 
root in fstab.


 Signed-off-by: Markus Volk >

 ---
 scripts/lib/wic/plugins/imager/direct.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py

 index c44159b235..75004ab320 100644
 --- a/scripts/lib/wic/plugins/imager/direct.py
 +++ b/scripts/lib/wic/plugins/imager/direct.py
 @@ -117,7 +117,8 @@ class DirectPlugin(ImagerPlugin):
 updated = False
 for part in self.parts:
 if not part.realnum or not part.mountpoint \
 -   or not part.mountpoint.startswith('/'):
 +   or not part.mountpoint.startswith('/') \
 +   or part.mountpoint == "/":
 continue

 if part.use_uuid:
 --
 2.34.1












-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168581): 
https://lists.openembedded.org/g/openembedded-core/message/168581
Mute This Topic: https://lists.openembedded.org/mt/92649199/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Otavio Salvador
Sent :-)

Em qua., 27 de jul. de 2022 às 13:45, Khem Raj 
escreveu:

>
>
> On 7/27/22 12:41 PM, Otavio Salvador wrote:
> >
> >
> > Em qua., 27 de jul. de 2022 às 13:35, Ross Burton  > > escreveu:
> >
> > Whoever adds the patch needs to add their S-o-b.
> >
> >
> > The patch sanity check should warn about it as it does for the status
> > header. I said, RP can add it.
>
> RP can do, but he can only do so much :) lets try to help him.
> Its not something that can be added during applying patch which could be
> done, this needs to change the libusb1 patch and then final patch
> regenerated, its better if it can be done by you and resend a v2.
>
> > --
> > Otavio Salvador O.S. Systems
> > http://www.ossystems.com.br 
> > http://code.ossystems.com.br 
> > Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
> >
> >
> >
> >
>
> 
>
>

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168580): 
https://lists.openembedded.org/g/openembedded-core/message/168580
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Otavio Salvador
Backport a fix from 1.0.27 so we only link atomic if no atomic builtins
are available.

Signed-off-by: Otavio Salvador 
---

Changes in v2:
- add signed-off-by

 ...k-with-latomic-only-if-no-atomic-bui.patch | 53 +++
 meta/recipes-support/libusb/libusb1_1.0.26.bb |  1 +
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch

diff --git 
a/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
 
b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
new file mode 100644
index 00..5c49cbb8a7
--- /dev/null
+++ 
b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
@@ -0,0 +1,53 @@
+From a6890a6a9a8f88b567631874e209aaadc79e28e5 Mon Sep 17 00:00:00 2001
+From: Lonnie Abelbeck 
+Date: Sun, 8 May 2022 14:05:56 -0500
+Subject: [PATCH] configure.ac: Link with -latomic only if no atomic builtins
+
+Follow-up to 561dbda, a check of GCC atomic builtins needs to be done
+first.
+
+I'm no autoconf guru, but using this:
+https://github.com/mesa3d/mesa/blob/0df485c285b73c34ba9062f0c27e55c3c702930d/configure.ac#L469
+as inspiration, I created a pre-check before calling AC_SEARCH_LIBS(...)
+
+Upstream-Status: Backport [1.0.27]
+
+Fixes #1135
+Closes #1139
+(cherry picked from commit 95e601ce116dd46ea7915c171976b85ea0905d58)
+
+Signed-off-by: Otavio Salvador 
+---
+ configure.ac | 16 +++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index d4f12510..96787500 100644
+--- a/configure.ac
 b/configure.ac
+@@ -153,7 +153,21 @@ if test "x$platform" = xposix; then
+   AC_SEARCH_LIBS([pthread_create], [pthread],
+   [test "x$ac_cv_search_pthread_create" != "xnone required" && 
AC_SUBST(THREAD_LIBS, [-lpthread])],
+   [], [])
+-  AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
++  dnl Check for new-style atomic builtins. We first check without linking 
to -latomic.
++  AC_MSG_CHECKING(whether __atomic_load_n is supported)
++  AC_LINK_IFELSE([AC_LANG_SOURCE([[
++  #include 
++  int main() {
++  struct {
++  uint64_t *v;
++  } x;
++  return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE) &
++ (int)__atomic_add_fetch(x.v, (uint64_t)1, 
__ATOMIC_ACQ_REL);
++  }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=yes, 
GCC_ATOMIC_BUILTINS_SUPPORTED=no)
++  AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_SUPPORTED)
++  if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" != xyes; then
++  AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
++  fi
+ elif test "x$platform" = xwindows; then
+   AC_DEFINE([PLATFORM_WINDOWS], [1], [Define to 1 if compiling for a 
Windows platform.])
+ else
+-- 
+2.37.0
+
diff --git a/meta/recipes-support/libusb/libusb1_1.0.26.bb 
b/meta/recipes-support/libusb/libusb1_1.0.26.bb
index fd63e7adc2..ff3f0be7a5 100644
--- a/meta/recipes-support/libusb/libusb1_1.0.26.bb
+++ b/meta/recipes-support/libusb/libusb1_1.0.26.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=fbc093901857fcd118f065f900982c24"
 BBCLASSEXTEND = "native nativesdk"
 
 SRC_URI = 
"https://github.com/libusb/libusb/releases/download/v${PV}/libusb-${PV}.tar.bz2 
\
+   
file://0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch \
file://run-ptest \
   "
 
-- 
2.37.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168579): 
https://lists.openembedded.org/g/openembedded-core/message/168579
Mute This Topic: https://lists.openembedded.org/mt/92653354/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Khem Raj



On 7/27/22 12:41 PM, Otavio Salvador wrote:



Em qua., 27 de jul. de 2022 às 13:35, Ross Burton > escreveu:


Whoever adds the patch needs to add their S-o-b.


The patch sanity check should warn about it as it does for the status 
header. I said, RP can add it.


RP can do, but he can only do so much :) lets try to help him.
Its not something that can be added during applying patch which could be 
done, this needs to change the libusb1 patch and then final patch 
regenerated, its better if it can be done by you and resend a v2.



--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br  
http://code.ossystems.com.br 

Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168577): 
https://lists.openembedded.org/g/openembedded-core/message/168577
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Otavio Salvador
Em qua., 27 de jul. de 2022 às 13:35, Ross Burton 
escreveu:

> Whoever adds the patch needs to add their S-o-b.
>

The patch sanity check should warn about it as it does for the status
header. I said, RP can add it.

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168576): 
https://lists.openembedded.org/g/openembedded-core/message/168576
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Ross Burton
Whoever adds the patch needs to add their S-o-b.

Ross

From: Otavio Salvador 
Date: Wednesday, 27 July 2022 at 17:20
To: Ross Burton , Purdie, Richard 

Cc: ota...@ossystems.com.br , 
openembedded-core@lists.openembedded.org 

Subject: Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic 
builtins


Em qua., 27 de jul. de 2022 às 12:28, Ross Burton 
mailto:ross.bur...@arm.com>> escreveu:
The patch is missing your S-o-b.

The patch isn't mine but a backport. Richard can add it when adding it to MUT, 
though.

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168575): 
https://lists.openembedded.org/g/openembedded-core/message/168575
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH] wic/direct.py: ignore root mountpoint in fstab updater

2022-07-27 Thread Markus Volk

Yes. With the patch the warning disappears from dmesg

Am Mi, 27. Jul 2022 um 15:44:48 + schrieb Ross Burton 
:
This looks like a fix for 
, can you 
confirm that?


Ross

 On 27 Jul 2022, at 14:45, Markus Volk via lists.openembedded.org 
> wrote:


 We already have a root entry in fstab. This commit prevents 
processing root
 mountpoint in fstab_updater and thus avoids duplicate entries for 
root in fstab.


 Signed-off-by: Markus Volk >

 ---
 scripts/lib/wic/plugins/imager/direct.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py

 index c44159b235..75004ab320 100644
 --- a/scripts/lib/wic/plugins/imager/direct.py
 +++ b/scripts/lib/wic/plugins/imager/direct.py
 @@ -117,7 +117,8 @@ class DirectPlugin(ImagerPlugin):
 updated = False
 for part in self.parts:
 if not part.realnum or not part.mountpoint \
 -   or not part.mountpoint.startswith('/'):
 +   or not part.mountpoint.startswith('/') \
 +   or part.mountpoint == "/":
 continue

 if part.use_uuid:
 --
 2.34.1












-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168574): 
https://lists.openembedded.org/g/openembedded-core/message/168574
Mute This Topic: https://lists.openembedded.org/mt/92649199/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Otavio Salvador
Em qua., 27 de jul. de 2022 às 12:28, Ross Burton 
escreveu:

> The patch is missing your S-o-b.
>

The patch isn't mine but a backport. Richard can add it when adding it to
MUT, though.

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168573): 
https://lists.openembedded.org/g/openembedded-core/message/168573
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH] wic/direct.py: ignore root mountpoint in fstab updater

2022-07-27 Thread Ross Burton
This looks like a fix for 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14865, can you confirm that?

Ross

> On 27 Jul 2022, at 14:45, Markus Volk via lists.openembedded.org 
>  wrote:
> 
> We already have a root entry in fstab. This commit prevents processing root
> mountpoint in fstab_updater and thus avoids duplicate entries for root in 
> fstab.
> 
> Signed-off-by: Markus Volk 
> ---
> scripts/lib/wic/plugins/imager/direct.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/lib/wic/plugins/imager/direct.py 
> b/scripts/lib/wic/plugins/imager/direct.py
> index c44159b235..75004ab320 100644
> --- a/scripts/lib/wic/plugins/imager/direct.py
> +++ b/scripts/lib/wic/plugins/imager/direct.py
> @@ -117,7 +117,8 @@ class DirectPlugin(ImagerPlugin):
> updated = False
> for part in self.parts:
> if not part.realnum or not part.mountpoint \
> -   or not part.mountpoint.startswith('/'):
> +   or not part.mountpoint.startswith('/') \
> +   or part.mountpoint == "/":
> continue
> 
> if part.use_uuid:
> -- 
> 2.34.1
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168572): 
https://lists.openembedded.org/g/openembedded-core/message/168572
Mute This Topic: https://lists.openembedded.org/mt/92649199/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] debian packaging: set md5sums for conffiles

2022-07-27 Thread Rusty Howell
Will do.

On Wed, Jul 27, 2022 at 8:35 AM Alexander Kanavin 
wrote:

> I think Ross is merely helping you to reach the correct solution, but
> everyone would appreciate if you write and submit the actual fix :-)
>
> Alex
>
> On Wed, 27 Jul 2022 at 16:32, Rusty Howell  wrote:
> >
> > Thanks for the quick responses.   It took us a while to figure out why
> we were seeing weird behaviour with our products, and we ultimately figured
> out the conffiles are being replaced during the update.   I am working off
> of Hardknott currently, so that's my mistake not switching to master.  And
> I guess I misunderstood who is allowed to "sign off" on patches. I assumed
> I couldn't since I'm not a regular. But in any case, it looks like Ross
> Burton may be on to a better solution than what I have to fix the issue.
> >
> > Rusty
> >
> > On Wed, Jul 27, 2022 at 8:09 AM Ross Burton  wrote:
> >>
> >> > So we’re definitely not generating the DEBIAN/md5sums files that
> dpkg-deb likes to have. However, this file in proper Debian packages
> doesn’t contain hashes for the conffiles, so I can only imagine that dpkg
> generates them on install, which leads to the question of where that is
> meant to happen.
> >>
> >> dpkg —configure does this, but we’re neutering it by renaming all
> foo.dpkg-new files to foo in the deb install() function.
> >>
> >> If we’re going to rename foo.dpkg-new to foo, then that is where we go
> and update the status file.
> >>
> >> Alternatively, we don’t do that, and every package needs to run its
> configure step on first boot.
> >>
> >> Ross
> >> 
> >>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168571): 
https://lists.openembedded.org/g/openembedded-core/message/168571
Mute This Topic: https://lists.openembedded.org/mt/92637328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v2] classes: rootfs-postcommands: autologin root on serial-getty

2022-07-27 Thread Ross Burton
> +serial_autologin_root () {
> + if [ -e ${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service 
> ]; then
> + sed -i '/^\s*ExecStart\b/ s/getty /&--autologin root /' \
> + 
> "${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service"
> + fi
> +}

What about images using sysvinit?

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168570): 
https://lists.openembedded.org/g/openembedded-core/message/168570
Mute This Topic: https://lists.openembedded.org/mt/92623778/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Ross Burton
The patch is missing your S-o-b.

Ross

> On 27 Jul 2022, at 13:00, Otavio Salvador via lists.openembedded.org 
>  wrote:
> 
> Backport a fix from 1.0.27 so we only link atomic if no atomic builtins
> are available.
> 
> Signed-off-by: Otavio Salvador 
> ---
> ...k-with-latomic-only-if-no-atomic-bui.patch | 51 +++
> meta/recipes-support/libusb/libusb1_1.0.26.bb |  1 +
> 2 files changed, 52 insertions(+)
> create mode 100644 
> meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
> 
> diff --git 
> a/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
>  
> b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
> new file mode 100644
> index 00..7c20dc0478
> --- /dev/null
> +++ 
> b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
> @@ -0,0 +1,51 @@
> +From a6890a6a9a8f88b567631874e209aaadc79e28e5 Mon Sep 17 00:00:00 2001
> +From: Lonnie Abelbeck 
> +Date: Sun, 8 May 2022 14:05:56 -0500
> +Subject: [PATCH] configure.ac: Link with -latomic only if no atomic builtins
> +
> +Follow-up to 561dbda, a check of GCC atomic builtins needs to be done
> +first.
> +
> +I'm no autoconf guru, but using this:
> +https://github.com/mesa3d/mesa/blob/0df485c285b73c34ba9062f0c27e55c3c702930d/configure.ac#L469
> +as inspiration, I created a pre-check before calling AC_SEARCH_LIBS(...)
> +
> +Upstream-Status: Backport [1.0.27]
> +
> +Fixes #1135
> +Closes #1139
> +(cherry picked from commit 95e601ce116dd46ea7915c171976b85ea0905d58)
> +---
> + configure.ac | 16 +++-
> + 1 file changed, 15 insertions(+), 1 deletion(-)
> +
> +diff --git a/configure.ac b/configure.ac
> +index d4f12510..96787500 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -153,7 +153,21 @@ if test "x$platform" = xposix; then
> + AC_SEARCH_LIBS([pthread_create], [pthread],
> + [test "x$ac_cv_search_pthread_create" != "xnone required" && 
> AC_SUBST(THREAD_LIBS, [-lpthread])],
> + [], [])
> +-AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
> ++dnl Check for new-style atomic builtins. We first check without linking 
> to -latomic.
> ++AC_MSG_CHECKING(whether __atomic_load_n is supported)
> ++AC_LINK_IFELSE([AC_LANG_SOURCE([[
> ++#include 
> ++int main() {
> ++struct {
> ++uint64_t *v;
> ++} x;
> ++return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE) &
> ++   (int)__atomic_add_fetch(x.v, (uint64_t)1, 
> __ATOMIC_ACQ_REL);
> ++}]])], GCC_ATOMIC_BUILTINS_SUPPORTED=yes, 
> GCC_ATOMIC_BUILTINS_SUPPORTED=no)
> ++AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_SUPPORTED)
> ++if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" != xyes; then
> ++AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
> ++fi
> + elif test "x$platform" = xwindows; then
> + AC_DEFINE([PLATFORM_WINDOWS], [1], [Define to 1 if compiling for a 
> Windows platform.])
> + else
> +-- 
> +2.37.0
> +
> diff --git a/meta/recipes-support/libusb/libusb1_1.0.26.bb 
> b/meta/recipes-support/libusb/libusb1_1.0.26.bb
> index fd63e7adc2..ff3f0be7a5 100644
> --- a/meta/recipes-support/libusb/libusb1_1.0.26.bb
> +++ b/meta/recipes-support/libusb/libusb1_1.0.26.bb
> @@ -11,6 +11,7 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=fbc093901857fcd118f065f900982c24"
> BBCLASSEXTEND = "native nativesdk"
> 
> SRC_URI = 
> "https://github.com/libusb/libusb/releases/download/v${PV}/libusb-${PV}.tar.bz2
>  \
> +   
> file://0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch \
>file://run-ptest \
>   "
> 
> -- 
> 2.37.0
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168569): 
https://lists.openembedded.org/g/openembedded-core/message/168569
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [Openembedded-architecture] Let's drop x86-x32 (was Re: [OE-core] [PATCH 05/51] rpm: update 4.17.0 -> 4.17.1)

2022-07-27 Thread Anuj Mittal
On Wed, 2022-07-27 at 16:56 +0200, Alexander Kanavin wrote:
> On Wed, 20 Jul 2022 at 17:46, Alexander Kanavin via
> lists.yoctoproject.org
> 
> wrote:
> > 
> > On Wed, 20 Jul 2022 at 17:41, Mittal, Anuj 
> > wrote:
> > > I don't know if there are any Yocto users of it who might notice.
> > > 
> > > Instead of dropping the testing completely, may be we should
> > > switch to
> > > building/testing just the core-image-minimal image on autobuilder
> > > and
> > > keep at least some minimal support for now.
> > 
> > There's actually already a patch for that :)
> > https://lists.yoctoproject.org/g/yocto/message/56880
> 
> Which I just resent. Now we have confirmation from Intel that nobody
> minds reducing the scope of the AB test.
> 

It was just a personal opinion saying that I won't mind. If it's
needed, then someone would hopefully fix the issues.

Thanks,

Anuj

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168568): 
https://lists.openembedded.org/g/openembedded-core/message/168568
Mute This Topic: https://lists.openembedded.org/mt/92650727/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [Openembedded-architecture] Let's drop x86-x32 (was Re: [OE-core] [PATCH 05/51] rpm: update 4.17.0 -> 4.17.1)

2022-07-27 Thread Alexander Kanavin
On Wed, 20 Jul 2022 at 17:46, Alexander Kanavin via
lists.yoctoproject.org 
wrote:
>
> On Wed, 20 Jul 2022 at 17:41, Mittal, Anuj  wrote:
> > I don't know if there are any Yocto users of it who might notice.
> >
> > Instead of dropping the testing completely, may be we should switch to
> > building/testing just the core-image-minimal image on autobuilder and
> > keep at least some minimal support for now.
>
> There's actually already a patch for that :)
> https://lists.yoctoproject.org/g/yocto/message/56880

Which I just resent. Now we have confirmation from Intel that nobody
minds reducing the scope of the AB test.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168567): 
https://lists.openembedded.org/g/openembedded-core/message/168567
Mute This Topic: https://lists.openembedded.org/mt/92650727/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCHv2]] recipes-support: rng-tools change systemd service name

2022-07-27 Thread An?bal Lim?n
On Wed, Jul 27, 2022 at 5:44 AM Luca Ceresoli 
wrote:

> Hello Aníbal,
>
> On Tue, 26 Jul 2022 14:33:22 -0500
> "An?bal Lim?n"  wrote:
>
> > From: Aníbal Limón 
> >
> > Change systemd service name from rngd -> rng-tools to avoid load twice
> > the service when sysvinit compatibility is enabled,
> >
> > ...
> > root@:~# ps  | grep rng
> >23 root 0 SW   [hwrng]
> > 13109 root  3528 R/usr/sbin/rngd -f -r /dev/hwrng
> > 13117 root  2348 Sgrep rng
> > 29418 root 12756 S/usr/sbin/rngd -r /dev/hwrng
> > ...
> >
> > Signed-off-by: Aníbal Limón 
> > ---
> >  .../rng-tools/{rngd.service => rng-tools.service}|  0
> >  meta/recipes-support/rng-tools/rng-tools_6.15.bb | 12 ++--
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >  rename meta/recipes-support/rng-tools/rng-tools/{rngd.service =>
> rng-tools.service} (100%)
> >
> > diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > similarity index 100%
> > rename from meta/recipes-support/rng-tools/rng-tools/rngd.service
> > rename to meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> > diff --git a/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > index 0696351903..efc08b5e0a 100644
> > --- a/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > +++ b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> > @@ -11,7 +11,7 @@ DEPENDS = "sysfsutils openssl"
> >  SRC_URI = "git://
> github.com/nhorman/rng-tools.git;branch=master;protocol=https \
> > file://init \
> > file://default \
> > -   file://rngd.service \
> > +   file://rng-tools.service \
>
> This feels strange to me: "rng-tools" does not look like a daemon name,
> but rather a, well, tools name. Maybe "rng-daemon" would clarify?
>

Another option is to change the init daemon to be called rngd.

Regards,
Anibal


>
> Still I'm taking this patch for testing, I'll replace it with v2 should
> you send one.
>
> However please note there is an extra ']' in the subject: [PATCHv2]]
> should be [PATCHv2]. This leads 'git am' to produce a commit starting
> with a "] " prefix. I fixed it while applying, however you should check
> that in the future.
>
> Best regards.
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168566): 
https://lists.openembedded.org/g/openembedded-core/message/168566
Mute This Topic: https://lists.openembedded.org/mt/92635255/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] debian packaging: set md5sums for conffiles

2022-07-27 Thread Alexander Kanavin
I think Ross is merely helping you to reach the correct solution, but
everyone would appreciate if you write and submit the actual fix :-)

Alex

On Wed, 27 Jul 2022 at 16:32, Rusty Howell  wrote:
>
> Thanks for the quick responses.   It took us a while to figure out why we 
> were seeing weird behaviour with our products, and we ultimately figured out 
> the conffiles are being replaced during the update.   I am working off of 
> Hardknott currently, so that's my mistake not switching to master.  And I 
> guess I misunderstood who is allowed to "sign off" on patches. I assumed I 
> couldn't since I'm not a regular. But in any case, it looks like Ross Burton 
> may be on to a better solution than what I have to fix the issue.
>
> Rusty
>
> On Wed, Jul 27, 2022 at 8:09 AM Ross Burton  wrote:
>>
>> > So we’re definitely not generating the DEBIAN/md5sums files that dpkg-deb 
>> > likes to have. However, this file in proper Debian packages doesn’t 
>> > contain hashes for the conffiles, so I can only imagine that dpkg 
>> > generates them on install, which leads to the question of where that is 
>> > meant to happen.
>>
>> dpkg —configure does this, but we’re neutering it by renaming all 
>> foo.dpkg-new files to foo in the deb install() function.
>>
>> If we’re going to rename foo.dpkg-new to foo, then that is where we go and 
>> update the status file.
>>
>> Alternatively, we don’t do that, and every package needs to run its 
>> configure step on first boot.
>>
>> Ross
>> 
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168565): 
https://lists.openembedded.org/g/openembedded-core/message/168565
Mute This Topic: https://lists.openembedded.org/mt/92637328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] debian packaging: set md5sums for conffiles

2022-07-27 Thread Rusty Howell
Thanks for the quick responses.   It took us a while to figure out why we
were seeing weird behaviour with our products, and we ultimately figured
out the conffiles are being replaced during the update.   I am working off
of Hardknott currently, so that's my mistake not switching to master.  And
I guess I misunderstood who is allowed to "sign off" on patches. I assumed
I couldn't since I'm not a regular. But in any case, it looks like Ross
Burton may be on to a better solution than what I have to fix the issue.

Rusty

On Wed, Jul 27, 2022 at 8:09 AM Ross Burton  wrote:

> > So we’re definitely not generating the DEBIAN/md5sums files that
> dpkg-deb likes to have. However, this file in proper Debian packages
> doesn’t contain hashes for the conffiles, so I can only imagine that dpkg
> generates them on install, which leads to the question of where that is
> meant to happen.
>
> dpkg —configure does this, but we’re neutering it by renaming all
> foo.dpkg-new files to foo in the deb install() function.
>
> If we’re going to rename foo.dpkg-new to foo, then that is where we go and
> update the status file.
>
> Alternatively, we don’t do that, and every package needs to run its
> configure step on first boot.
>
> Ross
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168564): 
https://lists.openembedded.org/g/openembedded-core/message/168564
Mute This Topic: https://lists.openembedded.org/mt/92637328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] debian packaging: set md5sums for conffiles

2022-07-27 Thread Ross Burton
> So we’re definitely not generating the DEBIAN/md5sums files that dpkg-deb 
> likes to have. However, this file in proper Debian packages doesn’t contain 
> hashes for the conffiles, so I can only imagine that dpkg generates them on 
> install, which leads to the question of where that is meant to happen.

dpkg —configure does this, but we’re neutering it by renaming all foo.dpkg-new 
files to foo in the deb install() function.

If we’re going to rename foo.dpkg-new to foo, then that is where we go and 
update the status file.

Alternatively, we don’t do that, and every package needs to run its configure 
step on first boot.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168563): 
https://lists.openembedded.org/g/openembedded-core/message/168563
Mute This Topic: https://lists.openembedded.org/mt/92637328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] debian packaging: set md5sums for conffiles

2022-07-27 Thread Ross Burton
So we’re definitely not generating the DEBIAN/md5sums files that dpkg-deb likes 
to have. However, this file in proper Debian packages doesn’t contain hashes 
for the conffiles, so I can only imagine that dpkg generates them on install, 
which leads to the question of where that is meant to happen.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168562): 
https://lists.openembedded.org/g/openembedded-core/message/168562
Mute This Topic: https://lists.openembedded.org/mt/92637328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [meta-oe][PATCH] wic/direct.py: ignore root mountpoint in fstab updater

2022-07-27 Thread Markus Volk
We already have a root entry in fstab. This commit prevents processing root
mountpoint in fstab_updater and thus avoids duplicate entries for root in fstab.

Signed-off-by: Markus Volk 
---
 scripts/lib/wic/plugins/imager/direct.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index c44159b235..75004ab320 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -117,7 +117,8 @@ class DirectPlugin(ImagerPlugin):
 updated = False
 for part in self.parts:
 if not part.realnum or not part.mountpoint \
-   or not part.mountpoint.startswith('/'):
+   or not part.mountpoint.startswith('/') \
+   or part.mountpoint == "/":
 continue
 
 if part.use_uuid:
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168561): 
https://lists.openembedded.org/g/openembedded-core/message/168561
Mute This Topic: https://lists.openembedded.org/mt/92649199/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] debian packaging: set md5sums for conffiles

2022-07-27 Thread Ross Burton

> On 27 Jul 2022, at 12:48, Alexander Kanavin via lists.openembedded.org 
>  wrote:
> 
> Also, I'm not sure I understand why this needs to be fixed with custom
> code. Isn't this something that dpkg/apt take care of themselves?

Yes, I suspect this is a problem with how we’re generating the DEBIAN/.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168560): 
https://lists.openembedded.org/g/openembedded-core/message/168560
Mute This Topic: https://lists.openembedded.org/mt/92637328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH] libusb1: Link with -latomic only if no atomic builtins

2022-07-27 Thread Otavio Salvador
Backport a fix from 1.0.27 so we only link atomic if no atomic builtins
are available.

Signed-off-by: Otavio Salvador 
---
 ...k-with-latomic-only-if-no-atomic-bui.patch | 51 +++
 meta/recipes-support/libusb/libusb1_1.0.26.bb |  1 +
 2 files changed, 52 insertions(+)
 create mode 100644 
meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch

diff --git 
a/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
 
b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
new file mode 100644
index 00..7c20dc0478
--- /dev/null
+++ 
b/meta/recipes-support/libusb/libusb1/0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch
@@ -0,0 +1,51 @@
+From a6890a6a9a8f88b567631874e209aaadc79e28e5 Mon Sep 17 00:00:00 2001
+From: Lonnie Abelbeck 
+Date: Sun, 8 May 2022 14:05:56 -0500
+Subject: [PATCH] configure.ac: Link with -latomic only if no atomic builtins
+
+Follow-up to 561dbda, a check of GCC atomic builtins needs to be done
+first.
+
+I'm no autoconf guru, but using this:
+https://github.com/mesa3d/mesa/blob/0df485c285b73c34ba9062f0c27e55c3c702930d/configure.ac#L469
+as inspiration, I created a pre-check before calling AC_SEARCH_LIBS(...)
+
+Upstream-Status: Backport [1.0.27]
+
+Fixes #1135
+Closes #1139
+(cherry picked from commit 95e601ce116dd46ea7915c171976b85ea0905d58)
+---
+ configure.ac | 16 +++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index d4f12510..96787500 100644
+--- a/configure.ac
 b/configure.ac
+@@ -153,7 +153,21 @@ if test "x$platform" = xposix; then
+   AC_SEARCH_LIBS([pthread_create], [pthread],
+   [test "x$ac_cv_search_pthread_create" != "xnone required" && 
AC_SUBST(THREAD_LIBS, [-lpthread])],
+   [], [])
+-  AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
++  dnl Check for new-style atomic builtins. We first check without linking 
to -latomic.
++  AC_MSG_CHECKING(whether __atomic_load_n is supported)
++  AC_LINK_IFELSE([AC_LANG_SOURCE([[
++  #include 
++  int main() {
++  struct {
++  uint64_t *v;
++  } x;
++  return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE) &
++ (int)__atomic_add_fetch(x.v, (uint64_t)1, 
__ATOMIC_ACQ_REL);
++  }]])], GCC_ATOMIC_BUILTINS_SUPPORTED=yes, 
GCC_ATOMIC_BUILTINS_SUPPORTED=no)
++  AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_SUPPORTED)
++  if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" != xyes; then
++  AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic])
++  fi
+ elif test "x$platform" = xwindows; then
+   AC_DEFINE([PLATFORM_WINDOWS], [1], [Define to 1 if compiling for a 
Windows platform.])
+ else
+-- 
+2.37.0
+
diff --git a/meta/recipes-support/libusb/libusb1_1.0.26.bb 
b/meta/recipes-support/libusb/libusb1_1.0.26.bb
index fd63e7adc2..ff3f0be7a5 100644
--- a/meta/recipes-support/libusb/libusb1_1.0.26.bb
+++ b/meta/recipes-support/libusb/libusb1_1.0.26.bb
@@ -11,6 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=fbc093901857fcd118f065f900982c24"
 BBCLASSEXTEND = "native nativesdk"
 
 SRC_URI = 
"https://github.com/libusb/libusb/releases/download/v${PV}/libusb-${PV}.tar.bz2 
\
+   
file://0001-configure.ac-Link-with-latomic-only-if-no-atomic-bui.patch \
file://run-ptest \
   "
 
-- 
2.37.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168559): 
https://lists.openembedded.org/g/openembedded-core/message/168559
Mute This Topic: https://lists.openembedded.org/mt/92647443/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [RFC][PATCHv2] glibc: revert one upstream change to work around broken DEBUG_BUILD build

2022-07-27 Thread Martin Jansa
* work around for build failure with DEBUG_BUILD:
  http://errors.yoctoproject.org/Errors/Details/661468/

  
TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc/2.35-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux/../../libexec/x86_64-oe-linux/gcc/x86_64-oe-linux/11.3.0/ld.bfd:
  
TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc/2.35-r0/build-x86_64-oe-linux/libc.a(libc-tls.o):
  in function `__libc_setup_tls':
  /usr/src/debug/glibc/2.35-r0/git/csu/libc-tls.c:202: undefined reference to 
`_startup_fatal_not_constant'

  introduced in:
  
https://git.openembedded.org/openembedded-core/commit/?id=50ca0eea5424c89c9b39cf69d8bd73fd65f06e95
  with:
  
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a2a6bce7d7e52c1c34369a7da62c501cc350bc31

  Temporary reverting as discussed in:
  https://lists.openembedded.org/g/openembedded-core/message/168463
  (it's also reverted in buildroot now with: 
https://lore.kernel.org/buildroot/20220720213853.1a27184...@busybox.osuosl.org/t/)

  instead of revert we can use -fexpensive-optimizations which
  will optimize-out the symbol, but that works only with -O1 and
  not -Og used by DEBUG_BUILD

  upstream report:
  https://sourceware.org/bugzilla/show_bug.cgi?id=29249

Signed-off-by: Martin Jansa 
---

 v2: mention -fexpensive-optimizations and add link to upstream
 bug report

 ...lement-a-useful-version-of-_startup_.patch | 128 ++
 meta/recipes-core/glibc/glibc_2.35.bb |   2 +
 2 files changed, 130 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch
 
b/meta/recipes-core/glibc/glibc/0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch
new file mode 100644
index 00..2421a63605
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0001-Revert-Linux-Implement-a-useful-version-of-_startup_.patch
@@ -0,0 +1,128 @@
+From 6b8959add09e425df262bf9178b39ca35bc4003c Mon Sep 17 00:00:00 2001
+From: Martin Jansa 
+Date: Sun, 24 Jul 2022 19:41:41 +0200
+Subject: [PATCH] Revert "Linux: Implement a useful version of _startup_fatal"
+
+This reverts commit 2d05ba7f8ef979947e910a37ae8115a816eb4d08.
+Upstream-Status: Inappropriate [temporary work around]
+
+Signed-off-by: Martin Jansa 
+
+---
+ sysdeps/unix/sysv/linux/i386/startup.h | 23 ---
+ sysdeps/unix/sysv/linux/ia64/startup.h | 22 ---
+ sysdeps/unix/sysv/linux/startup.h  | 39 --
+ 3 files changed, 19 insertions(+), 65 deletions(-)
+ delete mode 100644 sysdeps/unix/sysv/linux/ia64/startup.h
+ delete mode 100644 sysdeps/unix/sysv/linux/startup.h
+
+diff --git a/sysdeps/unix/sysv/linux/i386/startup.h 
b/sysdeps/unix/sysv/linux/i386/startup.h
+index 213805d7d2..67c9310f3a 100644
+--- a/sysdeps/unix/sysv/linux/i386/startup.h
 b/sysdeps/unix/sysv/linux/i386/startup.h
+@@ -1,5 +1,5 @@
+ /* Linux/i386 definitions of functions used by static libc main startup.
+-   Copyright (C) 2022 Free Software Foundation, Inc.
++   Copyright (C) 2017-2022 Free Software Foundation, Inc.
+This file is part of the GNU C Library.
+ 
+The GNU C Library is free software; you can redistribute it and/or
+@@ -16,7 +16,22 @@
+License along with the GNU C Library; if not, see
+.  */
+ 
+-/* Can't use "call *%gs:SYSINFO_OFFSET" during startup.  */
+-#define I386_USE_SYSENTER 0
++#if BUILD_PIE_DEFAULT
++/* Can't use "call *%gs:SYSINFO_OFFSET" during statup in static PIE.  */
++# define I386_USE_SYSENTER 0
+ 
+-#include_next 
++# include 
++# include 
++
++__attribute__ ((__noreturn__))
++static inline void
++_startup_fatal (const char *message __attribute__ ((unused)))
++{
++  /* This is only called very early during startup in static PIE.
++ FIXME: How can it be improved?  */
++  ABORT_INSTRUCTION;
++  __builtin_unreachable ();
++}
++#else
++# include_next 
++#endif
+diff --git a/sysdeps/unix/sysv/linux/ia64/startup.h 
b/sysdeps/unix/sysv/linux/ia64/startup.h
+deleted file mode 100644
+index 77f29f15a2..00
+--- a/sysdeps/unix/sysv/linux/ia64/startup.h
 /dev/null
+@@ -1,22 +0,0 @@
+-/* Linux/ia64 definitions of functions used by static libc main startup.
+-   Copyright (C) 2022 Free Software Foundation, Inc.
+-   This file is part of the GNU C Library.
+-
+-   The GNU C Library is free software; you can redistribute it and/or
+-   modify it under the terms of the GNU Lesser General Public
+-   License as published by the Free Software Foundation; either
+-   version 2.1 of the License, or (at your option) any later version.
+-
+-   The GNU C Library is distributed in the hope that it will be useful,
+-   but WITHOUT ANY WARRANTY; without even the implied warranty of
+-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+-   Lesser General Public License for more details.
+-
+-   You should have received a copy of 

Re: [OE-core] [kirkstone][master][PATCH] apt: fix do_package_qa failure

2022-07-27 Thread Alexander Kanavin
What is actually being installed in there? Is it really right to remove it?

Alex

On Wed, 27 Jul 2022 at 07:39, Changqing Li  wrote:
>
> From: Changqing Li 
>
> bitbake nativesdk-apt failed with error:
> ERROR: nativesdk-apt-2.4.5-r0 do_package_qa: QA Issue: nativesdk-apt installs 
> files in 
> /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var/volatile,
>  but it is expected to be empty [empty-dirs]
>
> Signed-off-by: Changqing Li 
> ---
>  meta/recipes-devtools/apt/apt_2.4.5.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/apt/apt_2.4.5.bb 
> b/meta/recipes-devtools/apt/apt_2.4.5.bb
> index 1d94dd118c..d79a33857a 100644
> --- a/meta/recipes-devtools/apt/apt_2.4.5.bb
> +++ b/meta/recipes-devtools/apt/apt_2.4.5.bb
> @@ -123,6 +123,7 @@ do_install:append:class-native() {
>
>  do_install:append:class-nativesdk() {
> customize_apt_conf_sample
> +   rm -rf ${D}${localstatedir}/log
>  }
>
>  do_install:append:class-target() {
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168557): 
https://lists.openembedded.org/g/openembedded-core/message/168557
Mute This Topic: https://lists.openembedded.org/mt/92643987/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] debian packaging: set md5sums for conffiles

2022-07-27 Thread Alexander Kanavin
Also, I'm not sure I understand why this needs to be fixed with custom
code. Isn't this something that dpkg/apt take care of themselves?

Alex

On Wed, 27 Jul 2022 at 12:53, Luca Ceresoli via lists.openembedded.org
 wrote:
>
> Hello Rusty,
>
> On Tue, 26 Jul 2022 15:13:28 -0600
> "Rusty Howell"  wrote:
>
> > Currently in an image created with debian package management, dpkg is 
> > missing the md5sums in
> > /var/lib/dpkg/status for files designated as conffiles.  They are just 
> > listed as "newconffile",
> > which is an intermediate state when dpkg installs a package with an conf 
> > file.  Also, when the
> > device first boots the script /usr/sbin/run-postinsts does not cause 
> > /var/lib/dpkg/status to update
> > those hashes either.
> >
> > The problem here is that when using a package feed, all the conf files are 
> > listed as "newconffile",
> > which will indicate to dpkg to replace them all on the first update.  dpkg 
> > will not follow the rules for
> > confold, confnew, confdef.
>
> This patch does not apply on the current master branch of oe-core.
> Maybe you wrote it on an older commit or on a branch (e.g. kirkstone)?
>
> Also we require you so sign-off the patches you send on the mailing
> list ('git commit -s' does that automatically).
>
> Best regards.
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168556): 
https://lists.openembedded.org/g/openembedded-core/message/168556
Mute This Topic: https://lists.openembedded.org/mt/92637328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 1/3] wic: add target tools to PATH when executing native commands

2022-07-27 Thread Ross Burton
We might want to run a cross tool, such as objcopy, in wic.  These are
in a TARGET_SYS/ subdirectory under /usr/bin, so add that directory to
the search path too.

Signed-off-by: Ross Burton 
---
 scripts/lib/wic/misc.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/wic/misc.py b/scripts/lib/wic/misc.py
index 3bc165fd7d4..2b90821b305 100644
--- a/scripts/lib/wic/misc.py
+++ b/scripts/lib/wic/misc.py
@@ -141,11 +141,12 @@ def exec_native_cmd(cmd_and_args, native_sysroot, 
pseudo=""):
 cmd_and_args = pseudo + cmd_and_args
 
 hosttools_dir = get_bitbake_var("HOSTTOOLS_DIR")
+target_sys = get_bitbake_var("TARGET_SYS")
 
-native_paths = "%s/sbin:%s/usr/sbin:%s/usr/bin:%s/bin:%s" % \
+native_paths = "%s/sbin:%s/usr/sbin:%s/usr/bin:%s/usr/bin/%s:%s/bin:%s" % \
(native_sysroot, native_sysroot,
-native_sysroot, native_sysroot,
-hosttools_dir)
+native_sysroot, native_sysroot, target_sys,
+native_sysroot, hosttools_dir)
 
 native_cmd_and_args = "export PATH=%s:$PATH;%s" % \
(native_paths, cmd_and_args)
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168554): 
https://lists.openembedded.org/g/openembedded-core/message/168554
Mute This Topic: https://lists.openembedded.org/mt/92646877/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 2/3] wic/bootimg-efi: use cross objcopy when building unified kernel image

2022-07-27 Thread Ross Burton
We can't rely on the host objcopy knowing how to process target binaries,
so use the cross objcopy in the sysroot instead.

Also construct the command argument-by-argument as the format expression
was getting unwieldy.

Signed-off-by: Ross Burton 
---
 scripts/lib/wic/plugins/source/bootimg-efi.py | 25 +--
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 0391aebdc84..a65a5b97804 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -326,21 +326,20 @@ class BootimgEFIPlugin(SourcePlugin):
 exec_cmd(install_cmd)
 
 staging_dir_host = get_bitbake_var("STAGING_DIR_HOST")
+target_sys = get_bitbake_var("TARGET_SYS")
 
 # 
https://www.freedesktop.org/software/systemd/man/systemd-stub.html
-objcopy_cmd = "objcopy \
---add-section .osrel=%s --change-section-vma 
.osrel=0x2 \
---add-section .cmdline=%s --change-section-vma 
.cmdline=0x3 \
---add-section .linux=%s --change-section-vma 
.linux=0x200 \
---add-section .initrd=%s --change-section-vma 
.initrd=0x300 \
-%s %s" % \
-("%s/usr/lib/os-release" % staging_dir_host,
-cmdline.name,
-"%s/%s" % (staging_kernel_dir, kernel),
-initrd.name,
-efi_stub,
-"%s/EFI/Linux/linux.efi" % hdddir)
-exec_cmd(objcopy_cmd)
+objcopy_cmd = "%s-objcopy" % target_sys
+objcopy_cmd += " --add-section .osrel=%s/usr/lib/os-release" % 
staging_dir_host
+objcopy_cmd += " --change-section-vma .osrel=0x2"
+objcopy_cmd += " --add-section .cmdline=%s" % cmdline.name
+objcopy_cmd += " --change-section-vma .cmdline=0x3"
+objcopy_cmd += " --add-section .linux=%s/%s" % 
(staging_kernel_dir, kernel)
+objcopy_cmd += " --change-section-vma .linux=0x200"
+objcopy_cmd += " --add-section .initrd=%s" % initrd.name
+objcopy_cmd += " --change-section-vma .initrd=0x300"
+objcopy_cmd += " %s %s/EFI/Linux/linux.efi" % (efi_stub, 
hdddir)
+exec_native_cmd(objcopy_cmd, native_sysroot)
 else:
 install_cmd = "install -m 0644 %s/%s %s/%s" % \
 (staging_kernel_dir, kernel, hdddir, kernel)
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168553): 
https://lists.openembedded.org/g/openembedded-core/message/168553
Mute This Topic: https://lists.openembedded.org/mt/92646876/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 3/3] wic: depend on cross-binutils

2022-07-27 Thread Ross Burton
Wic can build an unified kernel image, but this needs the cross-objcopy
from binutils.

Signed-off-by: Ross Burton 
---
 meta/classes/image_types_wic.bbclass | 2 ++
 meta/recipes-core/meta/wic-tools.bb  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index 79f8d93b94c..940dc5f5774 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -84,6 +84,8 @@ do_image_wic[deptask] += "do_image_complete"
 
 WKS_FILE_DEPENDS_DEFAULT = '${@bb.utils.contains_any("BUILD_ARCH", [ 'x86_64', 
'i686' ], "syslinux-native", "",d)}'
 WKS_FILE_DEPENDS_DEFAULT += "bmap-tools-native cdrtools-native 
btrfs-tools-native squashfs-tools-native e2fsprogs-native erofs-utils-native"
+# Unified kernel images need objcopy
+WKS_FILE_DEPENDS_DEFAULT += "virtual/${TARGET_PREFIX}binutils"
 WKS_FILE_DEPENDS_BOOTLOADERS = ""
 WKS_FILE_DEPENDS_BOOTLOADERS:x86 = "syslinux grub-efi systemd-boot os-release"
 WKS_FILE_DEPENDS_BOOTLOADERS:x86-64 = "syslinux grub-efi systemd-boot 
os-release"
diff --git a/meta/recipes-core/meta/wic-tools.bb 
b/meta/recipes-core/meta/wic-tools.bb
index b9580d7e335..9282d36a4dc 100644
--- a/meta/recipes-core/meta/wic-tools.bb
+++ b/meta/recipes-core/meta/wic-tools.bb
@@ -7,6 +7,7 @@ DEPENDS = "\
mtools-native bmap-tools-native grub-native cdrtools-native \
btrfs-tools-native squashfs-tools-native pseudo-native \
e2fsprogs-native util-linux-native tar-native erofs-utils-native \
+   virtual/${TARGET_PREFIX}binutils \
"
 DEPENDS:append:x86 = " syslinux-native syslinux grub-efi systemd-boot"
 DEPENDS:append:x86-64 = " syslinux-native syslinux grub-efi systemd-boot"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168555): 
https://lists.openembedded.org/g/openembedded-core/message/168555
Mute This Topic: https://lists.openembedded.org/mt/92646878/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] debian packaging: set md5sums for conffiles

2022-07-27 Thread Luca Ceresoli via lists.openembedded.org
Hello Rusty,

On Tue, 26 Jul 2022 15:13:28 -0600
"Rusty Howell"  wrote:

> Currently in an image created with debian package management, dpkg is missing 
> the md5sums in
> /var/lib/dpkg/status for files designated as conffiles.  They are just listed 
> as "newconffile",
> which is an intermediate state when dpkg installs a package with an conf 
> file.  Also, when the
> device first boots the script /usr/sbin/run-postinsts does not cause 
> /var/lib/dpkg/status to update
> those hashes either.
> 
> The problem here is that when using a package feed, all the conf files are 
> listed as "newconffile",
> which will indicate to dpkg to replace them all on the first update.  dpkg 
> will not follow the rules for
> confold, confnew, confdef.

This patch does not apply on the current master branch of oe-core.
Maybe you wrote it on an older commit or on a branch (e.g. kirkstone)?

Also we require you so sign-off the patches you send on the mailing
list ('git commit -s' does that automatically).

Best regards.
-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168552): 
https://lists.openembedded.org/g/openembedded-core/message/168552
Mute This Topic: https://lists.openembedded.org/mt/92637328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCHv2]] recipes-support: rng-tools change systemd service name

2022-07-27 Thread Luca Ceresoli via lists.openembedded.org
Hello Aníbal,

On Tue, 26 Jul 2022 14:33:22 -0500
"An?bal Lim?n"  wrote:

> From: Aníbal Limón 
> 
> Change systemd service name from rngd -> rng-tools to avoid load twice
> the service when sysvinit compatibility is enabled,
> 
> ...
> root@:~# ps  | grep rng
>23 root 0 SW   [hwrng]
> 13109 root  3528 R/usr/sbin/rngd -f -r /dev/hwrng
> 13117 root  2348 Sgrep rng
> 29418 root 12756 S/usr/sbin/rngd -r /dev/hwrng
> ...
> 
> Signed-off-by: Aníbal Limón 
> ---
>  .../rng-tools/{rngd.service => rng-tools.service}|  0
>  meta/recipes-support/rng-tools/rng-tools_6.15.bb | 12 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)
>  rename meta/recipes-support/rng-tools/rng-tools/{rngd.service => 
> rng-tools.service} (100%)
> 
> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service 
> b/meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> similarity index 100%
> rename from meta/recipes-support/rng-tools/rng-tools/rngd.service
> rename to meta/recipes-support/rng-tools/rng-tools/rng-tools.service
> diff --git a/meta/recipes-support/rng-tools/rng-tools_6.15.bb 
> b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> index 0696351903..efc08b5e0a 100644
> --- a/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> +++ b/meta/recipes-support/rng-tools/rng-tools_6.15.bb
> @@ -11,7 +11,7 @@ DEPENDS = "sysfsutils openssl"
>  SRC_URI = 
> "git://github.com/nhorman/rng-tools.git;branch=master;protocol=https \
> file://init \
> file://default \
> -   file://rngd.service \
> +   file://rng-tools.service \

This feels strange to me: "rng-tools" does not look like a daemon name,
but rather a, well, tools name. Maybe "rng-daemon" would clarify?

Still I'm taking this patch for testing, I'll replace it with v2 should
you send one.

However please note there is an extra ']' in the subject: [PATCHv2]]
should be [PATCHv2]. This leads 'git am' to produce a commit starting
with a "] " prefix. I fixed it while applying, however you should check
that in the future.

Best regards.
-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168551): 
https://lists.openembedded.org/g/openembedded-core/message/168551
Mute This Topic: https://lists.openembedded.org/mt/92635255/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v3] classes: rootfs-postcommands: autologin root on serial-getty

2022-07-27 Thread Luca Ceresoli via lists.openembedded.org
On Wed, 27 Jul 2022 05:37:39 +0200
"Johannes Schneider via lists.openembedded.org"
 wrote:

> when empty-root-password AND serial-autologin-root are part of the
> IMAGE_FEATURES, save some of the developers time by not having to type
> the (then still sole) 'root' username on the serial consoleafter each

s/consoleafter/console after/

> and every reboot
> 
> this is done by inserting '--autologin root' into the command line of
> the responsible 'getty' service
> 
> Signed-off-by: Johannes Schneider 
> ---
>  meta/classes/core-image.bbclass  |  1 +
>  meta/classes/image.bbclass   |  2 +-
>  meta/classes/rootfs-postcommands.bbclass | 15 +++
>  3 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass
> index 84fd3eeb38..6764035729 100644
> --- a/meta/classes/core-image.bbclass
> +++ b/meta/classes/core-image.bbclass
> @@ -29,6 +29,7 @@
>  #   - allow-empty-password
>  #   - allow-root-login
>  #   - post-install-logging
> +# - serial-autologin-root - with 'empty-root-password': autologin 'root' on 
> the serial console
>  # - dev-pkgs- development packages (headers, etc.) for all 
> installed packages in the rootfs
>  # - dbg-pkgs- debug symbol packages for all installed packages 
> in the rootfs
>  # - lic-pkgs- license packages for all installed pacakges in the 
> rootfs, requires
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 2139a7e576..fe32cdefd5 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -34,7 +34,7 @@ INHIBIT_DEFAULT_DEPS = "1"
>  # IMAGE_FEATURES may contain any available package group
>  IMAGE_FEATURES ?= ""
>  IMAGE_FEATURES[type] = "list"
> -IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
> read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
> allow-empty-password allow-root-login post-install-logging overlayfs-etc"
> +IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
> read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
> allow-empty-password allow-root-login serial-autologin-root 
> post-install-logging overlayfs-etc"
>  
>  # Generate companion debugfs?
>  IMAGE_GEN_DEBUGFS ?= "0"
> diff --git a/meta/classes/rootfs-postcommands.bbclass 
> b/meta/classes/rootfs-postcommands.bbclass
> index a8a952f31d..65fe74cc5d 100644
> --- a/meta/classes/rootfs-postcommands.bbclass
> +++ b/meta/classes/rootfs-postcommands.bbclass
> @@ -8,6 +8,9 @@ ROOTFS_POSTPROCESS_COMMAND += 
> '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'deb
>  # Allow dropbear/openssh to accept root logins if debug-tweaks or 
> allow-root-login is enabled
>  ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
> 'debug-tweaks', 'allow-root-login' ], "ssh_allow_root_login; ", "",d)}'
>  
> +# Autologin the root user on the serial console, if empty-root-password and 
> serial-autologin-root are active
> +ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", [ 
> 'empty-root-password', 'serial-autologin-root' ], "serial_autologin_root; ", 
> "",d)}'
> +
>  # Enable postinst logging if debug-tweaks or post-install-logging is enabled
>  ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
> 'debug-tweaks', 'post-install-logging' ], "postinst_enable_logging; ", "",d)}'
>  
> @@ -196,6 +199,18 @@ ssh_allow_root_login () {
>   fi
>  }
>  
> +#
> +# Autologin the 'root' user on the serial terminal,
> +# if empty-root-password' AND 'serial-autologin-root are enabled
> +#
> +serial_autologin_root () {
> + if [ -e ${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service 
> ]; then
> + sed -i '/^\s*ExecStart\b/ s/getty /&--autologin root /' \
> + 
> "${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service"
> + fi
> +}
> +
> +


Extra empty line.

I took you patch for testing with the above fixed, no need to resend
just for those.

Thanks.
-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168550): 
https://lists.openembedded.org/g/openembedded-core/message/168550
Mute This Topic: https://lists.openembedded.org/mt/92642961/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH 1/1] lame: Remove hardcoded rpaths

2022-07-27 Thread Paulo Neves
I thought of that myself, but did not yet investigate. We have 
hardcode_into_libs disabling in 4 "recipes":


git grep hardcode_into_libs -- meta
recipes-devtools/binutils/binutils/0009-Use-libtool-2.4.patch: 
hardcode_into_libs=yes
recipes-devtools/binutils/binutils/0009-Use-libtool-2.4.patch: if test 
"$hardcode_into_libs" != yes || test "$build_old_libs" = yes; then
recipes-devtools/gcc/gcc-sanitizers.inc:    sed -i -e 
's/hardcode_into_libs=yes/hardcode_into_libs=no/' 
${B}/${TARGET_SYS}/libsanitizer/libtool
recipes-devtools/gcc/gcc-source.inc:    cmd = d.expand("sed -i -e 
's/hardcode_into_libs=yes/hardcode_into_libs=no/' ${S}/libcc1/configure")
recipes-devtools/gcc/libgfortran.inc:  sed -i -e 
's/hardcode_into_libs=yes/hardcode_into_libs=no/' 
${B}/${TARGET_SYS}/$target/libtool
recipes-support/db/db_5.3.28.bb:    sed -i -e 
's|hardcode_into_libs=yes|hardcode_into_libs=no|' ${B}/libtool


The hardcode_into_libs=no did not fix things for the lame case. We have 
a patch for libtools that looks like could be the culprit and need 
tightening [1]



[1] 
recipes-devtools/libtool/libtool/0004-ltmain.sh-Fix-sysroot-paths-being-encoded-into-RPATH.patch


Paulo Neves

On 7/26/22 23:34, Richard Purdie wrote:

On Tue, 2022-07-26 at 22:23 +0200, Paulo Neves wrote:

Due to hardcoded rpaths tmpdir contamination happened on lame
executable. This commit hot patches libtool to not hardcode
the .libs directory in the rpath. This solves [YOCTO #14863]

Signed-off-by: Paulo Neves 
---
  meta/recipes-multimedia/lame/lame_3.100.bb | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/recipes-multimedia/lame/lame_3.100.bb 
b/meta/recipes-multimedia/lame/lame_3.100.bb
index 5b42795f4e..2d9bd9d29f 100644
--- a/meta/recipes-multimedia/lame/lame_3.100.bb
+++ b/meta/recipes-multimedia/lame/lame_3.100.bb
@@ -24,3 +24,7 @@ FILES:${PN} = "${bindir}/lame"
  FILES:libmp3lame = "${libdir}/libmp3lame.so.*"
  FILES:libmp3lame-dev = "${includedir} ${libdir}/*"
  FILES:${PN}-dev = ""
+do_compile:prepend() {
+# Stop libtool adding RPATHs
+sed -i -e 's|hardcode_libdir_flag_spec=".*"|hardcode_libdir_flag_spec=""|' 
${B}/libtool
+}

Any idea why lame has this issue but we don't see it with anything else
using libtool? I'm wondering if there is an underlying cause we should
look at?

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168549): 
https://lists.openembedded.org/g/openembedded-core/message/168549
Mute This Topic: https://lists.openembedded.org/mt/92636379/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [dunfell][PATCH] libTiff: CVE-2022-2056 CVE-2022-2057 CVE-2022-2058 DoS from Divide By Zero Error

2022-07-27 Thread Hitendra Prajapati
Source: https://gitlab.com/libtiff/libtiff
MR: 119341
Type: Security Fix
Disposition: Backport from 
https://gitlab.com/libtiff/libtiff/-/commit/dd1bcc7abb26094e93636e85520f0d8f81ab0fab
ChangeID: 6cea4937a34a618567a42cef8c41961ade2f3a07
Description:
CVE-2022-2056 CVE-2022-2057 CVE-2022-2058 libTiff: DoS from Divide By 
Zero Error.

Signed-off-by: Hitendra Prajapati 
---
 ...022-2056-CVE-2022-2057-CVE-2022-2058.patch | 183 ++
 meta/recipes-multimedia/libtiff/tiff_4.1.0.bb |   1 +
 2 files changed, 184 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libtiff/files/CVE-2022-2056-CVE-2022-2057-CVE-2022-2058.patch

diff --git 
a/meta/recipes-multimedia/libtiff/files/CVE-2022-2056-CVE-2022-2057-CVE-2022-2058.patch
 
b/meta/recipes-multimedia/libtiff/files/CVE-2022-2056-CVE-2022-2057-CVE-2022-2058.patch
new file mode 100644
index 00..01e81349a2
--- /dev/null
+++ 
b/meta/recipes-multimedia/libtiff/files/CVE-2022-2056-CVE-2022-2057-CVE-2022-2058.patch
@@ -0,0 +1,183 @@
+From 8261237113a53cd21029c4a8cbb62c47b4c19523 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Wed, 27 Jul 2022 11:30:18 +0530
+Subject: [PATCH] CVE-2022-2056 CVE-2022-2057 CVE-2022-2058
+
+Upstream-Status: Backport 
[https://gitlab.com/libtiff/libtiff/-/commit/dd1bcc7abb26094e93636e85520f0d8f81ab0fab]
+CVE: CVE-2022-2056 CVE-2022-2057 CVE-2022-2058
+Signed-off-by: Hitendra Prajapati 
+---
+ libtiff/tif_aux.c |  9 +++
+ libtiff/tiffiop.h |  1 +
+ tools/tiffcrop.c  | 62 ++-
+ 3 files changed, 44 insertions(+), 28 deletions(-)
+
+diff --git a/libtiff/tif_aux.c b/libtiff/tif_aux.c
+index 8188db5..3dac542 100644
+--- a/libtiff/tif_aux.c
 b/libtiff/tif_aux.c
+@@ -402,6 +402,15 @@ float _TIFFClampDoubleToFloat( double val )
+ return (float)val;
+ }
+ 
++uint32 _TIFFClampDoubleToUInt32(double val)
++{
++if( val < 0 )
++return 0;
++if( val > 0xU || val != val )
++return 0xU;
++return (uint32)val;
++}
++
+ int _TIFFSeekOK(TIFF* tif, toff_t off)
+ {
+ /* Huge offsets, especially -1 / UINT64_MAX, can cause issues */
+diff --git a/libtiff/tiffiop.h b/libtiff/tiffiop.h
+index 45a7932..c6f6f93 100644
+--- a/libtiff/tiffiop.h
 b/libtiff/tiffiop.h
+@@ -393,6 +393,7 @@ extern double _TIFFUInt64ToDouble(uint64);
+ extern float _TIFFUInt64ToFloat(uint64);
+ 
+ extern float _TIFFClampDoubleToFloat(double);
++extern uint32 _TIFFClampDoubleToUInt32(double);
+ 
+ extern tmsize_t
+ _TIFFReadEncodedStripAndAllocBuffer(TIFF* tif, uint32 strip,
+diff --git a/tools/tiffcrop.c b/tools/tiffcrop.c
+index c2c2052..79dd0a0 100644
+--- a/tools/tiffcrop.c
 b/tools/tiffcrop.c
+@@ -5141,17 +5141,17 @@ computeInputPixelOffsets(struct crop_mask *crop, 
struct image_data *image,
+   {
+   if ((crop->res_unit == RESUNIT_INCH) || (crop->res_unit == 
RESUNIT_CENTIMETER))
+ {
+-  x1 = (uint32) (crop->corners[i].X1 * scale * xres);
+-  x2 = (uint32) (crop->corners[i].X2 * scale * xres);
+-  y1 = (uint32) (crop->corners[i].Y1 * scale * yres);
+-  y2 = (uint32) (crop->corners[i].Y2 * scale * yres);
++  x1 = _TIFFClampDoubleToUInt32(crop->corners[i].X1 * scale * xres);
++  x2 = _TIFFClampDoubleToUInt32(crop->corners[i].X2 * scale * xres);
++  y1 = _TIFFClampDoubleToUInt32(crop->corners[i].Y1 * scale * yres);
++  y2 = _TIFFClampDoubleToUInt32(crop->corners[i].Y2 * scale * yres);
+ }
+   else
+ {
+-  x1 = (uint32) (crop->corners[i].X1);
+-  x2 = (uint32) (crop->corners[i].X2);
+-  y1 = (uint32) (crop->corners[i].Y1);
+-  y2 = (uint32) (crop->corners[i].Y2);   
++  x1 = _TIFFClampDoubleToUInt32(crop->corners[i].X1);
++  x2 = _TIFFClampDoubleToUInt32(crop->corners[i].X2);
++  y1 = _TIFFClampDoubleToUInt32(crop->corners[i].Y1);
++  y2 = _TIFFClampDoubleToUInt32(crop->corners[i].Y2);
+   }
+   if (x1 < 1)
+ crop->regionlist[i].x1 = 0;
+@@ -5214,17 +5214,17 @@ computeInputPixelOffsets(struct crop_mask *crop, 
struct image_data *image,
+ {
+ if (crop->res_unit != RESUNIT_INCH && crop->res_unit != 
RESUNIT_CENTIMETER)
+   { /* User has specified pixels as reference unit */
+-  tmargin = (uint32)(crop->margins[0]);
+-  lmargin = (uint32)(crop->margins[1]);
+-  bmargin = (uint32)(crop->margins[2]);
+-  rmargin = (uint32)(crop->margins[3]);
++  tmargin = _TIFFClampDoubleToUInt32(crop->margins[0]);
++  lmargin = _TIFFClampDoubleToUInt32(crop->margins[1]);
++  bmargin = _TIFFClampDoubleToUInt32(crop->margins[2]);
++  rmargin = _TIFFClampDoubleToUInt32(crop->margins[3]);
+   }
+ else
+   { /* inches or centimeters specified */
+-  tmargin = (uint32)(crop->margins[0] * scale * yres);
+-  lmargin = (uint32)(crop->margins[1] * scale * xres);
+-  bmargin = (uint32)(crop->margins[2] * scale * yres);
+-  rmargin = (uint32)(crop->margins[3] * scale * xres);
++  

[OE-core] [dunfell][PATCH] qemu: CVE-2022-35414 can perform an uninitialized read on the translate_fail path, leading to an io_readx or io_writex crash

2022-07-27 Thread Hitendra Prajapati
Source: https://github.com/qemu/qemu
MR: 119832
Type: Security Fix
Disposition: Backport from 
https://github.com/qemu/qemu/commit/418ade7849ce7641c0f7333718caf5091a02fd4c
ChangeID: 1246afd7bb950d2d5fe2e198961797c0fa14ac00
Description:
CVE-2022-35414 qemu: can perform an uninitialized read on the 
translate_fail path, leading to an io_readx or io_writex crash.

Signed-off-by: Hitendra Prajapati 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2022-35414.patch| 53 +++
 2 files changed, 54 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 4135619fc6..10b4280b23 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -98,6 +98,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2020-13253_4.patch \
file://CVE-2020-13253_5.patch \
file://CVE-2020-13791.patch \
+   file://CVE-2022-35414.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch
new file mode 100644
index 00..4196ebcf98
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch
@@ -0,0 +1,53 @@
+From 09a07b5b39c87423df9e8f6574c19a14d36beac5 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Wed, 27 Jul 2022 10:34:12 +0530
+Subject: [PATCH] CVE-2022-35414
+
+Upstream-Status: Backport 
[https://github.com/qemu/qemu/commit/418ade7849ce7641c0f7333718caf5091a02fd4c]
+CVE: CVE-2022-35414
+Signed-off-by: Hitendra Prajapati 
+---
+ exec.c | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/exec.c b/exec.c
+index 43c70ffb..2d6add46 100644
+--- a/exec.c
 b/exec.c
+@@ -685,7 +685,7 @@ static void tcg_iommu_free_notifier_list(CPUState *cpu)
+ 
+ /* Called from RCU critical section */
+ MemoryRegionSection *
+-address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr addr,
++address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr orig_addr,
+   hwaddr *xlat, hwaddr *plen,
+   MemTxAttrs attrs, int *prot)
+ {
+@@ -694,6 +694,7 @@ address_space_translate_for_iotlb(CPUState *cpu, int 
asidx, hwaddr addr,
+ IOMMUMemoryRegionClass *imrc;
+ IOMMUTLBEntry iotlb;
+ int iommu_idx;
++hwaddr addr = orig_addr;
+ AddressSpaceDispatch *d = 
atomic_rcu_read(>cpu_ases[asidx].memory_dispatch);
+ 
+ for (;;) {
+@@ -737,6 +738,16 @@ address_space_translate_for_iotlb(CPUState *cpu, int 
asidx, hwaddr addr,
+ return section;
+ 
+ translate_fail:
++/*
++ * We should be given a page-aligned address -- certainly
++ * tlb_set_page_with_attrs() does so.  The page offset of xlat
++ * is used to index sections[], and PHYS_SECTION_UNASSIGNED = 0.
++ * The page portion of xlat will be logged by memory_region_access_valid()
++ * when this memory access is rejected, so use the original untranslated
++ * physical address.
++ */
++assert((orig_addr & ~TARGET_PAGE_MASK) == 0);
++*xlat = orig_addr;
+ return >map.sections[PHYS_SECTION_UNASSIGNED];
+ }
+ #endif
+-- 
+2.25.1
+
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168547): 
https://lists.openembedded.org/g/openembedded-core/message/168547
Mute This Topic: https://lists.openembedded.org/mt/92645007/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v3] classes: rootfs-postcommands: autologin root on serial-getty

2022-07-27 Thread Johannes Schneider via lists.openembedded.org
Hi,

what & where would you like to see (as) additional documentation? (-:

regards

From: Marta Rybczynska 
Sent: Wednesday, July 27, 2022 09:27
To: SCHNEIDER Johannes 
Cc: OE-core 
Subject: Re: [OE-core] [meta-oe][PATCH v3] classes: rootfs-postcommands: 
autologin root on serial-getty

[You don't often get email from rybczyn...@gmail.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

This email is not from Hexagon’s Office 365 instance. Please be careful while 
clicking links, opening attachments, or replying to this email.


On Wed, Jul 27, 2022 at 5:37 AM Johannes Schneider via
lists.openembedded.org

wrote:
>
> when empty-root-password AND serial-autologin-root are part of the
> IMAGE_FEATURES, save some of the developers time by not having to type
> the (then still sole) 'root' username on the serial consoleafter each
> and every reboot
>

If this change is accepted, it would be good to have it documented
really soon. It is likely
to break CIs.

Regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168546): 
https://lists.openembedded.org/g/openembedded-core/message/168546
Mute This Topic: https://lists.openembedded.org/mt/92642961/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2] mesa: fix compile error when debug build enabled

2022-07-27 Thread kai
From: Kai Kang 

It fails to compile mesa{,-native} when DEBUG_BUILD is enabled:

../mesa-22.1.3/src/compiler/nir/nir_inline_helpers.h: In function 
‘nir_opt_move_block’:
../mesa-22.1.3/src/compiler/nir/nir_opt_move.c:55:1: error: inlining failed in 
call to
  always_inline ‘src_is_ssa’: indirect function call with a yet undetermined 
callee
 src_is_ssa(nir_src *src, void *state)
 ^~

Backport patch from mesa merge request to fix it.

Signed-off-by: Kai Kang 
---
v2:
* use patch from mesa merge request

 ...ove-fix-ALWAYS_INLINE-compiler-error.patch | 65 +++
 meta/recipes-graphics/mesa/mesa.inc   |  1 +
 2 files changed, 66 insertions(+)
 create mode 100644 
meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch

diff --git 
a/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
 
b/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
new file mode 100644
index 00..48fc1e37ff
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
@@ -0,0 +1,65 @@
+Backport merge request to fix mesa compile error when debug build
+enabled.
+
+Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17439]
+
+Signed-off-by: Kai Kang 
+
+From c69c6e7a35205557de73734ad4a1f411c8f99926 Mon Sep 17 00:00:00 2001
+From: t bettler 
+Date: Sat, 9 Jul 2022 09:28:51 +
+Subject: [PATCH] nir/nir_opt_move: fix ALWAYS_INLINE compiler error
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+fix call to ‘always_inline’ ‘src_is_ssa’
+
+Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6825
+Fixes: f1d20ec67c3f186886b97de94f74484650f8fda1 ("nir/nir_opt_move: handle 
non-SSA defs ")
+---
+ src/compiler/nir/nir_inline_helpers.h | 10 --
+ src/compiler/nir/nir_opt_move.c   |  2 +-
+ 2 files changed, 9 insertions(+), 3 deletions(-)
+
+diff --git a/src/compiler/nir/nir_inline_helpers.h 
b/src/compiler/nir/nir_inline_helpers.h
+index 125dd8a537c..ec33f0509f7 100644
+--- a/src/compiler/nir/nir_inline_helpers.h
 b/src/compiler/nir/nir_inline_helpers.h
+@@ -73,8 +73,8 @@ nir_foreach_dest(nir_instr *instr, nir_foreach_dest_cb cb, 
void *state)
+return _nir_foreach_dest(instr, cb, state);
+ }
+ 
+-static inline bool
+-nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
++static ALWAYS_INLINE bool
++_nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
+ {
+switch (instr->type) {
+case nir_instr_type_alu: {
+@@ -162,3 +162,9 @@ nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, 
void *state)
+dest_state.cb = cb;
+return _nir_foreach_dest(instr, _nir_visit_dest_indirect, _state);
+ }
++
++static inline bool
++nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
++{
++   return _nir_foreach_src(instr, cb, state);
++}
+diff --git a/src/compiler/nir/nir_opt_move.c b/src/compiler/nir/nir_opt_move.c
+index 81bcde5c436..051c3cc6295 100644
+--- a/src/compiler/nir/nir_opt_move.c
 b/src/compiler/nir/nir_opt_move.c
+@@ -60,7 +60,7 @@ src_is_ssa(nir_src *src, void *state)
+ static ALWAYS_INLINE bool
+ instr_reads_register(nir_instr *instr)
+ {
+-   return !nir_foreach_src(instr, src_is_ssa, NULL);
++   return !_nir_foreach_src(instr, src_is_ssa, NULL);
+ }
+ 
+ static bool
+-- 
+2.34.1
+
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 710cacb09d..f02ef2dc2b 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -22,6 +22,7 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-util-format-Check-for-NEON-before-using-it.patch \

file://0001-Revert-egl-wayland-deprecate-drm_handle_format-and-d.patch \

file://0001-swrast_kms-use-swkmsDRI2Extension-instead-of-driDRI2.patch \
+   file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch 
\
"
 
 SRC_URI[sha256sum] = 
"b98f32ba7aa2a1ff5725fb36eb999c693079f0ca16f70aa2f103e2b6c3f093e3"
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168545): 
https://lists.openembedded.org/g/openembedded-core/message/168545
Mute This Topic: https://lists.openembedded.org/mt/92644854/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [meta-oe][PATCH v3] classes: rootfs-postcommands: autologin root on serial-getty

2022-07-27 Thread Marta Rybczynska
On Wed, Jul 27, 2022 at 5:37 AM Johannes Schneider via
lists.openembedded.org

wrote:
>
> when empty-root-password AND serial-autologin-root are part of the
> IMAGE_FEATURES, save some of the developers time by not having to type
> the (then still sole) 'root' username on the serial consoleafter each
> and every reboot
>

If this change is accepted, it would be good to have it documented
really soon. It is likely
to break CIs.

Regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168544): 
https://lists.openembedded.org/g/openembedded-core/message/168544
Mute This Topic: https://lists.openembedded.org/mt/92642961/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [kirkstone][PATCH] qemu: CVE-2022-35414 can perform an uninitialized read on the translate_fail path, leading to an io_readx or io_writex crash

2022-07-27 Thread Hitendra Prajapati
Source: https://github.com/qemu/qemu
MR: 119830
Type: Security Fix
Disposition: Backport from 
https://github.com/qemu/qemu/commit/418ade7849ce7641c0f7333718caf5091a02fd4c
ChangeID: 41d6646e06319e629da574b9b2e8a3a197a73441
Description:
CVE-2022-35414 qemu: can perform an uninitialized read on the 
translate_fail path, leading to an io_readx or io_writex crash.

Signed-off-by: Hitendra Prajapati 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2022-35414.patch| 53 +++
 2 files changed, 54 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 8c5a649c76..2395625948 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -35,6 +35,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://pvrdma.patch \
file://CVE-2021-4206.patch \
file://CVE-2021-4207.patch \
+   file://CVE-2022-35414.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch
new file mode 100644
index 00..3786497f01
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch
@@ -0,0 +1,53 @@
+From ee76e64ee1cb232b77652b21cc94ec6b6c7e4b13 Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Wed, 27 Jul 2022 10:49:47 +0530
+Subject: [PATCH] CVE-2022-35414
+
+Upstream-Status: Backport 
[https://github.com/qemu/qemu/commit/418ade7849ce7641c0f7333718caf5091a02fd4c]
+CVE: CVE-2022-35414
+Signed-off-by: Hitendra Prajapati 
+---
+ softmmu/physmem.c | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/softmmu/physmem.c b/softmmu/physmem.c
+index 3524c04c2..3c467527d 100644
+--- a/softmmu/physmem.c
 b/softmmu/physmem.c
+@@ -667,7 +667,7 @@ void tcg_iommu_init_notifier_list(CPUState *cpu)
+ 
+ /* Called from RCU critical section */
+ MemoryRegionSection *
+-address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr addr,
++address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr orig_addr,
+   hwaddr *xlat, hwaddr *plen,
+   MemTxAttrs attrs, int *prot)
+ {
+@@ -676,6 +676,7 @@ address_space_translate_for_iotlb(CPUState *cpu, int 
asidx, hwaddr addr,
+ IOMMUMemoryRegionClass *imrc;
+ IOMMUTLBEntry iotlb;
+ int iommu_idx;
++hwaddr addr = orig_addr;
+ AddressSpaceDispatch *d =
+ qatomic_rcu_read(>cpu_ases[asidx].memory_dispatch);
+ 
+@@ -720,6 +721,16 @@ address_space_translate_for_iotlb(CPUState *cpu, int 
asidx, hwaddr addr,
+ return section;
+ 
+ translate_fail:
++/*
++ * We should be given a page-aligned address -- certainly
++ * tlb_set_page_with_attrs() does so.  The page offset of xlat
++ * is used to index sections[], and PHYS_SECTION_UNASSIGNED = 0.
++ * The page portion of xlat will be logged by memory_region_access_valid()
++ * when this memory access is rejected, so use the original untranslated
++ * physical address.
++ */
++assert((orig_addr & ~TARGET_PAGE_MASK) == 0);
++*xlat = orig_addr;
+ return >map.sections[PHYS_SECTION_UNASSIGNED];
+ }
+ 
+-- 
+2.25.1
+
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168543): 
https://lists.openembedded.org/g/openembedded-core/message/168543
Mute This Topic: https://lists.openembedded.org/mt/92644506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-