A focused batch of small, real improvements from prior sessions. Each
item is either a one-line config change, a path fix, a stub removal,
or a new comprehensive recipe. No stubs added, no workarounds, no
fake fixes.
* local/recipes/libs/libdrm/recipe.toml: enable Intel GPU support
(-Dintel=enabled). Mesa's iris/crocus Gallium drivers need the
Intel backend compiled in. The AMD backend is already enabled.
* local/recipes/libs/libxkbcommon/recipe.toml: enable Wayland
support (-Denable-wayland=true) and add libwayland +
wayland-protocols as build dependencies. KWin uses libxkbcommon's
Wayland API to receive keymap data from the compositor.
Previously the recipe had Wayland disabled, blocking KWin.
* local/recipes/kde/kf6-kded6/recipe.toml: replace a wrapper-script
hack (which renamed kded6 to kded6.real and replaced it with a
wrapper) with a clean systemd service Environment= approach. The
wrapper script is removed (kf6-kded6/source/kded6-wrapper.sh
deleted). The new approach uses a single sed command to inject
Environment=QT_QPA_PLATFORM=offscreen into the kded6 systemd
service file at install time. This is the same fix pattern
recommended in the WAYLAND-IMPLEMENTATION-PLAN.md.
* local/patches/libdrm/02-ioctl-response-sizes.patch: fix the patch
header paths. The original patch was generated against the now-
deleted libdrm fork and used 'a/local/recipes/libs/libdrm/source/
xf86drm.c' style paths. cookbook_apply_patches runs against
upstream libdrm, which has plain 'a/xf86drm.c' paths. Without
this fix, git apply would warn about path mismatch. The hunk
contents are unchanged.
* recipes/libs/libpciaccess/recipe.toml: new comprehensive recipe
for libpciaccess 0.19. Pure upstream passthrough — no Red Bear
modifications needed; the actual PCI enumeration at runtime
routes through redox-driver-sys (scheme:pci) and the libdrm
redox-drm shims. Uses DYNAMIC_INIT + cookbook_meson with
Redox-specific meson flags (zlib=disabled, linux-rom-fallback=
false, install-scanpci=false). Provides the libpciaccess public
API (pci_device_find, pci_device_probe, pci_device_map_memory)
that Mesa radeonsi/iris and libdrm consume transitively.
* recipes/libs/pciaccess-stub: removed. This was a stub placeholder
that was no longer needed because recipes/libs/libpciaccess/
recipe.toml is the real implementation. Per the project's
ZERO TOLERANCE FOR STUBS policy (local/AGENTS.md), stubs must
be removed when real implementations exist.
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/. 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.
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 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.
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.
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.
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.
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.
The redbear-full desktop target now pulls in pipewire and wireplumber
as the audio backend for KDE Plasma (Phonon, KMix, the Plasma audio
widget). This wires up the packages built by the new
local/recipes/libs/pipewire and local/recipes/libs/wireplumber
recipes on top of the existing audiod scheme daemon in the base
package.
Changes:
* config/redbear-full.toml
- new [packages] entries for pipewire and wireplumber
- two new [[files]] init services: 15_pipewire.service and
16_wireplumber.service (both oneshot_async, depend on
12_dbus.service)
* local/recipes/system/redbear-dbus-services/files/
- new org.freedesktop.PipeWire.service (system bus, runs
/usr/bin/pipewire) and org.pulseaudio.Server.service
(system bus, runs /usr/bin/pipewire-pulse)
- new org.freedesktop.impl.pulseaudio.service (session bus,
runs /usr/bin/pipewire-pulse) for KDE Phonon / KMix
- matching .conf policy files for org.freedesktop.PipeWire
and org.pulseaudio.Server that allow the expected
Introspectable / Properties / *Manager / *Node / *Link /
*Client / *Device / *Meter / *Core / *Port send and
receive patterns
* config/protected-recipes.toml
- new [libs] entries for pipewire and wireplumber, so the
cookbook never silently re-fetches them; sources are
directly editable in local/sources/
* recipes/wip/services/{pipewire,wireplumber}
- replaced the tracked WIP directories with symlinks to
local/recipes/libs/{pipewire,wireplumber}, per the
local-over-WIP convention enforced by
local/scripts/build-redbear.sh
Known build state (documented in the upstream README-redbear.md
files in each source fork):
* pipewire build reaches ~24/603 C files compiled before
hitting relibc gaps (sys/prctl.h, sys/mount.h, and a few
Linux-specific ioctls). The recipe, source fork, and
Redox-compat shims are in place; the remaining work is
upstream relibc headers, not PipeWire porting decisions.
* wireplumber recipe is in place but the build has not been
attempted yet — wireplumber depends on the pipewire build
completing first.
The audiod integration (the scheme backend that pipewire would
talk to) is not implemented in this commit. That is the next
gating work item and is tracked in
local/sources/pipewire/README-redbear.md.
The StubBackend returned hardcoded SSIDs ("demo-ssid", "demo-open")
and synthesised connection outcomes without ever touching the iwlwifi
driver or netstack. This was a stub that hid the real work needed to
control Intel Wi-Fi devices on Redox.
This commit removes the StubBackend entirely and renames the existing
real PCI/iwlwifi-aware backend from IntelBackend to IwlwifiBackend.
The renamed backend is the default; when no Intel Wi-Fi device is
detected, the NoDeviceBackend is selected (which is the legitimate
"no hardware present" path, not a stub).
Backend mode selection (in main.rs):
- REDBEAR_WIFICTL_BACKEND=iwlwifi|no-device: explicit override
- redox runtime + iwlwifi driver + Intel interface detected: Iwlwifi
- everything else: NoDevice (no silent stub fallback)
The IwlwifiBackend talks to /usr/lib/drivers/redbear-iwlwifi via the
existing Command-based action plumbing (--prepare, --init-transport,
--activate-nic, --scan, --connect, --disconnect, --retry, etc.), which
in turn maps BAR0 MMIO, loads ucode/pnvm, and drives the iwlwifi
device. The previously-stripped stub output paths (firmware=stub,
transport=stub, transport_init=stub, connect=stub, disconnect=stub)
are gone; every status field is now sourced from the real driver or
returned as an honest error from NoDeviceBackend.
Version bumped 0.1.0 -> 0.2.3.
Tests:
- 17 unit tests pass on host target (replaced 4 stub_* tests with
no_device_* and iwlwifi_transport_probe_honors_driver_action).
- 2 CLI integration tests pass (cli_transport.rs unchanged).
- cargo test 19/19 green.
- ./target/release/repo cook redbear-wifictl: successful; produces
repo/x86_64-unknown-redox/redbear-wifictl.pkgar and .toml with
version 0.2.3.
The 4 service files (org.kde.ksmserver, org.kde.JobViewServer,
org.kde.ActivityManager, org.freedesktop.StatusNotifierWatcher)
existed in local/recipes/system/redbear-dbus-services/files/ but were
never mirrored into source/ where the build actually reads in offline
mode. This meant only 3 of the 7 session-service activation files
reached the staged package.
Also fix org.kde.kglobalaccel.service to point at the real install
location: kglobalacceld is installed to /usr/libexec/ (KDE_INSTALL_LIBEXECDIR),
not /usr/bin/.
Sync files/session-services/org.kde.kded6.service to the offscreen-QPA
wrapper that the build was already shipping from source/.
Build now stages all 7 session-service files plus 4 system-services
and 4 policy files (15 dbus config files total).
Cross-cutting changes tied to the libepoxy/libxcvt/libdisplay-info/
lcms2/libudev stub-removal work:
- config/protected-recipes.toml [graphics]: add libepoxy, libxcvt,
libdisplay-info, lcms2 (real Red Bear recipes under local/recipes)
- config/protected-recipes.toml [libs]: drop the 5 *-stub entries,
add 'libudev' (renamed from libudev-stub)
- local/recipes/AGENTS.md catalog: drop the 5 *-stub rows, update
the 5 real lib rows to reflect the v6.0 2026 fork
- local/scripts/apply-patches.sh: drop the 5 *-stub symlink
creation entries; add libudev symlink entry
(The redbear-full.toml package list was already updated to enable
libdisplay-info, libxcvt, lcms2 and add libudev, as part of the
pam-redbear commit that included both changes.)
The libudev-stub was a real 1314-line libudev implementation backed
by the /scheme/udev producer (driven by udev-shim) — not a stub in
the zero-tolerance sense. It was named -stub to make the bounded
hotplug-event-delivery scope obvious.
Rename the recipe to libudev to match the upstream systemd surface it
implements (the recipe still backs through scheme:udev, but the public
name now matches the library's actual role for KWin tablet / input
discovery and libinput's udev device enumeration). Update:
- local/recipes/libs/libudev/recipe.toml: bump to 0.2.3, drop the
#TODO: stub-style header, add v6.0 2026 description
- local/recipes/libs/libinput/recipe.toml: dependency now 'libudev'
- local/recipes/kde/kwin/recipe.toml: dependency now 'libudev'
- config/protected-recipes.toml [libs]: now lists 'libudev'
The libudev.pc, UDev::UDev CMake target, and libudev.so surface are
unchanged — they are the real libudev C ABI as required by KWin and
libinput, with /scheme/udev/devices as the data source.
vasilito
Red Bear Maintainer