Replace all non-canonical build invocations (bare 'make all/live
CONFIG_NAME=', 'scripts/build-iso.sh', 'scripts/run.sh') with the
canonical './local/scripts/build-redbear.sh' wrapper.
Updated: AGENTS.md, local/AGENTS.md, README.md, docs/README.md,
docs/06-BUILD-SYSTEM-SETUP.md, and 6 active local/docs plan files.
Archived docs and frozen boot-logs left as-is (historical evidence).
Updates kernel submodule to 573b3e6 which replaces context::current()
with context::try_current() in excp_handler(), preventing the cascading
'not inside of context' panic when a page fault occurs during BSP's
start() before context::init() runs.
The cmake-generated Qt6ShaderToolsConfig.cmake has an empty
extra_cmake_include list. Patch it to include Qt6ShaderToolsMacros.cmake
so qt_internal_add_shaders is defined for downstream modules.
cmake install skipped this 405-line macros file that defines
qt_internal_add_shaders/qt6_add_shaders. Without it, downstream Qt
modules (qtdeclarative) fail at cmake configure with 'Unknown CMake
command qt_internal_add_shaders'.
Qt6's standalone module build installs qsb binary but does not generate
the Qt6ShaderToolsTools cmake wrapper package needed by cross-compile.
Added a Python generator that creates the minimal cmake package files
(Config, Targets, Targets-release, Precheck, AdditionalTargetInfo,
VersionlessTargets, Dependencies, ConfigVersion) following the exact
pattern of Qt6WaylandScannerTools from qtbase host build.
qtshadertools cross-compile needs the host 'qsb' (Qt Shader Builder)
tool, just like qtbase needs host moc/rcc/uic. Added a native cmake
build step that compiles qsb from the 6.11.1 source and installs it
into the shared qt-host-build prefix.
Also regenerate pam-redbear Cargo.lock (stale after 0.2.5 version bump
of redbear-login-protocol path dependency).
The host tool build profile was hardcoded with '6.11.0', causing the
stale 6.11.0 host tools to be reused for the 6.11.1 cross-compile.
Updated profile string to invalidate old host build.
Upstream Qt 6.11.1 already absorbed the #if QT_CONFIG(opengl) guards in
qwaylandclientbufferintegration_p.h that our redox.patch was adding.
Removed the now-obsolete hunks per patch governance (rebase, drop if
upstream absorbed it).
All remaining hunks apply cleanly against 6.11.1 with minor line offsets.
- Cookbook Cargo.toml: 0.1.0 → 0.2.5
- All 61 in-house crate Cargo.toml versions: 0.2.4 → 0.2.5
- os-release.in: fix URLs from github.com to gitea.redbearos.org
- sync-versions.sh --check passes with zero drift
The OS version is derived from the git branch name at build time.
Building on branch 0.2.5 produces os-release with VERSION_ID=0.2.5.
Records actual recipes bumped in 0.2.5 on 2026-07-02:
- Qt stack 6.8.2/6.11.0a1 -> 6.11.1 (all 6 sub-recipes, verified BLAKE3)
- Wayland/DRM/Input/expat/seatd to upstream latest stable (8 recipes,
verified BLAKE3)
- KWin 6.3.4 -> 6.7.2 + kdecoration 6.3.4 -> 6.7.2 + konsole 24.08.3
-> 26.04.3
Plus structural fix: created the missing qtshadertools recipe so the
qtdeclarative dependency chain resolves.
Documents what was deliberately NOT done:
- KF6 6.10 -> 6.27.0: 38 frameworks, 17-minor delta. Per AGENTS.md
patch-governance, no commit that bumps recipe.toml URLs without
first rebasing the local patches can be made honestly. Rebase
work (17-minor * 38 recipes) is multi-day and recorded as open.
- Mesa 24.0.8 -> 26.1.4: blocked on redox-os/mesa fork rebase
(0.3.0 work).
Includes the rebase order for the next session that plans to run
'make all CONFIG_NAME=redbear-full' against the bumped pins.
Bump KDE Plasma + KDE utility recipes to upstream latest stable
on 2026-07-02.
Versions resolved against download.kde.org/stable/plasma/ and
invent.kde.org/plasma/* tags:
kwin 6.3.4 -> 6.7.2 (invent.kde.org/plasma/kwin)
kdecoration 6.3.4 -> 6.7.2 (invent.kde.org/plasma/kdecoration)
konsole 24.08.3 -> 26.04.3 (invent.kde.org/utilities/konsole;
note: KDE utility versioning switched
from YY.MM calendars to v26.04-style)
BLAKE3 hashes verified against the actual downloaded upstream tarballs.
State of source trees on disk (NOT touched by this commit):
- local/recipes/kde/kwin/source/ : still KWin 6.6.5 (prior
session imported 6.6.5 source; new tarball at v6.7.2 will replace
on next repo fetch).
- local/recipes/kde/kdecoration/source/ : still 6.3.4
- local/recipes/kde/konsole/source/ : still 24.08 (RELEASE_SERVICE_
VERSION_MAJOR/MINOR).
Per AGENTS.md fork-adaptation policy, patches in local/patches/
{kwin,kdecoration,konsole}/ must be re-applied against the new
upstream source trees after fetch; rebase is open work for the
next session. Disabling patches or wrapping with feature flags is
NOT acceptable per the in-tree stub/workaround zero-tolerance rule.
This commit does NOT bump any KF6 framework recipe (38 recipes,
17-minor upstream delta). That work is multi-day patch rebase and
remains open.
Bump the lower-delta graphics-stack lane to real upstream latest stable
on 2026-07-02. Per AGENTS.md fork-adaptation policy, the local patches
in local/patches/{libdrm,libwayland,libevdev,libinput}/ must be re-applied
against the new source trees before the next build; rebase is open work.
Versions resolved against authoritative upstream registries (real latest stable):
libwayland 1.24.0 -> 1.25.0 (gitlab.freedesktop.org/wayland/wayland)
wayland-protocols 1.38 -> 1.49 (gitlab.freedesktop.org/wayland/wayland-protocols)
libdrm 2.4.125 -> 2.4.134 (gitlab.freedesktop.org/mesa/libdrm)
libxkbcommon 1.7.0 -> 1.9.2 (github.com/xkbcommon/libxkbcommon mirror)
libevdev 1.13.2 -> 1.13.6 (freedesktop.org/software/libevdev)
libinput 1.30.2 -> 1.31.3 (gitlab.freedesktop.org/libinput/libinput)
seatd-redox 0.9.1 -> 0.9.3 (git.sr.ht/~kennylevinsen/seatd)
expat 2.5.0 -> 2.8.2 (github.com/libexpat/libexpat)
BLAKE3 hashes verified against the actual downloaded upstream tarballs.
Not changed (already at or near upstream latest):
- dbus 1.16.2 (== upstream latest)
- xkeyboard-config (no standalone recipe; consumed via libxkbcommon)
- linux-input-headers (Red Bear original, not upstream)
Patches NOT yet rebased: see local/patches/{libdrm,libwayland,libevdev,
libinput}/. The dependency surfaces they patch (libdrm 2.4.134 has new
DRM modifier code, libwayland 1.25.0 has new server-decoder helpers,
libinput 1.31 has new touchpad gesture tables) will need review before
re-fetch.
Bump the entire Qt 6 recipe surface to 6.11.1 as resolved from
download.qt.io on 2026-07-02. Per AGENTS.md fork-adaptation policy,
patches in local/patches/qtbase/* and local/patches/qtdeclarative/*
must be re-applied against the 6.11.1 source tree after this commit;
rebase is open work for the next session.
Verified BLAKE3 hashes for the 6.11.1 tarballs:
qtbase c3b83023dc54f1173831bbc80abca1901418ef517875bf8071a4895d3c4a3162
qtdeclarative 10f2d0662047ceb0ef221b725b59e7fec5c9092a4c10d5acc7daefea5f11b962
qtwayland 154b80972e472b10330c82d3b171a915959a5d06139289d5b898c16c58de4de8
qtsvg 49b947e1a96bf0a29a1ee84c231a518a1413d9f3ec360617e405400e510508b2
qtshadertools 24dcd88b9e752a380067182687032b2139d2f6220d64e4193428434970102ae2
qtsensors 52ad8a724bc34f724feef197cf29f1cb535831ddd0fbad6e9dfedaa01eef1379
Also:
- qtbase: bumped from 6.8.2 -> 6.11.1. The 6.11.0 source tree had been
imported under local/recipes/qt/qtbase/source/ by a prior session
without updating the recipe.toml. This commit aligns the recipe
with both the imported source and the resolved upstream latest.
- qtshadertools: NEW recipe created. The recipes/qt/qtshadertools
symlink was dangling (target directory did not exist), making
qtdeclarative's qtshadertools dependency unresolvable. Now wired
up following the qt6-sensors recipe pattern. Source tar URL is
the resolved 6.11.1 upstream; per-repo fetch will populate
source/ on next build.
What's NOT done (deliberately):
- Patch rebase in local/patches/qtbase/P*.patch and
local/patches/qtdeclarative/P1-skip-tools-crosscompile.patch.
These must be re-applied against the 6.11.1 source tree before
the next build. AGENTS.md policy: rebase, do not remove.
- KF6 6.10 -> 6.27.0 bump (38 framework recipes, 17-minor delta).
Deferred — multi-day patch-rebase work, out of scope for one session.
See local/docs/0.2.5-GRAPHICS-FREEZE-PLAN.md §2.2.
- KWin 6.6.5 -> 6.7.2 + wayland-protocols/libdrm/libwayland/...
bumps (remaining graphics recipes). Deferred.
- No build was attempted. recipe.toml pin is now consistent with
resolved upstream latest-stable; no source tree replacement has
happened.
Plan-only artifact for the 0.2.5 graphics path. No recipe.toml changes,
no build attempted. Documents:
- Per-recipe upstream-latest-stable versions resolved via download.qt.io,
download.kde.org, gitlab.freedesktop.org, and git ls-remote on
invent.kde.org projects (no human guessing).
- Pre-build actions required (re-pull, re-blake3, validate-patches).
- Patch surface to re-evaluate across 17-minor KF6 bump and 1-minor
KWin bump.
- Mesa fork situation (24.0.8 vs 26.1.4): freeze at current fork,
rebase is 0.3.0 work.
- Freeze-when-green criteria for cutting 0.2.5.
- Out-of-scope items (Plasma workspace, real libepoxy, etc.).
Decisions in this plan are reversible; no recipe.toml field has been
modified. All work-in-progress from prior session is preserved as
uncommitted files in the working tree.
The build-redbear.sh script auto-stashes working tree changes
in nested relibc and base source trees before running the
build. These changes were captured by the failed kernel
build attempt that hit the json-target-spec / kernel rust
toolchain mismatch (fixed in 0.2.5 by creating the local
0.2.5 branch).
Captured changes:
- local/recipes/kde/* : KDE Frameworks 6 source CMakeLists
whitespace changes from the autostash (preserved)
- local/recipes/qt/qtbase/* : qtypes.h whitespace from the
autostash (preserved)
- local/sources/kernel/Cargo.lock : dependency lock from
the kernel relibc rebuild attempt
- local/sources/kernel/src/lib.rs : touched (mtime) by the
build script's touch + make prefix command
This is a bookkeeping commit — the actual code changes
for the threading plan are on the 4 submodule branches
(kernel, relibc, base, libredox) and will be pushed
separately.
0.2.5 branch was created from 0.2.4 (HEAD cd3950072e) to
continue Phase 0 of the multi-threading plan work in a
clean branch.
When a git-sourced recipe's source/ directory exists but has no
embedded .git (e.g., a cleanup pass removed .git directories from
build-cache sources, or the dir was extracted from an archive without
.git), the cookbook previously hard-bailed with
'{:?} is not a git repository, but recipe indicated git source'
This required manual intervention: the operator had to find the
broken source/ dir, rm -rf it, and re-run the build. With many
local recipes that use git URLs and embedded .git directories as
build caches (e.g., local/recipes/dev/ninja-build, local/recipes/kde/*),
this happened easily.
Fix: detect the missing .git, wipe the source dir, and re-clone from
the recipe's git URL. The fresh-clone logic is extracted to a new
reclone_git_source() helper used by both the initial-fetch path and
the self-heal path. After the self-heal, the source/ has a valid
.git and the rest of the fetch flow continues normally.
Tested by: deleting local/recipes/dev/ninja-build/source/.git (the
exact regression that triggered this fix) and running
./local/scripts/build-redbear.sh --upstream redbear-mini
which now self-heals instead of hard-failing.
Prepend an UPDATE block at the top of the plan document recording:
- The 8 commits that landed Phase 0c (futex sharding, per-CPU run
queues, vruntime, work stealing, load balancing, cache-affine,
initial placement, NUMA topology, proc scheme handles, fadt fix)
- The upstream-redox kernel audit finding (upstream has none of
these features; local fork is sole implementation)
- A plan-vs-actual state table showing which claimed 'missing'
features are now present
- The kernel-side Phase 0c is complete; remaining work is
relibc-side (Phase 0e) and futex-REQUEUE/PI/robust (Phase 1)
The detailed §1–§9 analysis is preserved unchanged as historical
record. The status column 'Missing' in §1 should be re-read as
'now present in local kernel fork, pending relibc userspace wiring.'
cargo check now exits 0 with 0 errors in the local kernel fork.
The local kernel fork just gained 3 commits:
- add Context::set_sched_policy and set_sched_other_prio
- acpi/fadt: fix pre-existing usize/u32 type mismatch on x86_64
- add SchedPolicy/Name/Priority proc scheme handles
After these, the local kernel fork:
- Has 13 of the 18 P5-P9 plan patches re-applied (3 obsolete by
refactor, 1 misnamed, 1 already in fork from P4)
- cargo check exits 0 with 0 errors
- Provides userspace API for pthread_setname_np, sched_setscheduler,
and setpriority via /proc/<tid>/{name, sched-policy, priority}
- Fixes a long-standing pre-existing ACPI FADT type mismatch
Phase 0c (patch recovery) is functionally complete for the kernel
side. Remaining P5-P9 work is in relibc fork (P3/P5/P7/P9 threading
patches) which is a separate, more self-contained effort.
The local kernel fork just gained two commits:
- P6-futex-sharding: replaces single global Mutex<L1, FutexList> with
64-shard hash table, eliminating contention between futex operations
on different addresses.
- RUN_QUEUE_COUNT: pre-flight constant at context::RUN_QUEUE_COUNT = 40
that downstream patches (P8-percpu-sched, P8-percpu-wiring) need but
none of the existing P5–P9 patches define.
Phase 0c, plan orders #1 and pre-flight.
The relibc fork at local/sources/relibc just gained a one-line
correctness fix for pthread_cond_signal (was calling broadcast() which
wakes all waiters; POSIX requires wake exactly one). The fix was
committed to the fork as 6caad3a5 and pushed to the submodule/relibc
branch on the canonical RedBear-OS repo.
This parent-repo commit updates the gitlink so a fresh clone picks
up the new relibc fork HEAD.
First execution of the multi-threading plan (Phase 0a).
vasilito
Red Bear Build System