Bug in Berkshelf, or Solve? Seems to be solve...

jtimberman commented 11 years ago

I'm not sure how to report this bug. It appears to be coming from solve, even though I encounter it with Berkshelf (v3.0.0.beta2). Here's the scenario.

I am working with a large number of cookbooks in an existing chef-repo. Most of them are private, and for number of reasons are not in separate repositories nor released on the community site. I want to use the :path directive for each cookbook for my Berksfile:

cookbook "opscode-foo", :path => "./cookbooks/opscode-foo"

We have over 200 cookbooks in the directory. I shortcut this with the following in my Berksfile:

Dir.glob(File.join(File.dirname(__FILE__), "cookbooks", "*")).each do |cb|
  if ::File.directory?(cb)
    cookbook File.basename(cb), :path => cb
  end
end

When I run berks install, it gets to building universe and then hits an infinite loop. As near as I can tell, through judicious use of puts in the solve library, it hits this code path:

if variable.value.nil?
  reset_possible_values_for(variable)
end

And variable.value is nil for every cookbook. I put the following line above the if statement:

puts variable.inspect

I see this output:

#<Solve::Solver::VariableRow:0x007f824c97b000 @artifact="opscode-base", @value=nil, @sources=[:root]>

I'm not sure where else to debug this, or how to get more appropriate information. It appears that this is a solve bug, not a berkshelf bug, so I am reporting it here. However, perhaps this is a berkshelf bug, since it should know about its world because I have all these cookbooks locally (and said so, in the Berksfile).

jtimberman commented 11 years ago

When it's printing the "debug" (ahem) message over and over, and I hit ^C, I see this stack trace:

^C/Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/forwardable.rb:171:in `name': Interrupt
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver/constraint_table.rb:20:in `block in constraints_on_artifact'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver/constraint_table.rb:19:in `select'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver/constraint_table.rb:19:in `constraints_on_artifact'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:251:in `possible_values_for'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:288:in `reset_possible_values_for'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:314:in `block in backtrack'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:313:in `each'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:313:in `backtrack'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:118:in `resolve'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve.rb:39:in `it!'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/resolver.rb:71:in `resolve'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/installer.rb:43:in `run'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/berksfile.rb:349:in `install'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/cli.rb:186:in `install'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/cli.rb:52:in `dispatch'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/cli.rb:27:in `execute!'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/bin/berks:5:in `<top (required)>'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/bin/berks:23:in `load'
    from /Users/jtimberman/.rbenv/versions/2.0.0-p247/bin/berks:23:in `<main>'

andrewGarson commented 11 years ago

@jtimberman This does sound like it might be a solve bug, but I'll need to see the graph coming in to Solve to figure it out. I don't think that anybody has ever run Solve against a constraint graph with 200+ demands. That'll definitely slow it down (although the behavior you are describing seems weird)

we have some debugging tools in Solve that we don't really expose anywhere.

1) Serialize out the Solver and we can take a look at the problem / I can load up the problem myself

serializer = Solve::Solver::Serializer.new
solver = Solve::Solver.new(graph, demands) # https://github.com/RiotGames/solve/blob/master/lib/solve.rb#L37
problem = serializer.serialize(solver)
puts problem

2) Turn on tracing by passing an optional UI object to Solve.it! - THIS WILL SLOW THINGS DOWN A LOT

class StupidUI
  def say(message)
    puts message
  end
end

Solve.it!(graph, demands, { :ui => StupidUI.new })

reset commented 11 years ago

@jtimberman any luck with getting the debug output that @andrewGarson requested?

jtimberman commented 11 years ago

Haven't had a chance to do that yet :-/. Maybe tomorrow.

grobie commented 10 years ago

I can confirm this behavior in our cookbook setup and am certain that solve is the issue here. The current resolver implementation has a worst case runtime behavior of O(n!) which can easily result in hundreds of thousands of version satisfaction tests. See #30 for more information.

RSTJNII commented 10 years ago

I'm seeing similar issues with only 17 cookbooks. I updated to 3.0.0.beta4 to try and resolve a dependency version issue, but "berks install" never completes:

$ bundle exec berks version
3.0.0.beta4
$ time bundle exec berks install
DEPRECATED: Your Berksfile contains a site location pointing to the Opscode Community Site (site :opscode). Site locations have been replaced by the source location. Change this to: 'source "http://api.berkshelf.com" to remove this warning. For more information visit https://github.com/berkshelf/berkshelf/wiki/deprecated-locations
Fetching 'wordpress' from git: 'git://github.com/RSTJNII/wordpress.git' with branch: 'master'
Fetching 'cloud_monitoring' from git: 'https://github.com/RSTJNII/cookbook-cloudmonitoring' with branch: 'yum_key-versionfix'
building universe...
<Killed with ctrl-C>
^C/var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:164:in `block in artifact_collection': Interrupt
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:164:in `each'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:164:in `collect'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:164:in `artifact_collection'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:61:in `artifacts'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:86:in `versions'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/solver.rb:267:in `block in add_dependencies'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/solver.rb:262:in `each'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/solver.rb:262:in `add_dependencies'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/solver.rb:111:in `resolve'
        from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve.rb:39:in `it!'
        from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/resolver.rb:73:in `resolve'
        from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/installer.rb:53:in `run'
        from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/berksfile.rb:353:in `install'
        from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/cli.rb:143:in `install'
        from /var/lib/gems/1.9.1/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
        from /var/lib/gems/1.9.1/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
        from /var/lib/gems/1.9.1/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
        from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/cli.rb:52:in `dispatch'
        from /var/lib/gems/1.9.1/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
        from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/cli.rb:27:in `execute!'
        from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/bin/berks:5:in `<top (required)>'
        from /var/lib/gems/1.9.1/bin/berks:23:in `load'
        from /var/lib/gems/1.9.1/bin/berks:23:in `<main>'

real    3646m53.023s
user    3632m42.990s
sys     0m20.913s

I let that run for 2.5 days, I would have expected it to complete if it was just a O(n!) issue. Ruby did have one core at 100% for the duration of the run. Here is the 'berks install' output of 2.0.10 for comparison:

$ berks version
Berkshelf (2.0.10)
<Snip license>
$ time berks install
Using wordpress-rolebook (0.1.1) from metadata
Installing wordpress (1.3.1) from git: 'git://github.com/RSTJNII/wordpress.git' with branch: 'master' at ref: '34f3f471a2ca62f754aab201699dfd6b9b94703f'
Installing cloud_monitoring (1.0.5) from git: 'https://github.com/RSTJNII/cookbook-cloudmonitoring' with branch: 'yum_key-versionfix' at ref: '833ab818387de449486e009a1e52d4c6261e118b'
Installing iptables (0.12.0) from site: 'http://cookbooks.opscode.com/api/v1/cookbooks'
Using php (1.3.10)
Using build-essential (1.4.2)
Using xml (1.2.0)
Using mysql (4.0.14)
Using openssl (1.1.0)
Using yum-epel (0.2.0)
Using yum (3.0.4)
Using windows (1.12.6)
Using chef_handler (1.1.4)
Using iis (2.0.0)
Using apache2 (1.8.14)
Installing chef_gem (0.1.0) from site: 'http://cookbooks.opscode.com/api/v1/cookbooks'
Using apt (2.3.4)
Installing python (1.4.4) from site: 'http://cookbooks.opscode.com/api/v1/cookbooks'

real    0m19.034s
user    0m1.800s
sys     0m0.364s

I'm not familiar enough with Berkshelf to provide the debugging information andrewGarson requested above at this time. Please also let me know if this should be reported against https://github.com/berkshelf/berkshelf/issues/959. Thanks.

keitwb commented 10 years ago

I am also running into this infinite loop issue with version 3.0.0.beta4. I was able to run the debugging commands above (specifically the second one with a File output UI) and got these (truncated to 500K) results. The output kept looping over and over around the "Could not find an acceptable value for virtualenvwrapper" and subsequent re-attempt at "Resetting possible values for virtualenvwrapper" event. The same thing appears to be happening with 'openssl' as well, though as far as I know the 'virutalenvwrapper' and 'openssl' cookbooks are not dependent on each other in any way.

Here is the main Berksfile that the troubled berks install command is using:

cookbook 'fpn_app', path: 'site-cookbooks/fpn_app'

Inside the 'fpn_app' cookbook, there is another Berksfile which looks like this:

site :opscode

metadata

cookbook 'postgresql', git: 'https://github.com/hw-cookbooks/postgresql.git'
# Use this until https://github.com/blackrobot/chef-virtualenvwrapper/pull/1 is accepted
cookbook 'virtualenvwrapper', git: 'https://github.com/keitwb/chef-virtualenvwrapper.git', branch: 'distlib_fix'
#cookbook 'virtualenvwrapper', git: 'https://github.com/blackrobot/chef-virtualenvwrapper.git'

cookbook 'quoin', path: '/share/code/quoin/quoin-cookbook'

The metadata.rb file for that cookbook is thus:

name             'fpn_app'
maintainer       'Quoin'
maintainer_email 'fpn.dev@quoininc.com'
license          'All rights reserved'
description      'Installs/Configures the ******* site'
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version          '0.1.0'

depends 'git'
depends 'quoin'
depends 'postgresql'
depends 'database'
depends 'nginx'
depends 'apt'
depends 'openssl' # Hack for https://github.com/coroutine/chef-postgresql/issues/10
depends 'virtualenvwrapper'
depends 'python'

It doesn't seem to work with the original virutalenvwrapper repository commented out in the application cookbook's Berksfile or with my bugfix fork. I have tried fixing the version on that dependency but no luck. I'm sure I've got something wrong here as I'm just learning chef/berkshelf, so perhaps somebody knows a workaround until this bug can be fixed?

andrewGarson commented 10 years ago

@keitwb could you send me the entire output by any chance? How long did you let it run before you killed it? Depending on the size of the graph not finding a solution could take a very very long time (weeks).

keitwb commented 10 years ago

Full output is here on Dropbox (just shy of 1 million lines). It probably ran for several minutes, I don't think any more than 10 minutes or so. I can't tell for sure but it looks like the output just started repeating the same thing over and over against after the first couple thousand lines of output.

damacus commented 10 years ago

So I'm also getting the same problem here. I've got a bunch of git repos in my Berksfile.

Taking a look at the output from @keitwb it's resetting the possible values for the cookbooks over and over, so it never resolves them.

Is there anything I can do to help diagnose this bug?

reset commented 10 years ago

@damacus the bug has already been well identified. The only work left now is to re-write the graph solver in Solve or a cross compatible set of FFI/C bindings for Gecode.

nicholasserra commented 10 years ago

Is there a final tracking issue for this? Subscribing.

sethvargo commented 10 years ago

@nicholasserra we are still working on it/

iroller commented 10 years ago

Looks like I have the same bug.

Berkshelf 3.0.beta7 starts to eat 100% of CPU and gets into an infinite loop

My environment

% ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin13.0]

% grep berks Gemfile
gem 'berkshelf', :github => 'berkshelf/berkshelf', ref: '776e9'

Configuration files

Berksfile

source 'http://berks-api:26200'
metadata
cookbook "local-cookbook", "= 0.0.1", path: "~/git/local-cookbook"
cookbook "fixture-cookbook", path: "test/fixtures/cookbooks/fixture-cookbook"

metadata.rb

It has a few cookbook to resolve from our internal Chef server

Backtrace

DEBUG_RESOLVER=1 bundle exec berks install -d gives me the following output:

Fetching cookbook index from http://berks-api:26200...

Attempting to find a solution
Adding constraint my-cookbook = 0.1.0 from root
Resetting possible values for my-cookbook
Possible values are my-cookbook-0.1.0
Adding constraint apt >= 0.0.0 from root
...
... all the deps are here ...
...
Searching for a value for my-cookbook
Constraints are = 0.1.0

Possible values are ["my-cookbook", [#<Solve::Artifact:0x007fee5ccc24d0 @graph=.....
...
Could not find an acceptable value for another_cookbook
Unbinding yum
Resetting possible values for another_cookbook
Searching for a value for yum

... here goes an infinite loop

So it fails on another_cookbook which is a fixture cookbook for serverspec tests located in cookbook-dependency/test/fixtures/cookbooks/another_cookbook.

Pressing Ctrl+C gives the following output:

^C/Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:164:in `block in artifact_collection': Interrupt
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:164:in `each'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:164:in `collect'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:164:in `artifact_collection'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:61:in `artifacts'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:86:in `versions'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/solver.rb:267:in `block in add_dependencies'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/solver.rb:262:in `each'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/solver.rb:262:in `add_dependencies'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/solver.rb:111:in `resolve'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve.rb:39:in `it!'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/resolver.rb:73:in `resolve'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/installer.rb:104:in `install_from_universe'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/installer.rb:37:in `run'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/berksfile.rb:364:in `install'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/cli.rb:143:in `install'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/cli.rb:52:in `dispatch'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/cli.rb:27:in `execute!'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/bin/berks:5:in `<top (required)>'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bin/berks:23:in `load'
    from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bin/berks:23:in `<main>'

sethvargo commented 10 years ago

@iroller yup. Definitely looks like the bug. We need to fix solve and that's not an easy task. There are also talks of moving to gecode.

iroller commented 10 years ago

Fixed mine by removing an extra dependency from metadata (https://github.com/sethvargo-cookbooks/users/pull/47). Tried to make a reproducible test case but no luck, only fails when it has a bunch of other internal dependencies, sorry.

ampledata commented 10 years ago

this.

sethvargo commented 10 years ago

@ampledata yes?

ampledata commented 10 years ago

Hah, sorry, this is what I'm currently battling myself. I'm seeing the same behavior outlined above, e.g. infinite loop on dep resolution or and/or unresolvable deps on fixture cookbooks.

A work-around I've just tried (and seems to hold) is to specify all deps in my main infrastructure Berksfile. This leads to a lot of duplication, but it works.

To Reproduce:

Create cookbooks: A & B & Infrastructure Code Berksfile:

A Cookbook:

Generic, no depends, no Berksfile.

B Cookbook:

metadata.rb: depends 'A'
Berksfile: cookbook 'A', git: 'git@github.com:example/A.git', branch: 'master'

Infrastructure Code:

Berksfile: cookbook 'B', git: 'git@github.com:example/B.git', branch: 'master'

Run: `$ berks install`

Expected Result

Cookbooks get got, puppies get saved.

Actual Result

Unable to find a solution for demands: B (1.0.0)

Work-around

Specify all dependencies in the Infrastructure Code Berksfile:

cookbook 'A', git: 'git@github.com:example/A.git', branch: 'master'
cookbook 'B', git: 'git@github.com:example/B.git', branch: 'master'

sethvargo commented 10 years ago

@ampledata okay - you were just adding that this affects you as well?

mansona commented 10 years ago

So i understand the workaround but is there any way to know which of the dependancies in the tree is causing the problem?

sethvargo commented 10 years ago

@mansona manually - yes. Automated - working on it.

mansona commented 10 years ago

any pointers for me? the last output for me before it goes nuts is

Searching for a value for apt
Constraints are >= 0.0.0

so that makes me think that the problem is apt... and i'm a bit lost as to what i should do next...

ampledata commented 10 years ago

@mansona can u post your entire dependency tree? do you have any cookbooks that are importing a non community version of apt?

mansona commented 10 years ago

is there a good way to do that? get the dependancy tree i mean... or is it just manually going through all metadata.rb files in cookbooks and keeping note of the versions?

sethvargo commented 10 years ago

We have recently merged #33, which switches to gecode for dependency resolution. While we have not released a new version, this merge closes this issue.

mansona commented 10 years ago

so it's in master but if i do a bundle install it wont bring down this fixed version right? sorry i'm not a ruby guy :wink: where can i "follow" to be notified of a release?

sethvargo commented 10 years ago

@mansona if you "watch" this project on GitHub, you'll get a notification when we cut a new tag (which will correspond to a new release). You can also subscribe to the RSS feed for the gem: https://rubygems.org/gems/solve.

mansona commented 10 years ago

awesome! thanks guys! just checked ruby gems there now and it looks like you released a version of berkshelf and solve 19 hours ago https://cloudup.com/cBylaGAtBVi i'm assuming these should have the fix?

reset commented 10 years ago

@mansona yes, the latest beta release (9) of Berkshelf should solve this completely

mansona commented 10 years ago

Hmm... well i'm still having some problems but it's unrelated to this issue (I think) I asked the question on Stack Overflow because I thought it sounded more like an issue with my setup, although any help would be much appreciated

http://stackoverflow.com/questions/22930511/symbol-not-found-when-using-ruby-gem-berkshelf

reset commented 10 years ago

@mansona the issue you're seeing is because you're using Gecode 4 and not Gecode 3. You can uninstall Gecode 4 and install 3 or wait a few days and there'll be a much easier way for us to get you Gecode.

mansona commented 10 years ago

Yea i guess if you're in the middle of moving a few things around then I should just wait. I managed to install an older version of gecode using help from this SO question but now i'm stuck when i'm trying to use test kitchen because it needs dep-selector-libgecode -v '1.0.0.rc.0' which i'm guessing is incompatible because i get this error when I try to install it:

ERROR:  Error installing dep-selector-libgecode:
    invalid gem: package is corrupt, exception while verifying: undefined method `path2class' for #<Psych::ClassLoader:0x00000101beb250> (NoMethodError) in /usr/local/rvm/gems/ruby-2.0.0-p451/cache/dep-selector-libgecode-1.0.0.rc.0.gem

Should we create a new bug that keep track of these dependancy problems or will i just wait for confirmation here?

reset commented 10 years ago

@mansona you should actually open a ticket with dep-selector-libgecode for that issue. That doesn't look good.

jtimberman commented 10 years ago

:thumbsup: Glad this is resolved, the change to gecode is delightful.

mansona commented 10 years ago

@reset i've solved all my issues by using the new chef-dk this has solved all but one of my dependancy issues.

reset commented 10 years ago

@mansona good to hear. What dependency issue was chef-dk not able to solve?

mansona commented 10 years ago

@reset https://github.com/opscode/chef-dk/issues/15 open issue to make it plain sailing for anyone else ;) i'm personally all set now

berkshelf / solve