The 6.11.1 upgrade bumped recipe URLs+blake3 for the Qt modules but left stale
committed fetch-caches for three of them: qtdeclarative/qtwayland/qt6-sensors
shipped source.tar (and qt6-sensors a source/ extract) still at 6.11.0. repo
validates the cache against recipe blake3, so the stale 6.11.0 tar mismatched
the 6.11.1 pin -> "downloaded tar blake3 ... is not equal to blake3 in
recipe.toml" -> qtdeclarative cook failed, cascading Qt6Qml failures in every
downstream consumer (qtwayland, kf6-*), aborting the whole build.
Root cause of the committed caches: .gitignore only ignored recipes/**/source.tar
(mainline tree), never local/recipes/**/source.tar, so local fetch-caches were
committable and went stale on version bumps. Fixes:
- git rm the stale 6.11.0 source.tar (x3) + qt6-sensors 6.11.0 source/ extract
so the build re-fetches the pinned 6.11.1 tarballs.
- .gitignore: ignore local/recipes/**/source.tar(.tmp) (fetch-cache; NOT
source/, the durable fork model) so this cannot recur.
qtbase/qtshadertools/qtsvg were already correct (source.tar==6.11.1==pin).
sddm and the kf6 modules (pulled by kwin) do find_package(Qt6Qml)/Qt6Quick,
which only exist once qtdeclarative is built. When resolved only transitively
during the parallel make-live graph, a consumer (qtwayland, kf6-kwindowsystem)
could be cooked before qtdeclarative published Qt6Qml -> "Could not find a
package configuration file provided by Qt6Qml" -> whole build aborts (exit 2).
Pre-cook qtbase qtshadertools qtdeclarative qtsvg qtwayland (in order) before
sddm/kwin so every Qt6 CMake config is cached in the sysroot first. Complements
the qtwayland->qtdeclarative recipe dep; covers all kf6 consumers at once.
qtwayland CMakeLists find_package(Qt6Qml) for the QtWaylandCompositor QML
integration. Without qtdeclarative in dependencies, cookbook may cook qtwayland
concurrently with qtdeclarative and configure fails with "Could not find a
package configuration file provided by Qt6Qml". Declaring the dep serializes
the build: qtbase -> qtshadertools -> qtdeclarative -> qtwayland.
qnetworkinterface_unix.cpp getifaddrs path declares `struct ifreq ifr` to pass
to getMtu(), but Redox relibc <net/if.h> provides only interface flags and the
if_nameindex() helpers -- no struct ifreq (Redox has no SIOCGIF* ioctls). The
SIOCGIFMTU body in getMtu() is #ifdef-guarded and compiles out, so the type
only needs to be complete. Define a minimal-but-standard struct ifreq under
#if defined(__redox__) at file scope; the ioctls that would use it fail
gracefully at runtime (mtu stays 0). Durable patch, wired into qtbase recipe.
The 8-element block-character ramp in the panel footer's
size-distribution histogram was indexed with a level that could
clamp to 8 (one past the end). The math scaled count/max_bucket to
[0, 8] and clamped with .min(8); for any populated directory the
max bucket always produced level == 8, panicking on the first
render with 'index out of bounds: the len is 8 but the index is 8'.
Replaced the inline arithmetic with a dedicated histogram_level
helper that mirrors the sparkline helper in ops/progress.rs:
scale count/max_bucket to [0, 7] and clamp to 7. The 8-element
array is now a named constant HIST_BLOCK_CHARS so the index
constraint is visible at the use site.
Added five regression tests:
- histogram_level_clamps_to_seven_for_max_bucket: the exact case
- histogram_level_returns_zero_for_empty_input
- histogram_level_monotonic_in_count: levels grow with count
- histogram_level_never_panic_indexes: exhaustive count in [0..max]
for max in [1..256]
- render_panel_does_not_panic_on_populated_directory: end-to-end
size_histogram + histogram_level + array index
Also: render() used to silently skip when the terminal reported
< 10x5, leaving the user with a blank screen and no feedback. It
now logs a one-shot warning to stderr and draws a single-line
yellow-on-black 'Terminal too small' message on the terminal so the
user can resize and continue.
Verified: 1474 lib tests pass (up from 1433), no new clippy warnings,
no panic in populated/empty/normal/tiny terminal scenarios, tlcedit
unaffected.
forkfd_qt.c includes <forkfd.h> (whose forkfd_wait4 prototype takes struct
rusage*) before struct rusage is declared at file scope; sys/resource.h is only
pulled in later by forkfd.c. So the header prototype gets a prototype-scoped
struct rusage incompatible with the file-scope one in the definition ->
"conflicting types for forkfd_wait4". 6.11.0 qglobal.h pulled it in
transitively; 6.11.1 does not. Fix: include <sys/resource.h> before <forkfd.h>.
Durable patch, wired into qtbase recipe.
Add a "Canonical build — do NOT bypass" subsection to AGENTS.md and
local/AGENTS.md, and inline warnings above every instructional repo cook /
repo fetch / make live / make r.<recipe> mention across the build/patch/plan
docs. Rationale (learned the hard way this session): direct repo cook/fetch
skips apply-patches.sh patch-linking + staleness handling, causing broken
patches (qtsvg CVE) and wasted rebuilds. Always build via
local/scripts/build-redbear.sh.
The recipe referenced "qtsvg/CVE-2026-6210.patch" (relative to the recipe dir →
recipes/.../qtsvg/qtsvg/CVE... which does not exist); the patch lived in
local/patches/qtsvg/. apply-patches.sh does not link it, so both direct fetch
and the canonical build failed to find it. Move the patch into the qtsvg recipe
dir (durable /local, same model as qtbase redox.patch) and reference it by bare
name so the build system resolves it.
Move the Redox in6_pktinfo patch into local/recipes/qt/qtbase/ (where qtbase
redox.patch lives) and add it to the [source] patches list, so a clean fetch of
qtbase 6.11.1 re-applies it. Verified: fetch of 6.11.1 applies all 3 patches
atomically. Durable in local/, resolved by the build system (no bypass).
Records the fix that unblocked qtbase on Redox: relibc lacks struct in6_pktinfo,
which Qt sizes cmsg buffers with in both datagram paths. Define it at file scope
(outside the QT_NO_SCTP guard that Redox compiles out). The current qtbase.pkgar
was built from the equivalent in-tree source edit; this patch is the durable
form. NOT yet added to recipe.toml patches[] — wiring it invalidates the qtbase
cache and forces a full re-cook, so it is wired as the final step once the ISO
assembles (during the desktop-stack fix phase qtbase stays cached).
On Redox relibc defines CLOCK_MONOTONIC=4 (not Linux 1) and has no
CLOCK_MONOTONIC_RAW, so -DCLOCK_MONOTONIC_RAW=4 collided with CLOCK_MONOTONIC in
wsi_common_wayland.c (duplicate case). The greeter uses GL/llvmpipe not Vulkan,
and Vulkan WSI is the only consumer of these Linux clock constants, so disable
vulkan-drivers to drop that unit. Also make the define collision-proof
(CLOCK_MONOTONIC+1000) for any non-Vulkan user.
Aliasing CLOCK_MONOTONIC_RAW to CLOCK_MONOTONIC created a duplicate case value
in wsi_common_wayland.c (switch has both). Use the real Linux clockid 4 so the
value is distinct and the switch compiles.
Vulkan WSI (wsi_common_wayland.c) uses CLOCK_MONOTONIC_RAW, which relibc does
not define (undeclared). Map it to CLOCK_MONOTONIC via a recipe c_args define;
for a display server the unadjusted-vs-NTP-slewed distinction is immaterial.
Third Redox mesa port gap.
meson 26.1.4 resolves wayland-scanner from the target wayland-scanner.pc, whose
absolute path is COOKBOOK_SYSROOT/usr/bin/wayland-scanner — the Redox cross
binary, which cannot execute on the Linux build host (ninja: code=127 "cannot
execute: required file not found") when generating fifo-v1-protocol.c etc. The
$WAYLAND_SCANNER env / PATH symlink do not help (meson uses the .pc absolute
path). Protocol codegen is host/target-independent, so overwrite the sysroot
copy with the runnable host wayland-scanner before meson runs. Next Redox mesa
port gap after alloca.
mesa uses alloca() in shader_query.cpp (and elsewhere) without including
<alloca.h>; on Redox stdlib.h does not pull it in, so the C++ compile failed
with "alloca was not declared in this scope". Redox relibc DOES provide alloca
(alloca.h = #define alloca(s) __builtin_alloca(s)); force-include it via meson
c_args/cpp_args so every alloca user resolves to the builtin. Next Redox mesa
port gap after the EGL gate; mesa now compiles past it.
Assessing/fixing the boot->SDDM chain for the full ISO:
1. VirGL driver table: the INSTALLED /lib/drivers.d/30-graphics.toml is inline
data in config/redbear-full.toml (not local/config/drivers.d/), and was
missing the priority-61 redox-drm entry for vendor 0x1AF4 — so virtio-gpud
could win the QEMU virtio-gpu bind and no /scheme/drm/card0 would exist.
Add the VirGL entry to the inline table (the one actually shipped).
2. Exclude redbear-iwlwifi (operator-authorized, temporary): it is a hard
cookbook dep of redbear-meta and its Redox build is WIP (fails at
src/linux_port.c), which aborts make live before the image assembles. Comment
it out of redbear-meta dependencies; nothing else pulls it. Re-add when green.
3. redbear-compositor: create_dir_all(XDG_RUNTIME_DIR) before binding the
Wayland socket. On Redox there is no logind to create /tmp/run/redbear-greeter,
so the bind failed with ENOENT and the SDDM greeter never got a compositor.
Toward: launch redbear-full ISO in QEMU and reach the SDDM Wayland login.
Iterating on one recipe (e.g. redbear-iwlwifi) forced a ~30-min re-churn every
rerun: the relibc-consumer invalidation (build/sysroot wipe + pkgar/target
deletion) re-cooked dozens of cached packages before reaching the edited one,
even when relibc was unchanged. Add REDBEAR_SKIP_ABI_STALENESS=1 to skip both
the layer-B build/sysroot clean and the layer-C invalidation loops. The
cookbook BLAKE3 dep-hash cache still re-cooks recipes whose sources changed, so
the edited package rebuilds while everything else stays cached — the rerun goes
straight to it. Safe only when relibc ABI is unchanged (documented + escape is
opt-in); unset to restore the stale-binary safety net when bumping relibc/base.
Documented in --help alongside REDBEAR_FORCE_TOOLCHAIN_RECOOK.
Mirrors Linux 7.1's pci_ers_result (include/linux/pci.h:920-938):
None/CanRecover/NeedReset/Disconnect/Recovered/NoAerDriver. This is
the vocabulary Driver::error_detected will return when the AER
recovery flow is wired to bound drivers. Currently the legacy
RecoveryAction enum (Handled/ResetDevice/RescanBus/Fatal) coexists
for the existing on_error callback — PciErsResult is the richer model
that will replace it once the driver-manager → driver IPC channel
exists for AER dispatch.
ConcurrentDeviceManager::from_manager called bus.enumerate_devices()
a second time inside its constructor — the same buses DeviceManager::
enumerate() had just enumerated to build the remaining list. Renamed
to from_devices(mgr, devices) which takes the already-enumerated
Vec<DeviceInfo> directly, eliminating the redundant I/O and removing
a potential consistency window between the two passes.
- redox-driver-sys: drop unused 'use std::sync::Once' in pci.rs and
underscore-prefix unused 'vendor' in lookup_hid_quirks. Zero
crate-local warnings (libredox's 2 are upstream fork code).
- udev-shim: scan_pci_devices now reads /scheme/driver-manager/bound
and populates DeviceInfo.driver for each PCI device; the DRIVER=<name>
property flows into the uevent output so libudev consumers (udisks,
KDE Solid) see the bound driver — closing the assessment gap from § 11.
d945483915 added a per-thread IOPL guard using std::sync::Once in a
#[cfg(target_os = "redox")] thread_local! (pci.rs:20) but did not import Once,
so redox-driver-sys fails to compile for x86_64-unknown-redox with E0425
"cannot find type Once" — breaking redox-drm (the /scheme/drm/card0 provider)
and driver-manager in the redbear-full build. Add the cfg-gated import.
Found while driving the redbear-full desktop build.
Operator confirmed "SDDM is the only greeter". Disable the two competing
display entry points that would contend with SDDM for the single-owner
GPU/card0: 20_greeter (redbear-greeterd, an alternative greeter) and 20_display
(redbear-session-launch, a boot-time auto-KDE-session that bypasses the
greeter). Gated reversibly via condition_path_exists on a sentinel
(/etc/redbear/enable-legacy-greeter) the image does not install — definitions
preserved, re-enable with a single touch. 21_sddm remains ungated. Post-login
session launch is SDDMs job via SessionDir=/usr/share/wayland-sessions.
redbear-info's integration check list still labeled the PCI spawner as
'pcid-spawner' and pointed at /usr/bin/pcid-spawner (deleted). Updated
to 'driver-manager' with /usr/bin/driver-manager and a note about
/scheme/driver-manager/bound. Plan v3.2 marks P2-1 done (pcid AER +
pciehp producers validated in QEMU).
SDDM greeter renders on redbear-compositor (per /etc/sddm.conf CompositorCommand);
KWin is the post-login session compositor. Runtime chain (driver-manager →
redox-drm → card0 → sddm → redbear-compositor → greeter) is coherent, BUT three
display entry points (20_display redbear-session-launch, 20_greeter
redbear-greeterd, 21_sddm) all fire oneshot_async and would contend for the
single-owner GPU/card0. For a clean SDDM path the first two must be disabled
(operator sign-off required).
Phase status for making redbear-full compile + run to the SDDM Wayland greeter:
build-system llvm fix, Mesa EGL gate persisted, VirGL priority (all done);
Rust components (redox-drm, redbear-compositor) compile-verified; remaining =
full C/C++ cook campaign (mesa/qt6/kf6/kwin/sddm) + Qt6 null+8 runtime validation
+ boot. Records upstream cherry-pick candidates and component homes.
driver-manager had a priority tie for QEMU virtio-gpu (vendor 0x1AF4, class
0x03): redox-drm (generic class @60) vs virtio-gpud (@60). If virtio-gpud won,
it registered display.virtio-gpu (VT scanout only) and never provided
/scheme/drm/card0, starving KWin/the compositor. redox-drm had priority-61
entries for Intel and AMD but none for VirtIO. Add a priority-61 redox-drm entry
for vendor 0x1AF4 class 0x03 (subclass omitted — QEMU virtio-gpu is subclass
0x80) so the VirGL path deterministically binds redox-drm and gets a real DRM
card0. virtio-gpud remains as fallback.
The meson gate that enables EGL on Redox — adding "redox" to
system_has_kms_drm (meson.build:159, so with_dri→with_egl/gbm) and to the
_GNU_SOURCE platform list (:1208) — existed only as an in-place edit in the
untracked extracted source/ tree. Any clean re-extract lost it and reverted to
"Feature egl cannot be enabled". Capture it as local/patches/mesa/08-*.patch and
wire it into recipe.toml so EGL/GBM/llvmpipe build reproducibly. Source tree
reverted to pristine so the patch is the sole, tracked change.
The relibc-consumer invalidation (correctly) force-deletes every pkgar+target
when relibc rebuilds or its pkgar is missing, to prevent stale-ABI skew. But it
swept up heavy, ABI-inert toolchain packages (llvm21, clang21, lld21, rust)
identically to a 200KB daemon — forcing a 1-2h LLVM re-cook on EVERY base/relibc
bump, which cripples Mesa/KDE iteration.
These are build-time-only STATIC archives (BUILD_SHARED_LIBS=off; no runtime .so
of their own). Their libc/relibc symbol references are UNRESOLVED in the .a and
resolve at the CONSUMER final link — mesa links libLLVM*.a and resolves against
the freshly-built relibc there. So a relibc protocol change is absorbed by
relinking mesa (NOT on the preserve-list; stays invalidated), and recompiling
all of LLVM from scratch is unnecessary.
Add TOOLCHAIN_PRESERVE={llvm21,clang21,lld21,rust} skipped in both invalidation
branches, with escape hatch REDBEAR_FORCE_TOOLCHAIN_RECOOK=1 for a genuine
libc-ABI change. Trades a rare theoretical risk for a large repeated speedup;
the churn during driver/desktop work is Redox scheme/syscall shims the compilers
never call, so the default is safe.
Record the two concrete prerequisites for compositor input wiring, found by
reading the compositor source: (1) an event-loop restructure — it uses a
blocking accept loop, drains keys only reactively, and ClientState stores no
UnixStream, so no input source can push wl_keyboard to a client; (2) the
desktop cannot run without DRM/Mesa (no /scheme/drm/card0 on mini), so the
wiring is unvalidatable until the Mesa EGL/DRI port lands. Defines the exact
wiring for when those clear (read /scheme/evdev, set_vt_mode, real XKB keymap
fd, keycode = evdev - 8).
P0 green (acpid compiles). Fresh redbear-mini boot confirms: no console
regression (login + shell command execution intact) and the raw tap is live
(evdevd reads consumer_raw, evdev scheme functional). Boot-log errors observed
are pre-existing and unrelated to the input stack.
- AER listener path moves from /scheme/acpi/aer (no producer) to
/scheme/pci/aer (pcid's new producer, submodule bump 5a43628d).
- redbear-iwlwifi --daemon parks via thread::sleep instead of
thread::park — park/unpark is unvalidated on the Redox target (the
thread::scope finding from the runtime gate).
Record what landed (S1 raw evdev tap, S4-core VT graphics-mode op, S5 seatd
local package; all compile-checked, boot-validation P0-gated) and correct the
Defect-3 framing: fbcond is a byte-queue + CR/LF + special-key escapes, not a
second canonical line discipline (ptyd is the only one), and the console login
works — so the old "collapse two disciplines" console surgery is deferred as
unnecessary and risky. Grab arbitration + compositor wiring remain gated on the
Mesa desktop bring-up.
Flip [source] from git=jackpot51/seatd to path="source" so the already-tracked
in-tree source/ (52 files, incl. libseat/seatd-launch) is the authoritative
implementation — a first-class local Red Bear package like evdevd and
redbear-compositor, per Local Fork Supremacy and the operator decision
(INPUT-STACK-LINUX-ALIGNMENT-PLAN.md §4b). We own it and integrate upstream
into our tree rather than fetch+patch.
Does not affect redbear-mini/bare (they do not pull seatd). Making it compile
for Redox + wiring the compositor seat path remain part of the Mesa-gated
desktop bring-up.
Point evdevd at /scheme/input/consumer_raw (the new raw device tap added in
base bd5e3db3) instead of /scheme/input/consumer. The console consumer handed
evdevd keymapped, VT-gated events — it only received input while its own VT
was active, and the character had already been keymapped, both wrong for a
libinput/xkbcommon (Wayland) feed. The raw tap delivers the pre-keymap event
stream for every device event regardless of the active VT, matching the Linux
evdev contract.
evdevd only ever used scancode+pressed (never character), so no translation
change is needed on its side.
Bumps the base submodule pointer to include the consumer_raw tap. Part of the
Linux-aligned input-stack consolidation
(local/docs/INPUT-STACK-LINUX-ALIGNMENT-PLAN.md). Compile-checked for
x86_64-unknown-redox.
Phase 6.2 foundation. Port the Mini-MLD layer from Linux 7.1
(drivers/net/wireless/intel/iwlwifi/mld/), the MLD analog of Mini-MVM:
- linux_mld.h: iwlmld op-mode IDs, notification command groups
(LEGACY/MAC_CONF/PHY_OPS/DATA_PATH/SCAN/STATISTICS), and the MLD
notification command ID set. The RX frame IDs (0xc0/0xc1/0xc5) and the
iwl_rx_mpdu_desc descriptor are shared with MVM and stay in Mini-MVM;
MLD adds ROC/session-protection/MU-group-mgmt/probe-response/
channel-switch/MFUART/DTS-measurement notification IDs.
- linux_mld.c: rb_iwl_mld_handle_notification() — real MLD notification
dispatch. RX MPDU frames are parsed by the Mini-MVM descriptor parser
(rb_iwl_mvm_extract_signal/detect_format, no duplicate parser) with real
signal/rate extraction; MLD-specific notifications are identified,
grouped, and counted. Includes the BZ-family op-mode selection
(rb_iwl_opmode_for_family, mirroring Linux iwl-drv.c).
- linux_port.c: include linux_mld.h; add trans->opmode set from
device_family (BZ -> iwlmld, others -> iwlmvm); report opmode= in the
linux_kpi_status line so the gate is observable.
- build.rs: compile linux_mld.c.
This is the bounded foundation; MLO/link management and the full MLD
feature set (mac80211-integrated) are the multi-week continuation.
All 8 host tests pass.
vasilito