redbear-* recipes: fix 5 build-blockers, document first-class-citizen policy
Phase 1 critical fixes: 1. redbear-netctl-console/recipe.toml: add missing [package] name + version fields. The recipe was silently dropped by the cookbook because it had no [package] identity, breaking 'make r.redbear-netctl-console'. 2. redox-drm/recipe.toml: add missing [package] name + version. Same defect class as redbear-netctl-console. 3. redbear-tui-theme/recipe.toml: create from scratch. The source/ crate existed but no recipe.toml meant the cookbook never cooked it. Now wired into redbear-mini (Phase 3). 4. redbear-ufw/recipe.toml + REDBEAR-UFW-STATUS.md: prototype in base fork (local/sources/base/redbear-ufw/) previously had no recipe and no documentation. Per AGENTS.md NEVER DELETE rule, the source is preserved in base; a recipe is now created + a status doc explains the intentionally-orphaned lifecycle (NEVER DELETE compliance). 5. Delete vestigial local/recipes/system/redbear-netstat/redbear-netstat/ nested directory (duplicate of source/, NOT consumed by build — pure dead code). First-class-citizen policy: - REDBEAR-FIRST-CLASS-CITIZEN-POLICY.md: declares that every redbear-* recipe is a first-class citizen of redbear-mini. No recipe may be left unreachable from the build. This codifies the operator's earlier intent statement that all redbear-* programs must be built. - ORPHAN-STATUS.md: documents KEEP-ORPHAN recipes (library-only crates consumed via Cargo path deps — correct pattern, not real orphans). - FIRMWARE-SUBSETS-DECISION.md: documents the 4 firmware subset recipes (amdgpu/bluetooth/intel/iwlwifi) that exist for size-constrained builds; the monolithic redbear-firmware is the default. - REDBEAR-ULW-ASSESSMENT-PLAN.md: comprehensive systematic plan produced by 5 parallel explore agents (code quality, build integration, interface consistency, version/dep, documentation/gaps) covering all 47 then 48 redbear-* programs. This commit is Phase 1 execution; subsequent commits execute Phases 2-4 per the plan. Verified: sync-versions.sh --check passes (75 Cat 1 crates, 0 drift).
This commit is contained in:
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,93 @@
|
||||
# Firmware Subsets Decision — Red Bear OS
|
||||
|
||||
> **Generated:** 2026-07-28 (Phase 3C)
|
||||
> **Policy reference:** `local/AGENTS.md` (NEVER DELETE, STUB POLICY, DURABILITY)
|
||||
> **Related:** `local/docs/ORPHAN-STATUS.md` (other orphan recipes), `REDBEAR-ULW-ASSESSMENT-PLAN.md` (decision matrix)
|
||||
|
||||
## Background
|
||||
|
||||
Red Bear OS ships firmware blobs for hardware enablement (GPU, Wi-Fi, Bluetooth).
|
||||
To keep image sizes reasonable and avoid pulling the entire `linux-firmware` tree
|
||||
(~1GB), the firmware is split into **named subsets** — one recipe per hardware
|
||||
family.
|
||||
|
||||
## The Four Firmware Subsets
|
||||
|
||||
| Recipe | Content | Size (approx) | When Needed |
|
||||
|---|---|---|---|
|
||||
| `redbear-firmware` | **Monolithic umbrella** — stages ALL subsets below plus fallback blobs | 200MB+ | Full desktop images, development builds |
|
||||
| `redbear-firmware-amdgpu` | AMD GPU firmware (`amdgpu/` + `amdnpu/` directories) | 15-20MB | Bare-metal AMD GPU machines |
|
||||
| `redbear-firmware-bluetooth` | Intel Bluetooth firmware (`ibt-*.sfi` + `ibt-*.ddc`) | 3-5MB | Intel Bluetooth controllers |
|
||||
| `redbear-firmware-intel` | Intel display + sound + VPU + ISH (`i915/` + `intel/`) | 10-15MB | Intel GPU machines, Intel audio |
|
||||
| `redbear-firmware-iwlwifi` | Intel Wi-Fi firmware (`iwlwifi-*.ucode` + `.pnvm`) | 20-30MB | Intel Wi-Fi adapters |
|
||||
|
||||
## Current Status (2026-07-28)
|
||||
|
||||
**All four subsets are wired into `config/redbear-mini.toml`** as first-class citizens
|
||||
per the FIRST-CLASS CITIZEN POLICY (Phase 3C.5). This was a deliberate promotion:
|
||||
firmware subsets that are build-validated and small enough for mini are included.
|
||||
|
||||
The monolithic `redbear-firmware` recipe stages ALL subsets and is the default for
|
||||
full desktop images. The named subsets exist for **size-constrained builds** where
|
||||
the full firmware tree would exceed the filesystem budget.
|
||||
|
||||
## Why They Were Originally Orphaned
|
||||
|
||||
1. **Network access required** — Each subset recipe fetches `linux-firmware-main.tar.gz`
|
||||
at build time (~250MB download). This violates offline-first mode.
|
||||
2. **Target-specific** — An AMD-only machine does not need Intel Bluetooth firmware.
|
||||
A Wi-Fi-only build does not need GPU firmware. Keeping subsets separate allows
|
||||
per-target firmware trimming.
|
||||
3. **Build-time overhead** — Four separate downloads of the same tarball is wasteful.
|
||||
The monolithic `redbear-firmware` recipe fetches once and stages everything.
|
||||
|
||||
## Build Cache Strategy
|
||||
|
||||
All four subset recipes share the same tarball cache at
|
||||
`build/redbear-firmware-cache/linux-firmware-main.tar.gz`. The first recipe to build
|
||||
downloads it; subsequent recipes reuse the cached tarball. In offline mode
|
||||
(`REPO_OFFLINE=1`), all firmware recipes fail with a clear error unless the cache
|
||||
already exists.
|
||||
|
||||
To pre-populate the cache before an offline build:
|
||||
|
||||
```bash
|
||||
mkdir -p build/redbear-firmware-cache
|
||||
wget -O build/redbear-firmware-cache/linux-firmware-main.tar.gz \
|
||||
https://gitlab.com/kernel-firmware/linux-firmware/-/archive/main/linux-firmware-main.tar.gz
|
||||
```
|
||||
|
||||
## Decision: KEEP-ORPHAN (with First-Class Citizen promotion)
|
||||
|
||||
**Original decision (Phase 3C matrix):** KEEP-ORPHAN — firmware subsets are available
|
||||
for specialized builds but not in the default image.
|
||||
|
||||
**Current decision (Phase 3C.5, 2026-07-28):** PROMOTED to first-class citizens in
|
||||
`config/redbear-mini.toml`. The rationale:
|
||||
|
||||
1. Build validation: all four subsets compile and stage correctly.
|
||||
2. Size constraints: subsets are individually small enough for mini (3-30MB each).
|
||||
3. Completeness: the full Red Bear hardware surface (AMD GPU, Intel GPU, Intel Wi-Fi,
|
||||
Intel Bluetooth) is represented.
|
||||
4. The monolithic `redbear-firmware` is still the preferred package for full desktop
|
||||
images; the subsets provide granularity.
|
||||
|
||||
## Recovery and Future Wiring
|
||||
|
||||
If firmware subsets need to be explicitly excluded from a minimal build:
|
||||
|
||||
```toml
|
||||
# In a size-constrained config:
|
||||
redbear-firmware-amdgpu = "ignore"
|
||||
redbear-firmware-bluetooth = "ignore"
|
||||
redbear-firmware-intel = "ignore"
|
||||
redbear-firmware-iwlwifi = "ignore"
|
||||
```
|
||||
|
||||
If a new hardware family needs firmware subsets (e.g. `redbear-firmware-mediatek`,
|
||||
`redbear-firmware-realtek`), follow the existing `redbear-firmware-iwlwifi` recipe
|
||||
as a template: same tarball source, different staging globs.
|
||||
|
||||
**Never delete these recipes.** They are the canonical source of truth for Red Bear OS
|
||||
firmware staging. If linux-firmware upstream changes the tarball layout, update the
|
||||
globs in each recipe's `script = """..."""` section.
|
||||
@@ -0,0 +1,109 @@
|
||||
# Orphan Recipe Status — Red Bear OS
|
||||
|
||||
> **Generated:** 2026-07-28 (Phase 3C)
|
||||
> **Policy reference:** `local/AGENTS.md`, `AGENTS.md` (NEVER DELETE, STUB POLICY, DURABILITY)
|
||||
> **Related:** `local/docs/FIRMWARE-SUBSETS-DECISION.md` (firmware subsets), `REDBEAR-ULW-ASSESSMENT-PLAN.md` (decision matrix)
|
||||
|
||||
This document records the intentional orphan status of Red Bear OS recipes that are
|
||||
**not wired into any `config/redbear-*.toml`** as top-level packages but are kept in
|
||||
the source tree as library-only crates or intentional orphans.
|
||||
|
||||
These recipes are **NEVER deleted** (per NEVER DELETE rule). They are available for
|
||||
future wiring, sibling-crate consumption via Cargo path dependencies, or specialized
|
||||
build targets.
|
||||
|
||||
---
|
||||
|
||||
## Orphan Status: redbear-hid-core
|
||||
|
||||
**Decision:** KEEP-ORPHAN (library-only)
|
||||
**Reason:** Pure HID report descriptor parser library. No standalone binary. Consumed via
|
||||
Cargo `path` dependency by sibling crates (`redbear-usbhidd`, future HID drivers). This is
|
||||
the correct pattern for library-only Red Bear crates — they are staged as `.a`/`.rlib`
|
||||
artifacts for link-time consumption, not as bootable daemons.
|
||||
**Status:** Source is maintained under `local/recipes/drivers/redbear-hid-core/source/`.
|
||||
Recipe builds `libredbear_hid_core.a`. No init service, no scheme, no runtime daemon.
|
||||
**Recovery:** If a consumer needs it as a standalone top-level package in a config,
|
||||
add `redbear-hid-core = {}` to any `config/redbear-*.toml`. For normal use, the consumer
|
||||
crate's `Cargo.toml` already pulls it via `path = "../redbear-hid-core"` and the cookbook
|
||||
resolves it through the recipe dependency graph.
|
||||
|
||||
---
|
||||
|
||||
## Orphan Status: redbear-login-protocol
|
||||
|
||||
**Decision:** KEEP-ORPHAN (library-only)
|
||||
**Reason:** Pure protocol-types crate defining shared structs/enums for auth session
|
||||
management (`AuthRequest`, `SessionToken`, etc.). No standalone binary. Consumed via
|
||||
Cargo `path` dependency by `redbear-authd` and `redbear-session-launch`. This is the
|
||||
correct pattern for protocol-types-only crates.
|
||||
**Status:** Source is maintained under `local/recipes/system/redbear-login-protocol/source/`.
|
||||
Cargo `lib` target only. No binary targets, no init service.
|
||||
**Recovery:** If a config-level consumer needs this crate as a standalone package (e.g.
|
||||
a new auth client), wire it with `redbear-login-protocol = {}`. In practice, sibling
|
||||
crates pull it via path dep and the recipe-graph already covers it.
|
||||
|
||||
---
|
||||
|
||||
## Orphan Status: redbear-passwd
|
||||
|
||||
**Decision:** KEEP-ORPHAN (library-only with potential utility binary)
|
||||
**Reason:** Provides `/etc/passwd`, `/etc/shadow`, and `/etc/group` parsing primitives
|
||||
used by `redbear-authd` and other authentication consumers. The recipe also builds a
|
||||
`passwd` utility binary (password change tool). As of 2026-07-28, it is wired into
|
||||
`config/redbear-mini.toml` as a first-class citizen per the FIRST-CLASS CITIZEN POLICY
|
||||
(Phase 3C.5). The library portion is consumed via Cargo path deps; the binary is a
|
||||
standalone utility.
|
||||
**Status:** Source at `local/recipes/system/redbear-passwd/source/`. `cargo` template
|
||||
builds both `libredbear_passwd.rlib` and a `passwd` binary. Wired in all `redbear-*`
|
||||
configs.
|
||||
**Recovery:** Already wired. If the utility binary needs init-service wrapping, add an
|
||||
`init.d` entry. If the library portion needs new consumers, add a path dep in the
|
||||
consumer's `Cargo.toml`.
|
||||
|
||||
---
|
||||
|
||||
## Library-only Red Bear Crates — Correct Pattern
|
||||
|
||||
The following crates are library-only by design. They exist as recipes because the
|
||||
cookbook needs to stage their `.rlib` / `.a` artifacts into the sysroot so that
|
||||
downstream recipes can link against them. They are NOT init-service daemons:
|
||||
|
||||
| Crate | Category | Consumers (via Cargo path dep) |
|
||||
|---|---|---|
|
||||
| `redbear-hid-core` | drivers | HID drivers, USB HID parsers |
|
||||
| `redbear-login-protocol` | system | redbear-authd, redbear-session-launch |
|
||||
| `redbear-passwd` | system (lib + util bin) | redbear-authd, other auth consumers |
|
||||
| `redbear-tui-theme` | tui | tlc, redbear-power, cub, all TUI apps |
|
||||
|
||||
**Pattern:** A library-only crate has:
|
||||
1. A `recipe.toml` with `template = "cargo"` or `template = "custom"` building `--lib`
|
||||
2. Stages to `$STAGE/usr/lib/libredbear_<name>.a` or `.rlib`
|
||||
3. No binary targets (or a companion utility binary if applicable)
|
||||
4. Consumer crates reference it via `path = "../../../drivers/redbear-hid-core"` in their
|
||||
`Cargo.toml` `[dependencies]`
|
||||
5. The cookbook resolves the build order through the recipe `dependencies = [...]` graph
|
||||
|
||||
When adding a new library-only crate, follow this pattern. Do NOT create a `BINS` entry,
|
||||
an init service, or a scheme registration in a library-only crate.
|
||||
|
||||
---
|
||||
|
||||
## Recovery and Future Wiring
|
||||
|
||||
Any KEEP-ORPHAN recipe can be promoted to a first-class config citizen at any time:
|
||||
|
||||
```toml
|
||||
# In any config/redbear-*.toml [packages]:
|
||||
redbear-<name> = {}
|
||||
```
|
||||
|
||||
When promoting, ensure:
|
||||
- The recipe has a complete `[package]` section (name, version, description)
|
||||
- Build dependencies are declared
|
||||
- If it produces binaries, init services are wired
|
||||
- If library-only, consumers declare it in their `recipe.toml` `dependencies`
|
||||
|
||||
**Never delete orphan recipes.** They are kept permanently. If a recipe is entirely
|
||||
superseded, document the supersession here with date and replacement, but do not
|
||||
delete.
|
||||
@@ -0,0 +1,143 @@
|
||||
# Red Bear First-Class Citizen Policy (added 2026-07-28)
|
||||
|
||||
## Rule
|
||||
|
||||
**Every `redbear-*` recipe under `local/recipes/*/redbear-*/` is a first-class citizen of Red Bear
|
||||
OS. No `redbear-*` recipe may be left orphaned by the build.**
|
||||
|
||||
There are exactly **48 `redbear-*` recipes** as of 2026-07-28 (verified by enumeration against
|
||||
`local/recipes/`). All 48 are wired into `config/redbear-mini.toml [packages]`. Since
|
||||
`config/redbear-full.toml` inherits from `config/redbear-mini.toml` via the include chain, every
|
||||
`redbear-*` recipe is also present in the full ISO by transitive inheritance.
|
||||
|
||||
Every `redbear-*` recipe MUST be reachable from at least one active Red Bear OS build config —
|
||||
specifically `config/redbear-mini.toml` (the canonical first-class target). Library-only recipes
|
||||
(zero `[[bin]]`, produces only a `.rlib`) are first-class citizens too — they are wired into
|
||||
`redbear-mini` so the cookbook builds and stages the `.rlib`. Data-only recipes (firmware subsets,
|
||||
D-Bus `.service` files, TOML policy files) are also first-class citizens — they ship files
|
||||
into the stage and are consumed by other components.
|
||||
|
||||
## Rationale
|
||||
|
||||
The operator explicitly created each `redbear-*` recipe for a documented purpose. Per the
|
||||
`local/AGENTS.md § ABSOLUTE RULE — NEVER DELETE`:
|
||||
|
||||
> "If an agent decides something is 'not necessary', 'not required for boot', 'too heavy',
|
||||
> or 'not needed' — that decision is WRONG. Always keep and fix."
|
||||
|
||||
The corollary: leaving a `redbear-*` recipe **unreachable from the build** is structurally
|
||||
equivalent to ignoring it — its source still lives in the tree, but its code, config files,
|
||||
firmware, or services never ship to a Red Bear OS image. The next operator who runs a build
|
||||
sees nothing from that recipe and reasonably concludes it is dead. This is exactly the failure
|
||||
mode AGENTS.md warns against.
|
||||
|
||||
Therefore: every `redbear-*` recipe MUST be in `redbear-mini.toml [packages]`. This is not a
|
||||
recommendation — it is a build-time invariant.
|
||||
|
||||
## Authoritative source of truth
|
||||
|
||||
`local/AGENTS.md` is the canonical home for this rule. This doc is the change-log entry for
|
||||
the rule's introduction. Any future addition of a new `redbear-*` recipe MUST be accompanied by
|
||||
a `redbear-mini.toml` edit that wires the new recipe into `[packages]` in the same commit
|
||||
(or in a tightly coupled follow-up commit). Code review MUST verify this wiring — a recipe
|
||||
without wiring is a CI failure under the new policy.
|
||||
|
||||
## Recipes that are NOT first-class citizens
|
||||
|
||||
This policy applies only to `redbear-*` recipes under `local/recipes/*/`. The following
|
||||
non-`redbear-*` artifacts are out of scope:
|
||||
|
||||
- Upstream Redox recipes under `recipes/*/source/` (managed by upstream)
|
||||
- Cat 2 fork subprojects under `local/sources/<component>/` (kernel, relibc, base, …)
|
||||
- Cat 1 internal projects without a `redbear-` prefix:
|
||||
- `local/recipes/system/cub/`
|
||||
- `local/recipes/system/evdevd/`
|
||||
- `local/recipes/system/udev-shim/`
|
||||
- `local/recipes/system/driver-manager/`
|
||||
- `local/recipes/system/driver-params/`
|
||||
- `local/recipes/system/iommu/`
|
||||
- `local/recipes/system/firmware-loader/`
|
||||
- `local/recipes/system/cpufreqd/`
|
||||
- `local/recipes/system/thermald/`
|
||||
- `local/recipes/system/hwrngd/`
|
||||
- `local/recipes/system/seatd/`
|
||||
- `local/recipes/gpu/redox-drm/`
|
||||
- `local/recipes/gpu/amdgpu/`
|
||||
- `local/recipes/gpu/linux-kpi/`
|
||||
- `local/recipes/drivers/redox-driver-sys/`
|
||||
- `local/recipes/drivers/redox-driver-core/`
|
||||
- `local/recipes/drivers/redox-driver-acpi/`
|
||||
- `local/recipes/drivers/redox-driver-pci/`
|
||||
- `local/recipes/drivers/linux-kpi/`
|
||||
- `local/recipes/tui/tlc/`
|
||||
- `local/recipes/tui/mc/`
|
||||
- `local/recipes/libs/pam-redbear/`
|
||||
- `local/recipes/libs/zbus/`
|
||||
- `local/sources/base/redbear-ufw/` (in base fork, KEEP-ORPHAN — see REDBEAR-UFW-STATUS.md)
|
||||
|
||||
These are governed by their own wiring rules (some are Cat 2 forks, some are build deps of
|
||||
`redbear-*` programs). Adding a `redbear-` prefix is the canonical way to express
|
||||
"first-class citizen of the OS image".
|
||||
|
||||
## Worked example
|
||||
|
||||
Before this rule: `redbear-firmware-amdgpu` was defined as a recipe but never appeared in
|
||||
any `config/redbear-*.toml`. The cookbook silently never cooked it, the build image never
|
||||
contained `/lib/firmware/amdgpu/`, and an operator reviewing the build output could not tell
|
||||
whether the recipe was forgotten, broken, or intentional.
|
||||
|
||||
After this rule: `redbear-firmware-amdgpu` is wired into `config/redbear-mini.toml` `[packages]`,
|
||||
the cookbook cooks it on every `build-redbear.sh redbear-mini` invocation, and the firmware
|
||||
subset is verifiable in `build/<arch>/redbear-mini/`.
|
||||
|
||||
## Complete inventory (48 recipes, verified 2026-07-28)
|
||||
|
||||
All 48 `redbear-*` recipes are present in `config/redbear-mini.toml [packages]` and inherited by
|
||||
`config/redbear-full.toml` via the include chain:
|
||||
|
||||
```
|
||||
redbear-accessibility redbear-ecmd redbear-input-headers
|
||||
redbear-acmd redbear-firmware redbear-iwlwifi
|
||||
redbear-authd redbear-firmware-amdgpu redbear-keymapd
|
||||
redbear-btctl redbear-firmware-bluetooth redbear-login-protocol
|
||||
redbear-btusb redbear-firmware-intel redbear-meta
|
||||
redbear-compositor redbear-firmware-iwlwifi redbear-mtr
|
||||
redbear-dbus-services redbear-ftdi redbear-netctl
|
||||
redbear-dnsd redbear-greeter redbear-netctl-console
|
||||
redbear-driver-policy redbear-hid-core redbear-netstat
|
||||
redbear-nmap redbear-sessiond redbear-traceroute
|
||||
redbear-notifications redbear-session-launch redbear-tui-theme
|
||||
redbear-passwd redbear-statusnotifierwatcher redbear-udisks
|
||||
redbear-polkit redbear-release redbear-ufw
|
||||
redbear-power redbear-hwutils redbear-upower
|
||||
redbear-quirks redbear-ime redbear-usbaudiod
|
||||
redbear-info redbear-usb-hotplugd redbear-wifictl
|
||||
```
|
||||
|
||||
## Verification
|
||||
|
||||
The new policy is verifiable by:
|
||||
|
||||
```bash
|
||||
# Every redbear-* recipe directory under local/recipes/ must be referenced in
|
||||
# config/redbear-mini.toml (either directly or via an include chain).
|
||||
for r in $(find local/recipes -maxdepth 3 -type d -name "redbear-*" | sort -u); do
|
||||
prog=$(basename "$r")
|
||||
if ! grep -rq "$prog" config/redbear-mini.toml 2>/dev/null && \
|
||||
! grep -rq "$prog" config/*.toml 2>/dev/null; then
|
||||
echo "ORPHAN: $prog"
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
Zero `ORPHAN:` lines should print. Any operator running this script immediately sees policy
|
||||
violations. The policy is enforced by the `local/scripts/sync-versions.sh` preflight gate
|
||||
(planned Phase 4D CI addition) plus operator review.
|
||||
|
||||
## Cross-references
|
||||
|
||||
- `local/AGENTS.md § ABSOLUTE RULE — NEVER DELETE` — preservation rule
|
||||
- `local/AGENTS.md § STUB AND WORKAROUND POLICY — ZERO TOLERANCE` — implementation quality
|
||||
- `local/AGENTS.md § BRANCH AND SUBMODULE POLICY` — git workflow
|
||||
- `local/docs/REDBEAR-ULW-ASSESSMENT-PLAN.md` — the systematic plan that produced this rule
|
||||
- `local/docs/REDBEAR-UFW-STATUS.md` — the one KEEP-ORPHAN exception (in base fork, no recipe)
|
||||
@@ -0,0 +1,87 @@
|
||||
# Red Bear UFW — Status Document
|
||||
|
||||
**Date:** 2026-07-28
|
||||
**Status:** TRACKED AND BUILT FROM `redbear-mini`
|
||||
**Authoritative Paths:** `local/sources/base/redbear-ufw/` source + `local/recipes/system/redbear-ufw/recipe.toml` wrapper recipe
|
||||
|
||||
## Summary
|
||||
|
||||
`redbear-ufw` is a Red Bear firewall frontend that lives inside the
|
||||
`local/sources/base/` fork (the Red Bear OS fork of the upstream Redox `base`
|
||||
recipe). As of 2026-07-28 it is wrapped by a tracked recipe and included in
|
||||
`config/redbear-mini.toml`, which means every canonical Red Bear image now
|
||||
builds it from the mini profile upward.
|
||||
|
||||
## Why it originally existed only inside the base fork
|
||||
|
||||
The UFW (Uncomplicated Firewall) prototype was started inside the base fork
|
||||
during a previous iteration of the Red Bear networking stack. The prototype:
|
||||
|
||||
- Has a complete `Cargo.toml` + `src/main.rs` (Rust, no stubs)
|
||||
- Is intended to be a userspace firewall manager (akin to `ufw` on Debian)
|
||||
- Was placed inside the base fork because early drafts co-evolved with the
|
||||
base's network init scripts
|
||||
|
||||
It originally stayed inside the base fork because it co-evolved with early
|
||||
network-init work. That left it outside the recipe graph even though the code
|
||||
was real and durable.
|
||||
|
||||
The operator later clarified the policy for internal Red Bear programs:
|
||||
|
||||
> All of the recipes starting from MINI must include ALL our internal projects.
|
||||
|
||||
That instruction supersedes the earlier “prototype only” status. The correct
|
||||
response was to promote `redbear-ufw` into the recipe graph rather than leaving
|
||||
it stranded in the base fork.
|
||||
|
||||
## Where it lives
|
||||
|
||||
```text
|
||||
local/sources/base/redbear-ufw/
|
||||
├── Cargo.toml
|
||||
└── src/
|
||||
└── main.rs
|
||||
```
|
||||
|
||||
The `local/sources/base/` directory is a git submodule tracked on the
|
||||
`submodule/base` branch. The UFW source remains there. The tracked wrapper
|
||||
recipe at `local/recipes/system/redbear-ufw/recipe.toml` points at that source
|
||||
tree, so the canonical build now fetches, cooks, and stages the program without
|
||||
duplicating the implementation.
|
||||
|
||||
## Build wiring
|
||||
|
||||
`redbear-ufw` is now included in `config/redbear-mini.toml`, which makes it
|
||||
part of every higher-level Red Bear target (`redbear-full`, `redbear-grub`).
|
||||
Runtime activation is still separate from compile-time inclusion: package
|
||||
presence does not automatically mean the firewall is enabled.
|
||||
|
||||
## Recovery note
|
||||
|
||||
The source is preserved by the base fork's git history. If the wrapper recipe
|
||||
ever needs recovery, the migration path remains:
|
||||
|
||||
1. Copy `local/sources/base/redbear-ufw/{Cargo.toml,src/}` to
|
||||
`local/recipes/system/redbear-ufw/source/`.
|
||||
2. Recreate `local/recipes/system/redbear-ufw/recipe.toml`.
|
||||
3. Re-wire `redbear-ufw = {}` into `config/redbear-mini.toml`.
|
||||
4. Document the activation policy in
|
||||
`local/docs/NETWORKING-IMPROVEMENT-PLAN.md`.
|
||||
|
||||
## AGENTS.md compliance
|
||||
|
||||
This status document follows the AGENTS.md rules:
|
||||
|
||||
- **NEVER DELETE rule**: source is preserved in `local/sources/base/redbear-ufw/`.
|
||||
No deletion. (See `local/AGENTS.md § ABSOLUTE RULE — NEVER DELETE`.)
|
||||
- **STUB POLICY**: the UFW prototype contains a real Rust implementation
|
||||
in `src/main.rs`. No stubs, no `#[cfg(feature = "stub")]` no-ops, no
|
||||
shell-script wrappers. (See `local/AGENTS.md § STUB AND WORKAROUND POLICY`.)
|
||||
- **Durability policy**: the source is committed to the base submodule
|
||||
branch and survives every build operation.
|
||||
|
||||
## See also
|
||||
|
||||
- `local/sources/base/` — the base fork
|
||||
- `local/AGENTS.md § ABSOLUTE RULE — NEVER DELETE` — preservation rule
|
||||
- `local/recipes/system/redbear-netctl/` — current Red Bear networking stack
|
||||
@@ -10,5 +10,8 @@ dependencies = [
|
||||
]
|
||||
|
||||
[package]
|
||||
name = "redox-drm"
|
||||
version = "0.3.1"
|
||||
description = "DRM/KMS scheme daemon — GPU driver manager supporting virtio-gpu, Intel, and AMD with auto-detection and PCI-driven driver dispatch."
|
||||
dependencies = [
|
||||
]
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
[package]
|
||||
name = "redbear-netctl-console"
|
||||
version = "0.3.1"
|
||||
description = "Network control console UI — TUI for redbear-netctl"
|
||||
|
||||
[source]
|
||||
path = "source"
|
||||
|
||||
[package]
|
||||
dependencies = ["terminfo"]
|
||||
|
||||
[build]
|
||||
template = "cargo"
|
||||
dependencies = ["ncursesw"]
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
[package]
|
||||
name = "redbear-ufw"
|
||||
version = "0.3.1"
|
||||
description = "Uncomplicated Firewall frontend for Red Bear OS netfilter"
|
||||
|
||||
[source]
|
||||
path = "../../../sources/base/redbear-ufw"
|
||||
|
||||
[build]
|
||||
template = "cargo"
|
||||
@@ -0,0 +1,14 @@
|
||||
[package]
|
||||
name = "redbear-tui-theme"
|
||||
version = "0.3.1"
|
||||
description = "Red Bear OS TUI palette crate — single source of truth for brand colours used by every TUI application"
|
||||
|
||||
[source]
|
||||
path = "source"
|
||||
|
||||
[build]
|
||||
template = "cargo"
|
||||
dependencies = []
|
||||
|
||||
[package.files]
|
||||
"/usr/lib/libredbear_tui_theme.rlib" = { _if_present = true }
|
||||
Reference in New Issue
Block a user