November 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:118923] [Ruby master Bug#20690] URI.encode_www_form_component method escapes tilde when it's not supposed to
by y4m4p (Masahiro Yamashita) 06 Dec '24

06 Dec '24

Issue #20690 has been reported by y4m4p (Masahiro Yamashita). ---------------------------------------- Bug #20690: URI.encode_www_form_component method escapes tilde when it's not supposed to https://bugs.ruby-lang.org/issues/20690 * Author: y4m4p (Masahiro Yamashita) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin21] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ## Problem As the title says, `Uri.encode_www_form_component` is escaping tilde (`~`) where it should not according to the RFC3986. Ref: https://datatracker.ietf.org/doc/html/rfc3986#section-2.3 There was a previous issue with the same problem, https://bugs.ruby-lang.org/issues/6696 which has been resolved and merged. --- Since `URI.escape` is now obsolete and gone, the preferred way to escape URI characters are to choose from the following methods. - `URI.encode_www_form_component` (or, `URI.encode_www_form` which uses this) - `CGI.escape` - `ERB::Util.#url_encode` - `WEBrick::HTTPUtils.#escape_form` - `WEBrick::HTTPUtils.#escape` This issue does not occur when using any of the methods except `URI.encode_www_form_component`. These preferred options are not compatible with each other, making it a poor experience for Ruby users. ### Minimum replication ``` ruby # URI irb(main):002:0> require 'uri' => true irb(main):004:0> URI.encode_www_form_component("ruby~test") => "ruby%7Etest" # CGI irb(main):001:0> require 'cgi' => true irb(main):003:0> CGI.escape("ruby~test") => "ruby~test" # ERB irb(main):009:0> require 'erb' => true irb(main):012:0> ERB::Util.url_encode("ruby~test") => "ruby~test" # Webrick # needs webrick gem installed [3] pry(main)> require 'webrick' => true [4] pry(main)> WEBrick::HTTPUtils.escape_form("ruby~test") => "ruby~test" [5] pry(main)> WEBrick::HTTPUtils.escape("ruby~test") => "ruby~test" ``` ## Real world use-case problem I have a use-case problem with using URI when implementing a OIDC with PKCE client / server setup. When trying to generate a GET URI for Open ID Connect with PKCE, you need to provide a `code_verifier` value to the Authorization server, which actually requires you to use the tilde without escaping. Ref: https://www.oauth.com/oauth2-servers/pkce/authorization-request/ > When the native app begins the authorization request, instead of immediately launching a browser, the client first creates what is known as a “code verifier“. This is a cryptographically random string using the characters A-Z, a-z, 0-9, and the punctuation characters -._~ (hyphen, period, underscore, and tilde), between 43 and 128 characters long. The inconsistent encoding is problematic for the Server and Client both, since both ends needs to have an agreement on using tilde as an escaped character or an unescaped character. Logically speaking, `~` should be sent AS-IS and not to be escaped, since the `code_challenge` value and `code_verifier` values are strictly checked using a Hash generation function `Digest::SHA256.digest`, which generates a different Hash value depending on `~`(non escaped) or `%7E`(escaped). These parameters from user inputs are usually not meant to be tampered with for security sake, so it's best to have tilde `~` to be unescaped from the beginning. ## Related issues - https://bugs.ruby-lang.org/issues/6696 - This seems to have been resolved and merged. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:111434] [Ruby master Feature#19261] `Data#members` is not important
by ko1 (Koichi Sasada) 04 Dec '24

04 Dec '24

Issue #19261 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #19261: `Data#members` is not important https://bugs.ruby-lang.org/issues/19261 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- `Data#members` is defined but it is calculated by `self.class.members` (in other words, `#members` is a shorthand for `self.class.members`). So it is better to remove this method. ```ruby P = Data.define(:x, :y) p P.new(1, 2).members #=> [:x, :y] Group = Data.define(:name, :members) gs = Group.new('SasadaFamily', %w(ko1 yuki)) p gs.members #=> ["ko1", "yuki"] ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:119513] [Ruby master Bug#20795] Timeout method doesn't check for negative time values
by kanakchaudhari12 (kanak chaudhari) 03 Dec '24

03 Dec '24

Issue #20795 has been reported by kanakchaudhari12 (kanak chaudhari). ---------------------------------------- Bug #20795: Timeout method doesn't check for negative time values https://bugs.ruby-lang.org/issues/20795 * Author: kanakchaudhari12 (kanak chaudhari) * Status: Open * ruby -v: 3.1.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'timeout' # Case 1: Negative timeout with quick execution Timeout.timeout(-5) do puts "This should not execute" end # Case 2: Negative timeout with sleep Timeout.timeout(-5) do sleep(10) end ``` Potential issues with current behaviour: * Inconsistency: The behaviour differs based on the block's content, which may not be immediately apparent * Silent failure: The negative timeout is silently ignored, potentially masking logical errors in the calling code. * Unexpected source of error: one might expect the timeout method to validate its input, rather than relying on methods called within the block to catch invalid time values. I suggest this change for the consistent behaviour regardless of code-block as well as the clear indication of the source of the error ```ruby def timeout(sec, klass = nil, message = nil, &block) raise ArgumentError, "timeout must be positive" if sec.is_a?(Numeric) && sec < 0 # ... end ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:120033] [Ruby master Bug#20916] Prism compiler should support ** in Ractor constant
by mame (Yusuke Endoh) 03 Dec '24

03 Dec '24

Issue #20916 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20916: Prism compiler should support ** in Ractor constant https://bugs.ruby-lang.org/issues/20916 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * ruby -v: ruby 3.4.0dev (2024-11-28T02:34:20Z avoid-uninitialize.. 79ae6e72c8) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The Prism compiler raises an exception against the following code. ``` $ ./miniruby -e '# shareable_constant_value: experimental_everything C = { **{ } }' -e:2: Ractor constant writes do not support ** -e: node type not implemented (NotImplementedError) ``` But the traditional compiler support it, and @ko1 said it should be supported. Also, I feel that this error message `node type not implemented` is a sign of a worse problem. Actually, valgrind reports `Conditional jump or move depends on uninitialised value(s)`against the Prism compiler. An assertion failure is also reported. ``` $ valgrind ./miniruby -e '# shareable_constant_value: experimental_everything C = { **{ } }' ==49978== Memcheck, a memory error detector ==49978== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==49978== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==49978== Command: ./miniruby -e #\ shareable_constant_value:\ experimental_everything_C\ =\ {\ **{\ }\ } ==49978== ==49978== Warning: set address range perms: large range [0x64e0000, 0x1e4e0000) (defined) -e:2: Ractor constant writes do not support ** ==49978== Conditional jump or move depends on uninitialised value(s) ==49978== at 0x4BB42A: pm_newline_list_line (pm_newline_list.c:63) ==49978== by 0x1E718A: pm_compile_shareable_constant_value (prism_compile.c:5280) ==49978== by 0x1E7243: pm_compile_shareable_constant_value (prism_compile.c:5318) ==49978== by 0x1E8DC1: pm_compile_constant_write_node.isra.0 (prism_compile.c:5372) ==49978== by 0x1DCB2F: pm_compile_node (prism_compile.c:9823) ==49978== by 0x1DC9C8: pm_compile_node (prism_compile.c:9934) ==49978== by 0x1F3AC9: pm_compile_scope_node.isra.0 (prism_compile.c:6603) ==49978== by 0x1DA66A: pm_compile_node (prism_compile.c:9805) ==49978== by 0x1F61A7: pm_iseq_compile_node (prism_compile.c:10109) ==49978== by 0x2A5303: pm_iseq_new_with_opt_try (iseq.c:1027) ==49978== by 0x23DFF2: rb_protect (eval.c:1033) ==49978== by 0x2AB198: pm_iseq_new_with_opt (iseq.c:1080) ==49978== miniruby: prism/util/pm_newline_list.c:63: pm_newline_list_line: Assertion `cursor >= list->start' failed. ==49978== ==49978== Process terminating with default action of signal 6 (SIGABRT) ==49978== at 0x4AFAB1C: __pthread_kill_implementation (pthread_kill.c:44) ==49978== by 0x4AFAB1C: __pthread_kill_internal (pthread_kill.c:78) ==49978== by 0x4AFAB1C: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89) ==49978== by 0x4AA126D: raise (raise.c:26) ==49978== by 0x4A848FE: abort (abort.c:79) ==49978== by 0x4A8481A: __assert_fail_base.cold (assert.c:94) ==49978== by 0x4A97506: __assert_fail (assert.c:103) ==49978== by 0x4BB49B: pm_newline_list_line (pm_newline_list.c:63) ==49978== by 0x1E718A: pm_compile_shareable_constant_value (prism_compile.c:5280) ==49978== by 0x1E7243: pm_compile_shareable_constant_value (prism_compile.c:5318) ==49978== by 0x1E8DC1: pm_compile_constant_write_node.isra.0 (prism_compile.c:5372) ==49978== by 0x1DCB2F: pm_compile_node (prism_compile.c:9823) ==49978== by 0x1DC9C8: pm_compile_node (prism_compile.c:9934) ==49978== by 0x1F3AC9: pm_compile_scope_node.isra.0 (prism_compile.c:6603) ==49978== ==49978== HEAP SUMMARY: ==49978== in use at exit: 2,645,494 bytes in 10,084 blocks ==49978== total heap usage: 36,662 allocs, 26,578 frees, 6,066,537 bytes allocated ==49978== ==49978== LEAK SUMMARY: ==49978== definitely lost: 0 bytes in 0 blocks ==49978== indirectly lost: 0 bytes in 0 blocks ==49978== possibly lost: 1,050,576 bytes in 4 blocks ==49978== still reachable: 1,594,918 bytes in 10,080 blocks ==49978== suppressed: 0 bytes in 0 blocks ==49978== Rerun with --leak-check=full to see details of leaked memory ==49978== ==49978== Use --track-origins=yes to see where uninitialised values come from ==49978== For lists of detected and suppressed errors, rerun with: -s ==49978== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Aborted (core dumped) ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120034] [Ruby master Bug#20917] redo/next in nested begin block causes wrong order of execution
by hoshiumiarata (Arata Hoshiumi) 02 Dec '24

02 Dec '24

Issue #20917 has been reported by hoshiumiarata (Arata Hoshiumi). ---------------------------------------- Bug #20917: redo/next in nested begin block causes wrong order of execution https://bugs.ruby-lang.org/issues/20917 * Author: hoshiumiarata (Arata Hoshiumi) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It seems that `redo`/`next` in a nested `begin` block can cause the wrong order of execution. For example: ```ruby for _ in [0] puts 0 begin puts 1 begin puts 2 redo ensure puts 3 end ensure puts 4 break end end ``` It prints: ``` 0 1 2 3 4 3 4 => nil ``` But I think it should print: ``` 0 1 2 3 4 => nil ``` Because execution order should be: 1. `puts 0` 2. `puts 1` 3. `puts 2` 4. `redo` 5. unwind to nested `ensure` block 6. `puts 3` 7. unwind to outer `ensure` block 8. `puts 4` 9. `break` 10. end of loop Interestingly enough, if we add an empty `rescue` block before any of the `ensure` blocks, then the execution order is correct. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120002] [Ruby master Bug#20908] Ruby extension builds fail with GCC 15 which defaults to -std=gnu23
by thesamesam (Sam James) 01 Dec '24

01 Dec '24

Issue #20908 has been reported by thesamesam (Sam James). ---------------------------------------- Bug #20908: Ruby extension builds fail with GCC 15 which defaults to -std=gnu23 https://bugs.ruby-lang.org/issues/20908 * Author: thesamesam (Sam James) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi! Upcoming GCC 15 defaults to C23 (`-std=gnu23`). One thing C23 changes is removing unprototyped functions, so `void foo()` now means `void foo(void)`, rather than "any arguments". Ruby extensions fail to build as a result with GCC 15. This was reported downstream in Gentoo at https://bugs.gentoo.org/943784 where brotli-0.6.0 is an example: ``` make: Entering directory '/var/tmp/portage/dev-ruby/brotli-0.6.0/work/ruby32/brotli-0.6.0/ext/brotli' x86_64-pc-linux-gnu-gcc -I. -I/usr/include/ruby-3.2.0/x86_64-linux -I/usr/include/ruby-3.2.0/ruby/backward -I/usr/include/ruby-3.2.0 -I. -DHAVE_BROTLI_DECODE_H -DHAVE_BROTLI_ENCODE_H -fPIC -O2 -pipe -march=native -fno-diagnostics-color -o brotli.o -c brotli.c In file included from /usr/include/ruby-3.2.0/ruby/ruby.h:27, from /usr/include/ruby-3.2.0/ruby.h:38, from brotli.h:4, from brotli.c:1: brotli.c: In function ‘Init_brotli’: /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:363:45: error: passing argument 3 of ‘rb_define_singleton_method_m1’ from incompatible pointer type [-Wincompatible-pointer-types] 363 | # define RUBY_METHOD_FUNC(func) RBIMPL_CAST((VALUE (*)(ANYARGS))(func)) | ^ | | | VALUE (*)(void) {aka long unsigned int (*)(void)} /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:308:144: note: in definition of macro ‘rb_define_singleton_method’ 308 | #define rb_define_singleton_method(obj, mid, func, arity) RBIMPL_ANYARGS_DISPATCH_rb_define_singleton_method((arity), (func))((obj), (mid), (func), (arity)) | ^~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:363:33: note: in expansion of macro ‘RBIMPL_CAST’ 363 | # define RUBY_METHOD_FUNC(func) RBIMPL_CAST((VALUE (*)(ANYARGS))(func)) | ^~~~~~~~~~~ brotli.c:478:55: note: in expansion of macro ‘RUBY_METHOD_FUNC’ 478 | rb_define_singleton_method(rb_mBrotli, "deflate", RUBY_METHOD_FUNC(brotli_deflate), -1); | ^~~~~~~~~~~~~~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:271:21: note: expected ‘VALUE (*)(int, union <anonymous>, VALUE)’ {aka ‘long unsigned int (*)(int, union <anonymous>, long unsigned int)’} but argument is of type ‘VALUE (*)(void)’ {aka ‘long unsigned int (*)(void)’} 271 | RBIMPL_ANYARGS_DECL(rb_define_singleton_method, VALUE, const char *) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/ruby-3.2.0/ruby/internal/anyargs.h:254:41: note: in definition of macro ‘RBIMPL_ANYARGS_DECL’ 254 | RBIMPL_ANYARGS_ATTRSET(sym) static void sym ## _m1(__VA_ARGS__, VALUE(*)(int, union { VALUE *x; const VALUE *y; } __attribute__((__transparent_union__)), VALUE), int); \ | ^~~ ``` The `ANYARGS` macro can't work in its current form, as defined at e.g. https://github.com/ruby/ruby/blob/f127bcb8294fd417c253dd7acab3ff3b9f0bf555/…: ``` #ifndef ANYARGS # ifdef __cplusplus # define ANYARGS ... # else # define ANYARGS # endif #endif ``` ... because of the change in C23 I mentioned above, i.e. `(ANYARGS)` being `()` now means no arguments, not any. I note that Ruby was adapted in part already for this change, see e.g. https://github.com/ruby/ruby/commit/4e64edb6cd8d1b444c591bfd50ec3d357e794f6e, but it appears that the headers that extensions need to build against aren't yet ready. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:119942] [Ruby master Bug#20898] Backport https://github.com/ruby/ruby/pull/9737 to Ruby 3.3 and 3.2
by katei (Yuta Saito) 30 Nov '24

30 Nov '24

Issue #20898 has been reported by katei (Yuta Saito). ---------------------------------------- Bug #20898: Backport https://github.com/ruby/ruby/pull/9737 to Ruby 3.3 and 3.2 https://bugs.ruby-lang.org/issues/20898 * Author: katei (Yuta Saito) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The memory corruption issue on Wasm led to mysterious crashes and [consumed much debugging time](https://github.com/ruby/ruby.wasm/issues/555). It's nice to backport the fix to save developers time. https://github.com/ruby/ruby/pull/9737 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120016] [Ruby master Feature#20912] Move warning when redefining object_id to __id__
by jhawthorn (John Hawthorn) 30 Nov '24

30 Nov '24

Issue #20912 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #20912: Move warning when redefining object_id to __id__ https://bugs.ruby-lang.org/issues/20912 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- Currently if you create a class and redefine or remove either `object_id` or `__send__` it will issue a warning. There's no such warning on `__id__`. ``` ❯ ruby -we 'class << Object.new; def object_id = 1; end' -e:1: warning: redefining `object_id' may cause serious problems ❯ ruby -we 'class << Object.new; def __id__ = 1; end' ❯ ``` It makes sense that there's no warning on `send`, because we expect `__send__` to be the method reliably available. `__send__` is on `BasicObject`, `send` is only on `Kernel`. This seems a little inconsistent that `object_id` warns while `__id__` does not warn. `__id__` is the equivalent to `__send__` as it's also on `BasicObject`, where `object_id` is only on `Kernel`. This may be a more obvious problem in Ruby 3.4.0 as commit:cffd380390967d17899fde0a81f5151ae6ddd076 makes the warning print in more cases. I propose we change this warning to be emitted only when `__id__` is redefined and not when `object_id` is redefined: **Proposed behaviour:** ``` ❯ ruby -we 'class << Object.new; def object_id = 1; end' ❯ ruby -we 'class << Object.new; def __id__ = 1; end' -e:1: warning: redefining `__id__' may cause serious problems ❯ ``` -- https://bugs.ruby-lang.org/

6 10

[ruby-core:120055] [Ruby master Misc#20923] Add builds for existing shared GC's to CI
by eightbitraptor (Matt V-H) 29 Nov '24

29 Nov '24

Issue #20923 has been reported by eightbitraptor (Matt V-H). ---------------------------------------- Misc #20923: Add builds for existing shared GC's to CI https://bugs.ruby-lang.org/issues/20923 * Author: eightbitraptor (Matt V-H) * Status: Open ---------------------------------------- ## Summary I'd like to add CI builds that exercise the GC API implementation with the currently supported known GC modules. Implemented in [[GH-#12212]](https://github.com/ruby/ruby/pull/12212) ## Background Ruby now ships with a GC API, through which GC implementations communicate with the VM. By default the existing Ruby GC is compiled into the released binaries as it always has been. Optionally, the Ruby GC can be compiled as a shared object and loaded through the API. Ruby also provides a second GC implementation based on MMTk that can also be built as a module and loaded through the API. The MMTk implementation is being developed in the `ruby/mmtk` repository and synced into `ruby/ruby` using the existing gem syncing mechanisms. Currently the Ruby CI exercises that it can build the default GC as a shared object, but it doesn't exercise whether it can load a shared GC correctly. ## Implementation The attached ticket provides Github Actions workflows that: - build Ruby with shared GC support - build both provided GC's as shared objects - run `make check` with both modular GC libraries It's important to note that this CI workflow will only test code that is directly included in the `ruby/ruby` repository. MMTk development work will be happening inside `ruby/mmtk` so these changes will be fully tested there. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118003] [Ruby master Bug#20506] Failure compiling Ruby 3.4.0-preview1 on aarch64 on a mac and linux (Ubuntu 24.04)
by schneems (Richard Schneeman) 29 Nov '24

29 Nov '24

Issue #20506 has been reported by schneems (Richard Schneeman). ---------------------------------------- Bug #20506: Failure compiling Ruby 3.4.0-preview1 on aarch64 on a mac and linux (Ubuntu 24.04) https://bugs.ruby-lang.org/issues/20506 * Author: schneems (Richard Schneeman) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I was unable to compile Ruby 3.4.0-preview1 on Ubuntu 24.04 via Github Actions. As the logs are not retained indefinitely here's a link to the compilation failure: https://gist.github.com/schneems/bc6bdd6fba08ff6bfdd1bce8d76c457d The relevant errors seem to be in linking yjit: ``` touch yjit/target/release/libyjit.a partial linking yjit/target/release/libyjit.a into yjit/target/release/libyjit.o linking miniruby /usr/bin/ld: yjit/target/release/libyjit.o: in function `__multc3': /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:33:(.text.__multc3+0x30c): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:34:(.text.__multc3+0x394): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:42:(.text.__multc3+0x7f4): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:43:(.text.__multc3+0x864): undefined reference to `__builtin_copysignq' /usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:47:(.text.__multc3+0x8c4): undefined reference to `__builtin_copysignq' /usr/bin/ld: yjit/target/release/libyjit.o:/cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:38: more undefined references to `__builtin_copysignq' follow collect2: error: ld returned 1 exit status make: *** [Makefile:298: miniruby] Error 1 /tmp/lib/build_script.rb:118:in `pipe': Command failed debugflags="-g" ./configure --disable-install-doc --prefix /tmp/d20240524-1-bdq0bj/prefix --enable-load-relative --enable-shared --enable-yjit && make -j16 && make install (RuntimeError) from /tmp/lib/build_script.rb:158:in `block in build' from /tmp/lib/build_script.rb:152:in `chdir' from /tmp/lib/build_script.rb:152:in `build' from /tmp/lib/build_script.rb:65:in `block in run_build_script' from /usr/lib/ruby/3.2.0/tmpdir.rb:94:in `mktmpdir' from /tmp/lib/build_script.rb:61:in `run_build_script' from /tmp/build.rb:8:in `<main>' ``` Here's the GHA link: https://github.com/heroku/docker-heroku-ruby-builder/actions/runs/922553814…. This is the Dockerfile for Ubuntu 24.04 https://github.com/heroku/docker-heroku-ruby-builder/blob/73bdda974811717ba…. I'm able to reproduce the failure locally: ``` $ git clone https://github.com/heroku/docker-heroku-ruby-builder $ cd docker-heroku-ruby-builder $ export DOCKER_DEFAULT_PLATFORM=linux/arm64 $ bin/activate_docker heroku-24 $ bin/build_ruby heroku-24 3.4.0-preview1 # Fails ``` Full output https://gist.github.com/schneems/cfa21847228d48e6bbe27463deae6745. I'm also seeing failures when using `ruby-install` on my mac (ARM), the error message is different so I'm not sure if it's the same problem or unrelated: https://gist.github.com/schneems/12af87e967126c7bfa319645b00015b3 -- https://bugs.ruby-lang.org/

6 11