i'm using a ubuntu vagrant box with installed capistrano to develop an application.
when i tried to deploy i get the following error:
/usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:152:in `require': no such file to load -- capistrano/ext/multistage (LoadError)
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:152:in `require'
from ./config/deploy.rb:3:in `load'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:172:in `load_from_file'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:89:in `load'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:86:in `load'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:86:in `each'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:86:in `load'
from Capfile:4:in `load'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:172:in `load_from_file'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:89:in `load'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:86:in `load'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:86:in `each'
from /usr/lib/ruby/vendor_ruby/capistrano/configuration/loading.rb:86:in `load'
from /usr/lib/ruby/vendor_ruby/capistrano/cli/execute.rb:65:in `load_recipes'
from /usr/lib/ruby/vendor_ruby/capistrano/cli/execute.rb:65:in `each'
from /usr/lib/ruby/vendor_ruby/capistrano/cli/execute.rb:65:in `load_recipes'
from /usr/lib/ruby/vendor_ruby/capistrano/cli/execute.rb:31:in `execute!'
from /usr/lib/ruby/vendor_ruby/capistrano/cli/execute.rb:14:in `execute'
from /usr/bin/cap:4
as google suggested i tried to reinstall capistrano, but this failed because of dependencies(net-ssh requires ruby >= 2.0)
so i installed net-ssh v2.9.2
sudo gem install net-ssh -v 2.9.2
Fetching: net-ssh-2.9.2.gem (100%)
Successfully installed net-ssh-2.9.2
1 gem installed
but now the next dependency error occures...
How do i make a fresh installation of capistrano working?
do i need a newer version of ruby(apt-get install ruby tells me that the newest version is already installed)?
Or is the cause of this error something complete different?
I can't see anything in your trace about what version of ruby you're on, but you did say "net-ssh requires ruby >= 2.0", so you might need a newer version of ruby like you said. You can check the version of ruby you're using with ruby -v. I would also recommend using a version manager so that you can use multiple versions between projects. I find RVM or rbenv to be good starting points.
OK, this is strange...
after running vagrant provision multiple(~5) times and installing/deinstalling multiple gems and ruby versions the next "vagrant provision" fixed the problem magicaly. i still dont know why this error occured and what fixed it, bull i'll close this question...
Related
I am having a problem running a Rails 4 app with Ruby Debug IDE using Visual Studio Code. This is the error I get.
/home/ziyan/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/rubygems/specification.rb:2158:in `method_missing'
: undefined method `this' for #<Gem::Specification:0x1271b08 debase-0.2.1> (NoMethodError)
from /home/ziyan/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/rubygems/specification.rb:1057:in `find_active_stub_by_path'
from /home/ziyan/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:64:in `require'
from /home/ziyan/.rvm/gems/ruby-2.3.0#tbv_website/gems/debase-0.2.1/lib/debase.rb:4:in `<top (required)>'
from /home/ziyan/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `require'
from /home/ziyan/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `rescue in require'
from /home/ziyan/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
from /home/ziyan/.rvm/gems/ruby-2.3.0#tbv_website/gems/ruby-debug-ide-0.6.0/lib/ruby-debug-ide.rb:8:in `<top (required)>'
from /home/ziyan/.rvm/gems/ruby-2.3.0#tbv_website/gems/ruby-debug-ide-0.6.0/bin/rdebug-ide:8:in `require_relative'
from /home/ziyan/.rvm/gems/ruby-2.3.0#tbv_website/gems/ruby-debug-ide-0.6.0/bin/rdebug-ide:8:in `<top (required)>'
from /home/ziyan/.rvm/gems/ruby-2.3.0#tbv_website/bin/rdebug-ide:23:in `load'
from /home/ziyan/.rvm/gems/ruby-2.3.0#tbv_website/bin/rdebug-ide:23:in `<main>'
from /home/ziyan/.rvm/gems/ruby-2.3.0#tbv_website/bin/ruby_executable_hooks:15:in `eval'
from /home/ziyan/.rvm/gems/ruby-2.3.0#tbv_website/bin/ruby_executable_hooks:15:in `<main>'
Extra details
Ruby 2.3.0
Ruby Debug IDE 0.6
IDE: Visual Studio Code + vscode-ruby
Different variations tried
Tried updating to Ruby 2.3.3
Tried downgrading ruby-debug-ide to 0.5
Tried upgrading ruby-debug-ide to 0.6.1.beta4
With no success
Extra
I started a new Rails 5 + Ruby 2.4.0 project and debugging works fine with it. It uses the same ruby-debug-ide version. So the version of ruby-debug-ide should be working.
I just solved the issue by updating rubygems to version 2.6.11 (I think it's the latest version available as of today).
$ gem update --system
Now debugging in VSCode works again.
My current config.
CentOS 7
RVM, latest stable
VSCode, latest stable with Ruby extension 0.10.4
Rails 4 - Ruby 2.3.3 (currently working on a Solidus-based e-commerce)
Debase 0.2.1, Ruby-Debug-IDE 0.6.1b4
I hope this will help you.
I have a Rails server application that uses the openid_connect gem. When I attempt to run it on CentOS 6.6, I get:
uninitialized constant OpenSSL::PKey::EC
Here is the full stacktrace:
$ rails server
/home/foo/.rvm/gems/ruby-2.1.3/gems/json-jwt-1.5.1/lib/json/jwk/jwkizable.rb:69:in `<top (required)>': uninitialized constant OpenSSL::PKey::EC (NameError)
from /home/foo/.rvm/gems/ruby-2.1.3/gems/json-jwt-1.5.1/lib/json/jwt.rb:102:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object/id_token.rb:1:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:7:in `block in <top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:6:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/response_object.rb:6:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect/connect_object.rb:52:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/openid_connect-0.9.2/lib/openid_connect.rb:85:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:76:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:76:in `block (2 levels) in require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:72:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:72:in `block in require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:61:in `each'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler/runtime.rb:61:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/bundler-1.10.6/lib/bundler.rb:134:in `require'
from /home/foo/tmp/openid_connect_sample/config/application.rb:7:in `<top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:53:in `require'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:53:in `block in <top (required)>'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:50:in `tap'
from /home/foo/.rvm/gems/ruby-2.1.3/gems/railties-3.2.22/lib/rails/commands.rb:50:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'
What does this mean and how I can I get past it?
This problem stems from Red Hat's refusal to include (for fear-of-patent-litigation reasons) certain Elliptic Curve (EC) algorithms in CentOS' default build of OpenSSL.
Note: According to #Cal's answer, CentOS 6.7 does not have this issue.
The openid_connect gem is dependent on the json-jwt gem, which uses one of those not-included algorithms.
Therefore, you need to rebuild a new version of OpenSSL that includes the needed algorithms.
These are the steps I followed (adapted from here) to build a new OpenSSL on my machine:
cd /usr/src
wget https://www.openssl.org/source/openssl-1.0.1l.tar.gz
yum install autoconf automake (you probably already have these installed)
tar zxvf openssl-1.0.1l.tar.gz
cd openssl-1.0.1l
export CFLAGS="-fPIC"
./config --prefix=/opt/openssl shared enable-ec enable-ecdh enable-ecdsa
make all
make install
Now, your Ruby is probably still linked against the old OpenSSL library, so you'll need to rebuild it to link to the new one.
Are you using rvm? Then great! Any new Rubies you install will build against the new OpenSSL. rvm remove your Ruby and re-install it (or simply install a different ruby version).
Not using rvm? Then I guess you'll need to rebuild Ruby the traditional way. But you probably already know how to do that, right? If not, you'll need to look in a different tutorial, because we can't cover that here.
Now reinstall bunder and do a bundle install, and your rails server should now run successfully.
(If anyone has corrections or clarifications to offer, please leave a comment and I'll make edits as necessary.)
I ran into this same problem with CentOS 6.6. But I didn't want to recompile a custom openssl and ruby to fix this. I didn't take very good notes because I tried so many things, but it appears that an update to all of the latest & greatest packages to CentOS 6.7 solves the problem.
Here are a few relevant package versions I have:
openssl098e-0.9.8e-18.el6_5.2.x86_64
openssl-1.0.1e-42.el6.x86_64
openssl-1.0.1e-42.el6.i686
openssl-devel-1.0.1e-42.el6.x86_64
glibc-2.12-1.166.el6_7.3.x86_64
kernel-2.6.32-573.7.1.el6.x86_64
After updating these packages, rebooting, and reinstalling my bundle the json-jwt gem worked perfectly.
This was our production machines, and I believe the ruby standard libs were compiled from source, then created as a custom RPM.
Our build server uses RVM, and this ended up being more of a pain. The RVM installer kept pulling binaries for centos, and the same failure came back again.
Found remote file https://rvm.io/binaries/centos/6/x86_64/ruby-1.9.3-p484.tar.bz2
I forced a source recompile like this:
rvm reinstall --disable-binary ruby-1.9.3-p484
And I noticed a very wonderful looking message:
#applying patch .rvm/patches/ruby/ssl_no_ec2m.patch.
That patch file has some C macro conditions that appear to exclude some EC related code.
And that worked! I also noticed that ruby's openssl.so has a lot of EC related symbols in it. The previously packaged centos ruby did not have these:
$ cd ~/.rvm/rubies/ruby-1.9.3-p484/lib/ruby/1.9.1/x86_64-linux
$ strings openssl.so |grep _EC
PEM_write_bio_ECPKParameters
i2d_ECPKParameters
PEM_read_bio_ECPKParameters
d2i_ECPKParameters
PEM_write_bio_ECPrivateKey
i2d_ECPrivateKey_bio
i2d_EC_PUBKEY_bio
PEM_write_bio_EC_PUBKEY
PEM_read_bio_ECPrivateKey
PEM_read_bio_EC_PUBKEY
d2i_ECPrivateKey_bio
d2i_EC_PUBKEY_bio
OPENSSL_1.0.1_EC
EVP_PKEY_assign_EC_KEY
OP_SINGLE_ECDH_USE
If I had to guess, the recompile against my new openssl 1.0.1 package must have triggered some C macros that opened up some kind of alternative algorithm that isn't legally protected.
If you check your openssl.so for symbols and it doesn't have all of these _EC related stuff, that's probably an issue.
I'm trying to get started with the excellent deliver tool (https://github.com/KrauseFx/deliver) but I know nothing about ruby. So when I try to run deliver init and I get this message, I don't know what to do about it:
/Users/sarbogast/.rvm/rubies/ruby-2.1.0/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:2052:in `raise_if_conflicts': can't activate json-1.6.8, already activated json-1.8.1 (Gem::LoadError)
from /Users/sarbogast/.rvm/rubies/ruby-2.1.0/lib/ruby/site_ruby/2.1.0/rubygems/specification.rb:1262:in `activate'
from /Users/sarbogast/.rvm/rubies/ruby-2.1.0/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:96:in `block in require'
from /Users/sarbogast/.rvm/rubies/ruby-2.1.0/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:95:in `each'
from /Users/sarbogast/.rvm/rubies/ruby-2.1.0/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:95:in `require'
from /Users/sarbogast/.rvm/gems/ruby-2.1.0#global/gems/deliver-0.3.6/lib/deliver.rb:1:in `<top (required)>'
from /Users/sarbogast/.rvm/rubies/ruby-2.1.0/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:73:in `require'
from /Users/sarbogast/.rvm/rubies/ruby-2.1.0/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:73:in `require'
from /Users/sarbogast/.rvm/gems/ruby-2.1.0#global/gems/deliver-0.3.6/bin/deliver:5:in `<top (required)>'
from /Users/sarbogast/.rvm/rubies/ruby-2.1.0/bin/deliver:23:in `load'
from /Users/sarbogast/.rvm/rubies/ruby-2.1.0/bin/deliver:23:in `<main>'
from /Users/sarbogast/.rvm/gems/ruby-2.1.0/bin/ruby_executable_hooks:15:in `eval'
from /Users/sarbogast/.rvm/gems/ruby-2.1.0/bin/ruby_executable_hooks:15:in `<main>'
What should I do? By the way I'm on MacOSX Yosemite.
If you are using bundler and you have a Gemfile you can try to run it with bundle using:
bundle exec deliver init
In that way Gemfile will pick for you the right version of the json gem.
If you aren't using bundler you should uninstall the newer version of json using:
gem uninstall json
and choosing the 1.8.1 to uninstall. Then you can try to run again deliver init
As a matter of fact, all I had to do was to install json with "sudo gem install json" and it solved my problem.
I'm a newbie to Ruby. Trying to setup nanoc in my machine. I'm running Ubuntu 14.04.
After the nanoc installation, when I type
$nanoc --version
I get the following errors:
/home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler/shared_helpers.rb:24:in `default_gemfile': Could not locate Gemfile (Bundler::GemfileNotFound)
from /home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler.rb:248:in `default_gemfile'
from /home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler.rb:192:in `root'
from /home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler.rb:99:in `bundle_path'
from /home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler.rb:400:in `configure_gem_home_and_path'
from /home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler.rb:90:in `configure'
from /home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler.rb:151:in `definition'
from /home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler.rb:116:in `setup'
from /home/ananth/.rvm/gems/ruby-head#global/gems/bundler-1.6.2/lib/bundler.rb:132:in `require'
from /home/ananth/.rvm/gems/ruby-head/gems/nanoc-3.7.0/bin/nanoc:7:in `<top (required)>'
from /home/ananth/.rvm/gems/ruby-head/bin/nanoc:23:in `load'
from /home/ananth/.rvm/gems/ruby-head/bin/nanoc:23:in `<main>'
from /home/ananth/.rvm/gems/ruby-head/bin/ruby_executable_hooks:15:in `eval'
from /home/ananth/.rvm/gems/ruby-head/bin/ruby_executable_hooks:15:in `<main>'
Am I missing something from my rvm? Anything to do with $PATH, .bashrc or .bash_profile?
Thanks for the help in advance!
This is a bug in 3.7.0 that will be fixed in 3.7.1.
3.7.0 unintentionally requires a Gemfile to be present when Bundler is installed.
To avoid this bug, either temporarily switch back to 3.6.11, or use a Gemfile (I recommend the latter).
I'm using rails 3.1.0 and trying to setup Capistrano to precompile assets. Capistrano v2.8.0 has "load 'deploy/assets'" in Capfile. But when I run "cap deploy" it shows the following error:
cap deploy
/usr/lib/ruby/1.8/capistrano/configuration/loading.rb:183:in `find_file_in_load_path': no such file to load -- deploy/assets (LoadError)
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:171:in `load_from_file'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:89:in `load'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:86:in `load'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:86:in `each'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:86:in `load'
from Capfile:3:in `load'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:172:in `load_from_file'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:89:in `load'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:86:in `load'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:86:in `each'
from /usr/lib/ruby/1.8/capistrano/configuration/loading.rb:86:in `load'
from /usr/lib/ruby/1.8/capistrano/cli/execute.rb:64:in `load_recipes'
from /usr/lib/ruby/1.8/capistrano/cli/execute.rb:64:in `each'
from /usr/lib/ruby/1.8/capistrano/cli/execute.rb:64:in `load_recipes'
from /usr/lib/ruby/1.8/capistrano/cli/execute.rb:30:in `execute!'
from /usr/lib/ruby/1.8/capistrano/cli/execute.rb:14:in `execute'
from /usr/bin/cap:4
UPDATE
It magically started working after I restarted my PC (Ubuntu).
Can you please demonstrate that the cap that you are using is indeed in the bundle?
Please share your Gemfile and your Capfile, chances are that "cap" isn't in the bundle, so it's loading a previous version, be sure to run with "bundle exec" (to make sure to use the correct capistrano)
As I encountered the same problem currently, I noticed that using RVM with a project specific .rvmrc was not reloaded after I switched branches with git checkout. The result was that the system wide capistrano version 2.6.0 was being used instead of the project specific capistrano version 2.9.0. This lead to the same error message 'no such file to load -- deploy/assets (LoadError)'.
A simple cd out of the project path and again into the project path solved the problem for me.
What worked for me for this issue was installing the latest version of capistrano (gem install capistrano).