Round 11 audit cleanup. Six fixes across six files:
1. local/recipes/system/redbear-passwd/recipe.toml — CRITICAL: was
missing the [source] block entirely. The recipe had only [package]
and [build] with template=cargo, which the cookbook cannot fetch.
Added [source] path = "source" so the cookbook locates the local
Rust crate. Also added a one-line description.
2. local/recipes/dev/libclc/recipe.toml — MEDIUM: the build script
installs via cmake but never verifies that libclc.pc (Mesa's
pkg-config dependency) and the .bc bitcode files actually landed.
Without these, Mesa's 3D driver cook fails opaquely with
'Dependency libclc not found (tried pkg-config)'. Added three
post-install test -f checks that fail the build with a precise
error pointing at the missing path.
3. local/recipes/system/redbear-sessiond/source/src/manager.rs — HIGH:
the D-Bus login1 can_power_off / can_reboot / can_suspend methods
were returning 'yes' unconditionally — the archetype lie-grade-ok
pattern (probe says success, then the real action fails because
/scheme/sys/kstop is missing). Replaced with a kstop_writable()
probe that fs::metadata()s the path. Used metadata() rather than
an actual write because writing 'shutdown'/'reset'/'s3' to
/scheme/sys/kstop would trigger the action. The actual power_off/
reboot/suspend methods still report granular errors when the
write is refused.
4. local/recipes/system/redbear-dnsd/source/src/transport.rs — MEDIUM:
UpstreamConfig::default() hardcoded 8.8.8.8 + 1.1.1.1 as fallback
upstream DNS. Hardcoding third-party DNS bypasses netcfg integration
and leaks user queries without consent on first boot. Replaced with
an empty Vec — main() reads the upstream list from netcfg before
any query is dispatched; upstream queries SERVFAIL until netcfg
populates the list (honest default).
5. local/docs/GREETER-LOGIN-IMPLEMENTATION-PLAN.md — MEDIUM: 16
references to the non-existent binary 'redbear-kde-session' (now
'redbear-session-launch'). Global s/redbear-kde-session/redbear-
session-launch/g. Also updated two 'redbear-kde' profile-name
references to reflect the 2026-07-24 retirement and the current
'redbear-full' ownership of the desktop path.
6. local/docs/DBUS-INTEGRATION-PLAN.md — LOW: 7 references to
'redbear-kde-session' renamed to 'redbear-session-launch' (same
binary rename).
6 files changed, +68/-28.
Note: Mesa 04-sys-ioccom-stub-header.patch migration to relibc proper
(sys/ioccom.h with Linux-style IOC encoding) is deferred — the
patch is a genuine gap-filler (relibc's sys/ioctl.h has the basic
macros but sys/ioccom.h is the BSD include path DRM UAPI expects).
That work belongs in the relibc fork with a prefix rebuild and
should be coordinated with the operator's prefix-staleness policy.
libclc's [source] uses git + path_in_repo="libclc", and the recipe assumed
COOKBOOK_SOURCE would already be the libclc subdir. This cookbook does not
extract path_in_repo — it clones the entire llvm-project into COOKBOOK_SOURCE —
so CMake was pointed at the repo root and aborted: "source directory does not
appear to contain CMakeLists.txt". Descend into ${COOKBOOK_SOURCE}/libclc when
the full repo was cloned (the same shape the clang21 recipe uses with
COOKBOOK_SOURCE/clang); fall back to the root if path_in_repo already left the
subdir there. recipe.toml is committed (not the operator's dirty source WIP).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The libclc CMake config validates target names as
(with double-dash suffix for the unspecified-ABI variant). The
previous 'amdgcn', 'amdgcn-amdhsa', 'r600', 'generic', 'spirv'
names caused:
CMake Error at CMakeLists.txt:156 (message):
Unknown target in LIBCLC_TARGETS_TO_BUILD: 'amdgcn'
Valid targets are:
amdgcn--;amdgcn--amdhsa;clspv--;clspv64--;r600--;nvptx--;
nvptx64--;nvptx--nvidiacl;nvptx64--nvidiacl;amdgcn-mesa-mesa3d
Fix: use the correct names with suffix:
r600-- -> r600 (Southern Islands / Evergreen)
amdgcn-- -> GCN GFX6..GFX12 default-ABI
amdgcn--amdhsa -> GCN with HSA runtime
amdgcn-mesa-mesa3d -> GCN via Mesa3D-specific frontend
The target is excluded because Mesa's clc tool produces
its own spirv .bc files rather than consuming libclc's. Similarly,
nvptx is excluded because there is no NVIDIA path in Mesa.
Verified: 'cmake' with -DLIBCLC_TARGETS_TO_BUILD=... above
configures successfully and 'make' produces all 118 expected .bc
files (r600 devices: cedar/cypress/barts/cayman, amdgcn devices:
tahiti..gfx1201 across all GFX variants). 'make install' places
the .pc file at /share/pkgconfig/libclc.pc (default cmake
pkgconfig location, in pkg-config's standard search path) and the
.bc files at /share/clc/ (which is what libclc.pc's
libexecdir points to).
After this fix, a fresh meson setup of Mesa with the iris/radeonsi
gallium drivers and intel/amd/swrast Vulkan drivers resolves
'dependency(libclc)' successfully — the previous 'Dependency
libclc not found' error goes away, and the gallium-r600 / gallium-
amdgpu / iris paths can compile.
The mesa-recipe's iris/radeonsi/Vulkan configuration is already
in place (per commit b7b8168aae which reverted the libclc-induced
driver drop). With this libclc recipe committed, the recipe build
chain is unblocked.
libclc was vendored at recipes/dev/llvm21/source/libclc/ as a
build artifact of the llvm21 fork. This promoted it from an
implicit Mesa dependency (the CLC bitcode Mesa consumes) to a
first-class local project, mirroring how tlc, redbear-*, cub, etc.
are organized per local/AGENTS.md.
Local layout follows the existing in-house pattern:
recipes/dev/libclc -> ../../local/recipes/dev/libclc
local/recipes/dev/libclc/recipe.toml
local/recipes/dev/libclc/source/ (vendored from llvm-project)
The recipe builds libclc as a host-side CMake project using the
cookbook-sysroot clang21 binary (not the cross-compiler) to compile
OpenCL kernels to .bc bitcode. Output targets are amdgcn, amdgcn-amdhsa,
r600, generic, and spirv — the union that Mesa's clc tool consumes
for the iris/radeonsi/llvmpipe drivers. ptx-nvidiacl and clspv are
excluded because they don't map onto any Mesa hardware driver.
The recipe also wires the cookbook's native-cmake generation with
an override that points CMAKE_C_COMPILER etc. at the cookbook
sysroot's clang-21 binary. This is needed because libclc must
run on the build host (output is bitcode, not a Redox binary),
and the cookbook's default cross-toolchain would link the build
against relibc instead of host glibc.
libclc.pc is installed at usr/lib/pkgconfig/, satisfying Mesa's
dependency('libclc') lookup. The .bc files are installed under
usr/share/clc/, which is what the libclc.pc libexecdir pointer
(libexecdir=<prefix>/share/clc) expects.
This is the prerequisite for re-enabling iris, radeonsi, and the
Intel Vulkan driver in the Mesa recipe (Phase 4-6 of
local/docs/3D-DRIVER-PLAN.md). With libclc available in the
cross-sysroot, mesa's meson '-Dwith_clc -> dependency(libclc)'
resolves and the gallium drivers compile.
vasilito