Conversation
…SC-V This recipe depends on amazon-kvs-producer-sdk-c which depends on amazon-kvs-producer-pic. The amazon-kvs-producer-pic recipe is marked as incompatible with 32-bit ARM and RISC-V, so this recipe must also be marked as incompatible to avoid build failures. Fixes build failures in release PR #15252
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
…SC-V This recipe depends on amazon-kvs-producer-sdk-c which depends on amazon-kvs-producer-pic. The amazon-kvs-producer-pic recipe is marked as incompatible with 32-bit ARM and RISC-V, so this recipe must also be marked as incompatible to avoid build failures. Fixes build failures in release PR #15252
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
…SC-V This recipe depends on amazon-kvs-producer-sdk-c which depends on amazon-kvs-producer-pic. The amazon-kvs-producer-pic recipe is marked as incompatible with 32-bit ARM and RISC-V, so this recipe must also be marked as incompatible to avoid build failures. Fixes build failures in release PR #15252
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
The workflow was trying to checkout BitBake using Yocto release names (kirkstone, scarthgap, whinlatter) but BitBake uses version numbers (2.0, 2.8, 2.16) for its branches. Mapping per Yocto Project documentation: - kirkstone (4.0) → BitBake 2.0 - scarthgap (5.0) → BitBake 2.8 - whinlatter (5.3) → BitBake 2.16 - master → BitBake master This was causing all scarthgap/whinlatter builds to fail with: 'fatal: Remote branch scarthgap not found in upstream origin' Fixes build failures in release PRs #15252, #15254, #15255
The workflow was trying to checkout BitBake using Yocto release names (kirkstone, scarthgap, whinlatter) but BitBake uses version numbers (2.0, 2.8, 2.16) for its branches. Mapping per Yocto Project documentation: - kirkstone (4.0) → BitBake 2.0 - scarthgap (5.0) → BitBake 2.8 - whinlatter (5.3) → BitBake 2.16 - master → BitBake master This was causing all scarthgap/whinlatter builds to fail with: 'fatal: Remote branch scarthgap not found in upstream origin' Fixes build failures in release PRs #15252, #15254, #15255
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
The workflow was trying to checkout BitBake using Yocto release names (kirkstone, scarthgap, whinlatter) but BitBake uses version numbers (2.0, 2.8, 2.16) for its branches. Mapping per Yocto Project documentation: - kirkstone (4.0) → BitBake 2.0 - scarthgap (5.0) → BitBake 2.8 - whinlatter (5.3) → BitBake 2.16 - master → BitBake master This was causing all scarthgap/whinlatter builds to fail with: 'fatal: Remote branch scarthgap not found in upstream origin' Fixes build failures in release PRs #15252, #15254, #15255
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
The workflow was trying to checkout BitBake using Yocto release names (kirkstone, scarthgap, whinlatter) but BitBake uses version numbers (2.0, 2.8, 2.16) for its branches. Mapping per Yocto Project documentation: - kirkstone (4.0) → BitBake 2.0 - scarthgap (5.0) → BitBake 2.8 - whinlatter (5.3) → BitBake 2.16 - master → BitBake master This was causing all scarthgap/whinlatter builds to fail with: 'fatal: Remote branch scarthgap not found in upstream origin' Fixes build failures in release PRs #15252, #15254, #15255
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
The workflow was trying to checkout BitBake using Yocto release names (kirkstone, scarthgap, whinlatter) but BitBake uses version numbers (2.0, 2.8, 2.16) for its branches. Mapping per Yocto Project documentation: - kirkstone (4.0) → BitBake 2.0 - scarthgap (5.0) → BitBake 2.8 - whinlatter (5.3) → BitBake 2.16 - master → BitBake master This was causing all scarthgap/whinlatter builds to fail with: 'fatal: Remote branch scarthgap not found in upstream origin' Fixes build failures in release PRs #15252, #15254, #15255
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
The workflow was only uploading build logs, not test phase failure logs. This made it impossible to diagnose rootfs and testimage failures. Now uploads: - log.do_rootfs.* - Package installation failures - log.do_testimage.* - Test execution failures - testresults.json - Test results (if available) These logs are critical for debugging ptest package installation issues and test failures. Related: PR #15252 rootfs failure investigation
The workflow was only uploading build logs, not test phase failure logs. This made it impossible to diagnose rootfs and testimage failures. Now uploads: - log.do_rootfs.* - Package installation failures - log.do_testimage.* - Test execution failures - testresults.json - Test results (if available) These logs are critical for debugging ptest package installation issues and test failures. Related: PR #15252 rootfs failure investigation
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
The workflow was only uploading build logs, not test phase failure logs. This made it impossible to diagnose rootfs and testimage failures. Now uploads: - log.do_rootfs.* - Package installation failures - log.do_testimage.* - Test execution failures - testresults.json - Test results (if available) These logs are critical for debugging ptest package installation issues and test failures. Related: PR #15252 rootfs failure investigation
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
The workflow was only uploading build logs, not test phase failure logs. This made it impossible to diagnose rootfs and testimage failures. Now uploads: - log.do_rootfs.* - Package installation failures - log.do_testimage.* - Test execution failures - testresults.json - Test results (if available) These logs are critical for debugging ptest package installation issues and test failures. Related: PR #15252 rootfs failure investigation
rpcme
added a commit
that referenced
this pull request
Mar 9, 2026
The workflow was only uploading build logs, not test phase failure logs. This made it impossible to diagnose rootfs and testimage failures. Now uploads: - log.do_rootfs.* - Package installation failures - log.do_testimage.* - Test execution failures - testresults.json - Test results (if available) These logs are critical for debugging ptest package installation issues and test failures. Related: PR #15252 rootfs failure investigation
The test phase was failing with: ERROR: File .../core-image-minimal-*.rootfs.testdata.json not found This happens because testdata.json is generated during image build, but the test phase modifies IMAGE_INSTALL after the build phase. Solution: Force regeneration of testdata_json task before running testimage. This ensures the JSON reflects the actual packages in the test image.
Previous fix tried to run non-existent do_testdata_json task. The real issue: testdata.json is generated during image build when IMAGE_CLASSES += "testimage" is set. Since we modify IMAGE_INSTALL in the test phase (adding ptest packages), we must rebuild the image to regenerate testdata.json with the new package list. The rebuild will use sstate-cache so it's fast - only rootfs needs to be regenerated with the new packages.
Root cause: The image in sstate-cache was built WITHOUT IMAGE_CLASSES set, so testdata.json was never created. When test phase runs 'bitbake core-image-minimal', it finds the cached image and skips rebuild. IMAGE_CLASSES is set in build phase but image is never built there (only individual recipes). Test phase adds ptest packages and tries to build image, but BitBake uses cached rootfs from previous runs. Solution: Force do_rootfs with -f flag to ensure it rebuilds with: 1. IMAGE_CLASSES += "testimage" (from build phase conf) 2. New ptest packages in IMAGE_INSTALL (from test phase) 3. Generates testdata.json required by do_testimage
testdata.json is created by testimage class during do_image_complete, not do_rootfs. Running 'bitbake -c rootfs -f' rebuilds rootfs but doesn't trigger testimage class's testdata generation. Fix: Run 'bitbake -c image_complete -f' which includes rootfs AND the testimage class hooks that create testdata.json.
This was referenced Mar 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release Merge: master-next → master
Recipe Updates
Other Changes
Generated: 2026-03-09 13:49 UTC