Because setting the option makes some tests stable that are currently randomly
failing with error on especially s390x and aarch64.
We observed the failing tests are calling `assert_in_out_err` method
calling `invoke_ruby` calling method.
Then when the `th_stdout.join(timeout)` or `th_stderr.join(timeout)` returns
`nil` as thread timeout in `invoke_ruby` method, it causes the error. [1][2]
The `test_timeout_scale` macro is to set the environment variable
`RUBY_TEST_TIMEOUT_SCALE` to increase the timeout in `apply_timeout_scale`
method as <new timeout> = <timeout> * <timeout scale>.
As an example, `TestBugReporter#test_bug_reporter_add` test's
maximum thread timeout was 56+ seconds for the default timeout 10 seconds. [3]
In this case setting `RUBY_TEST_TIMEOUT_SCALE=6` (6 * 10 = 60) is good enough
for 56+ seconds.
[1] https://github.com/ruby/ruby/blob/v2_7_1/tool/lib/envutil.rb#L149
[2] https://bugs.ruby-lang.org/issues/16492#note-8
[3] https://bugs.ruby-lang.org/issues/16492#note-4
Independent rubygems package used to provide rubygems-devel subpackages,
but this is going to change to ease the independent rubygems package
maitenance and therefore ruby package will become the ultimate source of
rubygems-devel package.
It is increasingly hard to maintain default gems extracted from StdLib
into gems. If they are overlapped by independent versions, it is even
harder, because the overlapped versions would need to provide symlinks
back to StdLib \[[1]\]. On top of that, the layout differs from
upstream, where default gems are always available.
Because these small nuances can make hard discoverable race conditions
during Ruby application loading and runtime, it will be best to keep the
default gems bundled.
[1]: https://src.fedoraproject.org/rpms/rubygem-racc/pull-request/1
This is needed to compile zlib support. I think it is by accident available in the original buildroot, but not in mine.
I think it is better to explicitly name it.
During update, RPM cannot simply replace directory by link to direcotry,
therefore create the directory structure and link the files there one by
one (rhbz#1691039).
This avoids issues running `$ bin/rails console --sandbox`, which
otherwise breaks with error such as:
~~~
$ bin/rails console --sandbox
Traceback (most recent call last):
12: from bin/rails:4:in `<main>'
11: from bin/rails:4:in `require'
10: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/commands.rb:18:in `<top (required)>'
9: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/command.rb:44:in `invoke'
8: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/command.rb:70:in `find_by_namespace'
7: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/command/behavior.rb:79:in `lookup'
6: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/command/behavior.rb:79:in `each'
5: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/command/behavior.rb:80:in `block in lookup'
4: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/command/behavior.rb:80:in `each'
3: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/command/behavior.rb:84:in `block (2 levels) in lookup'
2: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/command/behavior.rb:84:in `require'
1: from /builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/commands/console/console_command.rb:3:in `<top (required)>'
/builddir/.gem/ruby/gems/railties-5.2.2.1/lib/rails/commands/console/console_command.rb:3:in `require': cannot load such file -- irb (LoadError)
~~~
