[OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

We want the ability to do stable version upgrades for recipes.
To this end, add an optional stable_upgrade parameter to the
get_recipe_upgrade_status function, which defaults to False and
when enabled will try to get the latest stable version of the recipe.

The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets
it, it will be used as the filter_regex. If it's not set explicitly,
it means that there's no stable updates or the recipe hasn't been
checked yet.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/lib/oe/recipeutils.py | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index c6604f536d..7c1df518a8 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -1009,7 +1009,7 @@ def get_recipe_pv_with_pfx_sfx(pv, uri_type):
 
     return (pv, pfx, sfx)
 
-def get_recipe_upstream_version(rd):
+def get_recipe_upstream_version(rd, stable_upgrade):
     """
         Get upstream version of recipe using bb.fetch2 methods with support for
         http, https, ftp and git.
@@ -1080,7 +1080,15 @@ def get_recipe_upstream_version(rd):
             except bb.fetch2.FetchError as e:
                 bb.warn("Unable to obtain latest revision: {}".format(e))
         else:
-            pupver = ud.method.latest_versionstring(ud, rd)
+            if stable_upgrade:
+                stable_release_regex = rd.getVar("UPSTREAM_STABLE_RELEASE_REGEX")
+                if stable_release_regex:
+                    pupver = ud.method.latest_versionstring(ud, rd, filter_regex=stable_release_regex)
+                else:
+                    # Not explicitly setting "UPSTREAM_STABLE_RELEASE_REGEX" means there's no stable upgrade
+                    pupver = (ru['current_version'], None)
+            else:
+                pupver = ud.method.latest_versionstring(ud, rd)
             (upversion, revision) = pupver
 
         if upversion:
@@ -1094,8 +1102,8 @@ def get_recipe_upstream_version(rd):
 
     return ru
 
-def _get_recipe_upgrade_status(data):
-    uv = get_recipe_upstream_version(data)
+def _get_recipe_upgrade_status(data, stable_upgrade):
+    uv = get_recipe_upstream_version(data, stable_upgrade)
 
     pn = data.getVar('PN')
     cur_ver = uv['current_version']
@@ -1119,9 +1127,10 @@ def _get_recipe_upgrade_status(data):
 
     return {'pn':pn, 'status':status, 'cur_ver':cur_ver, 'next_ver':next_ver, 'maintainer':maintainer, 'revision':revision, 'no_upgrade_reason':no_upgrade_reason}
 
-def get_recipe_upgrade_status(recipes=None):
+def get_recipe_upgrade_status(recipes=None, stable_upgrade=False):
     pkgs_list = []
     data_copy_list = []
+    stable_copy_list = []
     copy_vars = ('SRC_URI',
                  'PV',
                  'DL_DIR',
@@ -1134,6 +1143,7 @@ def get_recipe_upgrade_status(recipes=None):
                  'UPSTREAM_CHECK_REGEX',
                  'UPSTREAM_CHECK_URI',
                  'UPSTREAM_VERSION_UNKNOWN',
+                 'UPSTREAM_STABLE_RELEASE_REGEX',
                  'RECIPE_MAINTAINER',
                  'RECIPE_NO_UPDATE_REASON',
                  'RECIPE_UPSTREAM_VERSION',
@@ -1180,12 +1190,13 @@ def get_recipe_upgrade_status(recipes=None):
                     data_copy.setVar(k, data.getVar(k))
 
             data_copy_list.append(data_copy)
+            stable_copy_list.append(stable_upgrade)
 
             recipeincludes[data.getVar('FILE')] = {'bbincluded':data.getVar('BBINCLUDED').split(),'pn':data.getVar('PN')}
 
     from concurrent.futures import ProcessPoolExecutor
     with ProcessPoolExecutor(max_workers=utils.cpu_count()) as executor:
-        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list)
+        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list, stable_copy_list)
 
     return _group_recipes(pkgs_list, _get_common_include_recipes(recipeincludes))
 
-- 
2.34.1

[OE-core][PATCH V5 2/7] upstream-stable-release-point.bbclass: add bbclass for stable point upgrade

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

If a recipe can do stable version upgrade and the stable parts of the version
is seperated by '.', then it can inherit this bbclass.

By default, the stable parts number is 2, which means the following upgrades
are stable version upgrades:
x.y.z -> x.y.z+1
x.y.z+1 -> x.y.z+1.zz
x.y.z+1.zz -> x.y.z+2

Recipes that have different stable version parts can also inherit this bbclass
and set STABLE_VERSION_PARTS. For example, systemd sets this variable to "1".

For recipes whose stable version part is not separated by '.', they should not
inherit this bbclass and intead set UPSTREAM_STABLE_RELEASE_REGEX themselves.
For example, openssh's stable part is separted by 'p' and should not inherit
this bbclass.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 .../upstream-stable-release-point.bbclass     | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 meta/classes-recipe/upstream-stable-release-point.bbclass

diff --git a/meta/classes-recipe/upstream-stable-release-point.bbclass b/meta/classes-recipe/upstream-stable-release-point.bbclass
new file mode 100644
index 0000000000..13040e541b
--- /dev/null
+++ b/meta/classes-recipe/upstream-stable-release-point.bbclass
@@ -0,0 +1,21 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+#
+# This bbclass is expected to be inherited by recipes explicitly.
+# If a recipe's version is separated by point and we know for sure
+# which parts of the version represent the stable part, then the
+# recipe could inherit this bbclass.
+#
+
+STABLE_VERSION_PARTS ?= "2"
+def get_majmin_version_regex(d):
+    pv = d.getVar('PV')
+    stable_parts = pv.split('.')[:int(d.getVar('STABLE_VERSION_PARTS'))]
+    return '\.'.join(stable_parts)
+
+STABLE_VERSION_REGEX = "${@get_majmin_version_regex(d)}"
+UPSTREAM_STABLE_RELEASE_REGEX ?= "^${STABLE_VERSION_REGEX}(\.\d+)*$"
-- 
2.34.1

[OE-core][PATCH V5 3/7] vte: inherit upstream-stable-release-point

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

The last version part bump for vte is a stable upgrade.

* Evidence

  Its repo[1] has remote branches like:
    origin/vte-0-76
    origin/vte-0-78
    origin/vte-0-80
    origin/vte-0-82
    origin/vte-0-84

So for example, 0.82.2 -> 0.82.3 is a stable upgrade.

[1] https://gitlab.gnome.org/GNOME/vte.git

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/recipes-support/vte/vte_0.82.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/vte/vte_0.82.2.bb b/meta/recipes-support/vte/vte_0.82.2.bb
index d5dced4ce6..839475f32c 100644
--- a/meta/recipes-support/vte/vte_0.82.2.bb
+++ b/meta/recipes-support/vte/vte_0.82.2.bb
@@ -15,7 +15,7 @@ DEPENDS = "fastfloat fmt glib-2.0 glib-2.0-native gtk+3 libpcre2 libxml2-native
 
 GIR_MESON_OPTION = 'gir'
 GIDOCGEN_MESON_OPTION = "docs"
-inherit gnomebase gi-docgen features_check upstream-version-is-even gobject-introspection systemd vala
+inherit gnomebase gi-docgen features_check upstream-version-is-even gobject-introspection systemd vala upstream-stable-release-point
 
 SRC_URI += "file://0001-Add-W_EXITCODE-macro-for-non-glibc-systems.patch \
             file://0001-support-reproducibility-for-debug-sources.patch;patchdir=./subprojects/simdutf \
-- 
2.34.1

[OE-core][PATCH V5 4/7] systemd: inherit upstream-stable-release-point

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

Upgrades like 259 -> 259.1 or 259.1 -> 259.2 are stable upgrades
for systemd.

* Evidence

  Its repo[1] has remote branches like:
    origin/v256-stable
    origin/v257-stable
    origin/v258-stable
    origin/v259-stable
    origin/v260-stable

[1] https://github.com/systemd/systemd.git

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/recipes-core/systemd/systemd.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-core/systemd/systemd.inc b/meta/recipes-core/systemd/systemd.inc
index f107c4c5da..e63dde3af9 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -19,6 +19,9 @@ SRCREV = "b3d8fc43e9cb531d958c17ef2cd93b374bc14e8a"
 SRCBRANCH = "v259-stable"
 SRC_URI = "git://github.com/systemd/systemd.git;protocol=https;branch=${SRCBRANCH};tag=v${PV}"
 
+inherit upstream-stable-release-point
+STABLE_VERSION_PARTS = "1"
+
 CVE_PRODUCT = "systemd"
 
 CVE_STATUS[CVE-2019-3815] = "not-applicable-platform: only applied to RHEL"
-- 
2.34.1

[OE-core][PATCH V5 5/7] kmod: inherit upstream-stable-release-point

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

Upgrades like 34 -> 34.1 or 34.1 -> 34.2 for kmod are stable upgrades.

* Evidence

  Its repo contains a branch called:
  origin/kmod-34.y

  Its tags are like:
  v32
  v33
  v34
  v34.1

  So we can infer that the maintenance policy for kmod is that
  upgrades such as 33 -> 34 contains features and upgrades such
  as 34 -> 34.1 is a stable upgrade. And such maintenance policy
  is likely to continue.

[1] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/recipes-kernel/kmod/kmod_34.2.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/kmod/kmod_34.2.bb b/meta/recipes-kernel/kmod/kmod_34.2.bb
index e5923a64cf..a61466cefb 100644
--- a/meta/recipes-kernel/kmod/kmod_34.2.bb
+++ b/meta/recipes-kernel/kmod/kmod_34.2.bb
@@ -13,13 +13,15 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
                     file://libkmod/COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
                     file://tools/COPYING;md5=751419260aa954499f7abaabaa882bbe \
                    "
-inherit bash-completion gtk-doc manpages meson pkgconfig update-alternatives
+inherit bash-completion gtk-doc manpages meson pkgconfig update-alternatives upstream-stable-release-point
 
 SRC_URI = "https://www.kernel.org/pub/linux/utils/kernel/${BPN}/${BP}.tar.xz \
            file://depmod-search.conf \
            "
 SRC_URI[sha256sum] = "5a5d5073070cc7e0c7a7a3c6ec2a0e1780850c8b47b3e3892226b93ffcb9cb54"
 
+STABLE_VERSION_PARTS = "1"
+
 EXTRA_OEMESON += "\
     -Ddistconfdir=${nonarch_base_libdir} \
     --bindir=${base_bindir} \
-- 
2.34.1

[OE-core][PATCH V5 6/7] util-linux: inherit upstream-stable-release-point

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

util-linux has x.y.z version scheme and the bump in z is a stable
version upgrade. For example, 2.41.1 -> 2.41.2 is a stable version
upgrade.

* Evidence

  Its repo[1] contains branches like:
    origin/stable/v2.39
    origin/stable/v2.40
    origin/stable/v2.41

[1] https://github.com/util-linux/util-linux.git

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/recipes-core/util-linux/util-linux.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index 0235862666..1068e24b76 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -25,4 +25,6 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-lin
 
 SRC_URI[sha256sum] = "3330d873f0fceb5560b89a7dc14e4f3288bbd880e96903ed9b50ec2b5799e58b"
 
+inherit upstream-stable-release-point
+
 CVE_PRODUCT = "util-linux"
-- 
2.34.1

[OE-core][PATCH V5 7/7] openssh: set UPSTREAM_STABLE_RELEASE_REGEX

[Qi.Chen]

From: Chen Qi <Qi.Chen@windriver.com>

For openssh, 10.3p1 -> 10.3p2 is a stable upgrade.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
 meta/recipes-connectivity/openssh/openssh_10.3p1.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-connectivity/openssh/openssh_10.3p1.bb b/meta/recipes-connectivity/openssh/openssh_10.3p1.bb
index a050475532..394b4c2884 100644
--- a/meta/recipes-connectivity/openssh/openssh_10.3p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_10.3p1.bb
@@ -27,6 +27,9 @@ SRC_URI = "https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.ta
            "
 SRC_URI[sha256sum] = "56682a36bb92dcf4b4f016fd8ec8e74059b79a8de25c15d670d731e7d18e45f4"
 
+STABLE_VERSION = "${@d.getVar('PV').split('p')[0].replace('.', '\.')}"
+UPSTREAM_STABLE_RELEASE_REGEX = "^${STABLE_VERSION}p\d+$"
+
 CVE_STATUS[CVE-2007-2768] = "not-applicable-config: This CVE is specific to OpenSSH with the pam opie which we don't build/use here."
 
 # This CVE is specific to OpenSSH server, as used in Fedora and Red Hat Enterprise Linux 7
-- 
2.34.1

Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Alexander Kanavin]

Thanks, I think this is good and ready. I'll pick the auh patch when
bitbake and core patches merge.

We can add more recipes over time (e.g. openssl, webkit, glib, ...),
they don't have to be in the initial patchset. Probably a review of
scarthgap/whinlatter/walnascar/styhead commits can help identify more
recipes with stable maintenance releases as well.

Daniel's changelog extraction patches will also help a lot, take a look at them.

Alex


On Wed, 13 May 2026 at 07:23, <Qi.Chen@windriver.com> wrote:
>
> From: Chen Qi <Qi.Chen@windriver.com>
>
> We want the ability to do stable version upgrades for recipes.
> To this end, add an optional stable_upgrade parameter to the
> get_recipe_upgrade_status function, which defaults to False and
> when enabled will try to get the latest stable version of the recipe.
>
> The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets
> it, it will be used as the filter_regex. If it's not set explicitly,
> it means that there's no stable updates or the recipe hasn't been
> checked yet.
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
>  meta/lib/oe/recipeutils.py | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> index c6604f536d..7c1df518a8 100644
> --- a/meta/lib/oe/recipeutils.py
> +++ b/meta/lib/oe/recipeutils.py
> @@ -1009,7 +1009,7 @@ def get_recipe_pv_with_pfx_sfx(pv, uri_type):
>
>      return (pv, pfx, sfx)
>
> -def get_recipe_upstream_version(rd):
> +def get_recipe_upstream_version(rd, stable_upgrade):
>      """
>          Get upstream version of recipe using bb.fetch2 methods with support for
>          http, https, ftp and git.
> @@ -1080,7 +1080,15 @@ def get_recipe_upstream_version(rd):
>              except bb.fetch2.FetchError as e:
>                  bb.warn("Unable to obtain latest revision: {}".format(e))
>          else:
> -            pupver = ud.method.latest_versionstring(ud, rd)
> +            if stable_upgrade:
> +                stable_release_regex = rd.getVar("UPSTREAM_STABLE_RELEASE_REGEX")
> +                if stable_release_regex:
> +                    pupver = ud.method.latest_versionstring(ud, rd, filter_regex=stable_release_regex)
> +                else:
> +                    # Not explicitly setting "UPSTREAM_STABLE_RELEASE_REGEX" means there's no stable upgrade
> +                    pupver = (ru['current_version'], None)
> +            else:
> +                pupver = ud.method.latest_versionstring(ud, rd)
>              (upversion, revision) = pupver
>
>          if upversion:
> @@ -1094,8 +1102,8 @@ def get_recipe_upstream_version(rd):
>
>      return ru
>
> -def _get_recipe_upgrade_status(data):
> -    uv = get_recipe_upstream_version(data)
> +def _get_recipe_upgrade_status(data, stable_upgrade):
> +    uv = get_recipe_upstream_version(data, stable_upgrade)
>
>      pn = data.getVar('PN')
>      cur_ver = uv['current_version']
> @@ -1119,9 +1127,10 @@ def _get_recipe_upgrade_status(data):
>
>      return {'pn':pn, 'status':status, 'cur_ver':cur_ver, 'next_ver':next_ver, 'maintainer':maintainer, 'revision':revision, 'no_upgrade_reason':no_upgrade_reason}
>
> -def get_recipe_upgrade_status(recipes=None):
> +def get_recipe_upgrade_status(recipes=None, stable_upgrade=False):
>      pkgs_list = []
>      data_copy_list = []
> +    stable_copy_list = []
>      copy_vars = ('SRC_URI',
>                   'PV',
>                   'DL_DIR',
> @@ -1134,6 +1143,7 @@ def get_recipe_upgrade_status(recipes=None):
>                   'UPSTREAM_CHECK_REGEX',
>                   'UPSTREAM_CHECK_URI',
>                   'UPSTREAM_VERSION_UNKNOWN',
> +                 'UPSTREAM_STABLE_RELEASE_REGEX',
>                   'RECIPE_MAINTAINER',
>                   'RECIPE_NO_UPDATE_REASON',
>                   'RECIPE_UPSTREAM_VERSION',
> @@ -1180,12 +1190,13 @@ def get_recipe_upgrade_status(recipes=None):
>                      data_copy.setVar(k, data.getVar(k))
>
>              data_copy_list.append(data_copy)
> +            stable_copy_list.append(stable_upgrade)
>
>              recipeincludes[data.getVar('FILE')] = {'bbincluded':data.getVar('BBINCLUDED').split(),'pn':data.getVar('PN')}
>
>      from concurrent.futures import ProcessPoolExecutor
>      with ProcessPoolExecutor(max_workers=utils.cpu_count()) as executor:
> -        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list)
> +        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list, stable_copy_list)
>
>      return _group_recipes(pkgs_list, _get_common_include_recipes(recipeincludes))
>
> --
> 2.34.1
>

RE: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Daniel Turull]

Hi,

I will be presenting in Nice https://github.com/Nordix/meta-binaryaudit/tree/devel which can help also identify more components that are good keeping backward compatibility. I could send the list of components that I have identified.

Qi, will you request to have this backported to the TSC? Once my devtool changelog patch get's merged I was planning to request it as well. Then we can have a powerful AUH tool to help to maintain version in LTS verifying backward compatibility or for selected components.

Best regards,
Daniel

> -----Original Message-----
> From: Alexander Kanavin <alex.kanavin@gmail.com>
> Sent: Wednesday, 13 May 2026 11:36
> To: Qi.Chen@windriver.com
> Cc: openembedded-core@lists.openembedded.org;
> randy.macleod@windriver.com; Daniel Turull <daniel.turull@ericsson.com>
> Subject: Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade
> parameter to get_recipe_upgrade_status
> 
> Thanks, I think this is good and ready. I'll pick the auh patch when bitbake and
> core patches merge.
> 
> We can add more recipes over time (e.g. openssl, webkit, glib, ...), they don't have
> to be in the initial patchset. Probably a review of
> scarthgap/whinlatter/walnascar/styhead commits can help identify more recipes
> with stable maintenance releases as well.
> 
> Daniel's changelog extraction patches will also help a lot, take a look at them.
> 
> Alex
> 
> 
> On Wed, 13 May 2026 at 07:23, <Qi.Chen@windriver.com> wrote:
> >
> > From: Chen Qi <Qi.Chen@windriver.com>
> >
> > We want the ability to do stable version upgrades for recipes.
> > To this end, add an optional stable_upgrade parameter to the
> > get_recipe_upgrade_status function, which defaults to False and when
> > enabled will try to get the latest stable version of the recipe.
> >
> > The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets it,
> > it will be used as the filter_regex. If it's not set explicitly, it
> > means that there's no stable updates or the recipe hasn't been checked
> > yet.
> >
> > Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> > ---
> >  meta/lib/oe/recipeutils.py | 23 +++++++++++++++++------
> >  1 file changed, 17 insertions(+), 6 deletions(-)
> >
> > diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> > index c6604f536d..7c1df518a8 100644
> > --- a/meta/lib/oe/recipeutils.py
> > +++ b/meta/lib/oe/recipeutils.py
> > @@ -1009,7 +1009,7 @@ def get_recipe_pv_with_pfx_sfx(pv, uri_type):
> >
> >      return (pv, pfx, sfx)
> >
> > -def get_recipe_upstream_version(rd):
> > +def get_recipe_upstream_version(rd, stable_upgrade):
> >      """
> >          Get upstream version of recipe using bb.fetch2 methods with support for
> >          http, https, ftp and git.
> > @@ -1080,7 +1080,15 @@ def get_recipe_upstream_version(rd):
> >              except bb.fetch2.FetchError as e:
> >                  bb.warn("Unable to obtain latest revision: {}".format(e))
> >          else:
> > -            pupver = ud.method.latest_versionstring(ud, rd)
> > +            if stable_upgrade:
> > +                stable_release_regex =
> rd.getVar("UPSTREAM_STABLE_RELEASE_REGEX")
> > +                if stable_release_regex:
> > +                    pupver = ud.method.latest_versionstring(ud, rd,
> filter_regex=stable_release_regex)
> > +                else:
> > +                    # Not explicitly setting "UPSTREAM_STABLE_RELEASE_REGEX"
> means there's no stable upgrade
> > +                    pupver = (ru['current_version'], None)
> > +            else:
> > +                pupver = ud.method.latest_versionstring(ud, rd)
> >              (upversion, revision) = pupver
> >
> >          if upversion:
> > @@ -1094,8 +1102,8 @@ def get_recipe_upstream_version(rd):
> >
> >      return ru
> >
> > -def _get_recipe_upgrade_status(data):
> > -    uv = get_recipe_upstream_version(data)
> > +def _get_recipe_upgrade_status(data, stable_upgrade):
> > +    uv = get_recipe_upstream_version(data, stable_upgrade)
> >
> >      pn = data.getVar('PN')
> >      cur_ver = uv['current_version']
> > @@ -1119,9 +1127,10 @@ def _get_recipe_upgrade_status(data):
> >
> >      return {'pn':pn, 'status':status, 'cur_ver':cur_ver,
> > 'next_ver':next_ver, 'maintainer':maintainer, 'revision':revision,
> > 'no_upgrade_reason':no_upgrade_reason}
> >
> > -def get_recipe_upgrade_status(recipes=None):
> > +def get_recipe_upgrade_status(recipes=None, stable_upgrade=False):
> >      pkgs_list = []
> >      data_copy_list = []
> > +    stable_copy_list = []
> >      copy_vars = ('SRC_URI',
> >                   'PV',
> >                   'DL_DIR',
> > @@ -1134,6 +1143,7 @@ def get_recipe_upgrade_status(recipes=None):
> >                   'UPSTREAM_CHECK_REGEX',
> >                   'UPSTREAM_CHECK_URI',
> >                   'UPSTREAM_VERSION_UNKNOWN',
> > +                 'UPSTREAM_STABLE_RELEASE_REGEX',
> >                   'RECIPE_MAINTAINER',
> >                   'RECIPE_NO_UPDATE_REASON',
> >                   'RECIPE_UPSTREAM_VERSION', @@ -1180,12 +1190,13 @@
> > def get_recipe_upgrade_status(recipes=None):
> >                      data_copy.setVar(k, data.getVar(k))
> >
> >              data_copy_list.append(data_copy)
> > +            stable_copy_list.append(stable_upgrade)
> >
> >              recipeincludes[data.getVar('FILE')] =
> > {'bbincluded':data.getVar('BBINCLUDED').split(),'pn':data.getVar('PN')
> > }
> >
> >      from concurrent.futures import ProcessPoolExecutor
> >      with ProcessPoolExecutor(max_workers=utils.cpu_count()) as executor:
> > -        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list)
> > +        pkgs_list = executor.map(_get_recipe_upgrade_status,
> > + data_copy_list, stable_copy_list)
> >
> >      return _group_recipes(pkgs_list,
> > _get_common_include_recipes(recipeincludes))
> >
> > --
> > 2.34.1
> >

Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Alexander Kanavin]

On Wed, 13 May 2026 at 11:44, Daniel Turull <daniel.turull@ericsson.com> wrote:
> I will be presenting in Nice https://github.com/Nordix/meta-binaryaudit/tree/devel which can help also identify more components that are good keeping backward compatibility. I could send the list of components that I have identified.
>
> Qi, will you request to have this backported to the TSC? Once my devtool changelog patch get's merged I was planning to request it as well. Then we can have a powerful AUH tool to help to maintain version in LTS verifying backward compatibility or for selected components.
>

Just in case, I support the backport. The changes to bitbake/core are
not invasive, and they're in relatively 'safe' parts of the code that
aren't used in core workflows (e.g. actual builds aren't affected,
only the version checks and even there it's backwards compatible).

Alex

RE: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Chen, Qi]

Hi Daniel,

I don't have any strong preference. I'll respect TSC's decision and if there's anything that needs me to do, I'll do it.

My major focus, as replied to Alex in other email, is to go through oe-core and meta-openembedded once these patches get merged. I expect that the UPSTREAM_STABLE_RELEASE_REGEX meta data will be in good shape in one or two months. And Yocto LTS releases (future ones can maybe the current ones if the backport happens) can make use of these meta data.

P.S.
I saw the changelog changes and I like it.

Regards,
Qi

-----Original Message-----
From: Alexander Kanavin <alex.kanavin@gmail.com> 
Sent: Wednesday, May 13, 2026 5:52 PM
To: Daniel Turull <daniel.turull@ericsson.com>
Cc: Chen, Qi <Qi.Chen@windriver.com>; openembedded-core@lists.openembedded.org; MacLeod, Randy <Randy.MacLeod@windriver.com>
Subject: Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

On Wed, 13 May 2026 at 11:44, Daniel Turull <daniel.turull@ericsson.com> wrote:
> I will be presenting in Nice https://github.com/Nordix/meta-binaryaudit/tree/devel which can help also identify more components that are good keeping backward compatibility. I could send the list of components that I have identified.
>
> Qi, will you request to have this backported to the TSC? Once my devtool changelog patch get's merged I was planning to request it as well. Then we can have a powerful AUH tool to help to maintain version in LTS verifying backward compatibility or for selected components.
>

Just in case, I support the backport. The changes to bitbake/core are not invasive, and they're in relatively 'safe' parts of the code that aren't used in core workflows (e.g. actual builds aren't affected, only the version checks and even there it's backwards compatible).

Alex

RE: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Chen, Qi]

Hi Alex,

Thanks for your review. After these patches are merged, I think I can coordinate some of my colleagues to help with adding more recipes. In this way, the meta data for oe-core and meta-openembedded will be ready in one or two months.
Reviewing previous commits of released branches is really a good idea!
I think we'll also be checking repos, branches (as you suggested), changelogs and even upstreams directly to ensure the correctness.

Regards,
Qi

-----Original Message-----
From: Alexander Kanavin <alex.kanavin@gmail.com> 
Sent: Wednesday, May 13, 2026 5:36 PM
To: Chen, Qi <Qi.Chen@windriver.com>
Cc: openembedded-core@lists.openembedded.org; MacLeod, Randy <Randy.MacLeod@windriver.com>; Daniel Turull <daniel.turull@ericsson.com>
Subject: Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

Thanks, I think this is good and ready. I'll pick the auh patch when bitbake and core patches merge.

We can add more recipes over time (e.g. openssl, webkit, glib, ...), they don't have to be in the initial patchset. Probably a review of scarthgap/whinlatter/walnascar/styhead commits can help identify more recipes with stable maintenance releases as well.

Daniel's changelog extraction patches will also help a lot, take a look at them.

Alex


On Wed, 13 May 2026 at 07:23, <Qi.Chen@windriver.com> wrote:
>
> From: Chen Qi <Qi.Chen@windriver.com>
>
> We want the ability to do stable version upgrades for recipes.
> To this end, add an optional stable_upgrade parameter to the 
> get_recipe_upgrade_status function, which defaults to False and when 
> enabled will try to get the latest stable version of the recipe.
>
> The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets it, 
> it will be used as the filter_regex. If it's not set explicitly, it 
> means that there's no stable updates or the recipe hasn't been checked 
> yet.
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
>  meta/lib/oe/recipeutils.py | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py 
> index c6604f536d..7c1df518a8 100644
> --- a/meta/lib/oe/recipeutils.py
> +++ b/meta/lib/oe/recipeutils.py
> @@ -1009,7 +1009,7 @@ def get_recipe_pv_with_pfx_sfx(pv, uri_type):
>
>      return (pv, pfx, sfx)
>
> -def get_recipe_upstream_version(rd):
> +def get_recipe_upstream_version(rd, stable_upgrade):
>      """
>          Get upstream version of recipe using bb.fetch2 methods with support for
>          http, https, ftp and git.
> @@ -1080,7 +1080,15 @@ def get_recipe_upstream_version(rd):
>              except bb.fetch2.FetchError as e:
>                  bb.warn("Unable to obtain latest revision: {}".format(e))
>          else:
> -            pupver = ud.method.latest_versionstring(ud, rd)
> +            if stable_upgrade:
> +                stable_release_regex = rd.getVar("UPSTREAM_STABLE_RELEASE_REGEX")
> +                if stable_release_regex:
> +                    pupver = ud.method.latest_versionstring(ud, rd, filter_regex=stable_release_regex)
> +                else:
> +                    # Not explicitly setting "UPSTREAM_STABLE_RELEASE_REGEX" means there's no stable upgrade
> +                    pupver = (ru['current_version'], None)
> +            else:
> +                pupver = ud.method.latest_versionstring(ud, rd)
>              (upversion, revision) = pupver
>
>          if upversion:
> @@ -1094,8 +1102,8 @@ def get_recipe_upstream_version(rd):
>
>      return ru
>
> -def _get_recipe_upgrade_status(data):
> -    uv = get_recipe_upstream_version(data)
> +def _get_recipe_upgrade_status(data, stable_upgrade):
> +    uv = get_recipe_upstream_version(data, stable_upgrade)
>
>      pn = data.getVar('PN')
>      cur_ver = uv['current_version']
> @@ -1119,9 +1127,10 @@ def _get_recipe_upgrade_status(data):
>
>      return {'pn':pn, 'status':status, 'cur_ver':cur_ver, 
> 'next_ver':next_ver, 'maintainer':maintainer, 'revision':revision, 
> 'no_upgrade_reason':no_upgrade_reason}
>
> -def get_recipe_upgrade_status(recipes=None):
> +def get_recipe_upgrade_status(recipes=None, stable_upgrade=False):
>      pkgs_list = []
>      data_copy_list = []
> +    stable_copy_list = []
>      copy_vars = ('SRC_URI',
>                   'PV',
>                   'DL_DIR',
> @@ -1134,6 +1143,7 @@ def get_recipe_upgrade_status(recipes=None):
>                   'UPSTREAM_CHECK_REGEX',
>                   'UPSTREAM_CHECK_URI',
>                   'UPSTREAM_VERSION_UNKNOWN',
> +                 'UPSTREAM_STABLE_RELEASE_REGEX',
>                   'RECIPE_MAINTAINER',
>                   'RECIPE_NO_UPDATE_REASON',
>                   'RECIPE_UPSTREAM_VERSION', @@ -1180,12 +1190,13 @@ 
> def get_recipe_upgrade_status(recipes=None):
>                      data_copy.setVar(k, data.getVar(k))
>
>              data_copy_list.append(data_copy)
> +            stable_copy_list.append(stable_upgrade)
>
>              recipeincludes[data.getVar('FILE')] = 
> {'bbincluded':data.getVar('BBINCLUDED').split(),'pn':data.getVar('PN')
> }
>
>      from concurrent.futures import ProcessPoolExecutor
>      with ProcessPoolExecutor(max_workers=utils.cpu_count()) as executor:
> -        pkgs_list = executor.map(_get_recipe_upgrade_status, data_copy_list)
> +        pkgs_list = executor.map(_get_recipe_upgrade_status, 
> + data_copy_list, stable_copy_list)
>
>      return _group_recipes(pkgs_list, 
> _get_common_include_recipes(recipeincludes))
>
> --
> 2.34.1
>

Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Mathieu Dubois-Briand]

On Wed May 13, 2026 at 7:23 AM CEST, Chen Qi via lists.openembedded.org wrote:
> From: Chen Qi <Qi.Chen@windriver.com>
>
> We want the ability to do stable version upgrades for recipes.
> To this end, add an optional stable_upgrade parameter to the
> get_recipe_upgrade_status function, which defaults to False and
> when enabled will try to get the latest stable version of the recipe.
>
> The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets
> it, it will be used as the filter_regex. If it's not set explicitly,
> it means that there's no stable updates or the recipe hasn't been
> checked yet.
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---

Hi Chen,

Thanks for the new version.

We got several selftest fails on the autobuilder:

2026-05-13 20:05:23,677 - oe-selftest - INFO - overlayfs.OverlayFSTests.test_mount_unit_not_set (subunit.RemotedTestCase)
2026-05-13 20:05:23,678 - oe-selftest - INFO -  ... FAIL
...
ERROR: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/build-st-37462/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb: A recipe uses overlayfs class but there is no OVERLAYFS_MOUNT_POINT set in your MACHINE configuration
ERROR: Parsing halted due to errors, see error messages above
...
2026-05-13 20:11:59,345 - oe-selftest - INFO - overlayfs.OverlayFSTests.test_wrong_mount_unit_set (subunit.RemotedTestCase)
2026-05-13 20:11:59,345 - oe-selftest - INFO -  ... FAIL
...
2026-05-13 20:22:13,763 - oe-selftest - INFO - recipetool.RecipetoolAppendTests.test_recipetool_appendfile_add_bindir (subunit.RemotedTestCase)
2026-05-13 20:22:13,764 - oe-selftest - INFO -  ... FAIL
...
2026-05-13 20:23:11,171 - oe-selftest - INFO - recipetool.RecipetoolAppendTests.test_recipetool_appendfile_add_machine (subunit.RemotedTestCase)
2026-05-13 20:23:11,172 - oe-selftest - INFO -  ... FAIL
...
2026-05-13 20:24:48,333 - oe-selftest - INFO - recipetool.RecipetoolAppendTests.test_recipetool_appendfile_basic (subunit.RemotedTestCase)
2026-05-13 20:24:48,334 - oe-selftest - INFO -  ... FAIL
...

https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/3951
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3850
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3718

Can you have a look at this issue?

Thanks,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

RE: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Chen, Qi]

Hi Mathieu,

I can't reproduce this issue.

I ran the related recipetool oe-selftest on Ubuntu 22.04 host, Ubuntu 24.04 host and Fedora 44 container. All succeeded.
To be more detailed, I ran 'oe-selftest -r recipetool.RecipetoolAppendTests.test_recipetool_appendfile_add_bindir' on Ubuntu 22 and Fedora 44, and 'oe-selftest -r recipetool' on Ubuntu 24.

I examined the error messages on autobuilder. The key part is:
upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n

However, the actual codes are:
'\.'.join(stable_parts)

There seems to be an extra '\' there. Interestingly, even if I manually added an extra '\' to the codes, the test ('oe-selftest -r recipetool.RecipetoolAppendTests.test_recipetool_appendfile_add_bindir) still passed.

Could you please help me check how to reproduce this issue?

For easier examination, I've copy pasted the autobuilder's error message below.

----- error message start -----
2026-05-13 20:22:13,764 - oe-selftest - INFO - 1: 40/96 487/686 (57.83s) (2 failed) (recipetool.RecipetoolAppendTests.test_recipetool_appendfile_add_bindir)
2026-05-13 20:22:13,764 - oe-selftest - INFO - testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/lib/oeqa/selftest/cases/recipetool.py", line 198, in test_recipetool_appendfile_add_bindir
    self.assertNotIn('WARNING: ', output)
  File "/usr/lib/python3.12/unittest/case.py", line 1159, in assertNotIn
    self.fail(self._formatMessage(msg, standardMsg))
  File "/usr/lib/python3.12/unittest/case.py", line 715, in fail
    raise self.failureException(msg)
AssertionError: 'WARNING: ' unexpectedly found in "NOTE: Reconnecting to bitbake server...\nLoading cache...done.\nLoaded 0 entries from dependency cache.\nParsing recipes...WARNING: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/recipes-core/systemd/systemd-boot-native_259.5.bb: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/classes-recipe/upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n\nWARNING: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/recipes-core/systemd/systemd-boot_259.5.bb: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/classes-recipe/upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n\nWARNING: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/recipes-core/systemd/systemd-systemctl-native_259.5.bb: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/classes-recipe/upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n\nWARNING: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/recipes-core/systemd/systemd_259.5.bb: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/classes-recipe/upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n\nWARNING: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/recipes-core/util-linux/util-linux-libuuid_2.41.3.bb: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/classes-recipe/upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n\nWARNING: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.41.3.bb: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/classes-recipe/upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n\nWARNING: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/recipes-kernel/kmod/kmod_34.2.bb: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/layers/openembedded-core/meta/classes-recipe/upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n\ndone.\nParsing of 1029 .bb files complete (0 cached, 1029 parsed). 2078 targets, 64 skipped, 1 masked, 0 errors.\n\nSummary: There were 7 WARNING messages.\nNOTE: Writing append file /tmp/recipetoolqa7po32_jr/recipes-core/netbase/netbase_6.5.bbappend\nNOTE: Copying testfile to /tmp/recipetoolqa7po32_jr/recipes-core/netbase/netbase/testfile"
---- error message end ----

Regards,
Qi

-----Original Message-----
From: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> 
Sent: Thursday, May 14, 2026 6:39 PM
To: Chen, Qi <Qi.Chen@windriver.com>; openembedded-core@lists.openembedded.org
Cc: alex.kanavin@gmail.com; MacLeod, Randy <Randy.MacLeod@windriver.com>
Subject: Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

On Wed May 13, 2026 at 7:23 AM CEST, Chen Qi via lists.openembedded.org wrote:
> From: Chen Qi <Qi.Chen@windriver.com>
>
> We want the ability to do stable version upgrades for recipes.
> To this end, add an optional stable_upgrade parameter to the 
> get_recipe_upgrade_status function, which defaults to False and when 
> enabled will try to get the latest stable version of the recipe.
>
> The UPSTREAM_STABLE_RELEASE_REGEX is respected. If a recipe sets it, 
> it will be used as the filter_regex. If it's not set explicitly, it 
> means that there's no stable updates or the recipe hasn't been checked 
> yet.
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---

Hi Chen,

Thanks for the new version.

We got several selftest fails on the autobuilder:

2026-05-13 20:05:23,677 - oe-selftest - INFO - overlayfs.OverlayFSTests.test_mount_unit_not_set (subunit.RemotedTestCase)
2026-05-13 20:05:23,678 - oe-selftest - INFO -  ... FAIL ...
ERROR: /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/build-st-37462/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb: A recipe uses overlayfs class but there is no OVERLAYFS_MOUNT_POINT set in your MACHINE configuration
ERROR: Parsing halted due to errors, see error messages above ...
2026-05-13 20:11:59,345 - oe-selftest - INFO - overlayfs.OverlayFSTests.test_wrong_mount_unit_set (subunit.RemotedTestCase)
2026-05-13 20:11:59,345 - oe-selftest - INFO -  ... FAIL ...
2026-05-13 20:22:13,763 - oe-selftest - INFO - recipetool.RecipetoolAppendTests.test_recipetool_appendfile_add_bindir (subunit.RemotedTestCase)
2026-05-13 20:22:13,764 - oe-selftest - INFO -  ... FAIL ...
2026-05-13 20:23:11,171 - oe-selftest - INFO - recipetool.RecipetoolAppendTests.test_recipetool_appendfile_add_machine (subunit.RemotedTestCase)
2026-05-13 20:23:11,172 - oe-selftest - INFO -  ... FAIL ...
2026-05-13 20:24:48,333 - oe-selftest - INFO - recipetool.RecipetoolAppendTests.test_recipetool_appendfile_basic (subunit.RemotedTestCase)
2026-05-13 20:24:48,334 - oe-selftest - INFO -  ... FAIL ...

https://autobuilder.yoctoproject.org/valkyrie/#/builders/23/builds/3951
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3850
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3718

Can you have a look at this issue?

Thanks,
Mathieu

--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Alexander Kanavin]

On Fri, 15 May 2026 at 11:06, Chen Qi via lists.openembedded.org
<Qi.Chen=windriver.com@lists.openembedded.org> wrote:
> I examined the error messages on autobuilder. The key part is:
> upstream-stable-release-point.bbclass:18: SyntaxWarning: invalid escape sequence '\\.'\n  return '\\.'.join(stable_parts)\n
>
> However, the actual codes are:
> '\.'.join(stable_parts)
>
> There seems to be an extra '\' there. Interestingly, even if I manually added an extra '\' to the codes, the test ('oe-selftest -r recipetool.RecipetoolAppendTests.test_recipetool_appendfile_add_bindir) still passed.
>
> Could you please help me check how to reproduce this issue?

Hello Chen,

I'm not sure why you're not seeing this, but the fix is almost
certainly prefixing the string with r, e.g. making it a raw string.
Oe-core has had lots of similar fixes recently, e.g.:

https://git.openembedded.org/openembedded-core/commit/?id=24b0ba00d4f0b4d9834f7693ecb6032dfc534a80

Alex

Re: [OE-core][PATCH V5 1/7] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[Mathieu Dubois-Briand]

On Fri May 15, 2026 at 11:06 AM CEST, Qi Chen wrote:
> Hi Mathieu,
>
> I can't reproduce this issue.

Hi Chen,

Yes, I confirm I have the same issue on my side: I can't reproduce the
failures locally.

Yet I confirm the issue is linked with this series: dropping the patches
solves the issue, and I have similar issues with the v4. It's not clear
why in only happens on the autobuilder.

If you have ideas you want to test on the autobuilder to debug it, I can
easily schedule some builds. Aside of that, I fear I have no better
solution right now, I'm sorry.

Thanks,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com