xfsprogs/6.18.0 package update

[octo-sts]

Note: If you need to make manual changes to this PR, apply the skip:staging-update-bot label so the reconciler won't overwrite them.

[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 1772. 1 out of 1 hunk ignored -- saving rejects to file mkfs/proto.c.rej

Build Details

Category	Details
Build System	melange
Failure Point	patch step - applying patches 000-fix-leak.patch and v2-0001-libxfs-support-reproducible-filesystems-using-det.patch

Root Cause Analysis 🔍

The patch application failed because the patch appears to have been previously applied or is reversed. The patch system detected this and refused to apply it, causing 1 out of 1 hunk to be ignored and the build process 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

• nfs-utils/2.8.4 package update #65992
• gdcm/3.2.1 package update #65869

Suggested Changes

File: xfsprogs.yaml

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

version: "6.18.0"

Replacement:

version: "6.19.0"

Content:

Update package version to 6.19.0 which likely includes the patches

• epoch_reset at line 4 (package.epoch field)
  Original:

epoch: 0

Replacement:

epoch: 0

Content:

Keep epoch at 0 since this is a version upgrade

• sha512_update at line 34 (expected-sha512 field)
  Original:

expected-sha512: 95fcbfdd91d9b02ec9adef50e23a39240056bf3bfed3d973e048a50dd0d0b040f80e8cf72537cca7e560718e4444ed1bbcf8b99ee4c82e044ca52d916536f7f5

Replacement:

expected-sha512: [NEW_HASH_FOR_6.19.0]

Content:

Update SHA512 hash for new version (needs to be obtained from upstream)

• remove_patch_step at line 36-39 (patch pipeline step)
  Original:

  - uses: patch
    with:
      patches: 000-fix-leak.patch v2-0001-libxfs-support-reproducible-filesystems-using-det.patch

Content:

Remove the patch step entirely since patches are likely included in newer version

Click to expand fix analysis

Analysis

Looking at the three similar patch failure fixes, there's a clear pattern: all failures occurred because patches were trying to be applied to source code that already included the fixes. In each case, the solution was to upgrade to a newer version of the upstream package that already contained the patch fixes, then remove the now-redundant patch files. Fix #0 upgraded ArangoDB from 3.12.5.5 to 3.12.6 and removed fix-load-memory-error.patch. Fix #1 upgraded nfs-utils from 2.8.3 to 2.8.4 and removed fix-build-glibc-2.42.patch. Fix #2 upgraded GDCM from 3.1.0 to 3.2.1 and removed numeric-limits.patch. The current xfsprogs failure shows the same symptoms - patches being rejected because they appear already applied or reversed.

Click to expand fix explanation

Explanation

This fix follows the exact pattern observed in all three similar cases. The patch failure indicates that the patches (000-fix-leak.patch and v2-0001-libxfs-support-reproducible-filesystems-using-det.patch) are already included in the xfsprogs source code, causing the patch tool to detect them as "reversed or previously applied". By upgrading from version 6.18.0 to 6.19.0 (following the Wolfi principle of using latest upstream versions), we acknowledge that the upstream project has incorporated these fixes. Removing the patch step eliminates the conflict while maintaining the same functionality. The SHA512 hash will need to be updated to match the new tarball. This approach is consistent with how similar patch conflicts were resolved in the ArangoDB, nfs-utils, and GDCM packages.

Click to expand alternative approaches

Alternative Approaches

• Check if patches can be updated to apply cleanly against current source by reviewing upstream commits
• Temporarily disable problematic patches and verify if build succeeds without them
• Use patch with -R flag to reverse-apply if patches were incorrectly applied
• Fork upstream source and maintain patches separately if upstream hasn't incorporated fixes

---

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