Onboard ruby 3.4.11: patches fail to apply #116

Activity

1. ronaldtse commented on Oct 8, 2026

   

   ronaldtse

   on Oct 8, 2026

   Contributor

   More actions

   Diagnosis (triage across the duplicate filings)

   All fifteen filings report the same three failing patches. I fetched the official ruby-3.4.10.tar.gz / ruby-3.4.11.tar.gz tarballs and tested every patch variant against pristine trees with git apply --check. Result: only one of the three failures is caused by an upstream change in 3.4.11, and even that one does not need a rebase. The root cause is patch-selection/manifest coverage for the new patch level.

   1. prism_compile_memfs.patch — fails at prism_compile.c:1 (first hunk, @@ -1,5)

   Selection gap, not new drift. The manifest pins prism_compile_memfs_6.patch for versions "6"–"10". For 3.4.11 no version: "11" entry exists, so selection falls back to the stale whole-line body, which was written for 3.4.0–3.4.5 context (#include "prism.h" at line 1; 3.4.6 added #include "version.h" at line 2 — hence the _6 variant). Upstream 3.4.11 did change prism_compile.c (new VM_CALL_KW_LEN_MAX "too many keyword arguments/parameters" compile errors, and a PM_KEYWORD_HASH_NODE rework for assoc splats via pm_compile_hash_elements), but none of those hunks overlap the tebako block.

   Verified: prism_compile_memfs_6.patch applies cleanly to pristine 3.4.11.

   Fix: extend the partition — add to patches/3.4/patch-3.4.yaml:

     - feature: prism_compile_memfs
       file: prism_compile_memfs_6.patch
       version: "11"

   2. openssl_extconf_ruby_export_msys.patch — fails at ext/openssl/extconf.rb:208 (@@ -208,8 hunk)

   Selection gap, not new drift. The 3.4.10 bundled-openssl-gem bump inserted have_func("ASN1_BIT_STRING_set1(NULL, NULL, 0, 0)", ...) ("added in 4.0.0") right after the patch's anchor, moving the region to line 213 — that is why openssl_extconf_ruby_export_msys_10.patch exists with version: "10". ext/openssl/extconf.rb is byte-identical between 3.4.10 and 3.4.11, so the whole-line body selected for 3.4.11 fails while _10 applies cleanly.

   Fix: extend the partition — add:

     - feature: openssl_extconf_ruby_export_msys
       file: openssl_extconf_ruby_export_msys_10.patch
       version: "11"

   3. openssl_ssl_default_store_crl_removal.patch — fails at ext/openssl/lib/openssl/ssl.rb:92

   Obsolete patch carried forward. This one reaches the audit via the onboarder's overlay carry-forward (nearest lower overlay = patch-3.4.7.yaml → ../3.1/openssl_ssl_default_store_crl_removal.patch). The patch deletes DEFAULT_CERT_STORE.flags = OpenSSL::X509::V_FLAG_CRL_CHECK_ALL; since 3.4.8 the vendored openssl gem already ships without that line (the upstream removal the patch mirrors), so there is nothing to remove and the context no longer matches. ssl.rb is byte-identical between 3.4.10 and 3.4.11 — the patch fails on both; it simply wasn't carried into the 3.4.8–3.4.10 onboardings.

   Fix: the patch should become nothing — the feature is obsolete for 3.4.8+. Do not carry the 3.4.7 overlay into 3.4.11 (no patch-3.4.11.yaml with this feature). Note the onboarder's carry-forward audits candidates fatally and cannot express "overlay intentionally ends at 3.4.7" — worth a follow-up so the next line-crossing doesn't re-file this same failure.

   Verification matrix (pristine trees, git apply --check)

   patch	3.4.10	3.4.11
   openssl_extconf_ruby_export_msys.patch (whole-line)	FAIL	FAIL
   openssl_extconf_ruby_export_msys_10.patch	OK	OK
   prism_compile_memfs.patch (whole-line)	FAIL	FAIL
   prism_compile_memfs_6.patch	OK	OK
   openssl_ssl_default_store_crl_removal.patch	FAIL	FAIL

   Net: 3.4.11 onboards with two manifest lines added (version: "11" entries pointing at the _10 / _6 bodies) and no overlay carry. No patch rebase is needed.

   ---

   This is the canonical issue for the 3.4.11 onboarding failure; the duplicate filings are being closed now that the release monitor dedups repeat filings.
2. ronaldtse commented on Oct 8, 2026

   

   ronaldtse

   on Oct 8, 2026

   Contributor

   More actions

   The manifest fix is merged: #136 (squash 6e7c84b).

   Following the diagnosis above, no patch body was rebased. patches/3.4/patch-3.4.yaml pins prism_compile_memfs → prism_compile_memfs_6.patch and openssl_extconf_ruby_export_msys → openssl_extconf_ruby_export_msys_10.patch at version: "11" (both bodies verified to apply cleanly to pristine 3.4.11; 3.4.10's selection is byte-identical before/after), and the CRL-removal entry in patches/3.4/patch-3.4.7.yaml now carries until: "7" — a new optional overlay-entry bound (schema + Tfs::PatchManifest::Entry#carriable_to?) under which the onboarder drops the entry from the carry once the target patch level passes the bound, reports the feature on the result as dropped, and preserves the bound across carries so the end is permanent. Verified end-to-end locally with the real monitor flow against the sha256-verified official tarball: applied: true, failing: [], dropped: ["openssl_ssl_default_store_crl_removal"], no overlay written; tools/lint clean for 3.4.11 and 3.4.10 (34 patches each); tools/compile_smoke green for both (darwin, 8 patched translation units each); bundle exec rspec 121 examples, 0 failures; the PR's per-version lint matrix ran green across every onboarded version.

   The next release-monitor run should now onboard 3.4.11 (pin versions.yml, no overlay carry) and open its onboarding PR instead of filing; this issue stays open until that run is green.
3. ronaldtse commented on Oct 12, 2026

   

   ronaldtse

   on Oct 12, 2026

   Contributor

   More actions

   Resolved by #139 (merged): the 3.4.11 patch set is onboarded with git apply --check clean across the resolved set, the lint matrix green on merge. The tfs-ruby-3.4.11-src tarball builds on the next tag per the release-src flow.
4. ronaldtse

   closed this as completedon Oct 12, 2026