Yocto License Checksums: Review a Changed Text Range Before Accepting a New Digest
A source upgrade inserts three introductory lines above a license header. The license wording stays the same, but a Yocto recipe's LIC_FILES_CHKSUM fails. If the recipe hashes a line range, the old numbers can now select the wrong bytes. Before accepting the reported digest, reconstruct the exact selection that produced it.
This is a source-text checkpoint, separate from the checksum that validates a downloaded archive. The procedure below follows Yocto Project 5.0.12 and the examined Scarthgap QA implementation.
Locate the file in the recipe's source context
The license-tracking guide explains that relative license-file paths are resolved using S. An entry can instead identify an explicit location such as a file under WORKDIR.
Inspect the effective S and LIC_FILES_CHKSUM in bitbake -e sensor-agent, replacing the recipe name. Find the actual file in the source tree used by the task. An upstream archive can change its top-level directory or move a notice to another file without changing the recipe's old reference.
Treat a missing-file diagnostic separately from a mismatching digest. No amount of recalculating the expected checksum repairs a path that identifies no file. Conversely, an existing file with the same basename may contain a different notice after an upstream reorganization.
Reconstruct the selected interval
A hypothetical entry containing beginline=5;endline=16 selects twelve lines: numbering starts at one and both endpoints are included. If the unchanged notice moved to lines eight through nineteen, the old interval now includes three preceding lines and omits three final lines.
Use a numbered view of the actual source file to locate both the old interval and the intended complete notice. Do not choose a shorter range merely because it excludes the text that changed. The selection should continue to represent the license material the recipe is meant to track.
The syntax explanation also defines omitted endpoints: without a beginning, selection starts at the file's first line; without an ending, it extends through the last line. With neither, the whole file is tracked.
Hash the same bytes rather than a normalized display
The examined QA checksum code reads a ranged selection in binary mode and updates MD5 with each selected line's bytes. It does not normalize whitespace before computing that digest.
For a small diagnostic script, binary readlines() followed by the Python slice [4:16] reproduces the selection corresponding to lines five through sixteen. Join those byte strings without inserting new separators, then calculate MD5. Apply this to the actual task input, not a text editor's re-saved copy. This is an illustrative calculation, not a reported build result.
Line-ending changes can therefore alter the digest even when a displayed notice looks identical. So can trailing spaces. Compare bytes when a visual diff shows no explanation, and distinguish a formatting change from a moved selection or changed wording.
The same QA implementation can shorten the license excerpt printed in a failure message according to QA_MAX_LICENSE_LINES. An ellipsis in that diagnostic is not part of the hashed file, and a shortened display is not the complete selection. Open the underlying file to inspect the omitted middle.
Check the extracted evidence as well as the pass result
The examined license-file copying code also uses the configured line bounds when copying a selected notice. Incorrect bounds can therefore affect the extracted license evidence, not merely whether the checksum passes.
After determining the intended interval, compare the old and new selected text. If the notice only moved, update the range and verify the resulting bytes. If wording changed, have that actual difference evaluated through the project's license-review process before changing the expected digest.
Rebuild the affected recipe and inspect the extracted notice for completeness. Passing QA with a checksum of the wrong paragraph is technically possible; the meaningful result is a correct file, a justified interval and a digest tied to the complete text that interval was intended to represent.
