On 1/11/07, Anthony Eden <[EMAIL PROTECTED]> wrote: > On 1/11/07, Anthony Eden <[EMAIL PROTECTED]> wrote: > > On 1/11/07, Anthony Eden <[EMAIL PROTECTED]> wrote: > > > On 1/11/07, Anthony Eden <[EMAIL PROTECTED]> wrote: > > > > On 1/7/07, Jim Freeze <[EMAIL PROTECTED]> wrote: > > > > > > > > > > On Jan 7, 2007, at 7:35 PM, Eric Hodel wrote: > > > > > > > > > > > > > > > Its a bug somewhere, but where exactly is uncertain still. > > > > > > > > > > Did source_cache already exist, or were these systems virgin? > > > > > > > > > > These were all new systems - no ruby in site. > > > > > > > > > > > > > > > There have been problems with source_cache being hosed since RubyGems > > > > > 0.9.0, but I'm unsure if that's due to RubyGems changes or Ruby > > > > > changes. I'm trying to collect corrupt source_cache files to > > > > > reproduce the problem. > > > > > > > > > > Hmm, well, the problem may have been my fault. I installed rubygems > > > > > 0.8.11 > > > > > on each of these systems and immediately did update --system. > > > > > > > > > > I just noticed that there is a 0.9.0 version of rubygems. I will use > > > > > that in > > > > > the future. > > > > > But, seems all the upgrades from 0.8.11 are going to fail. Maybe a > > > > > quick fix > > > > > would > > > > > be just to have 'update --system' to just delete source_cache. :) > > > > > > > > > > > > > > > > > > > > > > > > > Jim Freeze > > > > > > > > I just got bit by this same bug, so I've attached my source_cache so > > > > you can have a look at it. What it looks like to me is that cache > > > > entries used to be stored as Hashes and now they should be > > > > Gem::SourceInfoCacheEntry. Unfortunately the cache loader will not > > > > create new cache entries if one already exists, so it loads the Hash > > > > instances and then tries to call the non-existent method source_index. > > > > > > > > IMHO, the best thing to do is to blow out the source_cache > > > > automatically during the install process, if at all possible. > > > > > > Well, it looks like my analysis of the problem may have been > > > premature. I blew out my source_cache and the problem still exists. > > > I'm debugging now. > > > > > > First message didn't make it to the list because I attached my > > source_cache. Eric, if you want my source_cache just let me know and > > I'll send it directly to you. > > > > Back to debugging... > > > > V/r > > Anthony > > OK, I think I have found something of interest. I put in some puts > lines and found this: > > [/usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb,37] > retrieving the cache > [/usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb,87] > refreshing the cache data > [/usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb,90] > cache_entry is a Gem::SourceInfoCacheEntry > [/usr/local/lib/ruby/site_ruby/1.8/rubygems/remote_installer.rb,81] > http://gems.rubyforge.org: sic_entry is a Gem::SourceInfoCacheEntry > [/usr/local/lib/ruby/site_ruby/1.8/rubygems/remote_installer.rb,81] > http://dist.leetsoft.com: sic_entry is a Hash > > As you can see then, it's actually a remote repository that is > returning a Hash instead of a Gem::SourceInfoCacheEntry. > > I haven't come up with a patch yet as I figure someone who knows the > internals of rubygems might be able to do it quicker, however I'll be > happy to dig around and create one if necessary, just let me know. > > V/r > Anthony >
I blew out my user cache ~/.gem/source_cache in addition to the system one and the problem went away, so I suppose my initial interpretation was correct but incomplete. So, I suppose blowing out the system and user cache on install may still be the easiest solution. V/r Anthony -- Cell: 808 782-5046 Current Location: Melbourne, FL _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
