Migrate linux-pinetab2-danctnix-besser PKGBUILD into kernel-agent flow #5
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
The danctnix kernel for ohm (
linux-pinetab2-danctnix-besser) is currently hand-managed across two parallel checkouts on boltzmann:~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/kernel/marfrit/besserumbrella~/src/besser/danctnix-besser-pkgbuild/kernel/marfrit/linux-pinetab2-danctnix-besser(404, never created)The orphan was created by a sibling agent with
git remote addpointing at a repo that was neverPOST /api/v1/orgs/.../repos'd. No CI, no pre-commit hook, no remote-side check caught the drift. The orphan accumulated fourier-campaign work (vb2_dma_resv RFC) that diverged from the canonical, and the divergence surfaced on 2026-05-09 as besser issue #17 (build fail,bes2600_chrdev_switch_subsys_glbundefined — Mobian-overlay bes_chardev.c got squashed into the cumulative patch).This is the shape of work kernel-agent exists to own: per-host kernel build with a scope-tagged patch tree, a single canonical PKGBUILD, no parallel-checkout drift.
Proposed setup
Patches (depends on #2)
Issue #2 migrates
besser/patches/intopatches/driver/bes2600/<series>/. Once that lands, kernel-agent generates0001-bes2600-besser-cumulative-series.patchper build job by concatenating the series resolved from ohm's manifest scopedriver:bes2600. No more hand-edited cumulative patch checked into a PKGBUILD repo.PKGBUILD
Move
linux-pinetab2-danctnix-besser/PKGBUILDtomarfrit-packages/arch/linux-pinetab2-danctnix-besser/(sibling to the existingarch/chromium-fourier, etc.). The PKGBUILD becomes a template that kernel-agent renders before each build:b2sums[4](cumulative patch) computed at job time from the regenerated patchpkgrelbumped per kernel-agent jobconfigstays a normal source file (still hand-managed for now; future issue if we want manifest-driven kconfig)_srctag(kernel base version) read from manifestManifest
fleet/ohm.yamlincludes scopedriver:bes2600plus the existinglinux-pinetab2upstream base. Patch series flaggedpromote_eligible: trueget included; WIP series stay local until promoted viaka-promote.Build / sign / install
Standard kernel-agent flow: build on
kbuild-aarch64(boltzmann), sign on hertz with marfrit-packages key, push topackages.reauktion.de, file[ka:installable], user runska-install ohm.Orphan retirement
~/src/besser/danctnix-besser-pkgbuild/— fourier has untracked working state there. Surface to Markus / fourier when the canonical move is ready, let them migrate any remaining work onto the kernel-agent flow first.~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/and the orphan both retire; the kernel build lives inmarfrit-packages/arch/linux-pinetab2-danctnix-besser/, fed by kernel-agent.Considerations
bes2600-dkms(Mobian fork) doesn't ship through this PKGBUILD — separate target. Once besser series lands upstream we drop both. Cross-ref issue #2's "DKMS-to-in-tree transition path."feedback_bes2600_dual_tree_flavors, each besser patch has Mobian-DKMS and danctnix-intree variants (different timer APIs). The danctnix flavor is what this PKGBUILD wants; the Mobian flavor goes to bes2600-dkms. Manifest needs aflavor: danctnixselector if both live inpatches/driver/bes2600/<series>/.Acceptance
marfrit-packages/arch/linux-pinetab2-danctnix-besser/PKGBUILDexists, builds via kernel-agent flowfleet/ohm.yamlreferencesdriver:bes2600scope with explicit series order +flavor: danctnixlinux-pinetab2-danctnix-bessersucceeds end-to-end (build → sign → installable →ka-install ohm→ verify)~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/archived with a README pointer to the new home~/src/besser/danctnix-besser-pkgbuild/documented as decommissioned (after fourier migrates remaining work)References
https://git.reauktion.de/marfrit/besser/issues/17)reference_danctnix_besser_pkgbuild_canonical— orphan-vs-canonical detection recipefeedback_bes2600_dual_tree_flavors— why two flavors per patchproject_danctnix_besser_deployed— current ohm deployment baseline