Build system health — reproducibility, CI speed, and upstream integration

[castrojo]

Summary

Dakota's build system is the foundation for everything else. This epic tracks work that improves reproducibility, reduces CI toil, and strengthens our relationship with upstream (fdsdk, gnome-build-meta, GNOME OS).

Child issues

• Build: date +%m breaks reproducibility and causes monthly cache misses #504 — Build: date +%m breaks reproducibility (P0)
• CI: deduplicate bst2 pin check and config generation into composite actions #503 — CI: deduplicate bst2 pin check into composite actions (P1)
• CI: auto-merge junction bumps from mergeraptor #501 — CI: auto-merge junction bumps from mergeraptor (P1)
• Patches: drop pipewire backports once fdsdk ships >= 1.6.1 #505 — Patches: drop pipewire backports once fdsdk ships >= 1.6.1
• chunkah: upstream fakecap-xattr for BuildStream xattr support #231 — chunkah: upstream fakecap-xattr for BuildStream xattr support
• Contribute signing stack to GNOME OS #403 — Contribute signing stack to GNOME OS
• Document Dakota as a reference architecture for GNOMEOS and bootc #404 — Document Dakota as a reference architecture for GNOMEOS and bootc
• Implement testing branch setup #55 — Implement testing branch setup

Definition of done

BST builds are byte-for-byte reproducible across runs. Junction bumps merge without human intervention. CI job duration under 5 minutes for validate. At least one upstream contribution merged.

Notes

#504 is a P0 blocker — monthly cache invalidation wastes ~60 min of CI time per run. Fix it first.

Dakota · issue pipeline

  ✓  triage     needs kind/ + area/ then /approve
  ·  discussing —
  ▶  queued     —
  ·  claimed    —
  ·  done       —

area: area/buildstream, area/ci   priority: priority/p1
maintainer: —
reporter: comment /claim to fix it yourself, or wait for a contributor

[github-actions]

✅ Approved. The community has found its way here.

Before this goes to the build queue it needs acceptance criteria — the spec a contributor or agent will implement against. Add it to the issue body, then apply needs-human/agent-ready to open it up.

Wranglers: write acceptance criteria, then comment /ready.