Concurrency
-----------
Package variants of one recipe (llvm-native, llvm-native.dev,
llvm-native.runtime) share a single target/<triple>/ directory and are
cooked concurrently by the cook_jobs thread pool, but every staging path
under it had a fixed name -- stage.tmp and sysroot.tmp. The variants
therefore raced: one renamed or removed the shared directory while a
sibling was still writing into it.
Canonicalize stage dir failed at '.../stage.tmp': No such file or directory
Renaming failed from '.../sysroot.tmp' to '.../sysroot': File exists
llvm-native cooks clean on its own -- verified, zero errors, all three
variants published -- but failed in every parallel build for this
reason. It was never a compile error, which is what the earlier
'C++/pthread header gaps' note in the config misattributed.
Both stage.tmp sites and the sysroot site now go through one
unique_tmp_dir() helper. A pid alone cannot disambiguate (the pool is
threads in one process), so a process-wide counter supplies uniqueness.
Config
------
Restore gcc-native, llvm-native and rust-native to redbear-full.
gcc-native was set to "ignore" and the other two were commented out as
'not needed for greeter proof'. Both forms are forbidden by AGENTS.md
ABSOLUTE RULE -- NEVER DELETE, NEVER IGNORE, NEVER COMMENT OUT, and by
local/AGENTS.md 'No build-excluded until ported packages': a package
that does not build gets ported, not excluded. llvm-native is required,
not optional -- it supplies the host LLVM dev tree that libclc and
Mesa's iris/radeonsi CLC path need.
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.
The libredox 0.1.19 / redox_syscall 0.9.1 bump left 45 recipe lockfiles
pinning libredox 0.1.18+rb0.3.1 and redox_syscall 0.9.0+rb0.3.1. The
cookbook builds with --locked, so every affected recipe died with
error: cannot update the lock file .../Cargo.lock because --locked was
passed to prevent this
which is what took out redox-driver-sys -- and with it every Red Bear
driver -- during the redbear-full build. Regenerating the fork lockfiles
was not enough; the recipes that consume the forks as path deps carry
their own. This is step 6 of local/docs/FORK-BUMP-PATCHING-POLICY.md
applied to the recipe layer.
Also drop the hardcoded GCC version in recipes/libs/libstdcxx-v3: the
literal include/c++/13.2.0 stopped resolving the moment the cross
toolchain moved to 16.1.0, leaving -I pointing at a directory that does
not exist. Now resolves the newest installed C++ header directory and
fails loudly if there is none. Same failure class as the hardcoded
13.2.0 in mk/prefix.mk.
Note: a few recipe-level Cargo.lock files (redox-driver-pci, cpufreqd,
redbear-acmd/-ecmd/-ftdi) sit beside a recipe.toml whose [source] is
path = "source", so they are not build inputs; redox-driver-pci's even
references a redox-driver-core/Cargo.toml that does not exist. They are
left alone rather than given meaning they do not have.
redox-driver-sys now cooks clean.
Two related races on recipes/<r>/target/<target>/sysroot, hit by
llvm-native during a -j 20 redbear-full build:
repo: failed to build: Renaming failed from '.../sysroot.tmp' to
'.../sysroot': File exists (os error 17)
llvm-native, llvm-native.dev and llvm-native.runtime are package
variants of one recipe and share that target directory. The cook_jobs
pool runs them as concurrent threads in a single process, so:
1. Shared staging path. Every variant used the same '<sysroot>.tmp', and
create_dir_clean() at the start of the staging block would wipe a
sibling's half-populated tree while it was still extracting pkgars
into it. Staging is now per-call, named from an atomic counter (a pid
would not disambiguate -- the pool is threads, not processes).
2. TOCTOU on the publish. The '!deps_dir.is_dir()' guard is checked long
before the rename, so all variants can pass it and then race; rename(2)
returns EEXIST/ENOTEMPTY once a winner has published a non-empty
directory, and the losers failed the whole recipe. Losing is harmless
-- every variant populates from the same recipe's dep set, so the
winner's tree is equivalent -- so the losers now discard their staging
and use it. The destination is deliberately not removed first, since a
concurrent cook may already be reading it.
Round 18's N22 'stale-doc removal' deleted three docs on the stated
premise that they had 'no references anywhere in the repo'. That premise
was wrong for two of them, and SUPERSEDED-DOC-LOG.md's recorded
absorption destinations for those two do not exist:
- CUB-PACKAGE-MANAGER.md was said to be absorbed into a 'redbear-cub
recipe README.md' and NETWORKING-IMPROVEMENT-PLAN.md section 8.2.
Neither exists -- there is no cub README under local/recipes/system/cub,
and that plan has no package-manager section (its 'cubic' matches are
TCP congestion control). README.md meanwhile links the doc from its
Documentation list and names cub in six places, so this left a headline
component with no documentation at all.
- BLUETOOTH-IMPLEMENTATION-PLAN.md was said to be merged into
NETWORKING-IMPROVEMENT-PLAN.md section 3.x. That file contains three
passing mentions of Bluetooth, not a 703-line plan. local/AGENTS.md,
docs/README.md and docs/07 all still list it as a first-class subsystem
plan, and AGENTS.md forbids treating Bluetooth as secondary.
Both restored from aa480f7ca3^ and their SUPERSEDED-DOC-LOG entries
retracted with the reason. USB-VALIDATION-RUNBOOK.md's supersession is
genuine -- USB-IMPLEMENTATION-PLAN.md carries the runbook as section 6.x
test procedures -- so it stays removed and its one reference now points
there.
Also de-dangled references to docs the authorised 2026-07-27
consolidation (092d1b39c3) removed but which canonical docs still cited
as openable: the driver-manager ASSESSMENT-2026-07-22 and D5-AUDIT
evidence files and the archived migration plan, across eight documents.
They now name what they were and where the supersession is recorded.
Remaining unresolved references are upstream KWin's vendored README
pointing at upstream's own CONTRIBUTING.md, which is deliberately not
touched.
verify-fork-versions.sh reads the 4th column of fork-upstream-map.toml
and skips the content check for forks marked 'diverged', with a WARN.
verify-fork-functions.sh had no notion of mode and hard-failed every
fork, so kernel (30), bootloader (5) and installer (2) blocked every
canonical build for drift the map itself records as accepted, with
comments saying a full rebase is later work.
Both verifiers now read the same source of truth. Diverged forks are
reported and counted as warnings; every other fork still gates. This
turned a 5-fork / 43-function hard failure into 2 real findings, which
are fixed in the accompanying relibc and base commits.
Cargo.lock in seven forks still named libredox 0.1.18+rb0.3.1 and
redox_syscall 0.9.0+rb0.3.1. Cargo rewrites them on first build, which
then trips the dirty-source gate mid-run. Regenerated offline and
committed so fingerprints reflect committed state.
New local/docs/FORK-BUMP-PATCHING-POLICY.md, wired into AGENTS.md,
local/AGENTS.md and docs/README.md. Core rule: a version bump is a
REBASE, never a REPLACEMENT.
Written from the libredox 0.1.19 incident, which hit three failures at
once -- wholesale replacement that dropped the acpi re-export,
F_DUPFD_CLOEXEC, the mandated authors entry and the Single-Repo
repository URL; a version-named branch that also tripped the build's
fork-branch gate; and a stale fork-upstream-map.toml that failed
verify-fork-versions.sh with a fake-label violation. Covers the vendored
recipe-fork mirror image (metadata moves, build input does not -- how Qt
shipped 6.11.0 against a 6.11.1 recipe), patch handling during a bump,
and toolchain bumps as version bumps.
Also fixes the two bookkeeping gaps that failed this build:
- local/fork-upstream-map.toml: libredox 0.1.18 -> 0.1.19, never updated
when the fork was bumped.
- verify-fork-versions.sh: record redoxfs's legitimate divergence in the
declarative allowlist the script already provides for libredox, with
the originating commit for each file -- a936d00 (Red Bear, Vec from
alloc for no_std bootloader builds) for filesystem.rs and record.rs,
852a971 (Red Bear, RecvFd EOPNOTSUPP) for mount/redox/mod.rs, and
d807dd3 (upstream symlink fix imported ahead of the 0.9.1 tag) for
mount/redox/scheme.rs. Documented rather than bypassed with
REDBEAR_SKIP_FORK_VERIFY.
Docs:
- Baseline was stated as 0.3.1 across the canonical set while the branch,
Cat 0/1 crates and every Cat 2 fork are 0.3.2. AGENTS.md also cited a
sources/redbear-0.3.1/ archive that does not exist; the only archive
present is sources/redbear-0.1.0/. Versioning examples now match the
forks as they actually stand (redoxfs/syscall 0.9.1, libredox 0.1.19).
- Repaired 18 instances of 'immutable archived' across 8 documents, where
a global find/replace had turned sync/synced/archived into that phrase
and produced ungrammatical text ('never auto-immutable archived',
'### Source immutable archived').
- Settled the apply-patches.sh contradiction empirically. Both sides were
wrong: the GROSS WARNING blocks (x5) described it as routine
patch-linking, and SCRIPT-BEHAVIOR-MATRIX.md said build-redbear.sh
'never invokes' it. It is invoked at build-redbear.sh:487, but only to
auto-repair a failed verify-overlay-integrity.sh check.
- Dropped the dangling reference to a local/AGENTS.md section
'NO OVERLAY-STYLE PATCHES — SCOPED POLICY' that does not exist.
Build system:
- mk/prefix.mk hardcoded 13.2.0 in the limits.h removal, which silently
no-ops after a toolchain upgrade and leaves the conflicting header.
Version-globbed.
- Parameterized GCC_RECIPE so the from-source toolchain path is not
pinned to gcc13.
- The three cstdlib strtold seds were not idempotent -- the shipped GCC
13 toolchain carried that comment block 17 times from repeated
'make prefix' runs. Each is now guarded.
The gitlink referenced 4398964, the tip of a stray 'bump-0.1.19' branch.
That branch violated local/AGENTS.md BRANCH AND SUBMODULE POLICY (no
version-named branches) and, being a wholesale replacement of the fork
with upstream, had dropped committed Red Bear work: the redox_syscall-
gated 'pub mod acpi' re-export, F_DUPFD_CLOEXEC, the vasilito authors
entry required by 'Fork authorship attribution', and the
gitea.redbearos.org repository URL required by the Single-Repo Rule.
submodule/libredox now carries upstream 0.1.19 merged into the fork, so
both the upstream multiple-fds work and all Red Bear work are present.
Type-checks clean for x86_64-unknown-redox.
recipes/**/*.patch is gitignored, but 01_redox.patch is force-added and
tracked. Match that precedent so the patch wiring survives a clean
checkout -- recipe.toml lists it, so an untracked symlink would break
the build from scratch.
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.
Both forks moved to the real upstream crate version, with in-house work
preserved deliberately rather than through upgrade-forks.sh's net-diff
(which squashes Red Bear commits into a single reapplied patch).
syscall 0.9.0 -> 0.9.1, via rebase. All 16 Red Bear commits replayed
individually so history and authorship survive; three obsolete label-only
commits dropped. Verified present afterwards: SYS_SETNS, SYS_CLOCK_SETTIME,
AcpiVerb::SetLpiHint, EnterS2Idle/ExitS2Idle, SetS3WakingVector, O_CLOEXEC,
SYS_SENDFD, SYS_OPENAT_WITH_FILTER, FullContextRegs, SYS_SYNCFS. Delta vs
upstream is purely additive: 348 insertions, 1 deletion across 9 files.
libredox 0.1.18 -> 0.1.19, via cherry-pick (a rebase aborted on the fork's
bulk "apply Red Bear patches" commit). Kept the two changes still unique to
us: demux() unwrap_or(u16::MAX) instead of .expect(), and Fd::ftruncate /
Fd::futimens taking &self. Dropped three in favour of upstream, which now
implements them at least as well: O_CLOEXEC handling, .gitignore/metadata,
and the bulk patch commit. Net delta is now 8 insertions / 3 deletions.
Pre-bump states kept at rb-backup/syscall-pre-0.9.1 and
rb-backup/libredox-pre-0.1.19 in the respective forks.
NOTE: neither fork branch is pushed yet - both rebases rewrote history, so
submodule/syscall and submodule/libredox need a force push, and the remote
tips must be confirmed to still equal the rb-backup commits first.
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.
The upgrade decision compared the newest upstream git TAG against $base,
which callers pass as the fork's Cargo.toml CRATE version. For several
Redox crates those namespaces are unrelated, so the comparison was
meaningless:
relibc git tags 0.5.0 / 0.6.0, but Cargo.toml AT tag 0.6.0 is 0.1.0,
and our fork is 0.2.5 -> reported '0.2.5 -> 0.6.0 upgrade'
when upstream master is 0.2.5, i.e. ALREADY CURRENT
libredox newest tag is v0.1.13, but upstream master is 0.1.19
Not cosmetic: upgrade-forks.sh consumes the result as --to=<ref> and does
'git reset --hard <ref>' before reapplying Red Bear commits as a net diff.
Acting on the relibc answer would have reset the fork onto an unrelated
lineage and reapplied our commits against it.
These forks are Cargo path deps with [patch.crates-io] and our label is
<upstream-version>+rb<branch>, so the CRATE version is the upstream
identity Cargo must satisfy -- compare crate-to-crate. Tag scanning
remains as the fallback for forks with no readable Cargo.toml.
Report after the fix:
syscall 0.9.0 -> 0.9.1 upgrade (tag 0.9.1 also exists)
libredox 0.1.18 -> 0.1.19 upgrade (master only; no matching tag)
relibc 0.2.5 ok (was a false positive)
redoxfs / redox-scheme / userutils ok
Known gap, documented at the call site: a fork whose crate version has no
matching tag (libredox) will make upgrade-forks.sh --to=<version> fail
loudly rather than reset onto a wrong ref -- the safe outcome. Threading
the upstream branch ref through as the rebase target is follow-up work.
New release branch per the release-branch model (operator decision;
local/AGENTS.md reserves branch creation to the operator).
sync-versions.sh, driven by bump-release.sh, rewrites:
- Cat 1 in-house crates -> version = 0.3.2
- Cat 2 upstream forks -> <upstream-tag>+rb0.3.2
Labels only; no fork source was rebased in this commit. bump-release.sh
reports these forks as having newer upstream tags, to be taken next:
relibc 0.2.5 -> 0.6.0
syscall 0.9.0 -> 0.9.1
libredox 0.1.18 -> 0.1.19
redoxfs and redox-scheme are already current. kernel, bootloader and
installer are 'diverged' in the fork map and stay report-only (manual
rebase); bootloader additionally has no merge-base with upstream.
kwin needs qtwaylandscanner_kde to run during the build. Its cmake offers
three paths (src/wayland/tools/CMakeLists.txt): a prebuilt binary via
QTWAYLANDSCANNER_KDE_EXECUTABLE, an in-place cross-compile via
ExternalProject, or a native build. With no executable supplied it took
the ExternalProject path, which inherits this recipe's cross CC/CXX/CFLAGS
and therefore compiled HOST code with the Redox toolchain:
/usr/include/qt6/QtCore/qsystemdetection.h:135:
#error "Qt has not been ported to this OS"
-- host headers, target compiler. Same host/target confusion as the
mesa-clc LLVM mislink, but inside an ExternalProject where QT_HOST_PATH
and KF6_HOST_TOOLING have no reach. Build it ourselves with the host
toolchain (the tools dir declares its own project() when it is top-level)
and pass it in: upstream's own first branch, no leakage. Host Qt6 is
6.11.1, matching the target Qt.
Bumps local/sources/relibc to pick up 'sys/un.h: define SUN_LEN'. KWin's
wl-socket.c uses that BSD/glibc extension and relibc did not define it.
Fixed in the fork rather than worked around in the recipe, per the
zero-tolerance stub policy; the prefix rebuilds automatically on the next
canonical build.
kwin compiles further; the remaining failure has moved into the native
qtwaylandscanner_kde sub-build (host/target flag leakage), not the target
sources.
killer and dialoghelper both include <private/qtx11extras_p.h> unguarded
and call QX11Info / XCB_CURRENT_TIME behind a RUNTIME platformName()==xcb
check that is always false on a Wayland-only session. Note src/main.cpp
does this CORRECTLY -- #if KWIN_BUILD_X11 around both the include and
every use -- so the guard is upstream's own convention and these two
helpers simply were not updated. Core kwin needed no change.
The missing private header also explains a misleading second symptom: on
failing to find it the compiler fell back to the HOST /usr/include/qt6 and
reported 'Qt has not been ported to this OS', which looks like an
unrelated toolchain fault but is the same missing header.
kcm_kwin4_genericscripted includes QUiLoader from qttools, which is not
ported. Dropping only the Qt::UiTools link left the include behind, so the
whole target is gated. It is the settings dialog for scripted effects; the
effects themselves are unaffected. Remove once qttools lands.
kwin now gets past cmake configure into compilation for the first time.
nightlight: TEMPORARY DEBT, same shape as systembell. KNightTime is used
by exactly one plugin (src/plugins/nightlight). find_package(KNightTime
CONFIG) is not itself REQUIRED -- set_package_properties(TYPE REQUIRED)
plus feature_summary(FATAL_ON_MISSING_REQUIRED_PACKAGES) is what aborts.
Correct KNightTime source, verified and recorded at the call site:
https://download.kde.org/stable/plasma/6.7.2/knighttime-6.7.2.tar.xz
blake3 27b06ec4545f732d0c44934b2a3d6e9359bd5e90e94627377accf2b69725d677
It is a PLASMA component (versioned 6.7.x alongside kwin), NOT a
Framework. The frameworks URL is a trap: invent.kde.org answers HTTP 200
with an HTML error page for a nonexistent project, so a naive fetch yields
a 13KB 'tarball' that only fails later at extraction.
Porting it is deliberately not attempted here: KNightTime itself needs
Qt6Positioning and KF6Holidays, neither of which has a recipe in-tree --
a three-package chain for colour-temperature shifting. Port those two,
then knighttime, then drop the two nightlight seds.
Qt::UiTools: the top-level component list was already stripped, but the
generic scripted-effect KCM links the target directly, so cmake still
failed with 'Target kcm_kwin4_genericscripted links to Qt::UiTools but the
target was not found'. That is the only target_link_libraries reference.
kwin's CMakeLists issues find_package/pkg_check_modules REQUIRED for
several packages that are in the config and built but were never declared
as deps, so they were never staged into kwin's sysroot: libxcvt,
libdisplay-info, kglobalacceld, libinput, lcms2. Audited the CMakeLists
for REQUIRED names and cross-checked against recipes that exist, rather
than adding them one failed configure at a time.
KF6_HOST_TOOLING must point at the HOST's system KF6 (/usr/lib/cmake), as
konsole already does. src/wayland/tools needs a native Qt/KF6 prefix;
pointing it at build/qt-host-build instead fails differently, because that
tree carries Qt host tooling but no KF6, and KF6AuthConfig /
KF6KCMUtilsConfig then fail their include().
systembell: TEMPORARY DEBT, narrowly scoped and documented at the call
site. It is the only consumer of Canberra in KWin, yet
find_package(Canberra REQUIRED) is ungated, so one optional audible-bell
plugin blocks the whole compositor. The in-tree WIP libcanberra recipe
depends on gtk3 and is itself marked 'no audio backend supported'; a local
recipe using --disable-gtk3 plus the null backend is the intended fix.
Visual bell and every other effect are unaffected.
.config pinned COOKBOOK_MAKE_JOBS=4. config.rs reads that variable from
the environment into cook_opt.jobs, and cook_build.rs exports it to every
recipe's build script as its -j value; mk/repo.mk passes no --jobs flag,
so the pin was authoritative. Every recipe therefore compiled with -j4 no
matter what -j build-redbear.sh was given, capping a 24-core host at ~12
concurrent compiles through Qt, KF6 and Mesa.
Unset, it derives from -j (default available_parallelism()). Re-add only
to deliberately clamp per-recipe compiles BELOW -j.
KWin does an unconditional find_package(Vulkan REQUIRED), and CMake's
FindVulkan needs BOTH Vulkan_INCLUDE_DIR and Vulkan_LIBRARY. Mesa already
builds the Vulkan drivers (libvulkan_intel/_radeon/_lvp) but an ICD is not
the API surface a consumer links against, so kwin could not configure.
vulkan-headers: header-only, but VulkanHeadersConfig.cmake is GENERATED at
install time rather than shipped in the tarball, and Vulkan-Loader
hard-requires it -- a hand copy of include/ satisfies FindVulkan and then
fails the loader. Run upstream's cmake install instead.
vulkan-loader: one real port. vk_loader_platform.h gates the whole POSIX
arm (DIRECTORY_SYMBOL, the dlopen wrappers, manifest search) on an OS list
that predates Redox, so the build collapsed with 'DIRECTORY_SYMBOL'
undeclared. Redox provides dlopen/dlsym and POSIX paths via relibc, so it
belongs in the same arm as Linux; that header is the only file under
loader/ doing OS detection. WSI backends are left off: Red Bear is
Wayland-only and the compositor talks to Mesa's ICDs directly.
Both shadow the untested recipes/wip/libs/graphics/{vulkan-headers,
libvulkan} via the local-over-WIP mechanism, per the WIP ownership rule
that the shipping version lives in local/recipes/.
Verified: kwin now reports
-- Found Vulkan: .../sysroot/lib/libvulkan.so (found version 1.4.321)
kwin also gains its missing kf6-knewstuff dep -- its
find_package(KF6 COMPONENTS NewStuff) is REQUIRED, so without the dep the
framework was never staged into kwin's sysroot.
qt-sysroot.sh: Qt installs QML modules under <prefix>/qml, KDE under
<prefix>/lib/qml, and ecm_find_qmlmodule() only searches the KDE root. A
REQUIRED Qt module was therefore reported missing even though its recipe
staged it correctly (plasma-framework aborting on
Qt5Compat.GraphicalEffects) while every org.kde.* module resolved fine.
Bridge the two roots with relative symlinks, never clobbering a real KDE
module of the same name.
plasma-framework: kf6-kwindowsystem is built KWINDOWSYSTEM_X11=OFF, so
KX11Extras and KWindowInfo do not exist, yet core translation units
reference them. Every such call already sits behind a runtime
KWindowSystem::isPlatformX11(), which is always false here, and the
package already ships some #if HAVE_X11 sites -- this finishes the job
upstream started. Done in Python, not sed: the transform needs brace
matching, and an if/else chain must keep its ELSE body (appletpopup.cpp
sets the Wayland surface role there; wrapping the whole chain would have
deleted the Wayland path). Also guards the unconditional <xcb/xcb.h>
include and drops BlurEffectWatcher's QAbstractNativeEventFilter base,
whose only override is itself X11-guarded, leaving the class abstract.
Pin WaylandScanner_EXECUTABLE to the host tool for the same reason breeze
needed it.
kf6-knotifications: the range-comment sed had an UNANCHORED start address
and an anchored end, so on re-runs it matched the '#if (NOT APPLE ...'
it had produced itself while '#endif()' no longer matched -- the range
ran to END OF FILE, commenting a little more of CMakeLists.txt on every
rebuild until install(FILES ...) lost its closing paren. Anchor the start
so it cannot match its own output, and drop the companion
'sed 127,137 s/^#*//' hack that existed only to undo the damage.
Four distinct ways the cross build reached for the wrong thing:
mesa-clc: 'unset LDFLAGS' left only /usr/lib on the link path, so the
HOST libLLVM won over llvm-native. Arch-family builds use
-DLLVM_LINK_LLVM_DYLIB, so libLLVM re-exports libstdc++ symbols under its
own version node; mesa_clc then recorded std::string::reserve@LLVM_21.1,
which no llvm-native build provides. When it instead resolved the host
libLLVM at runtime, clang derived its resource dir from the HOST install,
and with host clang 22 beside an llvm-runtime 21.1 the directory
/usr/lib/clang/21 does not exist, so every OpenCL compile died with
"'opencl-c-base.h' file not found" -- nowhere near the cause. Put
llvm-native back on the link path with a matching -rpath, and pin the
staged tools' RUNPATH to this recipe's own sysroot. Also wipe build-clc
before meson setup: re-running setup on a configured dir reinterprets -D
flags as option CHANGES and aborts on any option the old configuration
lacked ("Unknown option: mesa-clc").
breeze: kconfig_compiler_kf6 resolved to the cross-compiled Redox binary,
which the host cannot execute ('cannot execute: required file not found'
is ENOENT on the ELF interpreter). Point at the host tool.
kde-cli-tools: installs to KDE_INSTALL_FULL_BINDIR, an ABSOLUTE /usr/bin.
'cmake --install --prefix' only re-roots relative destinations, so cmake
wrote straight into the BUILD HOST's filesystem and only file permissions
stopped it. Use DESTDIR, which re-roots absolute paths too. kstart is
X11-only (Qt private X11 interop header) and cannot work without an X
server, so exclude it as kdesu already is.
sddm: QML_INSTALL_DIR fell back to 'qmake -query QT_INSTALL_QML', i.e.
the HOST Qt, so SddmComponents installed into the host build tree. Every
greeter theme does 'import SddmComponents 2.0', so this broke the login
UI at runtime with no build-time error.
polkit: dbus-1.pc's system_bus_services_dir comes back sysroot-prefixed
under a cross build, dropping a bogus /mnt/... tree into the image.
warm-cargo-offline-cache.sh: builds run cargo with --offline --locked, so
resolution comes from the sparse-index CACHE, which only an online cargo
run refreshes. A lockfile can pin a version whose .crate is already
downloaded while the index cache does not list it, producing
error: failed to select a version for the requirement quinn = ^0.11.1
(locked to 0.11.11)
candidate versions found which didn't match: 0.11.9
on a dependency that is in fact present. 13 lockfiles were missing 42
crates this way. --check reports offending manifests without fetching.
test-sddm-virgl-qemu.sh: boots redbear-full on virtio-gpu-gl with
egl-headless so the guest takes the accelerated redox-drm -> Mesa (virgl)
-> Wayland path, captures the serial console and classifies each boot
marker independently rather than collapsing to pass/fail.
The extractor matched '(?:pub )?(?:async )?(?:unsafe )?fn \w+' and then
stripped only the 'fn ', leaving the visibility modifier inside the key.
So 'fn foo' and 'pub fn foo' were different keys, and 'pub(crate) fn' was
not matched at all. Merely changing a function's visibility made it look
deleted: base was reported as missing remove_dentry, which the fork
demonstrably still has, and the report printed nonsense like 'fn pub
socket'. The exclude files had accumulated duplicate entries ('foo' and
'pub foo') to work around this.
Compare bare names on both sides, and normalize the function half of each
exclude entry so existing files keep matching.
Path-source recipes symlink recipes/<comp>/source at the local fork. The
guard used Path::exists(), which follows symlinks, so two cases silently
failed and then aborted the build with EEXIST:
* a DANGLING symlink (left behind after the checkout moved) reports
exists()==false, so nothing was removed;
* a live symlink TO a directory reports true, but remove_dir_all()
refuses to operate on a symlink and the error was swallowed by .ok().
Every core fork (relibc, kernel, base, bootloader, installer, redoxfs,
userutils) was dangling for this reason and no build could start.
force_symlink() classifies the entry with symlink_metadata() (which does
not follow the final component) and removes it correctly. It also writes
a RELATIVE link: recipe source links are committed build state that must
survive the checkout being moved or cloned to another prefix, and an
absolute link bakes in one machine's layout.
fetch_make_symlink() now repairs a same_as link whose target no longer
matches the recipe, instead of keeping it forever.
quick_sprite was the one QtQuick feature missing from qtquick-config_p.h (10
others defined), so any consumer including the private scenegraph headers hit
'#if QT_CONFIG(quick_sprite)' -> 1/QT_FEATURE_quick_sprite with the macro
undefined -> 'division by zero in #if'. This blocked qt5compat's GraphicalEffects
QML module (and would block every QtQuick-based QML module across the Plasma
stack). Enable -DQT_FEATURE_quick_sprite=ON alongside the other quick_* features.
plasma-framework's ecm_find_qmlmodule REQUIRED checks need two QML modules that
were not being built:
- org.kde.config: kf6-kconfig had -DKCONFIG_USE_QML=OFF -> enable it (qtdeclarative
is already a dep).
- Qt5Compat.GraphicalEffects: qt5compat only builds its QML imports when QtQuick
is present in the sysroot; add qtdeclarative to qt5compat deps so it cooks after
QtQuick exists, then stages the GraphicalEffects qml module.
Also declare qt5compat as a plasma-framework dep. (X11/XCB/OpenGL are optional on
the Wayland build and not the blocker.)
plasma-framework (task #13, the Plasma grind) needs KF6Svg + PlasmaActivities +
Wayland; declare kf6-ksvg, kf6-plasma-activities, plasma-wayland-protocols,
qtwayland, kf6-kdbusaddons. kf6-plasma-activities' QML imports in turn require
Qt6Sql (activities database), which qtbase built with FEATURE_sql=OFF. Enable
FEATURE_sql + FEATURE_sqlite (bundled, FEATURE_system_sqlite=OFF) in the TARGET
qtbase config — Sql is broadly needed across the KDE desktop, not just activities.
This retriggers the qtbase->Qt->KDE relink cascade.
Downstream KCM consumers (kde-cli-tools, plasma-*) run the imported
KF6::kcmdesktopfilegenerator at build time via kcmutils_generate_desktop_file();
the cmake build staged a Redox binary that cannot execute on the build host.
The tool is a single Qt6::Core-only source (tools/kcmmetadatagenerator.cpp — no
Q_OBJECT/moc, no KF6 libs), so recompile it with the host g++ + host Qt and
overwrite the staged binary. Verified: the staged file is a GNU/Linux x86-64 ELF
and kf6-kcmutils cooks successfully. It is a build-time-only generator (never run
on Redox), and usr/lib/libexec/kf6/ is outside the recipe strip/patchelf sweeps.
A relibc ABI change invalidates qtdeclarative's fingerprint and triggers an
incremental rebuild that keeps the 1-line empty qqmljsgrammar_p.h stub (it
survives the recipe's CMakeCache/CMakeFiles removal), so ninja skips qlalr
regeneration and every consumer of qqmljslexer_p.h fails with 'expected
class-name' / 'QQmlJS::Parser incomplete type'. Delete the stale qlalr outputs
(qqmljsgrammar_p.h + qqmljsgrammar.cpp) before configure so qt_process_qlalr
regenerates them. Pattern (j): stale codegen after a toolchain rebuild — now
durable instead of needing a manual clean rebuild each time.
Validated: qtdeclarative built (libQt6Qml/libQt6Quick) in the full cascade build.
Real data from a running build: 6 recipes cooking concurrently but only ONE
actual compiler process, load 2.2/16. Recipes almost never hit their compile
phase simultaneously — most cook-time is single-threaded configure/link/IO — so
the strict per_make = jobs/concurrency division starved the one recipe that was
compiling (mesa pinned to -j2 while 14 cores idled).
Give each concurrent cook the full -j; the active compiler now uses the
whole machine and the OS scheduler absorbs the rare overlap. Worst-case
parallelism is bounded by cook_jobs * jobs, so build-redbear.sh now defaults
COOKBOOK_COOK_JOBS to 4 (was JOBS/2) to cap simultaneous heavy C++ compiles for
RAM safety. A shared make jobserver would cap total jobs precisely while keeping
full per-recipe -j — noted as the proper long-term fix.
JOBS/4 left cores idle (observed load ~4.5/16 during a build). The make-job
budget division keeps total compile parallelism ~JOBS regardless of COOK_JOBS, so
RAM stays bounded; JOBS/2 keeps per-recipe make jobs >= 2 (fully using the -j
budget on busy levels) while adding enough recipe-concurrency to saturate the
cores. Higher (e.g. JOBS) would floor per-recipe jobs to 1 and waste budget.
Export COOKBOOK_COOK_JOBS (default JOBS/4, min 1) so the full build cooks
independent same-level recipes concurrently. Override with COOKBOOK_COOK_JOBS=1
for serial. See the cook orchestrator's run_parallel_cook.
The cook orchestrator built recipes strictly serially — COOKBOOK_MAKE_JOBS only
parallelized within a single recipe's make, so cores sat idle during every
recipe's configure/link/small-file phases. src/cook/scheduler.rs (dep_levels)
was written for this but never wired in (the module wasn't even declared, so it
never compiled).
- Declare the scheduler module (src/cook.rs) so dep_levels + its 7 tests build.
- New COOKBOOK_COOK_JOBS setting (config.rs, default 1 = serial): how many
recipes to cook concurrently.
- run_parallel_cook (repo.rs): partition recipes into topological dep-levels
(same level = no inter-deps = safe concurrent), process levels in order behind
a barrier, and within a level pull recipes from an atomic work-index across
scoped worker threads. The make-job budget is divided per level so
a lone heavyweight recipe (e.g. qtbase, alone at its level) still gets the full
-j, while crowded levels share it — no oversubscription, no slowdown for
serial-level recipes. Publishing stays a single batched step. Failure/nonstop
semantics preserved; only engaged for with cook_jobs>1 and >1 recipe.
- Safe because each recipe builds in its own target/stage/sysroot and a recipe's
sysroot is assembled from its dependencies' (lower-level, already-complete)
stage pkgars — read-only for concurrent siblings.
- package.rs: serialize packaging behind a global PACKAGE_LOCK. package() shares
process-global state (the lazily-created pkgar signing key at
build/id_ed25519.toml, name/metadata construction) that raced under concurrent
cooks (corrupt key, mangled names like 'x.dev.dev'); packaging is cheap, so
serializing it keeps the compile-parallelism win. Also make the package-name
construction fail gracefully (Err, not unwrap-panic) so a bad name fails one
recipe instead of crashing the whole scoped-thread build.
Validated: all-cached tree (COOK_JOBS=4) and a real concurrent build of 3
independent recipes (COOK_JOBS=3) both succeed and publish correctly.
kf6-kcmutils: (1) add the missing 'source local/scripts/lib/qt-sysroot.sh' before
redbear_qt_link_sysroot_dirs (undefined-function crash); (2) drop Qt6::Test from
the REQUIRED components (qtbase FEATURE_testlib=OFF, tests off); (3) declare the
kirigami dependency so its org.kde.kirigami QML module is in the sysroot (an
ecm_find_qmlmodule REQUIRED check).
kde-cli-tools: declare kf6-kcmutils + kf6-parts deps (find_package(KF6 REQUIRED
COMPONENTS KCMUtils Parts)); add -DBUILD_DOC=OFF (the doc subdir hard-requires
KF6DocTools + the docbook/xsltproc toolchain, not needed for a working desktop).
kf6-kio re-cooked (fingerprint invalidated by the cookbook_configure change) and
surfaced three issues; fix them as build-time seds so restore-sources.sh cannot
revert them (a cached source snapshot kept reverting in-tree source edits):
- previewjob.cpp: a prior port replaced the pristine '#include <KConfigGroup>'
with an unterminated '#if defined(Q_OS_UNIX) && ... && !defined(Q_OS_REDOX)'
(also dropping the include) -> 'unterminated #if'. Restore the include.
- hostinfo.cpp: drop <arpa/nameser.h> + <resolv.h> (BIND resolver headers absent
on relibc); the only symbol used, _PATH_RESCONF, has a /etc/resolv.conf fallback.
- CMakeLists.txt: drop Qt6::Test from the REQUIRED components (autotests-only,
gated on BUILD_TESTING, and Qt6Test is not built for the cross target).
Vendor libsecret 0.21.7 (org.freedesktop.secrets client lib, required by
kwalletd6's secretserviceclient.cpp) under the full-fork model; build it shared
against the static libgcrypt closure (custom template + unset COOKBOOK_DYNAMIC so
pkg-config --static pulls libgpg-error). Add it to kf6-kwallet deps.
Fixes to reach a full kwallet build:
- qca recipe: rewrite the exported Qca-qt6Targets.cmake to compute _IMPORT_PREFIX
relative to the config-file location (QCA hardcoded an absolute /usr prefix +
include dir, so cross consumers failed with 'imported target includes
non-existent path /usr/include/Qca-qt6/QtCrypto').
- ksecretd/CMakeLists.txt: gate add_subdirectory(autotests) on BUILD_TESTING
(upstream does not); the autotests need Qt6Test, unavailable for the cross
target and never shipped.
- kwalletbackend blowfish.h + sha1.cc: include <stdint.h> on __redox__ (the cross
check_include_files(stdint.h) misfired, leaving HAVE_STDINT_H unset -> uint32_t
undeclared).
- cmake/FindLibGcrypt.cmake: append libgpg-error after libgcrypt (static-only on
Redox, its gpg-error dep not pulled transitively -> undefined gpgrt_lock_*/
gpg_strerror at link).
Gpgmepp stays optional (find_package without REQUIRED, all uses HAVE_GPGMEPP-
gated); GPG-key wallets are a secondary feature. kwalletd6 + ksecretd both build.
Un-defer xwayland in config/redbear-full.toml (it is a kwin build dependency).
Getting it to build required:
- cook_build script.rs: cookbook_configure now defeats autotools maintainer-mode
regeneration. Release tarballs ship a complete build system, but extraction
timestamp skew makes make re-run the version-pinned aclocal-<N>/automake-<N>
the tarball was generated with, which the host (a different automake) lacks
('aclocal-1.NN: command not found'). Force generated files newer than their
sources (staggered mtimes) and no-op ACLOCAL/AUTOMAKE/AUTOCONF/AUTOHEADER as a
safety net. This unblocked the whole X11 autotools stack (libxcb, libx11,
libxfont2, libxkbfile, ...) with no per-recipe edits.
- xwayland recipe: meson -> custom template so it can (1) overlay the host
wayland-scanner onto the sysroot path meson resolves (the sysroot scanner is a
Redox binary, unrunnable on the build host; it is a build-time-only generator
emitting arch-independent C), and (2) unset COOKBOOK_DYNAMIC so the cross
pkg-config resolves --static, pulling the X11 libs' Requires.private closure
(xcb -> xau) — those libs are static-only on Redox (libtool has no Redox
shared support), so the closure was otherwise dropped and the link failed on
XauGetBestAuthByAddr/XauDisposeAuth.
- os/access.c: include <sys/utsname.h> on __redox__ (Redox lacks SIOCGIFCONF so
the uname()-based DefineSelf is compiled; relibc provides uname/struct utsname).
Produces a proper Redox /usr/bin/Xwayland ELF.
kf6-kwallet's ksecretd daemon (the org.freedesktop.secrets Secret Service
provider) requires Qca-qt6 2.3.1. Vendor QCA 2.3.10 under the full-fork model
and build the gcrypt provider plugin (backed by the vendored libgcrypt) so QCA
has a working SymmetricCipher/Hash/PBKDF2 backend on Redox. External-toolkit
providers (ossl/nss/botan/gnupg/pkcs11/cyrus-sasl) are disabled — those
libraries are not part of the Redox userland; logger + softstore (pure-Qt) are
kept.
Source edit: the top-level Qt6 find_package required the Test component
unconditionally; gate it on BUILD_TESTS so a tools/tests-off build configures
without Qt6Test. Install via DESTDIR since QCA anchors its install dirs to the
absolute Qt prefix (/usr), which ignores cmake --install --prefix.
Build libgpg-error + libgcrypt with --with-pic so their static archives can be
linked into the qca-gcrypt shared plugin. Add qca to kf6-kwallet deps.
kf6-kwallet's kwalletbackend hard-requires LibGcrypt 1.5.0 for PBKDF2 key
derivation and the GPG-backed wallet format. Vendor both libraries under the
full-fork model (committed source/, offline-reproducible) and add libgcrypt to
kf6-kwallet's dependencies.
Release tarballs ship a pre-generated configure and a config.sub that already
recognises the *-redox triple, so no autotools regeneration is needed at cook
time. libgpg-error supplies a generic pthread-backed gpgrt_lock_t for Redox via
its build script; the test-only redox.patch (tms/times stub) is baked into
libgcrypt's source and kept alongside for future version bumps.
Promoted from the stale recipes/wip copies (now .disabled).
kf6-kdeclarative's CMakeLists does find_package(KF6GlobalAccel REQUIRED) on
non-Windows/Apple/Android/Haiku but never declared the dependency (it was passing
by cache in earlier builds). No cycle: kf6-kglobalaccel does not depend on it.
- The upstream CMakeLists defaults BUILD_QT5=ON and calls build_Qt5() (needs Qt5,
which Redbear does not ship). Pass -DBUILD_QT5=OFF -DBUILD_QT6=ON.
- The window-decoration KCM uses kcmutils_generate_desktop_file(), a cmake macro
from kf6-kcmutils — declare that dependency.
vasilito