Skip to content

ci: make the bundled DKMS module list a matrix field - #89

Open
Christopher Obbard (obbardc) wants to merge 1 commit into
mainfrom
wip/obbardc/dkms-matrix-array
Open

ci: make the bundled DKMS module list a matrix field#89
Christopher Obbard (obbardc) wants to merge 1 commit into
mainfrom
wip/obbardc/dkms-matrix-array

Conversation

@obbardc

@obbardc Christopher Obbard (obbardc) commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

The set of out-of-tree DKMS modules bundled into the kernel image is currently fixed by the packaging branch alone so it cannot differ per kernel variant or delivery.

Add a list "dkms" field to every matrix row, carrying "kgsl" for all variants today as per the existing packaging. resolve-matrix.sh validates it (module names without the -dkms suffix, no commas, no duplicates) and joins it into a comma-separated string, exactly as it already does for kernel_config. daily.yml and release.yml thread it through as the new dkms input of build-kernel-deb.yml, which passes it to prepare-source.sh as --dkms when non-empty.

This is the sister-PR of #90; both are needed to land at the same time.

The set of out-of-tree DKMS modules bundled into the kernel image is
currently fixed by the packaging branch alone so it cannot differ per
kernel variant or delivery.

Add a list "dkms" field to every matrix row, carrying "kgsl" for
all variants today as per the existing packaging. resolve-matrix.sh
validates it (module names without the -dkms suffix, no commas, no
duplicates) and joins it into a comma-separated string, exactly as it
already does for kernel_config. daily.yml and release.yml thread it
through as the new dkms input of build-kernel-deb.yml, which passes it
to prepare-source.sh as --dkms when non-empty.

Signed-off-by: Christopher Obbard <[email protected]>
@bjordiscollaku

Copy link
Copy Markdown
Contributor

prepare-source.sh on the packaging branch has no --dkms case and its parser exits on an unknown option. Since every row here carries ["kgsl"], DKMS_INPUT is never empty and --dkms is always appended, so this takes out every leg at Prepare rather than just some. Same shape as the #83/#86 pair, it needs a partner on qcom/debian/latest before either can land.

On keying it by distro family: dkms as a flat row field cannot get there, qcom-next Daily has trixie, forky and resolute in the one row. resolve-matrix.sh looks like the right place, since it already flattens to one entry per suite so it can classify and emit the right joined string with nothing downstream changing. Worth knowing prepare does not needs: resolve, so the family output from build-kernel-deb.yml is not reachable from the job that runs prepare-source.sh. If you do it in the flattener, maybe lift the suite case out of the resolve job into a small ci/scripts helper so it is not defined twice?

Third thing, for whatever consumes --dkms on the packaging side: control.in hardcodes dkms, kgsl-dkms, so Build-Depends wants templating from the same list. Otherwise a row with a different list still pulls the hardcoded deps and fails at apt before the bundler runs. Kills the control.in / dkms-modules hand-sync at the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants