Re: [OE-core] [RFC] recipeutils: check for SRC_URI name in get_recipe_upstream_version

[Alexander Kanavin]

I wonder if adding another variable is really necessary if instead you
can set UPSTREAM_CHECK_URI to anything, including entries in SRC_URI?
What is the specific example where you ran into the issue?

Alex

On Wed, 27 Mar 2024 at 19:45, Jon Mason  wrote:
>
> Previously, get_recipe_upstream_version took whatever the first entry in
> SRC_URI was for determining the upstream version.  This does not work
> for recipes that append to the SRC_URI, as theirs will never be first.
> To work around this, add a new variable to specify the SRC_URI name
> field and use that to match.  If nothing is specified, it will use the
> first SRC_URI.
>
> Signed-off-by: Jon Mason 
> ---
>  documentation/ref-manual/devtool-reference.rst |  4 ++--
>  documentation/ref-manual/variables.rst |  8 
>  meta/lib/oe/recipeutils.py | 11 +--
>  3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/documentation/ref-manual/devtool-reference.rst 
> b/documentation/ref-manual/devtool-reference.rst
> index 9319addc3c61..b774dcb1092b 100644
> --- a/documentation/ref-manual/devtool-reference.rst
> +++ b/documentation/ref-manual/devtool-reference.rst
> @@ -340,8 +340,8 @@ being able to upgrade it, displayed in a table.
>
>  This upgrade checking mechanism relies on the optional 
> :term:`UPSTREAM_CHECK_URI`,
>  :term:`UPSTREAM_CHECK_REGEX`, :term:`UPSTREAM_CHECK_GITTAGREGEX`,
> -:term:`UPSTREAM_CHECK_COMMITS` and :term:`UPSTREAM_VERSION_UNKNOWN`
> -variables in package recipes.
> +:term:`UPSTREAM_CHECK_COMMITS`, :term: `UPSTREAM_CHECK_SRCNAME`,  and
> +:term:`UPSTREAM_VERSION_UNKNOWN` variables in package recipes.
>
>  .. note::
>
> diff --git a/documentation/ref-manual/variables.rst 
> b/documentation/ref-manual/variables.rst
> index 435481c9aa12..12372c1e67f3 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -9686,6 +9686,14 @@ system and gives an overview of their function and 
> contents.
>
>   UPSTREAM_CHECK_REGEX = "package_regex"
>
> +   :term:`UPSTREAM_CHECK_SRCNAME`
> +  By default, the first entry in :term:`SRC_URI` is what is used to
> +  determine the latest upstream source code version.  If this is not
> +  the desired behavior, the :term:`UPSTREAM_CHECK_SRCNAME` variable
> +  is used to specify which of the other entries in SRC_URI should be
> +  used for this determination.  The value should match the specified
> +  name of the :term:`SRC_URI` entry.
> +
> :term:`UPSTREAM_CHECK_URI`
>You can perform a per-recipe check for what the latest upstream
>source code version is by calling ``devtool latest-version recipe``. If
> diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> index de1fbdd3a8c8..6fb9fbbc6abc 100644
> --- a/meta/lib/oe/recipeutils.py
> +++ b/meta/lib/oe/recipeutils.py
> @@ -1041,9 +1041,15 @@ def get_recipe_upstream_version(rd):
>  ru['datetime'] = datetime.now()
>  return ru
>
> -# XXX: we suppose that the first entry points to the upstream sources
> +# If the upstream name has been specified, take that one.
> +# Otherwise, default to the first URI in the list
>  src_uri = src_uris.split()[0]
> -uri_type, _, _, _, _, _ =  decodeurl(src_uri)
> +if str(rd.getVar('UPSTREAM_CHECK_SRCNAME')):
> +for s in src_uris.split():
> +ud = bb.fetch2.FetchData(s, rd)
> +if ud.parm.get('name') == 
> str(rd.getVar('UPSTREAM_CHECK_SRCNAME')):
> +src_uri = s
> +uri_type, _, _, _, _, _ = decodeurl(src_uri)
>
>  (pv, pfx, sfx) = get_recipe_pv_with_pfx_sfx(rd.getVar('PV'), uri_type)
>  ru['current_version'] = pv
> @@ -1127,6 +1133,7 @@ def get_recipe_upgrade_status(recipes=None):
>   'UPSTREAM_CHECK_COMMITS',
>   'UPSTREAM_CHECK_GITTAGREGEX',
>   'UPSTREAM_CHECK_REGEX',
> + 'UPSTREAM_CHECK_SRCNAME',
>   'UPSTREAM_CHECK_URI',
>   'UPSTREAM_VERSION_UNKNOWN',
>   'RECIPE_MAINTAINER',
> --
> 2.30.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197569): 
https://lists.openembedded.org/g/openembedded-core/message/197569
Mute This Topic: https://lists.openembedded.org/mt/105183205/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] curl: improve reproducibility

[Ross Burton]

On 27 Mar 2024, at 17:14, Oleh Matiusha via lists.openembedded.org 
 wrote:
> +do_install:append:class-target() {
> + fix_absolute_paths
> +}
> +
> +do_install:append:class-nativesdk() {
> + fix_absolute_paths
> +}

Would it be best to just always do this sed?  A native build won’t have a 
—sysroot anyway.

(or even better, stop curl-config from embedding the sysroot in the first place)

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

[OE-core] [RFC] recipeutils: check for SRC_URI name in get_recipe_upstream_version

[Jon Mason]

Previously, get_recipe_upstream_version took whatever the first entry in
SRC_URI was for determining the upstream version.  This does not work
for recipes that append to the SRC_URI, as theirs will never be first.
To work around this, add a new variable to specify the SRC_URI name
field and use that to match.  If nothing is specified, it will use the
first SRC_URI.

Signed-off-by: Jon Mason 
---
 documentation/ref-manual/devtool-reference.rst |  4 ++--
 documentation/ref-manual/variables.rst |  8 
 meta/lib/oe/recipeutils.py | 11 +--
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/documentation/ref-manual/devtool-reference.rst 
b/documentation/ref-manual/devtool-reference.rst
index 9319addc3c61..b774dcb1092b 100644
--- a/documentation/ref-manual/devtool-reference.rst
+++ b/documentation/ref-manual/devtool-reference.rst
@@ -340,8 +340,8 @@ being able to upgrade it, displayed in a table.
 
 This upgrade checking mechanism relies on the optional 
:term:`UPSTREAM_CHECK_URI`,
 :term:`UPSTREAM_CHECK_REGEX`, :term:`UPSTREAM_CHECK_GITTAGREGEX`,
-:term:`UPSTREAM_CHECK_COMMITS` and :term:`UPSTREAM_VERSION_UNKNOWN`
-variables in package recipes.
+:term:`UPSTREAM_CHECK_COMMITS`, :term: `UPSTREAM_CHECK_SRCNAME`,  and
+:term:`UPSTREAM_VERSION_UNKNOWN` variables in package recipes.
 
 .. note::
 
diff --git a/documentation/ref-manual/variables.rst 
b/documentation/ref-manual/variables.rst
index 435481c9aa12..12372c1e67f3 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -9686,6 +9686,14 @@ system and gives an overview of their function and 
contents.
 
  UPSTREAM_CHECK_REGEX = "package_regex"
 
+   :term:`UPSTREAM_CHECK_SRCNAME`
+  By default, the first entry in :term:`SRC_URI` is what is used to
+  determine the latest upstream source code version.  If this is not
+  the desired behavior, the :term:`UPSTREAM_CHECK_SRCNAME` variable
+  is used to specify which of the other entries in SRC_URI should be
+  used for this determination.  The value should match the specified
+  name of the :term:`SRC_URI` entry.
+
:term:`UPSTREAM_CHECK_URI`
   You can perform a per-recipe check for what the latest upstream
   source code version is by calling ``devtool latest-version recipe``. If
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index de1fbdd3a8c8..6fb9fbbc6abc 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -1041,9 +1041,15 @@ def get_recipe_upstream_version(rd):
 ru['datetime'] = datetime.now()
 return ru
 
-# XXX: we suppose that the first entry points to the upstream sources
+# If the upstream name has been specified, take that one.
+# Otherwise, default to the first URI in the list
 src_uri = src_uris.split()[0]
-uri_type, _, _, _, _, _ =  decodeurl(src_uri)
+if str(rd.getVar('UPSTREAM_CHECK_SRCNAME')):
+for s in src_uris.split():
+ud = bb.fetch2.FetchData(s, rd)
+if ud.parm.get('name') == str(rd.getVar('UPSTREAM_CHECK_SRCNAME')):
+src_uri = s
+uri_type, _, _, _, _, _ = decodeurl(src_uri)
 
 (pv, pfx, sfx) = get_recipe_pv_with_pfx_sfx(rd.getVar('PV'), uri_type)
 ru['current_version'] = pv
@@ -1127,6 +1133,7 @@ def get_recipe_upgrade_status(recipes=None):
  'UPSTREAM_CHECK_COMMITS',
  'UPSTREAM_CHECK_GITTAGREGEX',
  'UPSTREAM_CHECK_REGEX',
+ 'UPSTREAM_CHECK_SRCNAME',
  'UPSTREAM_CHECK_URI',
  'UPSTREAM_VERSION_UNKNOWN',
  'RECIPE_MAINTAINER',
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197567): 
https://lists.openembedded.org/g/openembedded-core/message/197567
Mute This Topic: https://lists.openembedded.org/mt/105183205/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] gmp: improve reproducibility

[Khem Raj]

On Wed, Mar 27, 2024 at 10:16 AM Oleh Matiusha via
lists.openembedded.org 
wrote:
>
> nativesdk-gmp package contains host references in output packages.
> remove them.
>
> Signed-off-by: Oleh Matiusha 
> ---
> v2
>  - move common code to separate function
> ---
> ---
>  meta/recipes-support/gmp/gmp_6.3.0.bb | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/gmp/gmp_6.3.0.bb 
> b/meta/recipes-support/gmp/gmp_6.3.0.bb
> index 3dbcd68b5c..fd4aec92fd 100644
> --- a/meta/recipes-support/gmp/gmp_6.3.0.bb
> +++ b/meta/recipes-support/gmp/gmp_6.3.0.bb
> @@ -29,13 +29,21 @@ do_install:append() {
> oe_multilib_header gmp.h
>  }
>
> -do_install:prepend:class-target() {
> +fix_absolute_paths () {
>  sed -i \
>  -e "s|--sysroot=${STAGING_DIR_HOST}||g" \
>  -e "s|${DEBUG_PREFIX_MAP}||g" \
>   ${B}/gmp.h
>  }
>
> +do_install:prepend:class-target() {
> +fix_absolute_paths
> +}
> +
> +do_install:prepend:class-nativesdk() {
> +fix_absolute_paths
> +}
> +

why can't we have it in common do_install shared across all
variants of recipes.

>  SSTATE_SCAN_FILES += "gmp.h"
>
>  # Doesn't compile in MIPS16e mode due to use of hand-written
> --
> 2.33.0
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197566): 
https://lists.openembedded.org/g/openembedded-core/message/197566
Mute This Topic: https://lists.openembedded.org/mt/105181617/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] gmp: improve reproducibility

[Oleh Matiusha via lists.openembedded.org]

nativesdk-gmp package contains host references in output packages.
remove them.

Signed-off-by: Oleh Matiusha 
---
v2
 - move common code to separate function
---
---
 meta/recipes-support/gmp/gmp_6.3.0.bb | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/gmp/gmp_6.3.0.bb 
b/meta/recipes-support/gmp/gmp_6.3.0.bb
index 3dbcd68b5c..fd4aec92fd 100644
--- a/meta/recipes-support/gmp/gmp_6.3.0.bb
+++ b/meta/recipes-support/gmp/gmp_6.3.0.bb
@@ -29,13 +29,21 @@ do_install:append() {
oe_multilib_header gmp.h
 }
 
-do_install:prepend:class-target() {
+fix_absolute_paths () {
 sed -i \
 -e "s|--sysroot=${STAGING_DIR_HOST}||g" \
 -e "s|${DEBUG_PREFIX_MAP}||g" \
  ${B}/gmp.h
 }
 
+do_install:prepend:class-target() {
+fix_absolute_paths
+}
+
+do_install:prepend:class-nativesdk() {
+fix_absolute_paths
+}
+
 SSTATE_SCAN_FILES += "gmp.h"
 
 # Doesn't compile in MIPS16e mode due to use of hand-written
-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197565): 
https://lists.openembedded.org/g/openembedded-core/message/197565
Mute This Topic: https://lists.openembedded.org/mt/105181617/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] curl: improve reproducibility

[Oleh Matiusha via lists.openembedded.org]

nativesdk-curl package contains host references in output files.
remove them.

Signed-off-by: Oleh Matiusha 
---
v2
 - moved common code to separate function 
---
---
 meta/recipes-support/curl/curl_8.6.0.bb | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/curl/curl_8.6.0.bb 
b/meta/recipes-support/curl/curl_8.6.0.bb
index ea69164d76..49ba0cb4a7 100644
--- a/meta/recipes-support/curl/curl_8.6.0.bb
+++ b/meta/recipes-support/curl/curl_8.6.0.bb
@@ -79,7 +79,7 @@ EXTRA_OECONF = " \
 ${@'--without-ssl' if (bb.utils.filter('PACKAGECONFIG', 'gnutls mbedtls 
openssl', d) == '') else ''} \
 "
 
-do_install:append:class-target() {
+fix_absolute_paths () {
# cleanup buildpaths from curl-config
sed -i \
-e 's,--sysroot=${STAGING_DIR_TARGET},,g' \
@@ -89,6 +89,14 @@ do_install:append:class-target() {
${D}${bindir}/curl-config
 }
 
+do_install:append:class-target() {
+   fix_absolute_paths
+}
+
+do_install:append:class-nativesdk() {
+   fix_absolute_paths
+}
+
 do_compile_ptest() {
oe_runmake -C ${B}/tests
 }
-- 
2.33.0


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

Re: [OE-core] [kirkstone][PATCH 1/2] python3-unittest-automake-output: add new recipe for ptest integration

[Steve Sakoman]

Sorry, it is outside of stable branch policy to add features so I
can't take this patch series.

Steve

On Tue, Mar 26, 2024 at 9:22 PM Yu, Mingli  wrote:
>
> From: Ross Burton 
>
> This package contains modules for both unittest and pytest that alter
> the output to look like automake's 'make check' output, for better
> integration with ptest.
>
> Signed-off-by: Ross Burton 
> Signed-off-by: Richard Purdie 
> (cherry picked from commit 961e4f3fc786715fc136fa446686972a4a95a3d5)
> Signed-off-by: Mingli Yu 
> ---
>  meta/conf/distro/include/maintainers.inc|  1 +
>  .../python/python3-unittest-automake-output_0.1.bb  | 13 +
>  2 files changed, 14 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb
>
> diff --git a/meta/conf/distro/include/maintainers.inc 
> b/meta/conf/distro/include/maintainers.inc
> index bfc14951fe..09c1599915 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -684,6 +684,7 @@ RECIPE_MAINTAINER:pn-python3-toml = "Tim Orling 
> "
>  RECIPE_MAINTAINER:pn-python3-tomli = "Tim Orling "
>  RECIPE_MAINTAINER:pn-python3-typing-extensions = "Tim Orling 
> "
>  RECIPE_MAINTAINER:pn-python3-typogrify = "Alexander Kanavin 
> "
> +RECIPE_MAINTAINER:pn-python3-unittest-automake-output = "Ross Burton 
> "
>  RECIPE_MAINTAINER:pn-python3-urllib3 = "Tim Orling "
>  RECIPE_MAINTAINER:pn-python3-vcversioner = "Bruce Ashfield 
> "
>  RECIPE_MAINTAINER:pn-python3-wcwidth = "Tim Orling "
> diff --git 
> a/meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb 
> b/meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb
> new file mode 100644
> index 00..ba58c18df0
> --- /dev/null
> +++ b/meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb
> @@ -0,0 +1,13 @@
> +SUMMARY = "Modules to make unittest and pytest look like Automake output, 
> for ptest"
> +HOMEPAGE = "https://gitlab.com/rossburton/python-unittest-automake-output;
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=f6f16008d9fb7349f06609329f1ab93b"
> +
> +SRC_URI = 
> "git://gitlab.com/rossburton/python-unittest-automake-output;protocol=https;branch=main"
> +SRCREV = "06537edb18f3641c70bce25256f6ecf5f5164ead"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit python_flit_core
> +
> +BBCLASSEXTEND = "native nativesdk"
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197563): 
https://lists.openembedded.org/g/openembedded-core/message/197563
Mute This Topic: https://lists.openembedded.org/mt/105173226/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] common-licenses: Backport missing license

[Colin McAllister via lists.openembedded.org]

Backports missing license from master to kirkstone.

Signed-off-by: Colin McAllister 
---
 .../LGPL-3.0-with-zeromq-exception| 181 ++
 1 file changed, 181 insertions(+)
 create mode 100644 meta/files/common-licenses/LGPL-3.0-with-zeromq-exception

diff --git a/meta/files/common-licenses/LGPL-3.0-with-zeromq-exception 
b/meta/files/common-licenses/LGPL-3.0-with-zeromq-exception
new file mode 100644
index 00..02e943c4ac
--- /dev/null
+++ b/meta/files/common-licenses/LGPL-3.0-with-zeromq-exception
@@ -0,0 +1,181 @@
+GNU LESSER GENERAL PUBLIC LICENSE
+   Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. 
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+
+  This version of the GNU Lesser General Public License incorporates
+the terms and conditions of version 3 of the GNU General Public
+License, supplemented by the additional permissions listed below.
+
+  0. Additional Definitions. 
+
+  As used herein, "this License" refers to version 3 of the GNU Lesser
+General Public License, and the "GNU GPL" refers to version 3 of the GNU
+General Public License.
+
+  "The Library" refers to a covered work governed by this License,
+other than an Application or a Combined Work as defined below.
+
+  An "Application" is any work that makes use of an interface provided
+by the Library, but which is not otherwise based on the Library.
+Defining a subclass of a class defined by the Library is deemed a mode
+of using an interface provided by the Library.
+
+  A "Combined Work" is a work produced by combining or linking an
+Application with the Library.  The particular version of the Library
+with which the Combined Work was made is also called the "Linked
+Version".
+
+  The "Minimal Corresponding Source" for a Combined Work means the
+Corresponding Source for the Combined Work, excluding any source code
+for portions of the Combined Work that, considered in isolation, are
+based on the Application, and not on the Linked Version.
+
+  The "Corresponding Application Code" for a Combined Work means the
+object code and/or source code for the Application, including any data
+and utility programs needed for reproducing the Combined Work from the
+Application, but excluding the System Libraries of the Combined Work.
+
+  1. Exception to Section 3 of the GNU GPL.
+
+  You may convey a covered work under sections 3 and 4 of this License
+without being bound by section 3 of the GNU GPL.
+
+  2. Conveying Modified Versions.
+
+  If you modify a copy of the Library, and, in your modifications, a
+facility refers to a function or data to be supplied by an Application
+that uses the facility (other than as an argument passed when the
+facility is invoked), then you may convey a copy of the modified
+version:
+
+   a) under this License, provided that you make a good faith effort to
+   ensure that, in the event an Application does not supply the
+   function or data, the facility still operates, and performs
+   whatever part of its purpose remains meaningful, or
+
+   b) under the GNU GPL, with none of the additional permissions of
+   this License applicable to that copy.
+
+  3. Object Code Incorporating Material from Library Header Files.
+
+  The object code form of an Application may incorporate material from
+a header file that is part of the Library.  You may convey such object
+code under terms of your choice, provided that, if the incorporated
+material is not limited to numerical parameters, data structure
+layouts and accessors, or small macros, inline functions and templates
+(ten or fewer lines in length), you do both of the following:
+
+   a) Give prominent notice with each copy of the object code that the
+   Library is used in it and that the Library and its use are
+   covered by this License.
+
+   b) Accompany the object code with a copy of the GNU GPL and this license
+   document.
+
+  4. Combined Works.
+
+  You may convey a Combined Work under terms of your choice that,
+taken together, effectively do not restrict modification of the
+portions of the Library contained in the Combined Work and reverse
+engineering for debugging such modifications, if you also do each of
+the following:
+
+   a) Give prominent notice with each copy of the Combined Work that
+   the Library is used in it and that the Library and its use are
+   covered by this License.
+
+   b) Accompany the Combined Work with a copy of the GNU GPL and this license
+   document.
+
+   c) For a Combined Work that displays copyright notices during
+   execution, include the copyright notice for the Library among
+   these notices, as well as a reference directing the user to the
+   copies of the GNU GPL and this license document.
+
+   d) Do one of the following:
+
+   0) Convey the Minimal Corresponding Source under the terms of this
+   

[OE-core][dunfell][PATCH 2/2] licenses.conf: Backport missing licenses

[Colin McAllister via lists.openembedded.org]

SPDX generation on Dunfell curently runs into issues because some
recipes contain licenses that are not supported in licenses.conf. This
commit backports licenses added to licenses.conf since Dunfell.

Signed-off-by: Colin McAllister 
---
This patch updates licenses.conf to align with both Kirkstone and
Master.

 meta/conf/licenses.conf | 114 
 1 file changed, 69 insertions(+), 45 deletions(-)

diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index d14c365977..991fb6cc23 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -10,84 +10,108 @@
 # Any mapping to MPL/LGPL/GPL should be fixed
 
 # AGPL variations
-SPDXLICENSEMAP[AGPL-3] = "AGPL-3.0"
-SPDXLICENSEMAP[AGPLv3] = "AGPL-3.0"
-SPDXLICENSEMAP[AGPLv3.0] = "AGPL-3.0"
-SPDXLICENSEMAP[AGPL-3.0-only] = "AGPL-3.0"
+SPDXLICENSEMAP[AGPL-3] = "AGPL-3.0-only"
+SPDXLICENSEMAP[AGPL-3+] = "AGPL-3.0-or-later"
+SPDXLICENSEMAP[AGPLv3] = "AGPL-3.0-only"
+SPDXLICENSEMAP[AGPLv3+] = "AGPL-3.0-or-later"
+SPDXLICENSEMAP[AGPLv3.0] = "AGPL-3.0-only"
+SPDXLICENSEMAP[AGPLv3.0+] = "AGPL-3.0-or-later"
+SPDXLICENSEMAP[AGPL-3.0] = "AGPL-3.0-only"
+SPDXLICENSEMAP[AGPL-3.0+] = "AGPL-3.0-or-later"
+
+# BSD variations
+SPDXLICENSEMAP[BSD-0-Clause] = "0BSD"
 
 # GPL variations
-SPDXLICENSEMAP[GPL-1] = "GPL-1.0"
-SPDXLICENSEMAP[GPLv1] = "GPL-1.0"
-SPDXLICENSEMAP[GPLv1.0] = "GPL-1.0"
-SPDXLICENSEMAP[GPL-1.0-only] = "GPL-1.0"
-SPDXLICENSEMAP[GPL-2] = "GPL-2.0"
-SPDXLICENSEMAP[GPLv2] = "GPL-2.0"
-SPDXLICENSEMAP[GPLv2+] = "GPL-2.0+"
-SPDXLICENSEMAP[GPLv2.0] = "GPL-2.0"
-SPDXLICENSEMAP[GPLv2.0+] = "GPL-2.0+"
-SPDXLICENSEMAP[GPL-2.0-only] = "GPL-2.0"
-SPDXLICENSEMAP[GPL-3] = "GPL-3.0"
-SPDXLICENSEMAP[GPLv3] = "GPL-3.0"
-SPDXLICENSEMAP[GPLv3+] = "GPL-3.0+"
-SPDXLICENSEMAP[GPLv3.0] = "GPL-3.0"
-SPDXLICENSEMAP[GPLv3.0+] = "GPL-3.0+"
-SPDXLICENSEMAP[GPL-3.0-only] = "GPL-3.0"
-
-#LGPL variations
-SPDXLICENSEMAP[LGPLv2] = "LGPL-2.0"
-SPDXLICENSEMAP[LGPLv2+] = "LGPL-2.0+"
-SPDXLICENSEMAP[LGPLv2.0] = "LGPL-2.0"
-SPDXLICENSEMAP[LGPL-2.0-only] = "LGPL-2.0"
-SPDXLICENSEMAP[LGPL2.1] = "LGPL-2.1"
-SPDXLICENSEMAP[LGPLv2.1] = "LGPL-2.1"
-SPDXLICENSEMAP[LGPLv2.1+] = "LGPL-2.1+"
-SPDXLICENSEMAP[LGPL-2.1-only] = "LGPL-2.1"
-SPDXLICENSEMAP[LGPLv3] = "LGPL-3.0"
-SPDXLICENSEMAP[LGPLv3+] = "LGPL-3.0+"
-SPDXLICENSEMAP[LGPL-3.0-only] = "LGPL-3.0"
-
-#MPL variations
+SPDXLICENSEMAP[GPL-1] = "GPL-1.0-only"
+SPDXLICENSEMAP[GPL-1+] = "GPL-1.0-or-later"
+SPDXLICENSEMAP[GPLv1] = "GPL-1.0-only"
+SPDXLICENSEMAP[GPLv1+] = "GPL-1.0-or-later"
+SPDXLICENSEMAP[GPLv1.0] = "GPL-1.0-only"
+SPDXLICENSEMAP[GPLv1.0+] = "GPL-1.0-or-later"
+SPDXLICENSEMAP[GPL-1.0] = "GPL-1.0-only"
+SPDXLICENSEMAP[GPL-1.0+] = "GPL-1.0-or-later"
+SPDXLICENSEMAP[GPL-2] = "GPL-2.0-only"
+SPDXLICENSEMAP[GPL-2+] = "GPL-2.0-or-later"
+SPDXLICENSEMAP[GPLv2] = "GPL-2.0-only"
+SPDXLICENSEMAP[GPLv2+] = "GPL-2.0-or-later"
+SPDXLICENSEMAP[GPLv2.0] = "GPL-2.0-only"
+SPDXLICENSEMAP[GPLv2.0+] = "GPL-2.0-or-later"
+SPDXLICENSEMAP[GPL-2.0] = "GPL-2.0-only"
+SPDXLICENSEMAP[GPL-2.0+] = "GPL-2.0-or-later"
+SPDXLICENSEMAP[GPL-3] = "GPL-3.0-only"
+SPDXLICENSEMAP[GPL-3+] = "GPL-3.0-or-later"
+SPDXLICENSEMAP[GPLv3] = "GPL-3.0-only"
+SPDXLICENSEMAP[GPLv3+] = "GPL-3.0-or-later"
+SPDXLICENSEMAP[GPLv3.0] = "GPL-3.0-only"
+SPDXLICENSEMAP[GPLv3.0+] = "GPL-3.0-or-later"
+SPDXLICENSEMAP[GPL-3.0] = "GPL-3.0-only"
+SPDXLICENSEMAP[GPL-3.0+] = "GPL-3.0-or-later"
+
+# LGPL variations
+SPDXLICENSEMAP[LGPLv2] = "LGPL-2.0-only"
+SPDXLICENSEMAP[LGPLv2+] = "LGPL-2.0-or-later"
+SPDXLICENSEMAP[LGPLv2.0] = "LGPL-2.0-only"
+SPDXLICENSEMAP[LGPLv2.0+] = "LGPL-2.0-or-later"
+SPDXLICENSEMAP[LGPL-2.0] = "LGPL-2.0-only"
+SPDXLICENSEMAP[LGPL-2.0+] = "LGPL-2.0-or-later"
+SPDXLICENSEMAP[LGPL2.1] = "LGPL-2.1-only"
+SPDXLICENSEMAP[LGPL2.1+] = "LGPL-2.1-or-later"
+SPDXLICENSEMAP[LGPLv2.1] = "LGPL-2.1-only"
+SPDXLICENSEMAP[LGPLv2.1+] = "LGPL-2.1-or-later"
+SPDXLICENSEMAP[LGPL-2.1] = "LGPL-2.1-only"
+SPDXLICENSEMAP[LGPL-2.1+] = "LGPL-2.1-or-later"
+SPDXLICENSEMAP[LGPLv3] = "LGPL-3.0-only"
+SPDXLICENSEMAP[LGPLv3+] = "LGPL-3.0-or-later"
+SPDXLICENSEMAP[LGPL-3.0] = "LGPL-3.0-only"
+SPDXLICENSEMAP[LGPL-3.0+] = "LGPL-3.0-or-later"
+
+# MPL variations
 SPDXLICENSEMAP[MPL-1] = "MPL-1.0"
 SPDXLICENSEMAP[MPLv1] = "MPL-1.0"
 SPDXLICENSEMAP[MPLv1.1] = "MPL-1.1"
 SPDXLICENSEMAP[MPLv2] = "MPL-2.0"
 
-#MIT variations
+# MIT variations
 SPDXLICENSEMAP[MIT-X] = "MIT"
 SPDXLICENSEMAP[MIT-style] = "MIT"
 
-#Openssl variations
+# Openssl variations
 SPDXLICENSEMAP[openssl] = "OpenSSL"
 
-#PSF variations
+# PSF variations
 SPDXLICENSEMAP[PSF] = "PSF-2.0"
 SPDXLICENSEMAP[PSFv2] = "PSF-2.0"
 
-#Python variations
+# Python variations
 SPDXLICENSEMAP[Python-2] = "Python-2.0"
 
-#Apache variations
+# Apache variations
 SPDXLICENSEMAP[Apachev2] = "Apache-2.0"
 SPDXLICENSEMAP[Apache-2] = "Apache-2.0"
 
-#Artistic variations
+# Artistic variations
 SPDXLICENSEMAP[Artisticv1] = "Artistic-1.0"
 SPDXLICENSEMAP[Artistic-1] = "Artistic-1.0"
 
-#Academic variations
+# Academic 

[OE-core][dunfell][PATCH 0/2] License backports

[Colin McAllister via lists.openembedded.org]

The following two changes backport common-licenes added after
Dunfell. This fixes spdx generation issues for some recipes on
Dunfell that use licenses that are not supported in licenses.conf.

Colin McAllister (2):
  common-licenses: Backport missing licenses
  licenses.conf: Backport missing licenses

 meta/conf/licenses.conf   | 114 +--
 meta/files/common-licenses/0BSD   |   5 +
 meta/files/common-licenses/ADSL   |   1 +
 meta/files/common-licenses/AFL-1.1|  27 +
 meta/files/common-licenses/AGPL-1.0-only  |  86 +++
 meta/files/common-licenses/AGPL-1.0-or-later  |  86 +++
 meta/files/common-licenses/AGPL-3.0-only  | 661 ++
 meta/files/common-licenses/AGPL-3.0-or-later  | 613 
 meta/files/common-licenses/AMDPLPA|  20 +
 meta/files/common-licenses/AML|   9 +
 meta/files/common-licenses/AMPAS  |  13 +
 meta/files/common-licenses/ANTLR-PD-fallback  |   7 +
 meta/files/common-licenses/APAFML |   3 +
 meta/files/common-licenses/Abstyles   |  11 +
 meta/files/common-licenses/Adobe-2006 |  12 +
 meta/files/common-licenses/Adobe-Glyph|  10 +
 meta/files/common-licenses/Afmparse   |  10 +
 meta/files/common-licenses/Aladdin|  62 ++
 meta/files/common-licenses/Artistic-1.0-Perl  |  51 ++
 meta/files/common-licenses/Artistic-1.0-cl8   |  51 ++
 meta/files/common-licenses/BSD-2-Clause-Views |  11 +
 .../common-licenses/BSD-3-Clause-Attribution  |  11 +
 meta/files/common-licenses/BSD-3-Clause-Clear |  32 +
 meta/files/common-licenses/BSD-3-Clause-LBNL  |  12 +
 .../common-licenses/BSD-3-Clause-Modification |  35 +
 .../BSD-3-Clause-No-Military-License  |  16 +
 .../BSD-3-Clause-No-Nuclear-License   |  14 +
 .../BSD-3-Clause-No-Nuclear-License-2014  |  16 +
 .../BSD-3-Clause-No-Nuclear-Warranty  |  14 +
 .../common-licenses/BSD-3-Clause-Open-MPI |  34 +
 .../common-licenses/BSD-4-Clause-Shortened|  13 +
 meta/files/common-licenses/BSD-4-Clause-UC|  15 +
 meta/files/common-licenses/BSD-Protection |  53 ++
 meta/files/common-licenses/BSD-Source-Code|  10 +
 meta/files/common-licenses/BUSL-1.1   |  72 ++
 meta/files/common-licenses/Bahyph |  11 +
 meta/files/common-licenses/Barr   |   1 +
 meta/files/common-licenses/Beerware   |   1 +
 meta/files/common-licenses/BitTorrent-1.0 | 330 +
 meta/files/common-licenses/BitTorrent-1.1 | 137 
 meta/files/common-licenses/BlueOak-1.0.0  |  55 ++
 meta/files/common-licenses/Borceux|  19 +
 meta/files/common-licenses/C-UDA-1.0  |  47 ++
 meta/files/common-licenses/CAL-1.0| 354 ++
 .../CAL-1.0-Combined-Work-Exception   | 354 ++
 meta/files/common-licenses/CC-BY-2.5-AU   | 112 +++
 meta/files/common-licenses/CC-BY-3.0-AT   | 111 +++
 meta/files/common-licenses/CC-BY-3.0-DE   | 109 +++
 meta/files/common-licenses/CC-BY-3.0-NL   |  97 +++
 meta/files/common-licenses/CC-BY-3.0-US   |  83 +++
 meta/files/common-licenses/CC-BY-4.0  | 156 +
 meta/files/common-licenses/CC-BY-NC-3.0-DE| 110 +++
 meta/files/common-licenses/CC-BY-NC-4.0   | 158 +
 meta/files/common-licenses/CC-BY-NC-ND-3.0-DE | 101 +++
 .../files/common-licenses/CC-BY-NC-ND-3.0-IGO |  99 +++
 meta/files/common-licenses/CC-BY-NC-ND-4.0| 155 
 meta/files/common-licenses/CC-BY-NC-SA-2.0-FR |  93 +++
 meta/files/common-licenses/CC-BY-NC-SA-2.0-UK | 149 
 meta/files/common-licenses/CC-BY-NC-SA-3.0-DE | 126 
 .../files/common-licenses/CC-BY-NC-SA-3.0-IGO | 105 +++
 meta/files/common-licenses/CC-BY-NC-SA-4.0| 170 +
 meta/files/common-licenses/CC-BY-ND-3.0-DE| 101 +++
 meta/files/common-licenses/CC-BY-ND-4.0   | 154 
 meta/files/common-licenses/CC-BY-SA-2.0-UK| 147 
 meta/files/common-licenses/CC-BY-SA-2.1-JP|  83 +++
 meta/files/common-licenses/CC-BY-SA-3.0-AT| 139 
 meta/files/common-licenses/CC-BY-SA-3.0-DE| 136 
 meta/files/common-licenses/CC-PDDC|   8 +
 meta/files/common-licenses/CDDL-1.1   | 123 
 meta/files/common-licenses/CDL-1.0|  53 ++
 .../files/common-licenses/CDLA-Permissive-1.0 |  85 +++
 .../files/common-licenses/CDLA-Permissive-2.0 |  35 +
 meta/files/common-licenses/CDLA-Sharing-1.0   |  89 +++
 meta/files/common-licenses/CECILL-1.1 | 229 ++
 meta/files/common-licenses/CECILL-2.1 | 518 ++
 meta/files/common-licenses/CERN-OHL-1.1   |  47 ++
 meta/files/common-licenses/CERN-OHL-1.2   |  49 ++
 meta/files/common-licenses/CERN-OHL-P-2.0 | 199 ++
 meta/files/common-licenses/CERN-OHL-S-2.0 | 289 
 meta/files/common-licenses/CERN-OHL-W-2.0 | 310 
 meta/files/common-licenses/CNRI-Jython|  12 +
 meta/files/common-licenses/CNRI-Python|  25 +
 

Re: [oe-core][RFC][PATCHv2] glib-2.0: update 2.78.4 -> 2.80.0

[Alexander Kanavin]

On Tue, 26 Mar 2024 at 19:10, Alexander Kanavin via
lists.openembedded.org 
wrote:
>
> On Wed, 20 Mar 2024 at 12:43, Ross Burton  wrote:
> > > and adding that depend (or using inherit gobject-introspection) caused 
> > > circular dependency
> >
> > Indeed.  My branch has a glib-initial to break that cycle, but it wasn’t 
> > quite working right (and upstream were still changing things).
>
> I just took a look at this and ugh. Upstream should just merge g-i and
> glib into one source tree, and then figure out the correct build
> sequence.
>
> I think we can avoid glib-initial by building and installing glib as
> usual (with introspection turned off), then building g-i, then
> building/installing only the introspection data from glib. This needs
> confirmation that the introspection flag only affects those parts, and
> not libraries themselves, and perhaps a new build flag
> 'introspection-only' or similar to avoid unneeded library builds.

Ok, I've poked at this a bit more, and arrived at the combination of
options and variants that builds world fully via the 'glib-initial'
approach:
https://git.yoctoproject.org/poky-contrib/log/?h=akanavin/package-version-updates

You're welcome to test this. The key element is adding a mcextend
variant of glib that disables introspection, making g-i depend on
that, then building glib normally in a way that doesn't clash with the
mcextend target.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197558): 
https://lists.openembedded.org/g/openembedded-core/message/197558
Mute This Topic: https://lists.openembedded.org/mt/105042037/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 31/34] spirv-tools: upgrade 1.3.275.0 -> 1.3.280.0

[Alexander Kanavin]

This should all be squashed into a single commit, because otherwise it
will break bisection, if the bisect process lands between those
patches (or just take the original v2). I'm fine with not having
upstream changelogs.

Alex


On Wed, 27 Mar 2024 at 13:45, Alexandre Belloni via
lists.openembedded.org
 wrote:
>
> On 27/03/2024 11:34:42+, Jose Quaresma wrote:
> > Hi Alexandre,
> >
> > I see this is still on
> > https://git.yoctoproject.org/poky-contrib/log/?h=abelloni/master-next but
> > it should be dropped
> > because it is included in the vulkan v2
> > https://lists.openembedded.org/g/openembedded-core/message/197546
> >
> > This spirv and glslang recipes should be updated in lockstep with vulkan as
> > printed by AlexK on
> > https://lists.openembedded.org/g/openembedded-core/message/197529
>
> Note that I took the spirv patches only once there was the vulkan
> update so it is not *still* there.
> This is super frustrating because the vulkan upgrade commit changelog is
> not a replacement for the spirv upgrade commit changelog.
>
> >
> > Jose
> >
> >
> > wangmy via lists.openembedded.org 
> > 
> > escreveu (terça, 26/03/2024 à(s) 00:37):
> >
> > > From: Wang Mingyu 
> > >
> > > Changelog:
> > > ==
> > > - Add tooling support for SPV_KHR_maximal_reconvergence
> > > - Add support for SPV_KHR_float_controls2
> > > - SPV_KHR_quad_control
> > > - Fold 64-bit int operations
> > > - update image enum tests to remove Kernel capability
> > > - Support operand kind for SPV_INTEL_maximum_registers
> > > - SPV_NV_shader_atomic_fp16_vector
> > > - Support for SPV_QCOM_image_processing2 (#5582)
> > > - Fix access chain struct checks
> > >
> > > Signed-off-by: Wang Mingyu 
> > > ---
> > >  .../spir/{spirv-tools_1.3.275.0.bb => spirv-tools_1.3.280.0.bb} | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >  rename meta/recipes-graphics/spir/{spirv-tools_1.3.275.0.bb =>
> > > spirv-tools_1.3.280.0.bb} (96%)
> > >
> > > diff --git a/meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> > > b/meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> > > similarity index 96%
> > > rename from meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> > > rename to meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> > > index 05c6de1b50..d2b6acf946 100644
> > > --- a/meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> > > +++ b/meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> > > @@ -7,7 +7,7 @@ SECTION = "graphics"
> > >  LICENSE  = "Apache-2.0"
> > >  LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
> > >
> > > -SRCREV = "f0cc85efdbbe3a46eae90e0f915dc1509836d0fc"
> > > +SRCREV = "04896c462d9f3f504c99a4698605b6524af813c1"
> > >  SRC_URI = "git://
> > > github.com/KhronosGroup/SPIRV-Tools.git;branch=main;protocol=https"
> > >  PE = "1"
> > >  # These recipes need to be updated in lockstep with each other:
> > > --
> > > 2.34.1
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Best regards,
> >
> > José Quaresma
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197557): 
https://lists.openembedded.org/g/openembedded-core/message/197557
Mute This Topic: https://lists.openembedded.org/mt/105150547/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 31/34] spirv-tools: upgrade 1.3.275.0 -> 1.3.280.0

[Alexandre Belloni via lists.openembedded.org]

On 27/03/2024 11:34:42+, Jose Quaresma wrote:
> Hi Alexandre,
> 
> I see this is still on
> https://git.yoctoproject.org/poky-contrib/log/?h=abelloni/master-next but
> it should be dropped
> because it is included in the vulkan v2
> https://lists.openembedded.org/g/openembedded-core/message/197546
> 
> This spirv and glslang recipes should be updated in lockstep with vulkan as
> printed by AlexK on
> https://lists.openembedded.org/g/openembedded-core/message/197529

Note that I took the spirv patches only once there was the vulkan
update so it is not *still* there.
This is super frustrating because the vulkan upgrade commit changelog is
not a replacement for the spirv upgrade commit changelog.

> 
> Jose
> 
> 
> wangmy via lists.openembedded.org 
> escreveu (terça, 26/03/2024 à(s) 00:37):
> 
> > From: Wang Mingyu 
> >
> > Changelog:
> > ==
> > - Add tooling support for SPV_KHR_maximal_reconvergence
> > - Add support for SPV_KHR_float_controls2
> > - SPV_KHR_quad_control
> > - Fold 64-bit int operations
> > - update image enum tests to remove Kernel capability
> > - Support operand kind for SPV_INTEL_maximum_registers
> > - SPV_NV_shader_atomic_fp16_vector
> > - Support for SPV_QCOM_image_processing2 (#5582)
> > - Fix access chain struct checks
> >
> > Signed-off-by: Wang Mingyu 
> > ---
> >  .../spir/{spirv-tools_1.3.275.0.bb => spirv-tools_1.3.280.0.bb} | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >  rename meta/recipes-graphics/spir/{spirv-tools_1.3.275.0.bb =>
> > spirv-tools_1.3.280.0.bb} (96%)
> >
> > diff --git a/meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> > b/meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> > similarity index 96%
> > rename from meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> > rename to meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> > index 05c6de1b50..d2b6acf946 100644
> > --- a/meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> > +++ b/meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> > @@ -7,7 +7,7 @@ SECTION = "graphics"
> >  LICENSE  = "Apache-2.0"
> >  LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
> >
> > -SRCREV = "f0cc85efdbbe3a46eae90e0f915dc1509836d0fc"
> > +SRCREV = "04896c462d9f3f504c99a4698605b6524af813c1"
> >  SRC_URI = "git://
> > github.com/KhronosGroup/SPIRV-Tools.git;branch=main;protocol=https"
> >  PE = "1"
> >  # These recipes need to be updated in lockstep with each other:
> > --
> > 2.34.1
> >
> >
> > 
> >
> >
> 
> -- 
> Best regards,
> 
> José Quaresma

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197556): 
https://lists.openembedded.org/g/openembedded-core/message/197556
Mute This Topic: https://lists.openembedded.org/mt/105150547/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 30/34] spirv-headers: upgrade 1.3.275.0 -> 1.3.280.0

[Jose Quaresma]

Hi Alexandre,

I see this is still on
https://git.yoctoproject.org/poky-contrib/log/?h=abelloni/master-next but
it should be dropped
because it is included in the vulkan v2
https://lists.openembedded.org/g/openembedded-core/message/197546

This spirv and glslang recipes should be updated in lockstep with vulkan as
printed by AlexK on
https://lists.openembedded.org/g/openembedded-core/message/197529

Jose

wangmy via lists.openembedded.org 
escreveu (terça, 26/03/2024 à(s) 00:37):

> From: Wang Mingyu 
>
> Changelog:
> ==
> -Add SPV_NV_raw_access_chains
> -Headers support for SPV_INTEL_maximum_registers extension
> -Add SPV_NV_shader_atomic_fp16_vector
> -SPV_QCOM_image_processing2
> -cmake: Allow external control of test and install options
> -remove Kernel from Image Channel Order and Channel Data Type enums
> -Update FPFastMath token reservation
> -List all licenses in the root LICENSE file.
> -Support SPV_KHR_quad_control (with fixed line endings)
> -SPV_KHR_float_controls2
> -Add SPV_KHR_maximal_reconvergence
> -update copyright dates to 2024
> -Register Zig Compiler tool
> -Add a Source Language for Zig
> -Reserve an FPFastMathMode bit
> -Bump the github-actions group with 1 update
> -Publish the header for the vulkan-shader-profiler embedded reflection
> -Upstream tokens for SPV_INTEL_masked_gather_scatter
> -feat: Create dependabot.yml
>
> License-Update: List all licenses in the root LICENSE file.
>
> Signed-off-by: Wang Mingyu 
> ---
>  ...{spirv-headers_1.3.275.0.bb => spirv-headers_1.3.280.0.bb} | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-graphics/spir/{spirv-headers_1.3.275.0.bb =>
> spirv-headers_1.3.280.0.bb} (84%)
>
> diff --git a/meta/recipes-graphics/spir/spirv-headers_1.3.275.0.bb
> b/meta/recipes-graphics/spir/spirv-headers_1.3.280.0.bb
> similarity index 84%
> rename from meta/recipes-graphics/spir/spirv-headers_1.3.275.0.bb
> rename to meta/recipes-graphics/spir/spirv-headers_1.3.280.0.bb
> index 598a8fc209..26bfd9c4fa 100644
> --- a/meta/recipes-graphics/spir/spirv-headers_1.3.275.0.bb
> +++ b/meta/recipes-graphics/spir/spirv-headers_1.3.280.0.bb
> @@ -2,9 +2,9 @@ SUMMARY = "Machine-readable files for the SPIR-V Registry"
>  SECTION = "graphics"
>  HOMEPAGE = "https://www.khronos.org/registry/spir-v;
>  LICENSE = "MIT"
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=c938b85bceb8fb26c1a807f28a52ae2d"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=d14ee3b13f42e9c9674acc5925c3d741"
>
> -SRCREV = "1c6bb2743599e6eb6f37b2969acc0aef812e32e3"
> +SRCREV = "8b246ff75c6615ba4532fe4fde20f1be090c3764"
>  SRC_URI = "git://
> github.com/KhronosGroup/SPIRV-Headers;protocol=https;branch=main"
>  PE = "1"
>  # These recipes need to be updated in lockstep with each other:
> --
> 2.34.1
>
>
> 
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197555): 
https://lists.openembedded.org/g/openembedded-core/message/197555
Mute This Topic: https://lists.openembedded.org/mt/105150545/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 31/34] spirv-tools: upgrade 1.3.275.0 -> 1.3.280.0

[Jose Quaresma]

Hi Alexandre,

I see this is still on
https://git.yoctoproject.org/poky-contrib/log/?h=abelloni/master-next but
it should be dropped
because it is included in the vulkan v2
https://lists.openembedded.org/g/openembedded-core/message/197546

This spirv and glslang recipes should be updated in lockstep with vulkan as
printed by AlexK on
https://lists.openembedded.org/g/openembedded-core/message/197529

Jose


wangmy via lists.openembedded.org 
escreveu (terça, 26/03/2024 à(s) 00:37):

> From: Wang Mingyu 
>
> Changelog:
> ==
> - Add tooling support for SPV_KHR_maximal_reconvergence
> - Add support for SPV_KHR_float_controls2
> - SPV_KHR_quad_control
> - Fold 64-bit int operations
> - update image enum tests to remove Kernel capability
> - Support operand kind for SPV_INTEL_maximum_registers
> - SPV_NV_shader_atomic_fp16_vector
> - Support for SPV_QCOM_image_processing2 (#5582)
> - Fix access chain struct checks
>
> Signed-off-by: Wang Mingyu 
> ---
>  .../spir/{spirv-tools_1.3.275.0.bb => spirv-tools_1.3.280.0.bb} | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-graphics/spir/{spirv-tools_1.3.275.0.bb =>
> spirv-tools_1.3.280.0.bb} (96%)
>
> diff --git a/meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> b/meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> similarity index 96%
> rename from meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> rename to meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> index 05c6de1b50..d2b6acf946 100644
> --- a/meta/recipes-graphics/spir/spirv-tools_1.3.275.0.bb
> +++ b/meta/recipes-graphics/spir/spirv-tools_1.3.280.0.bb
> @@ -7,7 +7,7 @@ SECTION = "graphics"
>  LICENSE  = "Apache-2.0"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
>
> -SRCREV = "f0cc85efdbbe3a46eae90e0f915dc1509836d0fc"
> +SRCREV = "04896c462d9f3f504c99a4698605b6524af813c1"
>  SRC_URI = "git://
> github.com/KhronosGroup/SPIRV-Tools.git;branch=main;protocol=https"
>  PE = "1"
>  # These recipes need to be updated in lockstep with each other:
> --
> 2.34.1
>
>
> 
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197554): 
https://lists.openembedded.org/g/openembedded-core/message/197554
Mute This Topic: https://lists.openembedded.org/mt/105150547/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][nanbield] openssl: fix crash on aarch64 if BTI is enabled but no Crypto instructions

[Ross Burton]

From: Ross Burton 

On aarch64, if the processor doesn't have the Crypto instructions then
OpenSSL will fall back onto the "bit-sliced" assembler routines. When
branch protection (BTI) was enabled in OpenSSL these routines were
missed, so if BTI is available libssl will immediately abort when it
enters this assembler.

Backport a patch submitted upstream to add the required call target
annotations so that BTI doesn't believe the code is being exploited.

Signed-off-by: Ross Burton 
---
 .../openssl/openssl/bti.patch | 58 +++
 .../openssl/openssl_3.1.5.bb  |  1 +
 2 files changed, 59 insertions(+)
 create mode 100644 meta/recipes-connectivity/openssl/openssl/bti.patch

diff --git a/meta/recipes-connectivity/openssl/openssl/bti.patch 
b/meta/recipes-connectivity/openssl/openssl/bti.patch
new file mode 100644
index 000..748576c30ca
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/bti.patch
@@ -0,0 +1,58 @@
+From ba8a599395f8b770c76316b5f5b0f3838567014f Mon Sep 17 00:00:00 2001
+From: Tom Cosgrove 
+Date: Tue, 26 Mar 2024 13:18:00 +
+Subject: [PATCH] aarch64: fix BTI in bsaes assembly code
+
+In Arm systems where BTI is enabled but the Crypto extensions are not (more
+likely in FVPs than in real hardware), the bit-sliced assembler code will
+be used. However, this wasn't annotated with BTI instructions when BTI was
+enabled, so the moment libssl jumps into this code it (correctly) aborts.
+
+Solve this by adding the missing BTI landing pads.
+
+Upstream-Status: Submitted [https://github.com/openssl/openssl/pull/23982]
+Signed-off-by: Ross Burton 
+---
+ crypto/aes/asm/bsaes-armv8.pl | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/crypto/aes/asm/bsaes-armv8.pl b/crypto/aes/asm/bsaes-armv8.pl
+index b3c97e439f..c3c5ff3e05 100644
+--- a/crypto/aes/asm/bsaes-armv8.pl
 b/crypto/aes/asm/bsaes-armv8.pl
+@@ -1018,6 +1018,7 @@ _bsaes_key_convert:
+ //   Initialisation vector overwritten with last quadword of ciphertext
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_cbc_encrypt:
++AARCH64_VALID_CALL_TARGET
+ cmp x2, #128
+ bhs .Lcbc_do_bsaes
+ b   AES_cbc_encrypt
+@@ -1270,7 +1271,7 @@ ossl_bsaes_cbc_encrypt:
+ //   Output text filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_ctr32_encrypt_blocks:
+-
++AARCH64_VALID_CALL_TARGET
+ cmp x2, #8  // use plain AES for
+ blo .Lctr_enc_short // small sizes
+ 
+@@ -1476,6 +1477,7 @@ ossl_bsaes_ctr32_encrypt_blocks:
+ //   Output ciphertext filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_xts_encrypt:
++AARCH64_VALID_CALL_TARGET
+ // Stack layout:
+ // sp ->
+ //nrounds*128-96 bytes: key schedule
+@@ -1921,6 +1923,7 @@ ossl_bsaes_xts_encrypt:
+ //   Output plaintext filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_xts_decrypt:
++AARCH64_VALID_CALL_TARGET
+ // Stack layout:
+ // sp ->
+ //nrounds*128-96 bytes: key schedule
+-- 
+2.34.1
+
diff --git a/meta/recipes-connectivity/openssl/openssl_3.1.5.bb 
b/meta/recipes-connectivity/openssl/openssl_3.1.5.bb
index 05bfeac45e3..174b5f6ad36 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.1.5.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.1.5.bb
@@ -12,6 +12,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz 
\

file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
file://0001-Configure-do-not-tweak-mips-cflags.patch \
file://0001-Added-handshake-history-reporting-when-test-fails.patch 
\
+   file://bti.patch \
"
 
 SRC_URI:append:class-nativesdk = " \
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197553): 
https://lists.openembedded.org/g/openembedded-core/message/197553
Mute This Topic: https://lists.openembedded.org/mt/105174971/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][kirkstone] openssl: fix crash on aarch64 if BTI is enabled but no Crypto instructions

[Ross Burton]

From: Ross Burton 

On aarch64, if the processor doesn't have the Crypto instructions then
OpenSSL will fall back onto the "bit-sliced" assembler routines. When
branch protection (BTI) was enabled in OpenSSL these routines were
missed, so if BTI is available libssl will immediately abort when it
enters this assembler.

Backport a patch submitted upstream to add the required call target
annotations so that BTI doesn't believe the code is being exploited.

Signed-off-by: Ross Burton 
---
 .../openssl/openssl/bti.patch | 58 +++
 .../openssl/openssl_3.0.13.bb |  1 +
 2 files changed, 59 insertions(+)
 create mode 100644 meta/recipes-connectivity/openssl/openssl/bti.patch

diff --git a/meta/recipes-connectivity/openssl/openssl/bti.patch 
b/meta/recipes-connectivity/openssl/openssl/bti.patch
new file mode 100644
index 000..748576c30ca
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/bti.patch
@@ -0,0 +1,58 @@
+From ba8a599395f8b770c76316b5f5b0f3838567014f Mon Sep 17 00:00:00 2001
+From: Tom Cosgrove 
+Date: Tue, 26 Mar 2024 13:18:00 +
+Subject: [PATCH] aarch64: fix BTI in bsaes assembly code
+
+In Arm systems where BTI is enabled but the Crypto extensions are not (more
+likely in FVPs than in real hardware), the bit-sliced assembler code will
+be used. However, this wasn't annotated with BTI instructions when BTI was
+enabled, so the moment libssl jumps into this code it (correctly) aborts.
+
+Solve this by adding the missing BTI landing pads.
+
+Upstream-Status: Submitted [https://github.com/openssl/openssl/pull/23982]
+Signed-off-by: Ross Burton 
+---
+ crypto/aes/asm/bsaes-armv8.pl | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/crypto/aes/asm/bsaes-armv8.pl b/crypto/aes/asm/bsaes-armv8.pl
+index b3c97e439f..c3c5ff3e05 100644
+--- a/crypto/aes/asm/bsaes-armv8.pl
 b/crypto/aes/asm/bsaes-armv8.pl
+@@ -1018,6 +1018,7 @@ _bsaes_key_convert:
+ //   Initialisation vector overwritten with last quadword of ciphertext
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_cbc_encrypt:
++AARCH64_VALID_CALL_TARGET
+ cmp x2, #128
+ bhs .Lcbc_do_bsaes
+ b   AES_cbc_encrypt
+@@ -1270,7 +1271,7 @@ ossl_bsaes_cbc_encrypt:
+ //   Output text filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_ctr32_encrypt_blocks:
+-
++AARCH64_VALID_CALL_TARGET
+ cmp x2, #8  // use plain AES for
+ blo .Lctr_enc_short // small sizes
+ 
+@@ -1476,6 +1477,7 @@ ossl_bsaes_ctr32_encrypt_blocks:
+ //   Output ciphertext filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_xts_encrypt:
++AARCH64_VALID_CALL_TARGET
+ // Stack layout:
+ // sp ->
+ //nrounds*128-96 bytes: key schedule
+@@ -1921,6 +1923,7 @@ ossl_bsaes_xts_encrypt:
+ //   Output plaintext filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_xts_decrypt:
++AARCH64_VALID_CALL_TARGET
+ // Stack layout:
+ // sp ->
+ //nrounds*128-96 bytes: key schedule
+-- 
+2.34.1
+
diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.13.bb 
b/meta/recipes-connectivity/openssl/openssl_3.0.13.bb
index 5e43fdc2ded..d0910a7a32d 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.0.13.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.0.13.bb
@@ -12,6 +12,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz 
\

file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
file://afalg.patch \
file://0001-Configure-do-not-tweak-mips-cflags.patch \
+   file://bti.patch \
"
 
 SRC_URI:append:class-nativesdk = " \
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197552): 
https://lists.openembedded.org/g/openembedded-core/message/197552
Mute This Topic: https://lists.openembedded.org/mt/105174962/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] openssl: fix crash on aarch64 if BTI is enabled but no Crypto instructions

[Ross Burton]

From: Ross Burton 

On aarch64, if the processor doesn't have the Crypto instructions then
OpenSSL will fall back onto the "bit-sliced" assembler routines. When
branch protection (BTI) was enabled in OpenSSL these routines were
missed, so if BTI is available libssl will immediately abort when it
enters this assembler.

Backport a patch submitted upstream to add the required call target
annotations so that BTI doesn't believe the code is being exploited.

Signed-off-by: Ross Burton 
---
 .../openssl/openssl/bti.patch | 58 +++
 .../openssl/openssl_3.2.1.bb  |  1 +
 2 files changed, 59 insertions(+)
 create mode 100644 meta/recipes-connectivity/openssl/openssl/bti.patch

diff --git a/meta/recipes-connectivity/openssl/openssl/bti.patch 
b/meta/recipes-connectivity/openssl/openssl/bti.patch
new file mode 100644
index 000..748576c30ca
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/bti.patch
@@ -0,0 +1,58 @@
+From ba8a599395f8b770c76316b5f5b0f3838567014f Mon Sep 17 00:00:00 2001
+From: Tom Cosgrove 
+Date: Tue, 26 Mar 2024 13:18:00 +
+Subject: [PATCH] aarch64: fix BTI in bsaes assembly code
+
+In Arm systems where BTI is enabled but the Crypto extensions are not (more
+likely in FVPs than in real hardware), the bit-sliced assembler code will
+be used. However, this wasn't annotated with BTI instructions when BTI was
+enabled, so the moment libssl jumps into this code it (correctly) aborts.
+
+Solve this by adding the missing BTI landing pads.
+
+Upstream-Status: Submitted [https://github.com/openssl/openssl/pull/23982]
+Signed-off-by: Ross Burton 
+---
+ crypto/aes/asm/bsaes-armv8.pl | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/crypto/aes/asm/bsaes-armv8.pl b/crypto/aes/asm/bsaes-armv8.pl
+index b3c97e439f..c3c5ff3e05 100644
+--- a/crypto/aes/asm/bsaes-armv8.pl
 b/crypto/aes/asm/bsaes-armv8.pl
+@@ -1018,6 +1018,7 @@ _bsaes_key_convert:
+ //   Initialisation vector overwritten with last quadword of ciphertext
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_cbc_encrypt:
++AARCH64_VALID_CALL_TARGET
+ cmp x2, #128
+ bhs .Lcbc_do_bsaes
+ b   AES_cbc_encrypt
+@@ -1270,7 +1271,7 @@ ossl_bsaes_cbc_encrypt:
+ //   Output text filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_ctr32_encrypt_blocks:
+-
++AARCH64_VALID_CALL_TARGET
+ cmp x2, #8  // use plain AES for
+ blo .Lctr_enc_short // small sizes
+ 
+@@ -1476,6 +1477,7 @@ ossl_bsaes_ctr32_encrypt_blocks:
+ //   Output ciphertext filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_xts_encrypt:
++AARCH64_VALID_CALL_TARGET
+ // Stack layout:
+ // sp ->
+ //nrounds*128-96 bytes: key schedule
+@@ -1921,6 +1923,7 @@ ossl_bsaes_xts_encrypt:
+ //   Output plaintext filled in
+ //   No output registers, usual AAPCS64 register preservation
+ ossl_bsaes_xts_decrypt:
++AARCH64_VALID_CALL_TARGET
+ // Stack layout:
+ // sp ->
+ //nrounds*128-96 bytes: key schedule
+-- 
+2.34.1
+
diff --git a/meta/recipes-connectivity/openssl/openssl_3.2.1.bb 
b/meta/recipes-connectivity/openssl/openssl_3.2.1.bb
index 1682b6f8ccf..c7134c54dba 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.2.1.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.2.1.bb
@@ -12,6 +12,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz 
\

file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
file://0001-Configure-do-not-tweak-mips-cflags.patch \
file://0001-Added-handshake-history-reporting-when-test-fails.patch 
\
+   file://bti.patch \
"
 
 SRC_URI:append:class-nativesdk = " \
-- 
2.34.1


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

Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen performac

[Alexander Kanavin]

Sorry, but I have to strongly object to this. Performance improvements
are not bug/security fixes, and thus are not eligible for backports.

In addition, key generation in a key crypto component is a highly
sensitive area, it's very easy to get wrong and render the whole of
yocto insecure, and without upstream review none of us understand what
is going on, and what is being changed, and whether the backport is
correct.

If you need faster crypto, bring in a new openssl version in a private
layer, or better yet, contribute it to a lts-mixin layer.

Alex

On Wed, 27 Mar 2024 at 04:16, jason.lau via lists.openembedded.org
 wrote:
>
> Hey!
>
> Sorry for the late reply, I was on vacation for a week.
>
> >-Original Message-
> >From: openembedded-core@lists.openembedded.org  >c...@lists.openembedded.org> On Behalf Of Steve Sakoman via
> >lists.openembedded.org
> >Sent: Wednesday, March 27, 2024 8:11 AM
> >To: MacLeod, Randy 
> >Cc: Liu, Haitao ; openembedded-
> >c...@lists.openembedded.org
> >Subject: Re: [OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen
> >performac
> >
> >CAUTION: This email comes from a non Wind River email account!
> >Do not click links or open attachments unless you recognize the sender and
> >know the content is safe.
> >
> >On Tue, Mar 26, 2024 at 11:34 AM Randy MacLeod via lists.openembedded.org
> > wrote:
> >>
> >> On 2024-03-19 7:23 p.m., Steve Sakoman wrote:
> >>
> >> On Tue, Mar 19, 2024 at 11:45 AM Randy MacLeod
> >>  wrote:
> >>
> >> Hi Haitao, et al,
> >>
> >>
> >> Summary:
> >>
> >> I think we could bring these two commits back to kirkstone even though
> >> upstream openssl mtc does not plan to do so, at least not without "very 
> >> good
> >reasons".
> >>
> >> but I have some comments and questions below that I'd like you to respond
> >to before sending a v2.
> >>
> >> ../Randy
> >>
> >>
> >>
> >> Typo in the subject:
> >>[OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen
> >> performac should be:
> >>[OE-core][kirkstone][PATCH] openssl: Improve FIPS RSA keygen
> >> performance
> >>
> >> On 2024-03-18 2:55 a.m., jason.lau via lists.openembedded.org wrote:
> >>
> >> The ssh-keygen would take a long time to generate the entropy of a key
> >>
> >> It's best to be more specific.
> >>
> >> You mentioned in:
> >>
> >> https://github.com/openssl/openssl/issues/23766
> >>
> >> that "ssh-keygen (built with openssl3.0) is taking 1-2s to execute whereas 
> >> in
> >openssl3.1 it was hardly half a second"
> >>
> >> so you should mention that in the commit log.
>
> I will add these comments into the V2 patch.
>
>
> >>
> >> You should also include a link to the upstream issue you opened to explain
> >that:
> >>
> >>"Performance fixes are in general not eligible for backports to stable 
> >> release
> >branches.
> >> In specific cases an exception could be given by OTC but there would 
> >> have
> >to be very good reasons for such an exception."
> >>
> >> I saw that comment last week and wondered if we should push harder for
> >> upstream to backport these commits but I understand your reluctance to do
> >that when it might make sense to just backport here in oe-core.
> >>
> >> Note that the commits are only part of 3.2.0+:
> >>
> >> ❯ git tag --contains dd1d7bcb69994d81662e709b0ad838880b943870
> >> openssl-3.2.0
> >> openssl-3.2.0-alpha1
> >> openssl-3.2.0-alpha2
> >> openssl-3.2.0-beta1
> >> openssl-3.2.1
> >>
> >> ❯ git tag --contains d2f6e66d2837bff1f5f7636bb2118e3a45c9df61
> >> openssl-3.2.0
> >> openssl-3.2.0-alpha1
> >> openssl-3.2.0-alpha2
> >> openssl-3.2.0-beta1
> >> openssl-3.2.1
> >>
> >> so they'd also have to be back-ported to nanbield technically:
> >>
> >> https://git.openembedded.org/openembedded-core/tree/meta/recipes-
> >conne
> >> ctivity/openssl/openssl_3.1.4.bb?h=nanbield
> >>
> >> Steve,
> >> Given that nanbield is a week or so away from EOL, is it worth doing that?
> >>
> >> I'm going to close down changes to nanbield in the next day or so, so
> >> there probably isn't time to get such a change in.
> >>
> >> And I suspect that the kirkstone v2 patch won't make it through
> >>
> >> Haitao,
> >>
> >> Steve has NOT merged this to kirkstone:
> >>
> >> https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/k
> >> irkstone-nut
> >>
> >>   https://git.openembedded.org/openembedded-core/log/?h=kirkstone
> >
> >Correct, I've been waiting for V2
> >
> >Steve
>
> I will sent the V2 Patch as soon as possible.
>
>
> >
> >> Please reply to and/or deal with my comments and send a v2.
> >>
> >> Thanks!
> >>
> >> ../Randy
> >>
> >>
> >> testing until after the nanbield final release is done, so I don't
> >> have an issue with taking it.
> >>
> >> Steve
> >>
> >> Note that the original commits were from Nov 2, 2022 so they've had
> >> some time to ummm, bake but the 3.2.0 release was 'only' on Nov 23, 2023:
> >>https://www.openssl.org/source/old/3.2/index.html
> >> so it's got 3 or 4 months of the public being able to test 

[OE-core] [kirkstone][PATCH 1/2] python3-unittest-automake-output: add new recipe for ptest integration

[Yu, Mingli]

From: Ross Burton 

This package contains modules for both unittest and pytest that alter
the output to look like automake's 'make check' output, for better
integration with ptest.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit 961e4f3fc786715fc136fa446686972a4a95a3d5)
Signed-off-by: Mingli Yu 
---
 meta/conf/distro/include/maintainers.inc|  1 +
 .../python/python3-unittest-automake-output_0.1.bb  | 13 +
 2 files changed, 14 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index bfc14951fe..09c1599915 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -684,6 +684,7 @@ RECIPE_MAINTAINER:pn-python3-toml = "Tim Orling 
"
 RECIPE_MAINTAINER:pn-python3-tomli = "Tim Orling "
 RECIPE_MAINTAINER:pn-python3-typing-extensions = "Tim Orling 
"
 RECIPE_MAINTAINER:pn-python3-typogrify = "Alexander Kanavin 
"
+RECIPE_MAINTAINER:pn-python3-unittest-automake-output = "Ross Burton 
"
 RECIPE_MAINTAINER:pn-python3-urllib3 = "Tim Orling "
 RECIPE_MAINTAINER:pn-python3-vcversioner = "Bruce Ashfield 
"
 RECIPE_MAINTAINER:pn-python3-wcwidth = "Tim Orling "
diff --git 
a/meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb 
b/meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb
new file mode 100644
index 00..ba58c18df0
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb
@@ -0,0 +1,13 @@
+SUMMARY = "Modules to make unittest and pytest look like Automake output, for 
ptest"
+HOMEPAGE = "https://gitlab.com/rossburton/python-unittest-automake-output;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=f6f16008d9fb7349f06609329f1ab93b"
+
+SRC_URI = 
"git://gitlab.com/rossburton/python-unittest-automake-output;protocol=https;branch=main"
+SRCREV = "06537edb18f3641c70bce25256f6ecf5f5164ead"
+
+S = "${WORKDIR}/git"
+
+inherit python_flit_core
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.25.1


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

[OE-core] [kirkstone][PATCH 2/2] python3-unittest-automake-output: upgrade to 0.2

[Yu, Mingli]

From: Ross Burton 

Specifically this fixes the issue where if a pytest test suite fails
during collection then the errors are hidden.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit db0e82135ce73d0d6d55b2c2ac17a3fdec8aca99)
Signed-off-by: Mingli Yu 
---
 ...ke-output_0.1.bb => python3-unittest-automake-output_0.2.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/python/{python3-unittest-automake-output_0.1.bb 
=> python3-unittest-automake-output_0.2.bb} (89%)

diff --git 
a/meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb 
b/meta/recipes-devtools/python/python3-unittest-automake-output_0.2.bb
similarity index 89%
rename from meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb
rename to meta/recipes-devtools/python/python3-unittest-automake-output_0.2.bb
index ba58c18df0..1fc6180d0e 100644
--- a/meta/recipes-devtools/python/python3-unittest-automake-output_0.1.bb
+++ b/meta/recipes-devtools/python/python3-unittest-automake-output_0.2.bb
@@ -4,7 +4,7 @@ LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=f6f16008d9fb7349f06609329f1ab93b"
 
 SRC_URI = 
"git://gitlab.com/rossburton/python-unittest-automake-output;protocol=https;branch=main"
-SRCREV = "06537edb18f3641c70bce25256f6ecf5f5164ead"
+SRCREV = "aebdfb188e368c690ea55cf6c9c9ffa1a52def65"
 
 S = "${WORKDIR}/git"
 
-- 
2.25.1


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