Upgrade to actionpack-2.0.2 fails for me on sparc and 2 different amd64s with: * gem install failed (spec file /var/tmp/portage/dev-ruby/activesupport-2.0.2/image///usr/lib/ruby/gems/1.8/specifications/activesupport-2.0.2.gemspec missing) (on amd64, the "lib" bit is "lib64") Relevant to this, perhaps, on both systems, I have: Sat Aug 18 13:55:39 2007 >>> sys-devel/autoconf-2.61-r1 Mon Oct 22 11:31:49 2007 >>> dev-lang/ruby-1.8.6_p110-r2 Mon Nov 19 12:44:11 2007 >>> dev-ruby/rubygems-0.9.4-r2 (Dates are perhaps different on the two systems, but that sequence of events is the same on both.) Note that "emerge =dev-ruby/activesupport-1.4.4" works fine. All systems are pretty standard at profile 2007.0
Just a note: One of the failing systems (amd64) did not have rails installed on it at all, and an installation of rails (stable for amd64) went fine on that system.
It appears to be because gems creates with rubygems-0.9.5 are not backwards compatible.
*** Bug 202728 has been marked as a duplicate of this bug. ***
After unmasking and installing rubygems-0.9.5 everything installs properly on amd64. I haven't tested anything yet.
I've just masked Rails 2.0.2 and its dependencies while we figure out what the right approach is. No need to generate tons of duplicates for this.
Looks like gem is not finding activesupport-2.0.2.gemspec. A quick look in /var/tmp/portage/dev-ruby/activesupport-2.0.2/image///usr/lib/ruby/gems/1.8/specifications/ revels that the file is named activesupport-2.0.2-.gemspec. I'm guessing it might be line 114 in /var/tmp/portage/dev-ruby/activesupport-2.0.2/temp/environment, conf=activesupport-2.0.2-r0 that gets parsed wrong.
The problem is that the rails gems don't set a particular setting that seems to have become mandatory with rubygems 0.9.5. See upstream bug http://dev.rubyonrails.org/ticket/10541 for details. It's fixed in upstream's source repository, but no new gems have been generated yet.
The same buf on ~x86. Solutions: - Mask rails 2.0 (noooo ;) ) and add dependence to rubygems? - Unmask rubygems and add depencence for rubygem?
I already masked Rails 2.0.x. Complain to upstream who messed up and didn't do proper testing. Unmasking rubygems 0.9.5 isn't an option right now because it seems to be broken in more ways then one. My solution is to wait for a new upstream release, since the problem has been fixed upstream I suspect this won't take long.
(In reply to comment #9) > I already masked Rails 2.0.x. Complain to upstream who messed up and didn't do > proper testing. Having users complaining upstream is exactly what you took on to prevent when you got onboard the Ruby team. As for laying the blame, that's an entirely different matter :)
*** Bug 202838 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Unmasking rubygems 0.9.5 isn't an option right now because it seems to be > broken in more ways then one. Hans, Any pointers what to look out for? Is it just the problem at http://bugs.gentoo.org/show_bug.cgi?id=202109#c5 - not able to find YAML? I'm running ruby and rubygems~x86 and using gem install for everything else (rails 2.0.2 etc) with my /etc/package.unmask as =dev-ruby/rubygems-0.9.5 and so far everything is running sweetly. `gem outdated` worked fine; `gem update` works fine, results in `gem outdated` producing clean (empty) output. I have activesupport-2.0.2 showing as installed ok. Current app has clean Test::Unit and RSpec output: units: 103 tests, 365 assertions, 0 failures, 0 errors functionals: 1198 tests, 13204 assertions, 0 failures, 0 errors integration: 2 tests, 11 assertions, 0 failures, 0 errors so I'm not sure where to look for potential problems. Anything I could productively test? Regards, Thomas. `gem list` output: # gem list *** LOCAL GEMS *** actionmailer (2.0.2, 2.0.1, 1.3.6, 1.3.3) actionpack (2.0.2, 2.0.1, 1.13.6, 1.13.3) actionwebservice (1.2.6, 1.2.3) activerecord (2.0.2, 2.0.1, 1.15.6, 1.15.3) activeresource (2.0.2, 2.0.1) activesupport (2.0.2, 2.0.1, 1.4.4, 1.4.2) builder (2.1.2) capistrano (2.1.0, 2.0.0, 1.4.1) cgi_multipart_eof_fix (2.5.0, 2.1) daemons (1.0.9, 1.0.7) fastthread (1.0.1, 1.0) ferret (0.11.6) gem_plugin (0.2.3, 0.2.2) gettext (1.10.0) highline (1.4.0) maruku (0.5.7, 0.5.6) mime-types (1.15) money (1.7.1) mongrel (1.1.2, 1.1.1, 1.0.1) mongrel_cluster (1.0.5, 1.0.2) needle (1.3.0) net-sftp (1.1.0) net-ssh (1.1.2) payment (1.0.1) postgres (0.7.9.2007.12.12, 0.7.1) rails (2.0.2, 2.0.1, 1.2.6, 1.2.3) rake (0.7.3) RedCloth (3.0.4) rmagick (1.15.11, 1.15.7) rspec (1.1.1, 1.0.8, 1.0.5) ruby-lsapi (2.8, 2.5) rubygems-update (1.0.0, 0.9.5, 0.9.4) shipping (1.5.1) spreadsheet-excel (0.3.5.1) syntax (1.0.0)
To install actionpack-2.0.2, line 5 of metadata file in activerecord-2.0.2.gem must be deleted. The line is: platform: "" It handles incorrectly dy gem installator, it creates file var/tmp/portage/dev-ruby/activesupport-2.0.2/image///usr/lib/ruby/gems/1.8/specifications/activesupport-2.0.2-.gemspec instead of var/tmp/portage/dev-ruby/activesupport-2.0.2/image///usr/lib/ruby/gems/1.8/specifications/activesupport-2.0.2.gemspec
Looks like gems.eclass is incorrect, not gem: file /usr/portage/eclass/gems.eclass, line51 spec_path=${D}/${GEMSDIR}/specifications/${P}.gemspec But gem creates file like "#{@name}-#{@version}-#{platform}", not "#{@name}-#{@version}". (See specification.rb, lines 495-501) So bug can be also fixed by fixing gems.eclass
I had a brief look at this just know, but I don't think the situation is as clear-cut as comment 14 seems to make out. The actual name that is generated for a gem is dependant on the value of platform, and may in fact be left off. This should be the default for gems installed for Gentoo, as far as I can tell, because we compile any extensions anyway. This is the same as the platform Ruby. The problem with the Rails ebuilds was that platform was actually the empty string, and thus the platform was not default and thus not dropped. This has been fixed in upstream's SVN and will hopefully be released shortly. Too bad we don't have an easy way to patch gems... Alexey, perhaps I'm misunderstanding your proposed fix? It would be great to see a patch that works with rubygems 0.9.4 and rubygems 1.0.1 and gems created with either version.
*** Bug 203372 has been marked as a duplicate of this bug. ***
I did some preliminary work for an eclass to build gems from source, so we could apply the upstream patch. I got it enough so it does build and install the gem... but it fails at the same place. It's failing at the line in the eclass where it checks for the spec, but doesn't find it because it's named activesupport-2.0.2-.spec instead of spec. This line looks like it was added as a workaround for an old, old version of rubygems, 0.9.0.8, not properly returning exit status. So, checking the prescence of the gemspec was a way to verify it being around. Since we have 0.9.4 stable, I think we could safely turn up the dependency in the eclass, and remove the workaround.
Created attachment 140518 [details] proposed changes to gems.eclass
I just tested emerging every ~x86 gem in the tree with the patch with both rubygems 0.9.4 and 1.0.1 without any issue.
The only remaining problem I see is that mips is still on rubygems 0.8.6. The good news, however, is that rubygems 1.0.1 is now keyworded by mips, so we have an upgrade path. mips would have to mark rubygems 1.0.1 stable, though, to keep a stable version... Proposed steps: 1. unmask rubygems 1.0.1 (Richard, you mentioned that this was good to go?) 2. remove rubygems 0.8.11-r6 3. apply this patch to gems.eclass 4. unmask rails 2.0.2
(In reply to comment #20) > mips would have to mark rubygems 1.0.1 stable, though, to keep > a stable version... So, we'd have to wait 30 days after it gets unmasked. That's pretty undesirable. I looked at the changelog, and I don't really see a reason why 0.9.x wouldn't have had ~mips, which is a little annoying. It may be worth checking how many packages which use gems have stable keywords for mips. Maybe there aren't any, in which case we'd be alright without a stable rubygems on mips.
Only one package, ruby-postgres, was stable with mips keywords. After talking with Redhatter, apparently postgres is broken on mips, so it was ok to drop. Doing some final testing, but I plan on going ahead with the patch.
Fixed in CVS.
