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.
recipes/dev/gcc13 was claiming name='cxx' — conflicted with
local/recipes/dev/gcc-native also claiming 'cxx'. Renamed to match
directory names for unique package identification by the cookbook.
All tarballs re-downloaded from upstream mirrors, BLAKE3 hashes
verified against downloaded files. Per user request: walk through ALL
recipes, not just graphics. This is the active build pipeline batch.
Cherry-picked from Qt upstream (commit e488f852fa18c2afc2842a88eff8f66ad4105a45).
Original patch source:
https://download.qt.io/official_releases/qt/6.11/CVE-2026-6210-qtsvg-6.11.diff
Fix: Test types of nodes before downcasting them. A bad cast in
QSvgMarker::drawHelper led to endless recursion resulting in a heap
overflow. While fixing that, another similar case was also fixed.
Gnulib generates lib/sched.h which wraps the system sched.h via
#include_next, but the #if @HAVE_SCHED_H@ guard evaluates to 0 during
cross-compilation, preventing sched_param typedef from being visible.
Adding ac_cv_header_sched_h=yes fixes the guard.
fstools.mk: Use canonical local/sources/ paths for installer and redoxfs
cargo install --path. The recipes/ symlink chain caused cargo to resolve
path dependencies (../libredox, ../redoxfs, ../syscall) relative to the
recipe directory instead of the canonical source location, breaking
the host build.
bison: Add cross-compilation cache variables for POSIX spawn support.
Gnulib's configure couldn't detect the system spawn.h during cross-compile,
causing generated lib/spawn.h to omit #include_next, leaving
POSIX_SPAWN_* constants undefined.
The working tree had accumulated git-tracking drift across the
local/sources, local/recipes/*/source, and local/reference trees.
Restored:
- local/sources/libredox: add missing 160000 gitlink at
d01da350 (submodule/libredox). The .gitmodules entry already
declared this fork; the parent tree entry was missing so a
fresh clone of the parent would not pull the libredox source.
- .gitignore: mark the four local/recipes/*/source build-cache
trees (uutils-tar, ninja-build, sddm, sddm/source-pristine)
and the two local/reference/* entries (linux-7.1, seL4) as
ignored. These are build caches and external references, not
durable Red Bear code. The durable code for the four recipes
is recipe.toml + the corresponding patch (redox.patch).
- Note in .gitignore: do not extend local/recipes/**/source to
a blanket rule, because ~150 Red Bear fork recipes do keep
their durable source under local/recipes/<name>/source/.
Removed six broken 160000 gitlinks:
- local/recipes/archives/uutils-tar/source (e4c2affa...): on-disk
working tree was a self-clone of RedBear-OS; gitlink pointed to
a non-existent commit in the parent object database.
- local/recipes/dev/ninja-build/source (d829f42b...): gitlink
was a dangling commit on a diverged branch that has since been
rewritten; the on-disk HEAD is upstream v1.13.1 (79feac0) which
the recipe re-fetches via recipe.toml anyway. The 6.4MB
embedded .git directory was also removed.
- local/recipes/kde/sddm/source (63780fcd...): build cache for
sddm 0.21.0 re-fetched via recipe.toml. The 11MB embedded
.git directory was also removed.
- local/recipes/kde/sddm/source-pristine (63780fcd...): empty
placeholder, build cache. Removed.
- local/reference/linux-7.1 (ab9de95c...): external Linux
reference tree, gitignored by size. The on-disk directory
is preserved per AGENTS.md 'NEVER delete the reference tree'.
- local/reference/seL4 (a0b4f2d2...): empty placeholder,
gitignored.
Removed untracked pollution at repo root:
- kernel (empty 0-byte file)
- qqmljsgrammar.cpp, qqmljsgrammar_p.h, qqmljsparser.cpp,
qqmljsparser_p.h (393KB total: build artifacts that escaped
a qtdeclarative build into the working tree root; they belong
inside the recipe source tree, not at the parent level)
Added:
- local/docs/MULTITHREADING-COMPREHENSIVE-ASSESSMENT-AND-PLAN.md:
comprehensive multi-threading audit and implementation plan
covering kernel scheduler, kernel futex, syscall ABI, relibc
pthreads, and userspace threading correctness. Will drive
the next implementation cycle after the git tracking work
is wrapped.
After this commit:
- 9 submodule entries in HEAD, all of local/sources/* forks.
- All previously-existing 8 fork submodules unchanged.
- libredox is now durable across clones (was previously lost).
- No untracked files at root.
- No dangling or self-referencing gitlinks.
kernel (2 commits):
- drop -Z json-target-spec (redundant with --target)
- add MWAIT idle_loop for deeper C-states on modern CPUs (Phase G)
ninja-build (1 commit):
- add Redox subprocess fork/exec and GetLoadAverage support
- Remove recipe target directories (47GB)
- Clean build directory artifacts
- Remove old temp logs
- Clean Cargo target directories
- Free disk space from 32GB to 91GB available
Core fixes to get redbear-mini building and booting via UEFI:
relibc: Use 'VaListImpl as va_list' in syslog so cbindgen outputs va_list
instead of unknown VaListImpl type (matches stdio pattern). Fixes
openssl3 and all C consumers of syslog.h.
base fork (f97da5b0): ps2d missing info! import, ps2d dead variable,
fbcond drm-0.15 API fix, acpid 31 errors (ivrs/mcfg modules, duplicate
methods, packed fields, dmar copy-paste bug), bootstrap abort_immediate
removal (feature removed from nightly)
redox-driver-sys: Add PciQuirkFlags re-export for crate-root imports
bash: Regenerate P1-mksyntax-host-headers.patch with proper unified diff
m4: Fix getlocalename_l unsafe wrapper
config: Comment out mc (requires glib-2.0 chain, not needed for mini)
UEFI boot verified in QEMU — boots to RedBear login prompt.
Author: vasilito <adminpupkin@gmail.com>
- Create local/docs/PACKAGE-BUILD-QUIRKS.md: central reference for all
known cross-compilation build issues (DYNAMIC_INIT behavior, m4
CFLAGS/LDFLAGS ordering, ninja-build BUILD_TESTING, general patterns)
- Update UPSTREAM-SYNC-PROCEDURE.md: add m4 LDFLAGS ordering quirk
(must be set AFTER DYNAMIC_INIT), ninja-build BUILD_TESTING=OFF,
DYNAMIC_INIT overwrite behavior, source reversion root cause summary
- Update AGENTS.md: reference PACKAGE-BUILD-QUIRKS.md in WHERE TO LOOK
table, add DYNAMIC_INIT and cross-compilation test conventions
- Fix ninja-build recipe: add cmakeflags=['-DBUILD_TESTING=OFF']
(tests require host gtest which conflicts with Redox sysroot stdlib.h)
Base fork workspace pins redox_syscall = '0.7.4' (resolves to 0.7.5).
Without this pin, redox-driver-sys pulls in 0.8.1, causing type mismatches
in downstream crates like driver-graphics that use both 0.7.5 and 0.8.1
types in the same expression.
The previous patch left a broken `__redox__ && HAVE_GETLOCALENAME_L`
branch that referenced the non-existent relibc function `getlocalename_l`,
causing the m4 build to fail with:
error: #error "Please port gnulib getlocalename_l-unsafe.c to your platform!"
Redox's relibc has no `getlocalename_l` symbol. The patch now uses
`__redox__ && !HAVE_GETLOCALENAME_L` and returns "C" (matching
the existing `__ANDROID__` branch behaviour for unknown locales),
so the build no longer hits the gnulib #error.
vasilito