Conversation
Keep the existing `whispers-bin` and `whispers-git` packages as the portable non-CUDA path, add explicit `whispers-cuda-bin` and `whispers-cuda-git` variants, and update the README/package docs so Arch users can pick the right install path without guessing. Constraint: Existing live AUR package names should not silently change semantics Rejected: Turn `whispers-bin` and `whispers-git` into CUDA-first packages | breaking change for current portable-package users Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep portable and CUDA package names/documentation explicit so users know which runtime path they are choosing Tested: makepkg --printsrcinfo; makepkg --verifysource (whispers-cuda-git); local bundle package build for whispers-cuda-bin Not-tested: Live CUDA release asset checksum until workflow publication
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5ecf2414c3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| source=( | ||
| "$pkgname-$pkgver.tar.gz::$url/releases/download/v$pkgver/whispers-cuda-$pkgver-x86_64-unknown-linux-gnu.tar.gz" | ||
| ) | ||
| sha256sums=('REPLACE_WITH_CUDA_RELEASE_SHA256') |
There was a problem hiding this comment.
The sha256sums entry is still a placeholder string, so makepkg verification for whispers-cuda-bin will fail for every install attempt because the downloaded tarball hash can never match REPLACE_WITH_CUDA_RELEASE_SHA256. This makes the newly documented paru -S whispers-cuda-bin path non-functional until a real SHA256 is committed (and corresponding .SRCINFO regenerated).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in commit 4ca48db by replacing the placeholder with the live whispers-cuda-0.2.1 release SHA and regenerating .SRCINFO. I also re-verified makepkg --verifysource against the published GitHub asset.
OneNoted
force-pushed
the
aur-cuda-package-variants
branch
from
5ecf241 to
a020638
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a020638cc9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| --title "$TAG_NAME" \ | ||
| --generate-notes \ | ||
| --target "$GITHUB_SHA" | ||
| gh release upload "$TAG_NAME" "${assets[@]}" --clobber |
There was a problem hiding this comment.
In .github/workflows/release.yml, the portable job uploads release assets as soon as it finishes, independently of build-cuda. On tag pushes both jobs run in parallel, so if CUDA build fails but portable succeeds, the workflow still publishes a partial release with only one bundle, which breaks the new expectation that tagged releases provide both portable and CUDA artifacts. Publish in a downstream job that depends on both build jobs (or otherwise gate upload) so releases are only updated when both variants succeed.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in commit 4df9b4c by moving release uploads behind separate publish jobs that depend on the completed build jobs. On tag pushes, both the portable and CUDA builds must succeed before any assets are uploaded.
| gh release create "$TAG_NAME" \ | ||
| --title "$TAG_NAME" \ | ||
| --generate-notes |
There was a problem hiding this comment.
gh release create from auto-creating wrong tags
The ensure-release job creates releases with gh release create "$TAG_NAME" before the workflow validates that tag_name is real and matches checked-out code, and it does so without --verify-tag. In a manual dispatch with publish_release=true, a typo/nonexistent tag can create an unintended tag/release from the default branch and then fail later in build steps, leaving incorrect release state behind. Add --verify-tag (or defer creation until after tag validation) to avoid this side effect.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in commit 4df9b4c by checking that the requested tag exists on origin before creating a release, so a typo/nonexistent tag cannot auto-create an unintended release/tag.
The workflow bootstrap job can create a missing GitHub release, but `gh release create --generate-notes` needs a Git checkout to inspect history. Add a checkout so the bootstrap path works for manual CUDA publish runs too. Constraint: The release bootstrap path must work before the asset-building jobs start Rejected: Drop generated notes entirely | keeps the release bootstrap simpler but regresses release metadata quality Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep the release-bootstrap job checkout lightweight but present if release creation still uses generated notes Tested: failure log analysis for workflow run 24339607306; ruby YAML parse for .github/workflows/release.yml Not-tested: Successful live rerun before push
OneNoted
force-pushed
the
aur-cuda-package-variants
branch
from
a020638 to
3a83975
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 00c85cb3f3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if [[ "$source_bundle" != "$final_bundle" && -f "dist/${source_bundle}.tar.gz" ]]; then | ||
| mv "dist/${source_bundle}.tar.gz" "dist/${final_bundle}.tar.gz" | ||
| ( | ||
| cd dist | ||
| sha256sum "${final_bundle}.tar.gz" > "${final_bundle}.tar.gz.sha256" |
There was a problem hiding this comment.
In build-cuda, this fallback only renames dist/whispers-...tar.gz to dist/whispers-cuda-...tar.gz and rewrites the checksum, but it does not change the archive’s internal top-level directory. For manual dispatches that publish older tags (where scripts/build-release-bundle.sh still emits whispers-<ver>-...), the uploaded CUDA asset name and its contents diverge, and packaging/aur/whispers-cuda-bin/PKGBUILD (which expects whispers-cuda-<ver>-... in package()) will fail when extracting/installing. Repack the archive with the CUDA root name (or block publishing from tags without prefix support).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in commit 4df9b4c by repacking legacy CUDA bundles under the whispers-cuda-... top-level directory instead of only renaming the tarball path, so the uploaded asset contents match the whispers-cuda-bin PKGBUILD expectations.
OneNoted
force-pushed
the
aur-cuda-package-variants
branch
from
00c85cb to
dea753f
Compare
Gate release uploads on the completed build jobs so tagged releases do not end up with only the portable bundle if the CUDA build fails, verify the requested tag exists before creating a release, and repack legacy CUDA bundles instead of only renaming the tarball path. Constraint: Release assets must not be published from partial or tag-less runs Rejected: Upload assets directly from each build job | races and partial releases leave the GitHub release in an inconsistent state Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep release publication downstream of successful build artifacts, especially when multiple bundle variants are involved Tested: ruby YAML parse for .github/workflows/release.yml; workflow failure analysis for runs 24339651972 and 24339701954 Not-tested: Fresh successful GitHub Actions run after this follow-up
Now that the `whispers-cuda-0.2.1` release asset is live, replace the placeholder checksum in `whispers-cuda-bin` and regenerate `.SRCINFO` so AUR source validation succeeds for the published package. Constraint: The committed AUR metadata must match the actual uploaded GitHub release asset Rejected: Leave the placeholder until after merge | keeps the PR review unresolved and makes the package definition invalid Confidence: high Scope-risk: narrow Reversibility: clean Directive: Do not merge or publish AUR `-bin` metadata with placeholder checksums; always update from the live release asset first Tested: makepkg --printsrcinfo; makepkg --verifysource (whispers-cuda-bin against live GitHub asset) Not-tested: AUR web index propagation after push
OneNoted
force-pushed
the
aur-cuda-package-variants
branch
from
dea753f to
4ca48db
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4ca48db6a1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| gh release create "$TAG_NAME" \ | ||
| --title "$TAG_NAME" \ | ||
| --generate-notes |
There was a problem hiding this comment.
The ensure-release job creates the GitHub release before build-portable/build-cuda run, so on tag pushes (or dispatch publishes) any later build failure leaves a newly published release with no assets because the downstream publish-release-* job is skipped. This is a release-state regression from the previous single-job flow and can expose broken/empty releases to users unless maintainers manually clean them up. Create the release only in the publish stage (or keep it draft until uploads complete) so publication is atomic.
Useful? React with 👍 / 👎.
1 participant
Summary
whispers-cuda-binandwhispers-cuda-gitAUR package variants while keeping the existing portable packages stableTesting
whispers-cuda-binpackage build against a preflight CUDA bundle