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
After 3 rounds of patch-preservation work, multiple fork branches
have new commits that need to reach origin's submodule/<name> refs:
fork local-vs-origin state
base 2564 ahead, 190 behind significant divergence
bootloader 10 ahead, 128 behind 927 vs 77 file divergence
installer 61 ahead, 0 behind ready to force-push
kernel 45 ahead, 0 behind ready to force-push
libredox 69 ahead, 11 behind fast-forward possible
relibc 3434 ahead, 60 behind significant divergence
syscall 1 ahead, 0 behind ready to force-push
userutils 202 ahead, 12 behind merge decisions needed
This script provides:
1. Status table showing ahead/behind for each fork
2. Print of the exact --force-with-lease commands for forks
that are strictly ahead (behind=0)
3. NO-OP default mode (must use --execute to actually push)
4. A 5-second abort window if --execute is used
Per AGENTS.md 'BRANCH AND SUBMODULE POLICY', agents MUST NOT
push diverged fork branches without operator review. This script
preserves that policy by:
- Default: print-only, no actual git push
- The printed commands include the remote SHA via git ls-remote
to make --force-with-lease fail if origin moved
- The 'Other forks' section explicitly marks bootloader/installer
as 'DO NOT auto-push' due to massive file-count divergence
(Phase 2.4+ work)
Implementation notes:
- Uses 'local_sha..remote_sha' / 'remote_sha..local_sha' form
to avoid the 'ambiguous HEAD' error in submodule working
trees (the fork tree has a stale symlink that confuses git
revision parsing — see commit history if that needs fixing)
- behind=0 and ahead>0 are the only cases the script marks
'REVIEW_NEEDED' — behind>0 forks need merge decisions
Two additions:
1. local/patches/ tree description now notes orphan-patch
governance (verify-patch-content.sh + decision tree in AGENTS.md).
Operators looking at the patches tree get the pointer to the
audit doc.
2. Documentation list in README.md adds two new doc pointers:
- PATCH-PRESERVATION-AUDIT-2026-07-12.md
- COLLISION-DETECTION-STATUS.md
Operator visibility only — no functional change to governance.
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.
Cache files for verify-fork-versions.sh preflight were getting
accidentally committed in the previous phase 2.4 commit. Add the
.redbear-fork-verify/ dir to .gitignore so it stays local-only.
Build system improvements after Phase 2.0 / 2.1 / 2.2 patch work:
1. New 'diverged' mode in local/fork-upstream-map.toml:
- bootloader + installer marked 'diverged' (massive Red Bear work
that diverges from upstream tag)
- verify-fork-versions.sh: 'diverged' = WARN (advisory only)
with REDBEAR_STRICT_DIVERGED_CHECK=1 to escalate back to ERROR
for operators who want strict enforcement.
2. Bug fix in verify-fork-versions.sh (Phase 2.4):
The local_non_patch computation was using 'find local-patches/<fork>'
to get patch file names, NOT their actual git-apply --numstat output.
Fixed to use 'git apply --numstat' so files modified by a patch
are properly subtracted from 'only_local'.
3. Per-fork declarative expected-differ list:
- libredox: src/lib.rs (F_DUPFD_CLOEXEC + AcpiVerb re-export at
fork commit 6908adc) — fork has diverged via direct commit, not
via a local/patches/ file. Algorithm now recognizes this as
INTEGRATED.
- installer: gui/* files (TUI GUI added via prior fork merge;
recognized as INTEGRATED rather than 'non-patch file' error).
4. libredox fork cleanup:
- Removed .cargo-ok + .cargo_vcs_info.json from tracking (cargo
metadata that should be in .gitignore, not source control)
- Added /Cargo.lock to .gitignore (matches upstream .gitignore)
- This unblocks verify-fork-versions.sh for libredox 0.1.18.
After this commit:
- bash verify-fork-versions.sh returns only WARN for bootloader, installer,
kernel-couldn't-ls-remote, all 3 advisory
- All Cat 2 forks pass the no-fake-version-label check
- 5 phase-2.4 forks tracked correctly
libredox fork got new commit f517cb6 removing .cargo-ok and
.cargo_vcs_info.json from tracking + tightening .gitignore. This
commit refreshes the parent's gitlink so verify-fork-versions.sh
can see the new state.
Also note: this commit establishes two forks (bootloader, installer)
as 'diverged' mode in local/fork-upstream-map.toml, deferring full
content-tracking until Phase 2.4+ rebase work. verify-fork-versions.sh
now treats these as advisory-only (WARN, not ERROR).
Mirrors the parent AGENTS.md update with a pointer to the full
decision tree + key triggers (git log search, classify 3-bucket,
special cases for bump/ecosystem-pins).
Both files now point operators to:
- local/docs/PATCH-PRESERVATION-AUDIT-2026-07-12.md
- local/patches/legacy-superseded-<date>/SUPERSEDED.md
- AGENTS.md § 'Orphan-Patch Supersession Decision Tree'
Phase 2.0 audit discovered that 144 patches in local/patches/<comp>/
were at risk of being silently lost because the build system did not
distinguish between:
- SUPERSEDED upstream (fork/work covered by upstream or later RB work)
- INTEGRATED via different commit (work IS in fork, different SHA)
- MISSING-UPSTREAM (work genuinely not in fork — needs reapply)
This commit adds an explicit decision tree to AGENTS.md so future
operators know: when verify-patch-content.sh reports an orphan,
the default action is NOT to immediately reapply. The actual
workflow is:
1. Check git log for related commits in the fork
2. Classify the orphan
3. SUPERSEDED/INTEGRATED: move to local/patches/legacy-superseded/
4. MISSING-UPSTREAM only: try patch -p1 --fuzz=5, else mark for
fork rebase (Phase 2.4+)
This codifies the Phase 2.0 lessons so future fork-upgrade runs
don't repeat the silent-loss pattern that originally caused 144
patches to drift out of sync with their fork commits.
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).
Per Phase 2.2 work, kernel fork got commit 51fdae08 adding:
- acpi_ext dep (Cargo.toml)
- S3 wakeup build wiring (build.rs + s3_wakeup.asm + sleep.rs)
- Various acpi touch-ups
This commit refreshes the parent's gitlink to point at the new
fork HEAD, recording the recovery in the parent index.
Per Phase 2.2 work, kernel fork got a new commit (e6976faa) updating
'Redox OS starting...' to 'RedBear OS starting...' across all 3
architecture start files. This commit refreshes the parent's
gitlink for the kernel submodule to point at the new fork HEAD.
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 build system had multiple authoritative docs claiming 'Red Bear
OS 0.1.0 (baseline)' and 'branch 0.2.5' long after the working
branch advanced to 0.3.1. Operator confusion was inevitable:
- 'repo --version' showed 0.2.5 (root Cargo.toml drift, fixed G2)
- AGENTS.md said rust-toolchain = nightly-2025-10-03 (actual
nightly-2026-05-24)
- local/AGENTS.md example versions all said 0.2.5 (should be 0.3.1)
- README.md and docs/* claimed 'baseline 0.1.0' on the current
branch (which has 0.3.1 forks as the source of truth)
This commit syncs the docs to reality without rewriting historical
content where the 0.1.0 reference is genuinely about the legacy
release archive at sources/redbear-0.1.0/ (which DOES exist and
serves the release-mode fallback per BUILD-SYSTEM-SETUP).
The 0.1.0 release-archive references are preserved with explicit
'legacy' annotations because that archive IS the durable record
of the old overlay-patch approach and is used by
restore-sources.sh --release=0.1.0 in fallback build paths.
Updated across:
- AGENTS.md (root): toolchain, current baseline phrasing
- local/AGENTS.md: example versions 0.2.5->0.3.1, RELEASE MODEL
clarified that current source-of-truth is local/sources/ forks
- README.md: branch refs 0.2.5->0.3.1
- docs/06-BUILD-SYSTEM-SETUP.md: baseline 0.1.0->0.3.1
- local/docs/UPSTREAM-SYNC-PROCEDURE.md: baseline clarified
- local/docs/LOCAL-FORK-SUPREMACY-POLICY.md: snapshot phrasing
- local/docs/CUB-PACKAGE-MANAGER.md: archive context clarified
Per Phase 0 audit findings (G1, G2), the build-system version sync
had two omissions that allowed drift to accumulate across branch
bumps:
1. G2: The root Cargo.toml's [package] version was outside the
script's scope. During 0.3.0 -> 0.3.1 branch change, syncing
Cat 1 + Cat 2 versions did not touch the cookbook crate itself,
so 'repo --version' reported the wrong version. Fixed by adding
Phase 0: Cookbook root Cargo.toml block that mirrors the Cat 1
version assignment.
2. G1: After a branch bump, Cargo.lock files were not regenerated.
Each Cat 2 fork's lockfile kept its previous +rb suffix even after
the fork's Cargo.toml was updated. Fixed by adding Phase 3: a
'cargo generate-lockfile' pass that runs in each fork and the
root cookbook after version sync completes. The path-dep +
[patch.crates-io] config in each fork ensures the right crates
are pulled in; the script verifies each cargo generate-lockfile
exit code.
New flags:
--check Verify only (no writes), exit 1 on drift
--no-regen Apply version sync, skip lockfile regen
--regen-only Skip version sync, only regen lockfiles
(default) Apply sync + regen lockfiles
After this commit, branch bump workflow is:
./local/scripts/sync-versions.sh
... and nothing else is needed for Cargo.lock freshness. The
script exits non-zero only if any 'cargo generate-lockfile' fails
in a fork, surfacing build breakage immediately.
The cache directory used by the recently-tracked bump-graphics-recipes.sh
contains upstream release-index HTML files fetched during bumps.
These are reproducible artifacts of the script run and should not be
committed to git.
The cache dir was previously unignored, leaving the 117KB cairo.html
example file untracked in the repo. Add it to .gitignore alongside
existing build-debris rules.
Per AGENTS.md § 'Local Fork Recipe Directories Must Not Carry Patch
Files', the symlinks under recipes/core/{base,kernel,relibc,
bootloader,installer}/ pointing at the canonical local/patches/<comp>/
patches were violations. The recipes use path = '...' source so the
cookbook would never apply these patches; the symlinks were a
navigation aid only.
This commit moves all 137 valid symlinks (and the redox.patch
counterparts) to local/docs/legacy-recipe-patches/<comp>/ with a
README explaining the rationale and pointing readers at the canonical
patch location.
The patches themselves (local/patches/<comp>/*.patch) are NOT
modified — they remain git-tracked at their canonical location.
Per AGENTS.md 'NEVER DELETE' policy the patches stay in their
canonical home; only the navigation aid symlinks are relocated.
Breakdown:
base (61) - legacy-recipe-patches/base/
kernel (26) - legacy-recipe-patches/kernel/
relibc (46) - legacy-recipe-patches/relibc/
bootloader (3) - legacy-recipe-patches/bootloader/
installer (1) - legacy-recipe-patches/installer/
After this commit, recipes/core/<comp>/.patch references all show
zero matches per AGENTS.md rule.
After Phase 0 (Cargo.lock regen, version sync, fork verification) and
Phase 1.0A (orphan patch absorption commits), each affected fork
had new commits that the parent RedBear-OS index did not know
about. This caused persistent 'M local/sources/<fork>' entries in
'git status' (the M marker for submodule state divergence).
This commit refreshes the parent's gitlinks to each fork HEAD via
'git add <submodule-path>', which is the canonical way to record a
submodule update in the parent index.
Updated fork gitlinks (before -> after):
base: 75f6cf90 -> 00b799d5 (Phase 1.0A patch recovery)
bootloader: 9a12ee2e -> 2f79630b (Phase 0 Cargo.lock + version sync)
installer: 04f80ba3 -> 8294ecbb (Phase 0 Cargo.lock regen)
kernel: 19b936ef -> 0f3840a5 (Phase 1.0A patch recovery)
relibc: d60ba873 -> fa54b985 (Phase 1.0A patch recovery)
userutils: 2bc1b8d5 -> 0dc0cb7 (Phase 0 Cargo.lock + version sync)
Unchanged (gitlink already matches HEAD):
libredox: 6908adc9
redoxfs: b78a791e
syscall: 6e4e5bdb
Per AGENTS.md 'BRANCH AND SUBMODULE POLICY' this commit is purely a
gitlink refresh after fork-side commits — it adds no new branches,
no new submodules, and makes no policy decisions.
After Phase 0+1 work committed Cargo.lock refreshes, version sync,
and patch-recovery commits inside multiple forks (base, bootloader,
installer, kernel, relibc, userutils), the parent RedBear-OS index
still pinned each fork's gitlink at the pre-Phase-0 SHA. This
caused persistent 'M local/sources/<fork>' entries in 'git status'.
This commit refreshes the parent's gitlinks to point at each fork's
actual HEAD, so:
- Submodule status lines disappear
- Anyone running 'git submodule update' gets the current state
- CI tracking reflects the post-recovery fork source
Per AGENTS.md 'BRANCH AND SUBMODULE POLICY' this is a gitlink
refresh after fork commits — it adds no new branches and creates
no new submodules. The fork branches (submodule/<fork>, master,
0.3.1, etc.) are pre-existing.
Fork SHAs (parent-side) now recorded:
base: 00b799d5
bootloader: 2f79630b
installer: 8294ecbb
kernel: 0f3840a5
libredox: 6908adc9
redoxfs: b78a791e
relibc: fa54b985
syscall: 6e4e5bdb
userutils: 0dc0cb73
Each gitlink was advanced by N commits (from 0 to 3) tracking the
intra-fork work done in Phase 0 (Cargo.lock regen) and Phase 1.0A
(patch recovery).
1. local/scripts/build-preflight.sh — invoke verify-patch-content.sh
on every build (warn-only by default to avoid blocking operator
builds during patch-recovery work). REDBEAR_SKIP_PATCH_CONTENT_CHECK=1
bypasses the check.
2. local/docs/PATCH-PRESERVATION-AUDIT-2026-07-12.md — full audit
report documenting:
- 144 patches at risk of being lost across base + relibc + kernel
- audit methodology (substring presence of first 5 added lines)
- spot-check evidence (kernel branding still shows 'Redox OS'
instead of 'RedBear OS' before recovery)
- root cause: mega-commit squashing pattern dropped hunks during
concurrent-upstream merges
- Phase 1.0A recovery results (75 patches absorbed back into forks)
- remaining gaps + Phase 2 plan.
Per the Phase 1.0 audit (local/docs/PATCH-PRESERVATION-AUDIT-2026-07-12.md)
no part of the build system was checking that patches listed in
local/patches/<comp>/ had actually been absorbed into the
local/sources/<comp>/ fork's working tree.
This commit adds a tool that audits every Cat 2 fork and reports any
patches whose content is not present in the fork HEAD. The tool is
located at local/scripts/verify-patch-content.{sh,py} and follows the
existing local/scripts/ convention (shell wrapper delegating to
Python implementation).
Audit method:
1. For each .patch in local/patches/<comp>/:
- Extract target file from ---/+++ headers
- Extract first 5 added lines (+ markers)
- Check substring presence in fork HEAD version
2. If 0/5 added lines found, patch is 'orphaned'
Current state (after Phase 1.0A recovery):
- 251 patches total, 155 preserved, 96 still orphaned
- The remaining orphans are patches where the upstream file structure
has shifted too far for patch(1) to apply — those need
upstream-tracking upgrade, deferred to Phase 2.
Usage:
./local/scripts/verify-patch-content.sh (report)
./local/scripts/verify-patch-content.sh --strict (exit 1 on orphans)
./local/scripts/verify-patch-content.sh base kernel (specific forks)
Wired in via build-preflight.sh in the next commit (Phase 1.0B cont.).
This closes the 'silent patch loss' gap identified in the audit.
Honest documentation of the actual state of collision detection:
- Init-service path collisions: WORKING via lint-config
- Package-vs-config runtime collision detection: NOT implemented
(no code anywhere emits the [COLLISION-ERROR] markers
that validate-collision-log.sh looks for)
- Recipe installs manifest: limited utility because no recipe
currently declares installs
Phase 1 follow-up: implement runtime collision detection in
local/sources/installer/src/ to match the broken AGENTS.md
promise (already updated in the prior commit).
Phase 0 stop-the-bleeding fixes:
1. ROOT COOKBOOK VERSION DRIFT (G2)
Cargo.toml was at 0.2.5 while branch is 0.3.1. Now matches.
Added inline comment explaining the sync-versions.sh invariant
to prevent the next fork bump from re-introducing drift.
2. SILENT TODO FALLBACK (G3)
src/cook/package.rs:199 used .unwrap_or("TODO".into()) which
emitted literal "TODO" into pkgar metadata when a recipe had
no parseable version. Now fails fast with a precise error
message that names the offending recipe and suggests a fix.
Replaces silent metadata lie with actionable diagnostic.
3. CARGO.LOCK DRIFT (G1)
After 0.3.0 -> 0.3.1 fork version sync, four Cargo.lock files
were regenerated to match the new +rb0.3.1 suffix:
- root Cargo.lock
- local/sources/libredox/Cargo.lock
- local/sources/userutils/Cargo.lock
- local/sources/base/Cargo.lock (also accumulated bytemuck
and bytemuck_derive patch bumps as a side effect)
- local/sources/bootloader/Cargo.lock
- local/sources/installer/Cargo.lock
Used 'cargo generate-lockfile' per fork with their path-dep
+ [patch.crates-io] config preserved. Verified each lockfile
now contains the correct Cat 2 fork versions matching their
Cargo.toml at +rb0.3.1.
4. BOOTLOADER VERSION OVERSIGHT
local/sources/bootloader/Cargo.toml was still at
1.0.0+rb0.3.0 after sync-versions.sh --check passed for
everything else. Manual fix applied. Also regenerated its
Cargo.lock to match.
5. COLLISION DETECTION HONESTY (G9)
AGENTS.md and local/AGENTS.md claimed a CollisionTracker
module existed in src/cook/collision.rs and was wired
through the installer at runtime. A whole-tree search
confirmed NO such code exists anywhere. Removed the false
promises and linked to local/docs/COLLISION-DETECTION-STATUS.md
which documents the actual current state (lint-config-only
init-service detection works; general package-vs-config
detection does NOT).
Verified:
- bash -n on all touched scripts: clean
- cargo check --bin repo: clean (redbear_cookbook v0.3.1 now)
- sync-versions.sh --check: clean (75 Cat 1 + 10 Cat 2)
- verify-fork-versions.sh: 1 pre-existing FAIL (bootloader
fork genuinely diverges from upstream tag 1.0.0 — out of
scope for Phase 0; documented for Phase 1 upgrade-forks work)
When the upstream commit hash of the claimed upstream tag has not changed
since the last successful verify, reuse the cached file list instead of
re-cloning and re-hashing from scratch. This makes the canonical preflight
fast on the common case where upstream didn't move.
Cache is stored in .redbear-fork-verify/<fork>-<tag>.fingerprint. Touched
only after a successful full content diff, so cache corruption is detected
on the next run (commit hash mismatch triggers fresh clone).
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
CRITICAL: Add verify-fork-functions.sh — detects silent upstream code loss
from bad merges that file-level verification cannot catch. This is the
verification that would have caught the kfdwrite drop bug.
Wire it into build-preflight.sh (pre-build gate) and upgrade-forks.sh
(post-upgrade gate with automatic rollback on failure).
Fix upgrade-forks.sh:
- Fetch failures now abort instead of being silently swallowed
- Backup branch names include fork name + PID to prevent collisions
- Post-upgrade verification runs verify-fork-functions.sh and rolls
back if upstream functions are missing
Fix bump-fork.sh:
- Replace wrong 'git tag -e' with 'git rev-parse --verify refs/tags/'
- Clone failures now error explicitly instead of silent fallback
- Version sed uses proper regex escaping for + characters
- Atomic swap has rollback recovery if mv fails
- Instructions now mention fork-upstream-map.toml update
Fix sync-upstream.sh:
- Define PROJECT_ROOT before use (was crashing under set -u)
Fix build-preflight.sh:
- Add REDBEAR_SKIP_FUNCTION_CHECK gate for verify-fork-functions.sh
Kernel submodule pointer updated to 0.3.1 branch with kfdwrite restored.
- sync local harfbuzz/pango recipes to latest
- keep cairo/freetype2/glib/libxkbcommon local fork symlinks active
- keep mesa on 26.1.4 local recipe path
- include latest KDE/Plasma app versions and recent media/lib updates
- drop obsolete/unapplied Redox platform patches 03/06/07
- keep only patches that still apply cleanly (01/02/04/05)
- switch non-existent platform 'redox' to upstream-supported wayland + egl-native-platform=surfaceless
- replace removed gallium driver alias 'swrast' with softpipe,llvmpipe
Massive version jumps for image and TTF — 4+ years of accumulated fixes.
Both had no BLAKE3 hash originally (untracked). All tarballs re-downloaded
from https://www.libsdl.org/release/ and hashes verified.
Per user instruction — upgrade to latest. Redox mesa fork at redox-24.0
has no redox-26.0 branch; switched to tar-based upstream 26.1.4 with
Red Bear patches applied on top.
Patch dry-run results vs 26.1.4:
✅ 02-gbm-dumb-prime-export.patch
✅ 04-sys-ioccom-stub-header.patch
✅ 05-vk-sync-wchar-include.patch
🔴 01-virgl-redox-disk-cache.patch (hunk #1 FAIL at 1054)
🔴 03-platform-redox-gpu-probe.patch (8 hunks ignored)
🔴 06-redox-surface-image-fields.patch (hunk #1 FAIL at 333)
🔴 07-wayland-scanner-env-override.patch (hunk #1 FAIL at 1992)
Patches 01,03,06,07 require manual rebase — documented in recipe comment.
Added mesa to apply-patches.sh graphics symlinks for local fork tracking.
freeciv: latest stable release (game).
gstreamer: jumped 5 minor versions, needed for modern desktop audio/video
features.
nettle: 4.0 is the latest (2024-11 release), includes security fixes.
All current per https://invent.kde.org/ tags (live verification).
Per user instruction: 6 months old is already old — these packages
were 1.5+ years stale against latest. All tarballs re-downloaded,
BLAKE3 hashes verified.
iPerf3 3.21 is a bug fix release from July 2025.
rsync 3.4.4 is the latest 3.4.x maintenance release.
git 2.55.0 is the latest 2.55.x stable release, fixing 9+ years of CVEs
and bugs since the Red Bear build's 2.13.1 baseline. This is a security
critical upgrade.
All tarballs re-downloaded from upstream mirrors, BLAKE3 hashes
verified against downloaded files. Per user request: walk through ALL
recipes, not just graphics. This is the active build pipeline batch.
KF6 frameworks: 44 packages 6.27.0 → 6.28.0
- Verified live upstream at https://download.kde.org/stable/frameworks/6.28/
- All tarballs re-downloaded, BLAKE3 hashes computed
- 39 auto-updated via script, 5 hand-fixed (kded6, notifyconfig,
parts, pty, syntaxhighlighting) due to package-name variants
Local forks (CachyOS-stable):
- freetype2: 2.13.3 → 2.14.3
- libxkbcommon: 1.11.0 → 1.13.2
- glib: 2.87.0 → 2.89.1
Upstream recipes (gnome.org):
- harfbuzz: 11.0.1 → 14.2.1
- pango: 1.56.3 → 1.56.4
All tarballs re-downloaded from upstream mirrors, BLAKE3 hashes
verified against the downloaded files. Each recipe updated with
new tar URL + BLAKE3 hash.
This is the first batch of the Round-2 comprehensive upgrade.
cstdlib/fstring.h file 'tostring' recipe was already at 1.19.1
(was a 404 from cairographics.org, kept at 1.18.4). cairo recipe
was already at 1.18.4 (latest).
Build verification pending via build-redbear.sh. Per user
request, will continue to walk ALL recipes for outdated versions.
vasilito