Skip to content

ruby-chef broken #186

Description

@bahamat

In a global zone, with pkgsrc-tools

[root@smartos-iso /var/chef]# /opt/tools/bin/chef-solo -c /var/chef/solo.rb
/opt/tools/lib/ruby/2.4.0/rubygems/dependency.rb:310:in `to_specs': Could not find 'libyajl2' (~> 1.2) - did find: [libyajl2-2.0.0] (Gem::MissingSpecVersionError)
Checked in 'GEM_PATH=/root/.gem/ruby/2.4.0:/opt/tools/lib/ruby/gems/2.4.0', execute `gem env` for more information
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1445:in `block in activate_dependencies'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1434:in `each'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1434:in `activate_dependencies'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1416:in `activate'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1448:in `block in activate_dependencies'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1434:in `each'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1434:in `activate_dependencies'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1416:in `activate'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1448:in `block in activate_dependencies'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1434:in `each'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1434:in `activate_dependencies'
	from /opt/tools/lib/ruby/2.4.0/rubygems/specification.rb:1416:in `activate'
	from /opt/tools/lib/ruby/2.4.0/rubygems.rb:300:in `block in activate_bin_path'
	from /opt/tools/lib/ruby/2.4.0/rubygems.rb:300:in `synchronize'
	from /opt/tools/lib/ruby/2.4.0/rubygems.rb:300:in `activate_bin_path'
	from /opt/tools/bin/chef-solo24:23:in `<main>'

But...

[root@smartos-iso /opt/custom/templates]# pkg_info -e ruby24-libyajl2
ruby24-libyajl2-2.0.0

Meanwhile, in a zone:

[root@cf33cc2c-60f4-e687-878a-e66f19f2df7c /var/chef]# /opt/local/bin/chef-solo -c /var/chef/solo.rb
/opt/local/lib/ruby/2.4.0/rubygems/dependency.rb:310:in `to_specs': Could not find 'net-ssh' (~> 4.2) - did find: [net-ssh-5.0.2] (Gem::MissingSpecVersionError)
Checked in 'GEM_PATH=/root/.gem/ruby/2.4.0:/opt/local/lib/ruby/gems/2.4.0', execute `gem env` for more information
	from /opt/local/lib/ruby/2.4.0/rubygems/specification.rb:1445:in `block in activate_dependencies'
	from /opt/local/lib/ruby/2.4.0/rubygems/specification.rb:1434:in `each'
	from /opt/local/lib/ruby/2.4.0/rubygems/specification.rb:1434:in `activate_dependencies'
	from /opt/local/lib/ruby/2.4.0/rubygems/specification.rb:1416:in `activate'
	from /opt/local/lib/ruby/2.4.0/rubygems.rb:300:in `block in activate_bin_path'
	from /opt/local/lib/ruby/2.4.0/rubygems.rb:300:in `synchronize'
	from /opt/local/lib/ruby/2.4.0/rubygems.rb:300:in `activate_bin_path'
	from /opt/local/bin/chef-solo24:23:in `<main>'

But...

[root@cf33cc2c-60f4-e687-878a-e66f19f2df7c /var/chef]# pkg_info -e ruby24-net-ssh
ruby24-net-ssh-5.0.2

This happens with 2017Q4 and 2018Q4.

Activity

  1. changed the title [-]chef broken[/-] [+]ruby-chef broken[/+] on Apr 2, 2019
  2. jperkin commented on Apr 3, 2019

    @jperkin
    Collaborator

    You may be able to get away with editing the specs to remove the specific version constraint, often it will just work with newer versions anyway.

    As for updating the package to work against the newer ruby libraries, they're now shipping IPS packages instead of the SVR4 ones so this will be more difficult and probably mean we'll need to roll our own. This may take a while.

  3. self-assigned this
    on Apr 3, 2019
  4. bahamat commented on Apr 3, 2019

    @bahamat
    Author

    Do you mean that this error is being thrown because of the spec directory in my cookbooks?

  5. jperkin commented on Apr 3, 2019

    @jperkin
    Collaborator

    No, the specs in chef. So for example, this error:

    Could not find 'net-ssh' (~> 4.2) - did find: [net-ssh-5.0.2]
    

    If you search through the chef files for where it specifies ~> 4.2 which from memory means 4.2 or newer but not greater than 4.x, and change it to a value where 5.x (maybe just >= 4.2 I think) is permitted then you might it just works. I've done this before with various packages, developers tend to be on the conservative side when specifying dependency matches.

    Obviously it's a hack, but may get things working until the package can be updated.

  6. added a commit that references this issue on Jul 1, 2019
    2ccac82
  7. added a commit that references this issue on Jul 15, 2019
  8. added a commit that references this issue on Nov 6, 2019
  9. added a commit that references this issue on Nov 24, 2019
  10. added a commit that references this issue on Dec 15, 2019
  11. added a commit that references this issue on Jan 3, 2020
  12. added a commit that references this issue on Jan 11, 2020
  13. 98 remaining items

  14. added a commit that references this issue on Aug 7, 2026
  15. added a commit that references this issue on Aug 25, 2026
  16. added a commit that references this issue on Sep 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions