06:53 <ShiroiKuma> I'm reading the docs, but so far unable to find a solution to the problem of missing dependencies from a bundle install that works on one machine but not another. In short, is there any known reason a gem wouldn't download on one machine?

06:57 <kgrz> ShiroiKuma: Just guessing here; may be the platform is different? some gems depend on a particular platform. some extensions may check for certain libraries to be present on the machine. It would be of help if you can provide the Gemfile.locks (and the Gemfile, ofcourse) on both the machines

06:59 <ShiroiKuma> kgrz: I guess there may be some platform differences, but the gem in question (ice_nine) only lists bundler as it's sole dependency. The 2 platforms are indeed different and it's only ice_nine that seems to be missing on the arm one versus the x64 platform.

06:59 <ShiroiKuma> kgrz: How would I go about checking additional dependencies of said ice_nine module? Sorry I'm not much of a Ruby developer, only a user :(

07:02 <ShiroiKuma> The Gemfile in question was downloaded from git. https://github.com/gitlabhq/gitlab-ci/blob/v7.8.4/Gemfile

07:02 <ShiroiKuma> And also the Gemfile.lock too https://github.com/gitlabhq/gitlab-ci/blob/v7.8.4/Gemfile.lock

07:04 <kgrz> ShiroiKuma: Any information on which gems were not dowloaded on the other machine? I see some platform specific gems there — OS notification wrappers

07:08 <ShiroiKuma> kgrz: I'm running without development and test, so those are being ignored anyway. But looking at the lock file, Virtus has a dep on Axiom_Types, and Axion_Types has a dep on Ice_Nine which has no further deps. At the moment, when trying to run the application I get an error that Ice_Nine doesn't exist. A bundle check, tells me all is okay. But comparing the vendor/bundle/ folders the one that stands out

07:08 <ShiroiKuma> immediately is ice_nine being missing

07:11 <kgrz> okay, yeah I even I don't see any platform based deps in ice_nine gem. Does manual installation work? That is, if you run `gem install axiom-types` or `gem install ice_nine`?

07:11 <ShiroiKuma> Oh, and there is one more confusing issue. Another application, which also depends on ice_nine (https://raw.githubusercontent.com/gitlabhq/gitlabhq/v7.8.4/Gemfile https://raw.githubusercontent.com/gitlabhq/gitlabhq/v7.8.4/Gemfile.lock) has it installed correctly.

07:12 <ShiroiKuma> If I do that, it works, but the application doesn't recognize it. Maybe as it get's put under $HOME instead of the apps vendor/bundle dir

07:13 <kgrz> yeah, that'd be the reason. I just wanted to know if it's being downloaded and installed normally

07:16 <ShiroiKuma> I've put up a pastebin of the section where it says it's installing the gems. http://pastebin.com/miQRzHnh You can see it's skipping it

07:18 <kgrz> ShiroiKuma: Interesting. I've noticed that the versions of ice_nine in each of the lock files is different. one uses 0.10.0 and the other 0.11.0 I think 0.10.0 is what worked on both machines

07:19 <kgrz> the change between both these versions is: https://github.com/dkubb/ice_nine/compare/5b47e6f...master

07:21 <kgrz> can you update gitlab-ci's Gemfile and add `gem ice_nine, '0.10.0'` and then run `bundle update virtus`? That _should_ update the ice_nine version resolution to 0.10.0

07:22 <kgrz> or probably `bundle update ice_nine` if that works.

07:22 <ShiroiKuma> Lemme check if that works, I'm just the end user ^^ What about the lockfile should I alter that at all?

07:23 <kgrz> bundle update <gem> will update the lockfile

07:25 <ShiroiKuma> "You are trying to install in deployment mode after changing your Gemfile. Run `bundle install` elsewhere and add the updated Gemfile.lock to version control."

07:25 <ShiroiKuma> "If this is a development machine, remove the Gemfile freeze by running `bundle install --no-deployment`."

07:25 <ShiroiKuma> Should I do that?

07:27 <kgrz> I hope the machine you're testing on is not a production machine :D

07:27 <kgrz> If it's not, then go ahead

07:28 <ShiroiKuma> Not yet, it's a new install on the new pi, most things are working nicely though.

07:28 <kgrz> if it is, then clone the repo to a different folder and run `bundle install --path=vendor` (that's what the first instruction means, I think)

07:31 <ShiroiKuma> It's all under it's own subfolder now, so I can just start again if it's trashed. ^^ Oh, it's downloaded ice_nine 0.10.0 now in the output (still going)

07:32 <ShiroiKuma> Maybe I should write a script to get the repo, and replace ice_nine 0.11.0 with ice_nine 0.10.0 in the Gemfile.lock before running bundle install. Axion is only asking for ~> 0.9

07:37 <ShiroiKuma> And finally atleast rake -T now works, getting somewhere! Thanks ever much so far.

07:38 <kgrz> Or, clone the repo and maintain a fork and keep the repos in sync every time there's a release in the main gem. But the question still stays. Why didn't it download when the gem version is 0.11.0

07:39 <kgrz> may be open an issue on the ice_nine repo? linking to this chat log?

07:39 <kgrz> Are you using MRI or Rubinius?

07:40 <ShiroiKuma> It's a really weird issue, I'd have expected at error/warning atleast. I'm going to update my issue on gitlab_ci about it, but I'll also report it to ice_nine repo too.

07:43 <ShiroiKuma> I'm not using MRI or Rubinus, I'm doing this on Gentoo linux, I'm updating my ebuild file now to swap out the version as part of the install procedure.

21:40 <sshaw> Anyone else having problems running bundle exec rake with minitest + Ruby 2.2?

21:41 <sshaw> cannot load such file -- minitest/autorun

21:41 <sshaw> No problems when running outside of bundle exec

21:41 <sshaw> or versions of Ruby < 2.2

21:42 <sshaw> Well, bundle exec rake tests

21:43 <sshaw> https://travis-ci.org/sshaw/logging-appenders-airbrake/builds/55316386