Re: [OE-core] [PATCH 1/7] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid

[Chen Qi]

On 9/14/22 13:00, Alexander Kanavin wrote:

Hello,

this is done for reasons of discoverability and consistency with
machine and distro definitions: they all should be under
meta-somelayer/conf/. This way both tools and humans can easily find
the config templates, and be certain that this is the only location..

Alex


Hi Alex,

I'm reluctant to agree that this is like machine and distro, because 
it's a hard requirement that machine and distro definitions be under 
some layer, otherwise how can bitbake get info about it? But 
TEMPLATECONF seems to be a different case, it could be everywhere 
because it's used by the project setup script.


In our case, the TEMPLATECONF is /config/, and layers are 
//. This directory hierarchy has been working for 
years until recent changes.


Do you think such directory hierarchy makes sense? How about we deleting 
such check if there's no strong technical reason to do so? By 'strong 
technical reason', I mean that some codes in oe-core are written based 
on this assumption (this is the part I'm sure about).


Regards,

Qi



On Wed, 14 Sept 2022 at 05:27, ChenQi  wrote:

Hi Alex,

Why must TEMPLATECONF be under a layer?

Regards,
Qi

On 8/31/22 19:13, Alexander Kanavin wrote:

specifically that ../../layer.conf exists, and that second-from-last
component in the path is 'templates'.

This requires tweaking template.conf creation in eSDK bbclass, as
we need to ensure that the path in it is valid, and exists
(which may not be the case if the SDK is poky-based).

Signed-off-by: Alexander Kanavin 
---
   meta/classes-recipe/populate_sdk_ext.bbclass | 3 ++-
   scripts/oe-setup-builddir| 5 +
   2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass 
b/meta/classes-recipe/populate_sdk_ext.bbclass
index 56e24c4eed..925cb313fc 100644
--- a/meta/classes-recipe/populate_sdk_ext.bbclass
+++ b/meta/classes-recipe/populate_sdk_ext.bbclass
@@ -438,7 +438,8 @@ python copy_buildsystem () {
   else:
   # Write a templateconf.cfg
   with open(baseoutpath + '/conf/templateconf.cfg', 'w') as f:
-f.write('meta/conf\n')
+f.write('meta/conf/templates/default\n')
+os.makedirs(os.path.join(baseoutpath, core_meta_subdir, 
'conf/templates/default'), exist_ok=True)

   # Ensure any variables set from the external environment (by way of
   # BB_ENV_PASSTHROUGH_ADDITIONS) are set in the SDK's configuration
diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index 5d644168cb..bf832ee0ca 100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -61,6 +61,11 @@ if [ -n "$TEMPLATECONF" ]; then
   echo >&2 "Error: TEMPLATECONF value points to nonexistent directory 
'$TEMPLATECONF'"
   exit 1
   fi
+templatesdir=$(python3 -c "import sys; 
print(sys.argv[1].strip('/').split('/')[-2])" $TEMPLATECONF)
+if [ ! -f "$TEMPLATECONF/../../layer.conf" -o $templatesdir != 
"templates" ]; then
+echo >&2 "Error: TEMPLATECONF value (which is $TEMPLATECONF) must point 
to meta-some-layer/conf/templates/template-name"
+exit 1
+fi
   fi
   OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample"
   OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170633): 
https://lists.openembedded.org/g/openembedded-core/message/170633
Mute This Topic: https://lists.openembedded.org/mt/93368468/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 v3] webkitgtk: Fix build on 32bit arm

[Yu, Mingli]

On 9/14/22 11:02, Khem Raj wrote:

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

On Tue, Sep 13, 2022 at 7:25 PM Yu, Mingli  wrote:


Still failed on beaglebone-yocto:

/build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/webkitgtk/2.36.7-r0/webkitgtk-2.36.7/Source/W
ebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:38:8: error:
standard attributes in middle of decl-specifiers
 38 | static alignas(16) short s_FELightingConstantsForNeon[] = {
|^~~






What is your -j value ? please give 4GB per core of memory for
webkitgtk to build.


Not specify the -j value explicitly at first and it still failed with 
the same error even specify the -j value as you mentioned.



/build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/webkitgtk/2.36.7-r0/webkitgtk-2.36.7/Source/W
ebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:38:8: error: 
standard attributes in middle of decl-specifiers

   38 | static alignas(16) short s_FELightingConstantsForNeon[] = {
  |^~~


Thanks,




Thanks,

On 9/9/22 05:45, Khem Raj wrote:

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

Signed-off-by: Khem Raj 
Cc: Mingli Yu 
---
v2: Fix commit msg format
v3: Apply suggestion from 
https://github.com/WebKit/WebKit/pull/1233#discussion_r915217428

   ...44e17d258106617b0e6d783d073b188a2548.patch | 296 ++
   meta/recipes-sato/webkit/webkitgtk_2.36.7.bb  |   1 +
   2 files changed, 297 insertions(+)
   create mode 100644 
meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch

diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
 
b/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
new file mode 100644
index 00..32f92f7ff5
--- /dev/null
+++ 
b/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
@@ -0,0 +1,296 @@
+From 0d3344e17d258106617b0e6d783d073b188a2548 Mon Sep 17 00:00:00 2001
+From: Adrian Perez de Castro 
+Date: Thu, 2 Jun 2022 11:19:06 +0300
+Subject: [PATCH] [ARM][NEON] FELightningNEON.cpp fails to build, NEON fast
+ path seems unused https://bugs.webkit.org/show_bug.cgi?id=241182
+
+Reviewed by NOBODY (OOPS!).
+
+Move the NEON fast path for the SVG lighting filter effects into
+FELightingSoftwareApplier, and arrange to actually use them by
+forwarding calls to applyPlatformGeneric() into applyPlatformNeon().
+
+Some changes were needed to adapt platformApplyNeon() to the current
+state of filters after r286140. This was not detected because the code
+bitrotted due to it being guarded with CPU(ARM_TRADITIONAL), which does
+not get used much these days: CPU(ARM_THUMB2) is more common. It should
+be possible to use the NEON fast paths also in Thumb mode, but that is
+left for a follow-up fix.
+
+* Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:
+(WebCore::FELightingSoftwareApplier::platformApplyNeonWorker):
+(WebCore::FELightingSoftwareApplier::getPowerCoefficients):
+(WebCore::FELighting::platformApplyNeonWorker): Deleted.
+(WebCore::FELighting::getPowerCoefficients): Deleted.
+* Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.h:
+(WebCore::FELightingSoftwareApplier::applyPlatformNeon):
+(WebCore::FELighting::platformApplyNeon): Deleted.
+* Source/WebCore/platform/graphics/filters/DistantLightSource.h:
+* Source/WebCore/platform/graphics/filters/FELighting.h:
+* Source/WebCore/platform/graphics/filters/PointLightSource.h:
+* Source/WebCore/platform/graphics/filters/SpotLightSource.h:
+* 
Source/WebCore/platform/graphics/filters/software/FELightingSoftwareApplier.h:
+---
+Upstream-Status: Submitted [https://github.com/WebKit/WebKit/pull/1233]
+Signed-off-by: Khem Raj 
+
+ .../cpu/arm/filters/FELightingNEON.cpp|  4 +-
+ .../graphics/cpu/arm/filters/FELightingNEON.h | 54 +--
+ .../graphics/filters/DistantLightSource.h |  4 ++
+ .../platform/graphics/filters/FELighting.h|  7 ---
+ .../graphics/filters/PointLightSource.h   |  4 ++
+ .../graphics/filters/SpotLightSource.h|  4 ++
+ .../software/FELightingSoftwareApplier.h  | 16 ++
+ 7 files changed, 57 insertions(+), 36 deletions(-)
+
+--- a/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp
 b/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp
+@@ -49,7 +49,7 @@ short* feLightingConstantsForNeon()
+ return s_FELightingConstantsForNeon;
+ }
+
+-void FELighting::platformApplyNeonWorker(FELightingPaintingDataForNeon* 
parameters)
++void 
FELightingSoftwareApplier::platformApplyNeonWorker(FELightingPaintingDataForNeon*
 parameters)
+ {
+ neonDrawLighting(parameters);
+ }
+@@ -464,7 +464,7 @@ TOSTRING(neonDrawLighting) ":" NL
+ "b .lightStrengthCalculated" NL
+ ); // NOLINT
+
+-int FELighting::getPowerCoefficients(float exponent)
++int FELightingSoftwareApplier::getPowerCoefficients(float exponent)
+ {
+

Re: [OE-core] [PATCH 1/7] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid

[Alexander Kanavin]

Hello,

this is done for reasons of discoverability and consistency with
machine and distro definitions: they all should be under
meta-somelayer/conf/. This way both tools and humans can easily find
the config templates, and be certain that this is the only location..

Alex

On Wed, 14 Sept 2022 at 05:27, ChenQi  wrote:
>
> Hi Alex,
>
> Why must TEMPLATECONF be under a layer?
>
> Regards,
> Qi
>
> On 8/31/22 19:13, Alexander Kanavin wrote:
> > specifically that ../../layer.conf exists, and that second-from-last
> > component in the path is 'templates'.
> >
> > This requires tweaking template.conf creation in eSDK bbclass, as
> > we need to ensure that the path in it is valid, and exists
> > (which may not be the case if the SDK is poky-based).
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >   meta/classes-recipe/populate_sdk_ext.bbclass | 3 ++-
> >   scripts/oe-setup-builddir| 5 +
> >   2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass 
> > b/meta/classes-recipe/populate_sdk_ext.bbclass
> > index 56e24c4eed..925cb313fc 100644
> > --- a/meta/classes-recipe/populate_sdk_ext.bbclass
> > +++ b/meta/classes-recipe/populate_sdk_ext.bbclass
> > @@ -438,7 +438,8 @@ python copy_buildsystem () {
> >   else:
> >   # Write a templateconf.cfg
> >   with open(baseoutpath + '/conf/templateconf.cfg', 'w') as f:
> > -f.write('meta/conf\n')
> > +f.write('meta/conf/templates/default\n')
> > +os.makedirs(os.path.join(baseoutpath, core_meta_subdir, 
> > 'conf/templates/default'), exist_ok=True)
> >
> >   # Ensure any variables set from the external environment (by way of
> >   # BB_ENV_PASSTHROUGH_ADDITIONS) are set in the SDK's configuration
> > diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
> > index 5d644168cb..bf832ee0ca 100755
> > --- a/scripts/oe-setup-builddir
> > +++ b/scripts/oe-setup-builddir
> > @@ -61,6 +61,11 @@ if [ -n "$TEMPLATECONF" ]; then
> >   echo >&2 "Error: TEMPLATECONF value points to nonexistent 
> > directory '$TEMPLATECONF'"
> >   exit 1
> >   fi
> > +templatesdir=$(python3 -c "import sys; 
> > print(sys.argv[1].strip('/').split('/')[-2])" $TEMPLATECONF)
> > +if [ ! -f "$TEMPLATECONF/../../layer.conf" -o $templatesdir != 
> > "templates" ]; then
> > +echo >&2 "Error: TEMPLATECONF value (which is $TEMPLATECONF) 
> > must point to meta-some-layer/conf/templates/template-name"
> > +exit 1
> > +fi
> >   fi
> >   OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample"
> >   OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170631): 
https://lists.openembedded.org/g/openembedded-core/message/170631
Mute This Topic: https://lists.openembedded.org/mt/93368468/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/7] scripts/oe-setup-builddir: add a check that TEMPLATECONF is valid

[Chen Qi]

Hi Alex,

Why must TEMPLATECONF be under a layer?

Regards,
Qi

On 8/31/22 19:13, Alexander Kanavin wrote:

specifically that ../../layer.conf exists, and that second-from-last
component in the path is 'templates'.

This requires tweaking template.conf creation in eSDK bbclass, as
we need to ensure that the path in it is valid, and exists
(which may not be the case if the SDK is poky-based).

Signed-off-by: Alexander Kanavin 
---
  meta/classes-recipe/populate_sdk_ext.bbclass | 3 ++-
  scripts/oe-setup-builddir| 5 +
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass 
b/meta/classes-recipe/populate_sdk_ext.bbclass
index 56e24c4eed..925cb313fc 100644
--- a/meta/classes-recipe/populate_sdk_ext.bbclass
+++ b/meta/classes-recipe/populate_sdk_ext.bbclass
@@ -438,7 +438,8 @@ python copy_buildsystem () {
  else:
  # Write a templateconf.cfg
  with open(baseoutpath + '/conf/templateconf.cfg', 'w') as f:
-f.write('meta/conf\n')
+f.write('meta/conf/templates/default\n')
+os.makedirs(os.path.join(baseoutpath, core_meta_subdir, 
'conf/templates/default'), exist_ok=True)
  
  # Ensure any variables set from the external environment (by way of

  # BB_ENV_PASSTHROUGH_ADDITIONS) are set in the SDK's configuration
diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index 5d644168cb..bf832ee0ca 100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -61,6 +61,11 @@ if [ -n "$TEMPLATECONF" ]; then
  echo >&2 "Error: TEMPLATECONF value points to nonexistent directory 
'$TEMPLATECONF'"
  exit 1
  fi
+templatesdir=$(python3 -c "import sys; 
print(sys.argv[1].strip('/').split('/')[-2])" $TEMPLATECONF)
+if [ ! -f "$TEMPLATECONF/../../layer.conf" -o $templatesdir != 
"templates" ]; then
+echo >&2 "Error: TEMPLATECONF value (which is $TEMPLATECONF) must point 
to meta-some-layer/conf/templates/template-name"
+exit 1
+fi
  fi
  OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample"
  OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170630): 
https://lists.openembedded.org/g/openembedded-core/message/170630
Mute This Topic: https://lists.openembedded.org/mt/93368468/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] busybox: add devmem 128-bit support

[Yu, Mingli]

From: Mingli Yu 

Add devmem 128-bit support [1].

[1] 
https://git.busybox.net/busybox/commit/?id=d432049f288c9acdc4a7caa729c68ceba3c5dca1

Signed-off-by: Mingli Yu 
---
 .../0001-devmem-add-128-bit-width.patch   | 128 ++
 meta/recipes-core/busybox/busybox_1.35.0.bb   |   1 +
 2 files changed, 129 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-width.patch

diff --git 
a/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-width.patch 
b/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-width.patch
new file mode 100644
index 00..985e2bf1d9
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/0001-devmem-add-128-bit-width.patch
@@ -0,0 +1,128 @@
+From d432049f288c9acdc4a7caa729c68ceba3c5dca1 Mon Sep 17 00:00:00 2001
+From: Aaro Koskinen 
+Date: Thu, 25 Aug 2022 18:47:02 +0300
+Subject: [PATCH] devmem: add 128-bit width
+
+Add 128-bit width if the compiler provides the needed type.
+
+function old new   delta
+devmem_main  405 464 +59
+.rodata   109025  109043 +18
+--
+(add/remove: 0/0 grow/shrink: 2/0 up/down: 77/0)   Total: 77 bytes
+
+Upstream-Status: Backport 
[https://git.busybox.net/busybox/commit/?id=d432049f288c9acdc4a7caa729c68ceba3c5dca1]
+
+Signed-off-by: Aaro Koskinen 
+Signed-off-by: Aaro Koskinen 
+Signed-off-by: Denys Vlasenko 
+Signed-off-by: Mingli Yu 
+---
+ miscutils/devmem.c | 68 ++
+ 1 file changed, 44 insertions(+), 24 deletions(-)
+
+diff --git a/miscutils/devmem.c b/miscutils/devmem.c
+index f9f0276bc..f21621bd6 100644
+--- a/miscutils/devmem.c
 b/miscutils/devmem.c
+@@ -29,7 +29,6 @@ int devmem_main(int argc UNUSED_PARAM, char **argv)
+ {
+   void *map_base, *virt_addr;
+   uint64_t read_result;
+-  uint64_t writeval = writeval; /* for compiler */
+   off_t target;
+   unsigned page_size, mapped_size, offset_in_page;
+   int fd;
+@@ -64,9 +63,6 @@ int devmem_main(int argc UNUSED_PARAM, char **argv)
+   width = strchrnul(bhwl, (argv[2][0] | 0x20)) - bhwl;
+   width = sizes[width];
+   }
+-  /* VALUE */
+-  if (argv[3])
+-  writeval = bb_strtoull(argv[3], NULL, 0);
+   } else { /* argv[2] == NULL */
+   /* make argv[3] to be a valid thing to fetch */
+   argv--;
+@@ -96,28 +92,46 @@ int devmem_main(int argc UNUSED_PARAM, char **argv)
+   virt_addr = (char*)map_base + offset_in_page;
+ 
+   if (!argv[3]) {
+-  switch (width) {
+-  case 8:
+-  read_result = *(volatile uint8_t*)virt_addr;
+-  break;
+-  case 16:
+-  read_result = *(volatile uint16_t*)virt_addr;
+-  break;
+-  case 32:
+-  read_result = *(volatile uint32_t*)virt_addr;
+-  break;
+-  case 64:
+-  read_result = *(volatile uint64_t*)virt_addr;
+-  break;
+-  default:
+-  bb_simple_error_msg_and_die("bad width");
++#ifdef __SIZEOF_INT128__
++  if (width == 128) {
++  unsigned __int128 rd =
++  *(volatile unsigned __int128 *)virt_addr;
++  printf("0x%016llX%016llX\n",
++  (unsigned long long)(uint64_t)(rd >> 64),
++  (unsigned long long)(uint64_t)rd
++  );
++  } else
++#endif
++  {
++  switch (width) {
++  case 8:
++  read_result = *(volatile uint8_t*)virt_addr;
++  break;
++  case 16:
++  read_result = *(volatile uint16_t*)virt_addr;
++  break;
++  case 32:
++  read_result = *(volatile uint32_t*)virt_addr;
++  break;
++  case 64:
++  read_result = *(volatile uint64_t*)virt_addr;
++  break;
++  default:
++  bb_simple_error_msg_and_die("bad width");
++  }
++//printf("Value at address 0x%"OFF_FMT"X (%p): 0x%llX\n",
++//target, virt_addr,
++//(unsigned long long)read_result);
++  /* Zero-padded output shows the width of access just 
done */
++  printf("0x%0*llX\n", (width >> 2), (unsigned long 

Re: [OE-core] [PATCH v3] webkitgtk: Fix build on 32bit arm

[Khem Raj]

On Tue, Sep 13, 2022 at 7:25 PM Yu, Mingli  wrote:
>
> Still failed on beaglebone-yocto:
>
> /build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/webkitgtk/2.36.7-r0/webkitgtk-2.36.7/Source/W
> ebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:38:8: error:
> standard attributes in middle of decl-specifiers
> 38 | static alignas(16) short s_FELightingConstantsForNeon[] = {
>|^~~
>

What is your -j value ? please give 4GB per core of memory for
webkitgtk to build.

> Thanks,
>
> On 9/9/22 05:45, Khem Raj wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > Signed-off-by: Khem Raj 
> > Cc: Mingli Yu 
> > ---
> > v2: Fix commit msg format
> > v3: Apply suggestion from 
> > https://github.com/WebKit/WebKit/pull/1233#discussion_r915217428
> >
> >   ...44e17d258106617b0e6d783d073b188a2548.patch | 296 ++
> >   meta/recipes-sato/webkit/webkitgtk_2.36.7.bb  |   1 +
> >   2 files changed, 297 insertions(+)
> >   create mode 100644 
> > meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> >
> > diff --git 
> > a/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> >  
> > b/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> > new file mode 100644
> > index 00..32f92f7ff5
> > --- /dev/null
> > +++ 
> > b/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> > @@ -0,0 +1,296 @@
> > +From 0d3344e17d258106617b0e6d783d073b188a2548 Mon Sep 17 00:00:00 2001
> > +From: Adrian Perez de Castro 
> > +Date: Thu, 2 Jun 2022 11:19:06 +0300
> > +Subject: [PATCH] [ARM][NEON] FELightningNEON.cpp fails to build, NEON fast
> > + path seems unused https://bugs.webkit.org/show_bug.cgi?id=241182
> > +
> > +Reviewed by NOBODY (OOPS!).
> > +
> > +Move the NEON fast path for the SVG lighting filter effects into
> > +FELightingSoftwareApplier, and arrange to actually use them by
> > +forwarding calls to applyPlatformGeneric() into applyPlatformNeon().
> > +
> > +Some changes were needed to adapt platformApplyNeon() to the current
> > +state of filters after r286140. This was not detected because the code
> > +bitrotted due to it being guarded with CPU(ARM_TRADITIONAL), which does
> > +not get used much these days: CPU(ARM_THUMB2) is more common. It should
> > +be possible to use the NEON fast paths also in Thumb mode, but that is
> > +left for a follow-up fix.
> > +
> > +* Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:
> > +(WebCore::FELightingSoftwareApplier::platformApplyNeonWorker):
> > +(WebCore::FELightingSoftwareApplier::getPowerCoefficients):
> > +(WebCore::FELighting::platformApplyNeonWorker): Deleted.
> > +(WebCore::FELighting::getPowerCoefficients): Deleted.
> > +* Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.h:
> > +(WebCore::FELightingSoftwareApplier::applyPlatformNeon):
> > +(WebCore::FELighting::platformApplyNeon): Deleted.
> > +* Source/WebCore/platform/graphics/filters/DistantLightSource.h:
> > +* Source/WebCore/platform/graphics/filters/FELighting.h:
> > +* Source/WebCore/platform/graphics/filters/PointLightSource.h:
> > +* Source/WebCore/platform/graphics/filters/SpotLightSource.h:
> > +* 
> > Source/WebCore/platform/graphics/filters/software/FELightingSoftwareApplier.h:
> > +---
> > +Upstream-Status: Submitted [https://github.com/WebKit/WebKit/pull/1233]
> > +Signed-off-by: Khem Raj 
> > +
> > + .../cpu/arm/filters/FELightingNEON.cpp|  4 +-
> > + .../graphics/cpu/arm/filters/FELightingNEON.h | 54 +--
> > + .../graphics/filters/DistantLightSource.h |  4 ++
> > + .../platform/graphics/filters/FELighting.h|  7 ---
> > + .../graphics/filters/PointLightSource.h   |  4 ++
> > + .../graphics/filters/SpotLightSource.h|  4 ++
> > + .../software/FELightingSoftwareApplier.h  | 16 ++
> > + 7 files changed, 57 insertions(+), 36 deletions(-)
> > +
> > +--- a/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp
> >  b/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp
> > +@@ -49,7 +49,7 @@ short* feLightingConstantsForNeon()
> > + return s_FELightingConstantsForNeon;
> > + }
> > +
> > +-void FELighting::platformApplyNeonWorker(FELightingPaintingDataForNeon* 
> > parameters)
> > ++void 
> > FELightingSoftwareApplier::platformApplyNeonWorker(FELightingPaintingDataForNeon*
> >  parameters)
> > + {
> > + neonDrawLighting(parameters);
> > + }
> > +@@ -464,7 +464,7 @@ TOSTRING(neonDrawLighting) ":" NL
> > + "b .lightStrengthCalculated" NL
> > + ); // NOLINT
> > +
> > +-int FELighting::getPowerCoefficients(float exponent)
> > ++int FELightingSoftwareApplier::getPowerCoefficients(float exponent)
> > + {
> > + // Calling a powf function from the assembly code would require to 
> > save
> > + // and reload a lot of NEON registers. Since the base is in range 
> > [0..1]
> > +--- 

[OE-core][dunfell 9/9] binutils : CVE-2022-38533

[Steve Sakoman]

From: Florin Diaconescu 

Upstream-Status: Backport
[https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ef186fe54aa6d281a3ff8a9528417e5cc614c797]

Signed-off-by: Florin Diaconescu 
Signed-off-by: Steve Sakoman 
---
 .../binutils/binutils-2.34.inc|  1 +
 .../binutils/binutils/CVE-2022-38533.patch| 37 +++
 2 files changed, 38 insertions(+)
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.34.inc 
b/meta/recipes-devtools/binutils/binutils-2.34.inc
index 6a55de2d45..ff0d467132 100644
--- a/meta/recipes-devtools/binutils/binutils-2.34.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.34.inc
@@ -52,5 +52,6 @@ SRC_URI = "\
  file://CVE-2021-3549.patch \
  file://CVE-2020-16593.patch \
  file://0001-CVE-2021-45078.patch \
+ file://CVE-2022-38533.patch \
 "
 S  = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch
new file mode 100644
index 00..102d65f8a6
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch
@@ -0,0 +1,37 @@
+From ef186fe54aa6d281a3ff8a9528417e5cc614c797 Mon Sep 17 00:00:00 2001
+From: Alan Modra 
+Date: Sat, 13 Aug 2022 15:32:47 +0930
+Subject: [PATCH] PR29482 - strip: heap-buffer-overflow
+
+   PR 29482
+   * coffcode.h (coff_set_section_contents): Sanity check _LIB.
+
+CVE: CVE-2022-38533
+Upstream-Status: Backport 
[https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ef186fe54aa6d281a3ff8a9528417e5cc614c797]
+
+Signed-off-by: Florin Diaconescu 
+
+---
+ bfd/coffcode.h | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/bfd/coffcode.h b/bfd/coffcode.h
+index dec2e9c6370..75c18d88602 100644
+--- a/bfd/coffcode.h
 b/bfd/coffcode.h
+@@ -4170,10 +4170,13 @@ coff_set_section_contents (bfd * abfd,
+ 
+   rec = (bfd_byte *) location;
+   recend = rec + count;
+-  while (rec < recend)
++  while (recend - rec >= 4)
+ {
++  size_t len = bfd_get_32 (abfd, rec);
++  if (len == 0 || len > (size_t) (recend - rec) / 4)
++break;
++  rec += len * 4;
+   ++section->lma;
+-  rec += bfd_get_32 (abfd, rec) * 4;
+ }
+ 
+   BFD_ASSERT (rec == recend);
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170627): 
https://lists.openembedded.org/g/openembedded-core/message/170627
Mute This Topic: https://lists.openembedded.org/mt/93670485/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 8/9] systemd: Add 'no-dns-fallback' PACKAGECONFIG option

[Steve Sakoman]

From: "niko.ma...@vaisala.com" 

systemd defines a default set of fallback DNS servers in
https://github.com/systemd/systemd/blob/v251/meson_options.txt#L328-L330

By adding a PACKAGECONFIG knob providing a convenient way to opt out,
and then adding that value to systemd's PACKAGECONFIG, the output from
runtime 'resolvectl status' command no longer contains the following
line:

  Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 
1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 
2606:4700:4700::#cloudflare-dns.com 2001:4860:4860::#dns.google 
2606:4700:4700::1001#cloudflare-dns.com 2001:4860:4860::8844#dns.google

(From OE-Core rev: 2b300d6b9ec6288a99d9dacb24a86949caf99e55)

Signed-off-by: Niko Mauno 
Signed-off-by: Richard Purdie 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-core/systemd/systemd_244.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_244.5.bb 
b/meta/recipes-core/systemd/systemd_244.5.bb
index a648272bc0..f3e5395465 100644
--- a/meta/recipes-core/systemd/systemd_244.5.bb
+++ b/meta/recipes-core/systemd/systemd_244.5.bb
@@ -162,6 +162,7 @@ PACKAGECONFIG[manpages] = 
"-Dman=true,-Dman=false,libxslt-native xmlto-native do
 PACKAGECONFIG[microhttpd] = 
"-Dmicrohttpd=true,-Dmicrohttpd=false,libmicrohttpd"
 PACKAGECONFIG[myhostname] = 
"-Dnss-myhostname=true,-Dnss-myhostname=false,,libnss-myhostname"
 PACKAGECONFIG[networkd] = "-Dnetworkd=true,-Dnetworkd=false"
+PACKAGECONFIG[no-dns-fallback] = "-Ddns-servers="
 PACKAGECONFIG[nss] = "-Dnss-systemd=true,-Dnss-systemd=false"
 PACKAGECONFIG[nss-mymachines] = "-Dnss-mymachines=true,-Dnss-mymachines=false"
 PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170626): 
https://lists.openembedded.org/g/openembedded-core/message/170626
Mute This Topic: https://lists.openembedded.org/mt/93670484/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 7/9] systemd: Fix unwritable /var/lock when no sysvinit handling

[Steve Sakoman]

From: "niko.ma...@vaisala.com" 

Commit 8089cefed8e83c0348037768c292058f1bcbbbe5 ("systemd: Add
PACKAGECONFIG for sysvinit") decoupled enabling of systemd's sysvinit
handling behavior behind a distinct PACKAGECONFIG feature.

This new option affects among other things the installing of
tmpfiles.d/legacy.conf, which is responsible for creating /run/lock
directory, which is pointed to by /var/lock symlink provided by
base-files package.

In case the option is not enabled, then base-files provided /var/lock
is a dangling symlink on resulting rootfs, causing problems with
certain Linux userspace components that rely on existence of writable
/var/lock directory. As an example:

  # fw_printenv
  Error opening lock file /var/lock/fw_printenv.lock

Since Filesystem Hierarchy Standard Version 3.0 states in
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s09.html that

  Lock files should be stored within the /var/lock directory structure.

Ensure the /run/lock directory is always created, so that lock files
can be stored under /var/lock also when 'sysvinit' handling is
disabled.

(From OE-Core rev: 85e5ee2c35cf5778c3aefda45f526e8f6a511131)

Signed-off-by: Niko Mauno 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-core/systemd/systemd/00-create-volatile.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd/00-create-volatile.conf 
b/meta/recipes-core/systemd/systemd/00-create-volatile.conf
index 87cbe1e7d3..c4277221a2 100644
--- a/meta/recipes-core/systemd/systemd/00-create-volatile.conf
+++ b/meta/recipes-core/systemd/systemd/00-create-volatile.conf
@@ -3,5 +3,6 @@
 # inside /var/log.
 
 
+d  /run/lock   1777-   -   -
 d  /var/volatile/log   -   -   -   -
 d  /var/volatile/tmp   1777-   -
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170625): 
https://lists.openembedded.org/g/openembedded-core/message/170625
Mute This Topic: https://lists.openembedded.org/mt/93670483/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 6/9] virglrenderer: fix CVE-2022-0135

[Steve Sakoman]

From: Chee Yang Lee 

Signed-off-by: Chee Yang Lee 
Signed-off-by: Steve Sakoman 
---
 .../virglrenderer/CVE-2022-0135.patch | 100 ++
 .../virglrenderer/virglrenderer_0.8.2.bb  |   1 +
 2 files changed, 101 insertions(+)
 create mode 100644 
meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2022-0135.patch

diff --git 
a/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2022-0135.patch 
b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2022-0135.patch
new file mode 100644
index 00..4a277bd4d0
--- /dev/null
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2022-0135.patch
@@ -0,0 +1,100 @@
+From 95e581fd181b213c2ed7cdc63f2abc03eaaa77ec Mon Sep 17 00:00:00 2001
+From: Gert Wollny 
+Date: Tue, 30 Nov 2021 10:17:26 +0100
+Subject: [PATCH] vrend: Add test to resource OOB write and fix it
+
+v2: Also check that no depth != 1 has been send when none is due
+
+Closes: #250
+Signed-off-by: Gert Wollny 
+Reviewed-by: Chia-I Wu 
+
+https://gitlab.freedesktop.org/virgl/virglrenderer/-/commit/95e581fd181b213c2ed7cdc63f2abc03eaaa77ec
+Upstream-Status: Backport
+CVE: CVE-2022-0135
+Signed-off-by: Chee Yang Lee 
+---
+ src/vrend_renderer.c|  3 +++
+ tests/test_fuzzer_formats.c | 43 +
+ 2 files changed, 46 insertions(+)
+
+diff --git a/src/vrend_renderer.c b/src/vrend_renderer.c
+index 28f669727..357b81b20 100644
+--- a/src/vrend_renderer.c
 b/src/vrend_renderer.c
+@@ -7833,8 +7833,11 @@ static int vrend_renderer_transfer_write_iov(struct 
vrend_context *ctx,
+   info->box->height) * elsize;
+   if (res->target == GL_TEXTURE_3D ||
+   res->target == GL_TEXTURE_2D_ARRAY ||
++  res->target == GL_TEXTURE_2D_MULTISAMPLE_ARRAY ||
+   res->target == GL_TEXTURE_CUBE_MAP_ARRAY)
+   send_size *= info->box->depth;
++  else if (need_temp && info->box->depth != 1)
++ return EINVAL;
+ 
+   if (need_temp) {
+  data = malloc(send_size);
+diff --git a/tests/test_fuzzer_formats.c b/tests/test_fuzzer_formats.c
+index 59d6fb671..2de9a9a3f 100644
+--- a/tests/test_fuzzer_formats.c
 b/tests/test_fuzzer_formats.c
+@@ -957,6 +957,48 @@ static void test_vrend_set_signle_abo_heap_overflow() {
+ virgl_renderer_submit_cmd((void *) cmd, ctx_id, 0xde);
+ }
+ 
++/* Test adapted from yaojun8558...@gmail.com:
++ * https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/250
++*/
++static void test_vrend_3d_resource_overflow() {
++
++struct virgl_renderer_resource_create_args resource;
++resource.handle = 0x4c474572;
++resource.target = PIPE_TEXTURE_2D_ARRAY;
++resource.format = VIRGL_FORMAT_Z24X8_UNORM;
++resource.nr_samples = 2;
++resource.last_level = 0;
++resource.array_size = 3;
++resource.bind = VIRGL_BIND_SAMPLER_VIEW;
++resource.depth = 1;
++resource.width = 8;
++resource.height = 4;
++resource.flags = 0;
++
++virgl_renderer_resource_create(, NULL, 0);
++virgl_renderer_ctx_attach_resource(ctx_id, resource.handle);
++
++uint32_t size = 0x400;
++uint32_t cmd[size];
++int i = 0;
++cmd[i++] = (size - 1) << 16 | 0 << 8 | VIRGL_CCMD_RESOURCE_INLINE_WRITE;
++cmd[i++] = resource.handle;
++cmd[i++] = 0; // level
++cmd[i++] = 0; // usage
++cmd[i++] = 0; // stride
++cmd[i++] = 0; // layer_stride
++cmd[i++] = 0; // x
++cmd[i++] = 0; // y
++cmd[i++] = 0; // z
++cmd[i++] = 8; // w
++cmd[i++] = 4; // h
++cmd[i++] = 3; // d
++memset([i], 0, size - i);
++
++virgl_renderer_submit_cmd((void *) cmd, ctx_id, size);
++}
++
++
+ int main()
+ {
+initialize_environment();
+@@ -979,6 +1021,7 @@ int main()
+test_cs_nullpointer_deference();
+test_vrend_set_signle_abo_heap_overflow();
+ 
++   test_vrend_3d_resource_overflow();
+ 
+virgl_renderer_context_destroy(ctx_id);
+virgl_renderer_cleanup();
+-- 
+GitLab
+
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb 
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 31c45ef89c..8185d6f7e8 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -13,6 +13,7 @@ SRCREV = "7d204f3927be65fb3365dce01dbcd04d447a4985"
 SRC_URI = "git://anongit.freedesktop.org/git/virglrenderer;branch=master \
file://0001-gallium-Expand-libc-check-to-be-platform-OS-check.patch 
\
file://0001-meson.build-use-python3-directly-for-python.patch \
+   file://CVE-2022-0135.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170624): 
https://lists.openembedded.org/g/openembedded-core/message/170624
Mute This Topic: https://lists.openembedded.org/mt/93670482/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: 

[OE-core][dunfell 5/9] gnutls: fix CVE-2021-4209

[Steve Sakoman]

From: Chee Yang Lee 

Signed-off-by: Chee Yang Lee 
Signed-off-by: Steve Sakoman 
---
 .../gnutls/gnutls/CVE-2021-4209.patch | 37 +++
 meta/recipes-support/gnutls/gnutls_3.6.14.bb  |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 meta/recipes-support/gnutls/gnutls/CVE-2021-4209.patch

diff --git a/meta/recipes-support/gnutls/gnutls/CVE-2021-4209.patch 
b/meta/recipes-support/gnutls/gnutls/CVE-2021-4209.patch
new file mode 100644
index 00..0bcb55e573
--- /dev/null
+++ b/meta/recipes-support/gnutls/gnutls/CVE-2021-4209.patch
@@ -0,0 +1,37 @@
+From 3db352734472d851318944db13be73da61300568 Mon Sep 17 00:00:00 2001
+From: Daiki Ueno 
+Date: Wed, 22 Dec 2021 09:12:25 +0100
+Subject: [PATCH] wrap_nettle_hash_fast: avoid calling _update with zero-length
+ input
+
+As Nettle's hash update functions internally call memcpy, providing
+zero-length input may cause undefined behavior.
+
+Signed-off-by: Daiki Ueno 
+
+https://gitlab.com/gnutls/gnutls/-/commit/3db352734472d851318944db13be73da61300568
+Upstream-Status: Backport
+CVE: CVE-2021-4209
+Signed-off-by: Chee Yang Lee 
+---
+ lib/nettle/mac.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/lib/nettle/mac.c b/lib/nettle/mac.c
+index f9d4d7a8df..35e070fab0 100644
+--- a/lib/nettle/mac.c
 b/lib/nettle/mac.c
+@@ -788,7 +788,9 @@ static int wrap_nettle_hash_fast(gnutls_digest_algorithm_t 
algo,
+   if (ret < 0)
+   return gnutls_assert_val(ret);
+ 
+-  ctx.update(, text_size, text);
++  if (text_size > 0) {
++  ctx.update(, text_size, text);
++  }
+   ctx.digest(, ctx.length, digest);
+ 
+   return 0;
+-- 
+GitLab
+
diff --git a/meta/recipes-support/gnutls/gnutls_3.6.14.bb 
b/meta/recipes-support/gnutls/gnutls_3.6.14.bb
index e9af71c7bd..f1757871ce 100644
--- a/meta/recipes-support/gnutls/gnutls_3.6.14.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.6.14.bb
@@ -26,6 +26,7 @@ SRC_URI = 
"https://www.gnupg.org/ftp/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar
file://CVE-2021-20231.patch \
file://CVE-2021-20232.patch \
file://CVE-2022-2509.patch \
+   file://CVE-2021-4209.patch \
 "
 
 SRC_URI[sha256sum] = 
"5630751adec7025b8ef955af4d141d00d252a985769f51b4059e5affa3d39d63"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170623): 
https://lists.openembedded.org/g/openembedded-core/message/170623
Mute This Topic: https://lists.openembedded.org/mt/93670481/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 4/9] connman: fix CVE-2022-32292

[Steve Sakoman]

From: Chee Yang Lee 

Signed-off-by: Chee Yang Lee 
Signed-off-by: Steve Sakoman 
---
 .../connman/connman/CVE-2022-32292.patch  | 37 +++
 .../connman/connman_1.37.bb   |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 
meta/recipes-connectivity/connman/connman/CVE-2022-32292.patch

diff --git a/meta/recipes-connectivity/connman/connman/CVE-2022-32292.patch 
b/meta/recipes-connectivity/connman/connman/CVE-2022-32292.patch
new file mode 100644
index 00..74a739d6a2
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman/CVE-2022-32292.patch
@@ -0,0 +1,37 @@
+From d1a5ede5d255bde8ef707f8441b997563b9312bd Mon Sep 17 00:00:00 2001
+From: Nathan Crandall 
+Date: Tue, 12 Jul 2022 08:56:34 +0200
+Subject: gweb: Fix OOB write in received_data()
+
+There is a mismatch of handling binary vs. C-string data with memchr
+and strlen, resulting in pos, count, and bytes_read to become out of
+sync and result in a heap overflow.  Instead, do not treat the buffer
+as an ASCII C-string. We calculate the count based on the return value
+of memchr, instead of strlen.
+
+Fixes: CVE-2022-32292
+
+Upstream-Status: Backport
+https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=d1a5ede5d255bde8ef707f8441b997563b9312b
+CVE: CVE-2022-32292
+Signed-off-by: Lee Chee Yang 
+---
+ gweb/gweb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gweb/gweb.c b/gweb/gweb.c
+index 12fcb1d8..13c6c5f2 100644
+--- a/gweb/gweb.c
 b/gweb/gweb.c
+@@ -918,7 +918,7 @@ static gboolean received_data(GIOChannel *channel, 
GIOCondition cond,
+   }
+ 
+   *pos = '\0';
+-  count = strlen((char *) ptr);
++  count = pos - ptr;
+   if (count > 0 && ptr[count - 1] == '\r') {
+   ptr[--count] = '\0';
+   bytes_read--;
+-- 
+cgit 
+
diff --git a/meta/recipes-connectivity/connman/connman_1.37.bb 
b/meta/recipes-connectivity/connman/connman_1.37.bb
index bdd1e590ec..4f22c7ad49 100644
--- a/meta/recipes-connectivity/connman/connman_1.37.bb
+++ b/meta/recipes-connectivity/connman/connman_1.37.bb
@@ -12,6 +12,7 @@ SRC_URI  = 
"${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
 file://CVE-2021-33833.patch \
 file://CVE-2022-23096-7.patch \
 file://CVE-2022-23098.patch \
+file://CVE-2022-32292.patch \
 "
 
 SRC_URI_append_libc-musl = " 
file://0002-resolve-musl-does-not-implement-res_ninit.patch"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170622): 
https://lists.openembedded.org/g/openembedded-core/message/170622
Mute This Topic: https://lists.openembedded.org/mt/93670480/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 3/9] tiff: Security fixes CVE-2022-1354 and CVE-2022-1355

[Steve Sakoman]

From: Yi Zhao 

References:
https://nvd.nist.gov/vuln/detail/CVE-2022-1354
https://security-tracker.debian.org/tracker/CVE-2022-1354

https://nvd.nist.gov/vuln/detail/CVE-2022-1355
https://security-tracker.debian.org/tracker/CVE-2022-1355

Patches from:

CVE-2022-1354:
https://gitlab.com/libtiff/libtiff/-/commit/87f580f39011109b3bb5f6eca13fac543a542798

CVE-2022-1355:
https://gitlab.com/libtiff/libtiff/-/commit/c1ae29f9ebacd29b7c3e0c7db671af7db3584bc2

(From OE-Core rev: 6c373c041f1dd45458866408d1ca16d47cacbd86)

Signed-off-by: Yi Zhao 
Signed-off-by: Steve Sakoman 
Signed-off-by: Richard Purdie 
Signed-off-by: Chee Yang Lee 
Signed-off-by: Steve Sakoman 
---
 .../libtiff/tiff/CVE-2022-1354.patch  | 212 ++
 .../libtiff/tiff/CVE-2022-1355.patch  |  62 +
 meta/recipes-multimedia/libtiff/tiff_4.1.0.bb |   2 +
 3 files changed, 276 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2022-1354.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2022-1355.patch

diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2022-1354.patch 
b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-1354.patch
new file mode 100644
index 00..71b85cac10
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2022-1354.patch
@@ -0,0 +1,212 @@
+From 87881e093691a35c60b91cafed058ba2dd5d9807 Mon Sep 17 00:00:00 2001
+From: Even Rouault 
+Date: Sun, 5 Dec 2021 14:37:46 +0100
+Subject: [PATCH] TIFFReadDirectory: fix OJPEG hack (fixes #319)
+
+to avoid having the size of the strip arrays inconsistent with the
+number of strips returned by TIFFNumberOfStrips(), which may cause
+out-ouf-bounds array read afterwards.
+
+One of the OJPEG hack that alters SamplesPerPixel may influence the
+number of strips. Hence compute tif_dir.td_nstrips only afterwards.
+
+CVE: CVE-2022-1354
+
+Upstream-Status: Backport
+[https://gitlab.com/libtiff/libtiff/-/commit/87f580f39011109b3bb5f6eca13fac543a542798]
+
+Signed-off-by: Yi Zhao 
+---
+ libtiff/tif_dirread.c | 162 ++
+ 1 file changed, 83 insertions(+), 79 deletions(-)
+
+diff --git a/libtiff/tif_dirread.c b/libtiff/tif_dirread.c
+index 8f434ef5..14c031d1 100644
+--- a/libtiff/tif_dirread.c
 b/libtiff/tif_dirread.c
+@@ -3794,50 +3794,7 @@ TIFFReadDirectory(TIFF* tif)
+   MissingRequired(tif,"ImageLength");
+   goto bad;
+   }
+-  /*
+-   * Setup appropriate structures (by strip or by tile)
+-   */
+-  if (!TIFFFieldSet(tif, FIELD_TILEDIMENSIONS)) {
+-  tif->tif_dir.td_nstrips = TIFFNumberOfStrips(tif);  
+-  tif->tif_dir.td_tilewidth = tif->tif_dir.td_imagewidth;
+-  tif->tif_dir.td_tilelength = tif->tif_dir.td_rowsperstrip;
+-  tif->tif_dir.td_tiledepth = tif->tif_dir.td_imagedepth;
+-  tif->tif_flags &= ~TIFF_ISTILED;
+-  } else {
+-  tif->tif_dir.td_nstrips = TIFFNumberOfTiles(tif);
+-  tif->tif_flags |= TIFF_ISTILED;
+-  }
+-  if (!tif->tif_dir.td_nstrips) {
+-  TIFFErrorExt(tif->tif_clientdata, module,
+-  "Cannot handle zero number of %s",
+-  isTiled(tif) ? "tiles" : "strips");
+-  goto bad;
+-  }
+-  tif->tif_dir.td_stripsperimage = tif->tif_dir.td_nstrips;
+-  if (tif->tif_dir.td_planarconfig == PLANARCONFIG_SEPARATE)
+-  tif->tif_dir.td_stripsperimage /= 
tif->tif_dir.td_samplesperpixel;
+-  if (!TIFFFieldSet(tif, FIELD_STRIPOFFSETS)) {
+-#ifdef OJPEG_SUPPORT
+-  if ((tif->tif_dir.td_compression==COMPRESSION_OJPEG) &&
+-  (isTiled(tif)==0) &&
+-  (tif->tif_dir.td_nstrips==1)) {
+-  /*
+-   * XXX: OJPEG hack.
+-   * If a) compression is OJPEG, b) it's not a tiled TIFF,
+-   * and c) the number of strips is 1,
+-   * then we tolerate the absence of stripoffsets tag,
+-   * because, presumably, all required data is in the
+-   * JpegInterchangeFormat stream.
+-   */
+-  TIFFSetFieldBit(tif, FIELD_STRIPOFFSETS);
+-  } else
+-#endif
+-{
+-  MissingRequired(tif,
+-  isTiled(tif) ? "TileOffsets" : "StripOffsets");
+-  goto bad;
+-  }
+-  }
++
+   /*
+* Second pass: extract other information.
+*/
+@@ -4042,41 +3999,6 @@ TIFFReadDirectory(TIFF* tif)
+   } /* -- if (!dp->tdir_ignore) */
+   } /* -- for-loop -- */
+ 
+-if( tif->tif_mode == O_RDWR &&
+-tif->tif_dir.td_stripoffset_entry.tdir_tag != 0 &&
+-tif->tif_dir.td_stripoffset_entry.tdir_count == 0 &&
+-tif->tif_dir.td_stripoffset_entry.tdir_type == 0 &&
+-

[OE-core][dunfell 2/9] tiff: Fix for CVE-2022-2867/8/9

[Steve Sakoman]

From: Virendra Thakur 

Add Patch to fix CVE-2022-2867, CVE-2022-2868
CVE-2022-2869

Signed-off-by: Virendra Thakur 
Signed-off-by: Steve Sakoman 
---
 ...022-2867-CVE-2022-2868-CVE-2022-2869.patch | 159 ++
 meta/recipes-multimedia/libtiff/tiff_4.1.0.bb |   1 +
 2 files changed, 160 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libtiff/files/CVE-2022-2867-CVE-2022-2868-CVE-2022-2869.patch

diff --git 
a/meta/recipes-multimedia/libtiff/files/CVE-2022-2867-CVE-2022-2868-CVE-2022-2869.patch
 
b/meta/recipes-multimedia/libtiff/files/CVE-2022-2867-CVE-2022-2868-CVE-2022-2869.patch
new file mode 100644
index 00..131ff94119
--- /dev/null
+++ 
b/meta/recipes-multimedia/libtiff/files/CVE-2022-2867-CVE-2022-2868-CVE-2022-2869.patch
@@ -0,0 +1,159 @@
+From 07d79fcac2ead271b60e32aeb80f7b4f3be9ac8c Mon Sep 17 00:00:00 2001
+From: Su Laus 
+Date: Wed, 9 Feb 2022 21:31:29 +
+Subject: [PATCH] tiffcrop.c: Fix issue #352 heap-buffer-overflow by correcting
+ uint32_t underflow.
+
+CVE: CVE-2022-2867 CVE-2022-2868 CVE-2022-2869
+Upstream-Status: Backport 
[https://gitlab.com/libtiff/libtiff/-/commit/07d79fcac2ead271b60e32aeb80f7b4f3be9ac8c]
+Signed-off-by: Virendra Thakur 
+---
+Index: tiff-4.1.0/tools/tiffcrop.c
+===
+--- tiff-4.1.0.orig/tools/tiffcrop.c
 tiff-4.1.0/tools/tiffcrop.c
+@@ -5153,29 +5153,45 @@ computeInputPixelOffsets(struct crop_mas
+   y1 = _TIFFClampDoubleToUInt32(crop->corners[i].Y1);
+   y2 = _TIFFClampDoubleToUInt32(crop->corners[i].Y2);
+   }
+-  if (x1 < 1)
+-crop->regionlist[i].x1 = 0;
+-  else
+-crop->regionlist[i].x1 = (uint32) (x1 - 1);
++  /* a) Region needs to be within image sizes 0.. width-1; 0..length-1 
++   * b) Corners are expected to be submitted as top-left to bottom-right.
++   *Therefore, check that and reorder input.
++   * (be aware x,y are already casted to (uint32_t) and avoid (0 - 1) )
++   */
++  uint32_t aux;
++  if (x1 > x2) {
++aux = x1;
++x1 = x2;
++x2 = aux;
++  }
++  if (y1 > y2) {
++aux = y1;
++y1 = y2;
++y2 = aux;
++  }
++  if (x1 > image->width - 1)
++crop->regionlist[i].x1 = image->width - 1;
++  else if (x1 > 0)
++crop->regionlist[i].x1 = (uint32_t)(x1 - 1);
+ 
+   if (x2 > image->width - 1)
+ crop->regionlist[i].x2 = image->width - 1;
+-  else
+-crop->regionlist[i].x2 = (uint32) (x2 - 1);
+-  zwidth  = crop->regionlist[i].x2 - crop->regionlist[i].x1 + 1; 
+-
+-  if (y1 < 1)
+-crop->regionlist[i].y1 = 0;
+-  else
+-crop->regionlist[i].y1 = (uint32) (y1 - 1);
++  else if (x2 > 0)
++crop->regionlist[i].x2 = (uint32_t)(x2 - 1);
++
++  zwidth = crop->regionlist[i].x2 - crop->regionlist[i].x1 + 1;
++
++  if (y1 > image->length - 1)
++crop->regionlist[i].y1 = image->length - 1;
++  else if (y1 > 0)
++crop->regionlist[i].y1 = (uint32_t)(y1 - 1);
+ 
+   if (y2 > image->length - 1)
+ crop->regionlist[i].y2 = image->length - 1;
+-  else
+-crop->regionlist[i].y2 = (uint32) (y2 - 1);
+-
+-  zlength = crop->regionlist[i].y2 - crop->regionlist[i].y1 + 1; 
++  else if (y2 > 0)
++crop->regionlist[i].y2 = (uint32_t)(y2 - 1);
+ 
++  zlength = crop->regionlist[i].y2 - crop->regionlist[i].y1 + 1;
+   if (zwidth > max_width)
+ max_width = zwidth;
+   if (zlength > max_length)
+@@ -5205,7 +5221,7 @@ computeInputPixelOffsets(struct crop_mas
+   }
+   }
+ return (0);
+-}
++}  /* crop_mode == CROP_REGIONS */
+   
+   /* Convert crop margins into offsets into image
+* Margins are expressed as pixel rows and columns, not bytes
+@@ -5241,7 +5257,7 @@ computeInputPixelOffsets(struct crop_mas
+   bmargin = (uint32) 0;
+   return (-1);
+   }
+-}
++}  /* crop_mode == CROP_MARGINS */
+   else
+ { /* no margins requested */
+ tmargin = (uint32) 0;
+@@ -5332,24 +5348,23 @@ computeInputPixelOffsets(struct crop_mas
+   off->endx   = endx;
+   off->endy   = endy;
+ 
+-  crop_width  = endx - startx + 1;
+-  crop_length = endy - starty + 1;
+-
+-  if (crop_width <= 0)
++  if (endx + 1 <= startx)
+ {
+ TIFFError("computeInputPixelOffsets", 
+"Invalid left/right margins and /or image crop width 
requested");
+ return (-1);
+ }
++  crop_width  = endx - startx + 1;
+   if (crop_width > image->width)
+ crop_width = image->width;
+ 
+-  if (crop_length <= 0)
++  if (endy + 1 <= starty)
+ {
+ TIFFError("computeInputPixelOffsets", 
+   "Invalid top/bottom margins and /or image crop length 
requested");
+ return (-1);
+ }
++  crop_length = endy - starty + 1;
+   if (crop_length > image->length)
+ crop_length = image->length;
+ 
+@@ -5449,10 +5464,17 @@ getCropOffsets(struct image_data *image,
+  

[OE-core][dunfell 1/9] python3: Fix CVE-2021-28861 for python3

[Steve Sakoman]

From: "k...@kpit.com" 

Add patch to fix CVE-2021-28861

CVE-2021-28861.patch
Link: 
https://github.com/python/cpython/commit/4dc2cae3abd75f386374d0635d00443b897d0672

Signed-off-by: Riyaz Khan 
Signed-off-by: Steve Sakoman 
---
 .../python/python3/CVE-2021-28861.patch   | 135 ++
 .../recipes-devtools/python/python3_3.8.13.bb |   1 +
 2 files changed, 136 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3/CVE-2021-28861.patch

diff --git a/meta/recipes-devtools/python/python3/CVE-2021-28861.patch 
b/meta/recipes-devtools/python/python3/CVE-2021-28861.patch
new file mode 100644
index 00..dc97c6b4eb
--- /dev/null
+++ b/meta/recipes-devtools/python/python3/CVE-2021-28861.patch
@@ -0,0 +1,135 @@
+From 4dc2cae3abd75f386374d0635d00443b897d0672 Mon Sep 17 00:00:00 2001
+From: "Miss Islington (bot)"
+ <31488909+miss-isling...@users.noreply.github.com>
+Date: Wed, 22 Jun 2022 01:42:52 -0700
+Subject: [PATCH] gh-87389: Fix an open redirection vulnerability in
+ http.server. (GH-93879) (GH-94094)
+
+Fix an open redirection vulnerability in the `http.server` module when
+an URI path starts with `//` that could produce a 301 Location header
+with a misleading target.  Vulnerability discovered, and logic fix
+proposed, by Hamza Avvan (@hamzaavvan).
+
+Test and comments authored by Gregory P. Smith [Google].
+(cherry picked from commit 4abab6b603dd38bec1168e9a37c40a48ec89508e)
+
+Co-authored-by: Gregory P. Smith 
+
+Signed-off-by: Riyaz Khan 
+
+CVE: CVE-2021-28861
+
+Upstream-Status: Backport 
[https://github.com/python/cpython/commit/4dc2cae3abd75f386374d0635d00443b897d0672]
+
+---
+ Lib/http/server.py|  7 +++
+ Lib/test/test_httpservers.py  | 53 ++-
+ ...2-06-15-20-09-23.gh-issue-87389.QVaC3f.rst |  3 ++
+ 3 files changed, 61 insertions(+), 2 deletions(-)
+ create mode 100644 
Misc/NEWS.d/next/Security/2022-06-15-20-09-23.gh-issue-87389.QVaC3f.rst
+
+diff --git a/Lib/http/server.py b/Lib/http/server.py
+index 38f7accad7a3..39de35458c38 100644
+--- a/Lib/http/server.py
 b/Lib/http/server.py
+@@ -332,6 +332,13 @@ def parse_request(self):
+ return False
+ self.command, self.path = command, path
+ 
++# gh-87389: The purpose of replacing '//' with '/' is to protect
++# against open redirect attacks possibly triggered if the path starts
++# with '//' because http clients treat //path as an absolute URI
++# without scheme (similar to http://path) rather than a path.
++if self.path.startswith('//'):
++self.path = '/' + self.path.lstrip('/')  # Reduce to a single /
++
+ # Examine the headers and look for a Connection directive.
+ try:
+ self.headers = http.client.parse_headers(self.rfile,
+diff --git a/Lib/test/test_httpservers.py b/Lib/test/test_httpservers.py
+index 87d4924a34b3..fb026188f0b4 100644
+--- a/Lib/test/test_httpservers.py
 b/Lib/test/test_httpservers.py
+@@ -330,7 +330,7 @@ class request_handler(NoLogRequestHandler, 
SimpleHTTPRequestHandler):
+ pass
+ 
+ def setUp(self):
+-BaseTestCase.setUp(self)
++super().setUp()
+ self.cwd = os.getcwd()
+ basetempdir = tempfile.gettempdir()
+ os.chdir(basetempdir)
+@@ -358,7 +358,7 @@ def tearDown(self):
+ except:
+ pass
+ finally:
+-BaseTestCase.tearDown(self)
++super().tearDown()
+ 
+ def check_status_and_reason(self, response, status, data=None):
+ def close_conn():
+@@ -414,6 +414,55 @@ def test_undecodable_filename(self):
+ self.check_status_and_reason(response, HTTPStatus.OK,
+  data=support.TESTFN_UNDECODABLE)
+ 
++def test_get_dir_redirect_location_domain_injection_bug(self):
++"""Ensure //evil.co/..%2f../../X does not put //evil.co/ in Location.
++
++//netloc/ in a Location header is a redirect to a new host.
++https://github.com/python/cpython/issues/87389
++
++This checks that a path resolving to a directory on our server cannot
++resolve into a redirect to another server.
++"""
++os.mkdir(os.path.join(self.tempdir, 'existing_directory'))
++url = 
f'/python.org/..%2f..%2f..%2f..%2f..%2f../%0a%0d/../{self.tempdir_name}/existing_directory'
++expected_location = f'{url}/'  # /python.org.../ single slash single 
prefix, trailing slash
++# Canonicalizes to /tmp/tempdir_name/existing_directory which does
++# exist and is a dir, triggering the 301 redirect logic.
++response = self.request(url)
++self.check_status_and_reason(response, HTTPStatus.MOVED_PERMANENTLY)
++location = response.getheader('Location')
++self.assertEqual(location, expected_location, msg='non-attack 
failed!')
++
++# //python.org... multi-slash prefix, no trailing slash
++attack_url 

Re: [OE-core] [PATCH v3] webkitgtk: Fix build on 32bit arm

[Yu, Mingli]

Still failed on beaglebone-yocto:

/build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/webkitgtk/2.36.7-r0/webkitgtk-2.36.7/Source/W
ebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:38:8: error: 
standard attributes in middle of decl-specifiers

   38 | static alignas(16) short s_FELightingConstantsForNeon[] = {
  |^~~

Thanks,

On 9/9/22 05:45, Khem Raj wrote:

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

Signed-off-by: Khem Raj 
Cc: Mingli Yu 
---
v2: Fix commit msg format
v3: Apply suggestion from 
https://github.com/WebKit/WebKit/pull/1233#discussion_r915217428

  ...44e17d258106617b0e6d783d073b188a2548.patch | 296 ++
  meta/recipes-sato/webkit/webkitgtk_2.36.7.bb  |   1 +
  2 files changed, 297 insertions(+)
  create mode 100644 
meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch

diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
 
b/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
new file mode 100644
index 00..32f92f7ff5
--- /dev/null
+++ 
b/meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
@@ -0,0 +1,296 @@
+From 0d3344e17d258106617b0e6d783d073b188a2548 Mon Sep 17 00:00:00 2001
+From: Adrian Perez de Castro 
+Date: Thu, 2 Jun 2022 11:19:06 +0300
+Subject: [PATCH] [ARM][NEON] FELightningNEON.cpp fails to build, NEON fast
+ path seems unused https://bugs.webkit.org/show_bug.cgi?id=241182
+
+Reviewed by NOBODY (OOPS!).
+
+Move the NEON fast path for the SVG lighting filter effects into
+FELightingSoftwareApplier, and arrange to actually use them by
+forwarding calls to applyPlatformGeneric() into applyPlatformNeon().
+
+Some changes were needed to adapt platformApplyNeon() to the current
+state of filters after r286140. This was not detected because the code
+bitrotted due to it being guarded with CPU(ARM_TRADITIONAL), which does
+not get used much these days: CPU(ARM_THUMB2) is more common. It should
+be possible to use the NEON fast paths also in Thumb mode, but that is
+left for a follow-up fix.
+
+* Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp:
+(WebCore::FELightingSoftwareApplier::platformApplyNeonWorker):
+(WebCore::FELightingSoftwareApplier::getPowerCoefficients):
+(WebCore::FELighting::platformApplyNeonWorker): Deleted.
+(WebCore::FELighting::getPowerCoefficients): Deleted.
+* Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.h:
+(WebCore::FELightingSoftwareApplier::applyPlatformNeon):
+(WebCore::FELighting::platformApplyNeon): Deleted.
+* Source/WebCore/platform/graphics/filters/DistantLightSource.h:
+* Source/WebCore/platform/graphics/filters/FELighting.h:
+* Source/WebCore/platform/graphics/filters/PointLightSource.h:
+* Source/WebCore/platform/graphics/filters/SpotLightSource.h:
+* 
Source/WebCore/platform/graphics/filters/software/FELightingSoftwareApplier.h:
+---
+Upstream-Status: Submitted [https://github.com/WebKit/WebKit/pull/1233]
+Signed-off-by: Khem Raj 
+
+ .../cpu/arm/filters/FELightingNEON.cpp|  4 +-
+ .../graphics/cpu/arm/filters/FELightingNEON.h | 54 +--
+ .../graphics/filters/DistantLightSource.h |  4 ++
+ .../platform/graphics/filters/FELighting.h|  7 ---
+ .../graphics/filters/PointLightSource.h   |  4 ++
+ .../graphics/filters/SpotLightSource.h|  4 ++
+ .../software/FELightingSoftwareApplier.h  | 16 ++
+ 7 files changed, 57 insertions(+), 36 deletions(-)
+
+--- a/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp
 b/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.cpp
+@@ -49,7 +49,7 @@ short* feLightingConstantsForNeon()
+ return s_FELightingConstantsForNeon;
+ }
+
+-void FELighting::platformApplyNeonWorker(FELightingPaintingDataForNeon* 
parameters)
++void 
FELightingSoftwareApplier::platformApplyNeonWorker(FELightingPaintingDataForNeon*
 parameters)
+ {
+ neonDrawLighting(parameters);
+ }
+@@ -464,7 +464,7 @@ TOSTRING(neonDrawLighting) ":" NL
+ "b .lightStrengthCalculated" NL
+ ); // NOLINT
+
+-int FELighting::getPowerCoefficients(float exponent)
++int FELightingSoftwareApplier::getPowerCoefficients(float exponent)
+ {
+ // Calling a powf function from the assembly code would require to save
+ // and reload a lot of NEON registers. Since the base is in range [0..1]
+--- a/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.h
 b/Source/WebCore/platform/graphics/cpu/arm/filters/FELightingNEON.h
+@@ -24,14 +24,15 @@
+  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+  */
+
+-#ifndef FELightingNEON_h
+-#define FELightingNEON_h
++#pragma once
+
+ #if CPU(ARM_NEON) && CPU(ARM_TRADITIONAL) && COMPILER(GCC_COMPATIBLE)
+
+-#include "FELighting.h"
++#include "FELightingSoftwareApplier.h"
++#include "ImageBuffer.h"
+ #include "PointLightSource.h"
+ #include "SpotLightSource.h"

[OE-core][dunfell 0/9] Patch review

[Steve Sakoman]

Please review this set of patches for dunfell and have comments back by end
of day Thursday.

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/4224

The following changes since commit c9a9d5a1f7fbe88422ccee542a89afbc4c5336e4:

  vim: Upgrade 9.0.0242 -> 9.0.0341 (2022-09-07 04:40:43 -1000)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib stable/dunfell-nut
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut

Chee Yang Lee (3):
  connman: fix CVE-2022-32292
  gnutls: fix CVE-2021-4209
  virglrenderer: fix CVE-2022-0135

Florin Diaconescu (1):
  binutils : CVE-2022-38533

k...@kpit.com (1):
  python3: Fix CVE-2021-28861 for python3

Virendra Thakur (1):
  tiff: Fix for CVE-2022-2867/8/9

Yi Zhao (1):
  tiff: Security fixes CVE-2022-1354 and CVE-2022-1355

niko.ma...@vaisala.com (2):
  systemd: Fix unwritable /var/lock when no sysvinit handling
  systemd: Add 'no-dns-fallback' PACKAGECONFIG option

 .../connman/connman/CVE-2022-32292.patch  |  37 +++
 .../connman/connman_1.37.bb   |   1 +
 .../systemd/systemd/00-create-volatile.conf   |   1 +
 meta/recipes-core/systemd/systemd_244.5.bb|   1 +
 .../binutils/binutils-2.34.inc|   1 +
 .../binutils/binutils/CVE-2022-38533.patch|  37 +++
 .../python/python3/CVE-2021-28861.patch   | 135 +++
 .../recipes-devtools/python/python3_3.8.13.bb |   1 +
 .../virglrenderer/CVE-2022-0135.patch | 100 +
 .../virglrenderer/virglrenderer_0.8.2.bb  |   1 +
 ...022-2867-CVE-2022-2868-CVE-2022-2869.patch | 159 +
 .../libtiff/tiff/CVE-2022-1354.patch  | 212 ++
 .../libtiff/tiff/CVE-2022-1355.patch  |  62 +
 meta/recipes-multimedia/libtiff/tiff_4.1.0.bb |   3 +
 .../gnutls/gnutls/CVE-2021-4209.patch |  37 +++
 meta/recipes-support/gnutls/gnutls_3.6.14.bb  |   1 +
 16 files changed, 789 insertions(+)
 create mode 100644 
meta/recipes-connectivity/connman/connman/CVE-2022-32292.patch
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch
 create mode 100644 meta/recipes-devtools/python/python3/CVE-2021-28861.patch
 create mode 100644 
meta/recipes-graphics/virglrenderer/virglrenderer/CVE-2022-0135.patch
 create mode 100644 
meta/recipes-multimedia/libtiff/files/CVE-2022-2867-CVE-2022-2868-CVE-2022-2869.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2022-1354.patch
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2022-1355.patch
 create mode 100644 meta/recipes-support/gnutls/gnutls/CVE-2021-4209.patch

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170617): 
https://lists.openembedded.org/g/openembedded-core/message/170617
Mute This Topic: https://lists.openembedded.org/mt/93670471/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 07/24] libtasn1: upgrade 4.18.0 -> 4.19.0

[Steve Sakoman]

On Tue, Sep 13, 2022 at 2:37 PM Randy MacLeod
 wrote:
>
> On 2022-09-07 10:20, Steve Sakoman wrote:
> > From: wangmy 
> >
> > Changelog:
> > ===
> > - Clarify libtasn1.map license.  Closes: #38.
> > - Fix ETYPE_OK out of bounds read.  Closes: #32.
> > - Update gnulib files and various maintenance fixes.
> >
> > Signed-off-by: Wang Mingyu 
> > Signed-off-by: Alexandre Belloni 
> > (cherry picked from commit b8f2c6ec61ffcc607a35bd5c11f5020c9b676226)
> > Signed-off-by: Steve Sakoman 
> > ---
> >   .../gnutls/{libtasn1_4.18.0.bb => libtasn1_4.19.0.bb}   | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >   rename meta/recipes-support/gnutls/{libtasn1_4.18.0.bb => 
> > libtasn1_4.19.0.bb} (90%)
> >
> > diff --git a/meta/recipes-support/gnutls/libtasn1_4.18.0.bb 
> > b/meta/recipes-support/gnutls/libtasn1_4.19.0.bb
> > similarity index 90%
> > rename from meta/recipes-support/gnutls/libtasn1_4.18.0.bb
> > rename to meta/recipes-support/gnutls/libtasn1_4.19.0.bb
> > index db49adc1c2..5fb8b54c06 100644
> > --- a/meta/recipes-support/gnutls/libtasn1_4.18.0.bb
> > +++ b/meta/recipes-support/gnutls/libtasn1_4.19.0.bb
> > @@ -16,7 +16,7 @@ SRC_URI = "${GNU_MIRROR}/libtasn1/libtasn1-${PV}.tar.gz \
> >
> >   DEPENDS = "bison-native"
> >
> > -SRC_URI[sha256sum] = 
> > "4365c154953563d64c67a024b607d1ee75c6db76e0d0f65709ea80a334cd1898"
> > +SRC_URI[sha256sum] = 
> > "1613f0ac1cf484d6ec0ce3b8c06d56263cc7242f1c23b30d82d23de345a63f7a"
> >
> >   inherit autotools texinfo lib_package gtk-doc
>
> I was a little concerned about this update for kirkstone but
> after a little review, it seems fine so I thought I'd reply to show
> Steve that people do eventually read his updates and to re-assure
> any late to the party worriers like me.
>
>
> Full git log --oneline below but the source is mainly in 'src and lib':
>
> $ git log --oneline v4.18.0..v4.19.0 src
> 4e74cf2 Bump copyright years.
>
> $ git log --oneline v4.18.0..v4.19.0 lib
> 6acc6d9 Work around unfixed gtk-doc problem.
> 5ce3238 Some C89 fixes.  Closes: !70.
> 44a700d Fix ETYPE_OK off by one array size check.  Closes: #32.
> 33adcd0 Fix license header.  Closes: #38.
> 4e74cf2 Bump copyright years.
>
> so that all seems to be sensible.
>
> I may learn to trust Steve (but I'll keep verifying...)

Please do!  I'm not sure I would trust me ;-)

Steve

> $ git log --oneline v4.18.0..v4.19.0
> 2b7ee16 (tag: v4.19.0) version 4.19.0
> 6acc6d9 Work around unfixed gtk-doc problem.
> 53fe8c8 Improve CI/CD artifacts, and fail on errors.
> 06e7433 Put version checks in tests/version.c.
> 513bb42 Deduplicate.
> 51e04e5 bootstrap.conf (src_gnulib_modules): Add getopt-gnu.
> 290a4ad Build check with tcc/lld/pcc.
> 5ce3238 Some C89 fixes.  Closes: !70.
> b66b8ce Attempt to reproduce !70 build error.
> 4af0fbc Bump LT_REVISION.
> 42467ed Add sc_libtool_version_bump syntax-check.
> 74785e7 Move gnulib's dummy test directory from tests-gl to lib/gl/tests.
> 45c87b5 Add NEWS entry.
> 44a700d Fix ETYPE_OK off by one array size check.  Closes: #32.
> 1487507 Make sure syntax-check catches indent mistakes during cicd.
> 6533485 Add self-check for #32 to see if cicd catches it.
> 33adcd0 Fix license header.  Closes: #38.
> 72e30be Add NEWS entry.
> 7b58af4 Silence syntax-check.
> f1436e1 Silence sc_makefile_DISTCHECK_CONFIGURE_FLAGS until we clean up
> coverage code.
> 7c54eb1 Put gtkdocize in bootstrap_post_import_hook.
> 2a2686c Update bootstrap.
> 81b1cb0 Update gnulib.
> 4e74cf2 Bump copyright years.
> 02bf9cb Don't use -static when linking in fuzz/.  Closes: !61.
> 56d2301 Use portable way to remove carriage returns.
> 3af8286 (origin/jas/tmp-cicd) Don't use non-portable diff
> --strip-trailing-cr.
> 607e6b1 cicd: Add targets, reduce texlive.
> 581e2a3 maint: Fix builddir!=srcdir abi-check failure.
> c9c8de3 maint: Attempt to minimize texlive dependencies.
> 6182cf4 maint: Fix (and CICD-test) builddir!=srcdir bootstrap builds.
> 4332821 maint: Remove really old release announcement template.
> 5b766ad maint: Really remove texinfo.css.
> f3c679d maint: post-release administrivia
>
>
> >
> >
> > 
> >
>
> --
> # Randy MacLeod
> # Wind River Linux
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170616): 
https://lists.openembedded.org/g/openembedded-core/message/170616
Mute This Topic: https://lists.openembedded.org/mt/93525901/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] binutils: update USE_ALTERNATIVES_FOR for symlink files

[kai]

On 9/12/22 22:58, Richard Purdie wrote:

On Sun, 2022-09-11 at 16:47 +0800, kai wrote:

From: Kai Kang 

It provides more binary files by binutils 2.39. Then add them to
USE_ALTERNATIVES_FOR as others to handle symlink files via
update-alternative mechanism.

Signed-off-by: Kai Kang 
---
  meta/recipes-devtools/binutils/binutils.inc | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils.inc 
b/meta/recipes-devtools/binutils/binutils.inc
index 789c8bec21..9d33a64371 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -47,7 +47,13 @@ USE_ALTERNATIVES_FOR = " \
as \
c++filt \
elfedit \
+   gp-archive \
+   gp-collect-app \
+   gp-display-html \
+   gp-display-src \
+   gp-display-text \
gprof \
+   gprofng \
ld \
ld.bfd \
${LDGOLD_ALTS} \

This throws tons of warnings:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/4219

e.g.:

https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5896/steps/12/logs/warnings

but many more.


OK. I'll figure it out.

Regards,
Kai



Cheers,

Richard



--
Kai Kang
Wind River Linux


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170615): 
https://lists.openembedded.org/g/openembedded-core/message/170615
Mute This Topic: https://lists.openembedded.org/mt/93608151/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 07/24] libtasn1: upgrade 4.18.0 -> 4.19.0

[Randy MacLeod]

On 2022-09-07 10:20, Steve Sakoman wrote:

From: wangmy 

Changelog:
===
- Clarify libtasn1.map license.  Closes: #38.
- Fix ETYPE_OK out of bounds read.  Closes: #32.
- Update gnulib files and various maintenance fixes.

Signed-off-by: Wang Mingyu 
Signed-off-by: Alexandre Belloni 
(cherry picked from commit b8f2c6ec61ffcc607a35bd5c11f5020c9b676226)
Signed-off-by: Steve Sakoman 
---
  .../gnutls/{libtasn1_4.18.0.bb => libtasn1_4.19.0.bb}   | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
  rename meta/recipes-support/gnutls/{libtasn1_4.18.0.bb => libtasn1_4.19.0.bb} 
(90%)

diff --git a/meta/recipes-support/gnutls/libtasn1_4.18.0.bb 
b/meta/recipes-support/gnutls/libtasn1_4.19.0.bb
similarity index 90%
rename from meta/recipes-support/gnutls/libtasn1_4.18.0.bb
rename to meta/recipes-support/gnutls/libtasn1_4.19.0.bb
index db49adc1c2..5fb8b54c06 100644
--- a/meta/recipes-support/gnutls/libtasn1_4.18.0.bb
+++ b/meta/recipes-support/gnutls/libtasn1_4.19.0.bb
@@ -16,7 +16,7 @@ SRC_URI = "${GNU_MIRROR}/libtasn1/libtasn1-${PV}.tar.gz \
  
  DEPENDS = "bison-native"
  
-SRC_URI[sha256sum] = "4365c154953563d64c67a024b607d1ee75c6db76e0d0f65709ea80a334cd1898"

+SRC_URI[sha256sum] = 
"1613f0ac1cf484d6ec0ce3b8c06d56263cc7242f1c23b30d82d23de345a63f7a"
  
  inherit autotools texinfo lib_package gtk-doc


I was a little concerned about this update for kirkstone but
after a little review, it seems fine so I thought I'd reply to show
Steve that people do eventually read his updates and to re-assure
any late to the party worriers like me.


Full git log --oneline below but the source is mainly in 'src and lib':

$ git log --oneline v4.18.0..v4.19.0 src
4e74cf2 Bump copyright years.

$ git log --oneline v4.18.0..v4.19.0 lib
6acc6d9 Work around unfixed gtk-doc problem.
5ce3238 Some C89 fixes.  Closes: !70.
44a700d Fix ETYPE_OK off by one array size check.  Closes: #32.
33adcd0 Fix license header.  Closes: #38.
4e74cf2 Bump copyright years.

so that all seems to be sensible.

I may learn to trust Steve (but I'll keep verifying...)

../Randy


$ git log --oneline v4.18.0..v4.19.0
2b7ee16 (tag: v4.19.0) version 4.19.0
6acc6d9 Work around unfixed gtk-doc problem.
53fe8c8 Improve CI/CD artifacts, and fail on errors.
06e7433 Put version checks in tests/version.c.
513bb42 Deduplicate.
51e04e5 bootstrap.conf (src_gnulib_modules): Add getopt-gnu.
290a4ad Build check with tcc/lld/pcc.
5ce3238 Some C89 fixes.  Closes: !70.
b66b8ce Attempt to reproduce !70 build error.
4af0fbc Bump LT_REVISION.
42467ed Add sc_libtool_version_bump syntax-check.
74785e7 Move gnulib's dummy test directory from tests-gl to lib/gl/tests.
45c87b5 Add NEWS entry.
44a700d Fix ETYPE_OK off by one array size check.  Closes: #32.
1487507 Make sure syntax-check catches indent mistakes during cicd.
6533485 Add self-check for #32 to see if cicd catches it.
33adcd0 Fix license header.  Closes: #38.
72e30be Add NEWS entry.
7b58af4 Silence syntax-check.
f1436e1 Silence sc_makefile_DISTCHECK_CONFIGURE_FLAGS until we clean up 
coverage code.

7c54eb1 Put gtkdocize in bootstrap_post_import_hook.
2a2686c Update bootstrap.
81b1cb0 Update gnulib.
4e74cf2 Bump copyright years.
02bf9cb Don't use -static when linking in fuzz/.  Closes: !61.
56d2301 Use portable way to remove carriage returns.
3af8286 (origin/jas/tmp-cicd) Don't use non-portable diff 
--strip-trailing-cr.

607e6b1 cicd: Add targets, reduce texlive.
581e2a3 maint: Fix builddir!=srcdir abi-check failure.
c9c8de3 maint: Attempt to minimize texlive dependencies.
6182cf4 maint: Fix (and CICD-test) builddir!=srcdir bootstrap builds.
4332821 maint: Remove really old release announcement template.
5b766ad maint: Really remove texinfo.css.
f3c679d maint: post-release administrivia


  






--
# Randy MacLeod
# Wind River Linux


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170614): 
https://lists.openembedded.org/g/openembedded-core/message/170614
Mute This Topic: https://lists.openembedded.org/mt/93525901/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] opkg: enable zstd support

[Alex Stewart]

On 9/13/22 15:20, Alex Feinman wrote:
I do have some numbers. When I was selling this change internally, I 
did a comparison on our internal build.

   Combined write IPK times (Σ t do_package_write_ipk)
xz 162m 35s
gz 52m 13s
zstd   33m 49s
Compression rate for zstd was closer to xz than to gz but not as good 
as xz. For systems that have to cache packages on the device with 
limited storage xz might be a better option, but for the bulk of 
projects zstd is the best choice
Additionally, zstd offers much faster decompression than xz so the 
rootfs build step that includes unpacking all of the ipks, takes 3m 
58s with xz and 2m 44s with zstd.
One other thing of note - if your build includes debug packages, some 
may be quite large. E.g. one of our components produces a 2.2 GB debug 
package (uncompressed). On large files xz requires a disproportionally 
large amount of time resulting in 15 minutes needed to simply write 
ipk for the abovementioned packages, whereas zstd took about 45 sec. 
For frequent tasks like bitbaking a single package this translates in 
a lot of saved time.


Those are certainly compelling performance improvements. Assuming that 
the final data-segment size is within 5%-ish of xz, then I would agree 
with the rest of the thread that it should probably be the contemporary 
default.


And if we make it the default compressor for OE IPKs, then obviously my 
criticism in the original PR is satisfied.


Bottom line - I think making xz a default package compressor was not 
entirely thought through. gzip or zstd is what the default should be.


ZStandard support was only added to opkg last September [1]. Before 
that, xz was the new hotness that replaced gzip. :)


[1] 
https://git.yoctoproject.org/opkg/commit/?id=5dead419e94bce2e6b743ad786c1daec0e1aa294


One final note: I could not find a reasonable explanation for why 
opkg-tools require code changes to support a different compressor. BSD 
tar and GNU tar both can easily accept compressors that they have no 
idea about (via -I option) because all of them provide a unified 
command line interface for use in pipes. If this were done similar to 
tar, we could have used any compressor we wanted, including the 
multithreaded versions (zstdmt)


Well, presumably IPK creation tools can only support the matrix of 
compression algorithms which your opkg binary can decompress. I suppose 
someone could try to implement a plugable compression module system for 
opkg. But given that nearly everyone uses opkg in an embedded context, 
I'm not sure it would get much use.




On Tue, Sep 13, 2022 at 12:43 PM Khem Raj  wrote:

On Tue, Sep 13, 2022 at 12:19 PM Alex Stewart
 wrote:
>
> ACK from me - apart from enabling zstd by default.
>
> On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org


wrote:
> > This allows the use of zstd for opkg packages by using
OPKGBUILDCMD:
> > OPKGBUILDCMD = "opkg-build -Z zstd"
> >
> > Signed-off-by: Alex Feinman 
> > Signed-off-by: Etienne Cordonnier 
> > ---
> >   meta/recipes-devtools/opkg/opkg_0.6.0.bb


| 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb


b/meta/recipes-devtools/opkg/opkg_0.6.0.bb


> > index 7b351e8123..e38d9d6f3f 100644
> > --- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb


> > +++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb


> > @@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
> >   target_localstatedir := "${localstatedir}"
> >   OPKGLIBDIR ??= "${target_localstatedir}/lib"
> >
> > -PACKAGECONFIG ??= "libsolv"
> > +PACKAGECONFIG ??= "libsolv zstd"
>
> Building in zstd support by default is a little suspect to me.
>
> Unless I'm mistaken, OE-core will only build xz-compressed IPKs by
> default. So zstd support would be unnecessary for a distro
integrator
> who just uses upstream OE-core.
>
> For distros which use zstd compression in their 

[OE-core] [PATCH v2] elfutils: Enable ptests on musl targets

[Khem Raj]

Signed-off-by: Khem Raj 
---
v2: Install libeu.a into ptest package

 .../elfutils/elfutils_0.187.bb|   4 +-
 ...Add-libeu-to-tests-needing-error-API.patch | 147 ++
 2 files changed, 150 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.187.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.187.bb
index 561112c580..40c51c8814 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.187.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.187.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://run-ptest \
file://ptest.patch \

file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \
+   file://0001-tests-Add-libeu-to-tests-needing-error-API.patch \
"
 SRC_URI:append:libc-musl = " \
file://0003-musl-utils.patch \
@@ -29,7 +30,6 @@ SRC_URI:append:libc-musl = " \
 SRC_URI[sha256sum] = 
"e70b0dfbe610f90c4d1fe0d71af142a4e25c3c4ef9ebab8d2d72b65159d454c8"
 
 inherit autotools gettext ptest pkgconfig
-PTEST_ENABLED:libc-musl = "0"
 
 EXTRA_OECONF = "--program-prefix=eu-"
 
@@ -66,6 +66,7 @@ do_install_ptest() {
# copy the files which needed by the cases
TEST_FILES="strip strip.o addr2line elfcmp objdump readelf 
size.o nm.o nm elflint elfcompress elfclassify stack unstrip"
install -d -m 755   ${D}${PTEST_PATH}/src
+   install -d -m 755   ${D}${PTEST_PATH}/lib
install -d -m 755   ${D}${PTEST_PATH}/libelf
install -d -m 755   ${D}${PTEST_PATH}/libdw
install -d -m 755   
${D}${PTEST_PATH}/libdwfl
@@ -83,6 +84,7 @@ do_install_ptest() {
cp ${D}${libdir}/libasm-${PV}.so 
${D}${PTEST_PATH}/libasm/libasm.so
cp ${B}/libcpu/libcpu.a ${D}${PTEST_PATH}/libcpu/
cp ${B}/libebl/libebl.a ${D}${PTEST_PATH}/libebl/
+   cp ${B}/lib/libeu.a ${D}${PTEST_PATH}/lib/
cp ${S}/libelf/*.h ${D}${PTEST_PATH}/libelf/
cp ${S}/libdw/*.h  ${D}${PTEST_PATH}/libdw/
cp ${S}/libdwfl/*.h${D}${PTEST_PATH}/libdwfl/
diff --git 
a/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
 
b/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
new file mode 100644
index 00..7c1bc87cbf
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
@@ -0,0 +1,147 @@
+From c05c787070a390a2061bfcb845e1e35e8b1373b3 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 13 Sep 2022 09:33:00 -0700
+Subject: [PATCH] tests: Add libeu to tests needing error() API
+
+A local error() impelmentation is used when libc does not provide it,
+therefore link in libeu.a which contains this function in tests needing
+error() API
+
+Upstream-Status: Submitted 
[https://sourceware.org/pipermail/elfutils-devel/2022q3/005375.html]
+Signed-off-by: Khem Raj 
+---
+ tests/Makefile.am | 60 +++
+ 1 file changed, 30 insertions(+), 30 deletions(-)
+
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 3943e17..1acc49b 100644
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -638,17 +638,17 @@ libeu = ../lib/libeu.a
+ arextract_LDADD = $(libelf)
+ arsymtest_LDADD = $(libelf)
+ newfile_LDADD = $(libelf)
+-saridx_LDADD = $(libelf)
++saridx_LDADD = $(libeu) $(libelf)
+ scnnames_LDADD = $(libelf)
+-sectiondump_LDADD = $(libelf)
++sectiondump_LDADD = $(libeu) $(libelf)
+ showptable_LDADD = $(libelf)
+ hash_LDADD = $(libelf)
+ test_nlist_CFLAGS =-g -O0 $(EXTRA_NLIST_CFLAGS)
+ test_nlist_LDADD = $(libelf)
+ msg_tst_LDADD = $(libelf)
+ newscn_LDADD = $(libelf)
+-early_offscn_LDADD = $(libelf)
+-ecp_LDADD = $(libelf)
++early_offscn_LDADD = $(libeu) $(libelf)
++ecp_LDADD = $(libeu) $(libelf)
+ update1_LDADD = $(libelf)
+ update2_LDADD = $(libelf)
+ update3_LDADD = $(libdw) $(libelf)
+@@ -662,12 +662,12 @@ get_files_LDADD = $(libdw) $(libelf)
+ next_files_LDADD = $(libdw) $(libelf)
+ get_aranges_LDADD = $(libdw) $(libelf)
+ allfcts_LDADD = $(libdw) $(libelf)
+-line2addr_LDADD = $(libdw) $(argp_LDADD)
+-addrscopes_LDADD = $(libdw) $(argp_LDADD)
+-funcscopes_LDADD = $(libdw) $(argp_LDADD)
+-funcretval_LDADD = $(libdw) $(argp_LDADD)
+-allregs_LDADD = $(libdw) $(argp_LDADD)
+-find_prologues_LDADD = $(libdw) $(argp_LDADD)
++line2addr_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++addrscopes_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++funcscopes_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++funcretval_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++allregs_LDADD = $(libeu) $(libdw) $(argp_LDADD)

Re: [OE-core] [PATCH] opkg: enable zstd support

[Khem Raj]

Thanks for sharing, really appreciate it. How close were compression
rates in numbers ? I think some users might be sensitive to the
archive sizes, if its something
with in acceptable range, I do agree, zstd would be a better default these days.

On Tue, Sep 13, 2022 at 1:20 PM Alex Feinman  wrote:
>
> I do have some numbers. When I was selling this change internally, I did a 
> comparison on our internal build.
>
>   Combined write IPK times (Σ t do_package_write_ipk)
>
> xz 162m 35s
>
> gz 52m 13s
>
> zstd   33m 49s
>
> Compression rate for zstd was closer to xz than to gz but not as good as xz. 
> For systems that have to cache packages on the device with limited storage xz 
> might be a better option, but for the bulk of projects zstd is the best choice
>
> Additionally, zstd offers much faster decompression than xz so the rootfs 
> build step that includes unpacking all of the ipks, takes 3m 58s with xz and 
> 2m 44s with zstd.
>
> One other thing of note - if your build includes debug packages, some may be 
> quite large. E.g. one of our components produces a 2.2 GB debug package 
> (uncompressed). On large files xz requires a disproportionally large amount 
> of time resulting in 15 minutes needed to simply write ipk for the 
> abovementioned packages, whereas zstd took about 45 sec. For frequent tasks 
> like bitbaking a single package this translates in a lot of saved time.
>
> Bottom line - I think making xz a default package compressor was not entirely 
> thought through. gzip or zstd is what the default should be.
>
> One final note: I could not find a reasonable explanation for why opkg-tools 
> require code changes to support a different compressor. BSD tar and GNU tar 
> both can easily accept compressors that they have no idea about (via -I 
> option) because all of them provide a unified command line interface for use 
> in pipes. If this were done similar to tar, we could have used any compressor 
> we wanted, including the multithreaded versions (zstdmt)
>
>
> On Tue, Sep 13, 2022 at 12:43 PM Khem Raj  wrote:
>>
>> On Tue, Sep 13, 2022 at 12:19 PM Alex Stewart  wrote:
>> >
>> > ACK from me - apart from enabling zstd by default.
>> >
>> > On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org wrote:
>> > > This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
>> > > OPKGBUILDCMD = "opkg-build -Z zstd"
>> > >
>> > > Signed-off-by: Alex Feinman 
>> > > Signed-off-by: Etienne Cordonnier 
>> > > ---
>> > >   meta/recipes-devtools/opkg/opkg_0.6.0.bb | 3 ++-
>> > >   1 file changed, 2 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb 
>> > > b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > index 7b351e8123..e38d9d6f3f 100644
>> > > --- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > +++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > @@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
>> > >   target_localstatedir := "${localstatedir}"
>> > >   OPKGLIBDIR ??= "${target_localstatedir}/lib"
>> > >
>> > > -PACKAGECONFIG ??= "libsolv"
>> > > +PACKAGECONFIG ??= "libsolv zstd"
>> >
>> > Building in zstd support by default is a little suspect to me.
>> >
>> > Unless I'm mistaken, OE-core will only build xz-compressed IPKs by
>> > default. So zstd support would be unnecessary for a distro integrator
>> > who just uses upstream OE-core.
>> >
>> > For distros which use zstd compression in their packages, I think it
>> > would be more appropriate to overwrite the opkg PACKAGECONFIG in a
>> > .bbappend.
>> >
>>
>> This is perhaps fine. I do wonder if there is some performance
>> comparison data between xz and zstd compressed ipks
>> with opkg, it might help users on making this choice and also if we
>> should consider using
>> zstd by default at some point or not.
>>
>> > Is there something I'm not considering here?
>> >
>> > >
>> > >   PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
>> > >   gnupg gpgme libgpg-error,\
>> > > @@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
>> > >   PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
>> > >   PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl 
>> > > openssl"
>> > >   PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
>> > > +PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
>> > >   PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
>> > >
>> > >   EXTRA_OECONF:class-native = 
>> > > "--localstatedir=/${@os.path.relpath('${localstatedir}', 
>> > > '${STAGING_DIR_NATIVE}')} 
>> > > --sysconfdir=/${@os.path.relpath('${sysconfdir}', 
>> > > '${STAGING_DIR_NATIVE}')}"
>> > >
>> > >
>> > >
>> >
>> > --
>> > Alex Stewart
>> > Software Engineer - NI Real-Time OS
>> > NI (National Instruments)
>> >
>> > alex.stew...@ni.com
>> >
>> >
>> > 
>> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170611): 

Re: [OE-core] [PATCH] opkg: enable zstd support

[Alex Feinman via lists.openembedded.org]

On Tue, Sep 13, 2022 at 1:20 PM Alex Feinman  wrote:

> I do have some numbers. When I was selling this change internally, I did a
> comparison on our internal build.
>
>   Combined write IPK times (Σ t do_package_write_ipk)
>
> xz 162m 35s
>
> gz 52m 13s
>
> zstd   33m 49s
>
> Compression rate for zstd was closer to xz than to gz but not as good as xz. 
> For systems that have to cache packages on the device with limited storage xz 
> might be a better option, but for the bulk of projects zstd is the best choice
>
> Additionally, zstd offers much faster decompression than xz so the rootfs 
> build step that includes unpacking all of the ipks, takes 3m 58s with xz and 
> 2m 44s with zstd.
>
> One other thing of note - if your build includes debug packages, some may be 
> quite large. E.g. one of our components produces a 2.2 GB debug package 
> (uncompressed). On large files xz requires a disproportionally large amount 
> of time resulting in 15 minutes needed to simply write ipk for the 
> abovementioned packages, whereas zstd took about 45 sec. For frequent tasks 
> like bitbaking a single package this translates in a lot of saved time.
>
> Bottom line - I think making xz a default package compressor was not entirely 
> thought through. gzip or zstd is what the default should be.
>
> One final note: I could not find a reasonable explanation for why opkg-tools 
> require code changes to support a different compressor. BSD tar and GNU tar 
> both can easily accept compressors that they have no idea about (via -I 
> option) because all of them provide a unified command line interface for use 
> in pipes. If this were done similar to tar, we could have used any compressor 
> we wanted, including the multithreaded versions (zstdmt)
>
>
> On Tue, Sep 13, 2022 at 12:43 PM Khem Raj  wrote:
>
>> On Tue, Sep 13, 2022 at 12:19 PM Alex Stewart 
>> wrote:
>> >
>> > ACK from me - apart from enabling zstd by default.
>> >
>> > On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org wrote:
>> > > This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
>> > > OPKGBUILDCMD = "opkg-build -Z zstd"
>> > >
>> > > Signed-off-by: Alex Feinman 
>> > > Signed-off-by: Etienne Cordonnier 
>> > > ---
>> > >   meta/recipes-devtools/opkg/opkg_0.6.0.bb | 3 ++-
>> > >   1 file changed, 2 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > index 7b351e8123..e38d9d6f3f 100644
>> > > --- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > +++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
>> > > @@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
>> > >   target_localstatedir := "${localstatedir}"
>> > >   OPKGLIBDIR ??= "${target_localstatedir}/lib"
>> > >
>> > > -PACKAGECONFIG ??= "libsolv"
>> > > +PACKAGECONFIG ??= "libsolv zstd"
>> >
>> > Building in zstd support by default is a little suspect to me.
>> >
>> > Unless I'm mistaken, OE-core will only build xz-compressed IPKs by
>> > default. So zstd support would be unnecessary for a distro integrator
>> > who just uses upstream OE-core.
>> >
>> > For distros which use zstd compression in their packages, I think it
>> > would be more appropriate to overwrite the opkg PACKAGECONFIG in a
>> > .bbappend.
>> >
>>
>> This is perhaps fine. I do wonder if there is some performance
>> comparison data between xz and zstd compressed ipks
>> with opkg, it might help users on making this choice and also if we
>> should consider using
>> zstd by default at some point or not.
>>
>> > Is there something I'm not considering here?
>> >
>> > >
>> > >   PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
>> > >   gnupg gpgme libgpg-error,\
>> > > @@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
>> > >   PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
>> > >   PACKAGECONFIG[ssl-curl] =
>> "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
>> > >   PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
>> > > +PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
>> > >   PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
>> > >
>> > >   EXTRA_OECONF:class-native =
>> "--localstatedir=/${@os.path.relpath('${localstatedir}',
>> '${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}',
>> '${STAGING_DIR_NATIVE}')}"
>> > >
>> > >
>> > >
>> >
>> > --
>> > Alex Stewart
>> > Software Engineer - NI Real-Time OS
>> > NI (National Instruments)
>> >
>> > alex.stew...@ni.com
>> >
>> >
>> > 
>> >
>>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170610): 
https://lists.openembedded.org/g/openembedded-core/message/170610
Mute This Topic: https://lists.openembedded.org/mt/93654146/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] opkg: enable zstd support

[Khem Raj]

On Tue, Sep 13, 2022 at 12:19 PM Alex Stewart  wrote:
>
> ACK from me - apart from enabling zstd by default.
>
> On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org wrote:
> > This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
> > OPKGBUILDCMD = "opkg-build -Z zstd"
> >
> > Signed-off-by: Alex Feinman 
> > Signed-off-by: Etienne Cordonnier 
> > ---
> >   meta/recipes-devtools/opkg/opkg_0.6.0.bb | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb 
> > b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
> > index 7b351e8123..e38d9d6f3f 100644
> > --- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
> > +++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
> > @@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
> >   target_localstatedir := "${localstatedir}"
> >   OPKGLIBDIR ??= "${target_localstatedir}/lib"
> >
> > -PACKAGECONFIG ??= "libsolv"
> > +PACKAGECONFIG ??= "libsolv zstd"
>
> Building in zstd support by default is a little suspect to me.
>
> Unless I'm mistaken, OE-core will only build xz-compressed IPKs by
> default. So zstd support would be unnecessary for a distro integrator
> who just uses upstream OE-core.
>
> For distros which use zstd compression in their packages, I think it
> would be more appropriate to overwrite the opkg PACKAGECONFIG in a
> .bbappend.
>

This is perhaps fine. I do wonder if there is some performance
comparison data between xz and zstd compressed ipks
with opkg, it might help users on making this choice and also if we
should consider using
zstd by default at some point or not.

> Is there something I'm not considering here?
>
> >
> >   PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
> >   gnupg gpgme libgpg-error,\
> > @@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
> >   PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
> >   PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl 
> > openssl"
> >   PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
> > +PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
> >   PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
> >
> >   EXTRA_OECONF:class-native = 
> > "--localstatedir=/${@os.path.relpath('${localstatedir}', 
> > '${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}', 
> > '${STAGING_DIR_NATIVE}')}"
> >
> >
> >
>
> --
> Alex Stewart
> Software Engineer - NI Real-Time OS
> NI (National Instruments)
>
> alex.stew...@ni.com
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170609): 
https://lists.openembedded.org/g/openembedded-core/message/170609
Mute This Topic: https://lists.openembedded.org/mt/93654146/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] opkg: enable zstd support

[Alex Stewart]

ACK from me - apart from enabling zstd by default.

On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org wrote:

This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
OPKGBUILDCMD = "opkg-build -Z zstd"

Signed-off-by: Alex Feinman 
Signed-off-by: Etienne Cordonnier 
---
  meta/recipes-devtools/opkg/opkg_0.6.0.bb | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb 
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
index 7b351e8123..e38d9d6f3f 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
@@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
  target_localstatedir := "${localstatedir}"
  OPKGLIBDIR ??= "${target_localstatedir}/lib"
  
-PACKAGECONFIG ??= "libsolv"

+PACKAGECONFIG ??= "libsolv zstd"


Building in zstd support by default is a little suspect to me.

Unless I'm mistaken, OE-core will only build xz-compressed IPKs by 
default. So zstd support would be unnecessary for a distro integrator 
who just uses upstream OE-core.


For distros which use zstd compression in their packages, I think it 
would be more appropriate to overwrite the opkg PACKAGECONFIG in a 
.bbappend.


Is there something I'm not considering here?

  
  PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\

  gnupg gpgme libgpg-error,\
@@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
  PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
  PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
  PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
+PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
  PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
  
  EXTRA_OECONF:class-native = "--localstatedir=/${@os.path.relpath('${localstatedir}', '${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}', '${STAGING_DIR_NATIVE}')}"






--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stew...@ni.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170608): 
https://lists.openembedded.org/g/openembedded-core/message/170608
Mute This Topic: https://lists.openembedded.org/mt/93654146/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] binutils: stable 2.38 branch updates

[Steve Sakoman]

On Tue, Sep 13, 2022 at 8:42 AM Randy MacLeod
 wrote:
>
> On 2022-09-13 12:59, Khem Raj wrote:
> > On 9/13/22 2:43 AM, Sundeep KOKKONDA wrote:
> >> Hello,
> >> I am planning to take the gcc, glibc & binutils updates to Kirkstone.
> >> I found only the glibc-2.35 branch is having a few updates (given
> >> below).
> >> /f8ad66a4ca nscd: Fix netlink cache invalidation if epoll is used [BZ
> >> #29415]/
> >> /9e960717e1 Apply asm redirections in wchar.h before first use/
> >> /577c2fc7f3 elf: Call __libc_early_init for reused namespaces (bug
> >> 29528)/
> >> /83f1d9851e NEWS: Add entry for bug 28846/
> >> /cbd8685e82 socket: Check lengths before advancing pointer in
> >> CMSG_NXTHDR/
> >> /4bafc4001d alpha: Fix generic brk system call emulation in
> >> __brk_call (bug 29490)/
> >> /37fd2ac665 stdlib: Fixup mbstowcs NULL __dst handling. [BZ #29279]/
> >> /a1ec4157bc stdlib: Remove attr_write from mbstows if dst is NULL
> >> [BZ: 29265]/
> >> /813a8d0171 Update syscall lists for Linux 5.19/
> >> /e200127c6c riscv: Update rv64 libm test ulps/
> >> /8c172a6cb0 dlfcn: Pass caller pointer to static dlopen
> >> implementation (bug 29446)/
>
> Ideally you'd get that in this week since I think that 4.0.4 is being
> built on Monday, September 19th.
>
> CCing Steve in case he missed this thread.

It will have to hit the list in the next day or so to make it, since
it takes about 3 days for the test/review cycle.

Steve

>
>
> >> The binutils-2.38 has no new commits. And, gcc-11.x also not have any
> >> new release after 11.3.
>
> That's good to know. I was just wondering if there was going to be
> gcc-11.4 so this info is timely.
>
>
> >> In /master/ branch gcc_12.2, glibc_2.36 & binutils_2.39 versions are
> >> used. Kirkstone will continue to use the old versions?
>
>
> To answer this more directly than Khem. ;-)
>
> The Kirkstone branch will NOT update to the versions shown above. Users
> want a stable version
>
> for the supported timeline of a release; some even may be surprised that
> we update from 11.2 to 11.3
> even if it's all bug fixes.
>
>
> >>
> >
> > the glibc fixes are good so go ahead bump the SRCREV to latest on 2.35
> > branch
>
> Agreed.
>
>
> >  major version backports are exceptions. We can consider doing mixin
> > layers if needed for say newer compiler.
>
>
> Answered above.
>
> Thanks Sundeep!
>
> ../Randy
>
>
> >
> >>
> >>
> >> Thanks,
> >> Sundeep K.
> >>
> >>
> >>
> >>
> >
> > 
> >
>
> --
> # Randy MacLeod
> # Wind River Linux
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170607): 
https://lists.openembedded.org/g/openembedded-core/message/170607
Mute This Topic: https://lists.openembedded.org/mt/92739561/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] binutils: stable 2.38 branch updates

[Khem Raj]

On Tue, Sep 13, 2022 at 11:42 AM Randy MacLeod
 wrote:
>
> On 2022-09-13 12:59, Khem Raj wrote:
> > On 9/13/22 2:43 AM, Sundeep KOKKONDA wrote:
> >> Hello,
> >> I am planning to take the gcc, glibc & binutils updates to Kirkstone.
> >> I found only the glibc-2.35 branch is having a few updates (given
> >> below).
> >> /f8ad66a4ca nscd: Fix netlink cache invalidation if epoll is used [BZ
> >> #29415]/
> >> /9e960717e1 Apply asm redirections in wchar.h before first use/
> >> /577c2fc7f3 elf: Call __libc_early_init for reused namespaces (bug
> >> 29528)/
> >> /83f1d9851e NEWS: Add entry for bug 28846/
> >> /cbd8685e82 socket: Check lengths before advancing pointer in
> >> CMSG_NXTHDR/
> >> /4bafc4001d alpha: Fix generic brk system call emulation in
> >> __brk_call (bug 29490)/
> >> /37fd2ac665 stdlib: Fixup mbstowcs NULL __dst handling. [BZ #29279]/
> >> /a1ec4157bc stdlib: Remove attr_write from mbstows if dst is NULL
> >> [BZ: 29265]/
> >> /813a8d0171 Update syscall lists for Linux 5.19/
> >> /e200127c6c riscv: Update rv64 libm test ulps/
> >> /8c172a6cb0 dlfcn: Pass caller pointer to static dlopen
> >> implementation (bug 29446)/
>
> Ideally you'd get that in this week since I think that 4.0.4 is being
> built on Monday, September 19th.
>
> CCing Steve in case he missed this thread.
>
>
> >> The binutils-2.38 has no new commits. And, gcc-11.x also not have any
> >> new release after 11.3.
>
> That's good to know. I was just wondering if there was going to be
> gcc-11.4 so this info is timely.

11.4 would be next sprint or early summer of 2023

>
>
> >> In /master/ branch gcc_12.2, glibc_2.36 & binutils_2.39 versions are
> >> used. Kirkstone will continue to use the old versions?
>
>
> To answer this more directly than Khem. ;-)
>
> The Kirkstone branch will NOT update to the versions shown above. Users
> want a stable version
>
> for the supported timeline of a release; some even may be surprised that
> we update from 11.2 to 11.3
> even if it's all bug fixes.
>
>
> >>
> >
> > the glibc fixes are good so go ahead bump the SRCREV to latest on 2.35
> > branch
>
> Agreed.
>
>
> >  major version backports are exceptions. We can consider doing mixin
> > layers if needed for say newer compiler.
>
>
> Answered above.
>
> Thanks Sundeep!
>
> ../Randy
>
>
> >
> >>
> >>
> >> Thanks,
> >> Sundeep K.
> >>
> >>
> >>
> >>
> >
> > 
> >
>
> --
> # Randy MacLeod
> # Wind River Linux
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170606): 
https://lists.openembedded.org/g/openembedded-core/message/170606
Mute This Topic: https://lists.openembedded.org/mt/92739561/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] binutils: stable 2.38 branch updates

[Randy MacLeod]

On 2022-09-13 12:59, Khem Raj wrote:

On 9/13/22 2:43 AM, Sundeep KOKKONDA wrote:

Hello,
I am planning to take the gcc, glibc & binutils updates to Kirkstone. 
I found only the glibc-2.35 branch is having a few updates (given 
below).
/f8ad66a4ca nscd: Fix netlink cache invalidation if epoll is used [BZ 
#29415]/

/9e960717e1 Apply asm redirections in wchar.h before first use/
/577c2fc7f3 elf: Call __libc_early_init for reused namespaces (bug 
29528)/

/83f1d9851e NEWS: Add entry for bug 28846/
/cbd8685e82 socket: Check lengths before advancing pointer in 
CMSG_NXTHDR/
/4bafc4001d alpha: Fix generic brk system call emulation in 
__brk_call (bug 29490)/

/37fd2ac665 stdlib: Fixup mbstowcs NULL __dst handling. [BZ #29279]/
/a1ec4157bc stdlib: Remove attr_write from mbstows if dst is NULL 
[BZ: 29265]/

/813a8d0171 Update syscall lists for Linux 5.19/
/e200127c6c riscv: Update rv64 libm test ulps/
/8c172a6cb0 dlfcn: Pass caller pointer to static dlopen 
implementation (bug 29446)/


Ideally you'd get that in this week since I think that 4.0.4 is being 
built on Monday, September 19th.


CCing Steve in case he missed this thread.


The binutils-2.38 has no new commits. And, gcc-11.x also not have any 
new release after 11.3.


That's good to know. I was just wondering if there was going to be 
gcc-11.4 so this info is timely.



In /master/ branch gcc_12.2, glibc_2.36 & binutils_2.39 versions are 
used. Kirkstone will continue to use the old versions?



To answer this more directly than Khem. ;-)

The Kirkstone branch will NOT update to the versions shown above. Users 
want a stable version


for the supported timeline of a release; some even may be surprised that 
we update from 11.2 to 11.3

even if it's all bug fixes.






the glibc fixes are good so go ahead bump the SRCREV to latest on 2.35 
branch


Agreed.


 major version backports are exceptions. We can consider doing mixin 
layers if needed for say newer compiler.



Answered above.

Thanks Sundeep!

../Randy







Thanks,
Sundeep K.










--
# Randy MacLeod
# Wind River Linux


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170605): 
https://lists.openembedded.org/g/openembedded-core/message/170605
Mute This Topic: https://lists.openembedded.org/mt/92739561/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] libxml2: don't override XML_CATALOG_FILES in xmllint wrapper if already set

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Richard Purdie
> Sent: den 12 september 2022 10:44
> To: Ross Burton ; 
> openembedded-core@lists.openembedded.org
> Cc: schnitzelt...@gmail.com
> Subject: Re: [OE-core] [PATCH] libxml2: don't override XML_CATALOG_FILES in 
> xmllint wrapper if already set
> 
> On Sun, 2022-09-11 at 23:21 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > On Fri, 2022-09-09 at 23:54 +0100, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Fri, 2022-09-09 at 17:36 +0100, Ross Burton wrote:
> > > > The KDE build uses custom catalogs by setting XML_CATALOG_FILES, so this
> > > > wrapper should not override that value if it has already been set.
> > > >
> > > > Signed-off-by: Ross Burton 
> > > > ---
> > > >  meta/recipes-core/libxml/libxml2_2.9.14.bb | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-core/libxml/libxml2_2.9.14.bb 
> > > > b/meta/recipes-core/libxml/libxml2_2.9.14.bb
> > > > index 2b2289e38a6..165c92d4114 100644
> > > > --- a/meta/recipes-core/libxml/libxml2_2.9.14.bb
> > > > +++ b/meta/recipes-core/libxml/libxml2_2.9.14.bb
> > > > @@ -121,7 +121,7 @@ do_install:append:class-native () {
> > > > # Docs are not needed in the native case
> > > > rm ${D}${datadir}/gtk-doc -rf
> > > >
> > > > -   create_wrapper ${D}${bindir}/xmllint 
> > > > XML_CATALOG_FILES=${sysconfdir}/xml/catalog
> > > > +   create_wrapper ${D}${bindir}/xmllint 
> > > > 'XML_CATALOG_FILES=${XML_CATALOG_FILES:-${sysconfdir}/xml/catalog}'
> > > >  }
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/5823/steps/24/logs/stdio
> >
> > Dependency on variable 
> > XML_CATALOG_FILES:-/media/build1/poky/build-st-282284/tmp-sstatesamehash/work/x86_64-linux/libxml2-native/2.9.14-r0/recipe-sysroot-native/etc/xml/catalog
> >  was added
> > Dependency on Variable 
> > XML_CATALOG_FILES:-/media/build1/poky/build-st-282284/tmp-sstatesamehash2/work/x86_64-linux/libxml2-native/2.9.14-r0/recipe-sysroot-native/etc/xml/catalog
> >  was removed
> >
> > i.e. it is expanding the variable in the keyname!
> 
> I tweaked the patch to exclude this variable for now. We probably need
> to think a bit more about what bitbake is considering a variable name
> though...
> 
> Cheers,
> 
> Richard

Hasn't this always been the case for shell variables where you need to 
use ${...} for one reason or another? I know I have changed a number of 
"${some_shell_variable}" to "$some_shell_variable" over the years to 
mitigate it a little, but that is obviously not possible for non-trivial 
cases of shell parameter expansions.

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170604): 
https://lists.openembedded.org/g/openembedded-core/message/170604
Mute This Topic: https://lists.openembedded.org/mt/93577134/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] binutils: stable 2.38 branch updates

[Khem Raj]

On 9/13/22 2:43 AM, Sundeep KOKKONDA wrote:

Hello,
I am planning to take the gcc, glibc & binutils updates to Kirkstone. I 
found only the glibc-2.35 branch is having a few updates (given below).
/f8ad66a4ca nscd: Fix netlink cache invalidation if epoll is used [BZ 
#29415]/

/9e960717e1 Apply asm redirections in wchar.h before first use/
/577c2fc7f3 elf: Call __libc_early_init for reused namespaces (bug 29528)/
/83f1d9851e NEWS: Add entry for bug 28846/
/cbd8685e82 socket: Check lengths before advancing pointer in CMSG_NXTHDR/
/4bafc4001d alpha: Fix generic brk system call emulation in __brk_call 
(bug 29490)/

/37fd2ac665 stdlib: Fixup mbstowcs NULL __dst handling. [BZ #29279]/
/a1ec4157bc stdlib: Remove attr_write from mbstows if dst is NULL [BZ: 
29265]/

/813a8d0171 Update syscall lists for Linux 5.19/
/e200127c6c riscv: Update rv64 libm test ulps/
/8c172a6cb0 dlfcn: Pass caller pointer to static dlopen implementation 
(bug 29446)/
The binutils-2.38 has no new commits. And, gcc-11.x also not have any 
new release after 11.3.
In /master/ branch gcc_12.2, glibc_2.36 & binutils_2.39 versions are 
used. Kirkstone will continue to use the old versions?




the glibc fixes are good so go ahead bump the SRCREV to latest on 2.35 
branch
 major version backports are exceptions. We can consider doing mixin 
layers if needed for say newer compiler.





Thanks,
Sundeep K.






OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170603): 
https://lists.openembedded.org/g/openembedded-core/message/170603
Mute This Topic: https://lists.openembedded.org/mt/92739561/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] elfutils: Enable ptests on musl targets

[Khem Raj]

Signed-off-by: Khem Raj 
---
 .../elfutils/elfutils_0.187.bb|   2 +-
 ...Add-libeu-to-tests-needing-error-API.patch | 147 ++
 2 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.187.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.187.bb
index 561112c580..aadff1a03c 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.187.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.187.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://run-ptest \
file://ptest.patch \

file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \
+   file://0001-tests-Add-libeu-to-tests-needing-error-API.patch \
"
 SRC_URI:append:libc-musl = " \
file://0003-musl-utils.patch \
@@ -29,7 +30,6 @@ SRC_URI:append:libc-musl = " \
 SRC_URI[sha256sum] = 
"e70b0dfbe610f90c4d1fe0d71af142a4e25c3c4ef9ebab8d2d72b65159d454c8"
 
 inherit autotools gettext ptest pkgconfig
-PTEST_ENABLED:libc-musl = "0"
 
 EXTRA_OECONF = "--program-prefix=eu-"
 
diff --git 
a/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
 
b/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
new file mode 100644
index 00..7c1bc87cbf
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/files/0001-tests-Add-libeu-to-tests-needing-error-API.patch
@@ -0,0 +1,147 @@
+From c05c787070a390a2061bfcb845e1e35e8b1373b3 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 13 Sep 2022 09:33:00 -0700
+Subject: [PATCH] tests: Add libeu to tests needing error() API
+
+A local error() impelmentation is used when libc does not provide it,
+therefore link in libeu.a which contains this function in tests needing
+error() API
+
+Upstream-Status: Submitted 
[https://sourceware.org/pipermail/elfutils-devel/2022q3/005375.html]
+Signed-off-by: Khem Raj 
+---
+ tests/Makefile.am | 60 +++
+ 1 file changed, 30 insertions(+), 30 deletions(-)
+
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 3943e17..1acc49b 100644
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -638,17 +638,17 @@ libeu = ../lib/libeu.a
+ arextract_LDADD = $(libelf)
+ arsymtest_LDADD = $(libelf)
+ newfile_LDADD = $(libelf)
+-saridx_LDADD = $(libelf)
++saridx_LDADD = $(libeu) $(libelf)
+ scnnames_LDADD = $(libelf)
+-sectiondump_LDADD = $(libelf)
++sectiondump_LDADD = $(libeu) $(libelf)
+ showptable_LDADD = $(libelf)
+ hash_LDADD = $(libelf)
+ test_nlist_CFLAGS =-g -O0 $(EXTRA_NLIST_CFLAGS)
+ test_nlist_LDADD = $(libelf)
+ msg_tst_LDADD = $(libelf)
+ newscn_LDADD = $(libelf)
+-early_offscn_LDADD = $(libelf)
+-ecp_LDADD = $(libelf)
++early_offscn_LDADD = $(libeu) $(libelf)
++ecp_LDADD = $(libeu) $(libelf)
+ update1_LDADD = $(libelf)
+ update2_LDADD = $(libelf)
+ update3_LDADD = $(libdw) $(libelf)
+@@ -662,12 +662,12 @@ get_files_LDADD = $(libdw) $(libelf)
+ next_files_LDADD = $(libdw) $(libelf)
+ get_aranges_LDADD = $(libdw) $(libelf)
+ allfcts_LDADD = $(libdw) $(libelf)
+-line2addr_LDADD = $(libdw) $(argp_LDADD)
+-addrscopes_LDADD = $(libdw) $(argp_LDADD)
+-funcscopes_LDADD = $(libdw) $(argp_LDADD)
+-funcretval_LDADD = $(libdw) $(argp_LDADD)
+-allregs_LDADD = $(libdw) $(argp_LDADD)
+-find_prologues_LDADD = $(libdw) $(argp_LDADD)
++line2addr_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++addrscopes_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++funcscopes_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++funcretval_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++allregs_LDADD = $(libeu) $(libdw) $(argp_LDADD)
++find_prologues_LDADD = $(libeu) $(libdw) $(argp_LDADD)
+ #show_ciefde_LDADD = ../libdwarf/libdwarf.so $(libelf)
+ asm_tst1_LDADD = $(libasm) $(libebl) $(libelf) $(libdw)
+ asm_tst2_LDADD = $(libasm) $(libebl) $(libelf) $(libdw)
+@@ -678,19 +678,19 @@ asm_tst6_LDADD = $(libasm) $(libebl) $(libelf) $(libdw)
+ asm_tst7_LDADD = $(libasm) $(libebl) $(libelf) $(libdw)
+ asm_tst8_LDADD = $(libasm) $(libebl) $(libelf) $(libdw)
+ asm_tst9_LDADD = $(libasm) $(libebl) $(libelf) $(libdw)
+-dwflmodtest_LDADD = $(libdw) $(libebl) $(libelf) $(argp_LDADD)
+-rdwrmmap_LDADD = $(libelf)
++dwflmodtest_LDADD = $(libeu) $(libdw) $(libebl) $(libelf) $(argp_LDADD)
++rdwrmmap_LDADD = $(libeu) $(libelf)
+ dwfl_bug_addr_overflow_LDADD = $(libdw) $(libebl) $(libelf)
+ arls_LDADD = $(libelf)
+-dwfl_bug_fd_leak_LDADD = $(libdw) $(libebl) $(libelf)
++dwfl_bug_fd_leak_LDADD = $(libeu) $(libdw) $(libebl) $(libelf)
+ dwfl_bug_report_LDADD = $(libdw) $(libebl) $(libelf)
+-dwfl_bug_getmodules_LDADD = $(libdw) $(libebl) $(libelf)
+-dwfl_addr_sect_LDADD = $(libdw) $(libebl) $(libelf) $(argp_LDADD)
++dwfl_bug_getmodules_LDADD = $(libeu) $(libdw) $(libebl) $(libelf)
++dwfl_addr_sect_LDADD = $(libeu) $(libdw) $(libebl) $(libelf) 

[OE-core] [kirkstone][PATCH 1/2] lighttpd: upgrade 1.4.64 -> 1.4.65

[Sakib Sajal]

From: wangmy 

Changelog:
==
  * [build] meson: fix typo in variable name
  * [build] autoconf: report if building with zstd
  * [build] meson -Dlua_version=... to specify lua ver
  * [core] avoid CCRandomGenerateBytes on MacOS <10.12 (fixes #3140)
  * [core] use diff var name w/ CCRandomGenerateBytes (fixes #3141)
  * [core] parse conf cmds with SHELL or /bin/sh
  * [core] fix HMAC with openssl 3.0
  * [mod_webdav] no COPYFILE_CLONE_FORCE on OSX <10.12 (fixes #3142)
  * [mod_deflate] fix to return 304 with If-None-Match (fixes #3143)
  * [core] Illumos epoll incompatible w/ lighttpd impl
  * [core] feature flag to allow Range w/ HTTP/1.0
  * [mod_mbedtls] set usekeysize for mbedtls 3.2.0+
  * [mod_deflate] collect mmap code
  * [mod_deflate] prototype using libdeflate w/ mmap
  * [mod_deflate] --with-libdeflate to use libdeflate
  * [mod_deflate] mark input bytes const
  * [core] sys-setjmp.[ch]
  * [mod_magnet] check lighty.result.content b4 setjmp
  * [core] include guard consistency in sys-time.h
  * [core] network_write_file_chunk_remap separate fn
  * [multiple] use new sys_setjmp_eval3() interface
  * [multiple] pedantic chunk.c checks for 0-len chunk
  * [multiple] shared code for struct chunk and mmap
  * [mod_deflate] use pread if available
  * [mod_deflate] improve loop compressing file chunk
  * [core] prep server_tag at startup for h2 resp hdr
  * [mod_magnet] defer req_env init unless needed
  * [mod_magnet] reset after error attaching content
  * [mod_magnet] lua_tointegerx() avoids raising error
  * [mod_mbedtls] use newer mbedtls 3.2.0+ interfaces
  * [mod_magnet] adjust hot path for more inlining
  * [mod_magnet] collect chk for magnet lua_State init
  * [mod_magnet] use type returned from lua_getfield()
  * [core] chunk_file_pread() to wrap pread()
  * [core] disable keep-alive if forcing HTTP/1.0 resp
  * [mod_magnet] use lua_getextraspace() to store r
  * [core] fall back to getauxval(AT_RANDOM), if avail
  * [mod_magnet] keep message handler on stack
  * [doc] update external links
  * [mod_magnet] pass lighty table index, defer pops
  * [mod_magnet] clear and reuse script-env table
  * [mod_magnet] clear stack when reloading script
  * [mod_magnet] use lua_isnoneornil() in interfaces
  * [mod_magnet] fix lighty.c.cookie_tokens()
  * [mod_magnet] fix lighty.c.urldec_query()
  * [mod_magnet] remove duplicated NULL checks
  * [mod_magnet] adjust magnet_lighty_result_get()
  * [mod_magnet] magnet_tmpbuf_acquire(),release()
  * [mod_magnet] lighty.c.quotedenc(),dec() funcs
  * [mod_magnet] fix header,content legacy table clear
  * [mod_cgi] cgi.local-redir request_reset thru fnptr
  * [core] isolate plugins_*() funcs to main server
  * [mod_wolfssl] wolfssl v5.0.0 defines DH_set0_pqg()
  * [mod_auth] save letter-case diff in require config
  * [mod_magnet] magnet_push_quoted_string shared code
  * [mod_magnet] lighty.c.header_tokens convenience fn
  * [core] fill in un.sun_path after accept() (fixes #3147)
  * [mod_extforward] adjust trust check for HTTP/2
  * [mod_proxy] adjust handling of legacy X-* headers
  * [core] permit env w/ blank value (fix regression)
  * [TLS] consistent debug.log-ssl-noise config type
  * [mod_magnet] allow removal of req_env elt via nil
  * [core] compiler workarounds for very old gcc,glibc
  * [mod_mbedtls] use newer mbedtls 3.2.0+ interfaces
  * [mod_ssi] check http_chunk_transfer_cqlen for err
  * [core] chunkqueue_steal() handle unexpected 0 len
  * [core] discard DATA from REFUSED_STREAM at h2 init
  * [multiple] WebSockets over HTTP/2 (fixes #3151)
  * [multiple] immed connect to backend for streaming
  * [core] ensure socket ready before checking connect
  * [core] reduce trace on Upgrade backend connection
  * [core] adjust when TCP_CORK used on TLS connection
  * [mod_cgi] disable input optim if might Upgrade
  * [mod_cgi] immed start CGI if Upgrade
  * [mod_wolfssl] wolfssl v5.0.0 adds ASN1_TIME_diff()
  * [mod_openssl] libressl v3.5.0 adds ASN1_TIME_diff
  * [TLS] warn if leaf cert read is inactive/expired
  * [core] stricter conformance w/ upcoming HTTP/2 rev
  * [build] -D_DEFAULT_SOURCE consistency in builds
  * [mod_extforward] support addtl IPv6 syntax w/ "[]"
  * [core] build fix for cygwin and lmingw
  * [core] short-circuit earlier parsing h2 trailers
  * [core] reformat h2.h for cleaner enum additions
  * [core] consolidate trace for log-state-handling
  * [core] request_config bitmasks for smaller struct
  * [core] prefix (=^), suffix (=$) config conditions (fixes #3153)
  * [core] tighten config parsing loop
  * [core] convert simple config cond regex to pre/sfx
  * [tests] able to run tests when built w/o pcre
  * [core] allow redirect,rewrite ext subst w/o pcre
  * [mod_sockproxy] reset http vers, avoid rare crash (fixes #3152)
  * [core] HTTP/2 PRIORITY_UPDATE frame (experimental)
  * [core] send HTTP/2 SETTINGS_NO_RFC7540_PRIORITIES
  * [core] stricter check of HTTP/2 GOAWAY frame size
  * [mod_mbedtls] use newer mbedtls 

[OE-core] [kirkstone][PATCH 2/2] lighttpd: upgrade 1.4.65 -> 1.4.66

[Sakib Sajal]

From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit 3163134b0f58c58aaabe4e957c30109e63b2d60f)
Signed-off-by: Sakib Sajal 
---
 .../lighttpd/{lighttpd_1.4.65.bb => lighttpd_1.4.66.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-extended/lighttpd/{lighttpd_1.4.65.bb => 
lighttpd_1.4.66.bb} (97%)

diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.65.bb 
b/meta/recipes-extended/lighttpd/lighttpd_1.4.66.bb
similarity index 97%
rename from meta/recipes-extended/lighttpd/lighttpd_1.4.65.bb
rename to meta/recipes-extended/lighttpd/lighttpd_1.4.66.bb
index 10aa27f072..801162867c 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.65.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.66.bb
@@ -19,7 +19,7 @@ SRC_URI = 
"http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.t
file://lighttpd \
"
 
-SRC_URI[sha256sum] = 
"bf0fa68a629fbc404023a912b377e70049331d6797bcbb4b3e8df4c3b42328be"
+SRC_URI[sha256sum] = 
"47ac6e60271aa0196e65472d02d019556dc7c6d09df3b65df2c1ab6866348e3b"
 
 DEPENDS = "virtual/crypt"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170601): 
https://lists.openembedded.org/g/openembedded-core/message/170601
Mute This Topic: https://lists.openembedded.org/mt/93658479/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 24/24] npm: use npm_registry to cache package

[Martin Jansa]

FWIW: this depends on meta-oe change to add meta-oe-cache-native as
reported in:
https://github.com/openembedded/meta-openembedded/issues/606
I've sent the backport request for meta-oe/kirkstone:
https://lists.openembedded.org/g/openembedded-devel/message/98787

On Wed, Sep 7, 2022 at 4:21 PM Steve Sakoman  wrote:

> From: Enrico Scholz 
>
> With nodejs 16, the simple 'npm cache add' approach does not work
> anymore because its fetcher implementation downloads also meta
> information from the registry.
>
> We have to generate these information and add them to the cache.
> There is no direct support in 'npm' for task so we have to implement
> it manually.
>
> This implementation consists of a openembedded python module (in
> oe-core) and a nodejs version specific helper (in oe-meta).
>
> Signed-off-by: Enrico Scholz 
> Signed-off-by: Richard Purdie 
> (cherry picked from commit 019b9c341d539939098962c228c1fd5c99331312)
> Signed-off-by: Steve Sakoman 
> ---
>  meta/classes/npm.bbclass | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
> index 11c80a738e..8379c7b988 100644
> --- a/meta/classes/npm.bbclass
> +++ b/meta/classes/npm.bbclass
> @@ -19,7 +19,7 @@
>
>  inherit python3native
>
> -DEPENDS:prepend = "nodejs-native "
> +DEPENDS:prepend = "nodejs-native nodejs-oe-cache-native "
>  RDEPENDS:${PN}:append:class-target = " nodejs"
>
>  EXTRA_OENPM = ""
> @@ -46,6 +46,7 @@ NPM_ARCH ?=
> "${@npm_target_arch_map(d.getVar("TARGET_ARCH"))}"
>  NPM_PACKAGE = "${WORKDIR}/npm-package"
>  NPM_CACHE = "${WORKDIR}/npm-cache"
>  NPM_BUILD = "${WORKDIR}/npm-build"
> +NPM_REGISTRY = "${WORKDIR}/npm-registry"
>
>  def npm_global_configs(d):
>  """Get the npm global configuration"""
> @@ -109,16 +110,18 @@ python npm_do_configure() {
>  from bb.fetch2.npm import npm_unpack
>  from bb.fetch2.npmsw import foreach_dependencies
>  from bb.progress import OutOfProgressHandler
> +from oe.npm_registry import NpmRegistry
>
>  bb.utils.remove(d.getVar("NPM_CACHE"), recurse=True)
>  bb.utils.remove(d.getVar("NPM_PACKAGE"), recurse=True)
>
>  env = NpmEnvironment(d, configs=npm_global_configs(d))
> +registry = NpmRegistry(d.getVar('NPM_REGISTRY'),
> d.getVar('NPM_CACHE'))
>
> -def _npm_cache_add(tarball):
> -"""Run 'npm cache add' for a specified tarball"""
> -cmd = "npm cache add %s" % shlex.quote(tarball)
> -env.run(cmd)
> +def _npm_cache_add(tarball, pkg):
> +"""Add tarball to local registry and register it in the
> +   cache"""
> +registry.add_pkg(tarball, pkg)
>
>  def _npm_integrity(tarball):
>  """Return the npm integrity of a specified tarball"""
> @@ -182,7 +185,7 @@ python npm_do_configure() {
>  # Add the dependency to the npm cache
>  destdir = os.path.join(d.getVar("S"), destsuffix)
>  (tarball, pkg) = npm_pack(env, destdir, tmpdir)
> -_npm_cache_add(tarball)
> +_npm_cache_add(tarball, pkg)
>  # Add its signature to the cached shrinkwrap
>  dep = _npmsw_dependency_dict(cached_shrinkwrap, deptree)
>  dep["version"] = pkg['version']
> --
> 2.25.1
>
>
> 
>
>

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

[OE-core] Yocto Project Status 13 September 2022 (WW37)

[Stephen Jolley]

Current Dev Position: YP 4.1 M4 (Feature Freeze)

Next Deadline: 3rd October 2022 YP 4.1 M4 Build 

 

Next Team Meetings:

*   Bug Triage meeting Thursday September 22nd 7:30 am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Weekly Project Engineering Sync Tuesday September 20th at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See  
https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   4.1 M3 rc2 is in QA
*   4.1 M3 rc1 was abandoned after it failed to build due to a number of
intermittent issues including:

*   virtio block device issues in qemu we're hoping are fixed in qemu
7.1.0
*   debuginfod host contamination
*   recurrence of the libgcrypt ptest issues
*   problems with the fetcher race fix

Thanks to everyone who helped debug and/or fix these.

*   Builds are now running more reliably on the autobuilder but we're
still seeing some timeout issues
*   CVE counts are high on all branches at present. Steve Sakoman has
kindly put some encouragement in place for those helping dunfell with CVE
issues, see the mailing list for details.
*   Help is very much welcome in trying to resolve our autobuilder
intermittent issues. You can see the list of failures we're continuing to
see by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 4.1. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.1_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.
*   Help us resolve CVE issues:
 CVE metrics 

 

YP 4.1 Milestone Dates:

*   YP 4.1 M3 built and in QA
*   YP 4.1 M3 Release date 2022/09/02
*   YP 4.1 M4 build date 2022/10/03
*   YP 4.1 M4 Release date 2022/10/28

 

Upcoming dot releases:

*   YP 4.0.4 build date 2022/09/19
*   YP 4.0.4 Release date 2022/09/30
*   YP 3.1.20 build date 2022/10/10
*   YP 3.1.20 Release date 2022/10/21
*   YP 4.0.5 build date 2022/10/31
*   YP 4.0.5 Release date 2022/11/11

 

Tracking Metrics:

*   WDD 2424 (last week 2459) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1209 (last week 1221)
*   Patches in the Pending State: 311 (26%) [last week 314 (26%)]

*
https://autobuilder.yocto.io/pub/non-release/patchmetrics/

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170598): 
https://lists.openembedded.org/g/openembedded-core/message/170598
Mute This Topic: https://lists.openembedded.org/mt/93657986/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] python3: add PACKAGECONFIG[editline]

[Etienne Cordonnier via lists.openembedded.org]

editline is a BSD alternative for readline which is GPLv3.

Signed-off-by: Etienne Cordonnier 
---
 meta/recipes-devtools/python/python3_3.10.6.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3_3.10.6.bb 
b/meta/recipes-devtools/python/python3_3.10.6.bb
index 1b28728732..1f8b60a7a5 100644
--- a/meta/recipes-devtools/python/python3_3.10.6.bb
+++ b/meta/recipes-devtools/python/python3_3.10.6.bb
@@ -105,6 +105,7 @@ PACKAGECONFIG:class-target ??= "readline gdbm 
${@bb.utils.filter('DISTRO_FEATURE
 PACKAGECONFIG:class-native ??= "readline gdbm"
 PACKAGECONFIG:class-nativesdk ??= "readline gdbm"
 PACKAGECONFIG[readline] = ",,readline"
+PACKAGECONFIG[editline] = "--with-readline=editline,,libedit,,,readline"
 # Use profile guided optimisation by running PyBench inside qemu-user
 PACKAGECONFIG[pgo] = "--enable-optimizations,,qemu-native"
 PACKAGECONFIG[tk] = ",,tk"
-- 
2.36.1.vfs.0.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170597): 
https://lists.openembedded.org/g/openembedded-core/message/170597
Mute This Topic: https://lists.openembedded.org/mt/93657764/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] python3: add PACKAGECONFIG[editline]

[Etienne Cordonnier via lists.openembedded.org]

Hi Quentin,

yes, editline is replacing readline in python3, even though editline may
have slightly less functionality than readline. I'll edit the patch to add
a conflict between editline and readline.

Thanks,
Etienne

On Tue, Sep 13, 2022 at 2:53 PM Quentin Schulz <
quentin.sch...@theobroma-systems.com> wrote:

> Hi Etienne,
>
> On 9/13/22 14:39, Etienne Cordonnier via lists.openembedded.org wrote:
> > editline is a BSD alternative for readline which is GPLv3.
> >
> > Signed-off-by: Etienne Cordonnier 
> > ---
> >   meta/recipes-devtools/python/python3_3.10.6.bb | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-devtools/python/python3_3.10.6.bb
> b/meta/recipes-devtools/python/python3_3.10.6.bb
> > index 1b28728732..6c4ef5c7d1 100644
> > --- a/meta/recipes-devtools/python/python3_3.10.6.bb
> > +++ b/meta/recipes-devtools/python/python3_3.10.6.bb
> > @@ -105,6 +105,7 @@ PACKAGECONFIG:class-target ??= "readline gdbm
> ${@bb.utils.filter('DISTRO_FEATURE
> >   PACKAGECONFIG:class-native ??= "readline gdbm"
> >   PACKAGECONFIG:class-nativesdk ??= "readline gdbm"
> >   PACKAGECONFIG[readline] = ",,readline"
> > +PACKAGECONFIG[editline] = "--with-readline=editline,,libedit"
>
> Is libedit supposed to replace readline entirely in python3? If so, I'm
> wondering if it'd make sense to make readline and editline
> PACKAGECONFIG's packageconfig-conflicts-for-f1 the other so that we
> cannot have both configs enabled at the same time?
>
> C.f. last entry in
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_ref-2Dmanual_variables.html-23term-2DPACKAGECONFIG=DwICaQ=ncDTmphkJTvjIDPh0hpF_4vCHvabgGkICC2epckfdiw=AhkbNonVuMIGRfPx_Qj9TsyDLWdbBqarUzFxz3aALck=BI7ofOMnjkh-6dMCoBr-4L0qc7YYUHte9BK2ektyAy1jXC5OrzARmRie0aBAbBBB=1TEeBYT7HqMmOf5tqLzvd2rnYTyFAx8GHJy2vewKbMA=
>
>
> Cheers,
> Quentin
>
> >   # Use profile guided optimisation by running PyBench inside qemu-user
> >   PACKAGECONFIG[pgo] = "--enable-optimizations,,qemu-native"
> >   PACKAGECONFIG[tk] = ",,tk"
> >
> >
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170596): 
https://lists.openembedded.org/g/openembedded-core/message/170596
Mute This Topic: https://lists.openembedded.org/mt/93654164/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 16/16] runqemu: display host uptime when starting

[Steve Sakoman]

From: Alexandre Belloni 

In order to be able to debug issues on the host that have an impact on the
guest, it is useful to get the uptime of the host while starting so we can
match with the events in dmesg. Also include the uptime when cleaning up.

Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit 2d96499823f7de6e16a461426491e015ba63c1ec)
Signed-off-by: Steve Sakoman 
---
 scripts/runqemu | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/scripts/runqemu b/scripts/runqemu
index 24c4a40b50..1525081ad5 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1500,6 +1500,9 @@ class BaseConfig(object):
 cmd = "%s %s" % (self.qemu_opt, kernel_opts)
 cmds = shlex.split(cmd)
 logger.info('Running %s\n' % cmd)
+with open('/proc/uptime', 'r') as f:
+uptime_seconds = f.readline().split()[0]
+logger.info('Host uptime: %s\n' % uptime_seconds)
 pass_fds = []
 if self.taplock_descriptor:
 pass_fds = [self.taplock_descriptor.fileno()]
@@ -1523,6 +1526,9 @@ class BaseConfig(object):
 signal.signal(signal.SIGTERM, signal.SIG_IGN)
 
 logger.info("Cleaning up")
+with open('/proc/uptime', 'r') as f:
+uptime_seconds = f.readline().split()[0]
+logger.info('Host uptime: %s\n' % uptime_seconds)
 if self.cleantap:
 cmd = ('sudo', self.qemuifdown, self.tap, self.bindir_native)
 logger.debug('Running %s' % str(cmd))
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170595): 
https://lists.openembedded.org/g/openembedded-core/message/170595
Mute This Topic: https://lists.openembedded.org/mt/93656196/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 15/16] oeqa: qemurunner: Report UNIX Epoch timestamp on login

[Steve Sakoman]

From: Joshua Watt 

Updates the log message printed when login banner is seen in QEMU to
report the UNIX Epoch time in addition to the human readable time. This
makes it much easier and accurate to correlate logs with the guest, in
particular with the guest journalctl which prints log timestamps in
human readable format and the oeqa SSH debug logging which prints the
UNIX Epoch.

Signed-off-by: Joshua Watt 
Signed-off-by: Richard Purdie 
(cherry picked from commit 275b6f3c8d0eeafa3902c48a49655491a89c47bc)
Signed-off-by: Steve Sakoman 
---
 meta/lib/oeqa/utils/qemurunner.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 4c3d2010fb..c19164e6e7 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -471,9 +471,9 @@ class QemuRunner:
 self.server_socket = qemusock
 stopread = True
 reachedlogin = True
-self.logger.debug("Reached login banner in %s 
seconds (%s)" %
+self.logger.debug("Reached login banner in %s 
seconds (%s, %s)" %
   (time.time() - (endtime - 
self.boottime),
-  time.strftime("%D %H:%M:%S")))
+  time.strftime("%D %H:%M:%S"), 
time.time()))
 else:
 # no need to check if reachedlogin unless we support 
multiple connections
 self.logger.debug("QEMU socket disconnected before 
login banner reached. (%s)" %
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170594): 
https://lists.openembedded.org/g/openembedded-core/message/170594
Mute This Topic: https://lists.openembedded.org/mt/93656191/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 14/16] externalsrc: Don't wipe out src dir when EXPORT_FUNCTIONS is used.

[Steve Sakoman]

From: Kristian Amlie 

When 73fa855f6af5ef9c3 was introduced, the "cleandirs" variable flag
started applying to functions exported using EXPORT_FUNCTIONS.
The externalsrc class is supposed to remove cleandirs in order to
prevent wiping out an external src folder (home directory?), but
doesn't take the previous point into account. The result is that
cleandirs is still in effect.

To fix this, apply the cleandirs manipulation to all variables, not
just predefined ones. This is expensive, but since it executes inside
an `if externalsrc` clause, and EXTERNALSRC is usually only set for
specific single recipes, it won't affect most recipes.

Richard Purdie  is the original
author of this patch. I just submitted it under my name for blame
purposes, and also we have been testing it a lot in my company.

This is the original discussion:
https://lists.openembedded.org/g/openembedded-core/topic/91374926

Signed-off-by: Kristian Amlie 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit 74ad497a55007960a4869905878e3ccbd11e4369)
Signed-off-by: Steve Sakoman 
---
 meta/classes/externalsrc.bbclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 90792a737b..8136d25cb1 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -90,16 +90,18 @@ python () {
 # Since configure will likely touch ${S}, ensure only we lock 
so one task has access at a time
 d.appendVarFlag(task, "lockfiles", " ${S}/singletask.lock")
 
-for funcname in [task, "base_" + task, "kernel_" + task]:
+for v in d.keys():
+cleandirs = d.getVarFlag(v, "cleandirs", False)
+if cleandirs:
 # We do not want our source to be wiped out, ever 
(kernel.bbclass does this for do_clean)
-cleandirs = 
oe.recipeutils.split_var_value(d.getVarFlag(funcname, 'cleandirs', False) or '')
+cleandirs = oe.recipeutils.split_var_value(cleandirs)
 setvalue = False
 for cleandir in cleandirs[:]:
 if oe.path.is_path_parent(externalsrc, d.expand(cleandir)):
 cleandirs.remove(cleandir)
 setvalue = True
 if setvalue:
-d.setVarFlag(funcname, 'cleandirs', ' '.join(cleandirs))
+d.setVarFlag(v, 'cleandirs', ' '.join(cleandirs))
 
 fetch_tasks = ['do_fetch', 'do_unpack']
 # If we deltask do_patch, there's no dependency to ensure do_unpack 
gets run, so add one
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170593): 
https://lists.openembedded.org/g/openembedded-core/message/170593
Mute This Topic: https://lists.openembedded.org/mt/93656185/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 13/16] rootfs.py: dont try to list installed packages for baremetal images

[Steve Sakoman]

From: Alejandro Hernandez Samaniego 

Theres not a rootfs for baremetal images, hence we should avoid
trying to list rootfs packages for them.

This fixes an issue where some classes (e.g. license_image) rely on
rootfs functionality when included for baremetal images even if its
nonexistent

Signed-off-by: Alejandro Enedino Hernandez Samaniego 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit 5a7e13f46083ce3b08aa762238c1e93b7626dda4)
Signed-off-by: Steve Sakoman 
---
 meta/lib/oe/rootfs.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 9e6b411fb6..91312f8353 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -384,6 +384,10 @@ def create_rootfs(d, manifest_dir=None, 
progress_reporter=None, logcatcher=None)
 
 
 def image_list_installed_packages(d, rootfs_dir=None):
+# Theres no rootfs for baremetal images
+if bb.data.inherits_class('baremetal-image', d):
+return ""
+
 if not rootfs_dir:
 rootfs_dir = d.getVar('IMAGE_ROOTFS')
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170592): 
https://lists.openembedded.org/g/openembedded-core/message/170592
Mute This Topic: https://lists.openembedded.org/mt/93656183/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 12/16] cairo: Adapt the license information based on what is being built

[Steve Sakoman]

From: Peter Kjellerstedt 

If the "trace" PACKAGECONFIG is removed to disable cairo-trace (the
only part of the code licensed as GPL-3.0), we can adapt the licenses
for cairo-dbg and cairo-src so that they do not include
"GPL-3.0-or-later" and thus they can be used also when, e.g., GPL-3.0
is blacklisted in INCOMPATIBLE_LICENSE. Also drop the GPL-3.0 license
text from LIC_FILES_CHKSUM in this case.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit 4f0ea44c80f297d00349b7d3cf9438145aec8a74)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-graphics/cairo/cairo_1.16.0.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cairo/cairo_1.16.0.bb 
b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
index 67081bb8cb..ffb813d290 100644
--- a/meta/recipes-graphics/cairo/cairo_1.16.0.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
@@ -17,9 +17,13 @@ LICENSE:${PN}-doc = "MPL-1.1 | LGPL-2.1-only"
 LICENSE:${PN}-gobject = "MPL-1.1 | LGPL-2.1-only"
 LICENSE:${PN}-script-interpreter = "MPL-1.1 | LGPL-2.1-only"
 LICENSE:${PN}-perf-utils = "GPL-3.0-or-later"
+# Adapt the licenses for cairo-dbg and cairo-src depending on whether
+# cairo-trace is being built.
+LICENSE:${PN}-dbg = "(MPL-1.1 | 
LGPL-2.1-only)${@bb.utils.contains('PACKAGECONFIG', 'trace', ' & 
GPL-3.0-or-later', '', d)}"
+LICENSE:${PN}-src = "(MPL-1.1 | 
LGPL-2.1-only)${@bb.utils.contains('PACKAGECONFIG', 'trace', ' & 
GPL-3.0-or-later', '', d)}"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=e73e999e0c72b5ac9012424fa157ad77 \
-
file://util/cairo-trace/COPYING-GPL-3;md5=d32239bcb673463ab874e80d47fae504"
+${@bb.utils.contains('PACKAGECONFIG', 'trace', 
'file://util/cairo-trace/COPYING-GPL-3;md5=d32239bcb673463ab874e80d47fae504', 
'', d)}"
 
 
 DEPENDS = "fontconfig glib-2.0 libpng pixman zlib"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170591): 
https://lists.openembedded.org/g/openembedded-core/message/170591
Mute This Topic: https://lists.openembedded.org/mt/93656182/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 11/16] rootfs-postcommands.bbclass: avoid moving ssh host keys if etc is writable

[Steve Sakoman]

From: Peter Bergin 

When using IMAGE_FEATURE read-only-rootfs ssh host keys are moved to volatile
storage. If the feature overlayfs-etc is used in addition to read-only-rootfs
/etc is writable and the move is not wanted. But in the case also the 
IMAGE_FEATURE
stateless-rootfs is used the keys will be moved as storage of keys should not
be wanted in a stateless-rootfs.

This change only takes effect in the case IMAGE_FEATURE contains 
read-only-rootfs.
In adddition the following cases are handled:

  IMAGE_FEATURES = "read-only-rootfs" --> ssh keys/config handled as ro root
  IMAGE_FEATURES = "read-only-rootfs overlayfs-etc" --> ssh keys/config handled 
as rw root
  IMAGE_FEATURES = "read-only-rootfs stateless-rootfs" --> ssh keys/config 
handled as ro root
  IMAGE_FEATURES = "read-only-rootfs overlayfs-etc stateless-rootfs" --> ssh 
keys/config handled as ro root

Signed-off-by: Peter Bergin 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit d2ad7aa1f2153955adc044ea4eb11c48086a01d1)
Signed-off-by: Steve Sakoman 
---
 meta/classes/rootfs-postcommands.bbclass | 30 ++--
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index a59d9b5878..5c0b3ec37c 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -14,7 +14,7 @@ ROOTFS_POSTPROCESS_COMMAND += 
'${@bb.utils.contains_any("IMAGE_FEATURES", [ 'deb
 # Create /etc/timestamp during image construction to give a reasonably sane 
default time setting
 ROOTFS_POSTPROCESS_COMMAND += "rootfs_update_timestamp; "
 
-# Tweak the mount options for rootfs in /etc/fstab if read-only-rootfs is 
enabled
+# Tweak files in /etc if read-only-rootfs is enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", 
"read-only-rootfs", "read_only_rootfs_hook; ", "",d)}'
 
 # We also need to do the same for the kernel boot parameters,
@@ -103,20 +103,24 @@ read_only_rootfs_hook () {
# If we're using openssh and the /etc/ssh directory has no 
pre-generated keys,
# we should configure openssh to use the configuration file 
/etc/ssh/sshd_config_readonly
# and the keys under /var/run/ssh.
-   if [ -d ${IMAGE_ROOTFS}/etc/ssh ]; then
-   if [ -e ${IMAGE_ROOTFS}/etc/ssh/ssh_host_rsa_key ]; then
-   echo "SYSCONFDIR=\${SYSCONFDIR:-/etc/ssh}" >> 
${IMAGE_ROOTFS}/etc/default/ssh
-   echo "SSHD_OPTS=" >> ${IMAGE_ROOTFS}/etc/default/ssh
-   else
-   echo "SYSCONFDIR=\${SYSCONFDIR:-/var/run/ssh}" >> 
${IMAGE_ROOTFS}/etc/default/ssh
-   echo "SSHD_OPTS='-f /etc/ssh/sshd_config_readonly'" >> 
${IMAGE_ROOTFS}/etc/default/ssh
+   # If overlayfs-etc is used this is not done as /etc is treated as 
writable
+   # If stateless-rootfs is enabled this is always done as we don't want 
to save keys then
+   if ${@ 'true' if not bb.utils.contains('IMAGE_FEATURES', 
'overlayfs-etc', True, False, d) or bb.utils.contains('IMAGE_FEATURES', 
'stateless-rootfs', True, False, d) else 'false'}; then
+   if [ -d ${IMAGE_ROOTFS}/etc/ssh ]; then
+   if [ -e ${IMAGE_ROOTFS}/etc/ssh/ssh_host_rsa_key ]; then
+   echo "SYSCONFDIR=\${SYSCONFDIR:-/etc/ssh}" >> 
${IMAGE_ROOTFS}/etc/default/ssh
+   echo "SSHD_OPTS=" >> 
${IMAGE_ROOTFS}/etc/default/ssh
+   else
+   echo "SYSCONFDIR=\${SYSCONFDIR:-/var/run/ssh}" 
>> ${IMAGE_ROOTFS}/etc/default/ssh
+   echo "SSHD_OPTS='-f 
/etc/ssh/sshd_config_readonly'" >> ${IMAGE_ROOTFS}/etc/default/ssh
+   fi
fi
-   fi
 
-   # Also tweak the key location for dropbear in the same way.
-   if [ -d ${IMAGE_ROOTFS}/etc/dropbear ]; then
-   if [ ! -e ${IMAGE_ROOTFS}/etc/dropbear/dropbear_rsa_host_key ]; 
then
-   echo "DROPBEAR_RSAKEY_DIR=/var/lib/dropbear" >> 
${IMAGE_ROOTFS}/etc/default/dropbear
+   # Also tweak the key location for dropbear in the same way.
+   if [ -d ${IMAGE_ROOTFS}/etc/dropbear ]; then
+   if [ ! -e 
${IMAGE_ROOTFS}/etc/dropbear/dropbear_rsa_host_key ]; then
+   echo "DROPBEAR_RSAKEY_DIR=/var/lib/dropbear" >> 
${IMAGE_ROOTFS}/etc/default/dropbear
+   fi
fi
fi
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170590): 
https://lists.openembedded.org/g/openembedded-core/message/170590
Mute This Topic: https://lists.openembedded.org/mt/93656180/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 

[OE-core][kirkstone 10/16] core-image.bbclass: Exclude openssh complementary packages

[Steve Sakoman]

From: Pavel Zhukov 

Openssh (main) package may be marked for installation via complementary
packages mechanism if sftp-server is installed
and this causes conflict with dropbear [Yocto #14858] [1].
Excluding openssh complementary packages if packagegroup-core-ssh-dropbear
is in PACKAGE_INSTALL fixes this issue.
To install openssh complementary packages in the images with
ssh-server-dropbear they may be added manually into the list because
they will be excluded from the installation even if corresonding class
(dev-pkg or dbg-pkgs) inherited.

[1]
Error:
 Problem: problem with installed package dropbear-2020.81-r0.core2_64
  - package dropbear-2020.81-r0.core2_64 conflicts with openssh provided by 
openssh-8.9p1-r0.core2_64
  - package openssh-8.9p1-r0.core2_64 conflicts with dropbear provided by 
dropbear-2020.81-r0.core2_64
  - package openssh-ptest-8.9p1-r0.core2_64 requires openssh, but none of the 
providers can be installed
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages)

Signed-off-by: Pavel Zhukov 
Signed-off-by: Pavel Zhukov 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit fa08030b32c2bf77889c23f964892f46e84994a3)
Signed-off-by: Steve Sakoman 
---
 meta/classes/core-image.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass
index 84fd3eeb38..740a6c1d3d 100644
--- a/meta/classes/core-image.bbclass
+++ b/meta/classes/core-image.bbclass
@@ -59,6 +59,10 @@ FEATURE_PACKAGES_hwcodecs = "${MACHINE_HWCODECS}"
 # IMAGE_FEATURES_REPLACES_foo = 'bar1 bar2'
 # Including image feature foo would replace the image features bar1 and bar2
 IMAGE_FEATURES_REPLACES_ssh-server-openssh = "ssh-server-dropbear"
+# Do not install openssh complementary packages if either 
packagegroup-core-ssh-dropbear or dropbear
+# is installed # to avoid openssh-dropbear conflict
+# see [Yocto #14858] for more information
+PACKAGE_EXCLUDE_COMPLEMENTARY:append = 
"${@bb.utils.contains_any('PACKAGE_INSTALL', 'packagegroup-core-ssh-dropbear 
dropbear', 'openssh', '' , d)}"
 
 # IMAGE_FEATURES_CONFLICTS_foo = 'bar1 bar2'
 # An error exception would be raised if both image features foo and bar1(or 
bar2) are included
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170589): 
https://lists.openembedded.org/g/openembedded-core/message/170589
Mute This Topic: https://lists.openembedded.org/mt/93656179/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 09/16] libxml2: Port gentest.py to Python-3

[Steve Sakoman]

From: Martin Jansa 

* but it still won't work well on hosts without libxml2, make
  sure to use pre-generated testapi.c in do_compile_ptest

* this is reproducible with SOURCE_DATE_EPOCH set to 0 which
  e.g. meta-updater still sets by default for DISTROs which
  use it :(, see https://github.com/uptane/meta-updater/pull/35

Signed-off-by: Steve Sakoman 
Signed-off-by: Martin Jansa 
Signed-off-by: Richard Purdie 
(cherry picked from commit 178cea1593dc6e9a7eb74842615356d90d79f78f)
Signed-off-by: Steve Sakoman 
---
 .../0001-Port-gentest.py-to-Python-3.patch| 814 ++
 meta/recipes-core/libxml/libxml2_2.9.14.bb|  11 +
 2 files changed, 825 insertions(+)
 create mode 100644 
meta/recipes-core/libxml/libxml2/0001-Port-gentest.py-to-Python-3.patch

diff --git 
a/meta/recipes-core/libxml/libxml2/0001-Port-gentest.py-to-Python-3.patch 
b/meta/recipes-core/libxml/libxml2/0001-Port-gentest.py-to-Python-3.patch
new file mode 100644
index 00..c6567ac878
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/0001-Port-gentest.py-to-Python-3.patch
@@ -0,0 +1,814 @@
+From 2c20198b1ddb1bfb47269b8caf929ffb83748f78 Mon Sep 17 00:00:00 2001
+From: Nick Wellnhofer 
+Date: Thu, 21 Apr 2022 00:45:58 +0200
+Subject: [PATCH] Port gentest.py to Python 3
+
+Upstream-Status: Backport 
[https://gitlab.gnome.org/GNOME/libxml2/-/commit/343fc1421cdae097fa6c4cffeb1a065a40be6bbb]
+
+* fixes:
+
+make[1]: 'testReader' is up to date.
+  File "../libxml2-2.9.10/gentest.py", line 11
+print "libxml2 python bindings not available, skipping testapi.c 
generation"
+  ^
+SyntaxError: Missing parentheses in call to 'print'. Did you mean 
print("libxml2 python bindings not available, skipping testapi.c generation")?
+make[1]: [Makefile:2078: testapi.c] Error 1 (ignored)
+
+...
+
+make[1]: 'testReader' is up to date.
+  File "../libxml2-2.9.10/gentest.py", line 271
+return 1
+   ^
+TabError: inconsistent use of tabs and spaces in indentation
+make[1]: [Makefile:2078: testapi.c] Error 1 (ignored)
+
+...
+
+aarch64-oe-linux-gcc: error: testapi.c: No such file or directory
+aarch64-oe-linux-gcc: fatal error: no input files
+compilation terminated.
+make[1]: *** [Makefile:1275: testapi.o] Error 1
+
+But there is still a bit mystery why it worked before, because check-am
+calls gentest.py with $(PYTHON), so it ignores the shebang in the script
+and libxml2 is using python3native (through python3targetconfig.bbclass)
+so something like:
+
+libxml2/2.9.10-r0/recipe-sysroot-native/usr/bin/python3-native/python3 
gentest.py
+
+But that still fails (now without SyntaxError) with:
+libxml2 python bindings not available, skipping testapi.c generation
+
+because we don't have dependency on libxml2-native (to provide libxml2
+python bindings form python3native) and exported PYTHON_SITE_PACKAGES
+might be useless (e.g. /usr/lib/python3.8/site-packages on Ubuntu-22.10
+which uses python 3.10 and there is no site-packages with libxml2)
+
+Signed-off-by: Martin Jansa 
+
+---
+ gentest.py | 421 ++---
+ 1 file changed, 209 insertions(+), 212 deletions(-)
+
+diff --git a/gentest.py b/gentest.py
+index b6cd866..af15a4f 100755
+--- a/gentest.py
 b/gentest.py
+@@ -8,7 +8,7 @@ import string
+ try:
+ import libxml2
+ except:
+-print "libxml2 python bindings not available, skipping testapi.c 
generation"
++print("libxml2 python bindings not available, skipping testapi.c 
generation")
+ sys.exit(0)
+ 
+ if len(sys.argv) > 1:
+@@ -227,7 +227,7 @@ extra_post_call = {
+   if (old != NULL) {
+   xmlUnlinkNode(old);
+   xmlFreeNode(old) ; old = NULL ; }
+-ret_val = NULL;""",
++\t  ret_val = NULL;""",
+"xmlTextMerge": 
+"""if ((first != NULL) && (first->type != XML_TEXT_NODE)) {
+   xmlUnlinkNode(second);
+@@ -236,7 +236,7 @@ extra_post_call = {
+"""if ((ret_val != NULL) && (ret_val != ncname) &&
+   (ret_val != prefix) && (ret_val != memory))
+   xmlFree(ret_val);
+-ret_val = NULL;""",
++\t  ret_val = NULL;""",
+"xmlNewDocElementContent":
+"""xmlFreeDocElementContent(doc, ret_val); ret_val = NULL;""",
+"xmlDictReference": "xmlDictFree(dict);",
+@@ -268,29 +268,29 @@ modules = []
+ def is_skipped_module(name):
+ for mod in skipped_modules:
+ if mod == name:
+-  return 1
++return 1
+ return 0
+ 
+ def is_skipped_function(name):
+ for fun in skipped_functions:
+ if fun == name:
+-  return 1
++return 1
+ # Do not test destructors
+-if string.find(name, 'Free') != -1:
++if name.find('Free') != -1:
+ return 1
+ return 0
+ 
+ def is_skipped_memcheck(name):
+ for fun in skipped_memcheck:
+ if fun == name:
+-  return 1
++return 1
+ return 0
+ 
+ missing_types = {}
+ def add_missing_type(name, func):
+ try:
+ list = 

[OE-core][kirkstone 08/16] autoconf: Update K & R stype functions

[Steve Sakoman]

From: Khem Raj 

This replaces the proposed patch with a backport of what got accepted upstream

Signed-off-by: Khem Raj 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit f3e92b7cb5833f61ff13a66f03be513d97a69894)
Signed-off-by: Steve Sakoman 
---
 ...ilers-that-moan-about-K-R-func-decls.patch | 138 ++
 ...totype-for-functions-with-no-paramet.patch |  64 
 .../autoconf/autoconf_2.71.bb |   2 +-
 3 files changed, 139 insertions(+), 65 deletions(-)
 create mode 100644 
meta/recipes-devtools/autoconf/autoconf/0001-Port-to-compilers-that-moan-about-K-R-func-decls.patch
 delete mode 100644 
meta/recipes-devtools/autoconf/autoconf/0001-specify-void-prototype-for-functions-with-no-paramet.patch

diff --git 
a/meta/recipes-devtools/autoconf/autoconf/0001-Port-to-compilers-that-moan-about-K-R-func-decls.patch
 
b/meta/recipes-devtools/autoconf/autoconf/0001-Port-to-compilers-that-moan-about-K-R-func-decls.patch
new file mode 100644
index 00..4f15bf96c3
--- /dev/null
+++ 
b/meta/recipes-devtools/autoconf/autoconf/0001-Port-to-compilers-that-moan-about-K-R-func-decls.patch
@@ -0,0 +1,138 @@
+From 7a3bbca81b803ba116b83c82de378e840cc35f81 Mon Sep 17 00:00:00 2001
+From: Paul Eggert 
+Date: Thu, 1 Sep 2022 16:19:50 -0500
+Subject: [PATCH] Port to compilers that moan about K func decls
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+* lib/autoconf/c.m4 (AC_LANG_CALL, AC_LANG_FUNC_LINK_TRY):
+Use '(void)' rather than '()' in function prototypes, as the latter
+provokes fatal errors in some compilers nowadays.
+* lib/autoconf/functions.m4 (AC_FUNC_STRTOD):
+* tests/fortran.at (AC_F77_DUMMY_MAIN usage):
+* tests/semantics.at (AC_CHECK_DECLS):
+Don’t use () in a function decl.
+
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016c7ed2d67f31b03a3d2e361858ff5299b]
+Signed-off-by: Khem Raj 
+---
+ doc/autoconf.texi | 7 +++
+ lib/autoconf/c.m4 | 6 +++---
+ lib/autoconf/functions.m4 | 3 ---
+ tests/fortran.at  | 8 
+ tests/semantics.at| 2 +-
+ 5 files changed, 11 insertions(+), 15 deletions(-)
+
+--- a/doc/autoconf.texi
 b/doc/autoconf.texi
+@@ -5465,9 +5465,7 @@ the @samp{#undef malloc}):
+ #include 
+ #undef malloc
+ 
+-#include 
+-
+-void *malloc ();
++#include 
+ 
+ /* Allocate an N-byte block of memory from the heap.
+If N is zero, allocate a 1-byte block.  */
+@@ -8295,7 +8293,7 @@ needed:
+ #  ifdef __cplusplus
+  extern "C"
+ #  endif
+-   int F77_DUMMY_MAIN () @{ return 1; @}
++   int F77_DUMMY_MAIN (void) @{ return 1; @}
+ #endif
+ @end example
+ 
+--- a/lib/autoconf/c.m4
 b/lib/autoconf/c.m4
+@@ -127,7 +127,7 @@ m4_if([$2], [main], ,
+ [/* Override any GCC internal prototype to avoid an error.
+Use char because int might match the return type of a GCC
+builtin and then its argument prototype would still apply.  */
+-char $2 ();])], [return $2 ();])])
++char $2 (void);])], [return $2 ();])])
+ 
+ 
+ # AC_LANG_FUNC_LINK_TRY(C)(FUNCTION)
+@@ -151,7 +151,7 @@ m4_define([AC_LANG_FUNC_LINK_TRY(C)],
+ #define $1 innocuous_$1
+ 
+ /* System header to define __stub macros and hopefully few prototypes,
+-   which can conflict with char $1 (); below.  */
++   which can conflict with char $1 (void); below.  */
+ 
+ #include 
+ #undef $1
+@@ -162,7 +162,7 @@ m4_define([AC_LANG_FUNC_LINK_TRY(C)],
+ #ifdef __cplusplus
+ extern "C"
+ #endif
+-char $1 ();
++char $1 (void);
+ /* The GNU C library defines this for functions which it implements
+ to always fail with ENOSYS.  Some functions are actually named
+ something starting with __ and the normal name is an alias.  */
+--- a/lib/autoconf/functions.m4
 b/lib/autoconf/functions.m4
+@@ -1601,9 +1601,6 @@ AC_DEFUN([AC_FUNC_STRTOD],
+ AC_CACHE_CHECK(for working strtod, ac_cv_func_strtod,
+ [AC_RUN_IFELSE([AC_LANG_SOURCE([[
+ ]AC_INCLUDES_DEFAULT[
+-#ifndef strtod
+-double strtod ();
+-#endif
+ int
+ main (void)
+ {
+--- a/tests/fortran.at
 b/tests/fortran.at
+@@ -233,7 +233,7 @@ void FOOBAR_F77 (double *x, double *y);
+ #  ifdef __cplusplus
+  extern "C"
+ #  endif
+-   int F77_DUMMY_MAIN () { return 1; }
++   int F77_DUMMY_MAIN (void) { return 1; }
+ #endif
+ 
+ int main(int argc, char *argv[])
+@@ -315,7 +315,7 @@ void FOOBAR_FC(double *x, double *y);
+ #  ifdef __cplusplus
+  extern "C"
+ #  endif
+-   int FC_DUMMY_MAIN () { return 1; }
++   int FC_DUMMY_MAIN (void) { return 1; }
+ #endif
+ 
+ int main (int argc, char *argv[])
+@@ -561,7 +561,7 @@ void @foobar@ (int *x);
+ #  ifdef __cplusplus
+  extern "C"
+ #  endif
+-   int F77_DUMMY_MAIN () { return 1; }
++   int F77_DUMMY_MAIN (void) { return 1; }
+ #endif
+ 
+ int main(int argc, char *argv[])
+@@ -637,7 +637,7 @@ void @foobar@ (int *x);
+ #  ifdef __cplusplus
+  extern "C"
+ #  endif
+-   int FC_DUMMY_MAIN () { return 1; }
++   int FC_DUMMY_MAIN (void) 

[OE-core][kirkstone 01/16] cracklib: upgrade 2.9.7 -> 2.9.8

[Steve Sakoman]

From: wangmy 

v2.9.8 Correct parameter types to Debug() calls
   rules: Drop using register keyword
   remove needless use of %defattr per fedora project
   add exec perms
   translation updates
   Use what's in the build environment and use a current autoconf
   util/Makefile.am: fix link with lintl
   Force grep to treat the input as text when formatting word files

0001-rules-Drop-using-register-keyword.patch
0002-rules-Correct-parameter-types-to-Debug-calls.patch
removed since they're included in 2.9.8

Signed-off-by: Wang Mingyu 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit 7477178a4c60c02c2d1638746148dd3d2941dc28)
Signed-off-by: Steve Sakoman 
---
 ...01-rules-Drop-using-register-keyword.patch | 278 --
 ...rrect-parameter-types-to-Debug-calls.patch |  40 ---
 .../{cracklib_2.9.7.bb => cracklib_2.9.8.bb}  |   4 +-
 3 files changed, 1 insertion(+), 321 deletions(-)
 delete mode 100644 
meta/recipes-extended/cracklib/cracklib/0001-rules-Drop-using-register-keyword.patch
 delete mode 100644 
meta/recipes-extended/cracklib/cracklib/0002-rules-Correct-parameter-types-to-Debug-calls.patch
 rename meta/recipes-extended/cracklib/{cracklib_2.9.7.bb => cracklib_2.9.8.bb} 
(83%)

diff --git 
a/meta/recipes-extended/cracklib/cracklib/0001-rules-Drop-using-register-keyword.patch
 
b/meta/recipes-extended/cracklib/cracklib/0001-rules-Drop-using-register-keyword.patch
deleted file mode 100644
index a8446653eb..00
--- 
a/meta/recipes-extended/cracklib/cracklib/0001-rules-Drop-using-register-keyword.patch
+++ /dev/null
@@ -1,278 +0,0 @@
-From fe49471cfa7fe0618615c065f4c0ad04e888bf92 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Sun, 7 Aug 2022 12:24:39 -0700
-Subject: [PATCH 1/2] rules: Drop using register keyword
-
-This is a deprecated keyword
-
-Upstream-Status: Submitted [https://github.com/cracklib/cracklib/pull/48]
-Signed-off-by: Khem Raj 

- src/lib/rules.c | 94 -
- 1 file changed, 47 insertions(+), 47 deletions(-)
-
-diff --git a/lib/rules.c b/lib/rules.c
-index 3a2aa46..6e7a12a 100644
 a/lib/rules.c
-+++ b/lib/rules.c
-@@ -67,8 +67,8 @@ Suffix(myword, suffix)
- char *myword;
- char *suffix;
- {
--register int i;
--register int j;
-+int i;
-+int j;
- i = strlen(myword);
- j = strlen(suffix);
- 
-@@ -83,10 +83,10 @@ Suffix(myword, suffix)
- 
- char *
- Reverse(str)  /* return a pointer to a reversal */
--register char *str;
-+char *str;
- {
--register int i;
--register int j;
-+int i;
-+int j;
- static char area[STRINGSIZE];
- j = i = strlen(str);
- while (*str)
-@@ -99,9 +99,9 @@ Reverse(str) /* return a pointer to a 
reversal */
- 
- char *
- Uppercase(str)/* return a pointer to an uppercase */
--register char *str;
-+char *str;
- {
--register char *ptr;
-+char *ptr;
- static char area[STRINGSIZE];
- ptr = area;
- while (*str)
-@@ -116,9 +116,9 @@ Uppercase(str) /* return a pointer to 
an uppercase */
- 
- char *
- Lowercase(str)/* return a pointer to an lowercase */
--register char *str;
-+char *str;
- {
--register char *ptr;
-+char *ptr;
- static char area[STRINGSIZE];
- ptr = area;
- while (*str)
-@@ -133,9 +133,9 @@ Lowercase(str) /* return a pointer to 
an lowercase */
- 
- char *
- Capitalise(str)   /* return a pointer to an capitalised */
--register char *str;
-+char *str;
- {
--register char *ptr;
-+char *ptr;
- static char area[STRINGSIZE];
- ptr = area;
- 
-@@ -152,9 +152,9 @@ Capitalise(str)/* return a pointer to 
an capitalised */
- 
- char *
- Pluralise(string) /* returns a pointer to a plural */
--register char *string;
-+char *string;
- {
--register int length;
-+int length;
- static char area[STRINGSIZE];
- length = strlen(string);
- strcpy(area, string);
-@@ -193,11 +193,11 @@ Pluralise(string)/* returns a pointer to 
a plural */
- 
- char *
- Substitute(string, old, new)  /* returns pointer to a swapped about copy */
--register char *string;
--register char old;
--register char new;
-+char *string;
-+char old;
-+char new;
- {
--register char *ptr;
-+char *ptr;
- static char area[STRINGSIZE];
- ptr = area;
- while (*string)
-@@ -211,11 +211,11 @@ Substitute(string, old, new) /* returns pointer to a 
swapped about copy */
- 
- char *
- Purge(string, target) /* returns pointer to a purged copy */
--register char *string;
--register char target;
-+char *string;
-+char target;
- {
--register char *ptr;
--static char area[STRINGSIZE];
-+char *ptr;
-+char area[STRINGSIZE];
- ptr = area;
- 

[OE-core][kirkstone 07/16] autoconf: Fix strict prototype errors in generated tests

[Steve Sakoman]

From: Khem Raj 

This will fix issues with autoconf tests which fail due to lacking
prototypes

Signed-off-by: Khem Raj 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit eb477854ba230d8a8370f24880bd421607399e5a)
Signed-off-by: Steve Sakoman 
---
 ...totype-for-functions-with-no-paramet.patch | 64 +++
 .../autoconf/autoconf_2.71.bb |  1 +
 2 files changed, 65 insertions(+)
 create mode 100644 
meta/recipes-devtools/autoconf/autoconf/0001-specify-void-prototype-for-functions-with-no-paramet.patch

diff --git 
a/meta/recipes-devtools/autoconf/autoconf/0001-specify-void-prototype-for-functions-with-no-paramet.patch
 
b/meta/recipes-devtools/autoconf/autoconf/0001-specify-void-prototype-for-functions-with-no-paramet.patch
new file mode 100644
index 00..4d8aa296cd
--- /dev/null
+++ 
b/meta/recipes-devtools/autoconf/autoconf/0001-specify-void-prototype-for-functions-with-no-paramet.patch
@@ -0,0 +1,64 @@
+From 7ccfea413216bddd988823acf4e93421ea0f7f9f Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 16 Aug 2022 18:35:45 -0700
+Subject: [PATCH] specify void prototype for functions with no parameters
+
+Compilers defaulting to C99 flag such functions as warning which fails
+to compile when using -Werror
+
+Fixes
+error: a function declaration without a prototype is deprecated in all 
versions of C [-Werror,-Wstrict-prototypes]
+
+Upstream-Status: Submitted 
[https://lists.gnu.org/archive/html/autoconf-patches/2022-08/msg3.html]
+Signed-off-by: Khem Raj 
+---
+ lib/autoconf/c.m4 | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/lib/autoconf/c.m4
 b/lib/autoconf/c.m4
+@@ -127,7 +127,7 @@ m4_if([$2], [main], ,
+ [/* Override any GCC internal prototype to avoid an error.
+Use char because int might match the return type of a GCC
+builtin and then its argument prototype would still apply.  */
+-char $2 ();])], [return $2 ();])])
++char $2 (void);])], [return $2 ();])])
+ 
+ 
+ # AC_LANG_FUNC_LINK_TRY(C)(FUNCTION)
+@@ -151,7 +151,7 @@ m4_define([AC_LANG_FUNC_LINK_TRY(C)],
+ #define $1 innocuous_$1
+ 
+ /* System header to define __stub macros and hopefully few prototypes,
+-   which can conflict with char $1 (); below.  */
++   which can conflict with char $1 (void); below.  */
+ 
+ #include 
+ #undef $1
+@@ -162,7 +162,7 @@ m4_define([AC_LANG_FUNC_LINK_TRY(C)],
+ #ifdef __cplusplus
+ extern "C"
+ #endif
+-char $1 ();
++char $1 (void);
+ /* The GNU C library defines this for functions which it implements
+ to always fail with ENOSYS.  Some functions are actually named
+ something starting with __ and the normal name is an alias.  */
+@@ -252,7 +252,7 @@ dnl other built-in extern "C" functions,
+ dnl when it actually happens.
+ [AC_LANG_PROGRAM([[$1
+ namespace conftest {
+-  extern "C" int $2 ();
++  extern "C" int $2 (void);
+ }]],
+ [[return conftest::$2 ();]])])
+ 
+@@ -2457,7 +2457,7 @@ using std::strcmp;
+ 
+ namespace {
+ 
+-void test_exception_syntax()
++void test_exception_syntax(void)
+ {
+   try {
+ throw "test";
diff --git a/meta/recipes-devtools/autoconf/autoconf_2.71.bb 
b/meta/recipes-devtools/autoconf/autoconf_2.71.bb
index 799191e2ca..239b268119 100644
--- a/meta/recipes-devtools/autoconf/autoconf_2.71.bb
+++ b/meta/recipes-devtools/autoconf/autoconf_2.71.bb
@@ -18,6 +18,7 @@ SRC_URI = "${GNU_MIRROR}/autoconf/${BP}.tar.gz \
file://preferbash.patch \
file://autotest-automake-result-format.patch \
file://man-host-perl.patch \
+   
file://0001-specify-void-prototype-for-functions-with-no-paramet.patch \
"
 SRC_URI:append:class-native = " file://no-man.patch"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170586): 
https://lists.openembedded.org/g/openembedded-core/message/170586
Mute This Topic: https://lists.openembedded.org/mt/93656172/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 06/16] kernel: Use consistent make flags for menuconfig

[Steve Sakoman]

From: Richard Purdie 

We're currently only passing in a subset of the kernel make flags to
menuconfig. Fix this to be consistent with all the other kernel
operations since these are becomming increasingly reliant on host
compilers and flags and target toolchains as well.

Signed-off-by: Richard Purdie 
(cherry picked from commit 8c616bc090d1834a21073a33209323220c05d2e5)
Signed-off-by: Steve Sakoman 
---
 meta/classes/kernel.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index aca03fc071..8dff68612d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -637,7 +637,8 @@ addtask savedefconfig after do_configure
 
 inherit cml1
 
-KCONFIG_CONFIG_COMMAND:append = " PAHOLE=false LD='${KERNEL_LD}' 
HOSTLDFLAGS='${BUILD_LDFLAGS}'"
+# Need LD, HOSTLDFLAGS and more for config operations
+KCONFIG_CONFIG_COMMAND:append = " ${EXTRA_OEMAKE}"
 
 EXPORT_FUNCTIONS do_compile do_transform_kernel do_transform_bundled_initramfs 
do_install do_configure
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170585): 
https://lists.openembedded.org/g/openembedded-core/message/170585
Mute This Topic: https://lists.openembedded.org/mt/93656169/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 05/16] kernel: Always set CC and LD for the kernel build

[Steve Sakoman]

From: Richard Purdie 

It as been bothering me a bit that we don't set CC and LD consistently
for the kernel make calls and this can lead to interesting bugs as the
kernel increases in complexity. Add them to EXTRA_OEMAKE so they're
always passed in. This makes everything slightly more consistent and
less likely to break in future.

Signed-off-by: Richard Purdie 
(cherry picked from commit afe8c318843e4033dcc07e4f10198df241d8e4f6)
Signed-off-by: Steve Sakoman 
---
 meta/classes/kernel.bbclass | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c29bd3d5f3..aca03fc071 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -231,8 +231,9 @@ UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
 # Some Linux kernel configurations need additional parameters on the command 
line
 KERNEL_EXTRA_ARGS ?= ""
 
-EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}" HOSTCFLAGS="${BUILD_CFLAGS}" 
HOSTLDFLAGS="${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}""
-EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}" HOSTCXXFLAGS="${BUILD_CXXFLAGS}" 
PAHOLE=false"
+EXTRA_OEMAKE += ' CC="${KERNEL_CC}" LD="${KERNEL_LD}"'
+EXTRA_OEMAKE += ' HOSTCC="${BUILD_CC}" HOSTCFLAGS="${BUILD_CFLAGS}" 
HOSTLDFLAGS="${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}"'
+EXTRA_OEMAKE += ' HOSTCXX="${BUILD_CXX}" HOSTCXXFLAGS="${BUILD_CXXFLAGS}" 
PAHOLE=false'
 
 KERNEL_ALT_IMAGETYPE ??= ""
 
@@ -375,7 +376,7 @@ kernel_do_compile() {

use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
fi
for typeformake in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do
-   oe_runmake ${typeformake} CC="${KERNEL_CC}" LD="${KERNEL_LD}" 
${KERNEL_EXTRA_ARGS} $use_alternate_initrd
+   oe_runmake ${typeformake} ${KERNEL_EXTRA_ARGS} 
$use_alternate_initrd
done
 }
 
@@ -407,7 +408,7 @@ do_compile_kernelmodules() {
bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
fi
if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
-   oe_runmake -C ${B} ${PARALLEL_MAKE} modules CC="${KERNEL_CC}" 
LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}
+   oe_runmake -C ${B} ${PARALLEL_MAKE} modules ${KERNEL_EXTRA_ARGS}
 
# Module.symvers gets updated during the 
# building of the kernel modules. We need to
@@ -591,7 +592,7 @@ sysroot_stage_all () {
:
 }
 
-KERNEL_CONFIG_COMMAND ?= "oe_runmake_call -C ${S} CC="${KERNEL_CC}" 
LD="${KERNEL_LD}" O=${B} olddefconfig || oe_runmake -C ${S} O=${B} 
CC="${KERNEL_CC}" LD="${KERNEL_LD}" oldnoconfig"
+KERNEL_CONFIG_COMMAND ?= "oe_runmake_call -C ${S} O=${B} olddefconfig || 
oe_runmake -C ${S} O=${B} oldnoconfig"
 
 python check_oldest_kernel() {
 oldest_kernel = d.getVar('OLDEST_KERNEL')
@@ -629,7 +630,7 @@ kernel_do_configure() {
 
 do_savedefconfig() {
bbplain "Saving defconfig to:\n${B}/defconfig"
-   oe_runmake -C ${B} LD='${KERNEL_LD}' savedefconfig
+   oe_runmake -C ${B} savedefconfig
 }
 do_savedefconfig[nostamp] = "1"
 addtask savedefconfig after do_configure
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170584): 
https://lists.openembedded.org/g/openembedded-core/message/170584
Mute This Topic: https://lists.openembedded.org/mt/93656168/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 03/16] ruby: drop capstone support

[Steve Sakoman]

From: Alexandre Belloni 

Upstream dropped capstone support and this also causing us
reproducibility issues.

Signed-off-by: Alexandre Belloni 
(cherry picked from commit d2496a904a7099ef0de818180820ad7b40843a08)
Signed-off-by: Steve Sakoman 
---
 ...001-Remove-dependency-on-libcapstone.patch | 36 +++
 meta/recipes-devtools/ruby/ruby_3.1.2.bb  |  2 +-
 2 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/ruby/ruby/0001-Remove-dependency-on-libcapstone.patch

diff --git 
a/meta/recipes-devtools/ruby/ruby/0001-Remove-dependency-on-libcapstone.patch 
b/meta/recipes-devtools/ruby/ruby/0001-Remove-dependency-on-libcapstone.patch
new file mode 100644
index 00..5d0f8fcc09
--- /dev/null
+++ 
b/meta/recipes-devtools/ruby/ruby/0001-Remove-dependency-on-libcapstone.patch
@@ -0,0 +1,36 @@
+From 03297966f312109e8eaa2520f2cf2f59c09d Mon Sep 17 00:00:00 2001
+From: Alan Wu 
+Date: Thu, 31 Mar 2022 17:26:28 -0400
+Subject: [PATCH] Remove dependency on libcapstone
+
+We have received reports of build failures due to this configuration
+check modifying compile flags. Since only YJIT devs use this library
+we can remove it to make Ruby easier to build for users.
+
+See: https://github.com/rbenv/ruby-build/discussions/1933
+
+Upstream-Status: Backport
+---
+ configure.ac | 9 -
+ 1 file changed, 9 deletions(-)
+
+Index: ruby-3.1.2/configure.ac
+===
+--- ruby-3.1.2.orig/configure.ac
 ruby-3.1.2/configure.ac
+@@ -1244,15 +1244,6 @@ AC_CHECK_LIB(dl, dlopen)# Dynamic linki
+ AC_CHECK_LIB(dld, shl_load)   # Dynamic linking for HP-UX
+ AC_CHECK_LIB(socket, shutdown)  # SunOS/Solaris
+ 
+-if pkg-config --exists capstone; then
+-   CAPSTONE_CFLAGS=`pkg-config --cflags capstone`
+-   CAPSTONE_LIB_L=`pkg-config --libs-only-L capstone`
+-   LDFLAGS="$LDFLAGS $CAPSTONE_LIB_L"
+-   CFLAGS="$CFLAGS $CAPSTONE_CFLAGS"
+-fi
+-
+-AC_CHECK_LIB(capstone, cs_open) # Capstone disassembler for debugging YJIT
+-
+ dnl Checks for header files.
+ AC_HEADER_DIRENT
+ dnl AC_HEADER_STDC has been checked in AC_USE_SYSTEM_EXTENSIONS
diff --git a/meta/recipes-devtools/ruby/ruby_3.1.2.bb 
b/meta/recipes-devtools/ruby/ruby_3.1.2.bb
index 6fc1f53b18..387bfa9b44 100644
--- a/meta/recipes-devtools/ruby/ruby_3.1.2.bb
+++ b/meta/recipes-devtools/ruby/ruby_3.1.2.bb
@@ -12,6 +12,7 @@ SRC_URI += " \

file://0005-Mark-Gemspec-reproducible-change-fixing-784225-too.patch \
file://0006-Make-gemspecs-reproducible.patch \
file://0001-vm_dump.c-Define-REG_S1-and-REG_S2-for-musl-riscv.patch 
\
+   file://0001-Remove-dependency-on-libcapstone.patch \
"
 
 SRC_URI[sha256sum] = 
"61843112389f02b735428b53bb64cf988ad9fb81858b8248e22e57336f24a83e"
@@ -25,7 +26,6 @@ PACKAGECONFIG[ipv6] = "--enable-ipv6, --disable-ipv6,"
 # rdoc is off by default due to non-reproducibility reported in
 # https://bugs.ruby-lang.org/issues/18456
 PACKAGECONFIG[rdoc] = "--enable-install-rdoc,--disable-install-rdoc,"
-PACKAGECONFIG[capstone] = "--with-capstone=yes, --with-capstone=no"
 
 EXTRA_OECONF = "\
 --disable-versioned-paths \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170582): 
https://lists.openembedded.org/g/openembedded-core/message/170582
Mute This Topic: https://lists.openembedded.org/mt/93656164/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 04/16] gcc-multilib-config: Fix i686 toolchain relocation issues

[Steve Sakoman]

From: Richard Purdie 

This code wasn't changing the linux.h on i686. Make the entry match that
for i586 which was correct.

This fixes problems where the wrong dynamic loader path was used by
nativesdk-gcc on i686 SDK targets by ensuring SYSTEMLIBS_DIR is replaced
by %r in the correct header files.

Signed-off-by: Richard Purdie 
(cherry picked from commit d30eb681f41bf9e921f7f0d42747fff7a4be9229)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/gcc/gcc-multilib-config.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-multilib-config.inc 
b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
index 26bfed9507..2dbbc23c94 100644
--- a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
+++ b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
@@ -154,7 +154,7 @@ python gcc_multilib_setup() {
 gcc_header_config_files = {
 'x86_64': ['gcc/config/linux.h', 'gcc/config/i386/linux.h', 
'gcc/config/i386/linux64.h'],
 'i586'  : ['gcc/config/linux.h', 'gcc/config/i386/linux.h', 
'gcc/config/i386/linux64.h'],
-'i686'  : ['gcc/config/linux.h', 'gcc/config/i386/linux64.h'],
+'i686'  : ['gcc/config/linux.h', 'gcc/config/i386/linux.h', 
'gcc/config/i386/linux64.h'],
 'mips'  : ['gcc/config/linux.h', 'gcc/config/mips/linux.h', 
'gcc/config/mips/linux64.h'],
 'mips64': ['gcc/config/linux.h', 'gcc/config/mips/linux.h', 
'gcc/config/mips/linux64.h'],
 'powerpc'   : ['gcc/config/linux.h', 'gcc/config/rs6000/linux64.h'],
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170583): 
https://lists.openembedded.org/g/openembedded-core/message/170583
Mute This Topic: https://lists.openembedded.org/mt/93656166/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 02/16] vala: upgrade 0.56.2 -> 0.56.3

[Steve Sakoman]

From: wangmy 

Changelog:
==
 * Various improvements and bug fixes:
  - vala: Don't unconditionally expect ObjectType of Class [#1341]
  - vala: Make try-statement parsing more resilient [#1304]
  - vala: Avoid problems with '\' in #line directives on Windows [#1353]
  - gidlparser: Set source reference of parameters

 * Bindings:
  - atspi-2: Fix a few binding errors
  - glib-2.0: Use g_abort for GLib.Process.abort() beginning with 2.50 [#1350]
  - gtk+-3.0: Correctly unhide BindingSet.by_class to avoid Version attribute

Signed-off-by: Wang Mingyu 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
(cherry picked from commit 29d2f8241312a7f0bda39805d41cd6789d369ce9)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/vala/vala_0.56.2.bb | 3 ---
 meta/recipes-devtools/vala/vala_0.56.3.bb | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)
 delete mode 100644 meta/recipes-devtools/vala/vala_0.56.2.bb
 create mode 100644 meta/recipes-devtools/vala/vala_0.56.3.bb

diff --git a/meta/recipes-devtools/vala/vala_0.56.2.bb 
b/meta/recipes-devtools/vala/vala_0.56.2.bb
deleted file mode 100644
index 08c8ccca1d..00
--- a/meta/recipes-devtools/vala/vala_0.56.2.bb
+++ /dev/null
@@ -1,3 +0,0 @@
-require ${BPN}.inc
-
-SRC_URI[sha256sum] = 
"66c9619bb17859fd1ac3aba0a57970613e38fd2a1ee30541174260c9fb90124c"
diff --git a/meta/recipes-devtools/vala/vala_0.56.3.bb 
b/meta/recipes-devtools/vala/vala_0.56.3.bb
new file mode 100644
index 00..83f61e5b2f
--- /dev/null
+++ b/meta/recipes-devtools/vala/vala_0.56.3.bb
@@ -0,0 +1,3 @@
+require ${BPN}.inc
+
+SRC_URI[sha256sum] = 
"e1066221bf7b89cb1fa7327a3888645cb33b604de3bf45aa81132fd040b699bf"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170581): 
https://lists.openembedded.org/g/openembedded-core/message/170581
Mute This Topic: https://lists.openembedded.org/mt/93656162/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 00/16] Patch review

[Steve Sakoman]

Please review this set of patches for kirkstone and have comments back by
end of day Thursday.

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/4220

The following changes since commit bfce90b1260d07f01a8dc2998c9e63ca36d4ebbe:

  npm: use npm_registry to cache package (2022-09-06 07:10:59 -1000)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib stable/kirkstone-nut
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut

Alejandro Hernandez Samaniego (1):
  rootfs.py: dont try to list installed packages for baremetal images

Alexandre Belloni (2):
  ruby: drop capstone support
  runqemu: display host uptime when starting

Joshua Watt (1):
  oeqa: qemurunner: Report UNIX Epoch timestamp on login

Khem Raj (2):
  autoconf: Fix strict prototype errors in generated tests
  autoconf: Update K & R stype functions

Kristian Amlie (1):
  externalsrc: Don't wipe out src dir when EXPORT_FUNCTIONS is used.

Martin Jansa (1):
  libxml2: Port gentest.py to Python-3

Pavel Zhukov (1):
  core-image.bbclass: Exclude openssh complementary packages

Peter Bergin (1):
  rootfs-postcommands.bbclass: avoid moving ssh host keys if etc is
writable

Peter Kjellerstedt (1):
  cairo: Adapt the license information based on what is being built

Richard Purdie (3):
  gcc-multilib-config: Fix i686 toolchain relocation issues
  kernel: Always set CC and LD for the kernel build
  kernel: Use consistent make flags for menuconfig

wangmy (2):
  cracklib: upgrade 2.9.7 -> 2.9.8
  vala: upgrade 0.56.2 -> 0.56.3

 meta/classes/core-image.bbclass   |   4 +
 meta/classes/externalsrc.bbclass  |   8 +-
 meta/classes/kernel.bbclass   |  16 +-
 meta/classes/rootfs-postcommands.bbclass  |  30 +-
 meta/lib/oe/rootfs.py |   4 +
 meta/lib/oeqa/utils/qemurunner.py |   4 +-
 .../0001-Port-gentest.py-to-Python-3.patch| 814 ++
 meta/recipes-core/libxml/libxml2_2.9.14.bb|  11 +
 ...ilers-that-moan-about-K-R-func-decls.patch | 138 +++
 .../autoconf/autoconf_2.71.bb |   1 +
 .../gcc/gcc-multilib-config.inc   |   2 +-
 ...001-Remove-dependency-on-libcapstone.patch |  36 +
 meta/recipes-devtools/ruby/ruby_3.1.2.bb  |   2 +-
 meta/recipes-devtools/vala/vala_0.56.2.bb |   3 -
 meta/recipes-devtools/vala/vala_0.56.3.bb |   3 +
 ...01-rules-Drop-using-register-keyword.patch | 278 --
 ...rrect-parameter-types-to-Debug-calls.patch |  40 -
 .../{cracklib_2.9.7.bb => cracklib_2.9.8.bb}  |   4 +-
 meta/recipes-graphics/cairo/cairo_1.16.0.bb   |   6 +-
 scripts/runqemu   |   6 +
 20 files changed, 1058 insertions(+), 352 deletions(-)
 create mode 100644 
meta/recipes-core/libxml/libxml2/0001-Port-gentest.py-to-Python-3.patch
 create mode 100644 
meta/recipes-devtools/autoconf/autoconf/0001-Port-to-compilers-that-moan-about-K-R-func-decls.patch
 create mode 100644 
meta/recipes-devtools/ruby/ruby/0001-Remove-dependency-on-libcapstone.patch
 delete mode 100644 meta/recipes-devtools/vala/vala_0.56.2.bb
 create mode 100644 meta/recipes-devtools/vala/vala_0.56.3.bb
 delete mode 100644 
meta/recipes-extended/cracklib/cracklib/0001-rules-Drop-using-register-keyword.patch
 delete mode 100644 
meta/recipes-extended/cracklib/cracklib/0002-rules-Correct-parameter-types-to-Debug-calls.patch
 rename meta/recipes-extended/cracklib/{cracklib_2.9.7.bb => cracklib_2.9.8.bb} 
(83%)

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170579): 
https://lists.openembedded.org/g/openembedded-core/message/170579
Mute This Topic: https://lists.openembedded.org/mt/93656154/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] python3: add PACKAGECONFIG[editline]

[Quentin Schulz]

Hi Etienne,

On 9/13/22 14:39, Etienne Cordonnier via lists.openembedded.org wrote:

editline is a BSD alternative for readline which is GPLv3.

Signed-off-by: Etienne Cordonnier 
---
  meta/recipes-devtools/python/python3_3.10.6.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3_3.10.6.bb 
b/meta/recipes-devtools/python/python3_3.10.6.bb
index 1b28728732..6c4ef5c7d1 100644
--- a/meta/recipes-devtools/python/python3_3.10.6.bb
+++ b/meta/recipes-devtools/python/python3_3.10.6.bb
@@ -105,6 +105,7 @@ PACKAGECONFIG:class-target ??= "readline gdbm 
${@bb.utils.filter('DISTRO_FEATURE
  PACKAGECONFIG:class-native ??= "readline gdbm"
  PACKAGECONFIG:class-nativesdk ??= "readline gdbm"
  PACKAGECONFIG[readline] = ",,readline"
+PACKAGECONFIG[editline] = "--with-readline=editline,,libedit"


Is libedit supposed to replace readline entirely in python3? If so, I'm 
wondering if it'd make sense to make readline and editline 
PACKAGECONFIG's packageconfig-conflicts-for-f1 the other so that we 
cannot have both configs enabled at the same time?


C.f. last entry in 
https://docs.yoctoproject.org/ref-manual/variables.html#term-PACKAGECONFIG


Cheers,
Quentin


  # Use profile guided optimisation by running PyBench inside qemu-user
  PACKAGECONFIG[pgo] = "--enable-optimizations,,qemu-native"
  PACKAGECONFIG[tk] = ",,tk"






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170578): 
https://lists.openembedded.org/g/openembedded-core/message/170578
Mute This Topic: https://lists.openembedded.org/mt/93654164/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] binutils : CVE-2022-38533

[Florin Diaconescu]

Upstream-Status: Backport
[https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ef186fe54aa6d281a3ff8a9528417e5cc614c797]

Signed-off-by: Florin Diaconescu 
---
 .../binutils/binutils-2.34.inc|  1 +
 .../binutils/binutils/CVE-2022-38533.patch| 37 +++
 2 files changed, 38 insertions(+)
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.34.inc 
b/meta/recipes-devtools/binutils/binutils-2.34.inc
index 6a55de2d45..ff0d467132 100644
--- a/meta/recipes-devtools/binutils/binutils-2.34.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.34.inc
@@ -52,5 +52,6 @@ SRC_URI = "\
  file://CVE-2021-3549.patch \
  file://CVE-2020-16593.patch \
  file://0001-CVE-2021-45078.patch \
+ file://CVE-2022-38533.patch \
 "
 S  = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch
new file mode 100644
index 00..102d65f8a6
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2022-38533.patch
@@ -0,0 +1,37 @@
+From ef186fe54aa6d281a3ff8a9528417e5cc614c797 Mon Sep 17 00:00:00 2001
+From: Alan Modra 
+Date: Sat, 13 Aug 2022 15:32:47 +0930
+Subject: [PATCH] PR29482 - strip: heap-buffer-overflow
+
+   PR 29482
+   * coffcode.h (coff_set_section_contents): Sanity check _LIB.
+
+CVE: CVE-2022-38533
+Upstream-Status: Backport 
[https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ef186fe54aa6d281a3ff8a9528417e5cc614c797]
+
+Signed-off-by: Florin Diaconescu 
+
+---
+ bfd/coffcode.h | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/bfd/coffcode.h b/bfd/coffcode.h
+index dec2e9c6370..75c18d88602 100644
+--- a/bfd/coffcode.h
 b/bfd/coffcode.h
+@@ -4170,10 +4170,13 @@ coff_set_section_contents (bfd * abfd,
+ 
+   rec = (bfd_byte *) location;
+   recend = rec + count;
+-  while (rec < recend)
++  while (recend - rec >= 4)
+ {
++  size_t len = bfd_get_32 (abfd, rec);
++  if (len == 0 || len > (size_t) (recend - rec) / 4)
++break;
++  rec += len * 4;
+   ++section->lma;
+-  rec += bfd_get_32 (abfd, rec) * 4;
+ }
+ 
+   BFD_ASSERT (rec == recend);
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170577): 
https://lists.openembedded.org/g/openembedded-core/message/170577
Mute This Topic: https://lists.openembedded.org/mt/93654296/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] python3: add PACKAGECONFIG[editline]

[Etienne Cordonnier via lists.openembedded.org]

editline is a BSD alternative for readline which is GPLv3.

Signed-off-by: Etienne Cordonnier 
---
 meta/recipes-devtools/python/python3_3.10.6.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3_3.10.6.bb 
b/meta/recipes-devtools/python/python3_3.10.6.bb
index 1b28728732..6c4ef5c7d1 100644
--- a/meta/recipes-devtools/python/python3_3.10.6.bb
+++ b/meta/recipes-devtools/python/python3_3.10.6.bb
@@ -105,6 +105,7 @@ PACKAGECONFIG:class-target ??= "readline gdbm 
${@bb.utils.filter('DISTRO_FEATURE
 PACKAGECONFIG:class-native ??= "readline gdbm"
 PACKAGECONFIG:class-nativesdk ??= "readline gdbm"
 PACKAGECONFIG[readline] = ",,readline"
+PACKAGECONFIG[editline] = "--with-readline=editline,,libedit"
 # Use profile guided optimisation by running PyBench inside qemu-user
 PACKAGECONFIG[pgo] = "--enable-optimizations,,qemu-native"
 PACKAGECONFIG[tk] = ",,tk"
-- 
2.36.1.vfs.0.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170576): 
https://lists.openembedded.org/g/openembedded-core/message/170576
Mute This Topic: https://lists.openembedded.org/mt/93654164/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] opkg: enable zstd support

[Etienne Cordonnier via lists.openembedded.org]

This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
OPKGBUILDCMD = "opkg-build -Z zstd"

Signed-off-by: Alex Feinman 
Signed-off-by: Etienne Cordonnier 
---
 meta/recipes-devtools/opkg/opkg_0.6.0.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb 
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
index 7b351e8123..e38d9d6f3f 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
@@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
 target_localstatedir := "${localstatedir}"
 OPKGLIBDIR ??= "${target_localstatedir}/lib"
 
-PACKAGECONFIG ??= "libsolv"
+PACKAGECONFIG ??= "libsolv zstd"
 
 PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
 gnupg gpgme libgpg-error,\
@@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
 PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
 PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
 PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
+PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
 PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
 
 EXTRA_OECONF:class-native = 
"--localstatedir=/${@os.path.relpath('${localstatedir}', 
'${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}', 
'${STAGING_DIR_NATIVE}')}"
-- 
2.36.1.vfs.0.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170575): 
https://lists.openembedded.org/g/openembedded-core/message/170575
Mute This Topic: https://lists.openembedded.org/mt/93654146/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] python3-cryptography: workaround broken native functionality

[Richard Purdie]

On Tue, 2022-09-13 at 14:13 +0300, Mikko Rapeli wrote:
> On Tue, 13 Sept 2022 at 13:34, Richard Purdie
>  wrote:
> > Are you using uninative? I'd have expected glibc and pthreads to come
> > from there rather than the host.
> 
> Yes, using uninative, not host libc, sorry. Added full list of
> openat()'d files to the end of this email, from master branch with
> this patch applied.
> Delta to without this patch is just a few python modules. I can't see
> anything wrong in that list.

It looks correct to me too.

It is weird it is ubuntu 18.04 as we had a lot of problems with the
rust SDK work specifically on that platform. The problem there was rust
running things with LD_LIBRARY_PATH set which meant host tools tried to
use the SDK sysroot libs which then broke in interesting ways. It was
specific to the form of the version mismatch on 18.04.

I have no idea if there is a connection, your strace output certainly
suggests not.
> 
> > > And then in bitbake -c devshell busybox:
> > > 
> > > # python3 -c  "from OpenSSL import crypto"
> > > 
> > > I guess there is no way to add a test like that for 
> > > python3-cryptography-native?
> > 
> > You could probably put that in do_configure to test it?
> 
> Yes, on my layer and recipes I can do this. But I'd rather upstream
> the test to python3-cryprography-native or somewhere else but I guess
> native recipes don't have selftests or similar.

I was wondering about putting something into upstream recipe...

We do somehow need to get more information about what is breaking here
:/.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170574): 
https://lists.openembedded.org/g/openembedded-core/message/170574
Mute This Topic: https://lists.openembedded.org/mt/93651845/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 2/2] systemd: Add 'no-dns-fallback' PACKAGECONFIG option

[niko.ma...@vaisala.com via lists.openembedded.org]

From: "niko.ma...@vaisala.com" 

systemd defines a default set of fallback DNS servers in
https://github.com/systemd/systemd/blob/v251/meson_options.txt#L328-L330

By adding a PACKAGECONFIG knob providing a convenient way to opt out,
and then adding that value to systemd's PACKAGECONFIG, the output from
runtime 'resolvectl status' command no longer contains the following
line:

  Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 
1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 
2606:4700:4700::#cloudflare-dns.com 2001:4860:4860::#dns.google 
2606:4700:4700::1001#cloudflare-dns.com 2001:4860:4860::8844#dns.google

(From OE-Core rev: 2b300d6b9ec6288a99d9dacb24a86949caf99e55)

Signed-off-by: Niko Mauno 
Signed-off-by: Richard Purdie 
---
 meta/recipes-core/systemd/systemd_250.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_250.5.bb 
b/meta/recipes-core/systemd/systemd_250.5.bb
index 9923312830..5d568f639e 100644
--- a/meta/recipes-core/systemd/systemd_250.5.bb
+++ b/meta/recipes-core/systemd/systemd_250.5.bb
@@ -165,6 +165,7 @@ PACKAGECONFIG[manpages] = 
"-Dman=true,-Dman=false,libxslt-native xmlto-native do
 PACKAGECONFIG[microhttpd] = 
"-Dmicrohttpd=true,-Dmicrohttpd=false,libmicrohttpd"
 PACKAGECONFIG[myhostname] = 
"-Dnss-myhostname=true,-Dnss-myhostname=false,,libnss-myhostname"
 PACKAGECONFIG[networkd] = "-Dnetworkd=true,-Dnetworkd=false"
+PACKAGECONFIG[no-dns-fallback] = "-Ddns-servers="
 PACKAGECONFIG[nss] = "-Dnss-systemd=true,-Dnss-systemd=false"
 PACKAGECONFIG[nss-mymachines] = "-Dnss-mymachines=true,-Dnss-mymachines=false"
 PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
-- 
2.35.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170573): 
https://lists.openembedded.org/g/openembedded-core/message/170573
Mute This Topic: https://lists.openembedded.org/mt/93653051/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/2] systemd: Fix unwritable /var/lock when no sysvinit handling

[niko.ma...@vaisala.com via lists.openembedded.org]

From: "niko.ma...@vaisala.com" 

Commit 8089cefed8e83c0348037768c292058f1bcbbbe5 ("systemd: Add
PACKAGECONFIG for sysvinit") decoupled enabling of systemd's sysvinit
handling behavior behind a distinct PACKAGECONFIG feature.

This new option affects among other things the installing of
tmpfiles.d/legacy.conf, which is responsible for creating /run/lock
directory, which is pointed to by /var/lock symlink provided by
base-files package.

In case the option is not enabled, then base-files provided /var/lock
is a dangling symlink on resulting rootfs, causing problems with
certain Linux userspace components that rely on existence of writable
/var/lock directory. As an example:

  # fw_printenv
  Error opening lock file /var/lock/fw_printenv.lock

Since Filesystem Hierarchy Standard Version 3.0 states in
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s09.html that

  Lock files should be stored within the /var/lock directory structure.

Ensure the /run/lock directory is always created, so that lock files
can be stored under /var/lock also when 'sysvinit' handling is
disabled.

(From OE-Core rev: 85e5ee2c35cf5778c3aefda45f526e8f6a511131)

Signed-off-by: Niko Mauno 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
---
 meta/recipes-core/systemd/systemd/00-create-volatile.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd/00-create-volatile.conf 
b/meta/recipes-core/systemd/systemd/00-create-volatile.conf
index 87cbe1e7d3..c4277221a2 100644
--- a/meta/recipes-core/systemd/systemd/00-create-volatile.conf
+++ b/meta/recipes-core/systemd/systemd/00-create-volatile.conf
@@ -3,5 +3,6 @@
 # inside /var/log.
 
 
+d  /run/lock   1777-   -   -
 d  /var/volatile/log   -   -   -   -
 d  /var/volatile/tmp   1777-   -
-- 
2.35.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170572): 
https://lists.openembedded.org/g/openembedded-core/message/170572
Mute This Topic: https://lists.openembedded.org/mt/93653049/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 2/2] systemd: Add 'no-dns-fallback' PACKAGECONFIG option

[niko.ma...@vaisala.com via lists.openembedded.org]

From: "niko.ma...@vaisala.com" 

systemd defines a default set of fallback DNS servers in
https://github.com/systemd/systemd/blob/v251/meson_options.txt#L328-L330

By adding a PACKAGECONFIG knob providing a convenient way to opt out,
and then adding that value to systemd's PACKAGECONFIG, the output from
runtime 'resolvectl status' command no longer contains the following
line:

  Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google 
1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google 
2606:4700:4700::#cloudflare-dns.com 2001:4860:4860::#dns.google 
2606:4700:4700::1001#cloudflare-dns.com 2001:4860:4860::8844#dns.google

(From OE-Core rev: 2b300d6b9ec6288a99d9dacb24a86949caf99e55)

Signed-off-by: Niko Mauno 
Signed-off-by: Richard Purdie 
---
 meta/recipes-core/systemd/systemd_244.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_244.5.bb 
b/meta/recipes-core/systemd/systemd_244.5.bb
index a648272bc0..f3e5395465 100644
--- a/meta/recipes-core/systemd/systemd_244.5.bb
+++ b/meta/recipes-core/systemd/systemd_244.5.bb
@@ -162,6 +162,7 @@ PACKAGECONFIG[manpages] = 
"-Dman=true,-Dman=false,libxslt-native xmlto-native do
 PACKAGECONFIG[microhttpd] = 
"-Dmicrohttpd=true,-Dmicrohttpd=false,libmicrohttpd"
 PACKAGECONFIG[myhostname] = 
"-Dnss-myhostname=true,-Dnss-myhostname=false,,libnss-myhostname"
 PACKAGECONFIG[networkd] = "-Dnetworkd=true,-Dnetworkd=false"
+PACKAGECONFIG[no-dns-fallback] = "-Ddns-servers="
 PACKAGECONFIG[nss] = "-Dnss-systemd=true,-Dnss-systemd=false"
 PACKAGECONFIG[nss-mymachines] = "-Dnss-mymachines=true,-Dnss-mymachines=false"
 PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
-- 
2.35.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170571): 
https://lists.openembedded.org/g/openembedded-core/message/170571
Mute This Topic: https://lists.openembedded.org/mt/93653014/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 1/2] systemd: Fix unwritable /var/lock when no sysvinit handling

[niko.ma...@vaisala.com via lists.openembedded.org]

From: "niko.ma...@vaisala.com" 

Commit 8089cefed8e83c0348037768c292058f1bcbbbe5 ("systemd: Add
PACKAGECONFIG for sysvinit") decoupled enabling of systemd's sysvinit
handling behavior behind a distinct PACKAGECONFIG feature.

This new option affects among other things the installing of
tmpfiles.d/legacy.conf, which is responsible for creating /run/lock
directory, which is pointed to by /var/lock symlink provided by
base-files package.

In case the option is not enabled, then base-files provided /var/lock
is a dangling symlink on resulting rootfs, causing problems with
certain Linux userspace components that rely on existence of writable
/var/lock directory. As an example:

  # fw_printenv
  Error opening lock file /var/lock/fw_printenv.lock

Since Filesystem Hierarchy Standard Version 3.0 states in
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s09.html that

  Lock files should be stored within the /var/lock directory structure.

Ensure the /run/lock directory is always created, so that lock files
can be stored under /var/lock also when 'sysvinit' handling is
disabled.

(From OE-Core rev: 85e5ee2c35cf5778c3aefda45f526e8f6a511131)

Signed-off-by: Niko Mauno 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
---
 meta/recipes-core/systemd/systemd/00-create-volatile.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd/00-create-volatile.conf 
b/meta/recipes-core/systemd/systemd/00-create-volatile.conf
index 87cbe1e7d3..c4277221a2 100644
--- a/meta/recipes-core/systemd/systemd/00-create-volatile.conf
+++ b/meta/recipes-core/systemd/systemd/00-create-volatile.conf
@@ -3,5 +3,6 @@
 # inside /var/log.
 
 
+d  /run/lock   1777-   -   -
 d  /var/volatile/log   -   -   -   -
 d  /var/volatile/tmp   1777-   -
-- 
2.35.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170570): 
https://lists.openembedded.org/g/openembedded-core/message/170570
Mute This Topic: https://lists.openembedded.org/mt/93653011/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] python3-cryptography: workaround broken native functionality

[Mikko Rapeli]

On Tue, 13 Sept 2022 at 13:34, Richard Purdie
 wrote:
> Are you using uninative? I'd have expected glibc and pthreads to come
> from there rather than the host.

Yes, using uninative, not host libc, sorry. Added full list of
openat()'d files to the end of this email, from master branch with
this patch applied.
Delta to without this patch is just a few python modules. I can't see
anything wrong in that list.

> > And then in bitbake -c devshell busybox:
> >
> > # python3 -c  "from OpenSSL import crypto"
> >
> > I guess there is no way to add a test like that for 
> > python3-cryptography-native?
>
> You could probably put that in do_configure to test it?

Yes, on my layer and recipes I can do this. But I'd rather upstream
the test to python3-cryprography-native or somewhere else but I guess
native recipes don't have selftests or similar.

-Mikko

list of files opened by python3 when using python3-cryptography,
failed attempts filtered as so many paths get tried:
# strace -f -f -v -v -v -s 9 python3 -c "from OpenSSL import
crypto" 2>&1 | grep ^openat|grep -v -- "-1 ENOENT"
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib64/libpseudo.so",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/bin/python3-native/../../lib/libpython3.10.so.1.0",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/lib/libdl.so.2",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/lib/libpthread.so.0",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/lib/libutil.so.1",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/lib/libm.so.6",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-components/x86_64/pseudo-native/usr",
O_RDONLY) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/pseudo/",
O_RDONLY) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/usr/lib/locale/locale-archive",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/usr/lib/gconv/gconv-modules",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/usr/lib/gconv/gconv-modules.d",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/sysroots-uninative/x86_64-linux/usr/lib/gconv/gconv-modules.d/gconv-modules-extra.conf",
O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, ".", O_RDONLY) = 3
openat(AT_FDCWD, "/home/builder/poky/bitbake/lib",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/busybox-1.35.0",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/encodings/__pycache__/__init__.cpython-310.pyc",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/__pycache__/codecs.cpython-310.pyc",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/encodings",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/encodings/__pycache__/aliases.cpython-310.pyc",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/encodings/__pycache__/utf_8.cpython-310.pyc",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/__pycache__/io.cpython-310.pyc",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,
"/home/builder/poky/build_master/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/__pycache__/abc.cpython-310.pyc",
O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD,

Re: [OE-core] [PATCH] python3-cryptography: workaround broken native functionality

[Richard Purdie]

On Tue, 2022-09-13 at 13:29 +0300, Mikko Rapeli wrote:
> Hi,
> 
> On Tue, 13 Sept 2022 at 13:01, Richard Purdie
>  wrote:
> > 
> > On Tue, 2022-09-13 at 12:34 +0300, Mikko Rapeli wrote:
> > > The python3-cryptography-native builds work but are functionally broken
> > > on Ubuntu 18.04 build host since the update from 3.3.2 in
> > > meta-openembedded/meta-python. If recipe needs and DEPENDS on
> > > python3-cryptography-native for signing use cases, loading
> > > the python modules fails:
> > > 
> > > $ python3 -c  "from OpenSSL import crypto"
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > >   File 
> > > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/__init__.py",
> > >  line 8, in 
> > > from OpenSSL import crypto, SSL
> > >   File 
> > > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/crypto.py",
> > >  line 11, in 
> > > from OpenSSL._util import (
> > >   File 
> > > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/_util.py",
> > >  line 5, in 
> > > from cryptography.hazmat.bindings.openssl.binding import Binding
> > >   File 
> > > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
> > >  line 228, in 
> > > Binding.init_static_locks()
> > >   File 
> > > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
> > >  line 188, in init_static_locks
> > > cls._ensure_ffi_initialized()
> > >   File 
> > > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
> > >  line 176, in _ensure_ffi_initialized
> > > _openssl_assert(
> > >   File 
> > > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
> > >  line 90, in _openssl_assert
> > > raise InternalError(
> > > cryptography.exceptions.InternalError: Unknown OpenSSL error. This error 
> > > is commonly encountered when another library is not cleaning up the 
> > > OpenSSL error stack. If you are using cryptography with another library 
> > > that uses OpenSSL try disabling it before reporting a bug. Otherwise 
> > > please file an issue at https://github.com/pyca/cryptography/issues with 
> > > information on how to reproduce this. 
> > > ([_OpenSSLErrorWithText(code=310378599, lib=37, reason=103, 
> > > reason_text=b'error:12800067:DSO support routines::could not load the 
> > > shared library'), _OpenSSLErrorWithText(code=310378599, lib=37, 
> > > reason=103, reason_text=b'error:12800067:DSO support routines::could not 
> > > load the shared library'), _OpenSSLErrorWithText(code=126615813, lib=15, 
> > > reason=786693, reason_text=b'error:078C0105:common libcrypto 
> > > routines::init fail')])
> > > 
> > > This hacky patch enables enough functionality in
> > > python3-cryptography-native to work so that basic secure boot
> > > signing use cases work again.
> > > 
> > > Signed-off-by: Mikko Rapeli 
> > > ---
> > >  ...3-cryptography_hack_to_remove_legacy.patch | 54 +++
> > >  .../python/python3-cryptography_37.0.4.bb |  5 ++
> > >  2 files changed, 59 insertions(+)
> > >  create mode 100644 
> > > meta/recipes-devtools/python/python3-cryptography/python3-cryptography_hack_to_remove_legacy.patch
> > 
> > I'm very nervous about taking a patch like this as it would be near
> > impossible to tell when we still need it or not and it has zero chance
> > of making it upstream.
> > 
> > Do we know how the openssl library is breaking internally? Is this some
> > kind of glibc or loader mismatch? Is it mixing up our sysroot ssl
> > library with the host one somehow?
> 
> I could not see what exactly was wrong.
> 
> python3 is taken correctly from recipe-sysroot-native path, same for
> all shared libraries like openssl, cffi etc.
> I went through strace output of the test case and could not see what
> exactly is wrong there. All binaries are openat()'ed from
> the native sysroot, part from libc, pthreads and a few others which
> AFAIK are normal.

Are you using uninative? I'd have expected glibc and pthreads to come
from there rather than the host.

>  The openssl.cnf file
> is not found in native sysroot, which is another small bug, but that
> did not seem to fix this (I just hacked it to work, some
> absolute build openssl-native env path leaks into the openssl-native 

Re: [OE-core] [PATCH] python3-cryptography: workaround broken native functionality

[Mikko Rapeli]

Hi,

On Tue, 13 Sept 2022 at 13:01, Richard Purdie
 wrote:
>
> On Tue, 2022-09-13 at 12:34 +0300, Mikko Rapeli wrote:
> > The python3-cryptography-native builds work but are functionally broken
> > on Ubuntu 18.04 build host since the update from 3.3.2 in
> > meta-openembedded/meta-python. If recipe needs and DEPENDS on
> > python3-cryptography-native for signing use cases, loading
> > the python modules fails:
> >
> > $ python3 -c  "from OpenSSL import crypto"
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File 
> > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/__init__.py",
> >  line 8, in 
> > from OpenSSL import crypto, SSL
> >   File 
> > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/crypto.py",
> >  line 11, in 
> > from OpenSSL._util import (
> >   File 
> > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/_util.py",
> >  line 5, in 
> > from cryptography.hazmat.bindings.openssl.binding import Binding
> >   File 
> > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
> >  line 228, in 
> > Binding.init_static_locks()
> >   File 
> > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
> >  line 188, in init_static_locks
> > cls._ensure_ffi_initialized()
> >   File 
> > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
> >  line 176, in _ensure_ffi_initialized
> > _openssl_assert(
> >   File 
> > "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
> >  line 90, in _openssl_assert
> > raise InternalError(
> > cryptography.exceptions.InternalError: Unknown OpenSSL error. This error is 
> > commonly encountered when another library is not cleaning up the OpenSSL 
> > error stack. If you are using cryptography with another library that uses 
> > OpenSSL try disabling it before reporting a bug. Otherwise please file an 
> > issue at https://github.com/pyca/cryptography/issues with information on 
> > how to reproduce this. ([_OpenSSLErrorWithText(code=310378599, lib=37, 
> > reason=103, reason_text=b'error:12800067:DSO support routines::could not 
> > load the shared library'), _OpenSSLErrorWithText(code=310378599, lib=37, 
> > reason=103, reason_text=b'error:12800067:DSO support routines::could not 
> > load the shared library'), _OpenSSLErrorWithText(code=126615813, lib=15, 
> > reason=786693, reason_text=b'error:078C0105:common libcrypto routines::init 
> > fail')])
> >
> > This hacky patch enables enough functionality in
> > python3-cryptography-native to work so that basic secure boot
> > signing use cases work again.
> >
> > Signed-off-by: Mikko Rapeli 
> > ---
> >  ...3-cryptography_hack_to_remove_legacy.patch | 54 +++
> >  .../python/python3-cryptography_37.0.4.bb |  5 ++
> >  2 files changed, 59 insertions(+)
> >  create mode 100644 
> > meta/recipes-devtools/python/python3-cryptography/python3-cryptography_hack_to_remove_legacy.patch
>
> I'm very nervous about taking a patch like this as it would be near
> impossible to tell when we still need it or not and it has zero chance
> of making it upstream.
>
> Do we know how the openssl library is breaking internally? Is this some
> kind of glibc or loader mismatch? Is it mixing up our sysroot ssl
> library with the host one somehow?

I could not see what exactly was wrong.

python3 is taken correctly from recipe-sysroot-native path, same for
all shared libraries like openssl, cffi etc.
I went through strace output of the test case and could not see what
exactly is wrong there. All binaries are openat()'ed from
the native sysroot, part from libc, pthreads and a few others which
AFAIK are normal. The openssl.cnf file
is not found in native sysroot, which is another small bug, but that
did not seem to fix this (I just hacked it to work, some
absolute build openssl-native env path leaks into the openssl-native binaries).

The old version 3.3.2 version of python3-cryptography from
meta-openembedded/meta-python works without any problems.
It's just the new versions 35, 36 and 37 which have this issue.

On my Ubuntu 18.04 machine, python3-cryptography-native 35 and later
don't work at all without this workaround.
Would be nice to know if others can reproduce 

Re: [OE-core] [PATCH] python3-cryptography: workaround broken native functionality

[Richard Purdie]

On Tue, 2022-09-13 at 12:34 +0300, Mikko Rapeli wrote:
> The python3-cryptography-native builds work but are functionally broken
> on Ubuntu 18.04 build host since the update from 3.3.2 in
> meta-openembedded/meta-python. If recipe needs and DEPENDS on
> python3-cryptography-native for signing use cases, loading
> the python modules fails:
> 
> $ python3 -c  "from OpenSSL import crypto"
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/__init__.py",
>  line 8, in 
> from OpenSSL import crypto, SSL
>   File 
> "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/crypto.py",
>  line 11, in 
> from OpenSSL._util import (
>   File 
> "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/_util.py",
>  line 5, in 
> from cryptography.hazmat.bindings.openssl.binding import Binding
>   File 
> "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
>  line 228, in 
> Binding.init_static_locks()
>   File 
> "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
>  line 188, in init_static_locks
> cls._ensure_ffi_initialized()
>   File 
> "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
>  line 176, in _ensure_ffi_initialized
> _openssl_assert(
>   File 
> "/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
>  line 90, in _openssl_assert
> raise InternalError(
> cryptography.exceptions.InternalError: Unknown OpenSSL error. This error is 
> commonly encountered when another library is not cleaning up the OpenSSL 
> error stack. If you are using cryptography with another library that uses 
> OpenSSL try disabling it before reporting a bug. Otherwise please file an 
> issue at https://github.com/pyca/cryptography/issues with information on how 
> to reproduce this. ([_OpenSSLErrorWithText(code=310378599, lib=37, 
> reason=103, reason_text=b'error:12800067:DSO support routines::could not load 
> the shared library'), _OpenSSLErrorWithText(code=310378599, lib=37, 
> reason=103, reason_text=b'error:12800067:DSO support routines::could not load 
> the shared library'), _OpenSSLErrorWithText(code=126615813, lib=15, 
> reason=786693, reason_text=b'error:078C0105:common libcrypto routines::init 
> fail')])
> 
> This hacky patch enables enough functionality in
> python3-cryptography-native to work so that basic secure boot
> signing use cases work again.
> 
> Signed-off-by: Mikko Rapeli 
> ---
>  ...3-cryptography_hack_to_remove_legacy.patch | 54 +++
>  .../python/python3-cryptography_37.0.4.bb |  5 ++
>  2 files changed, 59 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/python/python3-cryptography/python3-cryptography_hack_to_remove_legacy.patch

I'm very nervous about taking a patch like this as it would be near
impossible to tell when we still need it or not and it has zero chance
of making it upstream.

Do we know how the openssl library is breaking internally? Is this some
kind of glibc or loader mismatch? Is it mixing up our sysroot ssl
library with the host one somehow?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170566): 
https://lists.openembedded.org/g/openembedded-core/message/170566
Mute This Topic: https://lists.openembedded.org/mt/93651845/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] OE-core CVE metrics for master on Sun 11 Sep 2022 04:00:01 AM HST

[Richard Purdie]

On Mon, 2022-09-12 at 18:45 -0700, Khem Raj wrote:
> On 9/11/22 7:02 AM, Steve Sakoman wrote:
> > Branch: master
> > 
> > New this week: 10 CVEs
> > CVE-2020-35538 (CVSS3: 5.5 MEDIUM): libjpeg-turbo:libjpeg-turbo-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35538 *
> > CVE-2022-1354 (CVSS3: 5.5 MEDIUM): tiff 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1354 *
> > CVE-2022-1355 (CVSS3: 6.1 MEDIUM): tiff 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1355 *
> > CVE-2022-3099 (CVSS3: 7.8 HIGH): vim 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3099 *
> > CVE-2022-3134 (CVSS3: 7.8 HIGH): vim 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3134 *
> > CVE-2022-38126 (CVSS3: 5.5 MEDIUM): 
> > binutils:binutils-cross-testsuite:binutils-cross-x86_64 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38126 *
> > CVE-2022-38127 (CVSS3: 5.5 MEDIUM): 
> > binutils:binutils-cross-testsuite:binutils-cross-x86_64 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38127 *
> > CVE-2022-38128 (CVSS3: 5.5 MEDIUM): 
> > binutils:binutils-cross-testsuite:binutils-cross-x86_64 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38128 *
> > CVE-2022-39028 (CVSS3: 7.5 HIGH): inetutils 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-39028 *
> > CVE-2022-39046 (CVSS3: 5.3 MEDIUM): glibc 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-39046 *
> > 
> > Removed this week: 4 CVEs
> > CVE-2021-3929 (CVSS3: 8.2 HIGH): qemu:qemu-native:qemu-system-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3929 *
> > CVE-2022-2953 (CVSS3: 5.5 MEDIUM): tiff 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-2953 *
> > CVE-2022-32893 (CVSS3: 8.8 HIGH): webkitgtk 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-32893 *
> > CVE-2022-38533 (CVSS3: 5.5 MEDIUM): 
> > binutils:binutils-cross-testsuite:binutils-cross-x86_64 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38533 *
> > 
> > Full list:  Found 15 unpatched CVEs
> > CVE-2020-35538 (CVSS3: 5.5 MEDIUM): libjpeg-turbo:libjpeg-turbo-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35538 *
> 
> We are at 2.1.4 in master and this was fixed in 2.0.6 via 
> https://github.com/libjpeg-turbo/libjpeg-turbo/commit/9120a247436e84c0b4eea828cb11e8f665fcde30
>  
> so I wonder why its being flagged.

The CVE entry says 2.0.5 onwards. I've emailed them to suggest it apply
to 2.0.5 only as 2.0.6 is fixed.

> > CVE-2021-3521 (CVSS3: 4.7 MEDIUM): rpm:rpm-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3521 *
> > CVE-2021-35937 (CVSS3: 6.4 MEDIUM): rpm:rpm-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35937 *
> > CVE-2021-35938 (CVSS3: 7.8 HIGH): rpm:rpm-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35938 *
> > CVE-2021-35939 (CVSS3: 7.8 HIGH): rpm:rpm-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35939 *
> > CVE-2021-4158 (CVSS3: 6.0 MEDIUM): qemu:qemu-native:qemu-system-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-4158 *
> > CVE-2022-1354 (CVSS3: 5.5 MEDIUM): tiff 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1354 *
> > CVE-2022-1355 (CVSS3: 6.1 MEDIUM): tiff 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1355 *
> 
> there is a patch on ml for this.

The version restrictions on those are also wrong. I've sent email to
correct them.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170565): 
https://lists.openembedded.org/g/openembedded-core/message/170565
Mute This Topic: https://lists.openembedded.org/mt/93611544/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] OE-core CVE metrics for master on Sun 11 Sep 2022 04:00:01 AM HST

[Richard Purdie]

On Mon, 2022-09-12 at 18:45 -0700, Khem Raj wrote:
> On 9/11/22 7:02 AM, Steve Sakoman wrote:
> 
> > CVE-2021-3521 (CVSS3: 4.7 MEDIUM): rpm:rpm-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3521 *
> > CVE-2021-35937 (CVSS3: 6.4 MEDIUM): rpm:rpm-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35937 *
> > CVE-2021-35938 (CVSS3: 7.8 HIGH): rpm:rpm-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35938 *
> > CVE-2021-35939 (CVSS3: 7.8 HIGH): rpm:rpm-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35939 *
> > CVE-2021-4158 (CVSS3: 6.0 MEDIUM): qemu:qemu-native:qemu-system-native 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-4158 *
> > CVE-2022-1354 (CVSS3: 5.5 MEDIUM): tiff 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1354 *
> > CVE-2022-1355 (CVSS3: 6.1 MEDIUM): tiff 
> > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1355 *
> 
> there is a patch on ml for this.

These were merged and we also upgraded tiff to 4.4.0 which then dropped
the patches. 4.4.0 should contain those fixes but the CPE entry
upstream doesn't have version constraints. We probably need to contact
them to fix that.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170564): 
https://lists.openembedded.org/g/openembedded-core/message/170564
Mute This Topic: https://lists.openembedded.org/mt/93611544/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] binutils: stable 2.38 branch updates

[Sundeep KOKKONDA]

Hello,

I am planning to take the gcc, glibc & binutils updates to Kirkstone. I found 
only the glibc-2.35 branch is having a few updates (given below).

f8ad66a4ca nscd: Fix netlink cache invalidation if epoll is used [BZ #29415]
9e960717e1 Apply asm redirections in wchar.h before first use
577c2fc7f3 elf: Call __libc_early_init for reused namespaces (bug 29528)
83f1d9851e NEWS: Add entry for bug 28846
cbd8685e82 socket: Check lengths before advancing pointer in CMSG_NXTHDR
4bafc4001d alpha: Fix generic brk system call emulation in __brk_call (bug 
29490)
37fd2ac665 stdlib: Fixup mbstowcs NULL __dst handling. [BZ #29279]
a1ec4157bc stdlib: Remove attr_write from mbstows if dst is NULL [BZ: 29265]
813a8d0171 Update syscall lists for Linux 5.19
e200127c6c riscv: Update rv64 libm test ulps
8c172a6cb0 dlfcn: Pass caller pointer to static dlopen implementation (bug 
29446)

The binutils-2.38 has no new commits. And, gcc-11.x also not have any new 
release after 11.3.

In master branch gcc_12.2, glibc_2.36 & binutils_2.39 versions are used. 
Kirkstone will continue to use the old versions?

Thanks,
Sundeep K.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170563): 
https://lists.openembedded.org/g/openembedded-core/message/170563
Mute This Topic: https://lists.openembedded.org/mt/92739561/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] python3-cryptography: workaround broken native functionality

[Mikko Rapeli]

The python3-cryptography-native builds work but are functionally broken
on Ubuntu 18.04 build host since the update from 3.3.2 in
meta-openembedded/meta-python. If recipe needs and DEPENDS on
python3-cryptography-native for signing use cases, loading
the python modules fails:

$ python3 -c  "from OpenSSL import crypto"
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/__init__.py",
 line 8, in 
from OpenSSL import crypto, SSL
  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/crypto.py",
 line 11, in 
from OpenSSL._util import (
  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/_util.py",
 line 5, in 
from cryptography.hazmat.bindings.openssl.binding import Binding
  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
 line 228, in 
Binding.init_static_locks()
  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
 line 188, in init_static_locks
cls._ensure_ffi_initialized()
  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
 line 176, in _ensure_ffi_initialized
_openssl_assert(
  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
 line 90, in _openssl_assert
raise InternalError(
cryptography.exceptions.InternalError: Unknown OpenSSL error. This error is 
commonly encountered when another library is not cleaning up the OpenSSL error 
stack. If you are using cryptography with another library that uses OpenSSL try 
disabling it before reporting a bug. Otherwise please file an issue at 
https://github.com/pyca/cryptography/issues with information on how to 
reproduce this. ([_OpenSSLErrorWithText(code=310378599, lib=37, reason=103, 
reason_text=b'error:12800067:DSO support routines::could not load the shared 
library'), _OpenSSLErrorWithText(code=310378599, lib=37, reason=103, 
reason_text=b'error:12800067:DSO support routines::could not load the shared 
library'), _OpenSSLErrorWithText(code=126615813, lib=15, reason=786693, 
reason_text=b'error:078C0105:common libcrypto routines::init fail')])

This hacky patch enables enough functionality in
python3-cryptography-native to work so that basic secure boot
signing use cases work again.

Signed-off-by: Mikko Rapeli 
---
 ...3-cryptography_hack_to_remove_legacy.patch | 54 +++
 .../python/python3-cryptography_37.0.4.bb |  5 ++
 2 files changed, 59 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3-cryptography/python3-cryptography_hack_to_remove_legacy.patch

diff --git 
a/meta/recipes-devtools/python/python3-cryptography/python3-cryptography_hack_to_remove_legacy.patch
 
b/meta/recipes-devtools/python/python3-cryptography/python3-cryptography_hack_to_remove_legacy.patch
new file mode 100644
index 00..74b1cff248
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-cryptography/python3-cryptography_hack_to_remove_legacy.patch
@@ -0,0 +1,54 @@
+python3-cryptography: ignore broken legacy providers
+
+These are broken on python3-cryptography-native builds
+since update from python3-cryptography 3.3.2 in meta-openembedded/meta-python
+to the new rust based versions 35 and newer.
+
+Test case on Ubuntu 18.04 build host, a recipe which needs
+python3-cryptography-native for e.g. signing secure boot binaries:
+
+# python3 -c  "from OpenSSL import crypto"
+Traceback (most recent call last):
+  File "", line 1, in 
+  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/__init__.py",
 line 8, in 
+from OpenSSL import crypto, SSL
+  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/crypto.py",
 line 11, in 
+from OpenSSL._util import (
+  File 
"/home/builder/poky/build_kirkstone/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/recipe-sysroot-native/usr/lib/python3.10/site-packages/OpenSSL/_util.py",
 line 5, in 
+from cryptography.hazmat.bindings.openssl.binding import Binding
+  File 

[OE-core] [PATCH] selftest/qemurunner: Work around possible control character contamination

[Richard Purdie]

Using a binary string as the login banner search expression is fraught with
risks. We've seen cases on the autobuilder where "login:" is clearly shown
but the code hasn't triggered. The most likely cause is hidden control 
characters
in the output causing the search to fail.

Take the opportunity to remove the horrible binary string search, at the 
expense of
decoding the bootlog multiple times.

Tweak the logging so we can know which log was printed (self.msg or bootlog)
just in case this isn't the issue and we need more information in future.

Signed-off-by: Richard Purdie 
---
 meta/classes-recipe/testimage.bbclass |  6 +-
 meta/lib/oeqa/utils/qemurunner.py | 21 +
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/meta/classes-recipe/testimage.bbclass 
b/meta/classes-recipe/testimage.bbclass
index 8d2fab21dff..819c7d2bf4c 100644
--- a/meta/classes-recipe/testimage.bbclass
+++ b/meta/classes-recipe/testimage.bbclass
@@ -189,11 +189,7 @@ def get_testimage_boot_patterns(d):
 search_login_succeeded,search_cmd_finished\n Make sure 
your TESTIMAGE_BOOT_PATTERNS=%s \
 contains an accepted flag.' % 
d.getVar('TESTIMAGE_BOOT_PATTERNS'))
 return
-# We know boot prompt is searched through in binary format, 
others might be expressions
-if flag == 'search_reached_prompt':
-boot_patterns[flag] = flagval.encode()
-else:
-boot_patterns[flag] = 
flagval.encode().decode('unicode-escape')
+boot_patterns[flag] = flagval.encode().decode('unicode-escape')
 return boot_patterns
 
 
diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 948f8adc9f1..6a85f57e498 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -85,7 +85,7 @@ class QemuRunner:
 accepted_patterns = ['search_reached_prompt', 'send_login_user', 
'search_login_succeeded', 'search_cmd_finished']
 default_boot_patterns = defaultdict(str)
 # Default to the usual paterns used to communicate with the target
-default_boot_patterns['search_reached_prompt'] = b' login:'
+default_boot_patterns['search_reached_prompt'] = ' login:'
 default_boot_patterns['send_login_user'] = 'root\n'
 default_boot_patterns['search_login_succeeded'] = 
r"root@[a-zA-Z0-9\-]+:~#"
 default_boot_patterns['search_cmd_finished'] = 
r"[a-zA-Z0-9]+@[a-zA-Z0-9\-]+:~#"
@@ -109,12 +109,15 @@ class QemuRunner:
 sock.close()
 raise
 
+def decode_qemulog(self, todecode):
+# Sanitize the data received from qemu as it may contain control 
characters
+msg = todecode.decode("utf-8", errors='ignore')
+msg = re_control_char.sub('', msg)
+return msg
+
 def log(self, msg):
 if self.logfile:
-# It is needed to sanitize the data received from qemu
-# because is possible to have control characters
-msg = msg.decode("utf-8", errors='ignore')
-msg = re_control_char.sub('', msg)
+msg = self.decode_qemulog(msg)
 self.msg += msg
 with codecs.open(self.logfile, "a", encoding="utf-8") as f:
 f.write("%s" % msg)
@@ -468,7 +471,9 @@ class QemuRunner:
 self.log(data)
 
 data = b''
-if self.boot_patterns['search_reached_prompt'] in 
bootlog:
+
+decodedlog = self.decode_qemulog(bootlog)
+if self.boot_patterns['search_reached_prompt'] in 
decodedlog:
 self.server_socket = qemusock
 stopread = True
 reachedlogin = True
@@ -488,10 +493,10 @@ class QemuRunner:
 self.logger.warning("Target didn't reach login banner in %d 
seconds (%s)" %
   (self.boottime, time.strftime("%D 
%H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
-bootlog = bootlog.decode("utf-8")
+bootlog = self.decode_qemulog(bootlog)
 # in case bootlog is empty, use tail qemu log store at self.msg
 lines = tail(bootlog if bootlog else self.msg)
-self.logger.warning("Last 25 lines of text:\n%s" % lines)
+self.logger.warning("Last 25 lines of text (%d):\n%s" % 
(len(bootlog), lines))
 self.logger.warning("Check full boot log: %s" % self.logfile)
 self._dump_host()
 self.stop()
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170561): 
https://lists.openembedded.org/g/openembedded-core/message/170561
Mute This Topic: https://lists.openembedded.org/mt/93651820/21656
Group Owner: 

Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-4.1_M3.rc2)

[Teoh, Jay Shen]

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-4.1_M3.rc2. 
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. NUC 6
4. Edgerouter
5. Beaglebone

ETA for completion next Monday, September 19.

Thanks,
Jay

> -Original Message-
> From: yo...@lists.yoctoproject.org  On Behalf
> Of Pokybuild User
> Sent: Monday, 12 September, 2022 9:00 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [yocto] QA notification for completed autobuilder build (yocto-
> 4.1_M3.rc2)
> 
> 
> A build flagged for QA (yocto-4.1_M3.rc2) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.1_M3.rc2
> 
> 
> Build hash information:
> 
> bitbake: 6424f4b7e9c1ba8db81346e8b3a806dd035d4551
> meta-agl: e4ea839db9c26e78175d61388c5408a79f6927dc
> meta-arm: 261263a6701ab3530ff997643d08da50ac20
> meta-aws: a16f35a73bff26d9506f519451dc75034211d61b
> meta-gplv2: 43bf0e8d5985945d19d01f94bfbbda420c4435f3
> meta-intel: 9d2820d4bf436924db845de28850a807f9fdef87
> meta-mingw: 8327efb6334b9187fbaf7c871de4446c6863b3c5
> meta-openembedded: 09e086812aab7ca6ee480fb625966e2318174345
> meta-virtualization: 538e94e674dc1be0b0fee5da54083ca040b2f7b9
> oecore: bf5968bce59d5e5c777407dba431be3aec012404
> poky: 987e1503f733068d774ccf440b6f4e23e833571e
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 

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