[SOLVED] Problem compiling OpenNebula 5.4.0 gems in Centos7

Community Support
1

Hi all

I’m not sure if this is an known issue or not.
I’m trying to generate the new gem rpm packages required by OpenNebula 5.4.0 version but I got this error:

...
Compiling required gems.. Please wait.
ERROR:  Error installing nokogiri:
	nokogiri requires Ruby version >= 2.1.0.

It looks like install_gems tries to install the latest nokogiri version but at this moment it requires Ruby 2.1.0 unfortunately in Centos7:

$ ruby --version
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]

I have generated the same package some months ago: rubygem-nokogiri-1.6.6.2-1.x86_64 that seems to work with OpenNebula 5.4.0…

My question is if OpenNebula 5.4.0 requires the latest version or with nokogiri 1.6.6 also works (I did some tests and it seems to work but I’m not 100% sure).

If so, it would be possible to include a version lock for nokogiri in install_gems script?, for OpenNebula 5.4.0 it has these dependencies:

$ /usr/share/one/install_gems --showallgems
**nokogiri**
rack --version "< 2.0.0"
**sinatra**
thin
memcache-client
zendesk_api --version "< 1.14.0"
sqlite3
sequel
amazon-ec2
uuidtools
curb
net-ldap --version "< 0.13"
builder
trollop
treetop --version ">= 1.6.3"
parse-cron
aws-sdk --version "~> 2.5"
ox
mysql2
aws-sdk
configparser
**azure**

Thanks a lot in advance!

Cheers
Álvaro

2

btw I got a similar error for sinatra and azure gems , the versions are also not restricted

3

Maybe your OS is not clean, installing custom RPMS is normally not a good idea.
Is there a specific reason to use a custom rubygem-nokogiri RPM?
Here is what happens to me on a clean, up-to-date CentOS 7.3:

[root@frontend ~]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

[root@frontend ~]# ruby --version
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]

[root@frontend ~]# rpm -q rubygem-nokogiri
rubygem-nokogiri-1.6.1-1.el7.1.x86_64

[root@frontend ~]# /usr/share/one/install_gems --showallgems
nokogiri
rack --version “< 2.0.0”
sinatra
thin
memcache-client
zendesk_api --version “< 1.14.0”
sqlite3
sequel
amazon-ec2
uuidtools
curb
net-ldap --version “< 0.13”
builder
trollop
treetop --version “>= 1.6.3”
parse-cron
aws-sdk --version “~> 2.5”
ox
mysql2
aws-sdk
configparser
azure

[root@frontend ~]# gem list

*** LOCAL GEMS ***

addressable (2.4.0)
amazon-ec2 (0.9.17)
aws-sdk (2.5.10)
aws-sdk-core (2.5.10)
aws-sdk-resources (2.5.10)
azure (0.7.6)
azure-core (0.1.4)
bigdecimal (1.2.0)
builder (3.2.2)
bundler (1.15.4)
configparser (0.1.4)
curb (0.9.3)
daemons (1.2.4)
eventmachine (1.2.0.1)
faraday (0.9.2)
faraday_middleware (0.10.0)
hashie (3.4.4)
inflection (1.0.0)
io-console (0.4.2)
jmespath (1.3.1)
json (1.8.3, 1.7.7)
memcache-client (1.8.5)
mime-types (2.99.2)
multipart-post (2.0.0)
mysql2 (0.4.9)
net-ldap (0.12.1)
nokogiri (1.6.1)
ox (2.4.4)
parse-cron (0.1.4)
polyglot (0.3.5)
psych (2.0.0)
rack (1.6.4)
rack-protection (1.5.3)
rake (0.9.6)
rdoc (4.0.0)
scrub_rb (1.0.1)
sequel (4.38.0)
sinatra (1.4.7)
sqlite3 (1.3.11)
systemu (2.6.5)
thin (1.7.0)
thor (0.19.1)
tilt (2.0.5)
treetop (1.6.8)
trollop (2.1.2)
uuidtools (2.1.5)
xml-simple (1.1.5)
zendesk_api (1.13.4)

4

install_gems now uses bundler by default and it needs the file Gemfile.lock in the same directory as Gemfile and install_gems to get the exact gem versions. There are specific versions per distribution, you can find the CentOS version here:

When the packages are built these files are placed in the correct directory.

In case you want to download the gems you can use bundler, execute this in a directory with both Gemfile and Gemfile.lock:

$ bundler install --path my_gems

The libraries will be downloaded to the directory my_gems.

5

Hi

Ah… that means that we should update the addon-installgems to take into account these changes and use bundler if the Gemfile.lock is available.

Thanks a lot for the info! I will try to write a PR to take into account these changes as soon as possible, in fact this simplifies the dependencies problem a lot.

Cheers
Álvaro