rpms / ruby

Clone
Source Code
GIT

#156 [f37] Fix bundler improperly resolving with --deployment.
Merged 11 months ago by jackorp. Opened 11 months ago by jackorp.
rpms/ jackorp/ruby ruby31-fix-bundler-deployment  into  f37

file modified
+15 -1 
@@ -22,7 +22,7 @@ 
 

  %endif
 

  

  

- %global release 175
 

+ %global release 176
 

  %{!?release_string:%define release_string %{?development_release:0.}%{release}%{?development_release:.%{development_release}}%{?dist}}
 

  

  # The RubyGems library has to stay out of Ruby directory tree, since the
 
@@ -205,6 +205,14 @@ 
 

  # https://bugs.ruby-lang.org/issues/19576
 

  Patch30: rubygem-bundler-2.3.26-Provide-fix-for-bundler-Gemfile-resolving-regression.patch
 

  Patch31: rubygem-bundler-2.3.26-Tests-from-bundler-PR-6225.patch
 

+ # Continuation of the bundler fix for s2i-ruby-container #469 issue.
 

+ # Additionally to already described problem, when bundler is run with
 

+ # --deployment it again resolves to the incorrect gem from Rubygems repository.
 

+ # Fix and test from:
 

+ # https://github.com/rubygems/rubygems/pull/6261
 

+ # https://bugs.ruby-lang.org/issues/19576#note-4
 

+ Patch32: rubygem-bundler-2.3.26-Backport-Fix-another-issue-of-Bundler-not-falling-back.patch
 

+ Patch33: rubygem-bundler-2.3.26-Backport-Fix-another-issue-of-Bundler-not-falling-back-test.patch
 

  

  Requires: %{name}-libs%{?_isa} = %{version}-%{release}
 

  Suggests: rubypick
 
@@ -678,9 +686,11 @@ 
 

  %patch28 -p1
 

  %patch29 -p1
 

  %patch30 -p2
 

+ %patch32 -p2
 

  

  pushd spec/bundler
 

  %patch31 -p3
 

+ %patch33 -p3
 

  popd
 

  

  # Provide an example of usage of the tapset:
 
@@ -1552,6 +1562,10 @@ 
 

  

  

  %changelog
 

+ * Tue Jun 06 2023 Jarek Prokop jprokop@redhat.com - 3.1.4-176
 

+ - Fix bundler improperly resolving with --deployment.
 

+   Resolves: rhbz#2178171
 

+ 

  * Fri Mar 31 2023 Jarek Prokop jprokop@redhat.com - 3.1.4-175
 

  - Upgrade to Ruby 3.1.4.
 

  - Fix ReDoS vulnerability in URI (CVE-2023-28755)

file added
+72 
@@ -0,0 +1,72 @@ 
 

+ diff --git a/bundler/spec/install/gemfile/specific_platform_spec.rb b/bundler/spec/install/gemfile/specific_platform_spec.rb
 

+ index a29446305..e35d8bc16 100644
 

+ --- a/bundler/spec/install/gemfile/specific_platform_spec.rb
 

+ +++ b/bundler/spec/install/gemfile/specific_platform_spec.rb
 

+ @@ -104,40 +104,53 @@
 

+        L
 

+      end
 

+  

+ -    it "still installs the generic RUBY variant if necessary even when running on a legacy lockfile locked only to RUBY" do
 

+ -      build_repo4 do
 

+ -        build_gem "nokogiri", "1.3.10"
 

+ -        build_gem "nokogiri", "1.3.10" do |s|
 

+ -          s.platform = "arm64-darwin"
 

+ -          s.required_ruby_version = "< #{Gem.ruby_version}"
 

+ +    context "when running on a legacy lockfile locked only to RUBY" do
 

+ +      around do |example|
 

+ +        build_repo4 do
 

+ +          build_gem "nokogiri", "1.3.10"
 

+ +          build_gem "nokogiri", "1.3.10" do |s|
 

+ +            s.platform = "arm64-darwin"
 

+ +            s.required_ruby_version = "< #{Gem.ruby_version}"
 

+ +          end
 

+ +
 

+ +          build_gem "bundler", "2.1.4"
 

+          end
 

+  

+ -        build_gem "bundler", "2.1.4"
 

+ -      end
 

+ -
 

+ -      gemfile <<~G
 

+ +        gemfile <<~G
 

+          source "#{file_uri_for(gem_repo4)}"
 

+ +
 

+          gem "nokogiri"
 

+ -      G
 

+ +        G

I wonder that this part of the patch is properly created. I see a difference from the upstream patch. In your patch, in the here document "G", there is no 2 spaces indent.

https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac
https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac.patch

+      gemfile <<~G
+        source "#{file_uri_for(gem_repo4)}"

-    gemfile <<~G
-      source "#{file_uri_for(gem_repo4)}"
+        gem "nokogiri"
+      G

-      gem "nokogiri"
-    G

 
+  

+ -      lockfile <<-L
 

+ +        lockfile <<-L
 

+          GEM
 

+            remote: #{file_uri_for(gem_repo4)}/
 

+            specs:
 

+              nokogiri (1.3.10)
 

+ +
 

+          PLATFORMS
 

+            ruby
 

+ +
 

+          DEPENDENCIES
 

+            nokogiri
 

+ +
 

+          RUBY VERSION
 

+            2.5.3p105
 

+ +
 

+          BUNDLED WITH
 

+             2.1.4
 

+ -      L
 

+ +        L
 

+  

+ -      simulate_platform "arm64-darwin-22" do
 

+ +        simulate_platform "arm64-darwin-22", &example
 

+ +      end
 

+ +
 

+ +      it "still installs the generic RUBY variant if necessary" do
 

+          bundle "update --bundler", :artifice => "compact_index", :env => { "BUNDLER_SPEC_GEM_REPO" => gem_repo4.to_s }
 

+        end
 

+ +
 

+ +      it "still installs the generic RUBY variant if necessary, even in frozen mode" do
 

+ +        bundle "update --bundler", :artifice => "compact_index", :env => { "BUNDLER_SPEC_GEM_REPO" => gem_repo4.to_s, "BUNDLE_FROZEN" => "true" }
 

+ +      end
 

+      end
 

+  

+      it "doesn't discard previously installed platform specific gem and fall back to ruby on subsequent bundles" do

file added
+54 
@@ -0,0 +1,54 @@ 
 

+ From 891246c3865ed0af7e277ca50c079f466d035f7c Mon Sep 17 00:00:00 2001
 

+ From: Jarek Prokop <jprokop@redhat.com>
 

+ Date: Thu, 1 Jun 2023 13:22:24 +0200
 

+ Subject: [PATCH] Backport "Fix another issue of Bundler not falling back to an
 

+  installable candidate"
 

+ 

+ In this case, when materializing a legacy lockfile using only "ruby"
 

+ platform, and in frozen mode.
 

+ 

+ =====
 

+ 

+ Commit adapted from: https://github.com/rubygems/rubygems/pull/6261
 

+ ---
 

+  bundler/lib/bundler/lazy_specification.rb     | 11 +++--
 

+  .../install/gemfile/specific_platform_spec.rb | 41 ++++++++++++-------
 

+  2 files changed, 35 insertions(+), 17 deletions(-)
 

+ 

+ diff --git a/bundler/lib/bundler/lazy_specification.rb b/bundler/lib/bundler/lazy_specification.rb
 

+ index e8bee25ab..a65020e6c 100644
 

+ --- a/bundler/lib/bundler/lazy_specification.rb
 

+ +++ b/bundler/lib/bundler/lazy_specification.rb
 

+ @@ -85,7 +85,7 @@ def materialize_for_installation
 

+  

+                       installable_candidates = GemHelpers.select_best_platform_match(matching_specs, target_platform)
 

+  

+ -                     specification = __materialize__(installable_candidates)
 

+ +                     specification = __materialize__(installable_candidates, :fallback_to_non_installable => false)
 

+                       return specification unless specification.nil?
 

+  

+                       if target_platform != platform
 

+ @@ -98,13 +98,18 @@ def materialize_for_installation
 

+        __materialize__(candidates)
 

+      end
 

+  

+ -    def __materialize__(candidates)
 

+ +    # If in frozen mode, we fallback to a non-installable candidate because by
 

+ +    # doing this we avoid re-resolving and potentially end up changing the
 

+ +    # lock file, which is not allowed. In that case, we will give a proper error
 

+ +    # about the mismatch higher up the stack, right before trying to install the
 

+ +    # bad gem.
 

+ +    def __materialize__(candidates, fallback_to_non_installable: Bundler.frozen_bundle?)
 

+        search = candidates.reverse.find do |spec|
 

+          spec.is_a?(StubSpecification) ||
 

+            (spec.matches_current_ruby? &&
 

+             spec.matches_current_rubygems?)
 

+        end
 

+ -      if search.nil? && Bundler.frozen_bundle?
 

+ +      if search.nil? && fallback_to_non_installable
 

+          search = candidates.last
 

+        else
 

+          search.dependencies = dependencies if search && search.full_name == full_name && (search.is_a?(RemoteSpecification) || search.is_a?(EndpointSpecification))
 

+ -- 

+ 2.41.0.rc1
 

+

Continuation of the bundler fix for s2i-ruby-container issues.

This commit requires previous commit <487c4a5aeaa09e979173beb9bcffebbdb5a770ad>
from the f37 branch to be applied.

Additionally to already described problem fixed in previous commit,
when bundler is run with --deployment it again resolves to
the incorrect gem from Rubygems repository.

See the attached note from Ruby tracker for more information.

Fix and test from:
https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac
https://bugs.ruby-lang.org/issues/19576#note-4

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/68cd5e0c73e6435ebdbb80be5baf5083

Thanks for the PR. Let me review this PR.

First I will confirm the issue using the reproducing commands written in the note below.
https://bugs.ruby-lang.org/issues/19576#note-3

Continuation of the bundler fix for s2i-ruby-container #469 issue.

For the commit message, shall we add the link https://github.com/sclorg/s2i-ruby-container/issues/469 to the commit message? It's easy to see the ticket.

This builds on previous F37 commit <487c4a5aeaa09e979173beb9bcffebbdb5a770ad>.

Also for the commit message, what does the sentence mean? You meant the issue #469 happened with the ruby build of f37 whose commit is 487c4a5aeaa09e979173beb9bcffebbdb5a770ad?

For the commit message, shall we add the link https://github.com/sclorg/s2i-ruby-container/issues/469 to the commit message? It's easy to see the ticket.

That's a bit of a different issue. It is related to the previous fix, and it did fix that, but it does not mention --deployment anywhere or is is using the option. The bugzilla and upstream Ruby bug tracker ticket as a reference is better as I believe it is the same bug and added clarification/extension to what the bug is to them.

Also for the commit message, what does the sentence mean? You meant the issue #469 happened with the ruby build of f37 whose commit is 487c4a5?

Right, I am assuming that everyone's understand of contextual this is equal, whereas here it can cause confusion. I'll try to get better.

This in the commit message refers to the commit. IOW, you have to have the previous commit applied to apply this PR, as otherwise I do not give any guarantee that This PR is a fix. I think the commit of this PR also, in a way, builds on the content applied in the previous commit.

I'll fix that.

rebased onto d29fbc28a964c26b58027fc35f50f3ddeebd8c50
11 months ago

That's a bit of a different issue. It is related to the previous fix

Ah, now I get what you mean. Right, what I meant originally is that it was discovered there, and that it is similar. I have pushed a rewording update to try to clarify the situation.

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/9b7d3aa4114f41b89a62a3252fb37e24

Ah, now I get what you mean. Right, what I meant originally is that it was discovered there, and that it is similar. I have pushed a rewording update to try to clarify the situation.

I saw your updated commit message. I meant that I need to find the actual issue link of the "s2i-ruby-container #469 issue" in the previous comment. So, I thought the reference of the actual link is helpful to understand the content. But I saw you dropped the "s2i-ruby-container #469 issue" in the commit message. That's okay.

We know what is the "s2i-ruby-container" and where the repository is. However, I think the description "s2i-ruby-container #469 issue" is ambiguous to identify the issue for people who don't know it.
That's why I suggested adding the reference to the https://github.com/sclorg/s2i-ruby-container/issues/469, if you write the "s2i-ruby-container #469 issue".

Note I am still reviewing the PR.

We know what is the "s2i-ruby-container" and where the repository is. However, I think the description "s2i-ruby-container #469 issue" is ambiguous to identify the issue for people who don't know it.

Here it is contextually different than in the commit IMO. You have the reference in the previous Patch: definition.

But it is a reference I missed, I shouldn't really refer to that issue in spec as well, as the github ticket describes a slightly different situation, if you would use the reproducer steps, verbatim as they are written, there, it would not yield you the expected error.

It is a bit questionable if the container repo should be referred to at all currently, as I think replacing the GH issue with the RHBZ's comment#14 (the RHBZ that is in Resolves:) is more useful, you can gather more Fedora specific context without having to jump around the links more.
Edited 11 months ago by jackorp

Where does the comment come above from? The referred upstream commit doesn't have the comment? Did you add it by your self?
https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac

I wonder that this part of the patch is properly created. I see a difference from the upstream patch. In your patch, in the here document "G", there is no 2 spaces indent.

https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac
https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac.patch

+      gemfile <<~G
+        source "#{file_uri_for(gem_repo4)}"

-    gemfile <<~G
-      source "#{file_uri_for(gem_repo4)}"
+        gem "nokogiri"
+      G

-      gem "nokogiri"
-    G

Where does the comment come above from? The referred upstream commit doesn't have the comment? Did you add it by your self?
https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac

Ah I found the comment on the pages below.

https://bugs.ruby-lang.org/issues/19576#note-4 - 0001-Backport-Fix-another-issue-of-Bundler-not-falling-back.patch
https://github.com/rubygems/rubygems/pull/6717/files#diff-aeb9edfaf1badd9cf55c339b60061eeb3d402b2b2182359a21e33e999fc302dc

I wonder that this part of the patch is properly created. I see a difference from the upstream patch. In your patch, in the here document "G", there is no 2 spaces indent.

I think that the change of the patch is not exactly backported from the https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac. But I suppose that your patch is going to be merged to the RubyGems 3.3 in the PR, https://github.com/rubygems/rubygems/pull/6717/commits/a096e49734716e7bdc14ae25d769dd32d0797a5e.

So, I think we don't need to change the patch content in the 2 added patch files.

  • rubygem-bundler-2.3.26-Backport-Fix-another-issue-of-Bundler-not-falling-back.patch
  • rubygem-bundler-2.3.26-Backport-Fix-another-issue-of-Bundler-not-falling-back-test.patch

Ah you added the 3rd commit in the total 3 commits in the pull-request to the master branch in RubyGems. I was confused because I saw the # https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac is only mentioned in the comment.

I hope you remove the comment that is the content of the https://github.com/rubygems/rubygems/pull/6261/commits/7c4375264b797742bc911d3beb7d434ec66704c8 if you truly backport from the https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac.

+# https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac
+# https://bugs.ruby-lang.org/issues/19576#note-4
+Patch32: rubygem-bundler-2.3.26-Backport-Fix-another-issue-of-Bundler-not-falling-back.patch
+Patch33: rubygem-bundler-2.3.26-Backport-Fix-another-issue-of-Bundler-not-falling-back-test.patch

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/5127f730071c453bb30c1acce7c48a70

Could you tell me the exact hopefully minimal reproducing steps? I want to test with minimal Gemfile and Gemfile.lock.

https://bugs.ruby-lang.org/issues/19576

Using the following Gemfile for a rails app:
https://github.com/sclorg/rails-ex/blob/67b7a61eae9efa1088ff3f634ae316e1022fa913/Gemfile.lock

I tried to get Gemfile and Gemfile.lock (based on your report on the Ruby ticket) with the updated bundler, and then I got another error.

$ wget https://raw.githubusercontent.com/sclorg/rails-ex/67b7a61eae9efa1088ff3f634ae316e1022fa913/Gemfile

$ pwd
/builddir/work

$ bundle config set path ./bundle
$ bundle config set deployment true

$ cat .bundle/config
---
BUNDLE_PATH: "./bundle"
BUNDLE_DEPLOYMENT: "true"


$ bundle install
The deployment setting requires a Gemfile.lock. Please make sure you have checked your
Gemfile.lock into version control before deploying.

$ echo $?
16

$ wget https://raw.githubusercontent.com/sclorg/rails-ex/67b7a61eae9efa1088ff3f634ae316e1022fa913/Gemfile.lock

$ bundle install
...
An error occurred while installing sassc (2.4.0), and Bundler cannot continue.
...
An error occurred while installing sqlite3 (1.4.4), and Bundler cannot continue.
Edited 11 months ago by jaruga

Where does the comment come above from? The referred upstream commit doesn't have the comment? Did you add it by your self?

I have done the patch manually, backporting this automatically cannot be done easily or without editing the patch manually, adding comment on top seemed useful at the time, and there is the link to the whole PR, that includes the comment.
(But I doubt anyone is going to search which comment caused regression, having the specific code references is more useful.) I also kept in mind that it is going to be upstreamed, therefore I included the comment.

I wonder that this part of the patch is properly created. I see a difference from the upstream patch. In your patch, in the here document "G", there is no 2 spaces indent.

Probably not 1:1 looking at the file now. Dealing with at least having properly formatting code blocks might have mangled the heredoc.

Functionally this shouldn't be an issue though (and upstream CI is passing, including rubocop, so it probably isn't an issue).

(What surprises me is the combined use of dash <<- and tilde <<~ heredoc styles, but that's a whole other discussion.)

I hope you remove the comment that is the content of the https://github.com/rubygems/rubygems/pull/6261/commits/7c4375264b797742bc911d3beb7d434ec66704c8 if you truly backport from the https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac

Well, I used https://github.com/rubygems/rubygems/commit/f2084b1727f4cf71795035cad84924528e6b082f which is the final merge of https://github.com/rubygems/rubygems/pull/6261 but I left out the formatting change, as that only complicates matters for me and makes the overall backport more difficult than need be, so I only took over the comment and the actual behavior change that we care about, which is the only part of the whole patch that actually has effect for end-users (and the test to prevent regression in the upstream). Moreover, to simplify matters I pointed to the actual PR, where you can find the commits more atomically, as well as the functional part, which I did not even link to via an URL link but rather a commit.

The target of this exercise is to retro-actively fix the bug described in Bugzilla and the linked upstream Ruby bug tracker. I'd argue I supplied sufficient information for the changes to be traceable to the sources.

So I think the better step actually is to completely remove what commits were used in the patches and instead move that information out to the commit/specfile as I can edit that easier than the patch.

Could you tell me the exact hopefully minimal reproducing steps? I want to test with minimal Gemfile and Gemfile.lock. I tried to get Gemfile and Gemfile.lock (based on your report on the Ruby ticket) with the updated bundler, and then I got another error.

This is a Bundler issue, I provided Gemfile and Gemfile.lock explicitly, and described that I can't even get it to resolve to get to the install step.

If you see errors you have pasted in here, you don't have an issue with bundler (most likely), but with your environment, as you see specific gems and their version that errored during installation.

I think installing build deps for ruby will fix you the sassc failure.

Do note that in the upstream Ruby bug tracker ticket you mentioned, I link the reproducer from sclorg repo with the comment "Initial bug report with reproducer and more in-depth description can be found here: https://github.com/sclorg/s2i-ruby-container/issues/469" and I consider it minimal enough in the perspective of steps needed to execute

Where Zuzka specifies the following for starters:
"""
1. use following Dockerfile:

FROM quay.io/fedora/ruby-31:latest
ADD app-src ./
RUN bundle install --path ./bundle
CMD exec bundle exec "rackup -P /tmp/rack.pid --host 0.0.0.0 --port 8080"

"""

For this PR reproducer is a bit different as you can find out in comment#14 in my bugzilla ticket and comment#4 in the upstream Ruby tracker ticket:

FROM quay.io/fedora/ruby-31:latest
ADD app-src ./
RUN bundle install --path ./bundle --deployment
CMD exec bundle exec "rackup -P /tmp/rack.pid --host 0.0.0.0 --port 8080"

This is important, it is the first step out of 3 total, it is a container, so you know the environment and have it transferable between machines without needing to hunt down C dependencies on different platforms. This approach has the value that you can focus only on the pure Ruby part of the issue. If you want to try with gemfiles only you only need simply to adjust ADD step like so (you have to have the Gemfiles in the current directory):

FROM quay.io/fedora/ruby-31:latest
ADD Gemfile Gemfile.lock ./
RUN bundle install --path ./bundle --deployment
CMD exec bundle exec "rackup -P /tmp/rack.pid --host 0.0.0.0 --port 8080"

you can also switch to root to install updated packages and then back to unprivileged user like so:

FROM quay.io/fedora/ruby-31:latest

USER 0
COPY rubygem-bundler<new_nvr>.noarch.rpm ./
RUN dnf update ./rubygem-bundler<new_nvr>.noarch.rpm
USER default

ADD Gemfile Gemfile.lock ./
RUN bundle install --path ./bundle --deployment
CMD exec bundle exec "rackup -P /tmp/rack.pid --host 0.0.0.0 --port 8080"

When I tested it in a fresh VM to confirm my issues I took care I had all required C development dependencies, as it is a Rails app afterall, I did this manually by inspecting individual gem error output files to see where they failed and install the packages they needed. That is, if I didn't already know what each gem requires already from previous experience (for example, I know I am testing on fresh VM with basic Ruby build dependencies included, therefore when sqlite3 fails, I assume I am missing sqlite-devel package and install that).

Moreover this is the container where we actually test the Gemfile (well, we test that the whole app can run), therefore you have all the required dependencies to do bundle install without any errors. If bundler is working correctly. Which is why I recommend it.

If you want to test with minimal Gemfiles, without using the container, you need relevant C dependencies, I do not know what those exactly are.

To conclude, I can find out if you really want me to, but I find it time consuming and not relevant at all for the report. Mainly due the the reason that the error happens way before any gem package is actually downloaded from rubygems.org, and installed therefore you do not necessarily need the correct dependencies beyond the Ruby & bundler runtime. Additionally I provided a container where all dependencies are pre-installed, which should be sufficient for your needs.

Thank you for your answers. And, I am sorry that I asked many questions. Maybe I should ask a few key questions. Then you had to write many texts to answer. I am overwhelmed beyond my ability to read the texts that riggers additional questions, and I understand my questions triggered the situation.

but I left out the formatting change, as that only complicates matters for me and makes the overall backport more difficult than need be

Maybe you understand in general, if you don't backport the exact changes (not only it just works) to a downstream (f37 in this case), you are harder to backport another patch to the downstream in the future.

I am not sure how difficult the backport work was as I didn't work actually for it. But the implied changes (or adjustment) just surprised me. But in this case, you don't need to change the patch, as your backport patch is likely to be merged on the upstream.

Well, I used https://github.com/rubygems/rubygems/commit/f2084b1727f4cf71795035cad84924528e6b082f which is the final merge of https://github.com/rubygems/rubygems/pull/6261

I see. You used the marge commit on the master branch. I didn't know if we can use the marge commit as a patch. Because the following command doesn't show the difference for the marge commit f2084b1727f4cf71795035cad84924528e6b082f.

$ git remote -v | grep origin
origin  git@github.com:rubygems/rubygems.git (fetch)
origin  git@github.com:rubygems/rubygems.git (push)

$ git show f2084b1727f4cf71795035cad84924528e6b082f
commit f2084b1727f4cf71795035cad84924528e6b082f
Merge: 17b4977363 7c4375264b
Author: David Rodríguez <deivid.rodriguez@riseup.net>
Date:   Wed Jan 11 12:15:52 2023 +0100

    Merge pull request #6261 from rubygems/fix-another-materialization-issue

    Fix another case of not properly falling back to ruby variant when materializing

So, if you actually used the marge commit, I suggest changing the following link to the https://github.com/rubygems/rubygems/commit/f2084b1727f4cf71795035cad84924528e6b082f or https://github.com/rubygems/rubygems/pull/6261. I expected the patch file is created based on the commented commit. It makes hard to understand how to create the patch.

+# https://github.com/rubygems/rubygems/commit/93af31aaaed75e9aa9cb182d2f0c2100918ed7ac

If you see errors you have pasted in here, you don't have an issue with bundler (most likely), but with your environment, as you see specific gems and their version that errored during installation.

I think installing build deps for ruby will fix you the sassc failure.

Okay. After installing addtional build dependencies, the bundle install succeeded. As I didn't understand where the original issue come in the process of the bundle install, I wanted to make sure the bundle install succeeds.

I installed the following build dependencies.

$ mock -r fedora-37-x86_64 -i libsass sqlite-devel g++ postgresql-server libpq-devel

Then

$ bundle install
...
Bundle complete! 21 Gemfile dependencies, 81 gems now installed.
Bundled gems are installed into `./bundle`

$ echo $?
0

Thank you for providing the reproducer with containers. Sorry I didn't execute the reproducer.

Other parts looks ok.
Edited 11 months ago by jaruga

Maybe you understand in general, if you don't backport the exact changes (not only it just works) to a downstream (f37 in this case), you are harder to backport another patch to the downstream in the future.

I do understand this, but it just isn't possible to backport the exact changes. It does not seem reasonable for me to burn time on explicit formatting commits.

So, if you actually used the marge commit, I suggest changing the following link to the

If it will help to push this change, sure.

rebased onto 4048f89
11 months ago

I do understand this, but it just isn't possible to backport the exact changes. It does not seem reasonable for me to burn time on explicit formatting commits.

As I wrote above, you don't need to change the patch in this case.

If it will help to push this change, sure.

Thanks.

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/55cf3b41d36141ebac89fcf31c34c5bc

I got a bit sidetracked, let's get back to this.

@jaruga are there any more items or is this ready to merge & build? I think I have addressed the concerns in latest push.

I don't think there are any more items. You are ready to merge and build! Thanks.

Great, moving on with the work then.

Pull-Request has been merged by jackorp
11 months ago
Metadata
None
No Tags
Changes Summary 3
+15 -1
file changed
ruby.spec
+72
file added
rubygem-bundler-2.3.26-Backport-Fix-another-issue-of-Bundler-not-falling-back-test.patch
+54
file added
rubygem-bundler-2.3.26-Backport-Fix-another-issue-of-Bundler-not-falling-back.patch
Powered by Pagure 5.13.3
Documentation • File an Issue • About this Instance • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.