26.2.0-trunk.832.0502.212243

ci/maintenance-unit-tests: stop+rm long-up named test-service containers

Tests that exercise module_postgres / module_redis / module_immich
(and friends) spawn long-running service containers — postgres,
postgres-immich, mysql, redis — and only call `remove` if the test
reaches that stage. An interrupted test (or one that only does
install) leaves them wedged on the runner; the diagnostic step on
this branch's first run showed postgres-immich and mysql with
'Up 7 days', and a `postgres` container in 'Created' state for 8h
because its 5432 publish was held by the older one.

Add a second cleanup block to both diagnostic steps, ahead of the
orphaned-Created sweep, that stop+rm's exactly these four names if
they have been *running for more than 2 hours*. The threshold is
the safety knob: native job timeout-minutes is 90, emulated 210
(3.5h), so 2h sits comfortably below "test still in flight" and
well above "leftover from a prior run". Anything younger is left
alone — the next slot's start will pick it up if needed.

Implementation:

  * Names are exact-match anchored ('^name$') so a future sibling
    like 'mysql-readonly' or 'postgres-staging' isn't caught.
  * Stopped / Created containers are deliberately skipped here —
    the orphaned-Created sweep below uses the bare-hash filter
    and handles them safely.
  * Uptime via 'docker inspect ... .State.StartedAt' → 'date -d'
    → epoch math. GNU date is standard on Linux runners.
  * 'docker stop --time 30' gives postgres / mysql a chance to
    flush the WAL before SIGKILL; '|| true' on each docker call
    so a transient hiccup doesn't fail the test slot.
  * Output is one line per name ('absent', 'recent <2h (skip)',
    'stopped (skip — orphan sweep handles below)', or
    'stop+rm: <name> (up Xh)') so the GHA log shows exactly which
    containers were touched and why.

Runs *before* the orphaned-Created sweep so a freshly-stopped
service isn't briefly seen as orphan in the same pass.

Same block in both gradle-native and gradle-emulated diagnostic
steps so the cleanup fires on both runner hosts (the arm64 host
is only seen by native; the amd64 host is seen by both).

26.2.0-trunk.832.0502.205256

ci/maintenance-unit-tests: clean orphaned 'Created' containers

Replace the placeholder comment in both diagnostic steps with a
narrow cleanup: containers in 'Created' state whose Image column
is a bare 12-char hex ID (no repo:tag). These are leftovers from
prior runs where the underlying image was already removed but the
container record stayed wedged. The arm64 self-hosted runner had
12 of them visible in the first diagnostic run, oldest 2 months.

Pattern:

    docker ps -a --filter 'status=created' \
        --format '{{.ID}} {{.Image}}' \
      | awk '$2 ~ /^[0-9a-f]{12}$/ { print $1 }' \
      | xargs -r docker rm

Tagged-image-but-'Created' containers are deliberately not in
scope. The runner host also runs the operator's home services
(postgres-immich, mysql, wireguard, openssh-server, swag) and a
'Created' state with a tagged image can be a mid-'docker create'
in flight on those — only the bare-hash form is unambiguously
orphan.

xargs -r no-ops on empty input so the step doesn't error when
there's nothing to clean; '|| true' so a transient docker hiccup
on the host doesn't fail the test slot.

Other cleanups deliberately not added here:

  * ghcr.io/armbian/repository-update:*-<arch> images that aren't
    in use — would race sibling matrix slots that still need them
    mid-run. Belongs in the 'stop' job once it lands.
  * 62 GB of dangling volumes per the diagnostic — too risky to
    auto-prune; the operator needs to spot-check the mountpoints
    before running 'docker volume prune'. Manual one-off.

Both gradle-native and gradle-emulated diagnostic steps get the
same cleanup so the arm64 host (only seen by native) and the
amd64 host (seen by both) both have orphans removed.

26.2.0-trunk.831.0502.154013

`Automatic` documentation update

26.2.0-trunk.831.0502.152506

desktops/bianbu: purge gnome-initial-setup after install

Bianbu's GNOME stack pulls gnome-initial-setup as a dependency, which
makes the GNOME first-run "Welcome" wizard run on first GUI boot,
prompting the user to create an account / pick locale / sign into a
GNOME Online Account. Armbian images already do their own first-boot
setup via the firstrun service (account, locale, keyboard, network),
so the GNOME wizard is redundant and lands the user in a confusing
two-prompts-for-the-same-thing experience.

Add gnome-initial-setup to bianbu.yaml's minimal-tier
packages_uninstall list. The list is already wired end-to-end:

  parse_desktop_yaml.py:296   collects per-tier packages_uninstall
  parse_desktop_yaml.py:319   emits DESKTOP_PACKAGES_UNINSTALL
  module_desktops.sh:657      pkg_remove $DESKTOP_PACKAGES_UNINSTALL
                              (autopurge — also drops orphaned deps)

Runs in build mode too: the purge is part of the install action,
not the postinst (the latter is skipped under CI/container env).
The 2>/dev/null || true at the call site keeps a missing
gnome-initial-setup from failing the install — for any future
release where Bianbu drops the dep, this entry becomes a no-op
rather than a regression.

26.2.0-trunk.831.0502.123706

desktops/bianbu: re-enable systemd suspend on K1

SpacemiT's stock Bianbu image ships a /etc/systemd/sleep.conf with
`AllowSuspend=no`, so on a freshly installed Bianbu desktop the
GNOME suspend menu entry, `systemctl suspend`, and the lid-close
action all fail with:

    Call to Suspend failed: Sleep verb 'suspend' is disabled by config

Suspend actually works on shipped K1 boards (verified on Musebook)
— SpacemiT just gates it off, presumably to avoid edge-case
resume failures on boards / firmware revisions where it isn't yet
solid. For users running the Armbian Bianbu build the desktop UX
expectation is that the suspend button does something, so drop a
sleep.conf.d/ override re-enabling it.

The override goes into /etc/systemd/sleep.conf.d/ rather than
modifying the SpacemiT-shipped /etc/systemd/sleep.conf so an
upgrade of the bianbu-* package set won't undo it, and so a user
who hits resume problems on a different K1 board can simply remove
the single drop-in to fall back to SpacemiT's default behaviour.

No daemon-reload is issued — logind re-reads sleep.conf on each
suspend call, so the override is live on first boot regardless,
and skipping the reload avoids disturbing running units in the
chrooted build-time environment where this postinst also runs.

26.2.0-trunk.831.0502.115510

desktops: pass --allow-downgrades on pinned package install

Bianbu image build (armbian/os run 25250450338) failed at the
chrooted `module_desktops install de=bianbu tier=mid mode=build`
call with:

    The following packages will be DOWNGRADED:
       libdrm-common libdrm2
    E: Packages were downgraded and -y was used without --allow-downgrades.
    Error: bianbu package install failed; aborting before any system state is changed

The downgrade is exactly what bianbu.yaml's per-package APT pin asks
for — priority 1001 against archive.spacemit.com pulls Bianbu's
older `libdrm2 / libdrm-common` over the distro's newer ones so the
whole Mesa stack stays on the SpacemiT BSP version. apt resolves
correctly; it just refuses to act with `-y` alone because the result
includes downgrades, by design.

Add `--allow-downgrades` to the three desktop pkg_install call sites
that run with the per-DE pin in effect:

  - module_desktops.sh: main DESKTOP_PACKAGES install
  - module_desktops.sh: display-manager install
  - module_desktops.sh: tier-upgrade install (set-tier path; pin still
    in place during cross-tier package adds)

The flag is a no-op for DEs whose YAML carries no pin (apt only
resolves to a downgrade when explicitly directed to), so this is
scoped to the install path that benefits without touching pkg_install
itself or any other apt user.

Skipped: the armbian-plymouth-theme install on the live-system path
(specific Armbian-archive package, no pin-driven downgrade scenario)
and the global `_module_desktops_write_apt_pin` path which targets
apt.armbian.com snap-shim packages (the existing 1001 priority on
that pin already requires --allow-downgrades de facto, but that pin
has been working as-is for years — it acts on packages where the
distro version is a stub, not a real older build, so apt's resolution
doesn't classify the swap as a downgrade).

26.2.0-trunk.831.0502.103927

desktops: detect installed DE via marker file, add Bianbu menu entries

`module_desktops status de=<X>` is the gate every Desktops submenu
entry runs to decide whether to show its "Uninstall / Disable login /
Change tier" actions. The check was a plain
`dpkg -l "$DESKTOP_PRIMARY_PKG" | grep ^ii`, which misfires whenever
two desktops share a primary-tier package — most notably on a Bianbu
install, where bianbu-desktop-minimal-en pulls gnome-session as a
dependency. The Desktops menu would then offer "Uninstall GNOME" and
"Change GNOME to full" while the actual installed DE is Bianbu, and
clicking them would tear down packages Bianbu owns.

Three coupled changes, since fixing detection without also rounding
out the Bianbu menu would leave a Bianbu user with an empty submenu
and only a single mid-tier install entry where every other DE
exposes minimal/mid/full:

1. Introduce _module_desktops_is_installed and route the three
   status callers (status, tier, at-tier) through it. Three layers,
   falling through in order:

     a. /etc/armbian/desktop/<de>.tier exists → installed.
        Authoritative because install/remove maintain the marker.
     b. A different DE has its marker present → not installed. The
        other DE's marker is the tiebreaker against the dpkg
        fallback when desktops share packages.
     c. No markers anywhere AND DESKTOP_PRIMARY_PKG is dpkg-installed
        → legacy installs that pre-date the marker convention or
        were done with apt directly.

2. Add the standard six management entries for Bianbu in
   config.system.json (Uninstall, autologin on/off, tier
   minimal/mid/full), gated on `module_desktops status de=bianbu`,
   so the submenu has actual options once the GNOME entries
   correctly hide. IDs allocated as BIAN02/03/04/07/08/09 to match
   the slot numbers used by the other DEs.

3. Bring Bianbu's install entries in line with the rest of the menu:
   BIAN01 was the only Bianbu install slot and was misnamed —
   labelled "Install Bianbu" with tier=mid, where every other DE's
   slot 01 is minimal. Repoint BIAN01 to tier=minimal and add BIAN05
   (mid) and BIAN06 (full) so the user sees the full minimal/mid/full
   choice on a clean install instead of just one entry.

26.2.0-trunk.797.0424.134951

`Automatic` documentation update

26.2.0-trunk.797.0424.130907

config.system: add Bianbu to the desktop install menu

bianbu has a complete YAML definition under
tools/modules/desktops/yaml/bianbu.yaml (SpacemiT K1 RISC-V
desktop, riscv64 on noble/resolute, pinned SpacemiT archive)
and wires up through module_desktops install like every other
DE. But the DE install menu is populated from hardcoded entries
in tools/json/config.system.json, and bianbu was simply never
added — so on a riscv64 image there was no way to reach it from
armbian-config.

Add a single-tier entry (tier=mid — full DE + bianbu-standard +
k1x-cam, the intended out-of-box experience) alongside the other
community DEs (kde-neon/budgie/deepin/enlightenment). The
`module_desktop_supported bianbu` condition already gates on the
YAML's architectures list, so the entry auto-hides everywhere
except riscv64 noble/resolute.

26.2.0-trunk.797.0424.105535

desktops: install libv4l-0 before rockchip-multimedia packages

rockchip-multimedia-config's postinst expects the V4L2 userspace library to
already be present. Mirror the ordering from armbian/build's
extensions/mesa-vpu.sh by doing a separate pkg_install of libv4l-0 between
pkg_update and the rockchip-multimedia-* batch, inside the existing
noble/rk3588/vendor gate in _module_desktops_rockchip_multimedia.