- .config: drop REDBEAR_RELEASE?=0.1.0 (was forcing offline)
- local/patches/gettext/01-external-gettext.patch (new): fix
AM_GNU_GETTEXT arg for autopoint 0.23.1+. autopoint now requires
'external' as first arg; gettext 0.22.5 used 'use-libtool'/'here'.
Patched 3 files: gettext-tools, gettext-runtime, gettext-runtime/intl.
- recipes/tools/gettext/01-external-gettext.patch (symlink): durable
source for the patch.
- recipes/tools/gettext/recipe.toml: fix source script for
gettext 0.22.5:
- Use /usr/share/aclocal (not /share/aclocal) — host sysroot is /.
- Create missing m4/ subdirs in every configure.ac-bearing dir
before autoreconf runs (newer aclocal needs them).
- src/cook/gnu-config/{config.sub,config.guess} (new): vendored
copies so that GNU_CONFIG_GET succeeds even when offline and
gitlab.redox-os.org is unreachable.
After several rounds of patch alignment issues with the overlay-patches
approach, switching to the local Red Bear base fork. The local fork is
the durable source of truth (already at d0ca0d5f with 14 unused-var
fixes). Future work will import upstream redox-os/base commits into the
fork and re-apply any necessary Red Bear deltas as patches on top.
This matches the existing pattern: kernel and relibc are also built
from local forks (local/sources/kernel, local/sources/relibc).
The old overlay patches in local/patches/base/ are preserved for
reference and will be re-applied to the fork during the next
synchronization pass.
The build system uses `patch --fuzz=0` to apply patches atomically.
Previous patches had extra context that included line counts in the
hunk header that didn't match the current source state due to upstream
drift. The result was atomic rollbacks.
Reduce the hunk context to 1-2 lines around the actual change. This
keeps the patches minimal and ensures they apply cleanly under fuzz=0.
- P0-redox-scheme-bump-0.11.1.patch: hunk now starts at line 96
(where redox-scheme actually is in the current source)
- P0-relibc-syscall-0.8.1.patch: hunk now starts at line 71
(where redox_syscall actually is in the current relibc source)
The P0-redox-ioctl-syscall-0.8.1.patch only bumped the redox-ioctl
sub-crate's pin. The relibc main workspace still pinned
redox_syscall = 0.7.4, causing relibc itself to fail to compile
with redox-rt errors when the path-override in base pulled in
the now-0.8.1 redox-ioctl.
Bump the relibc workspace's redox_syscall to 0.8.1 to match.
The previous P0-redox-ioctl-syscall-0.8.1.patch on relibc was useless
because base uses `redox-ioctl = { git = ... relibc.git }` which
bypasses the relibc recipe's local source.
Add a [patch] override in base/Cargo.toml to use the local relibc
source's redox-ioctl instead, which has the syscall 0.8.1 pin.
Base build was failing with:
error[E0277]: `?` couldn't convert the error to `syscall::error::Error`
--> drivers/graphics/driver-graphics/src/lib.rs
because relibc's redox-ioctl sub-crate pins `redox_syscall = "0.7"`
which uses one syscall::Error type, but the rest of the build
(redox-scheme 0.11.1, base workspace redox_syscall 0.8.1) uses
another. Two versions of the same type can't unify across crate
boundaries.
Bump the pin in relibc/redox-ioctl/Cargo.toml to 0.8.1 to match.
The previous daemon patches (P0-daemon-init-notify-graceful, P0-daemon-fix-init-notify-unwrap,
P0-daemon-silence-init-notify) were conflicting with each other and with
the upstream daemon code. The result was either:
1. get_fd returns RawFd (-1) but Daemon.write_pipe is Option<PipeWriter>
(from P0-daemon-init-notify-graceful) — broken
2. get_fd returns Option<RawFd> but Daemon::new uses io::PipeWriter::from_raw_fd
(no .map()) — broken
This single comprehensive patch applies all needed changes atomically:
- get_fd returns Option<RawFd> with full error handling
- Daemon.write_pipe: Option<PipeWriter>
- Daemon::new uses .map(|fd| unsafe { from_raw_fd(fd) })
- Daemon::ready handles Option
- SchemeDaemon.write_pipe: Option<PipeWriter>
- SchemeDaemon::new uses same closure pattern
- ready_with_fd handles Option
Replaces: P0-daemon-init-notify-graceful, P0-daemon-fix-init-notify-unwrap,
P0-daemon-silence-init-notify
The previous commit (d86bcb24a) added this patch which assumed a
different state of daemon/src/lib.rs than what P0-daemon-fix-init-notify-unwrap.patch
produces. The original P0-daemon-fix-init-notify-unwrap.patch ALREADY
fixes the same lines using a proper closure:
unsafe { get_fd("INIT_NOTIFY").map(|fd| io::PipeWriter::from_raw_fd(fd)) }
vs my (broken) version:
unsafe { get_fd("INIT_NOTIFY").map(io::PipeWriter::from_raw_fd) }
The original uses a closure which makes the unsafe call syntactically
valid. My version passes the function directly which Rust 2024 rejects
because from_raw_fd is unsafe fn.
Removing the redundant patch and relying on P0-daemon-fix-init-notify-unwrap
which is already in the recipe.
P2-xhcid-remaining.patch was renaming allocate_first_msi_interrupt_on_bsp
to try_allocate_first_msi_interrupt_on_bsp and adding Result return types.
But the upstream pcid crate has the un-prefixed allocate_* functions, not
the try_ versions. This patch was based on a future pcid API that does
not exist in the current source.
Without the patch, the upstream xhcid main.rs uses the correct
allocate_* function names that match the upstream pcid crate API.
Same issue as P2-ihdad-device-refactor (already removed in df8027fb2f).
Adds imports for parser, digital, dispatch, FixupEngine, InputStream
modules that don't exist in the source tree.
P2-ihdad-device-refactor.patch was adding imports for modules that
don't exist in the source tree (parser, digital, dispatch, FixupEngine,
InputStream). The build was failing with:
error[E0432]: unresolved import `super::parser`
error[E0432]: unresolved import `super::digital`
error[E0432]: unresolved import `super::dispatch`
error[E0432]: unresolved import `super::FixupEngine`
error[E0432]: unresolved import `super::InputStream`
This patch was speculative work referencing modules that were never
committed to the source. Without those modules, the patch breaks the
build. The Red Bear base fork (local/sources/base) has the same
device.rs as upstream (no patch needed), so removing this patch is
safe.
The other P2-ihdad-* patches (P2-ihdad-graceful-init, P2-ihdad-hda-stream)
remain as they don't add missing imports.
Earlier we over-included workspace patches. After closer inspection:
- Upstream Cargo.toml ALREADY has `exclude = ["bootstrap"]` at the end
of the workspace members list (line 72). No need to add another.
- Upstream bootstrap/Cargo.toml ALREADY has `[workspace]` declaration.
No need to add another.
The only real gap was the missing driver members (i2c, gpio, intel-thc-hidd,
acpi-resource, amlserde, thermald, ucsid). The P0-add-missing-driver-members.patch
fixes that alone.
Removed the redundant P0-bootstrap-workspace-{fix,exclude,standalone} patches.
The base build was failing with:
error: package ID specification `amd-mp2-i2cd` did not match any packages
error: package ID specification `dw-acpi-i2cd` did not match any packages
... (15+ missing drivers)
because the upstream base Cargo.toml workspace members list is missing
drivers that the recipe's BINS list tries to build (e1000d-rtl8139d
succeeded but amd-mp2-i2cd, i2c-*, gpio-*, intel-thc-hidd, ucsid, etc.
failed). Earlier Red Bear session must have had a more comprehensive
patch.
The new P0-bootstrap-workspace-exclude.patch:
- Adds `exclude = ["bootstrap"]` to the parent workspace
- Adds missing drivers to members: i2c/*, gpio/*, input/i2c-hidd,
input/intel-thc-hidd, acpi-resource, amlserde, thermald, usb/ucsid
The new P0-bootstrap-workspace-standalone.patch:
- Adds `[workspace]` to bootstrap/Cargo.toml so it can be standalone
(matches the parent workspace's exclude)
The base build was failing with:
error[E0277]: expected a `FnOnce(i32)` closure
--> daemon/src/lib.rs:67:61
error[E0308]: mismatched types
--> daemon/src/lib.rs:119:63
arguments to this function are incorrect
because P0-daemon-fix-init-notify-unwrap.patch changed `unsafe fn
get_fd(var: &str)` to return `Option<RawFd>` instead of `RawFd`,
but the upstream daemon code in SchemeDaemon::new still treated the
return value as `RawFd` (not `Option<RawFd>`).
This patch updates the SchemeDaemon code to handle the Option<RawFd>:
- Change `write_pipe` field to `Option<PipeWriter>`
- Use `.map(io::PipeWriter::from_raw_fd)` in new()
- Handle None case in ready_with_fd (return Ok early)
This matches the Daemon struct above and the Red Bear base fork at
local/sources/base.
Base build was failing with:
error[E0277]: the trait `From<libredox::error::Error>` is not implemented for `syscall::Error`
error: could not compile `scheme-utils` (lib) due to 13 previous errors
error: could not compile `daemon` (lib) due to 6 previous errors
because the workspace pinned redox-scheme 0.11.0 (libredox 0.1.12) and
redox_syscall 0.7.4. The newer libredox 0.1.16/0.1.17 has a different
Error API. Bump both to versions compatible with libredox 0.1.17:
redox-scheme 0.11.0 -> 0.11.1 (requires libredox 0.1.17)
redox_syscall 0.7.4 -> 0.8.1 (requires libredox 0.1.17)
This matches the Red Bear base fork at local/sources/base.
The base build was failing with:
error: multiple workspace roots found in the same workspace:
bootstrap
source
because P0-bootstrap-workspace-fix.patch was adding a [workspace] block
to bootstrap/Cargo.toml, while P0-workspace-add-bootstrap.patch was
adding 'bootstrap' as a member of the parent source/Cargo.toml
workspace. Cargo forbids a member from also being a workspace root.
The correct fix is P0-workspace-add-bootstrap.patch alone (which makes
bootstrap a member of the parent workspace). The P0-bootstrap-workspace-fix
patch was an inverted/historical artifact and has been removed.
This restores the build to working state for the redbear-mini target.
bison build was failing with:
undefined reference to `__fseterr\'
in function `rpl_fprintf'
in function `rpl_vfprintf'
because the relibc recipe was missing P3-stdio-fseterr.patch, which
implements `__freadahead` and `__fseterr` in src/header/stdio/ext.rs
and adds the stdio_ext.h prototypes needed by gnulib (which m4, bison,
and flex all rely on).
The patch file was already present in local/patches/relibc/ with a
symlink at recipes/core/relibc/P3-stdio-fseterr.patch, but the recipe
never listed it. Without these symbols, any gnulib-using package that
links rpl_fprintf/rpl_vfprintf fails to link.
This is the same fix that was already applied to local/sources/relibc
fork at commit f45729d4 but not mirrored into the recipe patch chain
for upstream builds.
The preflight validate-source-trees.py was blocking development builds
with 'To restore: ./local/scripts/restore-sources.sh --release=<release>'
because the source/ trees for 17 core recipes (base, kernel, etc.) are
gitignored and only auto-fetched on demand by `repo cook`.
This worked correctly for release mode (REDBEAR_RELEASE=...) where
sources are immutable and pre-extracted, but blocked every dev build.
Now:
- RELEASE mode: full strict validation, sources must be pre-extracted
- Development mode: validation skipped, repo cook auto-fetches sources
This is the documented Red Bear OS policy (see AGENTS.md:
Build flow: 'make all CONFIG_NAME=redbear-full' calls repo cook which
fetches sources from git/tar URLs)
The build was failing at verify-overlay-integrity.sh with:
ERROR: dangling patch symlink: recipes/core/base/redox.patch -> .../local/patches/base/redox.patch
ERROR: missing critical patch: local/patches/base/redox.patch
The mega-patch (100MB+) was gitignored and got lost, while the
dangling symlink at recipes/core/base/ is leftover infrastructure.
The base recipe (recipes/core/base/recipe.toml) does NOT reference
redox.patch - it uses individual P*.patch files (P0-P9). The mega-patch
was abandoned 2026-04-30 in favor of ~100 individual patches.
Changes:
- Remove dangling recipes/core/base/redox.patch symlink
- Update verify-overlay-integrity.sh to drop obsolete references
(redox.patch in base) and consolidate redbear-live-full into the
current critical configs list
- Remove 'local/patches/base/redox.patch' from .gitignore (it is gone
for good; never resurrect the mega-patch approach)
- Document NEVER-GITIGNORE-CRITICAL-INFRASTRUCTURE policy in AGENTS.md
(replaces the obsolete 'Large Patch Files' section that described
the now-removed chunks/reassembly approach)
- Add Linux reference tree migration note (2.1GB tree should eventually
be tracked via sparse submodule or gitea mirror)
The previous patch left a broken `__redox__ && HAVE_GETLOCALENAME_L`
branch that referenced the non-existent relibc function `getlocalename_l`,
causing the m4 build to fail with:
error: #error "Please port gnulib getlocalename_l-unsafe.c to your platform!"
Redox's relibc has no `getlocalename_l` symbol. The patch now uses
`__redox__ && !HAVE_GETLOCALENAME_L` and returns "C" (matching
the existing `__ANDROID__` branch behaviour for unknown locales),
so the build no longer hits the gnulib #error.
- Switch tar URL from invent.kde.org git tag v6.10.0 to
download.kde.org 6.27.0 release tarball (matching the other KF6
packages). Add blake3 verified against source.tar.
- Add cookbook_apply_patches call so the durable patches in
local/patches/kf6-kio/ are applied at cook time.
- Add local/patches/kf6-kio/01-no-testlib.patch:
- Drop Qt6 Test from top-level find_package, make conditional on
BUILD_TESTING (relibc qtbase disables Test)
- Skip LibMount find_package on cross-compile (CMAKE_CROSSCOMPILING)
to avoid LibMount errors since the toolchain sets CMAKE_SYSTEM_NAME=Linux
- Combined short flags expand: -Sdy → install --noconfirm
- -Gp prints raw PKGBUILD from AUR
- -Scc cleans all caches including ~/.cub/tmp/
- --noconfirm skips interactive prompts
- Deduplicated flag expansion, added to global flag list
- extract_bash_function() extracts bash function bodies by brace-matching
- Custom template now populates build_script from build() body
- Custom template now populates install_script from package() body
- Fixes 'custom builds require prepare/build/install instructions' error
- search now queries AUR directly on Linux (skips pkgutils repo)
- install -S offers AUR fetch + recipe conversion on Linux
- update-all, remove, query-* show helpful error on Linux
- host_only_notice() helper for consistent messaging
vasilito