From luislavena at gmail.com Tue Mar 1 10:03:58 2011 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 1 Mar 2011 12:03:58 -0300 Subject: [Rubygems-developers] Errors and Failures at master Message-ID: Hello: 8) Error: test_update_index(TestGemIndexer): Errno::EACCES: Permission denied - C:/Users/Luis/AppData/Local/Temp/test_rubygems_4476/ ./lib/rubygems/indexer.rb:624:in `utime' ./lib/rubygems/indexer.rb:624:in `update_index' ./lib/rubygems/indexer.rb:617:in `each' ./lib/rubygems/indexer.rb:617:in `update_index' ./test/rubygems/test_gem_indexer.rb:519:in `test_update_index' ./lib/rubygems/user_interaction.rb:40:in `use_ui' ./lib/rubygems/user_interaction.rb:63:in `use_ui' ./test/rubygems/test_gem_indexer.rb:518:in `test_update_index' Any hint on this? Another: 12) Failure: test_cache_dir_escapes_windows_paths(TestGemSpecFetcher) [./test/rubygems/test_gem_spec_fetcher.rb:412]: C:/Users/Luis/AppData/Local/Temp/test_rubygems_4476/userhome/.gem/specs/%/C-/WINDOWS/Temp should not contain a : The problem here seems the test assume no path with : will show, but since is doing File.join, at last 1 ":" will be present. Those seems to be the only failures I have with it, testing usage today to know any other glitch that exist. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From noreply at rubyforge.org Tue Mar 1 13:54:24 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Mar 2011 13:54:24 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is sometimes too large. Message-ID: <20110301185424.A10EA1678326@rubyforge.org> Bugs item #27154, was opened at 2009-09-21 16:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 Category: `gem install` command Group: v1.3.x Status: Closed Resolution: Accepted Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: John Barnette (jbarnette) Summary: Computed hash is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- Comment By: Bernard Lambeau (blambeau) Date: 2011-03-01 19:54 Message: This bug seems to re-appear. requirement.rb should probably be patched as proposed by Daniel Weaver to guarantee compatibility with ruby 1.8.7-p176. I've written a review with additional details about this bug at: http://revision-zero.org/history-of-a-bug ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-02-02 01:03 Message: This is fixed. ---------------------------------------------------------------------- Comment By: Daniel Weaver (zlern2k) Date: 2010-12-20 21:20 Message: I realize these are bugs in the underlying Ruby implementation of hash, but it really helps us to have them fixed in gem. This is the patch for requirement.rb that we currently need to deploy to make bundler happy with our apps: zlerntop:rubygems danielweaver$ diff -u requirement.rb.orig requirement.rb --- requirement.rb.orig 2010-12-20 12:13:40.000000000 -0800 +++ requirement.rb 2010-12-20 12:13:40.000000000 -0800 @@ -106,7 +106,7 @@ end def hash # :nodoc: - requirements.hash + requirements.inject(0) { |h, r| h ^ r.first.hash ^ r.last.hash } end def marshal_dump # :nodoc: ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-12-07 05:06 Message: Hello again, I got the bignum error again, but this time with cucumber-0.9.4. These commands weren't able to install the gem: * bundle install * bundle install --local * sudo bundle install --local * sudo bundle install --local --system * sudo bundle install --system However, I was able to work around the issue by 1. installing the gem to my system manually (sudo gem install cucumber --version "0.9.4"), and 2. installing the bundle to the system (sudo bundle install --system) For step 2, trying "bundle install --local" worked only if all the gems in the bundle are already installed. If there were some gems from the bundle that are not installed, running "sudo bundle install --system" was the only way I could install them. George Mendoza Philippines ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-12-01 04:52 Message: Hello, Appreciate if anybody can re-open this ticket. I am also getting the error when I try to install the dmitryv-backup gem via bundle. Please let me know if I need to provide any other information in order to fix this bug. Thanks! Gemfile: ---------------------------------------- source :rubygems source "http://gems.github.com" #... gem 'dmitryv-backup', '2.4.0', :require => "backup" #... ---------------------------------------- Running: ---------------------------------------- bundle install --local /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash': bignum too big to convert into `long' (RangeError) from /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:675:in `hash' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/index.rb:36:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `each' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `hash' from /usr/lib/ruby/1.8/tsort.rb:204:in `include?' from /usr/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:209:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:182:in `each_strongly_connected_component' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/1.8/tsort.rb:180:in `each_strongly_connected_component' from /usr/lib/ruby/1.8/tsort.rb:148:in `tsort_each' from /usr/lib/ruby/1.8/tsort.rb:135:in `tsort' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:107:in `sorted' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:44:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:8:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/cli.rb:225:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `send' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor.rb:246:in `dispatch' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/base.rb:389:in `start' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/bin/bundle:13 from /usr/bin/bundle:19:in `load' from /usr/bin/bundle:19 ---------------------------------------- Thanks, George Mendoza Philippines ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 23:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Craig Cook (ccook) Date: 2010-10-18 23:08 Message: Hello, I tried this patch, but I am still getting the error, at the same place in the code. The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above. This happened when installing using bundler, executed via capistrano. We had been using hpricot, it wasn't needed, it was giving this error first. I took it out, but then the same RangeError happened with mysql. I've seen it before also with nokogiri. (Always with native gems, though). Here's the relevant part of the log: ----------- begin log ---------------------------- ** [out :: 192.168.10.63] Installing mysql (2.8.1) ** [out :: 192.168.10.63] with native extensions ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] : ** [out :: 192.168.10.62] bignum too big to convert into `long' ** [out :: 192.168.10.62] ( ** [out :: 192.168.10.62] RangeError ** [out :: 192.168.10.62] ) ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from' ** [out :: 192.168.10.62] ... 22 levels... ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start' ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load' ** [out :: 192.168.10.62] from /usr/bin/bundle:19 ----------- end cap output ------------------- running: ------------ system & ruby info ------------------ [ccook at ev2-stage ~]$ ruby -v ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux] [ccook at ev2-stage ~]$ gem -v 1.3.7 [ccook at ev2-stage ~]$ uname -a Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux ------ end system / ruby info ---------- Gemfile: ----------- begin Gemfile ----------------- source :gemcutter gem 'rails', '2.3.8' gem 'mysql', '2.8.1' gem "geokit" gem "geokit-rails" gem "builder" gem 'chronic' gem 'whenever' gem 'database_cleaner' gem 'apn_on_rails' gem 'factory_girl' gem 'net-sftp' gem 'will_paginate' # dependency for squirrel & jqgrid gem 'nokogiri' # only for test/functional/auth_controller_test.rb gem 'cucumber' gem 'cucumber-rails' gem 'webrat' gem 'rspec' ---------- end Gemfile ----------------- So, is this the same issue? It sure looks like it to me. I hope not to have to dive into the innards of rubygems if possible. But we need to be able to deploy. The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap. I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again. Thanks for your time in this! Cheers, Craig ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 From noreply at rubyforge.org Tue Mar 1 17:35:45 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Mar 2011 17:35:45 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is sometimes too large. Message-ID: <20110301223545.9C8151858374@rubyforge.org> Bugs item #27154, was opened at 2009-09-21 07:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 Category: `gem install` command Group: v1.3.x >Status: Deleted >Resolution: Rejected Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: John Barnette (jbarnette) Summary: Computed hash is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-01 14:35 Message: Bernard, Might I suggest reading a copy of Zig ZIgler's How to Win Friends and Influence People? Because you're failing. Your passive-agressive barb of a blog post seems to gloss over the fact that this bug is a bug in ruby, not a bug in the libraries. Not only that, but the bug has been fixed (and released) for over a year. It is not in any author's best interest to maintain hack after hack to deal with any and every incompatibility with every version of ruby ever released. We're calling #hash or an array of arrays of strings and ints. If #hash returns a BigNum, that's a bug... in ruby. Upgrade ruby and the problem is fixed. ---------------------------------------------------------------------- Comment By: Bernard Lambeau (blambeau) Date: 2011-03-01 10:54 Message: This bug seems to re-appear. requirement.rb should probably be patched as proposed by Daniel Weaver to guarantee compatibility with ruby 1.8.7-p176. I've written a review with additional details about this bug at: http://revision-zero.org/history-of-a-bug ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-02-01 16:03 Message: This is fixed. ---------------------------------------------------------------------- Comment By: Daniel Weaver (zlern2k) Date: 2010-12-20 12:20 Message: I realize these are bugs in the underlying Ruby implementation of hash, but it really helps us to have them fixed in gem. This is the patch for requirement.rb that we currently need to deploy to make bundler happy with our apps: zlerntop:rubygems danielweaver$ diff -u requirement.rb.orig requirement.rb --- requirement.rb.orig 2010-12-20 12:13:40.000000000 -0800 +++ requirement.rb 2010-12-20 12:13:40.000000000 -0800 @@ -106,7 +106,7 @@ end def hash # :nodoc: - requirements.hash + requirements.inject(0) { |h, r| h ^ r.first.hash ^ r.last.hash } end def marshal_dump # :nodoc: ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-12-06 20:06 Message: Hello again, I got the bignum error again, but this time with cucumber-0.9.4. These commands weren't able to install the gem: * bundle install * bundle install --local * sudo bundle install --local * sudo bundle install --local --system * sudo bundle install --system However, I was able to work around the issue by 1. installing the gem to my system manually (sudo gem install cucumber --version "0.9.4"), and 2. installing the bundle to the system (sudo bundle install --system) For step 2, trying "bundle install --local" worked only if all the gems in the bundle are already installed. If there were some gems from the bundle that are not installed, running "sudo bundle install --system" was the only way I could install them. George Mendoza Philippines ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-11-30 19:52 Message: Hello, Appreciate if anybody can re-open this ticket. I am also getting the error when I try to install the dmitryv-backup gem via bundle. Please let me know if I need to provide any other information in order to fix this bug. Thanks! Gemfile: ---------------------------------------- source :rubygems source "http://gems.github.com" #... gem 'dmitryv-backup', '2.4.0', :require => "backup" #... ---------------------------------------- Running: ---------------------------------------- bundle install --local /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash': bignum too big to convert into `long' (RangeError) from /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:675:in `hash' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/index.rb:36:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `each' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `hash' from /usr/lib/ruby/1.8/tsort.rb:204:in `include?' from /usr/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:209:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:182:in `each_strongly_connected_component' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/1.8/tsort.rb:180:in `each_strongly_connected_component' from /usr/lib/ruby/1.8/tsort.rb:148:in `tsort_each' from /usr/lib/ruby/1.8/tsort.rb:135:in `tsort' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:107:in `sorted' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:44:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:8:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/cli.rb:225:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `send' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor.rb:246:in `dispatch' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/base.rb:389:in `start' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/bin/bundle:13 from /usr/bin/bundle:19:in `load' from /usr/bin/bundle:19 ---------------------------------------- Thanks, George Mendoza Philippines ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 14:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Craig Cook (ccook) Date: 2010-10-18 14:08 Message: Hello, I tried this patch, but I am still getting the error, at the same place in the code. The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above. This happened when installing using bundler, executed via capistrano. We had been using hpricot, it wasn't needed, it was giving this error first. I took it out, but then the same RangeError happened with mysql. I've seen it before also with nokogiri. (Always with native gems, though). Here's the relevant part of the log: ----------- begin log ---------------------------- ** [out :: 192.168.10.63] Installing mysql (2.8.1) ** [out :: 192.168.10.63] with native extensions ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] : ** [out :: 192.168.10.62] bignum too big to convert into `long' ** [out :: 192.168.10.62] ( ** [out :: 192.168.10.62] RangeError ** [out :: 192.168.10.62] ) ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from' ** [out :: 192.168.10.62] ... 22 levels... ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start' ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load' ** [out :: 192.168.10.62] from /usr/bin/bundle:19 ----------- end cap output ------------------- running: ------------ system & ruby info ------------------ [ccook at ev2-stage ~]$ ruby -v ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux] [ccook at ev2-stage ~]$ gem -v 1.3.7 [ccook at ev2-stage ~]$ uname -a Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux ------ end system / ruby info ---------- Gemfile: ----------- begin Gemfile ----------------- source :gemcutter gem 'rails', '2.3.8' gem 'mysql', '2.8.1' gem "geokit" gem "geokit-rails" gem "builder" gem 'chronic' gem 'whenever' gem 'database_cleaner' gem 'apn_on_rails' gem 'factory_girl' gem 'net-sftp' gem 'will_paginate' # dependency for squirrel & jqgrid gem 'nokogiri' # only for test/functional/auth_controller_test.rb gem 'cucumber' gem 'cucumber-rails' gem 'webrat' gem 'rspec' ---------- end Gemfile ----------------- So, is this the same issue? It sure looks like it to me. I hope not to have to dive into the innards of rubygems if possible. But we need to be able to deploy. The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap. I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again. Thanks for your time in this! Cheers, Craig ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 From noreply at rubyforge.org Tue Mar 1 17:52:47 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Mar 2011 17:52:47 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28935 ] Failing rdoc generation doesnt fail the installation since 1.5 Message-ID: <20110301225247.3080C1858374@rubyforge.org> Bugs item #28935, was opened at 2011-02-17 11:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28935&group_id=126 Category: `gem install` command Group: None >Status: Open Resolution: Accepted Priority: 3 Submitted By: Marcus Rueckert (darix) >Assigned to: Eric Hodel (drbrain) Summary: Failing rdoc generation doesnt fail the installation since 1.5 Initial Comment: it seems gem install returns 0, even though the rdoc generation failed. in 1.3.7 it still returned the a non zero return code. as shown here http://bit.ly/f8vfi7 e.g. important part: [[[ 1 gem installed Installing ri documentation for ci_reporter-1.6.4... rdoc --ri --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/ri --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Documentation Installing RDoc documentation for ci_reporter-1.6.4... rdoc --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/rdoc --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Doc Invalid output formatter For help on options, try 'rdoc --help' ERROR: While generating documentation for ci_reporter-1.6.4 ... MESSAGE: exit ... RDOC args: --op /var/tmp/rubygem-ci_reporter-1.6.4-build/usr/lib64/ruby/gems/1.8/doc/ci_reporter-1.6.4/rdoc --main README.txt -SHN -f darkfish --quiet lib History.txt Manifest.txt README.txt LICENSE.txt --title ci_reporter-1.6.4 Documentation (continuing with the rest of the installation) ]]] the problem in the build was that the ruby version didnt ship the darkfish template, but the gemspec specifies 's.rdoc_options = ["--main", "README.txt", "-SHN", "-f", "darkfish"]'. ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-01 14:52 Message: I could not reproduce the behavior of --quiet suppressing the exit code with ci_reporter and RDoc 1.0.1, 2.3.0, 2.5.11 or trunk rdoc. I reverted the commit in RubyGems that add --quiet as it has no effect on the exit code. Reopened this bug. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-02-23 16:49 Message: DocManager was passing in --quiet which does a lot more than just "don't output stuff". I've removed that and forced the exit to be 1 if it borks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28935&group_id=126 From noreply at rubyforge.org Tue Mar 1 18:41:45 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Mar 2011 18:41:45 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is sometimes too large. Message-ID: <20110301234145.2A1781678326@rubyforge.org> Bugs item #27154, was opened at 2009-09-21 16:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 Category: `gem install` command Group: v1.3.x Status: Deleted Resolution: Rejected Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: John Barnette (jbarnette) Summary: Computed hash is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- Comment By: Bernard Lambeau (blambeau) Date: 2011-03-02 00:41 Message: Hi Ryan, I'm sorry if my posts seem aggressive, this is far from being an objective in itself. I'm far from being sure that "Upgrade ruby and the problem is fixed" is the appropriate answer to a problem users encounter in practice. Many users are much less skilled than you are and are just afraid by obtrusive changes. In my opinion, people upgrading ruby version should be a middle-term community goal, backed up with well documented good practices like "ruby 1.8.7 p248 is considered as a must have, prior versions are considered too buggy in practice". Rubygems is certainly a good place to broadcast such messages, ... slowly (as an example I certainly support the recent broken support of ruby 1.8.6 by influencing gems). Recent major changes in rubygems are certainly required and welcome(d) for long-term goals around ruby. Too many such changes will make users' life a nightmare. Anyway, maybe I'm just wrong. In that case, please apologize. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-01 23:35 Message: Bernard, Might I suggest reading a copy of Zig ZIgler's How to Win Friends and Influence People? Because you're failing. Your passive-agressive barb of a blog post seems to gloss over the fact that this bug is a bug in ruby, not a bug in the libraries. Not only that, but the bug has been fixed (and released) for over a year. It is not in any author's best interest to maintain hack after hack to deal with any and every incompatibility with every version of ruby ever released. We're calling #hash or an array of arrays of strings and ints. If #hash returns a BigNum, that's a bug... in ruby. Upgrade ruby and the problem is fixed. ---------------------------------------------------------------------- Comment By: Bernard Lambeau (blambeau) Date: 2011-03-01 19:54 Message: This bug seems to re-appear. requirement.rb should probably be patched as proposed by Daniel Weaver to guarantee compatibility with ruby 1.8.7-p176. I've written a review with additional details about this bug at: http://revision-zero.org/history-of-a-bug ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-02-02 01:03 Message: This is fixed. ---------------------------------------------------------------------- Comment By: Daniel Weaver (zlern2k) Date: 2010-12-20 21:20 Message: I realize these are bugs in the underlying Ruby implementation of hash, but it really helps us to have them fixed in gem. This is the patch for requirement.rb that we currently need to deploy to make bundler happy with our apps: zlerntop:rubygems danielweaver$ diff -u requirement.rb.orig requirement.rb --- requirement.rb.orig 2010-12-20 12:13:40.000000000 -0800 +++ requirement.rb 2010-12-20 12:13:40.000000000 -0800 @@ -106,7 +106,7 @@ end def hash # :nodoc: - requirements.hash + requirements.inject(0) { |h, r| h ^ r.first.hash ^ r.last.hash } end def marshal_dump # :nodoc: ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-12-07 05:06 Message: Hello again, I got the bignum error again, but this time with cucumber-0.9.4. These commands weren't able to install the gem: * bundle install * bundle install --local * sudo bundle install --local * sudo bundle install --local --system * sudo bundle install --system However, I was able to work around the issue by 1. installing the gem to my system manually (sudo gem install cucumber --version "0.9.4"), and 2. installing the bundle to the system (sudo bundle install --system) For step 2, trying "bundle install --local" worked only if all the gems in the bundle are already installed. If there were some gems from the bundle that are not installed, running "sudo bundle install --system" was the only way I could install them. George Mendoza Philippines ---------------------------------------------------------------------- Comment By: George Mendoza (gsmendoza) Date: 2010-12-01 04:52 Message: Hello, Appreciate if anybody can re-open this ticket. I am also getting the error when I try to install the dmitryv-backup gem via bundle. Please let me know if I need to provide any other information in order to fix this bug. Thanks! Gemfile: ---------------------------------------- source :rubygems source "http://gems.github.com" #... gem 'dmitryv-backup', '2.4.0', :require => "backup" #... ---------------------------------------- Running: ---------------------------------------- bundle install --local /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash': bignum too big to convert into `long' (RangeError) from /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:675:in `hash' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/index.rb:36:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `each' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `inject' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `hash' from /usr/lib/ruby/1.8/tsort.rb:204:in `include?' from /usr/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:209:in `each_strongly_connected_component_from' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child' from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from' from /usr/lib/ruby/1.8/tsort.rb:182:in `each_strongly_connected_component' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node' from /usr/lib/ruby/1.8/tsort.rb:180:in `each_strongly_connected_component' from /usr/lib/ruby/1.8/tsort.rb:148:in `tsort_each' from /usr/lib/ruby/1.8/tsort.rb:135:in `tsort' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:107:in `sorted' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:in `each' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:44:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:8:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/cli.rb:225:in `install' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `send' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `run' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor.rb:246:in `dispatch' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/base.rb:389:in `start' from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/bin/bundle:13 from /usr/bin/bundle:19:in `load' from /usr/bin/bundle:19 ---------------------------------------- Thanks, George Mendoza Philippines ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 23:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Craig Cook (ccook) Date: 2010-10-18 23:08 Message: Hello, I tried this patch, but I am still getting the error, at the same place in the code. The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above. This happened when installing using bundler, executed via capistrano. We had been using hpricot, it wasn't needed, it was giving this error first. I took it out, but then the same RangeError happened with mysql. I've seen it before also with nokogiri. (Always with native gems, though). Here's the relevant part of the log: ----------- begin log ---------------------------- ** [out :: 192.168.10.63] Installing mysql (2.8.1) ** [out :: 192.168.10.63] with native extensions ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] : ** [out :: 192.168.10.62] bignum too big to convert into `long' ** [out :: 192.168.10.62] ( ** [out :: 192.168.10.62] RangeError ** [out :: 192.168.10.62] ) ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject' ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?' ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from' ** [out :: 192.168.10.62] ... 22 levels... ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start' ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load' ** [out :: 192.168.10.62] from /usr/bin/bundle:19 ----------- end cap output ------------------- running: ------------ system & ruby info ------------------ [ccook at ev2-stage ~]$ ruby -v ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux] [ccook at ev2-stage ~]$ gem -v 1.3.7 [ccook at ev2-stage ~]$ uname -a Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux ------ end system / ruby info ---------- Gemfile: ----------- begin Gemfile ----------------- source :gemcutter gem 'rails', '2.3.8' gem 'mysql', '2.8.1' gem "geokit" gem "geokit-rails" gem "builder" gem 'chronic' gem 'whenever' gem 'database_cleaner' gem 'apn_on_rails' gem 'factory_girl' gem 'net-sftp' gem 'will_paginate' # dependency for squirrel & jqgrid gem 'nokogiri' # only for test/functional/auth_controller_test.rb gem 'cucumber' gem 'cucumber-rails' gem 'webrat' gem 'rspec' ---------- end Gemfile ----------------- So, is this the same issue? It sure looks like it to me. I hope not to have to dive into the innards of rubygems if possible. But we need to be able to deploy. The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap. I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again. Thanks for your time in this! Cheers, Craig ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 From drbrain at segment7.net Tue Mar 1 19:08:53 2011 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 1 Mar 2011 16:08:53 -0800 Subject: [Rubygems-developers] [ANN] rubygems-update 1.6.0 Released Message-ID: rubygems-update version 1.6.0 has been released! * * * * * RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have any RubyGems install, there is still the pre-gem approach to getting software, doing it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help Changes: ### 1.6.0 / 2011-02-29 4 Deprecations: * RubyGems no longer requires 'thread'. Rails < 3 will need to add require 'thread' to their applications. * Gem.cache is deprecated. Use Gem.source_index. * RbConfig.datadir is deprecated. Use Gem.datadir. * Gem::LoadError#version_requirements has been removed. Use Gem::LoadError#requirement. 2 Major Enhancements: * Rewrote how Gem::activate (gem and require) resolves dependencies. * Gem::LoadError#version_requirement has been removed. Use Gem::LoadError#requirement. 17 Minor Enhancments: * Added --key to `gem push` for setting alternate API keys. * Added --format-executable support to gem uninstall. * Added Gem::DependencyList#clear. * Added Gem::DependencyList#remove_specs_unsatisfied_by * Added Gem.latest_spec_for, latest_version_for, and latest_rubygems_version. * Added Gem::Dependency#merge which merges requirements for two dependencies. * Added Gem::TestCase#util_spec for faster tests. * Added Gem::Specification#dependent_specs. * Added Gem::TestCase#new_spec and Gem::TestCase#install_specs. * Added flag to include prerelease gems in Gem::SourceIndex#latest_specs. * Gem.cache_dir always references the proper cache dir. Pass true to support a user path. * Gem.cache_gem, given a filename always references the cache gem. Pass true to support a user path. * Added Gem::Specification#conflicts * Removed rdoc gem/require from test_case.rb. * Rubygems will no longer let you push if you're using beta or unreleased rubygems. * Save RAM / GC churn by removing spec.files and rdoc options from locally cached gem specifications. * SpecFetcher.fetch_spec can now take a string source_uri. 10 Bug Fixes: * Added missing require of Gem::RemoteFetcher to the unpack command. * RubyGems now completely removes a previous install when reinstalling. * Fixed Gem::Installer#generate_bin to only chmod files that exist. * Fixed handling of Windows style file:/// uris. * Fixed requires in tests. (shota) * Fixed script generation on Windows. * Fixed test issues if you have older rubygems installed. * Gem::DependencyInstaller tests use Gem::Security, add the missing require. * Gem::Security used FileUtils but didn't require it. Reported by Elia Schito. * Gem::Uninstaller now respects --format-executable. From noreply at rubyforge.org Tue Mar 1 22:51:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Mar 2011 22:51:29 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27588 ] Activating a dependency raises error even though a satisfactory version is already activated. Message-ID: <20110302035129.AA878185836C@rubyforge.org> Bugs item #27588, was opened at 2009-12-18 01:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126 Category: #gem and #require methods Group: v1.4.x >Status: Closed Resolution: Out of Date Priority: 3 Submitted By: Daniel Parker (dcparker) Assigned to: Ryan Davis (zenspider) Summary: Activating a dependency raises error even though a satisfactory version is already activated. Initial Comment: I have loaded a gem "A" that loaded version 0.9.13 of gem "B", and then continued to load gem "C" that needed version "~> 0.9.12" of gem "B". Under normal conditions, version 0.9.13 should suit just fine if I'm looking for "~> 0.9.12". But in this case, since: (1) version 0.9.13 is *already loaded*, and (2) I have since changed my Gem path in such a way that 0.9.13 is not able to be found in the new Gem path, -> it fails and raises an error saying that it can't activate. This happens because in rubygems.rb, line 268: unless matches.any? { |spec| spec.version == existing_spec.version } then This should look at the existing spec and test whether it passes the version-requirements. However, the way it is doing it depends on the already-loaded spec to be able to be found again in the most recent search. This fails if the Gem paths have changed and the already-loaded spec is a version that is no longer able to be found in the new Gem path. This proposed change to this single line fixes the problem: rubygems.rb at 268 - unless matches.any? { |spec| spec.version == existing_spec.version } then + unless gem.version_requirements.satisfied_by?(existing_spec.version) then ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-01 19:51 Message: The following test passes in at least 1.6.0: a1 = new_spec "a", "1.0", "b" => "= 0.2" b1 = new_spec "b", "0.1", "c" => "= 1" b2 = new_spec "b", "0.2", "c" => "= 1" c1 = new_spec "c", "1.0", "b" => "~> 0.1" install_specs a1, b1, b2, c1 Gem.activate "a", "= 1" assert_equal %w(a-1.0 b-0.2 c-1.0), loaded_spec_names assert_equal [], unresolved_names ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 16:59 Message: Please respond to Eric's question so I can write a failing test. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-02-06 22:02 Message: Do you have a set of gems that can reproduce this? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126 From noreply at rubyforge.org Tue Mar 1 22:58:57 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Mar 2011 22:58:57 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28806 ] Re-install of a gem can leave prior gem files remaining Message-ID: <20110302035857.C03B91858374@rubyforge.org> Bugs item #28806, was opened at 2010-12-28 17:26 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28806&group_id=126 Category: `gem install` command Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: David Kellum (dekellum) Assigned to: Ryan Davis (zenspider) Summary: Re-install of a gem can leave prior gem files remaining Initial Comment: The problem arises when the contents of gem change over multiple builds with the same gem version, typically when a gem is under development and installed repeatedly to a local gem home. There are several cases where gems load or otherwise use all files in a particular directory within the gem install dir. When a file is removed or renamed over subsequent builds, old files from the prior "gem install" will remain after the new "gem install", leading to often unexpected behavior. One specific example would be gem packaged ActiveRecord migrations directory, where all migrations in a gem installed "db/" directory are applied. To avoid any chance of inconsistent behavior from prior installed gem files, it would be best if the gem Installer removed all old files from the gem_dir before installing the new files. It looks like an easy change. I will offer a patch for this issue up on github. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-01 19:58 Message: Thanks! ---------------------------------------------------------------------- Comment By: David Kellum (dekellum) Date: 2011-02-08 07:04 Message: New Pull Request with test case: https://github.com/rubygems/rubygems/pull/29 ---------------------------------------------------------------------- Comment By: David Kellum (dekellum) Date: 2010-12-28 17:35 Message: Pull request: https://github.com/rubygems/rubygems/pull/18 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28806&group_id=126 From noreply at rubyforge.org Tue Mar 1 23:04:20 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Mar 2011 23:04:20 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28993 ] "gem uninstall" and --format-executable Message-ID: <20110302040420.6171D185836C@rubyforge.org> Bugs item #28993, was opened at 2011-02-24 09:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28993&group_id=126 Category: `gem install` command Group: None Status: Open >Resolution: Accepted Priority: 3 Submitted By: Sven Schwyn (svoop) >Assigned to: Ryan Davis (zenspider) >Summary: "gem uninstall" and --format-executable Initial Comment: I'm observing the following issue on my Gentoo box with several Rubies (MRI 1.8 and 1.9) installed: cat /etc/gemrc --- gem: --format-executable gem19 install rake ls /usr/local/bin rake19 # executable installed by Rubygems rake -> rake19 # convenience symlink is created by Gentoo gem uninstall rake ls /usr/local/bin rake19 Apparently, the "gem uninstall" command does not honor --format-executable. Wouldn't it be a more consistent behavior if the versioned (or formatted) executable were uninstalled? (Gentoo would then take care of the dead symlink.) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28993&group_id=126 From noreply at rubyforge.org Wed Mar 2 02:44:15 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 Mar 2011 02:44:15 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28993 ] "gem uninstall" and --format-executable Message-ID: <20110302074415.81051177994C@rubyforge.org> Bugs item #28993, was opened at 2011-02-24 09:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28993&group_id=126 Category: `gem install` command Group: None >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Sven Schwyn (svoop) Assigned to: Ryan Davis (zenspider) >Summary: "gem uninstall" and --format-executable Initial Comment: I'm observing the following issue on my Gentoo box with several Rubies (MRI 1.8 and 1.9) installed: cat /etc/gemrc --- gem: --format-executable gem19 install rake ls /usr/local/bin rake19 # executable installed by Rubygems rake -> rake19 # convenience symlink is created by Gentoo gem uninstall rake ls /usr/local/bin rake19 Apparently, the "gem uninstall" command does not honor --format-executable. Wouldn't it be a more consistent behavior if the versioned (or formatted) executable were uninstalled? (Gentoo would then take care of the dead symlink.) ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-01 23:44 Message: This is fixed by 1.6.0 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28993&group_id=126 From noreply at rubyforge.org Wed Mar 2 08:39:31 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 Mar 2011 08:39:31 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28993 ] " gem uninstall" and --format-executable Message-ID: <20110302133931.A41141858317@rubyforge.org> Bugs item #28993, was opened at 2011-02-24 18:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28993&group_id=126 Category: `gem install` command Group: None Status: Closed Resolution: Accepted Priority: 3 Submitted By: Sven Schwyn (svoop) Assigned to: Ryan Davis (zenspider) >Summary: "gem uninstall" and --format-executable Initial Comment: I'm observing the following issue on my Gentoo box with several Rubies (MRI 1.8 and 1.9) installed: cat /etc/gemrc --- gem: --format-executable gem19 install rake ls /usr/local/bin rake19 # executable installed by Rubygems rake -> rake19 # convenience symlink is created by Gentoo gem uninstall rake ls /usr/local/bin rake19 Apparently, the "gem uninstall" command does not honor --format-executable. Wouldn't it be a more consistent behavior if the versioned (or formatted) executable were uninstalled? (Gentoo would then take care of the dead symlink.) ---------------------------------------------------------------------- >Comment By: Sven Schwyn (svoop) Date: 2011-03-02 14:39 Message: Thanks for the fix, it's very much appreciated! ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-02 08:44 Message: This is fixed by 1.6.0 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28993&group_id=126 From jon.forums at gmail.com Wed Mar 2 10:02:03 2011 From: jon.forums at gmail.com (Jon) Date: Wed, 2 Mar 2011 10:02:03 -0500 Subject: [Rubygems-developers] [JRuby/Windows] 1.6.0 update - partial script update? In-Reply-To: References: Message-ID: <20110302100203.231843f3.jon.forums@gmail.com> > To upgrade to the latest RubyGems, run: > > $ gem update --system # you might need to be an administrator or root When upgrading RG for JRuby on Windows (1.6.0.RC2) should both jgem.bat/jgem and gem.bat/gem be updated or only jgem.bat/jgem? >From the following it looks like jgem.bat/jgem were the only ones updated: C:\Users\Jon\Documents>gem update --system Updating rubygems-update Fetching: rubygems-update-1.6.0.gem (100%) Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ... RubyGems installed the following executables: C:/jruby/bin/jgem RubyGems system software updated C:\jruby\bin>git diff gem.bat jgem.bat diff --git a/gem.bat b/jgem.bat index dc28ef1..befbaf7 100644 --- a/gem.bat +#!C:/jruby/bin/jruby.exe +++ b/jgem.bat @@ -1,6 +1,6 @@ @ECHO OFF IF NOT "%~f0" == "~f0" GOTO :WinNT -@"jruby" -S "gem" %1 %2 %3 %4 %5 %6 %7 %8 %9 +@"jruby.exe" "C:/jruby/bin/jgem" %1 %2 %3 %4 %5 %6 %7 %8 %9 GOTO :EOF :WinNT -@"%~dp0jruby.exe" "%~dpn0" %* +@"jruby.exe" "%~dpn0" %* Jon --- blog: http://jonforums.github.com/ twitter: @jonforums From noreply at rubyforge.org Wed Mar 2 15:03:36 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 Mar 2011 15:03:36 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Patches-29049 ] show rdoc process verbosely with -V specified Message-ID: <20110302200337.026C71858374@rubyforge.org> Patches item #29049, was opened at 2011-03-03 05:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=29049&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mamoru Tasaka (mtasaka) Assigned to: Nobody (None) Summary: show rdoc process verbosely with -V specified Initial Comment: When "gem install" is executed with -V option, - unpack process of gem archive - build process of C native codes are shown verbosely. But rdoc process is always called with --quiet option so the process won't be shown verbosely, which I think is inconsistent. The patch is to show rdoc process verbosely when "gem install" is executed with -V option (verbose mode). Please consider to apply this patch. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=29049&group_id=126 From noreply at rubyforge.org Wed Mar 2 15:09:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 Mar 2011 15:09:54 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29050 ] rake test fails with some umask Message-ID: <20110302200954.390BC1858346@rubyforge.org> Bugs item #29050, was opened at 2011-03-03 05:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29050&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mamoru Tasaka (mtasaka) Assigned to: Nobody (None) Summary: rake test fails with some umask Initial Comment: $ rake test for rubygems 1.6.0 fails on some tests when umask is set to 0077, like 1) Failure: test_generate_bin_script_no_shebang(TestGemInstaller) [./test/rubygems/test_gem_installer.rb:301]: Expected 33261, not 33216. The attached patch is to fix this issue. Please consider to apply this patch. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29050&group_id=126 From noreply at rubyforge.org Wed Mar 2 15:17:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 Mar 2011 15:17:07 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29051 ] cached gem installed in two directories with 1.6.0 Message-ID: <20110302201707.E7F791858346@rubyforge.org> Bugs item #29051, was opened at 2011-03-03 05:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29051&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mamoru Tasaka (mtasaka) Assigned to: Nobody (None) Summary: cached gem installed in two directories with 1.6.0 Initial Comment: ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-linux] With rubygems 1.6.0, when trying to install gem with $ gem install --install-dir cached gem is installed under - /cache - and also /cache/cache The latter one is unneeded. This issue does not exist with 1.5.3. Looking at the diff between 1.5.3 and 1.6.0, the attached patch fixes this issue. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29051&group_id=126 From noreply at rubyforge.org Thu Mar 3 07:31:38 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Mar 2011 07:31:38 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29053 ] YAML error when installing gem on jruby Message-ID: <20110303123138.BD6561678326@rubyforge.org> Bugs item #29053, was opened at 2011-03-04 01:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29053&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: John Mair (banister) Assigned to: Nobody (None) Summary: YAML error when installing gem on jruby Initial Comment: john at littleblood ~ $ gem install pry ERROR: While executing gem ... (ArgumentError) undefined class/module YAML::Syck::DefaultKey gem env output: $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.0 - RUBY VERSION: 1.8.7 (2010-09-28 patchlevel 249) [java] - INSTALLATION DIRECTORY: /home/john/.rvm/gems/jruby-1.5.3 - RUBY EXECUTABLE: /home/john/.rvm/rubies/jruby-1.5.3/bin/jruby - EXECUTABLE DIRECTORY: /home/john/.rvm/gems/jruby-1.5.3/bin - RUBYGEMS PLATFORMS: - ruby - universal-java-1.6 - GEM PATHS: - /home/john/.rvm/gems/jruby-1.5.3 - /home/john/.rvm/gems/jruby-1.5.3 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--env-shebang" - "update" => "--env-shebang" - "gem" => "--no-rdoc --no-ri" - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29053&group_id=126 From noreply at rubyforge.org Thu Mar 3 07:39:07 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Mar 2011 07:39:07 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29053 ] YAML error when installing gem on jruby Message-ID: <20110303123907.5E8901858346@rubyforge.org> Bugs item #29053, was opened at 2011-03-04 01:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29053&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: John Mair (banister) Assigned to: Nobody (None) Summary: YAML error when installing gem on jruby Initial Comment: john at littleblood ~ $ gem install pry ERROR: While executing gem ... (ArgumentError) undefined class/module YAML::Syck::DefaultKey gem env output: $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.0 - RUBY VERSION: 1.8.7 (2010-09-28 patchlevel 249) [java] - INSTALLATION DIRECTORY: /home/john/.rvm/gems/jruby-1.5.3 - RUBY EXECUTABLE: /home/john/.rvm/rubies/jruby-1.5.3/bin/jruby - EXECUTABLE DIRECTORY: /home/john/.rvm/gems/jruby-1.5.3/bin - RUBYGEMS PLATFORMS: - ruby - universal-java-1.6 - GEM PATHS: - /home/john/.rvm/gems/jruby-1.5.3 - /home/john/.rvm/gems/jruby-1.5.3 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--env-shebang" - "update" => "--env-shebang" - "gem" => "--no-rdoc --no-ri" - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- >Comment By: John Mair (banister) Date: 2011-03-04 01:39 Message: Note that above is using the java platform gem, when i use the --platform=ruby gem i get even scarier errors: $ gem install pry --platform=ruby Fetching: sexp_processor-3.0.5.gem (100%) Fetching: ruby_parser-2.0.6.gem (100%) Fetching: coderay-0.9.7.gem (100%) Fetching: method_source-0.3.4.gem (100%) System.java:-2:in `arraycopy': java.lang.ArrayIndexOutOfBoundsException from DefaultResolver.java:111:in `makeTime' from DefaultResolver.java:277:in `create' from DefaultResolver.java:317:in `handleScalar' from DefaultResolver.java:435:in `orgHandler' from DefaultResolver.java:455:in `node_import' from org/yecht/ruby/DefaultResolver$s_method_1_0$RUBYINVOKER$node _import.gen:65535:in `call' from CachingCallSite.java:146:in `call' (..elided..) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29053&group_id=126 From noreply at rubyforge.org Thu Mar 3 14:17:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Mar 2011 14:17:14 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110303191714.E076D1858346@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 19:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Nobody (None) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Thu Mar 3 15:01:42 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Mar 2011 15:01:42 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-28907 ] [RG 1.5.0/Ruby 1.9.x] source gem build error due to syck? Message-ID: <20110303200142.D993C1858317@rubyforge.org> Bugs item #28907, was opened at 2011-02-03 18:59 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28907&group_id=126 Category: `gem` commands (other) Group: v1.5.x Status: Closed Resolution: Accepted Priority: 3 Submitted By: Jon Forums (jonforums) Assigned to: Eric Hodel (drbrain) Summary: [RG 1.5.0/Ruby 1.9.x] source gem build error due to syck? Initial Comment: When building a source gem from http://github.com/oopsforge/oops-null using 'rake gem' I get the following error on Win7 with: * ruby 1.9.2p174 (2011-01-28 revision 30696) [i386-mingw32] * ruby 1.9.3dev (2011-02-04 trunk 30776) [i386-mingw32] but no errors using "ruby 1.8.7 (2010-12-23 patchlevel 330) [i386-mingw32]". Manually building via 'gem build oops-null.gemspec' work fine on all the Ruby versions including JRuby 1.6.0.RC1. All versions have been upgraded to RG 1.5.0 via "gem update --system". FWIW, the failure does not occur on "ruby 1.9.2 (2010-12-25 patchlevel 136) [i386-mingw32]" using RG 1.3.7 My "fix" was to add the following lines to the project Rakefile after the 3 require's: require 'yaml' YAML::ENGINE.yamler='psych' if defined?(YAML::ENGINE) I will try to replicate on my Arch system later this afternoon. Reproducible? Jon == ERROR == C:\projects\oops-null-git>gem env RubyGems Environment: - RUBYGEMS VERSION: 1.5.0 - RUBY VERSION: 1.9.2 (2011-01-28 patchlevel 174) [i386-mingw32] - INSTALLATION DIRECTORY: C:/ruby192/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: C:/ruby192/bin/ruby.exe - EXECUTABLE DIRECTORY: C:/ruby192/bin - RUBYGEMS PLATFORMS: - ruby - x86-mingw32 - GEM PATHS: - C:/ruby192/lib/ruby/gems/1.9.1 - C:/Users/Jon/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org", "http://gemcutter.org"] - "gem" => "--no-ri --no-rdoc" - REMOTE SOURCES: - http://rubygems.org - http://gemcutter.org C:\projects\oops-null-git>rake gem (in C:/projects/oops-null-git) mkdir -p pkg mkdir -p pkg mkdir -p pkg/oops-null-0.3.0/bin rm -f pkg/oops-null-0.3.0/bin/nulloops ln bin/nulloops pkg/oops-null-0.3.0/bin/nulloops rm -f pkg/oops-null-0.3.0/Rakefile ln Rakefile pkg/oops-null-0.3.0/Rakefile rm -f pkg/oops-null-0.3.0/oops-null.gemspec ln oops-null.gemspec pkg/oops-null-0.3.0/oops-null.gemspec mkdir -p pkg/oops-null-0.3.0/ext/oops_null rm -f pkg/oops-null-0.3.0/ext/oops_null/extconf.rb ln ext/oops_null/extconf.rb pkg/oops-null-0.3.0/ext/oops_null/extconf.rb rm -f pkg/oops-null-0.3.0/ext/oops_null/oops_null.c ln ext/oops_null/oops_null.c pkg/oops-null-0.3.0/ext/oops_null/oops_null.c rm -f pkg/oops-null-0.3.0/ext/oops_null/oops_null.h ln ext/oops_null/oops_null.h pkg/oops-null-0.3.0/ext/oops_null/oops_null.h mkdir -p pkg/oops-null-0.3.0/lib rm -f pkg/oops-null-0.3.0/lib/oops-null.rb ln lib/oops-null.rb pkg/oops-null-0.3.0/lib/oops-null.rb cd pkg/oops-null-0.3.0 rake aborted! undefined method `write' for # C:/ruby192/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in `end_document' C:/ruby192/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in `visit_Psych_Nodes_Document' C:/ruby192/lib/ruby/1.9.1/psych/visitors/visitor.rb:10:in `accept' C:/ruby192/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `block in visit_Psych_Nodes_Stream' C:/ruby192/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `each' C:/ruby192/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `visit_Psych_Nodes_Stream' C:/ruby192/lib/ruby/1.9.1/psych/visitors/visitor.rb:11:in `accept' C:/ruby192/lib/ruby/1.9.1/psych/nodes/node.rb:36:in `to_yaml' C:/ruby192/lib/ruby/1.9.1/psych.rb:166:in `dump' C:/ruby192/lib/ruby/1.9.1/psych/core_ext.rb:13:in `psych_to_yaml' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:706:in `node_export' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:706:in `add' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:706:in `encode_with' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:727:in `block (2 levels) in to_yaml' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:726:in `map' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:726:in `block in to_yaml' C:/ruby192/lib/ruby/1.9.1/syck.rb:401:in `call' C:/ruby192/lib/ruby/1.9.1/syck.rb:401:in `emit' C:/ruby192/lib/ruby/1.9.1/syck.rb:401:in `quick_emit' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:725:in `to_yaml' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:78:in `block (2 levels) in write_package' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:73:in `block (3 levels) in add_gem_contents' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:83:in `new' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:67:in `block (2 levels) in add_gem_contents' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in `wrap' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in `block in add_gem_contents' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:113:in `add_file' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:63:in `add_gem_contents' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:31:in `open' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package.rb:68:in `open' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:77:in `block in write_package' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:76:in `open' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:76:in `write_package' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:39:in `build' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package_task.rb:116:in `block (3 levels) in define' C:/ruby192/lib/ruby/1.9.1/rake.rb:1157:in `when_writing' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package_task.rb:115:in `block (2 levels) in define' C:/ruby192/lib/ruby/1.9.1/fileutils.rb:121:in `chdir' C:/ruby192/lib/ruby/1.9.1/fileutils.rb:121:in `cd' C:/ruby192/lib/ruby/1.9.1/rake.rb:1092:in `chdir' C:/ruby192/lib/ruby/site_ruby/1.9.1/rubygems/package_task.rb:114:in `block in define' C:/ruby192/lib/ruby/1.9.1/rake.rb:634:in `call' C:/ruby192/lib/ruby/1.9.1/rake.rb:634:in `block in execute' C:/ruby192/lib/ruby/1.9.1/rake.rb:629:in `each' C:/ruby192/lib/ruby/1.9.1/rake.rb:629:in `execute' C:/ruby192/lib/ruby/1.9.1/rake.rb:595:in `block in invoke_with_call_chain' C:/ruby192/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize' C:/ruby192/lib/ruby/1.9.1/rake.rb:588:in `invoke_with_call_chain' C:/ruby192/lib/ruby/1.9.1/rake.rb:605:in `block in invoke_prerequisites' C:/ruby192/lib/ruby/1.9.1/rake.rb:602:in `each' C:/ruby192/lib/ruby/1.9.1/rake.rb:602:in `invoke_prerequisites' C:/ruby192/lib/ruby/1.9.1/rake.rb:594:in `block in invoke_with_call_chain' C:/ruby192/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize' C:/ruby192/lib/ruby/1.9.1/rake.rb:588:in `invoke_with_call_chain' C:/ruby192/lib/ruby/1.9.1/rake.rb:581:in `invoke' C:/ruby192/lib/ruby/1.9.1/rake.rb:2041:in `invoke_task' C:/ruby192/lib/ruby/1.9.1/rake.rb:2019:in `block (2 levels) in top_level' C:/ruby192/lib/ruby/1.9.1/rake.rb:2019:in `each' C:/ruby192/lib/ruby/1.9.1/rake.rb:2019:in `block in top_level' C:/ruby192/lib/ruby/1.9.1/rake.rb:2058:in `standard_exception_handling' C:/ruby192/lib/ruby/1.9.1/rake.rb:2013:in `top_level' C:/ruby192/lib/ruby/1.9.1/rake.rb:1992:in `run' C:/ruby192/bin/rake:31:in `
' ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2011-03-03 20:01 Message: Was this still fixed in 1.6.0? (I'm still getting it there). Thanks! -r ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-02-28 18:56 Message: Fixed by 1.5.3 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-02-25 19:38 Message: So, to be clear, if psych is used to create a gemspec with a version specifier using "=", and the gem is subsequently loaded using syck, this error will occur. This is a bug in syck. Our workaround is to look up the parsed value and if it looks up nil, fall back on a manual "=". We should backport this fix into the 1.5 line. Eric. I'll leave the backport to you. ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2011-02-25 18:24 Message: Just got this with jeweler, too, FYI. https://gist.github.com/844237 ---------------------------------------------------------------------- Comment By: Leonard Chin (lchin) Date: 2011-02-10 07:37 Message: The same error occurs with hoe Using RubyGems at commit 182bcaf7bd4f77493794 with Ruby 1.9.2-p136 https://github.com/rubygems/rubygems/tree/182bcaf7bd4f77493794d216ac37aa9935655943 rake package --trace (in /Users/lchin/Downloads/buggy) ** Invoke package (first_time) ** Invoke pkg/buggy-1.0.0.tgz (first_time, not_needed) ** Invoke pkg/buggy-1.0.0 (first_time, not_needed) ** Invoke .autotest (first_time, not_needed) ** Invoke History.txt (first_time, not_needed) ** Invoke Manifest.txt (first_time, not_needed) ** Invoke README.txt (first_time, not_needed) ** Invoke Rakefile (first_time, not_needed) ** Invoke bin/buggy (first_time, not_needed) ** Invoke lib/buggy.rb (first_time, not_needed) ** Invoke test/test_buggy.rb (first_time, not_needed) ** Invoke .autotest (not_needed) ** Invoke History.txt (not_needed) ** Invoke Manifest.txt (not_needed) ** Invoke README.txt (not_needed) ** Invoke Rakefile (not_needed) ** Invoke bin/buggy (not_needed) ** Invoke lib/buggy.rb (not_needed) ** Invoke test/test_buggy.rb (not_needed) ** Invoke gem (first_time) ** Invoke pkg/buggy-1.0.0.gem (first_time) ** Invoke pkg (first_time, not_needed) ** Invoke pkg/buggy-1.0.0 (not_needed) ** Invoke .autotest (not_needed) ** Invoke History.txt (not_needed) ** Invoke Manifest.txt (not_needed) ** Invoke README.txt (not_needed) ** Invoke Rakefile (not_needed) ** Invoke bin/buggy (not_needed) ** Invoke lib/buggy.rb (not_needed) ** Invoke test/test_buggy.rb (not_needed) ** Execute pkg/buggy-1.0.0.gem cd pkg/buggy-1.0.0 WARNING: description and summary are identical rake aborted! undefined method `write' for # /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in `end_document' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in `visit_Psych_Nodes_Document' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/visitors/visitor.rb:10:in `accept' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `block in visit_Psych_Nodes_Stream' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `each' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in `visit_Psych_Nodes_Stream' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/visitors/visitor.rb:11:in `accept' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/nodes/node.rb:36:in `to_yaml' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:166:in `dump' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych/core_ext.rb:13:in `psych_to_yaml' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:706:in `node_export' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:706:in `add' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:706:in `encode_with' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:728:in `block (2 levels) in to_yaml' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:727:in `map' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:727:in `block in to_yaml' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/syck.rb:401:in `call' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/syck.rb:401:in `emit' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/syck.rb:401:in `quick_emit' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:726:in `to_yaml' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:78:in `block (2 levels) in write_package' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:73:in `block (3 levels) in add_gem_contents' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:83:in `new' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:67:in `block (2 levels) in add_gem_contents' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in `wrap' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in `block in add_gem_contents' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:113:in `add_file' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:63:in `add_gem_contents' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:31:in `open' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package.rb:68:in `open' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:77:in `block in write_package' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:76:in `open' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:76:in `write_package' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:39:in `build' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package_task.rb:116:in `block (3 levels) in define' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:1159:in `when_writing' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package_task.rb:115:in `block (2 levels) in define' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/fileutils.rb:121:in `chdir' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/fileutils.rb:121:in `cd' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:1094:in `chdir' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/site_ruby/1.9.1/rubygems/package_task.rb:114:in `block in define' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:636:in `call' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:636:in `block in execute' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:631:in `each' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:631:in `execute' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:597:in `block in invoke_with_call_chain' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:607:in `block in invoke_prerequisites' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:604:in `each' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:604:in `invoke_prerequisites' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:596:in `block in invoke_with_call_chain' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:607:in `block in invoke_prerequisites' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:604:in `each' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:604:in `invoke_prerequisites' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:596:in `block in invoke_with_call_chain' /Users/lchin/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:583:in `invoke' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:2029:in `block (2 levels) in top_level' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:2029:in `each' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:2029:in `block in top_level' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:2001:in `block in run' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/lib/rake.rb:1998:in `run' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/gems/rake-0.8.7/bin/rake:31:in `' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/bin/rake:19:in `load' /Users/lchin/.rvm/gems/ruby-1.9.2-p136 at global/bin/rake:19:in `
' ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-02-05 22:00 Message: All OK now with the updated rake-compiler. So I'm clear, this is the main commit to pay attention to? https://github.com/rubygems/rubygems/commit/67f9f760c782142d9bfd8099750274ba498d6682 Given the simple tweak to rake-compiler, is your recommendation that other gems requiring yaml also prefer psych when running on 1.9.2+ and RG 1.5.0+ FWIW, I personally like the idea of preferring psych, but would like to have first seen it mentioned in one of the following rather than in a bt: http://blog.segment7.net/2011/01/31/rubygems-1-5 https://github.com/rubygems/rubygems/blob/master/UPGRADING.rdoc Jon ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-02-04 23:37 Message: Yes, you are loading syck (require 'yaml') before psych (require 'psych'): https://github.com/luislavena/rake-compiler/blob/master/lib/rake/baseextensiontask.rb This is not supported. A patch will be sent to rake-compiler. You can work around this by requiring psych before rake-compiler. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-02-04 21:01 Message: That's not the issue, sorry I wasn't clear. I'm not mixing syck or psyck in the same ruby in my code. My original Rakefile https://github.com/oopsforge/oops- null/blob/master/Rakefile that worked pre-1.5.0 didn't explicitly require 'yaml' or the YAML::ENGINE.yamler= nonsense. I added these lines to get the gem to build when I saw the error message undefined method `write' for # C:/ruby192/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in `end_document' ... ..as I guessed that explicitly setting the YAML engine to psych would prevent syck from being visited/wrapped by psych. I think something's changed in RG 1.5.0 and/or ruby_1_9_2 or trunk that's causing the problem. I wanted to dig into how psych was visiting/wrapping syck but ran out of time. I also did a quick look through rake-compiler and don't think it's to blame. Given that my original Rakefile fails on Win7 MRI 1.9.2- p174, 1.9.2-p136, 1.9.3dev and Arch 1.9.3dev when using RG 1.5.0 I still think the problem is in RG. Hopefully I explained it more clearly this time. Would you take one more look at that long back trace and see if you change your mind on the issue? ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-02-04 20:33 Message: Do not mix syck (require 'yaml') and psych (require 'psych') in the same ruby. RubyGems uses psych on ruby 1.9.2 and newer as syck is deprecated and will be removed at a future date. Please update your Rakefile to match. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-02-04 14:53 Message: same failure on "ruby 1.9.2p136 (2010-12-25) [i386-mingw32]" upgraded from RG 1.3.7 to RG 1.5.0 ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-02-03 19:13 Message: similar failure and working "fix" on Arch using: ruby 1.9.3dev (2011-02-04 trunk 30776) [i686-linux] RubyGems Environment: - RUBYGEMS VERSION: 1.5.0 - RUBY VERSION: 1.9.3 (2011-02-04 patchlevel -1) [i686- linux] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /usr/local/bin/ruby - EXECUTABLE DIRECTORY: /usr/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-linux - GEM PATHS: - /usr/local/lib/ruby/gems/1.9.1 - /home/jon/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org", "http://gemcutter.org"] - "gem" => "--no-ri --no-rdoc" - REMOTE SOURCES: - http://rubygems.org - http://gemcutter.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28907&group_id=126 From noreply at rubyforge.org Thu Mar 3 18:14:35 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Mar 2011 18:14:35 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110303231435.266381858300@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 11:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other >Group: v1.6.x Status: Open >Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) >Assigned to: Eric Hodel (drbrain) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-03 15:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Thu Mar 3 18:22:22 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Mar 2011 18:22:22 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29051 ] cached gem installed in two directories with 1.6.0 Message-ID: <20110303232222.8229A1858300@rubyforge.org> Bugs item #29051, was opened at 2011-03-02 12:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29051&group_id=126 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Mamoru Tasaka (mtasaka) >Assigned to: Eric Hodel (drbrain) Summary: cached gem installed in two directories with 1.6.0 Initial Comment: ruby 1.8.7 (2011-02-18 patchlevel 334) [i386-linux] With rubygems 1.6.0, when trying to install gem with $ gem install --install-dir cached gem is installed under - /cache - and also /cache/cache The latter one is unneeded. This issue does not exist with 1.5.3. Looking at the diff between 1.5.3 and 1.6.0, the attached patch fixes this issue. ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-03 15:22 Message: Applied! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29051&group_id=126 From noreply at rubyforge.org Thu Mar 3 18:26:04 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Mar 2011 18:26:04 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29050 ] rake test fails with some umask Message-ID: <20110303232604.4B9251858300@rubyforge.org> Bugs item #29050, was opened at 2011-03-02 12:09 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29050&group_id=126 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Mamoru Tasaka (mtasaka) >Assigned to: Eric Hodel (drbrain) Summary: rake test fails with some umask Initial Comment: $ rake test for rubygems 1.6.0 fails on some tests when umask is set to 0077, like 1) Failure: test_generate_bin_script_no_shebang(TestGemInstaller) [./test/rubygems/test_gem_installer.rb:301]: Expected 33261, not 33216. The attached patch is to fix this issue. Please consider to apply this patch. ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-03 15:26 Message: Applied! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29050&group_id=126 From ryand-ruby at zenspider.com Thu Mar 3 20:26:55 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 3 Mar 2011 17:26:55 -0800 Subject: [Rubygems-developers] The 1.7 Plan Message-ID: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Working on the installer and Gem.activate on 1.6 showed how crufty and painful Gem, Specification and Dependency were. 1.7 is going to focus almost entirely on refactoring the API into something useful. Specifically: + GemPathSearcher needs to die. God I hate it. 100% of it is bad design and equivalent functionality should be built into specifications themselves. + The relationship between Specification and Dependency needs to be made more usable. In particular, going to source_index every time you need something is an abomination. Specification should be able to respond with all specs that match it's dependencies. + Installer code and activation code needs a refactoring. The fact that I had to do _nearly_ the same thing twice was proof of that. + Gem.activate should be moved to Specification#activate. + Gem.source_index should be hidden as an implementation detail (or removed) and proper public counterparts should be added (eg. Specification.all/active/find/named). + Lots more Gem class methods should be moved to where their responsibilities properly belong. There is so many LoD violations that it isn't funny. I'm sure there is a lot more. That's just off the top of my head. IMPORTANT: This release is going to be a code contraction month. Feature additions / enhancements should NOT go in master and should NOT be released in 1.7. We can add toys in 1.8. From nick at quaran.to Thu Mar 3 22:11:47 2011 From: nick at quaran.to (Nick Quaranto) Date: Thu, 3 Mar 2011 22:11:47 -0500 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: I'd like to get gem yank in at some point, I think by now it's solid, especially with the addition of platform support that I sat on for way too long. Does that mean I'll have to wait until April to get a patch in for that? On Thu, Mar 3, 2011 at 8:26 PM, Ryan Davis wrote: > Working on the installer and Gem.activate on 1.6 showed how crufty and painful Gem, Specification and Dependency were. 1.7 is going to focus almost entirely on refactoring the API into something useful. Specifically: > > + GemPathSearcher needs to die. God I hate it. 100% of it is bad design and equivalent functionality should be built into specifications themselves. > + The relationship between Specification and Dependency needs to be made more usable. In particular, going to source_index every time you need something is an abomination. Specification should be able to respond with all specs that match it's dependencies. > + Installer code and activation code needs a refactoring. The fact that I had to do _nearly_ the same thing twice was proof of that. > + Gem.activate should be moved to Specification#activate. > + Gem.source_index should be hidden as an implementation detail (or removed) and proper public counterparts should be added (eg. Specification.all/active/find/named). > + Lots more Gem class methods should be moved to where their responsibilities properly belong. There is so many LoD violations that it isn't funny. > > I'm sure there is a lot more. That's just off the top of my head. > > IMPORTANT: This release is going to be a code contraction month. Feature additions / enhancements should NOT go in master and should NOT be released in 1.7. We can add toys in 1.8. > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From erik at hollensbe.org Thu Mar 3 23:10:06 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 3 Mar 2011 23:10:06 -0500 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: On Mar 3, 2011, at 8:26 PM, Ryan Davis wrote: > Working on the installer and Gem.activate on 1.6 showed how crufty and painful Gem, Specification and Dependency were. 1.7 is going to focus almost entirely on refactoring the API into something useful. Specifically: > > + GemPathSearcher needs to die. God I hate it. 100% of it is bad design and equivalent functionality should be built into specifications themselves. > + The relationship between Specification and Dependency needs to be made more usable. In particular, going to source_index every time you need something is an abomination. Specification should be able to respond with all specs that match it's dependencies. > + Installer code and activation code needs a refactoring. The fact that I had to do _nearly_ the same thing twice was proof of that. > + Gem.activate should be moved to Specification#activate. > + Gem.source_index should be hidden as an implementation detail (or removed) and proper public counterparts should be added (eg. Specification.all/active/find/named). > + Lots more Gem class methods should be moved to where their responsibilities properly belong. There is so many LoD violations that it isn't funny. > > I'm sure there is a lot more. That's just off the top of my head. > > IMPORTANT: This release is going to be a code contraction month. Feature additions / enhancements should NOT go in master and should NOT be released in 1.7. We can add toys in 1.8. Ryan, I have some change proposals which will probably impact this rather significantly that I've been toying around with, e.g.: https://gist.github.com/22fa600b8c98bdf8c785 It seems like implementing this would cover a lot of similar ground in spots. Is there a chance we can talk about how this fits in (or if it does at all) at some point? I was going to be drumming up a patch this weekend to integrate it for your guys' review, per a conversation with Eric and Evan. -Erik From drbrain at segment7.net Thu Mar 3 23:18:38 2011 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 3 Mar 2011 20:18:38 -0800 Subject: [Rubygems-developers] [ANN] rubygems-update 1.6.1 Released Message-ID: rubygems-update version 1.6.1 has been released! * * * * * RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have any RubyGems install, there is still the pre-gem approach to getting software, doing it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help Changes: ### 1.6.1 / 2011-03-03 Bug Fixes: * Installation no longer fails when a dependency from a version that won't be installed is unsatisfied. * README.rdoc now shows how to file tickets and get help. Pull Request #40 by Aaron Patterson. * Gem files are cached correctly again. Patch #29051 by Mamoru Tasaka. * Tests now pass with non-022 umask. Patch #29050 by Mamoru Tasaka. From evan at fallingsnow.net Thu Mar 3 22:12:58 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 3 Mar 2011 19:12:58 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: Sounds good. I'm working with the bundler guys to make sure we don't bust them for the release. Additionally, if there are other projects that have hard rubygems API dependencies, please let me know so that I can be sure add it to my list. Ryan, do you want to coordinate on making these changes or should we all dive in? - Evan From noreply at rubyforge.org Fri Mar 4 05:08:24 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 Mar 2011 05:08:24 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110304100824.44A2C1858367@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 19:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x Status: Open Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Eric Hodel (drbrain) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- >Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 10:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 23:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Fri Mar 4 10:08:35 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 Mar 2011 10:08:35 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29059 ] 1.6.1 doesn't update prerelease gems Message-ID: <20110304150835.BB9DD1858378@rubyforge.org> Bugs item #29059, was opened at 2011-03-04 15:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29059&group_id=126 Category: `gem` commands (other) Group: v1.6.x Status: Open Resolution: None Priority: 3 Submitted By: Jon Forums (jonforums) Assigned to: Nobody (None) Summary: 1.6.1 doesn't update prerelease gems Initial Comment: Is this use case supported? C:\Users\Jon>gem list eventmachine *** LOCAL GEMS *** eventmachine (1.0.0.beta.2 x86-mingw32) C:\Users\Jon>gem list eventmachine -r --pre *** REMOTE GEMS *** eventmachine (1.0.0.beta.3 ruby java java x86-mingw32 x86-mingw32 x86-mswin32-60 x86-mswin32-60, 1.0.0.beta.2 ruby java java x86-mingw32 x86-mingw32 x86-mswin32-60 x86-mswin32-60, 1.0.0.beta.1 ruby java java) C:\Users\Jon>gem update eventmachine --pre Updating installed gems Nothing to update C:\Users\Jon>gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-03-04 patchlevel -1) [i386-mingw32] - INSTALLATION DIRECTORY: C:/ruby19trunk/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: C:/ruby19trunk/bin/ruby.exe - EXECUTABLE DIRECTORY: C:/ruby19trunk/bin - RUBYGEMS PLATFORMS: - ruby - x86-mingw32 - GEM PATHS: - C:/ruby19trunk/lib/ruby/gems/1.9.1 - C:/Users/Jon/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org", "http://gemcutter.org"] - "gem" => "--no-ri --no-rdoc" - REMOTE SOURCES: - http://rubygems.org - http://gemcutter.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29059&group_id=126 From noreply at rubyforge.org Sat Mar 5 10:02:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 5 Mar 2011 10:02:14 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29053 ] YAML error when installing gem on jruby Message-ID: <20110305150214.21EA41858378@rubyforge.org> Bugs item #29053, was opened at 2011-03-04 01:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29053&group_id=126 Category: None Group: None >Status: Deleted Resolution: None Priority: 3 Submitted By: John Mair (banister) Assigned to: Nobody (None) Summary: YAML error when installing gem on jruby Initial Comment: john at littleblood ~ $ gem install pry ERROR: While executing gem ... (ArgumentError) undefined class/module YAML::Syck::DefaultKey gem env output: $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.0 - RUBY VERSION: 1.8.7 (2010-09-28 patchlevel 249) [java] - INSTALLATION DIRECTORY: /home/john/.rvm/gems/jruby-1.5.3 - RUBY EXECUTABLE: /home/john/.rvm/rubies/jruby-1.5.3/bin/jruby - EXECUTABLE DIRECTORY: /home/john/.rvm/gems/jruby-1.5.3/bin - RUBYGEMS PLATFORMS: - ruby - universal-java-1.6 - GEM PATHS: - /home/john/.rvm/gems/jruby-1.5.3 - /home/john/.rvm/gems/jruby-1.5.3 at global - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--env-shebang" - "update" => "--env-shebang" - "gem" => "--no-rdoc --no-ri" - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- Comment By: John Mair (banister) Date: 2011-03-04 01:39 Message: Note that above is using the java platform gem, when i use the --platform=ruby gem i get even scarier errors: $ gem install pry --platform=ruby Fetching: sexp_processor-3.0.5.gem (100%) Fetching: ruby_parser-2.0.6.gem (100%) Fetching: coderay-0.9.7.gem (100%) Fetching: method_source-0.3.4.gem (100%) System.java:-2:in `arraycopy': java.lang.ArrayIndexOutOfBoundsException from DefaultResolver.java:111:in `makeTime' from DefaultResolver.java:277:in `create' from DefaultResolver.java:317:in `handleScalar' from DefaultResolver.java:435:in `orgHandler' from DefaultResolver.java:455:in `node_import' from org/yecht/ruby/DefaultResolver$s_method_1_0$RUBYINVOKER$node _import.gen:65535:in `call' from CachingCallSite.java:146:in `call' (..elided..) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29053&group_id=126 From jftucker at gmail.com Sat Mar 5 18:49:29 2011 From: jftucker at gmail.com (James Tucker) Date: Sat, 5 Mar 2011 15:49:29 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: On Mar 3, 2011, at 7:12 PM, Evan Phoenix wrote: > Sounds good. > > I'm working with the bundler guys to make sure we don't bust them for the release. I've been trying to figure out in the odd 5 minutes I can scramble, how to get the requirements ordering regulated between 1.5 and 1.6, so far I haven't made a working patch. They'll start seeing bug reports coming in soon where teams are mixed between 1.6 and 1.5 rubygems. Just a heads up. Let me know if I can be of any assistance. From jftucker at gmail.com Sat Mar 5 18:53:51 2011 From: jftucker at gmail.com (James Tucker) Date: Sat, 5 Mar 2011 15:53:51 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: <4C9E2377-C352-4E43-8535-7551AD1C12F1@gmail.com> On Mar 3, 2011, at 5:26 PM, Ryan Davis wrote: > Working on the installer and Gem.activate on 1.6 showed how crufty and painful Gem, Specification and Dependency were. 1.7 is going to focus almost entirely on refactoring the API into something useful. Specifically: > > + GemPathSearcher needs to die. God I hate it. 100% of it is bad design and equivalent functionality should be built into specifications themselves. Nice :-) > + The relationship between Specification and Dependency needs to be made more usable. In particular, going to source_index every time you need something is an abomination. Specification should be able to respond with all specs that match it's dependencies. > + Installer code and activation code needs a refactoring. The fact that I had to do _nearly_ the same thing twice was proof of that. > + Gem.activate should be moved to Specification#activate. Want, so much. Use case: https://github.com/rack/rack/blob/rack-1.1/test/gemloader.rb Hoe could do with something similar, and that would be well served by the above feature. (Note: the reason is that rack-master and rack-1.1 have different version dependencies) > + Gem.source_index should be hidden as an implementation detail (or removed) and proper public counterparts should be added (eg. Specification.all/active/find/named). Totally, I mentioned to evan the other day that I'd really like to strip this down as much as possible, and maybe even keep the minimum required details in a single marshalled file, in order to massively speed up boot times when loading gems. My spec.files patch made a 75% reduction in ram usage, but we can go a lot further, deserialization is expensive. > + Lots more Gem class methods should be moved to where their responsibilities properly belong. There is so many LoD violations that it isn't funny. > > I'm sure there is a lot more. That's just off the top of my head. > > IMPORTANT: This release is going to be a code contraction month. Feature additions / enhancements should NOT go in master and should NOT be released in 1.7. We can add toys in 1.8. If time is available to do anything, do you want it in topic branches? is it safe to branch from master, or would you prefer them be based off the 1.6 branch? From noreply at rubyforge.org Sat Mar 5 21:34:19 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 5 Mar 2011 21:34:19 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29063 ] Get `undefined class/module YAML::PrivateType` when installing rails3_assist gem in 1.9.2 Message-ID: <20110306023419.51226185838C@rubyforge.org> Bugs item #29063, was opened at 2011-03-06 00:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29063&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcelo Giorgi (marklazz) Assigned to: Nobody (None) Summary: Get `undefined class/module YAML::PrivateType` when installing rails3_assist gem in 1.9.2 Initial Comment: $ gem install rails3_assist ERROR: While executing gem ... (ArgumentError) undefined class/module YAML::PrivateType And the output from `gem env`: $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.5.3 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [i686-linux] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /usr/local/bin/ruby - EXECUTABLE DIRECTORY: /usr/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-linux - GEM PATHS: - /usr/local/lib/ruby/gems/1.9.1 - /home/marcelo/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org/", "http://gems.github.com", "http://gemcutter.org"] - "install" => "--no-rdoc --no-ri" - "update" => "--no-rdoc --no-ri" - REMOTE SOURCES: - http://rubygems.org/ - http://gems.github.com - http://gemcutter.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29063&group_id=126 From christian.oloff at googlemail.com Fri Mar 4 10:15:23 2011 From: christian.oloff at googlemail.com (Chris Oloff) Date: Fri, 4 Mar 2011 17:15:23 +0200 Subject: [Rubygems-developers] vanilla 'gem install heroku' fails Message-ID: I get an error when trying to install latest version of the heroku gem by 'gem install heroku', ddollar looked into it already, see https://github.com/heroku/heroku/issues#issue/78, ddoller finally pointed me here. Any ideas? Chris From noreply at rubyforge.org Mon Mar 7 03:51:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 03:51:29 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110307085129.62BFC167805B@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 19:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x Status: Open Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Eric Hodel (drbrain) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- Comment By: Dalibor Filus (noice) Date: 2011-03-07 08:51 Message: I can confirm this too on OS X Snow Leopard: noice-macbook% cap deploy /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) noice-macbook% gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/daliborfilus/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ noice-macbook% gem -v 1.6.1 noice-macbook% gem list capi *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) capistrano-ext (1.2.1) noice-macbook% gem list net-ssh *** LOCAL GEMS *** net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.0) Tried to remove new versions of net-ssh, reinstalling old capistrano, removing new versions, installing just new versions... But I can't remove old net-ssh because of dependency issues, etc... ---------------------------------------------------------------------- Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 10:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 23:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Mon Mar 7 07:04:34 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 07:04:34 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110307120434.DDFBE1858346@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 13:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: None Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Nobody (None) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Mon Mar 7 17:43:54 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 17:43:54 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110307224354.918BC1858387@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 04:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open >Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) >Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-07 14:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Mon Mar 7 17:47:04 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 17:47:04 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110307224704.74F8C167805B@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 13:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- >Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-07 23:47 Message: it should be on http://gems.github.com ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 23:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Mon Mar 7 18:35:49 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 18:35:49 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110307233549.BE21F167805B@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 19:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x Status: Open Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Eric Hodel (drbrain) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2011-03-07 23:35 Message: Looks like the new activation code is broken for some normal cases. https://gist.github.com/d316ea3fc642dbaca107 should fix it, but I haven't written tests yet. ---------------------------------------------------------------------- Comment By: Dalibor Filus (noice) Date: 2011-03-07 08:51 Message: I can confirm this too on OS X Snow Leopard: noice-macbook% cap deploy /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) noice-macbook% gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/daliborfilus/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ noice-macbook% gem -v 1.6.1 noice-macbook% gem list capi *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) capistrano-ext (1.2.1) noice-macbook% gem list net-ssh *** LOCAL GEMS *** net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.0) Tried to remove new versions of net-ssh, reinstalling old capistrano, removing new versions, installing just new versions... But I can't remove old net-ssh because of dependency issues, etc... ---------------------------------------------------------------------- Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 10:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 23:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Mon Mar 7 19:12:37 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 19:12:37 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110308001237.7C88A167805B@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 11:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x Status: Open Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) >Assigned to: Ryan Davis (zenspider) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-07 16:12 Message: I have an exact repro and am looking into this now. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2011-03-07 15:35 Message: Looks like the new activation code is broken for some normal cases. https://gist.github.com/d316ea3fc642dbaca107 should fix it, but I haven't written tests yet. ---------------------------------------------------------------------- Comment By: Dalibor Filus (noice) Date: 2011-03-07 00:51 Message: I can confirm this too on OS X Snow Leopard: noice-macbook% cap deploy /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) noice-macbook% gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/daliborfilus/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ noice-macbook% gem -v 1.6.1 noice-macbook% gem list capi *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) capistrano-ext (1.2.1) noice-macbook% gem list net-ssh *** LOCAL GEMS *** net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.0) Tried to remove new versions of net-ssh, reinstalling old capistrano, removing new versions, installing just new versions... But I can't remove old net-ssh because of dependency issues, etc... ---------------------------------------------------------------------- Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 02:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 15:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Mon Mar 7 19:55:26 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 19:55:26 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29069 ] When repackaging gems, `gzip data.tar' yields bad gem file Message-ID: <20110308005527.0E150167805B@rubyforge.org> Bugs item #29069, was opened at 2011-03-07 16:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: None Priority: 3 Submitted By: Jos Backus (josb) Assigned to: Nobody (None) Summary: When repackaging gems, `gzip data.tar' yields bad gem file Initial Comment: In the example below, gzip data.tar creates a broken gem file. One has to use gzip < data.tar > data.tar.gz instead. Is this an issue with zlib or how Rubygems uses zlib? /tmp% mkdir am /tmp% cd am /tmp/am% tar xf /home/josb/.rvm/gems/ruby-1.9.2-head/cache/amalgalite-1.0.0.gem tar: metadata.gz: implausibly old time stamp 1969-12-31 16:00:00 /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348246 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip data.tar /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem ERROR: While executing gem ... (Zlib::DataError) invalid code lengths set /tmp/am% ls -l total 2656 -rw-r--r-- 1 josb wheel 1361920 Mar 7 13:45 amalgalite-1.0.0.gem -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% rm amalgalite-1.0.0.gem /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip < data.tar > data.tar.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem Building native extensions. This could take a while... Successfully installed amalgalite-1.0.0 1 gem installed Installing ri documentation for amalgalite-1.0.0... Building YARD (yri) index for amalgalite-1.0.0... Installing RDoc documentation for amalgalite-1.0.0... /tmp/am% ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 From noreply at rubyforge.org Mon Mar 7 20:16:24 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 20:16:24 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110308011624.A82181858385@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 11:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x Status: Open Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Ryan Davis (zenspider) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-07 17:16 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 16:12 Message: I have an exact repro and am looking into this now. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2011-03-07 15:35 Message: Looks like the new activation code is broken for some normal cases. https://gist.github.com/d316ea3fc642dbaca107 should fix it, but I haven't written tests yet. ---------------------------------------------------------------------- Comment By: Dalibor Filus (noice) Date: 2011-03-07 00:51 Message: I can confirm this too on OS X Snow Leopard: noice-macbook% cap deploy /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) noice-macbook% gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/daliborfilus/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ noice-macbook% gem -v 1.6.1 noice-macbook% gem list capi *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) capistrano-ext (1.2.1) noice-macbook% gem list net-ssh *** LOCAL GEMS *** net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.0) Tried to remove new versions of net-ssh, reinstalling old capistrano, removing new versions, installing just new versions... But I can't remove old net-ssh because of dependency issues, etc... ---------------------------------------------------------------------- Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 02:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 15:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Mon Mar 7 20:44:26 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 20:44:26 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110308014426.D1A60167805B@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 11:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x Status: Open Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Ryan Davis (zenspider) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-07 17:44 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 17:16 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 16:12 Message: I have an exact repro and am looking into this now. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2011-03-07 15:35 Message: Looks like the new activation code is broken for some normal cases. https://gist.github.com/d316ea3fc642dbaca107 should fix it, but I haven't written tests yet. ---------------------------------------------------------------------- Comment By: Dalibor Filus (noice) Date: 2011-03-07 00:51 Message: I can confirm this too on OS X Snow Leopard: noice-macbook% cap deploy /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) noice-macbook% gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/daliborfilus/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ noice-macbook% gem -v 1.6.1 noice-macbook% gem list capi *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) capistrano-ext (1.2.1) noice-macbook% gem list net-ssh *** LOCAL GEMS *** net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.0) Tried to remove new versions of net-ssh, reinstalling old capistrano, removing new versions, installing just new versions... But I can't remove old net-ssh because of dependency issues, etc... ---------------------------------------------------------------------- Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 02:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 15:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Mon Mar 7 20:50:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 20:50:29 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110308015029.C85AB1858379@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 11:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Ryan Davis (zenspider) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-07 17:50 Message: doh. sorry about the dupe. I have a fix that just went up and I've verified that it works against your exact gemset. Feel free to install from git master to get around this problem until we release 1.6.2 (which won't be long--so feel free to wait too). ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 17:44 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 17:16 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 16:12 Message: I have an exact repro and am looking into this now. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2011-03-07 15:35 Message: Looks like the new activation code is broken for some normal cases. https://gist.github.com/d316ea3fc642dbaca107 should fix it, but I haven't written tests yet. ---------------------------------------------------------------------- Comment By: Dalibor Filus (noice) Date: 2011-03-07 00:51 Message: I can confirm this too on OS X Snow Leopard: noice-macbook% cap deploy /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) noice-macbook% gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/daliborfilus/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ noice-macbook% gem -v 1.6.1 noice-macbook% gem list capi *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) capistrano-ext (1.2.1) noice-macbook% gem list net-ssh *** LOCAL GEMS *** net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.0) Tried to remove new versions of net-ssh, reinstalling old capistrano, removing new versions, installing just new versions... But I can't remove old net-ssh because of dependency issues, etc... ---------------------------------------------------------------------- Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 02:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 15:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Mon Mar 7 20:52:31 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 20:52:31 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29059 ] 1.6.1 doesn't update prerelease gems Message-ID: <20110308015231.C98E01858379@rubyforge.org> Bugs item #29059, was opened at 2011-03-04 07:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29059&group_id=126 Category: `gem` commands (other) Group: v1.6.x Status: Open Resolution: None Priority: 3 Submitted By: Jon Forums (jonforums) >Assigned to: Eric Hodel (drbrain) Summary: 1.6.1 doesn't update prerelease gems Initial Comment: Is this use case supported? C:\Users\Jon>gem list eventmachine *** LOCAL GEMS *** eventmachine (1.0.0.beta.2 x86-mingw32) C:\Users\Jon>gem list eventmachine -r --pre *** REMOTE GEMS *** eventmachine (1.0.0.beta.3 ruby java java x86-mingw32 x86-mingw32 x86-mswin32-60 x86-mswin32-60, 1.0.0.beta.2 ruby java java x86-mingw32 x86-mingw32 x86-mswin32-60 x86-mswin32-60, 1.0.0.beta.1 ruby java java) C:\Users\Jon>gem update eventmachine --pre Updating installed gems Nothing to update C:\Users\Jon>gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.9.3 (2011-03-04 patchlevel -1) [i386-mingw32] - INSTALLATION DIRECTORY: C:/ruby19trunk/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: C:/ruby19trunk/bin/ruby.exe - EXECUTABLE DIRECTORY: C:/ruby19trunk/bin - RUBYGEMS PLATFORMS: - ruby - x86-mingw32 - GEM PATHS: - C:/ruby19trunk/lib/ruby/gems/1.9.1 - C:/Users/Jon/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org", "http://gemcutter.org"] - "gem" => "--no-ri --no-rdoc" - REMOTE SOURCES: - http://rubygems.org - http://gemcutter.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29059&group_id=126 From noreply at rubyforge.org Mon Mar 7 20:52:43 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 20:52:43 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29063 ] Get `undefined class/module YAML::PrivateType` when installing rails3_assist gem in 1.9.2 Message-ID: <20110308015243.442FB1858379@rubyforge.org> Bugs item #29063, was opened at 2011-03-05 18:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29063&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Marcelo Giorgi (marklazz) >Assigned to: Ryan Davis (zenspider) Summary: Get `undefined class/module YAML::PrivateType` when installing rails3_assist gem in 1.9.2 Initial Comment: $ gem install rails3_assist ERROR: While executing gem ... (ArgumentError) undefined class/module YAML::PrivateType And the output from `gem env`: $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.5.3 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [i686-linux] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /usr/local/bin/ruby - EXECUTABLE DIRECTORY: /usr/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-linux - GEM PATHS: - /usr/local/lib/ruby/gems/1.9.1 - /home/marcelo/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org/", "http://gems.github.com", "http://gemcutter.org"] - "install" => "--no-rdoc --no-ri" - "update" => "--no-rdoc --no-ri" - REMOTE SOURCES: - http://rubygems.org/ - http://gems.github.com - http://gemcutter.org ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29063&group_id=126 From noreply at rubyforge.org Mon Mar 7 21:01:58 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 21:01:58 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29063 ] Get `undefined class/module YAML::PrivateType` when installing rails3_assist gem in 1.9.2 Message-ID: <20110308020202.D3F731858379@rubyforge.org> Bugs item #29063, was opened at 2011-03-05 18:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29063&group_id=126 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Marcelo Giorgi (marklazz) Assigned to: Ryan Davis (zenspider) Summary: Get `undefined class/module YAML::PrivateType` when installing rails3_assist gem in 1.9.2 Initial Comment: $ gem install rails3_assist ERROR: While executing gem ... (ArgumentError) undefined class/module YAML::PrivateType And the output from `gem env`: $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.5.3 - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [i686-linux] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: /usr/local/bin/ruby - EXECUTABLE DIRECTORY: /usr/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-linux - GEM PATHS: - /usr/local/lib/ruby/gems/1.9.1 - /home/marcelo/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://rubygems.org/", "http://gems.github.com", "http://gemcutter.org"] - "install" => "--no-rdoc --no-ri" - "update" => "--no-rdoc --no-ri" - REMOTE SOURCES: - http://rubygems.org/ - http://gems.github.com - http://gemcutter.org ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-07 18:01 Message: Looks like the gem was rebuilt (in the index). I can't reproduce this in 1.5.3 or 1.6.1. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29063&group_id=126 From noreply at rubyforge.org Mon Mar 7 21:08:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 21:08:27 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29069 ] When repackaging gems, `gzip data.tar' yields bad gem file Message-ID: <20110308020827.3C7DE1858379@rubyforge.org> Bugs item #29069, was opened at 2011-03-07 16:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 Category: `gem install` command Group: v1.6.x >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Jos Backus (josb) Assigned to: Nobody (None) Summary: When repackaging gems, `gzip data.tar' yields bad gem file Initial Comment: In the example below, gzip data.tar creates a broken gem file. One has to use gzip < data.tar > data.tar.gz instead. Is this an issue with zlib or how Rubygems uses zlib? /tmp% mkdir am /tmp% cd am /tmp/am% tar xf /home/josb/.rvm/gems/ruby-1.9.2-head/cache/amalgalite-1.0.0.gem tar: metadata.gz: implausibly old time stamp 1969-12-31 16:00:00 /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348246 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip data.tar /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem ERROR: While executing gem ... (Zlib::DataError) invalid code lengths set /tmp/am% ls -l total 2656 -rw-r--r-- 1 josb wheel 1361920 Mar 7 13:45 amalgalite-1.0.0.gem -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% rm amalgalite-1.0.0.gem /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip < data.tar > data.tar.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem Building native extensions. This could take a while... Successfully installed amalgalite-1.0.0 1 gem installed Installing ri documentation for amalgalite-1.0.0... Building YARD (yri) index for amalgalite-1.0.0... Installing RDoc documentation for amalgalite-1.0.0... /tmp/am% ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-07 18:08 Message: This isn't a supported usecase. `gzip` != Zlib::GzipWriter. Use `gem package`. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 From noreply at rubyforge.org Mon Mar 7 22:00:45 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 22:00:45 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29069 ] When repackaging gems, `gzip data.tar' yields bad gem file Message-ID: <20110308030045.3A34B1858385@rubyforge.org> Bugs item #29069, was opened at 2011-03-07 16:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 Category: `gem install` command Group: v1.6.x Status: Closed Resolution: Rejected Priority: 3 Submitted By: Jos Backus (josb) Assigned to: Nobody (None) Summary: When repackaging gems, `gzip data.tar' yields bad gem file Initial Comment: In the example below, gzip data.tar creates a broken gem file. One has to use gzip < data.tar > data.tar.gz instead. Is this an issue with zlib or how Rubygems uses zlib? /tmp% mkdir am /tmp% cd am /tmp/am% tar xf /home/josb/.rvm/gems/ruby-1.9.2-head/cache/amalgalite-1.0.0.gem tar: metadata.gz: implausibly old time stamp 1969-12-31 16:00:00 /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348246 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip data.tar /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem ERROR: While executing gem ... (Zlib::DataError) invalid code lengths set /tmp/am% ls -l total 2656 -rw-r--r-- 1 josb wheel 1361920 Mar 7 13:45 amalgalite-1.0.0.gem -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% rm amalgalite-1.0.0.gem /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip < data.tar > data.tar.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem Building native extensions. This could take a while... Successfully installed amalgalite-1.0.0 1 gem installed Installing ri documentation for amalgalite-1.0.0... Building YARD (yri) index for amalgalite-1.0.0... Installing RDoc documentation for amalgalite-1.0.0... /tmp/am% ---------------------------------------------------------------------- >Comment By: Jos Backus (josb) Date: 2011-03-07 19:00 Message: `gem package` doesn't appear to exist in Rubygems 1.6.1: /tmp/am% gem --version 1.6.1 /tmp/am% gem package ERROR: While executing gem ... (RuntimeError) Unknown command package /tmp/am% ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 18:08 Message: This isn't a supported usecase. `gzip` != Zlib::GzipWriter. Use `gem package`. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 From noreply at rubyforge.org Mon Mar 7 22:44:03 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 22:44:03 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29069 ] When repackaging gems, `gzip data.tar' yields bad gem file Message-ID: <20110308034403.CD9F8167805B@rubyforge.org> Bugs item #29069, was opened at 2011-03-07 16:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 Category: `gem install` command Group: v1.6.x Status: Closed Resolution: Rejected Priority: 3 Submitted By: Jos Backus (josb) Assigned to: Nobody (None) Summary: When repackaging gems, `gzip data.tar' yields bad gem file Initial Comment: In the example below, gzip data.tar creates a broken gem file. One has to use gzip < data.tar > data.tar.gz instead. Is this an issue with zlib or how Rubygems uses zlib? /tmp% mkdir am /tmp% cd am /tmp/am% tar xf /home/josb/.rvm/gems/ruby-1.9.2-head/cache/amalgalite-1.0.0.gem tar: metadata.gz: implausibly old time stamp 1969-12-31 16:00:00 /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348246 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip data.tar /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem ERROR: While executing gem ... (Zlib::DataError) invalid code lengths set /tmp/am% ls -l total 2656 -rw-r--r-- 1 josb wheel 1361920 Mar 7 13:45 amalgalite-1.0.0.gem -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% rm amalgalite-1.0.0.gem /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip < data.tar > data.tar.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem Building native extensions. This could take a while... Successfully installed amalgalite-1.0.0 1 gem installed Installing ri documentation for amalgalite-1.0.0... Building YARD (yri) index for amalgalite-1.0.0... Installing RDoc documentation for amalgalite-1.0.0... /tmp/am% ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-07 19:44 Message: DOH. sorry. I meant gem build. I was using the hoe/rake task name by muscle memory. ---------------------------------------------------------------------- Comment By: Jos Backus (josb) Date: 2011-03-07 19:00 Message: `gem package` doesn't appear to exist in Rubygems 1.6.1: /tmp/am% gem --version 1.6.1 /tmp/am% gem package ERROR: While executing gem ... (RuntimeError) Unknown command package /tmp/am% ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 18:08 Message: This isn't a supported usecase. `gzip` != Zlib::GzipWriter. Use `gem package`. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 From noreply at rubyforge.org Mon Mar 7 23:44:26 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 7 Mar 2011 23:44:26 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29069 ] When repackaging gems, `gzip data.tar' yields bad gem file Message-ID: <20110308044426.BD479185838A@rubyforge.org> Bugs item #29069, was opened at 2011-03-07 16:55 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 Category: `gem install` command Group: v1.6.x Status: Closed Resolution: Rejected Priority: 3 Submitted By: Jos Backus (josb) Assigned to: Nobody (None) Summary: When repackaging gems, `gzip data.tar' yields bad gem file Initial Comment: In the example below, gzip data.tar creates a broken gem file. One has to use gzip < data.tar > data.tar.gz instead. Is this an issue with zlib or how Rubygems uses zlib? /tmp% mkdir am /tmp% cd am /tmp/am% tar xf /home/josb/.rvm/gems/ruby-1.9.2-head/cache/amalgalite-1.0.0.gem tar: metadata.gz: implausibly old time stamp 1969-12-31 16:00:00 /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348246 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip data.tar /tmp/am% ls -l total 1324 -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem ERROR: While executing gem ... (Zlib::DataError) invalid code lengths set /tmp/am% ls -l total 2656 -rw-r--r-- 1 josb wheel 1361920 Mar 7 13:45 amalgalite-1.0.0.gem -rw-r--r-- 1 josb wheel 1348255 Mar 7 13:34 data.tar.gz -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% rm amalgalite-1.0.0.gem /tmp/am% gunzip data.tar.gz /tmp/am% ls -l total 5084 -rw-r--r-- 1 josb wheel 5198336 Mar 7 13:34 data.tar -rw-r--r-- 1 josb wheel 1726 Dec 31 1969 metadata.gz /tmp/am% gzip < data.tar > data.tar.gz /tmp/am% tar cvf amalgalite-1.0.0.gem data.tar.gz metadata.gz data.tar.gz metadata.gz /tmp/am% gem install $PWD/amalgalite-1.0.0.gem Building native extensions. This could take a while... Successfully installed amalgalite-1.0.0 1 gem installed Installing ri documentation for amalgalite-1.0.0... Building YARD (yri) index for amalgalite-1.0.0... Installing RDoc documentation for amalgalite-1.0.0... /tmp/am% ---------------------------------------------------------------------- >Comment By: Jos Backus (josb) Date: 2011-03-07 20:44 Message: Got it. Amalgalite isn't 'gem build'ing out of the box but I'll take that up with its author. Thanks, Ryan. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 19:44 Message: DOH. sorry. I meant gem build. I was using the hoe/rake task name by muscle memory. ---------------------------------------------------------------------- Comment By: Jos Backus (josb) Date: 2011-03-07 19:00 Message: `gem package` doesn't appear to exist in Rubygems 1.6.1: /tmp/am% gem --version 1.6.1 /tmp/am% gem package ERROR: While executing gem ... (RuntimeError) Unknown command package /tmp/am% ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 18:08 Message: This isn't a supported usecase. `gzip` != Zlib::GzipWriter. Use `gem package`. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29069&group_id=126 From noreply at rubyforge.org Tue Mar 8 02:11:13 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 Mar 2011 02:11:13 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29070 ] MRI test-all reports a failure on Windows Message-ID: <20110308071113.8836B1858367@rubyforge.org> Bugs item #29070, was opened at 2011-03-08 16:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Usaku Nakamura (usa) Assigned to: Nobody (None) Summary: MRI test-all reports a failure on Windows Initial Comment: see r31062 on MRI. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 From noreply at rubyforge.org Tue Mar 8 05:41:40 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 Mar 2011 05:41:40 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29070 ] MRI test-all reports a failure on Windows Message-ID: <20110308104140.985241858376@rubyforge.org> Bugs item #29070, was opened at 2011-03-07 23:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Usaku Nakamura (usa) >Assigned to: Luis Lavena (luislavena) Summary: MRI test-all reports a failure on Windows Initial Comment: see r31062 on MRI. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-08 02:41 Message: I default to reject because the change was made in ruby-trunk in a clearly marked file. So... Your call Luis... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 From noreply at rubyforge.org Tue Mar 8 07:40:31 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 Mar 2011 07:40:31 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29070 ] MRI test-all reports a failure on Windows Message-ID: <20110308124033.2DDBD1858376@rubyforge.org> Bugs item #29070, was opened at 2011-03-08 04:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Usaku Nakamura (usa) >Assigned to: Ryan Davis (zenspider) Summary: MRI test-all reports a failure on Windows Initial Comment: see r31062 on MRI. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-03-08 09:40 Message: Hello, This was already fixed in RubyGems master prior the release of 1.6.0: https://github.com/rubygems/rubygems/commit/53df9ed9364ae9130ffbed92cd28f9fb16140802 And the rationale was simple: cache_dir expand_path, which will contain ':' for Windows drive letter at the beginning of it, but not as part of the cache dir. So decided to extract .dir from it before doing the comparison. The change done in trunk should be reverted with this change. When RubyGems will be merged back? Dunno if I should mark this as out of date or closed, so assigning back to you Ryan to decide. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-08 07:41 Message: I default to reject because the change was made in ruby-trunk in a clearly marked file. So... Your call Luis... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 From noreply at rubyforge.org Tue Mar 8 16:38:13 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 8 Mar 2011 16:38:13 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29070 ] MRI test-all reports a failure on Windows Message-ID: <20110308213813.7CBFA185834E@rubyforge.org> Bugs item #29070, was opened at 2011-03-07 23:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Usaku Nakamura (usa) >Assigned to: Luis Lavena (luislavena) Summary: MRI test-all reports a failure on Windows Initial Comment: see r31062 on MRI. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-08 13:38 Message: Luis, we pulled in 1.6.0 (and maybe 1.6.1?) into trunk... so I think something else might be going on. Can you look into it? We're about to do 1.6.2 so I'll double check that we're completely synced up when we release. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-08 04:40 Message: Hello, This was already fixed in RubyGems master prior the release of 1.6.0: https://github.com/rubygems/rubygems/commit/53df9ed9364ae9130ffbed92cd28f9fb16140802 And the rationale was simple: cache_dir expand_path, which will contain ':' for Windows drive letter at the beginning of it, but not as part of the cache dir. So decided to extract .dir from it before doing the comparison. The change done in trunk should be reverted with this change. When RubyGems will be merged back? Dunno if I should mark this as out of date or closed, so assigning back to you Ryan to decide. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-08 02:41 Message: I default to reject because the change was made in ruby-trunk in a clearly marked file. So... Your call Luis... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 From drbrain at segment7.net Wed Mar 9 00:58:13 2011 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 8 Mar 2011 21:58:13 -0800 Subject: [Rubygems-developers] [ANN] rubygems-update 1.6.2 Released Message-ID: <52BE49A1-D3D2-488D-9097-34204A684BBD@segment7.net> rubygems-update version 1.6.2 has been released! * * * * * RubyGems is a package management framework for Ruby. This gem is an update for the RubyGems software. You must have an installation of RubyGems before this update can be applied. See Gem for information on RubyGems (or `ri Gem`) To upgrade to the latest RubyGems, run: $ gem update --system # you might need to be an administrator or root See UPGRADING.rdoc for more details and alternative instructions. ----- If you don't have RubyGems installed, your can still do it manually: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb # you may need admin/root privilege For more details and other options, see: ruby setup.rb --help Changes: ### 1.6.2 / 2011-03-08 Bug Fixes: * require of an activated gem could cause activation conflicts. Fixes Bug #29056 by Dave Verwer. * `gem outdated` now works with up-to-date prerelease gems. From noreply at rubyforge.org Wed Mar 9 01:13:12 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 Mar 2011 01:13:12 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110309061312.6A8D41858367@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 14:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x Status: Closed Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Ryan Davis (zenspider) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- Comment By: Brendan Stennett (brendan6) Date: 2011-03-09 01:13 Message: Same issue happened to me: Solved on Mac OSX with: $ sudo gem uninstall -v '1.6.1' rubygems-update $ sudo gem update --system $ sudo gem update Everything was working again. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 20:50 Message: doh. sorry about the dupe. I have a fix that just went up and I've verified that it works against your exact gemset. Feel free to install from git master to get around this problem until we release 1.6.2 (which won't be long--so feel free to wait too). ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 20:44 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 20:16 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 19:12 Message: I have an exact repro and am looking into this now. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2011-03-07 18:35 Message: Looks like the new activation code is broken for some normal cases. https://gist.github.com/d316ea3fc642dbaca107 should fix it, but I haven't written tests yet. ---------------------------------------------------------------------- Comment By: Dalibor Filus (noice) Date: 2011-03-07 03:51 Message: I can confirm this too on OS X Snow Leopard: noice-macbook% cap deploy /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) noice-macbook% gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/daliborfilus/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ noice-macbook% gem -v 1.6.1 noice-macbook% gem list capi *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) capistrano-ext (1.2.1) noice-macbook% gem list net-ssh *** LOCAL GEMS *** net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.0) Tried to remove new versions of net-ssh, reinstalling old capistrano, removing new versions, installing just new versions... But I can't remove old net-ssh because of dependency issues, etc... ---------------------------------------------------------------------- Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 05:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 18:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Wed Mar 9 02:21:56 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 Mar 2011 02:21:56 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29056 ] RubyGems 1.6.0 seems to break Capistrano Message-ID: <20110309072156.D61071858367@rubyforge.org> Bugs item #29056, was opened at 2011-03-03 19:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 Category: other Group: v1.6.x Status: Closed Resolution: Accepted Priority: 3 Submitted By: Dave Verwer (daveverwer) Assigned to: Ryan Davis (zenspider) Summary: RubyGems 1.6.0 seems to break Capistrano Initial Comment: This is going to be a fairly vague bug report and I apologise for that in advance, feel free to ignore if you can not reproduce. I did a rubygems update and got 1.6.0, after that every time I ran cap, even something as innocuous as "cap -V" in a directory with no capfile in it I got the following error message: /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) installing RubyGems 1.5.0 again fixes the problem. Capistrano versions installed are: capistrano (2.5.19, 2.5.2) Net-SSH versions are: net-ssh (2.1.3, 2.0.4, 1.1.4) ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2011-03-09 07:21 Message: Great, thanks Ryan. Yep, I didn't have time at the time of the patch to do the test setup, sorry about that (that's why i didn't just drop a branch). I had looked at the code and wondered why we weren't following the old code path of try gem_original_require first. Thanks for fixing it quick! ---------------------------------------------------------------------- Comment By: Brendan Stennett (brendan6) Date: 2011-03-09 06:13 Message: Same issue happened to me: Solved on Mac OSX with: $ sudo gem uninstall -v '1.6.1' rubygems-update $ sudo gem update --system $ sudo gem update Everything was working again. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-08 01:50 Message: doh. sorry about the dupe. I have a fix that just went up and I've verified that it works against your exact gemset. Feel free to install from git master to get around this problem until we release 1.6.2 (which won't be long--so feel free to wait too). ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-08 01:44 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-08 01:16 Message: I don't like that patch primarily because it doesn't have tests but also because it bypasses another usecase we need to support (that we don't have tests for, ironically). Specifically, we need to try gem searching and activation BEFORE we check load path so that gems in stdlib can be upgraded and used. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-08 00:12 Message: I have an exact repro and am looking into this now. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2011-03-07 23:35 Message: Looks like the new activation code is broken for some normal cases. https://gist.github.com/d316ea3fc642dbaca107 should fix it, but I haven't written tests yet. ---------------------------------------------------------------------- Comment By: Dalibor Filus (noice) Date: 2011-03-07 08:51 Message: I can confirm this too on OS X Snow Leopard: noice-macbook% cap deploy /Library/Ruby/Site/1.8/rubygems.rb:267:in `activate': can't activate net-ssh (= 2.0.4) for [], already activated net-ssh-2.1.3 for [] (Gem::LoadError) noice-macbook% gem env RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-10 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/daliborfilus/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ noice-macbook% gem -v 1.6.1 noice-macbook% gem list capi *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) capistrano-ext (1.2.1) noice-macbook% gem list net-ssh *** LOCAL GEMS *** net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.0) Tried to remove new versions of net-ssh, reinstalling old capistrano, removing new versions, installing just new versions... But I can't remove old net-ssh because of dependency issues, etc... ---------------------------------------------------------------------- Comment By: Dave Verwer (daveverwer) Date: 2011-03-04 10:08 Message: Full gem list *** LOCAL GEMS *** abstract (1.0.0) actionmailer (3.0.5, 3.0.3, 2.3.5, 1.3.6) actionpack (3.0.5, 3.0.3, 2.3.5, 1.13.6) actionwebservice (1.2.6) activemodel (3.0.5, 3.0.3) activerecord (3.0.5, 3.0.3, 2.3.5, 1.15.6) activeresource (3.0.5, 3.0.3, 2.3.5) activesupport (3.0.5, 3.0.3, 2.3.5, 1.4.4) acts_as_ferret (0.5.2, 0.4.3) addressable (2.2.4) arel (2.0.9, 2.0.6) builder (3.0.0, 2.1.2) bundler (1.0.10, 1.0.7) capistrano (2.5.19, 2.5.2) cgi_multipart_eof_fix (2.5.0) classifier (1.3.3) configuration (1.2.0) daemons (1.1.0, 1.0.10) data_objects (0.10.3) datamapper (1.0.2) directory_watcher (1.3.2) dm-aggregates (1.0.2) dm-constraints (1.0.2) dm-core (1.0.2) dm-do-adapter (1.0.2) dm-migrations (1.0.2) dm-serializer (1.0.2) dm-sqlite-adapter (1.0.2) dm-timestamps (1.0.2) dm-transactions (1.0.2) dm-types (1.0.2) dm-validations (1.0.2) dnssd (1.4, 0.6.0) do_sqlite3 (0.10.3) erubis (2.6.6) extlib (0.9.15) faraday (0.5.7) faraday_middleware (0.3.2) fast-stemmer (1.0.0) fastercsv (1.5.4) fastthread (1.0.7, 1.0.1) fcgi (0.8.8, 0.8.7) ferret (0.11.6) gem_plugin (0.2.3) github (0.6.0, 0.4.5) haml (3.0.25) hashie (1.0.0) highline (1.6.1, 1.5.2, 1.5.0) hpricot (0.8.4, 0.8.3, 0.6.164) i18n (0.5.0) jekyll (0.10.0) jk-ferret (0.11.8.3, 0.11.8.2) json (1.5.1, 1.4.6) json_pure (1.5.1) launchy (0.4.0, 0.3.7) libxml-ruby (1.1.4, 1.1.2) liquid (2.2.2) mail (2.2.15, 2.2.14, 2.2.12) maruku (0.6.0) mime-types (1.16) mongrel (1.1.5) multi_json (0.0.5) multi_xml (0.2.1) multipart-post (1.1.0) needle (1.3.0) net-scp (1.0.4, 1.0.1) net-sftp (2.0.5, 2.0.1, 1.1.1) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1, 1.0.0) polyglot (0.3.1) rack (1.2.1, 1.0.1) rack-mount (0.6.13) rack-test (0.5.7, 0.5.6) rails (3.0.5, 3.0.3, 2.3.5, 1.2.6) railties (3.0.5, 3.0.3) rake (0.8.7, 0.8.3) rdiscount (1.6.8, 1.6.5) RedCloth (4.2.7, 4.2.3, 4.1.1) ruby-openid (2.1.8, 2.1.2) ruby-yadis (0.3.4) rubygems-update (1.6.0, 1.5.0, 1.4.1, 1.3.7) rubynode (0.1.5) simple_oauth (0.1.4) sqlite3 (1.3.3) sqlite3-ruby (1.3.3, 1.3.2, 1.2.4) stringex (1.2.0, 1.1.0) syntax (1.0.0) termios (0.9.4) text-format (1.0.0) text-hyphen (1.0.2, 1.0.0) thor (0.14.6) treetop (1.4.9) twitter (1.1.2) tzinfo (0.3.24, 0.3.23) uuidtools (2.1.2) xmpp4r (0.5, 0.4) ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-03 23:14 Message: Can I see a full `gem list`? I can't reproduce with just the gems you've listed: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems gem list *** LOCAL GEMS *** capistrano (2.5.19, 2.5.2) highline (1.6.1) needle (1.3.0) net-scp (1.0.4) net-sftp (2.0.5) net-ssh (2.1.3, 2.0.4, 1.1.4) net-ssh-gateway (1.0.1) $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ~/tmp/gems/bin/cap -V Capistrano v2.5.19 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29056&group_id=126 From noreply at rubyforge.org Wed Mar 9 19:35:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 Mar 2011 19:35:14 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29070 ] MRI test-all reports a failure on Windows Message-ID: <20110310003514.CF1C6167805D@rubyforge.org> Bugs item #29070, was opened at 2011-03-08 04:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 Category: other Group: None >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Usaku Nakamura (usa) Assigned to: Luis Lavena (luislavena) Summary: MRI test-all reports a failure on Windows Initial Comment: see r31062 on MRI. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-03-09 21:35 Message: Hello, I can confirm this issue is no longer present in trunk, was fixed by RubyGems 1.6.0 and now is merged in trunk. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-08 18:38 Message: Luis, we pulled in 1.6.0 (and maybe 1.6.1?) into trunk... so I think something else might be going on. Can you look into it? We're about to do 1.6.2 so I'll double check that we're completely synced up when we release. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-08 09:40 Message: Hello, This was already fixed in RubyGems master prior the release of 1.6.0: https://github.com/rubygems/rubygems/commit/53df9ed9364ae9130ffbed92cd28f9fb16140802 And the rationale was simple: cache_dir expand_path, which will contain ':' for Windows drive letter at the beginning of it, but not as part of the cache dir. So decided to extract .dir from it before doing the comparison. The change done in trunk should be reverted with this change. When RubyGems will be merged back? Dunno if I should mark this as out of date or closed, so assigning back to you Ryan to decide. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-08 07:41 Message: I default to reject because the change was made in ruby-trunk in a clearly marked file. So... Your call Luis... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29070&group_id=126 From noreply at rubyforge.org Thu Mar 10 11:44:17 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Mar 2011 11:44:17 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29074 ] Can't upgrade to newer rubygems version with explicit version number Message-ID: <20110310164417.4D4091D780F5@rubyforge.org> Bugs item #29074, was opened at 2011-03-10 17:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Martin Tepper (mgpalmer) Assigned to: Nobody (None) Summary: Can't upgrade to newer rubygems version with explicit version number Initial Comment: Hi everybody ! I've already briefly explained the problem here: http://help.rubygems.org/discussions/problems/514-cant-upgrade-to-newer-rubygems-version-with-explicit-version-number Basically, upgrading rubygems to a specific, higher-than-now version (or the latest version) doesn't work as it is. You can workaround by installing rubygems-update manually, but I think it's quite unobvious why you can't just tell the target version and be done with it. I've poked around in the code and found a solution. Here's my take on it: https://github.com/MGPalmer/rubygems/commit/a1bd03cd597a3a0fc1d13059c582ac7266c34fb8 I haven't really contributed to a project before like this, is there anything else I need to do ? Run tests etc. ? Thanks for all your work on the ruby ecosystem ! Best regards, Martin Tepper ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 From noreply at rubyforge.org Thu Mar 10 16:28:40 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Mar 2011 16:28:40 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110310212840.E7A3C1D780F6@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 08:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- Comment By: An?bal Rojas (anibalrojas) Date: 2011-03-10 17:28 Message: I had the same issue running Ruby Gems 1.6.1 (under RVM). Downgrading to 1.5.2 fixed it. Here are the details of the exception: $ gem install rubyist-aasm -v2.1.1 --no-rdoc --no-ri --backtrace ERROR: While executing gem ... (TypeError) can't dup NilClass /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/bin/gem:25 ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-07 18:47 Message: it should be on http://gems.github.com ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 18:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Thu Mar 10 16:45:15 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Mar 2011 16:45:15 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110310214515.2524D185835A@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 04:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- Comment By: Michael Hutchinson (shinzon) Date: 2011-03-10 13:45 Message: I'm having the same problem running RubyGems 1.6.2 under RVM: ? gem install taf2-curb --backtrace Building native extensions. This could take a while... ERROR: While executing gem ... (TypeError) can't dup NilClass /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `block in initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `initialize_dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `to_ruby_for_cache' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:234:in `write_spec' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:175:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:299:in `block in install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:120:in `block in execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:133:in `process_args' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:103:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:63:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' ---------------------------------------------------------------------- Comment By: An?bal Rojas (anibalrojas) Date: 2011-03-10 13:28 Message: I had the same issue running Ruby Gems 1.6.1 (under RVM). Downgrading to 1.5.2 fixed it. Here are the details of the exception: $ gem install rubyist-aasm -v2.1.1 --no-rdoc --no-ri --backtrace ERROR: While executing gem ... (TypeError) can't dup NilClass /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/bin/gem:25 ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-07 14:47 Message: it should be on http://gems.github.com ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 14:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Thu Mar 10 16:53:41 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Mar 2011 16:53:41 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110310215341.359EE1D780F6@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 13:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- >Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-10 22:53 Message: just changing /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442 line 442 for : instance_variable_set name, other_spec.instance_variable_get(name).dup if other_spec.instance_variable_get(name) fixed the thing for me, and didn't seem to break anything else. hope it helps. Elias ---------------------------------------------------------------------- Comment By: Michael Hutchinson (shinzon) Date: 2011-03-10 22:45 Message: I'm having the same problem running RubyGems 1.6.2 under RVM: ? gem install taf2-curb --backtrace Building native extensions. This could take a while... ERROR: While executing gem ... (TypeError) can't dup NilClass /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `block in initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `initialize_dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `to_ruby_for_cache' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:234:in `write_spec' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:175:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:299:in `block in install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:120:in `block in execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:133:in `process_args' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:103:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:63:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' ---------------------------------------------------------------------- Comment By: An?bal Rojas (anibalrojas) Date: 2011-03-10 22:28 Message: I had the same issue running Ruby Gems 1.6.1 (under RVM). Downgrading to 1.5.2 fixed it. Here are the details of the exception: $ gem install rubyist-aasm -v2.1.1 --no-rdoc --no-ri --backtrace ERROR: While executing gem ... (TypeError) can't dup NilClass /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/bin/gem:25 ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-07 23:47 Message: it should be on http://gems.github.com ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 23:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Thu Mar 10 17:17:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Mar 2011 17:17:50 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29074 ] Can't upgrade to newer rubygems version with explicit version number Message-ID: <20110310221751.0136E185835A@rubyforge.org> Bugs item #29074, was opened at 2011-03-10 08:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Martin Tepper (mgpalmer) Assigned to: Nobody (None) Summary: Can't upgrade to newer rubygems version with explicit version number Initial Comment: Hi everybody ! I've already briefly explained the problem here: http://help.rubygems.org/discussions/problems/514-cant-upgrade-to-newer-rubygems-version-with-explicit-version-number Basically, upgrading rubygems to a specific, higher-than-now version (or the latest version) doesn't work as it is. You can workaround by installing rubygems-update manually, but I think it's quite unobvious why you can't just tell the target version and be done with it. I've poked around in the code and found a solution. Here's my take on it: https://github.com/MGPalmer/rubygems/commit/a1bd03cd597a3a0fc1d13059c582ac7266c34fb8 I haven't really contributed to a project before like this, is there anything else I need to do ? Run tests etc. ? Thanks for all your work on the ruby ecosystem ! Best regards, Martin Tepper ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-10 14:17 Message: I can't reproduce: $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ? $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system --no-rdoc --no-ri Updating rubygems-update Fetching: rubygems-update-1.6.2.gem (100%) Successfully installed rubygems-update-1.6.2 Installing RubyGems 1.6.2 RubyGems 1.6.2 installed Your commit does not have any test changes. I would like to see a failing test first as the update functionality does have tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 From noreply at rubyforge.org Thu Mar 10 17:47:45 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Mar 2011 17:47:45 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110310224745.1B64A3C8033@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 04:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-10 14:47 Message: Soooo... are all these problems coming from gems served off of github? ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-10 13:53 Message: just changing /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442 line 442 for : instance_variable_set name, other_spec.instance_variable_get(name).dup if other_spec.instance_variable_get(name) fixed the thing for me, and didn't seem to break anything else. hope it helps. Elias ---------------------------------------------------------------------- Comment By: Michael Hutchinson (shinzon) Date: 2011-03-10 13:45 Message: I'm having the same problem running RubyGems 1.6.2 under RVM: ? gem install taf2-curb --backtrace Building native extensions. This could take a while... ERROR: While executing gem ... (TypeError) can't dup NilClass /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `block in initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `initialize_dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `to_ruby_for_cache' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:234:in `write_spec' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:175:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:299:in `block in install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:120:in `block in execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:133:in `process_args' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:103:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:63:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' ---------------------------------------------------------------------- Comment By: An?bal Rojas (anibalrojas) Date: 2011-03-10 13:28 Message: I had the same issue running Ruby Gems 1.6.1 (under RVM). Downgrading to 1.5.2 fixed it. Here are the details of the exception: $ gem install rubyist-aasm -v2.1.1 --no-rdoc --no-ri --backtrace ERROR: While executing gem ... (TypeError) can't dup NilClass /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/bin/gem:25 ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-07 14:47 Message: it should be on http://gems.github.com ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 14:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Thu Mar 10 20:23:21 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Mar 2011 20:23:21 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110311012321.94728167815E@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 04:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-10 17:23 Message: This appears to be a bug specific to github. taf2-curb, rubyist-aasm and yfactorial-utility_scopes are all broken gems as they have a licenses field that is not an Array as required by the gem specification. Silently ignoring broken gems is not a safe fix. Please ask the author to repackage the gems properly and publish them on rubygems.org or move to a newer version: taf2-curb on github is 15 months old (latest is 0.7.12) utility_scopes on github is 3 months old (latest is 0.3.1) rubyist-aasm on github is 16 months old (latest is 2.2.0) I have opened an issue with github on these broken gems: http://support.github.com/discussions/site/3134-some-gems-in-gemsgithubcom-are-broken ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-10 14:47 Message: Soooo... are all these problems coming from gems served off of github? ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-10 13:53 Message: just changing /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442 line 442 for : instance_variable_set name, other_spec.instance_variable_get(name).dup if other_spec.instance_variable_get(name) fixed the thing for me, and didn't seem to break anything else. hope it helps. Elias ---------------------------------------------------------------------- Comment By: Michael Hutchinson (shinzon) Date: 2011-03-10 13:45 Message: I'm having the same problem running RubyGems 1.6.2 under RVM: ? gem install taf2-curb --backtrace Building native extensions. This could take a while... ERROR: While executing gem ... (TypeError) can't dup NilClass /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `block in initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `initialize_dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `to_ruby_for_cache' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:234:in `write_spec' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:175:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:299:in `block in install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:120:in `block in execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:133:in `process_args' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:103:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:63:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' ---------------------------------------------------------------------- Comment By: An?bal Rojas (anibalrojas) Date: 2011-03-10 13:28 Message: I had the same issue running Ruby Gems 1.6.1 (under RVM). Downgrading to 1.5.2 fixed it. Here are the details of the exception: $ gem install rubyist-aasm -v2.1.1 --no-rdoc --no-ri --backtrace ERROR: While executing gem ... (TypeError) can't dup NilClass /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/bin/gem:25 ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-07 14:47 Message: it should be on http://gems.github.com ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 14:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Thu Mar 10 20:32:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Mar 2011 20:32:27 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110311013227.2B738185835A@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 04:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-10 17:32 Message: RubyGems now raises a better error when you attempt to install broken gems. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-10 17:23 Message: This appears to be a bug specific to github. taf2-curb, rubyist-aasm and yfactorial-utility_scopes are all broken gems as they have a licenses field that is not an Array as required by the gem specification. Silently ignoring broken gems is not a safe fix. Please ask the author to repackage the gems properly and publish them on rubygems.org or move to a newer version: taf2-curb on github is 15 months old (latest is 0.7.12) utility_scopes on github is 3 months old (latest is 0.3.1) rubyist-aasm on github is 16 months old (latest is 2.2.0) I have opened an issue with github on these broken gems: http://support.github.com/discussions/site/3134-some-gems-in-gemsgithubcom-are-broken ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-10 14:47 Message: Soooo... are all these problems coming from gems served off of github? ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-10 13:53 Message: just changing /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442 line 442 for : instance_variable_set name, other_spec.instance_variable_get(name).dup if other_spec.instance_variable_get(name) fixed the thing for me, and didn't seem to break anything else. hope it helps. Elias ---------------------------------------------------------------------- Comment By: Michael Hutchinson (shinzon) Date: 2011-03-10 13:45 Message: I'm having the same problem running RubyGems 1.6.2 under RVM: ? gem install taf2-curb --backtrace Building native extensions. This could take a while... ERROR: While executing gem ... (TypeError) can't dup NilClass /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `block in initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `initialize_dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `to_ruby_for_cache' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:234:in `write_spec' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:175:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:299:in `block in install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:120:in `block in execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:133:in `process_args' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:103:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:63:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' ---------------------------------------------------------------------- Comment By: An?bal Rojas (anibalrojas) Date: 2011-03-10 13:28 Message: I had the same issue running Ruby Gems 1.6.1 (under RVM). Downgrading to 1.5.2 fixed it. Here are the details of the exception: $ gem install rubyist-aasm -v2.1.1 --no-rdoc --no-ri --backtrace ERROR: While executing gem ... (TypeError) can't dup NilClass /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/bin/gem:25 ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-07 14:47 Message: it should be on http://gems.github.com ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 14:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Fri Mar 11 02:34:32 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 02:34:32 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29074 ] Can't upgrade to newer rubygems version with explicit version number Message-ID: <20110311073432.61ADF185835A@rubyforge.org> Bugs item #29074, was opened at 2011-03-10 17:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Martin Tepper (mgpalmer) Assigned to: Nobody (None) Summary: Can't upgrade to newer rubygems version with explicit version number Initial Comment: Hi everybody ! I've already briefly explained the problem here: http://help.rubygems.org/discussions/problems/514-cant-upgrade-to-newer-rubygems-version-with-explicit-version-number Basically, upgrading rubygems to a specific, higher-than-now version (or the latest version) doesn't work as it is. You can workaround by installing rubygems-update manually, but I think it's quite unobvious why you can't just tell the target version and be done with it. I've poked around in the code and found a solution. Here's my take on it: https://github.com/MGPalmer/rubygems/commit/a1bd03cd597a3a0fc1d13059c582ac7266c34fb8 I haven't really contributed to a project before like this, is there anything else I need to do ? Run tests etc. ? Thanks for all your work on the ruby ecosystem ! Best regards, Martin Tepper ---------------------------------------------------------------------- >Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 08:34 Message: Ah yes. Sorry, it actually only fails when trying to install explicitly the latest online version: $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ... $ sudo gem update --system 1.6.2 --no-rdoc --no-ri Latest version currently installed. Aborting. I'll make a test for that. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-10 23:17 Message: I can't reproduce: $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ? $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system --no-rdoc --no-ri Updating rubygems-update Fetching: rubygems-update-1.6.2.gem (100%) Successfully installed rubygems-update-1.6.2 Installing RubyGems 1.6.2 RubyGems 1.6.2 installed Your commit does not have any test changes. I would like to see a failing test first as the update functionality does have tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 From noreply at rubyforge.org Fri Mar 11 02:36:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 02:36:50 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29067 ] calling .dup on nil while installing a gem Message-ID: <20110311073650.3B787185835A@rubyforge.org> Bugs item #29067, was opened at 2011-03-07 13:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 Category: `gem install` command Group: v1.6.x Status: Closed Resolution: Rejected Priority: 3 Submitted By: Elias Baixas (eliasbaixas) Assigned to: Ryan Davis (zenspider) Summary: calling .dup on nil while installing a gem Initial Comment: sudo gem env: RubyGems Environment: - RUBYGEMS VERSION: 1.6.1 - RUBY VERSION: 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin9] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-9 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/elias/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com", "http://gemcutter.org/"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com - http://gemcutter.org/ sudo gem install --debug yfactorial-utility_scopes ERROR: While executing gem ... (TypeError) can't dup NilClass /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /opt/local/bin/gem:21 ---- from the sources (/opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442) I can see this: 440: self.class.array_attributes.each do |name| 441: name = :"@#{name}" 442: next unless other_ivars.include? name 442: instance_variable_set name, other_spec.instance_variable_get(name).dup 443: end so the trick would be to add an "if other_spec.instance_variable_get(name)" at line 442 (but then the 'name' variable would be unset, instad of nil, well, I'm not sure :P ) Elias ---------------------------------------------------------------------- >Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-11 08:36 Message: Agreed on the assumption that silently ignoring broken gems is not a safe fix :) thanks for your help ! Elias ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-11 02:32 Message: RubyGems now raises a better error when you attempt to install broken gems. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-11 02:23 Message: This appears to be a bug specific to github. taf2-curb, rubyist-aasm and yfactorial-utility_scopes are all broken gems as they have a licenses field that is not an Array as required by the gem specification. Silently ignoring broken gems is not a safe fix. Please ask the author to repackage the gems properly and publish them on rubygems.org or move to a newer version: taf2-curb on github is 15 months old (latest is 0.7.12) utility_scopes on github is 3 months old (latest is 0.3.1) rubyist-aasm on github is 16 months old (latest is 2.2.0) I have opened an issue with github on these broken gems: http://support.github.com/discussions/site/3134-some-gems-in-gemsgithubcom-are-broken ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-10 23:47 Message: Soooo... are all these problems coming from gems served off of github? ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-10 22:53 Message: just changing /opt/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442 line 442 for : instance_variable_set name, other_spec.instance_variable_get(name).dup if other_spec.instance_variable_get(name) fixed the thing for me, and didn't seem to break anything else. hope it helps. Elias ---------------------------------------------------------------------- Comment By: Michael Hutchinson (shinzon) Date: 2011-03-10 22:45 Message: I'm having the same problem running RubyGems 1.6.2 under RVM: ? gem install taf2-curb --backtrace Building native extensions. This could take a while... ERROR: While executing gem ... (TypeError) can't dup NilClass /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:442:in `block in initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:439:in `initialize_copy' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `initialize_dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `dup' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:832:in `to_ruby_for_cache' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:234:in `write_spec' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/installer.rb:175:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:299:in `block in install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:120:in `block in execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `each' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in `execute' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in `invoke' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:133:in `process_args' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:103:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:63:in `run' /usr/local/rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `
' ---------------------------------------------------------------------- Comment By: An?bal Rojas (anibalrojas) Date: 2011-03-10 22:28 Message: I had the same issue running Ruby Gems 1.6.1 (under RVM). Downgrading to 1.5.2 fixed it. Here are the details of the exception: $ gem install rubyist-aasm -v2.1.1 --no-rdoc --no-ri --backtrace ERROR: While executing gem ... (TypeError) can't dup NilClass /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:442:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:439:in `initialize_copy' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `dup' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/specification.rb:832:in `to_ruby_for_cache' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:234:in `write_spec' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/installer.rb:175:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:299:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:270:in `install' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:120:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `each' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:115:in `execute' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command.rb:278:in `invoke' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133:in `process_args' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:103:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:63:in `run' /home/anibal/.rvm/rubies/ruby-1.8.7-p334/bin/gem:25 ---------------------------------------------------------------------- Comment By: Elias Baixas (eliasbaixas) Date: 2011-03-07 23:47 Message: it should be on http://gems.github.com ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-07 23:43 Message: I can't reproduce this: gem install -i xxx --backtrace yfactorial-utility_scopes ERROR: Could not find a valid gem 'yfactorial-utility_scopes' (>= 0) in any repository ERROR: Possible alternatives: utility_scopes ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29067&group_id=126 From noreply at rubyforge.org Fri Mar 11 08:36:43 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 08:36:43 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110311133643.4C6B5185835A@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Fri Mar 11 08:44:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 08:44:27 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110311134427.A46B4185836C@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 10:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-03-11 10:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Fri Mar 11 08:54:19 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 08:54:19 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110311135419.8BC041858378@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Fri Mar 11 10:13:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 10:13:29 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110311151329.678971858367@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 13:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 15:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 13:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 13:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Fri Mar 11 10:46:26 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 10:46:26 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110311154626.704FA1858363@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Fri Mar 11 11:05:25 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 11:05:25 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110311160526.0D3021858363@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 13:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 15:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 15:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 13:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 13:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Fri Mar 11 11:27:03 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 11:27:03 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29074 ] Can't upgrade to newer rubygems version with explicit version number Message-ID: <20110311162703.3EA76185836B@rubyforge.org> Bugs item #29074, was opened at 2011-03-10 17:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Martin Tepper (mgpalmer) Assigned to: Nobody (None) Summary: Can't upgrade to newer rubygems version with explicit version number Initial Comment: Hi everybody ! I've already briefly explained the problem here: http://help.rubygems.org/discussions/problems/514-cant-upgrade-to-newer-rubygems-version-with-explicit-version-number Basically, upgrading rubygems to a specific, higher-than-now version (or the latest version) doesn't work as it is. You can workaround by installing rubygems-update manually, but I think it's quite unobvious why you can't just tell the target version and be done with it. I've poked around in the code and found a solution. Here's my take on it: https://github.com/MGPalmer/rubygems/commit/a1bd03cd597a3a0fc1d13059c582ac7266c34fb8 I haven't really contributed to a project before like this, is there anything else I need to do ? Run tests etc. ? Thanks for all your work on the ruby ecosystem ! Best regards, Martin Tepper ---------------------------------------------------------------------- >Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 17:27 Message: Alrighty: The test: https://github.com/MGPalmer/rubygems/commit/a3c6ac8663032fcb c84d4a1193ec246fd4143fb3 The fix: https://github.com/MGPalmer/rubygems/commit/a57fde4082e76e69 2e292c9312e935f3282f61de And to get all tests working for me locally, I had to fix this: https://github.com/MGPalmer/rubygems/commit/f97755c77ece0929 0e7536e367fa07ce69b363cd It doesn't seem to be connected with the other changes, as I got this error when running the tests against the vanilla 1.6.2 rubygems, but I didn't want to leave the error in. Feel free to ignore this. ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 08:34 Message: Ah yes. Sorry, it actually only fails when trying to install explicitly the latest online version: $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ... $ sudo gem update --system 1.6.2 --no-rdoc --no-ri Latest version currently installed. Aborting. I'll make a test for that. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-10 23:17 Message: I can't reproduce: $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ? $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system --no-rdoc --no-ri Updating rubygems-update Fetching: rubygems-update-1.6.2.gem (100%) Successfully installed rubygems-update-1.6.2 Installing RubyGems 1.6.2 RubyGems 1.6.2 installed Your commit does not have any test changes. I would like to see a failing test first as the update functionality does have tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 From noreply at rubyforge.org Fri Mar 11 15:07:16 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 15:07:16 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29077 ] [PATCH] executable wrapper should set $0 Message-ID: <20110311200717.06F4E1858361@rubyforge.org> Bugs item #29077, was opened at 2011-03-11 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Suraj Kurapati (snk) Assigned to: Nobody (None) Summary: [PATCH] executable wrapper should set $0 Initial Comment: Hello, The wrapper executable that RubyGems generates should set $0 to the actual executable file before loading it. This allows us to use the "if __FILE__ == $0" idiom (which is an indispensable feature for essentially single-file executables that we just want to release as ruby gems) in our executables. Thanks for your consideration. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 From noreply at rubyforge.org Fri Mar 11 15:15:00 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 15:15:00 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29077 ] [PATCH] executable wrapper should set $0 Message-ID: <20110311201500.7D3171858361@rubyforge.org> Bugs item #29077, was opened at 2011-03-11 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Suraj Kurapati (snk) Assigned to: Nobody (None) Summary: [PATCH] executable wrapper should set $0 Initial Comment: Hello, The wrapper executable that RubyGems generates should set $0 to the actual executable file before loading it. This allows us to use the "if __FILE__ == $0" idiom (which is an indispensable feature for essentially single-file executables that we just want to release as ruby gems) in our executables. Thanks for your consideration. ---------------------------------------------------------------------- >Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:15 Message: Whoops, sorry for filing this patch request under the bug tracker (I started out writing a bug report but decided to submit a patch midway). Please move it under the patch tracker if possible. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 From noreply at rubyforge.org Fri Mar 11 15:27:04 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Mar 2011 15:27:04 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29077 ] [PATCH] executable wrapper should set $0 Message-ID: <20110311202704.14E0D1858361@rubyforge.org> Bugs item #29077, was opened at 2011-03-11 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Suraj Kurapati (snk) Assigned to: Nobody (None) Summary: [PATCH] executable wrapper should set $0 Initial Comment: Hello, The wrapper executable that RubyGems generates should set $0 to the actual executable file before loading it. This allows us to use the "if __FILE__ == $0" idiom (which is an indispensable feature for essentially single-file executables that we just want to release as ruby gems) in our executables. Thanks for your consideration. ---------------------------------------------------------------------- >Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:27 Message: Here is a handy little command to fix existing wrappers: sed -i '$s/^load G/load $0 = G/' \ $(gem env | sed -n 's/^.*EXECUTABLE DIRECTORY: *//p')/* Cheers. ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:15 Message: Whoops, sorry for filing this patch request under the bug tracker (I started out writing a bug report but decided to submit a patch midway). Please move it under the patch tracker if possible. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 From ryand-ruby at zenspider.com Fri Mar 11 17:26:36 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 11 Mar 2011 14:26:36 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: On Mar 3, 2011, at 19:11 , Nick Quaranto wrote: > I'd like to get gem yank in at some point, I think by now it's solid, > especially with the addition of platform support that I sat on for way > too long. Does that mean I'll have to wait until April to get a patch > in for that? do it From ryand-ruby at zenspider.com Fri Mar 11 17:28:09 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 11 Mar 2011 14:28:09 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: <2283B633-0EAB-4472-9F96-5DEC7D554EE5@zenspider.com> On Mar 3, 2011, at 20:10 , Erik Hollensbe wrote: > I have some change proposals which will probably impact this rather significantly that I've been toying around with, e.g.: > > https://gist.github.com/22fa600b8c98bdf8c785 > > It seems like implementing this would cover a lot of similar ground in spots. Is there a chance we can talk about how this fits in (or if it does at all) at some point? I was going to be drumming up a patch this weekend to integrate it for your guys' review, per a conversation with Eric and Evan. As discussed in IRC, I don't think these changes will have much, if any, impact on the work I have in mind. Most of my stuff is on the modeling side and doesn't care about the filesystem. I think this work could be done in parallel w/o too many collisions. From ryand-ruby at zenspider.com Fri Mar 11 17:31:46 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 11 Mar 2011 14:31:46 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: <7DFB1AD6-3E31-48A8-B20D-36C8E3EAE0F4@zenspider.com> On Mar 3, 2011, at 19:12 , Evan Phoenix wrote: > I'm working with the bundler guys to make sure we don't bust them for the release. cool cool... thanks. > Additionally, if there are other projects that have hard rubygems API dependencies, please let me know so that I can be sure add it to my list. none that I know of, but that's probably more ignorance on my part. I'm mostly going to be adding API that we don't have than changing API that we do. Of course, I'll probably be changing the guts of Gem.activate and friends a fair amount, but now that we actually have tests on them, I hopefully won't be changing them (too much) in incompatible ways. > Ryan, do you want to coordinate on making these changes or should we all dive in? I'll coordinate. I have some ideas I need to get out of my head before we can all dive in. From ryand-ruby at zenspider.com Fri Mar 11 17:34:16 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 11 Mar 2011 14:34:16 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: <4C9E2377-C352-4E43-8535-7551AD1C12F1@gmail.com> References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> <4C9E2377-C352-4E43-8535-7551AD1C12F1@gmail.com> Message-ID: <7F0B65B3-54D9-4399-8C51-FD4A6E00DB93@zenspider.com> On Mar 5, 2011, at 15:53 , James Tucker wrote: >> IMPORTANT: This release is going to be a code contraction month. Feature additions / enhancements should NOT go in master and should NOT be released in 1.7. We can add toys in 1.8. > > If time is available to do anything, do you want it in topic branches? is it safe to branch from master, or would you prefer them be based off the 1.6 branch? For new features? probably easiest to do them on master on a personal clone. Then when we hit the next expansion month we can just do some pull requests. From ryand-ruby at zenspider.com Fri Mar 11 17:35:29 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 11 Mar 2011 14:35:29 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> Message-ID: On Mar 5, 2011, at 15:49 , James Tucker wrote: > > On Mar 3, 2011, at 7:12 PM, Evan Phoenix wrote: > >> Sounds good. >> >> I'm working with the bundler guys to make sure we don't bust them for the release. > > I've been trying to figure out in the odd 5 minutes I can scramble, how to get the requirements ordering regulated between 1.5 and 1.6, so far I haven't made a working patch. They'll start seeing bug reports coming in soon where teams are mixed between 1.6 and 1.5 rubygems. Just a heads up. regulated == normalized? I don't think we can. The activation logic is incompatible (but improved). Working on a mixed team just smells of problems. From evan at fallingsnow.net Fri Mar 11 18:07:22 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Fri, 11 Mar 2011 15:07:22 -0800 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: <7DFB1AD6-3E31-48A8-B20D-36C8E3EAE0F4@zenspider.com> References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> <7DFB1AD6-3E31-48A8-B20D-36C8E3EAE0F4@zenspider.com> Message-ID: See below. On Mar 11, 2011, at 2:31 PM, Ryan Davis wrote: > > On Mar 3, 2011, at 19:12 , Evan Phoenix wrote: > >> I'm working with the bundler guys to make sure we don't bust them for the release. > > cool cool... thanks. No prob. > >> Additionally, if there are other projects that have hard rubygems API dependencies, please let me know so that I can be sure add it to my list. > > none that I know of, but that's probably more ignorance on my part. Ok, well, if you think of any, let me know. > > I'm mostly going to be adding API that we don't have than changing API that we do. Of course, I'll probably be changing the guts of Gem.activate and friends a fair amount, but now that we actually have tests on them, I hopefully won't be changing them (too much) in incompatible ways. I figured as much. Sounds good. > >> Ryan, do you want to coordinate on making these changes or should we all dive in? > > I'll coordinate. I have some ideas I need to get out of my head before we can all dive in. Ok, sounds good. Just let us know how you're going to proceed. > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From erik at hollensbe.org Fri Mar 11 18:26:10 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Fri, 11 Mar 2011 18:26:10 -0500 Subject: [Rubygems-developers] The 1.7 Plan In-Reply-To: <2283B633-0EAB-4472-9F96-5DEC7D554EE5@zenspider.com> References: <95D78401-3D7B-44DD-AEA5-AAC9307AB697@zenspider.com> <2283B633-0EAB-4472-9F96-5DEC7D554EE5@zenspider.com> Message-ID: <5FB3B768-1E83-41A9-889B-6DABF6754DF4@hollensbe.org> On Mar 11, 2011, at 5:28 PM, Ryan Davis wrote: > > On Mar 3, 2011, at 20:10 , Erik Hollensbe wrote: > >> I have some change proposals which will probably impact this rather significantly that I've been toying around with, e.g.: >> >> https://gist.github.com/22fa600b8c98bdf8c785 >> >> It seems like implementing this would cover a lot of similar ground in spots. Is there a chance we can talk about how this fits in (or if it does at all) at some point? I was going to be drumming up a patch this weekend to integrate it for your guys' review, per a conversation with Eric and Evan. > > As discussed in IRC, I don't think these changes will have much, if any, impact on the work I have in mind. Most of my stuff is on the modeling side and doesn't care about the filesystem. I think this work could be done in parallel w/o too many collisions. OK, excellent. I would really like it (it's a short read) if you could read the path-support diff as well, (I think) it solves some of your previous concerns expressed about GEM_HOME and pals. A preliminary sign-off, if you have time, before I go in neck-deep would really ease my mind. Top of this file: https://github.com/erikh/rubygems/blob/path-support/lib/rubygems/file_system.rb Integration is mostly there, but I didn't want to proceed on this because this is going to be a much bigger hit than the Gem::FS stuff, which is already going to be pretty large. There is one failing test in this branch; it's been a busy week and I haven't had time to track it down. -Erik From noreply at rubyforge.org Sat Mar 12 05:55:06 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 12 Mar 2011 05:55:06 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110312105506.A552E185836B@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Sat Mar 12 10:18:44 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 12 Mar 2011 10:18:44 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110312151844.3C5DF18581F3@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 13:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 15:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 10:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 15:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 15:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 13:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 13:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 09:51:37 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 09:51:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314135137.EAC70185834E@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 13:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 13:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 15:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 10:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 15:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 15:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 13:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 13:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 10:22:03 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 10:22:03 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314142203.708D7185836B@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 15:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 14:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 16:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 10:50:13 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 10:50:13 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29080 ] rubygems-update now depends on a new version of hoe redering it useless Message-ID: <20110314145013.F08E71858377@rubyforge.org> Bugs item #29080, was opened at 2011-03-14 14:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: J. Pablo Fer?ndez (pupeno) Assigned to: Nobody (None) Summary: rubygems-update now depends on a new version of hoe redering it useless Initial Comment: I normally user rubygems-update to update gems in Debian installations, but now that's no longer possible, it depends on hoe >= 2.8.0: ~# /var/lib/gems/1.8/bin/update_rubygems /usr/lib/ruby/1.8/rubygems.rb:578:in `report_activate_error': Could not find RubyGem hoe (>= 2.8.0) (Gem::LoadError) which depends on RubyGems >= 1.2.1 :~# gem install hoe --version=2.8.0 ERROR: Error installing hoe: hoe requires RubyGems version >= 1.3.1 which isn't what Debian comes with: ~# gem --version 1.2.0 That made rubygems-update useless for me :( ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 From noreply at rubyforge.org Mon Mar 14 11:04:10 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 11:04:10 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314150410.58398185837B@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 13:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 15:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 14:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 13:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 15:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 10:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 15:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 15:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 13:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 13:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 11:07:20 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 11:07:20 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314150721.076A0185837B@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 16:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 16:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 15:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 14:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 16:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 11:42:58 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 11:42:58 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29080 ] rubygems-update now depends on a new version of hoe redering it useless Message-ID: <20110314154258.54649185838C@rubyforge.org> Bugs item #29080, was opened at 2011-03-14 11:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: J. Pablo Fer?ndez (pupeno) Assigned to: Nobody (None) Summary: rubygems-update now depends on a new version of hoe redering it useless Initial Comment: I normally user rubygems-update to update gems in Debian installations, but now that's no longer possible, it depends on hoe >= 2.8.0: ~# /var/lib/gems/1.8/bin/update_rubygems /usr/lib/ruby/1.8/rubygems.rb:578:in `report_activate_error': Could not find RubyGem hoe (>= 2.8.0) (Gem::LoadError) which depends on RubyGems >= 1.2.1 :~# gem install hoe --version=2.8.0 ERROR: Error installing hoe: hoe requires RubyGems version >= 1.3.1 which isn't what Debian comes with: ~# gem --version 1.2.0 That made rubygems-update useless for me :( ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-03-14 12:42 Message: If you're in debian, you should follow the debian-way to update packages, not using gem update --system, which was intentionally disabled by them Now, you can: wait for them to update it, or do it yourself. https://github.com/rubygems/rubygems/blob/master/UPGRADING.rdoc ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 From noreply at rubyforge.org Mon Mar 14 11:44:53 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 11:44:53 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29080 ] rubygems-update now depends on a new version of hoe redering it useless Message-ID: <20110314154453.427CE185838D@rubyforge.org> Bugs item #29080, was opened at 2011-03-14 14:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: J. Pablo Fer?ndez (pupeno) Assigned to: Nobody (None) Summary: rubygems-update now depends on a new version of hoe redering it useless Initial Comment: I normally user rubygems-update to update gems in Debian installations, but now that's no longer possible, it depends on hoe >= 2.8.0: ~# /var/lib/gems/1.8/bin/update_rubygems /usr/lib/ruby/1.8/rubygems.rb:578:in `report_activate_error': Could not find RubyGem hoe (>= 2.8.0) (Gem::LoadError) which depends on RubyGems >= 1.2.1 :~# gem install hoe --version=2.8.0 ERROR: Error installing hoe: hoe requires RubyGems version >= 1.3.1 which isn't what Debian comes with: ~# gem --version 1.2.0 That made rubygems-update useless for me :( ---------------------------------------------------------------------- >Comment By: J. Pablo Fer?ndez (pupeno) Date: 2011-03-14 15:44 Message: I'm not doing gem update --system, I'm using rubygems-update, which was created specifically to workaround issues like this, wasn't it? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 15:42 Message: If you're in debian, you should follow the debian-way to update packages, not using gem update --system, which was intentionally disabled by them Now, you can: wait for them to update it, or do it yourself. https://github.com/rubygems/rubygems/blob/master/UPGRADING.rdoc ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 From noreply at rubyforge.org Mon Mar 14 11:47:42 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 11:47:42 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314154743.0BE8A185838D@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 16:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 16:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 16:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 15:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 14:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 16:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 11:48:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 11:48:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29080 ] rubygems-update now depends on a new version of hoe redering it useless Message-ID: <20110314154859.EB79A1858390@rubyforge.org> Bugs item #29080, was opened at 2011-03-14 11:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: J. Pablo Fer?ndez (pupeno) Assigned to: Nobody (None) Summary: rubygems-update now depends on a new version of hoe redering it useless Initial Comment: I normally user rubygems-update to update gems in Debian installations, but now that's no longer possible, it depends on hoe >= 2.8.0: ~# /var/lib/gems/1.8/bin/update_rubygems /usr/lib/ruby/1.8/rubygems.rb:578:in `report_activate_error': Could not find RubyGem hoe (>= 2.8.0) (Gem::LoadError) which depends on RubyGems >= 1.2.1 :~# gem install hoe --version=2.8.0 ERROR: Error installing hoe: hoe requires RubyGems version >= 1.3.1 which isn't what Debian comes with: ~# gem --version 1.2.0 That made rubygems-update useless for me :( ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-03-14 12:48 Message: No, if you installed rubygems via debian, there is no workaround to get that working. You have a really old version of RubyGems that can't distinguish between runtime and development dependencies. Because of that, you need to manually install RubyGems *if* you installed manually before. If not, you will bork your system because debian customized a series of commands. ---------------------------------------------------------------------- Comment By: J. Pablo Fer?ndez (pupeno) Date: 2011-03-14 12:44 Message: I'm not doing gem update --system, I'm using rubygems-update, which was created specifically to workaround issues like this, wasn't it? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 12:42 Message: If you're in debian, you should follow the debian-way to update packages, not using gem update --system, which was intentionally disabled by them Now, you can: wait for them to update it, or do it yourself. https://github.com/rubygems/rubygems/blob/master/UPGRADING.rdoc ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 From noreply at rubyforge.org Mon Mar 14 11:50:50 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 11:50:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29080 ] rubygems-update now depends on a new version of hoe redering it useless Message-ID: <20110314155050.CE8A7185838D@rubyforge.org> Bugs item #29080, was opened at 2011-03-14 14:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: J. Pablo Fer?ndez (pupeno) Assigned to: Nobody (None) Summary: rubygems-update now depends on a new version of hoe redering it useless Initial Comment: I normally user rubygems-update to update gems in Debian installations, but now that's no longer possible, it depends on hoe >= 2.8.0: ~# /var/lib/gems/1.8/bin/update_rubygems /usr/lib/ruby/1.8/rubygems.rb:578:in `report_activate_error': Could not find RubyGem hoe (>= 2.8.0) (Gem::LoadError) which depends on RubyGems >= 1.2.1 :~# gem install hoe --version=2.8.0 ERROR: Error installing hoe: hoe requires RubyGems version >= 1.3.1 which isn't what Debian comes with: ~# gem --version 1.2.0 That made rubygems-update useless for me :( ---------------------------------------------------------------------- >Comment By: J. Pablo Fer?ndez (pupeno) Date: 2011-03-14 15:50 Message: Up until today, we updated all our debian servers with rubygems-update and everything worked like a charm. What's rubygems-update for then? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 15:48 Message: No, if you installed rubygems via debian, there is no workaround to get that working. You have a really old version of RubyGems that can't distinguish between runtime and development dependencies. Because of that, you need to manually install RubyGems *if* you installed manually before. If not, you will bork your system because debian customized a series of commands. ---------------------------------------------------------------------- Comment By: J. Pablo Fer?ndez (pupeno) Date: 2011-03-14 15:44 Message: I'm not doing gem update --system, I'm using rubygems-update, which was created specifically to workaround issues like this, wasn't it? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 15:42 Message: If you're in debian, you should follow the debian-way to update packages, not using gem update --system, which was intentionally disabled by them Now, you can: wait for them to update it, or do it yourself. https://github.com/rubygems/rubygems/blob/master/UPGRADING.rdoc ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 From noreply at rubyforge.org Mon Mar 14 11:54:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 11:54:14 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29080 ] rubygems-update now depends on a new version of hoe redering it useless Message-ID: <20110314155414.8E1F0185838D@rubyforge.org> Bugs item #29080, was opened at 2011-03-14 11:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: J. Pablo Fer?ndez (pupeno) Assigned to: Nobody (None) Summary: rubygems-update now depends on a new version of hoe redering it useless Initial Comment: I normally user rubygems-update to update gems in Debian installations, but now that's no longer possible, it depends on hoe >= 2.8.0: ~# /var/lib/gems/1.8/bin/update_rubygems /usr/lib/ruby/1.8/rubygems.rb:578:in `report_activate_error': Could not find RubyGem hoe (>= 2.8.0) (Gem::LoadError) which depends on RubyGems >= 1.2.1 :~# gem install hoe --version=2.8.0 ERROR: Error installing hoe: hoe requires RubyGems version >= 1.3.1 which isn't what Debian comes with: ~# gem --version 1.2.0 That made rubygems-update useless for me :( ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2011-03-14 12:54 Message: Update first to something like 1.3.1 and *then* update to latest. You're missing lot of steps. You didn't mention which version of RubyGems you have, but if you get >= 1.3.1 warnings means is quite old. That means you haven't been updating RubyGems in long time, so wonder how things worked like a charm... since you didn't update them in long time. ---------------------------------------------------------------------- Comment By: J. Pablo Fer?ndez (pupeno) Date: 2011-03-14 12:50 Message: Up until today, we updated all our debian servers with rubygems-update and everything worked like a charm. What's rubygems-update for then? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 12:48 Message: No, if you installed rubygems via debian, there is no workaround to get that working. You have a really old version of RubyGems that can't distinguish between runtime and development dependencies. Because of that, you need to manually install RubyGems *if* you installed manually before. If not, you will bork your system because debian customized a series of commands. ---------------------------------------------------------------------- Comment By: J. Pablo Fer?ndez (pupeno) Date: 2011-03-14 12:44 Message: I'm not doing gem update --system, I'm using rubygems-update, which was created specifically to workaround issues like this, wasn't it? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 12:42 Message: If you're in debian, you should follow the debian-way to update packages, not using gem update --system, which was intentionally disabled by them Now, you can: wait for them to update it, or do it yourself. https://github.com/rubygems/rubygems/blob/master/UPGRADING.rdoc ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 From noreply at rubyforge.org Mon Mar 14 13:04:27 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 13:04:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314170427.4B9F218583BA@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 18:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 16:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 16:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 16:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 15:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 14:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 16:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 14:02:41 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 14:02:41 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314180241.614211858374@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 19:02 Message: and any packaging system that uses post install hooks for building files *is* broken. i didnt even refer to potential abuse scenarios yet, building native extensions for ruby is certainly in the scope of rubygems. building binaries that get installed somewhere definitely is not. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 18:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 16:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 16:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 16:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 15:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 14:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 16:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 14:55:13 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 14:55:13 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314185513.3C8CB185835A@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: None Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Nobody (None) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 19:55 Message: You can turn it like you want but building binaries is what rubygems is already doing today. They just get a different linker treatment. Not sure why one make such hard distinction there. Abuse scenarios are a bogus argument as long as the extconf (or for that matter - any code from the gem) gets executed. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 19:02 Message: and any packaging system that uses post install hooks for building files *is* broken. i didnt even refer to potential abuse scenarios yet, building native extensions for ruby is certainly in the scope of rubygems. building binaries that get installed somewhere definitely is not. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 18:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 16:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 16:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 16:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 15:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 14:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 16:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 16:45:57 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 16:45:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29077 ] [PATCH] executable wrapper should set $0 Message-ID: <20110314204558.B7C2B185837E@rubyforge.org> Bugs item #29077, was opened at 2011-03-11 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 Category: `gem install` command >Group: v1.6.x Status: Open Resolution: None Priority: 3 Submitted By: Suraj Kurapati (snk) >Assigned to: Eric Hodel (drbrain) Summary: [PATCH] executable wrapper should set $0 Initial Comment: Hello, The wrapper executable that RubyGems generates should set $0 to the actual executable file before loading it. This allows us to use the "if __FILE__ == $0" idiom (which is an indispensable feature for essentially single-file executables that we just want to release as ruby gems) in our executables. Thanks for your consideration. ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-14 13:45 Message: If this is only a single-file executable why would you need the `if __FILE__ == $0` check? RubyGems no longer places 'bin' on the load path. ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:27 Message: Here is a handy little command to fix existing wrappers: sed -i '$s/^load G/load $0 = G/' \ $(gem env | sed -n 's/^.*EXECUTABLE DIRECTORY: *//p')/* Cheers. ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:15 Message: Whoops, sorry for filing this patch request under the bug tracker (I started out writing a bug report but decided to submit a patch midway). Please move it under the patch tracker if possible. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 From noreply at rubyforge.org Mon Mar 14 17:01:02 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 17:01:02 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110314210102.D5B951858381@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 05:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open >Resolution: Rejected Priority: 3 Submitted By: Torsten Curdt (tcurdt) >Assigned to: Ryan Davis (zenspider) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-14 14:01 Message: Just to make sure I understand: you have a pure ruby gem that calls out to a binary that you want to provide (build and install) via the gem. If that is accurate, I don't think that extra post_install hooks are the right way to go here. I think you can make this work via "normal" mechanisms. I think what you want to do is design a rake-based extension but then have that rakefile build and install your binary instead of a shared library. I just simulated this with a simple hoe-based project that had 'notext/blah/Rakefile' as it's extension and that rakefile just had: task :default => :build task :build do puts "building my cmdline tool!" touch "happy" end Upon packaging and installing, 'happy' was created inside the notext dir of the install. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 11:55 Message: You can turn it like you want but building binaries is what rubygems is already doing today. They just get a different linker treatment. Not sure why one make such hard distinction there. Abuse scenarios are a bogus argument as long as the extconf (or for that matter - any code from the gem) gets executed. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 11:02 Message: and any packaging system that uses post install hooks for building files *is* broken. i didnt even refer to potential abuse scenarios yet, building native extensions for ruby is certainly in the scope of rubygems. building binaries that get installed somewhere definitely is not. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 10:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 08:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 08:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 08:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 07:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 06:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 07:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 02:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 08:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 07:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 07:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 05:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 05:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Mon Mar 14 17:16:08 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 17:16:08 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29080 ] rubygems-update now depends on a new version of hoe redering it useless Message-ID: <20110314211608.6545E185837F@rubyforge.org> Bugs item #29080, was opened at 2011-03-14 07:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: J. Pablo Fer?ndez (pupeno) Assigned to: Nobody (None) Summary: rubygems-update now depends on a new version of hoe redering it useless Initial Comment: I normally user rubygems-update to update gems in Debian installations, but now that's no longer possible, it depends on hoe >= 2.8.0: ~# /var/lib/gems/1.8/bin/update_rubygems /usr/lib/ruby/1.8/rubygems.rb:578:in `report_activate_error': Could not find RubyGem hoe (>= 2.8.0) (Gem::LoadError) which depends on RubyGems >= 1.2.1 :~# gem install hoe --version=2.8.0 ERROR: Error installing hoe: hoe requires RubyGems version >= 1.3.1 which isn't what Debian comes with: ~# gem --version 1.2.0 That made rubygems-update useless for me :( ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2011-03-14 14:16 Message: rubygems-update is the gem we install and run when you do update --system. So if update --system doesn't work, there is a good chance that rubygems-update doesn't work. Rubygems 1.2.0 was the first version to ship with development dependency support. So the fact that you're seeing this problem hints that you're not actually running 1.2.0 (or that debian REALLY broke 1.2.0). As stated in UPGRADING.rdoc: === From rubygems 1-1.x through 1.2.x: RubyGems 1.1 and 1.2 have problems upgrading when there is no rubygems-update installed. You will need to use the following instructions if you see "Nothing to update". Use the Manual Upgrade Recipe below. ... === Manual Install If you don't have any RubyGems install, there is still the pre-gem approach to getting software, doing it manually: Use sudo/su as appropriate: * Download from: https://rubygems.org/pages/download * Unpack into a directory and cd there * Install with: ruby setup.rb ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 08:54 Message: Update first to something like 1.3.1 and *then* update to latest. You're missing lot of steps. You didn't mention which version of RubyGems you have, but if you get >= 1.3.1 warnings means is quite old. That means you haven't been updating RubyGems in long time, so wonder how things worked like a charm... since you didn't update them in long time. ---------------------------------------------------------------------- Comment By: J. Pablo Fer?ndez (pupeno) Date: 2011-03-14 08:50 Message: Up until today, we updated all our debian servers with rubygems-update and everything worked like a charm. What's rubygems-update for then? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 08:48 Message: No, if you installed rubygems via debian, there is no workaround to get that working. You have a really old version of RubyGems that can't distinguish between runtime and development dependencies. Because of that, you need to manually install RubyGems *if* you installed manually before. If not, you will bork your system because debian customized a series of commands. ---------------------------------------------------------------------- Comment By: J. Pablo Fer?ndez (pupeno) Date: 2011-03-14 08:44 Message: I'm not doing gem update --system, I'm using rubygems-update, which was created specifically to workaround issues like this, wasn't it? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-14 08:42 Message: If you're in debian, you should follow the debian-way to update packages, not using gem update --system, which was intentionally disabled by them Now, you can: wait for them to update it, or do it yourself. https://github.com/rubygems/rubygems/blob/master/UPGRADING.rdoc ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29080&group_id=126 From noreply at rubyforge.org Mon Mar 14 17:16:56 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 17:16:56 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29074 ] Can't upgrade to newer rubygems version with explicit version number Message-ID: <20110314211656.C32181858381@rubyforge.org> Bugs item #29074, was opened at 2011-03-10 08:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 Category: None Group: None Status: Open >Resolution: Accepted Priority: 3 Submitted By: Martin Tepper (mgpalmer) >Assigned to: Ryan Davis (zenspider) Summary: Can't upgrade to newer rubygems version with explicit version number Initial Comment: Hi everybody ! I've already briefly explained the problem here: http://help.rubygems.org/discussions/problems/514-cant-upgrade-to-newer-rubygems-version-with-explicit-version-number Basically, upgrading rubygems to a specific, higher-than-now version (or the latest version) doesn't work as it is. You can workaround by installing rubygems-update manually, but I think it's quite unobvious why you can't just tell the target version and be done with it. I've poked around in the code and found a solution. Here's my take on it: https://github.com/MGPalmer/rubygems/commit/a1bd03cd597a3a0fc1d13059c582ac7266c34fb8 I haven't really contributed to a project before like this, is there anything else I need to do ? Run tests etc. ? Thanks for all your work on the ruby ecosystem ! Best regards, Martin Tepper ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 08:27 Message: Alrighty: The test: https://github.com/MGPalmer/rubygems/commit/a3c6ac8663032fcb c84d4a1193ec246fd4143fb3 The fix: https://github.com/MGPalmer/rubygems/commit/a57fde4082e76e69 2e292c9312e935f3282f61de And to get all tests working for me locally, I had to fix this: https://github.com/MGPalmer/rubygems/commit/f97755c77ece0929 0e7536e367fa07ce69b363cd It doesn't seem to be connected with the other changes, as I got this error when running the tests against the vanilla 1.6.2 rubygems, but I didn't want to leave the error in. Feel free to ignore this. ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-10 23:34 Message: Ah yes. Sorry, it actually only fails when trying to install explicitly the latest online version: $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ... $ sudo gem update --system 1.6.2 --no-rdoc --no-ri Latest version currently installed. Aborting. I'll make a test for that. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-10 14:17 Message: I can't reproduce: $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ? $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system --no-rdoc --no-ri Updating rubygems-update Fetching: rubygems-update-1.6.2.gem (100%) Successfully installed rubygems-update-1.6.2 Installing RubyGems 1.6.2 RubyGems 1.6.2 installed Your commit does not have any test changes. I would like to see a failing test first as the update functionality does have tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 From noreply at rubyforge.org Mon Mar 14 17:30:26 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 14 Mar 2011 17:30:26 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29077 ] [PATCH] executable wrapper should set $0 Message-ID: <20110314213027.3EA03185837F@rubyforge.org> Bugs item #29077, was opened at 2011-03-11 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 Category: `gem install` command Group: v1.6.x Status: Open Resolution: None Priority: 3 Submitted By: Suraj Kurapati (snk) Assigned to: Eric Hodel (drbrain) Summary: [PATCH] executable wrapper should set $0 Initial Comment: Hello, The wrapper executable that RubyGems generates should set $0 to the actual executable file before loading it. This allows us to use the "if __FILE__ == $0" idiom (which is an indispensable feature for essentially single-file executables that we just want to release as ruby gems) in our executables. Thanks for your consideration. ---------------------------------------------------------------------- >Comment By: Suraj Kurapati (snk) Date: 2011-03-14 14:30 Message: Although it is a single-file executable, it still uses data structures / logic factored into separate classes & modules. The "if __FILE__ == $0" idiom allows me to try out these data structures in IRB without "running" the executable. That idiom also allows me to embed a unit test inside the executable (via an additional "if $DEBUG") if I want. I don't understand your comment about RubyGems not putting 'bin' on the $LOAD_PATH. Why does that matter? Doesn't RubyGems install wrapper executables that rely on Gem.bin_path() instead of $LOAD_PATH? IMHO, the wrapper executables RubyGems installs should be completely transparent to the underlying "real" executable being invoked. Thanks for your consideration. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-14 13:45 Message: If this is only a single-file executable why would you need the `if __FILE__ == $0` check? RubyGems no longer places 'bin' on the load path. ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:27 Message: Here is a handy little command to fix existing wrappers: sed -i '$s/^load G/load $0 = G/' \ $(gem env | sed -n 's/^.*EXECUTABLE DIRECTORY: *//p')/* Cheers. ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:15 Message: Whoops, sorry for filing this patch request under the bug tracker (I started out writing a bug report but decided to submit a patch midway). Please move it under the patch tracker if possible. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 From noreply at rubyforge.org Tue Mar 15 03:02:58 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 Mar 2011 03:02:58 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29075 ] need for a post_install hook Message-ID: <20110315070258.460461858391@rubyforge.org> Bugs item #29075, was opened at 2011-03-11 14:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 Category: `gem install` command (extensions) Group: next Status: Open Resolution: Rejected Priority: 3 Submitted By: Torsten Curdt (tcurdt) Assigned to: Ryan Davis (zenspider) Summary: need for a post_install hook Initial Comment: While there is Gem.post_install this cannot be used for gems that want to run some code on installation. In my particular case I need to compile some C++ code -a command line tool- that the gem depends on. It does not come with an extension though. Since there is no post_install hook exposed to the gem lifecycle people use the extconf for things like this. Since that one makes the assumption of building an extension, leaving out the create_makefile() results in Building native extensions. This could take a while... ERROR: Error installing ... ERROR: Failed to build gem native extension. No builder for extension 'path/to/extconf.rb' Which result in people doing things like this http://blog.costan.us/2008/11/post-install-post-update-scripts-for.html The best solution would certainly be to have some gem lifecyle hooks. But just making less assumption on the extension building would already be a first step. ---------------------------------------------------------------------- >Comment By: Torsten Curdt (tcurdt) Date: 2011-03-15 08:02 Message: Ryan, can elaborate or point me to an example how to do a "rake-based extension"? IIUC this means providing a Rakefile (or Makefile?) instead of the generated by the extconf? Still have your test project around? ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2011-03-14 22:01 Message: Just to make sure I understand: you have a pure ruby gem that calls out to a binary that you want to provide (build and install) via the gem. If that is accurate, I don't think that extra post_install hooks are the right way to go here. I think you can make this work via "normal" mechanisms. I think what you want to do is design a rake-based extension but then have that rakefile build and install your binary instead of a shared library. I just simulated this with a simple hoe-based project that had 'notext/blah/Rakefile' as it's extension and that rakefile just had: task :default => :build task :build do puts "building my cmdline tool!" touch "happy" end Upon packaging and installing, 'happy' was created inside the notext dir of the install. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 19:55 Message: You can turn it like you want but building binaries is what rubygems is already doing today. They just get a different linker treatment. Not sure why one make such hard distinction there. Abuse scenarios are a bogus argument as long as the extconf (or for that matter - any code from the gem) gets executed. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 19:02 Message: and any packaging system that uses post install hooks for building files *is* broken. i didnt even refer to potential abuse scenarios yet, building native extensions for ruby is certainly in the scope of rubygems. building binaries that get installed somewhere definitely is not. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 18:04 Message: If that binary was something that would make sense outside of the gem I would agree - but it doesn't. Following your arguments all native code should live somewhere else - including the normal extensions. That would add a complexity to the system I don't see worth having. A post_install hook certainly gives room for abuse but it's a common pattern found in the various packaging systems. Not sure I would call this a broken feature. In fact I think the current build in assumptions are even worse. ---------------------------------------------------------------------- Comment By: Marcus Rueckert (darix) Date: 2011-03-14 16:47 Message: imho this is just the wrong approach, intree packaging like that just sucks. for users as for packagers. maybe the user has your binary installed already just outside of $PATH? while you could walk over $PATH and check if a binary with the desired name exists, you couldnt be sure that behind the filename is really the app you are expecting and that the version is compatible. handle the absence of the binary properly in your code and document for the user that a certain binary is required for proper functioning of your gem. I would really object adding a broken feature like this. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 16:07 Message: You are probably right. As long as it is tracked as feature or bug I am fine. Thanks - the short term thing works. It's just ugly :) ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 16:04 Message: Fair. IMO this issue should reappear as a feature request rather than stay a bug. And that would likely lead to relooking at plugin/hook visibility. I don't know what Eric wants for next steps on this, but since he asked you to open the issue, maybe it's enough to leave it as a bug. Good luck with whatever short-term solution you choose. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-14 15:22 Message: Sorry, but the --init is more a work around than really an option. IMO a post_install hook for a gem is quite a natural thing to expect. If that's not on the table extconf should at least not make all those assumptions people hack around today. If you just close this issue people will continue to abuse the extconf like I am doing, too now. IMO an empty extconf should just not result in an error and we would be OKish. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-14 14:51 Message: While you could go down the plugin/hook path and split things something like... https://github.com/jonforums/prething https://github.com/jonforums/thing I think it's a bad fit for what you're trying to do...could become a tarbaby trying to keep the `prething` plugin from affecting other gems and coordinating with your main gem. Try building/installing the `prething` and see how globally it affects RG ops. Probably faster and more robust to add an `--init` to your gem's `bin\somthing` executable and document your gem's two-step install process in a `Gem::Specification.post_install_message` and your project doc. Any reason to keep this listed as an open RG bug? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-12 16:18 Message: That snippet from our install script results in a rubygems/defaults/operating_system.rb file being generated similar to the following: # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage Gem.pre_install do |gem_installer| unless gem_installer.spec.extensions.empty? unless ENV['PATH'].include?('C:\DevKit\mingw\bin') then Gem.ui.say 'Temporarily enhancing PATH to include DevKit...' if Gem.configuration.verbose ENV['PATH'] = 'C:\DevKit\bin;C:\DevKit\mingw\bin;' + ENV['PATH'] end ENV['RI_DEVKIT'] = 'C:\DevKit' ENV['CC'] = 'gcc' ENV['CPP'] = 'cpp' ENV['CXX'] = 'g++' end end # :DK-END While my usage is fairly simple and the only mildly clever parts are (a) checking whether a native extension is being installed, and (b) wrapping the code snippet in markers so I can manage non-clobbering/upgrades of existing operating_system.rb files, I'm still betting that you could use `system` to call out to your toolchain and build your C++ tool in a similar way. It's the combination of the filename/location in combination with the block to Gem.pre_install which sets the pre-install hook that RG calls at the appropriate time during an install. These two places in the source should help: https://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L65-82 https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L140 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-12 11:55 Message: @Jon: Still don't quite understand when you are setting that hook. Why would that code be called on a 'gem install' ? ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 17:05 Message: In the DevKit (MSYS/MinGW toolchain for Windows) subproject of the RubyInstaller we have a Ruby install script which dynamically builds a gem override script that uses the pre-install hook to setup the environment for building native gems on Windows using the DevKit: https://github.com/oneclick/rubyinstaller/blob/master/resources/devkit/dk.rb.erb#L46-65 Basically, it automagically brings the DevKit toolchain into the environment when doing something like `gem install bson_ext` Thinking out loud, but I wonder if you can do something similar but use `system` or `IO.popen` to optimistically compile your gem's C++ dependency before the install and abort if you get any errors. Might also want to check/cleanup in post-build. A wild-eyed idea, but it might work if you can split things into "pre-build dependencies" and "build extension" and abort if things go badly. ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 16:46 Message: Maybe I misunderstood but I think Eric said on IRC that the existing post_install is not for gems. Which is why he asked me to open this issue. Jon, can you give an example how that would work? Whether it is pre or post install is not important to me. It's just that one might want to build more than just extension on install. I got that working by abusing the extconf to execute my build and creating an empty Makefile. But that smells. ---------------------------------------------------------------------- Comment By: Jon Forums (jonforums) Date: 2011-03-11 16:13 Message: Can you split things up to use the pre-install and post-build hooks which as of 1.5.0 that can cancel gem installation...optimistically compile in the pre-install and abort if needed in either pre-install or post-build? http://blog.segment7.net/2011/01/31/rubygems-1-5 ---------------------------------------------------------------------- Comment By: Torsten Curdt (tcurdt) Date: 2011-03-11 14:54 Message: Then you also cannot allow native builds. Where is the difference? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2011-03-11 14:44 Message: I would say no to this. Most of the users do not check what the gem do inside, so there is a huge potential of security risks on this. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29075&group_id=126 From noreply at rubyforge.org Tue Mar 15 08:41:59 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 Mar 2011 08:41:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29074 ] Can't upgrade to newer rubygems version with explicit version number Message-ID: <20110315124159.41D0C167815E@rubyforge.org> Bugs item #29074, was opened at 2011-03-10 17:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Martin Tepper (mgpalmer) Assigned to: Ryan Davis (zenspider) Summary: Can't upgrade to newer rubygems version with explicit version number Initial Comment: Hi everybody ! I've already briefly explained the problem here: http://help.rubygems.org/discussions/problems/514-cant-upgrade-to-newer-rubygems-version-with-explicit-version-number Basically, upgrading rubygems to a specific, higher-than-now version (or the latest version) doesn't work as it is. You can workaround by installing rubygems-update manually, but I think it's quite unobvious why you can't just tell the target version and be done with it. I've poked around in the code and found a solution. Here's my take on it: https://github.com/MGPalmer/rubygems/commit/a1bd03cd597a3a0fc1d13059c582ac7266c34fb8 I haven't really contributed to a project before like this, is there anything else I need to do ? Run tests etc. ? Thanks for all your work on the ruby ecosystem ! Best regards, Martin Tepper ---------------------------------------------------------------------- >Comment By: Martin Tepper (mgpalmer) Date: 2011-03-15 13:41 Message: I've cleaned up the spec: https://github.com/MGPalmer/rubygems/commit/2ebbfc71ea5548df8 d3bab6bffe3524324bff211 Please also see my comment on your comment - IMHO, making it easier for developers is more important in this case. But changing the test style is not my mission here :) ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 17:27 Message: Alrighty: The test: https://github.com/MGPalmer/rubygems/commit/a3c6ac8663032fcb c84d4a1193ec246fd4143fb3 The fix: https://github.com/MGPalmer/rubygems/commit/a57fde4082e76e69 2e292c9312e935f3282f61de And to get all tests working for me locally, I had to fix this: https://github.com/MGPalmer/rubygems/commit/f97755c77ece0929 0e7536e367fa07ce69b363cd It doesn't seem to be connected with the other changes, as I got this error when running the tests against the vanilla 1.6.2 rubygems, but I didn't want to leave the error in. Feel free to ignore this. ---------------------------------------------------------------------- Comment By: Martin Tepper (mgpalmer) Date: 2011-03-11 08:34 Message: Ah yes. Sorry, it actually only fails when trying to install explicitly the latest online version: $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ... $ sudo gem update --system 1.6.2 --no-rdoc --no-ri Latest version currently installed. Aborting. I'll make a test for that. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-10 23:17 Message: I can't reproduce: $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system 1.6.1 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.1 Installing RubyGems 1.6.1 RubyGems 1.6.1 installed ? $ sudo gem update --system 1.6.0 --no-rdoc --no-ri Updating rubygems-update Successfully installed rubygems-update-1.6.0 Installing RubyGems 1.6.0 RubyGems 1.6.0 installed ? $ sudo gem update --system --no-rdoc --no-ri Updating rubygems-update Fetching: rubygems-update-1.6.2.gem (100%) Successfully installed rubygems-update-1.6.2 Installing RubyGems 1.6.2 RubyGems 1.6.2 installed Your commit does not have any test changes. I would like to see a failing test first as the update functionality does have tests. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29074&group_id=126 From noreply at rubyforge.org Tue Mar 15 18:30:05 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 Mar 2011 18:30:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29077 ] [PATCH] executable wrapper should set $0 Message-ID: <20110315223006.529BD185835A@rubyforge.org> Bugs item #29077, was opened at 2011-03-11 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 Category: `gem install` command Group: v1.6.x >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Suraj Kurapati (snk) Assigned to: Eric Hodel (drbrain) Summary: [PATCH] executable wrapper should set $0 Initial Comment: Hello, The wrapper executable that RubyGems generates should set $0 to the actual executable file before loading it. This allows us to use the "if __FILE__ == $0" idiom (which is an indispensable feature for essentially single-file executables that we just want to release as ruby gems) in our executables. Thanks for your consideration. ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-15 15:30 Message: In the past 'bin' was on the load path so require may have loaded executables unintentionally. Since this functionality is only desired to make your testing easier you should move testable code out of bin/ and place it in lib/. Your executable in bin should be something simple like: #!/usr/local/bin/ruby19 require 'meme' Meme.run ARGV Furthermore, setting $0 accurately may not be possible due to platform issues. On some operating systems $0 will be truncated when set. ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2011-03-14 14:30 Message: Although it is a single-file executable, it still uses data structures / logic factored into separate classes & modules. The "if __FILE__ == $0" idiom allows me to try out these data structures in IRB without "running" the executable. That idiom also allows me to embed a unit test inside the executable (via an additional "if $DEBUG") if I want. I don't understand your comment about RubyGems not putting 'bin' on the $LOAD_PATH. Why does that matter? Doesn't RubyGems install wrapper executables that rely on Gem.bin_path() instead of $LOAD_PATH? IMHO, the wrapper executables RubyGems installs should be completely transparent to the underlying "real" executable being invoked. Thanks for your consideration. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2011-03-14 13:45 Message: If this is only a single-file executable why would you need the `if __FILE__ == $0` check? RubyGems no longer places 'bin' on the load path. ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:27 Message: Here is a handy little command to fix existing wrappers: sed -i '$s/^load G/load $0 = G/' \ $(gem env | sed -n 's/^.*EXECUTABLE DIRECTORY: *//p')/* Cheers. ---------------------------------------------------------------------- Comment By: Suraj Kurapati (snk) Date: 2011-03-11 12:15 Message: Whoops, sorry for filing this patch request under the bug tracker (I started out writing a bug report but decided to submit a patch midway). Please move it under the patch tracker if possible. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29077&group_id=126 From noreply at rubyforge.org Thu Mar 17 23:13:30 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Mar 2011 23:13:30 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29088 ] undefined method `write' for # Message-ID: <20110318031331.399131858377@rubyforge.org> Bugs item #29088, was opened at 2011-03-17 22:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29088&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Josiah Kiehl (bluepojo) Assigned to: Nobody (None) Summary: undefined method `write' for # Initial Comment: http://pastie.org/1685001 When I rake install rubygems-test, it blows up: undefined method `write' for # See full trace with `gem env` at the pastie above. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29088&group_id=126 From noreply at rubyforge.org Fri Mar 18 17:54:34 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 Mar 2011 17:54:34 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29088 ] undefined method `write' for # Message-ID: <20110318215434.A52521678163@rubyforge.org> Bugs item #29088, was opened at 2011-03-17 20:13 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29088&group_id=126 Category: other >Group: v1.6.x >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Josiah Kiehl (bluepojo) >Assigned to: Eric Hodel (drbrain) Summary: undefined method `write' for # Initial Comment: http://pastie.org/1685001 When I rake install rubygems-test, it blows up: undefined method `write' for # See full trace with `gem env` at the pastie above. ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-18 14:54 Message: RubyGems uses Psych on Ruby 1.9.2+ as Syck is deprecated. You will need to update your code to require 'psych' before require 'yaml'. In this case I think the problem is in hoe which needs a release. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29088&group_id=126 From bgquest at gmail.com Sat Mar 19 13:47:19 2011 From: bgquest at gmail.com (beegee beegee) Date: Sat, 19 Mar 2011 23:17:19 +0530 Subject: [Rubygems-developers] Please help: Syntax error observed "Unexpected Token" Message-ID: Hi All, I have a mac os x tiger 10.4.11, and ruby i.8.6. I was trying to open a file using the following command $ File.open('new-inventory.txt') -bash: syntax error near unexpected token `'new-inventory.txt'' Then I tried double quotes $ File.open("new-inventory.txt") -bash: syntax error near unexpected token `"new-inventory.txt"' I also tried File.open("new-inventory.txt", "r") -bash: syntax error near unexpected token `"new-inventory.txt",' *My question is, how do I open this file (new-inventory.txt) and how do i read from it?* *Regards* * * From evan at fallingsnow.net Sat Mar 19 15:27:48 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Sat, 19 Mar 2011 12:27:48 -0700 Subject: [Rubygems-developers] Please help: Syntax error observed "Unexpected Token" In-Reply-To: References: Message-ID: You should take this up on a ruby list, this list is for rubygems developers. But I'll throw you a bone. You're trying to run ruby in your shell. Run "irb" first then type in your ruby code. - Evan On Mar 19, 2011, at 10:47 AM, beegee beegee wrote: > Hi All, > I have a mac os x tiger 10.4.11, and ruby i.8.6. I was trying to open a > file using the following command > > $ File.open('new-inventory.txt') > -bash: syntax error near unexpected token `'new-inventory.txt'' > > Then I tried double quotes > > $ File.open("new-inventory.txt") > -bash: syntax error near unexpected token `"new-inventory.txt"' > > I also tried > > File.open("new-inventory.txt", "r") > -bash: syntax error near unexpected token `"new-inventory.txt",' > > *My question is, how do I open this file (new-inventory.txt) and how do i > read from it?* > > *Regards* > * > * > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From noreply at rubyforge.org Mon Mar 21 16:57:09 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 Mar 2011 16:57:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29096 ] gem pristine command fails with NameError Gem::RemoteFetcher Message-ID: <20110321205709.E7B2B185837F@rubyforge.org> Bugs item #29096, was opened at 2011-03-21 13:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29096&group_id=126 Category: `gem` commands (remote behavior) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Arnell (aarnell) Assigned to: Nobody (None) Summary: gem pristine command fails with NameError Gem::RemoteFetcher Initial Comment: You can see the output from the command here: https://gist.github.com/0a77cd75114756dfff60#file_raw_gem_pristine.log This was achieved using rubygems 1.6.2 on Ruby 1.9.2-p180. When I add a require 'rubygems/remote_fetcher' to the require list of the pristine_command.rb file it fixes the problem. However I am not familiar enough with the source code to say whether this is the best fix or not. A quick check in the install_command shows me that the remote_fetcher can be required elsewhere to make remote commands work. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29096&group_id=126 From noreply at rubyforge.org Tue Mar 22 14:53:29 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 22 Mar 2011 14:53:29 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29098 ] Installer fails with Cygwin Message-ID: <20110322185329.AC8671858361@rubyforge.org> Bugs item #29098, was opened at 2011-03-22 13:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29098&group_id=126 Category: RubyGems installer (setup.rb) Group: v1.6.x Status: Open Resolution: None Priority: 3 Submitted By: Dan Hetherington (repentorperish) Assigned to: Nobody (None) Summary: Installer fails with Cygwin Initial Comment: This is the output trying to install 1.6.2 inside cygwin: 14:45 Slack at vaio:~/mydocs/Downloads/rubygems-1.6.2$ ruby setup.rb install ./lib/rubygems/custom_require.rb:54: warning: parenthesize argument(s) for future version ./lib/rubygems/dependency.rb:203: warning: parenthesize argument(s) for future version ./lib/rubygems/dependency.rb:204: warning: parenthesize argument(s) for future version ./lib/rubygems/custom_require.rb:57:in `require': undefined method `end_with?' for "no such file to g (NoMethodError) from ./lib/rubygems.rb:695:in `load_yaml' from ./lib/rubygems/config_file.rb:231:in `load_file' from ./lib/rubygems/config_file.rb:178:in `initialize' from ./lib/rubygems/gem_runner.rb:76:in `new' from ./lib/rubygems/gem_runner.rb:76:in `do_configuration' from ./lib/rubygems/gem_runner.rb:49:in `run' from setup.rb:35 This is the current default version of ruby in cygwin (I updated a few days ago): 14:45 Slack at vaio:~/mydocs/Downloads/rubygems-1.6.2$ ruby --version ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] Windows XP SP 3. Much the same happens with 1.6.0: ./lib/rubygems/custom_require.rb:49: warning: parenthesize argument(s) for future version ./lib/rubygems/dependency.rb:203: warning: parenthesize argument(s) for future version ./lib/rubygems/dependency.rb:204: warning: parenthesize argument(s) for future version ./lib/rubygems/custom_require.rb:52:in `require': undefined method `end_with?' for "no such file to g (NoMethodError) from ./lib/rubygems.rb:694:in `load_yaml' from ./lib/rubygems/config_file.rb:231:in `load_file' from ./lib/rubygems/config_file.rb:178:in `initialize' from ./lib/rubygems/gem_runner.rb:76:in `new' from ./lib/rubygems/gem_runner.rb:76:in `do_configuration' from ./lib/rubygems/gem_runner.rb:49:in `run' from setup.rb:35 I also tried a really old version (1.3.7): the installation seems to work but Cygwin gem doesn't seem to have ended up anywhere Cygwin can find it (see below). Sorry if I'm missing something obvious but Google drew a complete blank. 14:48 Slack at vaio:~/mydocs/Downloads/rubygems-1.3.7$ ruby setup.rb install RubyGems 1.3.7 installed ???=== 1.3.7 / 2010-05-13 NOTE: http://rubygems.org is now the default source for downloading gems. You may have sources set via ~/.gemrc, so you should replace http://gems.rubyforge.org with http://rubygems.org http://gems.rubyforge.org will continue to work for the forseeable future. New features: * `gem` commands * `gem install` and `gem fetch` now report alternate platforms when a matching one couldn't be found. * `gem contents` --prefix is now the default as specified in --help. Bug #27211 by Mamoru Tasaka. * `gem fetch` can fetch of old versions again. Bug #27960 by Eric Hankins. * `gem query` and friends output now lists platforms. Bug #27856 by Greg Hazel. * `gem server` now allows specification of multiple gem dirs for documentation. Bug #27573 by Yuki Sonoda. * `gem unpack` can unpack gems again. Bug #27872 by Timothy Jones. * `gem unpack` now unpacks remote gems. * --user-install is no longer the default. If you really liked it, see Gem::ConfigFile to learn how to set it by default. (This change was made in 1.3.6) * RubyGems now has platform support for IronRuby. Patch #27951 by Will Green. Bug fixes: * Require rubygems/custom_require if --disable-gem was set. Bug #27700 by Roger Pack. * RubyGems now protects against exceptions being raised by plugins. * rubygems/builder now requires user_interaction. Ruby Bug #1040 by Phillip Toland. * Gem::Dependency support #version_requirements= with a warning. Fix for old Rails versions. Bug #27868 by Wei Jen Lu. * Gem::PackageTask depends on the package dir like the other rake package tasks so dependencies can be hooked up correctly. ------------------------------------------------------------------------------ RubyGems installed the following executables: C:/ruby/bin/gem 14:49 Slack at vaio:~/mydocs/Downloads/rubygems-1.3.7$ gem C:\ruby\bin\ruby.exe: No such file or directory -- /cygdrive/c/ruby/bin/gem (LoadError) 14:49 Slack at vaio:~/mydocs/Downloads/rubygems-1.3.7$ gem env C:\ruby\bin\ruby.exe: No such file or directory -- /cygdrive/c/ruby/bin/gem (LoadError) 14:49 Slack at vaio:~/mydocs/Downloads/rubygems-1.3.7$ which gem /cygdrive/c/ruby/bin/gem ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29098&group_id=126 From noreply at rubyforge.org Tue Mar 22 17:56:14 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 22 Mar 2011 17:56:14 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29098 ] Installer fails with Cygwin Message-ID: <20110322215614.3BADF1858300@rubyforge.org> Bugs item #29098, was opened at 2011-03-22 11:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29098&group_id=126 Category: RubyGems installer (setup.rb) Group: v1.6.x >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Dan Hetherington (repentorperish) >Assigned to: Eric Hodel (drbrain) Summary: Installer fails with Cygwin Initial Comment: This is the output trying to install 1.6.2 inside cygwin: 14:45 Slack at vaio:~/mydocs/Downloads/rubygems-1.6.2$ ruby setup.rb install ./lib/rubygems/custom_require.rb:54: warning: parenthesize argument(s) for future version ./lib/rubygems/dependency.rb:203: warning: parenthesize argument(s) for future version ./lib/rubygems/dependency.rb:204: warning: parenthesize argument(s) for future version ./lib/rubygems/custom_require.rb:57:in `require': undefined method `end_with?' for "no such file to g (NoMethodError) from ./lib/rubygems.rb:695:in `load_yaml' from ./lib/rubygems/config_file.rb:231:in `load_file' from ./lib/rubygems/config_file.rb:178:in `initialize' from ./lib/rubygems/gem_runner.rb:76:in `new' from ./lib/rubygems/gem_runner.rb:76:in `do_configuration' from ./lib/rubygems/gem_runner.rb:49:in `run' from setup.rb:35 This is the current default version of ruby in cygwin (I updated a few days ago): 14:45 Slack at vaio:~/mydocs/Downloads/rubygems-1.6.2$ ruby --version ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] Windows XP SP 3. Much the same happens with 1.6.0: ./lib/rubygems/custom_require.rb:49: warning: parenthesize argument(s) for future version ./lib/rubygems/dependency.rb:203: warning: parenthesize argument(s) for future version ./lib/rubygems/dependency.rb:204: warning: parenthesize argument(s) for future version ./lib/rubygems/custom_require.rb:52:in `require': undefined method `end_with?' for "no such file to g (NoMethodError) from ./lib/rubygems.rb:694:in `load_yaml' from ./lib/rubygems/config_file.rb:231:in `load_file' from ./lib/rubygems/config_file.rb:178:in `initialize' from ./lib/rubygems/gem_runner.rb:76:in `new' from ./lib/rubygems/gem_runner.rb:76:in `do_configuration' from ./lib/rubygems/gem_runner.rb:49:in `run' from setup.rb:35 I also tried a really old version (1.3.7): the installation seems to work but Cygwin gem doesn't seem to have ended up anywhere Cygwin can find it (see below). Sorry if I'm missing something obvious but Google drew a complete blank. 14:48 Slack at vaio:~/mydocs/Downloads/rubygems-1.3.7$ ruby setup.rb install RubyGems 1.3.7 installed ???=== 1.3.7 / 2010-05-13 NOTE: http://rubygems.org is now the default source for downloading gems. You may have sources set via ~/.gemrc, so you should replace http://gems.rubyforge.org with http://rubygems.org http://gems.rubyforge.org will continue to work for the forseeable future. New features: * `gem` commands * `gem install` and `gem fetch` now report alternate platforms when a matching one couldn't be found. * `gem contents` --prefix is now the default as specified in --help. Bug #27211 by Mamoru Tasaka. * `gem fetch` can fetch of old versions again. Bug #27960 by Eric Hankins. * `gem query` and friends output now lists platforms. Bug #27856 by Greg Hazel. * `gem server` now allows specification of multiple gem dirs for documentation. Bug #27573 by Yuki Sonoda. * `gem unpack` can unpack gems again. Bug #27872 by Timothy Jones. * `gem unpack` now unpacks remote gems. * --user-install is no longer the default. If you really liked it, see Gem::ConfigFile to learn how to set it by default. (This change was made in 1.3.6) * RubyGems now has platform support for IronRuby. Patch #27951 by Will Green. Bug fixes: * Require rubygems/custom_require if --disable-gem was set. Bug #27700 by Roger Pack. * RubyGems now protects against exceptions being raised by plugins. * rubygems/builder now requires user_interaction. Ruby Bug #1040 by Phillip Toland. * Gem::Dependency support #version_requirements= with a warning. Fix for old Rails versions. Bug #27868 by Wei Jen Lu. * Gem::PackageTask depends on the package dir like the other rake package tasks so dependencies can be hooked up correctly. ------------------------------------------------------------------------------ RubyGems installed the following executables: C:/ruby/bin/gem 14:49 Slack at vaio:~/mydocs/Downloads/rubygems-1.3.7$ gem C:\ruby\bin\ruby.exe: No such file or directory -- /cygdrive/c/ruby/bin/gem (LoadError) 14:49 Slack at vaio:~/mydocs/Downloads/rubygems-1.3.7$ gem env C:\ruby\bin\ruby.exe: No such file or directory -- /cygdrive/c/ruby/bin/gem (LoadError) 14:49 Slack at vaio:~/mydocs/Downloads/rubygems-1.3.7$ which gem /cygdrive/c/ruby/bin/gem ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2011-03-22 14:56 Message: Upgrade your ruby, RubyGems 1.3.7 is the last version that supported ruby 1.8.6 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29098&group_id=126 From noreply at rubyforge.org Wed Mar 23 19:25:23 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 Mar 2011 19:25:23 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-29096 ] gem pristine command fails with NameError Gem::RemoteFetcher Message-ID: <20110323232523.58BC91858317@rubyforge.org> Bugs item #29096, was opened at 2011-03-21 13:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29096&group_id=126 Category: `gem` commands (remote behavior) Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Alex Arnell (aarnell) >Assigned to: Ryan Davis (zenspider) Summary: gem pristine command fails with NameError Gem::RemoteFetcher Initial Comment: You can see the output from the command here: https://gist.github.com/0a77cd75114756dfff60#file_raw_gem_pristine.log This was achieved using rubygems 1.6.2 on Ruby 1.9.2-p180. When I add a require 'rubygems/remote_fetcher' to the require list of the pristine_command.rb file it fixes the problem. However I am not familiar enough with the source code to say whether this is the best fix or not. A quick check in the install_command shows me that the remote_fetcher can be required elsewhere to make remote commands work. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29096&group_id=126 From jeremy at hinegardner.org Fri Mar 25 18:28:10 2011 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Fri, 25 Mar 2011 16:28:10 -0600 Subject: [Rubygems-developers] [ANN] stickler 2.1.0 released Message-ID: <20110325222810.GU8939@hinegardner.org> stickler version 2.1.0 by Jeremy Hinegardner http://www.copiousfreetime.org/projects/stickler == DESCRIPTION Stickler is a tool to organize and maintain an internal gem repository. Primarily, you would want to use Stickler if: 1. You have proprietary gems that you want to have available via a gem server so you may 'gem install' them. 2. You would like to have a local mirror of third party gems from either http://rubygems.org or some other gem server. 3. You want both (1) and (2) in the same server. == CHANGES Version 2.1.0 - 2011-03-25 -------------------------- * Added 'list' client command * Added support for prerelease gems * Internal refactoring of how internal repositories are managed * Refactored testing and updated to rspec2 * Switched underlying HTTP client to Excon * Change to ISC License -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org