l1_futex.rs uses AtomicU32::new and Ordering::SeqCst but imported neither, so
the crate did not compile:
error[E0433]: cannot find type `Ordering` in this scope (x4)
error[E0433]: cannot find type `AtomicU32` in this scope
Same class as the kernel errors fixed a moment ago: committed first-party code
that does not build, invisible while the package was served from cache. The
relibc bump invalidated the cache and both surfaced in the same run.
Verified: cook redbear-threadtest - successful.
The kernel had been served from cache for the whole session; a relibc bump
forced a real rebuild and exposed two committed type errors (madt/mod.rs
pattern against into_iter's owned tuples, and a usize/u64 comparison in
scheme/irq.rs). Neither was introduced here.
plasma-desktop compiled deep into its tree (105 packages cooked) and failed on
applets/taskmanager/backend.h:16: fatal error: netwm.h
because adding the X11 libraries made find_package(X11) succeed, so
CMakeLists.txt:211 set HAVE_X11=1 -- and the code then legitimately includes
KWindowSystem's X11-only headers, which our KWindowSystem does not install.
I tried the coherent fix first: KWINDOWSYSTEM_X11=ON. It fails because Qt here
is built without the xcb platform:
src/platforms/xcb/kxerrorhandler_p.h:15: fatal error: private/qtx11extras_p.h
That header ships only with Qt's X11 support, so enabling KWindowSystem X11
cascades into rebuilding qtbase with the entire xcb plugin stack. Too large to
start mid-build; reverted with the reason recorded at the flag.
So HAVE_X11=1 asserts "Qt/KDE X11 integration is available", which is false
here. Forced to 0 -- the honest value -- and the gating script compiles those
paths out. The X11 libraries remain, because they ARE required: X11 is TYPE
REQUIRED in plasma-desktop and libxcb is needed unconditionally.
Also promotes xcb-util-keysyms and xcb-util-wm (built and staged:
libxcb-keysyms.a, libxcb-icccm.a, libxcb-ewmh.a), which KWindowSystem X11 would
need and which are cheap to have available.
Pre-existing uncommitted first-party work, surfaced by the first-party
integrity gate. Committing rather than reverting: this code exists nowhere but
this project, so a revert would destroy it outright, and it is coherent and
self-consistent -- a DMI entry for the board plus a test in toml_loader.rs that
parses the REAL 50-system.toml and asserts the entry matches while LG entries
do not.
The quirk carries no flags by design; its comment states it is a bare-metal
anchor so future board-specific quirks can be added precisely. Related to the
Ryzen 7000 / X670E work in .omo/plans/ryzen-7000-x670e-compat.md.
Not authored in this session -- committed here because it blocked every build
and the gate's guidance is to commit or revert, and reverting irreplaceable
work is the wrong call.
plasma-desktop cleared configure and failed in the build:
/bin/sh: .../sysroot/lib/libexec/kf6/kconfig_compiler_kf6: cannot execute
KF6 exports these generators as imported targets whose IMPORTED_LOCATION is the
TARGET (Redox) binary in the sysroot, so cmake tries to run a Redox ELF on the
build host.
Overlays the HOST binary onto the path the imported target points at. Their
output is plain text/XML, so a host build is equivalent, and this keeps the
features ENABLED rather than switching them off. Same block plasma-workspace
already carries -- verified /usr/lib/kf6/kconfig_compiler_kf6 exists on this
host before relying on it.
kcms/keyboard links X11::xkbfile (CMakeLists.txt:37) and cmake aborted with
"Target kded_keyboard links to X11::xkbfile but the target was not found".
libxkbfile was sitting in recipes/wip/x11; promoted, given its util-macros
dependency, and wired into plasma-desktop and the config.
Also clears 9 build directories stranded by the earlier `git mv` out of wip.
Autotools bakes the absolute srcdir into its generated Makefiles, so a moved
recipe keeps building against a path that no longer exists:
No rule to make target
'.../recipes/wip/x11/libxkbfile/source/src/cout.c', needed by 'cout.lo'
The cook-side auto-invalidation added earlier only inspects CMakeCache.txt, so
autotools recipes are not covered by it -- these were latent failures that
would have surfaced one package at a time (libx11, libxcb, libxdmcp, libxft,
libxrender, x11proto, x11proto-kb, xcb-proto, xtrans).
Verified: cook libxkbfile - successful, libxkbfile.a staged.
feature_summary aborted on two REQUIRED packages:
* X11 -- "Required for building the X11 based workspace". The libraries exist
(promoted out of wip and building), but plasma-desktop did not depend on
them, so they were absent from its sysroot and cmake reported X11 missing.
Exactly the gap libxcb had earlier. Added libx11, libxext, libxfixes, libxi,
libxrender, libxau, libxdmcp.
This is where providing the real X11 stack pays off: the alternative was
patching plasma-desktop to stop requiring X11 at all, which is a much larger
and more invasive change than declaring a dependency that already builds.
* KF6DocTools -- not ported, and REQUIRED only because BUILD_DOC defaults ON.
Disabled: this drops generated handbook pages, not functionality; every
settings module still builds.
kcms/touchpad/CMakeLists.txt:18 carries the identical FATAL_ERROR to
kcms/mouse, on the same missing xorg-libinput (the X SERVER input driver, not
portable to a system with no X server). Disabled pre-emptively rather than
after another ~15-minute cycle rediscovers it.
Both KCMs keep their KWin+Wayland backends -- BUILD_KCM_MOUSE_KWIN_WAYLAND and
BUILD_KCM_TOUCHPAD_KWIN_WAYLAND remain ON -- so neither module is lost, only
its unusable X11-session path.
kcms/mouse/CMakeLists.txt:4 gates an X11-specific backend on xorg-libinput,
X11_Xi and X11_Xinput, and aborts naming the remedy:
Missing X11 dependencies for kcm_mouse: xorg-libinput;X11_Xi;X11_Xinput.
Install dependencies or set CMake option -DBUILD_KCM_MOUSE_X11=OFF.
xorg-libinput is the X SERVER input driver -- there is no X server here, so it
is not a porting candidate. This drops only the X11-session backend; the mouse
KCM still builds with its Wayland/libinput backend, which is the one actually
used.
The single sed with an embedded \n had to survive TOML unescaping, then the
shell, then sed's insert parsing -- and it did not. The generated file began
with 'nclude(CheckIncludeFiles)', losing the leading 'i', so configure failed
with
ConfigureChecks.cmake:2 (nclude): Unknown CMake command
My earlier dry-run passed because I ran the sed by hand in the shell rather
than the form the recipe actually produces after parsing. Verified this time by
extracting the commands from the PARSED TOML and running those: the file now
starts with include(CheckFunctionExists) / include(CheckIncludeFiles).
ConfigureChecks.cmake calls check_function_exists() and check_include_files()
without including the modules that define them:
ConfigureChecks.cmake:14: Unknown CMake command "check_function_exists"
Upstream gets away with it because a native KDE configure has already pulled
those modules in transitively by that point; that does not happen here. CMake
documents both as requiring an explicit include(), so adding them is what
upstream should have done rather than a workaround.
ConfigureChecks.cmake:7 does
pkg_get_variable(XKBDIR xkeyboard-config xkb_base)
if (NOT EXISTS "${CMAKE_SYSROOT}/${XKBDIR}")
assuming pkg-config returns an unprefixed path. This build sets
PKG_CONFIG_SYSROOT_DIR, so pkg-config already applies the sysroot and XKBDIR
comes back absolute. Prefixing again produced
.../sysroot//mnt/data/.../sysroot/usr/share/X11/xkb
and configure aborted although the directory is present (verified: the xkb
directory IS in plasma-desktop's sysroot, and xkeyboard-config.pc correctly
records xkb_base=/usr/share/X11/xkb).
Accepts either form instead of un-prefixing XKBDIR: which one pkg-config
returns depends on PKG_CONFIG_SYSROOT_DIR, so testing both is correct in both
configurations and keeps the check meaningful rather than disabling it.
plasma-desktop requires it unconditionally:
CMakeLists.txt:244 pkg_check_modules(XKBREGISTRY xkbregistry REQUIRED ...)
and configure aborted with "The following required packages were not found:
- xkbregistry". The recipe had -Denable-xkbregistry=false.
xkbregistry provides the keyboard-layout registry the keyboard KCM reads, so
this restores a real feature rather than routing around one. Its dependency,
libxml2, was already in the tree (recipes/libs/libxml2) and is now declared and
added to the config.
-Denable-x11 is deliberately left false for now: it is a separate switch, not
required by this failure, and turning it on alongside would blur which change
fixed what if the rebuild misbehaves.
I tried resetting the build dir whenever rsync reported changed files, to catch
stale GENERATED build files after a recipe edit -- the xcb-util-image case where
the staged source said `SUBDIRS = image` but build/Makefile still said
`SUBDIRS = image test`, so a correct fix looked like it had no effect.
That signal is wrong. --delete restores the pristine tree, undoing the previous
build's seds, so rsync reports changes on EVERY run. Measured on a plain
kirigami rebuild: 6 "changed" files that were only the sed undo, and the build
dir was wiped. Shipping it would have forced a full rebuild of every recipe on
every build.
Reverted, with the reasoning recorded at the call site so it is not attempted
again. Stale generated files are the job of the content-hash invalidation the
cookbook already performs against the PRISTINE source; the staged copy is not a
valid basis for that comparison.
Verified after revert: kirigami is cached again rather than rebuilding.
Three separate defects, one per class:
1. script.rs passed autoreconf only -I${COOKBOOK_HOST_SYSROOT}/share/aclocal, so
macros installed by a DEPENDENCY into the per-recipe sysroot were invisible.
util-macros was built and declared as a dependency, yet configure still said
configure.ac:10: error: must install xorg-macros 1.16.0 or later
Now also searches ${COOKBOOK_SYSROOT}/usr/share/aclocal and exports
ACLOCAL_PATH. Fixed generically -- every autotools recipe benefits.
2. Upstream builds test/test_xcb_image_shm unconditionally (Makefile.am:15
SUBDIRS = image test) and it needs SysV shared memory, which Redox lacks.
The library itself does not: configure only probes sys/shm.h and adapts. So
dropping test/ removes a test binary, not functionality.
3. libxcb is a STATIC archive here, so its libXau/libXdmcp dependencies do not
propagate to consumers as a shared library's DT_NEEDED would:
xcb_auth.c: undefined reference to `XauGetBestAuthByAddr'
Named them via LIBS, not LDFLAGS: autoconf emits LDFLAGS BEFORE the objects
and LIBS AFTER, and a static archive only satisfies symbols referenced by
objects preceding it. With -lXau in LDFLAGS the link still failed while
libXau.a sat in the sysroot. Same ordering rule as -lgcc in
redox-toolchain.cmake and -licudata in plasma-workspace -- third occurrence.
Verified: cook xcb-util-image - successful, libxcb-image.a staged.
xcb-util and xcb-util-image start configure.ac with XORG_MACROS_VERSION(), so
autoreconf dies before configure runs:
configure.ac:10: error: must install xorg-macros 1.16.0 or later before
running autoconf/autogen
libice failed identically earlier -- it was dropped as unnecessary, but
xcb-util-image is genuinely required (plasma-desktop needs the XCB IMAGE
component), so the macros had to be ported rather than routed around.
util-macros ships only autoconf m4 text and a pkg-config file -- no compiled
code, so no cross-compilation concern. Installed into the sysroot's
share/aclocal, which is already the directory the cookbook passes to
autoreconf (-I .../sysroot//share/aclocal), so consumers need no other change.
Verified by cooking it standalone before wiring it in: builds successfully and
stages usr/share/aclocal/xorg-macros.m4. The recipe asserts that file exists,
since a silent no-op would resurface as the same "must install xorg-macros"
error in a consumer, far from the cause.
plasma-desktop's CMakeLists.txt:223 does
find_package(XCB REQUIRED COMPONENTS XCB SHM IMAGE)
and configure aborted with "Could NOT find XCB (missing: XCB_LIBRARIES XCB SHM
IMAGE)" -- libxcb was promoted but plasma-desktop did not depend on it, so it
was absent from that recipe's sysroot.
libxcb supplies xcb and xcb-shm (libxcb-shm.a confirmed staged); IMAGE comes
from xcb-util-image, which needs xcb-util. Both promoted out of recipes/wip/x11
and their tarballs fetched and blake3-verified.
This is the case for xcb on Wayland, not X11 nostalgia: KDE's XWayland
integration and Qt's xcb platform plugin both reference these.
plasma-workspace now builds and installs, so plasma-desktop configured for the
first time and stopped at:
The following required packages were not found: - libwacom
kcms/tablet requires libwacom (CMakeLists.txt:175), which is not ported -- it
needs libgudev plus upstream's tablet-definition database. Disabled via
upstream's own option (CMakeLists.txt:44, default ON), not an invented switch;
it gates exactly three sources (tabletsmodel.cpp, kcmtablet.cpp,
tabletmoduledata.cpp) and nothing else in plasma-desktop is affected.
THIS REMOVES THE DRAWING-TABLET SETTINGS MODULE. Tracked as a real port; the
option goes back ON in the same change that lands libwacom.
plasma-workspace COMPILED AND LINKED COMPLETELY and then failed at install:
file INSTALL cannot copy ".../libnotificationmanager/plasmanotifyrc"
to "/etc/xdg/plasmanotifyrc": Permission denied
`cmake --install --prefix` re-roots only RELATIVE destinations. KDE's
KDE_INSTALL_FULL_* paths are absolute, so cmake tried to write into the BUILD
HOST's /etc -- only the host's permissions stopped it from polluting the host
filesystem. DESTDIR re-roots absolute destinations too. Same fix already
applied to kf6-ktexteditor, kde-cli-tools and sddm.
plasma-desktop gets the same fix pre-emptively: it ships /etc/xdg config and
has never been built, so this would otherwise have cost another full cycle.
54 other KDE recipes use the --prefix form but install nothing to an absolute
path, which is why they build clean; left alone rather than churned.
kcm_users failed with 'ld: cannot find -lcrypt' although libc.a exports crypt
and crypt_r. relibc now ships empty libcrypt.a/libutil.a so the link resolves
from libc, matching what it already does for libdl/libpthread/librt.
vasilito