[OE-core] [dunfell] [PATCH] flex: Exclude CVE-2015-1773 from cve-check.

2023-08-31 Thread Dhairya Nagodra via lists.openembedded.org
Issue only affects Apache.

Signed-off-by: Dhairya Nagodra 
---
 meta/recipes-devtools/flex/flex_2.6.4.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb 
b/meta/recipes-devtools/flex/flex_2.6.4.bb
index 50d3bf8de1..7eb7da355f 100644
--- a/meta/recipes-devtools/flex/flex_2.6.4.bb
+++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
@@ -31,6 +31,9 @@ UPSTREAM_CHECK_REGEX = "flex-(?P\d+(\.\d+)+)\.tar"
 # https://github.com/westes/flex/issues/414
 CVE_CHECK_WHITELIST += "CVE-2019-6293"
 
+# Issue only affects Apache vendor, not us.
+CVE_CHECK_WHITELIST += "CVE-2015-1773"
+
 inherit autotools gettext texinfo ptest
 
 M4 = "${bindir}/m4"
-- 
2.35.6


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



[OE-core] [mickledore] [PATCH] flex: Exclude CVE-2015-1773 from cve-check.

2023-08-31 Thread Dhairya Nagodra via lists.openembedded.org
Issue only affects Apache.

Signed-off-by: Dhairya Nagodra 
---
 meta/recipes-devtools/flex/flex_2.6.4.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb 
b/meta/recipes-devtools/flex/flex_2.6.4.bb
index 15cf6f5cca..7201977857 100644
--- a/meta/recipes-devtools/flex/flex_2.6.4.bb
+++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
@@ -31,6 +31,9 @@ GITHUB_BASE_URI = "https://github.com/westes/flex/releases;
 # https://github.com/westes/flex/issues/414
 CVE_CHECK_IGNORE += "CVE-2019-6293"
 
+# Issue only affects Apache vendor, not us.
+CVE_CHECK_IGNORE += "CVE-2015-1773"
+
 inherit autotools gettext texinfo ptest github-releases
 
 M4 = "${bindir}/m4"
-- 
2.35.6


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186992): 
https://lists.openembedded.org/g/openembedded-core/message/186992
Mute This Topic: https://lists.openembedded.org/mt/101088511/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] flex: Exclude CVE-2015-1773 from cve-check.

2023-08-31 Thread Dhairya Nagodra via lists.openembedded.org
Issue only affects Apache.

Signe-off-by: Dhairya Nagodra 
---
 meta/recipes-devtools/flex/flex_2.6.4.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb 
b/meta/recipes-devtools/flex/flex_2.6.4.bb
index c7cd965347..266507d7ac 100644
--- a/meta/recipes-devtools/flex/flex_2.6.4.bb
+++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
@@ -33,6 +33,9 @@ UPSTREAM_CHECK_REGEX = "flex-(?P\d+(\.\d+)+)\.tar"
 # https://github.com/westes/flex/issues/414
 CVE_CHECK_IGNORE += "CVE-2019-6293"
 
+# Issue only affects Apache vendor, not us.
+CVE_CHECK_IGNORE += "CVE-2015-1773"
+
 inherit autotools gettext texinfo ptest
 
 M4 = "${bindir}/m4"
-- 
2.35.6


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186991): 
https://lists.openembedded.org/g/openembedded-core/message/186991
Mute This Topic: https://lists.openembedded.org/mt/101088497/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] [master] [PATCH] flex: Exclude CVE-2015-1773 from cve-check.

2023-08-31 Thread Dhairya Nagodra via lists.openembedded.org
Hi @Steve Sakoman @richard.pur...@linuxfoundation.org,

Kindly consider this patch for "master" branch.
Apologies for the error.

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Dhairya Nagodra via
> lists.openembedded.org
> Sent: Friday, September 1, 2023 9:38 AM
> To: openembedded-core@lists.openembedded.org
> Cc: qi.c...@windriver.com; xe-linux-external(mailer list)  exter...@cisco.com>; Dhairya Nagodra -X (dnagodra - E-INFO CHIPS INC at
> Cisco) 
> Subject: [OE-core] [dunfell] [PATCH] flex: Exclude CVE-2015-1773 from cve-
> check.
> 
> Issue only affects Apache.
> 
> Signed-off-by: Dhairya Nagodra 
> ---
>  meta/recipes-devtools/flex/flex_2.6.4.bb | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb b/meta/recipes-
> devtools/flex/flex_2.6.4.bb
> index 1ac88d65ef..5be7351f4c 100644
> --- a/meta/recipes-devtools/flex/flex_2.6.4.bb
> +++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
> @@ -31,6 +31,8 @@ CVE_STATUS[CVE-2019-6293] = "upstream-wontfix: \
> there is stack exhaustion but no bug and it is building the \  parser, not
> running it, effectively similar to a compiler ICE. Upstream no plans to 
> address
> this."
> 
> +CVE_STATUS[CVE-2015-1773] = "not-applicable-platform: Issue only affects
> Apache."
> +
>  inherit autotools gettext texinfo ptest github-releases
> 
>  M4 = "${bindir}/m4"
> --
> 2.35.6


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186990): 
https://lists.openembedded.org/g/openembedded-core/message/186990
Mute This Topic: https://lists.openembedded.org/mt/101088488/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] flex: Exclude CVE-2015-1773 from cve-check.

2023-08-31 Thread Dhairya Nagodra via lists.openembedded.org
Issue only affects Apache.

Signed-off-by: Dhairya Nagodra 
---
 meta/recipes-devtools/flex/flex_2.6.4.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb 
b/meta/recipes-devtools/flex/flex_2.6.4.bb
index 1ac88d65ef..5be7351f4c 100644
--- a/meta/recipes-devtools/flex/flex_2.6.4.bb
+++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
@@ -31,6 +31,8 @@ CVE_STATUS[CVE-2019-6293] = "upstream-wontfix: \
 there is stack exhaustion but no bug and it is building the \
 parser, not running it, effectively similar to a compiler ICE. Upstream no 
plans to address this."
 
+CVE_STATUS[CVE-2015-1773] = "not-applicable-platform: Issue only affects 
Apache."
+
 inherit autotools gettext texinfo ptest github-releases
 
 M4 = "${bindir}/m4"
-- 
2.35.6


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186989): 
https://lists.openembedded.org/g/openembedded-core/message/186989
Mute This Topic: https://lists.openembedded.org/mt/101088411/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] kernel.bbclass: Add force flag to rm calls

2023-08-31 Thread Ryan Eatmon via lists.openembedded.org
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it.  Simple fix is to add the
-f (force) flag to the call.

Signed-off-by: Ryan Eatmon 
---
v2: Switch from if exists wrapper to -f flag on rm.

 meta/classes-recipe/kernel.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/kernel.bbclass 
b/meta/classes-recipe/kernel.bbclass
index acb43bd4d5..2ec9ea2091 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -454,8 +454,8 @@ kernel_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
oe_runmake DEPMOD=echo 
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION} 
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
-   rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
-   rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+   rm -f 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
+   rm -f 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
# Remove empty module directories to prevent QA issues
find 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d -empty 
-delete
else
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186988): 
https://lists.openembedded.org/g/openembedded-core/message/186988
Mute This Topic: https://lists.openembedded.org/mt/101083154/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] kernel.bbclass: Add file exist checks around removes

2023-08-31 Thread Ryan Eatmon via lists.openembedded.org



On 8/31/2023 1:26 PM, Ryan Eatmon via lists.openembedded.org wrote:


With two votes I'll send a v2.

No, I have not done that thorough of an investigation into what happened 
to the source file.  My thought was just to get the build working so 
that our nightly upstream testing (latest kernel, uboot, optee-os, 
trusted-firmeware) would not be blocked.  But I can look into it deeper 
and let you know.


It looks like they reworked how make modules_install worked.  They moved 
the logic into a files scripts/Makefile.modinst.  And all they seem to 
have removed was the symlink to the source tree.  The symlink build is 
still there.





On 8/31/2023 12:58 PM, Peter Kjellerstedt wrote:

For what it’s worth, I would also go with rm -f.

Also, have you checked so that the files have not just been 
moved/renamed? I.e., are they produced in some other location where 
they should now also be removed from?


//Peter

*From:*openembedded-core@lists.openembedded.org 
 *On Behalf Of *Frederic 
Martinsons

*Sent:* den 31 augusti 2023 18:57
*To:* Ryan Eatmon 
*Cc:* openembedded-core@lists.openembedded.org
*Subject:* Re: [OE-core][PATCH] kernel.bbclass: Add file exist checks 
around removes


On Thu, 31 Aug 2023 at 15:49, Ryan Eatmon > wrote:




    On 8/31/2023 8:47 AM, Frédéric Martinsons wrote:
 > Hello,
 >
 > On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via
    lists.openembedded.org 
 > >
    mailto:ti@lists.openembedded.org>
 > >> wrote:
 >
 >     The latest 6.5 kernels do not appear to create the source 
file in

 >     ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source
    so the
 >     recipe errors out when trying to remove it.  Simple fix is to
    add an
 >     exists check around the call.
    >     >     Signed-off-by: Ryan Eatmon >>
    >     ---
    >       meta/classes-recipe/kernel.bbclass | 8 ++--
    >       1 file changed, 6 insertions(+), 2 deletions(-)
    >     >     diff --git a/meta/classes-recipe/kernel.bbclass
    >     b/meta/classes-recipe/kernel.bbclass
    >     index acb43bd4d5..4df052061b 100644
    >     --- a/meta/classes-recipe/kernel.bbclass
    >     +++ b/meta/classes-recipe/kernel.bbclass
    >     @@ -454,8 +454,12 @@ kernel_do_install() {
    >              unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
    >              if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
    >                      oe_runmake 
DEPMOD=echoMODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
    >     -  
 rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
    >     -  
 rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
    >     +               if [ 
-e"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
    >     +  
 rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"

    >     +               fi
    >     +               if [ 
-e"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
    >     +  
 rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"

    >     +               fi
    >                      # Remove empty module directories to 
prevent QA issues
    >  
find"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -typed

    -empty -delete
    >              else
    >     --     >     2.17.1
    >     >     > My 2 cents: the "-f" switch 
makes rm ignore nonexistent files , and it     > will make a shorter 
patch ;)


    If that is the group consensus I can submit a v2. Anyone else feel 
that

    way?

Don't know if a "group consensus" can exist here. (it is a public list

where anyone can raise remarks) and there is no "vote".

Mine was not a "cons" for you patch, what you did is completely valid,

I just wanted to say that there was a more concise way of doing it.

Feel free to send a v2 if you think my remark is relevant.


 >
 >
 >

    --     Ryan Eatmon reat...@ti.com 
    -
    Texas Instruments, Inc.  -  LCPD  -  MGTS









--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc.  -  LCPD  -  MGTS

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

Re: [OE-core][PATCH] kernel.bbclass: Add file exist checks around removes

2023-08-31 Thread Ryan Eatmon via lists.openembedded.org


With two votes I'll send a v2.

No, I have not done that thorough of an investigation into what happened 
to the source file.  My thought was just to get the build working so 
that our nightly upstream testing (latest kernel, uboot, optee-os, 
trusted-firmeware) would not be blocked.  But I can look into it deeper 
and let you know.



On 8/31/2023 12:58 PM, Peter Kjellerstedt wrote:

For what it’s worth, I would also go with rm -f.

Also, have you checked so that the files have not just been 
moved/renamed? I.e., are they produced in some other location where they 
should now also be removed from?


//Peter

*From:*openembedded-core@lists.openembedded.org 
 *On Behalf Of *Frederic 
Martinsons

*Sent:* den 31 augusti 2023 18:57
*To:* Ryan Eatmon 
*Cc:* openembedded-core@lists.openembedded.org
*Subject:* Re: [OE-core][PATCH] kernel.bbclass: Add file exist checks 
around removes


On Thu, 31 Aug 2023 at 15:49, Ryan Eatmon > wrote:




On 8/31/2023 8:47 AM, Frédéric Martinsons wrote:
 > Hello,
 >
 > On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via
lists.openembedded.org 
 > >
mailto:ti@lists.openembedded.org>
 > >> wrote:
 >
 >     The latest 6.5 kernels do not appear to create the source file in
 >     ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source
so the
 >     recipe errors out when trying to remove it.  Simple fix is to
add an
 >     exists check around the call.
> 
>     Signed-off-by: Ryan Eatmon mailto:reat...@ti.com>>>
>     ---
>       meta/classes-recipe/kernel.bbclass | 8 ++--
>       1 file changed, 6 insertions(+), 2 deletions(-)
> 
>     diff --git a/meta/classes-recipe/kernel.bbclass

>     b/meta/classes-recipe/kernel.bbclass
>     index acb43bd4d5..4df052061b 100644
>     --- a/meta/classes-recipe/kernel.bbclass
>     +++ b/meta/classes-recipe/kernel.bbclass
>     @@ -454,8 +454,12 @@ kernel_do_install() {
>              unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
>              if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
>                      oe_runmake 
DEPMOD=echoMODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware
 modules_install
>     -               
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
>     -               
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
>     +               if [ 
-e"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
>     +                       
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
>     +               fi
>     +               if [ 
-e"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
>     +                       
rm"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
>     +               fi
>                      # Remove empty module directories to prevent QA 
issues
>                      
find"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -typed
-empty -delete
>              else
>     -- 
>     2.17.1
> 
> 
> My 2 cents: the "-f" switch makes rm ignore nonexistent files , and it 
> will make a shorter patch ;)


If that is the group consensus I can submit a v2. Anyone else feel that
way?

Don't know if a "group consensus" can exist here. (it is a public list

where anyone can raise remarks) and there is no "vote".

Mine was not a "cons" for you patch, what you did is completely valid,

I just wanted to say that there was a more concise way of doing it.

Feel free to send a v2 if you think my remark is relevant.


 >
 >
 >

-- 
Ryan Eatmon reat...@ti.com 

-
Texas Instruments, Inc.  -  LCPD  -  MGTS



--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc.  -  LCPD  -  MGTS

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186986): 
https://lists.openembedded.org/g/openembedded-core/message/186986
Mute This Topic: https://lists.openembedded.org/mt/101073782/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] kernel.bbclass: Add file exist checks around removes

2023-08-31 Thread Peter Kjellerstedt
For what it’s worth, I would also go with rm -f.

Also, have you checked so that the files have not just been moved/renamed? 
I.e., are they produced in some other location where they should now also be 
removed from?

//Peter

From: openembedded-core@lists.openembedded.org 
 On Behalf Of Frederic Martinsons
Sent: den 31 augusti 2023 18:57
To: Ryan Eatmon 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH] kernel.bbclass: Add file exist checks around 
removes



On Thu, 31 Aug 2023 at 15:49, Ryan Eatmon 
mailto:reat...@ti.com>> wrote:


On 8/31/2023 8:47 AM, Frédéric Martinsons wrote:
> Hello,
>
> On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via 
> lists.openembedded.org
>  
> mailto:ti@lists.openembedded.org>
> >> 
> wrote:
>
> The latest 6.5 kernels do not appear to create the source file in
> ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
> recipe errors out when trying to remove it.  Simple fix is to add an
> exists check around the call.
>
> Signed-off-by: Ryan Eatmon mailto:reat...@ti.com> 
> >>
> ---
>   meta/classes-recipe/kernel.bbclass | 8 ++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> index acb43bd4d5..4df052061b 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -454,8 +454,12 @@ kernel_do_install() {
>  unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
>  if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
>  oe_runmake DEPMOD=echo 
> MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION} 
> INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
> -   rm 
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> -   rm 
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> +   if [ -e 
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
> +   rm 
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> +   fi
> +   if [ -e 
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
> +   rm 
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> +   fi
>  # Remove empty module directories to prevent QA issues
>  find 
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d -empty 
> -delete
>  else
> --
> 2.17.1
>
>
> My 2 cents: the "-f" switch makes rm ignore nonexistent files , and it
> will make a shorter patch ;)

If that is the group consensus I can submit a v2.  Anyone else feel that
way?
Don't know if a "group consensus" can exist here. (it is a public list
where anyone can raise remarks) and there is no "vote".

Mine was not a "cons" for you patch, what you did is completely valid,
I just wanted to say that there was a more concise way of doing it.

Feel free to send a v2 if you think my remark is relevant.


>
>
>

--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc.  -  LCPD  -  MGTS

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



Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"

2023-08-31 Thread Peter Kjellerstedt
> -Original Message-
> From: Ryan Eatmon 
> Sent: den 28 augusti 2023 19:10
> To: Peter Kjellerstedt ; Max Krummenacher
> ; openembedded-core@lists.openembedded.org
> Cc: Max Krummenacher ; Randolph Sapp
> 
> Subject: Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit
> the default dependencies"
> 
> On 8/27/2023 4:23 PM, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: Max Krummenacher 
> >> Sent: den 27 augusti 2023 10:10
> >> To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
> >> 
> >> Cc: Max Krummenacher ; Randolph Sapp
> >> 
> >> Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the
> >> default dependencies"
> >>
> >> From: Max Krummenacher 
> >>
> >> Hi
> >>
> >> With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
> >> dependencies") applied I'm getting a lot of these errors, i.e. qa
> >> does miss libc and compiler provided libs:
> >>
> >> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> >> /usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
> >> requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found
> >> in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> >> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> >> /usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
> >> requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
> >> RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> >> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> >> /usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-
> >> umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers
> >> found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> >>
> >> Reverting the commit makes the build pass, alternatively adding
> >> to depends in the recipe which is using the bin_package class
> >> fixes it too:
> >>
> >> DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
> >>
> >> I'd prefer reverting removing the default dependencies over fixing
> >> each of the recipes which do use the bin_package class to actually
> >> install binaries running in the target user space.
> >>
> >> Any opinions?
> >
> > Bummer. I guess we will have to update our recipes individually
> > instead. :(
> 
> Was there some issue that your patch was seeking to solve?  There was
> not much explanation in your patch or discussion about it on the mailing
> list before it was accepted.
> 
> Or did this just seem like something to do since this class doesn't
> build anything?

It just seemed logical that since nothing is built, there should be 
no need for the compiler. I did, however, miss the potential need for 
the runtime libraries.
 
> Just looking for background.
> 
> Your commit is also the source of another error with this the same
> ti-img-rogue-umlibs recipe that I've been trying to track down all last
> week.  Max just beat me to finding it.
> 
> I'm voting to revert your patch unless there is compelling reason for
> your patch.

If it was not obvious from my response above, I am in favor of reverting 
my change since the errors reported by Max obviously was not part of my 
use case and did not affect any of our recipes.

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186984): 
https://lists.openembedded.org/g/openembedded-core/message/186984
Mute This Topic: https://lists.openembedded.org/mt/100987453/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] kernel.bbclass: Add file exist checks around removes

2023-08-31 Thread Frederic Martinsons
On Thu, 31 Aug 2023 at 15:49, Ryan Eatmon  wrote:

>
>
> On 8/31/2023 8:47 AM, Frédéric Martinsons wrote:
> > Hello,
> >
> > On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via lists.openembedded.org
> >   > > wrote:
> >
> > The latest 6.5 kernels do not appear to create the source file in
> > ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
> > recipe errors out when trying to remove it.  Simple fix is to add an
> > exists check around the call.
> >
> > Signed-off-by: Ryan Eatmon mailto:reat...@ti.com>>
> > ---
> >   meta/classes-recipe/kernel.bbclass | 8 ++--
> >   1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/classes-recipe/kernel.bbclass
> > b/meta/classes-recipe/kernel.bbclass
> > index acb43bd4d5..4df052061b 100644
> > --- a/meta/classes-recipe/kernel.bbclass
> > +++ b/meta/classes-recipe/kernel.bbclass
> > @@ -454,8 +454,12 @@ kernel_do_install() {
> >  unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
> >  if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
> >  oe_runmake DEPMOD=echo
> > MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}
> > INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
> > -   rm
> > "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > -   rm
> > "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> > +   if [ -e
> > "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
> > +   rm
> > "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> > +   fi
> > +   if [ -e
> > "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
> > +   rm
> > "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> > +   fi
> >  # Remove empty module directories to prevent QA
> issues
> >  find
> > "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type
> > d -empty -delete
> >  else
> > --
> > 2.17.1
> >
> >
> > My 2 cents: the "-f" switch makes rm ignore nonexistent files , and it
> > will make a shorter patch ;)
>
> If that is the group consensus I can submit a v2.  Anyone else feel that
> way?
>
> Don't know if a "group consensus" can exist here. (it is a public list
where anyone can raise remarks) and there is no "vote".

Mine was not a "cons" for you patch, what you did is completely valid,
I just wanted to say that there was a more concise way of doing it.

Feel free to send a v2 if you think my remark is relevant.


> >
> > 
> >
>
> --
> Ryan Eatmonreat...@ti.com
> -
> Texas Instruments, Inc.  -  LCPD  -  MGTS
>

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



Re: [OE-core] [PATCH 2/2] glib-networking: use gnutls backend for TLS sockets

2023-08-31 Thread Khem Raj

On 8/31/23 9:28 AM, Ross Burton wrote:

On 31 Aug 2023, at 17:27, Khem Raj  wrote:


On 8/31/23 3:02 AM, Ross Burton wrote:

From: Ross Burton 
As per upstream:
   There are hacks in half the tests where this backend doesn't return
   the expected error code or doesn't work as expected. I do hope to
   enable this backend by default in the future. For now, it's not there
   yet.
https://gitlab.gnome.org/GNOME/glib-networking/-/commit/8e1d80c1e0fc52d17d08a21946fa4a86ec30e1db
Signed-off-by: Ross Burton 
---
  meta/recipes-core/glib-networking/glib-networking_2.76.1.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb 
b/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
index 66b6a78a531..ed1625617e6 100644
--- a/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
+++ b/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
@@ -16,7 +16,7 @@ DEPENDS = "glib-2.0-native glib-2.0"
SRC_URI[archive.sha256sum] = 
"5c698a9994dde51efdfb1026a56698a221d6250e89dc50ebcddda7b81480a42b"
  -PACKAGECONFIG ??= "openssl environment ${@bb.utils.contains('PTEST_ENABLED', '1', 
'tests', '', d)}"
+PACKAGECONFIG ??= "gnutls environment ${@bb.utils.contains('PTEST_ENABLED', '1', 
'tests', '', d)}"



this is sad. Are we running into visible issues with OE if we use openssl TLS 
implementation.


Visible issues? No.  But the glib-networking maintainers explicitly say the 
openssl backend is not as functional and known to be buggier than the gnutls 
backend.


Yes I am not opposed to the patch per se. But trying to find more 
information on status of openssl TLS support in glib-networking.




If you want to use the openssl backend then you’re welcome to switch back, but 
I think the default should respect the will of the authors unless we have a 
good argument otherwise.

Ross


OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

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



Re: [OE-core] [PATCH 2/2] glib-networking: use gnutls backend for TLS sockets

2023-08-31 Thread Ross Burton
On 31 Aug 2023, at 17:27, Khem Raj  wrote:
> 
> On 8/31/23 3:02 AM, Ross Burton wrote:
>> From: Ross Burton 
>> As per upstream:
>>   There are hacks in half the tests where this backend doesn't return
>>   the expected error code or doesn't work as expected. I do hope to
>>   enable this backend by default in the future. For now, it's not there
>>   yet.
>> https://gitlab.gnome.org/GNOME/glib-networking/-/commit/8e1d80c1e0fc52d17d08a21946fa4a86ec30e1db
>> Signed-off-by: Ross Burton 
>> ---
>>  meta/recipes-core/glib-networking/glib-networking_2.76.1.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb 
>> b/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
>> index 66b6a78a531..ed1625617e6 100644
>> --- a/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
>> +++ b/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
>> @@ -16,7 +16,7 @@ DEPENDS = "glib-2.0-native glib-2.0"
>>SRC_URI[archive.sha256sum] = 
>> "5c698a9994dde51efdfb1026a56698a221d6250e89dc50ebcddda7b81480a42b"
>>  -PACKAGECONFIG ??= "openssl environment 
>> ${@bb.utils.contains('PTEST_ENABLED', '1', 'tests', '', d)}"
>> +PACKAGECONFIG ??= "gnutls environment ${@bb.utils.contains('PTEST_ENABLED', 
>> '1', 'tests', '', d)}"
>> 
> 
> this is sad. Are we running into visible issues with OE if we use openssl TLS 
> implementation.

Visible issues? No.  But the glib-networking maintainers explicitly say the 
openssl backend is not as functional and known to be buggier than the gnutls 
backend.

If you want to use the openssl backend then you’re welcome to switch back, but 
I think the default should respect the will of the authors unless we have a 
good argument otherwise.

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



Re: [OE-core] [PATCH 2/2] glib-networking: use gnutls backend for TLS sockets

2023-08-31 Thread Khem Raj

On 8/31/23 3:02 AM, Ross Burton wrote:

From: Ross Burton 

As per upstream:

   There are hacks in half the tests where this backend doesn't return
   the expected error code or doesn't work as expected. I do hope to
   enable this backend by default in the future. For now, it's not there
   yet.

https://gitlab.gnome.org/GNOME/glib-networking/-/commit/8e1d80c1e0fc52d17d08a21946fa4a86ec30e1db

Signed-off-by: Ross Burton 
---
  meta/recipes-core/glib-networking/glib-networking_2.76.1.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb 
b/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
index 66b6a78a531..ed1625617e6 100644
--- a/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
+++ b/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
@@ -16,7 +16,7 @@ DEPENDS = "glib-2.0-native glib-2.0"
  
  SRC_URI[archive.sha256sum] = "5c698a9994dde51efdfb1026a56698a221d6250e89dc50ebcddda7b81480a42b"
  
-PACKAGECONFIG ??= "openssl environment ${@bb.utils.contains('PTEST_ENABLED', '1', 'tests', '', d)}"

+PACKAGECONFIG ??= "gnutls environment ${@bb.utils.contains('PTEST_ENABLED', '1', 
'tests', '', d)}"



this is sad. Are we running into visible issues with OE if we use 
openssl TLS implementation.




  PACKAGECONFIG[gnutls] = "-Dgnutls=enabled,-Dgnutls=disabled,gnutls"
  PACKAGECONFIG[openssl] = "-Dopenssl=enabled,-Dopenssl=disabled,openssl"







OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186980): 
https://lists.openembedded.org/g/openembedded-core/message/186980
Mute This Topic: https://lists.openembedded.org/mt/101070628/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] createrepo-c: upgrade 0.21.1 -> 1.0.0

2023-08-31 Thread Alexandre Belloni via lists.openembedded.org
Hello,

On 31/08/2023 10:29:52+0800, wangmy wrote:
> From: Wang Mingyu 
> 
> 0001-src-cmd_parser.c-add-a-missing-parameter-name.patch
> removed since it's included in 1.0.0
> 
> Signed-off-by: Wang Mingyu 

This causes failures on the AB:

https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/8000/steps/12/logs/stdio

ERROR: core-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf. Command 
'/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0/recipe-sysroot-native/usr/bin/dnf
 -v --rpmverbosity=info -y -c 
/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0/rootfs/etc/dnf/dnf.conf
 
--setopt=reposdir=/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0/rootfs/etc/yum.repos.d
 
--installroot=/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0/rootfs
 
--setopt=logdir=/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0/temp
 
--repofrompath=oe-repo,/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0/oe-rootfs-repo
 makecache --refresh' returned 1:
DNF version: 4.16.1
cachedir: 
/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0/rootfs/var/cache/dnf
Added oe-repo repo from 
/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0/oe-rootfs-repo
Making cache files for all metadata files.
oe-repo: has expired and will be refreshed.
repo: downloading from remote: oe-repo
oe-repo 101 MB/s | 281 kB 00:00
loading repo 'oe-repo' failure: Opening repository primary data has failed: No 
such file or directory
Error: Loading repository 'oe-repo' has failed

> ---
>  ...arser.c-add-a-missing-parameter-name.patch | 39 ---
>  ...repo-c_0.21.1.bb => createrepo-c_1.0.0.bb} |  3 +-
>  2 files changed, 1 insertion(+), 41 deletions(-)
>  delete mode 100644 
> meta/recipes-devtools/createrepo-c/createrepo-c/0001-src-cmd_parser.c-add-a-missing-parameter-name.patch
>  rename meta/recipes-devtools/createrepo-c/{createrepo-c_0.21.1.bb => 
> createrepo-c_1.0.0.bb} (92%)
> 
> diff --git 
> a/meta/recipes-devtools/createrepo-c/createrepo-c/0001-src-cmd_parser.c-add-a-missing-parameter-name.patch
>  
> b/meta/recipes-devtools/createrepo-c/createrepo-c/0001-src-cmd_parser.c-add-a-missing-parameter-name.patch
> deleted file mode 100644
> index 0d1c6b08fb..00
> --- 
> a/meta/recipes-devtools/createrepo-c/createrepo-c/0001-src-cmd_parser.c-add-a-missing-parameter-name.patch
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -From 970b901e1999f415da8bac205f526c808ddad0ba Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Mon, 8 May 2023 10:40:43 +0200
> -Subject: [PATCH] src/cmd_parser.c: add a missing parameter name
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
> -
> -This resolves the following error with older versions of gcc:
> -| 
> /srv/storage/alex/yocto/build-32/tmp/work/x86_64-linux/createrepo-c-native/0.21.1-r0/git/src/cmd_parser.c:
>  In function ‘duplicated_nevra_option_parser’:
> -| 
> /srv/storage/alex/yocto/build-32/tmp/work/x86_64-linux/createrepo-c-native/0.21.1-r0/git/src/cmd_parser.c:76:32:
>  error: parameter name omitted
> -|76 | duplicated_nevra_option_parser(const gchar *,
> -|   |^
> -| 
> /srv/storage/alex/yocto/build-32/tmp/work/x86_64-linux/createrepo-c-native/0.21.1-r0/git/src/cmd_parser.c:78:32:
>  error: parameter name omitted
> -|78 |gpointer,
> -|   |^~~~
> -
> -Upstream-Status: Submitted 
> [https://github.com/rpm-software-management/createrepo_c/pull/366]
> -Signed-off-by: Alexander Kanavin 
> 
> - src/cmd_parser.c | 4 ++--
> - 1 file changed, 2 insertions(+), 2 deletions(-)
> -
> -diff --git a/src/cmd_parser.c b/src/cmd_parser.c
> -index 97c9ea7..63af7ea 100644
>  a/src/cmd_parser.c
> -+++ b/src/cmd_parser.c
> -@@ -73,9 +73,9 @@ struct CmdOptions _cmd_options = {
> - 
> - 
> - gboolean
> --duplicated_nevra_option_parser(const gchar *,
> -+duplicated_nevra_option_parser(const gchar *option_name,
> -const gchar *value,
> --   gpointer,
> -+   gpointer data,
> -GError **error)
> - {
> - if (!g_strcmp0(value, "keep"))
> diff --git a/meta/recipes-devtools/createrepo-c/createrepo-c_0.21.1.bb 
> b/meta/recipes-devtools/createrepo-c/createrepo-c_1.0.0.bb
> similarity index 92%
> rename from meta/recipes-devtools/createrepo-c/createrepo-c_0.21.1.bb
> rename to 

[OE-core] [PATCH 2/2] ppp-dialin: Fix groupname gid change warning

2023-08-31 Thread JD Schroeder
This patch fixes warnings when useradd-staticids.bbclass is used and
USERADD_PARAM is used to add the user to a group that has not been
explicitly created yet. By adding the GROUPADD_PARAM for the new group
being used the warnings for changing the gid from GID-OLD to GID-NEW
is eliminated.

Warning fixed:
ppp-dialin: Changing groupname nogroup's gid from (WXYZ) to (JKLM), verify 
configuration files!

Signed-off-by: JD Schroeder 
---
 meta/recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb 
b/meta/recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb
index 8a6c297cb0..a7b566515e 100644
--- a/meta/recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb
+++ b/meta/recipes-connectivity/ppp-dialin/ppp-dialin_0.1.bb
@@ -23,6 +23,7 @@ do_install() {
 }
 
 USERADD_PACKAGES = "${PN}"
+GROUPADD_PARAM:${PN} = "--system nogroup"
 USERADD_PARAM:${PN} = "--system --home /dev/null \
--no-create-home --shell ${sbindir}/ppp-dialin \
--no-user-group --gid nogroup ppp"
-- 
2.37.0


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



[OE-core] [PATCH 1/2] distcc: Fix groupname gid change warning

2023-08-31 Thread JD Schroeder
This patch fixes warnings when useradd-staticids.bbclass is used and
USERADD_PARAM is used to add the user to a group that has not been
explicitly created yet. By adding the GROUPADD_PARAM for the new group
being used the warnings for changing the gid from GID-OLD to GID-NEW
is eliminated.

Warning fixed:
distcc: Changing groupname nogroup's gid from (WXYZ) to (JKLM), verify 
configuration files!

Signed-off-by: JD Schroeder 
---
 meta/recipes-devtools/distcc/distcc_3.4.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/distcc/distcc_3.4.bb 
b/meta/recipes-devtools/distcc/distcc_3.4.bb
index 45fc7cde53..0c20f74d68 100644
--- a/meta/recipes-devtools/distcc/distcc_3.4.bb
+++ b/meta/recipes-devtools/distcc/distcc_3.4.bb
@@ -33,6 +33,7 @@ EXTRA_OECONF += "--disable-Werror PYTHON='' 
--disable-pump-mode"
 PACKAGE_BEFORE_PN = "${PN}-distmon-gnome ${PN}-server"
 
 USERADD_PACKAGES = "${PN}-server"
+GROUPADD_PARAM:${PN}-server = "--system nogroup"
 USERADD_PARAM:${PN}-server = "--system \
--home /dev/null \
--no-create-home \
-- 
2.37.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186977): 
https://lists.openembedded.org/g/openembedded-core/message/186977
Mute This Topic: https://lists.openembedded.org/mt/101074670/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] kernel.bbclass: Add file exist checks around removes

2023-08-31 Thread Ryan Eatmon via lists.openembedded.org



On 8/31/2023 8:47 AM, Frédéric Martinsons wrote:

Hello,

On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via lists.openembedded.org 
 > wrote:


The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it.  Simple fix is to add an
exists check around the call.

Signed-off-by: Ryan Eatmon mailto:reat...@ti.com>>
---
  meta/classes-recipe/kernel.bbclass | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/kernel.bbclass
b/meta/classes-recipe/kernel.bbclass
index acb43bd4d5..4df052061b 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -454,8 +454,12 @@ kernel_do_install() {
         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
         if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
                 oe_runmake DEPMOD=echo
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
-               rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
-               rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+               if [ -e
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
+                       rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
+               fi
+               if [ -e
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
+                       rm
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+               fi
                 # Remove empty module directories to prevent QA issues
                 find
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type
d -empty -delete
         else
-- 
2.17.1



My 2 cents: the "-f" switch makes rm ignore nonexistent files , and it 
will make a shorter patch ;)


If that is the group consensus I can submit a v2.  Anyone else feel that 
way?









--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc.  -  LCPD  -  MGTS

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186976): 
https://lists.openembedded.org/g/openembedded-core/message/186976
Mute This Topic: https://lists.openembedded.org/mt/101073782/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] kernel.bbclass: Add file exist checks around removes

2023-08-31 Thread Frederic Martinsons
Hello,

On Thu, 31 Aug 2023 at 15:38, Ryan Eatmon via lists.openembedded.org
 wrote:

> The latest 6.5 kernels do not appear to create the source file in
> ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
> recipe errors out when trying to remove it.  Simple fix is to add an
> exists check around the call.
>
> Signed-off-by: Ryan Eatmon 
> ---
>  meta/classes-recipe/kernel.bbclass | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> index acb43bd4d5..4df052061b 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -454,8 +454,12 @@ kernel_do_install() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
> if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
> oe_runmake DEPMOD=echo
> MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}
> INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
> -   rm
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> -   rm
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> +   if [ -e
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
> +   rm
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
> +   fi
> +   if [ -e
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
> +   rm
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
> +   fi
> # Remove empty module directories to prevent QA issues
> find
> "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d
> -empty -delete
> else
> --
> 2.17.1
>
>
My 2 cents: the "-f" switch makes rm ignore nonexistent files , and it will
make a shorter patch ;)

>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186975): 
https://lists.openembedded.org/g/openembedded-core/message/186975
Mute This Topic: https://lists.openembedded.org/mt/101073782/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] kernel.bbclass: Add file exist checks around removes

2023-08-31 Thread Ryan Eatmon via lists.openembedded.org
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it.  Simple fix is to add an
exists check around the call.

Signed-off-by: Ryan Eatmon 
---
 meta/classes-recipe/kernel.bbclass | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/kernel.bbclass 
b/meta/classes-recipe/kernel.bbclass
index acb43bd4d5..4df052061b 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -454,8 +454,12 @@ kernel_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
oe_runmake DEPMOD=echo 
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION} 
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
-   rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
-   rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+   if [ -e 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build" ]; then
+   rm 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
+   fi
+   if [ -e 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source" ]; then
+   rm 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+   fi
# Remove empty module directories to prevent QA issues
find 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel" -type d -empty 
-delete
else
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186974): 
https://lists.openembedded.org/g/openembedded-core/message/186974
Mute This Topic: https://lists.openembedded.org/mt/101073782/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 v2 1/3] inetutils: don't guess target paths

2023-08-31 Thread Ross Burton
On 31 Aug 2023, at 08:22, Alexandre Belloni  
wrote:
> 
> Hello Ross,
> 
> I think this causes failures with musl:
> ERROR: inetutils-2.4-r0 do_configure: Default path values used, these must be 
> set explicitly
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/7684/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/7706/steps/12/logs/stdio

Yes, thanks, v2 sent.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186973): 
https://lists.openembedded.org/g/openembedded-core/message/186973
Mute This Topic: https://lists.openembedded.org/mt/101049210/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 2/3] inetutils: remove obsolete patches

2023-08-31 Thread Ross Burton
From: Ross Burton 

fix-disable-ipv6.patch: we don't support uclibc, and most libcs don't
have optional support for IPv6.

inetutils-1.8-0001-printf-parse-pull-in-features.h-for-__GLIBC__.patch and
inetutils-1.8-0003-wchar.patch: these don't appear to be needed anymore.

inetutils-only-check-pam_appl.h-when-pam-enabled.patch: configure.ac
doesn't fail if PAM is disabled anymore.

Signed-off-by: Ross Burton 
---
 .../inetutils/fix-disable-ipv6.patch  | 85 ---
 ...rse-pull-in-features.h-for-__GLIBC__.patch | 27 --
 .../inetutils/inetutils-1.8-0003-wchar.patch  | 25 --
 ...ly-check-pam_appl.h-when-pam-enabled.patch | 49 ---
 .../inetutils/inetutils_2.4.bb|  4 -
 5 files changed, 190 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/inetutils/inetutils/fix-disable-ipv6.patch
 delete mode 100644 
meta/recipes-connectivity/inetutils/inetutils/inetutils-1.8-0001-printf-parse-pull-in-features.h-for-__GLIBC__.patch
 delete mode 100644 
meta/recipes-connectivity/inetutils/inetutils/inetutils-1.8-0003-wchar.patch
 delete mode 100644 
meta/recipes-connectivity/inetutils/inetutils/inetutils-only-check-pam_appl.h-when-pam-enabled.patch

diff --git 
a/meta/recipes-connectivity/inetutils/inetutils/fix-disable-ipv6.patch 
b/meta/recipes-connectivity/inetutils/inetutils/fix-disable-ipv6.patch
deleted file mode 100644
index 603d2baf9d2..000
--- a/meta/recipes-connectivity/inetutils/inetutils/fix-disable-ipv6.patch
+++ /dev/null
@@ -1,85 +0,0 @@
-From c7c27ba763c613f83c1561e56448b49315c271c5 Mon Sep 17 00:00:00 2001
-From: Jackie Huang 
-Date: Wed, 6 Mar 2019 09:36:11 -0500
-Subject: [PATCH] Upstream:
- http://www.mail-archive.com/bug-inetutils@gnu.org/msg02103.html
-
-Upstream-Status: Pending
-
-Signed-off-by: Jackie Huang 
-

- ping/ping_common.h | 20 
- 1 file changed, 20 insertions(+)
-
-diff --git a/ping/ping_common.h b/ping/ping_common.h
-index 65e3e60..3e84db0 100644
 a/ping/ping_common.h
-+++ b/ping/ping_common.h
-@@ -18,10 +18,14 @@
-   You should have received a copy of the GNU General Public License
-   along with this program.  If not, see `http://www.gnu.org/licenses/'. */
- 
-+#include 
-+
- #include 
- #include 
- #include 
-+#ifdef HAVE_IPV6
- #include 
-+#endif
- #include 
- #include 
- #include 
-@@ -63,7 +67,12 @@ struct ping_stat
-want to follow the traditional behaviour of ping.  */
- #define DEFAULT_PING_COUNT 0
- 
-+#ifdef HAVE_IPV6
- #define PING_HEADER_LEN (USE_IPV6 ? sizeof (struct icmp6_hdr) : ICMP_MINLEN)
-+#else
-+#define PING_HEADER_LEN (ICMP_MINLEN)
-+#endif
-+
- #define PING_TIMING(s)  ((s) >= sizeof (struct timeval))
- #define PING_DATALEN(64 - PING_HEADER_LEN)  /* default data length */
- 
-@@ -78,13 +87,20 @@ struct ping_stat
- 
- #define PING_MIN_USER_INTERVAL (20/PING_PRECISION)
- 
-+#ifdef HAVE_IPV6
- /* FIXME: Adjust IPv6 case for options and their consumption.  */
- #define _PING_BUFLEN(p, u) ((u)? ((p)->ping_datalen + sizeof (struct 
icmp6_hdr)) : \
-  (MAXIPLEN + (p)->ping_datalen + ICMP_TSLEN))
- 
-+#else
-+#define _PING_BUFLEN(p, u) (MAXIPLEN + (p)->ping_datalen + ICMP_TSLEN)
-+#endif
-+
-+#ifdef HAVE_IPV6
- typedef int (*ping_efp6) (int code, void *closure, struct sockaddr_in6 * dest,
- struct sockaddr_in6 * from, struct icmp6_hdr * icmp,
- int datalen);
-+#endif
- 
- typedef int (*ping_efp) (int code,
-void *closure,
-@@ -93,13 +109,17 @@ typedef int (*ping_efp) (int code,
-struct ip * ip, icmphdr_t * icmp, int datalen);
- 
- union event {
-+#ifdef HAVE_IPV6
-   ping_efp6 handler6;
-+#endif
-   ping_efp handler;
- };
- 
- union ping_address {
-   struct sockaddr_in ping_sockaddr;
-+#ifdef HAVE_IPV6
-   struct sockaddr_in6 ping_sockaddr6;
-+#endif
- };
- 
- typedef struct ping_data PING;
diff --git 
a/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.8-0001-printf-parse-pull-in-features.h-for-__GLIBC__.patch
 
b/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.8-0001-printf-parse-pull-in-features.h-for-__GLIBC__.patch
deleted file mode 100644
index 2974bd4f94d..000
--- 
a/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.8-0001-printf-parse-pull-in-features.h-for-__GLIBC__.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From f7f785c21306010b2367572250b2822df5bc7728 Mon Sep 17 00:00:00 2001
-From: Mike Frysinger 
-Date: Thu, 18 Nov 2010 16:59:14 -0500
-Subject: [PATCH] printf-parse: pull in features.h for __GLIBC__
-
-Upstream-Status: Pending
-
-Signed-off-by: Mike Frysinger 
-

- lib/printf-parse.h | 3 +++
- 1 file changed, 3 insertions(+)
-
-diff --git a/lib/printf-parse.h b/lib/printf-parse.h
-index e7d0f82..d7b4534 100644
 a/lib/printf-parse.h
-+++ b/lib/printf-parse.h
-@@ -28,6 +28,9 @@
- 
- #include "printf-args.h"
- 
-+#ifdef HAVE_FEATURES_H
-+# include /* for __GLIBC__ */
-+#endif
- 
- /* Flags */

[OE-core] [PATCH v2 3/3] inetutils: remove obsolete cruft from do_configure

2023-08-31 Thread Ross Burton
From: Ross Burton 

glob/ doesn't exist and the other files are copied by autotools.bbclass

Signed-off-by: Ross Burton 
---
 meta/recipes-connectivity/inetutils/inetutils_2.4.bb | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/recipes-connectivity/inetutils/inetutils_2.4.bb 
b/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
index a84fed1fbb8..957f1feac60 100644
--- a/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
+++ b/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
@@ -64,10 +64,6 @@ ERROR_QA:remove = "unknown-configure-option"
 
 do_configure:prepend () {
 export HELP2MAN='true'
-cp ${STAGING_DATADIR_NATIVE}/gettext/config.rpath 
${S}/build-aux/config.rpath
-install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S}
-install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S}
-rm -f ${S}/glob/configure*
 }
 
 do_install:append () {
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186972): 
https://lists.openembedded.org/g/openembedded-core/message/186972
Mute This Topic: https://lists.openembedded.org/mt/101071434/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 1/3] inetutils: don't guess target paths

2023-08-31 Thread Ross Burton
From: Ross Burton 

inetutils guesses a lot of target paths in cross builds, and warns that
some of them are known to be wrong (for example, whether /proc/net/dev
exists is guessed as 'no').

Add a post-configure function to check for these warnings, and pass
--with-path-* as appropriate to set the paths explicitly.

This means we can remove the patch which was setting PATH_PROCNET_DEV,
and the autoconf cache value inetutils_cv_path_login.

The downside is that these --with-path-* options are not real autoconf
options, so the "unknown options" warning is emitted.  Losing those is
an acceptable compromise, so disable it.

Musl doesn't implement utmp and has stub defines for _PATH_UTMP but not
_PATH_UTMPX, so we need to set the X variants explicitly.

Signed-off-by: Ross Burton 
---
 .../inetutils-1.9-PATH_PROCNET_DEV.patch  | 37 ---
 .../inetutils/inetutils_2.4.bb| 21 +--
 2 files changed, 18 insertions(+), 40 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/inetutils/inetutils/inetutils-1.9-PATH_PROCNET_DEV.patch

diff --git 
a/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.9-PATH_PROCNET_DEV.patch
 
b/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.9-PATH_PROCNET_DEV.patch
deleted file mode 100644
index 460ddf98300..000
--- 
a/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.9-PATH_PROCNET_DEV.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-From 101130f422dd5c01a1459645d7b2a5b8d19720ab Mon Sep 17 00:00:00 2001
-From: Martin Jansa 
-Date: Wed, 6 Mar 2019 09:36:11 -0500
-Subject: [PATCH] inetutils: define PATH_PROCNET_DEV if not already defined
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-this prevents the following compilation error :
-system/linux.c:401:15: error: 'PATH_PROCNET_DEV' undeclared (first use in this 
function)
-
-this patch comes from :
- http://repository.timesys.com/buildsources/i/inetutils/inetutils-1.9/
-
-Upstream-Status: Inappropriate [not author]
-
-Signed-of-by: Eric Bénard 
-

- ifconfig/system/linux.c | 4 
- 1 file changed, 4 insertions(+)
-
-diff --git a/ifconfig/system/linux.c b/ifconfig/system/linux.c
-index e453b46..4268ca9 100644
 a/ifconfig/system/linux.c
-+++ b/ifconfig/system/linux.c
-@@ -53,6 +53,10 @@
- #include "../ifconfig.h"
- 
- 
-+#ifndef PATH_PROCNET_DEV
-+  #define PATH_PROCNET_DEV "/proc/net/dev"
-+#endif
-+
- /* ARPHRD stuff.  */
- 
- static void
diff --git a/meta/recipes-connectivity/inetutils/inetutils_2.4.bb 
b/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
index 85e9f642b30..d3f9e9e5fa4 100644
--- a/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
+++ b/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
@@ -20,7 +20,6 @@ SRC_URI = "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.xz \
file://rsh.xinetd.inetutils \
file://telnet.xinetd.inetutils \
file://tftpd.xinetd.inetutils \
-   file://inetutils-1.9-PATH_PROCNET_DEV.patch \
file://inetutils-only-check-pam_appl.h-when-pam-enabled.patch \

file://0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch \
file://0002-CVE-2023-40303-Indent-changes-in-previous-commit.patch \
@@ -42,15 +41,31 @@ PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6 
gl_cv_socket_ipv6=no,"
 PACKAGECONFIG[ping6] = "--enable-ping6,--disable-ping6,"
 
 EXTRA_OECONF = "--with-ncurses-include-dir=${STAGING_INCDIR} \
-inetutils_cv_path_login=${base_bindir}/login \
 --with-libreadline-prefix=${STAGING_LIBDIR} \
 --enable-rpath=no \
-"
+--with-path-login=${base_bindir}/login \
+--with-path-cp=${base_bindir}/cp \
+--with-path-uucico=${libexecdir}/uuico \
+--with-path-procnet-dev=/proc/net/dev \
+"
+
+EXTRA_OECONF:append:libc-musl = " --with-path-utmpx=/dev/null/utmpx 
--with-path-wtmpx=/dev/null/wtmpx"
 
 # These are horrible for security, disable them
 EXTRA_OECONF:append = " --disable-rsh --disable-rshd --disable-rcp \
 --disable-rlogin --disable-rlogind --disable-rexec --disable-rexecd"
 
+# The configure script guesses many paths in cross builds, check for this 
happening
+do_configure_cross_check() {
+if grep "may be incorrect because of cross-compilation" ${B}/config.log; 
then
+bberror Default path values used, these must be set explicitly
+fi
+}
+do_configure[postfuncs] += "do_configure_cross_check"
+
+# The --with-path options are not actually options, so this check needs to be 
silenced
+ERROR_QA:remove = "unknown-configure-option"
+
 do_configure:prepend () {
 export HELP2MAN='true'
 cp ${STAGING_DATADIR_NATIVE}/gettext/config.rpath 
${S}/build-aux/config.rpath
-- 
2.34.1


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

Re: [OE-core] [PATCH] insane.bbclass: introduce SIGILL finder

2023-08-31 Thread Benjamin Bara
Hi Alex,

thanks for the feedback!

On Thu, 31 Aug 2023 at 11:24, Alexander Kanavin  wrote:
> objdump -d is a heavy operation, and the problem is both arm-specific
> and rare. Also SIGILL is a very clear indicator of what the problem
> is, even if it's annoying to see it at runtime.

As the grep is part of the call, at least the processing is quite fast. It
could also be extended to other architectures which might not support the
latest and greatest SIMD extensions.

> I don't think this should happen across all builds and components.

It will just be executed if the "filters" apply to your machine, currently:
- "vfpv3d16" in features
- "armv7a" in features and "neon" not in features

But I understand that this probably doesn't make sense for a "everyday build".

Regards,
Benjamin

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



[OE-core] [PATCH 1/2] glib-networking: enable build with GnuTLS if PKCS#11 was disabled

2023-08-31 Thread Ross Burton
From: Ross Burton 

If GnuTLS is built without PKCS#11 support then glib-networking will
fail to build the tests. Backport a patch to fix this issue.

Signed-off-by: Ross Burton 
---
 ...sable-PKCS-11-tests-if-not-available.patch | 113 ++
 .../glib-networking/glib-networking_2.76.1.bb |   1 +
 2 files changed, 114 insertions(+)
 create mode 100644 
meta/recipes-core/glib-networking/glib-networking/0001-tls-tests-disable-PKCS-11-tests-if-not-available.patch

diff --git 
a/meta/recipes-core/glib-networking/glib-networking/0001-tls-tests-disable-PKCS-11-tests-if-not-available.patch
 
b/meta/recipes-core/glib-networking/glib-networking/0001-tls-tests-disable-PKCS-11-tests-if-not-available.patch
new file mode 100644
index 000..7b003588c88
--- /dev/null
+++ 
b/meta/recipes-core/glib-networking/glib-networking/0001-tls-tests-disable-PKCS-11-tests-if-not-available.patch
@@ -0,0 +1,113 @@
+From 04728a5b73e870b4695c5e7ba42fa41c00471944 Mon Sep 17 00:00:00 2001
+From: Ross Burton 
+Date: Fri, 12 May 2023 20:19:35 +0100
+Subject: [PATCH] tls/tests: disable PKCS#11 tests if not available
+
+GnuTLS can be built without PKCS#11, which means the symbols
+gnutls_pkcs11_init and gnutls_pkcs11_add_provider are not part of the
+library.
+
+If these symbols don't exist in GnuTLS then we can't add a mock pkcs#11
+provider for testing, and several tests which need the mock provider
+will fail.
+
+Solve this by checking for the symbols at build time and disabling the
+provider and tests which need it.
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+---
+ meson.build |  4 
+ tls/tests/certificate.c | 11 +++
+ tls/tests/connection.c  |  4 +++-
+ 3 files changed, 14 insertions(+), 5 deletions(-)
+
+diff --git a/meson.build b/meson.build
+index 0fa9027..d2a023a 100644
+--- a/meson.build
 b/meson.build
+@@ -84,6 +84,10 @@ gnutls_dep = dependency('gnutls', version: '>= 3.7.4', 
required: get_option('gnu
+ 
+ if gnutls_dep.found()
+   backends += ['gnutls']
++  # test-specific, maybe move to tls/tests
++  if cc.has_function('gnutls_pkcs11_init', prefix: '#include 
', dependencies: gnutls_dep)
++config_h.set10('HAVE_GNUTLS_PKCS11', true)
++  endif
+ endif
+ 
+ # *** Checks for OpenSSL***
+diff --git a/tls/tests/certificate.c b/tls/tests/certificate.c
+index e820ba1..dd2412b 100644
+--- a/tls/tests/certificate.c
 b/tls/tests/certificate.c
+@@ -24,6 +24,7 @@
+  * Author: Stef Walter 
+  */
+ 
++#include "config.h"
+ #include "certificate.h"
+ 
+ #include 
+@@ -911,7 +912,7 @@ int
+ main (int   argc,
+   char *argv[])
+ {
+-#ifdef BACKEND_IS_GNUTLS
++#if defined(BACKEND_IS_GNUTLS) && HAVE_GNUTLS_PKCS11
+   char *module_path;
+ #endif
+ 
+@@ -921,7 +922,7 @@ main (int   argc,
+   g_setenv ("GIO_USE_TLS", BACKEND, TRUE);
+   g_assert_cmpint (g_ascii_strcasecmp (G_OBJECT_TYPE_NAME 
(g_tls_backend_get_default ()), "GTlsBackend" BACKEND), ==, 0);
+ 
+-#ifdef BACKEND_IS_GNUTLS
++#if defined(BACKEND_IS_GNUTLS) && HAVE_GNUTLS_PKCS11
+   module_path = g_test_build_filename (G_TEST_BUILT, "mock-pkcs11.so", NULL);
+   g_assert_true (g_file_test (module_path, G_FILE_TEST_EXISTS));
+ 
+@@ -942,12 +943,14 @@ main (int   argc,
+   setup_certificate, test_create_certificate_with_issuer, 
teardown_certificate);
+   g_test_add ("/tls/" BACKEND "/certificate/create-with-garbage-input", 
TestCertificate, NULL,
+   setup_certificate, test_create_certificate_with_garbage_input, 
teardown_certificate);
+-  g_test_add ("/tls/" BACKEND "/certificate/pkcs11", TestCertificate, NULL,
+-  setup_certificate, test_create_certificate_pkcs11, 
teardown_certificate);
+   g_test_add ("/tls/" BACKEND "/certificate/private-key", TestCertificate, 
NULL,
+   setup_certificate, test_private_key, teardown_certificate);
++#if HAVE_GNUTLS_PKCS11
++  g_test_add ("/tls/" BACKEND "/certificate/pkcs11", TestCertificate, NULL,
++  setup_certificate, test_create_certificate_pkcs11, 
teardown_certificate);
+   g_test_add ("/tls/" BACKEND "/certificate/private-key-pkcs11", 
TestCertificate, NULL,
+   setup_certificate, test_private_key_pkcs11, 
teardown_certificate);
++#endif
+ 
+   g_test_add_func ("/tls/" BACKEND "/certificate/create-chain", 
test_create_certificate_chain);
+   g_test_add_func ("/tls/" BACKEND "/certificate/create-no-chain", 
test_create_certificate_no_chain);
+diff --git a/tls/tests/connection.c b/tls/tests/connection.c
+index 17efe1b..62a7fbb 100644
+--- a/tls/tests/connection.c
 b/tls/tests/connection.c
+@@ -3376,7 +3376,7 @@ main (int   argc,
+ 
+   g_assert_true (g_ascii_strcasecmp (G_OBJECT_TYPE_NAME 
(g_tls_backend_get_default ()), "GTlsBackend" BACKEND) == 0);
+ 
+-#ifdef BACKEND_IS_GNUTLS
++#if defined(BACKEND_IS_GNUTLS) && HAVE_GNUTLS_PKCS11
+   module_path = g_test_build_filename (G_TEST_BUILT, "mock-pkcs11.so", NULL);
+   g_assert_true (g_file_test (module_path, G_FILE_TEST_EXISTS));
+ 
+@@ -3438,8 +3438,10 

[OE-core] [PATCH 2/2] glib-networking: use gnutls backend for TLS sockets

2023-08-31 Thread Ross Burton
From: Ross Burton 

As per upstream:

  There are hacks in half the tests where this backend doesn't return
  the expected error code or doesn't work as expected. I do hope to
  enable this backend by default in the future. For now, it's not there
  yet.

https://gitlab.gnome.org/GNOME/glib-networking/-/commit/8e1d80c1e0fc52d17d08a21946fa4a86ec30e1db

Signed-off-by: Ross Burton 
---
 meta/recipes-core/glib-networking/glib-networking_2.76.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb 
b/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
index 66b6a78a531..ed1625617e6 100644
--- a/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
+++ b/meta/recipes-core/glib-networking/glib-networking_2.76.1.bb
@@ -16,7 +16,7 @@ DEPENDS = "glib-2.0-native glib-2.0"
 
 SRC_URI[archive.sha256sum] = 
"5c698a9994dde51efdfb1026a56698a221d6250e89dc50ebcddda7b81480a42b"
 
-PACKAGECONFIG ??= "openssl environment ${@bb.utils.contains('PTEST_ENABLED', 
'1', 'tests', '', d)}"
+PACKAGECONFIG ??= "gnutls environment ${@bb.utils.contains('PTEST_ENABLED', 
'1', 'tests', '', d)}"
 
 PACKAGECONFIG[gnutls] = "-Dgnutls=enabled,-Dgnutls=disabled,gnutls"
 PACKAGECONFIG[openssl] = "-Dopenssl=enabled,-Dopenssl=disabled,openssl"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186968): 
https://lists.openembedded.org/g/openembedded-core/message/186968
Mute This Topic: https://lists.openembedded.org/mt/101070628/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] insane.bbclass: introduce SIGILL finder

2023-08-31 Thread Alexander Kanavin
objdump -d is a heavy operation, and the problem is both arm-specific
and rare. Also SIGILL is a very clear indicator of what the problem
is, even if it's annoying to see it at runtime.

I don't think this should happen across all builds and components.

Alex

On Thu, 31 Aug 2023 at 11:16, Benjamin Bara  wrote:
>
> From: Benjamin Bara 
>
> This commit should look for unsupported instructions depending on the
> active tune features. For now, it checks for vfpv3d16 and other non-neon
> machines, but it can be easily extended for other architectures/checks.
>
> Reason for this check is that a couple of packages assume neon support
> for armv7, but it is actually optional.
>
> Signed-off-by: Benjamin Bara 
> ---
> Hi,
>
> as I lately played a little bit around with a vfpv3d16 machine and some
> multimedia packages, I stumbled across a couple of illegal instructions
> during runtime. Therefore I decided to hack a QA job which should find
> these during package time. Not sure if this is the correct location to
> do such a check and if this is something needed at all...
>
> Regards,
> Benjamin
> ---
>  meta/classes-global/insane.bbclass | 78 +-
>  meta/lib/oe/qa.py  | 34 +
>  2 files changed, 111 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes-global/insane.bbclass 
> b/meta/classes-global/insane.bbclass
> index 2e53778934..5b9112d05c 100644
> --- a/meta/classes-global/insane.bbclass
> +++ b/meta/classes-global/insane.bbclass
> @@ -44,7 +44,7 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch 
> pkgconfig la \
>  configure-gettext perllocalpod shebang-size \
>  already-stripped installed-vs-shipped ldflags compile-host-path \
>  install-host-path pn-overrides unknown-configure-option \
> -useless-rpaths rpaths staticdev empty-dirs \
> +useless-rpaths rpaths staticdev empty-dirs sigill \
>  patch-fuzz \
>  "
>  # Add usrmerge QA check based on distro feature
> @@ -635,6 +635,82 @@ def check_32bit_symbols(path, packagename, d, elf, 
> messages):
>  'Suppress with INSANE_SKIP = "32bit-time"'
>  )
>
> +QAPATHTEST[sigill] = "package_qa_check_sigill"
> +def package_qa_check_sigill(path, name, d, elf, messages):
> +"""
> +Check that the package doesn't contain unsupported instructions.
> +"""
> +import re
> +
> +if not elf:
> +return
> +
> +if os.path.islink(path):
> +return
> +
> +def test_skeleton(grep, test):
> +dump = elf.run_filtered_objdump_unstripped("-d", grep, d, name)
> +if dump == 'stripped':
> +# stripped binaries might give false positives
> +return
> +
> +# get all instructions and registers from the disassembled binary
> +instr_list = []
> +regs_list = []
> +for line in dump.split("\\n"):
> +splitted = dump.split("\\t")
> +if len(splitted) < 3:
> +continue
> +# 0 is just empty, as line starts with \t
> +instr_list.append(splitted[1])
> +regs_list.append(splitted[2])
> +
> +# loop through instr+regs list and apply the given test function
> +uniques = set()
> +for index, regs in enumerate(regs_list):
> +instr = instr_list[index]
> +affected = test(instr, regs)
> +if affected:
> +uniques.add(f"{instr} {regs}")
> +
> +for instr_regs in uniques:
> +oe.qa.add_message(messages, "sigill", "%s contains %s" % (path, 
> instr_regs))
> +
> +features = d.getVar('TUNE_FEATURES')
> +if "vfpv3d16" in features:
> +# grep for d16-d31, d0-d15 are valid for f64 instructions
> +vfpv3d16_grep = "f64\s+(d1|d2|d3)"
> +
> +def vfpv3d16_test(instr, regs):
> +for reg in re.findall(r'd(\d+)', regs):
> +return int(reg) >= 16
> +
> +test_skeleton(vfpv3d16_grep, vfpv3d16_test)
> +
> +if "armv7a" in features and "neon" not in features:
> +# 
> https://developer.arm.com/documentation/den0018/a/NEON-and-VFP-Instruction-Summary/List-of-all-NEON-and-VFP-instructions
> +neon_instrs = ["vq?r?shl", "vq?abs", "vq?add", "vq?movn", "vq?sub",
> +   "vr?addhn", "vr?hadd", "vr?shrn?", "vr?sra", 
> "vr?subhn",
> +   "vabal?", "vabdl?", "vacge", "vacgt", "vacle", 
> "vaclt",
> +   "vaddl", "vaddw", "vand", "vbic", "vbif", "vbit", 
> "vceq",
> +   "vcge", "vcgt", "vcle", "vcls", "vclt", "vclz", 
> "vcnt",
> +   "vdup", "veor", "vext", "vhsub", "vmax", "vmin", 
> "vmlal",
> +   "vmlsl", "vmov2", "vmovl", "vmull", "vmvn", "vqneg",
> +   "vorn", "vorr", "vpadal", "vpaddl?", "vpmax", "vpmin",
> +   "vqr?dmulh", "vqr?shru?n", "vqdmlal", 

[OE-core] [PATCH] insane.bbclass: introduce SIGILL finder

2023-08-31 Thread Benjamin Bara
From: Benjamin Bara 

This commit should look for unsupported instructions depending on the
active tune features. For now, it checks for vfpv3d16 and other non-neon
machines, but it can be easily extended for other architectures/checks.

Reason for this check is that a couple of packages assume neon support
for armv7, but it is actually optional.

Signed-off-by: Benjamin Bara 
---
Hi,

as I lately played a little bit around with a vfpv3d16 machine and some
multimedia packages, I stumbled across a couple of illegal instructions
during runtime. Therefore I decided to hack a QA job which should find
these during package time. Not sure if this is the correct location to
do such a check and if this is something needed at all...

Regards,
Benjamin
---
 meta/classes-global/insane.bbclass | 78 +-
 meta/lib/oe/qa.py  | 34 +
 2 files changed, 111 insertions(+), 1 deletion(-)

diff --git a/meta/classes-global/insane.bbclass 
b/meta/classes-global/insane.bbclass
index 2e53778934..5b9112d05c 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -44,7 +44,7 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch 
pkgconfig la \
 configure-gettext perllocalpod shebang-size \
 already-stripped installed-vs-shipped ldflags compile-host-path \
 install-host-path pn-overrides unknown-configure-option \
-useless-rpaths rpaths staticdev empty-dirs \
+useless-rpaths rpaths staticdev empty-dirs sigill \
 patch-fuzz \
 "
 # Add usrmerge QA check based on distro feature
@@ -635,6 +635,82 @@ def check_32bit_symbols(path, packagename, d, elf, 
messages):
 'Suppress with INSANE_SKIP = "32bit-time"'
 )
 
+QAPATHTEST[sigill] = "package_qa_check_sigill"
+def package_qa_check_sigill(path, name, d, elf, messages):
+"""
+Check that the package doesn't contain unsupported instructions.
+"""
+import re
+
+if not elf:
+return
+
+if os.path.islink(path):
+return
+
+def test_skeleton(grep, test):
+dump = elf.run_filtered_objdump_unstripped("-d", grep, d, name)
+if dump == 'stripped':
+# stripped binaries might give false positives
+return
+
+# get all instructions and registers from the disassembled binary
+instr_list = []
+regs_list = []
+for line in dump.split("\\n"):
+splitted = dump.split("\\t")
+if len(splitted) < 3:
+continue
+# 0 is just empty, as line starts with \t
+instr_list.append(splitted[1])
+regs_list.append(splitted[2])
+
+# loop through instr+regs list and apply the given test function
+uniques = set()
+for index, regs in enumerate(regs_list):
+instr = instr_list[index]
+affected = test(instr, regs)
+if affected:
+uniques.add(f"{instr} {regs}")
+
+for instr_regs in uniques:
+oe.qa.add_message(messages, "sigill", "%s contains %s" % (path, 
instr_regs))
+
+features = d.getVar('TUNE_FEATURES')
+if "vfpv3d16" in features:
+# grep for d16-d31, d0-d15 are valid for f64 instructions
+vfpv3d16_grep = "f64\s+(d1|d2|d3)"
+
+def vfpv3d16_test(instr, regs):
+for reg in re.findall(r'd(\d+)', regs):
+return int(reg) >= 16
+
+test_skeleton(vfpv3d16_grep, vfpv3d16_test)
+
+if "armv7a" in features and "neon" not in features:
+# 
https://developer.arm.com/documentation/den0018/a/NEON-and-VFP-Instruction-Summary/List-of-all-NEON-and-VFP-instructions
+neon_instrs = ["vq?r?shl", "vq?abs", "vq?add", "vq?movn", "vq?sub",
+   "vr?addhn", "vr?hadd", "vr?shrn?", "vr?sra", "vr?subhn",
+   "vabal?", "vabdl?", "vacge", "vacgt", "vacle", "vaclt",
+   "vaddl", "vaddw", "vand", "vbic", "vbif", "vbit", 
"vceq",
+   "vcge", "vcgt", "vcle", "vcls", "vclt", "vclz", "vcnt",
+   "vdup", "veor", "vext", "vhsub", "vmax", "vmin", 
"vmlal",
+   "vmlsl", "vmov2", "vmovl", "vmull", "vmvn", "vqneg",
+   "vorn", "vorr", "vpadal", "vpaddl?", "vpmax", "vpmin",
+   "vqr?dmulh", "vqr?shru?n", "vqdmlal", "vqdmlsl",
+   "vqdmull", "vqmovun", "vqshl", "vqshlu", "vcrecpe",
+   "vcrecps", "vrev", "vrsqrte", "vrsqrts", "vshl", 
"vshll",
+   "vsli", "vsri", "vsubl", "vsubw", "vswp", "vtbl", 
"vtbx",
+   "vtrn", "vtst", "vuzp", "vzip"]
+# most of them are only NEON when the used data type isn't 
floating-point
+neon_grep = "\s(" + "|".join(neon_instrs) + ")\.(s|u|p)"
+
+def neon_test(instr, regs):
+# if something is found by the 

[OE-core][dunfell][PATCH] go: Backport fix for CVE-2023-29409

2023-08-31 Thread Vijay Anusuri via lists.openembedded.org
From: Vijay Anusuri 

Upstream-commit: 
https://github.com/golang/go/commit/2300f7ef07718f6be4d8aa8486c7de99836e233f

Signed-off-by: Vijay Anusuri 
---
 meta/recipes-devtools/go/go-1.14.inc  |   1 +
 .../go/go-1.14/CVE-2023-29409.patch   | 175 ++
 2 files changed, 176 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2023-29409.patch

diff --git a/meta/recipes-devtools/go/go-1.14.inc 
b/meta/recipes-devtools/go/go-1.14.inc
index b2cf805d2d..20377e095b 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -69,6 +69,7 @@ SRC_URI += "\
 file://CVE-2023-29404.patch \
 file://CVE-2023-29400.patch \
 file://CVE-2023-29406.patch \
+file://CVE-2023-29409.patch \
 "
 
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2023-29409.patch 
b/meta/recipes-devtools/go/go-1.14/CVE-2023-29409.patch
new file mode 100644
index 00..00685cc180
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2023-29409.patch
@@ -0,0 +1,175 @@
+From 2300f7ef07718f6be4d8aa8486c7de99836e233f Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker 
+Date: Wed, 7 Jun 2023 15:27:13 -0700
+Subject: [PATCH] [release-branch.go1.19] crypto/tls: restrict RSA keys in
+ certificates to <= 8192 bits
+
+Extremely large RSA keys in certificate chains can cause a client/server
+to expend significant CPU time verifying signatures. Limit this by
+restricting the size of RSA keys transmitted during handshakes to <=
+8192 bits.
+
+Based on a survey of publicly trusted RSA keys, there are currently only
+three certificates in circulation with keys larger than this, and all
+three appear to be test certificates that are not actively deployed. It
+is possible there are larger keys in use in private PKIs, but we target
+the web PKI, so causing breakage here in the interests of increasing the
+default safety of users of crypto/tls seems reasonable.
+
+Thanks to Mateusz Poliwczak for reporting this issue.
+
+Updates #61460
+Fixes #61579
+Fixes CVE-2023-29409
+
+Change-Id: Ie35038515a649199a36a12fc2c5df3af855dca6c
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1912161
+Reviewed-by: Damien Neil 
+Reviewed-by: Tatiana Bradley 
+Run-TryBot: Roland Shoemaker 
+(cherry picked from commit d865c715d92887361e4bd5596e19e513f27781b7)
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1965487
+Reviewed-on: https://go-review.googlesource.com/c/go/+/514915
+Run-TryBot: David Chase 
+Reviewed-by: Matthew Dempsky 
+TryBot-Bypass: David Chase 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/2300f7ef07718f6be4d8aa8486c7de99836e233f]
+CVE: CVE-2023-29409
+Signed-off-by: Vijay Anusuri 
+---
+ src/crypto/tls/handshake_client.go  |  8 +++
+ src/crypto/tls/handshake_client_test.go | 78 +
+ src/crypto/tls/handshake_server.go  |  4 ++
+ 3 files changed, 90 insertions(+)
+
+diff --git a/src/crypto/tls/handshake_client.go 
b/src/crypto/tls/handshake_client.go
+index 4fb528c..ba33ea1 100644
+--- a/src/crypto/tls/handshake_client.go
 b/src/crypto/tls/handshake_client.go
+@@ -788,6 +788,10 @@ func (hs *clientHandshakeState) sendFinished(out []byte) 
error {
+   return nil
+ }
+ 
++// maxRSAKeySize is the maximum RSA key size in bits that we are willing
++// to verify the signatures of during a TLS handshake.
++const maxRSAKeySize = 8192
++
+ // verifyServerCertificate parses and verifies the provided chain, setting
+ // c.verifiedChains and c.peerCertificates or sending the appropriate alert.
+ func (c *Conn) verifyServerCertificate(certificates [][]byte) error {
+@@ -798,6 +802,10 @@ func (c *Conn) verifyServerCertificate(certificates 
[][]byte) error {
+   c.sendAlert(alertBadCertificate)
+   return errors.New("tls: failed to parse certificate 
from server: " + err.Error())
+   }
++  if cert.PublicKeyAlgorithm == x509.RSA && 
cert.PublicKey.(*rsa.PublicKey).N.BitLen() > maxRSAKeySize {
++  c.sendAlert(alertBadCertificate)
++  return fmt.Errorf("tls: server sent certificate 
containing RSA key larger than %d bits", maxRSAKeySize)
++  }
+   certs[i] = cert
+   }
+ 
+diff --git a/src/crypto/tls/handshake_client_test.go 
b/src/crypto/tls/handshake_client_test.go
+index 6bd3c37..8d20b2b 100644
+--- a/src/crypto/tls/handshake_client_test.go
 b/src/crypto/tls/handshake_client_test.go
+@@ -1984,3 +1984,81 @@ func TestCloseClientConnectionOnIdleServer(t 
*testing.T) {
+   t.Errorf("Error expected, but no error returned")
+   }
+ }
++
++// discardConn wraps a net.Conn but discards all writes, but reports that 
they happened.
++type discardConn struct {
++  net.Conn
++}
++
++func (dc *discardConn) Write(data []byte) (int, error) {
++  

Re: [OE-core] [PATCH][master-next] qemu: fix segfault in MMU emulation

2023-08-31 Thread Richard Purdie
On Thu, 2023-08-31 at 09:30 +0200, Alexandre Belloni via
lists.openembedded.org wrote:
> On 30/08/2023 15:39:56+0100, Ross Burton wrote:
> > From: Ross Burton 
> > 
> > Backport a patch that has been submitted to the qemu list that resolves
> > a crash in the softmmu code.
> > 
> > Signed-off-by: Ross Burton 
> > ---
> >  meta/recipes-devtools/qemu/qemu.inc   |   1 +
> >  meta/recipes-devtools/qemu/qemu/softmmu.patch | 216 ++
> >  2 files changed, 217 insertions(+)
> >  create mode 100644 meta/recipes-devtools/qemu/qemu/softmmu.patch
> > 
> > diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> > b/meta/recipes-devtools/qemu/qemu.inc
> > index 131162dd62f..ccde87d1901 100644
> > --- a/meta/recipes-devtools/qemu/qemu.inc
> > +++ b/meta/recipes-devtools/qemu/qemu.inc
> > @@ -30,6 +30,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
> > 
> > file://0010-hw-pvrdma-Protect-against-buggy-or-malicious-guest-d.patch \
> > 
> > file://0002-linux-user-Replace-use-of-lfs64-related-functions-an.patch \
> > file://fixedmeson.patch \
> > +   file://softmmu.patch \
> 
> This doesn't apply cleanly on master, can you rebase?

It applies against qemu 8.1.0 which is in master-next and whilst it
fixes the x86 issues 8.1.0 has, it breaks qemumips and qemumips64 :(

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186963): 
https://lists.openembedded.org/g/openembedded-core/message/186963
Mute This Topic: https://lists.openembedded.org/mt/101053465/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][master-next] qemu: fix segfault in MMU emulation

2023-08-31 Thread Alexandre Belloni via lists.openembedded.org
On 30/08/2023 15:39:56+0100, Ross Burton wrote:
> From: Ross Burton 
> 
> Backport a patch that has been submitted to the qemu list that resolves
> a crash in the softmmu code.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/qemu/qemu.inc   |   1 +
>  meta/recipes-devtools/qemu/qemu/softmmu.patch | 216 ++
>  2 files changed, 217 insertions(+)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/softmmu.patch
> 
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index 131162dd62f..ccde87d1901 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -30,6 +30,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
> 
> file://0010-hw-pvrdma-Protect-against-buggy-or-malicious-guest-d.patch \
> 
> file://0002-linux-user-Replace-use-of-lfs64-related-functions-an.patch \
> file://fixedmeson.patch \
> +   file://softmmu.patch \

This doesn't apply cleanly on master, can you rebase?

> file://qemu-guest-agent.init \
> file://qemu-guest-agent.udev \
> "
> diff --git a/meta/recipes-devtools/qemu/qemu/softmmu.patch 
> b/meta/recipes-devtools/qemu/qemu/softmmu.patch
> new file mode 100644
> index 000..bd28335b142
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/softmmu.patch
> @@ -0,0 +1,216 @@
> +From 1960291925029e92dd340c64186f4bdb709805b8 Mon Sep 17 00:00:00 2001
> +From: Richard Henderson 
> +Date: Sat, 26 Aug 2023 16:24:13 -0700
> +Subject: [PATCH 1/3] softmmu: Assert data in bounds in iotlb_to_section
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Suggested-by: Alex Bennée 
> +Signed-off-by: Richard Henderson 
> +Acked-by: Alex Bennée 
> +
> +Upstream-Status: Submitted 
> [https://patchew.org/QEMU/20230826232415.80233-1-richard.hender...@linaro.org/]
> +Signed-off-by: Ross Burton 
> +---
> + softmmu/physmem.c | 10 --
> + 1 file changed, 8 insertions(+), 2 deletions(-)
> +
> +diff --git a/softmmu/physmem.c b/softmmu/physmem.c
> +index 3df73542e1..7597dc1c39 100644
> +--- a/softmmu/physmem.c
>  b/softmmu/physmem.c
> +@@ -2413,9 +2413,15 @@ MemoryRegionSection *iotlb_to_section(CPUState *cpu,
> + int asidx = cpu_asidx_from_attrs(cpu, attrs);
> + CPUAddressSpace *cpuas = >cpu_ases[asidx];
> + AddressSpaceDispatch *d = qatomic_rcu_read(>memory_dispatch);
> +-MemoryRegionSection *sections = d->map.sections;
> ++int section_index = index & ~TARGET_PAGE_MASK;
> ++MemoryRegionSection *ret;
> ++
> ++assert(section_index < d->map.sections_nb);
> ++ret = d->map.sections + section_index;
> ++assert(ret->mr);
> ++assert(ret->mr->ops);
> + 
> +-return [index & ~TARGET_PAGE_MASK];
> ++return ret;
> + }
> + 
> + static void io_mem_init(void)
> +-- 
> +2.34.1
> +
> +
> +From 94d2d2c85c04aab738daf56ec73915218fa05d82 Mon Sep 17 00:00:00 2001
> +From: Richard Henderson 
> +Date: Sat, 26 Aug 2023 16:24:14 -0700
> +Subject: [PATCH 2/3] softmmu: Use async_run_on_cpu in tcg_commit
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +After system startup, run the update to memory_dispatch
> +and the tlb_flush on the cpu.  This eliminates a race,
> +wherein a running cpu sees the memory_dispatch change
> +but has not yet seen the tlb_flush.
> +
> +Since the update now happens on the cpu, we need not use
> +qatomic_rcu_read to protect the read of memory_dispatch.
> +
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1826
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1834
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1846
> +Signed-off-by: Richard Henderson 
> +Reviewed-by: Alex Bennée 
> +Tested-by: Alex Bennée 
> +Tested-by: Jonathan Cameron 
> +---
> + softmmu/physmem.c | 40 +---
> + 1 file changed, 29 insertions(+), 11 deletions(-)
> +
> +diff --git a/softmmu/physmem.c b/softmmu/physmem.c
> +index 7597dc1c39..18277ddd67 100644
> +--- a/softmmu/physmem.c
>  b/softmmu/physmem.c
> +@@ -680,8 +680,7 @@ address_space_translate_for_iotlb(CPUState *cpu, int 
> asidx, hwaddr orig_addr,
> + IOMMUTLBEntry iotlb;
> + int iommu_idx;
> + hwaddr addr = orig_addr;
> +-AddressSpaceDispatch *d =
> +-qatomic_rcu_read(>cpu_ases[asidx].memory_dispatch);
> ++AddressSpaceDispatch *d = cpu->cpu_ases[asidx].memory_dispatch;
> + 
> + for (;;) {
> + section = address_space_translate_internal(d, addr, , plen, 
> false);
> +@@ -2412,7 +2411,7 @@ MemoryRegionSection *iotlb_to_section(CPUState *cpu,
> + {
> + int asidx = cpu_asidx_from_attrs(cpu, attrs);
> + CPUAddressSpace *cpuas = >cpu_ases[asidx];
> +-AddressSpaceDispatch *d = qatomic_rcu_read(>memory_dispatch);
> ++AddressSpaceDispatch *d = cpuas->memory_dispatch;
> + int 

Re: [OE-core] [PATCH v2 1/3] inetutils: don't guess target paths

2023-08-31 Thread Alexandre Belloni via lists.openembedded.org
Hello Ross,

I think this causes failures with musl:
ERROR: inetutils-2.4-r0 do_configure: Default path values used, these must be 
set explicitly

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/7684/steps/11/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/7706/steps/12/logs/stdio

On 30/08/2023 11:20:37+0100, Ross Burton wrote:
> From: Ross Burton 
> 
> inetutils guesses a lot of target paths in cross builds, and warns that
> some of them are known to be wrong (for example, whether /proc/net/dev
> exists is guessed as 'no').
> 
> Add a post-configure function to check for these warnings, and pass
> --with-path-* as appropriate to set the paths explicitly.
> 
> This means we can remove the patch which was setting PATH_PROCNET_DEV,
> and the autoconf cache value inetutils_cv_path_login.
> 
> The downside is that these --with-path-* options are not real autoconf
> options, so the "unknown options" warning is emitted.  Losing those is
> an acceptable compromise, so disable it.
> 
> Signed-off-by: Ross Burton 
> ---
>  .../inetutils-1.9-PATH_PROCNET_DEV.patch  | 37 ---
>  .../inetutils/inetutils_2.4.bb| 19 --
>  2 files changed, 16 insertions(+), 40 deletions(-)
>  delete mode 100644 
> meta/recipes-connectivity/inetutils/inetutils/inetutils-1.9-PATH_PROCNET_DEV.patch
> 
> diff --git 
> a/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.9-PATH_PROCNET_DEV.patch
>  
> b/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.9-PATH_PROCNET_DEV.patch
> deleted file mode 100644
> index 460ddf98300..000
> --- 
> a/meta/recipes-connectivity/inetutils/inetutils/inetutils-1.9-PATH_PROCNET_DEV.patch
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -From 101130f422dd5c01a1459645d7b2a5b8d19720ab Mon Sep 17 00:00:00 2001
> -From: Martin Jansa 
> -Date: Wed, 6 Mar 2019 09:36:11 -0500
> -Subject: [PATCH] inetutils: define PATH_PROCNET_DEV if not already defined
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
> -
> -this prevents the following compilation error :
> -system/linux.c:401:15: error: 'PATH_PROCNET_DEV' undeclared (first use in 
> this function)
> -
> -this patch comes from :
> - http://repository.timesys.com/buildsources/i/inetutils/inetutils-1.9/
> -
> -Upstream-Status: Inappropriate [not author]
> -
> -Signed-of-by: Eric Bénard 
> -
> 
> - ifconfig/system/linux.c | 4 
> - 1 file changed, 4 insertions(+)
> -
> -diff --git a/ifconfig/system/linux.c b/ifconfig/system/linux.c
> -index e453b46..4268ca9 100644
>  a/ifconfig/system/linux.c
> -+++ b/ifconfig/system/linux.c
> -@@ -53,6 +53,10 @@
> - #include "../ifconfig.h"
> - 
> - 
> -+#ifndef PATH_PROCNET_DEV
> -+  #define PATH_PROCNET_DEV "/proc/net/dev"
> -+#endif
> -+
> - /* ARPHRD stuff.  */
> - 
> - static void
> diff --git a/meta/recipes-connectivity/inetutils/inetutils_2.4.bb 
> b/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
> index 85e9f642b30..fdbcbb53369 100644
> --- a/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
> +++ b/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
> @@ -20,7 +20,6 @@ SRC_URI = "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.xz \
> file://rsh.xinetd.inetutils \
> file://telnet.xinetd.inetutils \
> file://tftpd.xinetd.inetutils \
> -   file://inetutils-1.9-PATH_PROCNET_DEV.patch \
> file://inetutils-only-check-pam_appl.h-when-pam-enabled.patch \
> 
> file://0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch \
> 
> file://0002-CVE-2023-40303-Indent-changes-in-previous-commit.patch \
> @@ -42,15 +41,29 @@ PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6 
> gl_cv_socket_ipv6=no,"
>  PACKAGECONFIG[ping6] = "--enable-ping6,--disable-ping6,"
>  
>  EXTRA_OECONF = "--with-ncurses-include-dir=${STAGING_INCDIR} \
> -inetutils_cv_path_login=${base_bindir}/login \
>  --with-libreadline-prefix=${STAGING_LIBDIR} \
>  --enable-rpath=no \
> -"
> +--with-path-login=${base_bindir}/login \
> +--with-path-cp=${base_bindir}/cp \
> +--with-path-uucico=${libexecdir}/uuico \
> +--with-path-procnet-dev=/proc/net/dev \
> +"
>  
>  # These are horrible for security, disable them
>  EXTRA_OECONF:append = " --disable-rsh --disable-rshd --disable-rcp \
>  --disable-rlogin --disable-rlogind --disable-rexec --disable-rexecd"
>  
> +# The configure script guesses many paths in cross builds, check for this 
> happening
> +do_configure_cross_check() {
> +if grep "may be incorrect because of cross-compilation" ${B}/config.log; 
> then
> +bberror Default path values used, these must be set explicitly
> +fi
> +}
> +do_configure[postfuncs] += "do_configure_cross_check"
> +
> +# The --with-path options are not actually options, so this check needs to 
> be silenced
> +ERROR_QA:remove = "unknown-configure-option"
> +