Since the last redmine upgrade, a dependency on ruby18-gems on version 1.6.1 is required. But after doing the upgrade, it is impossible to use the rake tool on the redmine environment. The db_migrate operation gives the following trace : # rake db:migrate RAILS_ENV=production --trace (in /usr/local/www/redmine) rake aborted! uninitialized constant ActiveSupport::Dependencies::Mutex /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2503:in `const_missing' /usr/local/www/redmine/vendor/rails/activesupport/lib/active_support/dependencies.rb:55 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' /usr/local/www/redmine/vendor/rails/activesupport/lib/active_support.rb:56 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' /usr/local/www/redmine/vendor/rails/railties/lib/tasks/misc.rake:18 /usr/local/www/redmine/vendor/rails/railties/lib/tasks/rails.rb:4:in `load' /usr/local/www/redmine/vendor/rails/railties/lib/tasks/rails.rb:4 /usr/local/www/redmine/vendor/rails/railties/lib/tasks/rails.rb:4:in `each' /usr/local/www/redmine/vendor/rails/railties/lib/tasks/rails.rb:4 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require' /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' /usr/local/www/redmine/Rakefile:10 /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in `load' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2017:in `load_rakefile' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2000:in `run' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:31 /usr/local/bin/rake:19:in `load' /usr/local/bin/rake:19 As told in redmine forum, it seems that redmine needs a gems version between 1.3 and 1.5 like said here : http://www.redmine.org/boards/1/topics/22314?r=22315 How-To-Repeat: Execute rake db:migrate RAILS_ENV=production --trace with redmine 1.1.2 and ruby18-gems-1.6.1
A more interesting and official link on the redmine installation page (http://www.redmine.org/projects/redmine/wiki/RedmineInstall) : Official releases include the appropriate Rails version in their vendor directory. So no particular action is needed.If you checkout the source from the Redmine repository, you can install a specific Rails version on your machine by running: and RubyGems 1.3.1 or higher is required (Rails 2.3.5 will fail with RubyGems 1.5.0 and later, stick to previous versions of RubyGems) And with port dependency we are clearly in that case Regards, Olivier BONHOMME
Responsible Changed From-To: freebsd-ports-bugs->decke Fix synopsis and assign.
decke 2011-03-14 13:23:31 UTC FreeBSD ports repository Modified files: www/redmine Makefile Added files: www/redmine/files patch-Rakefile Log: - Add fix to work with RubyGems 1.6.x - Bump PORTREVISION RubyGems 1.6.x is incompatible with the bundled rails 2.3.5. It's documented in the RubyGems release notes that "RubyGems no longer requires 'thread'. Rails < 3 will need to add require 'thread' to their applications." PR: ports/155492 Revision Changes Path 1.26 +1 -1 ports/www/redmine/Makefile 1.1 +10 -0 ports/www/redmine/files/patch-Rakefile (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Unfortunately the fix committed at 2011-03-14 13:23:31 UTC is insufficient to fix this problem. You still get the uninitialized constant ActiveSupport::Dependencies::Mutex error even with this point-release of the redmine port. The only way I've been able to fix this is to forcibly downgrade the rubygems package back to 1.3.7 -- Thomas Sandford
On Mon, 14 Mar 2011 17:11:04 +0000, Thomas Sandford wrote: > Unfortunately the fix committed at 2011-03-14 13:23:31 UTC is > insufficient to fix this problem. > > You still get the uninitialized constant > ActiveSupport::Dependencies::Mutex error even with this point-release > of the redmine port. I've reproduced the original problem and the committed fix worked for me and also makes sense from the technical description. If it doesn't work for you please give me more details. (how to reproduce and backtrace with --full) -- Bernhard Froehlich http://www.bluelife.at/
On 15/03/2011 10:33, Bernhard Froehlich wrote: > On Mon, 14 Mar 2011 17:11:04 +0000, Thomas Sandford wrote: >> Unfortunately the fix committed at 2011-03-14 13:23:31 UTC is >> insufficient to fix this problem. >> >> You still get the uninitialized constant >> ActiveSupport::Dependencies::Mutex error even with this point-release >> of the redmine port. > > I've reproduced the original problem and the committed fix worked for > me and also makes sense from the technical description. If it doesn't > work for you please give me more details. (how to reproduce and > backtrace with --full) I've now installed the port (redmine-1.1.2_3) on a virgin FreeBSD 8.2-RELEASE and can confirm that it "works for me". And I've successfully got my production server (which showed the problem reported) to update to ruby18-gems-1.6.2 without breaking redmine. I don't quite know what happened last time (I defintiely had pulled the redmine update - that's on redmine-1.1.2_2 - due to be brought up to redmine-1.1.2_2 now the dust has died down on this previous issue). Sorry for the noise. -- Thomas Sandford
On 17/03/2011 17:39, Thomas Sandford wrote: > On 15/03/2011 10:33, Bernhard Froehlich wrote: >> On Mon, 14 Mar 2011 17:11:04 +0000, Thomas Sandford wrote: >>> Unfortunately the fix committed at 2011-03-14 13:23:31 UTC is >>> insufficient to fix this problem. >>> >>> You still get the uninitialized constant >>> ActiveSupport::Dependencies::Mutex error even with this point-release >>> of the redmine port. >> >> I've reproduced the original problem and the committed fix worked for >> me and also makes sense from the technical description. If it doesn't >> work for you please give me more details. (how to reproduce and >> backtrace with --full) > > I've now installed the port (redmine-1.1.2_3) on a virgin FreeBSD > 8.2-RELEASE and can confirm that it "works for me". > > And I've successfully got my production server (which showed the problem > reported) to update to ruby18-gems-1.6.2 without breaking redmine. I > don't quite know what happened last time (I defintiely had pulled the > redmine update - that's on redmine-1.1.2_2 - due to be brought up to > redmine-1.1.2_2 now the dust has died down on this previous issue). > > Sorry for the noise. I've now worked out what my issue is. I don't use thin, etc to run my redmine instance, instead using ap22-mod_fcgid and ruby18-fcgi. The patch is applied to Rakefile and so is not does not work for my setup. The same "require 'thread'" line needs adding to public/dispatch.fcgi immediately before the line where the environment is pulled in. (and presumably the same would apply to the other dispatch.xxx files) The above addition to my public/dispatch.fcgi makes my installation work again with ruby18-gems-1.6.2. -- Thomas Sandford
On Thu, 17 Mar 2011 18:44:29 +0000, Thomas Sandford wrote: > I've now worked out what my issue is. I don't use thin, etc to run my > redmine instance, instead using ap22-mod_fcgid and ruby18-fcgi. > > The patch is applied to Rakefile and so is not does not work for my setup. > > The same "require 'thread'" line needs adding to public/dispatch.fcgi > immediately before the line where the environment is pulled in. > > (and presumably the same would apply to the other dispatch.xxx files) > > The above addition to my public/dispatch.fcgi makes my installation > work again with ruby18-gems-1.6.2. I think i found a better way. Can you please remove "require 'thread'" from Rakefile and add it at the top of config/boot.rb and test with that? That should be the central place where we avoid to patch all files. -- Bernhard Froehlich http://www.bluelife.at/
On 17/03/2011 20:01, Bernhard Froehlich wrote: > On Thu, 17 Mar 2011 18:44:29 +0000, Thomas Sandford wrote: >> I've now worked out what my issue is. I don't use thin, etc to run my >> redmine instance, instead using ap22-mod_fcgid and ruby18-fcgi. >> >> The patch is applied to Rakefile and so is not does not work for my setup. >> >> The same "require 'thread'" line needs adding to public/dispatch.fcgi >> immediately before the line where the environment is pulled in. >> >> (and presumably the same would apply to the other dispatch.xxx files) >> >> The above addition to my public/dispatch.fcgi makes my installation >> work again with ruby18-gems-1.6.2. > > I think i found a better way. Can you please remove "require 'thread'" > from Rakefile and add it at the top of config/boot.rb and test with > that? That should be the central place where we avoid to patch all > files. I've moved the "require 'thread'" line from Rakefile to config/boot.rb (and reverted my local change to public/dispatch.fcgi) and can confirm that this works both for "rake ..." and for fcgi operations. I'll look forward to the official patch in my "portsnap fetch update" in due course :-) Thanks! -- Thomas Sandford
decke 2011-03-18 14:07:06 UTC FreeBSD ports repository Modified files: www/redmine/files patch-config-boot.rb Removed files: www/redmine/files patch-Rakefile Log: - Improve fix to work with RubyGems 1.6.x RubyGems 1.6.x is incompatible with the bundled rails 2.3.5. It's documented in the RubyGems release notes that "RubyGems no longer requires 'thread'. Rails < 3 will need to add require 'thread' to their applications." PR: ports/155492 Reported by: Thomas Sandford <freebsduser@paradisegreen.co.uk> Thanks to: Thomas Sandford <freebsduser@paradisegreen.co.uk> Revision Changes Path 1.2 +0 -10 ports/www/redmine/files/patch-Rakefile (dead) 1.4 +12 -3 ports/www/redmine/files/patch-config-boot.rb _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
On Fri, 18 Mar 2011 10:42:03 +0000, Thomas Sandford wrote: > On 17/03/2011 20:01, Bernhard Froehlich wrote: >> On Thu, 17 Mar 2011 18:44:29 +0000, Thomas Sandford wrote: >>> I've now worked out what my issue is. I don't use thin, etc to run my >>> redmine instance, instead using ap22-mod_fcgid and ruby18-fcgi. >>> >>> The patch is applied to Rakefile and so is not does not work for my setup. >>> >>> The same "require 'thread'" line needs adding to public/dispatch.fcgi >>> immediately before the line where the environment is pulled in. >>> >>> (and presumably the same would apply to the other dispatch.xxx files) >>> >>> The above addition to my public/dispatch.fcgi makes my installation >>> work again with ruby18-gems-1.6.2. >> >> I think i found a better way. Can you please remove "require 'thread'" >> from Rakefile and add it at the top of config/boot.rb and test with >> that? That should be the central place where we avoid to patch all >> files. > > I've moved the "require 'thread'" line from Rakefile to > config/boot.rb (and reverted my local change to public/dispatch.fcgi) > and can confirm that this works both for "rake ..." and for fcgi > operations. > > I'll look forward to the official patch in my "portsnap fetch update" > in due course :-) > > Thanks! Thanks a lot for your help and time to test it! Final patch is committed now. -- Bernhard Froehlich http://www.bluelife.at/
Le 18/03/2011 15:09, Bernhard Froehlich a écrit : > Thanks a lot for your help and time to test it! Final patch is > committed now. > Hello, I just updated my redmine with your patch and the rake works perfectly now on a redmine installation using passenger. Thanks for your support Regards, Olivier BONHOMME
State Changed From-To: open->closed Problem fixed. Thanks!