Description of problem: rubygem-bundler bundled with Ruby locks up when a dependency does not support current platform. Version-Release number of selected component (if applicable): $ rpm -qa rubygem-bundler rubygem-bundler-2.3.26-173.fc36.noarch $ rpm -qa ruby ruby-3.1.3-173.fc36.x86_64 This is applicable to Fedora 37 as well. How reproducible: Always Steps to Reproduce: 0. $ sudo dnf install ruby -y ruby-devel rubygem-bundler 1. Grab the Gemfile and Gemfile.lock a) Gemfile: https://github.com/sclorg/rails-ex/blob/67b7a61eae9efa1088ff3f634ae316e1022fa913/Gemfile Gemfile.lock: https://github.com/sclorg/rails-ex/blob/67b7a61eae9efa1088ff3f634ae316e1022fa913/Gemfile.lock b) optionally clone the whole project: https://github.com/sclorg/rails-ex 2. $ bundle install --path ./bundle 3. It doesn't terminate and keeps repeating: ~~~~ $ bundle install --path ./bundle [DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local path './bundle'`, and stop using this flag Fetching gem metadata from https://rubygems.org/.......... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... <...snip...> ~~~ Actual results: Process locks up in a cycle. It can go on like this forever (up to 6h, after which the timeout for tests killed it) ~~~ Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... <repeats...> ~~~ Expected results: Either an error or a successful dependency resolution. Additional info: Not a problem with Ruby 3.2 and its bundled rubygem-bundler v2.4.6 Upstream issue: https://github.com/rubygems/rubygems/issues/6054 Upstream fix PR: https://github.com/rubygems/rubygems/pull/6070 Containers issue for this: https://github.com/sclorg/s2i-ruby-container/issues/469 Can be mitigated by updating dependencies. Therefore, there might be some gem in the Gemfile that doesn't play nice with the rest, but to us, it is important that bundler does not lock up in a cycle. You can reproduce in containers using a `Dockerfile` with following contents: ~~~ FROM registry.fedoraproject.org/fedora:37 RUN dnf install -y ruby ruby-devel rubygem-bundler git RUN rpm -qa ruby rubygem-bundler # Print NVRs WORKDIR /opt/ RUN git clone https://github.com/sclorg/rails-ex app-src # Get the app with the reproducer Gemfile USER 0 RUN chown -R 1000:1000 ./ # Fix perms to not be a root account for bundle install USER 1000 WORKDIR /opt/app-src RUN bundle install --path ./bundle CMD exec bundle exec "rackup -P /tmp/rack.pid --host 0.0.0.0 --port 8080" ~~~ Then simply run `podman build --no-cache .` in the same directory as the `Dockerfile`. You can exchange `:37` with `:36` for the `FROM`, the result is the same.
I think I found the culprit and a working workaround. Culprit: Running `bundle install` with `frozen` stop bundler from trying to re-resolve the already locked-in deps reveals the offending gem: ~~~ $ bundle install --frozen [DEPRECATED] The `--frozen` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local frozen 'true'`, and stop using this flag Fetching gem metadata from https://rubygems.org/.......... nokogiri-1.12.5-x86_64-linux requires ruby version < 3.1.dev, >= 2.5, which is incompatible with the current version, 3.1.3 ~~~ This points to a kind of regression IMHO, as the only platform in "PLATFORMS" is `ruby`. It should not try to fetch an architecture specific gem. This is not a problem with bundler v2.4.8, there it works normally (IOW, it install gems correctly and doesn't complain) without any extra adjusting. Workaround: Force bundler to only look at the Ruby platform gems: ``` $ bundle config set force_ruby_platform true $ bundle install --path bundle [DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local path 'bundle'`, and stop using this flag Fetching gem metadata from https://rubygems.org/.......... Fetching rake 13.0.6 Installing rake 13.0.6 Using racc 1.6.0 Fetching minitest 5.15.0 Fetching zeitwerk 2.6.0 Fetching builder 3.2.4 Fetching crass 1.0.6 Fetching concurrent-ruby 1.1.10 Fetching erubi 1.11.0 Fetching rack 2.2.4 Fetching mini_portile2 2.6.1 Installing builder 3.2.4 Fetching nio4r 2.5.8 Installing crass 1.0.6 <...snip...> Using turbolinks 5.2.1 Using uglifier 4.2.0 Using web-console 4.2.0 Bundle complete! 21 Gemfile dependencies, 81 gems now installed. Bundled gems are installed into `./bundle` ```
I believe this is a regression on Bundler's side for Ruby 3.1.3, due to this behaviour not being present on Ruby 3.1.2 or Ruby 3.2.1, therefore I filed: https://github.com/rubygems/rubygems/issues/6482
That ticket was not needed, because it works on newer version... This is probably relevant PR: https://github.com/rubygems/rubygems/pull/6225
Fix will be included in the newest Ruby 3.1.4 rebase: https://src.fedoraproject.org/rpms/ruby/pull-request/154
FEDORA-2023-f58d72c700 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f58d72c700
FEDORA-2023-a7be7ea1aa has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a7be7ea1aa
FEDORA-2023-f58d72c700 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-f58d72c700` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f58d72c700 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-a7be7ea1aa has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a7be7ea1aa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a7be7ea1aa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-a7be7ea1aa has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-f58d72c700 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
The current fix is only "partial". The bug also happens if you add `--deployment` option either via CLI (`bundle install --deployment`) or config (`bundle config set deployment true`), then we see that incorrect arch gets picked from a selection: ~~~ $ bundle config set path ./bundle $ bundle config set deployment true $ bundle install Fetching gem metadata from https://rubygems.org/.......... nokogiri-1.12.5-x86_64-linux requires ruby version < 3.1.dev, >= 2.5, which is incompatible with the current version, 3.1.4 ~~~ It's a similar problem that's been happening with the original report. I have run git bisect for upstream and prepared a patch that should fix this situation: https://bugs.ruby-lang.org/issues/19576#note-4
FEDORA-2023-7f13da96c6 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-7f13da96c6
FEDORA-2023-7f13da96c6 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-7f13da96c6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-7f13da96c6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-7f13da96c6 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.