jq/1.8.0 package update

[octo-sts]

[octo-sts]

🩹 Build Failed: Patch Application Failed

Patch application failed: Reversed (or previously applied) patch detected! Skipping patch. 4 out of 4 hunks ignored -- saving rejects to file src/jv.c.rej

Build Details

Category	Details
Build System	melange
Failure Point	Patch application during 'patch' step in the melange build process

Root Cause Analysis 🔍

The build is trying to apply a patch to src/jv.c, but the patch cannot be applied. The error suggests the patch may be reversed or has already been applied to the source code. All 4 hunks of the patch were ignored, and the rejects were saved to src/jv.c.rej. This indicates that the patch doesn't match the current state of the source file.

---

🔍 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

• x11vnc/0.9.17 package update #52199
• druid/33.0.0 package update #51716
• metric-collector-for-apache-cassandra-4.1/0.3.6 package update #48616

Suggested Changes

File: jq.yaml

• modify at line 28-31 (patch step in pipeline)
  Original:

  - uses: patch
    with:
      patches: |
        0001-fix-jv_number_value-should-cache-the-double-value-of.patch
        0002-Reject-NaN-with-payload-while-parsing-JSON.patch

Replacement:

  # Patches are already included in this version

File: jq.yaml

• modify at line 75-77 (test section)
  Original:

    - name: CVE-2024-53427
      runs: |
        output=$(echo '["NaN"]' | jq -r '.[] | try (fromjson | isnan) catch .')
        [ "$output" = "true" ]
        output=$(echo '["NaN1"]' | jq -r '.[] | try (fromjson | isnan) catch .')
        [ "$output" = "Invalid numeric literal at EOF at line 1, column 4 (while parsing 'NaN1')" ]

Replacement:

    - name: CVE-2024-53427
      runs: |
        output=$(echo '["NaN"]' | jq -r '.[] | try (fromjson | isnan) catch .')
        [ "$output" = "true" ]
        output=$(echo '["NaN1"]' | jq -r '.[] | try (fromjson | isnan) catch .')
        [ "$output" = "Invalid numeric literal at EOF at line 1, column 4 (while parsing 'NaN1')" ]

Click to expand fix analysis

Analysis

After analyzing the similar fixed build failures, I can see a clear pattern: all three examples involve patch application failures with the error message "Reversed (or previously applied) patch detected!". In each case, the solution was to remove the patch step completely and update the package version to a newer release where the patch was no longer needed.

The common pattern in these fixes was:

1. Upgrading to a newer version of the package where the patch has already been integrated
2. Removing the patch file and the patch step from the build pipeline
3. Updating the expected commit hash to match the new version

This suggests that patches which fail with "Reversed (or previously applied) patch detected!" are typically addressing issues that have been fixed in newer versions of the source code.

Click to expand fix explanation

Explanation

The build failure is occurring because the patches 0001-fix-jv_number_value-should-cache-the-double-value-of.patch and 0002-Reject-NaN-with-payload-while-parsing-JSON.patch are being applied to source code that already contains these changes.

Looking at the error message: "Reversed (or previously applied) patch detected! Skipping patch. 4 out of 4 hunks ignored -- saving rejects to file src/jv.c.rej", we can see that the patch tool is detecting that the patches have already been applied to the source code.

This is likely because jq version 1.8.0 already includes the fixes that these patches were meant to apply. Looking at the test section, there's even a specific test for CVE-2024-53427, which is likely what one of the patches was addressing.

The fix is simple - we should remove or comment out the patch step in the pipeline. Since the patches are already included in version 1.8.0 of jq, we don't need to apply them again.

The test for CVE-2024-53427 in the yaml file indicates that this version of jq should already have the fix, which further confirms that the patches are redundant.

Click to expand alternative approaches

Alternative Approaches

• Instead of completely removing the patch step, we could add a condition to only apply the patches for versions earlier than 1.8.0, but this is unnecessary since the current version already has the fixes.
• We could try to apply the patches with the '-N' flag (--forward) to force application even if they appear to be reversed, but this is risky as it could result in corrupted source code.
• Another approach would be to examine each patch file and manually verify which parts of them need to be applied, then create new patches with only those parts, but this is time-consuming and unnecessary since the code already has the fixes.

---

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