ci(build-kernel): support dbgsym packages and build qcom-rt flavour

[guanquan (GuanquanTian)]

Summary

• Add a dbgsym workflow input (default true, both workflow_dispatch and workflow_call) mapped to a DBGSYM env var and passed into the build container.

• Pass do_dbgsym_package=true/false to debian/rules based on DBGSYM (a standard Canonical kernel packaging switch already supported by debian/rules.d/).

• Collect and list *.ddeb alongside *.deb/*.changes/*.buildinfo, both inside the container and in the outer "Collect built packages" step.

• Add a Dbgsym row to the run summary table.

• Document the new dbgsym input in docs/PIPELINE.md.

• Build all kernel flavours (FLAVOR=all) instead of only qcom.

[Bjordis Collaku (bjordiscollaku)]

Nice, the dbgsym switch is handy and do_dbgsym_package is the right knob for it.

Two things to fix first. The "${TARGET}" quoting breaks the build: TARGET is two words, binary-qcom binary-indep, and 791b790 dropped the quotes on purpose when it added binary-indep. Quoted, make sees one goal named binary-qcom binary-indep and bails with "No rule to make target", so no linux-qcom-headers.

Second, the true default doesn't survive the nightly. On schedule: the inputs context is empty, so inputs.dbgsym is null, and GitHub casts null and false both to 0 for ==. null == false is true, so DBGSYM lands on 'false'. The cron build is the one that uploads to S3, so that's the build quietly losing dbgsym.

Separately, the S3 step uploads all of output/, so ddebs hit the bucket on any run without skip_s3. Default true is fine by me for dispatch and nightly. The premerge check however is in my #28, which hasn't landed yet, so it needs a change on that side as well: I'll have it pass dbgsym: false there so contributor builds skip the debug symbol work.

Couple of nits inline.

[Bjordis Collaku (bjordiscollaku)]

One more thing before this lands. Landing two flavours flat in .../${{ github.run_id }}-${{ github.run_attempt }}/ causes problems on the distro side, which expects artifacts per kernel variant: a single linux-image / linux-modules / linux-headers set at the location it points at.

I'd propose we give each variant its own prefix: qcom stays where it is so the current consumer is unaffected, the rt packages including the rt dbgsym go under rt/ in the same location, and the flavour-independent ones (linux-qcom-headers, linux-qcom-tools) stay at the top. Any flavour added later would follow the same pattern.

[Bjordis Collaku (bjordiscollaku)]

Checked the bucket, the rt/ split looks right.

One gap in it: rt/ has linux-headers-7.0.0-1006-qcom-rt but not linux-qcom-headers-7.0.0-1006, which that package depends on. debian.qcom/control.d/flavour-control.stub has linux-headers-PKGVER-ABINUM-FLAVOUR depending on SRCPKGNAME-headers-PKGVER-ABINUM, and that one is declared Architecture: all at source level in debian.qcom/control.stub.in, so there is a single copy per ABI shared by both flavours rather than one per flavour. It is already being built, it just stays at the top level since it does not match the -qcom-rt pattern in the collect step.

So nothing to change at build time. Could we copy (not move, qcom needs it too) linux-qcom-headers-7.0.0-1006_7.0.0-1006.8_all.deb into rt/ as well, so each variant folder is self-contained? Otherwise enabling headers for rt from the distro side fails on the missing dependency. Same likely applies to linux-qcom-tools-7.0.0-1006 if we ever install linux-tools-*-qcom-rt.