Convert the transient git-fetch sddm recipe to the vendored model: commit the
source/ tree (pristine sddm @63780fcd + the two Redox patches baked in), switch
[source] to path="source" so the build never reaches github at cook time, and
keep the .patch files tracked for re-application on a version bump. Also fixes
the malformed redox-helper-utmpx-stub.patch (wrong hunk line-counts -> 'malformed
patch at line 24') by regenerating it with correct headers. First of the 26
transient recipes being vendored for an offline, reproducible full-fork build.
Proves build-redbear.sh's vendored source/ staleness loop: seeds on first sight
(no spurious rebuild), stays quiet unchanged, and invalidates target/ on
committed/uncommitted/untracked source/ changes. Keeps the loop body in sync.
The staleness gap behind the qtshadertools failure: cookbook keys its build
cache on the source.tar hash, but the actual build input for a vendored recipe
is the git-committed source/ tree. A version bump that propagates into source/
without changing source.tar (Qt's source.tar was already 6.11.1 while source/
was a 6.11.0 muddle) leaves cookbook reusing a stale stage — the desktop then
builds the old version. New loop fingerprints each vendored source/ by its git
tree hash (+ dirty flag) and rm's target/ on change; first observation only
seeds the fingerprint so it never forces a spurious full rebuild.
The 6 Plasma modules (breeze/kdecoration/kf6-kwayland/kglobalacceld/kwin) and
konsole were 'no-marker(skip)' because src_version/the validator only knew KF's
KF_VERSION. Now both also read set(PROJECT_VERSION) (Plasma) and the split
RELEASE_SERVICE_VERSION_MAJOR/MINOR/MICRO (KDE Gear), so these vendored modules
are version-checked and rebasable. Test E23.
Redo of the earlier lossy rebase with the added-file-preserving engine. 38
modules rebased to their declared upstream (KF 6.28.0 / Plasma 6.7.2 / Gear /
plasma-wayland-protocols 1.21.0) with every RedBear-added file kept (verified:
kglobalacceld5-wrapper.sh, utmp_compat.h, notifications_interface.cpp, kpty
shims) and blake3/source.tar reconciled. Deletion audit vs the pre-rebase base
shows zero RedBear files lost. 7 modules remain at their tested version pending a
manual Redox-port rebase (kf6-kded6/kiconthemes/kio/kservice SHIM-REJECT,
kirigami PATCH-REJECT, kf6-kimageformats/plasma-desktop DL-FAIL) — flagged, not
silently shipped.
The engine silently no-op'd ('!! not found') when given full paths like
local/recipes/kde/kf6-kio/ — resolve only understood bare names or group/name
tokens. Now strips a trailing slash, an absolute ROOT prefix, and a
local/recipes/ prefix before matching. Test E22.
9th silent-failure bug: the version stamp was checked BEFORE the real code marker
(Qt .cmake.conf / KDE KF_VERSION). A code-only revert leaves the stamp stale, and
the stale stamp then reported the module 'consistent' -> the engine skipped a
needed rebase and the validator false-passed a divergent tree. Both now check the
authoritative code marker first and use the stamp only as a fallback for
marker-less trees. The validator also learned KDE's KF_VERSION marker. Test E21.
Data-loss bug: rsync --delete during a rebase dropped RedBear-added files that
carry no __redox__ token (a Redox Wayland-crash wrapper .sh, a utmp compat
header, a generated D-Bus interface) because the capture was grep-on-marker
only. The engine now, for EVERY vendored rebase, fetches pristine(Vold) and
carries forward every committed file absent from Vold (content-agnostic, matched
by path) — so RedBear additions survive. If Vold cannot be fetched it rejects
(manual) rather than produce a lossy tree. New tests E20 (non-marker added file
preserved) + Vold fixtures for the rebase cases. 41 tests green.
Auto-resolved by sync-recipe-source.sh once the shim-port bugs were fixed: the
baked Redox shims (kpty PTY/utmp guards, UDisks2 D-Bus/optical-disc branches)
apply cleanly to 6.28.0 and are content-verified present in the rebased tree.
Found by extending the edge-case suite to the baked-shim path (E17-E19) after a
sync reported 'ready' but silently dropped a module's Redox shim:
- git show used an ABSOLUTE recipe path ('HEAD:/mnt/.../source/f') which git
rejects (needs repo-relative) -> empty content -> garbage delta. Now uses
${dir#$ROOT/}.
- diff|patch under 'set -o pipefail': diff exits 1 whenever files differ (always
here), so the pipeline looked failed even when patch succeeded -> EVERY shim
false-rejected. Now captures the delta to a file and checks patch's own exit.
- a shim whose file was renamed/removed upstream, or unreadable from HEAD, was
silently skipped. Now: Redox-added files are carried in verbatim; a missing
target or unreadable HEAD file -> SHIM-REJECT (manual), never a silent drop.
Also: old-version URL derivation now rewrites the major.minor dir component too
(KDE mirrors nest tarballs under .../6.28/foo-6.28.0). CI branch glob widened to
[0-9]* so 0.4.0/0.5.0 release branches keep triggering.
Follow-up to the KDE rebase: the vendored bumps had left recipe blake3 stale
(URL bumped, hash not), so recipe.toml declared a hash that no longer matched its
own source.tar. sync-recipe-source.sh now sets recipe blake3 to the authoritative
source.tar hash, and bumps transient recipes' stale cached source.tar to the
declared version. Applied to the marker-readable + transient set.
Integration (answers 'does it run automatically'):
- redbear-ci.yml now runs test-versioning-machinery.sh (33 cases) and
verify-external-source-versions.sh on every push/PR; trigger widened to
0.3.* so a release-branch increment keeps CI (and these checks) firing.
- The validator already runs in build-preflight.sh Phase 1.0C (every build),
and bump-graphics-recipes.sh (invoked by bump-release.sh --with-external)
now calls the sync engine — so an external bump propagates + is validated.
Engine hardening (both regression-tested):
- reconcile_blake3: a vendored bump often left recipe blake3 stale (URL bumped,
hash not); the engine now sets recipe blake3 to the authoritative source.tar
hash (only when source.tar version matches the URL version; no-op under --check).
- transient recipes (no vendored source/) now get their stale cached source.tar
bumped to the declared version too, instead of being skipped.
Applies the versioning fix to the KDE stack via sync-recipe-source.sh: these
modules carry no Redox port (0 __redox__ markers, 0 or auto-appliable patches),
so each is a clean pristine-6.28.0 re-lay with --checksum + a version stamp,
dropping the stale 6.10.0 trees and the line-duplication corruption. The 6
Redox-touching modules (kf6-pty/kio/solid/kservice/kded6, kirigami) are left for
manual port rebasing; mesa and other unknown-marker trees are untouched.
Each module still needs a Redbear OS build-adaptation pass at 6.28.0 (18 versions
of upstream drift); tracked as follow-up.
Edge-case suite (local/scripts/test-versioning-machinery.sh, 27 cases, zero
network via file:// tarballs) covering the validator and the sync engine.
It found and fixed three silent-failure bugs — the exact class the user flagged:
- sync engine used 'rsync -a --delete' (size+mtime quick-check): a changed file
of identical size with a coincidental mtime was skipped, leaving stale content
in source/. Now uses --checksum (content comparison).
- apply_patch relied on patch's default fuzz: a patch whose context no longer
matched the new upstream was force-fitted instead of rejected. Now --fuzz=0
(exact context; line offsets still allowed).
- decorrupt collapsed ANY run of identical lines, mangling legitimate paired
lines; now only collapses the corruption pattern (runs >=4).
Also: unknown-version recipes are skipped (never clobber a ported tree like
mesa), and grep patterns use [[:space:]] for portability.
Root cause of the Qt 6.11.0/6.11.1 and KDE 6.10.0/6.28.0 divergences: a version
bump rewrote recipe tar=/blake3= but never propagated into the vendored source/
tree (the actual build input), and nothing caught the resulting drift.
Adds the missing pieces (see local/docs/VERSIONING.md):
- sync-recipe-source.sh: propagation engine — rebases a vendored source/ onto
the recipe's declared version (pristine + patches + captured baked delta),
with baked-shim preservation and corruption drop; reports patches/shims that
need a manual rebase instead of applying with fuzz.
- verify-external-source-versions.sh: preflight gate (build-preflight.sh Phase
1.0C, REDBEAR_SKIP_EXTERNAL_SOURCE_CHECK) that fails loudly on recipe-vs-
source-vs-tarball version divergence — the tar-recipe analogue of
verify-fork-functions.sh.
- bump-graphics-recipes.sh: now calls the sync engine after a bump, so a bump
can never again silently no-op on a vendored recipe.
- source/.redbear-src-version stamp; seeded for the corrected qt modules.
Same half-done bump as qtbase: recipe tar= was 6.11.1 but the vendored source/
trees stayed 6.11.0. These three carry no Redox port (0 __redox__ markers), so
each is a clean pristine-6.11.1 re-lay:
- qtwayland: pristine 6.11.1 (no patches)
- qtdeclarative: pristine 6.11.1 + P1-skip-tools-crosscompile.patch
- qtsvg: pristine 6.11.1; stale 6.11.0 source.tar replaced; CVE-2026-6210 patch
dropped (the heap-overflow fix is already in upstream 6.11.1)
Drops the injected line-duplication corruption present in the old trees.
The recipe tar= and blake3 were bumped to 6.11.1 at the 0.3.1 branch cut, but
the vendored source/ tree was never propagated: it was a muddle of 6.11.0 and
6.11.1 files plus injected line-duplication corruption. Rebase the Redox port
onto a clean pristine 6.11.1 tree:
- pristine 6.11.1 + redox.patch + in6-pktinfo/ifreq/forkfd_qt patches
- re-apply the 6 baked-only Redox shims never captured as patches
(forkfd waitid, qprocess vfork, posix-sem decls, qassert, qplugin, qnet)
- qtwaylandscanner null-guard one-liner (its patch file was malformed)
- drop the sys/ioctl.h / assert.h / QT_CONFIG(opengl) line-duplication corruption
Result differs from pristine 6.11.1 by exactly the 36-file Redox port.
Make the vendored Red Bear Redox GPU port compile against Mesa 26.1.4:
- winsys meson.build: fix doubled 'drm/' source paths (meson.build already sits
in drm/); drop invalid declare_dependency(sources: [static_library]).
- redox_drm_winsys.c: adapt the custom swrast pipe_screen to 26.1.4 — the
never-mainline pipe_screen_ops indirection is gone (wire get_name/get_vendor/
get_device_vendor/get_screen_fd/is_format_supported/resource_create/destroy/
flush_frontbuffer/fence_reference/fence_finish directly on pipe_screen) and
per-cap get_param() is replaced by u_init_pipe_screen_caps(). The context-level
callbacks (resource_map/unmap, create_surface/destroy, fence_create/submit/
signalled) stay defined for the future full HW screen but leave the vtable.
Drop the dead rws->base.base.screen tracking (sw_winsys has no such member).
- redox_drm_surface.h: forward-declare struct redox_drm_winsys so the
flip_to_crtc prototype matches its definition (was a prototype-scoped tag ->
'conflicting types'). redox_drm_bo.c: PIPE_TEXTURE_ARRAY -> PIPE_TEXTURE_2D_ARRAY,
util/u_format.h -> util/format/u_format.h.
- pipe_loader_redox.c: include <xf86drm.h>; store the drm_driver_descriptor on
the redux device (base pipe_loader_device has no 'dd'); drop the bogus cast to
the private pipe_loader_drm_device.
- platform_redox.c: define redox_flush_front_buffer (was undefined
dri2_flush_front_buffer). egl_dri2.h: rename the surfaceless/device dri_image
front/back to image_front/image_back to avoid colliding with the wayland/drm
color-buffer 'back' when all platforms are enabled.
Result: the entire Mesa tree (iris/radeonsi/ANV + softpipe/llvmpipe/virgl/lavapipe)
compiles for x86_64-unknown-redox.
Add the mesa-clc dependency, put its staged usr/bin on PATH so meson's
find_program(native) resolves mesa_clc/vtn_bindgen2, and pass -Dmesa-clc=system
-Dprecomp-compiler=system. This resolves the cross-build structural error where
vtn_bindgen2 (native) linked target libs; with_clc now flips false so the cross
build no longer builds the in-tree CLC infra. Verified: cross mesa finds both
tools YES and passes every dependency + CLC gate (next blocker is the Redox
gallium winsys port).
A Redox cross build cannot run the target shader-precompile tools on the host,
so build them natively once and feed them to the cross Mesa via
-Dmesa-clc=system -Dprecomp-compiler=system. Native meson build against
llvm-native's CLEAN host LLVM/Clang (the redoxer toolchain's llvm-config emits
-I<toolchain>/include, which holds Redox target libc headers that poison host
g++), host system deps (libdrm/expat/zlib/zstd), and our host-built
SPIRV-Tools/LLVMSPIRVLib/libclc (pkg-config with absolute .pc prefixes; native
pkg-config, not the cross wrapper). Driver-agnostic tools, so iris-only (no
amdgpu-LLVM needed); they serve radeonsi/radv in the cross build too.
Mesa's radeonsi gallium driver requires libelf. Add a libelf recipe that builds
only the elfutils lib/+libelf/ subdirs (avoiding the libdw/libasm/tools glibc
surface) as a PIC static archive, relying on the new relibc headers/functions
(byteswap/error/libintl/ar/search + tsearch/mempcpy/rawmemchr). Installs
libelf.a + libelf.h/gelf.h/nlist.h + libelf.pc. Wired into mesa deps.
Verified: cook libelf - successful.
The host libLLVM.so (COOKBOOK_HOST_SYSROOT=/usr branch) lives in the redoxer
toolchain and is dynamically linked by rustc's librustc_driver. Building it as
X86;AMDGPU;NVPTX only dropped AArch64/RISCV, so after the AMDGPU splice rustc
failed to load with 'undefined symbol: LLVMInitializeAArch64AsmPrinter' —
breaking every Rust compile in the tree. Build the host LLVM with all CPU
targets rustc emits (X86;AArch64;RISCV) PLUS the GPU backends (AMDGPU;NVPTX).
The Redox-target llvm21 stays X86;AMDGPU;NVPTX (Redox is amd64-only, no need to
bloat the shipped libLLVM with foreign CPU backends).
Fixes a latent regression from 80d20db8/a6999912.
Shipping the Intel iris/ANV gallium+vulkan drivers turns on Mesa's with_clc
(with_driver_using_cl), which requires, in the native mesa_clc/intel_clc shader
precompile path: LLVMSPIRVLib (SPIRV-LLVM-Translator), SPIRV-Tools, and clang's
C++ libraries. None had recipes. Add three host-built dev recipes modelled on
libclc (built against llvm-native's host LLVM 21, staged into the cross sysroot
so Mesa's pkg-config resolves them):
- spirv-headers (SPIR-V grammar + headers; find_package package)
- spirv-tools (SPIRV-Tools.pc; SPIRV-Headers via find_package)
- spirv-llvm-translator (LLVMSPIRVLib.pc, v21.1.0.0; llvm_release_210 branch)
All three clear the cross-sysroot __libc_start_main leak with the llvm21-style
flag-clearing block in their native toolchain files.
Wire them + clang21 into mesa deps: Mesa resolves dep_clang via
cpp.find_library('clang-cpp', dirs: llvm-config --libdir), which the wrapper
rewrites to the target sysroot/lib, so clang21's target libclang-cpp.so must be
staged there (shared-llvm=enabled avoids needing the static clang libs).
Verified: mesa meson now passes amdgpu, LLVMSPIRVLib, SPIRV-Tools, and clang-cpp
(next gate is libelf for radeonsi).
The redoxer toolchain ships a prebuilt host LLVM built X86;AArch64;RISCV only.
Mesa resolves dependency('llvm', modules:[amdgpu,...]) against that host
llvm-config (COOKBOOK_HOST_SYSROOT), so radeonsi/radv AND the Intel iris/ANV
CLC precompile path fail and the whole desktop stack silently drops. The
binary prefix never regenerates that host LLVM, so add an idempotent pre-cook
hook (redbear-full only): if the toolchain llvm-config lacks AMDGPU, cook
host:llvm21 (recipe carries X86;AMDGPU;NVPTX) and splice its llvm-config +
libLLVM.so + AMDGPU headers/static libs into the toolchain, backing up the
originals first. Fails loudly; a no-op once AMDGPU is present.
clang-install now cooks host:llvm21 (which carries AMDGPU;NVPTX). rsync its
host LLVM (llvm-config + libs + llvm headers) into ~/.redoxer/toolchain so the
host llvm-config the Mesa build reads reports the amdgpu module (mesa's
dependency('llvm', modules: amdgpu) otherwise fails against the toolchain's
downloaded X86-only LLVM). Mirrors the existing relibc->toolchain propagation;
rsync without --delete preserves the toolchain's gcc/rust/redox-target files.
Per operator: don't forget Intel + virgl, and prepare for future NVIDIA. Intel
(iris/anvil) and virgl need NO LLVM GPU backend (NIR / virtualized) — they stay
in Mesa's driver lists as first-class targets. AMD needs AMDGPU (now); NVIDIA
(future, nouveau/NVK) needs NVPTX. LLVM rebuilds are very expensive, so include
NVPTX now (llvm21: X86;AMDGPU;NVPTX) to avoid an LLVM rebuild when NVIDIA lands.
Documented the vendor->driver->LLVM-backend matrix in the amd64-only policy.
Mesa's radeonsi/radv AMD-GPU drivers require the LLVM 'amdgpu' codegen backend
(dependency('llvm', modules: [... amdgpu ...])). llvm21 built X86 only, so the
host llvm-config the mesa build reads reported amdgpu(missing). Add AMDGPU to
LLVM_TARGETS_TO_BUILD (X86;AMDGPU per the amd64-only policy — AMDGPU is a GPU
backend, not a second CPU platform). This is the redox-target LLVM whose libs
mesa links AND the source of the prefix clang-install host LLVM. NB: the
~/.redoxer toolchain host llvm-config (a provisioned prebuilt) still needs the
rebuilt AMDGPU host-LLVM propagated into it (follow-up).
Red Bear OS supports exactly one CPU platform: amd64 (x86_64-unknown-redox).
No 32-bit x86, AArch64, RISC-V. Clarify that LLVM's 'X86' target name IS amd64
(not 32-bit) and that GPU backends like AMDGPU are a separate axis from the CPU
platform (radeonsi/radv need AMDGPU codegen; it doesn't add a second CPU arch).
The redbear-* logging-unify refactor (println/eprintln -> log::*) left three
mechanical corruptions, caught by --check-sweep:
1. log::MACRO!(); (empty call + spurious ;, args dangling) -> log::MACRO!(
2. log::MACRO!(<args>)); (one extra trailing paren) -> log::MACRO!(<args>);
3. use log::{..}; inserted INSIDE a 'use std::{' block -> moved out
Fixed across redbear-greeter/notifications/session-launch/statusnotifierwatcher/
upower (string-aware paren-balance sweep; balanced nested-paren calls untouched).
Separately, the 'tokio minimal' refactor left redbear-notifications and
redbear-statusnotifierwatcher using tokio::signal::ctrl_c/unix without the
tokio 'signal' feature (compile break). Per redbear-upower's documented finding,
tokio::signal::unix page-faults on Redox (relibc lacks the signal-handler
registration path) and Redox manages daemon lifecycle via the init system, not
POSIX signals. So the correct fix is NOT to re-add the feature but to drop the
signal-based shutdown entirely — the daemon holds its shutdown channel open and
runs until init stops it. Applied to all four signal-using daemons
(notifications, statusnotifierwatcher, udisks, polkit) and removed the now-unused
tokio 'signal' feature from udisks/polkit for consistency with upower.
Install used an ABSOLUTE CMAKE_INSTALL_PREFIX (${COOKBOOK_STAGE}/usr) together
with DESTDIR=${COOKBOOK_STAGE}/stage, so everything double-nested under
stage.tmp/<abs>/stage.tmp/usr/... and libclc.pc/.bc never reached the expected
paths. Use the standard pattern: relative prefix /usr + DESTDIR=${COOKBOOK_STAGE}
(libclc.pc gets prefix=/usr, resolved downstream via PKG_CONFIG_SYSROOT_DIR);
drop the stage-flatten hack. Also relocate libclc.pc from share/pkgconfig
(upstream's DATADIR) to lib/pkgconfig (cookbook convention mesa looks up).
All 2610 GPU bitcode files already generate + install correctly.
In LIBCLC_STANDALONE_BUILD the bitcode-gen custom commands invoke the host tool
by bare name ('prepare_builtins -o foo.bc'), which fails 'command not found'
when '.' isn't in PATH. prepare_builtins is built into the build dir (CWD), so
add it to PATH before the ninja run.
CMAKE_CXX_COMPILER was the plain `clang` (C) driver, so cmake's link of the
C++ prepare_builtins tool did not pull in the C++ runtime -> ld failed
'libstdc++.so.6: DSO missing from command line' (undefined
std::__cxx11::basic_string::_M_assign). Resolve a HOST_CLANGXX (clang++) and
use it for CMAKE_CXX_COMPILER; clang++ links libstdc++. Verified: relinking
prepare-builtins.cpp.o with clang++ succeeds.
Moving llvm-native fully to dev-dependencies removed it from the cook set: the
cookbook's cook-tree (src/cook/tree.rs) only follows `dependencies` when
resolving --with-package-deps, so llvm-native was staged-but-never-built and
libclc failed installing a nonexistent stage.pkgar. Cooking llvm-native (main)
via `dependencies` produces all its subpackage pkgars; stage .dev + .runtime
(host static libs/cmake + host clang) as dev-dependencies.
LLVM_DEFAULT_TARGET_TRIPLE was ${TARGET} (redox), so the host clang defaulted
to x86_64-unknown-redox and searched the Redox sysroot for the C++ stdlib when
libclc compiled its host prepare_builtins.cpp -> 'type_traits' file not found.
A host clang must default to the host triple (the redoxer toolchain's clang
does exactly this: Target x86_64-unknown-linux-gnu). Set it to
${COOKBOOK_HOST_TARGET}. libclc's .cl->bitcode compiles pass -target amdgcn
explicitly, so the host default does not affect them.
The host build works and staged llvm-native's .dev (static libs + cmake) so
find_package(LLVM) now resolves — but the host clang binaries live in
llvm-native's .runtime subpackage, which libclc didn't pull. The .dev ->
.runtime package link does NOT transitively stage at build time, so libclc
errored 'host clang not found under .../sysroot/usr/bin'.
Move the entire host toolchain to dev-dependencies (build-only; libclc's
shipped artifact is the .bc/.pc files, never clang) and add llvm-native.runtime
explicitly so usr/bin/clang* is staged.
llvm-native's job is to supply a COMPLETE host LLVM dev tree (host clang +
host static component libs + matching cmake/llvm export) that libclc's
find_package(LLVM) and host clang need for Mesa's iris/radeonsi CLC path. The
redoxer toolchain ships host clang + libLLVM.so but strips the static libs, so
find_package fails — and stubbing them violates the no-stub policy.
The recipe was WRONGLY cross-compiling LLVM for the Redox target via
cookbook_cmake: that (a) produces host-unusable Redox binaries and (b) fails to
link because Redox's libstdc++ lacks symbols LLVM uses (std::random_device
etc.). My earlier LLVM_USE_HOST_TOOLS=OFF / tblgen-var / native.cmake patches
were all treating symptoms of that wrong architecture.
Rewrite: build entirely with the host gcc, targeting the host, exactly like
libclc builds its own host prepare_builtins tool — invoke cmake directly (not
cookbook_cmake) with /usr/bin/gcc and no CMAKE_SYSTEM_NAME so CROSSCOMPILING is
false (LLVM builds one native tblgen with host gcc; no NATIVE sub-project, no
Redox-header leak). Drop all Redox build-deps and the llvm21.runtime package
dep. Validated: host GCC 16.1.1 configures LLVM 21 and builds llvm-min-tblgen +
libLLVMSupport.a/libLLVMTableGen.a cleanly.
This is how upstream-style host LLVM tooling should be produced; it supersedes
the cross-build patch chain (312659fe21, 5d426d89a7, 872935057c, b2d9a31a4f).
Even with LLVM_TABLEGEN/CLANG_TABLEGEN provided, LLVM_USE_HOST_TOOLS defaults
ON when cross-compiling, so llvm/CMakeLists.txt creates the NATIVE external
project (llvm_create_cross_target LLVM NATIVE) — a full second HOST LLVM build
that inherits the Redox cross flags and died compiling native llvm-config.
We already supply the only native tools a cross-build needs (the tablegens),
so OFF eliminates the native sub-build entirely; LLVM uses the provided host
tblgens for .inc generation. Completes the llvm-native cross-build fix chain
(native-link, OPTIMIZED_TABLEGEN, LLVM_TABLEGEN var name, and now this).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
These three tarballs were tracked in git despite being downloaded
artifacts, not Red Bear source. They total ~430MB on disk:
prefix/x86_64-unknown-redox/clang-install.tar.gz 138,545,573 bytes
prefix/x86_64-unknown-redox/gcc-install.tar.gz 99,661,186 bytes
prefix/x86_64-unknown-redox/rust-install.tar.gz 191,883,635 bytes
Why they were tracked is unknown (they predate AGENTS.md, which now
explicitly excludes toolchain installer tarballs via .gitignore pattern
'/prefix/**/*.tar.gz' added in the previous commit). They are reproducible
from build-redbear.sh — the script downloads them into this prefix path
when invoked.
This commit uses 'git rm --cached' so the working tree retains the
tarballs (the build system can still consume them as-is, no re-download
required). They are now untracked but covered by the .gitignore pattern
so future 'git status' is clean.
Working tree size reduction: ~430MB from the index. Full history rewrite
is out of scope for this housekeeping pass — old commits retain the
tarballs, but any new checkout/clone will skip downloading these blobs
via the 'thin pack' optimization. A full history rewrite via filter-repo
could be performed in a follow-up if storage pressure demands it.
Per AGENTS.md 'Never gitignore critical build infrastructure' policy: the
tarballs are NOT build infrastructure — they are reproducible download
artifacts. The real build infrastructure (recipes/, mk/, src/, local/) is
untouched.
vasilito