led-nightmode: add LED night mode runtime

[mv-go]

Package Details

Maintainer: @mv-go

Description:

Add the headless led-nightmode runtime for reversible OpenWrt LED night profiles. It discovers Linux LED class devices at runtime, preserves their original triggers and brightness, and restores them after the night profile ends. The package also owns the UCI, procd, rpcd, scheduling, and generic provider boundaries used by the separately submitted LuCI application.

Companion UI Draft PR: openwrt/luci#8998.

The source is signed release v0.5.1 (0.5.1-r1) with archive SHA-256 7e7af0c3e6970f47f1af975863ede0339f359a3fafce7d6cdc637e168305c4cc.

The hardware-specific Quectel provider is intentionally not included.

---

Run Testing Details

• OpenWrt Version: 25.12.4 and current snapshot SDK
• OpenWrt Target/Subtarget: mediatek/filogic; package output verified as noarch on aarch64_cortex-a53
• OpenWrt Device: Banana Pi BPI-R3 Mini for the unchanged runtime through monolithic 0.5.0-r8; the 0.5.1-r1 package split was upgrade-tested offline with apk-tools 3

Validation completed:

• fixture-backed CLI, init, service, schedule, rpcd, UCI migration, and provider lifecycle tests;
• official OpenWrt 25.12.4 SDK build;
• isolated transaction from monolithic 0.5.0-r8 preserving modified UCI, installing the new default as .apk-new, and verifying file ownership, symlinks, and installed bytes;
• combined current-snapshot SDK build with the dependent UI-only LuCI package;
• forced-Night reboot and physical power-cycle validation on the first device remain evidence for the unchanged runtime in published 0.5.0-r8; no new live-router claim is made for the package split.

---

Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.
• The commit is SSH-signed and has a matching Signed-off-by: Mv Go <rapture-ribose6k@icloud.com>.
• No patches are included.

[openwrt-ai]

Reviewed 1 commit (149aa43) — the message matches the diff, no commit-check issues.

One inline finding, on the missing empty Build/Compile override. That is the only thing I would call merge-blocking, and only if the upstream tarball has no top-level Makefile — see the comment for why it is worth adding either way. The build job has not reported on this head yet (only the three FormalityCheck runs, all green), so there is no CI evidence one way or the other.

Everything else I checked matches existing feed practice and is not worth changing: conffiles with no indentation and an absolute file path, the unindented postinst block (it lands in postinst-pkg and is appended after default_postinst, so it does not suppress the automatic init.d/uci-defaults handling), $(INSTALL_CONF) for /etc/config/led-nightmode (179 in-tree uses vs. 50 for $(INSTALL_DATA)), the relative $(LN) targets — ../led-nightmode-service from /usr/libexec/rpcd/ resolves correctly — the trailing-? GitHub archive URL (same shape as utils/afuse, utils/mbpoll, libs/valkey; @GITHUB maps to raw.githubusercontent.com and does not apply to release tarballs), PKG_BUILD_DIR matching the tag's archive top-level directory, all five DEPENDS resolving to real packages (sunwait is in utils/sunwait), and test-version.sh taking the package name as $1 (27 in-tree scripts use the positional form).

---

Generated by Claude Code

[openwrt-ai]

Reviewed the amended commit (149aa43 → f9d0cf4a); no new issues found.

The only change since the last review is the empty Build/Compile override, placed after include $(INCLUDE_DIR)/package.mk — that is exactly the fix for the previous finding, and your note that the v0.5.1 tarball does carry a top-level package Makefile confirms it was needed. The commit message is unchanged and still matches the diff. All three FormalityCheck runs are green on this head; the build job has not reported yet, so there is no CI evidence either way.

---

Generated by Claude Code