fix(kernel): narrow do_sign/do_deploy DISTRO_FEATURES vardep to secureboot

[HarryWaschkeit]

Problem

do_sign (recipes-kernel/linux/linux-common-secureboot.inc) and do_deploy (linux-phytec-fitimage.inc, from meta-phytec) each read the raw DISTRO_FEATURES string directly to check for secureboot membership:

python do_sign() {
    if "secureboot" in d.getVar('DISTRO_FEATURES'):

do_deploy:append() {
    if echo ${DISTRO_FEATURES} | grep -wq "secureboot"; then

BitBake's automatic vardep scanner ties both tasks' taskhash to the entire feature list, not just the secureboot flag. Because do_compile/do_configure/do_kernel_metadata/do_compile_kernelmodules have no sstate object of their own (only do_populate_lic, do_package*, do_populate_sysroot, do_packagedata, do_deploy participate in sstate for this recipe), any unrelated DISTRO_FEATURES change forces the entire kernel compile lineage to re-run for real on the next build — while do_package_write_ipk's own signature is untouched and gets served from an older cached sstate object.

Observed incident

In omnect-os-build/tauril2,gateway-devel build 107 (2026-07-10), the device_caps.json-driven DISTRO_FEATURES rework (#665 / e1ad988) changed DISTRO_FEATURES's value for unrelated wifi/bluetooth reasons. This invalidated do_sign/do_deploy's taskhash, forcing a fresh kernel rebuild (do_kernel_metadata → ... → do_compile_kernelmodules → do_deploy, all real executions, confirmed in the Concourse build log). Meanwhile do_package_write_ipk hit the shared sstate cache with an object from build 104. The result: the deployed kernel Image and the packaged kernel modules originated from two different kernel builds and failed to load on the device (module version magic mismatch, confirmed via uname -r vs. the modules directory name differing in their kernel-yocto merge-tree hash).

Fix

Add a derived SECUREBOOT_ENABLED variable and exclude the raw DISTRO_FEATURES var from do_sign/do_deploy's tracked vardeps, so their taskhash only changes when secureboot membership itself actually toggles — not on every unrelated DISTRO_FEATURES churn.

Scope / limitations

This closes the specific trigger seen in this incident. It does not fix the general architectural gap that do_package_write_ipk/do_populate_sysroot have no dependency on whether do_compile_kernelmodules was actually re-executed vs. served from sstate — a follow-up hardening this dependency directly is being considered separately.