| Summary: |
RRS: upgrade history hangs parsing OE-Core 3c00ad5d3b (OEEquivHash without BB_HASHSERVE) |
| Product: |
[Yocto Project Subprojects] Recipe Reporting System (RRS)
|
Reporter: |
Tim Orling <tim.orling> |
| Component: |
Recipe Reporting System (RRS) | Assignee: |
Tim Orling <tim.orling> |
| Status: |
IN PROGRESS REVIEW
---
|
QA Contact: |
|
| Severity: |
normal
|
|
|
| Priority: |
Medium+
|
|
|
| Version: |
unspecified | |
|
| Target Milestone: |
6.2 M2 | |
|
| Hardware: |
All | |
|
| OS: |
Multiple | |
|
| Whiteboard: |
|
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|
Verified:
|
|
Documentation change:
|
Don't know
|
rrs_upgrade_history.py stalls indefinitely when it reaches OE-Core commit 3c00ad5d3b ("build-appliance-image: Update to master head revisions", 2026-02-27). OE-Core 5596ea156d ("bitbake.conf: Switch BB_SIGNATURE_HANDLER to OEEquivHash by default") changed the default signature handler, and BB_HASHSERVE ??= "auto" was only added in the following commit, 4a388406ac ("bitbake.conf: Set BB_HASHSERVE alongside BB_SIGNATURE_HANDLER"). 3c00ad5d3b is the only commit in between that touches a recipe, so RRS parses it. Parsing it fails in meta/lib/oe/sstatesig.py with: ERROR: OEEquivHash requires BB_HASHSERVE to be set The error is raised in the BitBake server during tinfoil setup, and the BitBake of that period (bc8be83aef) doesn't return it to the client, so upgrade_history_internal.py never exits. run_internal() ignores non-zero exits and would move on, but it has no timeout, so the whole run stalls until it is killed. On layers.moto-timo.net it sat idle for ~7.5 hours. The layer index parse configuration (conf/local.conf) doesn't need hash equivalence at all. Since 4a388406ac, OE-Core master also starts a local hashserv for every layer index / RRS parse. Proposed fix: set BB_SIGNATURE_HANDLER = "OEBasicHash" in layerindex-web's conf/local.conf. This fixes the bad revision and avoids the per-parse hashserv on current master. Possible follow-up: add a per-commit timeout to run_internal() so any future hang becomes a logged failure instead of stalling the run.