linkerd2: stream 25.12

[Dentrax]

Linkerd2 supports 25.12.x, 25.11.x, and 25.10.x version streams.

Fixes:

Related:

Pre-review Checklist

For new package PRs only

• This PR is marked as fixing a pre-existing package request bug
  • Alternatively, the PR is marked as related to a pre-existing package request bug, such as a dependency
• REQUIRED - The package is available under an OSI-approved or FSF-approved license
• REQUIRED - The version of the package is still receiving security updates
• This PR links to the upstream project's support policy (e.g. endoflife.date)

For new version streams

• The upstream project actually supports multiple concurrent versions.
• Any subpackages include the version string in their package name (e.g. name: ${{package.name}}-compat)
• The package (and subpackages) provides: logical unversioned forms of the package (e.g. nodejs, nodejs-lts)
• If non-streamed package names no longer built, open PR to withdraw them (see WITHDRAWING PACKAGES)

For package updates (renames) in the base images

When updating packages part of base images (i.e. cgr.dev/chainguard/wolfi-base or ghcr.io/wolfi-dev/sdk)

• REQUIRED cgr.dev/chainguard/wolfi-base and ghcr.io/wolfi-dev/sdk images successfully build
• REQUIRED cgr.dev/chainguard/wolfi-base and ghcr.io/wolfi-dev/sdk contain no obsolete (no longer built) packages
• Upon launch, does apk upgrade --latest successfully upgrades packages or performs no actions

For security-related PRs

• The security fix is recorded in the advisories repo

CVE Scanning: This PR will fail if ANY CVEs are found (fail-any mode). To customize:

• Must-fix specific CVEs only: Add <!--ci-cve-scan:must-fix: CVE-ID--> markers and remove the line below
• Fail on any CVEs (default): Keep the marker below

<!--ci-cve-scan:fail-any-->

For version bump PRs

• The epoch field is reset to 0

For PRs that add patches

• Patch source is documented

[octo-sts]

⚙️ Build Failed: Configuration

Error: no packages or bump file provides, use --packages/--bump-file

Build Details

Category	Details
Build System	melange
Failure Point	rust/cargobump step - cargobump command execution

Root Cause Analysis 🔍

The cargobump tool requires either --packages flag with package specifications or --bump-file flag pointing to a dependency file, but neither was provided. The build configuration is missing the necessary parameters for the cargobump step to identify which Rust dependencies to bump.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Similar PRs with fixes

• efs-utils/2.3.3-r0: cve remediation #62912

Suggested Changes

File: linkerd2-25.12.yaml

• remove at line 38 (pipeline section)
  Original:

  - uses: rust/cargobump

Content:

Remove the rust/cargobump step that's causing the build failure

Click to expand fix analysis

Analysis

The similar fixes show that cargobump/gobump tools require explicit parameters to specify which dependencies to manage. In Fix Example #0, the issue was resolved by removing the problematic cargobump step entirely and handling dependency updates through patch files instead. In Fix Example #1, the gobump issue was bypassed by manually updating the go.mod file with a direct sed command. The pattern shows that when bump tools fail due to missing parameters, the solution is either to provide the required parameters (--packages, --bump-file, etc.) or replace the automated bump step with manual dependency management.

Click to expand fix explanation

Explanation

The cargobump tool requires either --packages flag with specific package names or --bump-file flag pointing to a dependency file, but the current configuration provides neither. Based on the similar fixes, the most straightforward solution is to remove the problematic cargobump step entirely. This approach is validated by Fix Example #0, where the cargobump step was removed and dependency management was handled through other means (patch files in that case). Since this is a meta package for linkerd2-25.12 and the actual Rust compilation happens in the controller subpackage with 'cargo auditable build', the cargobump step at the main pipeline level appears unnecessary. The Rust dependencies will be resolved during the actual build process in the controller subpackage, making the separate bump step redundant.

Click to expand alternative approaches

Alternative Approaches

• Add explicit --packages parameter to cargobump with specific Rust crates to bump, but this requires knowledge of which crates need updating
• Add --bump-file parameter pointing to a Cargo.toml or similar dependency file, but this requires creating and maintaining such a file
• Replace cargobump with manual dependency updates using sed commands similar to Fix Example Add binutils-2.39 configuration #1, updating specific version strings in Cargo.toml files

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

[Dentrax]

It seems its single versioned project.