Refs #1.
`scripts/install-apt.sh` explained the sqv rejection as a malformed MPI
encoding in an Ed25519 key. The registry does not serve one: at
`api/packages/heavy-duty/debian/repository.key`, `gpg --list-packets`
reports `algo 1` (RSA) with a 2048-bit `pkey[0]`. The explanation was
therefore wrong about the only part of itself that was checkable.
The comment now states the measurement and points at #1 for the cause,
rather than naming a mechanism nobody verified. This satisfies #1's
criterion that `git grep -in 25519` return no hits outside test fixtures,
which it now does.
Behaviour is unchanged: this commit edits a comment. The automatic
fallback this file still performs contradicts ruling B and is NOT fixed
here — that work is still owed on !38.
- chmod 0644 every keyring and sources.list entry after writing: tee
inherits the caller's umask, and under e.g. umask 077 apt's
unprivileged _apt user could not read the keyring
- Tests now run the script under umask 077 and assert the 0644 modes
(mutation-checked: dropping the chmod fails a test), and remove their
temp directories on exit
- Refusal error now states that metadata was already refreshed before
concluding the existing nodesource.list is unsuitable
Verified on fresh debian:13 under umask 077: all four files 0644,
install succeeds. npm test 32/32.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Covers the scenarios codex-reviewer recommended: suitable candidate
already present (incl. epoch stripping), missing metadata healed by a
refresh, bootstrap on too-old distro nodejs, bootstrap failure, and the
refuse-to-overwrite branch for a user-managed nodesource.list. Every
scenario runs under a localized LC_ALL with an apt-cache stub that only
emits the English Candidate: label under LC_ALL=C, so locale-safe
parsing is regression-tested (mutation-checked: dropping LC_ALL=C fails
3 tests).
install-apt.sh gains STOKE_APT_ETC to redirect /etc/apt to a throwaway
directory under test, following the script's existing env-override
pattern. Real-container flow re-verified on debian:13.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Parse apt-cache policy under LC_ALL=C (Candidate: label is localized)
- Refresh apt metadata (best effort) and re-check before concluding no
suitable nodejs source exists
- Refuse to overwrite an existing /etc/apt/sources.list.d/nodesource.list
instead of silently replacing a user-managed entry
- README: manual path now adds the forge source, then the Node 22 source,
then runs apt-get update && install — in that order
Verified on fresh debian:13: install, idempotent re-run (NodeSource not
re-added), and the refusal branch with a pre-existing user list.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The package depends on nodejs (>= 22.12), but Debian 13 ships Node 20 and
Ubuntu 24.04 ships Node 18, so a fresh container failed apt-get install
with an unmet dependency. install-apt.sh now checks whether any configured
apt source can satisfy the requirement and, if not, adds the NodeSource
Node 22 repository before installing. README documents the behaviour and
the manual equivalent.
Verified on fresh debian:13 and ubuntu:24.04 containers: one-line setup,
apt-get install stoke, stoke --version all succeed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Implements #1 — stoke installable with apt-get install stoke.
Packaging:
- scripts/build-deb.sh: builds dist/stoke_<version>_all.deb from a clean
staging copy (src + fresh npm ci --omit=dev), pure-JS Architecture: all,
Depends: nodejs (>= 22.12), /usr/lib/stoke payload with /usr/bin/stoke
symlink, copyright + changelog, normalized permissions. Lintian-clean.
- scripts/publish-deb.sh: uploads a .deb to the Forgejo Debian registry
(owner/distribution/component parameterized, defaults heavy-duty/
stable/main), authenticating with STOKE_TOKEN or the stoke login token.
- scripts/install-apt.sh: consumer-side one-time setup — adds the
registry key and apt source, then apt-get install stoke. Falls back to
a [trusted=yes] source when apt's sqv verifier rejects the forge's
registry signature (known upstream Forgejo signing bug; the script
prefers the signed source so setups heal once the forge is fixed).
- .forgejo/workflows/release.yml: on v* tags — test, build, publish to
the heavy-duty registry, attach the .deb to the release page. Needs a
runner and a RELEASE_TOKEN secret with org package write.
New command:
- stoke pr merge (-n, --method merge|rebase|rebase-merge|squash,
--title, --message, --delete-branch) — gap found while merging !2.
Docs and housekeeping:
- README: 'Install with apt' as the primary installation method with
manual setup and dpkg fallback, signature caveat, pr merge reference,
Packaging and releasing section with a release checklist.
- dist/ gitignored; version bumped to 1.2.0.
Verified end-to-end on this machine: built the deb (lintian-clean),
published it to the Forgejo Debian registry, installed it with
apt-get install stoke via install-apt.sh, and confirmed the installed
CLI works against the live forge. The test upload was removed from the
personal namespace afterwards; publishing under heavy-duty needs an
org-member token (401 reqPackageAccess with this restricted account).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
