Vendor libsecret 0.21.7 (org.freedesktop.secrets client lib, required by
kwalletd6's secretserviceclient.cpp) under the full-fork model; build it shared
against the static libgcrypt closure (custom template + unset COOKBOOK_DYNAMIC so
pkg-config --static pulls libgpg-error). Add it to kf6-kwallet deps.
Fixes to reach a full kwallet build:
- qca recipe: rewrite the exported Qca-qt6Targets.cmake to compute _IMPORT_PREFIX
relative to the config-file location (QCA hardcoded an absolute /usr prefix +
include dir, so cross consumers failed with 'imported target includes
non-existent path /usr/include/Qca-qt6/QtCrypto').
- ksecretd/CMakeLists.txt: gate add_subdirectory(autotests) on BUILD_TESTING
(upstream does not); the autotests need Qt6Test, unavailable for the cross
target and never shipped.
- kwalletbackend blowfish.h + sha1.cc: include <stdint.h> on __redox__ (the cross
check_include_files(stdint.h) misfired, leaving HAVE_STDINT_H unset -> uint32_t
undeclared).
- cmake/FindLibGcrypt.cmake: append libgpg-error after libgcrypt (static-only on
Redox, its gpg-error dep not pulled transitively -> undefined gpgrt_lock_*/
gpg_strerror at link).
Gpgmepp stays optional (find_package without REQUIRED, all uses HAVE_GPGMEPP-
gated); GPG-key wallets are a secondary feature. kwalletd6 + ksecretd both build.
kf6-kwallet's ksecretd daemon (the org.freedesktop.secrets Secret Service
provider) requires Qca-qt6 2.3.1. Vendor QCA 2.3.10 under the full-fork model
and build the gcrypt provider plugin (backed by the vendored libgcrypt) so QCA
has a working SymmetricCipher/Hash/PBKDF2 backend on Redox. External-toolkit
providers (ossl/nss/botan/gnupg/pkcs11/cyrus-sasl) are disabled — those
libraries are not part of the Redox userland; logger + softstore (pure-Qt) are
kept.
Source edit: the top-level Qt6 find_package required the Test component
unconditionally; gate it on BUILD_TESTS so a tools/tests-off build configures
without Qt6Test. Install via DESTDIR since QCA anchors its install dirs to the
absolute Qt prefix (/usr), which ignores cmake --install --prefix.
Build libgpg-error + libgcrypt with --with-pic so their static archives can be
linked into the qca-gcrypt shared plugin. Add qca to kf6-kwallet deps.
kf6-kwallet's kwalletbackend hard-requires LibGcrypt 1.5.0 for PBKDF2 key
derivation and the GPG-backed wallet format. Vendor both libraries under the
full-fork model (committed source/, offline-reproducible) and add libgcrypt to
kf6-kwallet's dependencies.
Release tarballs ship a pre-generated configure and a config.sub that already
recognises the *-redox triple, so no autotools regeneration is needed at cook
time. libgpg-error supplies a generic pthread-backed gpgrt_lock_t for Redox via
its build script; the test-only redox.patch (tms/times stub) is baked into
libgcrypt's source and kept alongside for future version bumps.
Promoted from the stale recipes/wip copies (now .disabled).
kf6-kauth deliberately uses the real polkit backend (KAUTH_BACKEND_NAME=
POLKITQT6-1), and PolkitQt6-1 links the upstream polkit CLIENT libraries, which
nothing provided (redbear-polkit is only the org.freedesktop.PolicyKit1 daemon).
This makes the KDE authorization mechanism actually work, not just compile.
- New recipe local/recipes/libs/polkit (vendored polkit 124, full-fork path=source)
built with -Dlibs-only=true so polkitd + the JS rules engine are skipped
(redbear-polkit is the authority daemon). glib/gio/expat deps already exist.
- src/meson.build: build src/polkitagent even under libs-only — libpolkit-agent-1
+ its PAM auth helper are client-side, needed by PolkitQt6-1, and depend only on
libpolkit-gobject-1 + glib + PAM (pam-redbear, the same PAM SDDM uses). Only the
daemon/backend/programs stay gated off.
- pam-redbear: add the standard PAM_MAX_MSG_SIZE/PAM_MAX_RESP_SIZE constants its
header was missing (polkit-agent-helper-1 needs them).
- polkit-qt6: depend on polkit; it now finds polkit-gobject-1 + polkit-agent-1
(v124) and builds. Auth prompts verify passwords via pam-redbear; authorization
decisions come from the redbear-polkit daemon over D-Bus.
Both now build for x86_64-unknown-redox against the ported relibc surface:
- wireplumber recipe: fix meson option types for 0.4.14 (doc feature; tests/
tools/daemon are booleans, not features) — configure was erroring out.
- pcre2: build the static archive with -fPIC so it links into WirePlumber's
shared PipeWire modules (via glib); matches expat/icu/libffi. Fixes the
R_X86_64_32S-in-shared-object link failure.
- config/redbear-full.toml: re-add pipewire + wireplumber to packages[] and
[files]; drop the TODO(audio) deferral.
- bump relibc submodule pointer to the ported C-runtime surface.
Per the no-workarounds policy, provide the Qt modules KDE needs instead of
patching KDE to avoid them:
- qt5compat (Core5Compat): promoted from recipes/wip, re-laid to 6.11.1
(matches the rest of Qt); no Redox source port needed. Unblocks 8 KDE pkgs.
- qtmultimedia: new recipe at 6.11.1, built API-only (all platform backends
off: ffmpeg/gstreamer/pulseaudio/alsa/pipewire/v4l2) so libQt6Multimedia
links for consumers (konsole bell); playback is a no-op until a Redox audio
backend exists.
- libclc: convert git= -> path=source (it was fully vendored; a fresh fetch
broke on the removed .git). Overlay symlinks added for both new qt modules.
git links -lintl (libintl, from gettext) for i18n but never declared gettext as
a build dependency — it was implicitly relying on libintl.a already being in the
shared prefix sysroot from another package. When the relibc/kernel-touched boot-
ABI relink cleaned the sysroot, git's own sysroot lacked libintl and the link
failed. Declare the dependency so libintl.a is staged into git's sysroot.
A Redox cross build cannot run the target shader-precompile tools on the host,
so build them natively once and feed them to the cross Mesa via
-Dmesa-clc=system -Dprecomp-compiler=system. Native meson build against
llvm-native's CLEAN host LLVM/Clang (the redoxer toolchain's llvm-config emits
-I<toolchain>/include, which holds Redox target libc headers that poison host
g++), host system deps (libdrm/expat/zlib/zstd), and our host-built
SPIRV-Tools/LLVMSPIRVLib/libclc (pkg-config with absolute .pc prefixes; native
pkg-config, not the cross wrapper). Driver-agnostic tools, so iris-only (no
amdgpu-LLVM needed); they serve radeonsi/radv in the cross build too.
Mesa's radeonsi gallium driver requires libelf. Add a libelf recipe that builds
only the elfutils lib/+libelf/ subdirs (avoiding the libdw/libasm/tools glibc
surface) as a PIC static archive, relying on the new relibc headers/functions
(byteswap/error/libintl/ar/search + tsearch/mempcpy/rawmemchr). Installs
libelf.a + libelf.h/gelf.h/nlist.h + libelf.pc. Wired into mesa deps.
Verified: cook libelf - successful.
The host libLLVM.so (COOKBOOK_HOST_SYSROOT=/usr branch) lives in the redoxer
toolchain and is dynamically linked by rustc's librustc_driver. Building it as
X86;AMDGPU;NVPTX only dropped AArch64/RISCV, so after the AMDGPU splice rustc
failed to load with 'undefined symbol: LLVMInitializeAArch64AsmPrinter' —
breaking every Rust compile in the tree. Build the host LLVM with all CPU
targets rustc emits (X86;AArch64;RISCV) PLUS the GPU backends (AMDGPU;NVPTX).
The Redox-target llvm21 stays X86;AMDGPU;NVPTX (Redox is amd64-only, no need to
bloat the shipped libLLVM with foreign CPU backends).
Fixes a latent regression from 80d20db8/a6999912.
Shipping the Intel iris/ANV gallium+vulkan drivers turns on Mesa's with_clc
(with_driver_using_cl), which requires, in the native mesa_clc/intel_clc shader
precompile path: LLVMSPIRVLib (SPIRV-LLVM-Translator), SPIRV-Tools, and clang's
C++ libraries. None had recipes. Add three host-built dev recipes modelled on
libclc (built against llvm-native's host LLVM 21, staged into the cross sysroot
so Mesa's pkg-config resolves them):
- spirv-headers (SPIR-V grammar + headers; find_package package)
- spirv-tools (SPIRV-Tools.pc; SPIRV-Headers via find_package)
- spirv-llvm-translator (LLVMSPIRVLib.pc, v21.1.0.0; llvm_release_210 branch)
All three clear the cross-sysroot __libc_start_main leak with the llvm21-style
flag-clearing block in their native toolchain files.
Wire them + clang21 into mesa deps: Mesa resolves dep_clang via
cpp.find_library('clang-cpp', dirs: llvm-config --libdir), which the wrapper
rewrites to the target sysroot/lib, so clang21's target libclang-cpp.so must be
staged there (shared-llvm=enabled avoids needing the static clang libs).
Verified: mesa meson now passes amdgpu, LLVMSPIRVLib, SPIRV-Tools, and clang-cpp
(next gate is libelf for radeonsi).
Per operator: don't forget Intel + virgl, and prepare for future NVIDIA. Intel
(iris/anvil) and virgl need NO LLVM GPU backend (NIR / virtualized) — they stay
in Mesa's driver lists as first-class targets. AMD needs AMDGPU (now); NVIDIA
(future, nouveau/NVK) needs NVPTX. LLVM rebuilds are very expensive, so include
NVPTX now (llvm21: X86;AMDGPU;NVPTX) to avoid an LLVM rebuild when NVIDIA lands.
Documented the vendor->driver->LLVM-backend matrix in the amd64-only policy.
Mesa's radeonsi/radv AMD-GPU drivers require the LLVM 'amdgpu' codegen backend
(dependency('llvm', modules: [... amdgpu ...])). llvm21 built X86 only, so the
host llvm-config the mesa build reads reported amdgpu(missing). Add AMDGPU to
LLVM_TARGETS_TO_BUILD (X86;AMDGPU per the amd64-only policy — AMDGPU is a GPU
backend, not a second CPU platform). This is the redox-target LLVM whose libs
mesa links AND the source of the prefix clang-install host LLVM. NB: the
~/.redoxer toolchain host llvm-config (a provisioned prebuilt) still needs the
rebuilt AMDGPU host-LLVM propagated into it (follow-up).
Cross-building lld/llvm needs a HOST-runnable llvm-tblgen to generate the
Options.inc opt-parser sources, and it must match the LLVM 21 source tree.
Both recipes referenced ${COOKBOOK_HOST_SYSROOT}/bin/llvm-tblgen, but the
cookbook does not export COOKBOOK_HOST_SYSROOT, so the path collapsed to the
host /bin/llvm-tblgen. On a rolling distro that is now LLVM 22, whose
-gen-opt-parser-defs backend requires a 'SubCommand' TableGen class absent
from LLVM 21's OptParser.td:
error: The class 'SubCommand' is not defined
Default COOKBOOK_HOST_SYSROOT to the redoxer toolchain (host-runnable LLVM
21.1.2 llvm-/clang-tblgen), exactly as the sibling clang21 recipe already
does. Fixes the full-target build reaching mesa's LLVM build-deps.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
redbear-dnsd is an in-house recipe (path = "source"), but recipes/system/
redbear-dnsd was a real dir with only a recipe.toml file-symlink, so
'cargo install --path recipes/system/redbear-dnsd/source' found no Cargo.toml
(the source lives in local/recipes/system/redbear-dnsd/source). Make it a
whole-dir symlink to local/ like every other in-house recipe (ehcid, netctl,
...), and add it to apply-patches.sh's link list so it is recreated durably.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Three concurrent refinements from the same work batch:
1. sessiond/manager.rs + runtime_state.rs: switch inhibitor_fds
from HashMap<u64, StdOwnedFd> to HashMap<i32, TrackedInhibitorFd>
so each inhibitor carries both its numeric id and the OwnedFd
that needs to be closed when the caller FD vanishes. The
TrackedInhibitorFd newtype wraps (inhibitor_id, _fd) and lets
reap-on-vanish use the keyed fd handle to take() out of the
map cleanly. The dead_senders code path now collects daemon_fd()
values directly instead of round-tripping through Vec<u64>.
2. wifictl/dbus_nm.rs: introduce AccessPointExport type alias
(OwnedObjectPath, AccessPointInterface) and rename
access_point_interfaces -> access_point_exports returning the
same shape. access_point_paths now derives from the exports
list (avoiding the parse-then-rebuild cycle) and a new
all_access_point_paths() passes through. All call sites in
serve_on_thread get a single coherent exports() call instead
of duplicate path/interface computations.
3. recipes/wip/wayland/qt6-wayland-smoke: correct the relative
symlink target from ../../../local/recipes/wayland/qt6-wayland-smoke
to ../../../../local/recipes/wayland/qt6-wayland-smoke. The
symlink resolves correctly either way (filesystem lookup
succeeds) but the git tree now records a path that is one
level more explicit and matches the canonical Red Bear recipe
symlink convention used elsewhere in recipes/wip/.
Verified via grep that no callers of the old HashMap<u64,
StdOwnedFd> shape remain; all switched to the new TrackedInhibitorFd
type. The sessiond-vs-dead_senders race that motivated the FD
tracking is now correctly closed by taking the daemon_fd handle
out of the map under the same Mutex that updates runtime.inhibitors.
Completes the round-2 docs cleanup sweep by repairing the same
stale-reference pattern in files I missed in the prior commit.
Same pattern as 5970dd226f: each replacement points at the
current canonical doc (restored to top-level, absorbed into a
different plan, or now tracked in SUPERSEDED-DOC-LOG.md for
historical reference).
- AGENTS.md: legacy-obsolete/BUILD-SYSTEM-HARDENING-PLAN.md
-> COLLISION-DETECTION-STATUS.md
legacy-obsolete/HOOKS.md -> RELEASE-BUMP-WORKFLOW.md § Git Hooks
legacy-obsolete/PATCH-PRESERVATION-AUDIT -> SUPERSEDED-DOC-LOG.md
- CONTRIBUTING.md: same legacy-obsolete repairs
- README.md: same legacy-obsolete repairs
- docs/01-REDOX-ARCHITECTURE.md:
WAYLAND-IMPLEMENTATION-PLAN.md -> 3D-DESKTOP-COMPREHENSIVE-PLAN.md
- docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md:
legacy-obsolete/IRQ -> top-level IRQ plan;
legacy-obsolete/05-KDE-PLASMA -> struck-through with deletion note;
WAYLAND-IMPLEMENTATION-PLAN.md -> 3D-DESKTOP-COMPREHENSIVE-PLAN.md
- docs/AGENTS.md: same legacy-obsolete repairs; 05-KDE marked as
deleted; legacy-obsolete/DRM-MODERNIZATION -> 3D-DESKTOP-COMPREHENSIVE
- docs/README.md: same legacy-obsolete repairs
- local/AGENTS.md: same legacy-obsolete repairs
- local/docs/SUPERSEDED-DOC-LOG.md: alignment with the
2026-07-27 consolidation entry
- recipes/wip/AGENTS.md: legacy-obsolete/05-KDE-PLASMA repoint
The deltas are documented verbatim in each diff; nothing was
rephrased, only the link target was corrected.
Round 14 audit cleanup. Six coordinated fixes across seven files
plus a documentation log update:
1. local/recipes/system/redbear-wayland-guard/ — REMOVED entirely.
The directory contained only source/wayland_guard.c — an LD_PRELOAD
interposer stub for three wl_proxy_* functions — with NO recipe.toml.
This violated local/AGENTS.md STUB AND WORKAROUND POLICY ('No LD_PRELOAD
tricks'). The correct null-guard fix lives in libwayland upstream per
QT6-WAYLAND-NULL8-DIAGNOSIS.md (already covered by Mesa win compat).
2. recipes/system/redbear-wayland-guard — broken symlink cleaned up.
3. local/recipes/AGENTS.md — catalog entry for redbear-wayland-guard was
wrong (claimed 'Rust' but the code was C LD_PRELOAD). Replaced with
REMOVED note explaining the policy violation and the correct fix
location in libwayland.
4. local/recipes/system/firmware-loader/source/src/main.rs — converted
9 .expect() calls in the daemon init path (Socket::create, scheme_root,
create_this_scheme_fd, syscall::call_wo notify, setrens, next_request,
write_response) to Result propagation. get_init_notify_fd() and
notify_scheme_ready() now return Result; run_daemon() returns Result and
main() matches on Err to log+exit(1) cleanly. The daemon was
crashing the entire firmware-delivery subsystem on any init failure;
now init can fall back or restart the daemon.
5. local/recipes/system/{redbear-keymapd,redbear-ime,redbear-accessibility}/
source/src/main.rs — three scheme daemons used the same
Socket::create().expect() + register_sync_scheme().expect() pattern.
Replaced all six .expect() calls with match expressions that
log_msg('ERROR', ...) and process::exit(1). Same pattern.
6. local/docs/NETWORKING-AND-DRIVERS-SYSTEMATIC-ASSESSMENT-2026-07-27.md —
struck through 5 references to the now-removed redbear-wayland-guard
(line 65 missing-daemons list, line 344 table row, line 397
implementation list, line 414 source-list, line 797 P3-8 backlog).
7. local/docs/SUPERSEDED-DOC-LOG.md — appended a 'Rounds 11-14 Source-Level
Supersessions' table logging every lie-grade fix and stale-doc
strike from this session. Mirrors the original deletion-log style for
consistency, and gives operators a single place to see what was
resolved and where. Documents the emerging pattern: lie-grade code in
Red Bear concentrates in (a) relibc panic-site catch-alls (addressed
rounds 9-10), (b) scheme daemon init paths using .expect() instead of
Result (rounds 11-14), (c) Mesa DRM/Wayland stubbing (rounds 12;
remaining work tracked in 3D-DESKTOP-COMPREHENSIVE-PLAN.md).
Not committed in this commit (operator's parallel work, to be
committed by them):
- driver-manager/* (N-tier edits)
- redbear-sessiond/manager.rs (can_* probe refinements)
- redbear-statusnotifierwatcher/* (recipe + source)
- redbear-dbus-services/* (dbus service cleanup)
- redox-driver-core/manager.rs (test-only)
- Mesa redox_drm_cs.c (CS submit fix)
7 files changed in this commit + 2 deletions.
The DRIVER-MANAGER-MIGRATION-PLAN was self-declared complete (the
driver-manager cutover happened 2026-07-23 per local/AGENTS.md). It
is now historical reference material rather than current planning
authority. Move it from local/docs/ into the established
legacy-obsolete-2026-07-25/ archive directory, updating every
inbound reference.
Also includes minor cross-doc alignment for the previous round's
relocations:
- local/AGENTS.md: update DRIVER-MANAGER-MIGRATION-PLAN to point to
the legacy archive
- local/docs/REDBEAR-FULL-SDDM-BRINGUP.md: alignment update
- local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md: alignment update
- local/docs/archived/README.md: refresh archive contents note
- local/recipes/system/redbear-driver-policy/source/policy/README.md:
policy doc drift alignment
- local/scripts/guard-recipes.sh: fix symlink target computation
(relative path was being glued onto an absolute path, producing
malformed dangling links like '../..//mnt/.../recipe.toml')
-- this is a real bug fix discovered during this audit round.
clang21 (recipes/dev/clang21): the cross build (redox target) references
${COOKBOOK_HOST_SYSROOT}/bin/clang-tblgen and .../llvm-tblgen to generate the
*.inc sources, but cookbook does not export COOKBOOK_HOST_SYSROOT, so the paths
collapsed to /bin/clang-tblgen and ninja died: "'/bin/clang-tblgen' ... missing
and no known rule to make it". Point COOKBOOK_HOST_SYSROOT at the redoxer
toolchain, which ships host-runnable clang-tblgen/llvm-tblgen (LLVM 21.1.2) —
the same way the mesa recipe sets it.
libxml2 (recipes/libs/libxml2): declare the libiconv dependency. libxml2 2.15.x
requires iconv and its configure aborts "libiconv not found"; a libiconv recipe
exists but was never built because nothing depended on it.
Both are base recipes (not the operator's dirty mesa/kf6/libclc source WIP).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The recipe's tar URL (https://libarchive.org/downloads/libarchive-3.8.8/...)
404s — that pathed form does not exist. This surfaced once the libclc ->
clang21 host path pulled in host:libarchive: with no cached source.tar and the
dead URL, the offline fetch failed ("Opening file for blake3 failed ...
source.tar: No such file"). Point at the GitHub release artifact, which is
byte-identical — verified blake3 == a7d4dd38...888b9024, unchanged.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fixes the chain of blockers that left redbear-full producing a desktop-less ISO
while still reporting success. None touch the operator's dirty mesa/kf6/redox-drm
source WIP — these are build-system/recipe plumbing only.
build-redbear.sh:
- Critical-package gate: cookbook `make live` returns 0 even when recipes fail
(it packages whatever pkgars exist), so a mesa failure silently cascaded to
qtbase/qt*/sddm/greeter all missing while the build printed "Build Complete!".
Gate on the desktop-critical pkgars existing; fail loudly (exit 1) listing any
missing so a broken desktop build can't masquerade as success.
- Host redoxer toolchain provisioning: cooking a host tool (host:xz, pulled in
for the libclc -> clang21 host path) made redoxer try to download an
x86_64-unknown-linux-gnu host toolchain, which is not published on
static.redox-os.org -> 404 "unable to init toolchain", failing every host
cook. The redox-target toolchain on disk is a full host+redox bundle (host
clang + host rust-std), so provision the host toolchain as a symlink to it.
Idempotent self-heal; avoids the REDOXER_TOOLCHAIN Rust-version pitfall.
- Pre-cook libclc before mesa.
local/recipes/libs/mesa/recipe.toml:
- Declare `libclc` as a dependency. Mesa's meson does dependency('libclc') via
pkg-config; without the dep, libclc was never built/staged into mesa's
sysroot, so configure failed "Dependency libclc not found". libclc ships its
.pc in its main package, so depending on "libclc" is sufficient.
recipes/tools/xz/recipe.toml:
- Host build static-only. xz 5.8.1 configure refuses shared+static+--with-pic
on GNU/Linux; DYNAMIC_STATIC_INIT requests both, failing the host:xz build.
Redox target keeps both.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
- base-initfs recipe: pcid-spawner removed from initfs BINS and the
lib/pcid.d initfs staging dropped (dead pcid-spawner config).
- acid.toml, redoxer.toml: requires_weak now points at
00_driver-manager.service.
- redbear-mini.toml: dead /etc/pcid.d/* staging removed; driver-manager
service override no longer gated on the retired fallback flag.
- redbear-full.toml: dead legacy-format /etc/pcid.d/ihdgd.toml and
virtio-gpud.toml removed (driver-manager's 30-graphics.toml covers
the same drivers in the current format).
- Comments updated: no fallback exists; driver-manager owns the path
unconditionally. Base submodule bump (0c11c2b5).
The driver-list filter ran `grep -R "^name = \"$bin\"$" $COOKBOOK_SOURCE`
once PER bin (~40 bins). $COOKBOOK_SOURCE is local/sources/base, whose
target/ build tree is ~8.7 GB, so each grep re-scanned gigabytes and the
whole loop scanned hundreds of GB — a very slow build phase.
Collect the workspace's crate names ONCE from Cargo.toml files (skipping
target/ via --exclude-dir), into a bash associative array, then do an
O(1) membership check per bin. Verified equivalent (same bins selected)
and near-instant: the single scan of local/sources/base completes in
~0.02s vs minutes for the per-bin recursive greps.
The recipe adds a forkpty extern to the libc crate's Redox module (which
relibc provides but the libc crate does not declare) so nix 0.30.1's pty
module compiles. The sed anchor was `)-> c_int;` (no space), which
matched older libc formatting but NOT libc 0.2.189's multi-line openpty
close `) -> c_int;` (with space) — pulled in by the latest-upstream rule.
The sed silently no-op'd, forkpty was never declared, and nix failed with
"cannot find function forkpty in crate libc", breaking the mini build.
Fix: anchor `) *-> c_int;` (optional space) matches both the old and new
formatting. Verified: clean uutils-tar build compiles nix and finishes.
Note on the stale-rlib symptom seen during diagnosis: cargo fingerprints
registry crates by version, not source content, so a libc rlib compiled
while the anchor was broken (forkpty absent) is reused even after the
source is patched. A clean/target-wiped build recompiles correctly; the
anchor fix is the durable root fix.
On the live image, a fork/exec during login-shell startup can stall the
shell before its first prompt. Replace command substitutions with pure
builtins in the startup path:
- bash.bashrc: read /etc/redox_chroot with the 'read' builtin instead of
$(cat ...)
- profile: derive the root prompt from EUID/USER/LOGNAME (set by
login(1)) instead of $(id -u)
- skel/.bashrc: disable lesspipe and dircolors eval (both spawn
subprocesses); keep the ls --color=auto alias
The kernel fork (submodule/kernel bd1b251f) now provides a proper
'install' target honoring DESTDIR, so the recipe no longer hand-rolls
the staging copy. Fork also gains post-merge compile fixes (import
dedup + UnmapVec).
ion pulls nix 0.23.1 (git), which has the Redox SaFlags_t=c_ulong bug
(relibc/libc use c_int) and fails to compile on a clean rebuild with the
`kill`/signal feature. ion was only a bundled initfs recovery shell that
nothing execs (init runs daemons then switchroots to /usr, where the
interactive login shell is brush). Per operator directive, drop ion rather
than hold nix back on an ancient pinned version for its sake.
nix 0.30.1 wrongly types Redox's sigaction SaFlags_t as c_ulong, but
relibc and the libc crate both declare sa_flags/SA_* as c_int (nix 0.31
already uses c_int for Redox). With the `kill` feature the nix signal
module is compiled and the u64-vs-i32 mismatch breaks the SaFlags
bitflags (E0308). This was latent (uutils built from cache); the relibc
epoll rebuild forced a clean recompile and surfaced it.
Patch the nix Redox branch before cookbook_cargo, with cargo fetch first
so the registry source exists before patching.
Port the brush shell (reubeno/brush) to Redox and adopt the recipe as a
Red Bear local recipe under local/recipes/shells/brush, with the standard
recipes/shells/brush -> ../../local/recipes/shells/brush overlay symlink so
it takes priority over any upstream WIP copy (per local/AGENTS.md "Local
recipe priority vs upstream WIP"). Removes the old recipes/wip/shells/brush.
The dependency tree did not build for Redox: nix 0.31 only partially
cfg-enables Redox and the libc crate's Redox module omits POSIX symbols that
relibc provides. Fixes are reviewable unified diffs under
local/recipes/shells/brush/patches/:
nix-0.31-redox.patch cfg-enable resource/Id/waitid/from_siginfo, rlimit
import + repr(i32), SaFlags width casts, pty.
libc-0.2-redox.patch add idtype_t, P_*/CLD_*, rusage, getrusage/waitid/
forkpty externs, siginfo child accessors.
brush-umask-redox.patch mode_t is signed on Redox; cast, not u32::from.
The recipe runs `cargo fetch` to materialise registry sources before
patching (they are only unpacked during the build), resolves the right
crate version from Cargo.lock (brush pulls both nix 0.26 and 0.31), and
applies each patch idempotently, failing loudly on version drift. The
binary target is named `brush` (not `brush-shell`), so install it
explicitly. Verified: cooks from a pristine cargo cache using only the
patch files. brush is shipped in redbear-mini as a package for in-image
validation; the login shell stays zsh until brush is runtime-proven.
Mini now boots (q35/KVM) all the way to the getty "Red Bear login:" prompt
on VT2 with zero kernel panics. Root-cause fixes across submodules + config:
- config: 00_base.service zsh->mkdir (a full shell startup hangs an init
oneshot; the earlier 'echo/mkdir also hang' result was a silent config
override running zsh). 00_ptyd.service notify->{scheme=pty} (ptyd signals
readiness via its scheme fd; notify made init block on a byte forever).
- kernel: wrmsr_safe/rdmsr_safe #GP recovery so /scheme/sys/msr can't panic
the kernel (cpufreqd's P-state MSR write #GP'd on KVM, halting the boot
before login). base: ptyd scheme type + hwd ACPI enum -> debug (noise).
installer: warn on config [[files]] override. relibc/bootloader: prior
getrlimit + warning-demotion pointers.
- build-redbear.sh: fix host-fstools staleness (installer/redoxfs never
rebuilt on source change), prefix rebuild-every-build (touch libc.a), add
concurrent-build flock.
Submodule pointers: base 8aa8616d, installer 460d9530, kernel 155d01b1,
relibc a7663b3a, bootloader 6e119641.
Multiple fixes to make redbear-bare actually build and progress
through boot:
config/redbear-bare.toml:
- filesystem_size: 96 -> 192 MiB. The bare image packages ~153 MiB
of installed content (zsh, base, base-initfs, kernel, relibc,
userutils, libgcc, libstdcxx, plus coreutils/extrautils/etc.),
so 96 MiB triggers installer ENOSPC during commit.
- Override 31_debug_console.service with postinstall=true so the
override wins over minimal.toml's version that uses
/scheme/debug/no-preserve (which busy-loops when the debug
scheme returns ENODEV in the bare initfs).
recipes/core/base-initfs/recipe.toml:
- bare_initfs() now only references BINS in the base workspace
(init, logd, ramfs, randd, zerod, ptyd). getty is removed from
BINS because it lives in userutils, not base.
- Copy getty from the sysroot into the initfs after the cargo
build (analogous to the existing redoxfs/ion/driver-manager
sysroot copies).
- Filter the init.d copy under REDBEAR_BARE_INITFS to keep only
services for binaries we actually built (logd, randd, zerod,
runtime.target, ramfs@.service, 90_initfs.target, 50_rootfs).
The mainline 23 services reference fbcond/vesad/acpid/pcid/
fbbootlogd/hwd/inputd which aren't in the bare BINS, so
init would try to start them and busy-loop.
- Synthesize minimal 00_ptyd.service and 30_getty.service units
in the initfs since they're built/copied but not in the
mainline init.initfs.d.
- Override 00_runtime.target to add ptyd and getty as weak
requires (the mainline target references nulld/rtcd which we
filtered out).
Address 4 gaps in the new redbear-bare target per review:
Gap 1: add REDBEAR_BARE_INITFS env var to base-initfs recipe. When
set, BINS=init logd ramfs randd zerod ptyd getty instead of 22+
daemons/drivers. The bare target can now opt into the truly-minimal
initfs via the env var.
Gap 2: add ptyd and getty to the cp case-list so they go to /initfs/bin
not /initfs/lib/drivers. Without this, the getty 2 service cannot
start because ptyd (which it requires) isn't in the initfs.
Gap 3: add /etc/issue (pre-login banner) and /etc/motd (post-login
message) to the bare config. Standard Unix login surface polish.
Gap 4: trim packages in the bare config. Override ca-certificates,
pkgutils, kibi (from minimal.toml) to empty. Bare only needs:
zsh, coreutils, base, base-initfs, kernel, relibc, userutils,
libgcc, libstdcxx.
Build invocation:
REDBEAR_BARE_INITFS=1 make live CONFIG_NAME=redbear-bare
(NO AI attribution)
Submodule pointers for base and relibc moved (operator-side work).
recipes/wip/wayland/qt6-wayland-smoke remains a broken gitlink
(known; see local/docs/SESSION-2026-07-13-DOC-CLEANUP.md for carry-over).
(NO AI attribution)
bss_dgram.c uses 'struct in6_pktinfo' from <netinet/in.h> which is
not fully defined in relibc headers (sizeof on incomplete type).
Added no-dgram to disable datagram BIO (DTLS/QUIC) for now.
Red Bear OS doesn't need DTLS yet — standard TLS via stream sockets
is sufficient.
OpenSSL's Configure detects x86_64-unknown-redox-gcc as the compiler
but Make can't find it because the cross-compiler prefix/bin is not
in PATH. Added COOKBOOK_HOST_SYSROOT/bin to PATH before Configure call.
Also added no-sctp flag since relibc lacks <netinet/sctp.h>.
Archived mega-patches (kernel/redox.patch, base/redox.patch, relibc/redox.patch,
installer/redox.patch, bootloader/redox.patch, P2-boot-runtime-fixes) were
consolidated into modular P0-...P9- patches during Phase 2/3 cleanup but the
integrity checker still expected them. Removed from EXPECTED_PATCH_SYMLINKS
and CRITICAL_PATCHES arrays. Fixed qt6-wayland-smoke symlink.
Overlay integrity check now PASSES (0 errors).
--with-pic alone doesn't generate PIC code in newer ncurses (6.6+).
The static archive produced non-PIC objects using R_X86_64_PC32
relocations, which can't be linked into PIE executables.
Forced PIC via:
- Switched DYNAMIC_INIT → DYNAMIC_STATIC_INIT (builds both shared AND static)
- Added CFLAGS+=+=-fPIC CXXFLAGS+=+=-fPIC export (forces PIC at compile)
redbear-netctl-console now links successfully against libncursesw.a.
Static archives without -fPIC cannot be linked into PIE executables
(default on modern Linux). redbear-netctl-console failed to link with:
libncursesw.a: relocation R_X86_64_32 ... can not be used when making a PIE
object; recompile with -fPIE
Added --with-pic to ncurses and ncursesw configure flags to produce
position-independent static archives.
Previously, same_as recipes (ncursesw uses same_as = ../ncurses) would
fail with 'cannot guess version' because the cookbook only falls back
to Cargo.toml extraction, not the target's recipe.toml.
Now when source is same_as, read the target's recipe.toml directly and
use its [package].version field. Falls back to Cargo.toml probe if no
version is set in the target recipe.
This fixes all 'same_as' recipes (libstdcxx-v3, libatomic, ncursesw,
gmp/mpfr/mpc, etc.) without requiring explicit [package] on each.
ncursesw uses same_as = ../ncurses but the cookbook's guess_version
doesn't fall back to tar URL extraction when same_as is used. With
only [source] and [build], ncursesw has no parseable version → fails.
Added explicit [package] section with version 6.6 to ncursesw recipe,
matching the upstream ncurses version.
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.
Comprehensive fix — not a fallback. Each recipe now has explicit
[package] section with name and version. Version inference:
- Git-source recipes without rev/branch: '0.1.0' (Red Bear convention)
- Tar/git recipes with version in URL or dir name: extracted version
- Sysroot-copy recipes: matched to toolchain version
Affected: 250+ recipes across all categories (core, libs, dev, system,
kde, qt, drivers, gpu, drm, kernel, userspace, etc.) Every recipe
in the redbear-mini build chain that was missing [package] now has
explicit version metadata. Cookbook can now always determine a version
at packaging time, eliminating 'cannot guess version' failures.
No cookbook fallback hack — the source of truth is recipe metadata.
netdb: git source with no rev/branch — added explicit version 0.1.0.
Reverted the 'guess_version -> 0.1.0' cookbook fallback — masking
missing versions is not a fix, proper recipe metadata is.
vasilito