Yocto Project Status 18 November 2025 (WW46)

Yocto Project Status 18 November 2025 (WW46)

[Stephen K Jolley]

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

Current Dev Position: YP 5.3 M4 - Stabilization and Final Build/Release

Next Deadline: YP 5.3 M4 Build Date 2025-11-10

Next Team Meetings:

   -

   Bug Triage meeting - Thursday Nov. 20th 7:30 am PDT (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync  - Tuesday Nov. 18th 8 am PDT (
   https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
   <https://zoom.us/j/990892712>
   -

   Yocto Project Patch Review - Thursday  Nov. 18th 10am GMT and Monday
   Nov. 24th 9am PDT (
   https://zoom.us/j/97762397148?pwd=1xk0iC9hp9SjEonaTaONwTb6iWry4Eb.1
   <https://zoom.us/j/97762397148?pwd=1xkiC9hp9SjEonaTaONwTb6iWry4Eb.1>)


Project data dashboard: https://dashboard.yoctoproject.org/

Key Status/Updates:

   -

   YP 4.0.31 was released.
   -

   YP 5.0.14 is in QA.
   -

   The final 5.3 build is still pending on resolving some rough edges on
   bitbake-setup. The patches so far have made a huge difference, thanks
   everyone who helped!
   -

   We aim to build 5.3 when the remaining identified issues with
   bitbake-setup are resolved:
   -

      Improvements to the default build directory path (json format string?)
      -

      Handling potential MACHINE/DISTRO conflict between conf/env and
      feature settings
      -

      Comments to toolcfg.conf about how to change
      -

      Mention "bitbake-config-build enable-fragment machine/XXX" in
      bitbake-setup output
      -

      Remove/change broken template files from meta-yocto
      -

   Other potential changes that have been discussed but don’t have workable
   patches yet:
   -

      defaulting to a common sstate directory and hashequiv server
      -

      Allowing symlinking of local existing repos into the build instead of
      fetching
      -

   There are likely going to be breaking changes to the npm fetcher related
   to ongoing security concerns but we are lacking patches.


Ways to contribute:

   -

   As people are likely aware, the project has a number of components which
   are either unmaintained, or have people with little to no time trying to
   keep them alive. These components include: devtool, toaster, wic, oeqa,
   autobuilder, CROPs containers, pseudo and more. Many have open bugs. Help
   is welcome in trying to better look after these components!
   -

   There is an issue open upstream with the openssl project related to
   making path relocation of openssl easier (as used in our buildtools tarball
   and SDK). We’d love assistance in moving this forward and getting some kind
   of upstream feature merged to make this easier:
   https://github.com/openssl/openssl/pull/19260
   -

   There are bugs identified as possible for newcomers to the project:
   https://dashboard.yoctoproject.org/bugtriage/#newcomer-container
   -

   There are bugs that are currently unassigned for YP 5.3. See:
   https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium+_5.3_Unassigned_Enhancements/Bugs
   -

   We’d welcome new maintainers for recipes in OE-Core. Please see the list
   at:
   http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
   and discuss with the existing maintainer, or ask on the OE-Core mailing
   list. We will likely move a chunk of these to “Unassigned” soon to help
   facilitate this.
   -

   Help is very much welcome in trying to resolve our autobuilder
   intermittent issues. You can see the list of failures we’re continuing to
   see by searching for the “AB-INT” tag in bugzilla:
   https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
   -

   Help us resolve CVE issues: CVE metrics
   <https://autobuilder.yocto.io/pub/non-release/patchmetrics/>
   -

   We have a growing number of bugs in bugzilla, any help with them is
   appreciated.
   -

   Regarding bugs, even if you can’t fix a bug, submitting a failing test
   case that can reproduce the issue significantly improves the chances it
   might get fixed.
   -

   Further help on optimizing build disk usage would be most welcome.
   -

   Ongoing project development plans are being developed in this document:
   https://docs.google.com/document/d/1xsnN_HcaMhqg6Dn1P_19AnumDaUMQSdFZ_I4rjD830A/edit?usp=sharing

We need to continue to develop this as it will allow us to potentially find
ways to fund specific work items.

Tracking Metrics:

   -

   WDD 2943 (last week 3048) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   OE-Core/Poky Patch Metrics
   -

      Total patches found: 1066 (last week 1067)
      -

      Patches in the Pending State: 175 (16%) [last week 153 (14%)]
      -

      https://autobuilder.yocto.io/pub/non-release/patchmetrics/


YP 5.3 Milestone Dates:

   -

   YP 5.3 M4 Build Date 2025-11-10
   -

   YP 5.3 M4 Release Date 2025-11-28


YP 6.0 Milestone Dates:

   -

   YP 6.0 M1 Build Date 2026-01-05
   -

   YP 6.0 M1 Release Date 2026-01-16
   -

   YP 6.0 M2 Build Date 2026-02-02
   -

   YP 6.0 M2 Release Date 2026-02-13
   -

   YP 6.0 M3 Build Date 2026-03-02
   -

   YP 6.0 M3 Release Date 2026-03-13
   -

   YP 6.0 M4 Build Date 2026-03-30
   -

   YP 6.0 M4 Release Date 2026-04-26


Upcoming dot releases:.

   -

   YP 4.0.31 was released.
   -

   YP 5.0.14 is in QA.
   -

   YP 4.0.32 Build Date 2025-12-15
   -

   YP 4.0.32 Release Date 2025-12-24
   -

   YP 5.0.15 Build Date 2026-01-05
   -

   YP 5.0.15 Release Date 2026-01-16
   -

   YP 5.3.1 Build Date 2026-01-12
   -

   YP 5.3.1 Release Date 2026-01-23
   -

   YP 4.0.33 Build Date 2026-01-26
   -

   YP 4.0.33 Release Date 2026-01-30
   -

   YP 5.0.16 Build Date 2026-02-09
   -

   YP 5.0.16 Release Date 2026-02-20
   -

   YP 5.3.2 Build Date 2026-02-16
   -

   YP 5.3.2 Release Date 2026-02-27
   -

   YP 4.0.34 Build Date 2026-02-23
   -

   YP 4.0.34 Release Date 2026-03-06
   -

   YP 5.3.3 Build Date 2026-03-09
   -

   YP 5.3.3 Release Date 2026-03-20
   -

   YP 5.0.17 Build Date 2026-03-16
   -

   YP 5.0.17 Release Date 2026-03-23
   -

   YP 4.0.35 Build Date 2026-04-06
   -

   YP 4.0.35 Release Date 2026-04-17
   -

   YP 5.3.4 Build Date 2026-04-13
   -

   YP 5.3.4 Release Date 2026-04-24
   -

   YP 5.0.18 Build Date 2026-04-20
   -

   YP 5.0.18 Release Date 2026-05-01
   -

   YP 5.0.19 Build Date 2026-05-26
   -

   YP 5.0.19 Release Date 2026-06-05


The Yocto Project’s technical governance is through its Technical Steering
Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

The Status reports are now stored on the wiki at:
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on this
weekly status update, let us know!]

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(    *Cell*:                (208) 244-4460

* *Email*:                 *s
<stephen.k.jolley@intel.com>jolley.yp.pm@gmail.com <jolley.yp.pm@gmail.com>*

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

Re: [OE-core] Yocto Project Status 18 November 2025 (WW46)

[Alexander Kanavin]

On Tue, 18 Nov 2025 at 16:55, Stephen Jolley via
lists.openembedded.org
<sjolley.yp.pm=gmail.com@lists.openembedded.org> wrote:
> Patches in the Pending State: 175 (16%) [last week 153 (14%)]
>
> https://autobuilder.yocto.io/pub/non-release/patchmetrics/

These both seem to have rolled back to about one year ago and show
situation as of 2024-10.

Alex

Re: [OE-core] Yocto Project Status 18 November 2025 (WW46)

[Alexander Kanavin]

On Tue, 18 Nov 2025 at 16:55, Stephen Jolley via
lists.openembedded.org
<sjolley.yp.pm=gmail.com@lists.openembedded.org> wrote:
> We aim to build 5.3 when the remaining identified issues with bitbake-setup are resolved:
...
> Other potential changes that have been discussed but don’t have workable patches yet:
>
> defaulting to a common sstate directory and hashequiv server

I looked into this a bit. The key question is how would the lifecycle
of such a server be managed (e.g. what starts the server and what
shuts it down, since we don't want to leave users with mysterious,
dangling processes doing nothing).

I think a workable approach would be this:

- bitbake invocations would continue to start (and stop) private
server processes that are accessed through a unix socket inside their
respective build directories
- such invocations would be configured to use a *shared* sqlite
database that is inside bitbake-setup's top directory
- sqlite documentation gives reassurances that this is okay:
https://sqlite.org/faq.html#q5

An alternative would be to somehow manage a common, single server, but
I just can't figure out how to do it automatically, and without fuss
and complications. Something has to start it, something has to shut it
down. It must be available when any bitbake invocation from any setup
directory happens. Users should not have to issue special magic
commands to make it work. I think sharing the database is far easier.

So the particular nomenclature for this would be:

BB_HASHSERVE = "auto-shared-database" (e.g. start and stop the server
automatically, but configure it to use a common database file, unlike
'auto' which keeps the database private to a build directory)
BB_HASHSERVE_SHARED_DB = "/path/to/common/hashserv.db"

bitbake-setup would put this (and SSTATE_DIR) into site.conf that is
symlinked into every build.

Terrible idea? Tell me :)

Alex

sharing sstate in bitbake-setup

[Alexander Kanavin]

On Tue, 25 Nov 2025 at 14:54, Alexander Kanavin via
lists.yoctoproject.org <alex.kanavin=gmail.com@lists.yoctoproject.org>
wrote:
> BB_HASHSERVE_SHARED_DB = "/path/to/common/hashserv.db"
>
> bitbake-setup would put this (and SSTATE_DIR) into site.conf that is
> symlinked into every build.

I quickly hacked bitbake's cooker.py to try this out:

-                dbfile = (self.data.getVar("PERSISTENT_DIR") or
self.data.getVar("CACHE")) + "/hashserv.db"
+                dbfile = "/home/alex" + "/hashserv.db"


And then made two build directories with shared SSTATE_DIR.

TL;DR: everything ran smoothly and as expected.

I ran overlapping builds, added no-ops to gnu-config recipe to 'force'
hash equivalency, and there were no errors or crashes, and sstate was
reused as expected.

So I think we should do it like this, subject to 'shared-sstate'
setting in bitbake-setup, on by default.

Alex

Re: sharing sstate in bitbake-setup

[Richard Purdie]

On Wed, 2025-11-26 at 17:13 +0100, Alexander Kanavin wrote:
> On Tue, 25 Nov 2025 at 14:54, Alexander Kanavin via
> lists.yoctoproject.org <alex.kanavin=gmail.com@lists.yoctoproject.org>
> wrote:
> > BB_HASHSERVE_SHARED_DB = "/path/to/common/hashserv.db"
> > 
> > bitbake-setup would put this (and SSTATE_DIR) into site.conf that is
> > symlinked into every build.
> 
> I quickly hacked bitbake's cooker.py to try this out:
> 
> -                dbfile = (self.data.getVar("PERSISTENT_DIR") or
> self.data.getVar("CACHE")) + "/hashserv.db"
> +                dbfile = "/home/alex" + "/hashserv.db"
> 
> 
> And then made two build directories with shared SSTATE_DIR.
> 
> TL;DR: everything ran smoothly and as expected.
> 
> I ran overlapping builds, added no-ops to gnu-config recipe to 'force'
> hash equivalency, and there were no errors or crashes, and sstate was
> reused as expected.
> 
> So I think we should do it like this, subject to 'shared-sstate'
> setting in bitbake-setup, on by default.

PERSISTENT_DIR is *not* designed to be shared between builds. it might
happen to work but is a really bad idea. Personally, I think those
cache directory variables and cache layout need redesigning so we
should probably take the opportunity to do that.

Cheers,

Richard

Re: sharing sstate in bitbake-setup

[Alexander Kanavin]

On Wed, 26 Nov 2025 at 17:41, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
linked into every build.
> >
> > I quickly hacked bitbake's cooker.py to try this out:
> >
> > -                dbfile = (self.data.getVar("PERSISTENT_DIR") or
> > self.data.getVar("CACHE")) + "/hashserv.db"
> > +                dbfile = "/home/alex" + "/hashserv.db"
> >
> >
> > And then made two build directories with shared SSTATE_DIR.
> >
> > TL;DR: everything ran smoothly and as expected.
> >
> > I ran overlapping builds, added no-ops to gnu-config recipe to 'force'
> > hash equivalency, and there were no errors or crashes, and sstate was
> > reused as expected.
> >
> > So I think we should do it like this, subject to 'shared-sstate'
> > setting in bitbake-setup, on by default.
>
> PERSISTENT_DIR is *not* designed to be shared between builds. it might
> happen to work but is a really bad idea. Personally, I think those
> cache directory variables and cache layout need redesigning so we
> should probably take the opportunity to do that.

I am not sharing PERSISTENT_DIR. Only the hash equivalency database in
hashserv.db, which I believe is fine because sqlite has locking
mechanisms and is explicitly designed for it.

Alex

Re: sharing sstate in bitbake-setup

[Daniel Chaves]

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

Hi, Alexander, if your goal is to share hash equivalence data through a
database, you might follow the "Hash Equivalence Server Setup" instructions
here:
https://docs.yoctoproject.org/dev/_sources/dev-manual/hashequivserver.rst.txt
.

Make sure to look at the `bind` and `database` options used when starting `
bitbake-hashserv`. Then, on the client side, the configuration would look
something like this:

```
BB_HASHSERVE = "<bind address of the running BitBake hash server>"
BB_SIGNATURE_HANDLER = "OEEquivHash"
```

So, in that scenario the site.conf for Bitbake Setup could enable a bind
address of `unix://${TOPDIR}/../hashserv.sock` to the BB_HASHSERVE.

And the server can be started with something like:

`bitbake-hashserv --bind unix://${TOPDIR}/../hashserv.sock --database
${TOPDIR}/../hashserv.db`



RidgeRun Embedded SW Engineer
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: https://www.ridgerun.com

-- 
This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be 
proprietary, privileged, or copyrighted under applicable law. If you are 
not the intended recipient, do not read, copy, or forward this email 
message or any attachments, delete this email message and any attachments 
immediately.

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

Re: sharing sstate in bitbake-setup

[Daniel Chaves]

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

Hi, Alexander, I saw your question about integrating the hash equivalence
server setup into Bitbake Setup. I've have actually tinkered with the basic
hash equivalence setup, and after diving into the documentation for the
hash equivalence looks like we could share hash equivalence data through
following the "Hash Equivalence Server Setup" instructions here:
https://docs.yoctoproject.org/dev/_sources/dev-manual/hashequivserver.rst.txt
.

Look at the `bind` and `database` options used when starting `
bitbake-hashserv`. Then, on the client side, the configuration would look
something like this:

```
BB_HASHSERVE = "<bind address of the running BitBake hash server>"
BB_SIGNATURE_HANDLER = "OEEquivHash"
```

So, in that scenario the site.conf for Bitbake Setup could enable a bind
address of `unix://${TOPDIR}/../hashserv.sock` to the BB_HASHSERVE.

And the server can be started with something like:

`bitbake-hashserv --bind unix://${TOPDIR}/../hashserv.sock --database
${TOPDIR}/../hashserv.db`

Hope that helps.
Regards
Daniel

RidgeRun Embedded SW Engineer
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: https://www.ridgerun.com

-- 
This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be 
proprietary, privileged, or copyrighted under applicable law. If you are 
not the intended recipient, do not read, copy, or forward this email 
message or any attachments, delete this email message and any attachments 
immediately.

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

Re: [OE-core] sharing sstate in bitbake-setup

[Daniel Chaves]

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

Hi, Alexander, I saw your question about integrating the hash equivalence
server setup into Bitbake Setup. I've have actually tinkered with the basic
hash equivalence setup, and after diving into the documentation for the
hash equivalence looks like we could share hash equivalence data through
following the "Hash Equivalence Server Setup" instructions here:
https://docs.yoctoproject.org/dev/_sources/dev-manual/hashequivserver.rst.txt
.

Look at the `bind` and `database` options used when starting `
bitbake-hashserv`. Then, on the client side, the configuration would look
something like this:

```
BB_HASHSERVE = "<bind address of the running BitBake hash server>"
BB_SIGNATURE_HANDLER = "OEEquivHash"
```

So, in that scenario the site.conf for Bitbake Setup could enable a bind
address of `unix://${TOPDIR}/../hashserv.sock` to the BB_HASHSERVE.

And the server can be started with something like:

`bitbake-hashserv --bind unix://${TOPDIR}/../hashserv.sock --database
${TOPDIR}/../hashserv.db`

Hope that helps.
Regards
Daniel

RidgeRun Embedded SW Engineer
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: https://www.ridgerun.com


On Wed, Nov 26, 2025 at 10:53 AM Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:

> On Wed, 26 Nov 2025 at 17:41, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> linked into every build.
> > >
> > > I quickly hacked bitbake's cooker.py to try this out:
> > >
> > > -                dbfile = (self.data.getVar("PERSISTENT_DIR") or
> > > self.data.getVar("CACHE")) + "/hashserv.db"
> > > +                dbfile = "/home/alex" + "/hashserv.db"
> > >
> > >
> > > And then made two build directories with shared SSTATE_DIR.
> > >
> > > TL;DR: everything ran smoothly and as expected.
> > >
> > > I ran overlapping builds, added no-ops to gnu-config recipe to 'force'
> > > hash equivalency, and there were no errors or crashes, and sstate was
> > > reused as expected.
> > >
> > > So I think we should do it like this, subject to 'shared-sstate'
> > > setting in bitbake-setup, on by default.
> >
> > PERSISTENT_DIR is *not* designed to be shared between builds. it might
> > happen to work but is a really bad idea. Personally, I think those
> > cache directory variables and cache layout need redesigning so we
> > should probably take the opportunity to do that.
>
> I am not sharing PERSISTENT_DIR. Only the hash equivalency database in
> hashserv.db, which I believe is fine because sqlite has locking
> mechanisms and is explicitly designed for it.
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#226806):
> https://lists.openembedded.org/g/openembedded-core/message/226806
> Mute This Topic: https://lists.openembedded.org/mt/116487236/7043332
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> dchvs11@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

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

Re: [OE-core] sharing sstate in bitbake-setup

[Alexander Kanavin]

On Sat, 6 Dec 2025 at 04:31, Daniel Chaves <dchvs11@gmail.com> wrote:
> Hi, Alexander, I saw your question about integrating the hash equivalence server setup into Bitbake Setup. I've have actually tinkered with the basic hash equivalence setup, and after diving into the documentation for the hash equivalence looks like we could share hash equivalence data through following the "Hash Equivalence Server Setup" instructions here:
> https://docs.yoctoproject.org/dev/_sources/dev-manual/hashequivserver.rst.txt.
>
> Look at the `bind` and `database` options used when starting `bitbake-hashserv`. Then, on the client side, the configuration would look something like this:
>
> ```
> BB_HASHSERVE = "<bind address of the running BitBake hash server>"
> BB_SIGNATURE_HANDLER = "OEEquivHash"
> ```
>
> So, in that scenario the site.conf for Bitbake Setup could enable a bind address of `unix://${TOPDIR}/../hashserv.sock` to the BB_HASHSERVE.
>
> And the server can be started with something like:
>
> `bitbake-hashserv --bind unix://${TOPDIR}/../hashserv.sock --database ${TOPDIR}/../hashserv.db`

Hello Daniel,

the mechanics of configuring and starting the server are not the
problem. The problem is how to do it in bitbake-setup workflows such
that users don't need to know or care: no separate configuration,
separate commands or leftover background processes. It should just
work, quietly and without fuss. I have some ideas (around sharing the
database between servers started privately by bitbake invocations (if
BB_HASHSERVE is "auto")), just need to sit down and write patches.

Alex