202688 2007-12-18 13:25 0000 dev-ruby/activesupport-2.0.2 installation fails 2008-01-16 05:52:50 0000 1 1 1 Unclassified Gentoo Linux Ebuilds 2007.0 All Linux RESOLVED FIXED P2 normal --- 202013 1 fmccor@gentoo.org ruby@gentoo.org amd64@gentoo.org exlevan@gmail.com gentoo-bugs@nexus10.com harrisl@lhjonline.com jer@gentoo.org massimo.fantin@alice.it mike@nerone.org netzdamon@gmail.com nobrow@eircom.net sparc@gentoo.org sum.notify@gmail.com theblackpeter@gmail.com fmccor@gentoo.org 2007-12-18 13:25:52 0000 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 fmccor@gentoo.org 2007-12-18 13:34:24 0000 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. rbrown@gentoo.org 2007-12-18 15:13:12 0000 It appears to be because gems creates with rubygems-0.9.5 are not backwards compatible. rbrown@gentoo.org 2007-12-18 22:46:47 0000 *** Bug 202728 has been marked as a duplicate of this bug. *** harrisl@lhjonline.com 2007-12-18 23:55:21 0000 After unmasking and installing rubygems-0.9.5 everything installs properly on amd64. I haven't tested anything yet. graaff@gentoo.org 2007-12-19 06:50:28 0000 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. theblackpeter@gmail.com 2007-12-19 08:17:00 0000 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. graaff@gentoo.org 2007-12-19 08:25:58 0000 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. uzytkownik2@gmail.com 2007-12-19 11:23:54 0000 The same buf on ~x86. Solutions: - Mask rails 2.0 (noooo ;) ) and add dependence to rubygems? - Unmask rubygems and add depencence for rubygem? graaff@gentoo.org 2007-12-19 14:58:17 0000 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. jer@gentoo.org 2007-12-19 15:44:05 0000 (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 :) jakub@gentoo.org 2007-12-20 07:55:09 0000 *** Bug 202838 has been marked as a duplicate of this bug. *** gentoo-bugs@nexus10.com 2007-12-20 12:41:07 0000 (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) exlevan@gmail.com 2007-12-22 22:51:11 0000 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 exlevan@gmail.com 2007-12-22 23:02:28 0000 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 graaff@gentoo.org 2007-12-23 15:55:08 0000 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. jakub@gentoo.org 2007-12-26 12:02:25 0000 *** Bug 203372 has been marked as a duplicate of this bug. *** nichoj@gentoo.org 2008-01-09 02:36:05 0000 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. nichoj@gentoo.org 2008-01-09 02:36:31 0000 Created an attachment (id=140518) proposed changes to gems.eclass nichoj@gentoo.org 2008-01-15 03:35:12 0000 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. graaff@gentoo.org 2008-01-15 07:00:25 0000 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 nichoj@gentoo.org 2008-01-15 14:38:16 0000 (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. nichoj@gentoo.org 2008-01-16 04:36:00 0000 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. nichoj@gentoo.org 2008-01-16 05:52:50 0000 Fixed in CVS. 140518 2008-01-09 02:36 0000 proposed changes to gems.eclass gems.patch text/plain SW5kZXg6IGdlbXMuZWNsYXNzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC92YXIvY3Zzcm9vdC9nZW50 b28teDg2L2VjbGFzcy9nZW1zLmVjbGFzcyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xOApkaWZm IC11IC1CIC1yMS4xOCBnZW1zLmVjbGFzcwotLS0gZ2Vtcy5lY2xhc3MJMTcgU2VwIDIwMDcgMDQ6 NTk6MjkgLTAwMDAJMS4xOAorKysgZ2Vtcy5lY2xhc3MJOSBKYW4gMjAwOCAwMjoxNzoxMSAtMDAw MApAQCAtMjUsMTIgKzI1LDkgQEAKIAogSVVTRT0iZG9jIgogCi1ERVBFTkQ9Ij49ZGV2LXJ1Ynkv cnVieWdlbXMtMC44LjQtcjEKK0RFUEVORD0iPj1kZXYtcnVieS9ydWJ5Z2Vtcy0wLjkuNAogCSFk ZXYtcnVieS9yZG9jIgogCi1TPSR7V09SS0RJUn0KLQotCiBnZW1zX2xvY2F0aW9uKCkgewogCWxv Y2FsIHNpdGVsaWJkaXIKIAlzaXRlbGliZGlyPWBydWJ5IC1yIHJiY29uZmlnIC1lICdwcmludCBD b25maWc6OkNPTkZJR1sic2l0ZWxpYmRpciJdJ2AKQEAgLTczLDEyICs3MCw2IEBACiAJZG9kaXIg JHtHRU1TRElSfQogCWdlbSBpbnN0YWxsICR7R0VNX1NSQ30gLXYgJHtQVn0gJHtteWNvbmZ9IC1s IC1pICR7RH0vJHtHRU1TRElSfSB8fCBkaWUgImdlbSBpbnN0YWxsIGZhaWxlZDogZ2VtLSQoZ2Vt IC0tdmVyc2lvbikgaW5zdGFsbCAke0dFTV9TUkN9IC12ICR7UFZ9ICR7bXljb25mfSAtbCAtaSAk e0R9LyR7R0VNU0RJUn0iCiAKLQkjIFRoaXMgaXMgYSB3b3JrYXJvdW5kIGZvciA8PXJ1YnlnZW1z LTAuOS4wLjggYmVjYXVzZSBpdCdzIGV4aXRzdGF0dXMgZXF1YWxzIDAKLQkjIGV2ZW4gaWYgdGhl IGRlcGVuZGVuY2llcyBhcmUgbm90IGZvdW5kLiBTbyB3ZSBhcmUgdGVzdGluZyBpZiBydWJ5Z2Vt cyBhdAotCSMgbGVhc3QgaW5zdGFsbGVkIHRoZSBnZW1zcGVjICh3aGljaCBzaG91bGQgYWx3YXlz IG9jY3VyIG90aGVyd2lzZSkuCi0JIyBTZWUgYnVnICMxMDQ3MzMKLQl0ZXN0IC1mICR7c3BlY19w YXRofSB8fCBkaWUgImdlbSBpbnN0YWxsIGZhaWxlZCAoc3BlYyBmaWxlICR7c3BlY19wYXRofSBt aXNzaW5nKSIKLQogCWlmIFsgLWQgJHtEfS8ke0dFTVNESVJ9L2JpbiBdIDsgdGhlbgogCQlleGVp bnRvIC91c3IvYmluCiAJCWZvciBleGUgaW4gJHtEfS8ke0dFTVNESVJ9L2Jpbi8qIDsgZG8K