sqlite: point at the 3.53.3 archive (now mirrored) - #511
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThe SQLite build configuration and script now consistently reference the ChangesSQLite mirrored archive update
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@LICENSING.md`:
- Around line 56-65: Update the retention policy wording in LICENSING.md so the
three-year retention period starts when the corresponding binary is first
publicly distributed and its written offer becomes available, not when the
archive is uploaded. State that retention must be extended for as long as the
binary remains distributed, while preserving the existing write-once,
mirror-migration, and verification requirements.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f8f65b0f-e35b-476c-b004-b350baf21339
📒 Files selected for processing (2)
LICENSING.mdpackages/sqlite/build.ncl
| Mirror objects are write-once (uploads never overwrite) and the bucket | ||
| carries a three-year retention policy — the GPLv2 §3(b) written-offer | ||
| period — so archives cannot be deleted or modified while the offer is | ||
| live. Retention runs from each object's upload time and is reviewed | ||
| periodically, since the offer lasts for as long as the corresponding | ||
| binary is distributed. A weekly automated sweep verifies every distributed | ||
| copyleft package's exact pinned source is present on the mirror. If public | ||
| distribution moves to a different endpoint, these obligations follow | ||
| wherever consumers actually fetch, and the mirror and this policy move | ||
| with it. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Do not start the GPLv2 retention clock at upload time.
An archive can be uploaded before its binary is first distributed; a three-year clock from upload could therefore expire before the written offer has been available for the required period. Anchor retention to the public distribution/offer date and extend it while the binary remains distributed.
Suggested wording
-Retention runs from each object's upload time and is reviewed
-periodically, since the offer lasts for as long as the corresponding
-binary is distributed.
+Retention is measured from the public distribution/offer date and is
+reviewed periodically; archives remain available for at least three
+years after that date and for as long as the corresponding binary is
+distributed.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Mirror objects are write-once (uploads never overwrite) and the bucket | |
| carries a three-year retention policy — the GPLv2 §3(b) written-offer | |
| period — so archives cannot be deleted or modified while the offer is | |
| live. Retention runs from each object's upload time and is reviewed | |
| periodically, since the offer lasts for as long as the corresponding | |
| binary is distributed. A weekly automated sweep verifies every distributed | |
| copyleft package's exact pinned source is present on the mirror. If public | |
| distribution moves to a different endpoint, these obligations follow | |
| wherever consumers actually fetch, and the mirror and this policy move | |
| with it. | |
| Mirror objects are write-once (uploads never overwrite) and the bucket | |
| carries a three-year retention policy — the GPLv2 §3(b) written-offer | |
| period — so archives cannot be deleted or modified while the offer is | |
| live. Retention is measured from the public distribution/offer date and is | |
| reviewed periodically; archives remain available for at least three | |
| years after that date and for as long as the corresponding binary is | |
| distributed. A weekly automated sweep verifies every distributed | |
| copyleft package's exact pinned source is present on the mirror. If public | |
| distribution moves to a different endpoint, these obligations follow | |
| wherever consumers actually fetch, and the mirror and this policy move | |
| with it. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@LICENSING.md` around lines 56 - 65, Update the retention policy wording in
LICENSING.md so the three-year retention period starts when the corresponding
binary is first publicly distributed and its written offer becomes available,
not when the archive is uploaded. State that retention must be extended for as
long as the binary remains distributed, while preserving the existing
write-once, mirror-migration, and verification requirements.
Source: MCP tools
Every build of sqlite has been failing:
HashMismatch want=c917d7db… got=a3db587a…
`version` and `sha256` were bumped to 3.53.3 but this URL stayed on
3.50.4's archive, so the fetch pulled 3.50.4's bytes and checked them
against 3.53.3's hash — a permanent failure, on the old toolchain and
the new min/mip stack alike. Verified by hashing both objects: the
mirrored 3500400 archive is a3db587a…, and c917d7db… is the correct
hash of upstream's 3.53.3 tarball.
The 3.53.3 archive was simply never mirrored. It is now — fetched from
canonical upstream, sha256 verified against this pin before and after
upload — so this only has to move to the object that should always have
been here. Source stays on gs:// per LICENSING.md §3 rather than
redirecting to upstream.
Root cause worth naming: nothing here derives from `version`. The
zero-padded release number in the archive name and the sha256 are
independent copies, so an updater that rewrites the sha but not the URL
turns a routine bump into a silent break. Comment added. The general fix
belongs in pkgmgr — it should refuse to rewrite a sha next to a
version-bearing literal URL it cannot also update — and is filed
separately.
Checked the other 20 packages whose literal URL lacks their version:
all legitimate (toolchain bootstrap SEEDS like glibc 2.43 building from
a glibc_2.40 prebuilt, libkrunfw's bundled kernel, tamarin-prover's
stackage snapshot). sqlite was the only real instance.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The buildbot failed on the previous commit:
tar: sqlite-autoconf-3500400.tar.gz: Cannot open: No such file or directory
build.sh was ALSO half-updated by the 3.53.3 bump — line 5 already said
`cd sqlite-autoconf-3530300` while line 4 still extracted
`sqlite-autoconf-3500400.tar.gz`. Before, that combination merely
never got the chance to fail: the fetch died on HashMismatch first.
Fixing the URL moved the failure one step later, to this.
The version is encoded in FIVE independent places across the package —
`version`, the archive name in the URL, the sha256, the `tar` argument
and the `cd` target — and the bump updated three. This is the last one.
`tar -xof` retained: the disallowed-patterns checker requires that exact
form.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
5799586 to
6d15832
Compare
Every build of sqlite has been failing:
versionandsha256were bumped to 3.53.3 but the URL stayed on 3.50.4's archive — so the fetch pulled 3.50.4's bytes and checked them against 3.53.3's hash. A permanent failure, on the old toolchain and the new min/mip stack alike.Verified by hashing both objects directly:
…-3500400.tar.gza3db587a…← thegot=c917d7db…← the pin, correctWhat changed
The 3.53.3 archive was simply never mirrored. It is now — fetched from canonical upstream, sha256 verified against this pin both before and after upload — so this PR only moves the URL to the object that should always have been there. Source stays on
gs://per LICENSING.md §3 rather than redirecting upstream.Root cause worth naming
Nothing here derives from
version. The zero-padded release number in the archive name (3.53.3→3530300) and the sha256 are independent copies. An updater that rewrites the sha but not the URL turns a routine bump into a silent break. Comment added at the site.The general fix belongs in pkgmgr — it should refuse to rewrite a sha next to a version-bearing literal URL it cannot also update — and I'm filing that separately.
I checked the other 20 packages whose literal URL lacks their version: all legitimate (toolchain bootstrap seeds like glibc 2.43 building from a
glibc_2.40prebuilt, libkrunfw's bundled kernel, tamarin-prover's stackage snapshot). sqlite was the only real instance.Found while getting package builds working on the new
min/mipstack — a previous session read this as a credentials problem, but source fetches are hardcoded anonymous (mctx/src/lib.rs:605) and the bucket answers anonymously, so it was never auth.🤖 Generated with Claude Code
Summary by CodeRabbit