local/sources/libc is libc 0.2.189 with src/unix/redox/mod.rs extended to
expose the waitid surface relibc already implements:
- idtype_t (= c_int, as relibc defines it)
- P_ALL / P_PID / P_PGID
- CLD_EXITED / KILLED / DUMPED / TRAPPED / STOPPED / CONTINUED
- extern fn waitid(idtype_t, id_t, *mut siginfo_t, c_int) -> c_int
All of it is real in relibc -- src/header/sys_wait/mod.rs defines the
types and constants, and `nm libc.a` shows `T waitid` -- but the libc
crate's Redox bindings never exposed any of it, and still do not as of
0.2.189. Any crate calling waitid therefore cannot build for
x86_64-unknown-redox:
error[E0531]: cannot find unit struct, unit variant or constant
`CLD_EXITED` in crate `libc`
which breaks nix, and through it ctrlc and rustc's bootstrap tooling --
the last thing blocking rust-native.
Values and types come from relibc, not from Linux. Every non-Redox target
is byte-for-byte upstream 0.2.189, so host builds are unaffected. Wired
into the rust workspace via [patch.crates-io]; the fork type-checks for
x86_64-unknown-redox.
Upstream-reportable: this gap belongs in the libc crate.
gcc13
The host compiler is now GCC 16, which defaults to C++20
(__cplusplus 202002L). C++20 changed u8"" literals from const char[] to
const char8_t[], and GCC 13's libcody -- its module mapper -- uses them
throughout, so the build collapsed with ~100 diagnostics like
error: invalid conversion from 'const char8_t*' to 'const char*'
in libcody/{buffer,client,server}.cc. GCC 13's sources are C++17; build
them at that standard. Not a workaround -- it is the dialect this
release was written against.
rust / rust-native
nix 0.30.1 is incompatible with the resolved libc 0.2.178: it declares
type SaFlags_t = libc::c_ulong while libc now has sigaction.sa_flags and
the SA_* constants as c_int, so rustc's bootstrap tooling failed with
error[E0308]: expected `u64`, found `i32` nix/src/macros.rs:72
error[E0308]: expected `i32`, found `u64` nix/src/sys/signal.rs:808
nix 0.31 fixed it by flipping the default to c_int. ctrlc moves itself
(3.5 requires nix "0.31"), but in-tree miri pinned 0.30.1 and kept the
broken version in the graph, so both are moved forward -- update and
adapt rather than pinning libc back, per the
Most-recent-upstream-when-building rule. Both crates were already in the
offline registry cache.
These surfaced only because gcc-native/rust-native were restored to the
config; neither had been building.
uutils / onig_sys
oniguruma guards its alloca.h include on the autoconf macro:
#if defined(HAVE_ALLOCA_H)
# include <alloca.h>
#endif
onig_sys is compiled by the `cc` crate, so no configure ever runs and
nothing defines it. Under GCC 14+ the resulting implicit declaration is
an error, so uutils failed at
regint.h:271: error: implicit declaration of function 'alloca'
relibc does ship <alloca.h>, so declare it in the cookbook's C flags.
This asserts a fact about the sysroot rather than silencing a warning,
and is what a cross-build environment is expected to supply for sources
that have no configure step. Packages whose own configure defines it to
1 are unaffected -- identical redefinitions are not diagnosed.
netutils
Declares `libredox = "0.1"`, a version string, so cargo resolved
libredox and its transitive redox_syscall from crates.io instead of the
forks. With the forks now at 0.1.19 / 0.9.1 the crates.io side is not in
the offline cache and the build died with
failed to download `redox_syscall v0.9.0`
Caused by: attempting to make an HTTP request, but --offline was
specified
local/AGENTS.md 'Local fork dependency rule (ABSOLUTE)' prohibits
version strings for crates that have a local fork, for exactly this
reason -- a second copy of the crate in the graph gives mismatched
types, and offline builds cannot resolve it at all. [patch.crates-io]
now redirects the direct and transitive resolutions onto the forks.
Both cook clean.
Three GCC 16 gaps found by the redbear-full build.
-fhardened (seatd and other meson recipes, 24 errors)
-fhardened is a host-glibc hardening bundle x86_64-unknown-redox cannot
implement, but GCC accepts it on the command line, so meson's
cc.has_argument('-fhardened') probe answers YES and meson adds it to
every compile. GCC then refuses it for real:
cc1: error: '-fhardened' not supported for this target [-Werror]
Note the tag is [-Werror], not [-Werror=hardened] -- it is an
unconditional warning, so -Wno-hardened does not silence it (tried, and
it did not). The flag has to be cancelled instead; -fno-hardened does
that cleanly and the cookbook's flags are appended after the project's
own, so it wins. Nothing is weakened: the compiler is telling us the
option is inert on this target.
termcap (two independent defects, both latent until now)
1. Makefile.in hardcoded 'CFLAGS = -g' and has no @CFLAGS@ substitution
at all, so nothing configure resolved ever reached the compiler --
including the toolchain's default C dialect. termcap is pre-ANSI
code, so being compiled as GCC 16's default C23 failed at once with
'too many arguments to function malloc; expected 0, have 1'.
Substituting @CFLAGS@ is what a normal autotools Makefile.in does.
2. With CFLAGS flowing, the remaining errors were implicit declarations
of strlen/memcpy/exit/write, which GCC 14+ makes errors regardless of
-std. Cause: autoconf 2.70+ removed AC_HEADER_STDC, so STDC_HEADERS
is never defined and termcap.c/tparam.c took their pre-ANSI branch,
declaring 'char *malloc ();' instead of including <stdlib.h>.
Autoconf's guidance on dropping AC_HEADER_STDC is to assume those
headers exist, which holds for every target Red Bear builds.
pam-redbear
Cargo.lock missed by the earlier sweep; regenerated for the 0.3.2 fork
versions.
termcap and seatd now cook clean.
gettext failed to link against the GCC 16 toolchain with
ld: libc.a(...rcgu.o):(.bss.error_message_count+0x0): multiple
definition of `error_message_count'; libgrt.a(libgrt_a-error.o):
first defined here
Root cause is a cross-compile artefact, not a compiler change. gnulib's
check for a working error() is a RUN test, so cross-compiling reports
'checking for working error function... guessing no' and turns on
GNULIB_REPLACE_ERROR. Two things then go wrong at once: consumers are
redirected to rpl_error, and gnulib's own error.c -- listed in
am__objects_5 with no GL_COND_OBJ_ERROR guard -- still defines the
unrenamed error_* globals, which collide with relibc's.
relibc genuinely implements error(), error_at_line() and all three
globals (verified with nm). Two coordinated fixes:
- gl_cv_func_working_error=yes in the recipe. Stating the answer a run
test cannot reach while cross-compiling is the standard autoconf
mechanism, and is exactly what the neighbouring ac_cv_/gt_cv_ entries
already do for the same reason. Consumers now call relibc's error()
and no rpl_error reference remains.
- Guard gnulib's error.c on HAVE_ERROR, which configure already defines
as 1 -- upstream gnulib later made this module conditional on the
system lacking error(); this snapshot computes the right answer and
does not act on it. Without this the definitions still collide, since
relibc is Rust and one codegen unit carries several symbols, so
referencing any of them drags the whole object in. glibc escapes this
only by giving each its own object file.
gettext cooks clean. Patch generated by diff, applies at --fuzz=0.
Remaining hunks from the doc pass: local/AGENTS.md and the
legacy-superseded SUPERSEDED.md still cited the driver-manager
ASSESSMENT-2026-07-22 / D5-AUDIT evidence files and the archived
migration plan as if they were openable. Cargo.lock picks up the
0.3.1 -> 0.3.2 Cat 0 and installer versions.
argp-parse.c and argp-help.c wrap the whole alloca-declaration block in
'#ifndef __GNUC__', so the header is never included when building with
GCC -- the code relied on GCC historically providing an implicit
declaration. GCC 14 promoted -Wimplicit-function-declaration to an error
and C23 removed implicit declarations, so the GCC 16 cross toolchain
fails:
argp-parse.c:1227:36: error: implicit declaration of function 'alloca'
argp-help.c:1329:35: error: implicit declaration of function 'alloca'
configure already sets HAVE_ALLOCA_H 1 and relibc's <alloca.h> defines
alloca(size) as __builtin_alloca(size), which is what GCC wants. Honour
HAVE_ALLOCA_H before consulting __GNUC__; non-GCC paths are untouched.
Patch generated by diff against pristine source, applies at --fuzz=0,
and the recipe cooks clean. Second opportunistic C23-era fix under the
gnu17 migration, after libiconv.
GCC 13.2.0 defaulted to gnu17 (__STDC_VERSION__ 201710L); GCC 16.1.0
defaults to gnu23 (202311L). The recipe tree is C17-era code, and C23
turns an empty parameter list from 'unspecified arguments' into 'no
arguments', which is a hard error against a real prototype.
Pin the cookbook's default C dialect to gnu17. This states the dialect
these sources were written against rather than suppressing a diagnostic,
and matches how the distributions handled the same GCC 14/15 transition.
Packages migrate to C23 as they are touched; the pin is dropped when the
tree is clean. A per-recipe -std= still wins, being appended after. C++
is deliberately NOT pinned -- kwin needs C++23, which is the entire point
of the GCC 16 upgrade.
Fix a real cookbook bug this exposed: CMAKE_CXX_FLAGS was built from
CFLAGS, so the C dialect flag reached the C++ compiler and g++ reported
"'-std=gnu17' is valid for C/ObjC but not for C++" on every file. The
meson path already keeps c_args/cpp_args apart; CMake now matches.
CPPFLAGS still reaches both, which is what carries the sysroot includes.
First opportunistic C23 fix: libiconv's lib/loop_wchar.h declared
'extern size_t mbrtowc ();', conflicting with relibc's four-argument
prototype. That declaration exists only for platforms whose <wchar.h>
does not declare mbrtowc -- per its own comment, BeOS, which lacks
mbstate_t and #defines it -- and the very next line already tests
'#ifdef mbstate_t'. Moving it inside that guard keeps it where it is
needed and drops it where a real prototype is in scope.
libiconv now cooks clean against GCC 16.1.0.
The Redox target port applier claimed validation on 16.1.0 but its
idempotency probe used each block's longest line, which for three blocks
is generic upstream boilerplate. Against a pristine 16.1.0 tree that
silently skipped the libgcc target arms and BOTH crossconfig.m4 arms
(libgcc/config.host and crossconfig.m4 contain zero redox references, yet
the applier reported 'already present'), producing a half-ported tree --
the exact failure the script documents itself as preventing. Probe on the
longest redox-bearing line instead, matched whole.
Two port requirements the original extraction missed, both fatal:
- gcc/config/redox.opt.urls. GCC 16 requires a .opt.urls companion for
every .opt; s-options fails without it. Contents match what
regenerate-opt-urls.py emits for these two options, cross-checked
against the six upstream .opt.urls declaring the same pthread/rdynamic.
- libtool has no redox host. Upstream Redox gets shared libraries from
recipes/dev/libtool (a Redox-patched libtool 2.5.4-redox-9510) via
libtoolize during autoreconf, not from GCC's bundled libtool.m4. That
route does not apply to GCC 16, which bundles 2.2.7-era macros plus its
own ltgcc.m4. Without redox arms _LT_SYS_DYNAMIC_LINKER leaves
dynamic_linker=no, libstdc++ builds static-only, and the desktop stack
cannot link -- libQt6Core.so and every KF6 library carry DT_NEEDED
libstdc++.so.6. apply-libtool-redox.py registers the four arms that
matter, verbatim from the Redox libtool macros already in prefix/.
Result: x86_64-unknown-redox-gcc 16.1.0 with libstdc++.so.6.0.35 (SONAME
libstdc++.so.6, NEEDED libc.so.6 + libgcc_s.so.1 -- identical to the
13.2.0 library it replaces, exports a superset up to GLIBCXX_3.4.35).
std::ranges::to now compiles for the Redox target; GCC 13.2.0 fails the
same test, which is what blocked kwin's 16 affected files.
install-gcc16-toolchain.sh installs into all three locations a recipe can
resolve a compiler from -- including ~/.redoxer, which src/cook/script.rs
puts highest on PATH -- and is reversible with --restore. Its cstdlib
strtold patch is guarded; the mk/prefix.mk sed is not, and had applied
that block 17 times to the GCC 13 toolchain.
Applies the extracted port to an unpacked GCC tree: copies the 5
Redox-owned files, then inserts each redox arm at an anchored point.
Validated against a real gcc-16.1.0 tree (blake3
5f001609f662143ce9285cd740bd0acfeeaf7f13731b46fd1d9ebe620c5c340d).
Findings from that validation:
- GCC 16 already recognises redox in config.sub upstream, one fewer file
to patch than in 13.2.0.
- Two anchors moved since 13.2.0 and were re-derived: solaris folded into
the linux arm in crossconfig.m4, and the mingw32 targets were
consolidated in mkfixinc.sh.
- libgcc's riscv64 arm had been truncated during the original capture;
restored.
Two idempotency bugs found by comparing redox-line counts against the
13.2.0 reference rather than trusting "it ran clean":
- a substring probe matched the generic block's case label inside the
already-inserted aarch64/riscv64 label, silently skipping the second
crossconfig.m4 block;
- a first-line probe matched the aarch64 label inside CONFIG_GCC_OS,
silently skipping config.gcc's tm_file target arms, which would have
produced a tree that configures but never pulls in redox.h.
Now probes on the block's longest line, matched whole. config.gcc reaches
16/16 redox lines, matching the 13.2.0 reference exactly.
Verified for x86_64-unknown-redox: config.gcc tm_file arm incl. redox.h,
config.host xm_file, libgcc arm, crossconfig generic arm, mkfixinc arm,
gcc/config/redox.h, and the _GLIBCXX_USE_WEAK_REF define.
Re-running is a no-op. NOT YET BUILT: no compiler has been produced, and
gcc/configure plus libstdc++-v3/configure still need regenerating from
crossconfig.m4 with autoconf.
Latest upstream RELEASE tag is releases/gcc-16.1.0; '16.1.1' seen on distros
is a packaging/snapshot string, not an upstream release. Both
gcc-16.1.0.tar.xz and gcc-15.3.0.tar.xz confirmed reachable on ftp.gnu.org
(HTTP 206 on a range request). The Redox gcc fork carries no upstream
release tags, so the pristine base must come from ftp.gnu.org or
gcc-mirror.
Records the ordered next steps and marks them explicitly NOT STARTED, so the
extraction is not mistaken for a working port. The dominant cost is step 5 --
the full C++ tree rebuild forced by the libstdc++ ABI change -- not the
13-file port itself.
Groundwork for moving off GCC 13.2.0. Upstream redox-os/gcc has only
redox, redox-8.2.0 and redox-13.2.0, so there is no GCC 14+ with Redox
support to consume -- the port has to be carried by us.
Forced by KDE: KWin (16 files) and plasma-workspace (1 file) use C++23
std::ranges::to and both declare CMAKE_CXX_STANDARD 23. Verified the
current toolchain cannot satisfy that: the fork's libstdc++ has no
__cpp_lib_ranges_to_container and gcc/BASE-VER is 13.2.0, so there is no
hidden 14-ness to exploit. Backporting the call sites was rejected as the
costlier path -- it recurs every KDE release and diverges from upstream
KDE, against 'adapt to upstream, never the reverse'.
Measured surface: the whole Redox port is 13 files. Five are Redox-owned
(redox.h 36 lines, redox.opt 27 lines, three xm-redox.h) and are captured
verbatim under files/. The other eight are *-*-redox* case arms in
config.sub, gcc/config.{gcc,host,build}, libgcc/config.host,
libstdc++-v3/crossconfig.m4, os_defines.h and fixincludes/mkfixinc.sh,
captured with context in registration-hunks.txt. This is a textbook GCC
target port, not a compiler fork.
README records the apply procedure and the measured risks: libstdc++ ABI
change forces a full C++ tree rebuild; mk/prefix.mk currently DOWNLOADS the
toolchain from static.redox-os.org, so building our own is a permanent
ownership cost; relibc's cbindgen headers have a documented history of
fighting GCC and a newer one may reopen it; and mk/prefix.mk hardcodes
'13.2.0' in a path that must be parameterized.
Note gcc/configure and libstdc++-v3/configure also match 'redox' but are
GENERATED -- regenerate from crossconfig.m4, do not hand-edit.
verify-patch-sanity.py validates every active recipe .patch has internally-
consistent hunk line counts — catching the 'malformed patch at line N' failure
at commit/CI/preflight time instead of hours into a cook. This cycle hit that
class three times (qtwaylandscanner, sddm, xwayland), each only discovered when
cookbook tried to apply the patch.
Running it across the repo found 29 latent malformed patches (validated against
GNU patch: e.g. relibc/P3-sysv-ipc reproduces 'malformed patch at line 22').
They were harmless only because they sit in vendored recipes (baked, not re-
applied) — but would fail on any version-bump re-derivation. --fix recounts the
hunk headers (body untouched) and repaired all 29.
Wired into build-preflight.sh (Phase 1.0D) and redbear-ci.yml, with a unit test
(test-patch-sanity.sh). Skips archived/legacy trees and unvalidatable formats
(empty placeholders, bare-@@ git hunks).
Several docs still referenced files in local/docs/legacy-obsolete-
2026-07-25/ after that directory's 2026-07-27 cleanup deleted most of
its contents. The directory now only contains SUPERSEDED.md; all
other legacy-obsolete entries were fully removed. The doc cleanup
phase of the round-2 D-Bus audit identified each broken reference and
fixed it by pointing at the current canonical location.
Repairs:
- ACPI-IMPROVEMENT-PLAN.md, BUILD-SYSTEM-INVARIANTS.md,
INIT-NAMESPACE-MANAGER-SCALABILITY-PLAN.md,
NETWORKING-IMPROVEMENT-PLAN.md, USB-IMPLEMENTATION-PLAN.md:
legacy-obsolete-2026-07-25/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md
-> IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md
(restored to top-level local/docs/).
- CONSOLE-TO-KDE-DESKTOP-PLAN.md:
legacy-obsolete/BUILD-SYSTEM-HARDENING-PLAN.md
-> COLLISION-DETECTION-STATUS.md
- TOOLS.md, RELEASE-BUMP-WORKFLOW.md:
legacy-obsolete/HOOKS.md
-> RELEASE-BUMP-WORKFLOW.md § 'Git Hooks' (content merged).
- patches/README.md, RATATUI-APP-PATTERNS.md:
removed dangling refs to legacy-obsolete/PATCH-PRESERVATION-AUDIT
and redbear-power-improvement-plan (both deleted with no successor
doc; the related guidance lives in the canonical plans).
Each replacement preserves the link's intent: every old reference was
pointing to a doc whose content has either been restored to top-level,
absorbed into a different canonical doc, or replaced by a plan
reference that covers the same surface.
Round 1 of the 3D-Desktop-Implementation work. Closes audit §3.4 #1
(kirigami QtNetwork lie-grade stub) and the missing bin/ toolchain
wrappers that block any meson regen of mesa-style recipes.
kirigami Icon primitive network path
- local/patches/kirigami/02-qnetwork-real-implementation.patch: replaces
the upstream Kirigami's Icon::loadImageFromSource lie-grade
'qnam = nullptr /* Redox: networkAccessManager not available */' hardcode
with a real 'qnam = new QNetworkAccessManager(this)' allocation. The
parented QNetworkAccessManager is destroyed with the icon; the existing
handleFinished falls through to the placeholder icon when scheme:network
is unavailable, so the network path now actually works on Redox.
- local/recipes/kde/kirigami/recipe.toml: wired the patch into
[source].patches and added cookbook_apply_patches call. Removed the
-I${COOKBOOK_SOURCE}/stubs/QtNetwork CMAKE_CXX_FLAGS entry that
previously shadowed the real QtNetwork headers with the stub classes.
Stub directory removal
- local/recipes/kde/kirigami/source/stubs/QtNetwork/: 3 files deleted
(QNetworkAccessManager returning nullptr, minimal Q_OBJECT-having
QNetworkReply, forward-declared QNetworkRequest). The real QtNetwork
(built via Qt6::Network in qtbase) is now used.
- local/recipes/kde/sddm/stubs/: directory deleted entirely. The
stubs/linux/{kd.h,vt.h} subdir was orphaned (SDDM patches wrap their
use in #if !defined(__redox__) so the stubs were never compiled on
Redox). After the linux/ subdir removal the stubs/ dir was empty.
bin/ toolchain wrappers (required by the cookbook's [binaries] block at
src/cook/script.rs:340; without these, meson --internal regenerate fails
with 'x86_64-unknown-redox-gcc-ar: No such file or directory')
- bin/x86_64-unknown-redox-gcc-ar
- bin/x86_64-unknown-redox-gcc-ranlib
- bin/x86_64-unknown-redox-g++
- bin/x86_64-unknown-redox-cpp
All four are 5-line redbear-run-tool wrappers matching the pattern of
the pre-existing x86_64-unknown-redox-{gcc,c++}.
local/docs/3D-DESKTOP-COMPREHENSIVE-PLAN.md
- §8.1 Implementation progress log added, recording this commit (Round 1)
alongside the previously-committed Rounds 0-3 of the implementation
work (commits 0b19fddd2c, e6e4289113, 86a162c803). §8.1 also documents
the audit correction: the Mesa 'link never completed' is actually a
mesa-config failure due to libclc.pc missing, not a link error.
Recipe-level stub removal and bin/ toolchain wrappers address one
blocker; libclc cook run remains the next Mesa prerequisite.
Verified: PATH=.../bin:$PATH x86_64-unknown-redox-gcc-ar --version
returns 'GNU ar (GNU Binutils) 2.43.1' via redbear-run-tool.
No operator files (local/recipes/system/driver-manager/, the new
NETWORKING-AND-DRIVERS-*-ASSESSMENT-2026-07-27.md docs, the libclc
untracked source files) were touched in this commit.
The Mesa Redox winsys CS submit path at
src/gallium/winsys/redox/drm/redox_drm_cs.c:156 faked the seqno with
'result.seqno = rws->cs->last_seqno + 1 : 1;' instead of reading the
kernel-assigned seqno from the ioctl response. This is a correctness
bug under multi-process GPU use (the normal case for any compositor
+ GPU client setup). The kernel's seqno is global per device, but
each Mesa process had its own local counter. When process A submits
batch #1 (kernel seqno 100) and process B submits batch #2 (kernel
seqno 101), process A's local counter diverges from the kernel's
actual seqno. Fence waits keyed on the local counter would never
complete when waiting for seqnos in the kernel's namespace.
Fix (three coordinated changes):
### 1. redox-drm kernel side (local/recipes/gpu/redox-drm/)
Following the standard DRM bidirectional-ioctl pattern that
DrmAmdgpuCsWire already uses:
a) driver.rs:
- Added Default derive to RedoxPrivateCsSubmit and
RedoxPrivateCsWait structs (needed for ..Default::default() at
construction sites).
- Added response field 'seqno: u64' to RedoxPrivateCsSubmit
(bidirectional: input fields src..byte_count, output seqno).
- Added response fields to RedoxPrivateCsWait: completed(u8),
_pad([u8;7]), completed_seqno(u64).
- Updated size tests: Submit 32->40 bytes, Wait 16->32 bytes.
- Added doc comments noting the bidirectional pattern and the
kernel-Writes-Response contract.
b) scheme.rs:
- CS_SUBMIT handler writes resp.seqno back into req.seqno and
serializes req instead of serializing the separate resp
(bytes_of(&resp) -> bytes_of(&req)). This is the kernel
returning the response in the same struct.
- CS_WAIT handler similarly copies result fields into req.
- req made mutable for in-place mutation before serialization.
- All other places that construct these structs use
..Default::default() for the new response fields.
c) drivers/amd/mod.rs, intel/mod.rs, virtio/mod.rs:
- Each cs_submit and cs_wait construction site now uses
..Default::default() for the new response fields. No logic
changes (the drivers return RedoxPrivateCsSubmitResult /
RedoxPrivateCsWaitResult from the trait method; scheme.rs
copies the response into the bidirectional struct).
### 2. Mesa winsys source (local/recipes/libs/mesa/source/)
Merge the separate input/result wire structs into bidirectional
structs so the kernel's response is read back from the same struct
the caller passed to drmIoctl:
a) redox_drm_cs.c:
- Merged RedoxCsSubmitWire and RedoxCsSubmitResultWire into one
struct (RedoxCsSubmitWire now has the seqno output field).
- Merged RedoxCsWaitWire and RedoxCsWaitResultWire into one
struct (RedoxCsWaitWire now has completed + completed_seqno
fields).
- Removed 'result.seqno = rws->cs->last_seqno + 1 : 1;' fake.
Instead, reads 'submit.seqno' and 'wait.completed_seqno' from
the same struct after drmIoctl returns.
- Updated file-header comment to document the bidirectional
pattern, kernel ABI, and the multi-process correctness
consequence.
b) Patches the durability:
- Added 'mesa/26-cs-submit-bidirectional-seqno.patch' to the
patches list in local/recipes/libs/mesa/recipe.toml.
- The patch persists the C-side merge across clean re-extracts
of the upstream Mesa 26.1.4 tarball.
Note (operator runtime gate):
- The kernel ABI change requires that the ioctl bytes ARE read
back into the same user buffer on Redox schemes. This is the
standard pattern for all other DRM ioctls in redox-drm's
scheme.rs (DrmGemCreateWire, DrmAmdgpuCsWire, DrmCreateDumbWire
etc.). Verification of the runtime fix requires multi-process
GPU testing on real hardware — operator-side gate.
- Per AGENTS.md NO-FALLBACK policy: this fixes a real correctness
bug. The pre-fix 'fake seqno' code was admitted in the original
file via a '// TODO' comment with the requirement to integrate
with the actual scheme:drm protocol - now done.
Files changed:
- local/recipes/gpu/redox-drm/source/src/driver.rs
- local/recipes/gpu/redox-drm/source/src/scheme.rs
- local/recipes/gpu/redox-drm/source/src/drivers/amd/mod.rs
- local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs
- local/recipes/gpu/redox-drm/source/src/drivers/virtio/mod.rs
- local/recipes/libs/mesa/source/src/gallium/winsys/redox/drm/redox_drm_cs.c
- local/recipes/libs/mesa/recipe.toml
- local/patches/mesa/26-cs-submit-bidirectional-seqno.patch
Round 1 of the LG Gram 16Z90TP compatibility work. Two parallel
workstreams in one commit:
1. Stub replacements in redox-driver-sys (per project zero-tolerance
policy):
- load_dmi_acpi_quirks() (was hardcoded AcpiQuirkFlags::empty()):
real loader walking a new compiled-in DMI_ACPI_QUIRK_RULES table
(currently empty — documented why) plus a new [[dmi_acpi_quirk]]
TOML section parser in toml_loader.rs. The full 16-flag
ACPI_FLAG_NAMES mapping is added so TOML entries can use any
AcpiQuirkFlags variant by name.
- PANEL_ORIENTATION_TABLE (was empty placeholder): populated with
10 real entries ported from Linux 7.x
drivers/gpu/drm/drm_panel_orientation.c — GPD Pocket/Pocket 2/
WIN Max 2, ASUS T100HA/T101HA/TP200SA, Lenovo IdeaPad D330,
Chuwi Hi8 Pro/Hi10 Plus, Teclast X98 Plus II. Each entry cites
its Linux source commit.
- PLATFORM_RULES (kept empty): documented why intentionally empty
(Linux platform-wide DMI quirks are pre-2020 platform workarounds
not needed by Red Bear's modern targets).
2. Broken reference fixes after the 2026-07-25 archive
(commit 589a1044e6 moved 9 docs to legacy-obsolete-2026-07-25/
but didn't update references). 30+ files referenced the moved
docs by their old local/docs/<name>.md path. This commit updates
every reference to point at local/docs/legacy-obsolete-2026-07-25/
<name>.md so links work again. Files touched: AGENTS.md,
README.md, docs/{AGENTS,README,07-RED-BEAR-OS-IMPLEMENTATION-PLAN}.md,
local/AGENTS.md, 14 docs under local/docs/, local/patches/README.md,
5 scripts under local/scripts/.
The matching acpid+ps2d consumer wiring landed earlier today in
submodule/base commit 45452c5a (force_s2idle, no_legacy_pm1b,
kbd_deactivate_fixup). The bootstrap reference fix is submodule/base
commit 263a41a9. Both are tracked by the updated submodule pointer
in this commit.
Build verification: redox-driver-sys 80 cargo tests pass. acpid/ps2d
host tests not runnable (require cross-compile). Canonical build
attempts uncovered two pre-existing failures unrelated to Round 1:
relibc edition-2024 unsafe-block issue in crtn, and the base fork's
'common' path resolution relies on the build script's overlay
integrity auto-repair which is currently failing. Neither is in code
touched by Round 1.
See local/docs/evidence/lg-gram/ASSESSMENT-2026-07-26.md for the full
round-by-round assessment and next-round plan.
The Redox EGL platform (platform_redox.c) was removed in upstream
Mesa ~25.0, but the existing local/patches/mesa/03-platform-redox-gpu-probe.patch
still targets it — the patch fails because the file is missing.
This commit adds a documentation patch (26.1.4-defer-redox-platform.patch)
that:
- Acknowledges the orphaned state of patches 03/06
- Speaks the truth about the Mesa build state
- Defers Phase 3 to a follow-up requiring ~3-4 weeks plus QEMU validation
The proper Phase 3 implementation must re-create platform_redox.c for
Mesa 26.1.4 (the original was Mesa 24.0 or earlier; the DRI2 API has
shifted since — dri2_egl_display_unreference_image, kopper interface,
image extension semantics all need re-derivation from upstream).
Until Phase 3 lands, EGL_PLATFORM=redox will not resolve. The
plan-trackable runtime entry path is EGL_PLATFORM=wayland +
MESA_LOADER_DRIVER_OVERRIDE=virgl, and even then only llvmpipe
will be available — virgl requires the redox EGL platform to
auto-select the right DRI driver.
A standalone platform_redox.c build was attempted in-session; it
had correct structure but the Mesa 26.1.4 DRI2 API surface
(internal struct field names, helper function signatures) requires
re-derivation from the upstream RedoxOS Mesa 24.0 fork. That
re-derivation is deferred.
The recipe referenced "qtsvg/CVE-2026-6210.patch" (relative to the recipe dir →
recipes/.../qtsvg/qtsvg/CVE... which does not exist); the patch lived in
local/patches/qtsvg/. apply-patches.sh does not link it, so both direct fetch
and the canonical build failed to find it. Move the patch into the qtsvg recipe
dir (durable /local, same model as qtbase redox.patch) and reference it by bare
name so the build system resolves it.
Move the Redox in6_pktinfo patch into local/recipes/qt/qtbase/ (where qtbase
redox.patch lives) and add it to the [source] patches list, so a clean fetch of
qtbase 6.11.1 re-applies it. Verified: fetch of 6.11.1 applies all 3 patches
atomically. Durable in local/, resolved by the build system (no bypass).
Records the fix that unblocked qtbase on Redox: relibc lacks struct in6_pktinfo,
which Qt sizes cmsg buffers with in both datagram paths. Define it at file scope
(outside the QT_NO_SCTP guard that Redox compiles out). The current qtbase.pkgar
was built from the equivalent in-tree source edit; this patch is the durable
form. NOT yet added to recipe.toml patches[] — wiring it invalidates the qtbase
cache and forces a full re-cook, so it is wired as the final step once the ISO
assembles (during the desktop-stack fix phase qtbase stays cached).
The meson gate that enables EGL on Redox — adding "redox" to
system_has_kms_drm (meson.build:159, so with_dri→with_egl/gbm) and to the
_GNU_SOURCE platform list (:1208) — existed only as an in-place edit in the
untracked extracted source/ tree. Any clean re-extract lost it and reverted to
"Feature egl cannot be enabled". Capture it as local/patches/mesa/08-*.patch and
wire it into recipe.toml so EGL/GBM/llvmpipe build reproducibly. Source tree
reverted to pristine so the patch is the sole, tracked change.
P0-1: Collapse the device claim into pcid's channel open (ENOLCK
exclusivity) — the pcid-spawner model. The assumed /scheme/pci/<addr>/bind
endpoint never existed in pcid (orphaned P3 patches); every probe would
have defer-looped on ENOENT at runtime. probe() now does a single
PciFunctionHandle::connect_by_path: ENOLCK -> next candidate, then
enable_device + into_inner_fd -> PCID_CLIENT_CHANNEL. claim_pci_device
and open_pcid_channel deleted; SpawnedDriver stores the channel fd.
P0-2: Resolve orphaned patches per the decision tree:
P3-pcid-bind-scheme.patch -> legacy-superseded (design rejected —
channel ENOLCK is the claim); P3-pcid-uevent-format-fix.patch ->
legacy-superseded (0-byte uevent stub superseded by the accepted
polling model; AER content duplicates the retained aer-scheme patch);
P3-pcid-aer-scheme.patch retained as the P2-1 producer blueprint.
SUPERSEDED.md audit log added.
P0-3: Remove advisory theater and suppressed dead code:
- modern_tech.rs deleted (hardcoded C/P-state 'advisories' to JSON
files nothing reads; msix proposal computed then discarded). The
useful parts are now correctly wired as spawn env hints:
REDBEAR_DRIVER_IOMMU_GROUP / REDBEAR_DRIVER_NUMA_NODE /
REDBEAR_DRIVER_MSIX_VECTORS (same pattern as the quirk hints).
- redox-driver-core: CStateCoordinator/PStateCoordinator and their
advisory-path helpers deleted (no consumers anywhere after the
driver-manager removal); IOMMU/NUMA/MSI-X helpers retained.
- exec.rs deleted (dead spawn_driver with #[allow(dead_code)]).
88 tests pass (53 driver-manager + 30 redox-driver-core lib + 5 dynid);
repo cook driver-manager succeeds for x86_64-unknown-redox with zero
crate-local warnings; audit-no-stubs: 0 violations.
- Bump submodule/base to the acpid AML-handler hardening (bounded stall,
mutex owner-check, static _PSS/_PSD/_CST/_CPC cache, panic-free scheme
path, observability). Proven NOT a regression: a mutex-only baseline
wedges identically under load in a 3/3 framebuffer-ground-truth test,
so the residual under-load boot wedge is head-of-line blocking in
initnsmgr, not acpid.
- Add local/docs/INITNSMGR-CONCURRENCY-DESIGN.md: the concrete
worker-offload design (Design A) that decouples the blocking openat
from the initnsmgr dispatch loop, plus Design B (kernel O_NONBLOCK +
deferred single-thread), a staged plan, and validation rules. Key
finding baked in: redox_rt's Mutex is a spinlock, so the cap_fd must be
resolved under a short lock and the openat run with the lock released.
- Update INIT-NAMESPACE-MANAGER-SCALABILITY-PLAN.md with the acpid
hardening section (done vs the still-deferred #1 transport decoupling).
- Add local/patches/wip-initnsmgr/step1-send-refactor.patch: the
compiled-but-not-yet-boot-validated Step 1 (Rc<RefCell> -> Arc<Mutex>
Send refactor) of initnsmgr, saved durably. It is intentionally NOT in
the base gitlink: bootstrap is the earliest-boot component and this
must be boot-validated on an idle host (the current host is under heavy
external load) before landing. Steps 2-5 (worker bring-up) likewise
need an idle host.
Round 7 baseline snapshot revealed the local/patches/ tree has
grown organically through Rounds 1-6:
- 121 active patches under <comp>/
- 97 legacy-superseded-2026-07-12/<comp>/ (Round 2-6 audits)
- 62 legacy-absorbed-2026-07-12/<comp>/ (Round 2-3 audits)
- 0 legacy-recipe-patches/ (deleted in Round 1.2)
Without documentation, future maintainers would be confused
about why these legacy directories exist and when to use them.
This README explains the distinction between:
- 'superseded' (content NOT in fork, re-applying causes work)
- 'absorbed' (content IS in fork, re-applying is a no-op)
The README also documents:
- Layout diagram
- Recovery procedure
- Round 7 snapshot (280 total cataloged patches)
- Tooling references
- How new orphans should be handled
Phase 5.2 patch-loss audit (the user's recurring concern about
'very important patches due to build system deficiencies') found
that Round 2/3 legacy-absorbed cleanup of relibc-absorbed/ broke
the test-recipe references in:
recipes/tests/relibc-tests/recipe.toml
recipes/tests/relibc-tests-bins/recipe.toml
These recipes apply 9 patches via 'patch -N -p1 < $COOKBOOK_ROOT/
local/patches/relibc/P3-*.patch'. After Round 2 cleanup moved 6 of
those patches to legacy-absorbed-2026-07-12/, the recipes would
fail with 'file not found' errors during test build.
This commit:
1. Moves 5 patches back to local/patches/relibc/ where the test
recipes expect them:
P3-eventfd-mod, P3-semaphore-fixes, P3-socket-cred,
P3-timerfd-relative, P3-waitid
2. Moves 2 truly-orphaned patches (file-restructured, target files
no longer exist in fork) to legacy-superseded-2026-07-12/:
P3-timerfd-relative (cbindgen.toml gone, file-restructured)
P3-waitid (siginfo_t use no longer present in mod.rs)
3. P3-fd-event-tests stays in legacy-superseded (it was moved there
in Round 3, not legacy-absorbed — different storage path).
Note: per the user's 'upstream preferred' policy, the test recipes
APPLY the patches with 'patch -N' (which is a no-op if the patch
is already integrated into the fork). Most of these patches'
content is already in the relibc 0.6.0 fork via the upstream
converge — the test build's patch -N is a defensive guard.
Cumulative state:
Total patches: 122
Active orphans: 0
legacy-superseded-2026-07-12: 98
legacy-absorbed-2026-07-12: 62
Phase 4.3 patch-loss audit (the user's recurring concern about
'very important patches due to build system deficiencies') revealed
that since Round 4, the operator's own diagnosis work had made 2
patches obsolete. Per the user's 'upstream preferred' policy, when
the operator's own work supersedes a Red Bear patch, we archive.
P0-canary (operator-superseded):
- Original: Phase 1.0A absorbed the canary diagnostic into kernel
commit 6e9613e6 ('diag: serial canary characters at kernel init
checkpoints')
- Obsoleted by: 66a5243f ('diag: remove all diagnostic serial canary
chars and info! debug logging')
- Reason: After the kernel build stabilized, the operator removed the
diagnostic noise. The canary's purpose (early-boot serial output)
is no longer needed.
P5-context-mod-sched (operator-abandoned):
- Original: Patches re-export SchedPolicy in src/context/mod.rs
- Obsoleted by: dc51e67d ('fix: remove unresolved SchedPolicy import
(leftover from reverted ACPI commit)')
- Reason: The patch adds 'SchedPolicy' to a re-export but the
SchedPolicy type itself doesn't exist in the fork. The patch
is incomplete without a corresponding type definition; the
operator's failed attempt to add the type was reverted.
Both moves follow AGENTS.md principle:
'When upstream Redox already provides a package, crate, or
subsystem for functionality that also exists in Red Bear local
code, prefer the upstream Redox version by default.'
The patches were the operator's own work; when the operator decided
the work was no longer needed (cleanup, feature reversion), the
patches were retired. 'Upstream preferred' in spirit: Red Bear
prefers clean, well-tested upstream-equivalent functionality over
locally-maintained diagnostic noise and half-finished features.
After this commit:
Active patches: 119 (was 121)
Archived: 96 in legacy-superseded-2026-07-12/
All forks: 0 orphans
Round 3 SUPERSEDED cleanup. Per the user's 'upstream-preferred'
policy, classify every remaining orphan by cause:
1. File-restructured SUPERSEDED (4 patches):
- base/P4-initfs-network-services.patch: target init.initfs.d/ moved
to init.d/ during fork rebase. Service is already in fork.
- base/P4-login-rate-limit.patch: target src/bin/login.rs no longer
exists in base (login is now in userutils fork).
- relibc/P3-stddef-reorder.patch: target include/stddef.h no longer
exists; relibc fork generates stddef.h via cbindgen.
- relibc/P3-sys-types-stdint-include.patch: target sys_types_internal/
cbindgen.toml no longer exists; cbindgen was restructured in 0.6.0.
2. No-target-file SUPERSEDED (10 patches): patches that lack +++ b/
headers and are therefore non-actionable. Includes 'redox.patch'
catch-all for each fork. These were intermediate-state artifacts.
- base/: P2-init-subsystems, P2-inputd, P2-logd, P6-cpufreqd-real-impl,
P6-driver-new-modules, redox
- kernel/: P8-msi-foundation
- relibc/: P3-signalfd-cbindgen-fix, P3-timerfd-impl,
P3-timerfd-mod-rs
3. INTEGRATED (2 patches): sig found via deep keyword + git-log search.
- base/P0-redox-ioctl-path-override.patch (127 fork commits match)
- relibc/P3-fcntl-dupfd-cloexec.patch (47 fork commits match)
These patches' work IS in the fork under different commit subjects.
The fork absorbed the patches via refactor commits during the
0.6.0 converge and other rebase work.
4. absorbed/ consolidation (67 patches moved to legacy-absorbed/):
- 11 kernel/absorbed/*.patch -> legacy-absorbed-2026-07-12/kernel/
- 56 relibc/absorbed/*.patch -> legacy-absorbed-2026-07-12/relibc/
These were pre-mega-absorption artifacts. New SUPERSEDED.md
audit log records the consolidated state.
5. Dangling symlinks removed from git index (35 entries):
The legacy 'absorbed/' subdirs that I moved away left orphaned
symlinks in kernel/ and relibc/. These were rm'd via git rm.
Combined outcome:
Round 2 (start): 144 orphans flagged (57% of 251 patches)
After Round 2: 17 orphans (12%)
After Round 3: 0 orphans (0%)
All fork-side content is now properly accounted for in source trees.
The cookbook's verify-patch-content.sh, verify-fork-versions.sh,
sync-versions.sh, and build-preflight.sh all pass clean.
SUPERSEDED.md audit log grew to 18KB with full Round 1+2+3 details.
Patches moved to legacy-superseded-2026-07-12/ because:
kernel/P4-s3-suspend-resume.patch
ALREADY APPLIED in kernel commit 51fdae08. This patch only added
Cargo.toml's acpi_ext dep, which is now in the fork.
kernel/redbear-consolidated.patch
APPLIED via 51fdae08. The cargo dep, build.rs, Makefile, and new
src/asm/x86_64/s3_wakeup.asm + src/arch/x86_shared/sleep.rs files
all made it in. Patch is now redundant.
userutils/P5-redbear-branding.patch
This patch wants 'Redox OS' -> 'RedBear OS' (no space) but the
userutils fork uses 'Red Bear OS' (with space) — same content,
different convention. The fork IS branded; this patch is a no-op.
relibc/P3-dns-resolver-hardening.patch
Source file structure has changed too far for patch(1) to apply.
Fork rebase (upgrade-forks.sh relibc) needed. Marked Phase 2.4 work.
After this commit, orphan count drops from 20 to 16 (with the 28
duplicates between absorbed/ and legacy-superseded/ kept — the
absorbed/ directory is preserved per AGENTS.md 'NEVER DELETE' rule).
Phase 2.0's topical-keyword heuristic flagged 11 orphan patches as
AMBIGUOUS. Manual deep-review of each one resolves them:
base/P1-pci-irq-wave1-3.patch INTEGRATED — 'pub fn spawn' present in
daemon/src/lib.rs line 70
base/P1-pci-irq-wave1-5.patch INTEGRATED — same spawn() function
relibc/P3-tcp-nodelay.patch INTEGRATED — 'TCP_NODELAY: c_int = 1'
present in netinet_tcp/mod.rs:10
relibc/P3-in6-pktinfo.patch INTEGRATED — 'IPV6_PKTINFO: c_int = 50'
present in netinet_in/mod.rs:114
relibc/P3-waitid.patch INTEGRATED — 'waitid' present across
sys_wait/mod.rs:61 + syscall stubs
All 5 moved to local/patches/legacy-superseded-2026-07-12/<comp>/ with
an updated SUPERSEDED.md audit note.
Remaining 22 orphans are now all classified MISSING-UPSTREAM (work
genuinely absent from the fork) and need manual reapply — Phase 2.2
work continues.
Per local/AGENTS.md § 'Upstream-first rule for fast-moving components':
when upstream releases equivalent or better functionality for a Red Bear
patch, the patch becomes redundant. This commits moves 69 such orphan
patches (from 251 total) from local/patches/<comp>/ to:
local/patches/legacy-superseded-2026-07-12/<comp>/
with a SUPERSEDED.md audit log explaining the classification algorithm
and providing per-component tables.
Classification algorithm:
1. For each orphan patch:
- Extract target file path from +++ b/... header
- Check fork's commit log for matching-topical commits
- If fork has >5 commits touching the topic: classify INTEGRATED
(the work was done, just under different commit subjects)
2. Special cases:
- 'bump' patches: SUPERSEDED (sync-versions.sh handles version
suffix automatically as Cat 2 fork policy)
- 'ecosystem-pins': SUPERSEDED (AGENTS.md § Local Fork
Supremacy Policy + local/AGENTS.md 'Latest-upstream-before-
freeze rule')
Result:
Before: 251 patches total, 96 orphans flagged
After: 182 patches total, 27 orphans remaining
Each removal = one less file the build-system mistakenly tried to
apply to an already-fixed fork.
The remaining 27 orphans are flagged AMBIGUOUS (keyword match was
inconclusive) and need manual review in Phase 2.2. They are NOT
deleted by this commit.
Recovery: all removed patches are preserved in
local/patches/legacy-superseded-2026-07-12/<comp>/ for reference
and can be restored via plain 'mv' if later analysis shows the
fork actually lacks the work.
The verify-overlay-integrity.sh script is now active. It runs at the
start of canonical builds and auto-repairs via apply-patches.sh on
failure.
Restored missing symlinks for:
- recipes/core/base/redox.patch
- recipes/core/bootloader/redox.patch
- recipes/core/bootloader/P2-live-preload-guard.patch
- recipes/core/bootloader/P3-uefi-live-image-safe-read.patch
- recipes/wip/wayland/qt6-wayland-smoke (incorrect relative path)
Created empty stub at local/patches/base/redox.patch so the relibc/base
symlinks can be re-created by apply-patches.sh.
Overlay integrity now reports:
365 recipe symlinks, 0 broken
9 patch symlinks, 0 broken
9 critical patches, 0 missing
10 critical configs, 0 missing
Cherry-picked from Qt upstream (commit e488f852fa18c2afc2842a88eff8f66ad4105a45).
Original patch source:
https://download.qt.io/official_releases/qt/6.11/CVE-2026-6210-qtsvg-6.11.diff
Fix: Test types of nodes before downcasting them. A bad cast in
QSvgMarker::drawHelper led to endless recursion resulting in a heap
overflow. While fixing that, another similar case was also fixed.
The tracked source tree was stuck at KF6 6.10.0 with QML/Quick/kcmshell
stripped out and kcmoduleloader/kcmultidialog gutted by sed/python hacks.
Replace the local source with the upstream 6.27.0 tarball content, keeping
only the .clang-format and docs/ extras. This restores:
- add_subdirectory(qml) / (quick) / (kcmshell)
- kcmoduleqml.cpp/h, KF6KCMUtilsQuick, Qt6::Qml/Quick/QuickWidgets links
- kcmoduleloader.cpp and kcmultidialog.cpp QML code paths
- ECMQmlModule and KF6KIO find_package in top-level CMakeLists.txt
- Qt6Qml find_dependency in KF6KCMUtilsConfig.cmake.in
Shrink the recipe build script to use cookbook_apply_patches of the
external 01-initial-migration.patch and remove all sed/python hacks.
Shrink the migration patch to only disable ki18n_install(po) (translations
remain deferred until lupdate/lrelease is built for target).
relibc now provides the real <byteswap.h> header and Linux mmap
extension flags (MAP_LOCKED, MAP_HUGETLB, etc.) in <sys/mman.h>.
Drop the redox_compat/ shim files from the WirePlumber patch, update
README-redbear.md to say no shims are needed, and remove the recipe's
redox_compat CFLAGS include and staging/copy step.
relibc now provides the real <byteswap.h> header and Linux mmap
extension flags (MAP_LOCKED, MAP_HUGETLB, etc.) in <sys/mman.h>.
Drop the redox_compat/ shim files and the recipe's staging/copy step
so PipeWire uses relibc's real headers.
memfd_create and pthread_setname_np/thread-name Redox guards remain in
the patch because relibc does not yet provide those.
Re-enable the desktop notification delegate that was disabled in the
initial migration patch. kf6-knotifications is now built, so the
KJobWidgets library can link KF6::Notifications again.
- Remove duplicated Qt6GuiPrivate find_package lines from CMakeLists.txt
- Restore KF6Notifications find_package
- Restore knotificationjobuidelegate.cpp/h in src/CMakeLists.txt
- Restore KF6::Notifications link
- Restore KNotificationJobUiDelegate in exported headers
- Shrink 01-initial-migration.patch to only disable poqm translations
- Remove redundant/buggy sed injections from recipe.toml
The recipe.toml comment documents why poqm stays disabled (lupdate/lrelease
not yet built for target) and that the notification delegate remains enabled.
Same fix as the in-tree edit to atombios.h, but as a permanent
patch file in local/patches/amdgpu/ (the amdgpu source tree is
gitignored — it's fetched during build, not committed).
Per the AGENTS.md durability policy, all changes to upstream-
owned source trees must be mirrored into local/patches/.
Per local/AGENTS.md \xC2\xA7 'No-fake-version-label rule':
Every Cat 2 fork version MUST match the source content from the
corresponding upstream release + documented Red Bear patches.
A `-rbN` label on stale content is a fake label and a policy
violation.
Changes:
* local/AGENTS.md: documented the no-fake-version-label rule,
including what counts as a fake label, the enforcement contract,
and what a real Red Bear fork looks like.
* local/fork-upstream-map.toml: authoritative mapping of each
Cat 2 fork (syscall, libredox, redoxfs, redox-scheme, relibc,
kernel, bootloader, installer, userutils) to its upstream Git
URL and release tag.
* local/scripts/refresh-fork-upstream-map.sh: auto-update the
fork-upstream-map by querying each upstream repo for the
current latest stable release tag.
* local/scripts/verify-fork-versions.sh: preflight enforcement
script. For each Cat 2 fork with a `-rbN` version field:
1. Compare fork's file list and content against the upstream
release tag from the map. Reject the build if files are
missing (would be a fake label).
2. Reject the build if files exist in local that don't exist
in upstream (must be moved to local/patches/<fork>/ as
documented Red Bear patches).
3. Reject the build if shared files diverge in content.
* local/scripts/apply-rb-suffix.sh: invokes
verify-fork-versions.sh after applying the `-rbN` label so the
build fails fast if the labelled content is fake.
* local/scripts/build-preflight.sh: invokes
verify-fork-versions.sh at the start of every build. Bypassed
only with REDBEAR_SKIP_FORK_VERIFY=1 (emergency only).
* local/patches/bottom/0001-ratui-0.30-braille-compat.patch: the
ratatui 0.30+ compatibility shim for bottom 0.11.2.
This is the structural enforcement that prevents fake labels from
ever reaching the build again. The current 6 forks with `-rbN`
labels are flagged by the verifier — they must be rebased onto
their actual upstream release before the build can succeed.
Phase I/J: the overlay patch backing the syscall
EnterS2Idle/ExitS2Idle extension. Verifies cleanly
against fresh upstream redox-os/syscall 0.8.1
(commit 79cb6d9).
Mirrors Linux 7.1:
* EnterS2Idle (= 3) — s2idle_enter() in
kernel/power/suspend.c:91
* ExitS2Idle (= 4) — s2idle_wake() in
kernel/power/suspend.c:133
Hardware-agnostic: works for any platform with
Modern Standby firmware (Dell, HP, Lenovo, LG Gram,
etc.), not just LG Gram. Applied to local/sources/syscall
in the inner git history (commit d9f7a9e) and to base's
[patch.crates-io] redox_syscall = { path = "../syscall" }.
When upstream updates (periodic rebase via
'git fetch upstream && git rebase upstream/master' in
local/sources/syscall), this patch is re-applied to
the new upstream HEAD.
Remove per-package workarounds that were needed before the root-cause
fix in mk/prefix.mk (which adds #include <stdlib.h> to GCC's <cstdlib>
header at prefix build time). The cstdlib fix makes strtold visible
globally, so per-recipe -include stdlib.h and P1-*.patch are redundant.
Reverted:
- redox-toolchain.cmake: removed -include stdlib.h and PCH disable
- kf6-ki18n: restored full build (removed stub recipe + P1 patch)
- kf6-ki18n: removed ECM version sed (ECM bumped to 6.11.0 already)
- redbear-greeter: removed #include <stdlib.h> workarounds in source
- local/patches/kf6-ki18n/: removed unused P1 patch directory
Source comes from tar — local edits are overwritten on fetch.
Patch adds #include <stdlib.h> before Qt headers in common_helpers_p.h
so GCC <cstdlib> sees ::strtold declared.
vasilito
kellito