The cub AUR→RBPKGBUILD→recipe.toml conversion pipeline (located at
local/recipes/system/cub/source/) was assessed end-to-end against
12 representative real-world PKGBUILDs:
- libevdev (simple meson)
- fd-find (cargo)
- libpciaccess 0.18.1 (meson)
- fmt (cmake)
- wlroots-git (git source, complex deps)
- libpciaccess 0.19 (extra/-style, meson + ninja)
- ffmpeg (configure + options)
- mesa 24.3 (git+url + multi-source + pkgver())
- gzip (configure + git source + check)
- zlib (simple C, configure)
- openssl (pkgbase split package)
- glib2 (complex deps, real-world)
The assessment found 8 critical bugs that would prevent cub from
producing working Red Bear recipes for any real Arch package. 7 of
the 8 bugs were fixed in the previous commit (7c5b1f36e); the 8th
(custom-template recipes lack DYNAMIC_INIT and cookbook_apply_patches
boilerplate) is deferred as a cookbook-integration concern.
This commit adds two artifacts of the assessment:
1. local/docs/cub-assessment-and-improvement-plan.md (508 lines,
~28KB): the complete assessment document. Sections:
- Executive summary (architecture decision + 8-bug verdict)
- What cub does well (10+ working cases)
- The 8 bugs (location, severity, root cause, fix)
- Test methodology
- Test cases by category (A: conversion success, B: dep mapping,
C: source URL, D: build template, E: edge cases, F: validation)
- Forward improvement plan (16 items in 4 tiers)
- Appendix A: cub architecture map (CLI + 17 modules)
- Appendix B: RBPKGBUILD format spec
- Appendix C: Generated recipe format vs. real Red Bear recipe
2. local/recipes/system/cub/source/cub-assessment/:
a 12-PKGBUILD integration test harness. A standalone binary that
exercises the conversion pipeline on each PKGBUILD and reports
status, warnings, action_items, recipe validity (TOML), and the
first 30 lines of the generated recipe. Used to verify the bug
fixes in 7c5b1f36e — all 12 cases convert successfully
post-fix, including the previously-erroring mesa 24.3 (which
now produces a valid recipe with a multi-source warning).
The test harness lives next to the cub source (cub-assessment/) and
has its own Cargo.toml with [workspace] empty so it doesn't join the
cub workspace. Build/run with:
cd local/recipes/system/cub/source
cargo run --manifest-path cub-assessment/Cargo.toml
The harness is intended for use by future cub maintainers to catch
regressions. It's not wired into CI yet — that would be a separate
task.
After running an empirical assessment of cub's AUR→RBPKGBUILD→recipe
pipeline against 12 representative real-world PKGBUILDs (libevdev,
fd-find, libpciaccess, fmt, wlroots-git, ffmpeg, mesa 24.3, gzip,
zlib, openssl, glib2, plus a libpciaccess extra/-style variant), 7
critical bugs were found that would prevent any real Arch package
from converting to a working Red Bear recipe.
Fixes (all surgical, in cub-lib/src/):
1. deps.rs: drop glibc dependency (was: mapped to relibc, which is
wrong because relibc is the Redox C library and is part of the
OS, not a package). glibc is a tautology on Redox and must be
omitted. The empty mapping triggers the standard 'omitted' path
in map_dep_list with a clear 'has no Redox mapping' warning.
2. deps.rs: drop gcc-libs dependency (was: mapped to gcc, which
conflates the runtime libgcc/libstdc++ with the compiler).
gcc-libs is provided by relibc on Redox and must be omitted.
3. deps.rs: prefix build tools (meson, ninja, cmake, make,
pkg-config, autoconf, automake, libtool, git, perl, python,
rust, cargo, llvm, clang, swig, bison, flex, doxygen, and ~50
more) with 'host:' so the Redox cookbook knows they're host-only
and not part of the cross-compiled target. The new BUILD_TOOLS
constant lists all known build tools; map_dependency returns
'host:<name>' for entries in this set.
4. pkgbuild.rs: parse AUR-style 'git+url#tag=branch' source syntax.
The new split_source_fragment function strips the 'git+' prefix,
extracts the '#tag=...' or '#branch=...' or '#commit=...'
fragment, and maps to the Redox cookbook's [source].branch or
[source].rev field. The previous behavior kept the literal
'git+...#tag=...' URL in the recipe, which is invalid Redox
cookbook format.
5. pkgbuild.rs: support multi-source PKGBUILDs. Real packages like
mesa have 2+ sources (git repo + extra file). The previous
behavior errored on multi-source with 'multiple sources not yet
supported'. Now: keep the first source as primary, warn about
the rest, and continue conversion. Auxiliary sources are listed
in the warning message so the user can re-add them.
6. pkgbuild.rs: preserve options=() flags (e.g., '!lto', '!strip',
'!emptydirs') in the new RBPKGBUILD compat.options field.
Previously dropped silently.
7. pkgbuild.rs: substitute \${pkgver}, \${pkgname}, etc. in source
URLs by piping each entry through resolve_shell_vars before
converting. The previous behavior kept the literal '\${pkgver}'
in the URL, making the recipe's [source].tar URL invalid.
All fixes verified by:
- cub-assessment: 12 PKGBUILDs all convert and produce valid TOML.
The mesa 24.3 case (which previously errored on multi-source) now
produces a valid recipe with a warning. ffmpeg's glibc is now
correctly dropped. All build tools (meson, ninja, etc.) are
correctly host: prefixed. All AUR git+url sources parse
correctly into branch/rev fields.
- cargo test --workspace: 72 passing (up from 70 — added 2 new
tests for the build-tool prefixing and gcc-libs dropping).
The 8th known issue (custom-template recipes lack DYNAMIC_INIT and
cookbook_apply_patches boilerplate) is deferred — it's a separate
cookbook-integration concern tracked in the cub assessment plan
(local/docs/cub-assessment-and-improvement-plan.md).
This is the final cleanup batch for the Rule 2 big-project migration
work (pipewire, wireplumber, mesa, libdrm all migrated to upstream git
+ external patches in local/patches/<component>/).
Changes:
* local/recipes/libs/libdrm/recipe.toml: upgrade from
template = 'meson' + mesonflags to template = 'custom' +
DYNAMIC_INIT + cookbook_apply_patches + cookbook_meson. This
matches the structural pattern used by the other 3 Rule 2
migration recipes (mesa, pipewire, wireplumber) and gives libdrm
the same flexible shell-script build context for future
cross-compilation tweaks. Adds build dependencies expat,
libpciaccess, meson, ninja-build, pkgconf (the meson template
had these implicit; the custom template requires them explicit).
Patch application still goes through cookbook_apply_patches
(4 dots from local/recipes/libs/libdrm/ to project root).
* local/recipes/AGENTS.md: catalog update reflecting the libdrm
template change (now 'custom' instead of 'meson') and adding
catalog entries for 4 recipes that were created during this
migration round but were missing from the catalog: libxkbcommon,
pam-redbear, pipewire, wireplumber.
* sources/redbear-0.1.0/manifest.json: add a new manifest entry
for 'libs/libdrm' (the historical 0.1.0 archive entry for libdrm,
which uses the patched tarball). This mirrors the existing
'lib/libdrm' entry and gives 'repo restore' a consistent way to
recover the libdrm source from the 0.1.0 release archive.
* Doc updates: AGENTS.md, README.md, local/AGENTS.md,
local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md, local/docs/GPU-MESA-
KDE-CHAIN-ASSESSMENT.md, local/recipes/AGENTS.md: bring the
docs in line with the Rule 2 policy and the 4-migration set
(pipewire, wireplumber, mesa, libdrm). Most are catalog or
cross-reference updates.
* local/docs/STUBS-FIX-PROGRESS.md: heavily trimmed (-303 net).
The old document was tracking 346+ stub fixes from earlier
sessions; most of those are now closed and the document has
been condensed to the current state.
* local/docs/SOURCE-OWNERSHIP-MODEL.md: deleted (-89 lines).
This old doc described a 'source ownership' concept that has
been superseded by the amended AGENTS.md Rule 2 (NO OVERLAY-
STYLE PATCHES — SCOPED POLICY) section, which is the canonical
source-ownership model going forward.
Two related cleanups for the libdrm Rule 2 migration (commit 5f5eec1c4):
* libwayland: add -Dscanner=false to cookbook_meson, with a 20-line
comment explaining the rationale. Without this flag, libwayland's
meson.build builds a `wayland-scanner` executable for the *target*
(Redox). The resulting binary has /lib/ld64.so.1 as its ELF
interpreter (Redox's loader) and is useless on the build host. The
pkgconfig that libwayland installs (wayland-scanner.pc) then points
`wayland_scanner` to this Redox binary, and downstream consumers
(mesa, wayland-protocols) pick it up via
dependency('wayland-scanner'). When the cookbook's redoxer sandbox
tries to exec it on the host, the host kernel can't find
/lib/ld64.so.1 and the build fails with 'required file not found'.
Disabling the scanner means libwayland doesn't install
wayland-scanner to the sysroot. Downstream consumers then fall
through to the host's /usr/bin/wayland-scanner (a proper
x86_64-linux-gnu binary that works on the build host). This
matches what wayland-protocols already does in its own meson.build
(see its redox.patch in the recipe).
* libdrm: remove 4 orphaned source-cache files that were left over
from the libdrm Local source fork at local/sources/libdrm/ (deleted
in commit 5f5eec1c4). The 4 files were the in-tree Red Bear edits
that are now external patches in local/patches/libdrm/:
- source/virtgpu_drm.h DELETED (was in 01-drm-ioctl-bridge.patch)
- source/xf86drm.c MODIFIED (most edits moved to patch)
- source/xf86drmMode.c MODIFIED (most edits moved to patch)
- source/xf86drm_redox.h DELETED (was in 01-drm-ioctl-bridge.patch)
The local/recipes/libs/libdrm/source/ cache is now empty (only
upstream files) and is regenerated by 'repo cook' from the upstream
git URL specified in the recipe. These 4 files are no longer
touched by the build system.
Fixes the build correctness issue where downstream mesa/wayland-protocols
builds would fail with 'required file not found: /lib/ld64.so.1' due to
wayland-scanner being built for the wrong target. The fix mirrors what
upstream Redox's wayland-protocols recipe does in its own meson.build.
Replace the inline `for p in ${REDBEAR_PATCHES_DIR}/[0-9]*.patch; do
git apply ...; done` loop in each of the 4 Rule 2 migration recipes
with a single call to cookbook_apply_patches (added in the previous
commit to src/cook/script.rs).
Before (9 lines per recipe):
REDBEAR_PATCHES_DIR="${REDBEAR_PATCHES_DIR:-...}/local/patches/<component>"
cd "${COOKBOOK_SOURCE}"
for p in "${REDBEAR_PATCHES_DIR}"/[0-9]*.patch; do
[ -f "$p" ] || continue
echo "Applying Red Bear <component> patch: $p"
git apply "$p" || { echo "Failed to apply $p"; exit 1; }
done
cd "${COOKBOOK_BUILD}"
After (1 line per recipe):
REDBEAR_PATCHES_DIR="${REDBEAR_PATCHES_DIR:-...}/local/patches/<component>"
cookbook_apply_patches "${REDBEAR_PATCHES_DIR}"
Behavior change: the helper is now idempotent (skips already-applied
patches via `git apply --reverse --check`), so a partial re-cook
after a previous successful build no longer fails with 'patch already
applied'. This was the primary motivation for the refactor.
Per-recipe path depth notes (for the record):
* mesa — recipes/libs/mesa/ (depth 2) — 2 dots
* libdrm — local/recipes/libs/libdrm/ (depth 3) — 4 dots
* pipewire — local/recipes/libs/pipewire/ (depth 3) — 4 dots
* wireplumber — local/recipes/libs/wireplumber/ (depth 3) — 4 dots
All four recipes parse as valid TOML and use the cookbook's
[source].script (libdrm) or [build].script (mesa/pipewire/wireplumber)
hook, both of which load cookbook shell functions including the new
cookbook_apply_patches helper.
Per local/AGENTS.md Rule 2 (NO OVERLAY-STYLE PATCHES — AMENDED 2026), big
external projects must NOT have source forks in local/sources/. libdrm's
Red Bear edits now live as external patches in local/patches/libdrm/,
matching the established pipewire and wireplumber migration pattern
(commits 8ff9da2ff, 722f0c452).
The 5 patches were recovered from git history (commit 89d1306c8^ —
the migration that deleted them) and renamed to the modern Rule 2
NN-prefix naming for lexical-order application:
01-drm-ioctl-bridge.patch (P1 from old series, 278 lines)
02-ioctl-response-sizes.patch (P1 from old series, 30 lines)
03-drm-get-pci-info.patch (P2 from old series, 153 lines)
04-drm-get-version-driver-name.patch (P3 from old series, 34 lines)
05-drmGetDeviceFromDevId-redox.patch (P4 from old series, 68 lines)
These patches add the Redox-side ioctl/ioctl-com and scheme: dispatch
path needed by redox-drm and Mesa radeonsi/iris.
The recipe now points at upstream libdrm 2.4.125
(https://gitlab.freedesktop.org/mesa/libdrm, tag libdrm-2.4.125) and
applies the patches via a [source].script hook (the cookbook's
"Optional script to run to prepare the source" field) with a
REDBEAR_PATCHES_DIR computed from COOKBOOK_RECIPE.
Fixes the broken state where the recipe referenced the now-deleted
local/sources/libdrm/ fork.
Per local/AGENTS.md Rule 2 (NO OVERLAY-STYLE PATCHES — AMENDED 2026), big
external projects must NOT have source forks in local/sources/. Mesa's
Red Bear edits now live as external patches in local/patches/mesa/,
matching the established pipewire and wireplumber migration pattern
(commits 8ff9da2ff, 722f0c452).
The 3 patches were recovered from git history (commit 89d1306c8^ —
the migration that deleted them) and renamed to the modern Rule 2
NN-prefix naming for lexical-order application:
01-virgl-redox-disk-cache.patch (P4 from old series, 49 lines)
02-gbm-dumb-prime-export.patch (P5 from old series, 56 lines)
03-platform-redox-gpu-probe.patch (P6 from old series, 264 lines)
These patches disable the virgl disk cache (dl_iterate_phdr is missing
on Redox), add the GBM dumb prime export for cross-GPU buffer sharing,
and implement the platform/redox GPU probe path needed for EGL/Vulkan
on Redox.
The recipe now points at upstream Redox mesa
(https://gitlab.redox-os.org/redox-os/mesa, branch redox-24.0) and
applies the patches via a git apply loop in [build].script with
correct path resolution (2 dots from recipes/libs/mesa/ to project root).
Fixes the broken state where the recipe referenced the now-deleted
local/sources/mesa/ fork.
Per local/AGENTS.md Rule 2 (NO OVERLAY-STYLE PATCHES — AMENDED 2026), big
external projects must NOT have source forks in local/sources/. PipeWire's
Red Bear edits now live as external patches in local/patches/pipewire/,
matching the established mesa, libdrm, and wireplumber migration pattern.
The patch contains the redox_compat/ shim headers (byteswap.h,
sys/mman.h) that bridge relibc gaps for the meson subprojects, the
__redox__ guards in src/pipewire/mem.c for the memfd_create emulation
on the redox ramfs scheme, and the __redox__ stubs in
src/pipewire/thread.c for pthread_setname_np and
sched_get_priority_min/max. It also includes the README-redbear.md
fork gap analysis and a small number of build script adjustments for
cross-compilation under the Redox toolchain.
The local/sources/pipewire/ fork is preserved as a historical reference
of the migration baseline but no longer used by the build system. A
follow-up commit will remove it after we verify a clean rebuild from
upstream git + the external patch.
The recipe's REDBEAR_PATCHES_DIR uses ../../../.. (four dots) to
correctly resolve to local/patches/pipewire/ from the recipe's depth
(local/recipes/libs/pipewire/recipe.toml). The mesa and libdrm
migrations shipped a path-count typo (one short); this recipe uses
the correct depth per local/AGENTS.md.
Per local/AGENTS.md Rule 2 (NO OVERLAY-STYLE PATCHES — AMENDED 2026), big
external projects must NOT have source forks in local/sources/. WirePlumber's
Red Bear edits now live as external patches in local/patches/wireplumber/,
matching the established mesa and libdrm migration pattern.
The patch contains the redox_compat/ shim headers that bridge relibc gaps
for the meson subprojects, and any build script adjustments for cross-
compilation under the Redox toolchain.
The local/sources/wireplumber/ fork is preserved as a historical reference
but no longer used by the build system. A follow-up commit will remove
it after we verify a clean rebuild from upstream git + patch.
Implements the 10 protocol surfaces from Phase 4 of CONSOLE-TO-KDE-DESKTOP-PLAN.md:
- xdg-shell: xdg_wm_base, xdg_surface, xdg_toplevel, xdg_popup, xdg_positioner
- xdg-output (zxdg_output_manager_v1)
- xdg-decoration (zxdg_decoration_manager_v1)
- wp_viewporter for surface scaling
- zwp_linux_dmabuf_v1 for hardware buffer import
- wl_data_device, wl_data_source, wl_data_offer for clipboard/drag-and-drop
- wl_subcompositor, wl_subsurface for sub-surface composition
All protocols are required for Qt6 / KDE Plasma / KWin clients to run under
redbear-compositor. The compositor still serves the greeter only; KWin is
the canonical compositor for the user session.
Captures the QEMU boot of the redbear-full target after the
VIRTIO_BLK_F_RO read-only fix landed in local/sources/base (commit
cffacf591 virtio-blkd: handle read-only drives gracefully). The
boot now proceeds past the previously-fatal virtio-blkd
assert_eq!(*status, 0) abort and continues through the rest of
the desktop init path, validating the fix end-to-end on the
desktop target.
The pre-fix pair is committed in the previous commit; keeping
pre/post pairs adjacent in main-repo history makes the regression
test reproducible from git alone without having to look up
when each log was captured.
Captured log: 16 893 bytes, 204 lines, same scope as the
pre-fix capture (q35 + OVMF, KVM, virtio-blk readonly ISO).
Marked-up analysis: REDBEAR-FULL-BOOT-POST-VIRTIO-BLKD-FIX-RESULTS.md
documents which init stages now reach the login prompt, which
drivers register, and what the next blocking stage is.
Captures the 300s extended QEMU boot of the redbear-full target
that exposed the virtio-blkd read-only assert. Boot progressed
through:
* PCI enumeration, pcid-spawner bring-up
* nvmed multi-queue registration
* virtio-blkd bring-up (READONLY boot ISO attached)
* ahcid probe
then panicked inside virtio-blkd during a write to the boot
drive. The ISO is attached with readonly=on (per the launcher
contract to protect the build artifact), and the driver received
VIRTIO_BLK_S_IOERR (status = 1) on what it expected to be a
writable block device; the assert_eq!(*status, 0) on line 70 of
drivers/storage/virtio-blkd/src/scheme.rs aborted the daemon.
The kernel caught the user-space invalid-opcode fault from the
aborted daemon and reported UNHANDLED EXCEPTION, CPU #0, PID 19
on the virtio-blkd scheme. Captured log is 16 893 bytes / 204
lines; the marked-up analysis (REDBEAR-FULL-BOOT-EXTENDED-RESULTS.md)
identifies the root cause and the missing VIRTIO_BLK_F_RO feature
negotiation that the follow-up commit in local/sources/base adds.
These two files are the only stable record of the pre-fix
behaviour; without them the regression test for the read-only
fix has no baseline. Both files are markdown + plain serial
console capture (no binary artifacts) and are safe to commit.
The post-fix pair (REDBEAR-FULL-BOOT-POST-VIRTIO-BLKD-FIX-RESULTS.md
+ redbear-full-boot-post-virtio-blkd-fix-20260609-181340.log)
are intentionally split into a separate commit so the pre- and
post-fix captures stay paired to their corresponding source
changes.
Adds a single canonical QEMU launcher for the redbear-full desktop
target so subsequent validation runs (boot logs, init probes,
DRM/KMS registration, audio-stack bring-up, D-Bus system bus) can
be reproduced from a single script.
Coverage:
* ACPI / GPE / Notify plumbing (acpid + kernel AML interpreter)
* v6.0 input architecture (evdevd + virtio-keyboard / virtio-mouse)
* MSI-X USB (xhcid via virtio xhci passthrough) and EHCI fallback
* multi-queue NVMe (nvmed with multiple queues)
* virtio-gpu (redox-drm via /scheme/drm/card0, opt-in via --with-gpu)
* virtio-net (e1000d / virtio-netd via net0 user-mode networking)
* D-Bus system bus (dbus) and redbear-sessiond
* SDDM + KWin Wayland compositor (when redbear-full image exists)
The launcher mirrors the per-target test-*qemu.sh scripts already
in this directory (test-ps2-qemu.sh, test-greeter-qemu.sh,
test-phase4-wayland-qemu.sh) so behaviour is consistent:
q35 + OVMF, KVM opportunistic with TCG fallback, serial log to
local/docs/boot-logs/ with a timestamped filename, snapshot=on
when booting the live ISO so the build artifact is not corrupted
across re-runs.
The QEMU display is intentionally hidden (no -display gtk/vnc);
the boot log is the source of truth, not a UI surface. This
matches the v6.0 2026 NO VESA POLICY: the standard display path
is /scheme/drm/card0 via redox-drm, and the test harness never
opens /scheme/display.vesa/.
Exit code 0 on capture, exit code 1 on missing prerequisites
(firmware, qemu, image); boot outcome is in the log, not the
exit code. The 60s default timeout mirrors the redbear-mini
boot time observed in test-ps2-qemu.sh / test-timer-qemu.sh and
can be overridden with --timeout.
The mesa recipe has been bouncing between direct-edit Wayland
configurations and the legacy Orbital EGL recipe. Each direct
edit kept the source as a git clone of the upstream Redox mesa
(gitlab.redox-os.org/redox-os/mesa, branch redox-24.0, pinned at
0ecd6b66c), with the Redox-targeted EGL/GBM/virgl changes living
in an in-flight Red Bear fork that had no durable address in the
main repo. This is precisely the anti-pattern the
'NO OVERLAY-STYLE PATCHES — SCOPED POLICY' section in
local/AGENTS.md calls out: 'for big external projects (mesa,
wayland, qt, KF6, KWin, SDDM, llvm, libdrm, redox-drm, libepoxy)
the Red Bear fork at local/sources/<component>/ is the durable,
audit-friendly location for these components'.
This commit completes the proper Red Bear full-fork model for
mesa:
* mainline recipes/libs/mesa/recipe.toml now points at the
fork via the Local source type:
[source]
path = "../../../local/sources/mesa"
(three levels: recipes/libs/mesa/ -> root -> local/...)
The cookbook's fetch.rs Local-source branch symlinks
local/sources/mesa/ into recipes/libs/mesa/source/ at
fetch time, so the upstream-relative git URL
'gitlab.redox-os.org/redox-os/mesa' is no longer needed
here.
* mainline recipes/libs/mesa/recipe.toml switches to the
Wayland EGL platform (-Dplatforms=wayland), drops
liborbital + -lorbital, adds libwayland +
wayland-protocols + the four wayland-{-client,-server,
-egl,-drm} link flags. The redox EGL platform
(src/egl/drivers/dri2/platform_redox.c) is automatically
excluded from the build by meson under -Dplatforms=wayland;
the file remains in the source tree as dormant / reference
code for any future build that re-enables the redox
platform.
* mainline recipes/libs/mesa/recipe.toml gets a [package]
section (version 0.2.3, description anchored on the
fork's 0.2.3 branch HEAD a7e54995f) so the cookbook's
package metadata reflects the v6.0 2026 release.
* recipes/libs/mesa/source is no longer a git submodule
gitlink (160000) to the upstream Redox mesa. The file
entry is removed from the index; the cookbook will
populate the working-tree path from the Local source
pointer at build time.
* local/recipes/libs/mesa/recipe.toml is removed. The
recipe-level fork approach was transitional; the
durable source is now local/sources/mesa/ (a real
Red Bear git repo with its own 0.2.3 branch, gitea
remote, and the upstream redox-24.0 branch left
intact for clean rebase-onto-upstream). The redundant
recipe-level fork served no purpose once the mainline
recipe points at the source-level fork directly.
* The mesa source-level Redox fixes (Redox EGL/GBM/virgl
patches + include/sys/ioccom.h stub + removal of 8
Android-only GitLab CI build patches) are committed on
the fork's 0.2.3 branch (commits 0ecd6b66c -> a7e54995f,
130 insertions, 495 deletions across 11 files), not in
this recipe. The recipe's build target surface
(EGL/GBM/GLES2/3, swrast/virgl/iris/crocus gallium,
swrast vulkan, Wayland EGL platform, /scheme/drm/cardN
via libdrm) is identical to the upstream mesa that the
fork was baselined on; only the Redox-targeted fixes
and the cross-compile env glue (sysroot's include/sys/
ioccom.h) diverge.
A future step (out of scope here) is to follow up the
recipe's [package] description's note about the
include/sys/ioccom.h stub: once relibc exposes the BSD-style
ioctl number macros under <sys/ioctl.h> directly, the
fork's include/sys/ioccom.h and the __redox__ guard in
include/drm-uapi/drm.h should both be removed, and the
fork's 0.2.3 branch should pick up the relibc change as a
forward rebase.
The header comment block of recipes/libs/mesa/recipe.toml
matches the same doc-contract used by
recipes/libs/libdrm/recipe.toml and
recipes/gpu/redox-drm/recipe.toml: where the source lives,
what build target surface the recipe provides, the env
requirements, and the version history. Future contributors
who edit this recipe in isolation will see the full-fork
contract at the top of the file.
The parallel-agent update completed the mesa recipe edit:
- Added full doc comment explaining the Red Bear fork model
- Switched to Wayland EGL platform (-Dplatforms=wayland)
- Replaced -lorbital with wayland-{client,server,egl,drm} link flags
- Added [package] section with version + description
- Removed liborbital dep; added libwayland + wayland-protocols
Per AGENTS.md Rule 2 (amended 2026), mesa is a big external
project (multi-million-line codebase) and is maintained as a
Red Bear fork at local/sources/mesa/. The recipe in mainline
is a thin shim that points the cookbook at the fork.
This is a direct edit of the mainline recipe, NOT an overlay
symlink. The cookbook now walks local/recipes/ first (commit
d747b4009), so the mainline recipe is the authoritative source
of truth for the Red Bear fork.
The previous commit 13d0543c2 introduced Phase 2.1 (Mesa EGL
Wayland migration) and was reverted in a88b43b71. This re-applies
the change directly to the mainline recipe.
Per the NO OVERLAY-STYLE PATCHES policy in AGENTS.md:
- Red Bear is a FULL FORK. recipes/ is the source of truth.
- The local/recipes/libs/mesa/ fork approach was overlay-style
and is being removed.
- Direct edits to the mainline recipe are the correct pattern.
Changes to recipes/libs/mesa/recipe.toml:
- Remove 'liborbital' from dependencies
- Add 'libwayland' and 'wayland-protocols' to dependencies
- Replace '-lorbital' link flag with:
-lwayland-client -lwayland-server -lwayland-egl -lwayland-drm
- Change '-Dplatforms=redox' to '-Dplatforms=wayland'
The mesa source's platform_redox.c (which includes <orbital.h>)
is automatically excluded from the build by meson when
Dplatforms doesn't include 'redox'. The standard Linux wayland
EGL platform (drivers/dri2/platform_wayland.c) is enabled.
Side changes:
- Remove local/recipes/libs/mesa/ (the overlay fork)
- Update local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md to reflect
Phase 2.1 status
The recipe still points at the upstream redox mesa git source
(per AGENTS.md: 'Upstream gitlab URLs are temporary ... but
unmodified upstream packages with pinned revisions' is allowed).
To complete the full-fork model, a future step is to fork the
mesa source to local/sources/mesa/ and switch the recipe to use
path = '...'.
Add the QEMU boot test results captured on 2026-06-09 from
test-redbear-full-qemu.sh. Two terminal captures (75 s and a longer
~2-min run) accompany the analysis document. The captures and the
analysis document the boot chain for the redbear-full target on
QEMU virtio-gpu, including the relationship to the redbear-mini
reference log.
The blanket reading from commit 5396e6c3c would have forced every direct
edit to mesa, wayland, qt, KF6, KWin, SDDM, llvm, libdrm, redox-drm,
libepoxy, and similar multi-million-line external projects to live
inside recipes/<pkg>/source/, where a 'make clean' or upstream sync
would silently clobber our work. That is not a full fork, that is a
liability.
Replace the single hard prohibition with a two-rule model:
Rule 1 — In-tree Red Bear components (kernel, relibc, base, installer,
bootloader) and small Red Bear-initiated packages: NO overlay, NO
local fork of mainline. Direct edits in recipes/<pkg>/source/ and
recipes/<pkg>/recipe.toml. No symlinks, no patch files.
Rule 2 — Big external projects (mesa, wayland, qt, KF6, KWin, SDDM,
llvm, libdrm, redox-drm, libepoxy, etc.): Red Bear fork at
local/sources/<component>/ is mandatory. The mainline recipe points
at the fork via 'git = ...' or a 'Local' source type. We own the
source, the recipe just builds it.
Both AGENTS.md (top-level) and local/AGENTS.md updated. Cross-references
to the section name in the anti-pattern tables at the bottom of the
policy remain valid.
Add the Red Bear OS forks of libxkbcommon and xkeyboard-config under
local/recipes/, replacing the previous WIP overlays. The local recipes
build against the XKB data and ship meson flags consistent with the
WIP-recipe baseline. The recipes/wip/ symlinks are kept so existing
config/ includes that reference the WIP path keep working.
Per the NO OVERLAY-STYLE PATCHES policy in AGENTS.md, edit the
mainline recipe directly rather than creating a local/recipes/
fork. This is the canonical Red Bear recipe.
Changes to recipes/libs/mesa/recipe.toml:
- Remove 'liborbital' from dependencies
- Add 'wayland' and 'wayland-protocols' to dependencies
- Replace '-lorbital' link flag with:
-lwayland-client -lwayland-server -lwayland-egl -lwayland-drm
- Change '-Dplatforms=redox' to '-Dplatforms=wayland'
The mesa source's platform_redox.c (which includes <orbital.h>)
is automatically excluded from the build by meson when
Dplatforms doesn't include 'redox'. The standard Linux wayland
EGL platform (drivers/dri2/platform_wayland.c) is enabled.
Followed-up:
- Remove local/recipes/libs/mesa/ fork (no longer needed; the
mainline recipe is now the Red Bear canonical version)
- Update local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md to mark
Phase 2.1 done (was 'skeleton recipe forked')
This is the correct, full-fork way to change a recipe. No overlay
layer, no apply-patches.sh symlink, no local fork. Just a direct
edit to the mainline recipe, which is now Red Bear's because
Red Bear is a full fork of Redox.
Red Bear is a full fork, not an overlay. Document explicitly:
- What the policy is
- What the forbidden anti-patterns are (apply-patches.sh symlinks,
recipes/*/source/ symlinks, mixing local/recipes/ edits with
recipes/ patches, etc.)
- How to fork a Redox package correctly (copy to local/recipes/,
edit there, delete the upstream recipe)
- Why this matters (auditability, build determinism, no stolen
upstream changes, CI reproducibility)
- Historical context of why apply-patches.sh and local/patches/
still exist (transitional remnants, historical-only)
Also update the 'How the build system works' diagram to clarify
that the source/ symlink is for core Red Bear forks (kernel,
base, relibc, bootloader, installer) — NOT for recipes. Recipes
have a different model: either fork entirely in local/recipes/ or
coexist in mainline. No symlinks, no overlay.
Also add a row to the 'Common anti-patterns' table listing the four
specific overlay-style mistakes (apply-patches.sh, recipes/ symlinks,
local/recipes/ + recipes/ mix, etc.) so future agents see them
flagged next to the existing 'don't edit source/' and 'don't add
patches' rules.
The user's 'IF YOU DID PATCHES, REDO ALL' was triggered by my adding
mesa to apply-patches.sh. The 450k line deletion was the cost of
the overlay approach breaking. This commit prevents recurrence.
Pick up the ninja-build fork's 0.2.3 branch HEAD (26f6155), which
adds an extern "C" declaration of getloadavg(double[], int)
guarded by __redox__ to util.cc. Redox's <cstdlib> wrapper pulls
in a stale toolchain stdlib.h that lacks getloadavg, so util.cc
fails to compile on Redox with an implicit-function-declaration
error even though relibc provides the implementation. Other
platforms are untouched.
Pick up the uutils-tar fork's 0.2.3 branch HEAD (bcf6fdb), which
pins rust-version to 1.92.0 to match the Red Bear cross-toolchain
(upstream bumped to 1.94, which is unavailable here) and removes
the uutests dev-dependency, which is a workspace member only
resolvable inside the uutils/coreutils monorepo. With uutests
gone, both root and fuzz Cargo.lock files no longer carry those
workspace-only entries and the lockfiles shrink back to a clean
standalone build.
Pick up the sddm fork's 0.2.3 branch HEAD (a994435), which builds
SDDM as a Wayland-only greeter/daemon for Redox. Highlights:
-DNO_X11 is added globally so X11 code paths are compiled out;
the XAU/XCB/XKB find_package calls are switched to QUIET so
missing X11 dev packages on a Wayland-only build do not fail
configure. XAuth.cpp, XorgDisplayServer.cpp,
XorgUserDisplayServer, and XcbKeyboardBackend sources are
dropped from the daemon, greeter, and helper link lists, the
sddm-helper-start-x11user target is removed, the .ts -> .qm
translation step is dropped (LinguistTools no longer required),
and the test/ subdir is no longer built. UserSession replaces
the Xauthority cookie write with a no-op (Wayland-only) and
passes an explicit third argument to TIOCSCTTY. Note: the
preprocessor guards in Display.cpp / Greeter.cpp / Seat.cpp /
KeyboardModel.cpp are emitted as deeply-nested duplicate
#ifndef NO_X11 blocks; the guards are semantically equivalent
to a single pair per region but should be collapsed in a
follow-up cleanup.
Pick up the installer fork's 0.2.3 branch HEAD (b85f274), which
comments out the optional ext4-blockdev path dependency. The crate
is resolved via a relative path that traverses the local/recipes
symlink chain, which breaks path resolution on Red Bear. The
installer already talks to ext4 through the rsext4 crate, so the
optional path dep is unused. Cargo.lock is rolled forward so the
transitive windows-sys entries match the rest of the resolver
graph for this snapshot.
Pick up the kernel fork's 0.2.3 branch HEAD (dd72d764), which calls
handles() in smbios_scheme_id() so the SMBIOS scheme id accessor
initializes the scheme namespace handles on demand. This matches
the pattern used by other scheme id accessors and prevents stale
or unset ids from being observed by bootstrap paths that pre-open
the SMBIOS scheme root for userspace.
Pick up the v6.0 stub-fix work that landed on the 0.2.3 branch of
local/sources/base: full input stack (inputd, ps2d, usbhidd,
i2c-hidd, intel-thc-hidd) on the single-producer evdev pipe, full
USB controller daemons (xhcid MSI-X, usbscsid UAS, virtio-netd MAC),
real PHY and link handling for virtio-netd and rtl8168d, MSI-X
plumbing on nvmed and ixgbed, acpid EC/GPE/AML/Notify implementation
plus TOML quirks loaders, pcid multi-bus MCFG enumeration, and
vesad display hand-off to redox-drm/card0 per the NO VESA policy.
The main-repo submodule pointer advances to 0df7977d.
v6.0 collapses the v5.0 dual-path input design (which was never
built) into a single-producer evdev pipe:
drivers → /scheme/input/evdev (inputd ring buffer)
→ evdevd consumer
→ /dev/input/eventN
→ libinput
Phase 1.1b (inputd scheme daemon) is now real. All five input
drivers + virtio-inputd already use EvdevProducerHandle. The
init system wires evdevd in. Plan status for Phase 1: 8 of 9
steps code-complete; only Step 1.9 (udev-shim eventN mapping
verification) and runtime gate (QEMU boot test) remain.
Also records the small fixes this session: Gap 3 (renderD128
openat path), Gap 5 (host->guest resize events, pre-existing),
Gap 8 (atomic_check connector validation), Phase 3.5 (page
flip keeps DRM fd open), the redox-drm dangling symlink, and
the build-redbear.sh aggressive cache-nuke fix.
Point the redox-drm recipe at the new durable fork at
local/sources/redox-drm/. The source tree is now an absolute
symlink from local/recipes/gpu/redox-drm/source to the fork,
matching the pipewire / wireplumber fork model. The absolute
target survives moving the project root.
Drop the dead recipe-local patches (P5, P8, P10 — P9 was dropped
in the prior redox-drm recipe commit). All four were already
applied to the in-tree source before the fork move, so the patch
artefacts were inert. The fork is the durable source of truth;
future Red Bear changes go as git commits there.
Bump version 0.1.0 -> 0.2.3 and add the v6.0 2026 Red Bear fork
marker to the description. The recipe documentation now describes
the supported GPU targets (virtio-gpu, Intel Meteor Lake / Arrow
Lake / Lunar Lake, AMD display glue) and the hardware validation
status of each.
DrmOutput's _file field was stored but unused; flip() reopened
/scheme/drm/card0 on every page flip. Rename to drm_file, un-
underscore, and use &self.drm_file in flip() to avoid the per-flip
open+close round trip.
This is the implementation of v6.0 plan Phase 3.5 'Fix page
flip to keep DRM fd open'.
Migrate the libdrm recipe from the tar+patches shape (redox.patch + four
P1-P4 patches from local/patches/libdrm/) to a Local source pointing at
the new Red Bear fork at local/sources/libdrm/. The fork is based on
upstream libdrm 2.4.125 (https://gitlab.freedesktop.org/mesa/libdrm) and
already has the full redox.patch series applied in-tree.
The P1-P4 patch files referenced from the previous recipe
(P1-drm-ioctl-bridge, P2-drm-get-pci-info, P3-drm-get-version-driver-name,
P4-drmGetDeviceFromDevId-redox) were already merged into redox.patch and
no longer existed in local/patches/. Consolidating everything into a
single in-tree fork is the durable form per the FULL FORK PRINCIPLE.
The fork's redox divergence covers:
- include/drm/drm.h: include <sys/ioctl.h> on __redox__ instead of
<sys/ioccom.h>
- xf86drm.h: Redox-aware ioctl type definitions
- xf86drm.c: major()/minor()/makedev() macros from musl for __redox__,
open_memstream fallback path (returns NULL with diagnostic on
__redox__), redox_drm_write_all helper, and the drmOpen /
drmGetDeviceFromDevId / etc. rewrites that dispatch through scheme:
paths on Redox
- xf86drmMode.c: Redox shim for drmModeGetResources /
drmModeGetConnector / etc. and the mode probing path
- xf86drm_redox.h: new header providing the Redox-side helper API
(open scheme:, drm fd adaptation, dev_t packing) used by xf86drm.c
Recipe changes:
- source: tar + patches list -> Local { path = '../../../../local/sources/libdrm' }
(the recipe lives under both recipes/wip/x11/libdrm and
recipes/libs/libdrm symlinks into local/recipes/libs/libdrm; the
four-.. path resolves correctly from both locations to
local/sources/libdrm).
- version: bumped to 0.2.3 (Red Bear fork tracking upstream 2.4.125).
- description: marked v6.0 2026 Red Bear fork.
- removed: redox.patch and source/ / source.tar / target/ artifacts
under the recipe directory; they are no longer referenced and the
fork is the single source of truth.
Verified: ./target/release/repo cook libdrm (with
REDBEAR_ALLOW_PROTECTED_FETCH=1) builds successfully and publishes
libdrm 0.2.3 to repo/x86_64-unknown-redox/ with the fork's commit
identifier pinned.
The amdgpu recipe's idr_* / ida_* header conflict with linux-kpi is
now resolved (see the preceding commit). Re-enable amdgpu in
redbear-full.toml by changing amdgpu = "ignore" to amdgpu = {} and
add a [package] section to the amdgpu recipe marking the 0.2.3
release and describing the bounded display-glue compile surface
(DCN20 / DCN30 / DCN31 backend files plus the Rust-side init /
connector detection / modeset glue).
The linux-kpi idr.h header and the amdgpu recipe's redox_glue.h
both define struct idr and the idr_init/alloc/remove/find/destroy
inline functions, but with different members and different argument
signatures. When the amdgpu build includes both headers in the same
translation unit (via -include linux/amdgpu_stubs.h and via
redox_glue.h), the compiler reports a redefinition of struct idr
and conflicting types for the idr_* inlines, blocking the build.
Resolve the conflict by gating the linux-kpi idr declarations on a
new REDBEAR_AMDGPU_BUILD preprocessor flag. The amdgpu recipe's
CFLAGS now defines REDBEAR_AMDGPU_BUILD, so the linux-kpi
declarations are suppressed and redox_glue.h's authoritative copies
take over. Every other consumer of linux-kpi (the redox-drm scheme
daemon, the Wi-Fi drivers) continues to see the generic stubs.
The IDA macros and struct ida in linux-kpi are kept outside the
gate because they are not part of the amdgpu surface and must
remain available to other drivers. A forward declaration of
struct idr is added at the top of the header so the
struct ida { struct idr *idr; } member compiles cleanly when the
IDR definitions are suppressed. The IDA macros are updated to
no-ops against a pointer-typed idr slot; the amdgpu build does
not exercise them and other consumers continue to treat them as
stubs.
Previously, when relibc/kernel/base/bootloader/installer had commits
newer than their pkgar, the script set NO_CACHE=1, which ran
'make repo_clean' and deleted the entire repo/ directory. This
forced rebuilding the full mesa/llvm21/qt6/kwin stack on every
base source change — adding 30+ minutes of wasted work to every
mini build.
Now we only delete the specific stale package's pkgar and target
dir. The cookbook rebuilds that package; downstream packages pick
up the new relibc/kernel/base via their own dependency tracking
without invalidating the rest of the repo. This is the primary
fix for the 'forever build' complaint: base source changes no
longer trigger a full mesa/llvm rebuild.
Gap 5: virtio IRQ handler at virtio/mod.rs:366-403 already reads
VIRTIO_GPU_EVENT_DISPLAY and calls refresh_connectors. Scheme layer
queues the hotplug event so userspace libdrm clients get notified.
Gap 8: atomic_check now validates connectors via the
available_connectors parameter — fixed in commit 32993a9ee.
Point the redox-drm recipe at the new durable fork at
local/sources/redox-drm/. The source tree is now a symlink from
local/recipes/gpu/redox-drm/source to the fork, matching the
redox-driver-sys / pipewire / wireplumber fork model.
Drop the four dead recipe-local patches (P5, P8, P9, P10). All four
were already applied to the in-tree source before the fork move, so
the patch artefacts were inert. The fork is the durable source of
truth; future Red Bear changes go as git commits there.
Bump version 0.1.0 -> 0.2.3 and add the v6.0 2026 Red Bear fork
marker to the description. The recipe documentation now describes
the supported GPU targets (virtio-gpu, Intel Meteor Lake / Arrow
Lake / Lunar Lake, AMD display glue) and the hardware validation
status of each.
The mainline recipes/libs/mesa/recipe.toml links against -lorbital
and uses -Dplatforms=redox — a deprecated Orbital-only path. For
the v6.0 console-to-desktop plan, Mesa must be switched to the
Wayland EGL platform (-Dplatforms=wayland + -lwayland-client) so
Qt6 eglfs can open a window under a Wayland compositor.
Create a Red Bear fork of the mainline recipe under
local/recipes/libs/mesa/ to receive the EGL Wayland changes
without modifying mainline directly. This recipe is currently
identical to upstream; subsequent commits will:
- Remove -lorbital link flag and liborbital dep
- Add wayland + libwayland-client deps
- Switch -Dplatforms=redox to -Dplatforms=wayland
- Verify EGL_KHR_platform_wayland loads in QEMU
Phase 2.1 of the v6.0 plan: 1 week effort.
atomic_check previously ignored the _available_connectors parameter
(prevented by underscore prefix). The CRTC state's connectors: Vec<u32>
field declared which connectors to bind, but atomic_check never
verified they actually existed or were connected. This allowed
client commits to reference phantom or disconnected connectors
and silently produce invalid state.
Fix: use the available_connectors slice to validate that each
referenced connector ID exists in hardware and has connection
status Connected. Return CrtcNotFound or ConnectorDisconnected
respectively so the kernel rejects invalid commits with a clear
error rather than producing a malformed display state.
This unblocks libdrm drmModeAtomicCommit callers that rely on
DRM_MODE_ATOMIC_ALLOW_MODESET returning success only for valid
connector configurations.
- STUBS-AUDIT-AND-REWRITE-PLAN.md: master plan, 20 drivers audited
- USB-STUBS-AUDIT.md: USB stack focus, xhcid/usbhubd/usbctl/usbhidd/usbscsid/ucsid
- HID-STUBS-AUDIT.md: HID focus, usbhidd/i2c-hidd/intel-thc-hidd/ps2d/inputd/evdevd
- LOWLEVEL-STUBS-AUDIT.md: ACPI/PCI/IRQ/IOMMU/boot/init, 50+ row coverage
- BOOT-AND-HW-ENABLEMENT-ASSESSMENT.md: kernel to display chain, NO VESA policy
- DESKTOP-SERVICES-ASSESSMENT.md: D-Bus, session, audio, network
- CONFIG-AND-INIT-ASSESSMENT.md: configs, init.d, recipes, layering
- GPU-MESA-KDE-CHAIN-ASSESSMENT.md: Mesa to Plasma build chain
These documents track the v6.0 stub-fix campaign and the comprehensive
Phase 1-5 implementation work. All cited paths and line numbers are
real. Documents are durable in local/docs/ which survives make distclean.
Adds the local recipe.toml files for pipewire and wireplumber
under local/recipes/libs/. Both recipes are now properly tracked
as Red Bear OS custom recipes that follow the local-over-WIP
convention.
The recipe.toml files document:
* the upstream version (0.3.85 for pipewire, 0.4.14 for
wireplumber) and the v6.0 2026 Red Bear description
* the build dependencies (glib, dbus, expat, pipewire for
wireplumber)
* the build command (cookbook_meson with Redox-specific
meson flags disabling ALSA, BlueZ, V4L2, JACK, systemd,
elogind, etc.)
* the redox_compat/ shim headers that stage byteswap.h and
sys/mman.h into the per-recipe sysroot so the meson
subprojects (spa/plugins/*) see them
The 'source' symlinks (absolute paths) and the
recipes/wip/services/{pipewire,wireplumber} symlinks were
already wired up in the previous redbear-full commit.
vasilito
Red Bear Maintainer