feat: add cross-compilation support and Docker containerized builds for kernel packaging

[guanquan (GuanquanTian)]

Summary

This PR enhances the kernel build infrastructure with cross-compilation support and Docker containerization:

1. build-kernel-deb.sh improvements

   • Add cross-compilation support for building arm64 kernels on non-arm64 hosts via dpkg foreign architecture and gcc cross-toolchain
   • Support VERSION_SUFFIX parameter for traceable local builds with git commit hash (including special auto value)
   • Add SKIP_BUILD_DEP environment variable to skip dependency installation (useful for pre-built Docker images)
   • Improve artifact collection with version-based matching to avoid stale packages
   • Add do_skip_checks flag to bypass config-policy check for optional toolchains

2. docker-build-kernel.sh wrapper script

   • New Docker wrapper for containerized kernel builds
   • Auto-detect host architecture and select appropriate Docker image
   • Support SKIP_BUILD_DEP flag for bare Ubuntu images vs pre-built images

3. Documentation improvements

   • Add scripts/README.md with comprehensive setup instructions
   • Provide multiple usage examples showing partial parameters and environment variable usage

Features

• Native builds: arm64 host building arm64 kernels
• Cross-compilation: e.g., amd64 host building arm64 kernels
• Automatic changelog restoration: prevents dirty tree state
• Docker containerization: isolated build environment with preinstalled dependencies

[Bjordis Collaku (bjordiscollaku)]

Thanks for the substantial effort here. I want to be direct about the architecture first, because it is the thing that decides this PR.

This repository already has a reproducible, org-owned, containerized build: build-kernel.yml drives qualcomm-linux/docker-pkg-build and builds inside ghcr.io/qualcomm-linux/pkg-builder:<suite>. scripts/build-kernel-deb.sh is, by our own docs, a legacy local helper that no workflow references. This PR grows that legacy script into a second, parallel build system with its own image, its own registry, and its own build logic. Two build systems drift, and the one added here is anchored to a personal Docker image the rest of us cannot reproduce or reach.

So the ask at the top is a redesign, not a patch. I am supportive of improving how we build, but I would strictly propose we standardize on native arm64 builds rather than cross-compilation. Our official CI build, the one that produces the packages we generate the nightly images from, already runs natively on an arm64 runner, so native arm64 is the path our shipping artifacts come from. I would rather invest in that single path than take on a cross toolchain and a second build system to maintain alongside it, each with its own failure modes. If we keep a local convenience wrapper at all, it should target the same official pkg-builder image.

Blocking items are marked inline. Requesting changes.

[Bjordis Collaku (bjordiscollaku)]

Blocking. This hard-couples a public repository to one person's image: docker-registry.qualcomm.com/guanquan/kernel-build-docker. Three independent problems, each disqualifying on its own:

1. It is a personal namespace on an internal registry. This is an external, public PR. A contributor following scripts/README.md cannot pull this, and the script then hard-exits at the docker pull. The documented happy path is unreachable for the audience it is written for.
2. No Dockerfile ships with the PR. The image is opaque: we cannot audit its toolchain, rebuild it, or pin it. When this namespace is renamed or the tag is deleted, every documented build breaks with no recovery path. That is a bus factor of one.
3. It duplicates infrastructure we already own. CI builds in ghcr.io/qualcomm-linux/pkg-builder:<suite> via qualcomm-linux/docker-pkg-build.

Fix: do not introduce a second image. Default to the official pkg-builder image the CI already standardizes on. If a distinct toolchain is genuinely needed for cross builds, extend that image and check its Dockerfile into this repo under the org namespace, built in CI. A build image referenced by committed tooling must itself be defined by committed, reviewable source.

[Bjordis Collaku (bjordiscollaku)]

WORKSPACE_DIR resolves to the grandparent of the repo (scripts/../..), and line 132 bind-mounts that entire directory read-write into a container that runs as root. The mount scope is inferred from filesystem layout, not chosen by the user. Clone this repo directly into $HOME and you have handed a root process in an opaque image read-write access to your whole home directory: SSH keys, unrelated repos, all of it. It also only works inside the exact sibling-checkout layout the new README prescribes; a normal clone breaks SOURCE_DIR resolution.

Fix: mount only what the build needs. Bind the source tree and a dedicated output directory, nothing else, and run with --user "$(id -u):$(id -g)" so artifacts are not left root-owned on the host. Derive the source root from git -C "$SOURCE_DIR" rev-parse --show-toplevel, never from a fixed two-levels-up heuristic.

[Bjordis Collaku (bjordiscollaku)]

Ordering bug. debian/rules clean runs here, before apt-get build-dep below. For this tree, clean regenerates debian/control through the kernel packaging machinery, which needs fakeroot, dpkg-dev, kernel-wedge, rsync, and friends. Those are exactly the build dependencies that are not installed yet on the documented native path (SKIP_BUILD_DEP=0). The first thing this line does is call fakeroot, which does not exist until build-dep installs it, so the standalone path dies right here before it can install anything. The Docker path only survives because the prebaked image already contains these tools.

Fix: install the build prerequisites before clean, or gate the standalone path with a clear precondition. Better, drive the whole thing through dpkg-buildpackage, which orders this correctly and also emits the .changes and .buildinfo files that the collection step below globs for but never produces.

[Bjordis Collaku (bjordiscollaku)]

Two defects in one line. First, this hardcodes llvm-21-dev and anchors on exact spacing. sed returns success on a non-match, so the day this kernel bumps to llvm-22-dev, or debian/control is reindented, this silently no-ops and the cross build fails later with a message that never names the root cause. Second, this edit to debian/control is never reverted. The changelog edit above is carefully restored via the EXIT trap; control is not, and that trap is not even registered unless VERSION_SUFFIX is set. So the script's own promise that it "never leaves the tree dirty" is false for cross builds.

Fix: do not mutate a generated file with a version-pinned regex. Express the :native build-tool dependency in the packaging itself via build profiles, or derive the package name dynamically and hard-fail if the substitution changed nothing. And restore control on exit the same way changelog is, with the trap registered unconditionally.

[Bjordis Collaku (bjordiscollaku)]

This promotes a legacy, non-CI local script to a first-class, user-facing entry in the primary navigation, above INTEGRATION and PIPELINE. That misrepresents how this repository actually works. The model is mirror plus CI plus S3: the kernel is built by the pipeline and published to the bucket. Sending newcomers to a local build path that requires an unreachable personal image, and that (per scripts/README.md) then walks them into qdl hardware flashing, points people at the least reproducible path we have and frames it as the supported one.

Fix: do not advertise a local build as the user path. If this doc survives the architecture discussion at all, scope it to maintainer and debug use, and keep the index pointing users at the released packages and the pipeline.