Migrate linux-pinetab2-danctnix-besser PKGBUILD into kernel-agent flow #5

Closed
opened 2026-05-09 11:01:14 +00:00 by marfrit · 0 comments
Owner

Context

The danctnix kernel for ohm (linux-pinetab2-danctnix-besser) is currently hand-managed across two parallel checkouts on boltzmann:

Path Remote Status
~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/kernel/ marfrit/besser umbrella canonical, PR #16 merged
~/src/besser/danctnix-besser-pkgbuild/kernel/ marfrit/linux-pinetab2-danctnix-besser (404, never created) orphan, fourier work landed here

The orphan was created by a sibling agent with git remote add pointing at a repo that was never POST /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_glb undefined — 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/ into patches/driver/bes2600/<series>/. Once that lands, kernel-agent generates 0001-bes2600-besser-cumulative-series.patch per build job by concatenating the series resolved from ohm's manifest scope driver:bes2600. No more hand-edited cumulative patch checked into a PKGBUILD repo.

PKGBUILD

Move linux-pinetab2-danctnix-besser/PKGBUILD to marfrit-packages/arch/linux-pinetab2-danctnix-besser/ (sibling to the existing arch/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 patch
  • pkgrel bumped per kernel-agent job
  • config stays a normal source file (still hand-managed for now; future issue if we want manifest-driven kconfig)
  • _srctag (kernel base version) read from manifest

Manifest

fleet/ohm.yaml includes scope driver:bes2600 plus the existing linux-pinetab2 upstream base. Patch series flagged promote_eligible: true get included; WIP series stay local until promoted via ka-promote.

Build / sign / install

Standard kernel-agent flow: build on kbuild-aarch64 (boltzmann), sign on hertz with marfrit-packages key, push to packages.reauktion.de, file [ka:installable], user runs ka-install ohm.

Orphan retirement

  • Don't delete ~/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.
  • After migration: canonical ~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/ and the orphan both retire; the kernel build lives in marfrit-packages/arch/linux-pinetab2-danctnix-besser/, fed by kernel-agent.

Considerations

  • Cumulative-patch generation order matters — current order is A, B, C v3, F, G, D, E, C2, c5.x, c6.x, c7, H. Manifest needs an explicit series-ordering field, not alphabetical sort. (Otherwise C2 and C v3 collide.)
  • DKMS coordination: 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."
  • bes_chardev merge regression (besser #17 root cause): cumulative-patch generation must NOT shell out to a Mobian-overlay copy of bes_chardev.{c,h}. The 1387-line proper-merge version is the source of truth; the Mobian-overlay 694-line version is a fossil. Add a sanity check (line count or sha) to the patch-gen step.
  • Two flavors per patch: per memory 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 a flavor: danctnix selector if both live in patches/driver/bes2600/<series>/.

Acceptance

  • marfrit-packages/arch/linux-pinetab2-danctnix-besser/PKGBUILD exists, builds via kernel-agent flow
  • fleet/ohm.yaml references driver:bes2600 scope with explicit series order + flavor: danctnix
  • First kernel-agent-driven build of linux-pinetab2-danctnix-besser succeeds 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
  • Orphan ~/src/besser/danctnix-besser-pkgbuild/ documented as decommissioned (after fourier migrates remaining work)
  • besser issue #17 closed by the new flow producing a clean build

References

  • besser issue #17 — the build fail that surfaced this (https://git.reauktion.de/marfrit/besser/issues/17)
  • besser PR #16 — the proper bes_chardev merge in canonical
  • Memory: reference_danctnix_besser_pkgbuild_canonical — orphan-vs-canonical detection recipe
  • Memory: feedback_bes2600_dual_tree_flavors — why two flavors per patch
  • Memory: project_danctnix_besser_deployed — current ohm deployment baseline
  • Depends on: #2 (patch-tree migration must land first)
## Context The danctnix kernel for **ohm** (`linux-pinetab2-danctnix-besser`) is currently hand-managed across two parallel checkouts on boltzmann: | Path | Remote | Status | |---|---|---| | `~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/kernel/` | `marfrit/besser` umbrella | canonical, PR #16 merged | | `~/src/besser/danctnix-besser-pkgbuild/kernel/` | `marfrit/linux-pinetab2-danctnix-besser` (404, never created) | orphan, fourier work landed here | The orphan was created by a sibling agent with `git remote add` pointing at a repo that was never `POST /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_glb` undefined — 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/` into `patches/driver/bes2600/<series>/`. Once that lands, kernel-agent generates `0001-bes2600-besser-cumulative-series.patch` per build job by concatenating the series resolved from ohm's manifest scope `driver:bes2600`. No more hand-edited cumulative patch checked into a PKGBUILD repo. ### PKGBUILD Move `linux-pinetab2-danctnix-besser/PKGBUILD` to `marfrit-packages/arch/linux-pinetab2-danctnix-besser/` (sibling to the existing `arch/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 patch - `pkgrel` bumped per kernel-agent job - `config` stays a normal source file (still hand-managed for now; future issue if we want manifest-driven kconfig) - `_srctag` (kernel base version) read from manifest ### Manifest `fleet/ohm.yaml` includes scope `driver:bes2600` plus the existing `linux-pinetab2` upstream base. Patch series flagged `promote_eligible: true` get included; WIP series stay local until promoted via `ka-promote`. ### Build / sign / install Standard kernel-agent flow: build on `kbuild-aarch64` (boltzmann), sign on hertz with marfrit-packages key, push to `packages.reauktion.de`, file `[ka:installable]`, user runs `ka-install ohm`. ### Orphan retirement - **Don't delete** `~/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. - After migration: canonical `~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/` and the orphan both retire; the kernel build lives in `marfrit-packages/arch/linux-pinetab2-danctnix-besser/`, fed by kernel-agent. ## Considerations - **Cumulative-patch generation order matters** — current order is A, B, C v3, F, G, D, E, C2, c5.x, c6.x, c7, H. Manifest needs an explicit series-ordering field, not alphabetical sort. (Otherwise C2 and C v3 collide.) - **DKMS coordination**: `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." - **bes_chardev merge regression** (besser #17 root cause): cumulative-patch generation must NOT shell out to a Mobian-overlay copy of bes_chardev.{c,h}. The 1387-line proper-merge version is the source of truth; the Mobian-overlay 694-line version is a fossil. Add a sanity check (line count or sha) to the patch-gen step. - **Two flavors per patch**: per memory `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 a `flavor: danctnix` selector if both live in `patches/driver/bes2600/<series>/`. ## Acceptance - [ ] `marfrit-packages/arch/linux-pinetab2-danctnix-besser/PKGBUILD` exists, builds via kernel-agent flow - [ ] `fleet/ohm.yaml` references `driver:bes2600` scope with explicit series order + `flavor: danctnix` - [ ] First kernel-agent-driven build of `linux-pinetab2-danctnix-besser` succeeds 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 - [ ] Orphan `~/src/besser/danctnix-besser-pkgbuild/` documented as decommissioned (after fourier migrates remaining work) - [ ] besser issue #17 closed by the new flow producing a clean build ## References - besser issue #17 — the build fail that surfaced this (`https://git.reauktion.de/marfrit/besser/issues/17`) - besser PR #16 — the proper bes_chardev merge in canonical - Memory: `reference_danctnix_besser_pkgbuild_canonical` — orphan-vs-canonical detection recipe - Memory: `feedback_bes2600_dual_tree_flavors` — why two flavors per patch - Memory: `project_danctnix_besser_deployed` — current ohm deployment baseline - Depends on: #2 (patch-tree migration must land first)
marfrit added this to the rollout milestone 2026-05-09 11:01:14 +00:00
Sign in to join this conversation.