Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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.