vasilito
49326998a3
Round 1 of the 3D-Desktop-Implementation work. Closes audit §3.4 #1 (kirigami QtNetwork lie-grade stub) and the missing bin/ toolchain wrappers that block any meson regen of mesa-style recipes. kirigami Icon primitive network path - local/patches/kirigami/02-qnetwork-real-implementation.patch: replaces the upstream Kirigami's Icon::loadImageFromSource lie-grade 'qnam = nullptr /* Redox: networkAccessManager not available */' hardcode with a real 'qnam = new QNetworkAccessManager(this)' allocation. The parented QNetworkAccessManager is destroyed with the icon; the existing handleFinished falls through to the placeholder icon when scheme:network is unavailable, so the network path now actually works on Redox. - local/recipes/kde/kirigami/recipe.toml: wired the patch into [source].patches and added cookbook_apply_patches call. Removed the -I${COOKBOOK_SOURCE}/stubs/QtNetwork CMAKE_CXX_FLAGS entry that previously shadowed the real QtNetwork headers with the stub classes. Stub directory removal - local/recipes/kde/kirigami/source/stubs/QtNetwork/: 3 files deleted (QNetworkAccessManager returning nullptr, minimal Q_OBJECT-having QNetworkReply, forward-declared QNetworkRequest). The real QtNetwork (built via Qt6::Network in qtbase) is now used. - local/recipes/kde/sddm/stubs/: directory deleted entirely. The stubs/linux/{kd.h,vt.h} subdir was orphaned (SDDM patches wrap their use in #if !defined(__redox__) so the stubs were never compiled on Redox). After the linux/ subdir removal the stubs/ dir was empty. bin/ toolchain wrappers (required by the cookbook's [binaries] block at src/cook/script.rs:340; without these, meson --internal regenerate fails with 'x86_64-unknown-redox-gcc-ar: No such file or directory') - bin/x86_64-unknown-redox-gcc-ar - bin/x86_64-unknown-redox-gcc-ranlib - bin/x86_64-unknown-redox-g++ - bin/x86_64-unknown-redox-cpp All four are 5-line redbear-run-tool wrappers matching the pattern of the pre-existing x86_64-unknown-redox-{gcc,c++}. local/docs/3D-DESKTOP-COMPREHENSIVE-PLAN.md - §8.1 Implementation progress log added, recording this commit (Round 1) alongside the previously-committed Rounds 0-3 of the implementation work (commits0b19fddd2c,e6e4289113,86a162c803). §8.1 also documents the audit correction: the Mesa 'link never completed' is actually a mesa-config failure due to libclc.pc missing, not a link error. Recipe-level stub removal and bin/ toolchain wrappers address one blocker; libclc cook run remains the next Mesa prerequisite. Verified: PATH=.../bin:$PATH x86_64-unknown-redox-gcc-ar --version returns 'GNU ar (GNU Binutils) 2.43.1' via redbear-run-tool. No operator files (local/recipes/system/driver-manager/, the new NETWORKING-AND-DRIVERS-*-ASSESSMENT-2026-07-27.md docs, the libclc untracked source files) were touched in this commit.
local/patches/ — patch archive structure
Last updated: 2026-07-12 (Round 7) Status: Build system at 100% patch preservation. 121 active patches + 159 archived = 280 total cataloged patches.
Layout
local/patches/
├── README.md # this file
├── <comp>/ # ACTIVE patches (121)
│ ├── <fork>/ # base, kernel, relibc, ...
│ │ ├── P3-*.patch # applied by cookbook
│ │ └── redox.patch # legacy all-in-one (gitignored)
│ ├── <fork>/absorbed/ # historical snapshots
│ │ └── P3-*.patch # PATCHES BEFORE they were committed
│ │ # to fork via mega-absorption. Recoverable.
│ └── <fork>/.gitignore'd # cargo metadata etc
├── legacy-superseded-2026-07-12/ # Round 2-6 archive (97)
│ ├── README + SUPERSEDED.md # per-component audit log
│ ├── base/, kernel/, relibc/, redoxfs/, userutils/
│ └── P3-*.patch # classified-SUPERSEDED
└── legacy-absorbed-2026-07-12/ # Round 2-3 archive (62)
├── README + SUPERSEDED.md # per-component audit log
├── base/, kernel/, relibc/, userutils/
└── P3-*.patch # classified-INTEGRATED
What's an "absorbed" patch?
A patch is moved to legacy-absorbed-2026-07-12/ when Round 2-3's
supersession classifier determined that the same fix is already
committed to the fork's HEAD under a different commit subject. The
.patch file is preserved as historical documentation but is no longer
applied during build. This is operator-supersession under AGENTS.md
"Upstream-first rule for fast-moving components".
The patch's content IS in the fork. Re-applying would either:
- Be a no-op (
patch -Nfor already-applied) — safe - Cause a real conflict (if fork content has since evolved past the patch's intent) — operator decision needed
What's a "superseded" patch?
A patch is moved to legacy-superseded-2026-07-12/ when its content
is no longer needed at all — either:
- Upstream Redox's newer tag already provides equivalent functionality (canonical "upstream preferred" path)
- The fork's file structure has been rebased past the patch's expectations (file-restructured)
- The operator cleaned up the corresponding code as part of a refactor (operator-superseded)
The patch's content is NOT in the fork. Re-applying would create unintended work. Recovery: rebase fork onto newer upstream or accept the operator's refactor.
How to recover a patch
# Move patch back to active location
cp local/patches/legacy-superseded-2026-07-12/<comp>/<patch>.patch \
local/patches/<comp>/
# Optionally try applying it (will probably be a no-op for INTEGRATED,
# may fail for SUPERSEDED)
cd local/sources/<comp>
git apply --check -N -p1 < ../../local/patches/<comp>/<patch>.patch
Tooling
The patch audit tool runs as part of pre-push-checks.sh:
./local/scripts/pre-push-checks.sh
The 5 checks are: sync-versions, verify-fork-versions,
verify-patch-content, verify-collision-detection, and the collision
selftest. All must pass for the pre-push hook to allow a git push.
For a full operator-decision guide on what to do with new orphans,
see local/docs/legacy-obsolete-2026-07-25/PATCH-PRESERVATION-AUDIT-2026-07-12.md (the "Out-of-
scope" section tracks the current Round 5+6 forward work).
Round 7 snapshot
| Directory | Count | Source |
|---|---|---|
*/ (active) |
121 | operator's working fork state |
legacy-superseded-2026-07-12/ |
97 | Round 2-6 SUPERSEDED audits |
legacy-absorbed-2026-07-12/ |
62 | Round 2-3 INTEGRATED audits |
legacy-recipe-patches/ |
0 | (deleted in Round 1.2; not a separate dir anymore) |
| Total cataloged | 280 |
Notes
- Each legacy/ directory has its own SUPERSEDED.md audit log with per-component tables of what was archived, when, and why.
- The
absorbed/subdir under each active component (base/absorbed/,relibc/absorbed/) was removed in Round 3.0; its content was consolidated intolegacy-absorbed-2026-07-12/<comp>/. Theabsorbed/under each component's recipe was Round 2's experimental split. - New orphans detected by
verify-patch-content.share NOT automatically archived — that's an operator decision. Seelocal/scripts/verify-patch-content.sh --help(no current options; future work: add a--auto-archivemode).