gdcm/3.2.1 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 be already applied or reversed, causing the patch application to fail. The patch system detected that the changes in the patch file don't match the current state of the target file, resulting in the patch being skipped and ultimately causing the build pipeline to exit with 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.1"

Replacement:

version: "3.2.2"

Content:

Update package version to latest upstream release

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

expected-commit: 9db6ec37c65efff07e82aa57be5c65f263ce37b5

Replacement:

expected-commit: [commit_hash_for_v3.2.2]

Content:

Update expected commit to match v3.2.2 tag

• 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 patch step as the fix is likely included in upstream v3.2.2

File: numeric-limits.patch

• file_removal (entire file)
  Original:

[entire patch file]

Content:

Delete the patch file as it's no longer needed

Click to expand fix analysis

Analysis

The three similar build failures all follow the same pattern: a patch was being applied that had already been incorporated into the upstream source code in newer versions. The fixes consistently involved two actions: 1) Updating the package version to a newer upstream release that already included the changes from the patch, and 2) Removing the now-unnecessary patch step and patch file from the build pipeline. This pattern suggests that when upstream releases incorporate patches, the build system should be updated to use the newer version and remove the redundant patch application.

Click to expand fix explanation

Explanation

The fix works by addressing the root cause: the numeric-limits.patch is being rejected because the changes it contains have already been incorporated into the upstream GDCM codebase in a newer version. By updating from v3.2.1 to v3.2.2 (or the latest available version), we get the upstream fix for the missing header without needing to apply a separate patch. This eliminates the patch conflict entirely. The pattern from all three similar fixes shows this is the standard approach in Wolfi OS - when upstream incorporates a patch, update to the newer version and remove the redundant patch step rather than trying to force-apply or modify the patch.

Click to expand alternative approaches

Alternative Approaches

• Check if there's an even newer version than 3.2.2 available that includes the fix
• Modify the patch content to match the current source code state, though this is less preferred than using upstream fixes
• Use the -R flag to reverse-apply the patch if it was somehow applied in reverse, but this is risky and not recommended
• Check the specific commit history to verify exactly when the numeric limits fix was incorporated upstream

---

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

[octo-sts]

superseded by #65859