These three carried only `path = "source"` with no origin recorded anywhere, so
nothing could distinguish them from Red Bear's own code and the first-party
integrity gate classified them as ours. URLs and versions taken from evidence
in each source tree, not guessed:
libepoxy github.com/anholt/libepoxy meson version 1.5.10
libxcvt gitlab.freedesktop.org/xorg/lib/libxcvt meson version 0.1.3
libdisplay-info gitlab.freedesktop.org/emersion/... meson version 0.4.0
NOT applied to libpciaccess or libudev, which were named alongside these as
upstream. Their source trees are 2 files / 272 lines and 3 files / 1314 lines
respectively -- these are Red Bear's own minimal implementations of those APIs,
not vendored copies of the upstream projects, which are far larger. Recording a
fake upstream for them would downgrade the gate from fatal to a warning on
first-party code, which is the one error direction that loses work that exists
nowhere else. Flagged for confirmation rather than assumed.
libcanberra: plasma-workspace calls find_package(Canberra) TYPE REQUIRED and
includes <canberra.h> from four translation units with no HAVE_CANBERRA guard,
one of them libnotificationmanager (the core notification library). It cannot
be made optional, so it is ported for real. Built shared: it dlopens its
backend through libltdl, the libtool recipe stages libltdl.so only (no .a), so
a static build left every consumer with an undefined lt_dlopenext.
Audio is SILENT. Upstream 0.30 offers alsa/oss/pulse/gstreamer/null and none
speak Redox; the pulse driver needs PulseAudio's client library, which PipeWire
does not provide. The null driver is real upstream code, so the API/ABI is
genuine and all consumers work -- but nothing reaches the speakers until a
native /scheme/audio driver exists.
KX11Extras et al: gate the five X11-only KWindowSystem headers behind the
HAVE_X11 that plasma-workspace already defines. X11 is compiled OUT, not added.
gate-kx11extras.py brace-matches each block and keeps any trailing else outside
the guard, since wrapping a whole if/else-if chain yields invalid C++.
check-recipe-escapes.py: a single backslash in a TOML multi-line string is a
TOML escape, so a sed written as \bFoo\b parses to <BS>Foo<BS> and silently
matches nothing -- no TOML error, no sed error. This class bit the tree three
times. Now gated in preflight; it also found openssh, which used an invalid \$
and could not be parsed by any compliant parser.
cook_build.rs: build git-tracked vendored sources OUT OF TREE. Recipe scripts
rewrite their source, so builds were mutating version-controlled files: a
no-op sed became indistinguishable from a working one, and the integrity gate
fired so often that clearing it stopped being protective. Uses
cp -a --reflink=auto, not cp -al: sed -i is link-safe but `cp -f` and `>`
truncate in place and would write through a hard link into the tracked
original. Content hashing still runs against the pristine tree, so hashes now
describe committed state. Escape hatch: REDBEAR_IN_TREE_BUILD=1.
Unblocks plasma-workspace/plasma-desktop, which required 14 packages that had
no in-tree recipe. Sources are reproducible from each recipe's tar= + blake3;
the vendored source/ trees are deliberately not committed here (212M).
New recipes:
KF6 6.28.0 kf6-kholidays, kf6-krunner, kf6-kstatusnotifieritem,
kf6-kunitconversion
Plasma 6.7.2 knighttime, layer-shell-qt, libkscreen, libksysguard,
plasma-activities-stats, plasma5support, kscreenlocker
Qt 6.11.1 qtpositioning, qtspeech, qttools
libksysguard carries P0-redox-process-backend.patch: processes_local_p.cpp
dispatches on platform macros and had no __redox__ arm, so ProcessesLocal was
entirely undefined. Adds a real backend reading /scheme/proc/ps (pid, ppid,
real+effective ids, thread count, state) and /scheme/sys/mem, with kill() for
signals. Upstream's generic fallback is a pure stub and was not used. Absent
facilities (no setpriority/sched_setscheduler/ioprio on a microkernel) report
NotSupported rather than pretending.
Restored, no longer disabled:
- night colour: kcms/nighttime + kwin's nightlight plugin, now that
KNightTime/Qt6Positioning/KF6Holidays exist
- KIO FileWidgets (file dialog, places model), wrongly swept in with the
unportable kiod/kssld/kioworkers subdirs
- kf6-ktexteditor text-to-speech: removes a disguised stub that rewrote
speechEngine() to return nullptr and mangled call sites into invalid C++
- kwin KWIN_BUILD_SCREENLOCKER=ON (needs kscreenlocker; see below)
Toolchain and recipe fixes:
- redox-toolchain.cmake: append -lgcc. __extendhfsf2/__extendbfsf2 are
global in libgcc.a but hidden in libgcc_s.so (the Redox libgcc version map
stops at GCC_7.0.0 and never emits the GCC_12/13 nodes upstream exports),
and GCC omits -lgcc for -shared, so no C++23 shared library using
std::format<_Float16|bfloat16_t> could link.
- qtmultimedia: rewrite /usr/src/.../meta_types paths and stage metatypes,
so consumers using qt_internal_add_qml_module can configure.
- qtspeech: qtmultimedia is mandatory, not optional -- upstream return()s
with only a NOTICE without it, yielding a green build over an empty
package. Asserts its own output so that cannot recur.
- narrow Linux-only guards with AND NOT REDOX where the toolchain sets
CMAKE_SYSTEM_NAME=Linux purely to get UNIX=TRUE (kio LibMount,
libksysguard NL/Sensors, plasma-workspace NetworkManagerQt).
- drop REQUIRED components that are declared but referenced nowhere
(Location, QCoro6, Qt6 Test) -- verified by exhaustive grep.
- DESTDIR installs where KDE emits absolute KDE_INSTALL_FULL_* paths that
--prefix cannot re-root, which otherwise write into the build host.
Auth stack:
- pam-redbear: add PAM_MODULE_UNKNOWN (28), missing from both the header and
lib.rs; realign 30/31 to Linux-PAM's PAM_CONV_AGAIN/PAM_INCOMPLETE, which
previously held Red Bear-only names on standard values, so anything built
against stock PAM headers mis-decoded them.
- redbear-authd: support yescrypt ($y$ -- the default shadow format on
current Debian/Ubuntu/Fedora, previously an unexplained login failure),
bcrypt and md5-crypt. Plaintext shadow entries now require the
/etc/redbear/allow-plaintext-passwords sentinel and warn on every use,
instead of being compared silently. 19/19 host tests pass.
Build-system hardening:
- verify-tracked-sources.sh, wired into preflight: fails on deletion of any
tracked vendored source, and on modifications with no baseline entry.
local/sources/ had a dirty gate and version checks; local/recipes/*/source/
had none, which allowed an rm -rf to delete 7958 tracked files and a
pristine re-extract to silently overwrite committed fixes (kwin's
std::expected/vulkan-hpp and X11 gating, kio's Q_OS_REDOX resolver guards).
- validate-source-trees.py: resolve recipe.toml through the overlay symlink;
it reported false MISSING for symlinked recipes.
- test-sddm-virgl-qemu.sh: the null-proxy check used report(), which PASSES
on regex match -- so the known Qt6 Wayland null+8 fault would report PASS
when present. Added report_absent().
kscreenlocker builds only its cmake-level Wayland-only changes so far; the
C++ X11 removal (61 call sites) is not yet applied, so kwin's screenlocker
flag is blocked on it.
The recipe was not building libdisplay-info. It synthesized its own
meson.build declaring `version: '0.2.3'` and compiled a hand-written
stub: one di.c and four headers, 518 lines, 20 exported functions.
0.2.3 does not exist upstream -- the tags are 0.1.0, 0.1.1, 0.2.0, 0.3.0
and 0.4.0. That fabricated version satisfied kwin's
pkg_check_modules(libdisplayinfo REQUIRED IMPORTED_TARGET libdisplay-info>=0.2.0)
so kwin configured cleanly and then failed to compile utils/edid.cpp on
di_info_get_default_color_primaries, di_info_get_hdr_static_metadata,
di_info_get_supported_signal_colorimetry and di_edid_display_descriptor.
A version gate satisfied by a declaration rather than an implementation.
Now vendors upstream 0.4.0 (gitlab.freedesktop.org/emersion/libdisplay-info):
14 C files, 10898 lines, 10 headers, 94 exported symbols. 0.4.0 rather than
0.2.0 because the colorimetry and HDR static metadata accessors kwin needs
post-date the 0.2.x series -- and they feed the real colour-primaries and
HDR path of the display stack, so a stub returning NULL would have been
wrong at runtime even if it had compiled.
Red Bear delta is one hunk in source/meson.build: the unconditional
subdir('di-edid-decode') and subdir('test') are commented out. Both build
auxiliary executables and a shell test harness that are not part of the
runtime and do not cross-compile for Redox. Library, headers and
pkg-config are untouched.
Verified: builds clean, stages libdisplay-info.so.0.4.0 with all four
symbols kwin needs, pkg-config reports 0.4.0, and kwin's utils/edid.cpp
now compiles.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Continues the previous kwin commit; all found by compiling further.
vulkan-hpp (VULKAN_HPP_RAII_NO_EXCEPTIONS, now active because GCC 16's
libstdc++ provides __cpp_lib_expected at C++23):
- vulkan_device.cpp getQueue() returns CreateReturnType<Queue>, an
expected, not a Queue -- unwrapped via splitResult().
- CommandBuffer::begin/end, bindImageMemory2, importSemaphoreFdKHR and
Queue::submit return void, not vk::Result. They route their Result
through detail::resultCheck -> VULKAN_HPP_ASSERT_ON_RESULT, which this
build defines to `void`, so the status is discarded by configuration.
Assigning them to vk::Result no longer compiles. Noted at each site;
the eErrorDeviceLost branch after Queue::submit is now unreachable.
- mapMemory() returns void* and needed wrapping.
- QueryPool::getResults already returns a decomposable std::pair, so
splitResult() had double-wrapped it; unwrapped.
X11 gating -- KWIN_BUILD_X11=OFF is set correctly by the recipe, but
several includes sit outside the guard their own uses are inside:
- workspace.cpp included syncalarmx11filter.h unguarded (both uses and
the workspace.h member are guarded).
- shadow.h declared readX11ShadowProperty(xcb_window_t) unguarded while
shadow.cpp guards the definition.
- effecthandler.h declared unique_ptr<WindowPropertyNotifyX11Filter>
unguarded; with X11 off the type is only forward-declared and
~unique_ptr needs it complete.
Missing includes, same shape as earlier findings -- the declaration exists,
it just never reaches the compiler:
- tabletmodemanager.cpp and backends/libinput/device.cpp call udev_device_*
without including <libudev.h>, which upstream gets transitively through
libinput.h. Ours does not pull it in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
qtbase configured with QT_FEATURE_xkbcommon=OFF because libxkbcommon was
never staged into its sysroot -- the recipe existed but nothing depended
on it. With the feature off, qtbase does not install
QtGui/private/qxkbcommon_p.h (src/gui/CMakeLists.txt:1095 is conditional
on it), so kwin's inputmethod.cpp failed with
inputmethod.cpp:51: fatal error: private/qxkbcommon_p.h: No such file
kwin also includes <xkbcommon/xkbcommon-keysyms.h> directly while
declaring no such dependency, relying on it arriving transitively; that
is now explicit.
Another latent gap rather than GCC 16 fallout -- it only surfaced once
kwin compiled far enough to reach this include.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vulkan-hpp switches every vk::raii create/enumerate/get return from the
decomposable vk::ResultValue to VULKAN_HPP_EXPECTED once
VULKAN_HPP_NO_EXCEPTIONS is set (kwin does, src/CMakeLists.txt) and the
standard library provides __cpp_lib_expected at C++23. GCC 16's libstdc++
has it and GCC 13's did not, so the toolchain upgrade silently changed the
API shape under kwin 6.7.2 and 20 call sites stopped compiling with
"cannot decompose class type 'std::expected<...>'".
There is no ResultValue path left to fall back to: vulkan_raii.hpp with
NO_EXCEPTIONS but no expected emits calls to throwResultException, which
NO_EXCEPTIONS compiles out. Declining the switch is not available.
So splitResult() (src/vulkan/vulkan_result_compat.h) restores the
(result, value) pair those sites are written against, and each site is
wrapped mechanically. The surrounding control flow stays exactly as
upstream wrote it rather than being rewritten around a different idiom.
Not every such call is still fallible in this header revision, so the
helper also passes plain payloads through paired with eSuccess.
Separately, two X11-only includes were never guarded, and only showed up
now because no xcb headers are staged for Redox:
- effect/effecthandler.cpp included window_property_notify_x11_filter.h
unguarded while every *use* of that type sits inside #if KWIN_BUILD_X11,
and x11window.h two lines below is guarded. A plain upstream oversight.
- screenedge.h included <xcb/xcb.h> while referencing no xcb_* type at all.
Both now use KWIN_BUILD_X11, matching the file's own idiom.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The recipe lists 02-qnetwork-real-implementation.patch, but the symlink
into the recipe directory was absent, so fetch failed outright:
repo: failed to fetch: Failed to find patch file
"recipes/kde/kirigami/02-qnetwork-real-implementation.patch"
The patch itself was never lost -- it is in local/patches/kirigami/ and
its content is already applied in the vendored source (icon.cpp carries
the QNetworkAccessManager work). Only the link was missing, because
recipes/**/*.patch is gitignored and this one was never force-added, so a
clean checkout could not resolve it.
Force-added, as done for the other patch symlinks this session. Swept the
rest of local/recipes for the same defect: no others.
kirigami cooks clean. The vendored source tree (493 tracked files) was
left untouched, per local/AGENTS.md LOCAL RECIPE SOURCE IMMUTABILITY.
gcc13 was still being built despite gcc-native/rust-native being
deferred, and it failed the whole build: binutils-native pulled it
transitively. It is the same dependency pattern already removed from
gcc-native -- what the recipe actually needs is a cross compiler, and
that comes from the prefix toolchain on PATH
(x86_64-unknown-redox-gcc, now 16.1.0), not from a cooked gcc13 package.
Keeping it meant building GCC 13 with GCC 16, which does not work: the
host link fails with the libstdc++ 128-bit float helpers unresolved
(__eqtf2/__getf2/__gttf2/__letf2/__unordtf2 against
/usr/lib/gcc/x86_64-pc-linux-gnu/16/libstdc++.so), a host/target libgcc
leak, and beyond that GCC 16 ICEs on GCC 13's libsupc++. See
local/docs/NATIVE-TOOLCHAIN-WORKSTREAM.md.
binutils-native cooks clean without it.
Follows the recipe's [source] move from same_as gcc13 to
path = "../gcc16/source". The old symlink pointed at
recipes/dev/gcc13/source and survived the recipe edit, which is why the
first GCC 16 build attempt was still compiling GCC 13 sources.
libiberty compiles getopt1.c against GCC's include/getopt.h, which
declares the GNU-internal _getopt_internal. relibc ships a getopt.h that
does not declare it and was shadowing GCC's:
getopt1.c:71: error: implicit declaration of function
'_getopt_internal'
Same shape as the cpuid.h shadowing already handled in recipes/dev/gcc13.
Verified: _getopt_internal errors 5 -> 0.
STILL FAILING, on a new and different phase: the HOST libstdc++ headers
are being pulled into the build --
/usr/include/c++/16/x86_64-pc-linux-gnu/bits/os_defines.h:44:
error: missing binary operator before token '('
which is __GLIBC_PREREQ evaluated where there is no glibc. That is a
host/target header leak, not a continuation of the getopt problem, and it
is unrelated to this commit's change.
Two corrections.
relibc dependency restored. Dropping gcc13 from gcc-native's deps also
removed what transitively staged relibc's headers, leaving the sysroot
with no libc headers at all -- no fenv.h, so libstdc++'s <cfenv> failed
with 'fenv_t has not been declared in ::'.
That corrects my earlier diagnosis: relibc's fenv.h is NOT a stub. It
delegates to openlibm_fenv.h, which dispatches on __x86_64__ to
openlibm_fenv_amd64.h where fenv_t and fexcept_t are both defined, and
relibc stages all of those headers. The header was simply never reaching
this recipe's sysroot. The previous commit message asserting a relibc
fenv gap was wrong.
relibc gitlink bumped for the fnmatch commit, which adds the GNU
FNM_FILE_NAME and FNM_LEADING_DIR that GCC 16's libiberty needs.
Repointed [source] from the gcc13 recipe to the Redox-ported GCC 16 tree
(local/recipes/dev/gcc16/source, upstream 16.1.0 + gcc-redox-port), which
is what produced the working cross toolchain in prefix/.
Building GCC 13 with the GCC 16 cross compiler was not a supported
configuration and each fix only revealed the next incompatibility -- a
C++11 pin for libcody, GCC 13's cpuid.h shadowing the toolchain's after
GCC 15/16 removed the withdrawn AVX512PF/ER/4VNNIW/4FMAPS and PREFETCHWT1
macros, and finally an ICE in gimple_build_eh_must_not_throw compiling
libsupc++. All three are gone on GCC 16: ICE 0, char8_t 0, cpuid 0.
Also fixed here:
- The stale same_as symlink (source -> recipes/dev/gcc13/source) survived
the recipe edit and kept feeding GCC 13 sources to the build. Removed.
- gcc13/gcc13.cxx dropped from dependencies: they build the compiler this
recipe no longer uses. The cross compiler comes from the prefix on PATH.
- Exempted from the tree-wide -std=gnu17 pin. That pin exists for the
C17-era recipes, but GCC 16's own sources are C23 and use `bool` as a
keyword: gcc/config/i386/i386.h:1722: unknown type name 'bool'.
- [package].version set explicitly -- same_as used to supply it, and a
path source leaves the cookbook nothing to infer from.
- Version-globbed the hardcoded 13.2.0 libgcc copy paths.
BLOCKED on a genuine relibc gap. libstdc++'s <cfenv> does
using ::fenv_t; using ::fexcept_t;
but relibc's fenv.h is a 3-line stub defining neither, so
libstdc++-v3/include/fenv.h fails. fenv.h is a C99/POSIX header owed
fenv_t, fexcept_t, the FE_* macros and the fe* functions. Implementing it
in the relibc fork is the fix -- per LOCAL-FORK-SUPREMACY-POLICY.md Rule 2
the fork must be complete -- and is real work, not a flag.
version = "0.2.189" -> "0.2.189+rb0.3.2", per local/AGENTS.md
"Version conventions": every Cat 2 fork is <upstream>+rb<branch>. The
label is what makes the fork traceable to both its upstream base and the
Red Bear branch it was built for.
+rb is build metadata, which semver ignores when matching, so ^0.2
requirements still resolve to the fork -- confirmed, the rust lockfile now
reads libc v0.2.189+rb0.3.2 from the path source. A -rb suffix would be
read as a pre-release and would NOT satisfy them, which is exactly why the
project mandates +rb.
Two things this surfaced:
- fork-upstream-map: libc moved from snapshot to diverged. The fork is
vendored from the crates.io PACKAGE, whose file set differs from the
upstream git tag by construction (no .github/, adds
.cargo_vcs_info.json), so a tag content-diff reported differences that
mean nothing -- 'missing files that exist in upstream' for files the
package never ships. diverged states the real relationship.
- local/recipes/dev/gcc16/.vendored-upstream added. Extracting GCC 16.1.0
put upstream's vendored Rust crates under local/recipes/*/source/, so
sync-versions.sh treated datafrog/log/polonius-engine as Cat 1 in-house
crates and wanted to stamp them 0.3.2. The marker is the documented
escape hatch (BUILD-SYSTEM.md section 7).
Both gates clean: verify-fork-versions reports no violations,
sync-versions --check reports no gcc16 drift.
rustc_llvm compiles llvm-wrapper/*.cpp, which include
"llvm/Config/llvm-config.h". Those headers ship in the .dev package, and
rust-native listed only llvm-native and llvm-native.runtime, so the build
failed with
LLVMWrapper.h:6:10: fatal error: llvm/Config/llvm-config.h:
No such file or directory
even though the header was staged at
llvm-native/target/<triple>/stage.dev/usr/include/. recipes/dev/rust
declares the equivalent llvm21.dev for the same reason.
Latent because rust-native was commented out of the config and had never
been built.
Three defects that were latent until GCC 14+ made implicit declarations
and pointer-type mismatches errors. None was a missing implementation --
in every case the code existed and only the declaration was wrong.
libinput
Carried its own bundled libudev.h that shadowed the real one from the
libudev recipe, which it already declares as a dependency. The bundled
copy lacked udev_device_get_sysattr_value(), so udev/libinput-device-
group.c got an implicit declaration and then an int-to-pointer
assignment. The real header is a strict superset -- nothing is declared
in the bundled copy that the real one lacks -- so the bundled file is
dead code that shadows a real implementation, which
LOCAL-FORK-SUPREMACY-POLICY.md Rule 4 requires removing.
linux-kpi
ieee80211_register_rx_handler() is fully implemented in
src/rust_impl/mac80211.rs as #[no_mangle] extern "C", and
ieee80211_rx_drain()'s own doc comment refers to it, but it was never
declared in c_headers/net/mac80211.h. Declared it.
redbear-iwlwifi
- rb_iwlwifi_bridge_register_rx() is used ~1800 lines before its
definition with no forward declaration. Added one at file scope.
- bridge_rx_callback was declared here as taking void *hw, while its
Rust definition in src/bridge/callback.rs takes *mut Ieee80211Hw and
linux-kpi's RxCallback type expects struct ieee80211_hw *. The C
declaration was simply wrong; corrected to match the implementation.
All three cook clean.
Three GCC 16 gaps found by the redbear-full build.
-fhardened (seatd and other meson recipes, 24 errors)
-fhardened is a host-glibc hardening bundle x86_64-unknown-redox cannot
implement, but GCC accepts it on the command line, so meson's
cc.has_argument('-fhardened') probe answers YES and meson adds it to
every compile. GCC then refuses it for real:
cc1: error: '-fhardened' not supported for this target [-Werror]
Note the tag is [-Werror], not [-Werror=hardened] -- it is an
unconditional warning, so -Wno-hardened does not silence it (tried, and
it did not). The flag has to be cancelled instead; -fno-hardened does
that cleanly and the cookbook's flags are appended after the project's
own, so it wins. Nothing is weakened: the compiler is telling us the
option is inert on this target.
termcap (two independent defects, both latent until now)
1. Makefile.in hardcoded 'CFLAGS = -g' and has no @CFLAGS@ substitution
at all, so nothing configure resolved ever reached the compiler --
including the toolchain's default C dialect. termcap is pre-ANSI
code, so being compiled as GCC 16's default C23 failed at once with
'too many arguments to function malloc; expected 0, have 1'.
Substituting @CFLAGS@ is what a normal autotools Makefile.in does.
2. With CFLAGS flowing, the remaining errors were implicit declarations
of strlen/memcpy/exit/write, which GCC 14+ makes errors regardless of
-std. Cause: autoconf 2.70+ removed AC_HEADER_STDC, so STDC_HEADERS
is never defined and termcap.c/tparam.c took their pre-ANSI branch,
declaring 'char *malloc ();' instead of including <stdlib.h>.
Autoconf's guidance on dropping AC_HEADER_STDC is to assume those
headers exist, which holds for every target Red Bear builds.
pam-redbear
Cargo.lock missed by the earlier sweep; regenerated for the 0.3.2 fork
versions.
termcap and seatd now cook clean.
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.
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.
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.
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.
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.
vasilito