Feature parity — capabilities users expect from a daily driver

[castrojo]

Summary

Dakota aims to be a full daily-driver desktop. This epic tracks gaps where users expect a feature that works on standard Fedora or Bluefin but is missing or broken on Dakota.

Child issues

• Parity: Podman Desktop kubectl setup failure #430 — Parity: Podman Desktop kubectl setup failure
• Feature parity: add kernel / library bits to make Virtual Machine Manager flatpak or command line equivalent work #399 — Parity: VMM flatpak missing kernel/library bits
• Feature parity: no way to persistently add kernel parameters #362 — Parity: no way to persistently add kernel parameters
• Parity: user account dinosaur icons are missing #353 — Parity: user account dinosaur icons are missing
• Login Keyring not unlocked when you log in after a reboot. #301 — Login keyring not unlocked after reboot
• Can not automount second hard drive #237 — Cannot automount second hard drive
• Feature: Zen Mode for focused work #333 — Feature: Zen Mode for focused work
• Docker on Dakota via brew #207 — Docker on Dakota via brew

Definition of done

All child issues are closed or explicitly deferred. Dakota runs a week as a primary machine without workarounds.

Notes

Parity issues are type/parity — each needs a standalone fix in the image element or a ujust recipe. Hardware-specific issues track separately under Epic #493.

Dakota · issue pipeline

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

area: —   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.