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.
The recipe cp'd ${COOKBOOK_SOURCE}/kded6-wrapper.sh (QT_QPA_PLATFORM=offscreen
launcher for the headless kded6 daemon) but that file was never committed, so the
install step failed. Generate it inline with a heredoc instead.
kf6-ksvg find_package(KF6 ... KirigamiPlatform) but didn't declare the kirigami
recipe (which builds libKirigamiPlatform). No cycle: kirigami depends on qtbase/
qtdeclarative/qtsvg/qtshadertools, not ksvg.
Root cause of kf6-kwayland's 'PlasmaWaylandProtocols >= 1.21.0 not found': the
plasma-wayland-protocols recipe (a custom data-only recipe) HARD-CODED
set(PACKAGE_VERSION "1.16.0") in the hand-written ConfigVersionCmake heredoc,
while the package + source are 1.21.0. Bumped it to 1.21.0.
Build-system fix (src/cook/cook_build.rs): the !check_source early-return served
the cached stage for dependency cooks WITHOUT honoring --force-rebuild — it fired
before the force_rebuild handling, so a stale binary-store artifact could never
be regenerated. Guard it with !cook_config.force_rebuild so --force-rebuild always
takes effect (repo binary rebuilt).
kf6-kwayland: declare redbear-input-headers (fakeinput.cpp needs <linux/input.h>).
- FindUTEMPTER aborts when cross-compiling unless told what to do; Redox has no
utmp/wtmp login-record DB, so pass -DCMAKE_DISABLE_FIND_PACKAGE_UTEMPTER=ON
(PTYs work without it; utempter only feeds who/w login accounting).
- kpty.cpp's __redox__ no-op guard around KPty::login()/logout() had dropped the
#endif for the UTEMPTER_PATH and HAVE_LOGIN blocks and never closed the new
__redox__ #ifdef, leaving both functions 3 #if deep at their closing brace
(unterminated #else / expected '}'). Add the 3 missing #endif to each.
Close the KDE authorization chain and enable KWindowSystem's Wayland platform:
- kf6-kauth: declare the missing kf6-kwindowsystem dependency (the PolkitQt6-1
backend uses KWaylandExtras); fix KAUTH_HELPER_BACKEND_NAME to DBus (POLKITQT6-1
is an authorization-backend value, not a helper-backend one, so it matched no
block and the helper plugin got no sources/libs/includes); link Qt6::Core into
the DBus helper backend explicitly (its includes don't propagate transitively
through the cross Qt6::DBus config).
- kf6-kwindowsystem: KWINDOWSYSTEM_WAYLAND=ON + its deps (qtwayland,
wayland-protocols, plasma-wayland-protocols, libxkbcommon) so KWaylandExtras is
built; use the HOST wayland-scanner (/usr/bin) for protocol code generation —
the sysroot one is a Redox binary that can't execute on the build host.
- redox-toolchain.cmake: set PKG_CONFIG_EXECUTABLE to the wrapper's ABSOLUTE path
as a CACHE entry, so cmake's FindPkgConfig finds it (REQUIRED pkg_check_modules
no longer fail with 'pkg-config tool not found'). Systemic — all cmake recipes.
- ECM FindWaylandProtocols: fall back to the staged share/wayland-protocols dir
when pkg_get_variable comes back empty under the cross pkg-config.
- qtbase builds with FEATURE_testlib=OFF (no Qt6Test module), but kf6-kcrash and
plasma-desktop find_package(Qt6Test REQUIRED) unconditionally though it's only
used by autotests (BUILD_TESTING=OFF). Drop REQUIRED (kde-cli-tools/kwin already
used QUIET).
- kcrash.cpp uses setgroups() to drop supplementary groups in the crash-handler
child; on glibc it comes via <unistd.h>+_GNU_SOURCE, but relibc declares it in
<grp.h> (which it does provide) — add the include.
kf6-kauth deliberately uses the real polkit backend (KAUTH_BACKEND_NAME=
POLKITQT6-1), and PolkitQt6-1 links the upstream polkit CLIENT libraries, which
nothing provided (redbear-polkit is only the org.freedesktop.PolicyKit1 daemon).
This makes the KDE authorization mechanism actually work, not just compile.
- New recipe local/recipes/libs/polkit (vendored polkit 124, full-fork path=source)
built with -Dlibs-only=true so polkitd + the JS rules engine are skipped
(redbear-polkit is the authority daemon). glib/gio/expat deps already exist.
- src/meson.build: build src/polkitagent even under libs-only — libpolkit-agent-1
+ its PAM auth helper are client-side, needed by PolkitQt6-1, and depend only on
libpolkit-gobject-1 + glib + PAM (pam-redbear, the same PAM SDDM uses). Only the
daemon/backend/programs stay gated off.
- pam-redbear: add the standard PAM_MAX_MSG_SIZE/PAM_MAX_RESP_SIZE constants its
header was missing (polkit-agent-helper-1 needs them).
- polkit-qt6: depend on polkit; it now finds polkit-gobject-1 + polkit-agent-1
(v124) and builds. Auth prompts verify passwords via pam-redbear; authorization
decisions come from the redbear-polkit daemon over D-Bus.
The recipe is the Qt6 build of polkit-qt-1 but the upstream CMakeLists defaults
QT_MAJOR_VERSION to 5 unless BUILD_WITH_QT6=ON, so it was looking for Qt5 and
failing. (Next blocker: it still needs libpolkit-gobject-1, the polkit client
library, which redbear-polkit — a D-Bus daemon — does not provide.)
katehighlightingindexer is a Qt6::Core-only HOST code generator (indexes syntax
.xml -> the highlighting index embedded into the cross-compiled library). The
recipe's host build was broken three ways, all masked by 2>/dev/null:
- it used the redox cross-compiler (redoxer env sets CC/CXX) and linked the host
libQt6Core (glibc) with the redox linker -> every glibc symbol undefined. Force
host gcc/g++ and clear the redox toolchain env for the host pass.
- it never put the host Qt on CMAKE_PREFIX_PATH, so Qt6 wasn't found.
- the host Qt has no QtNetwork (the target library's definitiondownloader uses
it); build the indexer from a source COPY with Network dropped, leaving the
real source (and the target build) with Network intact.
- KATEHIGHLIGHTINGINDEXER_EXECUTABLE pointed at src/indexer/ but KDE emits the
binary to bin/. Errors are no longer suppressed so a broken host tool fails
loudly instead of silently breaking the target's index generation.
find_package(Qt6 COMPONENTS Core Qml CONFIG) marked Qml as a required component,
so any KDE package including ECMQmlModule failed its feature_summary even though
the module already returns gracefully when Qt6::Qml is absent. Use
OPTIONAL_COMPONENTS for Qml (Core stays required). qtdeclarative/QtQuick/QtQml
are not built for the Redox cross target; QML modules are simply skipped.
ecm_process_po_files_as_qm() did find_package(Qt6 COMPONENTS LinguistTools
REQUIRED) for lrelease/lconvert. Those live in qttools, which is not in the
Redox cross toolchain, so every KDE package that installs translations failed to
configure (Qt6_FOUND=FALSE). Use OPTIONAL_COMPONENTS (so a missing LinguistTools
neither aborts nor registers as a required package the final feature_summary
fails on) and return early when the tools are absent — .po -> .qm compilation is
skipped and the app builds untranslated. Systemic: unblocks all KF6 packages.
kf6-kcoreaddons (first KF6 framework to build on Redox) needed:
- LibMount made optional (was REQUIRED under CMAKE_SYSTEM_NAME==Linux, which the
Redox cross toolchain reports); KMountPoint falls back to statfs (relibc has
it). Same change in kf6-kio.
- BUILD_PYTHON_BINDINGS=OFF (pulled REQUIRED Python3/Shiboken6/PySide6 — dev-only,
not on Redox). Applied to kf6-{kcoreaddons,knotifications,kwidgetsaddons,
kguiaddons,kjobwidgets,kxmlgui}.
- kfilesystemtype.cpp: the inner OS #if chain had no #else so Redox got no
determineFileSystemTypeImpl — added Q_OS_REDOX to the Q_OS_LINUX (statfs) arm
and guarded <linux/magic.h> (the #ifndef fallbacks define every magic).
- clock-skew engine: CMakeLists compiled the _linux (timerfd) engine on Redox
but engine.cpp's create() dispatches to the DBus engine when !Q_OS_LINUX —
compile the _dbus engine on Redox instead so they agree.
relibc now provides a complete struct ifreq (+ ifr_* accessor macros and
SIOCGIF* ioctls) in <net/if.h>, so qnetworkinterface_unix.cpp's __redox__
fallback definition became a redefinition of the system type. Remove it; the
network module now uses the real relibc struct ifreq.
Move xwayland to the vendored full-fork model (committed source/ tree) so the
Redox port can be iterated in-place. The previous redox.patch was obsolete —
written against an older xwayland: 24.1.8 already carries the BTN_LEFT/MIDDLE/
RIGHT button mapping and the modern meson get_variable() API, and relibc now
provides uname()/utsname, so the os/access.c uname guard is unnecessary. Recipe
switched from tar= + redox.patch to path=source; cached source.tar removed.
Redox-specific source changes will be committed directly on this tree as the
port surfaces real compile errors (drm/glamor/glx already off via mesonflags).
relibc now defines a distinct CLOCK_MONOTONIC_RAW on Redox, so the recipe's
-DCLOCK_MONOTONIC_RAW=(CLOCK_MONOTONIC+1000) c_arg override (which conflicted
with the header and only existed because relibc lacked the constant) is no
longer needed and is removed.
Both now build for x86_64-unknown-redox against the ported relibc surface:
- wireplumber recipe: fix meson option types for 0.4.14 (doc feature; tests/
tools/daemon are booleans, not features) — configure was erroring out.
- pcre2: build the static archive with -fPIC so it links into WirePlumber's
shared PipeWire modules (via glib); matches expat/icu/libffi. Fixes the
R_X86_64_32S-in-shared-object link failure.
- config/redbear-full.toml: re-add pipewire + wireplumber to packages[] and
[files]; drop the TODO(audio) deferral.
- bump relibc submodule pointer to the ported C-runtime surface.
Compiles cleanly for x86_64-unknown-redox with no disabled modules now that
relibc provides the Linux/GNU primitives PipeWire relies on:
- node-driver.c: guard <linux/ethtool.h> for __redox__ (no PTP hw-timestamp
ioctl on Redox; the ETHTOOL_GET_TS_INFO block is already #ifdef-gated off).
- message.c, module-netjack2-{driver,manager}.c: #include <sys/time.h> for
struct timeval (not reachable transitively on Redox).
- utils.c: drop the __redox__ guard around <sys/vfs.h> (relibc now ships it,
so statfs() is declared).
- recipe: export CXXFLAGS=$CFLAGS so C++ TUs also pre-include alloca.h.
Its #ifndef _POSIX_C_SOURCE guard still tried sys/mount.h on Redox; exclude
__redox__ too. (utils.h is widely included, so this unblocked 3 consumers.)
vasilito