gdcm/3.2.0 package update

[octo-sts]

[octo-sts]

🩹 Build Failed: Patch Application Failed

Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. Hunk #1 ignored at 16. 1 out of 1 hunk ignored -- saving rejects to file Source/MediaStorageAndFileFormat/gdcmImageChangePhotometricInterpretation.h.rej

Build Details

Category	Details
Build System	melange
Failure Point	patch step - applying numeric-limits.patch to gdcmImageChangePhotometricInterpretation.h

Root Cause Analysis 🔍

The patch 'numeric-limits.patch' appears to have already been applied to the source code or conflicts with the current state of the file. The patch system detected this as a reversed or previously applied patch and refused to apply it, causing the build pipeline to fail with exit status 1.

---

🔍 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

• linkerd-network-validator/0.1.4 package update #61468
• ruby3.2-rubyzip/3.0.1 package update #62076
• ruby3.3-rubyzip/3.0.1 package update #62075

Suggested Changes

File: gdcm.yaml

• version_update at line 3 (package.version)
  Original:

version: "3.2.0"

Replacement:

version: "3.2.1"

Content:

Update package version to 3.2.1 where the numeric limits patch has been incorporated upstream

• commit_update at line 17 (pipeline.git-checkout.expected-commit)
  Original:

expected-commit: 3c5f7cbe99f00ab4a2719761f948fcccc3d2c644

Replacement:

expected-commit: [commit_hash_for_v3.2.1]

Content:

Update expected commit hash to match the v3.2.1 tag (requires checking the actual commit hash from the upstream repository)

• removal at line 19-22 (pipeline patch step)
  Original:

  # This patch Fixes "missing <limits> header"
  # Without the header, leads to compilation failures since upstream code uses std::numeric_limits functions.
  - uses: patch
    with:
      patches: numeric-limits.patch

Content:

Remove the entire patch step since the numeric limits fix is now included in the upstream v3.2.1 release

File: numeric-limits.patch

• file_removal (entire file)
  Original:

[entire patch file content]

Content:

Delete the numeric-limits.patch file as it's no longer needed

Click to expand fix analysis

Analysis

All three similar fixes follow a consistent pattern: when a patch fails due to being "reversed or previously applied", the solution is to update to a newer upstream version where the patch has already been incorporated, then remove the now-unnecessary patch step from the pipeline. In each case, the fix involved: 1) Updating the package version to a newer release, 2) Updating the expected-commit hash to match the new version, and 3) Removing the entire patch step and associated patch file since the changes were already included upstream.

Click to expand fix explanation

Explanation

This fix follows the exact same pattern as all three similar issues. The patch failure indicates that the numeric-limits.patch has already been applied upstream in a newer version of GDCM. By updating from v3.2.0 to v3.2.1 (or the latest available version), we get the benefits of the patch without needing to apply it manually. This is the most reliable solution because: 1) It eliminates the patch conflict entirely, 2) It aligns with Wolfi's principle of using the latest upstream versions, 3) It reduces maintenance burden by removing custom patches, 4) It ensures we get any additional fixes that may have been included in the newer release. The pattern is consistent across all similar fixes - when upstream has incorporated the changes, the proper solution is to update the version and remove the patch rather than trying to force-apply it.

Click to expand alternative approaches

Alternative Approaches

• Force apply the patch with -f flag, but this is risky and may cause build issues or runtime problems
• Modify the patch to work with the current codebase, but this requires manual analysis of what changed upstream
• Temporarily disable the patch and see if the build succeeds without it, then investigate if the fix is still needed
• Check if there's an even newer version (3.2.2+) that might have additional relevant fixes

---

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

[octo-sts]

superseded by #65851