26.8.0-trunk.42.0522.123522

fix(runners): handle missing HOME in systemd hooks for runner-clean-p…

26.8.0-trunk.26.0519.144616

desktops: run DE postinst scripts in build chroot (fix missing wallpa…

26.8.0-trunk.24.0519.101927

desktops: install libcamera/v4l userspace at minimal tier (#924)

Modern laptops with complex ISPs (Intel IPU3/6/7, Qualcomm Snapdragon
X) enumerate /dev/video* at the kernel level but require userspace
pipeline plumbing (libcamera + PipeWire camera shim + GStreamer
libcamera plugin) before any app can show a live image. Without
these packages, GNOME Snapshot / Cheese / Firefox / Chrome see no
camera even when one is physically present and the kernel module is
bound.

Add at minimal tier so the userspace stack is ready as soon as
upstream libcamera lands the right pipeline handler for a given
machine. Inert on machines without a camera - the daemons stay idle.

Verified across noble / resolute / trixie / bookworm at amd64
minimal - all three packages resolve cleanly.

Note: on bleeding-edge SKUs (e.g. ThinkPad X9-15 Gen 1, Lunar Lake
IPU7), the camera still won't work because upstream libcamera 0.7
lacks an IPU7 pipeline handler - Intel/Canonical ship those out of
tree. When that lands in mainline libcamera and propagates to
Debian/Ubuntu, every Armbian desktop install on these laptops will
just work on the next apt upgrade. This is the cheap pre-stage.

26.8.0-trunk.22.0518.222202

module_cockpit: drop qemu-kvm (no riscv64 build; qemu-system covers it)

Install failed on riscv64 with:
  Package qemu-kvm is not available, but is referred to by another package.
  ...
  E: Package 'qemu-kvm' has no installation candidate

qemu-kvm is a legacy x86-leaning meta package - Debian / Ubuntu only
publish it for amd64 (and historically arm64). On riscv64 there is no
qemu-kvm; the equivalent on every arch is qemu-system, which is
already in the package list right next to it. qemu-system is the
arch-agnostic meta that pulls in qemu-system-<host-arch>
(qemu-system-riscv64 on riscv64, qemu-system-x86 on amd64, etc.) -
exactly what libvirt + cockpit-machines need.

Drop qemu-kvm from both pkg_install and pkg_remove; functionality
unchanged on amd64/arm64, install now succeeds on riscv64.

26.8.0-trunk.20.0518.152834

runner-cleanup: auto-deploy the systemd hook layer alongside the timer

Extension of the event-driven cleanup added two commits ago. The
helper + installer were shipped but had to be deployed by hand.
Wire them into the runner-cleanup install path so a single
`armbian-config module_armbian_runners install` now puts everything
on the host in one shot:

  - /usr/local/sbin/runner-cleanup            (existing, hourly)
  - /etc/systemd/system/runner-cleanup.timer  (existing)
  - /usr/local/sbin/runner-clean-pages        (new, event-driven helper)
  - 10-clean-pages.conf drop-ins for every actions.runner.*.service
    (new, written by install-runner-hooks invocation)

The install-runner-hooks invocation runs AFTER daemon-reload so the
new drop-ins take effect on the next runner restart. Existing runner
units that started moments earlier in the same install pass don't
have the hooks active yet; they pick them up on their next restart
(operator or systemd-initiated). Hourly runner-cleanup keeps
covering the gap.

Non-fatal: install-runner-hooks failure prints a warning and the
runner-cleanup timer setup proceeds.

26.8.0-trunk.20.0518.152155

desktops: install alsa-ucm-conf at minimal tier

Without alsa-ucm-conf installed, PipeWire / wireplumber see complex
sound cards (Intel SOF on Lunar/Meteor/Panther Lake laptops, Qualcomm
Snapdragon X, AMD ACP DSP, ...) but have no per-machine recipe for
which PCM device is the speaker output, which controls to unmute, or
how to route on jack-insert. Result: kernel-level audio is fully
alive (aplay -l shows Speaker pcm; `speaker-test -D plughw:0,2`
plays), but GNOME / KDE Sound shows only "Dummy Output" and the
speakers stay silent.

Verified on a ThinkPad X9-15 Gen 1 (LNL, CS42L43 jack + CS35L56 SPI
amps): same kernel + same SOF firmware + same Cirrus blobs + same
topology as a working Ubuntu OEM 6.17 boot of the same machine - the
only difference between "silent" and "working" was this package.

Mirrored in build's uefi_common.inc (armbian/build#9858) to cover
image builds; here in common.yaml minimal tier so the runtime
`armbian-config module_desktops install` path picks it up on any
desktop / release / arch / DE combo. Inert on simpler audio chains
(HDMI-only SBCs, USB DAC).

26.8.0-trunk.20.0518.152048

gnome: drop fwupd plugin from noble (built into gnome-software there)

Noble's apt archive doesn't have a separate gnome-software-plugin-fwupd
package - fwupd integration is built into gnome-software itself.
The standalone .deb first appears in oracular (25.04) and is fully
present from resolute (26.04) onward. Listing it for noble made the
desktop install fail with "Unable to locate package".

Final per-release distribution of the GNOME Software stack:
  noble:     packagekit + gnome-software-plugin-flatpak + appstream
             (fwupd integration is internal to gnome-software)
  resolute:  packagekit + 2 plugins (flatpak + fwupd) + appstream

26.8.0-trunk.17.0517.212205

desktops: auto-enable fprintd in PAM after install

libpam-fprintd ships a /usr/share/pam-configs/fprintd fragment but
leaves it disabled - the user has to run `pam-auth-update` manually.
Default desktop installs should "just work" after enrolment, so
flip it on as part of the post-install cross-DE configure step,
right next to the netplan renderer switch.

Idempotent (pam-auth-update is a no-op when already enabled). Inert
on:
  - build mode (no real user yet)
  - hosts where fprintd wasn't installed (older tiers, arches
    stripped via tier_overrides)
  - missing pam-auth-update (raw chroots without the PAM stack)
  - hosts without a fingerprint reader (libpam-fprintd's PAM
    fragment falls back to password auth when no finger is enrolled)

After this, the only step a user needs is `fprintd-enroll`. The
PAM wiring is already there.

26.8.0-trunk.17.0517.204725

runner-cleanup: drop redundant age-based _diag prune

Section 2b in the housekeeping pass (added in PR #920, merged as
f8c6fda3) already wipes ~/_diag/ on every runner each tick:

  for user in "${runner_users[@]}"; do
      ...
      note "wipe ${user}/_diag"
      run find "$diag" -mindepth 1 -delete
  done

The older section 4c was left behind:

  for user in "${runner_users[@]}"; do
      ...
      log "prune ${user}/_diag (older than ${diag_days}d)"
      run find "${home}/_diag" -type f \
          \( -name 'Runner_*.log' -o -name 'Worker_*.log' -o -name '*.log.gz' \) \
          -mtime "+${diag_days}" -delete
  done

By the time 4c runs, section 2b has already emptied ~/_diag/, so 4c
finds nothing to delete — it just emits a misleading "prune ..." log
line. Visible in the verbose output as 16 _diag lines per pass: 8
"wipe" + 8 "prune".

Drop the 4c block entirely and renumber the following docker
container-log section from 4d to 4c.

26.8.0-trunk.17.0517.204032

runner-cleanup: wipe ~/_diag/ on every runner each pass

Follow-up to #919. The first round wiped _diag/pages/ only on idle
runners + only while the systemd unit was stopped. Two problems:

  - Tied to KEEP_RUNNERS_WORK whitelist - 01 is in there, so its
    _diag/pages/ never got cleared, and exactly that runner kept
    breaking with "Initialize containers" UUID collisions.

  - Limited to pages/ - the agent also accumulates Runner_*.log
    / Worker_*.log under ~/_diag/ directly. A runner host grows
    tens of GB of these over a few months.

This round: `find ~/_diag -mindepth 1 -delete` on every runner each
pass, regardless of busy/idle state and regardless of any whitelist.

Safe to wipe even while a job is running: Linux keeps the inode
alive as long as Runner.Listener / Runner.Worker hold the file
open; the agent keeps writing to its existing fd, and new jobs
create fresh files. Recent logs are reachable via the GitHub
Actions UI (workflow logs retained 90 days) so the on-disk copies
are duplicative for triage purposes.

Stale page-UUID files - the original trigger for #919 - are cleared
on the next hourly tick.