Skip to content

Conversation

@robobun
Copy link
Collaborator

@robobun robobun commented Dec 11, 2025

Summary

  • Fix Docker image build failure on Debian trixie by using LLVM's unstable repository instead of the non-existent trixie repository
  • The LLVM apt repository (apt.llvm.org) doesn't have packages for Debian trixie (13) or forky - attempts to access llvm-toolchain-trixie-19 return 404
  • Pass -n=unstable flag to llvm.sh when running on these Debian versions

Test plan

Fixes the build failure from: https://github.com/oven-sh/bun-development-docker-image/actions/runs/20105199193

Error was:

E: The repository 'http://apt.llvm.org/trixie llvm-toolchain-trixie-19 Release' does not have a Release file.

🤖 Generated with Claude Code

@robobun
Copy link
Collaborator Author

robobun commented Dec 11, 2025

Updated 3:59 PM PT - Dec 11th, 2025

❌ Your commit 131442a7 has 9 failures in Build #33201 (All Failures):


🧪   To try this PR locally:

bunx bun-pr 25470

That installs a local version of the PR into your bun-25470 executable, so you can run:

bun-25470 --bun

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 11, 2025

Walkthrough

Adds Debian-specific logic to scripts/bootstrap.sh to pass -n=unstable to the LLVM installer when running on Debian with VERSION_CODENAME trixie or forky; LLVM installation flow and explicit llvm-tools install remain unchanged.

Changes

Cohort / File(s) Summary
LLVM Installation Configuration
scripts/bootstrap.sh
Added conditional that, when distro is Debian and VERSION_CODENAME is trixie or forky, passes -n=unstable to the llvm.sh installer; other LLVM install steps unchanged.

Possibly related PRs

  • all: update to debian 13 #24055 — Also modifies scripts/bootstrap.sh to change Debian-specific handling and broadens Debian support; shares overlap in Debian codename handling for LLVM install.

Suggested reviewers

  • Jarred-Sumner
  • dylan-conway

Pre-merge checks

❌ Failed checks (1 inconclusive)
Check name Status Explanation Resolution
Description check ❓ Inconclusive The description provides a clear summary of the issue, root cause, and solution. However, it does not follow the required template structure with 'What does this PR do?' and 'How did you verify your code works?' sections. Restructure the description to match the template format: add 'What does this PR do?' section and explicitly complete the 'How did you verify your code works?' section with actual verification steps taken.
✅ Passed checks (1 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: fixing LLVM repository configuration for Debian trixie/forky by using the unstable repository.

Comment @coderabbitai help to get the list of available commands and usage tips.

The LLVM apt repository (apt.llvm.org) doesn't have a dedicated release
for Debian trixie (13) or forky. When running llvm.sh on these distros,
it tries to access llvm-toolchain-trixie-19 which returns a 404.

This fix passes -n=unstable to llvm.sh when running on Debian trixie or
forky, directing it to use the unstable repository which does have the
packages available.

Fixes the docker image build failure:
E: The repository 'http://apt.llvm.org/trixie llvm-toolchain-trixie-19 Release' does not have a Release file.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>
@robobun robobun force-pushed the claude/fix-llvm-install-debian-trixie branch from 34b34ef to 131442a Compare December 11, 2025 15:14
@robobun robobun changed the title fix: use LLVM unstable repo for Debian trixie/forky fix: use LLVM unstable repo for Debian trixie/forky [build images] Dec 11, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Disabled knowledge base sources:

  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 34b34ef and 131442a.

📒 Files selected for processing (1)
  • scripts/bootstrap.sh (1 hunks)
🔇 Additional comments (1)
scripts/bootstrap.sh (1)

1160-1172: Approved — LLVM repository selection for Debian trixie/forky is correctly implemented.

The logic properly detects Debian trixie/forky systems and passes -n=unstable to llvm.sh to work around the missing trixie-specific repository. Variable initialization, conditional gating, and shell expansion are all correct. The fix matches the commit message intent and solves the documented 404 error on llvm-toolchain-trixie-19.

Comment on lines +1164 to +1169
case "$VERSION_CODENAME" in
trixie|forky)
llvm_codename_arg="-n=unstable"
;;
esac
fi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick | 🔵 Trivial

Optional: Add default case to case statement for clarity.

While the current code works correctly (unmatched codenames simply set no additional argument), adding an explicit default case improves code clarity and future maintainability.

 		if [ "$distro" = "debian" ]; then
 			case "$VERSION_CODENAME" in
 			trixie|forky)
 				llvm_codename_arg="-n=unstable"
+				;;
+			*)
+				# Other Debian versions use their native LLVM repository
 				;;
 			esac
 		fi

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents
In scripts/bootstrap.sh around lines 1164 to 1169, the case statement handling
$VERSION_CODENAME only lists trixie|forky and then ends, which is functional but
lacks an explicit default branch; add a default (*) case that explicitly sets
llvm_codename_arg to an empty value or leaves it unchanged (e.g.,
llvm_codename_arg="" or a no-op comment) to make intent clear and improve
maintainability, and ensure the case block still ends with ;; and the esac as
currently structured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants