Skip to content

feat(Makefile): Add kernel build integration and local APT repo support#325

Open
abickett wants to merge 2 commits intoqualcomm-linux:mainfrom
abickett:kernel-integration
Open

feat(Makefile): Add kernel build integration and local APT repo support#325
abickett wants to merge 2 commits intoqualcomm-linux:mainfrom
abickett:kernel-integration

Conversation

@abickett
Copy link
Copy Markdown
Contributor

Added makefile target "kernel-deb" for use of build-linux-deb script, linked to setup of the local apt repo for kernel installation. Added DEBOS_ARGS as well.

This allows for a simple developer flow, like the following images I built for Glymur:

make kernel-deb USE_QCOM_NEXT=yes 
make rootfs.tar DEBOS_ARGS="-t gnomedesktop:true"
make disk-sdcard.img DEBOS_ARGS="-t dtb:qcom/glymur-crd.dtb"

The handling of the different cases for kernel branch building is a bit clunky, but I think may also help toward enabling makefile use also in CI with some tweaking.

abickett added 2 commits March 5, 2026 22:39
…nux' path

The merge_config.sh and olddefconfig steps were using cwd="linux"
hardcoded, while the rest of the script correctly uses cwd=linux_dir.
This means --local-dir with any path other than ./linux would silently
run config steps in the wrong directory.

Fixes a regression introduced in commit 89bdaa0 (linux: Add support to
build kernel from local path).

Signed-off-by: Adam Bickett <abickett@qti.qualcomm.com>
Add comprehensive kernel package building with local APT repository:
- Add kernel-deb target to build kernel packages using build-linux-deb.py
- Add KERNEL_PACKAGE variable for automatic local APT repo integration
- Set up local APT repository with apt-ftparchive for kernel packages
- Support resuming interrupted kernel builds by reusing existing linux/ clone
- Add linux/ directory to clean target

Fix APT sources format for flat repositories:
- Change 'Suites: /' to 'Suites: ./' in rootfs recipe
- This is the correct format for flat APT repositories without dists/

This mirrors the CI workflow where kernel debs are placed in a local APT
repo so debos can install them by package name.

Signed-off-by: Adam Bickett <abickett@qti.qualcomm.com>
@github-actions
Copy link
Copy Markdown

Test Results

 2 files  ±0   6 suites  ±0   3m 32s ⏱️ ±0s
20 tests ±0  20 ✅ ±0  0 💤 ±0  0 ❌ ±0 
64 runs  ±0  64 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 4a8aae2. ± Comparison against base commit 63c8215.

@github-actions
Copy link
Copy Markdown

Test jobs for commit 4a8aae2

Copy link
Copy Markdown
Contributor

@lool lool left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

And sorry, I started a review last week, but it seems I didn't send it, or tried to and had some network issues; here are my notes!

Types: deb
URIs: file:///media/apt-local-repo
Suites: /
Suites: ./
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Thanks for the fix!) That should be its own commit; I'm curious what problem you ran into (since apt install works in our CI)!

# provide defaults that work for us as universally as we can manage.
FAKEMACHINE_BACKEND = $(shell [ -c /dev/kvm ] && echo kvm || echo qemu)
DEBOS_OPTS := --fakemachine-backend $(FAKEMACHINE_BACKEND) --memory 1GiB --scratchsize 6GiB
DEBOS_ARGS ?=
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shoot, that will likely conflict with #319

$(DEBOS_CMD) $(DEBOS_ARGS) -t imagetype:sdcard $<

# Kernel build variables - override to build a specific kernel
KERNEL_REPO ?= https://github.com/torvalds/linux
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I don't think we should duplicate the list of kernel git URLs, default branch etc. between the kernel building script and the Makefile. We can argue where it should live, but let's keep only one.

The kernel build script is fairly dumb, except for picking the latest tag. For qcom-next, I specifically received guidance that I should be using the highest qcom-next-date tag as some kind of release of qcom-next, even if other changes are landing daily in tip. I wouldn't want to do that from shell or – worse – from a Makefile :)

Personally, I think it makes sense to keep a short list of "well-known" kernels in build-linux-deb.py, but it's probably not scalable to mirror every script option with a Makefile option. Perhaps we do like debos, and just have a LINUX_OPTS (can't think of a good name) that lets one pass --qcom-next etc.?

The last tricky thing is the .config fragments. With this script, we always want to use some upstream defconfig, sometimes some tree-specific configs (in qcom-next: prune.config, qcom.config), qcom-deb-images wants to pass a number of config fragments, and I can guess users might want some extra ones too. The defaults could be set in the Makefile instead of github workflows, and perhaps we provide a way to override and/or extend, like with DEBOS.

rm -f disk-sdcard.img1 disk-sdcard.img2 disk-sdcard.img
rm -f rootfs.tar
rm -f dtbs.tar.gz
rm -f disk-*.img disk-*.img.gz disk-*.img[0-9]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how, but I think you're reverting changes from tip?

rm -f rootfs.tar
rm -f dtbs.tar.gz
rm -f disk-*.img disk-*.img.gz disk-*.img[0-9]
rm -rf rootfs/
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah do we need this?

rm -f disk-*.img disk-*.img.gz disk-*.img[0-9]
rm -rf rootfs/
rm -rf linux/
rm -rf $(LOCAL_APT_REPO)/
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason, the / makes me uncomfortable; I kind of fear this expands to rm -rf /; perhaps leave the trailing / out on this one.

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