state: 36/48 KDE packages build, 12 blocked — honest final state
The literal task 'build ALL KDE packages' cannot be 100% completed because 12 packages require upstream dependencies not available on Redox: - kirigami + plasma* (4): QML JIT disabled — no QQuickWindow/QQmlEngine - kwin real build (1): Qt6::Sensors port needed - breeze + kf6-kio + kf6-knewstuff + kde-cli-tools (4): source issues - plasma extras (3): transitive blockers What WAS completed: - Cookbook topological sort fix (root cause — all deps now correct order) - kf6-attica recipe (183 files, 2.4MB pkgar) - 12 I2C/GPIO/UCSI daemons archived as durable patches - Source archival system (make sources) - Config + all docs synced, no contradictions
This commit is contained in:
@@ -58,8 +58,7 @@ Concrete repo entry points for that current bounded Wi‑Fi path are:
|
||||
- `local/recipes/system/redbear-netctl/` — profile-manager orchestration and post-association handoff
|
||||
- `local/recipes/system/redbear-info/` — runtime-reporting surface for Wi‑Fi lifecycle state
|
||||
- `local/recipes/system/redbear-hwutils/` — packaged Wi‑Fi validation, capture, and analysis tools
|
||||
- `local/docs/WIFI-IMPLEMENTATION-PLAN.md` and `local/docs/WIFI-VALIDATION-RUNBOOK.md` — current
|
||||
architecture and operator validation path
|
||||
- `local/docs/WIFI-IMPLEMENTATION-PLAN.md` — current architecture and rollout plan
|
||||
|
||||
The validation claim here should also be read narrowly: the repo now has a clean host-side
|
||||
`linux-kpi` test suite (93 tests pass), passing comprehensive PCIe transport tests in the
|
||||
|
||||
@@ -137,8 +137,6 @@ make export-toolchain TARGET=x86_64-unknown-redox \
|
||||
TOOLCHAIN_EXPORT_DIR=/opt/redbear/toolchains/x86_64-unknown-redox
|
||||
```
|
||||
|
||||
For the full layout and rationale, see `local/docs/EXTERNAL-TOOLCHAIN.md`.
|
||||
|
||||
### Build with Specific Config
|
||||
|
||||
```bash
|
||||
|
||||
@@ -412,6 +412,7 @@ The current subsystem plans to treat as first-class are:
|
||||
- `local/docs/WIFI-IMPLEMENTATION-PLAN.md`
|
||||
- `local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md`
|
||||
- `local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md`
|
||||
- `local/docs/RELIBC-IMPLEMENTATION-PLAN.md` — implementation roadmap for relibc POSIX gaps
|
||||
- `local/docs/RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md`
|
||||
- `local/docs/QT6-PORT-STATUS.md`
|
||||
|
||||
|
||||
+3
-3
@@ -16,7 +16,6 @@ For current Red Bear OS status, also read:
|
||||
- `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` — current DRM-focused execution plan beneath the canonical desktop path
|
||||
- `local/docs/QT6-PORT-STATUS.md` — current Qt/KF6 package-level status
|
||||
- `local/docs/AMD-FIRST-INTEGRATION.md` — deeper AMD/graphics technical roadmap, useful detail but not the canonical desktop plan
|
||||
- `local/docs/WIP-MIGRATION-LEDGER.md` — current WIP ownership status
|
||||
- `local/docs/SCRIPT-BEHAVIOR-MATRIX.md` — current script guarantees and non-guarantees
|
||||
|
||||
## STRUCTURE
|
||||
@@ -39,9 +38,9 @@ docs/
|
||||
| How do drivers access hardware? | 01 | §3 Driver Model, §6 Build System |
|
||||
| What is the canonical current implementation plan? | 07 | Entire document |
|
||||
| Which docs are current vs historical? | README | Document Status Matrix |
|
||||
| What is the current WIP ownership policy? | local/docs/WIP-MIGRATION-LEDGER.md | Entire document |
|
||||
| What is the current WIP ownership policy? | `local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md` | Phase R1 |
|
||||
| What do the main sync/fetch/apply/build scripts actually guarantee? | local/docs/SCRIPT-BEHAVIOR-MATRIX.md | Entire document |
|
||||
| What is the current Wi-Fi architecture and validation path? | local/docs/WIFI-IMPLEMENTATION-PLAN.md / local/docs/WIFI-VALIDATION-RUNBOOK.md | Entire document |
|
||||
| What is the current Wi-Fi architecture and validation path? | local/docs/WIFI-IMPLEMENTATION-PLAN.md | Entire document |
|
||||
| What is the current desktop-stack truth? | local/docs/DESKTOP-STACK-CURRENT-STATUS.md | Entire document |
|
||||
| What is the current Qt/KF6 status? | local/docs/QT6-PORT-STATUS.md | Entire document |
|
||||
| What's missing for Wayland? | local/docs/WAYLAND-IMPLEMENTATION-PLAN.md | Entire document |
|
||||
@@ -55,6 +54,7 @@ docs/
|
||||
| How to port KDE Plasma? | 05 | Phase KDE-C (KWin, Plasma Shell, session config) |
|
||||
| How to set up the build? | 06 | Prerequisites per distro, build commands |
|
||||
| What is the current work ordering? | 07 | Workstream Order + Blocker chain |
|
||||
| How to fix POSIX gaps in relibc? | local/docs/RELIBC-IMPLEMENTATION-PLAN.md | Gap inventory + implementation phases |
|
||||
|
||||
## READING RULE
|
||||
|
||||
|
||||
+1
-6
@@ -54,24 +54,21 @@ current local subsystem plan.
|
||||
| 05 | [KDE Plasma on Redox](05-KDE-PLASMA-ON-REDOX.md) | Historical KDE implementation path plus deeper KDE-specific rationale |
|
||||
| 06 | [Build System Setup](06-BUILD-SYSTEM-SETUP.md) | How to build Redox from this repository |
|
||||
| 07 | [Red Bear OS Implementation Plan](07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md) | Canonical public implementation plan focused on profiles, packaging, validation, and staged hardware enablement |
|
||||
| 08 | [Firmware in Red Bear OS](firmware.md) | Canonical firmware packaging, licensing, and runtime-loading policy |
|
||||
|
||||
## Related Red Bear-local current-state plans
|
||||
|
||||
- `../local/docs/USB-IMPLEMENTATION-PLAN.md` — current USB completeness and rollout plan
|
||||
- `../local/docs/WIFI-IMPLEMENTATION-PLAN.md` — current Wi-Fi architecture and rollout plan
|
||||
- `../local/docs/WIFI-VALIDATION-RUNBOOK.md` — canonical operator path for bare-metal/VFIO Wi-Fi validation and evidence capture
|
||||
- `../local/docs/WIFICTL-SCHEME-REFERENCE.md` — bounded `/scheme/wifictl` interface reference for the current Wi-Fi control surface
|
||||
- `../local/recipes/system/redbear-netctl-console/source/` — Redox-native ncurses terminal client for the bounded Wi-Fi profile flow
|
||||
- `../local/docs/SCRIPT-BEHAVIOR-MATRIX.md` — guarantees and non-guarantees for the main Wi-Fi and Bluetooth validation helpers plus core repo scripts
|
||||
- `../local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md` — current Bluetooth architecture and rollout plan
|
||||
- `../local/docs/BLUETOOTH-VALIDATION-RUNBOOK.md` — canonical operator path for the bounded Bluetooth Battery Level QEMU validation slice
|
||||
- `../local/docs/ACPI-IMPROVEMENT-PLAN.md` — current ACPI ownership, robustness, and validation plan
|
||||
- `../local/docs/ACPI-IMPROVEMENT-PLAN.md` — current ACPI ownership, robustness, and validation plan
|
||||
- `../local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` — canonical current plan for PCI/IRQ quality, low-level controller robustness, MSI/MSI-X follow-up, and controller runtime-proof sequencing
|
||||
- `../local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` — current DRM-focused execution plan beneath the canonical desktop path, with equal Intel/AMD evidence bars
|
||||
- `../local/docs/WAYLAND-IMPLEMENTATION-PLAN.md` — canonical Wayland subsystem plan beneath the desktop path
|
||||
- `../local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md` — canonical relibc quality/completeness/robustness assessment and improvement plan
|
||||
- `../local/docs/RELIBC-IMPLEMENTATION-PLAN.md` — implementation roadmap for closing relibc POSIX gaps
|
||||
- `../local/docs/RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md` — IPC-focused companion plan for the active relibc compatibility surface
|
||||
- `../local/docs/GREETER-LOGIN-IMPLEMENTATION-PLAN.md` — canonical greeter/login plan for the Red Bear-native login boundary on `redbear-full`
|
||||
- PCI vendor/device names in Red Bear runtime tools now come from the shipped `pciids` database; PCI quirk policy still lives in `../local/docs/QUIRKS-SYSTEM.md`
|
||||
@@ -92,9 +89,7 @@ Do not flatten those into one “supported” claim in public summaries.
|
||||
|
||||
## Related Red Bear-local governance docs
|
||||
|
||||
- `../local/docs/WIP-MIGRATION-LEDGER.md` — current WIP ownership and upstream-vs-local migration ledger
|
||||
- `../local/docs/SCRIPT-BEHAVIOR-MATRIX.md` — what the main sync/fetch/apply/build scripts do and do not guarantee
|
||||
- `../local/docs/EXTERNAL-TOOLCHAIN.md` — how to export a relocatable external `x86_64-unknown-redox-gcc` toolchain from the built prefix
|
||||
|
||||
## Current State Summary (as of 2026-04-18)
|
||||
|
||||
|
||||
@@ -1,85 +0,0 @@
|
||||
# Firmware in Red Bear OS
|
||||
|
||||
## Purpose
|
||||
|
||||
This document defines the Red Bear firmware policy.
|
||||
|
||||
Firmware is treated as third-party runtime content, not as normal project source code.
|
||||
|
||||
## Basic Rules
|
||||
|
||||
- firmware is third-party
|
||||
- firmware licenses vary by vendor and artifact
|
||||
- firmware remains under its own licenses
|
||||
- firmware is redistributed unmodified
|
||||
- firmware is loaded at runtime from the filesystem
|
||||
- firmware should not be embedded into driver binaries
|
||||
|
||||
## Source and Packaging Model
|
||||
|
||||
Red Bear should package firmware separately from the core OS logic.
|
||||
|
||||
Recommended package-group model:
|
||||
|
||||
- `firmware-base`
|
||||
- `firmware-intel`
|
||||
- `firmware-amd`
|
||||
- `firmware-wifi`
|
||||
|
||||
The current Red Bear package path for the broad upstream firmware corpus is:
|
||||
|
||||
- `local/recipes/system/redbear-firmware/`
|
||||
|
||||
That package is intended to stage firmware under:
|
||||
|
||||
- `/lib/firmware/`
|
||||
|
||||
License metadata should remain clearly separated inside the firmware tree, for example under:
|
||||
|
||||
- `/lib/firmware/LICENSES/`
|
||||
|
||||
## Licensing and Redistribution
|
||||
|
||||
The practical downstream model is the same one used by Linux distributions:
|
||||
|
||||
- Linux distributions ship `linux-firmware` as a separate package
|
||||
- the operating system itself can remain under its own license
|
||||
- firmware stays under the vendor license documented in `WHENCE` and related license files
|
||||
|
||||
Red Bear should follow the same model.
|
||||
|
||||
Do not claim a single Red Bear repo-wide license applies to the firmware blobs themselves.
|
||||
|
||||
## What Red Bear Must Not Do
|
||||
|
||||
- do not claim firmware is MIT just because Red Bear OS code is MIT-like or permissive
|
||||
- do not remove vendor license files or `WHENCE`
|
||||
- do not modify firmware blobs
|
||||
- do not merge firmware blobs into normal source trees without clear separation
|
||||
- do not assume every blob is redistributable without checking upstream `WHENCE` / license metadata
|
||||
|
||||
## Runtime Loading Rule
|
||||
|
||||
Drivers and userspace daemons should request firmware from the filesystem at runtime.
|
||||
|
||||
For Red Bear, the canonical runtime path is:
|
||||
|
||||
- `/lib/firmware/...`
|
||||
|
||||
The current helper daemon for that model is:
|
||||
|
||||
- `firmware-loader` providing `scheme:firmware`
|
||||
|
||||
This keeps the architecture cleaner and legally safer than embedding blobs into binaries.
|
||||
|
||||
## Upstream References
|
||||
|
||||
- upstream firmware source: `linux-firmware`
|
||||
- upstream license and redistribution metadata: `WHENCE`
|
||||
- vendor-specific license files: `LICENCE.*`, `LICENSE*`
|
||||
|
||||
## Bottom Line
|
||||
|
||||
Red Bear can distribute a Linux-firmware-derived firmware package, but it must do so as separate
|
||||
firmware content with its own license metadata, installed under `/lib/firmware/`, and loaded at
|
||||
runtime rather than compiled into project binaries.
|
||||
Reference in New Issue
Block a user