Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 203706 - dev-lang/ruby:1.9 unmask
Summary: dev-lang/ruby:1.9 unmask
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Lowest enhancement with 3 votes (vote)
Assignee: Gentoo Ruby Team
URL: http://www.ruby-lang.org/en/
Whiteboard:
Keywords:
: 257519 (view as bug list)
Depends on: 256703 ruby19 320617 320623 336863
Blocks: 236064 236065 365675
  Show dependency tree
 
Reported: 2007-12-29 18:22 UTC by Mark Somerville
Modified: 2012-02-17 16:46 UTC (History)
20 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
diff against 1.8.6_p111-r1.ebuild (ruby-1.8.6_p111-r1.ebuild.diff,1.17 KB, patch)
2008-01-11 05:36 UTC, Josh Nichols (RETIRED)
Details | Diff
dropped CJK flag and related lines (ruby-1.9.0.0.ebuild,4.54 KB, text/plain)
2008-02-22 15:52 UTC, Senuma Takahiko
Details
Updated version (ruby-1.9.0.2.ebuild,4.50 KB, text/plain)
2008-07-03 10:45 UTC, Mark Somerville
Details
Patch to implement multiple gem installations for different ruby versions (gems_for_multiple_ruby_versions.patch,3.37 KB, patch)
2008-07-04 22:35 UTC, Mark Somerville
Details | Diff
Ruby 1.9.0.3 ebuild (ruby-1.9.0.3.ebuild,4.62 KB, text/plain)
2008-08-05 09:24 UTC, Mark Somerville
Details
Ruby 1.9.0.3 updated ebuild (ruby-1.9.0.3.ebuild,4.60 KB, text/plain)
2008-08-25 10:14 UTC, Mark Somerville
Details
Ruby 1.9.0-4 ebuild (ruby-1.9.0.4.ebuild,4.48 KB, text/plain)
2008-08-25 18:43 UTC, Alex Legler (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Somerville 2007-12-29 18:22:55 UTC
Ruby 1.9.0 has been released. Although it's still marked as a development release, it would be great to see this in the tree (slotted, I would guess).

Reproducible: Always
Comment 1 Hans de Graaff gentoo-dev 2007-12-30 07:56:32 UTC
Yes, it needs to be slotted. Other things to be considered before ruby 1.9 can be added:

 * is ruby-config up to date enough to handle this version, or is this a good time to ditch ruby-config and use an eselect-based mechanism
 * does the ruby.eclass properly deal with multiple ruby versions? There is the USE_RUBY mechanism, but I'm not sure it works well or has been tested properly
 * how to deal with gems and multiple ruby versions? Currently gems are installed in /usr/lib/ruby/gems/1.8 directory so this may not work well with ruby 1.9, and the USE_RUBY stuff does not apply to gems.

Perhaps some of the old hands in the ruby herd may give feedback on this as well, given that they had to support 1.6 and 1.8, and that we used to have a 1.9  CVS-based ebuild at some point?
Comment 2 Josh Nichols (RETIRED) gentoo-dev 2008-01-11 05:36:10 UTC
Created attachment 140658 [details, diff]
diff against 1.8.6_p111-r1.ebuild

Here's a first pass.

Doesn't seem to build without USE=threads

Also, it seems to fail to merge if it's already installed with a bizarre message:

>>> Install ruby-1.9.0 into /var/tmp/portage/dev-lang/ruby-1.9.0/image/ category dev-lang
./miniruby  ./instruby.rb --dest-dir="/var/tmp/portage/dev-lang/ruby-1.9.0/image/" --extout=".ext" --make="make" --mflags="" --make-flags="DESTDIR=/var/tmp/portage/dev-lang/ruby-1.9.0/image/" --installed-list .installed.list --mantype="doc"
/var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/ext/dl/win32/lib/Win32API.rb:13:in `initialize': kernel32: cannot open shared object file: No such file or directory (DL::DLError)
        from /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/ext/dl/win32/lib/Win32API.rb:13:in `dlopen'
        from /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/ext/dl/win32/lib/Win32API.rb:13:in `initialize'
        from /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tmpdir.rb:18:in `new'
        from /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tmpdir.rb:18:in `<class:Dir>'
        from /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tmpdir.rb:9:in `<top (required)>'
        from /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tempfile.rb:8:in `require'
        from /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tempfile.rb:8:in `<top (required)>'
        from ./instruby.rb:12:in `require'
        from ./instruby.rb:12:in `<main>'
make: *** [do-install-nodoc] Error 1

It doesn't really make any sense to me yet.
Comment 3 Senuma Takahiko 2008-02-22 15:52:34 UTC
Created attachment 144341 [details]
dropped CJK flag and related lines

Since Oniguruma is included from 1.9.0, the library is no longer needed even when USE "CJK" is stated.
Successfully emerged on ~amd64 with the attached version of ebuild.

Regards,
Comment 4 Senuma Takahiko 2008-02-22 16:13:53 UTC
(In reply to comment #2)
> Created an attachment (id=140658) [edit]
> diff against 1.8.6_p111-r1.ebuild
> 
> Here's a first pass.
> 
> Doesn't seem to build without USE=threads
> 
> Also, it seems to fail to merge if it's already installed with a bizarre
> message:
> 
> >>> Install ruby-1.9.0 into /var/tmp/portage/dev-lang/ruby-1.9.0/image/ category dev-lang
> ./miniruby  ./instruby.rb
> --dest-dir="/var/tmp/portage/dev-lang/ruby-1.9.0/image/" --extout=".ext"
> --make="make" --mflags=""
> --make-flags="DESTDIR=/var/tmp/portage/dev-lang/ruby-1.9.0/image/"
> --installed-list .installed.list --mantype="doc"
> /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/ext/dl/win32/lib/Win32API.rb:13:in
> `initialize': kernel32: cannot open shared object file: No such file or
> directory (DL::DLError)
>         from
> /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/ext/dl/win32/lib/Win32API.rb:13:in
> `dlopen'
>         from
> /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/ext/dl/win32/lib/Win32API.rb:13:in
> `initialize'
>         from
> /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tmpdir.rb:18:in
> `new'
>         from
> /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tmpdir.rb:18:in
> `<class:Dir>'
>         from
> /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tmpdir.rb:9:in `<top
> (required)>'
>         from
> /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tempfile.rb:8:in
> `require'
>         from
> /var/tmp/portage/dev-lang/ruby-1.9.0/work/ruby-1.9.0-0/lib/tempfile.rb:8:in
> `<top (required)>'
>         from ./instruby.rb:12:in `require'
>         from ./instruby.rb:12:in `<main>'
> make: *** [do-install-nodoc] Error 1
> 
> It doesn't really make any sense to me yet.
> 

This error happens when emerging ruby-1.9.0 more than once with --oneshot option.
After deleting initial install with emerge -C, the error never happens.

Comment 5 Josh Nichols (RETIRED) gentoo-dev 2008-02-25 15:28:01 UTC
(In reply to comment #4)
> This error happens when emerging ruby-1.9.0 more than once with --oneshot
> option.
> After deleting initial install with emerge -C, the error never happens.
> 

Yeah, that's the behavior I observed. We do need to find the cause of it though, because you really should be able to merge a package multiple times without unmerging it beforehand.
Comment 6 Sven Schwyn (svoop) 2008-05-28 13:42:58 UTC
> Perhaps some of the old hands in the ruby herd may give feedback on this as
> well, given that they had to support 1.6 and 1.8, and that we used to have a
> 1.9  CVS-based ebuild at some point?

Has ruby-1.9 stalled?

I'm not an "old hand", but if me and my little ebuild knowledge can be of help, please tell me where ruby-1.9 is being worked on. The Ruby Overlay is empty and the repos are gone.

With ruby-1.9.1 (production ready) aproaching and rails-2.1 (which runs on ruby-1.9) just hours away, it'd be nice if this thing gained some momentum on Gentoo.
Comment 7 Hans de Graaff gentoo-dev 2008-06-01 09:16:29 UTC
Sven: I'm not sure to what extend Josh is still working on the ebuild. Any feedback on it is welcome, and testing is appreciated.

As for the ruby overlay, we don't have an official one atm. We did recently create a ruby project, so this may be a side-effect. Josh?
Comment 8 Sven Schwyn (svoop) 2008-06-01 10:20:09 UTC
> Sven: I'm not sure to what extend Josh is still working on the ebuild. Any
> feedback on it is welcome, and testing is appreciated.

You can count on me for testing on amd64 once the ebuild is ready and available for testing. If Josh develops and tests the ebuild on another platform, a list of tests to perform would be helpful, too.

> As for the ruby overlay, we don't have an official one atm. We did recently
> create a ruby project, so this may be a side-effect. Josh?

An overlay of it's own seems more than appropriate, however, an alternative could also be the Gentoo Sunrise User Overlay which is open to everybody.
Comment 9 Josh Nichols (RETIRED) gentoo-dev 2008-06-04 19:17:01 UTC
My work on the ebuild had stalled. I think what's on this bug is my most recent work.

I (think) I had gotten us up overlays.gentoo.org, but there isn't anything there yet. 

My current level of involvement with gentoo/ruby has been depressing to be honest, and I'm not sure when I'm going to pick things up more.
Comment 10 Balint Dobai-Pataky 2008-06-18 09:32:42 UTC
i tried to emerge -va =dev-lang/ruby-1.9.0.0
with USE="berkdb ssl threads -debug -doc -emacs -examples -gdbm -ipv6 -rubytests -socks5 -tk -xemacs"

with and without ruby1.8 installed

...
creating config.h
configure: creating ./config.status
config.status: creating Makefile
rbconfig.rb updated
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lruby19
collect2: ld returned 1 exit status
make[1]: *** [.ext/i686-linux/enc/iso_8859_1.so] Error 1
make[1]: *** Waiting for unfinished jobs....
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lruby19
collect2: ld returned 1 exit status
make[1]: *** [.ext/i686-linux/enc/iso_8859_2.so] Error 1
make: *** [encs] Error 2
 * 
 * ERROR: dev-lang/ruby-1.9.0.0 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 3077:  Called die
 * The specific snippet of code:
 *       emake EXTLDFLAGS="${LDFLAGS}" || die "emake failed"
 *  The die message:
 *   emake failed
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/log/portage/dev-lang:ruby-1.9.0.0:20080618-074930.log'.
 * The ebuild environment file is located at '/dev/shm/portage/dev-lang/ruby-1.9.0.0/temp/environment'.
 * This ebuild is from an overlay: '/usr/local/portage/'

Comment 11 M. Edward Borasky 2008-06-18 13:14:28 UTC
(In reply to comment #10)
> i tried to emerge -va =dev-lang/ruby-1.9.0.0
> with USE="berkdb ssl threads -debug -doc -emacs -examples -gdbm -ipv6
> -rubytests -socks5 -tk -xemacs"
> 
> with and without ruby1.8 installed
> 
> ...
> creating config.h
> configure: creating ./config.status
> config.status: creating Makefile
> rbconfig.rb updated
> /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld:
> cannot find -lruby19
> collect2: ld returned 1 exit status
> make[1]: *** [.ext/i686-linux/enc/iso_8859_1.so] Error 1
> make[1]: *** Waiting for unfinished jobs....
> /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld:
> cannot find -lruby19
> collect2: ld returned 1 exit status
> make[1]: *** [.ext/i686-linux/enc/iso_8859_2.so] Error 1
> make: *** [encs] Error 2
>  * 
>  * ERROR: dev-lang/ruby-1.9.0.0 failed.
>  * Call stack:
>  *               ebuild.sh, line   49:  Called src_compile
>  *             environment, line 3077:  Called die
>  * The specific snippet of code:
>  *       emake EXTLDFLAGS="${LDFLAGS}" || die "emake failed"
>  *  The die message:
>  *   emake failed
>  * 
>  * If you need support, post the topmost build error, and the call stack if
> relevant.
>  * A complete build log is located at
> '/var/log/portage/dev-lang:ruby-1.9.0.0:20080618-074930.log'.
>  * The ebuild environment file is located at
> '/dev/shm/portage/dev-lang/ruby-1.9.0.0/temp/environment'.
>  * This ebuild is from an overlay: '/usr/local/portage/'
> 

IIRC an install of Ruby 1.9 needs Ruby 1.8. It's been a couple of months since I did anything with Ruby 1.9. There is a 1.9.1 in the works scheduled for a week or so.

Just out of curiosity, is one of the Ruby maintainers on the "ruby-core" mailing list? Is there a Ruby overlay? There's quite a bit of activity on the "edges" of Ruby.
Comment 12 Hans de Graaff gentoo-dev 2008-06-18 14:55:38 UTC
(In reply to comment #11)

> Just out of curiosity, is one of the Ruby maintainers on the "ruby-core"
> mailing list? Is there a Ruby overlay? There's quite a bit of activity on the
> "edges" of Ruby.

As far as I know the only dev who monitored ruby-core is no longer a dev (rbrown).

There is an overlay but we haven't used it yet. I think it was set up by nichoj so I assume he can provide access to it. I agree that it would be useful to put stuff like this into an overlay for easier testing and cooperation.

In short: we are understaffed and can use help. :-/
Comment 13 M. Edward Borasky 2008-06-19 02:54:19 UTC
> There is an overlay but we haven't used it yet. I think it was set up by nichoj
> so I assume he can provide access to it. I agree that it would be useful to put
> stuff like this into an overlay for easier testing and cooperation.
> 
> In short: we are understaffed and can use help. :-/
> 

Well ... there's quite a bit of "life on the edge of chaos" in the "ruby-core" community right now. There are now at least four Ruby implementations that will execute Rails, and two "main stream" 1.8 versions -- 1.8.6-p114 and 1,8.7. I can certainly test stuff like Rubinius, although I mostly do benchmarks these days.

Quite frankly, I'm not sure where 1.9 fits into the grand scheme of things any more. I think more energy is going into Rails performance hacks with 1.8.6-p114 than all the rest of "Ruby" put together.
Comment 14 Mark Somerville 2008-07-03 10:45:06 UTC
Created attachment 159395 [details]
Updated version

Version bump. This version works fine with multiple installs using --one-shot. Still requires the threads USE flag though (all on ~amd64).
Comment 15 Mark Somerville 2008-07-04 22:35:12 UTC
Created attachment 159580 [details, diff]
Patch to implement multiple gem installations for different ruby versions

This patch adds in support for installing gems for seperate ruby slots. gems_src_install() will now check USE_RUBY in the gem ebuild and will install the gem for each installed version of ruby that is also in USE_RUBY.

I'm not sure how many gems ebuilds have USE_RUBY set. Also, since even pure-ruby gems for 1.8 can sometimes explode with 1.9, USE_RUBY will default to "ruby18" if not set.

Executable files seem to have the shebang line set to the version of ruby that was used to install them, so gems_src_install() will also replace this with /usr/bin/ruby *if* more than one version of ruby is compatible - this way, the currently selected (using ruby-config/eselect) version will be used.

Things that aren't so good with this approach are you end up (potentially) with gems installed for ruby versions that you don't want. Meaning that, for example, you can't install rails for 1.8 and not 1.9.  Also, comment #1 says that "the USE_RUBY stuff does not apply to gems" - why? There may well be something that I don't know about that makes this approach unworkable.

Things I like about this approach are that the changes seem pretty low impact to me and I can't think of any other way of handling the problem!

Any thoughts would be appreciated.
Comment 16 Hans de Graaff gentoo-dev 2008-07-05 06:31:50 UTC
(In reply to comment #15)
> Created an attachment (id=159580) [edit]
> Patch to implement multiple gem installations for different ruby versions

Very nice. Thanks! Unfortunately I can't really look at this right now due to too many other things on my plate, but hopefully you'll get some feedback from other people watching this bug.

> Also, comment #1 says
> that "the USE_RUBY stuff does not apply to gems" - why? There may well be
> something that I don't know about that makes this approach unworkable.

When I wrote that (and currently still true excluding your patches) the gems eclass doesn't look at USE_RUBY at all. So my intention was to remove USE_RUBY from gems ebuilds on the grounds that it was not doing anything and might cause problems later.

With your patches I think it makes sense to retest gems on 1.9 before adding that (or the optimistic ANY) to each ebuild. Having said that, I'm guessing that a fair amount of gems ebuilds still have USE_RUBY statements.
Comment 17 Sven Schwyn (svoop) 2008-07-23 14:35:33 UTC
I've added some meat to the Ruby overlay:
- overlay scaffold
- current ebuilds for Ruby 1.8.6, 1.8.7 and 1.9.0 (the latter two hard masked)
- gem.eclass with Mark Somerville's patch applied

The corresponding bugs are now linked from the overlay wiki:
http://overlays.gentoo.org/proj/ruby/wiki

As soon as the overlay has been added to layman-global.txt, it will show up with "layman -L" and ready to use with "layman -a ruby".
Comment 18 M. Edward Borasky 2008-07-23 21:38:35 UTC
(In reply to comment #17)
> I've added some meat to the Ruby overlay:
> - overlay scaffold
> - current ebuilds for Ruby 1.8.6, 1.8.7 and 1.9.0 (the latter two hard masked)
> - gem.eclass with Mark Somerville's patch applied
> 
> The corresponding bugs are now linked from the overlay wiki:
> http://overlays.gentoo.org/proj/ruby/wiki
> 
> As soon as the overlay has been added to layman-global.txt, it will show up
> with "layman -L" and ready to use with "layman -a ruby".
> 

Thanks!!
Comment 19 Sven Schwyn (svoop) 2008-07-29 08:02:34 UTC
The Ruby overlay is now included:

layman -a ruby

Have fun!
Comment 20 Mark Somerville 2008-08-03 11:01:26 UTC
I can't seem to build 1.9.0.2 now (I have previously built it fine on both amd64 and x86). With USE="berkdb gdbm ipv6 ssl threads -debug -doc -emacs -examples -rubytests -socks5 -tk -xemacs" I get this error:

./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb  ./enc/make_encdb.rb ./enc encdb.h.new
./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb  ./enc/trans/make_transdb.rb ./enc/trans transdb.h.new
./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb  -I. -rrbconfig ./tool/compile_prelude.rb ./prelude.rb ./enc/prelude.rb ./gem_prelude.rb prelude.c
./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb  ./enc/make_encmake.rb --builtin-encs="ascii.o us_ascii.o unicode.o utf_8.o" enc.mk
:0:in `require': no such file to load -- rbconfig (LoadError)
make: *** [prelude.c] Error 1
make: *** Waiting for unfinished jobs....
rbconfig.rb updated
./tool/ifchange "encdb.h" "encdb.h.new"
encdb.h unchanged
./tool/ifchange "transdb.h" "transdb.h.new"
transdb.h updated

Anyone got any suggestions? I can't figure this one out.
Comment 21 M. Edward Borasky 2008-08-03 18:23:32 UTC
(In reply to comment #20)
> I can't seem to build 1.9.0.2 now (I have previously built it fine on both
> amd64 and x86). With USE="berkdb gdbm ipv6 ssl threads -debug -doc -emacs
> -examples -rubytests -socks5 -tk -xemacs" I get this error:
> 
> ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb  ./enc/make_encdb.rb
> ./enc encdb.h.new
> ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb 
> ./enc/trans/make_transdb.rb ./enc/trans transdb.h.new
> ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb  -I. -rrbconfig
> ./tool/compile_prelude.rb ./prelude.rb ./enc/prelude.rb ./gem_prelude.rb
> prelude.c
> ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb 
> ./enc/make_encmake.rb --builtin-encs="ascii.o us_ascii.o unicode.o utf_8.o"
> enc.mk
> :0:in `require': no such file to load -- rbconfig (LoadError)
> make: *** [prelude.c] Error 1
> make: *** Waiting for unfinished jobs....
> rbconfig.rb updated
> ./tool/ifchange "encdb.h" "encdb.h.new"
> encdb.h unchanged
> ./tool/ifchange "transdb.h" "transdb.h.new"
> transdb.h updated
> 
> Anyone got any suggestions? I can't figure this one out.
> 

Try 1.9.0-3. It's the latest version (about a week or two ago).
Comment 22 Mark Somerville 2008-08-05 09:24:01 UTC
Created attachment 162250 [details]
Ruby 1.9.0.3 ebuild
Comment 23 Mark Somerville 2008-08-05 09:27:11 UTC
Unfortunately, I experience the same problem with 1.9.0-3 as I mentioned in comment #20.

Can anyone get these 1.9 ebuilds to compile?
Comment 24 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-08-08 19:39:20 UTC
(In reply to comment #23)
> Can anyone get these 1.9 ebuilds to compile?

.3 worked fine for me on ~x86. Even when building multiple times w/o -C'ing and without 1.8. :o
---
Concerning the "threads" useflag: YARV requires threads for some time now, thus ruby-1.9 needs them one way or another. I guess the useflag can be dropped.

On ruby-config: IMHO now would be a good time to switch to eselect.
There still seems to be bug #169150, which could be fixed in one go and #210211, where I dunno whether to remove that.
If there is the slightest bit of hope that there is going to be an eselect-ruby, I can try my eselect-fu, if nobody started such a thing yet and it's alright with the guys from the herd. ;)

Another issue is that rubygems and rake are now part of the ruby core. How should that be handled?
Comment 25 M. Edward Borasky 2008-08-09 04:32:52 UTC
1. Ruby 1.9 does indeed require threads. In addition, if you have Ruby 1.9 and want to use the Ruby Tk bindings, you need to compile Tcl and Tk with the "threads" USE flag!

2. Even with upstream source from subversion, I've had the "make" step abort, and if you retry it, it will finish. I've had instances where it took "make; make; make" to get a full build. What that suggests to me is

a. It's an upstream problem
b. Forcing "make -j 1" might make it go away.
Comment 26 Mark Somerville 2008-08-09 09:03:46 UTC
(In reply to comment #25)
> b. Forcing "make -j 1" might make it go away.

Worked first time when I tried this! Excellent, thank you very much!

Comment 27 Mark Somerville 2008-08-25 10:14:25 UTC
Created attachment 163751 [details]
Ruby 1.9.0.3 updated ebuild

Dropped the threads USE flag, now always compile with --enable-pthread. Also force MAKEOPTS="-j1" (compilation was failing for me with -j5).
Comment 28 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-08-25 18:43:27 UTC
Created attachment 163770 [details]
Ruby 1.9.0-4 ebuild

Today, Ruby 1.9.0-4 was released.
Added an updated ebuild for that.

Could a dev update the overlay, please? Last version in there is -2.
Comment 29 Hans de Graaff gentoo-dev 2008-08-30 07:13:20 UTC
(In reply to comment #27)
> Created an attachment (id=163751) [edit]
> Ruby 1.9.0.3 updated ebuild
> 
> Dropped the threads USE flag, now always compile with --enable-pthread. Also
> force MAKEOPTS="-j1" (compilation was failing for me with -j5).

A couple of points on this ebuild:

* Please don't assume where the portage tmp dir is with hardcoded paths
* Only include something like -j1 if there is an upstream bug filed for it and if that is documented in the ebuild, so that we can remove it as soon as possible.
Comment 30 Hans de Graaff gentoo-dev 2008-08-30 07:15:44 UTC
(In reply to comment #28)

> Could a dev update the overlay, please? Last version in there is -2.

If people would like to actively help out and work on ruby 1.9 stuff in the overlay then please let me know and I can arrange access to it.

I'll be adding 1.9.0.4 to the overlay in a moment, but the -j1 stuff still needs to be fixed.

Comment 31 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-10-04 09:34:21 UTC
1.9.0-5 is in the overlay now.
Comment 32 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-10-28 19:24:16 UTC
Ruby 1.9.1 Preview 1 (aka ruby-1.9.1_pre1) is in the overlay now.

Just to state the deadline here once: The latest official release date of Ruby 1.9.1 (stable!) is January 25, 2009. [1]

That's only 3 more months. Please panic now! :)

--
[1] FWIW, here are the other release dates: https://overlays.gentoo.org/proj/ruby/wiki/Ruby1.9
Comment 33 M. Edward Borasky 2008-10-29 01:25:15 UTC
Thanks!! I was going to download it myself, but since it's in the overlay, I'll load it from there. Is there an "eselect ruby" or something I can use to switch between the two of them?
Comment 34 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-10-29 07:38:44 UTC
(In reply to comment #33)
> Is there an "eselect ruby" or something I can use to switch
> between the two of them?
> 

Yes, there is. It's in ruby's dependencies, so you should get it automatically.

Comment 35 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-12-01 19:10:08 UTC
We now have the Preview Release 2 (aka ruby-1.9.1_pre2) in the Ruby overlay.

I encourage everyone who is interested to grab the overlay (via layman), test the ebuild and give some feedback (on the bug or #gentoo-ruby @ Freenode).
We really appreciate it!

T minus two months :)
Comment 36 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2008-12-30 17:21:15 UTC
And now there is the Release Candidate 1, too.
Comment 37 Balint Dobai-Pataky 2009-01-06 15:38:56 UTC
i emerged ruby-enterprise and then the ebuilds work.
but here is another issue (have you encountered it? have you solved it?):
$ irb19 
irb(main):001:0> require 'gtk2'
LoadError: /usr/lib/ruby/site_ruby/1.9.0/i686-linux/gtk2.so: undefined symbol: rb_progname - /usr/lib/ruby/site_ruby/1.9.0/i686-linux/gtk2.so
	from /usr/lib/ruby/site_ruby/1.9.0/gtk2/base.rb:19:in `require'
	from /usr/lib/ruby/site_ruby/1.9.0/gtk2/base.rb:19:in `<top (required)>'
	from /usr/lib/ruby/site_ruby/1.9.0/gtk2.rb:11:in `require'
	from /usr/lib/ruby/site_ruby/1.9.0/gtk2.rb:11:in `<top (required)>'
	from (irb):1:in `require'
	from (irb):1
	from /usr/bin/irb19:12:in `<main>'
irb(main):002:0> 
Comment 38 Hans de Graaff gentoo-dev 2009-01-07 18:06:59 UTC
(In reply to comment #37)

Please file a separate bug for this. This is not a ruby 1.9 issue but rather an issue with gtk2's ruby 1.9 compatibility.
Comment 39 Balint Dobai-Pataky 2009-01-08 07:11:31 UTC
i just found out ruby-gtk2 is not ruby 1.9 compatible:
Note: Ruby-GNOME2 does *not* currently work with Ruby version 1.9.
The only version of Ruby that is currently supported is version 1.8.7.
Comment 40 Arseny Solokha 2009-01-31 07:01:47 UTC
Ruby 1.9.1 released. First stable release in this branch.

http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released
Comment 41 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2009-02-03 10:06:07 UTC
FYI, 1.9.1-p0 is in the overlay.

We need more time to fix the last things in the tree (mainly USE_RUBY stuff) and some dependencies (amarok, krossruby).

I will continue my work in 2 weeks, after some exams.
If you want to help speed things up, you know how to reach us... ;)
Comment 42 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-02-03 18:52:07 UTC
*** Bug 257519 has been marked as a duplicate of this bug. ***
Comment 43 Sven Schwyn (svoop) 2009-02-05 12:49:17 UTC
One "issue" is that when upping from Ruby 1.8 to 1.9.1 (yet keeping the 1.8 version), the setting in PREFIX/etc/env.d/10rubygems causes trouble when eselecting Ruby 1.9.1. It contains 'RUBYOPT="-rauto_gem"' which appears to be obsolete. Any idea how to have eselect switch this, too? Or maybe a condition in 10rubygems to use different values depending on the Ruby interpreter used?
Comment 44 Hans de Graaff gentoo-dev 2009-02-22 13:43:20 UTC
(In reply to comment #43)
> One "issue" is that when upping from Ruby 1.8 to 1.9.1 (yet keeping the 1.8
> version), the setting in PREFIX/etc/env.d/10rubygems causes trouble when
> eselecting Ruby 1.9.1. It contains 'RUBYOPT="-rauto_gem"' which appears to be
> obsolete. Any idea how to have eselect switch this, too? Or maybe a condition
> in 10rubygems to use different values depending on the Ruby interpreter used?

I think I discussed this earlier with Alex on IRC, and we came to the conclusion that we'd ship an empty auto_gem.rb file with Ruby 1.9.x. We can't tinker too much with RUBYOPT since even though you've selected to use ruby 1.9 as the main interpreter you might still have ruby18 scripts around.

The other solution is to ditch auto_gem completely and be prepared to fix a whole bunch of issues because of this.
Comment 45 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-02-22 14:34:23 UTC
_If_ we could rely on FEATURES=test (which we cannot do thanks to the lovely gems), it would be no issue to run it through my tinderbox with it disabled.

Or if somebody has any way I can automate the testing there I'd be ready to at least find the issues, and report them to assess the amount of work involved.
Comment 46 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2009-12-14 13:53:14 UTC
Heads-up: We have a set of new eclasses that allow for a proper installation for multiple ruby targets. That brought us quite a step forward towards the unmasking of the package. Now we just need to migrate ~300 packages. ;)

I'll see to bump ruby 1.9.1 to p376 this week.
Comment 47 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2010-05-16 16:06:44 UTC
Status: We have >50% of our packages on the new eclasses.
We still need to have most packages out of the sitedir to avoid collisions. When that is done, we can move ruby 1.9 from /usr/lib(64)?/ruby19/ back to /src/lib(64)?/ruby. Then, we can unmask it.
Comment 48 Hans de Graaff gentoo-dev 2010-07-21 09:45:56 UTC
Status: only two packages left that may cause problems (see depending bugs). We expect to unmask ruby 1.9.x once ruby 1.9.2 is no longer a release candidate.
Comment 49 Zeno Davatz 2010-07-28 10:39:32 UTC
Can you please point out in the meantime how to install Ruby18 and Ruby19 on the same machine together with gem18 and gem19. The blocking of Ruby1.9 cause a lot of damage to Ruby and also to the usability of Gentoo general. It is totally unclear how to install gem18 and gem19 together with Ruby18 and Ruby19 on the same machine without ending up with something like:

zeno@zdavatz-eeepc ~ $ gem
gem     gem1.9  gem18   gem19  
Comment 50 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2010-07-28 10:58:01 UTC
(In reply to comment #49)
> Can you please point out in the meantime how to install Ruby18 and Ruby19 on
> the same machine together with gem18 and gem19. The blocking of Ruby1.9 cause a
> lot of damage to Ruby and also to the usability of Gentoo general.

You surely have noticed that they are neither API nor ABI comptaible and lots of libraries lacked support until recently. We cannot just unleash ruby 1.9 on everyone (i.e. pulling the python-3 stunt). The good news is that we are nearing completion of testing and fixing things, and I expect a unmasked 1.9.2 version within the year.

> It is
> totally unclear how to install gem18 and gem19 together with Ruby18 and Ruby19
> on the same machine without ending up with something like:
> 
> zeno@zdavatz-eeepc ~ $ gem
> gem     gem1.9  gem18   gem19  
> 

gem1.9 is something you'd only find on funtoo. If that is the case, go bug them as they decided to divert from Gentoo with their ruby stuff.

Unclear? rubygems does everything for you, just set the targets and emerge. *shrug*
On Gentoo, gem is part of a set of binaries that are symlinked (in this case to either gem18 or gem19), controlled by `eselect ruby', to set a system-wide standard interpreter version. That's the best solution we have so far. If you have any *constructive* comments, we're all ears.
Comment 51 Zeno Davatz 2010-07-28 15:56:32 UTC
Thank you for the answer. But how do I set the "target" to emerge rubygems so I get "gem19" in my /usr/bin/ directory. That is not clear from this install instruction: 

http://www.gentoo.org/proj/en/prog_lang/ruby/index.xml

If you guys want to better then Funtoo you should really up-the-ante and start freeing Ruby from the Prison. Ruby1.9 is more then ready to be unmasked.
Comment 52 Zeno Davatz 2010-07-28 16:03:27 UTC
(In reply to comment #50)

> You surely have noticed that they are neither API nor ABI comptaible and lots
> of libraries lacked support until recently. We cannot just unleash ruby 1.9 on
> everyone (i.e. pulling the python-3 stunt). The good news is that we are
> nearing completion of testing and fixing things, and I expect a unmasked 1.9.2
> version within the year.

I understand your point.

It is just that certain People want Ruby and know Ruby and because Ruby1.8 and Ruby1.9 can coexist on the same system there is no reason to mask Ruby1.9 just because less software has been transcribed to support Ruby1.9.

I for example would like to keep my Ruby1.8 applications running but would like to also run my Ruby1.9 stuff at the same time. That is what eselect is for, correct? Ruby1.9 is perfectly stable, a lot faster and has much better memory management. Also no more Oniguruma-Patch is needed. Just put it out there so we can test it without having to jump through the Hula-Hoop when I want to install it.
Comment 53 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2010-07-28 16:19:35 UTC
(In reply to comment #51)
> Thank you for the answer. But how do I set the "target" to emerge rubygems so I
> get "gem19" in my /usr/bin/ directory. That is not clear from this install
> instruction: 
> 
> http://www.gentoo.org/proj/en/prog_lang/ruby/index.xml

The mask is put there specifically to be a little road block. We gave sufficient hints (unmask package and use flag; adapt RUBY_TARGETS), google and your regular gentoo-fu will get you the rest.
That document is btw not an 'installation instruction', it's an overview of our Ruby system. When this system is of importance to most stable users, the documentation will be straightforward, too.

> 
> If you guys want to better then Funtoo you should really up-the-ante and start
> freeing Ruby from the Prison. Ruby1.9 is more then ready to be unmasked.
> 

Your opinion is noted, but it does not match what we have experienced and are experiencing. We have no need to be 'better' (how ever that is defined in this context) than Funtoo or $any_other_distro.

(In reply to comment #52)
> (In reply to comment #50)
> 
> > You surely have noticed that they are neither API nor ABI comptaible and lots
> > of libraries lacked support until recently. We cannot just unleash ruby 1.9 on
> > everyone (i.e. pulling the python-3 stunt). The good news is that we are
> > nearing completion of testing and fixing things, and I expect a unmasked 1.9.2
> > version within the year.
> 
> I understand your point.
> 
> It is just that certain People want Ruby and know Ruby and because Ruby1.8 and
> Ruby1.9 can coexist on the same system there is no reason to mask Ruby1.9 just
> because less software has been transcribed to support Ruby1.9.
> 

Wrong. Some software in the tree still fails if 1.9 is default. I don't know about other distributions, but this is a fact we can and do not accept.

> I for example would like to keep my Ruby1.8 applications running but would like
> to also run my Ruby1.9 stuff at the same time. That is what eselect is for,
> correct? Ruby1.9 is perfectly stable, a lot faster and has much better memory
> management. Also no more Oniguruma-Patch is needed. Just put it out there so we
> can test it without having to jump through the Hula-Hoop when I want to install
> it.

We are well aware that Ruby 1.9 is a major improvement. But we also have more than two years of packaging experience with it that leads us to the conclusion that things are not yet ready for prime-time yet.

I think I've said everything that's to be said. I'll rather put my time into actually fixing things instead of defending our preference for stability.

Also, if you reply to a post, send one reply, not two. Thanks.
Comment 54 Zeno Davatz 2010-07-28 16:20:25 UTC
Just to make myself more clear:

I set: 

RUBY_TARGETS="ruby19"

in my 

/etc/make.conf

and then I do:

sudo emerge rubygems

and the result is:

>>> Emerging (1 of 1) dev-ruby/rubygems-1.3.7-r1
 * rubygems-1.3.7.tgz RMD160 SHA1 SHA256 size ;-) ...                                                                            [ ok ]
 * checking ebuild checksums ;-) ...                                                                                             [ ok ]
 * checking auxfile checksums ;-) ...                                                                                            [ ok ]
 * checking miscfile checksums ;-) ...                                                                                           [ ok ]
 * CPV:  dev-ruby/rubygems-1.3.7-r1
 * REPO: funtoo
 * USE:  elibc_glibc kernel_linux userland_GNU x86
 * ERROR: dev-ruby/rubygems-1.3.7-r1 failed:
 *   You need to select at least one Ruby implementation by setting RUBY_TARGETS in /etc/make.conf.
 * 
 * Call stack:
 *        ebuild.sh, line   47:  Called pkg_setup
 *        ebuild.sh, line 1345:  Called ruby-ng_pkg_setup
 *   ruby-ng.eclass, line  293:  Called _ruby_each_implementation
 *   ruby-ng.eclass, line  283:  Called die
 * The specific snippet of code:
 *      [[ ${invoked} == "no" ]] && die "You need to select at least one Ruby implementation by setting RUBY_TARGETS in /etc/make.conf."
 * 
 * If you need support, post the output of 'emerge --info =dev-ruby/rubygems-1.3.7-r1',
 * the complete build log and the output of 'emerge -pqv =dev-ruby/rubygems-1.3.7-r1'.
 * The complete build log is located at '/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/temp/die.env'.
 * S: '/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/work/rubygems-1.3.7'

>>> Failed to emerge dev-ruby/rubygems-1.3.7-r1, Log file:

As far as I can tell Ruby1.9 is working more then fine, but the installation of Ruby.19 is somehow not working.

Any hints are very welcome.

If I set

RUBY_TARGETS="ruby18 ruby19"

only gem18 is installed.
Comment 55 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2010-07-28 16:22:20 UTC
(In reply to comment #54)
> Just to make myself more clear:
> 

We do not support funtoo. Please leave us alone.
Comment 56 Zeno Davatz 2010-07-28 16:40:14 UTC
You should think more positive for the user. All I am telling you is that your instructions for the laymen are not clear. Why not try to profit from that and show some more respect to Funtoo.
Comment 57 Diego Elio Pettenò (RETIRED) gentoo-dev 2010-07-28 16:47:04 UTC
I'll put in the most clear words possible, but after this, if you insist, we'd think about asking the bugzilla admins to disable your account.

We _could_ just unmask this and have to answer every other bug to provide a patch or report it upstream because it is a known failure. Or we can do what we're doing, that is fixin the packages one by one to actually _work_ with both 1.8 and 1.9.

You're asked to edit at most three files to get Ruby 1.9, and then you get a system that has actually been tested (up to a point at least) with 1.9 and is designed to work.

Your insistence is just going to reduce our motivation to keep working so that thing works. So either help out, directly or indirectly, or shut the hell up.
Comment 58 Zeno Davatz 2010-07-28 17:02:12 UTC
Sorry I am trying to help but you are somehow not noticing it.

[[Just free Ruby1.9 out of prison and stop threatening me and stop being rude to me just because I give you honest Feedback.]]

And also just for the record: I think it would be a far better solution if you would see to it that Ruby1.8 and Ruby1.9 install clean side on side. After all, all the packages that depend on Ruby are not as important as Ruby itself. And yes: let the package maintainers see to it that they meet Ruby1.9.

It seems that you are tweaking Ruby.1.9 to meet the other packages. But Ruby was first. 

I think you are mixing up the priorities and that makes your work very difficult.

You are treating Ruby badly! To say: "Important:  The Gentoo Ruby Team currently does not recommend using Ruby 1.9 for production environments" is very close to FUD.

This whole Bugs gives the impression that Ruby1.9 is not working when it actually is working - what is not working are some packages. But that is their problem not Ruby's.

Comment 59 Konstantin Shabanov 2010-07-28 17:08:13 UTC
(In reply to comment #54)
> Just to make myself more clear:
> 
> I set: 
> 
> RUBY_TARGETS="ruby19"
> 
> in my 
> 
> /etc/make.conf
> 
> and then I do:
> 
> sudo emerge rubygems
> 
> and the result is:
> 
> >>> Emerging (1 of 1) dev-ruby/rubygems-1.3.7-r1
>  * rubygems-1.3.7.tgz RMD160 SHA1 SHA256 size ;-) ...                          
>                                                  [ ok ]
>  * checking ebuild checksums ;-) ...                                           
>                                                  [ ok ]
>  * checking auxfile checksums ;-) ...                                          
>                                                  [ ok ]
>  * checking miscfile checksums ;-) ...                                         
>                                                  [ ok ]
>  * CPV:  dev-ruby/rubygems-1.3.7-r1
>  * REPO: funtoo
>  * USE:  elibc_glibc kernel_linux userland_GNU x86
>  * ERROR: dev-ruby/rubygems-1.3.7-r1 failed:
>  *   You need to select at least one Ruby implementation by setting
> RUBY_TARGETS in /etc/make.conf.
>  * 
>  * Call stack:
>  *        ebuild.sh, line   47:  Called pkg_setup
>  *        ebuild.sh, line 1345:  Called ruby-ng_pkg_setup
>  *   ruby-ng.eclass, line  293:  Called _ruby_each_implementation
>  *   ruby-ng.eclass, line  283:  Called die
>  * The specific snippet of code:
>  *      [[ ${invoked} == "no" ]] && die "You need to select at least one Ruby
> implementation by setting RUBY_TARGETS in /etc/make.conf."
>  * 
>  * If you need support, post the output of 'emerge --info
> =dev-ruby/rubygems-1.3.7-r1',
>  * the complete build log and the output of 'emerge -pqv
> =dev-ruby/rubygems-1.3.7-r1'.
>  * The complete build log is located at
> '/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/temp/build.log'.
>  * The ebuild environment file is located at
> '/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/temp/die.env'.
>  * S: '/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/work/rubygems-1.3.7'
> 
> >>> Failed to emerge dev-ruby/rubygems-1.3.7-r1, Log file:
> 
> As far as I can tell Ruby1.9 is working more then fine, but the installation of
> Ruby.19 is somehow not working.
> 
> Any hints are very welcome.
> 
> If I set
> 
> RUBY_TARGETS="ruby18 ruby19"
> 
> only gem18 is installed.
> 
ruby 1.9 don't need rubygems packages. It have already in package.
Comment 60 Konstantin Shabanov 2010-07-28 17:11:33 UTC
(In reply to comment #56)
> You should think more positive for the user. All I am telling you is that your
> instructions for the laymen are not clear. Why not try to profit from that and
> show some more respect to Funtoo.
> 

Why you don't use rvm (http://rvm.beginrescueend.com/)? That's really more practical decision than installing 1.8 and 1.9 versions together through distro.
Comment 61 Zeno Davatz 2010-07-28 17:18:46 UTC
(In reply to comment #60)

> Why you don't use rvm (http://rvm.beginrescueend.com/)? That's really more
> practical decision than installing 1.8 and 1.9 versions together through
> distro.

Thank you for this practical information! I will definitely give it a shot! 

Comment 62 Zeno Davatz 2010-07-28 17:26:32 UTC
(In reply to comment #59)

> ruby 1.9 don't need rubygems packages. It have already in package.

Thank you for this answer.

Sorry, this I do not understand. Do you mean I can just unmask Ruby1.9 and install Ruby1.9. But How do I get my Ruby-1.9-Ready libraries to the correct location without using gem19? 

Comment 63 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2010-07-28 19:23:42 UTC
I'm opening this bug as a member of the User Relations team.
If there is any abuse in this bug, I'll deal with it ASAP.
Comment 64 Zeno Davatz 2010-07-29 08:55:29 UTC
Diego recommended the following:

> It is the total of FIVE commands you have to run:
>
> mkdir -p /etc/portage/profile
> echo "-ruby_targets_ruby19" >> /etc/portage/profile/use.mask
> echo "dev-lang/ruby:1.9" >> /etc/portage/package.unmask
> echo "dev-lang/ruby:1.9" >> /etc/portage/package.keywords
>> echo 'RUBY_TARGETS="ruby18 ruby19"' >> /etc/make.conf
>
> and then install whatever you wants.

I done exactly as recommended above but it does not work.

emerge rubygems results in:

RubyGems installed the following executables:
       /var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/image/usr/bin/gem18

 * Running install phase for ruby19 ...
/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/temp/environment: Zeile
2603: -rrbconfig: Kommando nicht gefunden.
/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/temp/environment: Zeile
796: setup.rb: Kommando nicht gefunden.
 * ERROR: dev-ruby/rubygems-1.3.7-r1 failed:
 *   setup.rb install failed
 *
 * Call stack:
 *     ebuild.sh, line   47:  Called src_install
 *   environment, line 2653:  Called ruby-ng_src_install
 *   environment, line 2471:  Called _ruby_each_implementation
'each_ruby_install'
 *   environment, line  281:  Called _ruby_invoke_environment 'ruby19'
'each_ruby_install'
 *   environment, line  310:  Called each_ruby_install
 *   environment, line  796:  Called die
 * The specific snippet of code:
 *       ${RUBY} setup.rb $myconf --destdir="${D}" || die "setup.rb
install failed";
 *
 * If you need support, post the output of 'emerge --info
=dev-ruby/rubygems-1.3.7-r1',
 * the complete build log and the output of 'emerge -pqv
=dev-ruby/rubygems-1.3.7-r1'.
 * The complete build log is located at
'/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/temp/environment'.
 * S: '/var/tmp/portage/dev-ruby/rubygems-1.3.7-r1/work/ruby19/rubygems-1.3.7'

Any helpful Feedback is more then welcome.

Best
Zeno
Comment 65 Sven Schwyn (svoop) 2011-10-07 12:09:35 UTC
FYI: The roadmap for upstream ruby-1.8.7 will continue regular updates until June 2012 and securty patches only until June 2013. After that date, ruby-1.8.7 is officially dead.

http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
Comment 66 Oleg Mikheev 2011-10-10 08:55:19 UTC
(In reply to comment #57)
> Or we can do what
> we're doing, that is fixin the packages one by one to actually _work_ with both
> 1.8 and 1.9.

If Ruby 1.8 is dead pretty soon then wouldn't it be a better idea to stop fixin the packages, hardmask them and unmask 1.9?
Comment 67 Hans de Graaff gentoo-dev 2011-10-10 18:02:11 UTC
The only real blocker left is bug 336863. Our plan is to put ruby 1.9.3 in the tree when it comes out and unmask it at the same time since this bug should be fixed with ruby 1.9.3.
Comment 68 Hans de Graaff gentoo-dev 2011-10-22 10:17:14 UTC
ruby 1.9.3_rc1 is now in the tree. Still masked until we fix compatibility issues between rubygems 1.8.x and jruby.
Comment 69 Sven Schwyn (svoop) 2011-11-02 13:17:00 UTC
@Hans: Ruby 1.9.3 has been released.
Comment 70 Sven Schwyn (svoop) 2011-11-21 14:32:29 UTC
I don't want to spark a discussion in the bugtracker, but maybe someone could comment on the unmask situation in the forum? Thanks!!

http://forums.gentoo.org/viewtopic-p-6878402.html#6878402
Comment 71 Hans de Graaff gentoo-dev 2011-12-18 18:13:31 UTC
(In reply to comment #69)
> @Hans: Ruby 1.9.3 has been released.

Now in the tree. This version still has massive test failure in the rubytests stuff which will need to be investigated before we can unmask.
Comment 72 Hans de Graaff gentoo-dev 2011-12-28 12:53:32 UTC
I've just unmasked ruby 1.9.3p0. If you find any problems please report them in new bugs, this bug has a long enough history as it is. :-)
Comment 73 Sven Schwyn (svoop) 2011-12-29 09:37:12 UTC
Thank you!!
Comment 74 Sven Schwyn (svoop) 2012-02-17 16:46:37 UTC
ruby-1.9.3-p125 has been released today which includes a security relevant OpenSSL patch:

http://www.ruby-lang.org/en/news/2012/02/16/ruby-1-9-3-p125-is-released/