Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity

task 27: pipeline census from the live API; kernel guard is host-probed config, not credentials

Browse source
This commit is contained in:
Fimeg 2026-07-25 16:25:09 -04:00
commit 81196d1ab9
1 changed files with 90 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

103
docs/tasks/27-gitea-pipeline-audit.md
View file

@ -1,6 +1,6 @@
# TASK 27 — Gitea pipeline audit
**Status:** scoped 2026-07-25, not started. Findings below are measured, not
**Status:** audited 2026-07-25 against the live Gitea API. Findings below are measured, not
assumed. **Size:** one session for the audit itself; the fixes are separate.
The goal is the one Casey stated: everything built in `~/Projects` ships as a
@ -28,26 +28,75 @@ neither is on the device.
Deciding what owns the overlay — a `blueline-rootfs` package, or per-component
packages that each own their own units — is the first real decision here.
## Pipeline census, measured from the Gitea API 2026-07-25
61 repos on `gitea.wiuf.net` (= `10.10.20.120:4455`; same box, three URL forms
in use — `ssh://…:2222`, `https://gitea.wiuf.net`, `http://<token>@10.10.20.120:4455`).
Four of them carry a `.gitea/workflows/`. One produces a package.
| repo | runs | green | publishes |
|---|---|---|---|
| `souveraine` | 48 | yes, #44–48 | signed pacman repo → `edge` release |
| `culver` | 15 | **never until 07-25** | nothing — CI has no packaging step |
| `Pixel3Arch` | 11 | **never** | nothing |
| `linux-blueline`, `pocketboot`, `souveraine-player`, `stevia`, `tuie`, `profile-engine`, … | — | no CI | nothing |
The Gitea **package registry is empty** of Arch packages — two `redflag`
containers from June, nothing else. Distribution is entirely release assets on
`souveraine`'s rolling `edge` tag, which is why the registry is not the thing
to audit.
`Pixel3Arch/pkgs/` holds **15 PKGBUILDs** — hyprgrass, stevia, squeekboard,
q6voiced, tqftpserv, usb-signaller, pulseaudio-q6, hexagonrpc, paru, pachub and
more. Not one is built by CI. Every one is hand-built on archdev and hand-carried
per `pkgs/README.md`. Installed that way they are pacman-*owned* but frozen:
`-Syu` has no repo to upgrade them from, so ownership records the version
without ever advancing it.
**The runner is a single host-mode `gitea-runner.service` user unit on archdev**
(PID 132, `Linger=yes`, `enabled` — that part is sound). Host mode means every
job mutates one shared box. That is precisely how the poisoned sysroot in
finding 6 happened, and nothing isolates the next one.
## Findings, measured 2026-07-25
1. **There is no `primary` branch.** `souveraine`'s `ci.yml` triggers on
`[primary, public]`; `git ls-remote` shows only `main`, `public`,
1. **There is no `primary` branch on `souveraine`.** `ci.yml` triggers on
`[primary, public]`; the API shows only `main`, `public`,
`experimental/session-trust-phase1`, `archive/main-mit-0.1.0`. So half the
trigger is dead and **`public` is the de facto release branch** — confirmed
by the phone's installed `souveraine 0.1.r218.g91c0cf800bf6` matching
`public`'s head exactly. Either create `primary` or drop it from the
trigger; a branch name in CI that does not exist is a trap.
trigger is dead and **`public` is the de facto release branch**. Worse, the
working branch `experimental/session-trust-phase1` is **not in the trigger
list at all** — a push there runs no CI and publishes nothing, silently.
`main` is the repo's *default* branch and has not moved since 2026-05-22, so
a fresh clone gets two-month-old code. Either create `primary` or drop it;
and point `main` at what actually ships. (`culver` is consistent by
contrast: default `primary`, CI triggers on `primary`.)
2. **`kernel.yml` has never once passed.** 11 runs, 11 failures, none since
Jul 14. `kernel-latest` is a 404. Blockers, in order (three from TASK-25,
the fourth found by Casey 2026-07-25):
- the last credential fix (`9c51f3f`) was never re-run and may already work
Jul 14 — eleven days with nobody retrying. `kernel-latest` is a 404.
The **actual** failure in the last run (#11, job 1790) is not a credential
problem at all — the credential fixes worked and the build got as far as
`olddefconfig`, which then tripped the drift guard at `kernel/PKGBUILD:53`:
```
-CONFIG_RUST_IS_AVAILABLE=y
-# CONFIG_RUST is not set
ERROR: olddefconfig changed kernel/config-blueline.aarch64
```
The guard is right to exist and wrong as written: `CONFIG_RUST_IS_AVAILABLE`
is derived from *the build host's* rustc, not from our intent. Baking a
host-probed symbol into a canonical config makes the check fail whenever the
runner's toolchain differs from whoever last regenerated it. Fix by stripping
host-probed symbols before the diff, not by chasing the config.
Remaining blockers behind it, unchanged:
- `pkgver` is static `7.1.1`, so `-Syu` can never see an upgrade
- a bare `.g<sha>` sorts as hex and is **non-monotonic** — use
`7.1.1.r<count>.g<sha>`
- `kernel/config-blueline.aarch64` had been moved to `archive/` while
`kernel/PKGBUILD:53` still copies it from `$startdir` — breaks the build
outright. Restored.
- `kernel/config-blueline.aarch64` was moved to `archive/` while
`PKGBUILD:53` still copies it from `$startdir`. **Restored and verified
present 2026-07-25**; a stale duplicate remains at
`archive/kernel/config-blueline.aarch64` and should go.
3. **The `edge` release clobbers other producers.** `ci.yml` deletes and
recreates the release and tag, uploading only its own `pacman-repo` after
@ -67,6 +116,19 @@ packages that each own their own units — is the first real decision here.
carrying co-author trailers. Fixing means a history rewrite. Casey's call,
still pending.
5b. **`culver` had been red for every one of its 13 runs since 2026-07-19**, and
the whole blockage was accumulated clippy lint: one `redundant_closure`, then
four more plus a `field_reassign_with_default`. None were real defects — but
because `-D warnings` fails the job at the first crate, each fix only reveals
the next, and nobody had walked the chain. Fixed 2026-07-25 (`1e3ea12`,
`b28b15f`); the fallbacks now say `DateTime::UNIX_EPOCH`, which is what the
surrounding comments claimed all along while the code carried a dead
`Utc::now()` branch.
The structural point outlasts the fix: **culver's CI has no packaging step.**
It runs test, clippy and build, then stops. Green culver still ships nothing.
Same for any repo whose CI ends at `cargo build`.
6. **Build-host integrity is unaudited, and it lies.** The archdev aarch64
sysroot was half-updated: extracting packages unprivileged silently skips
every file that already exists root-owned, so `hyprland.pc` read
@ -78,6 +140,21 @@ packages that each own their own units — is the first real decision here.
every cross build. A signed package built from a poisoned sysroot is still
a broken package — signing proves origin, not correctness.
7. **The update path only exists at home.** The phone's repo is
`Server = http://10.10.20.120:4455/Fimeg/souveraine/releases/download/edge`
— a LAN address over plain HTTP, reached through a `XferCommand` wrapper that
feeds a token from `/etc/pacman.d/souveraine-gitea.netrc` because pacman will
not forward credentials in a Server URL. Package signatures make HTTP
acceptable for integrity; they do not make the host reachable. Off the LAN,
`pacman -Syu` simply fails. A daily-driver phone that can only update in one
building is a constraint worth naming now rather than discovering on a trip.
8. **Published ≠ installed, and nothing closes the loop.** `edge` currently
carries `souveraine 0.1.r220.g9d8bce2a08cd` for both arches, signed, with a
valid db. The phone is on `r219`. Nothing pulls, notifies, or reports the
drift — the last mile is a human remembering. That is TASK-28's subject and
it starts here, not at the packaging.
## Acceptance
- Every repo in `~/Projects` that ships anything to the phone has a CI job