On macOS, `dsymutil` utility splits debug info into .dSYM directory.
Glob list of `.bundle/cache/extensions/**/*binary_c*` includes that
directory but `FileUtils.rm` fails to unlink a directory.
https://github.com/ruby/ruby/actions/runs/8149918901/job/22275331688#step:11:3000
```
Operation not permitted @ apply2files - /Users/runner/work/ruby/ruby/src/tmp/2/home/.bundle/cache/extensions/arm64-darwin-22/ruby/3.4.0+0/3b02a1011c53518f911ab3a9e8c6c608/very_simple_binary-1.0/very_simple_binary_c.bundle.dSYM
# ./lib/fileutils.rb:2332:in 'File.unlink'
# ./lib/fileutils.rb:2332:in 'block in FileUtils::Entry_#remove_file'
# ./lib/fileutils.rb:2337:in 'FileUtils::Entry_#platform_support'
# ./lib/fileutils.rb:2331:in 'FileUtils::Entry_#remove_file'
# ./lib/fileutils.rb:1475:in 'FileUtils.remove_file'
# ./lib/fileutils.rb:1223:in 'block in FileUtils.rm'
# ./lib/fileutils.rb:1222:in 'FileUtils.rm'
# ./spec/bundler/install/global_cache_spec.rb:235:in 'block (3 levels) in <top (required)>'
```
https://github.com/rubygems/rubygems/commit/375c127684
The `RUBY_CODESIGN` environment variable is used by mkmf-generated
Makefile to sign extension bundles on macOS. The variable specifies a
key identifier to use for signing given by the user. However, the key
is usually stored in `$HOME/Library/Keychains` directory, and the test
suite creates a fake `$HOME` directory. This causes the test suite to
try to find the specified key from the fake home directory, which
results in a failure.
https://github.com/rubygems/rubygems/commit/ddcfc65bf7
The documentation for `rb_enc_interned_str_cstr` notes that `enc` can be
a null pointer, but this currently causes a segmentation fault when
trying to autoload the encoding. This commit fixes the issue by checking
for NULL before calling `rb_enc_autoload`.
This new shorthand, similar to the existing `github:` shorthand, adds
support for Gitlab repositories with a notable difference. Gitlab
projects may be organized into projects and subprojects. An example
Ruby gem exists at:
https://gitlab.com/gitlab-org/analytics-section/product-analytics/gl-application-sdk-rb
With the new shorthand, a user may install this gem from its repository
by adding:
```ruby
gem "gitlab-sdk", gitlab: "gitlab-org/analytics-section/product-analytics/gl-application-sdk-rb"
```
As with the `github:` shorthand, a supplied string with no `/` will be
interpreted as `example/example`.
Also in keeping with the utility of the `github:` shorthand, the new
`gitlab:` shorthand also supports Merge Request URLs.
```ruby
gem "gitlab-sdk", gitlab: "https://gitlab.com/gitlab-org/analytics-section/product-analytics/gl-application-sdk-rb/-/merge_requests/27"
```
The `gitlab:` gem source shortcut is modeled on the existing `github:`
shortcut, so the new specs mimic the existing examples.
https://github.com/rubygems/rubygems/commit/f4399018c0
[Bug #20253]
All the way down to Ruby 1.9, `Proc`, `Method`, `UnboundMethod`
and `Binding` always had their own specific clone and dup routine.
This caused various discrepancies with how other objects behave
on `dup` and `clone. [Bug #20250], [Bug #20253].
This commit get rid of `CLONESETUP` and use the the same codepath
as all other types, so ensure consistency.
NB: It's still not accepting the `freeze` keyword argument on `clone`.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
Specs that use extension gems were failing in the new job but I noticed
that they were using very non standard `extconf.rb` files.
The hack being removed here was added just to make specs pass when run
in ruby-core but it seems the underlying issue has been fixed now, and
it's causing issues with Ruby 3.3 and Windows, so necessary so I'm
removing it and moving on.
https://github.com/rubygems/rubygems/commit/5b78275f0e