docs: note package/publish gaps blocking the 10MB-fix release
Code fix (35f1f972) is done, tested, and pushed. Package build + Forgejo
package-registry publish is blocked on missing packaging conventions
here (no existing publish script/credentials/target-scope decision) --
see NOTES-package-publish-todo.md for what's needed to finish this.
This commit is contained in:
Maciek "mab122" Bator
parent
35f1f97290
commit
76e3d6ced8
|
|
@ -0,0 +1,60 @@
|
||||||
|
# Status: 10MB IPFS `cat` fix — code done and pushed; package build/publish still needs your input
|
||||||
|
|
||||||
|
## Done (verified, no further action needed)
|
||||||
|
|
||||||
|
- Root-caused and fixed the bug: `crates/radicle-cli/src/ipfs.rs`'s `cat()` used ureq's
|
||||||
|
`Body::read_to_vec()`, which silently caps reads at 10MB (a default meant for typical JSON
|
||||||
|
API responses, not LFS content). Any LFS object over 10MB failed with "the response body is
|
||||||
|
larger than request limit: 10485760" — this is exactly what broke `blog-deploy.service` on
|
||||||
|
the VPS today, on `assets/posts/hashcash/thumbnail.xcf` (29MB).
|
||||||
|
- Fix: raised the limit to 1GiB via ureq's `.with_config().limit(...)`. Commit `35f1f972`,
|
||||||
|
branch `rad-lfs-ipfs`.
|
||||||
|
- Verification performed:
|
||||||
|
1. Added a `#[cfg(test)]` regression test (`ipfs::tests::cat_round_trips_content_larger_than_ureqs_default_10mb_limit`,
|
||||||
|
`#[ignore]`d since it needs a live Kubo daemon) — a 15MB add+cat round-trip.
|
||||||
|
2. Confirmed it **fails** with the exact production error when the fix is reverted, and
|
||||||
|
**passes** with the fix in place.
|
||||||
|
3. Ran the full `radicle-cli` test suite (123 tests) — one pre-existing, unrelated failure
|
||||||
|
(`rad_help`, a stale `--help`-output snapshot missing the `lfs` subcommand — confirmed to
|
||||||
|
fail identically on the unmodified base commit, nothing to do with this change).
|
||||||
|
4. `cargo clippy` clean (one pre-existing warning in an unrelated file/crate).
|
||||||
|
5. **Live reproduction against the real file**: moved aside the cached LFS blob for
|
||||||
|
`thumbnail.xcf` in `~/Blog/Blog`, ran `rad lfs fetch` with the *old* installed binary —
|
||||||
|
reproduced the identical production error byte-for-byte. Ran it again with the *newly
|
||||||
|
built* binary — the 10MB error is completely gone; it now correctly proceeds to the next
|
||||||
|
step (prompting for a passphrase to decrypt the private-repo content, which is expected
|
||||||
|
behavior and unrelated to this bug — I did not attempt to supply a passphrase). Restored
|
||||||
|
the blog repo's `.git/lfs/objects` cache back to its original state afterward; no changes
|
||||||
|
left in `~/Blog/Blog`.
|
||||||
|
- Pushed to `origin` (the Forgejo remote, `ssh://git.hswro.org:9022/mab122/radicle-heartwood-lfs.git`),
|
||||||
|
branch `rad-lfs-ipfs`, commit `35f1f972..4ae9756a`.
|
||||||
|
|
||||||
|
## Not done — needs your call
|
||||||
|
|
||||||
|
I did **not** build or publish a package. Stopping here rather than guessing, because:
|
||||||
|
|
||||||
|
1. **No existing Forgejo-package publishing path in this repo.** There's a `build/Dockerfile`
|
||||||
|
that cross-compiles reproducible `.tar.xz` releases (4 targets: linux/macOS ×
|
||||||
|
x86_64/aarch64) via `cargo-zigbuild`, but nothing that uploads anywhere — no CI workflow,
|
||||||
|
no `curl`-to-package-registry script, nothing referencing Forgejo's package API. I don't
|
||||||
|
know what package type you want registered (generic package? a distro-specific one?), what
|
||||||
|
name/version scheme you use there, or the auth (token?) needed to publish to
|
||||||
|
`git.hswro.org`'s package registry. I deliberately did not go hunting through credential
|
||||||
|
stores (`~/.netrc`, etc.) to find one myself — that's exactly the kind of thing I should ask
|
||||||
|
about rather than dig for.
|
||||||
|
2. **The existing Dockerfile's package doesn't include `rad-lfs-transfer`** — only `rad`,
|
||||||
|
`git-remote-rad`, and `radicle-node` get copied into the release tarball. `rad-lfs-transfer`
|
||||||
|
is a separate crate/binary (`radicle-lfs-transfer/`) and is required for this fork's whole
|
||||||
|
LFS-over-IPFS feature to work on a fresh install — worth fixing in the Dockerfile too, but
|
||||||
|
I didn't want to change the packaging script's scope without confirming that's wanted.
|
||||||
|
3. **Platform scope is unclear.** The existing Dockerfile builds all 4 targets (needed for a
|
||||||
|
real public release); the VPS only needs `x86_64-unknown-linux-musl`. Building all 4 takes
|
||||||
|
meaningfully longer and needs the macOS SDK blob (`build/macos-sdk-11.3.tar.xz`) and Zig
|
||||||
|
cross-toolchain set up — I can do it, but wanted to confirm whether you want the full
|
||||||
|
release matrix or just what's needed to update the VPS.
|
||||||
|
|
||||||
|
If you want me to keep going on this (rather than picking it up in the session that already
|
||||||
|
knows this fork's packaging conventions), I'd need: the Forgejo package type/target and an
|
||||||
|
auth token (however you'd like to provide it — e.g. via an env var you set, not me searching
|
||||||
|
for it), confirmation on whether to add `rad-lfs-transfer` to the Dockerfile's package list,
|
||||||
|
and whether to build the full 4-target matrix or just linux/x86_64.
|
||||||
Loading…
Reference in New Issue