Build all five G15 packages and add native Gitea push CI

packaging/NOTES.md

@@ -9,7 +9,7 @@ API keys or `.env` are needed. Build scripts install packages and require a
 disposable root container; do not run them in the hardware-enabled devcontainer.
 `G15_BUILD_IMAGE` optionally changes the shared image tag.
 
-`run.sh` builds `packaging/Dockerfile`, mounts only Git metadata, the four
+`run.sh` builds `packaging/Dockerfile`, mounts only Git metadata, the five
 submodules and `packaging/` read-only, then runs build and lifecycle tests.
 A second fresh container mounts only artifacts and `rebuild.sh`, proving that
 the source packages do not need this repository. All working sources are in
@@ -19,12 +19,12 @@ allowlisted mount layout. No container receives USB, uinput or a Docker socket.
 
 ## Sources, patches and versions
 
-Order: `libg15`, `libg15render`, `g15daemon`, `g15macro`. Each stage installs
+Order: `libg15`, `libg15render`, `g15daemon`, `g15macro`, `g15stats`. Each stage installs
 its own runtime and development packages before the next stage resolves build
 dependencies. The base image does not supply distro G15 development packages.
-Each of these four build submodules must match its indexed gitlink and be clean.
-The additional `g15stats` submodule is not built, packaged or recorded in package
-provenance. Git
+Each of these five build submodules must match its indexed gitlink and be clean.
+Stats uses its committed modern Debian packaging without an outer overlay;
+the image includes its `libgtop2-dev` build dependency. Git
 archives export immutable HEADs, not working-tree contents. No checkout,
 patching, committing, ref updates or pushing occurs in submodules.
 
@@ -52,7 +52,7 @@ The inherited `dh_installsystemd --no-start` remains in force.
 Versions use `<upstream>+g15.git<12-character-commit>-1`. Macro's upstream
 version is 1.0.5 (configure.ac), not the historical Debian changelog's 1.0.3.
 Tests require versions above every available trixie candidate, including binNMUs.
-There is no trixie macro candidate: macro is tested as a fresh installation,
+There are no trixie macro or stats candidates: both are tested as fresh installations,
 not falsely reported as a distro upgrade. Increment the local Debian revision
 when changing overlays for an already-published source commit. Git hashes are
 identifiers, not monotonically increasing versions between local releases.
@@ -65,9 +65,9 @@ binary reproducibility. Keep complete released artifacts. No signing is performe
 
 ## Outputs and gates
 
-Eight packages: `libg15-1`, `libg15-dev`, `libg15render1`, `libg15render-dev`,
-`g15daemon`, `libg15daemon-client1t64`, `libg15daemon-client-dev`, `g15macro`;
-plus five debug-symbol packages on amd64. Each of the four sources has a `.dsc`,
+Nine packages: `libg15-1`, `libg15-dev`, `libg15render1`, `libg15render-dev`,
+`g15daemon`, `libg15daemon-client1t64`, `libg15daemon-client-dev`, `g15macro`, `g15stats`;
+plus six debug-symbol packages on amd64. Each of the five sources has a `.dsc`,
 orig tarball, Debian tarball, `.buildinfo` and `.changes`. `SUBMODULES` records
 pins and `SHA256SUMS` covers all artifacts. The outer Git ZIP is not a substitute.
 
@@ -77,7 +77,13 @@ SONAMEs, executable linking, development headers/linking, t64 fields, service
 and udev installation, macro help/version and purge cleanup. Source rebuilds
 install newly rebuilt dependencies, not binaries from the first build.
 
-CI uses recursive checkout on relevant PRs, manual dispatch and published
+Gitea CI (`.gitea/workflows/debian.yml`) builds on every push to `main` and
+manual dispatch, using an `ubuntu-latest` runner with local Docker Engine.
+The runner must expose the same workspace paths to Docker for read-only mounts.
+It uploads `debian13-amd64` artifacts using the Gitea-compatible v3 protocol;
+download the artifact from the successful run and check `SHA256SUMS`.
+Gitea does not run the GitHub CLI release job or publish release assets.
+GitHub CI uses recursive checkout on main pushes, relevant PRs, manual dispatch and published
 releases. Build permissions are read-only; a separate write-permission job
 downloads the verified artifact and checks checksums before uploading release
 assets. All actions are commit-pinned. Existing assets are not overwritten.