ruby4.0-net-http-persistent/4.0.8 package update

[octo-sts]

Commit: 66bf49c4cb990b7a5b2a38006bac05da7582796d

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

Failed to run command "/bin/sh -c 'set -e \n[ -d '''/home/build''' ] || mkdir -p '''/home/build''\ncd '''/home/build''\nseries='''\nif [ -z $series ]; then\n\tif [ -n '''support-connection_pool-3.0.patch''' ]; then\n\t\tseries=$(mktemp)\n\t\techo '''support-connection_pool-3.0.patch''' | awk '''{ for(i = 1; i <= NF; i++) { print $i; } }''' >$series\n\telse\n\t\techo "ERROR: Neither patches or series was set."\n\t\texit 1\n\tfi\nfi\ngrep -v -E '''^(#|$)''' $series | (while read patchfile; do\n\tpatch '''-p1''' --fuzz=2 --verbose <$patchfile\ndone)\n\nexit 0'": Process exited with status 1

Build Details

Category	Details
Build System	melange
Failure Point	patch step in melange pipeline - applying support-connection_pool-3.0.patch

Root Cause Analysis 🔍

All hunks in the patch file were rejected because the patch appears to be reversed or already applied. The patch system detected that the changes were already present in the source code, causing all 4 files (pool.rb, timed_stack_multi.rb, gemspec, and test file) to have their hunks ignored and saved as .rej files. The patch step uses 'set -e' which causes the shell to exit with status 1 when any command fails.

---

🔍 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

• python-3.10/3.10.19 package update #68487
• ruby3.4-rubyzip/3.0.1 package update #62073

Suggested Changes

File: ruby4.0-net-http-persistent.yaml

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

version: "4.0.8"

Replacement:

version: "4.0.9"

Content:

Update package version to 4.0.9 to get upstream fixes

• commit_update at line 22 (pipeline[0].with.expected-commit)
  Original:

expected-commit: 66bf49c4cb990b7a5b2a38006bac05da7582796d

Replacement:

expected-commit: [new commit hash for v4.0.9]

Content:

Update expected commit to match v4.0.9 tag

• removal at line 26-28 (pipeline patch step)
  Original:

- uses: patch
    with:
      patches: support-connection_pool-3.0.patch

Content:

Remove the entire patch step since the patch is no longer needed in the newer version

File: ruby4.0-net-http-persistent/support-connection_pool-3.0.patch

• file_deletion at line all (entire file)
  Original:

[entire patch file contents]

Replacement:

[delete file]

Content:

Delete the patch file since it's no longer needed

Click to expand fix analysis

Analysis

Looking at the three similar fixes, there's a clear pattern: when patches fail to apply because they're "already applied" or "reversed", the solution is to update the package to a newer version where the patch is no longer needed, and then remove the patch file and patch step entirely. In Fix Example #0, the version was updated from 21.0.11 to 21.1.2 and the patch was updated. In Fix Example #1, Python was updated from 3.10.18 to 3.10.19 and the problematic gh-135462.patch was removed. In Fix Example #2, rubyzip was updated from 3.0.0 to 3.0.1 and the gh636.patch was completely removed along with the patch pipeline step.

Click to expand fix explanation

Explanation

This fix addresses the root cause of the patch failure. When a patch fails with "already applied" or "reversed" errors, it typically means the changes in the patch have been incorporated into the upstream codebase in a newer version. The upstream changelog shows that version 4.0.8 includes significant changes around CGI dependencies, which likely conflicts with or supersedes whatever the support-connection_pool-3.0.patch was trying to accomplish. By updating to a newer version (4.0.9 if available, or checking what the latest version is), the changes that the patch was trying to make are likely already included upstream. This follows the Wolfi principle of keeping packages up to date with upstream releases. The pattern from all three similar fixes shows this is the standard approach: update the version, update the commit hash, and remove the problematic patch entirely.

Click to expand alternative approaches

Alternative Approaches

• If version 4.0.9 doesn't exist, check if there are any newer patch versions or pre-release versions that include the needed fixes
• Examine the actual content of support-connection_pool-3.0.patch to understand what it's trying to do, then check if those changes are already present in the current 4.0.8 codebase - if so, simply remove the patch without version update
• If the patch is still needed but conflicts, update the patch file to apply cleanly against the current codebase, but this is less preferred than removing it entirely
• Investigate if the patch can be replaced with a build-time configuration change or environment variable instead of source code modification

---

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