On Fri, Aug 23, 2019 at 02:45:34AM +0530, Utkarsh Gupta wrote:
> Hey,
>
> On Thu, Aug 22, 2019 at 9:18 PM Antonio Terceiro <terceiro@debian.org>
> wrote:
>
> > On Wed, Aug 21, 2019 at 11:24:12PM +0530, Utkarsh Gupta wrote:
> > > Hey,
> > >
> > > While working on some packages, I hit an obstacle pertaining bundler.
> > > While we usually patched out bundler, ruby-combustion seems to be using
> > > bundler.
> > > Thus if any and every package that uses ruby-combustion is patched out
> > > for bundler, it's build fails.
> > > The logs of the failure point at combustion using bundler, saying:
> > > /var/lib/gems/2.5.0/gems/combustion-1.1.0/lib/combustion.rb:28:in
> > > `initialize!': uninitialized constant Combustion::Bundler (NameError)
> > >
> > > which is kinda obvious. Now that ruby (I guess?) also uses bundler
> > > somewhere, there's no escaping from it.
> > >
> > > Now, the packages using bundler and ruby-combustion, their autopkgtest
> > > fails (build is perfectly fine!) saying:
> > > "File does not exist: bundler/setup"
> > >
> > > which I find a little weird. I tried some work around(s) but all in
> > > vain. I might be missing something very obvious here, thus call out for
> > > help!
> > >
> > > Packages which show this behavior (for now):
> > > - ruby-arbre
> > > - ruby-ahoy-email
> > >
> > > Could you maybe take a look at them and write a patch to fix the same? I
> > > am kinda tired doing this now.
> >
> > You want to make ruby-combustion depend on ruby-bundler, because it
> > seems to use bundler at runtime.
> >
> > "File does not exist: bundler/setup" rings a giant bell in that
> > direction. :)
> >
>
> Geez, that didn't help either :/
> The error still remains the same, I tried building up ruby-combustion (with
> ruby-bundler in its depends) locally and then passing it with the other
> packages.
> Doesn't make a difference :/
>
> Maybe tomorrow, I'll formally upload ruby-combustion and then you can give
> this a try as well :D
That's pretty weird.
I went and took a look, and this is what I found. I hope this is useful
as small tutorial on how to debug weird stuff like this.
So, to to start I passed --shell-fail to autopkgtest against ruby-arbre
from git. That will give me a shell inside the testbed when the test
fails, which indeed happened in this case.
Inside the testbed, my first step was reproducing the issue. For this it
was enough to run just one of the files where the error appeared:
----------------8<----------------8<----------------8<-----------------
# rspec spec/rails/rails_spec_helper.rb
An error occurred while loading ./spec/rails/rails_spec_helper.rb.
Failure/Error: require 'bundler/setup'
LoadError:
cannot load such file -- bundler/setup
# ./spec/rails/rails_spec_helper.rb:2:in `<top (required)>'
No examples found.
Finished in 0.00017 seconds (files took 0.07584 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples
----------------8<----------------8<----------------8<-----------------
Then I installed vim, and added a pry prompt right before the point
where it tries to load bundler/setup and fails:
----------------8<----------------8<----------------8<-----------------
# diff -u spec/rails/rails_spec_helper.rb.orig spec/rails/rails_spec_helper.rb
--- spec/rails/rails_spec_helper.rb.orig 2019-08-23 10:39:19.235088800 +0000
+++ spec/rails/rails_spec_helper.rb 2019-08-23 10:39:41.934982349 +0000
@@ -1,4 +1,6 @@
require 'rubygems'
+require 'pry'
+binding.pry
require 'bundler/setup'
require 'combustion'
----------------8<----------------8<----------------8<-----------------
Then I tried to inspect whether bundler is visible as gem:
----------------8<----------------8<----------------8<-----------------
[1] pry(main)> gem 'bundler'
Gem::MissingSpecVersionError: Could not find 'bundler' (2.0.1) required by your /tmp/autopkgtest-lxc.l4zbgklv/downtmp/build.HLa/real-tree/Gemfile.lock.
To update to the latest version installed on your system, run `bundle update --bundler`.
To install the missing version, run `gem install bundler:2.0.1`
Checked in 'GEM_PATH=/home/debci/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all', execute `gem env` for more information
from /usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs'
----------------8<----------------8<----------------8<-----------------
I noted that it is looking for bundler 2.0.1, which is not the version we have:
----------------8<----------------8<----------------8<-----------------
# gem list bundler
*** LOCAL GEMS ***
bundler (1.17.3)
----------------8<----------------8<----------------8<-----------------
Then I installed ack and looked for `2.0.1` in the source tree:
----------------8<----------------8<----------------8<-----------------
# ack 2.0.1
Gemfile.lock
224: 2.0.1
.travis.yml
5: - gem install bundler:2.0.1
----------------8<----------------8<----------------8<-----------------
It turns out bundler is loading the Gemfile.lock (as it does), and
locking the version of "itself" to 2.0.1 which of course won't be found.
And that's what causes 'bundler/setup' to not be found.
One way of solving this would be to move Gemfile.lock away:
----------------8<----------------8<----------------8<-----------------
# mv Gemfile.lock /root
# rspec spec/rails/rails_spec_helper.rb
No examples found.
Finished in 0.00025 seconds (files took 0.96797 seconds to load)
0 examples, 0 failures
----------------8<----------------8<----------------8<-----------------
(no tests to run as this is a helper file, but the fact that it didn't crash is
a win; note that at this point I removed the pry usage before running rspec again).
But removing the Gemfile.lock cleanly would require repackaging the source, and
that can quickly become a mess. a better option is probably to copy the Gemfile
(not Gemfile.lock) and the gemspec (because the Gemfile refers to it) somewhere
else other than the root, and make bundler use that instead of the source
package. This will cause bundler to look for a Gemfile.lock in the same
directory as the gemfile (and it won't find one so it will use the packages in
any version that we actually have).
One way of doing that is:
----------------8<----------------8<----------------8<-----------------
diff --git a/debian/ruby-tests.rake b/debian/ruby-tests.rake
index cf1591e..c4444c8 100644
--- a/debian/ruby-tests.rake
+++ b/debian/ruby-tests.rake
@@ -1,4 +1,12 @@
require 'gem2deb/rake/spectask'
+require 'fileutils'
+require 'tmpdir'
+
+tmpdir = Dir.mktmpdir
+at_exit { FileUtils.rm_rf(tmpdir) }
+FileUtils.cp('Gemfile', tmpdir)
+FileUtils.cp('arbre.gemspec', tmpdir)
+ENV['BUNDLE_GEMFILE'] = tmpdir + '/Gemfile'
Gem2Deb::Rake::RSpecTask.new do |spec|
spec.pattern = './spec/**/*_spec.rb'
----------------8<----------------8<----------------8<-----------------
I tested building ruby-arbre with that change, and both build and autopkgtest
worked.
Now, I'm not sure why it only fails in that way under autopkgtest and not
during the build. Figuring that out is left as an exercise to the reader.
Attachment:
signature.asc
Description: PGP signature