I am now setting up my Redmine 2.1.0 in Debian. When I ran this RAILS_ENV=production rake db:migrate in Redmine directory. It's showing an error like this
rake aborted!
Invalid preference factor: 3.0
Tasks: TOP => db:migrate => environment
(See full trace by running task with --trace)
My Ruby version is 1.8.7
When I gave this command "ruby -e 'p 0.3". it prints 3.0. I don't know what the issue was. How can I set up Redmine 2.1.0 in my organization?
Seems you have an issue with your specific ruby.
rvm is your friend. Try installing 1.9.3-head, create gemset for redmine and proceed installation.
Big advantage of RVM approach is a fact that new rubies install does not affect system ruby no applications using it.
Related
My company need to upgrade their current Redmine1.1.1 server. In order to avoid productions issue, I am trying to recreate a working instance with identical version. That's why I can't use standard solution which mainly modify the gems or rail version.
I need to create an instance of a redmine-1.1.1 CentOS6 server with the following rubygems version:
[root#localhost redmine1]# rpm -qa |grep ruby
rubygem-rack-1.1.0-2.el6.noarch
rubygem-daemon_controller-1.1.5-1.el6.noarch
rubygems-1.3.7-5.el6.noarch ruby-ri-1.8.7.374-4.el6_6.i686
ruby-1.8.7.374-4.el6_6.i686 rubygem-rake-0.8.7-2.1.el6.noarch
ruby-mysql-2.8.2-1.el6.i686 ruby-irb-1.8.7.374-4.el6_6.i686
rubygems-devel-1.3.7-5.el6.noarch ruby-devel-1.8.7.374-4.el6_6.i686
rubygem-passenger-3.0.21-11.el6.i686
rubygem-passenger-native-libs-3.0.21-11.el6.i686
ruby-rdoc-1.8.7.374-4.el6_6.i686 ruby-docs-1.8.7.374-4.el6_6.i686
rubygem-passenger-native-3.0.21-11.el6.i686
ruby-libs-1.8.7.374-4.el6_6.i686 rubygem-fastthread-1.0.7-2.2.i686
I followed the tutorials below in order to recreate the redmine install.
https://www.redmine.org/projects/redmine/wiki/Redmine+Apache+Passenger_InstallOnRedHat
http://www.redmine.org/projects/redmine/wiki/HowTo_install_Redmine_on_CentOS_5
I got this error and knowing that I can't downgrade my gems, what are the other options to overcome this?
[root#localhost redmine1]# rake generate_session_store
rake aborted!
undefined method `source_index' for Gem:Module
/var/www/redmine1/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21:in
`add_frozen_gem_path' /var/www/redmine1/config/boot.rb:47:in
`load_initializer' /var/www/redmine1/config/boot.rb:38:in `run'
/var/www/redmine1/config/boot.rb:11:in `boot!'
/var/www/redmine1/config/boot.rb:122 /var/www/redmine1/Rakefile:4
/usr/local/rvm/gems/ruby-1.8.7-head#redmine111/bin/ruby_executable_hooks:15
(See full trace by running task with --trace)
What are the necessary complements to help you understand this issue?
/gems/htmlentities-4.3.2/lib/htmlentities/mappings/expanded.rb:465: warning: duplicated key at line 466 ignored: "inodot"
/gems/ruby-2.2.0/gems/fog-core-1.25.0/lib/fog/core/collection.rb:144: warning: circular argument reference - filters
The obvious suspicion is that these gems don't like ruby 2.2.0, but things seem to be working
Should I fear future, imminent failures, or has these gems just haven't caught up yet?
Both problems were solved in newer versions of these gems.
If I am depending on gems like that, I usually wait a little bit before switching the project to the latest and greatest ruby in production. Gems need time to get compatible with all the changes.
I to have like this error when install redmine 3.2:
/usr/lib/ruby/gems/2.3.0/gems/htmlentities-4.3.1/lib/htmlentities/mappings/expanded.rb:465: warning: key "inodot" is duplicated and overwritten on line 466
All is simple - just edit this file and remove duplicated line!)
But sometimes need just check your htmlentities version and remove not needed
gem list htmlentities
gem uninstall htmlentities -v '4.x.x'
My System Config: Win 8.1 + SQL 2016 Expr SP1 + Redmine DB (type SQL 2012 CS AI) + Redmine 3.3.1 + Ruby 2.3.3 + devkit + ImageMagick-6.9.6-8-Q16-HDRI-x64-dll (ImageMagick-7.0.3 Not working!)
Fix issue with htmlentities-4.3.1 "key inodot"
gem install htmlentities -v '4.3.4'
gem uninstall htmlentities -v '4.3.1'
Fix issue with error load "tiny_tds"
gem install tiny_tds -v '1.0.5'
gem uninstall tiny_tds -v '0.6.2'
Change all dependencies in Gemfile & Gemfile.lock from old version to new installed.
All other commands from Installing Redmine Guide Site.
Result:
c:\inetpub\redmine>bundle exec rake db:migrate
migrating
add_column(:roles, :settings, :text)
-> 0.0019s
-> -1 rows
AddRolesSettings: migrated (0.0027s)
c:\inetpub\redmine>set REDMINE_LANG=ru
c:\inetpub\redmine>bundle exec rake redmine:load_default_data
Default configuration data loaded.
c:\inetpub\redmine>bundle exec rails server webrick -e production
=> Booting WEBrick
=> Rails 4.2.7.1 application starting in production on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
[2016-12-13 15:14:25] INFO WEBrick 1.3.1
[2016-12-13 15:14:25] INFO ruby 2.3.3 (2016-11-21) [x64-mingw32]
[2016-12-13 15:14:25] INFO WEBrick::HTTPServer#start: pid=4468 port=3000
[2016-12-13 16:02:58] INFO going to shutdown ...
[2016-12-13 16:02:58] INFO WEBrick::HTTPServer#start done.
Exiting`enter code here`
gem uninstall htmlentities -v '4.3.2'
gem install htmlentities -v '4.3.4'
I am currently having a strange issue with bundler and ruby.
if I type:
$ which ruby
I get:
/home/martinos/.rubies/1.8.7-p370/bin/ruby
And when I type:
$ which bundle
I get
/home/martinos/.gem/ruby/1.8.7/bin/bundle
But for some reason when I run
$ bundle exec rake db:migrate
The task is run with ruby 1.9.3 (I have written a puts RUBY_VERSION in environment.rb)
Any one as an idea why this happens?
Here is more infos:
When I type:
$ which rake
I get:
/home/martinos/.gem/ruby/1.8.7/bin/rake
But if I
$ head -1 `which rake`
I get:
#!/usr/bin/env ruby1.9.1
There are a variety of pieces that could be in play. The first is that it could be a conflict between your Ruby version management tools and your global gems. Meaning, I suppose it is possible that you only have a Rake version that can work on Ruby 1.9.1 that is in your global set. So when you fire up Rake it is forced to run in Ruby 1.9.1.
What you may want to do is create a directory specific gemset. If you're using RVM you can see the documentation on how to do that by looking at their Gemset documentation. Once that is in place with the Ruby version you want to test with, then do a gem install of Rake at the version that will work with that Ruby version. At that point you should find that the Ruby version being used to run Rake in that directory will be the same as the version you have running.
I apologize if this does not answer your question, or if you have thought of this approach already. Trying to wrap my head around this without the ability to reproduce the problem is a tricky deal.
I have a box with 3 Rails apps on it. I wan't to upgrade one of the apps so that it uses Ruby 2.0.0, while leaving the others running on 1.9.3-p394. I have both those Rubies installed via Rvm.
I'm trying to control the Ruby version that each app uses via it's Gemfile.
# Gemfile
ruby '2.0.0'
So, I changed the version number in the Gemfile locally, made sure it all worked, committed and now I'm trying to deploy the change to the server.
However, the cap deploy fails at this point
bundle install --gemfile [path to release Gemfile] --path [path to app bundle] --deployment --quiet --without development test
because
Your Ruby version is 1.9.3, but your Gemfile specified 2.0.0
This is correct technically, my Gemfile does specify 2.0.0 and the app is currently running on 1.9.3. I'm trying to make it change versions before bundling though. How do I do that?
Your PATH is not set up correctly. You probably don't have bin: as the first entry in your path. That would lead to this error.
Even if you're not using Heroku it's worth reading this page on troubleshooting that issue: https://devcenter.heroku.com/articles/ruby-versions
Here is a link to an answer which will explain how to change your PATH on the server: Capistrano: Can I set an environment variable for the whole cap session?
If you have rvm maybe you can try to do
rvm use 2.0.0
before your bundler call.
If you're using rvm set the default to ruby 2.0.0 on your server
rvm --default use 2.0.0
Resolved the problem for me deploying to an AWS server from my mac - but I guess if I need to update my older sites I'll have to set the default back to 1.9.3 before deploying.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Rails 3.0 & Ruby 1.9.2rc: Rake commands return 'already initialized constant' & stack level too deep errors. Any ideas
Am using Ruby version 1.9.1 on windows vista. Am getting the rake aborted error for any rake commands am using. This does not happen in all my app folder. Its happening only on a specific app folder.
C:\rails_project\stunetwork>rake db:reset
(in C:/rails_project/stunetwork)
rake aborted!
stack level too deep
C:/Ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rak
efile'
(See full trace by running task with --trace)
try placing bundle exec in front of the rake command.
bundle exec rake -T
You need to update your gem.
I met this error with gem '1.8.10', and fixed by upgrading to 1.8.16
gem update --system
I only had this problem with ruby-1.9.2-p180 via rvm.
Switching to ruby-1.9.2-p0 fixed the problem.
try "rvm use 1.9.2-p0"
The stack of the calls can depend on the gems you install (some gems monkeypatch the rails tasks) which explains why you would encounter this on a specific app and not on others.
On a unix system you could try using the ulimit command to increase your stack size. On the windows side I haven't found a solution yet.
Depending on which release of ruby you use on windows you may want to ask the maintainers how to increase the stack.
For ruby installer you will need to install the mingw compile environment, clone the github repository and recompile the ruby you use (not very sexy I admit).
I just encountered this exact error message on Ubuntu, and was able to solve it by downgrading rubygems from 1.8.3 to 1.7.1.
There is nice post by Yehuda Katz that explains why without bundle exec there can be version conflicts:
http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-doing-it-right/
There is also bundle install --binstubs command that allows to version-safely run rake db:reset like this: bin/rake db:reset.