ci(build-kernel): inject DTB capsule certs and fix build-dep

[guanquan (GuanquanTian)]

Add DTB capsule certificate injection from GitHub Secrets and fix build-dep resolution order.

1. Inject DTB capsule certificates from GitHub Secrets

   • Add step to inject FMPCERT, FMPROOT, and FMPSUB certificates into debian.qcom/certs/ during kernel build
   • Enables DTB capsule package generation with proper signing
   • Certificates are securely handled with set +x to prevent exposure in logs
   • File permissions set to 600 for security

2. Resolve build-dep against local debian/control

   • Move apt-get build-dep call after debian/rules clean generates the real debian/control
   • Ensures qcom-specific Build-Depends (u-boot-tools, device-tree-compiler) are installed
   • Previously resolved against archive's generic "linux" source package, missing qcom-specific dependencies

[Bjordis Collaku (bjordiscollaku)]

Thanks for sharing this, this is a pretty extensive mechanism, however noting that is baked into the packaging metadata, not separate / independent. The sole reason of creating this repo was to align completely with canonical packaging, that is, ideally, we DO NOT touch their packaging metadata AT ALL. That's why even for versioning, I implemented a build time mechanism , so that metadata is intact.

If we really need to adapt / implement a capsule update mechanism, it just can not be baked into the metadata, kernel packaging should still remain 100% intact as it came from canonical, and the capsule update might be a dedicated mechanism living separately, generating a dtb product which ON Target, upon kernel update, is fired, and handles the update.

[Shoudi Li (shoudil)]

Thanks for sharing this, this is a pretty extensive mechanism, however noting that is baked into the packaging metadata, not separate / independent. The sole reason of creating this repo was to align completely with canonical packaging, that is, ideally, we DO NOT touch their packaging metadata AT ALL. That's why even for versioning, I implemented a build time mechanism , so that metadata is intact.

If we really need to adapt / implement a capsule update mechanism, it just can not be baked into the metadata, kernel packaging should still remain 100% intact as it came from canonical, and the capsule update might be a dedicated mechanism living separately, generating a dtb product which ON Target, upon kernel update, is fired, and handles the update.

As synced, let's check with canonical firstly and see what comment/input canonical have.