On Fri, 2026-08-07 at 10:45 +0100, Paul Barker wrote: > On Fri, 2026-07-31 at 14:25 +0200, [email protected] wrote: > > From: Daniel Turull <[email protected]> > > > > 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. > > > > This addresses the general case on master, where PV is 2.42.x. Since the > > regex is derived from PV, an older branch scopes it to that branch's series, > > and the 2.39 series scarthgap ships does not qualify. 2.39 adopted the new > > kernel mount API, so 2.39.1 introduced > > LIBMOUNT_FORCE_MOUNT2={always,never,auto} as, in its own words, "a stable > > workaround for use cases where new kernel API is not ready to use"; the > > series also took new CPU model support and libblkid bcachefs sub-device > > label probing. That is a property of the 2.39 series rather than of the > > project -- 2.42.2 is 32 commits of pure fixes -- but it means this must not > > be backported unchanged, and each branch's series needs checking on its own. > > 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 <[email protected]> > > Hi Daniel, > > We merged the rest of this series but skipped this patch as I wanted to > take a closer look at that last paragraph above. > > Scarthgap already has v2.39.3, so API fixes in 2.39.1 aren't really an > issue. However, reading the 2.39.1 release notes it aimed to "resolve > the regression that occurred due to the v2.39 rewrite for the new kernel > mount interface" which sounds like a valid fix for me. Supporting new > CPU models is low risk and likely wanted by many users of our stable > branches anyway. And allowing libblkid to handle bcachefs' version > scheme and sub-device labels is low risk and a sensible way to handle > what was still a moving target. > > So I'd say util-linux have shown good judgement in managing a stable > branch and we should be able to track any of their stable branches. > > Please send a v2 with an updated commit message if you agree with my > conclusions.
I agree with your conclusions. I'll send a v2 for only this one. I'm waiting to send series 3 until all what I sent is merged (for series 1 and 2). I was hopping to have more components that will have stable branches, but most are single track. Best regards, Daniel > > Best regards, >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#242999): https://lists.openembedded.org/g/openembedded-core/message/242999 Mute This Topic: https://lists.openembedded.org/mt/120533279/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
