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. 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
