Ruby 1.8.3 and RubyGems

[Tom Copeland]

Hi all -

There seems to be a problem with Ruby 1.8.3 and RubyGems; it's a YAML
thing that _why already knows about and (I think?) has already fixed.

But at any rate, the effect is that the gem server on RubyForge can't
process RubyGems that were built by Ruby 1.8.3. So the following Gems
have been uploaded/released on RubyForge but can't be downloaded. By
that I mean that they can't be put in the gems directory so that folks
can grab them with "gem install kwatable-0.1.0" or whatever:

vim-ruby-2005.09.24.gem
rstyx-0.1.0.gem
rrt_ruby-0.2.0-mswin32.gem
g-gem-0.1.0.gem
hostipinfo-0.1.0.gem
kwatable-0.1.0.gem
RubyInline-3.5.0.gem
ParseTree-1.4.0.gem
rcss-0.3.0.gem

My apologies to the folks who released the above-listed gems; you may
want to rebuild them using Ruby 1.8.2 and re-release them on RubyForge.
Doing a "delete" and "add" of the file in the "File Releases" section
should do the trick.

Yours,

tom

 

[Caleb Tennis]

My apologies to the folks who released the above-listed gems; you may

want to rebuild them using Ruby 1.8.2 and re-release them on RubyForge.
Doing a "delete" and "add" of the file in the "File Releases" section
should do the trick.

Please please please don't do this. Release a new version instead (and delete
the old one if you so desire). Changing the md5sum of an already released
package makes things very uncomfortable for downstream distribution
packagers.

Caleb

 

[Tom Copeland]

Please please please don't do this. Release a new version instead (and delete
the old one if you so desire). Changing the md5sum of an already released
package makes things very uncomfortable for downstream distribution
packagers.

Ah, good thought. Right on.

Yours,

Tom

 

[Sylvain Joyeux]

There seems to be a problem with Ruby 1.8.3 and RubyGems; it's a YAML

thing that _why already knows about and (I think?) has already fixed.

Does anybody knows it it *is* fixed for sure, and where ? (In Ruby CVS ? In
RubyGems CVS ?)