hoodwink.d enhanced


Ruby 1.8.3 Has Been Released #

by daigo in inspect

Ruby 1.8.3 has been released. Thank you for the developers and users.

Mirror: http://rubyforge.org/frs/download.php/6155/ruby-1.8.3.tar.gz
md5sum: 63d6c2bddd6af86664e338b31f3189a6

In ruby-dev mail list for Japanese guys are trying to write what’s new in 1.8.3, a press release for media and so on, but nobody works them yet.

Akira Yamada, a maintainer of ruby package in Debian, blogged that he would make the new package as soon as possible.

This includes a vulnerability fix.

The diagram in this Japanese document describes a bit detail of the vulnerability. It says that using plugins (which denote making instances in eval?) you could pass through Ruby security sandbox system.

Debian package ruby1.8 1.8.3-1 is out in unstable.

Matz talked about 1.8.4 release plan. 24 Dec will be the day. If an urgent release is required, (i) 1.8.4 might be out before the day or (ii) might be released.

said on 20 Sep 2005 at 20:22

Mirrored here.

said on 20 Sep 2005 at 21:05

gemstones glow !! fleeting response !! velvet-like goosebumps !!


said on 20 Sep 2005 at 21:36

It br0ked my Rails. :-(

said on 20 Sep 2005 at 22:05

Rails now asks “What is this logger you speak of?” to which I cannot reply… :-(

said on 20 Sep 2005 at 23:13

Mister Cat, blame the clean_logger.rb file under activesupport (which may have come from Nitro – I’m not sure who was first).

Anyway, that whole file is an abomination and should be burned before its infection spreads, it’s ashes scattered across the ocean to prevent it from ever reforming again.

The good news is that I’m pretty sure this can be fixed in a backwards compatible way.

said on 21 Sep 2005 at 01:03

Good news, indeed. Except that rubygems still isn’t included. That needs to happen soon.

said on 21 Sep 2005 at 01:12

Matz is really cookin, guys! We’re cruising through bugs in Basecamp. Matz did the honorable thing and followed his roadmap precisely. (Bow.)

said on 21 Sep 2005 at 06:56

So where’s the changelog? Why should I care? Huh? Huh?

said on 21 Sep 2005 at 09:02

Was this announcement sent to the ruby-talk list? It’s not a big deal, I may have just missed it, what with all of the messages about the “Ruby Troll” in comp.lang.perl.misc clogging up my mailbox.

said on 21 Sep 2005 at 09:41

Most excellent. Hopefully it will build on HP-UX. I need it.

For work. Yeah.

said on 21 Sep 2005 at 09:58

Does anyone know why rubygems isn’t included (yet)?

said on 21 Sep 2005 at 11:28

Matz has just noted 1.8.4 milestones in Basecamp. API freeze on December 1st. Release on December 24th.

said on 21 Sep 2005 at 15:18

_why: Where can we see the 1.8.4 milestones in Basecamp? Is there a URL ? Is rubygems included?

said on 21 Sep 2005 at 15:31

Hopefully the Debian Ruby guys won’t get too put off by the current bunfight over on ruby-devel….I’ve just got comfy on etch, don’t fancy moving again for a few weeks at least..

said on 22 Sep 2005 at 01:15

rasputnik: Well, since I’ve just updated Ruby to 1.8.3 this morning on my Unstable Debian box, it seems they didn’t ;) . And then they say Debian takes forever to repackage things ;) .

And I have to say I agree with the Debian maintainers here more than with the Rubygems people (the Debian package system saved me countless times already, when I broke things by being too enthusiastic with my Unstable Debian Box). Making Rubygems standard as it is now would be wrong. But my opinion on this issue is already known . Make it transparent, and then only it will be a good candidate to become part of the standard library.

said on 22 Sep 2005 at 12:25

Tsela, RubyGems doesn’t need to support Debian. It needs to support Ruby, which universe is larger than just Debian, despite what Debian bigots like to think. I, for one, am quite glad that RubyGems doesn’t bow to Debian snobbery.

said on 22 Sep 2005 at 14:14

Austin: you might have noticed that I don’t mention the point you make. I don’t care if Rubygems support Debian or not (I do care when it actively makes it difficult to repackage things though, because if you followed the thread on ruby-dev you might have noticed that other people have problems, and are not Debian people. That’s what I was referring to when I was saying that I was inclined to agree with the Debian people there).

What I care about is that a package manager should be transparent. It shouldn’t matter whether a library has been installed through the package manager of my distro, manually through setup.rb or through Rubygems. Rubygems isn’t transparent, and instead forces its presence to the developer. That’s what I don’t agree with. First solve that problem, and then it can be put in the standard library.

said on 23 Sep 2005 at 00:15

Will RubyGems be included in 1.8.4?

said on 23 Sep 2005 at 09:19

Wait, so would apt be able to manage a package that RubyGems installed?

I’m confused, how transparent are all the various package-managers?

said on 23 Sep 2005 at 10:12

Danno: they’re not, and Tsela is complaining about a non-problem. RubyGems, when incorporated into the Ruby core, will be completely transparent. This has been the plan from day one, and people complaining about the lack of transparency (e.g., require_gem, require ‘rubygems’) have pretty much not understood that these are all temporary hacks. PDF ::Writer does not have anything special in it to support RubyGems, but instead depends on the user to have RUBYOPT =rubygems set or run ruby with -rubygems. That’s about as transparent as you can get until Ruby’s default require understands the RubyGems installations.

said on 23 Sep 2005 at 11:29

If some obscure arguments over Debian are what’s keeping RubyGems out of the std Ruby distro, then that’s really wrong. The vast majority of us don’t run Debian – most of us are on OS X , Windows, or other Linux distros (I personally run OS X and Gentoo). Why is some small group (probably less than 5%) holding up RubyGems goodness? Come on, get some perspective! Get on the RubyGems train, or get out of the way!

I really don’t care about some obscure problem with Debian. Let the Debianites deal with it. Personally, I use RubyGems instead of Gentoo ports for all my Ruby package needs, why can’t these Debianistas do that as well?

If these Debian people are having so much trouble, mabye they should switch from apt to RubyGems themselves. Maybe RubyGems could be used as a Linux package management system as well?

The Identicon is pissed!

said on 24 Sep 2005 at 20:52

Does anyone actually have data indicated what the distribution of systems running Ruby looks like? (Not linux distribution)

said on 25 Sep 2005 at 00:35

I primarily use debian; but end up building ruby & perl separately from source (and install in /usr/local) just to have the cpan and rubygems be the primary sources for those packages. I’d be quite happy if rubygems made it into core ruby.

said on 25 Sep 2005 at 20:40

Any ETA on the Windows all-in-one for 1.8.3?

said on 27 Sep 2005 at 04:54

I’m interested to see how this works

said on 28 Sep 2005 at 13:42

Brian, because of several problems with 1.8.3, I am hoping that Curt waits until or 1.8.4 before doing the next release of the Windows all-in-one.

said on 28 Sep 2005 at 22:28

Thanks, Austin. I am pushing very hard to get some of our projects onto Rails (from J2EE ), and we are dotting the i’s and crossing the t’s on everything. Personally, I’m a Tiger developer myself, but we have a few holdouts :)

said on 30 Sep 2005 at 06:37

Yay, Rails broke. Two minutes browsing through rails bugs and I found a patch. Wonderful.

Anyway, rubygems (from source) is pretty weird in Debian: gem scripts and installed rubygems go in /usr, rubygems classes go in /usr/local. Personally I’m not going to reinstall the thing until they all go in /usr/local like God intended. If Perl’s CPAN module can do it right, I expect a supyeerior programming language to do at least the same!

Comments are closed for this entry.