[wrynose][PATCH 00/20] backport inherit upstream-stable-release-point

[wrynose][PATCH 00/20] backport inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

This series backports 'upstream-stable-release-point' support from
OE-Core master to wrynose. The first three commits are the
infrastructure, cherry-picked from the OE-Core originals:

  - recipeutils: add optional stable_upgrade parameter to
    get_recipe_upgrade_status, which passes UPSTREAM_STABLE_RELEASE_REGEX
    to the fetch method as filter_regex
  - upstream-stable-release-point.bbclass, which derives
    UPSTREAM_STABLE_RELEASE_REGEX from the recipe version so that stable
    point-release upgrades can be recognised
  - devtool/upgrade.py: add --stable option, the user-facing entry point
    that enables stable-only upgrade checking

The remaining 17 commits make the corresponding recipes inherit this
bbclass.

A companion bitbake series (filter_regex support for
latest_versionstring, also by Chen Qi) is sent separately against
bitbake 2.18. Without it the --stable option requests a
filter_regex parameter that older fetch2 implementations do not accept.

Each commit is cherry-picked with -x from the OE-Core original. Wrynose
carries older versions of several recipes, so those commits were applied
to the corresponding wrynose recipe file (e.g. git_2.53.0.bb rather than
git_2.55.0.bb); the adapted commits carry an 'Adapted for wrynose' note
in the commit message.

Pending TSC approval. Request sent.

Chen Qi (3):
  recipeutils: add optional stable_upgrade parameter to
    get_recipe_upgrade_status
  upstream-stable-release-point.bbclass: add bbclass for stable point
    upgrade
  devtool/upgrade.py: add --stable option

Daniel Turull (17):
  systemd: inherit upstream-stable-release-point
  glib-2.0: inherit upstream-stable-release-point
  dbus: inherit upstream-stable-release-point
  xz: inherit upstream-stable-release-point
  git: inherit upstream-stable-release-point
  perl: inherit upstream-stable-release-point
  libxml2: inherit upstream-stable-release-point
  python3: inherit upstream-stable-release-point
  openssl: inherit upstream-stable-release-point
  binutils: inherit upstream-stable-release-point
  libgcrypt: inherit upstream-stable-release-point
  sqlite3: inherit upstream-stable-release-point
  lttng-tools: inherit upstream-stable-release-point
  util-linux: inherit upstream-stable-release-point
  lttng-ust: inherit upstream-stable-release-point
  babeltrace2: inherit upstream-stable-release-point
  lttng-modules: inherit upstream-stable-release-point

 .../upstream-stable-release-point.bbclass     | 21 +++++++++++++++++
 meta/lib/oe/recipeutils.py                    | 23 ++++++++++++++-----
 .../openssl/openssl_3.5.7.bb                  |  5 ++++
 meta/recipes-core/dbus/dbus_1.16.2.bb         |  6 +++++
 meta/recipes-core/glib-2.0/glib.inc           |  4 +++-
 meta/recipes-core/libxml/libxml2_2.15.2.bb    |  4 ++++
 meta/recipes-core/systemd/systemd.inc         |  5 ++++
 meta/recipes-core/util-linux/util-linux.inc   |  4 ++++
 meta/recipes-devtools/binutils/binutils.inc   |  5 ++++
 meta/recipes-devtools/git/git_2.53.0.bb       |  4 ++++
 meta/recipes-devtools/perl/perl_5.42.0.bb     |  2 +-
 .../recipes-devtools/python/python3_3.14.6.bb |  4 ++++
 meta/recipes-extended/xz/xz_5.8.2.bb          |  4 ++++
 .../recipes-kernel/lttng/babeltrace2_2.1.2.bb |  4 +++-
 .../lttng/lttng-modules_2.14.4.bb             |  6 +++++
 .../lttng/lttng-tools_2.14.1.bb               |  2 +-
 meta/recipes-kernel/lttng/lttng-ust_2.14.0.bb |  4 +++-
 .../libgcrypt/libgcrypt_1.12.1.bb             |  2 +-
 meta/recipes-support/sqlite/sqlite3.inc       |  2 +-
 scripts/lib/devtool/upgrade.py                |  9 +++++---
 20 files changed, 104 insertions(+), 16 deletions(-)
 create mode 100644 meta/classes-recipe/upstream-stable-release-point.bbclass

[wrynose][PATCH 01/20] recipeutils: add optional stable_upgrade parameter to get_recipe_upgrade_status

[daniel.turull]

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>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1ed8fdda035dcc21f3df71c0c996973224f4f683)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.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))
 

[wrynose][PATCH 02/20] upstream-stable-release-point.bbclass: add bbclass for stable point upgrade

[daniel.turull]

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>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

(cherry picked from commit a1e069d04cb13e990b362804bd56a4935338ef96)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.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..98fdb5b808
--- /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 r'\.'.join(stable_parts)
+
+STABLE_VERSION_REGEX = "${@get_majmin_version_regex(d)}"
+UPSTREAM_STABLE_RELEASE_REGEX ?= "^${STABLE_VERSION_REGEX}(\.\d+)*$"

[wrynose][PATCH 03/20] devtool/upgrade.py: add --stable option

[daniel.turull]

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

Add '--stable' option to the three subcommands:
- latest-version
- check-upgrade-status
- upgrade

The effect of this option is to make the subcommand only consider
stable releases.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit 1e86aa039108621b2af734ef358a1e9d3c4d88d8)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
---
 scripts/lib/devtool/upgrade.py | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/devtool/upgrade.py b/scripts/lib/devtool/upgrade.py
index 8930fde5d6..91cb85403c 100644
--- a/scripts/lib/devtool/upgrade.py
+++ b/scripts/lib/devtool/upgrade.py
@@ -560,7 +560,7 @@ def upgrade(args, config, basepath, workspace):
 
         # try to automatically discover latest version and revision if not provided on command line
         if not args.version and not args.srcrev:
-            version_info = oe.recipeutils.get_recipe_upstream_version(rd)
+            version_info = oe.recipeutils.get_recipe_upstream_version(rd, args.stable)
             if version_info['version'] and not version_info['version'].endswith("new-commits-available"):
                 args.version = version_info['version']
             if version_info['revision']:
@@ -626,7 +626,7 @@ def latest_version(args, config, basepath, workspace):
         rd = parse_recipe(config, tinfoil, args.recipename, True)
         if not rd:
             return 1
-        version_info = oe.recipeutils.get_recipe_upstream_version(rd)
+        version_info = oe.recipeutils.get_recipe_upstream_version(rd, args.stable)
         # "new-commits-available" is an indication that upstream never issues version tags
         if not version_info['version'].endswith("new-commits-available"):
             logger.info("Current version: {}".format(version_info['current_version']))
@@ -649,7 +649,7 @@ def check_upgrade_status(args, config, basepath, workspace):
                                                                "cannot be updated due to: %s" %(recipe['no_upgrade_reason']) if recipe['no_upgrade_reason'] else ""))
     if not args.recipe:
         logger.info("Checking the upstream status for all recipes may take a few minutes")
-    results = oe.recipeutils.get_recipe_upgrade_status(args.recipe)
+    results = oe.recipeutils.get_recipe_upgrade_status(args.recipe, args.stable)
     for recipegroup in results:
         upgrades = [r for r in recipegroup if r['status'] != 'MATCH']
         currents = [r for r in recipegroup if r['status'] == 'MATCH']
@@ -673,6 +673,7 @@ def register_commands(subparsers, context):
                                            group='starting')
     parser_upgrade.add_argument('recipename', help='Name of recipe to upgrade (just name - no version, path or extension)')
     parser_upgrade.add_argument('srctree',  nargs='?', help='Path to where to extract the source tree. If not specified, a subdirectory of %s will be used.' % defsrctree)
+    parser_upgrade.add_argument('--stable', action="store_true", help='Only consider stable upstream releases')
     parser_upgrade.add_argument('--version', '-V', help='Version to upgrade to (PV). If omitted, latest upstream version will be determined and used, if possible.')
     parser_upgrade.add_argument('--srcrev', '-S', help='Source revision to upgrade to (useful when fetching from an SCM such as git)')
     parser_upgrade.add_argument('--srcbranch', '-B', help='Branch in source repository containing the revision to use (if fetching from an SCM such as git)')
@@ -690,11 +691,13 @@ def register_commands(subparsers, context):
                                                   description='Queries the upstream server for what the latest upstream release is (for git, tags are checked, for tarballs, a list of them is obtained, and one with the highest version number is reported)',
                                                   group='info')
     parser_latest_version.add_argument('recipename', help='Name of recipe to query (just name - no version, path or extension)')
+    parser_latest_version.add_argument('--stable', action="store_true", help='Only consider stable upstream releases')
     parser_latest_version.set_defaults(func=latest_version)
 
     parser_check_upgrade_status = subparsers.add_parser('check-upgrade-status', help="Report upgradability for multiple (or all) recipes",
                                                         description="Prints a table of recipes together with versions currently provided by recipes, and latest upstream versions, when there is a later version available",
                                                         group='info')
     parser_check_upgrade_status.add_argument('recipe', help='Name of the recipe to report (omit to report upgrade info for all recipes)', nargs='*')
+    parser_check_upgrade_status.add_argument('--stable', action="store_true", help='Only consider stable upstream releases')
     parser_check_upgrade_status.add_argument('--all', '-a', help='Show all recipes, not just recipes needing upgrade', action="store_true")
     parser_check_upgrade_status.set_defaults(func=check_upgrade_status)

[wrynose][PATCH 04/20] systemd: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

systemd's README ("STABLE BRANCHES AND BACKPORTS") documents per-release
stable branches carrying backported patches. The current one, v261-stable,
is branched in the main repository; the README still points at the
systemd-stable repository, which holds the branches up to v255. The major
is a single version part (261 -> 261.1), so upgrades within a major
are stable point upgrades per the OE-Core stable release policy
(ref-manual, "Stable Point Release Upgrades"). STABLE_VERSION_PARTS is
set to 1 accordingly.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/systemd/systemd/blob/v261.1/README#L460
  https://github.com/systemd/systemd/tree/v261-stable

Checked the last point release for feature creep:

  261.2 (Jul 23 2026), against 261.1 (Jun 26 2026): 277 commits, mostly
  fixes. NEWS files both releases under "CHANGES WITH 261" and gives
  neither its own entry. Four items are feature-shaped: refcounting,
  argument handling and JSON output additions, plus one new internal
  string-util flag.

Those are small internal additions on a real, diverged stable branch
rather than mainline drift, and none introduce a new subsystem: closer in
scope to a security-hardening batch than a feature release, though
broader than a pure bugfix release.

These bumps are not free: the scarthgap 255.4 -> 255.13 bump was held for a
v2 because TCLIBC=musl broke, and was merged once fixed. A point release
being fixes-only upstream does not remove the need to build and test it.

Already tracked this way on the OE stable branches, counting only bumps
made since each branch forked from master: kirkstone 250.4 -> 250.14 and
scarthgap 255.4 -> 255.21. wrynose has had no point-release bump yet.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c19dd5b2afa61ca78dad0b65556ba66e83db57c5)
---
 meta/recipes-core/systemd/systemd.inc | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-core/systemd/systemd.inc b/meta/recipes-core/systemd/systemd.inc
index f107c4c5da..bbcacf9deb 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -21,6 +21,11 @@ SRC_URI = "git://github.com/systemd/systemd.git;protocol=https;branch=${SRCBRANC
 
 CVE_PRODUCT = "systemd"
 
+# systemd publishes bugfix/security-only releases on its stable/v<major>-stable
+# branches (e.g. 261 -> 261.1). The major is a single version part.
+STABLE_VERSION_PARTS = "1"
+inherit upstream-stable-release-point
+
 CVE_STATUS[CVE-2019-3815] = "not-applicable-platform: only applied to RHEL"
 CVE_STATUS[CVE-2026-40223] = "fixed-version: fixed in 259.2"
 CVE_STATUS[CVE-2026-40224] = "fixed-version: fixed in 259.3"

[wrynose][PATCH 05/20] glib-2.0: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

GLib's docs/backports.md states that only bug and documentation fixes are
backported to the current stable branch, that new features and API/ABI
changes must not be, and that micro stable releases are intended as
drop-in replacements. So upgrades within a major.minor are stable point
upgrades per the OE-Core stable release policy (ref-manual, "Stable Point
Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://gitlab.gnome.org/GNOME/glib/-/blob/2.88.2/docs/backports.md#L18

Checked the last two point releases for feature creep:

  2.88.2 (Jun 25 2026): entirely "Bugs fixed" backports plus translation
  updates.
  2.88.1 (May 02 2026): seven fixes -- a GCC 16 miscompilation, a GRegex
  out-of-bounds read with security impact, and five further out-of-bounds
  reads. No API or behaviour changes.

The series opened with 2.88.0 (Mar 16 2026), which must stay outside the
regex as the feature-level release.

Already tracked this way on the OE stable branches, counting only bumps
made since each branch forked from master: kirkstone 2.72.0 -> 2.72.3,
scarthgap 2.78.4 -> 2.78.6, and wrynose 2.88.0 -> 2.88.2.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8de7017a3161ffb04f36e9c6ba2f7ead402dc4a5)
---
 meta/recipes-core/glib-2.0/glib.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc
index d49ae13168..cad74f53f7 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -30,7 +30,9 @@ LEAD_SONAME = "libglib-2.0.*"
 
 GNOMEBN = "glib"
 
-inherit gettext gi-docgen gnomebase ptest-gnome upstream-version-is-even bash-completion gio-module-cache manpages gobject-introspection-data
+# GLib publishes bugfix/security-only micro releases on its stable
+# (even-minor) series.
+inherit gettext gi-docgen gnomebase ptest-gnome upstream-version-is-even bash-completion gio-module-cache manpages gobject-introspection-data upstream-stable-release-point
 
 S = "${UNPACKDIR}/${GNOMEBN}-${PV}"
 

[wrynose][PATCH 06/20] dbus: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

D-Bus's CONTRIBUTING.md documents even-minor stable branches, currently
dbus-1.16.x, that receive only cherry-picked bug fixes, so upgrades
within a major.minor are stable point upgrades per the OE-Core stable
release policy (ref-manual, "Stable Point Release Upgrades"). It also
states that odd-minor development branches such as 1.17.x are not
supported at all and receive no bug fixes, not even for security
vulnerabilities, so only the even-minor stable series should be tracked.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://gitlab.freedesktop.org/dbus/dbus/-/blob/dbus-1.16.2/CONTRIBUTING.md#L65

Checked the only point release in the series so far for feature creep,
the 1.16.x series having just one non-.0 release to date:

  1.16.2 (Feb 27 2025): two items -- one build-regression fix for
  verbose-mode builds against libselinux >= 3.8, and a documentation
  update. No API or behaviour changes.

Already tracked this way on the OE stable branches, counting only bumps
made since each branch forked from master: kirkstone 1.14.0 -> 1.14.8.
scarthgap has had zero point-release bumps since its fork and remains at
1.14.10; wrynose ships 1.16.2 as its initial version with no bump yet.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

(cherry picked from commit 63948049e50abeda630fb716ea0ba97e71b4f7cd)
---
 meta/recipes-core/dbus/dbus_1.16.2.bb | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-core/dbus/dbus_1.16.2.bb b/meta/recipes-core/dbus/dbus_1.16.2.bb
index 7425bd2364..1102a8660e 100644
--- a/meta/recipes-core/dbus/dbus_1.16.2.bb
+++ b/meta/recipes-core/dbus/dbus_1.16.2.bb
@@ -5,6 +5,12 @@ SECTION = "base"
 
 inherit meson pkgconfig gettext upstream-version-is-even ptest-gnome
 
+# D-Bus publishes bugfix/security-only micro releases on its stable
+# (even-minor) branches. Odd-minor development branches (e.g. 1.17.x) are
+# not supported at all and receive no bug fixes, not even for security
+# vulnerabilities, so only the even-minor stable series is tracked here.
+inherit upstream-stable-release-point
+
 LICENSE = "AFL-2.1 | GPL-2.0-or-later"
 LIC_FILES_CHKSUM = "file://COPYING;md5=eb0ffc69a965797a3d6686baa153ef05 \
                     file://dbus/dbus.h;beginline=6;endline=22;md5=df4251a6c6e15e6a9e3c77b2ac30065d \

[wrynose][PATCH 07/20] xz: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

XZ Utils's README documents that an even minor (Y) is a stable series
where the revision (Z) "is incremented when bugs get fixed without adding
any new features". So upgrades within a major.minor are stable point
upgrades per the OE-Core stable release policy (ref-manual, "Stable Point
Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/tukaani-project/xz/blob/v5.8.3/README#L138

Checked the last two point releases for feature creep:

  5.8.3 (Mar 31 2026): one CVE (CVE-2026-34743, a buffer overflow in
  lzma_index_append), one invalid-memory-access fix, build portability
  fixes for Windows ARM64EC and Hurd, and man page translations. No new
  options or API.
  5.8.2 (Dec 17 2025): build portability fixes for four toolchains, a
  RHEL 9 kernel-bug workaround, and a resource-aware memory-limit default
  tweak that is a bugfix rather than a new feature. No new options or
  API.

Already tracked this way on the OE stable branches, counting only bumps
made since each branch forked from master: kirkstone picked up 5.2.6 and
scarthgap 5.4.7, one bump each.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Adapted for wrynose: applied to xz_5.8.2.bb (upstream: xz_5.8.3.bb).
(cherry picked from commit e336ba1ed32bc924dab329afe1d687e0382f1c87)
---
 meta/recipes-extended/xz/xz_5.8.2.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-extended/xz/xz_5.8.2.bb b/meta/recipes-extended/xz/xz_5.8.2.bb
index 15eaa7a52f..5e7ad1fc70 100644
--- a/meta/recipes-extended/xz/xz_5.8.2.bb
+++ b/meta/recipes-extended/xz/xz_5.8.2.bb
@@ -33,6 +33,10 @@ SRC_URI[sha256sum] = "ce09c50a5962786b83e5da389c90dd2c15ecd0980a258dd01f70f9e7ce
 UPSTREAM_CHECK_REGEX = "releases/tag/v(?P<pver>\d+(\.\d+)+)"
 UPSTREAM_CHECK_URI = "https://github.com/tukaani-project/xz/releases/"
 
+# XZ Utils publishes bugfix/security-only micro releases on its stable
+# (even-minor) branches.
+inherit upstream-stable-release-point
+
 CACHED_CONFIGUREVARS += "gl_cv_posix_shell=/bin/sh"
 
 inherit autotools gettext ptest

[wrynose][PATCH 08/20] git: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

Git's maintainer documentation defines the version scheme explicitly:
vX.Y.0 are feature releases carrying bugfixes and enhancements in any
area, while vX.Y.Z (Z>0) maintenance releases "contain only bugfixes for
the corresponding vX.Y.0 feature release and earlier maintenance
releases". So upgrades within a major.minor are stable point upgrades per
the OE-Core stable release policy (ref-manual, "Stable Point Release
Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/git/git/blob/v2.55.0/Documentation/howto/maintain-git.adoc#L47

Checked recent maintenance releases for feature creep:

  2.44.4 (May 28 2025): CVE fixes only, seven of them, merged up from the
  fixes that appeared in v2.43.7. The release notes contain nothing else.
  2.35.7 (Feb 06 2023): four fixes -- two libcurl portability fixes, and
  two symlink-escape fixes in apply and clone back-merged from older
  maintenance lines.

No 2.55.x point release exists yet, 2.55.0 being the current tip, so this
relies on the documented policy plus the historical pattern above rather
than a same-series point release. The ref-manual admits that basis: a
recipe may qualify on clear historical evidence that a class of bump is
bugfix-only (ref-manual, "Criteria for Qualifying Upstreams").

Already tracked this way on the OE stable branches, counting only bumps
made since each branch forked from master: kirkstone 2.35.2 -> 2.35.7,
five point bumps, and scarthgap 2.44.0 -> 2.44.4, three point bumps.
wrynose ships 2.53.0 as its initial version with no bump yet.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Adapted for wrynose: applied to git_2.53.0.bb (upstream: git_2.55.0.bb)
(cherry picked from commit 4300d9a707ee6ae2012ee03b4f4efae38521863c)
---
 meta/recipes-devtools/git/git_2.53.0.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/git/git_2.53.0.bb b/meta/recipes-devtools/git/git_2.53.0.bb
index 8d71905f41..5244891113 100644
--- a/meta/recipes-devtools/git/git_2.53.0.bb
+++ b/meta/recipes-devtools/git/git_2.53.0.bb
@@ -48,6 +48,10 @@ EXTRA_OECONF:append:class-native = " --with-gitconfig=/etc/gitconfig "
 # Needs brokensep as this doesn't use automake
 inherit autotools-brokensep perlnative bash-completion manpages
 
+# Git's maintainer docs define vX.Y.Z (Z>0) maintenance releases as
+# bugfix-only, scoped to the corresponding vX.Y.0 feature release.
+inherit upstream-stable-release-point
+
 EXTRA_OEMAKE = "NO_PYTHON=1 CFLAGS='${CFLAGS}' LDFLAGS='${LDFLAGS}'"
 EXTRA_OEMAKE += "'PERL_PATH=/usr/bin/env perl'"
 EXTRA_OEMAKE += "COMPUTE_HEADER_DEPENDENCIES=no"

[wrynose][PATCH 09/20] perl: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

perlpolicy documents a strict maintenance-branch policy: new releases of
a maint branch may only contain security/CVE fixes, crashing bugs,
regressions, build and install blockers, portability fixes and factual
documentation corrections, and must not contain patches that "add or
remove features", "break binary compatibility", or "add new warnings or
errors or deprecate features". New dual-life module versions are
explicitly deferred to the next stable series. So upgrades within a
major.minor are stable point upgrades per the OE-Core stable release
policy (ref-manual, "Stable Point Release Upgrades"). Long-lived
per-even-minor maint branches back this up, maint-5.6 through maint-5.42,
with a documented back-porting vote process.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/Perl/perl5/blob/v5.42.2/pod/perlpolicy.pod#L259

Checked the last two point releases for feature creep. perldelta makes
this easy to see, as maint releases carry no "Core Enhancements" section
at all:

  5.42.2 (Mar 29 2026): one CVE in a vendored dependency, CVE-2026-4176
  in Compress::Raw::Zlib, plus module version bumps. States "There are no
  changes intentionally incompatible with 5.42.1".
  5.42.1 (Mar 08 2026): four fixes -- a Configure fix so POSIX locale
  values can be passed in for cross-compilation, an AIX thread-safe
  locale workaround, a Win32 build fix, and module version bumps. States
  "There are no changes intentionally incompatible with Perl 5.42.0".
  5.42.0 (Jul 02 2025) is the series-opening release, not a point
  release: it adds seven language-level features, confirming X.Y.0 bumps
  are feature bumps that must stay outside the regex.

Cross-checked the previous series the same way: 5.40.1, 5.40.2 and 5.40.3
all show the same profile, with security, module, documentation, test and
bug-fix sections only and no Core Enhancements.

The policy forbidding binary-compatibility breaks in maint releases also
covers the ABI concern directly.

Already tracked this way on the OE stable branches, counting only bumps
made since each branch forked from master: kirkstone 5.34.1 -> 5.34.3 and
scarthgap 5.38.2 -> 5.38.4 are both in-series point bumps. wrynose is
still at 5.42.0 while master is at 5.42.2, so it is missing the
CVE-2026-4176 fix -- exactly the tracking gap --stable is meant to close.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Adapted for wrynose: applied to perl_5.42.0.bb (upstream: perl_5.44.0.bb).
(cherry picked from commit 73ae055e5a05078225226355f1545fc9e464e78d)
---
 meta/recipes-devtools/perl/perl_5.42.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/perl/perl_5.42.0.bb b/meta/recipes-devtools/perl/perl_5.42.0.bb
index 1833b7a352..e5f2db4bb9 100644
--- a/meta/recipes-devtools/perl/perl_5.42.0.bb
+++ b/meta/recipes-devtools/perl/perl_5.42.0.bb
@@ -30,7 +30,7 @@ SRC_URI[perl.sha256sum] = "e093ef184d7f9a1b9797e2465296f55510adb6dab8842b0c3ed53
 
 B = "${WORKDIR}/perl-${PV}-build"
 
-inherit upstream-version-is-even update-alternatives
+inherit upstream-version-is-even update-alternatives upstream-stable-release-point
 
 DEPENDS += "perlcross-native bzip2 zlib virtual/crypt"
 DEPENDS:append:class-native = " bzip2-replacement-native"

[wrynose][PATCH 10/20] libxml2: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

libxml2 maintains per-minor stable branches (2.9 through 2.15) that take
only bug-fix micro releases, and releases from several of them in
parallel: 2.13.9 and 2.14.6 went out the same day, after 2.14.5 was
already out. So upgrades within a major.minor are stable point upgrades
per the OE-Core stable release policy (ref-manual, "Stable Point Release
Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://gitlab.gnome.org/GNOME/libxml2/-/tree/2.15

Checked the last three point releases. 2.15.3 (Apr 15 2026) is five
security fixes plus an "Improvements" section that is also entirely fixes,
and 2.15.1 (Oct 16 2025) is security, regression and build fixes. 2.15.2
(Mar 03 2026) is five CVE fixes plus one addition, a --xpath0 option
confined to the xmllint command-line tool.

A public-header diff across the three shows zero added, removed or changed
libxml2.so declarations, so the library API and ABI are unaffected by that
addition.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone picked up 2.9.14, scarthgap 2.12.5 ->
2.12.10.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>

Adapted for wrynose: applied to libxml2_2.15.2.bb (upstream: libxml2_2.15.3.bb).
(cherry picked from commit a9fd7975e991124b8f54c4c763917e705fb4213c)
---
 meta/recipes-core/libxml/libxml2_2.15.2.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/libxml/libxml2_2.15.2.bb b/meta/recipes-core/libxml/libxml2_2.15.2.bb
index 9181949ea5..660e2dede2 100644
--- a/meta/recipes-core/libxml/libxml2_2.15.2.bb
+++ b/meta/recipes-core/libxml/libxml2_2.15.2.bb
@@ -30,6 +30,10 @@ BINCONFIG = "${bindir}/xml2-config"
 
 inherit autotools pkgconfig binconfig-disabled ptest
 
+# libxml2 publishes bugfix/security-only micro releases on its per-minor
+# release branches.
+inherit upstream-stable-release-point
+
 LDFLAGS:append:riscv64 = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-lld ptest', ' -fuse-ld=bfd', '', d)}"
 
 RDEPENDS:${PN}-ptest += "locale-base-en-us"

[wrynose][PATCH 11/20] python3: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

Python maintains each release series on a per-minor maintenance branch
that, once released, takes bug and security fixes only, and it releases
from several at once: 3.10.20, 3.11.15 and 3.12.13 all went out on
2026-03-03, after 3.14.3. So upgrades within a major.minor are stable
point upgrades per the OE-Core stable release policy (ref-manual, "Stable
Point Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://devguide.python.org/versions/

Checked the last three point releases by category, since these are
substantial bug-fix releases rather than security-only. 3.14.6 (Jun 10
2026) has 8 Security, 32 Library and 17 Core entries; 3.14.4 (Apr 07 2026)
has 5, 59 and 46. Every C API entry in both is a fix, so neither adds C
API. 3.14.5 (May 10 2026) is mostly fixes but does add RFC 9309 support to
urllib.robotparser -- one extra capability in one module, touching neither
the language, the C API nor the stable ABI.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone 3.10.4 -> 3.10.20, scarthgap 3.12.3 ->
3.12.13, wrynose 3.14.4 -> 3.14.6.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit e49e237208a9a5074d7bbc65b748962f3ea0eb49)
---
 meta/recipes-devtools/python/python3_3.14.6.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/python/python3_3.14.6.bb b/meta/recipes-devtools/python/python3_3.14.6.bb
index 0a9e82d445..c10ce3f0f4 100644
--- a/meta/recipes-devtools/python/python3_3.14.6.bb
+++ b/meta/recipes-devtools/python/python3_3.14.6.bb
@@ -47,6 +47,10 @@ SRC_URI[sha256sum] = "143b1dddefaec3bd2e21e3b839b34a2b7fb9842272883c576420d605e9
 # exclude pre-releases for both python 2.x and 3.x
 UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P<pver>\d+(\.\d+)+).tar"
 
+# Python publishes bugfix/security-only releases on its per-minor
+# maintenance branches.
+inherit upstream-stable-release-point
+
 CVE_PRODUCT = "python:python python_software_foundation:python cpython"
 
 PYTHON_MAJMIN = "3.14"

[wrynose][PATCH 12/20] openssl: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

OpenSSL's release strategy states that patch releases contain only bug and
security fixes, with no new features and no API or ABI breaking changes.
It maintains several series at once: 3.0.21, 3.4.6, 3.5.7 and 3.6.3 were
all released on 2026-06-09, with 4.0.0 already out. So upgrades within a
major.minor are stable point upgrades per the OE-Core stable release
policy (ref-manual, "Stable Point Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://openssl-library.org/policies/releasestrat/

Checked the last three point releases. Each is labelled "a security patch
release" in its own NEWS.md header, and every entry is a CVE fix, the item
count matching the unique CVE count exactly: 15 CVEs in 3.5.7 (Jun 09
2026), 7 in 3.5.6 (Apr 07 2026), 12 in 3.5.5 (Jan 27 2026).

When a series reaches EOL the regex must be moved to the next maintained
series by hand, as that is a feature-level change.

One limit is worth stating, from this recipe's own history: 3.2.4 -> 3.2.5
was refused on scarthgap in July 2025 for intermittent ptest failures in a
dependent recipe, bisected to an upstream commit and reported upstream,
and the branch went to 3.2.6 instead. A fixes-only release can still fail
to integrate, so proposing an upgrade is not the same as it passing.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone 3.0.2 -> 3.0.19 on the 3.0 LTS series;
scarthgap 3.2.1 -> 3.2.6 then, at EOL, 3.5.5 -> 3.5.7; wrynose picked up
3.5.7.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit 75f78c58cf9e4b385ddf4f09668b7f1a49117d97)
---
 meta/recipes-connectivity/openssl/openssl_3.5.7.bb | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-connectivity/openssl/openssl_3.5.7.bb b/meta/recipes-connectivity/openssl/openssl_3.5.7.bb
index 212879dfa3..1f2754d5e0 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.5.7.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.5.7.bb
@@ -24,6 +24,11 @@ SRC_URI[sha256sum] = "a8c0d28a529ca480f9f36cf5792e2cd21984552a3c8e4aa11a24aa31ae
 inherit lib_package multilib_header multilib_script ptest perlnative manpages
 MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
 
+# OpenSSL publishes bugfix/security-only releases on its per-minor branches.
+# When the tracked series reaches EOL, bump the regex manually to the next
+# maintained series.
+inherit upstream-stable-release-point
+
 PACKAGECONFIG ?= ""
 PACKAGECONFIG:class-native = ""
 PACKAGECONFIG:class-nativesdk = ""

[wrynose][PATCH 13/20] binutils: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

binutils cuts a per-X.Y stable branch, binutils-2_46-branch for the
current series, that takes only bugfixes and backported CVE fixes, and
tags X.Y.Z (Z>0) releases from it. Superseded branches stay alive: one x86
MODRM fix landed on the 2.40, 2.42 and 2.43 branches on the same day in
May 2025. So upgrades within a major.minor are stable point upgrades per
the OE-Core stable release policy (ref-manual, "Stable Point Release
Upgrades"). This is not spelled out in a policy document, so qualification
rests on the branch structure and the release contents below.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/binutils-2_46-branch

Checked the last two point releases. 2.46.1 (Jun 08 2026) is 137 commits,
mostly automatic version-string date bumps, with six substantive changes,
all fixes: gprof testsuite, build warnings, an sframe encoder/decoder
call-site fix, a DOS-filesystem fix and two linker fixes. 2.45.1 (Nov 10
2025) is aarch64/gas fixes to incorrectly restricted instruction
encodings, linker metadata fixes adding GLIBC_ABI_*_TLS version
dependencies to match glibc's own ABI tags, and libctf, strip and warning
fixes. Neither adds options or instruction support.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone has five or more "binutils: stable
2.38 branch update(s)" commits staying within 2.38.x, scarthgap the same
for 2.42.x, and wrynose has already taken 2.46.1.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit e61767b8d9486c1a13f505563919654af5955a23)
---
 meta/recipes-devtools/binutils/binutils.inc | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
index b3d0728e4b..29c05b1a27 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -15,6 +15,11 @@ DEPENDS = "flex-native bison-native zlib-native gnu-config-native autoconf-nativ
 
 inherit autotools gettext multilib_header pkgconfig texinfo
 
+# binutils maintains a stable branch per X.Y release (e.g. binutils-2_46-branch)
+# that only takes bugfixes and backported CVE fixes; X.Y.Z (Z>0) releases are
+# cut from that branch.
+inherit upstream-stable-release-point
+
 FILES:${PN} = " \
 	${bindir}/${TARGET_PREFIX}* \
 	${libdir}/lib*.so.* \

[wrynose][PATCH 14/20] libgcrypt: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

libgcrypt keeps a long-lived maintenance branch per minor version,
LIBGCRYPT-1.12-BRANCH matching the current PV with equivalents back to
1.2, and releases from several in parallel: in one week of April 2026 it
released into four of them, 1.12.2 and 1.8.13 on the 15th, 1.11.3 and
1.10.4 on the 21st. So upgrades within a major.minor are stable point
upgrades per the OE-Core stable release policy (ref-manual, "Stable Point
Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/gpg/libgcrypt/tree/LIBGCRYPT-1.12-BRANCH

NEWS separates "Bug fixes" from "New and extended interfaces", and neither
point release in the current series has the latter section at all: 1.12.2
(Apr 15 2026) is four fixes, including an ECDH buffer overwrite and a
missing Dilithium bounds check, and 1.12.1 (Feb 20 2026) four build or
arithmetic regressions. 1.12.0 (Jan 29 2026) opens the series and does add
features, confirming X.Y.0 bumps must stay outside the regex.

The libtool version-info in each NEWS heading is upstream's own ABI
record, and across the current series only the revision moves. One
deviation is worth disclosing from the previous series: 1.11.2 adds a
single enum constant, GCRY_KEM_RAW_P256R1, with current and age
incremented together so it stays backward compatible. Point releases here
are fixes-focused rather than absolutely fixes-only, with the deviation
bounded to additive constants.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: scarthgap took 1.10.3 -> 1.10.4, which needed a
build fix backported alongside it because 1.10.4 broke building with -O2
in the sysroot path. kirkstone has taken no in-series bump and stays at
1.9.4.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>

Adapted for wrynose: applied to libgcrypt_1.12.1.bb (upstream: libgcrypt_1.12.2.bb).
(cherry picked from commit 97caf8a110281becde5d888338712d71627cbf98)
---
 meta/recipes-support/libgcrypt/libgcrypt_1.12.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.12.1.bb b/meta/recipes-support/libgcrypt/libgcrypt_1.12.1.bb
index d7f8563ae6..d7b3e182cd 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.12.1.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.12.1.bb
@@ -32,7 +32,7 @@ SRC_URI[sha256sum] = "7df5c08d952ba33f9b6bdabdb06a61a78b2cf62d2122c2d1d03a91a798
 
 BINCONFIG = "${bindir}/libgcrypt-config"
 
-inherit autotools texinfo binconfig-disabled pkgconfig ptest
+inherit autotools texinfo binconfig-disabled pkgconfig ptest upstream-stable-release-point
 
 require recipes-support/gnupg/drop-unknown-suffix.inc
 

[wrynose][PATCH 15/20] sqlite3: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

SQLite cuts a per-minor maintenance branch for each release series,
branch-3.53 matching the current PV alongside branch-3.52, -3.51 and
-3.50, and tags patch releases off it. Superseded branches keep receiving
them: 3.44.5 and 3.42.1 were released in mid-2025, long after 3.50 was
current. So upgrades within a major.minor are stable point upgrades per
the OE-Core stable release policy (ref-manual, "Stable Point Release
Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/sqlite/sqlite/tree/branch-3.53

Checked the whole current series. 3.53.1 (May 05 2026) through 3.53.4 (Jul
24 2026) are almost entirely memory-safety and corruption-handling fixes:
five out-of-bounds reads, two buffer overreads or overwrites, two integer
overflows, hot-journal rollback with a zeroed super-journal record, safer
double-to-int64 conversion, and mutex acquisition added to a batch of
sqlite3_* entry points. 3.53.0 (Apr 09 2026) opens the series and does add
API surface, confirming X.Y.0 bumps must stay outside the regex.

Two additive exceptions in 3.53.4, neither touching the core library ABI:
the SQLITE_SHELL_EDITION compile-time option for the CLI, and
sqlite3_intck_register() in the incremental integrity-check extension.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone 3.38.2 -> 3.38.3 -> 3.38.5 and
scarthgap 3.45.1 -> 3.45.3. wrynose is at 3.51.3 with no in-series bump
yet.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(cherry picked from commit 22cd1dfc82049e47be5e73057c2f12cda036f352)
---
 meta/recipes-support/sqlite/sqlite3.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/sqlite/sqlite3.inc b/meta/recipes-support/sqlite/sqlite3.inc
index 94dbc38ec5..8791749dc8 100644
--- a/meta/recipes-support/sqlite/sqlite3.inc
+++ b/meta/recipes-support/sqlite/sqlite3.inc
@@ -21,7 +21,7 @@ UPSTREAM_CHECK_REGEX = "releaselog/(?P<pver>(\d+[\.\-_]*)+)\.html"
 
 CVE_PRODUCT = "sqlite"
 
-inherit pkgconfig siteinfo
+inherit pkgconfig siteinfo upstream-stable-release-point
 
 # enable those which are enabled by default in configure
 PACKAGECONFIG ?= "fts4 fts5 rtree dyn_ext"

[wrynose][PATCH 16/20] lttng-tools: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

lttng-tools maintains a branch per minor series (stable-2.11 through
stable-2.16) and tags point releases from it, releasing from more than one
at a time: 2.14.2 and 2.15.1 went out the same day. So upgrades within a
major.minor are stable point upgrades per the OE-Core stable release
policy (ref-manual, "Stable Point Release Upgrades"). There is no written
policy document, so qualification rests on the branch structure and the
release contents below.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/lttng/lttng-tools/blob/v2.15.1/ChangeLog
  https://github.com/lttng/lttng-tools/tree/stable-2.15

Upstream keeps a ChangeLog with a per-release entry list, and all 48
entries for 2.15.1 (Jun 05 2026, against 2.15.0 in February) are fixes,
tests, documentation or refactors. Seven address machine interface output
alone; the rest cover a consumerd lockfile fd leak across fork+exec, a
missing default kernel probe entry, an uninitialised read in uri_compare,
a musl compatibility fix, popt error handling, test fixes, and one
refactor preparing the CPU-mask escaping fix.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone took 2.13.4 -> 2.13.8 and 2.13.8 ->
2.13.9, scarthgap 2.13.11 -> 2.13.13. wrynose has taken none and sits at
2.14.1.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>

Adapted for wrynose: applied to lttng-tools_2.14.1.bb (upstream: lttng-tools_2.15.1.bb).
(cherry picked from commit 40f22582ff6989f9275808bfda229a8ec78504e4)
---
 meta/recipes-kernel/lttng/lttng-tools_2.14.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.14.1.bb b/meta/recipes-kernel/lttng/lttng-tools_2.14.1.bb
index 3a3f2cff2c..3df9ed1c00 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.14.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.14.1.bb
@@ -54,7 +54,7 @@ SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
 
 SRC_URI[sha256sum] = "0e68eb27923621c4bc127cfce40422d28cf7e473fedf6229ae6c32ba5c5b7c6d"
 
-inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
+inherit autotools ptest pkgconfig useradd python3-dir manpages systemd upstream-stable-release-point
 
 CACHED_CONFIGUREVARS = "PGREP=/usr/bin/pgrep"
 

[wrynose][PATCH 17/20] util-linux: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

util-linux's README ("Stable Branches") documents stable/v<major>.<minor>
branches whose maintenance releases are bug fixes only, so upgrades
within a major.minor are stable point upgrades per the OE-Core stable
release policy (ref-manual, "Stable Point Release Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/util-linux/util-linux/blob/v2.42.2/README#L95

Checked the last point release for feature creep:

  2.42.2 (Jun 16 2026), against 2.42.1 (May 18 2026): 32 commits, all
  fixes or hardening -- memory safety (a libblkid use-after-free, two
  buffer overflows, a libfdisk GPT fix), privilege tightening
  (X-mount.subdir restricted for non-root), diagnostics (fanotify queue
  overflow detection) and documentation. No new options or behaviour.

These releases are not picked up on the OE stable branches: util-linux has
had zero point-release bumps on kirkstone, scarthgap or wrynose since each
branch forked from master, leaving them at 2.37.4, 2.39.3 and 2.41.3
respectively. This addresses that gap going forward.

Scarthgap already has v2.39.3, and the 2.39.x stable branch history (mount
API regression fix in 2.39.1, new CPU model support, and libblkid’s bcachefs
handling) demonstrates that util-linux exercises good judgement in managing
stable branches, so we can safely track their stable series there as well.
For the avoidance of doubt it is not a development-series effect either:
util-linux has no development/stable version split, and pre-release work
goes to -rc tags.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

(cherry picked from commit d51c6e87a10c7c75a692ca86b71af9a818026ecb)
---
 meta/recipes-core/util-linux/util-linux.inc | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index aec8721ca3..aa1916f48e 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -25,3 +25,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-lin
 SRC_URI[sha256sum] = "f586e35d320ff537aab3ffeca37e9ecd482ccbe013590db4429a414d8aa6a728"
 
 CVE_PRODUCT = "util-linux"
+
+# util-linux publishes bugfix/security-only point releases on its
+# stable/v<major.minor> branches.
+inherit upstream-stable-release-point

[wrynose][PATCH 18/20] lttng-ust: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

lttng-ust maintains a branch per minor series (stable-2.13 through
stable-2.16) and releases from several at once: 2.14.2 and 2.15.1 went out
the same day in May 2026, and three series together in February, 2.13.10,
2.14.1 and 2.15.0. So upgrades within a major.minor are stable point
upgrades per the OE-Core stable release policy (ref-manual, "Stable Point
Release Upgrades"). There is no written policy document, so qualification
rests on that branch structure and the release contents below.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/lttng/lttng-ust/tree/stable-2.15

Upstream keeps a ChangeLog with a per-release entry list, and every entry
for the one point release in the current series is labelled a fix. 2.15.1
(May 22 2026) covers a negative error code on incorrect message size, a
shmp() return value checked before dereference, an underflow warning in
zero_file, uninitialised LTTNG_UST_LFILE and sigevent structs, close_range
inefficiency and excessive fd-tracker memory use, and a NULL check in
ustctl. The one non-fix entry changes a likely to unlikely branch hint.

Only one point release exists in the 2.15 series so far, so this also
rests on the 2.13 series' record, which ran to ten.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone took 2.13.5 -> 2.13.6 and scarthgap
2.13.7 -> 2.13.8 -> 2.13.10. wrynose has taken none and sits at 2.14.0.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Adapted for wrynose: applied to lttng-ust_2.14.0.bb (upstream: lttng-ust_2.15.1.bb).
(cherry picked from commit a5dcaef20fc91539efa08b47607c4c91f4f49849)
---
 meta/recipes-kernel/lttng/lttng-ust_2.14.0.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.14.0.bb b/meta/recipes-kernel/lttng/lttng-ust_2.14.0.bb
index 1a15c5b420..4285a445d6 100644
--- a/meta/recipes-kernel/lttng/lttng-ust_2.14.0.bb
+++ b/meta/recipes-kernel/lttng/lttng-ust_2.14.0.bb
@@ -11,7 +11,9 @@ PYTHON_OPTION = "am_cv_python_pyexecdir='${PYTHON_SITEPACKAGES_DIR}' \
                  PYTHON_INCLUDE='-I${STAGING_INCDIR}/python${PYTHON_BASEVERSION}${PYTHON_ABI}' \
 "
 
-inherit autotools lib_package manpages python3native pkgconfig
+# lttng-ust publishes bugfix/security-only releases on its per-minor
+# stable-X.Y branches, the same upstream and release model as lttng-tools.
+inherit autotools lib_package manpages python3native pkgconfig upstream-stable-release-point
 
 include lttng-platforms.inc
 

[wrynose][PATCH 19/20] babeltrace2: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

babeltrace2 maintains a branch per minor series (stable-2.0, stable-2.1)
and keeps the older one alive: 2.0.7 and 2.1.2 were released the same day
in July 2025, with 2.1.1 already out since April. So upgrades within a
major.minor are stable point upgrades per the OE-Core stable release
policy (ref-manual, "Stable Point Release Upgrades"). There is no written
policy document, so qualification rests on that branch structure and the
release contents below.

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/efficios/babeltrace/tree/stable-2.1

Upstream keeps a ChangeLog with a per-release entry list. Both point
releases in the current series are fixes, tests and documentation: 2.1.2
(Jul 22 2025) is 13 commits, and 2.1.1 (Apr 14 2025) 10.

Already tracked this way on the OE stable branches, counting only bumps
since each branch forked: kirkstone took 2.0.4 -> 2.0.5 and scarthgap
2.0.5 -> 2.0.6. wrynose has taken none and sits at 2.1.2.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3d742fa47d795b6b013d5ca3d78f0dd601432832)
---
 meta/recipes-kernel/lttng/babeltrace2_2.1.2.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.1.2.bb b/meta/recipes-kernel/lttng/babeltrace2_2.1.2.bb
index b0cd6efde1..5b9c02b0c2 100644
--- a/meta/recipes-kernel/lttng/babeltrace2_2.1.2.bb
+++ b/meta/recipes-kernel/lttng/babeltrace2_2.1.2.bb
@@ -19,7 +19,9 @@ SRC_URI = "git://git.efficios.com/babeltrace.git;branch=stable-2.1;protocol=http
 SRCREV = "d0e946a71faf5f0c2d7f1fb5b92a369983e9cf10"
 UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>2(\.\d+)+)$"
 
-inherit autotools pkgconfig ptest setuptools3-base
+# babeltrace2 publishes bugfix/security-only releases on its per-minor
+# stable-X.Y branches.
+inherit autotools pkgconfig ptest setuptools3-base upstream-stable-release-point
 
 EXTRA_OECONF = "--disable-debug-info --disable-Werror --enable-python-plugins --enable-python-bindings"
 

[wrynose][PATCH 20/20] lttng-modules: inherit upstream-stable-release-point

[daniel.turull]

From: Daniel Turull <daniel.turull@ericsson.com>

The LTTng project documents its stable-branch policy in README.md,
"Supported versions" at L171: fixes are backported to the last stable
version unless they would break the ABI or API, and security fixes to the
last two. So upgrades within a major.minor are stable point upgrades per
the OE-Core stable release policy (ref-manual, "Stable Point Release
Upgrades").

  https://docs.yoctoproject.org/dev/ref-manual/release-process.html#stable-point-release-upgrades
  https://github.com/lttng/lttng-modules/blob/v2.15.2/README.md#supported-versions
  https://github.com/lttng/lttng-modules/tree/stable-2.15

This recipe's policy differs from the rest of the project in one respect
worth stating. Where lttng-ust and lttng-tools do not backport new
features at all, L185 says kernel-version enablement is backported to the
last stable version. That is the only non-fix content a point release
carries, and for a kernel tracer it keeps existing probes working against
newer kernels rather than adding anything a user can call: no new options,
no new API, no changed defaults. Upstream labels these entries "fix:"
alongside the rest.

Six branches are maintained in parallel, stable-2.11 through stable-2.16,
and released from together: 2.14.6 and 2.15.2 the same day in June 2026,
2.14.5 and 2.15.1 in April, seven such days in the last two years.

The ChangeLog entries for the current series are fixes throughout. 2.15.2
(Jun 19 2026) is 13 entries: a leaked file and fd on channel create error,
plus twelve probe adjustments tracking kernel changes to ext4, btrfs, vfs,
vmscan and hrtimer tracepoints. 2.15.1 (Apr 24 2026) is three, covering
kallsyms on powerpc64 with ABI V1, a snd_soc_dapm_context move and a btrfs
probe range.

This recipe must share its minor version with lttng-ust and lttng-tools:
lttng-tools README.adoc L123 states it supports the kernel and user space
tracers "sharing the same _minor_ version", and that cross-version
combinations are untested. Pinning the regex to the minor is what keeps
that guarantee, permitting 2.15.x -> 2.15.y and excluding the 2.15 -> 2.16
bump that would need the three coordinated. Within a series they have
never moved together on any branch: taking modules, tools and ust in turn,
kirkstone ships 2.13.14, 2.13.9 and 2.13.6; scarthgap 2.13.12, 2.13.13 and
2.13.10; wrynose 2.14.4, 2.14.1 and 2.14.0. The minor agrees in every row
and the patch in none, and scarthgap has lttng-tools ahead of this recipe
rather than behind. There is no build dependency between them either.

Already tracked this way on the OE stable branches, and more thoroughly
than most: counting only bumps since each branch forked, kirkstone took
2.13.4 -> 2.13.5 -> 2.13.7 -> 2.13.8 -> 2.13.9 -> 2.13.14, scarthgap
2.13.9 -> 2.13.10 -> 2.13.11 -> 2.13.12, and wrynose 2.14.0 through
2.14.4. Each also carries local "fix build for kernel N" patches between
those bumps, which is the burden that staying current within a series
reduces.

AI-Generated: Kiro with Claude Opus 5
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Adapted for wrynose: applied to lttng-modules_2.14.4.bb (upstream: lttng-modules_2.15.2.bb).
(cherry picked from commit d4666244a51c7fb8fa7e66c11d91692197c89ce7)
---
 meta/recipes-kernel/lttng/lttng-modules_2.14.4.bb | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.14.4.bb b/meta/recipes-kernel/lttng/lttng-modules_2.14.4.bb
index b2c697d365..d0983f58cb 100644
--- a/meta/recipes-kernel/lttng/lttng-modules_2.14.4.bb
+++ b/meta/recipes-kernel/lttng/lttng-modules_2.14.4.bb
@@ -7,6 +7,12 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=018e002dbdda3306682e394ddd65fa32"
 
 inherit module
 
+# lttng-modules publishes bugfix/security-only releases on its per-minor
+# stable-X.Y branches. Point releases also carry kernel-version enablement,
+# which keeps existing probes working against newer kernels rather than adding
+# user-visible functionality.
+inherit upstream-stable-release-point
+
 include lttng-platforms.inc
 
 SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \