From 76e3d6ced82f9815fac4caa2c9f5c497bd7eb05c Mon Sep 17 00:00:00 2001 From: "Maciek \"mab122\" Bator" Date: Sun, 19 Jul 2026 12:51:54 +0200 Subject: [PATCH] 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. --- NOTES-package-publish-todo.md | 60 +++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 NOTES-package-publish-todo.md diff --git a/NOTES-package-publish-todo.md b/NOTES-package-publish-todo.md new file mode 100644 index 00000000..8b5e2d36 --- /dev/null +++ b/NOTES-package-publish-todo.md @@ -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.