[oe-core][PATCH 1/5] gcr: initialize libgcrypt from the secret exchange

[oe-core][PATCH 1/5] gcr: initialize libgcrypt from the secret exchange

[Markus Volk]

gnome-shell logs a libgcrypt warning on the first keyring prompt:

    Libgcrypt warning: missing initialization - please fix the application

gcr3 initialized libgcrypt from GcrSecretExchange's class_init; gcr 4
dropped that call, and _gcr_initialize_library() is only reached from
the certificate, parser and importer paths, never from the prompt path.
The guard in that function is inverted on top of it, so even when it is
called the first caller returns without initializing anything.

The secret exchange itself works either way, but libgcrypt then runs
without the egg secure memory allocators, which puts passwords into
ordinary swappable heap instead of locked pages.

AI-Generated: Uses Claude Code
Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 ...e-libgcrypt-from-the-secret-exchange.patch | 81 +++++++++++++++++++
 meta/recipes-gnome/gcr/gcr_4.4.1.bb           |  1 +
 2 files changed, 82 insertions(+)
 create mode 100644 meta/recipes-gnome/gcr/gcr/0001-gcr-initialize-libgcrypt-from-the-secret-exchange.patch

diff --git a/meta/recipes-gnome/gcr/gcr/0001-gcr-initialize-libgcrypt-from-the-secret-exchange.patch b/meta/recipes-gnome/gcr/gcr/0001-gcr-initialize-libgcrypt-from-the-secret-exchange.patch
new file mode 100644
index 0000000000..3a55cf30aa
--- /dev/null
+++ b/meta/recipes-gnome/gcr/gcr/0001-gcr-initialize-libgcrypt-from-the-secret-exchange.patch
@@ -0,0 +1,81 @@
+From e8b729cc6ceddd22b5160f27396cf07cecd977ad Mon Sep 17 00:00:00 2001
+From: Markus Volk <f_l_k@t-online.de>
+Date: Tue, 15 Sep 2026 18:24:45 +0200
+Subject: [PATCH] gcr: initialize libgcrypt from the secret exchange
+
+gnome-shell logs this on the first keyring prompt:
+
+    gnome-shell: Libgcrypt warning: missing initialization - please fix the application
+
+gcr3 initialized libgcrypt from the class_init of GcrSecretExchange
+(gcr/gcr-secret-exchange.c:847). That call is gone in gcr 4, leaving
+only _gcr_initialize_library(), which is reached from the certificate,
+parser and importer paths but never from the prompt path.
+
+On top of that the guard in _gcr_initialize_library() is inverted, in
+gcr3 as much as in gcr 4:
+
+    static gint gcr_initialize = 0;
+    if (g_atomic_int_add (&gcr_initialize, 1) == 0)
+            return;
+
+g_atomic_int_add() returns the value from before the addition, so the
+first call returns without ever reaching egg_libgcrypt_initialize() and
+only the second one initializes anything.
+
+This is not what breaks the keyring - the secret exchange was tested
+against both gcr3 and gcr 4 and transfers the secret correctly either
+way - but libgcrypt then runs without the egg secure memory allocators,
+so passwords end up in ordinary swappable heap instead of locked pages.
+
+Fix the guard and initialize from the secret exchange again.
+
+Upstream-Status: Pending
+
+AI-Generated: Uses Claude Code (Claude Opus 5)
+---
+ gcr/gcr-library.c         | 3 ++-
+ gcr/gcr-secret-exchange.c | 9 +++++++++
+ 2 files changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/gcr/gcr-library.c b/gcr/gcr-library.c
+index 560772b..9d03f25 100644
+--- a/gcr/gcr-library.c
++++ b/gcr/gcr-library.c
+@@ -125,7 +125,8 @@ _gcr_initialize_library (void)
+ {
+ 	static gint gcr_initialize = 0;
+ 
+-	if (g_atomic_int_add (&gcr_initialize, 1) == 0)
++	/* Initialize on the first call, do nothing on every call after it */
++	if (g_atomic_int_add (&gcr_initialize, 1) != 0)
+ 		return;
+ 
+ #ifdef WITH_GCRYPT
+diff --git a/gcr/gcr-secret-exchange.c b/gcr/gcr-secret-exchange.c
+index 943b2af..3e5f889 100644
+--- a/gcr/gcr-secret-exchange.c
++++ b/gcr/gcr-secret-exchange.c
+@@ -21,6 +21,8 @@
+ 
+ #include "gcr-secret-exchange.h"
+ 
++#include "gcr-internal.h"
++
+ #include "egg/egg-crypto.h"
+ #include "egg/egg-dh.h"
+ #include "egg/egg-fips.h"
+@@ -817,6 +819,13 @@ gcr_secret_exchange_class_init (GcrSecretExchangeClass *klass)
+ 	klass->decrypt_transport_data = gcr_secret_exchange_default_decrypt_transport_data;
+ 	klass->encrypt_transport_data = gcr_secret_exchange_default_encrypt_transport_data;
+ 
++	/*
++	 * The exchange is the only part of the library that some callers ever
++	 * touch - gnome-shell through keyring.js for one - so initialize
++	 * libgcrypt here as well. gcr3 did this and gcr-4 dropped it.
++	 */
++	_gcr_initialize_library ();
++
+ 	/**
+ 	 * GcrSecretExchange:protocol:
+ 	 *
diff --git a/meta/recipes-gnome/gcr/gcr_4.4.1.bb b/meta/recipes-gnome/gcr/gcr_4.4.1.bb
index 93028d2497..aedbe60b69 100644
--- a/meta/recipes-gnome/gcr/gcr_4.4.1.bb
+++ b/meta/recipes-gnome/gcr/gcr_4.4.1.bb
@@ -17,6 +17,7 @@ inherit gnomebase gi-docgen vala gobject-introspection lib_package
 UPSTREAM_CHECK_REGEX = "gcr-(?P<pver>\d+\.\d+\.(?!9\d+)\d+(\.\d+)?)"
 
 SRC_URI[archive.sha256sum] = "c4442c15d4330f17a1f5194df08c576877af68412ab2521446a93bd5e24c931b"
+SRC_URI += "file://0001-gcr-initialize-libgcrypt-from-the-secret-exchange.patch"
 
 PACKAGECONFIG ??= "${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'vapi', '', d)}"
 PACKAGECONFIG[ssh_agent] = "-Dssh_agent=true,-Dssh_agent=false,libsecret"
-- 
2.55.0

[oe-core][PATCH 2/5] cpan: survive the Makefile that MakeMaker rebuilds under us

[Markus Volk]

ExtUtils::MakeMaker makes the generated Makefile depend on Config.pm and
config.h from the perl it was configured against. do_prepare_recipe_sysroot
stages those files fresh on every run, so their mtime can end up newer than
a Makefile written by a do_configure that is still valid. make then
regenerates the Makefile, prints "Please rerun the make command" and exits
non-zero, which fails do_compile or do_install. Run make a second time in
that case, which is what MakeMaker asks for; a run that fails for any other
reason fails again. Also drop a stale Makefile before Makefile.PL runs, so
a configure in a used work directory does not start from old settings.

Reproduced with liburi-perl by touching Config.pm and config.h in the
recipe sysroot and forcing do_install: it failed before the change and
succeeds after it.

AI-Generated: Uses Claude Code (Claude Opus 5)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 meta/classes-recipe/cpan.bbclass | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/cpan.bbclass b/meta/classes-recipe/cpan.bbclass
index dbf44da9d2..0f7384786f 100644
--- a/meta/classes-recipe/cpan.bbclass
+++ b/meta/classes-recipe/cpan.bbclass
@@ -23,6 +23,10 @@ export PERLHOSTLIB = "${STAGING_LIBDIR_NATIVE}/perl5/${@get_perl_version(d)}/"
 export PERLHOSTARCHLIB = "${STAGING_LIBDIR_NATIVE}/perl5/${@get_perl_version(d)}/${@get_perl_hostarch(d)}/"
 
 cpan_do_configure () {
+	# A Makefile left behind by an earlier configure run would be used with the
+	# settings it was generated with, so start from the Makefile.PL every time.
+	rm -f Makefile
+
 	yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor NO_PERLLOCAL=1 NO_PACKLIST=1 PERL=$(which perl) ${EXTRA_CPANFLAGS}
 
 	# Makefile.PLs can exit with success without generating a
@@ -57,12 +61,17 @@ do_configure:append:class-nativesdk() {
            -e 's:LD_RUN_PATH ?= ?"?[^"]*"?::g'
 }
 
+# ExtUtils::MakeMaker regenerates the Makefile when the staged perl has become
+# newer than it, and then exits asking for make to be rerun. Do that instead of
+# failing the task; a run that fails for any other reason fails again.
 cpan_do_compile () {
-	oe_runmake PASTHRU_INC="${CFLAGS}" LD="${CCLD}"
+	oe_runmake_call PASTHRU_INC="${CFLAGS}" LD="${CCLD}" || \
+		oe_runmake PASTHRU_INC="${CFLAGS}" LD="${CCLD}"
 }
 
 cpan_do_install () {
-	oe_runmake DESTDIR="${D}" install_vendor
+	oe_runmake_call DESTDIR="${D}" install_vendor || \
+		oe_runmake DESTDIR="${D}" install_vendor
 	for PERLSCRIPT in `grep -rIEl '#! *${bindir}/perl-native.*/perl' ${D}`; do
 		sed -i -e 's|${bindir}/perl-native.*/perl|/usr/bin/env nativeperl|' $PERLSCRIPT
 	done
-- 
2.55.0

Re: [oe-core][PATCH 2/5] cpan: survive the Makefile that MakeMaker rebuilds under us

[Paul Barker]

On Tue, 2026-09-22 at 11:23 +0200, Markus Volk wrote:
> ExtUtils::MakeMaker makes the generated Makefile depend on Config.pm and
> config.h from the perl it was configured against. do_prepare_recipe_sysroot
> stages those files fresh on every run, so their mtime can end up newer than
> a Makefile written by a do_configure that is still valid. make then
> regenerates the Makefile, prints "Please rerun the make command" and exits
> non-zero, which fails do_compile or do_install. Run make a second time in
> that case, which is what MakeMaker asks for; a run that fails for any other
> reason fails again. Also drop a stale Makefile before Makefile.PL runs, so
> a configure in a used work directory does not start from old settings.
> 
> Reproduced with liburi-perl by touching Config.pm and config.h in the
> recipe sysroot and forcing do_install: it failed before the change and
> succeeds after it.
> 
> AI-Generated: Uses Claude Code (Claude Opus 5)
> Signed-off-by: Markus Volk <f_l_k@t-online.de>

Hi Markus,

The commit summary here is an excellent example of Claudish. I'm not
really sure what it means... It could do with re-writing.

> ---
>  meta/classes-recipe/cpan.bbclass | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes-recipe/cpan.bbclass b/meta/classes-recipe/cpan.bbclass
> index dbf44da9d2..0f7384786f 100644
> --- a/meta/classes-recipe/cpan.bbclass
> +++ b/meta/classes-recipe/cpan.bbclass
> @@ -23,6 +23,10 @@ export PERLHOSTLIB = "${STAGING_LIBDIR_NATIVE}/perl5/${@get_perl_version(d)}/"
>  export PERLHOSTARCHLIB = "${STAGING_LIBDIR_NATIVE}/perl5/${@get_perl_version(d)}/${@get_perl_hostarch(d)}/"
>  
>  cpan_do_configure () {
> +	# A Makefile left behind by an earlier configure run would be used with the
> +	# settings it was generated with, so start from the Makefile.PL every time.
> +	rm -f Makefile

I'm not really familiar with cpan packages - are we sure that none
include a Makefile?

> +
>  	yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor NO_PERLLOCAL=1 NO_PACKLIST=1 PERL=$(which perl) ${EXTRA_CPANFLAGS}
>  
>  	# Makefile.PLs can exit with success without generating a
> @@ -57,12 +61,17 @@ do_configure:append:class-nativesdk() {
>             -e 's:LD_RUN_PATH ?= ?"?[^"]*"?::g'
>  }
>  
> +# ExtUtils::MakeMaker regenerates the Makefile when the staged perl has become
> +# newer than it, and then exits asking for make to be rerun. Do that instead of
> +# failing the task; a run that fails for any other reason fails again.
>  cpan_do_compile () {
> -	oe_runmake PASTHRU_INC="${CFLAGS}" LD="${CCLD}"
> +	oe_runmake_call PASTHRU_INC="${CFLAGS}" LD="${CCLD}" || \
> +		oe_runmake PASTHRU_INC="${CFLAGS}" LD="${CCLD}"

Are we sure this won't mask other issues? The staged perl becoming newer
than the generated Makefile should be a rare occurance, perhaps we can
check for that before calling make and handle it explicitly?

>  }
>  
>  cpan_do_install () {
> -	oe_runmake DESTDIR="${D}" install_vendor
> +	oe_runmake_call DESTDIR="${D}" install_vendor || \
> +		oe_runmake DESTDIR="${D}" install_vendor

We don't want surprise rebuilds during do_install.

>  	for PERLSCRIPT in `grep -rIEl '#! *${bindir}/perl-native.*/perl' ${D}`; do
>  		sed -i -e 's|${bindir}/perl-native.*/perl|/usr/bin/env nativeperl|' $PERLSCRIPT
>  	done

Best regards,

-- 
Paul Barker

Re: [oe-core][PATCH 2/5] cpan: survive the Makefile that MakeMaker rebuilds under us

[Markus Volk]

[-- Attachment #1: Type: text/plain, Size: 5124 bytes --]

Hi Paul,


> 
> The commit summary here is an excellent example of Claudish. I'm not
> really sure what it means... It could do with re-writing.

Thats true. I think I only could follow it because I knew which real 
issue this fixes for me.
The problem is, that I'm following more or less regulary the current 
master branch of
oe-core and whenever there have been changes to perl the following 
build breaks a few
perl recipes. that then required a '-c cleansstate' to become buildable 
again.

> I'm not really familiar with cpan packages - are we sure that none
> include a Makefile?

I wasn't sure about this either, but since ā€œdo_configureā€ generates 
a new Makefile, I left it in. However,
that isn't necessary to fix the actual problem.

> 
> We don't want surprise rebuilds during do_install.

I'll send a v2 that just ignores the different timestamp

On Sat, Sep 26 2026 at 15:05:24 +01:00:00, Paul Barker 
<paul@pbarker.dev> wrote:
> On Tue, 2026-09-22 at 11:23 +0200, Markus Volk wrote:
>>  ExtUtils::MakeMaker makes the generated Makefile depend on 
>> Config.pm and
>>  config.h from the perl it was configured against. 
>> do_prepare_recipe_sysroot
>>  stages those files fresh on every run, so their mtime can end up 
>> newer than
>>  a Makefile written by a do_configure that is still valid. make then
>>  regenerates the Makefile, prints "Please rerun the make command" 
>> and exits
>>  non-zero, which fails do_compile or do_install. Run make a second 
>> time in
>>  that case, which is what MakeMaker asks for; a run that fails for 
>> any other
>>  reason fails again. Also drop a stale Makefile before Makefile.PL 
>> runs, so
>>  a configure in a used work directory does not start from old 
>> settings.
>> 
>>  Reproduced with liburi-perl by touching Config.pm and config.h in 
>> the
>>  recipe sysroot and forcing do_install: it failed before the change 
>> and
>>  succeeds after it.
>> 
>>  AI-Generated: Uses Claude Code (Claude Opus 5)
>>  Signed-off-by: Markus Volk <f_l_k@t-online.de 
>> <mailto:f_l_k@t-online.de>>
> 
> Hi Markus,
> 
> The commit summary here is an excellent example of Claudish. I'm not
> really sure what it means... It could do with re-writing.
> 
>>  ---
>>   meta/classes-recipe/cpan.bbclass | 13 +++++++++++--
>>   1 file changed, 11 insertions(+), 2 deletions(-)
>> 
>>  diff --git a/meta/classes-recipe/cpan.bbclass 
>> b/meta/classes-recipe/cpan.bbclass
>>  index dbf44da9d2..0f7384786f 100644
>>  --- a/meta/classes-recipe/cpan.bbclass
>>  +++ b/meta/classes-recipe/cpan.bbclass
>>  @@ -23,6 +23,10 @@ export PERLHOSTLIB = 
>> "${STAGING_LIBDIR_NATIVE}/perl5/${@get_perl_version(d)}/"
>>   export PERLHOSTARCHLIB = 
>> "${STAGING_LIBDIR_NATIVE}/perl5/${@get_perl_version(d)}/${@get_perl_hostarch(d)}/"
>> 
>>   cpan_do_configure () {
>>  +	# A Makefile left behind by an earlier configure run would be 
>> used with the
>>  +	# settings it was generated with, so start from the Makefile.PL 
>> every time.
>>  +	rm -f Makefile
> 
> I'm not really familiar with cpan packages - are we sure that none
> include a Makefile?
> 
>>  +
>>   	yes '' | perl ${EXTRA_PERLFLAGS} Makefile.PL INSTALLDIRS=vendor 
>> NO_PERLLOCAL=1 NO_PACKLIST=1 PERL=$(which perl) ${EXTRA_CPANFLAGS}
>> 
>>   	# Makefile.PLs can exit with success without generating a
>>  @@ -57,12 +61,17 @@ do_configure:append:class-nativesdk() {
>>              -e 's:LD_RUN_PATH ?= ?"?[^"]*"?::g'
>>   }
>> 
>>  +# ExtUtils::MakeMaker regenerates the Makefile when the staged 
>> perl has become
>>  +# newer than it, and then exits asking for make to be rerun. Do 
>> that instead of
>>  +# failing the task; a run that fails for any other reason fails 
>> again.
>>   cpan_do_compile () {
>>  -	oe_runmake PASTHRU_INC="${CFLAGS}" LD="${CCLD}"
>>  +	oe_runmake_call PASTHRU_INC="${CFLAGS}" LD="${CCLD}" || \
>>  +		oe_runmake PASTHRU_INC="${CFLAGS}" LD="${CCLD}"
> 
> Are we sure this won't mask other issues? The staged perl becoming 
> newer
> than the generated Makefile should be a rare occurance, perhaps we can
> check for that before calling make and handle it explicitly?
> 
>>   }
>> 
>>   cpan_do_install () {
>>  -	oe_runmake DESTDIR="${D}" install_vendor
>>  +	oe_runmake_call DESTDIR="${D}" install_vendor || \
>>  +		oe_runmake DESTDIR="${D}" install_vendor
> 
> We don't want surprise rebuilds during do_install.
> 
>>   	for PERLSCRIPT in `grep -rIEl '#! *${bindir}/perl-native.*/perl' 
>> ${D}`; do
>>   		sed -i -e 's|${bindir}/perl-native.*/perl|/usr/bin/env 
>> nativeperl|' $PERLSCRIPT
>>   	done
> 
> Best regards,
> 
> --
> Paul Barker
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#246637): 
> <https://lists.openembedded.org/g/openembedded-core/message/246637>
> Mute This Topic: <https://lists.openembedded.org/mt/121371712/3618223>
> Group Owner: openembedded-core+owner@lists.openembedded.org 
> <mailto:openembedded-core+owner@lists.openembedded.org>
> Unsubscribe: 
> <https://lists.openembedded.org/g/openembedded-core/unsub> 
> [f_l_k@t-online.de <mailto:f_l_k@t-online.de>]
> -=-=-=-=-=-=-=-=-=-=-=-
> 


[-- Attachment #2: Type: text/html, Size: 6552 bytes --]

[oe-core][PATCH 3/5] spdx_license: give UnknownId a name

[Markus Volk]

A LICENSE that contains an unknown identifier, as go-mod-update-modules
writes it for modules whose license it could not classify, made
do_populate_lic fail with an AttributeError in get_license_path instead
of the license-exists QA error. Give UnknownId the same name property
as LicenseId and ExceptionId so the lookup can fail gracefully.

AI-Generated: Uses Claude Code (Claude Fable 5.1)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 meta/lib/oe/spdx_license.py | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/lib/oe/spdx_license.py b/meta/lib/oe/spdx_license.py
index 1e201f21d5..7369eca9ef 100644
--- a/meta/lib/oe/spdx_license.py
+++ b/meta/lib/oe/spdx_license.py
@@ -240,6 +240,10 @@ class Identifier(Node):
 
 
 class UnknownId(Identifier):
+    @property
+    def name(self):
+        return self.ident
+
     @classmethod
     def reduce(cls, stack, lookahead):
         if not check_stack_types(stack, [Token]):
-- 
2.55.0

[oe-core][PATCH 4/5] license_finder: normalise license texts before hashing

[Markus Volk]

Matching by the md5 of a lightly crunched text missed most of the
common BSD, MIT, ISC, MPL-2.0 and Apache-2.0 copies in a Go module
tree: list markers, punctuation, case, the copyright holder's name in
the BSD advertising clause, the party in the ISC disclaimer and the
Apache-2.0 appendix all changed the hash. Compare the lower-cased word
stream instead, strip those variable parts, and only treat a line as a
license title at the top of the file. For rclone's 256 module license
files this brings the unrecognised ones down from 57 to 25, the rest
are dual-license files or texts with additions. The canonical licenses
are hashed in sorted order and the first name wins so that formatting
twins map to a stable name.

license-hashes.csv also holds hashes of texts crunched the old way, for
example the short Apache-2.0 boilerplate notice, so the old algorithm
stays as a third lookup step and none of the existing entries is lost.

AI-Generated: Uses Claude Code (Claude Fable 5.1)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 meta/lib/oe/license_finder.py | 61 +++++++++++++++++++++++++++++------
 1 file changed, 51 insertions(+), 10 deletions(-)

diff --git a/meta/lib/oe/license_finder.py b/meta/lib/oe/license_finder.py
index 9c217cf891..b500f3a599 100644
--- a/meta/lib/oe/license_finder.py
+++ b/meta/lib/oe/license_finder.py
@@ -46,40 +46,52 @@ def _crunch_known_licenses(d):
 
     lic_dirs = [d.getVar('COMMON_LICENSE_DIR')] + (d.getVar('LICENSE_PATH') or "").split()
     for lic_dir in lic_dirs:
-        for fn in os.listdir(lic_dir):
+        for fn in sorted(os.listdir(lic_dir)):
             path = os.path.join(lic_dir, fn)
             if not os.path.isfile(path):
                 continue
             # Hash the exact contents
             md5value = bb.utils.md5_file(path)
-            md5sums[md5value] = fn
-            # Also hash a "crunched" version
+            md5sums.setdefault(md5value, fn)
+            # Also hash a "crunched" version. Some licenses only differ
+            # in formatting, the first name in sort order wins for those.
             md5value = _crunch_license(path)
-            md5sums[md5value] = fn
+            md5sums.setdefault(md5value, fn)
 
     return md5sums
 
 
-def _crunch_license(licfile):
+def _crunch_license(licfile, legacy=False):
     '''
     Remove non-material text from a license file and then calculate its
     md5sum. This works well for licenses that contain a copyright statement,
     but is also a useful way to handle people's insistence upon reformatting
     the license text slightly (with no material difference to the text of the
     license).
+
+    With legacy set, the text is crunched the way it was before the word
+    stream normalisation, which is what the hashes in license-hashes.csv
+    were made with.
     '''
 
     import oe.utils
 
     # Note: these are carefully constructed!
-    license_title_re = re.compile(r'^#*\(? *(This is )?([Tt]he )?.{0,15} ?[Ll]icen[sc]e( \(.{1,10}\))?\)?[:\.]? ?#*$')
+    if legacy:
+        license_title_re = re.compile(r'^#*\(? *(This is )?([Tt]he )?.{0,15} ?[Ll]icen[sc]e( \(.{1,10}\))?\)?[:\.]? ?#*$')
+    else:
+        license_title_re = re.compile(r'^#*\(? *(This is )?([Tt]he )?([A-Z0-9].{0,14})? ?[Ll]icen[sc]e( \(.{1,10}\))?\)?[:\.]? ?#*$')
     license_statement_re = re.compile(r'^((This (project|software)|.{1,10}) is( free software)? (released|licen[sc]ed)|(Released|Licen[cs]ed)) under the .{1,10} [Ll]icen[sc]e:?$')
     copyright_re = re.compile(r'^ *[#\*]* *(Modified work |MIT LICENSED )?Copyright ?(\([cC]\))? .*$')
     disclaimer_re = re.compile(r'^ *\*? ?All [Rr]ights [Rr]eserved\.$')
     email_re = re.compile(r'^.*<[\w\.-]*@[\w\.\-]*>$')
     header_re = re.compile(r'^(\/\**!?)? ?[\-=\*]* ?(\*\/)?$')
     tag_re = re.compile(r'^ *@?\(?([Ll]icense|MIT)\)?$')
-    url_re = re.compile(r'^ *[#\*]* *https?:\/\/[\w\.\/\-]+$')
+    if legacy:
+        url_re = re.compile(r'^ *[#\*]* *https?:\/\/[\w\.\/\-]+$')
+    else:
+        url_re = re.compile(r'^ *[#\*]* *https?:\/\/[\w\.\/\-]+\.?$')
+    list_marker_re = re.compile(r'^(\(?[0-9a-zA-Z]{1,2}[\.\)]|[\*\-•o]) +')
 
     lictext = []
     with open(licfile, 'r', errors='surrogateescape') as f:
@@ -97,9 +109,11 @@ def _crunch_license(licfile):
                 continue
             elif url_re.match(line):
                 continue
-            elif license_title_re.match(line):
+            # Titles and statements are only dropped at the top of the
+            # file, further down they are wrapped sentences of the text
+            elif (legacy or len(lictext) < 3) and license_title_re.match(line):
                 continue
-            elif license_statement_re.match(line):
+            elif (legacy or len(lictext) < 3) and license_statement_re.match(line):
                 continue
             # Strip comment symbols
             line = line.replace('*', '') \
@@ -108,6 +122,9 @@ def _crunch_license(licfile):
             line = line.replace('sub-license', 'sublicense')
             # Squash spaces
             line = oe.utils.squashspaces(line.strip())
+            # Drop list markers, "1." and "*" are used interchangeably
+            if not legacy:
+                line = list_marker_re.sub('', line)
             # Replace smart quotes, double quotes and backticks with single quotes
             line = line.replace(u"\u2018", "'").replace(u"\u2019", "'").replace(u"\u201c","'").replace(u"\u201d", "'").replace('"', '\'').replace('`', '\'')
             # Unify brackets
@@ -115,9 +132,30 @@ def _crunch_license(licfile):
             if line:
                 lictext.append(line)
 
+    text = ' '.join(lictext)
+    if legacy:
+        return hashlib.md5(text.encode('utf-8', errors='ignore')).hexdigest()
+
+    # Only the words matter, not case or punctuation
+    text = text.lower()
+    text = text.replace('and/or', 'and')
+    text = re.sub(r'https?://\S+', ' ', text)
+    text = re.sub(r'[^a-z0-9]+', ' ', text).strip()
+    # The Apache-2.0 appendix is instructions, not license terms, and
+    # the end marker is often left out
+    text = re.sub(r' appendix how to apply the apache license to your work.*? limitations under the license', '', text)
+    text = text.replace(' end of terms and conditions', '')
+    # Names of copyright holders in the BSD advertising clause and the
+    # ISC disclaimer, and the extra paragraph reference in X11-style MIT
+    text = re.sub(r'neither the name of .*? nor the names of', 'neither the name of nor the names of', text)
+    text = text.replace('copyright owner', 'copyright holder')
+    text = re.sub(r'\b(the authors?|isc|the copyright holders?) disclaims?\b', 'the author disclaims', text)
+    text = re.sub(r'shall (the authors?|isc|the copyright holders?) be liable', 'shall the author be liable', text)
+    text = text.replace('permission notice including the next paragraph shall', 'permission notice shall')
+
     m = hashlib.md5()
     try:
-        m.update(' '.join(lictext).encode('utf-8'))
+        m.update(text.encode('utf-8'))
         md5val = m.hexdigest()
     except UnicodeEncodeError:
         md5val = None
@@ -183,6 +221,9 @@ def match_licenses(licfiles, srctree, d, extra_hashes={}):
         if not license:
             crunched_md5 = _crunch_license(resolved_licfile)
             license = md5sums.get(crunched_md5, None)
+        if not license:
+            crunched_md5 = _crunch_license(resolved_licfile, legacy=True)
+            license = md5sums.get(crunched_md5, None)
             if not license:
                 rel_fn = os.path.relpath(licfile, srctree + "/..")
                 license = oe.spdx_license.UnknownId("Unknown")
-- 
2.55.0

[oe-core][PATCH 5/5] go-mod-update-modules: include the generated files from the class

[Markus Volk]

A new recipe could not be parsed before its first update_modules run
because it had to require the two generated files itself. Include them
from the class instead, relative to the recipe, so a missing file is
tolerated until the task has written it.

AI-Generated: Uses Claude Code (Claude Fable 5.1)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
---
 meta/classes-recipe/go-mod-update-modules.bbclass | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/go-mod-update-modules.bbclass b/meta/classes-recipe/go-mod-update-modules.bbclass
index 3a0f0a3377..bae9e47c0d 100644
--- a/meta/classes-recipe/go-mod-update-modules.bbclass
+++ b/meta/classes-recipe/go-mod-update-modules.bbclass
@@ -10,7 +10,12 @@ do_update_modules[network] = "1"
 # -licenses.inc will append LICENSE and LIC_FILES_CHKSUM with the found licenses
 # in the modules.
 #
-# These files are machine-generated and should not be modified.
+# These files are machine-generated and should not be modified. They are
+# included here so that a new recipe parses before they have been generated
+# by the first run of the update-modules task.
+
+include ${FILE_DIRNAME}/${BPN}-licenses.inc
+include ${FILE_DIRNAME}/${BPN}-go-mods.inc
 
 python do_update_modules() {
     import subprocess, tempfile, json, re, urllib.parse
-- 
2.55.0

Re: [oe-core][PATCH 5/5] go-mod-update-modules: include the generated files from the class

[Antonin Godard]

Hi,

On Tue Sep 22, 2026 at 11:23 AM CEST, Markus Volk via lists.openembedded.org wrote:
> A new recipe could not be parsed before its first update_modules run
> because it had to require the two generated files itself. Include them
> from the class instead, relative to the recipe, so a missing file is
> tolerated until the task has written it.

This has the following side-effect for recipes already including the file(s):

stdio: WARNING: /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb: Duplicate inclusion for /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale-go-mods.inc in /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb
stdio: WARNING: /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb: Duplicate inclusion for /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale-licenses.inc in /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb
stdio: WARNING: /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/simpleiot_0.18.5.bb: Duplicate inclusion for /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/simpleiot-go-mods.inc in /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/simpleiot_0.18.5.bb
stdio: WARNING: /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible_2025.05.28.bb: Duplicate inclusion for /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible-go-mods.inc in /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible_2025.05.28.bb
stdio: WARNING: /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible_2025.05.28.bb: Duplicate inclusion for /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible-licenses.inc in /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible_2025.05.28.bb

https://autobuilder.yoctoproject.org/valkyrie/#/builders/89/builds/4515

If this is merged we'll need to adjust these recipes. Also if this is merged
please send an update to
https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-guides/migration-6.1.rst
on the documentation mailing list to let people know why this is happening in
their build.

Thanks,
Antonin

Re: [oe-core][PATCH 5/5] go-mod-update-modules: include the generated files from the class

[mrksvolk]

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]

Sure. Just tell me, if and when you want the patch.

On Tue, Sep 22 2026 at 16:14:03 +02:00:00, Antonin Godard via 
lists.openembedded.org 
<antonin.godard=bootlin.com@lists.openembedded.org> wrote:
> Hi,
> 
> On Tue Sep 22, 2026 at 11:23 AM CEST, Markus Volk via 
> lists.openembedded.org wrote:
>>  A new recipe could not be parsed before its first update_modules run
>>  because it had to require the two generated files itself. Include 
>> them
>>  from the class instead, relative to the recipe, so a missing file is
>>  tolerated until the task has written it.
> 
> This has the following side-effect for recipes already including the 
> file(s):
> 
> stdio: WARNING: 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb: 
> Duplicate inclusion for 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale-go-mods.inc 
> in 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb
> stdio: WARNING: 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb: 
> Duplicate inclusion for 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale-licenses.inc 
> in 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb
> stdio: WARNING: 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/simpleiot_0.18.5.bb: 
> Duplicate inclusion for 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/simpleiot-go-mods.inc 
> in 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/simpleiot_0.18.5.bb
> stdio: WARNING: 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible_2025.05.28.bb: 
> Duplicate inclusion for 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible-go-mods.inc 
> in 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible_2025.05.28.bb
> stdio: WARNING: 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible_2025.05.28.bb: 
> Duplicate inclusion for 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible-licenses.inc 
> in 
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible_2025.05.28.bb
> 
> <https://autobuilder.yoctoproject.org/valkyrie/#/builders/89/builds/4515>
> 
> If this is merged we'll need to adjust these recipes. Also if this is 
> merged
> please send an update to
> <https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-guides/migration-6.1.rst>
> on the documentation mailing list to let people know why this is 
> happening in
> their build.
> 
> Thanks,
> Antonin
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 3548 bytes --]

Re: [oe-core][PATCH 5/5] go-mod-update-modules: include the generated files from the class

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 4004 bytes --]

also in meta-openembedded

meta-networking/recipes-connectivity/tailscale/tailscale_1.102.3.bb
meta-oe/recipes-dbs/influxdb/influxdb_1.8.10.bb
meta-oe/recipes-extended/simpleiot/simpleiot_0.18.5.bb
meta-oe/recipes-support/crucible/crucible_2025.05.28.bb
meta-oe/recipes-support/rclone/rclone_1.75.1.bb
meta-oe/recipes-test/syzkaller/syzkaller_git.bb

On Tue, Sep 22, 2026 at 7:14 AM Antonin Godard via lists.openembedded.org
<antonin.godard=bootlin.com@lists.openembedded.org> wrote:

> Hi,
>
> On Tue Sep 22, 2026 at 11:23 AM CEST, Markus Volk via
> lists.openembedded.org wrote:
> > A new recipe could not be parsed before its first update_modules run
> > because it had to require the two generated files itself. Include them
> > from the class instead, relative to the recipe, so a missing file is
> > tolerated until the task has written it.
>
> This has the following side-effect for recipes already including the
> file(s):
>
> stdio: WARNING:
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/
> tailscale_1.102.3.bb: Duplicate inclusion for
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale-go-mods.inc
> in
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/
> tailscale_1.102.3.bb
> stdio: WARNING:
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/
> tailscale_1.102.3.bb: Duplicate inclusion for
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/tailscale-licenses.inc
> in
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-networking/recipes-connectivity/tailscale/
> tailscale_1.102.3.bb
> stdio: WARNING:
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/
> simpleiot_0.18.5.bb: Duplicate inclusion for
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/simpleiot-go-mods.inc
> in
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-extended/simpleiot/
> simpleiot_0.18.5.bb
> stdio: WARNING:
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/
> crucible_2025.05.28.bb: Duplicate inclusion for
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible-go-mods.inc
> in
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/
> crucible_2025.05.28.bb
> stdio: WARNING:
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/
> crucible_2025.05.28.bb: Duplicate inclusion for
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/crucible-licenses.inc
> in
> /srv/pokybuild/yocto-worker/meta-virt/build/meta-openembedded/meta-oe/recipes-support/crucible/
> crucible_2025.05.28.bb
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/89/builds/4515
>
> If this is merged we'll need to adjust these recipes. Also if this is
> merged
> please send an update to
>
> https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-guides/migration-6.1.rst
> on the documentation mailing list to let people know why this is happening
> in
> their build.
>
> Thanks,
> Antonin
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#246416):
> https://lists.openembedded.org/g/openembedded-core/message/246416
> Mute This Topic: https://lists.openembedded.org/mt/121371714/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 6154 bytes --]

Re: [oe-core][PATCH 5/5] go-mod-update-modules: include the generated files from the class

[Ross Burton]

On 22 Sep 2026, at 10:23, Markus Volk via lists.openembedded.org <f_l_k=t-online.de@lists.openembedded.org> wrote:
> A new recipe could not be parsed before its first update_modules run
> because it had to require the two generated files itself. Include them
> from the class instead, relative to the recipe, so a missing file is
> tolerated until the task has written it.

Where is this new recipe coming from?  recipetool should be creating the files when it writes the recipe file so it can’t be there.  If you’re hand-coding the recipe then you can touch the files when you write require, or just include in the recipe.

Ross

Re: [oe-core][PATCH 5/5] go-mod-update-modules: include the generated files from the class

[Markus Volk]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

On Fri, Sep 25 2026 at 11:18:39 +00:00:00, Ross Burton 
<Ross.Burton@arm.com> wrote:
> Where is this new recipe coming from?  recipetool should be creating 
> the files when it writes the recipe file so it canā€™t be there.  If 
> youā€™re hand-coding the recipe then you can touch the files when you 
> write require, or just include in the recipe.

Hi Ross,

the recipe was hand-coded and I wasn't aware that recipetool creates 
the files. You definitely got a point here


[-- Attachment #2: Type: text/html, Size: 658 bytes --]

Patchtest results for [oe-core][PATCH 1/5] gcr: initialize libgcrypt from the secret exchange

[patchtest]

[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]

Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:

---
Testing patch /home/patchtest/share/mboxes/1-5-gcr-initialize-libgcrypt-from-the-secret-exchange.patch

FAIL: test Signed-off-by presence: A patch file has been added without a Signed-off-by tag: '0001-gcr-initialize-libgcrypt-from-the-secret-exchange.patch' (test_patch.TestPatch.test_signed_off_by_presence)

PASS: pretest src uri left files (test_metadata.TestMetadata.pretest_src_uri_left_files)
PASS: test CVE check ignore (test_metadata.TestMetadata.test_cve_check_ignore)
PASS: test CVE tag format (test_patch.TestPatch.test_cve_tag_format)
PASS: test Signed-off-by presence (test_mbox.TestMbox.test_signed_off_by_presence)
PASS: test Upstream-Status presence (test_patch.TestPatch.test_upstream_status_presence_format)
PASS: test auh changelog truncation notice (test_mbox.TestMbox.test_auh_changelog_truncation_notice)
PASS: test author valid (test_mbox.TestMbox.test_author_valid)
PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence)
PASS: test commit message user tags (test_mbox.TestMbox.test_commit_message_user_tags)
PASS: test lic files chksum modified not mentioned (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned)
PASS: test max line length (test_metadata.TestMetadata.test_max_line_length)
PASS: test mbox format (test_mbox.TestMbox.test_mbox_format)
PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade)
PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format)
PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length)
PASS: test src uri left files (test_metadata.TestMetadata.test_src_uri_left_files)
PASS: test target mailing list (test_mbox.TestMbox.test_target_mailing_list)

SKIP: pretest pylint: No python related patches, skipping test (test_python_pylint.PyLint.pretest_pylint)
SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format)
SKIP: test lic files chksum presence: No added recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_presence)
SKIP: test license presence: No added recipes, skipping test (test_metadata.TestMetadata.test_license_presence)
SKIP: test pylint: No python related patches, skipping test (test_python_pylint.PyLint.test_pylint)
SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head)
SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence)

---

Please address the issues identified and
submit a new revision of the patch, or alternatively, reply to this
email with an explanation of why the patch should be accepted. If you
believe these results are due to an error in patchtest, please submit a
bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category
under 'Yocto Project Subprojects'). For more information on specific
failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank
you!

Re: [oe-core][PATCH 1/5] gcr: initialize libgcrypt from the secret exchange

[Paul Barker]

On Tue, 2026-09-22 at 11:23 +0200, Markus Volk wrote:
> gnome-shell logs a libgcrypt warning on the first keyring prompt:
> 
>     Libgcrypt warning: missing initialization - please fix the application
> 
> gcr3 initialized libgcrypt from GcrSecretExchange's class_init; gcr 4
> dropped that call, and _gcr_initialize_library() is only reached from
> the certificate, parser and importer paths, never from the prompt path.
> The guard in that function is inverted on top of it, so even when it is
> called the first caller returns without initializing anything.
> 
> The secret exchange itself works either way, but libgcrypt then runs
> without the egg secure memory allocators, which puts passwords into
> ordinary swappable heap instead of locked pages.
> 
> AI-Generated: Uses Claude Code
> Signed-off-by: Markus Volk <f_l_k@t-online.de>

Hi Marcus,

Has this issue been reported upstream? I see that the patch is
'Pending', which isn't ideal. Given that this affects security we really
should get input from upstream.

Best regards,

-- 
Paul Barker