Nice, thx for the summary and a few remarks inline.
Dne 29. 10. 23 v 9:09 Mamoru TASAKA napsal(a):
Isn't this some RegExp / GC thing seeint this part of backtrace:
~~~
/lib64/libruby.so.3.3(rb_st_foreach+0x85) [0x7f2fc3b24285]
/lib64/libruby.so.3.3(onig_names_free+0x27) [0x7f2fc3b10807]
/lib64/libruby.so.3.3(onig_free+0x1a) [0x7f2fc3b035fa]
/lib64/libruby.so.3.3(0x7f2fc3a24022) [0x7f2fc3a24022]
/lib64/libruby.so.3.3(0x7f2fc3c1e048) [0x7f2fc3c1e048]
/lib64/libruby.so.3.3(0x7f2fc3a21f23) [0x7f2fc3a21f23]
/lib64/libruby.so.3.3(0x7f2fc3a2a39b) [0x7f2fc3a2a39b]
/lib64/libruby.so.3.3(0x7f2fc3a2a7be) [0x7f2fc3a2a7be]
/lib64/libruby.so.3.3(rb_wb_protected_newobj_of+0x74) [0x7f2fc3a2b0a4]
~~~
5.
rubygem-bootsnap
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/...
```
1) Failure:
Bootsnap::KernelRequireTest#test_uses_the_same_duck_type_as_require
[/builddir/build/BUILD/bootsnap-1.15.0/usr/share/gems/gems/bootsnap-1.15.0/test/load_path_cache/core_ext/kernel_require_test.rb:26]:
Expected #<Process::Status: pid 1413 exit 1> to be success?.
```
I don't know what this means. With ruby 7b8d472100 (around 2023-10-06)
test was successful,
but with ruby 55c5ebe0a0 (around 2023-10-14) test test fails, not sure
what ruby change caused
this.
Looking at the test case, wouldn't it be enough to remove the `fork` [1]
to get more information? Of course it would fail the rest of test suite ....
[1]
https://github.com/Shopify/bootsnap/blob/c78981903d958ceacdaec843b9832add...
Seems to be just one test case:
https://github.com/enkessler/childprocess/blob/44227922488765ebad0c0bed0f...
We could skip the test temporary.
8.
rubygem-clockwork
https://copr.fedorainfracloud.org/coprs/mtasaka/rubygem-newruby-test-3-2/...
`<internal:/usr/share/rubygems/rubygems/core_ext/kernel_require.rb>:128:in
`require': cannot load such file -- mocha/setup (LoadError)`
This mocha issue is already fixed in
https://github.com/Rykian/clockwork/pull/64/ .
Looks like in addition Minitest issue needs fixing.
And leaf package. I am fine breaking and have it removed afterwards,
unless @Pavel Valena cares ...
Vít