ignored by bundle on arm cpu

[CanisHelix]

I was having issues with gitlab-ci on my arm as noted by the issue opened at gitlabhq/gitlab-ci#566

Thanks to irc.freenode.org #bundle (as you can see from that chat log) though I was able to determine that 0.11.0 won't install on arm, neither would 0.11.1 but 0.10.0 will. So something has changed since that time to prevent the installation.

[dkubb]

I don't know enough about the arm cpu to determine what it can and cannot support. Does anything in this diff stand out to you: https://github.com/dkubb/ice_nine/compare/v0.10.0...v0.11.1

Is it possible one of the dependencies is not available on arm?

Even if I wanted to exclude a gem from a specific platform I'm not sure how I would go about doing that (although I would not be surprised if it were possible through configuration). ice_nine itself is written in pure ruby, so it's not like there's a C extension that is platform specific preventing installation.

[mbj]

Ruby is a high level enough language that CPU architecture details should not matter. AFAIK ice_nine does only use pure ruby APIs that are not CPU dependent.

As the different behavior manifests on bundlers dependency resolution, we might look for a bug in ruby that is triggered on ARM when resolving ice_nine dependency. I do not see anything in the .gemspec that should limit ice_nine in terms of CPU architecture.

[CanisHelix]

I don't even know where to look into ruby issues, still got a 1.9 book laying around from when I intended to start learning but didn't start yet. Gitlab is currently the only ruby application I've used. My knowledge of installing a ruby application is, git clone, bundle install :-)

Based on experimentation it's got to be something to do with dependency resolution somehow. As root, and as a non-root user gem install ice_nine results in the following output

Fetching: ice_nine-0.11.1.gem (100%)
Successfully installed ice_nine-0.11.1
Parsing documentation for ice_nine-0.11.1
Installing ri documentation for ice_nine-0.11.1
Done installing documentation for ice_nine after 3 seconds
1 gem installed

and gem install ice_nine -v '0.11.0' yields (gitlab-ci's Gemfile.lock version)

Fetching: ice_nine-0.11.0.gem (100%)
Successfully installed ice_nine-0.11.0
Parsing documentation for ice_nine-0.11.0
Installing ri documentation for ice_nine-0.11.0
Done installing documentation for ice_nine after 3 seconds
1 gem installed

So the question is, why does bundle install skip it but a manual install works? Altering an applications Gemfile.lock before running bundle install resolves the immediate issue for me, but it's still a puzzle.

I've got 2 Pi's here running armv6 and armv7 so if there are outputs of any commands you'd like, I can provide them to you guys. I know arm support is not of the highest priority, but the help is appreciated.

[dkubb]

I know arm support is not of the highest priority, but the help is appreciated.

I have no problem with arm. If I had access to the hardware I'd probably be playing with it too :)

Based on experimentation it's got to be something to do with dependency resolution somehow.

Given the gem can actually install on the platform and is (I assume) usable, I think you and @mbj are right that this is most likely a dependency resolution issue within bundler. It's going to be a little hard to debug this via github issues, but I've got a few things I'd like to verify.

(After each paragraph below try repeating what you were doing originally and see if any of these changes makes a difference.)

The first think I would do is make sure you have the latest bundler and gem installed; 1.9.0 and 2.4.6 respectively.

The next thing I would do is add ice_nine 0.11.1 as an explicit dependency within your Gemfile. I think it's being pulled in as a transitive dependency, not a direct dependency, so we'll see if that makes a difference. You'll want to add something like this to your Gemfile:

gem 'ice_nine', '0.11.1'

If that doesn't work, we're going to test adding a git dependency instead of a rubygems dependency. If we fetch the git tag, it'll be the exact same sources. It's dependencies will be the same. The main difference is that we're using git instead of rubygems to fetch things. It's possible the bug is in rubygems and not bundler. You'll want to change that gem line you added above to something like this:

gem 'ice_nine', git: 'https://github.com/dkubb/ice_nine.git', tag: 'v0.11.1'

If for some reason you have problems fetching the repo via the https url, you can also replace this string with the ssh url, eg: 'git@github.com:dkubb/ice_nine.git'

I'm not sure what to do if all of these fail, so give them a try and we'll figure out something more to test. We can always ping the bundler people too for for more hints on things that can be tested.

[CanisHelix]

I'm currently using Bundler 1.7.3 as that's my distributions currently 'stable' version. However I just replaced 0.11.0 with 0.11.1 in the Gemfile.lock file before building and that's perfectly fine even as a dependency of axiom_types. So it's definitely only 0.11.0 that's silently failing to install. Atleast we got it narrowed down more specifically.

The Rasberry Pi's make great little low power servers. Especially the new quad core one.

[dkubb]

@ShiroiKuma Did you try the other things (besides upgrading bundler/gem), or are you comfortable with editing the Gemfile.lock prior to installation?

[dkubb]

Also when you said you replaced 0.11.0 with 0.11.1 in the Gemfile.lock, did you mean the Gemfile? The lock file is what is generated by bundler. Under normal operation you should never be hand editing it.

[mbj]

@ShiroiKuma You did not came back to us, so I assume the problem is solved upstream in bundler / rubygems. And will close this issue now.

In case you have new information or its still a problem let us know so we can reopen the issue.