I've seen this error sometimes but never found it helpful, since the
culprit has never been thread/monitor related, so it just adds noise.
Right now I'm seeing an issue in CI where we seem to be crashing during
ensure and showing a weird backtrace:
```
#<Thread:0x000055821d7a73b8 /home/runner/work/rubygems/rubygems/lib/rubygems/request_set.rb:167 run> terminated with exception (report_on_exception is true):
/home/runner/work/rubygems/rubygems/lib/rubygems/platform.rb:141:in `==': undefined local variable or method `to_a' for false:FalseClass (NameError)
Did you mean? to_s
from /home/runner/work/rubygems/rubygems/lib/rubygems/core_ext/kernel_require.rb:168:in `!='
from /home/runner/work/rubygems/rubygems/lib/rubygems/core_ext/kernel_require.rb:168:in `require'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:441:in `block in ensure_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:437:in `each'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:437:in `ensure_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems.rb:413:in `ensure_gem_subdirectories'
from /home/runner/work/rubygems/rubygems/lib/rubygems/resolver/specification.rb:110:in `download'
from /home/runner/work/rubygems/rubygems/lib/rubygems/request_set.rb:173:in `block (2 levels) in install'
```
Let's get this out of the picture in case that helps clarify the
culprit.
https://github.com/rubygems/rubygems/commit/87ce40b70e
String#unpack("C*") is equivalent to String#bytes and Array#inject {|a,b| a + b } is equivalent to Array#sum.
This is a minor enhancement in terms of speed and readability.
When we use this methods with local gemspec, we don't handle
build status of extension correctly. So We need to find extension
files in require_paths.
Example with ruby/erb repository:
```
$ bundle exec irb
Ignoring erb-4.0.2 because its extensions are not built. Try: gem pristine erb --version 4.0.2
>>
```
https://github.com/rubygems/rubygems/commit/f90e43cf3f
TarReader#each previously implemented a partial version of seek.
This code moved to Entry#seek for use from TarReader#each.
Entry#close now returns nil instead of true, like IO#close.
Closing an Entry now seeks to the end of the Entry, seeking past
any remaining zero byte tar file padding and moving the io to the
correcty position to read the next file in the archive.
Uses seek for Entry#rewind and #pos=, fixing the tar->gzip->tar nested
rewind that would break previous to this change.
Add Entry.open that behaves more like File.open.
https://github.com/rubygems/rubygems/commit/f5149565d5
Current implementation tried to build installation artifact. But default gems
didn't provide normal gem files. So, It's always build failure.
https://github.com/ruby/bigdecimal/actions/runs/4269574995/jobs/7432842788
ERROR: Error installing pkg/bigdecimal-3.1.4.gem:
ERROR: Failed to build gem native extension.
No such file or directory @ dir_s_mkdir - /Users/runner/.rubies/ruby-head/lib/ruby/gems/3.3.0+0/gems/bigdecimal-3.1.4/ext/bigdecimal/.gem.20230225-2301-2mul99
Gem files will remain installed in /Users/runner/.rubies/ruby-head/lib/ruby/gems/3.3.0+0/gems/bigdecimal-3.1.4 for inspection.
Results logged to /Users/runner/.rubies/ruby-head/lib/ruby/gems/3.3.0+0/extensions/x86_64-darwin-19/3.3.0+0/bigdecimal-3.1.4/gem_make.out
https://github.com/rubygems/rubygems/commit/2157aa8ec8
TarReader is used as an IO object, but doesn't behave the same as other
implementations. These fixes make `read` and `readpartial` conform to the
interface of StringIO and File.
https://github.com/rubygems/rubygems/commit/bba32d7217
Currently Bundler needs to do cumbersome operations to revert custom
RubyGems require on a `bundler/setup` context. This causes issues when
third party gems also monkeypatch require, since Bundler will also undo
those decorations.
This commit allows it to use the simpler approach of properly telling
RubyGems that it needs to default to built-in require without any extra
magic.
https://github.com/rubygems/rubygems/commit/1df5009e14
Co-authored-by: Xavier Noria <fxn@hashref.com>
the final copying of the extension into place has been slimmed
down, reflecting that it only needs to copy a single file, rather
than replicating the more involved process used for a C ext
this also refactors #build so that #cargo_crate_name only needs
to be called once, and hopefully the build flow is easier to
understand
https://github.com/rubygems/rubygems/commit/5a0d7f2e6c
Since RDoc does not parse string literals as documents, `eval` the
entire file instead of embedding in a here-document.
On the contrary, as `gem_original_require` alias is an implementation
detail but not for users, it should not be documented.
https://github.com/rubygems/rubygems/commit/cad4cf16cf
jruby-head (which will be JRuby 9.4.0.0) can now properly process
the keywords to Kernel#warn. I cannot think of any capability based
test for this so I constrained it using a version guard. Only JRuby
will ever hit the version guard.
https://github.com/rubygems/rubygems/commit/cd468c7e0f
Previously 9eead86 introduced non-commutativity of platforms, and
later commit 1b9f7f50 changed the behavior of `Gem::Platform.match` to
ensure the callee of `#=~` was the gem platform.
However, when the platform argument is a String, then the callee and
argument of `#=~` are flipped (see docs for `String#=~`), which works
against the fix from 1b9f7f50.
Closes#5938https://github.com/rubygems/rubygems/commit/3b1fb562e8
When extracting files from the tarball, a mode is retrieved from
the header. Occasionally you'll encounter a gem that was packaged
on a system whose permission bits result in a value that is larger
than the value that File.chmod will allow (anything >= 2^16). In
that case the extraction fails with a RangeError, which is pretty
esoteric.
If you extract the tarball with the tar and gunzip utilities, the
file permissions end up being just the bottom 16 bits masked off
from the original value. I've mirrored that behavior here. Per the
tar spec:
> Modes which are not supported by the operating system restoring
> files from the archive will be ignored.
I think that basically means what I've done here.
---
This commit also changes the behavior very slightly with regard to
when the chmod is called. Previously it was called while the file
descriptor was still open, but after the write call.
When write flushes, the file permissions are changed to the mode
value from the File.open call, undoing the changes made by
FileUtils.chmod. CRuby appears to flush the buffer after the
chmod call, whereas TruffleRuby flushes before the chmod call.
So the file permissions can change depending on implementation.
Both implementations end up getting the correct file permissions
for the bottom 9 bits (user, group, world), but differ with
regard to the sticky bit in the next 3.
To get consistent behavior, this commit changes it to close the
file descriptor before attempting to chmod anything, which makes
it consistent because the write flushes in both cases.
https://github.com/rubygems/rubygems/commit/22ce076e99
Attempting to install a gem published as both *-linux and *-linux-musl
results in the incorrect gem being picked up, causing build failures due
to binary incompatibility. This is caused by the `nil` wildcard
swallowing the libc information upon version comparison.
Handle the linux case by performing only non-wildcard equality on the
version and asserting 'gnu' and nil equivalence, while preserving the
current behaviour for other OSes.
https://github.com/rubygems/rubygems/commit/9eead86abc
Co-authored-by: Loic Nageleisen <loic.nageleisen@gmail.com>
Running a command like that is actually removing any previous default
bundler specs in the default RubyGems installation (outside of destdir).
It should instead only modify destdir.
https://github.com/rubygems/rubygems/commit/5ed275383c
WASI doesn't guarantee that `/dev/null` is present.
So without this patch, we needed to mount host's `/dev` directory to WASI
guest process to avoid `ENOTCAPABLE` error while `require "bundler/setup"`
https://github.com/rubygems/rubygems/commit/e9187ab61f
Since a few commits ago, we no longer call `Gem::Specification.reset`
after each invocation of `Gem::Installer#install`. This means we don't
call it when the default Bundler is installed during `gem update
--system`. This causes no issues until the end of the upgrade process
when:
* The previous default Bundler spec is removed from disk.
* All specification stubs are turned into real specifications by loading
them from disk. But the one for Bundler no longer exists so
materializes to `nil` and regenerating binstubs crashes like this:
```
Bundler 2.4.0.dev installed
RubyGems 3.4.0.dev installed
Regenerating binstubs
ERROR: While executing gem ... (NoMethodError)
undefined method `platform' for nil:NilClass
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `block in execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:981:in `block in each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:980:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:980:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `map'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `select'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:323:in `invoke_with_build_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:301:in `invoke'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/setup_command.rb:604:in `regenerate_binstubs'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/setup_command.rb:183:in `execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:323:in `invoke_with_build_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:185:in `process_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:149:in `run'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/gem_runner.rb:51:in `run'
setup.rb:33:in `<main>'
```
We fix it by more carefully managing the removal of the previous default
Bundler gem.
https://github.com/rubygems/rubygems/commit/9989f6d5af
While generate_index did clean up temporary directory, when running with
--update flag, that did not happen and the temporary directory was left
behind.
This commit fixes that and modifies tests in order to make sure this is
not reintroduced later on.
Fixes#5635.
https://github.com/rubygems/rubygems/commit/9fa34dc329
These gemspecs already work most of the times. When they are installed
normally, the require_paths in the gemspec stub line becomes actually
correct, and the incorrect value in the real gemspec is ignored. It only
becomes an issue in standalone mode.
In Ruby 3.2, `Kernel#=~` has been removed, and that means that it
becomes harder for us to gracefully deal with this error in standalone
mode, because it now happens earlier due to calling `Array#=~` for this
invalid gemspec (since require_paths is incorrectly an array of arrays).
The easiest way to fix this is to actually make this just work instead
by automatically fixing the issue when reading the packaged gemspec.
https://github.com/rubygems/rubygems/commit/d3f2fe6d26
It was being explicitly required from `Gem::Specification` but also a
strange autoload was set for it at `Gem::Version`. The autoload was non
standard because it should've been done in the `Gem` module, not in
`Gem::Specification`, since that's where the constant is expected to get
defined. Doing this might get deprecated in the future, and it was not
being effective anyways due to the explicit require.
Unify everything with an `autoload` at the right place.
https://github.com/rubygems/rubygems/commit/174ea3e24c
This issue was not detected because when all traces of old YAML parser
and emitter `Syck` were removed, this null-type.gemspec.rz marshalled
gemspec was updated to no longer load `YAML::Syck::PrivateType` but load
`Psych::PrivateType` instead.
However, realworld old marshalled gemspecs still use the
`YAML::PrivateType` constant, so this commit replaces the gemspec to be
the real pry-0.4.7 marshalled gemspec, so that it catches this issue.
https://github.com/rubygems/rubygems/commit/51b330b8d2
This old bug used to affect the `rubyforge_project` field in serialized
gemspecs. However, this field has been removed and it's no longer
present in marshaled loaded gemspecs.
So, while the constant is still present in these marshalled gemspecs and
we still need to make sure it exists, we no longer need to clean it up
from the loaded data.
https://github.com/rubygems/rubygems/commit/09df18e522
Hiroshi SHIBATA
David Rodríguez
Mau Magnaguagno
Martin Emde
Samuel Giddins
Josef Šimánek
Nobuyoshi Nakada
Mat Sadler
Gustavo Ribeiro
Eloy Espinaco
Benoit Daloze
Ian Ker-Seymer
Jason Karns
Peter Zhu
Thomas E. Enebo
Jenny Shen
Mike Dalessio
Kevin Newton
Antonio Paulino
なつき
Loic Nageleisen
Ilya Dyakonov
Ashley Ellis Pierce
Takuya Noguchi
Yuta Saito
Brian Le
Tomas Volf
Daniel Berger