From noreply at rubyforge.org  Tue Nov  2 18:19:16 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Nov 2010 18:19:16 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28582 ] gem build on a yaml
	spec file fails because of missing require 'yaml'
Message-ID: <20101102221916.3B037185838A@rubyforge.org>

Bugs item #28582, was opened at 2010-09-20 20:37
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28582&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Clint Byrum (spamaps)
Assigned to: Nobody (None)
Summary: gem build on a yaml spec file fails because of missing require 'yaml'

Initial Comment:
If I run gem build on a yaml gemspec, and I have no .gemrc, I get this error:


ubuntu at ip-10-196-111-253:~/g$ gem build metadata 
ERROR:  While executing gem ... (NameError)
    uninitialized constant Gem::Specification::YAML

However, if there is a .gemrc, I don't get an error.

This is because rubygems/config_file.rb requires yaml.

rubygems/specification.rb should require yaml at the top of the file as it uses YAML directly in its own code.


RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]
  - INSTALLATION DIRECTORY: /var/lib/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby1.8
  - EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /var/lib/gems/1.8
     - /home/clint/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

>Comment By: Clint Byrum (spamaps)
Date: 2010-11-02 22:19

Message:
Here is a very tiny patch that solves this issue.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28582&group_id=126

From nick at quaran.to  Fri Nov  5 10:57:22 2010
From: nick at quaran.to (Nick Quaranto)
Date: Fri, 5 Nov 2010 10:57:22 -0400
Subject: [Rubygems-developers] RubyConf Lunch / Breakout
Message-ID: <AANLkTin-nzB=Bhv-iQ4gcAFXjWSt29JgE=rq08hMFZmS@mail.gmail.com>

Hey folks,

I was wondering if anyone else wanted to get together the first day of
RubyConf to discuss plans for 1.4 and other issues (mirroring, CI, you
name it.)

Eric's talk and another RG one is on the first day, so at least things
will be fresh in our heads. (http://rubyconf.org/schedule)

-Nick

From thewoolleyman at gmail.com  Sat Nov  6 15:01:42 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sat, 6 Nov 2010 12:01:42 -0700
Subject: [Rubygems-developers] RubyConf Lunch / Breakout
In-Reply-To: <AANLkTin-nzB=Bhv-iQ4gcAFXjWSt29JgE=rq08hMFZmS@mail.gmail.com>
References: <AANLkTin-nzB=Bhv-iQ4gcAFXjWSt29JgE=rq08hMFZmS@mail.gmail.com>
Message-ID: <AANLkTikSikpawFi+OO2JLpX5_X6o6ci3GE3r-k42vQcg@mail.gmail.com>

On Fri, Nov 5, 2010 at 7:57 AM, Nick Quaranto <nick at quaran.to> wrote:
> Hey folks,
>
> I was wondering if anyone else wanted to get together the first day of
> RubyConf to discuss plans for 1.4 and other issues (mirroring, CI, you
> name it.)
>
> Eric's talk and another RG one is on the first day, so at least things
> will be fresh in our heads. (http://rubyconf.org/schedule)

Feel free to forward me any CI-related topics that come up.  The
existing builds are still up (NOTE: at a new hostname):

http://cibuilder.pivotallabs.com:3333/builds/RubyGems
http://cibuilder.pivotallabs.com:3333/builds/RubyGemsGitHub

...and I intend to address cross-platform and cross-interpreter CI as
part of my long-term goals.

-- Chad

From jftucker at gmail.com  Sun Nov  7 16:29:35 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 7 Nov 2010 13:29:35 -0800
Subject: [Rubygems-developers] RubyConf Lunch / Breakout
In-Reply-To: <AANLkTin-nzB=Bhv-iQ4gcAFXjWSt29JgE=rq08hMFZmS@mail.gmail.com>
References: <AANLkTin-nzB=Bhv-iQ4gcAFXjWSt29JgE=rq08hMFZmS@mail.gmail.com>
Message-ID: <CB674CF4-DE00-4E99-8E87-9756E2071715@gmail.com>


On 5 Nov 2010, at 07:57, Nick Quaranto wrote:

> Hey folks,
> 
> I was wondering if anyone else wanted to get together the first day of
> RubyConf to discuss plans for 1.4 and other issues (mirroring, CI, you
> name it.)
> 
> Eric's talk and another RG one is on the first day, so at least things
> will be fresh in our heads. (http://rubyconf.org/schedule)

I'll be there, I'm going more for getting some of this stuff done and to meet everyone, than I am for the talks.

From noreply at rubyforge.org  Tue Nov  9 13:26:04 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  9 Nov 2010 13:26:04 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28703 ] Update not possible
	if user folder contains umlaut
Message-ID: <20101109182604.6B5C318583B3@rubyforge.org>

Bugs item #28703, was opened at 2010-11-09 18:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28703&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Bugger Off (bugmenot2)
Assigned to: Nobody (None)
Summary: Update not possible if user folder contains umlaut

Initial Comment:
Hello,

I'm from Germany and in the German language there are umlauts, the letters ?, ? and ?. My name contains an umlaut, and therefore my user folder und C:\Users\ (I'm using Win 7) contains one too. Since renaming the user folder is impossible, there is now way to use gem, since it tells me that there is an "Errno:ENOENT". I have already tested and this problem does not occur if i use another user account without an umlaut. Thought you should know this so you could fix it


C:\Users\Tim J?ger>gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.2 (2010-08-18 patchlevel 0) [i
  - INSTALLATION DIRECTORY: E:/Ruby/lib/ruby/gems/1.
  - RUBY EXECUTABLE: E:/Ruby/bin/ruby.exe
  - EXECUTABLE DIRECTORY: E:/Ruby/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mingw32
  - GEM PATHS:
     - E:/Ruby/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

C:\Users\Tim J?ger>gem update --system
Updating RubyGems
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - C:/Users/Tim J?ger

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28703&group_id=126

From noreply at rubyforge.org  Tue Nov  9 13:45:14 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  9 Nov 2010 13:45:14 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28703 ] Update not possible
	if user folder contains umlaut
Message-ID: <20101109184516.2428618583B0@rubyforge.org>

Bugs item #28703, was opened at 2010-11-09 15:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28703&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Bugger Off (bugmenot2)
>Assigned to: Luis Lavena (luislavena)
Summary: Update not possible if user folder contains umlaut

Initial Comment:
Hello,

I'm from Germany and in the German language there are umlauts, the letters ?, ? and ?. My name contains an umlaut, and therefore my user folder und C:\Users\ (I'm using Win 7) contains one too. Since renaming the user folder is impossible, there is now way to use gem, since it tells me that there is an "Errno:ENOENT". I have already tested and this problem does not occur if i use another user account without an umlaut. Thought you should know this so you could fix it


C:\Users\Tim J?ger>gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.2 (2010-08-18 patchlevel 0) [i
  - INSTALLATION DIRECTORY: E:/Ruby/lib/ruby/gems/1.
  - RUBY EXECUTABLE: E:/Ruby/bin/ruby.exe
  - EXECUTABLE DIRECTORY: E:/Ruby/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mingw32
  - GEM PATHS:
     - E:/Ruby/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

C:\Users\Tim J?ger>gem update --system
Updating RubyGems
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - C:/Users/Tim J?ger

----------------------------------------------------------------------

>Comment By: Luis Lavena (luislavena)
Date: 2010-11-09 15:45

Message:
Hello,

Any version of Ruby prior 1.9.2 do not manage properly unicode/accented characters in folders.

Have you tried a folder without spaces? IN your case, you have umlaut and space.

Please try setting GEM_HOME and GEM_PATH variables to a path without spaces but still containing the umlaut symbol and let us know.

Thank you.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28703&group_id=126

From noreply at rubyforge.org  Wed Nov 10 23:42:53 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 10 Nov 2010 23:42:53 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27946 ] gem install hangs
	indefinitely on a NAT-ed machine
Message-ID: <20101111044253.DB3391858361@rubyforge.org>

Bugs item #27946, was opened at 2010-03-09 06:59
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27946&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bret Weinraub (bretweinraub)
Assigned to: Nobody (None)
Summary: gem install hangs indefinitely on a NAT-ed machine

Initial Comment:
As described in this thread from ruby forum:

http://www.ruby-forum.com/topic/204146



----------------------------------------------------------------------

Comment By: Ben Corneau (bencorneau)
Date: 2010-11-10 23:42

Message:
This just happened to me.  I'm running the bitnami ubuntu redmine virtual machine on a VMWare server.

This is my first tango with ruby so could all be related to me being a ruby noob.

Running 'gem install activeresource' would hang indefinitly.

using wget to pull the gem down and then installing locally worked.

My Steps:
1. go to http://rubygems.org/, search for 'activeresource', and copy the link
2. run wget http://rubygems.org/downloads/activeresource-3.0.1.gem
4. run sudo /opt/bitnami/ruby/bin/gem install ./activeresource-3.0.1.gem --local

This worked.  (actually there were several other dependencies that I had to wget first, but once I had all the dependencies it worked)

Hope this helps,
Ben

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-19 08:38

Message:
I'm going to have to close this up unless I get more info to be able to replicate it locally.

----------------------------------------------------------------------

Comment By: Bradly Feeley (bradly)
Date: 2010-03-15 18:18

Message:
I've started seeing this today on an ec2 instance running Ubuntu.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-03-11 05:45

Message:
It seems to not be "NAT'd machines", being that every developer behind a router / on wireless is generally NAT'd.

That being said, the multiple layers of NAT can introduce more problems.

We do need to get to the bottom of this issue, however, it very much seems that this is a problem on a lower layer than our app layer.

It's possible that read(2) is causing some kind of blocking issue in some connection teardown / nat mapping release. On that note, it's worth mentioning that a lot (but far from all) of the complaints are linux in a VM on win32.

My first question, given the seemingly repeatable failure caused by using NAT rather than bridged mode, is what class of NAT is actually being used, is it symmetric / asymmetric, full / partial cone, etc?

Also, are you running any ipv6?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27946&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Fri Nov 12 15:35:03 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Fri, 12 Nov 2010 20:35:03 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 78d9d31
	failed
Message-ID: <4cdda4f78d771_7270..fdbe31380196@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...78d9d31b90c5735df83201db44c226d350ff0b9e committed by Ryan Davis <ryand-ruby at zenspider.com> on 2010-11-12 20:29:34

    cleaned up the tests using util_gem w/ block for add_dependency

 test/gemutilities.rb                  |    2 +-
 test/test_gem_dependency_installer.rb |   10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)
Revision ...6ffd6e30e5b10ef71e17a706226eed51ab59d81c committed by Ryan Davis <ryand-ruby at zenspider.com> on 2010-11-12 20:23:39

    Added two dependency installer tests we're missing: divergent resolve should blow up and convergent mismatch should resolve properly

 test/test_gem_dependency_installer.rb |   53 +++++++++++++++++++++++++++++++++
 1 files changed, 53 insertions(+), 0 deletions(-)
Revision ...3cd4428e5ca27934314d25212a409dea62b5d98f committed by Ryan Davis <ryand-ruby at zenspider.com> on 2010-11-12 20:22:51

    Added cleaner way of adding dependencies to util_gem

 test/gemutilities.rb |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)
Revision ...6e8a25de4955af04915297c97990d919603bc446 committed by Ryan Davis <ryand-ruby at zenspider.com> on 2010-11-12 20:22:13

    Added ability to specify files to focus autotest

 .autotest |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_gather_dependencies_over(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-2.0", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:655


Name: test_gather_dependencies_under(TestGemDependencyInstaller)
Type: Failure
Message: Gem::DependencyError expected but nothing was raised.

./test/test_gem_dependency_installer.rb:678




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/78d9d31b90c5735df83201db44c226d350ff0b9e for details.

From ryand-ruby at zenspider.com  Fri Nov 12 16:20:07 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Fri, 12 Nov 2010 15:20:07 -0600
Subject: [Rubygems-developers] pushed failing tests
Message-ID: <9C393809-F29A-4749-9609-A9ED65CCB81C@zenspider.com>

Just a heads up. I've pushed failing tests while JB and I work through some scenarios.

From devnull+rubygems-ci at pivotallabs.com  Fri Nov 12 16:20:45 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Fri, 12 Nov 2010 21:20:45 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build d75daa1
	failed
Message-ID: <4cddafad58f65_7270..fdbe313802f3@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...d75daa18d5b178e5e40d705bc113c881b5790b92 committed by Ryan Davis <ryand-ruby at zenspider.com> on 2010-11-12 20:58:18

    Added another missing dep install test case

 test/test_gem_dependency_installer.rb |   34 ++++++++++++++++++++++++++++----
 1 files changed, 29 insertions(+), 5 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_gather_dependencies_divergent(TestGemDependencyInstaller)
Type: Failure
Message: Gem::DependencyError expected but nothing was raised.

./test/test_gem_dependency_installer.rb:704


Name: test_gather_dependencies_under(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-1.1", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:682


Name: test_gather_dependencies_over(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-2.0", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:656




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/d75daa18d5b178e5e40d705bc113c881b5790b92 for details.

From noreply at rubyforge.org  Fri Nov 12 16:46:01 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 16:46:01 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28713 ] clean and remove
	should run in reverse topo sort
Message-ID: <20101112214601.6B3A8185837B@rubyforge.org>

Bugs item #28713, was opened at 2010-11-12 13:46
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28713&group_id=126

Category: `gem` commands (other)
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: John Barnette (jbarnette)
Summary: clean and remove should run in reverse topo sort

Initial Comment:
kiss my ass rubyforge. see summary.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28713&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:42:09 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:42:09 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-26752 ] system update should
	delete obsolete files
Message-ID: <20101112224209.1500E1678316@rubyforge.org>

Bugs item #26752, was opened at 2009-07-25 15:10
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26752&group_id=126

Category: RubyGems installer (setup.rb)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 1
Submitted By: Chad Woolley (thewoolleyman)
Assigned to: Chad Woolley (thewoolleyman)
Summary: system update should delete obsolete files

Initial Comment:
For example, rubygems/rubygems_version.rb

See: http://rubyforge.org/tracker/index.php?func=detail&aid=26740&group_id=126&atid=575

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26752&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:24 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:24 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-14943 ] rubygems should use
	the same arch specific subdirs in lib for the native
	extensions as ruby
Message-ID: <20101112224624.C679F18583B6@rubyforge.org>

Bugs item #14943, was opened at 2007-10-22 03:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

Category: RubyGems installer (setup.rb)
Group: v0.9.5
>Status: Closed
Resolution: None
Priority: 1
Submitted By: Marcus Rueckert (darix)
Assigned to: Eric Hodel (drbrain)
Summary: rubygems should use the same arch specific subdirs in lib for the native extensions as ruby

Initial Comment:
quoting my my mail to ruby-core [1]
[[[
there is another feature that gem doesnt handle nicely atm:
with the standard ruby directory layout you can share the tree via nfs
for multiple architectures as the native extensions are in an arch
specific path. within an installed gem they are directly inside the
"lib" subdir. i wonder if gem should use the arch specific subdirs below
its "lib" subdir aswell.
]]]

Eric asked me in a follow up to open a ticket here. :)

Looking forward to the fix :)

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12724

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 14:37

Message:
My experience with package management (Dev-C++, Autopackage, Phusion Passenger) so far is that dependency rules, especially for cross-platform software, can get very complex. I'm not sure whether it's at all possible to cover all cases without a turing-complete dependency specification language. Autopackage's dependency checking mechanism is turing-complete (shell scripts) and it works wonderfully well, though few people understand it because it's so powerful. But maybe it's possible to have a "good enough" system that works for most people, and let developers who need more power write their own thing, kinda like what we did for Phusion Passenger by splitting native dependency checking to passenger-install-*-module.

For DebGem we didn't try to make RubyGems support native dependencies. We just manually maintained a per-gem native dependency list.

I agree with not bothering with C++ compatibility. Most native extensions are written in C anyways. Developers can always write their own thing to handle this. For example the next version of Phusion Passenger will no longer specify extconf.rb in the gem spec; instead it will automatically compile the native extension when it's require()'ed into an Ruby version-, OS- and architecture-specific subdirectory under $HOME.

As for Rubists being pitiful at dependency management: most Rubyists are on OS X which has no proper dependency management, so most people are not only unfamiliar with native dependency management but also wouldn't benefit from it. :) If RubyGems is to support native dependencies it should make it extremely easy for gem writers to specify them correctly.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 10:33

Message:
I mean, whilst GCC versions might be ok for C++, what about say, a lua plugin or a php plugin, etc, etc. Tracking external dependencies and binary level compatibility becomes a nightmare with more VMs / runtimes, combined too with platforms, heh.

Maybe, if we could pull in a more advanced extconf, that allowed arbitrary addition of dependency information, by reasonably formed keys, maybe such as:

dependencies << [:debian, :package, :gcc, gcc_version]
dependencies << [:debian, :package, :lua, lua_version]
etc

Then compute that based on some hash of the total dependency set (merged with rubys). So then you have a ruby dependency hash, from rbconfig (plus expanded info), and a gem dependency hash from install-time expansion data.

I've actually missed something here, which is to tell the dependencies list how to check if those dependencies are still available... Need to store some code for that really, so eval strings (nominally probably calls to Kernel#`)...

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 10:28

Message:
Hongli Lai - agreed completely.

A hash of some larger set of attributes may be most appropriate.

As far as dependencies like C++ are concerned, there's little we can do to be complete in that area. 

I try to encourage a move toward proper dependency management, but rubyists are extremely pitiful at this traditionally.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 10:26

Message:
I support the idea of putting a gem in an arch specific subdir.

I am strongly against this subdir being inside the gems installed path.

1. some platform specific gems pack different *ruby* code in their gemfiles for specific archs
2. some gems do not use the commonly accepted paths, or have multiple lib paths, i wouldn't want selection of the path to become arbitrary



----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 08:27

Message:
I support this change. This would make it possible for multiple Ruby interpreters, possibly on multiple machines with different platforms, to share the same gem directory.

However I don't think Gem::Platform in its current form is adequate. While Gem::Platform is a good enough description of the platform, it isn't a good enough description of Ruby extension binary compatibility, which is what matters more. A few examples:
- OS X Snow Leopard broke the ABI by switching to x86_64 by default, but uname and therefore RUBY_PLATFORM still report i386 as platform.
- Ruby breaks API compatibility even between teeny releases, e.g. RSTRING_PTR vs RSTRING(x)->ptr. The former didn't exist until 1.8.6. On 1.8.7 and later it became required so that the latter doesn't work anymore. It doesn't look like the ABI changes but the Ruby core team doesn't seem to make any ABI guarantees. The switch from 1.8 to 1.9 most definitely breaks some ABI though.

For Phusion Passenger we use the following code to identify Ruby extension binary compatibility: http://pastie.org/786648

But even this doesn't tell us the entire story. For example it doesn't include the C++ ABI version, which can be a problem for Ruby extensions written in C++ like EventMachine. GCC breaks the C++ ABI regularly, sometimes even multiple times within the same minor release. For example GCC 3.1 broke the C++ ABI about 3 times if I recall correctly.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-02-01 20:56

Message:
Luis,

Right, modification to the extension builder would be required as far as I know.

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-31 05:03

Message:
Sorry not to properly introduce my question.

Let's say I build a gem with VC6 (i386-mswin32), the gem platform is x86-mswin32-60

This means, my lib folder will be like this:

lib/my_lib.rb
lib/x86-mswin32-60/my_ext.so

my_lib.rb contains this:

require 'my_ext'

now, I'm in a IRB session:

require 'rubygems'
require 'my_lib'

It is supposed to work out.

But what about this:

require 'rubygems'
require 'my_ext'

Right now, since lib is added to LOAD_PATH on gem activation, there is no problem with that.

With the change, it indicates that:

If a gem contains a platform folder for libdir and the platform matches the current one, it should append that folder into LOAD_PATH.

That is the correct assumption?

I believe changes to Extension Builders bundled in rubygems will be required.


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-27 09:52

Message:
Luis, I'm not sure what you mean by "require of the extension directly". Can you explain?

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-27 09:01

Message:
So this will mean "lib/#{Gem::Platform}" will be added to the $LOAD_PATH if exist, correct?

What happens when users doing the require of the extension directly? it triggers the activation mechanism?

I kind of like this, but maybe I'm missing a drawback that will against us in the long run?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-26 12:24

Message:
For example, if you install a C extension gem called 'foo' on Windows you want it to install as:

C:/ruby/lib/ruby/gems/1.8/gems/foo/lib/i386-msvcr80/foo.so

And Rubygems should add this sitearch directory to its search path?

Is that about the sum of it?

Regards,

Dan

----------------------------------------------------------------------

Comment By: 7rans  (transami)
Date: 2007-11-06 02:27

Message:
After some trial and error with extensions, I
m starting to agree with this. It's more flexible.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:24 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:24 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-21325 ] Print message when no
	gems matching your platform are found
Message-ID: <20101112224624.DB7361858381@rubyforge.org>

Bugs item #21325, was opened at 2008-07-24 12:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126

Category: `gem install` command
Group: v1.2.x
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Eric Hodel (drbrain)
Assigned to: Wilson Bilkovich (wilson)
Summary: Print message when no gems matching your platform are found

Initial Comment:
Instead of 'no gem to install'

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2010-02-18 15:04

Message:
http://rubyforge.org/tracker/index.php?func=detail&aid=27856&group_id=126&atid=575

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-03-13 16:11

Message:
Added platforms to gem list -d

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:24 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:24 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-22617 ] Gem.loaded_specs does
	not work on 1.9
Message-ID: <20101112224625.0BF7918583C4@rubyforge.org>

Bugs item #22617, was opened at 2008-10-30 09:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

Category: other
Group: v1.3.x
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Paul Brannan (cout)
Assigned to: Eric Hodel (drbrain)
Summary: Gem.loaded_specs does not work on 1.9

Initial Comment:
The loaded_specs attribute seems to always be empty on 1.9:

[pbrannan at zem ruby]$ ruby -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
{"ruby-prof"=>#<Gem::Specification:0x402fd664 @extra_rdoc_files=["bin/ruby-prof", "ext/ruby_prof.c", "examples/flat.txt", "examples/graph.txt", "examples/graph.html", "README", "LICENSE"], @date=Sun Feb 03 00:00:00 -0500 2008, @new_platform="ruby", @executables=["ruby-prof"], @authors=["Shugo Maeda and Charlie Savage"], @cert_chain=[], @required_rubygems_version=#<Gem::Requirement:0x402fd470 @version=nil, @requirements=[[">=", #<Gem::Version "0">]]>, @version=#<Gem::Version "0.6.0">, @files=["Rakefile", "README", "LICENSE", "CHANGES", "bin/ruby-prof", "lib/ruby-prof", "lib/ruby-prof.rb", "lib/unprof.rb", "lib/ruby-prof/abstract_printer.rb", "lib/ruby-prof/call_tree_printer.rb", "lib/ruby-prof/call_tree_printer.rb.rej", "lib/ruby-prof/flat_printer.rb", "lib/ruby-prof/graph_html_printer.rb", "lib/ruby-prof/graph_printer.rb", "lib/ruby-prof/profile_test_case.rb", "lib/ruby-prof/task.rb", "rails_plugin/ruby-prof", "rails_plugin/ruby-prof/init.rb", "rails_plugin/ruby-prof/lib", "rails_plugin/ruby-prof/lib/profiling.rb", "examples/flat.txt", "examples/graph.html", "examples/graph.txt", "ext/extconf.rb", "ext/extconf.rb.rej", "ext/measure_allocations.h", "ext/measure_cpu_time.h", "ext/measure_memory.h", "ext/measure_process_time.h", "ext/measure_wall_time.h", "ext/ruby_prof.c", "test/basic_test.rb", "test/duplicate_names_test.rb", "test/line_number_test.rb", "test/measure_mode_test.rb", "test/module_test.rb", "test/no_method_class_test.rb", "test/prime.rb", "test/prime1.rb", "test/prime2.rb", "test/prime3.rb", "test/prime_test.rb", "test/printers_test.rb", "test/profile_unit_test.rb", "test/recursive_test.rb", "test/singleton_test.rb", "test/start_test.rb", "test/test_helper.rb", "test/test_suite.rb", "test/thread_test.rb", "test/timing_test.rb"], @has_rdoc=true, @specification_version=2, @loaded=true, @requirements=[], @signing_key=nil, @default_executable="ruby-prof", @email="shugo at ruby-lang.org and cfis at savagexi.com", @required_ruby_version=#<Gem::Requirement:0x402fcad4 @version=nil, @requirements=[[">=", #<Gem::Version "1.8.4">]]>, @rdoc_options=["--title", "ruby-prof", "--inline-source", "--line-numbers", "--main", "README"], @bindir="bin", @rubygems_version="1.2.0", @homepage="http://rubyforge.org/projects/ruby-prof/", @name="ruby-prof", @platform="ruby", @autorequire=nil, @rubyforge_project="ruby-prof", @extensions=["ext/extconf.rb"], @summary="Fast Ruby profiler", @loaded_from="/usr/local/lib/ruby/gems/1.8/specifications/ruby-prof-0.6.0.gemspec", @original_platform=nil, @post_install_message=nil, @description="ruby-prof is a fast code profiler for Ruby. It is a C extension and therefore is many times faster than the standard Ruby profiler. It supports both flat and graph profiles.  For each method, graph profiles show how long the method ran, which methods called it and which  methods it called. RubyProf generate both text and html and can output it to standard out or to a file.", @dependencies=[], @test_files=["test/test_helper.rb", "test/test_suite.rb"], @require_paths=["bin", "lib"]>}
[pbrannan at zem ruby]$ ruby1.9 -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 216:'def' and line 218:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 231:'def' and line 233:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 246:'def' and line 248:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 261:'def' and line 263:'end'
{}


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 10:23

Message:
I can't require 'gemname' on ruby1.9.1. Could it be related?

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-01-18 18:44

Message:
you can run ruby --disable-gems (I think) to disable gem prelude (auto loading of gem lib dirs).
Barring that, you could submit a patch that compares $LOADED_FEATURES with the load paths of existing gems and "infers" "we have already loaded those other gems via the normal mechanism"
Cheers!
-r

----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 13:36

Message:
Yes, I would love to be able to provide a patch, but I don?t see a solution.  To me it looks like this is an inherent flaw in how Ruby 1.9 and Rubygems interact.  Since Ruby 1.9 adds all the paths to gems installed on your system, Rubygems never gets a chance to load the specs and thus solve this problem.  I have no idea why it was decided that Ruby 1.9 should augment its $LOAD_PATH in this way, nor why these things weren?t considered at the time, but it would be great if someone came up with a solution.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-10-21 10:00

Message:
Whiny you sound, patches are welcome too :-)



----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 09:48

Message:
This is still the case on Windows 1.9.1-p243.  By extension, Config.datadir, which is what I care about, doesn?t work.

I don?t want to sound whiny, but I can?t see how this can have gone unfixed for close to a year now.  It seems like a rather central concept.

----------------------------------------------------------------------

Comment By: Matt Hulse (mhulse)
Date: 2009-08-04 16:27

Message:
Yes, this is still happening in 1.9.1-p129.  I'm on WinXP Pro using the mingw32 build from rubyinstaller.org/downloads.  I just updated to rubygems 1.3.5 using gem update --system and Gem.loaded_specs is still empty until I call gem('') or gem('nokogiri') (the gem I'm looking for).

----------------------------------------------------------------------

Comment By: Joeri Samson (joeri)
Date: 2009-03-29 11:42

Message:
with 1.9.1p0 and rubygems 1.3.1 I get the same error as Eric Hodel, except if I print/access Gem.loaded_specs before calling gem "rake":

joeri at alpha ~ $ ruby19 -rubygems -e 'p Gem.loaded_specs; gem("rake"); p Gem.loaded_specs'
{}
{"rake"=>#<Gem::Specification:0x81c8240 @new_platform="ruby", @name="rake", @version=#<Gem::Version "0.8.4">, @summary="Ruby based make-like utility.", @email="jim at weirichhouse.org", @homepage="http://rake.rubyforge.org", @rubyforge_project="rake", @description="Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax.", @autorequire=nil, @default_executable="rake", @signing_key=nil, @post_install_message=nil, @original_platform=nil, @rubygems_version="1.3.1", @specification_version=2, @date=2009-03-04 00:00:00 +0100, @require_paths=["bin", "lib"], @bindir="bin", @has_rdoc=true, @required_ruby_version=#<Gem::Requirement:0x81c8088 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @required_rubygems_version=#<Gem::Requirement:0x81c7778 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @platform="ruby", @cert_chain=[], @authors=["Jim Weirich"], @files=["install.rb", "CHANGES", "MIT-LICENSE", "Rakefile", "README", "TODO", "bin/rake", "lib/rake/classic_namespace.rb", "lib/rake/clean.rb", "lib/rake/contrib/compositepublisher.rb", "lib/rake/contrib/ftptools.rb", "lib/rake/contrib/publisher.rb", "lib/rake/contrib/rubyforgepublisher.rb", "lib/rake/contrib/sshpublisher.rb", "lib/rake/contrib/sys.rb", "lib/rake/gempackagetask.rb", "lib/rake/loaders/makefile.rb", "lib/rake/packagetask.rb", "lib/rake/rake_test_loader.rb", "lib/rake/rdoctask.rb", "lib/rake/repaired_system.rb", "lib/rake/ruby182_test_unit_fix.rb", "lib/rake/runtest.rb", "lib/rake/tasklib.rb", "lib/rake/testtask.rb", "lib/rake/win32.rb", "lib/rake.rb", "test/capture_stdout.rb", "test/check_expansion.rb", "test/contrib/test_sys.rb", "test/data/rakelib/test1.rb", "test/data/rbext/rakefile.rb", "test/filecreation.rb", "test/functional.rb", "test/in_environment.rb", "test/rake_test_setup.rb", "test/reqfile.rb", "test/reqfile2.rb", "test/session_functional.rb", "test/shellcommand.rb", "test/test_application.rb", "test/test_clean.rb", "test/test_definitions.rb", "test/test_earlytime.rb", "test/test_extension.rb", "test/test_file_creation_task.rb", "test/test_file_task.rb", "test/test_filelist.rb", "test/test_fileutils.rb", "test/test_ftp.rb", "test/test_invocation_chain.rb", "test/test_makefile_loader.rb", "test/test_multitask.rb", "test/test_namespace.rb", "test/test_package_task.rb", "test/test_pathmap.rb", "test/test_rake.rb", "test/test_rdoc_task.rb", "test/test_require.rb", "test/test_rules.rb", "test/test_task_arguments.rb", "test/test_task_manager.rb", "test/test_tasklib.rb", "test/test_tasks.rb", "test/test_test_task.rb", "test/test_top_level_functions.rb", "test/test_win32.rb", "test/data/imports/deps.mf", "test/data/sample.mf", "test/data/chains/Rakefile", "test/data/default/Rakefile", "test/data/dryrun/Rakefile", "test/data/file_creation_task/Rakefile", "test/data/imports/Rakefile", "test/data/multidesc/Rakefile", "test/data/namespace/Rakefile", "test/data/statusreturn/Rakefile", "test/data/unittest/Rakefile", "test/data/unittest/subdir", "doc/command_line_usage.rdoc", "doc/example", "doc/example/a.c", "doc/example/b.c", "doc/example/main.c", "doc/example/Rakefile1", "doc/example/Rakefile2", "doc/glossary.rdoc", "doc/jamis.rb", "doc/proto_rake.rdoc", "doc/rake.1.gz", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @test_files=[], @rdoc_options=["--line-numbers", "--inline-source", "--main", "README", "--title", "Rake -- Ruby Make"], @extra_rdoc_files=["README", "MIT-LICENSE", "TODO", "CHANGES", "doc/command_line_usage.rdoc", "doc/glossary.rdoc", "doc/proto_rake.rdoc", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @executables=["rake"], @extensions=[], @requirements=[], @dependencies=[], @loaded=true, @loaded_from="/home/joeri/.gem/ruby/1.9.1/specifications/rake-0.8.4.gemspec">}

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-03-27 14:29

Message:
With 1.9.1p0 and 1.9.2dev I see:

$ ruby19 -v -rubygems -e 'gem "rake"; p Gem.loaded_specs'
ruby 1.9.2dev (2009-03-28 trunk 23085) [i386-darwin9.6.0]
<internal:gem_prelude>:234:in `push_gem_version_on_load_path': Could not find RubyGem rake (>= 0) (Gem::LoadError)
	from <internal:gem_prelude>:14:in `gem'
	from -e:1:in `<main>'

This will take a bit more work than I planned for 1.3.1, and may require changes to gem_prelude :/

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 03:50

Message:
Ah, no, I hit .activate, which hits source_index.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 03:48

Message:
works for me

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-02 07:59

Message:
Is this still happening in 1.9.1?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:25 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:25 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-22965 ] Gem activation fails
	because version requirement not correctly honored in its
	dependencies
Message-ID: <20101112224625.2C0A2167831A@rubyforge.org>

Bugs item #22965, was opened at 2008-11-24 15:17
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22965&group_id=126

Category: #gem and #require methods
Group: v1.3.x
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Pascal Hurni (phi)
Assigned to: Eric Hodel (drbrain)
Summary: Gem activation fails because version requirement not correctly  honored in its dependencies

Initial Comment:
Hi,

I have a scenario in my project with multiple dependencies. The problem is that rubygems will fail when activating the gems while the overall requirements are valid.

Here is the context:
  installed gems are: activesupport 2.0.2, activesupport 2.1.0,
actionpack 2.0.2, actionpack 2.1.0, mygem 1.0

  Main app => depends on:
    activesupport, '= 2.0.2'
    mygem => depends on:
      activesupport, '>= 1.4.0'
      actionpack, '>= 2.0.2'
      
The problem arise from the last requirement which is actionpack
>= 2.0.2.
The current implementation will load actionpack 2.1.0 but fail
when loading its dependencies
because one of them is activesupport, '= 2.1.0' (the equal sign
is very important here!).
It should have continued to try other version of actionpack until 2.0.2.

Prem proposed a patch [#22272] which didn't resolve my issue. (You may read the discussion)

I submit a patch against rubygems 1.3.1 to fix this issue.

Regards,

Pascal

For info, part of my RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.1
  - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
  - INSTALLATION DIRECTORY: D:/Dev/Lang/Ruby/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: D:/Dev/Lang/Ruby/bin/ruby.exe


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-03-27 14:56

Message:
This seems to be with dup of #21154.

I'll need to write some tests before applying this patch, it seems complicated.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22965&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:25 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:25 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-25509 ] exception using new
	generate_index in 1.3.2
Message-ID: <20101112224625.4FC29167831B@rubyforge.org>

Bugs item #25509, was opened at 2009-04-16 13:15
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=25509&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Johnathan Conley (jconley)
Assigned to: Eric Hodel (drbrain)
Summary: exception using new generate_index in 1.3.2

Initial Comment:

After upgrading to 1.3.2, I wiped out my old indexes, and build a full index from scratch. Everything worked fine... but afterwards I rsyned with the upstream server, one new gem was available... and then I ran generate_index with the --update option and received this error...


receiving file list ... done
Onion-0.0.2.gem

sent 240 bytes  received 623761 bytes  83200.13 bytes/sec
total size is 4929983101  speedup is 7900.60

$ gem generate_index --no-legacy --update -d /home/mirror/www --backtrace
Loading 1 gems from /home/mirror/www
.
Loaded all gems
loaded: 0.004s
Generating Marshal quick index gemspecs for 1 gems
.
Complete
Generated Marshal quick index gemspecs: 0.001s
ERROR:  While executing gem ... (NoMethodError)
    undefined method `<=>' for nil:NilClass
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:703:in `<=>'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:703:in `sort'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:703:in `update_specs_index'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:656:in `update_index'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems.rb:966:in `time'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:655:in `update_index'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/commands/generate_index_command.rb:125:in `execute'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in `invoke'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run'
	/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run'
	/opt/ruby/bin/gem:21


Below is the output from the first full index build... likely won't help since it completed without errors.

Complete
Generated Marshal quick index gemspecs: 11.859s
Generating specs index
WARNING:  Skipping invalid platform in gem: win32-api-1.0.4-x86-mswin32-60
Generated specs index: 0.483s
Generating latest specs index
Generated latest specs index: 0.094s
Generating prerelease specs index
Generated prerelease specs index: 0.000s
Compressing indicies
Compressed indicies: 0.068s


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Johnathan Conley (jconley)
Date: 2009-07-12 16:52

Message:
It's not specific to that gem... as long as any new gem is
added to the repo before performing a reindex with --update.
As you'll note in a subsequent post, there are a totally
different set of updated gems pulled before the reindex.

This should be reproducible as I'm replicating the master
rubyforge gems repository:
rsync -av --del --exclude-from=rubygems.excludes
rsync://master.mirror.rubyforge.org/gems/ $GEM_MIRROR_BASE/gems 

rubygems.excludes includes a few gems which had spec
problems affecting other bugs in the past:
win32-api-1.0.4-x86-mswin32-60.gem
facets-2005.10.10.gem
facets-2005.10.11.gem
facets-2005.10.15.gem
facets-2005.10.30.gem

I am running generate_index with the following params:
gem generate_index --no-legacy -d $GEM_MIRROR_BASE
--backtrace -V


----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-07-07 17:30

Message:
What is the output of `gem spec Onion-0.0.2.gem`

Either name, version or platform appear to be nil, or your specs file is corrupt on input.

Can you attach Onion-0.0.2.gem to this ticket?

----------------------------------------------------------------------

Comment By: Johnathan Conley (jconley)
Date: 2009-07-07 09:59

Message:
still happening in 1.3.4, now at indexer.rb:704:in `<=>'

----------------------------------------------------------------------

Comment By: Johnathan Conley (jconley)
Date: 2009-05-07 14:03

Message:
yes, still happening... same error and line

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-05-05 20:39

Message:
Still happening with 1.3.3?

----------------------------------------------------------------------

Comment By: Johnathan Conley (jconley)
Date: 2009-04-16 17:24

Message:

Here is my latest run with -V

$ ./mirror-rubygems.sh
receiving file list ... done
./
gem_tools-0.2.0.gem
graph-1.1.0.gem
hoe-1.12.2.gem
mingle-macro-development-toolkit-1.2.gem
provisional-1.2.5.gem
rforce-0.3.gem
unicorn-0.5.2.gem

sent 378 bytes  received 796293 bytes  75873.43 bytes/sec
total size is 4930164349  speedup is 6188.46
Loading 8 gems from /home/mirror/www
1/8: mingle-macro-development-toolkit-1.2
2/8: hoe-1.12.2
3/8: graph-1.1.0
4/8: gem_tools-0.2.0
5/8: unicorn-0.5.2
6/8: Onion-0.0.2
7/8: provisional-1.2.5
8/8: rforce-0.3
Loaded all gems
loaded: 0.097s
Generating Marshal quick index gemspecs for 8 gems
1/8: gem_tools-0.2.0
2/8: provisional-1.2.5
3/8: graph-1.1.0
4/8: rforce-0.3
5/8: hoe-1.12.2
6/8: unicorn-0.5.2
7/8: Onion-0.0.2
8/8: mingle-macro-development-toolkit-1.2
Complete
Generated Marshal quick index gemspecs: 0.030s
ERROR:  While executing gem ... (NoMethodError)
    undefined method `<=>' for nil:NilClass
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:703:in
`<=>'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:703:in
`sort'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:703:in
`update_specs_index'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:656:in
`update_index'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems.rb:966:in
`time'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/indexer.rb:655:in
`update_index'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/commands/generate_index_command.rb:125:in
`execute'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in
`invoke'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in
`process_args'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in
`run'
       
/opt/ruby-enterprise-1.8.6-20081205/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in
`run'
        /opt/ruby/bin/gem:21


----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-04-16 13:40

Message:
Can you run with -V as well?

gem generate_index --no-legacy --update -d /home/mirror/www --backtrace -V

This should give the gem that's causing the problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=25509&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:25 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:25 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-25816 ] misleading error
	message when one of many sources unreachable.
Message-ID: <20101112224625.7C9EA1779944@rubyforge.org>

Bugs item #25816, was opened at 2009-05-06 19:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=25816&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Larry Kyrala (coldnebo)
Assigned to: Nobody (None)
Summary: misleading error message when one of many sources unreachable.

Initial Comment:
I puzzled over the following for about half an hour:

$ sudo gem install hoe
ERROR:  While executing gem ... (Zlib::GzipFile::Error)
    not in gzip format

Until I finally figured out that one of my sources (aka 'gem sources') was a address only accessible on my company's VPN. (I wasn't on the VPN at the time.) e.g:

$ gem sources
*** CURRENT SOURCES ***

http://gems.rubyforge.org/
http://rubygems.xxx.xxx/    <-- vpn address

This error was confusing, because I was attempting to get 'hoe' which is clearly at gems.rubyforge.org, however apparently gem attempts to ping ALL the sources, even if one isn't available, it croaks with this obscure error.

At least this should be documented.

At most, gem should return a meaningful error if one of the gem sources is unreachable.

Ideally, if the install name is found in one of the gem sources that IS available, it shouldn't matter, and should simply install the gem from the available source.

Other info:

using Mac OSX 10.5

Macports:
$ port installed | grep ruby
  rb-rubygems @1.3.1_0 (active)
  ruby @1.8.7-p72_2+thread_hooks
  ruby @1.8.7-p160_1+thread_hooks (active)
  ruby186 @1.8.6-p287_0+darwin_9+thread_hooks


Hope this helps! 
-lk


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2009-09-15 13:18

Message:
The same issue is described here: http://groups.google.com/group/cukes/browse_thread/thread/fc9809247b3369f5

If multiple --source arguments are passed, rubygems will start to download from tha last one first. (Not sure if that's deterministic or semi-random).

On the first failure, rubygems will bail, not even trying the remaining sources.

----------------------------------------------------------------------

Comment By: Larry Kyrala (coldnebo)
Date: 2009-08-27 13:51

Message:
Ah, I see your point.  I was focusing on the invalid host
first and foremost -- I'm not sure why in linux it reports a
problem with the domain, while under Mac it reports a
fictitious GZip error.. perhaps they are different code
paths on the different platforms?

The original reported problem on the Mac seemed to be due to
vpn disconnect, because removing the gem source
corresponding to the vpn also worked in that case. 

I think the expected behavior (IMHO) should be:

sources.each do |source|
  begin
    source.connect
    next unless source.connected?
    gem = source.search gem_name
    next if gem.nil?
    source.install gem
    break
  ensure
    source.disconnect
  end
end

In this way, rubygems iterates over all the sources
configured until it has searched all the active sources or
finds the gem, whichever comes first.


----------------------------------------------------------------------

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-27 12:06

Message:
I thought you meant this:

> $ sudo gem install hoe
> ERROR:  While executing gem ... (Zlib::GzipFile::Error)
>     not in gzip format

was a misleading error message.
--------

If we consider:

ERROR:  could not find gem <gem> locally or in a repository

to be misleading, when there is only a dead host in the sources list, then we can look at that. So...

Gem::SpecFetcher#legacy_repos tries a couple rescues and then raises when _any_ source is not available, regardless if there are more to try, or there are already known good ones.

It is requested that rubygems continue if there is at least one good source in the list.


----------------------------------------------------------------------

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-27 11:53

Message:
I thought you meant this:

> $ sudo gem install hoe
> ERROR:  While executing gem ... (Zlib::GzipFile::Error)
>     not in gzip format

was a misleading error message.
--------

If we consider:

ERROR:  could not find gem <gem> locally or in a repository

to be misleading, when there is only a dead host in the sources list, then we can look at that. So...

Gem::SpecFetcher#legacy_repos tries a couple rescues and then raises when _any_ source is not available, regardless if there are more to try, or there are already known good ones.

It is requested that rubygems continue if there is at least one good source in the list.


----------------------------------------------------------------------

Comment By: Larry Kyrala (coldnebo)
Date: 2009-08-27 04:49

Message:
I'm still getting that error. I think maybe you only tested
with one source or two bogus sources. The problem manifests
with one valid and one bogus. let me show you an example
under linux:

lkyrala at lkyrala-ibex-64:~$ gem -v
1.3.4
lkyrala at lkyrala-ibex-64:~$ ruby -v
ruby 1.8.6 (2009-06-08 patchlevel 369) [x86_64-linux]

# first, I edit sources...
lkyrala at lkyrala-ibex-64:~$ gem sources
*** CURRENT SOURCES ***

# notice the FIRST entry is valid and correct:
http://gems.rubyforge.org/
# it's the second entry that is bogus or unreachable:
http://rubygems.nodomain.com/
lkyrala at lkyrala-ibex-64:~$ gem install smoke
ERROR:  http://rubygems.nodomain.com/ does not appear to be
a repository
ERROR:  could not find gem smoke locally or in a repository

# notice how gem INCORRECTLY failed to find smoke on
rubyforge even though it was the FIRST source entry and
valid.  Instead, it INCORRECTLY goes to the second source
and reports an error even though rubyforge works fine.


# so, changing the SECOND source to a valid source...
lkyrala at lkyrala-ibex-64:~$ gem sources
*** CURRENT SOURCES ***

http://gems.rubyforge.org/
# note: I only changed the SECOND source:
http://rubygems.mathworks.com/
lkyrala at lkyrala-ibex-64:~$ gem install smoke
Successfully installed smoke-0.0.6
1 gem installed

# notice that the gem installs from the FIRST source ok now
even though it was the second source that had the problem.

# note: the second source does not have "smoke" in it's repo.


----------------------------------------------------------------------

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-26 14:36

Message:
Proper error message is displayed on two linux boxes:

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.1
  - RUBY VERSION: 1.8.5 (2006-08-25) [i386-linux]

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.3
  - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]


ERROR:  http://gems.nosuchdomain.com does not appear to be a repository
ERROR:  could not find gem utility_belt locally or in a repository

Larry suggests: simply install the gem from the available source

If this is accepted, this should be a feature. As a bug, i can not reproduce. 







----------------------------------------------------------------------

Comment By: Larry Kyrala (coldnebo)
Date: 2009-05-06 19:43

Message:
BTW, I forgot to mention the workaround:

Simply remove the source that is unreachable and gem works fine.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=25816&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:25 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:25 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-25826 ] Uninstalling
	executables created with --format-executable
Message-ID: <20101112224625.A314219782CD@rubyforge.org>

Bugs item #25826, was opened at 2009-05-07 03:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=25826&group_id=126

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Sven Schwyn (sschwyn)
Assigned to: Nobody (None)
Summary: Uninstalling executables created with --format-executable

Initial Comment:
Here's an example:

gem install --format-executable rake
==> Installs executable "rake18".

ln -s rake18 rake
==> This step is performed by most Linux distros.

gem uninstall rake
==> Asks whether to uninstall "rake", but not "rake18".

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Matthew Kent (mattkent)
Date: 2010-10-25 10:05

Message:
We are migrating from ruby 1.8 and I'd love to see this as a config option so gem removal works as expected.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-19 06:32

Message:
Indeed, this should not be used on a per command basis at all.

I'm thinking about removing it to avoid these problems, and maintaining support purely by config file.

----------------------------------------------------------------------

Comment By: Sven Schwyn (svoop)
Date: 2010-01-14 10:51

Message:
In fact, just add --format-executable to the uninstall command and the case is closed as those using this option most likely won't use it on a "per command" basis.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=25826&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:25 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:25 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-26109 ] gem install gemname
	--remote will fail if gemname is in current directory
Message-ID: <20101112224625.E2DED19782D4@rubyforge.org>

Bugs item #26109, was opened at 2009-06-02 15:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: ara howard (ahoward)
Assigned to: Nobody (None)
Summary: gem install gemname --remote will fail if gemname is in current directory

Initial Comment:
gem install gemname --remote  will prefer a gem in the current directory.  seems like --remote should *never* do *anything* local?

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Christof Spies (wingfire)
Date: 2010-08-19 23:52

Message:
gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby1.8
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby/gems/1.8
     - /root/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/



----------------------------------------------------------------------

Comment By: Christof Spies (wingfire)
Date: 2010-08-19 23:47

Message:
I can confirm this issue.
i.e. you have an outdated gem file in your home directory and run  "gem update" from home then gem reinstall the old gem from the home directory. "gem update -r" is also "updating" with the outdated local gem.

----------------------------------------------------------------------

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-27 15:37

Message:
Just familiarizing myself with the code here. I now see the issue.

#find_gems_with_sources probably should only merge gem sources if @domain == :both

also I don't see a case in which setting @domain = :local after rescuing a RemoteFetch exception would be useful or make sense

----------------------------------------------------------------------

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-26 13:54

Message:
I can not reproduce this issue as a "preference". 

Rubygems appears to do remote as requested with requested gem in pwd.

In the case of no network availability, the requested gem in the pwd is installed. This is as designed: Gem::DependencyInstaller#find_gems_with_sources rescues with @domain = :local

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.3
  - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby/gems/1.8
     - /home/nihildeb/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"]
  - REMOTE SOURCES:
     - http://gems.rubyforge.org
     - http://gems.github.com






----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:25 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:25 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-26740 ] outdated
	rubygems/rubygems_version.rb still exists on Leopard default
	ruby install even though it was removed in 1.3.5
Message-ID: <20101112224626.1266D197833E@rubyforge.org>

Bugs item #26740, was opened at 2009-07-24 00:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126

Category: None
Group: None
>Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Chad Woolley (thewoolleyman)
Assigned to: Nobody (None)
Summary: outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5

Initial Comment:
Does system installer not delete old files?  If someone happens to load this file, they get a warning, then get the wrong version.

Can't we just move the version back into this file and avoid the issue altogether?

chadmac:1.8 woolley$ pwd
/Library/Ruby/Site/1.8
chadmac:1.8 woolley$ grep RubyGemsVersion rubygems.rb 
  RubyGemsVersion = VERSION = '1.3.5'
chadmac:1.8 woolley$ ls rubygems/rubygems_version.rb 
rubygems/rubygems_version.rb


chadmac:~ woolley$ irb
>> Gem::RubyGemsVersion
=> "1.3.5"
>> require 'rubygems/rubygems_version'
/Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion
/Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION
=> true
>> Gem::RubyGemsVersion
=> "1.3.4"


chadmac:~ woolley$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
  - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8
  - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - universal-darwin-9
  - GEM PATHS:
     - /Library/Ruby/Gems/1.8
     - /Users/woolley/.gem/ruby/1.8
     - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"]
  - REMOTE SOURCES:
     - http://gems.rubyforge.org
     - http://gems.github.com




----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-19 06:34

Message:
We should keep a manifest and use that during uninstalls.


----------------------------------------------------------------------

Comment By: Youssef Gaigi (youssefg)
Date: 2009-10-08 17:31

Message:
Did you figure out a way out of this.

I tried to delete rubygems and install again, but still the problem is there. Here's what I get whenever i require rubygems:

irb(main):001:0> require 'RubyGems'
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:14: warning: already initialized constant VERSION
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:14: warning: already initialized constant RubyGemsVersion
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:193: warning: already initialized constant MUTEX
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:195: warning: already initialized constant RubyGemsPackageVersion
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:207: warning: already initialized constant WIN_PATTERNS
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:1078: warning: already initialized constant MARSHAL_SPEC_DIR
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:1083: warning: already initialized constant YAML_SPEC_DIR
=> true

I appreciate your help

Youssef

----------------------------------------------------------------------

Comment By: John Trupiano (jtrupiano)
Date: 2009-09-17 18:53

Message:
You have fixed it Chad-- our preinit wasn't enforcing 0.5.3 or greater, and this particular box did not yet have 0.5.3 installed.

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-09-17 14:08

Message:
"You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb."

I'm sure I fixed this in the latest geminstaller release.  Please open a bug if I didn't.

----------------------------------------------------------------------

Comment By: John Trupiano (jtrupiano)
Date: 2009-09-17 11:44

Message:
Hey Ryan,

You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb.

As a result, the "require 'rubygems'" call on line 86 of config/boot.rb was actually returning false and consequently not setting the RubyGemsVersion to 1.3.5 appropriately.

This explains why I could not reproduce the problem in irb.  My apologies for the noise.

In any case, manually deleting the file did do the trick.

-John


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2009-09-17 11:23

Message:
I just looked at rails 2.3.4 and don't see any place that rubygems_version is being required. The version checking code requires rubygems and then uses RubyGemsVersion.

How did you get bit by this bug?

----------------------------------------------------------------------

Comment By: John Trupiano (jtrupiano)
Date: 2009-09-17 07:55

Message:
I just want to point out that this exact bug bit us pretty badly again.  The scenario is this (and I'm surprised it hasn't happened more frequently):

We're running a rails 2.3.4 app.  The rails 2.3.x branch requires rubygems 1.3.2 or greater.

On this particular OSX machine, we jumped from RubyGems 1.3.1 directly to 1.3.5.  As a result, this left the rubygems_version.rb file specifying version 1.3.1.  As a result, we could never actually run the rails app because of the version checking code in config/boot.rb.

It took us quite awhile to track down what the issue really was.  Others not so in tune with RubyGems development are surely to lose a whole lot more time than we did.

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-07-24 13:53

Message:
Agreed, a very low priority.  I was only requiring explicitly as a side effect of my regression tests - normally you should rely on rubygems to require what it needs.

However, this should probably get turned into a bug with the system install command, because it isn't deleting old files.  This could come back to bite us in a more serious way in the future.

----------------------------------------------------------------------

Comment By: John Trupiano (jtrupiano)
Date: 2009-07-24 13:51

Message:
I can confirm the odd behavior on a default Leopard install:

john-mbp:1.8 john$ irb
irb(main):001:0> Gem::RubyGemsVersion
=> "1.3.5"
irb(main):002:0> require 'rubygems/rubygems_version'
/Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion
/Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION
=> true
irb(main):003:0> Gem::RubyGemsVersion
=> "1.3.4"

-John

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-07-24 12:16

Message:
I agree, the rubygems_version.rb file should be deleted on update if possible. Mind you, I've never heard of anyone explicitly require'ing that file, so it strikes me as a very low priority item, but it's still something we could fix.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-07-24 12:01

Message:
Rejected with no comment, huh?  Classy.

You ignore the fact that there are actual bugs:  

* RubyGems 1.3.5 introduced an obsolete file on the Leopard distribution
* This file contains an outdated and conflicting RubyGems version number
* If any existing rubygems API clients happen to still load this file, they will get a warning, and rubygems will subsequently report the incorrect and outdated version.
* There is a bug with the system update command that does not delete old files, at least on the default Leopard install.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:26 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-26792 ] uses gem even when an
	install fails
Message-ID: <20101112224626.3E8EB19783BA@rubyforge.org>

Bugs item #26792, was opened at 2009-07-29 16:59
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26792&group_id=126

Category: None
Group: v1.3.x
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Evan Phoenix (evan)
Summary: uses gem even when an install fails

Initial Comment:
Appears that in 1.9, at least

if you install a gem, and the installation fails

then you run 
require 'gemname'
it still loads it--in its very broken state.

At least that's about what I figure from scratching my head at this circumstance:

C:\dev\ruby\downloads\ruby-debug\pkg>gem search linecache -b

*** LOCAL GEMS ***

mark-moseley-linecache (0.5.2)
# note the lack of linecache -- removing mark-moseley-linecache seems to not affect the results, either

*** REMOTE GEMS ***

linecache (0.43)
mark-moseley-linecache (0.5.2)

C:\dev\ruby\downloads\ruby-debug\pkg>gem install linecache
Building native extensions.  This could take a while...
ERROR:  Error installing linecache:
        ERROR: Failed to build gem native extension.

c:/installs/ruby_trunk_installed/bin/ruby.exe extconf.rb
Can't handle 1.9.x yet
*** extconf.rb failed ***
...

C:\dev\ruby\downloads\ruby-debug\pkg>gem search linecache

*** LOCAL GEMS ***

mark-moseley-linecache (0.5.2)

C:\dev\ruby\downloads\ruby-debug\pkg>irb
irb(main):001:0> require 'ruby-debug'
LoadError: no such file to load -- c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/../lib/trace_nums # note that it's using the linecache-0.43 that just failed
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/tracelines.rb:12:in `require'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/tracelines.rb:12:in `rescue in <module:TraceLineNumbers>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/tracelines.rb:8:in `<module:TraceLineNumbers>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/tracelines.rb:6:in `<top (required)>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/linecache.rb:63:in `require'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/linecache.rb:63:in `<top (required)>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/mark-moseley-ruby-debug-base-0.11.6/lib/ruby-debug-base.rb:3:in `require'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/mark-moseley-ruby-debug-base-0.11.6/lib/ruby-debug-base.rb:3:in `<top (required)>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/ruby-debug-0.11/cli/ruby-debug.rb:5:in `require'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/ruby-debug-0.11/cli/ruby-debug.rb:5:in `<top (required)>'
        from (irb):1:in `require'
        from (irb):1
        from c:/installs/ruby_trunk_installed/bin/irb.bat:20:in `<main>'

Thanks!

[gem v 1.3.5, ruby 1.9.2 trunk]

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-13 08:33

Message:
`gem list` cannot reproduce the issue.

It's gem_prelude requires not using the installed spec list that's the problem.

Assigning to Evan.

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-02-09 07:56

Message:
It doesn't show up as a gem list, however it still gets
assigned to the load path thanks to gem prelude.

How to reproduce:

c:\dev_old\digitalarchive_trunk>gem install linecache
Building native extensions.  This could take a while...
ERROR:  Error installing linecache:
        ERROR: Failed to build gem native extension.

...
c:\dev_old\digitalarchive_trunk>gem search linecache

*** LOCAL GEMS ***


c:\dev_old\digitalarchive_trunk>gem which linecache
E:/installs/ruby191p376/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/linecache.rb

(and you can require it--require 'linecache' even though the
install failed, which was unexpected to me since 1.8 doesn't
do this).
-r

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-02-08 21:38

Message:
I believe this was fixed prior to 1.3.5 as 1.8 and 1.9.2 trunk give me the same:

$ ruby19 -Ilib bin/gem install mysql -i ~/tmp/gems

mysql 2.8.1 is 100% verified 1.9
Update http://isitruby19.com/mysql with your experiences!

Building native extensions.  This could take a while...
ERROR:  Error installing mysql:
	ERROR: Failed to build gem native extension.
[...]
$ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ruby19 -Ilib bin/gem list

*** LOCAL GEMS ***


$

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26792&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:26 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-26892 ] Gem::Ext::RakeBuilder
	can't execute Rake on JRuby if Rake gem isn't installed
Message-ID: <20101112224626.80B3819783BC@rubyforge.org>

Bugs item #26892, was opened at 2009-08-07 12:16
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26892&group_id=126

Category: `gem install` command (extensions)
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Jake Douglas (yakischloba)
Assigned to: Nobody (None)
Summary: Gem::Ext::RakeBuilder can't execute Rake on JRuby if Rake gem isn't installed

Initial Comment:
On JRuby, when installing a gem that has 'extensions = "Rakefile"' as part of it's specification, Gem::Ext::RakeBuilder tries to run 'jrake' which does not exist in JRuby. This occurs when the actual Rake gem is not installed. This can be worked around by requiring the rake gem as a dependency, but the desired behavior would be for it to find the rake that is bundled with JRuby.

This line, in the "1.8" compatible rubygems, is the culprit:

cmd = ENV['rake'] || "#{Gem.ruby} -rubygems #{Gem.bin_path('rake')}" rescue Gem.default_exec_format % 'rake'


In the "1.9" rubygems, its like this:

cmd = ENV['rake'] || 'rake'

which probably wouldn't work either unless JRuby is the default Ruby or the JRuby rake points it to the jruby executable.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-08-21 01:20

Message:
This is a problem because of inconsistent policy. I strongly recommend "wontfix" until this is actually sat down and thought about some more.

Gem.default_exec_format should really be the default so that we don't clobber multiple interpreters all the time. As more *applications* are available in the ruby space, this will become more common on open source platforms where apps are installed by package manager.

The special casing of system and random selection of executable names under jruby makes it extremely hard to get this right in all situations, and the above at least attempts to make it work when things are installed by gem, which is the highest level of reliability I can guarantee at this time.

Falling back to 'rake' on platforms where it is going to launch MRI has very strange impacts.

I would love to have a non-bikeshed discussion with everyone involved on this topic - that includes Charlie, Eric, myself and if we can get it, Matz. The only reason I would like matz to chime in, is that this is also related to the bundling of rake, and the lack of correct binary prefix and postfix discovery in the main MRI packages.

What we cannot do is keep making changes that fix one specific side of the problem, otherwise this will never go away. I also suspect that someone is going to have to suck it up and suffer a change, in order to reach consistency. Sadly I feel it is likely this will be the jruby project, and whilst I don't want to force that on them, I would like them to present some kind of reasonable alternative if they have one. I do not believe special casing system more will solve this issue.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26892&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:26 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-26958 ]
	Gem::Specification.hash can cause to_yaml RangeError
Message-ID: <20101112224626.A74251779944@rubyforge.org>

Bugs item #26958, was opened at 2009-08-19 22:18
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Simon Chiang (prosperity)
Assigned to: Nobody (None)
Summary: Gem::Specification.hash can cause to_yaml RangeError

Initial Comment:
Array.hash for objects do not produce a Fixnum hash will blow up. Gem::Specification often produces a Bignum and this prevents an array of specifications from being converted to YAML.

This issue (which is really a ruby issue) will be fixed in a future release but I thought you might like to know in case you wanted to patch RubyGems for versions prior to the fix.

(see http://redmine.ruby-lang.org/issues/show/1883)

==========================
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.1
  - RUBY VERSION: 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
  - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8
  - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - universal-darwin-9
  - GEM PATHS:
     - /Library/Ruby/Gems/1.8
     - /Users/simonchiang/.gem/ruby/1.8
     - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://gems.rubyforge.org/", "http://gems.github.com"]
  - REMOTE SOURCES:
     - http://gems.rubyforge.org/
     - http://gems.github.com


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Bruno Michel (nono)
Date: 2010-02-27 05:12

Message:
Bundler also seems to convert specs to yaml. See this message on the Rails-core mailing-list: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/a0ba2eacb26b5524?hl=en#

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-08-20 15:54

Message:
You probably wanted to use pp then.

----------------------------------------------------------------------

Comment By: Simon Chiang (prosperity)
Date: 2009-08-20 15:25

Message:
@chad

Ok, great.  I'll work a little something up when I get a
free minute.

@eric

A framework I'm working on (http://tap.rubyforge.org)
discovers resources within gems and my environment ends up
referencing an array of specs.  At some point I dumped the
environment and found the error.  Honestly, it's just
something I stumbled on.  I don't actually have a specific
need to convert the specs to YAML.



----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-08-20 13:48

Message:
Why are you converting specs to YAML in the first place?

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-08-20 10:55

Message:
This looks reasonable and is reproducible, but I'm not sure what is dependent upon the current implementation of hash.  Maybe someone else can weigh in...

Regardless, can you please submit this as a proper patch, with your failing tests added to the appropriate file (test_gem_specification.rb) - and, of course, ensure nothing else in the test suite breaks?

Thanks,
-- Chad

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:26 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27099 ] Problems with gems
	(treetop, polyglot,
	test-unit) installed in $HOME/.gem instead of /usr/local/...
Message-ID: <20101112224626.D6BF519783BD@rubyforge.org>

Bugs item #27099, was opened at 2009-09-13 15:00
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27099&group_id=126

Category: #gem and #require methods
Group: v1.3.x
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Cezary Baginski (czarek)
Assigned to: Nobody (None)
Summary: Problems with gems (treetop, polyglot, test-unit) installed in $HOME/.gem instead of /usr/local/...

Initial Comment:
I filed it initially as a bug in Lighthouse (cucumber):

https://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/445-patch-cucumber-cannot-find-treetop-if-all-gems-are-in-homegem#ticket-445-4

It seems like adding:

    gem 'foo-bar'

fixes things for some gems, others need:

    Gem.activate('foo-bar')

The Lighthouse ticket has a specific, detailed example in cucumber.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Cezary Baginski (czarek)
Date: 2009-09-18 11:21

Message:
Workaround - add a version requirement, e.g.:

gem 'foo-bar', '>=0'

Ticket on redmine / ruby-core:

http://redmine.ruby-lang.org/issues/show/2119

----------------------------------------------------------------------

Comment By: Cezary Baginski (czarek)
Date: 2009-09-13 15:56

Message:
Just to make sure, I tried trunk (r2296), but it wouldn't
let me even install gems in $HOME, even with --user-install
(exception with Requirement being Nil in <=>() ). Maybe I'll
submit a bug tomorrow.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27099&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:26 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and
	Ruby 1.9 breaks hard after require 'rubygems/specification'
Message-ID: <20101112224627.0388619783C0@rubyforge.org>

Bugs item #27087, was opened at 2009-09-10 13:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126

Category: #gem and #require methods
Group: None
>Status: Closed
Resolution: None
Priority: 1
Submitted By: Rob Sanheim (rsanheim)
Assigned to: Eric Hodel (drbrain)
Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification'

Initial Comment:
Please see the repo:

http://github.com/rsanheim/ruby19_rubygems_bug/tree/master

The build is here:

http://runcoderun.com/rsanheim/ruby19_rubygems_bug

The failing build on Ruby 1.9.1 p243:

http://runcoderun.com/rsanheim/ruby19_rubygems_bug

http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191

Here is the simplest code to illustrate:

  require 'hoe'
  gem 'hoe' # these should work

  puts "about to break 'gem'"  
  require 'rubygems/specification'
  gem 'hoe' # exception thrown here when it shouldn't be


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Hedge Hog (hedgehog)
Date: 2010-05-09 01:23

Message:
OK, disregard last comment. Some other gems need to be installed.

Recommended workaround is as mentioned before:
Remove require 'rubygems/specification'

So far I have not seen any adverse side effects.

----------------------------------------------------------------------

Comment By: Hedge Hog (hedgehog)
Date: 2010-05-08 21:23

Message:
Why I'm not yet sure but it is called after rake/gempackagetask.  Specifically:

require 'rubygems'
require 'rake/gempackagetask'
require 'rubygems/specification'

If I comment out the 
require 'rubygems/specification'

I still get a failure:

http://www.pastie.org/952149

I'm yet to get my head around how/why Chef has to use this sequence.... they may not be alone.

It is still a useful example of a reproducible case that is minimal:

$ gem list --local

*** LOCAL GEMS ***

rake (0.8.7)
rdoc (2.5.8)

HTH?


----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-05-04 13:26

Message:
Why are you requiring rubygems/specification?

require 'rubygems' provides it for you.

----------------------------------------------------------------------

Comment By: Hedge Hog (hedgehog)
Date: 2010-05-03 22:49

Message:
The following is a minimal rvm example, the `rake -T` command triggers the issue here too:

bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

cat >~/.bash_profile <<EOT
source ~/.bashrc
export LC_ALL=en_US.utf8
export LANGUAGE=en_US.utf8
export LANG=en_US.utf8
if [[ -s ~/.rvm/scripts/rvm ]] ; then source ~/.rvm/scripts/rvm ; fi
EOT

source ~/.bash_profile
rvm install 1.9.1 

pushd ~/src
git clone git://github.com/opscode/mixlib-authentication.git
pushd mixlib-authentication
rake -T 2>&1|tee /tmp/rake-t-error.log
popd
popd


The rake log is here:
http://www.pastie.org/944745

HTH?


gem list --local

*** LOCAL GEMS ***

rake (0.8.7)
rdoc (2.5.8)



----------------------------------------------------------------------

Comment By: Hedge Hog (hedgehog)
Date: 2010-05-03 21:39

Message:
Also affects:
    
    ruby 1.9.2dev (2009-07-18 trunk 24186) [x86_64-linux]

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-04-21 20:54

Message:
I'm not entirely sure how this is breaking, but require 'rubygems' provides Gem::Specification, so you don't need to require it.  The workaround is to not require 'rubygems/specification'.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2009-09-11 00:30

Message:
We've already tracked down the problem. The workaround as described is to remove your manually installed rubygems from 1.9.x. 

----------------------------------------------------------------------

Comment By: Adam Salter (aqsalter)
Date: 2009-09-10 23:33

Message:
Ryan: Sorry about that. I (too) am working on several projects, busy and wanted to throw in my helpful comments... I find problems can get fixed quicker if the devs know how many people are affected.

I misunderstood your initial comment: 

'0 failures out of 4' sounds like no failures, which could certainly be assumed to be a good thing - except we are trying to track down a problem.

+1 biting off a much ruder comment and looking to the future with hope and optimism.


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2009-09-10 23:08

Message:
Please don't +1. That shit is obnoxious.

We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone.

----------------------------------------------------------------------

Comment By: Adam Salter (aqsalter)
Date: 2009-09-10 18:47

Message:
+1 please fix... Not exactly 'urgent' but annoying.

I raised a bug on the 'jeweler' gem because of this:

http://github.com/technicalpickles/jeweler/issues#issue/34

I'm sure that the code i provide there:

Rakefile: require 'jeweler'

rake -T

will trigger issue.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2009-09-10 13:54

Message:
Huh!

% sudo gem uninstall rubygems-update
% multiruby -rubygems -rrubygems/specification -e 'gem "hoe"'
...
TOTAL RESULT = 0 failures out of 4

Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2009-09-10 13:53

Message:
Easier repro of the warnings:

multiruby -rubygems -rrubygems/specification -e 0

and:

multiruby -rubygems -rrubygems/specification -e 'gem "hoe"'


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:26 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is
	sometimes too large.
Message-ID: <20101112224627.41C7419782D4@rubyforge.org>

Bugs item #27154, was opened at 2009-09-21 07:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Ryan Riley (panesofglass)
Assigned to: Nobody (None)
Summary: Computed hash is sometimes too large.

Initial Comment:
The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value:

class C
  def hash
    100000000000000000000
  end
end

[C.new].hash  # => in `hash': bignum too big to convert into 
`long' (RangeError)

REXML has a similar issue. http://redmine.ruby-
lang.org/issues/show/1883 tracks the issue, and MRI will be 
fixing the issue.

Suggested fixes are:

edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659
File: dependency.rb
===================================================================
--- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659  (server)    6/23/2009 1:21 PM
+++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb
@@ -112,7 +112,7 @@
   end
 
   def hash # :nodoc:
-    name.hash + type.hash + version_requirements.hash
+    name.hash ^ type.hash ^ version_requirements.hash
   end
 
 end
===================================================================
edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357
File: specification.rb
===================================================================
--- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357  (server)    6/23/2009 1:24 PM
+++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb
@@ -661,9 +661,8 @@
     private :same_attributes?
 
     def hash # :nodoc:
-      @@attributes.inject(0) { |hash_code, (name, default_value)|
-        n = self.send(name).hash
-        hash_code + n
+      @@attributes.inject(612553) { |hash_code, (name, default_value)|
+        hash_code ^ self.send(name).hash
       }
     end
 
===================================================================

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Craig Cook (ccook)
Date: 2010-10-18 14:08

Message:
Hello,

I tried this patch, but I am still getting the error, at the same place in the code.  The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above.  This happened when installing using bundler, executed via capistrano.

We  had been using hpricot, it wasn't needed, it was giving this error first.  I took it out, but then the same  RangeError happened with mysql.  I've seen it before also with nokogiri.  (Always with native gems, though).

Here's the relevant part of the log:
----------- begin log ----------------------------
 ** [out :: 192.168.10.63] Installing mysql (2.8.1)
 ** [out :: 192.168.10.63] with native extensions
 ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash'
 ** [out :: 192.168.10.62] :
 ** [out :: 192.168.10.62] bignum too big to convert into `long'
 ** [out :: 192.168.10.62] (
 ** [out :: 192.168.10.62] RangeError
 ** [out :: 192.168.10.62] )
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from'
 ** [out :: 192.168.10.62] ... 22 levels...
 ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13
 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load'
 ** [out :: 192.168.10.62] from /usr/bin/bundle:19
----------- end cap output -------------------


running:
------------ system & ruby info ------------------
[ccook at ev2-stage ~]$ ruby -v
ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux]
[ccook at ev2-stage ~]$ gem  -v
1.3.7
[ccook at ev2-stage ~]$ uname -a
Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux
------ end system / ruby info  ----------

Gemfile:

----------- begin Gemfile -----------------
  source :gemcutter
             
  gem 'rails',          '2.3.8'    
  gem 'mysql',          '2.8.1'
  gem "geokit"
  gem "geokit-rails" 
  gem "builder"
  gem 'chronic'
  gem 'whenever'
  gem 'database_cleaner'       
  gem 'apn_on_rails'
  gem 'factory_girl'
  gem 'net-sftp'   
  gem 'will_paginate'    # dependency for squirrel & jqgrid
  gem 'nokogiri'           # only for test/functional/auth_controller_test.rb           
  
  gem 'cucumber'
  gem 'cucumber-rails'
  gem 'webrat'
  gem 'rspec'

---------- end Gemfile -----------------


So, is this the same issue? It sure looks like it to me.  I hope not to have to dive into the innards of rubygems if  possible.  But we need to be able to deploy.  The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap.  I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again.

Thanks for your time in this!

Cheers,
Craig

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:27 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:27 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27216 ] R1.9 require does not
	work when ENV['GEM_PATH'] specified
Message-ID: <20101112224627.5966F19783C5@rubyforge.org>

Bugs item #27216, was opened at 2009-09-30 02:18
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27216&group_id=126

Category: #gem and #require methods
Group: v1.3.x
>Status: Closed
Resolution: None
Priority: 3
Submitted By: V?t Ondruch (voxik)
Assigned to: Nobody (None)
Summary: R1.9 require does not work when ENV['GEM_PATH'] specified

Initial Comment:
Hello,

I'm trying to modify GEM_PATH variable from ruby script. However, modification of GEM_PATH environment variable has no effect since rubygems/custom_require is not required for Ruby 1.9. What was the intention here?

Of course I can use Kernel.gem method which will populate $LOAD_PATH properly and then regular require works well, but is not consistent, since you don't have to do it for regular gem directories.

Cheers


Vit

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27216&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:27 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:27 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27366 ] gem env command
	doesn't display ~/.gem as a gem path
Message-ID: <20101112224627.8886219783BC@rubyforge.org>

Bugs item #27366, was opened at 2009-10-28 09:24
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27366&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
>Status: Closed
Resolution: None
Priority: 1
Submitted By: Roger Pack (rogerdpack)
Assigned to: Eric Hodel (drbrain)
Summary: gem env command doesn't display ~/.gem as a gem path

Initial Comment:
Currently gem treats ~/.gem as a gem path, however running gem env doesn't hint at that fact.

rdp at li49-39:~/dev/downloads/rubygems-1.3.5$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.8.6 (2009-3-4 patchlevel 287) [i686-linux]
  - INSTALLATION DIRECTORY: /home/rdp/dev/downloads/rubygems-1.3.5
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - EXECUTABLE DIRECTORY: /home/rdp/dev/downloads/rubygems-1.3.5/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-linux
  - GEM PATHS:
     - /home/rdp/dev/downloads/rubygems-1.3.5
  - GEM CONFIGURATION:
      ...

Thanks!
-r

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-04-21 21:06

Message:
Mine shows ~/.gem as well.  I cannot reproduce.

gem env gemdir is the same as GEM_HOME

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-10-28 10:51

Message:
Hm, mine did on Snow Leopard:

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10.0.0]
  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /usr/local/lib/ruby/gems/1.8
     - /Users/dberger/.gem/ruby/1.8
 ...

Interestingly, when I run "gem env gempath" it only shows my .gem path, while "gem env gemdir" only shows the /usr/local/lib path. Intentional? Not sure.

Not sure what to make of this yet.

Regards,

Dan

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27366&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:27 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:27 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27324 ] string contains null
	byte
Message-ID: <20101112224627.D99DB197833E@rubyforge.org>

Bugs item #27324, was opened at 2009-10-21 02:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27324&group_id=126

Category: `gem install` command
Group: v1.3.x
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Thomas Preymesser (thopre)
Assigned to: Nobody (None)
Summary: string contains null byte 

Initial Comment:
Hello,

i get this error when i try to install rails. 
Many other gems can be installed without problems.


$ sudo gem install  rails --backtrace
ERROR:  While executing gem ... (ArgumentError)
    string contains null byte
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_reader/entry.rb:66:in `join'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_reader/entry.rb:66:in `full_name'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_input.rb:32:in `block in initialize'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_reader.rb:63:in `block in each'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_reader.rb:54:in `loop'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_reader.rb:54:in `each'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_input.rb:31:in `initialize'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_input.rb:16:in `new'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package/tar_input.rb:16:in `open'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/package.rb:56:in `open'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/format.rb:67:in `from_io'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/format.rb:51:in `block in from_file_by_path'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/format.rb:50:in `open'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/format.rb:50:in `from_file_by_path'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/installer.rb:119:in `initialize'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/dependency_installer.rb:239:in `new'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/dependency_installer.rb:239:in `block in install'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/dependency_installer.rb:222:in `each'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/dependency_installer.rb:222:in `install'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:118:in `block in execute'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:115:in `each'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/commands/install_command.rb:115:in `execute'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/command.rb:257:in `invoke'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/command_manager.rb:132:in `process_args'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/command_manager.rb:102:in `run'
	/usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/gem_runner.rb:58:in `run'
	/usr/local/bin/gem:21:in `<main>'

$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.9.2 (2009-10-21 patchlevel -1) [i686-linux]
  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.9.1
  - RUBYGEMS PREFIX: /usr/local/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-linux
  - GEM PATHS:
     - /usr/local/lib/ruby/gems/1.9.1
     - /home/tp/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://gems.rubyforge.org/"]
     - "rdoc" => "--inline-source --line-numbers --format=html --template=hanna"
  - REMOTE SOURCES:
     - http://gems.rubyforge.org/


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27324&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:27 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:27 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27301 ] gem uninstall without
	sudo incorrectly reports success on OS X
Message-ID: <20101112224627.EBB2419783BD@rubyforge.org>

Bugs item #27301, was opened at 2009-10-15 20:20
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27301&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Craig Walker (softcraft)
Assigned to: Nobody (None)
Summary: gem uninstall without sudo incorrectly reports success on OS X

Initial Comment:
On my system (OS X 10.5.8), uninstalling a gem without using "sudo" first causes gem to report that it  uninstalled the gem. However, it does not do so; the gem remains intalled.

I install gems using sudo; I get error messages if I forget it.

Running with --debug shows plenty of permissions errors, but those aren't propagated up under normal circumstances.

Attached is a copy of a gem session that shows the error and the pertinent info.

Is this a widespread issue? If so, could it be fixed so that it correctly fails?

Thanks,

Craig Walker
SoftCraft Development



----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Craig Walker (softcraft)
Date: 2009-10-16 12:54

Message:
I have had other problems with Ruby so I would not be
surprised if it was something specific to my machine.

Is there anything I can do to debug it further?

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2009-10-16 12:27

Message:
I'd have to guess that you or macports messed with your perms in some way, or macports patches rubygems? The only other difference I see is in GEM_PATH, so that is prolly easier to check first.

I can't repro this at all:

drwxr-xr-x   7 root  admin  374 Aug 31 15:14 zenweb-2.18.1/
503 % gem uninstall zenweb
Remove executables:
	zenweb, zenwebpage, zenwebsite

in addition to the gem? [Yn]  
ERROR:  While executing gem ... (Gem::FilePermissionError)
    You don't have write permissions into the /usr/bin directory.
504 % gem -v
1.3.5
505 % gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]
  - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8
  - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - universal-darwin-10
  - GEM PATHS:
     - /Library/Ruby/Gems/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://gems.rubyforge.org"]
  - REMOTE SOURCES:
     - http://gems.rubyforge.org


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27301&group_id=126

From noreply at rubyforge.org  Fri Nov 12 17:46:27 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 17:46:27 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27413 ] unable to install gem
	specified version
Message-ID: <20101112224628.13A7B19783C7@rubyforge.org>

Bugs item #27413, was opened at 2009-11-07 16:46
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27413&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to install gem specified version

Initial Comment:

C:\dev\ruby\crystalizer>gem search ruby2cext -b -a

*** LOCAL GEMS ***



*** REMOTE GEMS ***

ruby2cext (0.2.0)

C:\dev\ruby\crystalizer>gem install ruby2cext -v0.2.0
Successfully installed ruby2cext-0.2.1
1 gem installed

C:\dev\ruby\crystalizer>ls
Changelog  TODO        bin  ruby2cext-0.2.1.gem  stuff
README     VERSION     doc  ruby2cext.gemspec    test
Rakefile   benchmarks  lib  setup.rb

I'm guessing the cause is a ruby2cext-0.2.1.gem existing in the current working directory.
Not that this is not a show stopper, but thought I'd mention it.


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2009-11-09 00:09

Message:
% gem help install | grep -- --remote
    -r, --remote                     Restrict operations to the REMOTE domain


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27413&group_id=126

From noreply at rubyforge.org  Fri Nov 12 18:28:08 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 18:28:08 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-22617 ] Gem.loaded_specs does
	not work on 1.9
Message-ID: <20101112232808.953AB185837B@rubyforge.org>

Bugs item #22617, was opened at 2008-10-30 16:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

Category: other
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Paul Brannan (cout)
Assigned to: Eric Hodel (drbrain)
Summary: Gem.loaded_specs does not work on 1.9

Initial Comment:
The loaded_specs attribute seems to always be empty on 1.9:

[pbrannan at zem ruby]$ ruby -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
{"ruby-prof"=>#<Gem::Specification:0x402fd664 @extra_rdoc_files=["bin/ruby-prof", "ext/ruby_prof.c", "examples/flat.txt", "examples/graph.txt", "examples/graph.html", "README", "LICENSE"], @date=Sun Feb 03 00:00:00 -0500 2008, @new_platform="ruby", @executables=["ruby-prof"], @authors=["Shugo Maeda and Charlie Savage"], @cert_chain=[], @required_rubygems_version=#<Gem::Requirement:0x402fd470 @version=nil, @requirements=[[">=", #<Gem::Version "0">]]>, @version=#<Gem::Version "0.6.0">, @files=["Rakefile", "README", "LICENSE", "CHANGES", "bin/ruby-prof", "lib/ruby-prof", "lib/ruby-prof.rb", "lib/unprof.rb", "lib/ruby-prof/abstract_printer.rb", "lib/ruby-prof/call_tree_printer.rb", "lib/ruby-prof/call_tree_printer.rb.rej", "lib/ruby-prof/flat_printer.rb", "lib/ruby-prof/graph_html_printer.rb", "lib/ruby-prof/graph_printer.rb", "lib/ruby-prof/profile_test_case.rb", "lib/ruby-prof/task.rb", "rails_plugin/ruby-prof", "rails_plugin/ruby-prof/init.rb", "rails_plugin/ruby-prof/lib", "rails_plugin/ruby-prof/lib/profiling.rb", "examples/flat.txt", "examples/graph.html", "examples/graph.txt", "ext/extconf.rb", "ext/extconf.rb.rej", "ext/measure_allocations.h", "ext/measure_cpu_time.h", "ext/measure_memory.h", "ext/measure_process_time.h", "ext/measure_wall_time.h", "ext/ruby_prof.c", "test/basic_test.rb", "test/duplicate_names_test.rb", "test/line_number_test.rb", "test/measure_mode_test.rb", "test/module_test.rb", "test/no_method_class_test.rb", "test/prime.rb", "test/prime1.rb", "test/prime2.rb", "test/prime3.rb", "test/prime_test.rb", "test/printers_test.rb", "test/profile_unit_test.rb", "test/recursive_test.rb", "test/singleton_test.rb", "test/start_test.rb", "test/test_helper.rb", "test/test_suite.rb", "test/thread_test.rb", "test/timing_test.rb"], @has_rdoc=true, @specification_version=2, @loaded=true, @requirements=[], @signing_key=nil, @default_executable="ruby-prof", @email="shugo at ruby-lang.org and cfis at savagexi.com", @required_ruby_version=#<Gem::Requirement:0x402fcad4 @version=nil, @requirements=[[">=", #<Gem::Version "1.8.4">]]>, @rdoc_options=["--title", "ruby-prof", "--inline-source", "--line-numbers", "--main", "README"], @bindir="bin", @rubygems_version="1.2.0", @homepage="http://rubyforge.org/projects/ruby-prof/", @name="ruby-prof", @platform="ruby", @autorequire=nil, @rubyforge_project="ruby-prof", @extensions=["ext/extconf.rb"], @summary="Fast Ruby profiler", @loaded_from="/usr/local/lib/ruby/gems/1.8/specifications/ruby-prof-0.6.0.gemspec", @original_platform=nil, @post_install_message=nil, @description="ruby-prof is a fast code profiler for Ruby. It is a C extension and therefore is many times faster than the standard Ruby profiler. It supports both flat and graph profiles.  For each method, graph profiles show how long the method ran, which methods called it and which  methods it called. RubyProf generate both text and html and can output it to standard out or to a file.", @dependencies=[], @test_files=["test/test_helper.rb", "test/test_suite.rb"], @require_paths=["bin", "lib"]>}
[pbrannan at zem ruby]$ ruby1.9 -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 216:'def' and line 218:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 231:'def' and line 233:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 246:'def' and line 248:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 261:'def' and line 263:'end'
{}


----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-12 23:28

Message:
This one appears to still be valid.
(standard users are unable to re-open tickets.)


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 22:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 17:23

Message:
I can't require 'gemname' on ruby1.9.1. Could it be related?

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-01-19 02:44

Message:
you can run ruby --disable-gems (I think) to disable gem prelude (auto loading of gem lib dirs).
Barring that, you could submit a patch that compares $LOADED_FEATURES with the load paths of existing gems and "infers" "we have already loaded those other gems via the normal mechanism"
Cheers!
-r

----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 20:36

Message:
Yes, I would love to be able to provide a patch, but I don?t see a solution.  To me it looks like this is an inherent flaw in how Ruby 1.9 and Rubygems interact.  Since Ruby 1.9 adds all the paths to gems installed on your system, Rubygems never gets a chance to load the specs and thus solve this problem.  I have no idea why it was decided that Ruby 1.9 should augment its $LOAD_PATH in this way, nor why these things weren?t considered at the time, but it would be great if someone came up with a solution.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-10-21 17:00

Message:
Whiny you sound, patches are welcome too :-)



----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 16:48

Message:
This is still the case on Windows 1.9.1-p243.  By extension, Config.datadir, which is what I care about, doesn?t work.

I don?t want to sound whiny, but I can?t see how this can have gone unfixed for close to a year now.  It seems like a rather central concept.

----------------------------------------------------------------------

Comment By: Matt Hulse (mhulse)
Date: 2009-08-04 23:27

Message:
Yes, this is still happening in 1.9.1-p129.  I'm on WinXP Pro using the mingw32 build from rubyinstaller.org/downloads.  I just updated to rubygems 1.3.5 using gem update --system and Gem.loaded_specs is still empty until I call gem('') or gem('nokogiri') (the gem I'm looking for).

----------------------------------------------------------------------

Comment By: Joeri Samson (joeri)
Date: 2009-03-29 18:42

Message:
with 1.9.1p0 and rubygems 1.3.1 I get the same error as Eric Hodel, except if I print/access Gem.loaded_specs before calling gem "rake":

joeri at alpha ~ $ ruby19 -rubygems -e 'p Gem.loaded_specs; gem("rake"); p Gem.loaded_specs'
{}
{"rake"=>#<Gem::Specification:0x81c8240 @new_platform="ruby", @name="rake", @version=#<Gem::Version "0.8.4">, @summary="Ruby based make-like utility.", @email="jim at weirichhouse.org", @homepage="http://rake.rubyforge.org", @rubyforge_project="rake", @description="Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax.", @autorequire=nil, @default_executable="rake", @signing_key=nil, @post_install_message=nil, @original_platform=nil, @rubygems_version="1.3.1", @specification_version=2, @date=2009-03-04 00:00:00 +0100, @require_paths=["bin", "lib"], @bindir="bin", @has_rdoc=true, @required_ruby_version=#<Gem::Requirement:0x81c8088 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @required_rubygems_version=#<Gem::Requirement:0x81c7778 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @platform="ruby", @cert_chain=[], @authors=["Jim Weirich"], @files=["install.rb", "CHANGES", "MIT-LICENSE", "Rakefile", "README", "TODO", "bin/rake", "lib/rake/classic_namespace.rb", "lib/rake/clean.rb", "lib/rake/contrib/compositepublisher.rb", "lib/rake/contrib/ftptools.rb", "lib/rake/contrib/publisher.rb", "lib/rake/contrib/rubyforgepublisher.rb", "lib/rake/contrib/sshpublisher.rb", "lib/rake/contrib/sys.rb", "lib/rake/gempackagetask.rb", "lib/rake/loaders/makefile.rb", "lib/rake/packagetask.rb", "lib/rake/rake_test_loader.rb", "lib/rake/rdoctask.rb", "lib/rake/repaired_system.rb", "lib/rake/ruby182_test_unit_fix.rb", "lib/rake/runtest.rb", "lib/rake/tasklib.rb", "lib/rake/testtask.rb", "lib/rake/win32.rb", "lib/rake.rb", "test/capture_stdout.rb", "test/check_expansion.rb", "test/contrib/test_sys.rb", "test/data/rakelib/test1.rb", "test/data/rbext/rakefile.rb", "test/filecreation.rb", "test/functional.rb", "test/in_environment.rb", "test/rake_test_setup.rb", "test/reqfile.rb", "test/reqfile2.rb", "test/session_functional.rb", "test/shellcommand.rb", "test/test_application.rb", "test/test_clean.rb", "test/test_definitions.rb", "test/test_earlytime.rb", "test/test_extension.rb", "test/test_file_creation_task.rb", "test/test_file_task.rb", "test/test_filelist.rb", "test/test_fileutils.rb", "test/test_ftp.rb", "test/test_invocation_chain.rb", "test/test_makefile_loader.rb", "test/test_multitask.rb", "test/test_namespace.rb", "test/test_package_task.rb", "test/test_pathmap.rb", "test/test_rake.rb", "test/test_rdoc_task.rb", "test/test_require.rb", "test/test_rules.rb", "test/test_task_arguments.rb", "test/test_task_manager.rb", "test/test_tasklib.rb", "test/test_tasks.rb", "test/test_test_task.rb", "test/test_top_level_functions.rb", "test/test_win32.rb", "test/data/imports/deps.mf", "test/data/sample.mf", "test/data/chains/Rakefile", "test/data/default/Rakefile", "test/data/dryrun/Rakefile", "test/data/file_creation_task/Rakefile", "test/data/imports/Rakefile", "test/data/multidesc/Rakefile", "test/data/namespace/Rakefile", "test/data/statusreturn/Rakefile", "test/data/unittest/Rakefile", "test/data/unittest/subdir", "doc/command_line_usage.rdoc", "doc/example", "doc/example/a.c", "doc/example/b.c", "doc/example/main.c", "doc/example/Rakefile1", "doc/example/Rakefile2", "doc/glossary.rdoc", "doc/jamis.rb", "doc/proto_rake.rdoc", "doc/rake.1.gz", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @test_files=[], @rdoc_options=["--line-numbers", "--inline-source", "--main", "README", "--title", "Rake -- Ruby Make"], @extra_rdoc_files=["README", "MIT-LICENSE", "TODO", "CHANGES", "doc/command_line_usage.rdoc", "doc/glossary.rdoc", "doc/proto_rake.rdoc", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @executables=["rake"], @extensions=[], @requirements=[], @dependencies=[], @loaded=true, @loaded_from="/home/joeri/.gem/ruby/1.9.1/specifications/rake-0.8.4.gemspec">}

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-03-27 21:29

Message:
With 1.9.1p0 and 1.9.2dev I see:

$ ruby19 -v -rubygems -e 'gem "rake"; p Gem.loaded_specs'
ruby 1.9.2dev (2009-03-28 trunk 23085) [i386-darwin9.6.0]
<internal:gem_prelude>:234:in `push_gem_version_on_load_path': Could not find RubyGem rake (>= 0) (Gem::LoadError)
	from <internal:gem_prelude>:14:in `gem'
	from -e:1:in `<main>'

This will take a bit more work than I planned for 1.3.1, and may require changes to gem_prelude :/

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 10:50

Message:
Ah, no, I hit .activate, which hits source_index.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 10:48

Message:
works for me

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-02 15:59

Message:
Is this still happening in 1.9.1?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

From noreply at rubyforge.org  Fri Nov 12 18:37:44 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 18:37:44 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27841 ] gem prelude appears
	to prefer older versions of gems at times
Message-ID: <20101112233744.28DCC1858387@rubyforge.org>

Bugs item #27841, was opened at 2010-02-16 06:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27841&group_id=126

Category: #gem and #require methods
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gem prelude appears to prefer older versions of gems at times

Initial Comment:
Currently on doze, if I install the ffi gem with the following two version:


ffi-0.5.4-x86-mingw32

ffi-0.6.2 (from source)

gem prelude appears to "prefer" 0.5.4 even though it's older.

c:\dev_old\digitalarchive_trunk>gem search ffi

*** LOCAL GEMS ***

ffi (0.6.2, 0.6.0, 0.5.4)

c:\dev_old\digitalarchive_trunk>ruby -v  -rffi -e 'puts $LOADED_FEATURES.grep(/ffi/)'
ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-mingw32]
E:/installs/ruby191p376/lib/ruby/gems/1.9.1/gems/ffi-0.5.4-x86-mingw32/lib/1.9/ffi_c.so
E:/installs/ruby191p376/lib/ruby/gems/1.9.1/gems/ffi-0.5.4-x86-mingw32/lib/ffi/platform.rb
...

Thanks!
-rp

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 15:37

Message:
We don't maintain gem prelude.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-19 06:36

Message:
Sigh, prelude, roger, is this bug still active?


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27841&group_id=126

From noreply at rubyforge.org  Fri Nov 12 18:44:57 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 18:44:57 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27802 ] ruby-1.9.1 causes
	defaults/operating_system.rb to be overridden by defaults.rb
Message-ID: <20101112234457.62561185838D@rubyforge.org>

Bugs item #27802, was opened at 2010-02-09 14:14
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27802&group_id=126

Category: None
Group: v1.3.x
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Richard Brown (rbrown)
Assigned to: Nobody (None)
Summary: ruby-1.9.1 causes defaults/operating_system.rb to be overridden by defaults.rb

Initial Comment:
In ruby-1.9.1p376 gem_prelude requires defaults/opearting_system.rb

If rubygems-1.3.5 is required it requires defaults.rb. Although defaults.rb does require defaults/operating_system.rb ruby won't re-load a library that's already in $". This means that anything set in defaults/operating_system.rb is being overridden by defaults.rb.

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 15:44

Message:
IDGI. I don't see how this is a problem in 1.9 w/ $" being expanded.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27802&group_id=126

From noreply at rubyforge.org  Fri Nov 12 18:53:11 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 18:53:11 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27749 ] local gem install
	hits network even when gemfile exists locally
Message-ID: <20101112235311.F31071858376@rubyforge.org>

Bugs item #27749, was opened at 2010-01-29 15:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27749&group_id=126

Category: `gem install` command
Group: v1.3.x
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Joel Duffin (oxtralite)
Assigned to: Eric Hodel (drbrain)
Summary: local gem install hits network even when gemfile exists locally

Initial Comment:
The RubyGems documentation for gem install says: 

"It will attempt a local installation (i.e. a .gem file in the current directory), and if that fails, it will attempt to download and install
the most recent version of the gem you want." (http://docs.rubygems.org/read/chapter/10#page33) 

It appears that it still accesses the network even when the .gem file exists locally. This significantly slows down local gem installs. You can easily verify this by noticing the different in how long the command takes with and without the --local option. 

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 15:53

Message:
I'm not seeing any network access at all. Either this was fixed or invalid. Reopen if it isn't fixed for you and you can provide a repro that shows the problem.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-02-09 16:10

Message:
I'll take a second look at it.

----------------------------------------------------------------------

Comment By: Joel Duffin (oxtralite)
Date: 2010-02-08 19:56

Message:
I'm trying:

sudo gem install test.gem
vs
sudo gem install -local test.gem

I believe this is a much more common scenario than the one
you describe, though I'm guessing, you are saying it is
equivalent.

It definitely hits the network and takes a lot longer as I
describe. 

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-02-08 19:16

Message:
I don't see this:

$ ruby -Ilib bin/gem install rake -i ~/tmp/gems --local -V
Installing gem rake-0.8.7
Using local gem /Users/drbrain/.gem/ruby/1.8/cache/rake-0.8.7.gem
[...]
Successfully installed rake-0.8.7
1 gem installed
Installing ri documentation for rake-0.8.7...
Installing RDoc documentation for rake-0.8.7...
$ ruby -Ilib bin/gem install rake -i ~/tmp/gems -V
Installing gem rake-0.8.7
Using local gem /Users/drbrain/tmp/gems/cache/rake-0.8.7.gem
[...]
Successfully installed rake-0.8.7
1 gem installed
Installing ri documentation for rake-0.8.7...
Installing RDoc documentation for rake-0.8.7...


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27749&group_id=126

From noreply at rubyforge.org  Fri Nov 12 18:54:38 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 18:54:38 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27507 ] Remove -t from gem
	install
Message-ID: <20101112235438.D9B33185837E@rubyforge.org>

Bugs item #27507, was opened at 2009-12-01 16:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

Category: `gem install` command
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
>Assigned to: Ryan Davis (zenspider)
Summary: Remove -t from gem install

Initial Comment:
this is a message body.

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-03 08:29

Message:
I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb.  If this property existed, it would be used and the return code from the script would indicate test success/failure.

May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-03 00:15

Message:
Chad, what do you mean by a "test suite script"?

I was thinking a -r option to run the 'test' Rake task, if it exists.

I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-01 18:49

Message:
'Is there a reason we can't just make -t run "ruby -I spec.lib
spec.test_files"' - good idea.  And/or add an additional spec parameter for a test suite script...

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-01 18:45

Message:
Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

From noreply at rubyforge.org  Fri Nov 12 19:35:14 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 19:35:14 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-21325 ] Print message when no
	gems matching your platform are found
Message-ID: <20101113003514.65DB81858367@rubyforge.org>

Bugs item #21325, was opened at 2008-07-24 12:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126

Category: `gem install` command
Group: v1.2.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Eric Hodel (drbrain)
Assigned to: Wilson Bilkovich (wilson)
Summary: Print message when no gems matching your platform are found

Initial Comment:
Instead of 'no gem to install'

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2010-11-12 16:35

Message:
I do not have permission to re-open this ticket, but it should be re-opened.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Greg Hazel (ghazel)
Date: 2010-02-18 15:04

Message:
http://rubyforge.org/tracker/index.php?func=detail&aid=27856&group_id=126&atid=575

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-03-13 16:11

Message:
Added platforms to gem list -d

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Fri Nov 12 19:51:55 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 00:51:55 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build fb10fc1
	failed
Message-ID: <4cdde12ba78e9_7270..fdbe31380361@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...fb10fc102b9ef118e39255203c07a8c39ba462f3 committed by raggi <jftucker at gmail.com> on 2010-11-12 22:55:19

    Cleanup the datadir warning and attempt to protect against excess warnings, doesn't feel great

 lib/rbconfig/datadir.rb |   10 +++++++---
 lib/rubygems.rb         |   15 +++++----------
 2 files changed, 12 insertions(+), 13 deletions(-)
Revision ...daf8a7b7edad54316329224f99f2879606f98f92 committed by raggi <jftucker at gmail.com> on 2010-11-11 15:17:02

    Revert "Temporarily disable rubygems plugins autoloading, in order to reduce load times, look at source_index / cache file optimisation instead." - for merge wiht evans branch
    This reverts commit 44a19f51ade78addc6deee1083e981ba391f7102.

 lib/rubygems.rb |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)
Revision ...efd5cc7de7f8feafc0cf427f548e227c829d4aae committed by raggi <jftucker at gmail.com> on 2010-11-11 15:16:28

    Revert "Implement rubygems/fast which skips plugin loads, plugins can be loaded by requiring rubygems/plugins" - cleanup pre merge with evans branch
    This reverts commit 3720575bd1d6655d6825af7dea121bf4f22c5fa0.

 lib/rubygems.rb         |    7 ++-----
 lib/rubygems/fast.rb    |    5 -----
 lib/rubygems/plugins.rb |    5 -----
 3 files changed, 2 insertions(+), 15 deletions(-)
Revision ...90bc7a39bc4f09dfc93c2531a11a51782d49d9d2 committed by raggi <jftucker at gmail.com> on 2010-11-11 15:15:59

    Revert "Deprecate rubygems/fast.rb" - prep for merge with evans branch
    This reverts commit 93ac03aaaf5f65d7988fd0c5041840dee0982a95.

 lib/rubygems.rb                 |    7 +++++++
 lib/rubygems/command_manager.rb |    2 --
 lib/rubygems/fast.rb            |    5 +++++
 3 files changed, 12 insertions(+), 2 deletions(-)
Revision ...6398437d74e7895a275c689e7e28f63eee8db154 committed by raggi <jftucker at gmail.com> on 2010-07-06 17:56:28

    Deprecation notices for rbconfig stuff, because we're lazy loading it now, it needs to go soon.

 lib/rbconfig/datadir.rb |   17 +++--------------
 lib/rubygems.rb         |    3 +++
 2 files changed, 6 insertions(+), 14 deletions(-)
Revision ...50cdfdb1cee4a097d839aee2e46f8d45be259f98 committed by raggi <jftucker at gmail.com> on 2010-07-06 17:35:01

    Deprecate rubygems/fast.rb
    rubygems.rb no longer loads plugins immediately.
    Gem::CommandManager loads plugins.

 lib/rubygems.rb                 |    7 -------
 lib/rubygems/command_manager.rb |    2 ++
 lib/rubygems/fast.rb            |    5 -----
 3 files changed, 2 insertions(+), 12 deletions(-)
Revision ...06f107f89c11f30f353c08bb08aa667d2ed9d429 committed by raggi <jftucker at gmail.com> on 2010-07-06 10:36:02

    Forgot one!

 lib/rubygems/validator.rb |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)
Revision ...deefc81dda8f29e75f8bcf6f75eddfc484a8867b committed by raggi <jftucker at gmail.com> on 2010-07-05 22:35:13

    lazy, lazy, loads. Cut 8 files out of the normally loaded list (with plugins)

 lib/rubygems/command_manager.rb                |    2 +-
 lib/rubygems/commands/mirror_command.rb        |    8 ++++----
 lib/rubygems/commands/pristine_command.rb      |    1 -
 lib/rubygems/commands/setup_command.rb         |    6 +++---
 lib/rubygems/commands/sources_command.rb       |    3 ++-
 lib/rubygems/commands/specification_command.rb |    3 ++-
 lib/rubygems/commands/unpack_command.rb        |    3 ++-
 lib/rubygems/doc_manager.rb                    |    2 +-
 lib/rubygems/format.rb                         |    2 --
 lib/rubygems/gemcutter_utilities.rb            |    2 +-
 lib/rubygems/indexer.rb                        |    8 ++++----
 lib/rubygems/installer.rb                      |    5 ++---
 lib/rubygems/old_format.rb                     |    6 +++---
 lib/rubygems/package.rb                        |    7 +------
 lib/rubygems/remote_fetcher.rb                 |   10 +++++-----
 lib/rubygems/source_info_cache.rb              |    3 +--
 lib/rubygems/spec_fetcher.rb                   |    5 ++---
 17 files changed, 34 insertions(+), 42 deletions(-)
Revision ...5679f59a50d34cbe1cbb7b6198b1a9b00d6aaefd committed by raggi <jftucker at gmail.com> on 2010-07-05 02:49:30

    Move to autoload where applicable

 lib/rubygems.rb              |   17 ++++++++++-------
 lib/rubygems/source_index.rb |    6 ------
 lib/rubygems/version.rb      |    2 ++
 3 files changed, 12 insertions(+), 13 deletions(-)
Revision ...40af521e0f0d47d11a8419a07783a75cb6c8625d committed by raggi <jftucker at gmail.com> on 2010-07-05 02:38:32

    Implement rubygems/fast which skips plugin loads, plugins can be loaded by requiring rubygems/plugins

 lib/rubygems.rb         |    7 +++++--
 lib/rubygems/fast.rb    |    5 +++++
 lib/rubygems/plugins.rb |    5 +++++
 3 files changed, 15 insertions(+), 2 deletions(-)
Revision ...29a10eed18de8fb4ced534bd1fc70be4de6820f6 committed by raggi <jftucker at gmail.com> on 2010-07-05 02:27:11

    Temporarily disable rubygems plugins autoloading, in order to reduce load times, look at source_index / cache file optimisation instead.

 lib/rubygems.rb |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
Revision ...0dc500abc2509826ed3f0666acece0f95e45bad4 committed by raggi <jftucker at gmail.com> on 2010-07-05 02:22:17

    Buh bye rbconfig. Only lazy load as required.

 lib/rubygems.rb |   46 ++++++++++++++++++++++------------------------
 1 files changed, 22 insertions(+), 24 deletions(-)
Revision ...88f0bf50f267968e35db2f6db0b24b48042b3e92 committed by raggi <jftucker at gmail.com> on 2010-07-05 02:04:51

    Remove etc.rb dependency, unused.

 lib/rubygems.rb |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
Revision ...c50989261cbf9ef78070f644a371480abe20e5e2 committed by raggi <jftucker at gmail.com> on 2010-07-05 02:01:04

    We're not thread safe, stop pretending to be, drop thread.so dependency.

 lib/rubygems.rb      |   16 +++-------------
 test/gemutilities.rb |    2 +-
 2 files changed, 4 insertions(+), 14 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_gather_dependencies_under(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-1.1", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:682


Name: test_gather_dependencies_over(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-2.0", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:656


Name: test_gather_dependencies_divergent(TestGemDependencyInstaller)
Type: Failure
Message: Gem::DependencyError expected but nothing was raised.

./test/test_gem_dependency_installer.rb:704




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/fb10fc102b9ef118e39255203c07a8c39ba462f3 for details.

From noreply at rubyforge.org  Fri Nov 12 19:59:58 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 19:59:58 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27588 ] Activating a
	dependency raises error even though a satisfactory version is
	already activated.
Message-ID: <20101113005958.B6BF9185837F@rubyforge.org>

Bugs item #27588, was opened at 2009-12-18 01:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Parker (dcparker)
>Assigned to: Ryan Davis (zenspider)
Summary: Activating a dependency raises error even though a satisfactory version is already activated.

Initial Comment:
I have loaded a gem "A" that loaded version 0.9.13 of gem "B", and then continued to load gem "C" that needed version "~> 0.9.12" of gem "B". Under normal conditions, version 0.9.13 should suit just fine if I'm looking for "~> 0.9.12".

But in this case, since:
  (1) version 0.9.13 is *already loaded*, and
  (2) I have since changed my Gem path in such a way that 0.9.13 is not able to be found in the new Gem path,
 -> it fails and raises an error saying that it can't activate.

This happens because in rubygems.rb, line 268:

unless matches.any? { |spec| spec.version == existing_spec.version } then

This should look at the existing spec and test whether it passes the version-requirements. However, the way it is doing it depends on the already-loaded spec to be able to be found again in the most recent search. This fails if the Gem paths have changed and the already-loaded spec is a version that is no longer able to be found in the new Gem path.

This proposed change to this single line fixes the problem:

rubygems.rb at 268
- unless matches.any? { |spec| spec.version == existing_spec.version } then
+ unless gem.version_requirements.satisfied_by?(existing_spec.version) then


----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 16:59

Message:
Please respond to Eric's question so I can write a failing test.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-02-06 22:02

Message:
Do you have a set of gems that can reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:01:54 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:01:54 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27867 ] RubyGems should not
	pre-activate dependencies that have no version requirement
Message-ID: <20101113010154.0BF361858381@rubyforge.org>

Bugs item #27867, was opened at 2010-02-22 03:54
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27867&group_id=126

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Hongli Lai (hongli)
>Assigned to: Ryan Davis (zenspider)
Summary: RubyGems should not pre-activate dependencies that have no version requirement

Initial Comment:
Suppose that we have an app Foo that depends on Bar, no specific version. At this time, running 'gem "foo"' will automatically activate the latest version of "bar". This behavior causes various problems. A concrete example:

- Rails 3.0pre depends on Rack 1.1.
- Rails 2.3 depends on Rack 1.0.
- Thin depends on Rack, no specific version.

If all of the above are installed, and one tries to use Thin to start a Rails 2.3 app, then it will fail. Thin's wrapper binary runs 'gem "thin"', which in turn activates Rack 1.1 immediately. When Thin starts Rails 2.3, Rails tries to activate Rack 1.0. As you can see, Thin + Rails 2.3 is completely broken just by having Rack 1.1 installed.

This can be solved adding an hypothetical --rack-version=xxx command line option to Thin, which would instruct Thin to activate a specific Rack version during startup so that one can start Rails 2.3 apps with:

  thin start --rack-version=1.0.0

However this is currently unimplementable because the RubyGems wrapper binary activates Rack during startup. I think it should only check whether Rack is installed, but not actually activate it until it's actually require'ed.

See also https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4031-having-rails-23pre-or-rack-11-installed-breaks-rails-2x

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 17:01

Message:
I'm working on revamping activation to deal with this problem, but not with what is suggested here. Closing.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-02-22 05:18

Message:
But Thin doesn't call Kernel#gem, lib/thin.rb requires rack.

Arguably there's not really any need for thin to be putting things into the Rack namespace, but that's totally a 3rd party argument.

The only way to truly solve this problem is for applications and libraries to present a manifest of their dependencies before any code is loaded, so that a resolver such as the one in bundler can select compatible dependency trees.

This will not be popular in the ruby community. Common rejection of Hoe's Manifest.txt is an immediate example.

I see this as a social problem, rubyists don't like "complexity" and adding manifests in a separate file, that developers are going to have to track is going to be generally seen as "unnecessary complexity". That being said, bundler is gaining popularity, and it does effectively solve this issue in the manner I am suggesting, albeit in a sealed single application environment.

I would think that rubygems supporting dependency manifests and dependency resolution would be a good thing, indeed there is thought going into this, but it will require a carefully crafted API to remain backward and forward compatible, as well as being user friendly.



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27867&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:03:09 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:03:09 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27944 ] require does not
	populate Gem.loaded_specs under Ruby 1.9.1.
Message-ID: <20101113010309.4B89E185838D@rubyforge.org>

Bugs item #27944, was opened at 2010-03-08 17:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27944&group_id=126

Category: #gem and #require methods
Group: v1.3.x
>Status: Closed
>Resolution: Rejected
Priority: 1
Submitted By: postmodern  (postmodern)
Assigned to: Eric Hodel (drbrain)
Summary: require does not populate Gem.loaded_specs under Ruby 1.9.1.

Initial Comment:
I recently upgraded to RubyGems 1.3.6 under Ruby 1.8.7 and 1.9.1. I noticed that *only* under Ruby 1.9.1, the 'require' method would not populate Gem.loaded_specs:

    >> RUBY_VERSION
    # => "1.9.1"
    >> Gem.loaded_specs
    # => {}
    >> require 'rack'
    # => true
    >> Gem.loaded_specs
    # => {}



----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 17:03

Message:
no response.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-03-09 00:53

Message:
That is because the spec isn't loaded under ruby 1.9.x. That is because ruby 1.9 bypasses rubygems and uses the gem prelude to populate the load path. Inspect $: to see.

I don't like gem-prelude, personally, but I don't think it is going to change in ruby 1.9.x.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27944&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:04:29 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:04:29 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27946 ] gem install hangs
	indefinitely on a NAT-ed machine
Message-ID: <20101113010430.1A5AE1858385@rubyforge.org>

Bugs item #27946, was opened at 2010-03-09 03:59
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27946&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Bret Weinraub (bretweinraub)
Assigned to: Nobody (None)
Summary: gem install hangs indefinitely on a NAT-ed machine

Initial Comment:
As described in this thread from ruby forum:

http://www.ruby-forum.com/topic/204146



----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 17:04

Message:
no response. closing. reopen if you answer raggi's q's.

----------------------------------------------------------------------

Comment By: Ben Corneau (bencorneau)
Date: 2010-11-10 20:42

Message:
This just happened to me.  I'm running the bitnami ubuntu redmine virtual machine on a VMWare server.

This is my first tango with ruby so could all be related to me being a ruby noob.

Running 'gem install activeresource' would hang indefinitly.

using wget to pull the gem down and then installing locally worked.

My Steps:
1. go to http://rubygems.org/, search for 'activeresource', and copy the link
2. run wget http://rubygems.org/downloads/activeresource-3.0.1.gem
4. run sudo /opt/bitnami/ruby/bin/gem install ./activeresource-3.0.1.gem --local

This worked.  (actually there were several other dependencies that I had to wget first, but once I had all the dependencies it worked)

Hope this helps,
Ben

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-19 06:38

Message:
I'm going to have to close this up unless I get more info to be able to replicate it locally.

----------------------------------------------------------------------

Comment By: Bradly Feeley (bradly)
Date: 2010-03-15 16:18

Message:
I've started seeing this today on an ec2 instance running Ubuntu.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-03-11 02:45

Message:
It seems to not be "NAT'd machines", being that every developer behind a router / on wireless is generally NAT'd.

That being said, the multiple layers of NAT can introduce more problems.

We do need to get to the bottom of this issue, however, it very much seems that this is a problem on a lower layer than our app layer.

It's possible that read(2) is causing some kind of blocking issue in some connection teardown / nat mapping release. On that note, it's worth mentioning that a lot (but far from all) of the complaints are linux in a VM on win32.

My first question, given the seemingly repeatable failure caused by using NAT rather than bridged mode, is what class of NAT is actually being used, is it symmetric / asymmetric, full / partial cone, etc?

Also, are you running any ipv6?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27946&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:04:57 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:04:57 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27975 ] "gemspec is valid"
	has different meaning locally versus at submit time.
Message-ID: <20101113010457.0F536185837F@rubyforge.org>

Bugs item #27975, was opened at 2010-03-16 09:49
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
>Assigned to: Nick Quaranto (qrush)
>Summary: "gemspec is valid" has different meaning locally versus at submit time.

Initial Comment:
Currently the gemspec validity check doesn't check for a valid url (if there is one), however gemcutter does, so there's some surprisingness when your gemspec "is valid" but then later "is no longer valid" when you go to submit it.

suggestion: have the validity check check for valid url to avoid this surprisingness.

Thanks.
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:07:38 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:07:38 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27995 ]
	Gem.default_exec_format does not work with IronRuby
Message-ID: <20101113010739.0101E185837F@rubyforge.org>

Bugs item #27995, was opened at 2010-03-21 22:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27995&group_id=126

Category: other
Group: v1.3.x
>Status: Closed
>Resolution: Rejected
Priority: 4
Submitted By: Shri Borde (shrib)
Assigned to: Eric Hodel (drbrain)
Summary: Gem.default_exec_format does not work with IronRuby

Initial Comment:
Gem.default_exec_format assumes that the Ruby interpreter command line (RbConfig::CONGIF[:ruby_install_name]) is of the form *ruby*. This works for command lines like ruby, ruby18, ruby19, jruby, etc. However, this does not work for IronRuby where the command line is "ir.exe". 

As a result, "ir.exe -S gem update --system" fails with the call stack shown below. This is a serious issue for IronRuby.

RubyGems should have some way of dealing with such command lines. It could perhaps look at some new config setting, eg. RbConfig::CONFIG["defaul_exec_format"]. Or it could just append "%s" to RbConfig::CONGIF[:ruby_install_name].

lib/rubygems/defaults.rb:57:in `default_exec_format'
lib/rubygems/commands/setup_command.rb:72:in `description'
lib/rubygems/command.rb:393:in `create_option_parser'
lib/rubygems/command.rb:359:in `parser'
lib/rubygems/command.rb:328:in `handle_options'
lib/rubygems/command.rb:251:in `invoke'
lib/rubygems/command_manager.rb:134:in `process_args'
lib/rubygems/command_manager.rb:104:in `run'
lib/rubygems/gem_runner.rb:58:in `run'
setup.rb:35

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 17:07

Message:
As described by eric, this should be on ironruby to override in rubygems/defaults/ironruby.rb

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-04-20 20:47

Message:
rubygems/defaults/ironruby.rb would go in RbConfig::CONFIG['rubylibdir'] (not in RuybGems) so it should be picked up even by setup.rb

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-03-23 00:19

Message:
Good point, i think the answer is, there should be...

----------------------------------------------------------------------

Comment By: Shri Borde (shrib)
Date: 2010-03-22 23:18

Message:
The failure above happens in the child process spawned by 
the main "ir.exe -S gem update --system" process. The 
command line of the child process is "ir.exe setup.rb" and 
it executes in the rubygems-update gem folder after 
downloading the latest version of the rubygems-update gem. 
So if I add lib/rubygems/ironruby.rb, it would help with 
most commands except for "update --system". Is there a way 
to fix it for "update --system" too?

Thanks for the comments. 

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-03-22 01:38

Message:
Seems that iron ruby should be overriding default_exec_format in its own defaults/[engine].rb .

>From the documentation:

# == RubyGems Defaults, Packaging
#
# RubyGems defaults are stored in rubygems/defaults.rb.  If you're packaging
# RubyGems or implementing Ruby you can change RubyGems' defaults.
#
# For RubyGems packagers, provide lib/rubygems/operating_system.rb and
# override any defaults from lib/rubygems/defaults.rb.
#
# For Ruby implementers, provide lib/rubygems/#{RUBY_ENGINE}.rb and override
# any defaults from lib/rubygems/defaults.rb.


HTH

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27995&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:07:45 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:07:45 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27996 ] "gem install rails"
	command fails with time-out error
Message-ID: <20101113010745.211A31858385@rubyforge.org>

Bugs item #27996, was opened at 2010-03-21 23:23
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27996&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: None
Priority: 1
Submitted By: Z R (zhinker)
Assigned to: Eric Hodel (drbrain)
>Summary: "gem install rails" command fails with time-out error

Initial Comment:
Hi,

I just tried installing ruby on rails on a clean Ubuntu 9.10 VM.  I followed the steps on this site: http://castilho.biz/blog/2009/11/05/ruby-on-rails-ubuntu-9-10-karmic-koala/.

However, when I try to install rails it fails with a timeout error.  I reran the command with the --debug parameter and pasted that output below.

zain at ubuntu-x86:~$ sudo gem --debug install rails
Exception `NameError' at /usr/lib/ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `Gem::LoadError' at /usr/lib/ruby/1.8/rubygems.rb:827 - Could not find RubyGem test-unit (>= 0)

Exception `Gem::LoadError' at /usr/lib/ruby/1.8/rubygems.rb:827 - Could not find RubyGem sources (> 0.0.1)

Exception `#<Class:0xb63d3324>' at /usr/lib/ruby/1.8/timeout.rb:60 - execution expired
Exception `Timeout::Error' at /usr/lib/ruby/1.8/timeout.rb:74 - execution expired
Exception `Gem::RemoteFetcher::FetchError' at /usr/lib/ruby/1.8/rubygems/remote_fetcher.rb:170 - timed out (http://gems.rubyforge.org/quick/Marshal.4.8/activesupport-2.3.5.gemspec.rz)
Exception `Gem::RemoteFetcher::FetchError' at /usr/lib/ruby/1.8/rubygems/spec_fetcher.rb:76 - timed out (http://gems.rubyforge.org/quick/Marshal.4.8/activesupport-2.3.5.gemspec.rz)
Exception `#<Class:0xb63cc100>' at /usr/lib/ruby/1.8/timeout.rb:60 - execution expired
Exception `Timeout::Error' at /usr/lib/ruby/1.8/timeout.rb:74 - execution expired
Exception `Gem::RemoteFetcher::FetchError' at /usr/lib/ruby/1.8/rubygems/remote_fetcher.rb:170 - timed out (http://gems.rubyforge.org/gems/rake-0.8.7.gem)
Exception `Gem::RemoteFetcher::FetchError' at /usr/lib/ruby/1.8/rubygems/remote_fetcher.rb:110 - timed out (http://gems.rubyforge.org/gems/rake-0.8.7.gem)
Exception `Gem::RemoteFetcher::FetchError' at /usr/lib/ruby/1.8/rubygems/dependency_installer.rb:236 - timed out (http://gems.rubyforge.org/gems/rake-0.8.7.gem)
ERROR:  While executing gem ... (Gem::RemoteFetcher::FetchError)
    timed out (http://gems.rubyforge.org/gems/rake-0.8.7.gem)
	/usr/lib/ruby/1.8/rubygems/remote_fetcher.rb:170:in `fetch_path'
	/usr/lib/ruby/1.8/rubygems/remote_fetcher.rb:108:in `download'
	/usr/lib/ruby/1.8/rubygems/dependency_installer.rb:232:in `install'
	/usr/lib/ruby/1.8/rubygems/dependency_installer.rb:222:in `each'
	/usr/lib/ruby/1.8/rubygems/dependency_installer.rb:222:in `install'
	/usr/lib/ruby/1.8/rubygems/commands/install_command.rb:118:in `execute'
	/usr/lib/ruby/1.8/rubygems/commands/install_command.rb:115:in `each'
	/usr/lib/ruby/1.8/rubygems/commands/install_command.rb:115:in `execute'
	/usr/lib/ruby/1.8/rubygems/command.rb:257:in `invoke'
	/usr/lib/ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
	/usr/lib/ruby/1.8/rubygems/command_manager.rb:102:in `run'
	/usr/lib/ruby/1.8/rubygems/gem_runner.rb:58:in `run'
	/usr/bin/gem:21


----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 17:07

Message:
no response.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-03-22 01:57

Message:
Please provide the output of `gem env` and also repeat the command with --verbose, which will tell us which files are timing out.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27996&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:12:52 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:12:52 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28091 ] RubyGems Installer
	Cuts Off Beginning Characters
Message-ID: <20101113011252.DEDB21858381@rubyforge.org>

Bugs item #28091, was opened at 2010-04-14 09:06
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28091&group_id=126

Category: RubyGems installer (setup.rb)
Group: v1.3.x
>Status: Closed
Resolution: None
Priority: 3
Submitted By: A Wilson (aawilson)
Assigned to: Eric Hodel (drbrain)
Summary: RubyGems Installer Cuts Off Beginning Characters

Initial Comment:
With ruby-1.9.1 on an mswin32 environment, running setup.rb produces files in the lib\ruby\site_ruby\1.9.1\rubygems which are mostly missing the first four characters of the file. For example, C:\scripting\ruby-1.9.1\lib\ruby\site_ruby\1.9.1\rubygems\commands\list_command.rb has the following for its first line:

ire 'rubygems/command'

rather than

require 'rubygems/command'

Inspection of the sources under the rubygems-1.3.6 directory shows that those sources do not have this issue, indicating that the problem has something to do with setup.rb or its dependencies.

A workaround for this is to manually copy the rubygems-1.3.6\lib\rubygems directory into ruby-1.9.1\lib\ruby\site_ruby\1.9.1\.

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 17:12

Message:
no response. please reopen if you think necessary.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-04-22 11:02

Message:
It's in lib/rubygems/commands/setup_command.rb

----------------------------------------------------------------------

Comment By: A Wilson (aawilson)
Date: 2010-04-22 07:22

Message:
I did a couple of copies with FileUtils.install without any
problems, but I wasn't able to track down where setub.rb
uses it, so I don't know if there are any options you're
using that would affect that.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-04-20 21:31

Message:
RubyGems' setup.rb uses FileUtils#install to do all its copying, so I suspect the problem will exist there.

Can you rule out FileUtils as the source of this problem?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28091&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:13:21 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:13:21 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28154 ] Gem.binary_mode
	version test for Ruby 1.9 sets invalid rb:ascii-8bit mode
Message-ID: <20101113011321.355F71858381@rubyforge.org>

Bugs item #28154, was opened at 2010-04-29 11:35
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28154&group_id=126

Category: other
Group: v1.3.x
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Randall Lucas (rlucas)
Assigned to: Nobody (None)
Summary: Gem.binary_mode version test for Ruby 1.9 sets invalid rb:ascii-8bit mode

Initial Comment:
In rubygems.rb, line 344, self.binary_mode makes a check for RUBY_VERSION and sets @binary_mode accordingly.  However, it assumes wrongly that the mode "rb:ascii-8bit" is available for all RUBY_VERSION > '1.9'.  In fact, that mode does NOT work in Ruby 1.9.0, and was added in 1.9.1.  (See support below from Ruby core SVN.)

This manifests as a cryptic error:

ERROR:  While executing gem ... (ArgumentError)
    illegal access mode rb:ascii-8bit

(full debugging error output below).

Suggested fix: alter self.binary_mode to check for RUBY_VERSION > '1.9.0' thus:

binary_mode ||= RUBY_VERSION > '1.9.0' ? 'rb:ascii-8bit' : 'rb'

---
Support from Ruby core SVN for the mode name-change that breaks between 1.9.0 and 1.9.1:

>From http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v1_9_0_5/enc/ascii.c?view=log

Revision 13670  - (view) (download) (annotate) - [select for diffs]
Modified Wed Oct 10 06:50:33 2007 UTC (2 years, 6 months ago) by akr
Original Path: trunk/ascii.c
File length: 2408 byte(s)
Diff to previous 12376 (colored)

* encoding.c (rb_enc_init): don't alias iso-8859-1 to ascii.

* ascii.c (OnigEncodingASCII): change the name US-ASCII to ASCII-8BIT.


---
version info:

$ uname -a
Linux arrakis 2.6.18-6-amd64 #1 SMP Sat Feb 20 23:34:55 UTC 2010 x86_64 GNU/Linux

$ ruby -v
ruby 1.9.0 (2006-06-08) [x86_64-linux]

$ sudo gem --debug install rake
Exception `NameError' at /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:163 - uninitialized constant Gem::Commands::InstallCommand
Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem test-unit (>= 0)

Exception `Gem::LoadError' at /usr/local/lib/site_ruby/1.9/rubygems.rb:778 - Could not find RubyGem sources (> 0.0.1)

Exception `ArgumentError' at /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50 - illegal access mode rb:ascii-8bit
ERROR:  While executing gem ... (ArgumentError)
    illegal access mode rb:ascii-8bit
        /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `initialize'
        /usr/local/lib/site_ruby/1.9/rubygems/format.rb:50:in `Gem::Format#from_file_by_path'
        /usr/local/lib/site_ruby/1.9/rubygems/installer.rb:118:in `initialize'
        /usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:257:in `Gem::DependencyInstaller#install'
        /usr/local/lib/site_ruby/1.9/rubygems/dependency_installer.rb:240:in `Gem::DependencyInstaller#install'
        /usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:119:in `execute'
        /usr/local/lib/site_ruby/1.9/rubygems/commands/install_command.rb:116:in `execute'
        /usr/local/lib/site_ruby/1.9/rubygems/command.rb:258:in `Gem::Command#invoke'
        /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:134:in `process_args'
        /usr/local/lib/site_ruby/1.9/rubygems/command_manager.rb:104:in `Gem::CommandManager#run'
        /usr/local/lib/site_ruby/1.9/rubygems/gem_runner.rb:58:in `Gem::GemRunner#run'
        /usr/bin/gem:21

$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.6
  - RUBY VERSION: 1.9.0 (2006-06-08) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby1.9/gems/1.9
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby1.9/gems/1.9
     - /home/rlucas/.gem/ruby/1.9
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-01 10:43

Message:
Looks like it's fixed in trunk anyhow.  FYI.

----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-01 10:37

Message:
Well, the unsuitability of 1.9.0 is certainly crystal-clear
to me *now.*  But it *does* exist out there in the wild. 
Debian 4.0 and 5.0 (both the oldstable and stable) provide
1.9.0 as their Ruby 1.9 packages:

http://packages.debian.org/lenny/interpreters/ruby1.9

http://packages.debian.org/etch/interpreters/ruby1.9

But the real issue here is the correctness of the version
checks.  I'm not so much suggesting that Rubygems be changed
so as to accommodate 1.9.0, but rather asking that it not
falsely give 1.9.0 credit for being a fully self-actualized
and production-ready 1.9.1 version ;)

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-04-30 22:04

Message:
As far as I know 1.9.0 was never supposed to be a stable release used in production.

There are no 1.9.0 releases in ftp.ruby-lang.org/pub/ruby and no patchlevels were released for it in /pub/ruby/1.9.0 (only snapshots).

Is there some reason you can't use 1.9.1?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28154&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:17:35 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:17:35 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28155 ] source_index.rb uses
	1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues
Message-ID: <20101113011735.50D701858385@rubyforge.org>

Bugs item #28155, was opened at 2010-04-29 12:10
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

Category: other
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Randall Lucas (rlucas)
>Assigned to: John Barnette (jbarnette)
Summary: source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues

Initial Comment:
Facially, this looks like an argument TypeError, and manifests thus:

/usr/local/lib/site_ruby/1.9/rubygems/source_index.rb:91:in `IO#read': can't convert Hash into Integer (TypeError)

In fact, it's a very similar issue to #28154.

source_index.rb at line 88 checks RUBY_VERSION < '1.9' before using the new :encoding => 'UTF-8' calling syntax for File.read (IO#read).

However, this change didn't make it into Ruby 1.9.0 (see below from core Changelog).

Again, the fix here is to check RUBY_VERSION < '1.9.1'

Similar errors may be lurking in config_file.rb, defaults.rb, vanidator.rb, and in the tests.


---
$ irb1.9
irb(main):001:0> File.open '/tmp/thing.txt' , :encoding => 'UTF-8'
TypeError: can't convert Hash into String
        from (irb):1:in `initialize'
        from (irb):1:in `Kernel#binding'

---
Fri Feb 15 16:22:49 2008  Yukihiro Matsumoto  <matz at ruby-lang.org>

    * io.c (open_key_args): allow specifying both :mode and :encoding.
---
$ ruby -v
ruby 1.9.0 (2006-06-08) [x86_64-linux]

$ gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.6
  - RUBY VERSION: 1.9.0 (2006-06-08) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby1.9/gems/1.9
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby1.9/gems/1.9
     - /home/rlucas/.gem/ruby/1.9
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: Jason Frey (fryguy)
Date: 2010-06-23 13:40

Message:
I agree with Rob Anderson's disagreement.

I am using RubyGems 1.3.7 with both Ruby 1.8.6 and Ruby 1.8.7.  My project has REXML::Encoding loaded, so defined? Encoding passes when it shouldn't, and blows up with the can't convert Hash into Integer error.

I've changed source_index.rb:88 (similar to OP) to 
  spec_code = if RUBY_VERSION > '1.9.0' && defined? Encoding 
in order to get past the problem.

The mechanism of using defined? Encoding is insufficient if all that is needed is to determine the version of Ruby.  RUBY_VERSION feels like the more appropriate approach.

----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-25 22:13

Message:
I was using 1.9.0 because it was, and is, the Ruby 1.9 that
ships with Debian stable (both oldstable 4.x and current
stable 5.x).

It is bad to rely upon users not to use 1.9.0, because at
least one major *NIX distro includes it, and it is not
immediately apparent to the casual user/developer that 1.9.0
is special and untouchable.

That Rubygems should work on 1.8.X and 1.9.Y | Y >= 1
violates the principle of least surprise.  Whether or not
1.9.0 is intended for production is not the issue.  If
Rubygems is going to do version and/or symbol presence
checking that is known to break for this special case of
1.9.0, then it should do just one more version check and die
on invocation with 1.9.0, with a helpful message.

Seriously, for both this ticket and #28154, let's just
please stipulate that the API-change-induced version checks
should correspond to the actual versions in which the API
change is present.  The whole "> 1.9" vs. "> 1.9.0" shortcut
is bit-wise and byte-foolish.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-05-25 15:06

Message:
Why are you using 1.9.0?  AFAIK it was never intended for production use.

----------------------------------------------------------------------

Comment By: Rob Anderson (rabbashanks)
Date: 2010-05-24 04:30

Message:
I disagree that testing for the "Encoding" class name symbol is the better approach.  On my system (stats below), Encoding is defined by REXML as REXML::Encoding - so defined? Encoding returns true, despite my ruby version being 1.8.6

I have implemented the explicit check on RUBY_VERSION in my local copy of rubygems, but I would think this should be the way it is done for everyone.

ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]

gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]
  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /usr/local/lib/ruby/gems/1.8
     - /Users/robanderson/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-01 10:48

Message:
This appears to have been fixed in trunk.  Current code
takes the better approach of testing for the "Encoding"
class name symbol, and specifying encoding if it exists (as
it does in 1.9.1 and above).

Lurking cousin errors to this, with the version check
assumption of consistent behavior for >= 1.9 (when in fact,
1.9.0 and 1.9.1 have pretty major API diffs), may linger here:

rubygems/commands/install_command.rb:112:    ENV.delete
'GEM_PATH' if options[:install_dir].nil? and RUBY_VERSION >
'1.9'

rubygems/config_file.rb:54:      if RUBY_VERSION > '1.9' then

rubygems/validator.rb:168:  if RUBY_VERSION < '1.9' then

rubygems/validator.rb:215:    if RUBY_VERSION < '1.9' then

rubygems.rb:500:    unless RUBY_VERSION > '1.9' then

rubygems.rb:1135:require 'rubygems/custom_require' if
gem_disabled or RUBY_VERSION < '1.9'


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:17:46 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:17:46 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28212 ]
	UndefinedConversionError if Encoding.default_internal=ASCII-8BIT
Message-ID: <20101113011746.B82B91678316@rubyforge.org>

Bugs item #28212, was opened at 2010-05-18 08:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike Smith (msmith177)
>Assigned to: John Barnette (jbarnette)
Summary: UndefinedConversionError if Encoding.default_internal=ASCII-8BIT

Initial Comment:
With ruby 1.9.1, the default internal string encoding can be set with Encoding.default_internal= or by passing ruby the -E":US-ASCII" option.

If the internal encoding is set to non-UTF-8 encodings such as US-ASCII, BINARY, or ISO-8859-1, then you will get an exception when trying to load rubygems if you have installed gemspecs that have non-ASCII characters.

==== To reproduce ====
* Install Nokogiri, or any other gem that has non-ascii characters in its gemspec.
* Run test.rb (attached)

==== Exception ====
$ ruby test.rb 
Encoding.default_internal = US-ASCII
/opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `read': "\xE9\x8B\xB8" from UTF-8 to US-ASCII (Encoding::UndefinedConversionError)
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `load_specification'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:153:in `block (2 levels) in load_gems_in'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `each'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `block in load_gems_in'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `reverse_each'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `load_gems_in'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:345:in `refresh!'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:78:in `from_gems_in'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:58:in `from_installed_gems'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:883:in `source_index'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:13:in `initialize'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `new'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `block in searcher'
        from <internal:prelude>:8:in `synchronize'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:840:in `searcher'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:479:in `find_files'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:983:in `load_plugins'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:1139:in `<top (required)>'
        from <internal:gem_prelude>:235:in `require'
        from <internal:gem_prelude>:235:in `load_full_rubygems_library'
        from <internal:gem_prelude>:334:in `const_missing'
        from test.rb:12:in `<main>'

==== Suggested fix ====
Always specify the internal  encoding as UTF-8 when reading gemspec files.  Don't use the default internal encoding.  (see attached patch)

==== My environment ====
$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [i386-darwin10]
  - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: /opt/local/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /opt/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /opt/local/lib/ruby/gems/1.9.1
     - /Users/msmith/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:19:13 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:19:13 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28226 ] Gem::PackageTask
	gem_dir incorrect
Message-ID: <20101113011913.C6C621858385@rubyforge.org>

Bugs item #28226, was opened at 2010-05-20 13:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28226&group_id=126

Category: other
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Nick Sieger (nicksieger)
>Assigned to: John Barnette (jbarnette)
Summary: Gem::PackageTask gem_dir incorrect

Initial Comment:
The local variable "gem_dir" in Gem::PackageTask as added in r2471 incorrectly includes the platform (via gem_spec.full_name) when the parent is only expecting name-version. For gems that have platform names, this results in a bad rake prerequisite, since the actual directory is named without the '-java'.

Don't know how to build task 'pkg/activerecord-jdbc-adapter-0.9.7-java'

I think the intention is to just depend on the #package_dir_path name instead. Patch attached.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28226&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:19:30 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:19:30 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28237 ] gem outdated fails
	for gems that are outdated but have a prerelease installed
Message-ID: <20101113011931.073F11858381@rubyforge.org>

Bugs item #28237, was opened at 2010-05-23 10:58
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Caio Chassot (cchassot)
>Assigned to: John Barnette (jbarnette)
Summary: gem outdated fails for gems that are outdated but have a prerelease installed

Initial Comment:
    $ sudo gem1.9 outdated --backtrace
    ERROR:  While executing gem ... (NoMethodError)
        undefined method `first' for nil:NilClass
            .../rubygems/commands/outdated_command.rb:26:in `block in execute'
            .../rubygems/commands/outdated_command.rb:21:in `each'
            .../rubygems/commands/outdated_command.rb:21:in `execute'
            .../rubygems/command.rb:270:in `invoke'
            .../rubygems/command_manager.rb:134:in `process_args'
            .../rubygems/command_manager.rb:104:in `run'
            .../rubygems/gem_runner.rb:58:in `run'
            /opt/local/bin/gem1.9:21:in `<main>'

That occurs on my machine because I have rails 3.0.0.beta3 and 2.3.5 installed, but 2.3.6 is out.

I can fix this by updating Gem::Commands::OutdatedCommand to exclude prereleases when listing the outdated gems. Not sure if you'll want to somehow handle prereleases with gem outdated, tho.

----------------------------------------------------------------------

Comment By: Caio Chassot (cchassot)
Date: 2010-05-23 11:06

Message:
I made a simple patch that fixes the bug but doesn't otherwise enhance outdated 
to handle prereleases.

Eg. if a prerelease itself is outdated, I'm not sure how that would be handled. I 
think prereleases are ignored by Gem::SourceIndex.outdated. (Our bug happens 
after that, during the printing of the outdated gems.)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:19:55 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:19:55 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28238 ] gem update fails when
	released gem is outdated but a prerelease is installed
Message-ID: <20101113011955.EC0F51858381@rubyforge.org>

Bugs item #28238, was opened at 2010-05-23 11:23
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Caio Chassot (cchassot)
>Assigned to: John Barnette (jbarnette)
Summary: gem update fails when released gem is outdated but a prerelease is installed

Initial Comment:
somewhat related to #28237

Eg. rails 2.3.5 won't update to 2.3.6 is 3.0.0.beta3 is installed.

I think I fixed this by handling option[:prerelease] in update_command, but now when I run `gem update --pre` it insists in installing sinatra 1.0.b every time.

FWIW:
$ gem1.9 list sinatra
*** LOCAL GEMS ***
sinatra (1.0, 1.0.b, 1.0.a, 0.9.4, 0.9.2)



----------------------------------------------------------------------

Comment By: Caio Chassot (cchassot)
Date: 2010-05-26 10:15

Message:
I hear what you're saying, but is there any downside to being smart about 
updating released gems regardless of having a larger version installed as pre-
release?


> (but that appears to be a separate issue, please file a separate ticket for it).

I'll gladly open said ticket, but what issue exactly are you talking about here?

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-05-25 15:27

Message:
2.3.6 is a lesser version than 3.0.0.beta3.

If you want to install a lesser version than one you already have installed use `gem install rails --version 2.3.6`.

If you elect to use prereleases you can expect to have to do more work in managing your gems.

`gem update --prerelease` means "allow updating to prerelease versions", so the behavior you're seeing is correct (but that appears to be a separate issue, please file a separate ticket for it).

----------------------------------------------------------------------

Comment By: Caio Chassot (cchassot)
Date: 2010-05-23 11:29

Message:
Obviously I meant:


Eg. rails 2.3.5 won't update to 2.3.6 BECAUSE 3.0.0.beta3 is installed.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:20:53 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:20:53 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28286 ] Removal of wrappers
	should occur *after* successful uninstallation
Message-ID: <20101113012053.84594185837F@rubyforge.org>

Bugs item #28286, was opened at 2010-06-08 21:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Sakuro OZAWA (sakuro)
>Assigned to: John Barnette (jbarnette)
Summary: Removal of wrappers should occur *after* successful uninstallation

Initial Comment:
When one terminates uninstallation of a gem, he/she would expect wrapper scripts remain.

$ ruby --version
ruby 1.9.3dev (2010-06-08 trunk 28202) [i386-darwin9.8.0]
$ gem --version
1.3.7
$ gem uninstall nokogiri
Remove executables:
	nokogiri

in addition to the gem? [Yn]  y
Removing nokogiri

You have requested to uninstall the gem:
	nokogiri-1.4.2
cucumber-0.8.0 depends on [nokogiri (>= 1.4.2)]
mime-types-1.16 depends on [nokogiri (~> 1.2)]
webrat-0.7.1 depends on [nokogiri (>= 1.2.0)]
If you remove this gems, one or more dependencies will not be met.
Continue with Uninstall? [Yn]  n
ERROR:  While executing gem ... (Gem::DependencyRemovalException)
    Uninstallation aborted due to dependent gem(s)
$ which nokogiri
nokogiri not found


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:21:25 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:21:25 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28356 ] gem which only shows
	one possible option
Message-ID: <20101113012125.E56DE185837F@rubyforge.org>

Bugs item #28356, was opened at 2010-07-05 08:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
>Assigned to: John Barnette (jbarnette)
Summary: gem which only shows one possible option

Initial Comment:
Situation: currently if there is a conflict among gems, i.e. 

gem1/lib/xxx.rb
and
gem2/lib/xxx.rb

gem which will only show one of the possibilities, which seems unexpected to me.

ex:

d:\dev>gem which ruby_to_ruby_c
(checking gem RubyToC-1.0.0.5 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/RubyToC-1.0.0.5/lib/ruby_to_ruby_c.rb

d:\dev> gem uninstall RubyToC
...
d:\dev>gem which ruby_to_ruby_c
(checking gem ruby2c-1.0.0.7 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/ruby2c-1.0.0.7/lib/ruby_to_ruby_c.rb

-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:22:22 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:22:22 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28358 ] UTF-8 encoded files
	aren't documented (with example file)
Message-ID: <20101113012222.F104A185837F@rubyforge.org>

Bugs item #28358, was opened at 2010-07-06 17:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28358&group_id=126

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Stefano Diem (teonimesic)
Assigned to: Nobody (None)
Summary: UTF-8 encoded files aren't documented (with example file)

Initial Comment:
This is a dup of #26200, but with the addition of an example file as asked by Eric.

The attached file only contains the following:

# encoding: utf-8

But i added a BOM (Byte Order Mark) to the file (with kate > Tools > Add BOM), and because of it the parser doesn't finishes (it goes to 100% and then crashes/stops)

The original message on #26200 is:

Hi, 

I've tried to document some of my UTF-8 encoded Ruby 1.9 files, but it seems that RDoc cannot do this: 

#Encoding: UTF-8
#test file

#test class
class A

  #test method
  def a
    puts "a"
  end

end

A file like the above one can't be documented on my system (I'm using Windows XP SP3 and RDoc 2.4.3). See also
http://www.ruby-forum.com/topic/189135#new.

Marvin. 

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 17:22

Message:
This is an rdoc bug, not a rubygems bug, no?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28358&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:24:59 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:24:59 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28365 ] rubygems not
	uploading $LOAD_PATH with ruby 1.9.1
Message-ID: <20101113012459.A3AC91678316@rubyforge.org>

Bugs item #28365, was opened at 2010-07-08 12:28
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

Category: #gem and #require methods
Group: v1.3.x
>Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Giorgenes Gelatti (giorgenes)
Assigned to: Nobody (None)
Summary: rubygems not uploading $LOAD_PATH with ruby 1.9.1

Initial Comment:
I have successful installed gems, but when I do a require 'gemname' it fails. The $LOAD_PATH var shows the gem paths are not loaded.
I'm using ruby1.9.1p378 and gems 1.3.7 on ubuntu 10.04.

# gem list

*** LOCAL GEMS ***

rest-client (1.6.0)
.....

# irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> $:
=> ["/usr/local/lib/site_ruby/1.9.1", "/usr/local/lib/site_ruby/1.9.1/i486-linux", "/usr/local/lib/site_ruby", "/usr/lib/ruby/vendor_ruby/1.9.1", "/usr/lib/ruby/vendor_ruby/1.9.1/i486-linux", "/usr/lib/ruby/vendor_ruby", "/usr/lib/ruby/1.9.1", "/usr/lib/ruby/1.9.1/i486-linux", "."]
irb(main):003:0> require 'rest_client'
LoadError: no such file to load -- rest_client
	from (irb):3:in `require'
	from (irb):3
	from /usr/bin/irb:12:in `<main>'




----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-09 06:59

Message:
Yup, this is a bug in ruby.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-09 06:59

Message:
Yup, this is a bug in ruby.

----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 13:08

Message:
I did a further investigation and found out that when ruby
is run with --disable-gems the gem loading works.

I looks like the line below on rubygems.rb is preventing the
load through 'require' to work in 1.9.1:

require 'rubygems/custom_require' if gem_disabled or
RUBY_VERSION < '1.9'

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:26:10 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:26:10 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28371 ] Gem.find_home should
	expand all the paths, including Windows
Message-ID: <20101113012611.01085185837F@rubyforge.org>

Bugs item #28371, was opened at 2010-07-10 09:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28371&group_id=126

Category: `gem install` command
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Luis Lavena (luislavena)
Assigned to: Luis Lavena (luislavena)
Summary: Gem.find_home should expand all the paths, including Windows

Initial Comment:
On Windows, find_home look for environment variables like HOME, USERPROFILE and HOMEDRIVE + HOMEPATH

The problem is that it directly assign the value obtained from it to user_home, disregarding if these variables contain slashes or backslashes.

On fetching of gems, RubyGems uses user_home to download and store remote specifications and quick indexes, which uses FileUtils.mkdir_p to create the folder structure.

The problem at this point is that FileUtils is not aware of backslashes and thus, failing.

Having consistent slashes using File.expand_path will be more consistent and reduce the chances of errors.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28371&group_id=126

From noreply at rubyforge.org  Fri Nov 12 20:26:40 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 20:26:40 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28365 ] rubygems not
	uploading $LOAD_PATH with ruby 1.9.1
Message-ID: <20101113012640.B815B185837F@rubyforge.org>

Bugs item #28365, was opened at 2010-07-08 12:28
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

Category: #gem and #require methods
Group: v1.3.x
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Giorgenes Gelatti (giorgenes)
Assigned to: Nobody (None)
Summary: rubygems not uploading $LOAD_PATH with ruby 1.9.1

Initial Comment:
I have successful installed gems, but when I do a require 'gemname' it fails. The $LOAD_PATH var shows the gem paths are not loaded.
I'm using ruby1.9.1p378 and gems 1.3.7 on ubuntu 10.04.

# gem list

*** LOCAL GEMS ***

rest-client (1.6.0)
.....

# irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> $:
=> ["/usr/local/lib/site_ruby/1.9.1", "/usr/local/lib/site_ruby/1.9.1/i486-linux", "/usr/local/lib/site_ruby", "/usr/lib/ruby/vendor_ruby/1.9.1", "/usr/lib/ruby/vendor_ruby/1.9.1/i486-linux", "/usr/lib/ruby/vendor_ruby", "/usr/lib/ruby/1.9.1", "/usr/lib/ruby/1.9.1/i486-linux", "."]
irb(main):003:0> require 'rest_client'
LoadError: no such file to load -- rest_client
	from (irb):3:in `require'
	from (irb):3
	from /usr/bin/irb:12:in `<main>'




----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-09 06:59

Message:
Yup, this is a bug in ruby.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-09 06:59

Message:
Yup, this is a bug in ruby.

----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 13:08

Message:
I did a further investigation and found out that when ruby
is run with --disable-gems the gem loading works.

I looks like the line below on rubygems.rb is preventing the
load through 'require' to work in 1.9.1:

require 'rubygems/custom_require' if gem_disabled or
RUBY_VERSION < '1.9'

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:06:11 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:06:11 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-22617 ] Gem.loaded_specs does
	not work on 1.9
Message-ID: <20101113040611.EBC1A1858363@rubyforge.org>

Bugs item #22617, was opened at 2008-10-30 09:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

Category: other
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Paul Brannan (cout)
Assigned to: Eric Hodel (drbrain)
Summary: Gem.loaded_specs does not work on 1.9

Initial Comment:
The loaded_specs attribute seems to always be empty on 1.9:

[pbrannan at zem ruby]$ ruby -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
{"ruby-prof"=>#<Gem::Specification:0x402fd664 @extra_rdoc_files=["bin/ruby-prof", "ext/ruby_prof.c", "examples/flat.txt", "examples/graph.txt", "examples/graph.html", "README", "LICENSE"], @date=Sun Feb 03 00:00:00 -0500 2008, @new_platform="ruby", @executables=["ruby-prof"], @authors=["Shugo Maeda and Charlie Savage"], @cert_chain=[], @required_rubygems_version=#<Gem::Requirement:0x402fd470 @version=nil, @requirements=[[">=", #<Gem::Version "0">]]>, @version=#<Gem::Version "0.6.0">, @files=["Rakefile", "README", "LICENSE", "CHANGES", "bin/ruby-prof", "lib/ruby-prof", "lib/ruby-prof.rb", "lib/unprof.rb", "lib/ruby-prof/abstract_printer.rb", "lib/ruby-prof/call_tree_printer.rb", "lib/ruby-prof/call_tree_printer.rb.rej", "lib/ruby-prof/flat_printer.rb", "lib/ruby-prof/graph_html_printer.rb", "lib/ruby-prof/graph_printer.rb", "lib/ruby-prof/profile_test_case.rb", "lib/ruby-prof/task.rb", "rails_plugin/ruby-prof", "rails_plugin/ruby-prof/init.rb", "rails_plugin/ruby-prof/lib", "rails_plugin/ruby-prof/lib/profiling.rb", "examples/flat.txt", "examples/graph.html", "examples/graph.txt", "ext/extconf.rb", "ext/extconf.rb.rej", "ext/measure_allocations.h", "ext/measure_cpu_time.h", "ext/measure_memory.h", "ext/measure_process_time.h", "ext/measure_wall_time.h", "ext/ruby_prof.c", "test/basic_test.rb", "test/duplicate_names_test.rb", "test/line_number_test.rb", "test/measure_mode_test.rb", "test/module_test.rb", "test/no_method_class_test.rb", "test/prime.rb", "test/prime1.rb", "test/prime2.rb", "test/prime3.rb", "test/prime_test.rb", "test/printers_test.rb", "test/profile_unit_test.rb", "test/recursive_test.rb", "test/singleton_test.rb", "test/start_test.rb", "test/test_helper.rb", "test/test_suite.rb", "test/thread_test.rb", "test/timing_test.rb"], @has_rdoc=true, @specification_version=2, @loaded=true, @requirements=[], @signing_key=nil, @default_executable="ruby-prof", @email="shugo at ruby-lang.org and cfis at savagexi.com", @required_ruby_version=#<Gem::Requirement:0x402fcad4 @version=nil, @requirements=[[">=", #<Gem::Version "1.8.4">]]>, @rdoc_options=["--title", "ruby-prof", "--inline-source", "--line-numbers", "--main", "README"], @bindir="bin", @rubygems_version="1.2.0", @homepage="http://rubyforge.org/projects/ruby-prof/", @name="ruby-prof", @platform="ruby", @autorequire=nil, @rubyforge_project="ruby-prof", @extensions=["ext/extconf.rb"], @summary="Fast Ruby profiler", @loaded_from="/usr/local/lib/ruby/gems/1.8/specifications/ruby-prof-0.6.0.gemspec", @original_platform=nil, @post_install_message=nil, @description="ruby-prof is a fast code profiler for Ruby. It is a C extension and therefore is many times faster than the standard Ruby profiler. It supports both flat and graph profiles.  For each method, graph profiles show how long the method ran, which methods called it and which  methods it called. RubyProf generate both text and html and can output it to standard out or to a file.", @dependencies=[], @test_files=["test/test_helper.rb", "test/test_suite.rb"], @require_paths=["bin", "lib"]>}
[pbrannan at zem ruby]$ ruby1.9 -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 216:'def' and line 218:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 231:'def' and line 233:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 246:'def' and line 248:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 261:'def' and line 263:'end'
{}


----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:06

Message:
This was rejected because it is invalid. gem_prelude supersedes rubygems in 1.9. I doubt there is anything we can or should do (to rubygems).

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-12 15:28

Message:
This one appears to still be valid.
(standard users are unable to re-open tickets.)


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 14:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 10:23

Message:
I can't require 'gemname' on ruby1.9.1. Could it be related?

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-01-18 18:44

Message:
you can run ruby --disable-gems (I think) to disable gem prelude (auto loading of gem lib dirs).
Barring that, you could submit a patch that compares $LOADED_FEATURES with the load paths of existing gems and "infers" "we have already loaded those other gems via the normal mechanism"
Cheers!
-r

----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 13:36

Message:
Yes, I would love to be able to provide a patch, but I don?t see a solution.  To me it looks like this is an inherent flaw in how Ruby 1.9 and Rubygems interact.  Since Ruby 1.9 adds all the paths to gems installed on your system, Rubygems never gets a chance to load the specs and thus solve this problem.  I have no idea why it was decided that Ruby 1.9 should augment its $LOAD_PATH in this way, nor why these things weren?t considered at the time, but it would be great if someone came up with a solution.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-10-21 10:00

Message:
Whiny you sound, patches are welcome too :-)



----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 09:48

Message:
This is still the case on Windows 1.9.1-p243.  By extension, Config.datadir, which is what I care about, doesn?t work.

I don?t want to sound whiny, but I can?t see how this can have gone unfixed for close to a year now.  It seems like a rather central concept.

----------------------------------------------------------------------

Comment By: Matt Hulse (mhulse)
Date: 2009-08-04 16:27

Message:
Yes, this is still happening in 1.9.1-p129.  I'm on WinXP Pro using the mingw32 build from rubyinstaller.org/downloads.  I just updated to rubygems 1.3.5 using gem update --system and Gem.loaded_specs is still empty until I call gem('') or gem('nokogiri') (the gem I'm looking for).

----------------------------------------------------------------------

Comment By: Joeri Samson (joeri)
Date: 2009-03-29 11:42

Message:
with 1.9.1p0 and rubygems 1.3.1 I get the same error as Eric Hodel, except if I print/access Gem.loaded_specs before calling gem "rake":

joeri at alpha ~ $ ruby19 -rubygems -e 'p Gem.loaded_specs; gem("rake"); p Gem.loaded_specs'
{}
{"rake"=>#<Gem::Specification:0x81c8240 @new_platform="ruby", @name="rake", @version=#<Gem::Version "0.8.4">, @summary="Ruby based make-like utility.", @email="jim at weirichhouse.org", @homepage="http://rake.rubyforge.org", @rubyforge_project="rake", @description="Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax.", @autorequire=nil, @default_executable="rake", @signing_key=nil, @post_install_message=nil, @original_platform=nil, @rubygems_version="1.3.1", @specification_version=2, @date=2009-03-04 00:00:00 +0100, @require_paths=["bin", "lib"], @bindir="bin", @has_rdoc=true, @required_ruby_version=#<Gem::Requirement:0x81c8088 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @required_rubygems_version=#<Gem::Requirement:0x81c7778 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @platform="ruby", @cert_chain=[], @authors=["Jim Weirich"], @files=["install.rb", "CHANGES", "MIT-LICENSE", "Rakefile", "README", "TODO", "bin/rake", "lib/rake/classic_namespace.rb", "lib/rake/clean.rb", "lib/rake/contrib/compositepublisher.rb", "lib/rake/contrib/ftptools.rb", "lib/rake/contrib/publisher.rb", "lib/rake/contrib/rubyforgepublisher.rb", "lib/rake/contrib/sshpublisher.rb", "lib/rake/contrib/sys.rb", "lib/rake/gempackagetask.rb", "lib/rake/loaders/makefile.rb", "lib/rake/packagetask.rb", "lib/rake/rake_test_loader.rb", "lib/rake/rdoctask.rb", "lib/rake/repaired_system.rb", "lib/rake/ruby182_test_unit_fix.rb", "lib/rake/runtest.rb", "lib/rake/tasklib.rb", "lib/rake/testtask.rb", "lib/rake/win32.rb", "lib/rake.rb", "test/capture_stdout.rb", "test/check_expansion.rb", "test/contrib/test_sys.rb", "test/data/rakelib/test1.rb", "test/data/rbext/rakefile.rb", "test/filecreation.rb", "test/functional.rb", "test/in_environment.rb", "test/rake_test_setup.rb", "test/reqfile.rb", "test/reqfile2.rb", "test/session_functional.rb", "test/shellcommand.rb", "test/test_application.rb", "test/test_clean.rb", "test/test_definitions.rb", "test/test_earlytime.rb", "test/test_extension.rb", "test/test_file_creation_task.rb", "test/test_file_task.rb", "test/test_filelist.rb", "test/test_fileutils.rb", "test/test_ftp.rb", "test/test_invocation_chain.rb", "test/test_makefile_loader.rb", "test/test_multitask.rb", "test/test_namespace.rb", "test/test_package_task.rb", "test/test_pathmap.rb", "test/test_rake.rb", "test/test_rdoc_task.rb", "test/test_require.rb", "test/test_rules.rb", "test/test_task_arguments.rb", "test/test_task_manager.rb", "test/test_tasklib.rb", "test/test_tasks.rb", "test/test_test_task.rb", "test/test_top_level_functions.rb", "test/test_win32.rb", "test/data/imports/deps.mf", "test/data/sample.mf", "test/data/chains/Rakefile", "test/data/default/Rakefile", "test/data/dryrun/Rakefile", "test/data/file_creation_task/Rakefile", "test/data/imports/Rakefile", "test/data/multidesc/Rakefile", "test/data/namespace/Rakefile", "test/data/statusreturn/Rakefile", "test/data/unittest/Rakefile", "test/data/unittest/subdir", "doc/command_line_usage.rdoc", "doc/example", "doc/example/a.c", "doc/example/b.c", "doc/example/main.c", "doc/example/Rakefile1", "doc/example/Rakefile2", "doc/glossary.rdoc", "doc/jamis.rb", "doc/proto_rake.rdoc", "doc/rake.1.gz", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @test_files=[], @rdoc_options=["--line-numbers", "--inline-source", "--main", "README", "--title", "Rake -- Ruby Make"], @extra_rdoc_files=["README", "MIT-LICENSE", "TODO", "CHANGES", "doc/command_line_usage.rdoc", "doc/glossary.rdoc", "doc/proto_rake.rdoc", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @executables=["rake"], @extensions=[], @requirements=[], @dependencies=[], @loaded=true, @loaded_from="/home/joeri/.gem/ruby/1.9.1/specifications/rake-0.8.4.gemspec">}

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-03-27 14:29

Message:
With 1.9.1p0 and 1.9.2dev I see:

$ ruby19 -v -rubygems -e 'gem "rake"; p Gem.loaded_specs'
ruby 1.9.2dev (2009-03-28 trunk 23085) [i386-darwin9.6.0]
<internal:gem_prelude>:234:in `push_gem_version_on_load_path': Could not find RubyGem rake (>= 0) (Gem::LoadError)
	from <internal:gem_prelude>:14:in `gem'
	from -e:1:in `<main>'

This will take a bit more work than I planned for 1.3.1, and may require changes to gem_prelude :/

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 03:50

Message:
Ah, no, I hit .activate, which hits source_index.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 03:48

Message:
works for me

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-02 07:59

Message:
Is this still happening in 1.9.1?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:11:49 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:11:49 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28384 ] gem install doesn't
	refresh Rakefile (or something along those lines)
Message-ID: <20101113041149.5B7821858363@rubyforge.org>

Bugs item #28384, was opened at 2010-07-14 10:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28384&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gem install doesn't refresh Rakefile (or something along those lines)

Initial Comment:
Hi.  Noticed the following:




C:\installs\a space\ruby_1_8_installed\bin>gem install spork
Building native extensions.  This could take a while...
Successfully installed spork-0.8.4
1 gem installed

# reports success


C:\installs\a space\ruby_1_8_installed\bin>gem uninstall spork -a
Remove executables:
        spork

in addition to the gem? [Yn]  y
Removing spork
Successfully uninstalled spork-0.8.4

C:\installs\a space\ruby_1_8_installed\bin>gem install spork
Building native extensions.  This could take a while...
ERROR:  Error installing spork:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_8_installed/bin/ruby.exe" mkrf_conf.rb
Actually, there aren't any native extensions. I'm just dynamically installing dependencies based off of your operating system
installing windows dependencies

"C:/installs/a space/ruby_1_8_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/lib"
C:/installs/a space/ruby_1_8_installed/bin/ruby.exe:36: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4 for inspection.
Results logged to C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/ext/gem_make.out


now reports failure.  I would have expected them both to report failure.

Thanks.
-r

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:11

Message:
I don't see what this has to do with anything... You didn't quote the path to rake. This has nothing to do with rubygems.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28384&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:12:34 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:12:34 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28385 ] gems with
	mkrf_conf.rb extensions fail to build when installed into a
	ruby in a directory name that includes spaces
Message-ID: <20101113041234.CE4751858363@rubyforge.org>

Bugs item #28385, was opened at 2010-07-14 10:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gems with mkrf_conf.rb extensions fail to build when installed into a ruby in a directory name that includes spaces

Initial Comment:

C:\installs\a space\ruby_1_9_2_installed\bin>gem install rdp-rb-readline
Building native extensions.  This could take a while...
ERROR:  Error installing rdp-rb-readline:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" mkrf_conf.rb

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib"
C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1 for inspection.
Results logged to C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/ext/gem_make.out

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:12

Message:
What does this have to do with rubygems?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:14:04 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:14:04 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28454 ] gem install
	--development installs transitive development dependencies
Message-ID: <20101113041404.B53DC1858363@rubyforge.org>

Bugs item #28454, was opened at 2010-08-07 07:49
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28454&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
>Assigned to: John Barnette (jbarnette)
Summary: gem install --development installs transitive development dependencies

Initial Comment:
Currently it appears that if you install a gem with --development, it installs not only its development dependencies, and also its development dependencies' development dependencies (not just runtime).  

This results in a failure, for example not being able to use 

$ jruby -S gem install sensible-cinema --development 

because though all of its development dependencies are jruby friendly, their respective development dependencies are not, and it ends up trying to build binary extensions which don't work, since this is C, but they are for gems that aren't actual development dependencies for sensible-cinema, so I don't need them anyway.

This prevents --development from being useful in this situation.

Suggestion: only install development dependencies' run-time dependencies if --development is passed.
Thanks.
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28454&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:29:41 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:29:41 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28399 ] rubygems should use
	RbConfig::CONFIG['make-prog']
Message-ID: <20101113042941.4A7CA185837B@rubyforge.org>

Bugs item #28399, was opened at 2010-07-17 18:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Greg Hazel (ghazel)
>Assigned to: Luis Lavena (luislavena)
Summary: rubygems should use RbConfig::CONFIG['make-prog']

Initial Comment:
Similar to mkmf.rb, rubygems should use Config['make-prog'] if it is set. This allows per-ruby configuration of which "make" to use.


mkmf.rb does:

$make = with_config("make-prog", ENV["MAKE"] || "make")
make, = Shellwords.shellwords($make)
$nmake = nil
case
when $mswin
  $nmake = ?m if /nmake/i =~ make
when $bccwin
  $nmake = ?b if /Borland/i =~ `#{make} -h`
end


rubygems/ext/builder.rb does:

make_program = ENV['make']
unless make_program then
  make_program = (/mswin/ =~ RUBY_PLATFORM) ? 'nmake' : 'make'
end


I believe they should be the same, and that the mkmf.rb method is preferable.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-18 05:23

Message:
+1

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:31:41 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:31:41 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28404 ] Gem build does not
	check version carefully enough
Message-ID: <20101113043141.7A6CE185837B@rubyforge.org>

Bugs item #28404, was opened at 2010-07-19 09:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28404&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pierre Baillet (octplane)
>Assigned to: John Barnette (jbarnette)
Summary: Gem build does not check version carefully enough

Initial Comment:
Hi,

When building a gem, Gem should check that the version indicated by the gem builder is the same as the Gem computed one. If this is not the case, then things can go weird later:

- On one of our server, we have a Gem server that contains genx4r version "0.05" and another library mongo_report version "0.5".

- Because of the way the Gem::Version comparator is implemented (and I think this way is correct today), the two version are identical

- When building the Gem server indices, the Marshal compress method attempts to create as less objects as possible and will reuse objects that already exists when assembling the specs

- In out case this result is assigning version "0.05" to mongo_report. The gem cannot be installed anymore.

I've forked rubygems on github ( following jbarnette suggestion on IRC) and implemented a very crude algorithm to check that the computed version number is the same as the one provided by the gem builder.

http://github.com/octplane/rubygems/commit/cc332c3165cadea8766cc54b42db78ba8dc53375

Please feel free to integrate this patch in the master if you feel this is useful.

Thank your for rubygem,
-- 
Pierre 
Admin at fotopedia.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28404&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:32:14 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:32:14 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28414 ] RubyGems 1.3.7
	default gem directory is wrong when used with ruby 1.9.1 with
	--program-suffix=1.9
Message-ID: <20101113043214.3388B185837B@rubyforge.org>

Bugs item #28414, was opened at 2010-07-22 05:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Svetoslav Agafonkin (svetlyo)
>Assigned to: John Barnette (jbarnette)
Summary: RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9

Initial Comment:
RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9.

Gem.default_dir generates "/opt/local/lib/ruby/gems/1.9.1/"  instead of "/opt/local/lib/ruby1.9/gems/1.9.1/".

The change was introduced in lib/rubygems/defaults.rb in

http://github.com/rubygems/rubygems/commit/0495c7c0dd9878f9a7a74f5133d7892d28d01812

- a big import from the ruby trunk, right after 1.3.6 was released.

The original change comes from this commit:
http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=26048


---------------------
Mac OS X 10.5.8
ruby 1.9.1_429 (from Macports)
rubgygems 1.3.7

$ gem1.9 env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.1 (2010-07-02 patchlevel 429) [i386-darwin9]
  - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: /opt/local/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /opt/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-9
  - GEM PATHS:
     - /opt/local/lib/ruby/gems/1.9.1
     - /Users/fro/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:33:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:33:26 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28419 ] gem install and gem
	update commands fail
Message-ID: <20101113043326.C136D185837B@rubyforge.org>

Bugs item #28419, was opened at 2010-07-24 18:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28419&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Radu Popescu (radascuta)
Assigned to: Nobody (None)
Summary: gem install and gem update commands fail

Initial Comment:
I get this error when trying to upgrade to Rail 2.2.2 from 2.0.2:

Updating installed gems...
ERROR:  While executing gem ... (Gem::RemoteSourceException)
    HTTP Response 301 fetching http://gems.rubyforge.org/yaml

I get the very same error for both %>gem install rails --version 2.2.2 and %>gem update rails.

Any ideas? 
Thank you. 

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:33

Message:
Rubygems requires the following features that are part of a standard ruby 
distribution:

zlib
rdoc
openssl
etc

If your ruby complains about any of these files your ruby is broken.  You need to 
install the missing parts of ruby.  Please contact your ruby packager and tell them 
not to break ruby.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:33

Message:
no response. assumed fixed.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-07-24 18:52

Message:
Please update your gem sources to http://rubygems.org, removing the gems.rubyforge.org source.

Gem sources are in ~/.gemrc


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28419&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:33:52 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:33:52 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28481 ] 'gem install' always
	prefers local files with partial name match
Message-ID: <20101113043353.078BD185837B@rubyforge.org>

Bugs item #28481, was opened at 2010-08-17 05:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28481&group_id=126

Category: `gem install` command
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Hirotsugu Asari (asarih)
>Assigned to: John Barnette (jbarnette)
Summary: 'gem install' always prefers local files with partial name match

Initial Comment:
If you try to install gem with a shorter name (e.g., active_form) from a remote server but you have a .gem file of another gem with a longer name (e.g., active_forms) in the working directory, 'gem install' will use the gem file. The exact match should be preferred.

$ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_forms-0.2.1.gem
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0]
Successfully installed active_forms-0.2.1
1 gem installed
$ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_form
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0]
Successfully installed active_forms-0.2.1
1 gem installed

This was first reported by Stephen Bannasch in http://jira.codehaus.org/browse/JRUBY-4934.

----------------------------------------------------------------------

Comment By: Christof Spies (wingfire)
Date: 2010-08-19 23:59

Message:
seams to be the same bug as #26109 http://rubyforge.org/tracker/index.php?func=detail&aid=26109&group_id=126&atid=575

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28481&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:34:10 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:34:10 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28485 ] gem push is hardcoded
	to use GemCutter.
Message-ID: <20101113043410.EBA2C185837B@rubyforge.org>

Bugs item #28485, was opened at 2010-08-18 15:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28485&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: robert gleeson (robgleeson)
>Assigned to: Nick Quaranto (qrush)
Summary: gem push is hardcoded to use GemCutter.

Initial Comment:
The RubyGems command `push` is hard-coded to use GemCutter as its destination. 
We talked about this on IRC and you confirmed that it is a bug.

Rob

----------------------------------------------------------------------

Comment By: Erik Hollensbe (erikh)
Date: 2010-08-18 16:30

Message:
An update based on some review comments by Eric: http://gist.github.com/536523

----------------------------------------------------------------------

Comment By: Erik Hollensbe (erikh)
Date: 2010-08-18 16:21

Message:
Greetings sirs, I have provided a patch for this issue!

http://gist.github.com/536509

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28485&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:34:31 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:34:31 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28486 ] unable to use runtime
	dependencies in mkrf_conf.rb
Message-ID: <20101113043431.EC6791678317@rubyforge.org>

Bugs item #28486, was opened at 2010-08-18 17:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28486&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to use runtime dependencies in mkrf_conf.rb

Initial Comment:
Situation currently:

if you have the following in your mkrf_conf.rb file


require 'rubygems'
require 'some dependency gem'

and your gemspec lists "some dependency gem" as a runtime dependency, your gem will fail to install the first time, then install correctly when you attempt to install it a second time.  I would have expected runtime dependencies to be available at build time of the main gem.
Thanks!
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28486&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:36:23 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:36:23 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28491 ] fetch a specific
	prerelease version
Message-ID: <20101113043623.86456185837B@rubyforge.org>

Bugs item #28491, was opened at 2010-08-19 15:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28491&group_id=126

Category: `gem` commands (remote behavior)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: gabriel horner (cldwalker)
>Assigned to: John Barnette (jbarnette)
Summary: fetch a specific prerelease version

Initial Comment:
I can't fetch a specific prerelease version:
  $ gem fetch dm-core -v '1.0.0.rc2' --pre --debug
   Exception `NameError' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:164 - uninitialized constant Gem::Commands::FetchCommand
   Exception `OptionParser::InvalidOption' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/1.8/optparse.rb:1450 - invalid option: no-ri
   Exception `OptionParser::InvalidOption' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/1.8/optparse.rb:1263 - invalid option: --no-ri
   ERROR:  Could not find a valid gem 'dm-core' (= 1.0.0.rc2) in any repository
  
I'm aware I can fetch the latest prerelease version: gem fetch dm-core --pre
but I need specific prerelease versions of gems. Is this possible?

FYI, I originally asked about this on help.rubygems.org: http://help.rubygems.org/discussions/questions/38-gem-fetch-a-specific-prerelease-version

My gem environment:

$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin9.4.0]
  - INSTALLATION DIRECTORY: /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext
  - RUBY EXECUTABLE: /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/bin/ruby
  - EXECUTABLE DIRECTORY: /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-9
  - GEM PATHS:
     - /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext
     - /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - "gem" => "--no-ri"
     - :sources => ["http://rubygems.org"]
  - REMOTE SOURCES:
     - http://rubygems.org

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28491&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:37:05 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:37:05 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
Message-ID: <20101113043705.28082185837B@rubyforge.org>

Bugs item #28494, was opened at 2010-08-21 16:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michel Demazure (badal)
>Assigned to: James Tucker (raggi)
Summary: C: hard coded in rubygems.rb

Initial Comment:
Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :

in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]

_md

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:37

Message:
james? update status pls.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-08-22 19:17

Message:
Ah yes, sorry, I should have pulled. I will update and commit tomorrow, thanks Luis.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-08-22 13:39

Message:
Hello James,

I believe the only missing thing is File.expand_path around the values from ENV, as master branch have:

http://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L501-507

But looks valid for a solution.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:40:32 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:40:32 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28561 ] Doesn't check that
	the current thread already has the mutex in Gem.searcher
Message-ID: <20101113044032.DB54E1858357@rubyforge.org>

Bugs item #28561, was opened at 2010-09-12 10:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28561&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Evans (jeremyevans)
>Assigned to: James Tucker (raggi)
Summary: Doesn't check that the current thread already has the mutex in Gem.searcher

Initial Comment:
Gem.search doesn't check that the current thread already has the mutex.  In certain cases, it's possible that it will call itself when it already has the mutex.  See http://github.com/jeremyevans/home_run/issues/issue/13.

For example, this backtrace shows that searcher can call itself recursively (see ****):

C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `synchronize': thread 0x4394f10 tried to join itself (ThreadError)
****from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in `require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/date.rb:2
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/1.8/yaml/rubytypes.rb:2
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/1.8/yaml.rb:396
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:220:in `load_file'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:168:in `initialize'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:385:in `new'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:385:in `configuration'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:635:in `path'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:68:in `installed_spec_directories'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:58:in `from_installed_gems'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:883:in `source_index'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/gem_path_searcher.rb:13:in `initialize'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:841:in `new'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:841:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `synchronize'
****from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:479:in `find_files'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:983:in `load_plugins'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:1139
    from ./script/../config/boot.rb:90:in `require'
    from ./script/../config/boot.rb:90:in `load_rubygems'
    from ./script/../config/boot.rb:53:in `load_initializer'
    from ./script/../config/boot.rb:38:in `run'
    from ./script/../config/boot.rb:11:in `boot!'
    from ./script/../config/boot.rb:114
    from script/console:2:in `require'
    from script/console:2

You can prevent this by checking if current thread already has the mutex, and not doing MUTEX.synchronize if so.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-09-12 11:04

Message:
The following should be cherry picked into master at the appropriate time.

http://github.com/rubygems/rubygems/commit/cceab040bde07d567131ccea2bc707a1f7dd7c8b

We're not thread safe, this mutex is pointless and incorrect.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28561&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:40:57 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:40:57 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28582 ] gem build on a yaml
	spec file fails because of missing require 'yaml'
Message-ID: <20101113044058.06A6B185837B@rubyforge.org>

Bugs item #28582, was opened at 2010-09-20 13:37
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28582&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Clint Byrum (spamaps)
>Assigned to: John Barnette (jbarnette)
Summary: gem build on a yaml spec file fails because of missing require 'yaml'

Initial Comment:
If I run gem build on a yaml gemspec, and I have no .gemrc, I get this error:


ubuntu at ip-10-196-111-253:~/g$ gem build metadata 
ERROR:  While executing gem ... (NameError)
    uninitialized constant Gem::Specification::YAML

However, if there is a .gemrc, I don't get an error.

This is because rubygems/config_file.rb requires yaml.

rubygems/specification.rb should require yaml at the top of the file as it uses YAML directly in its own code.


RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]
  - INSTALLATION DIRECTORY: /var/lib/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby1.8
  - EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /var/lib/gems/1.8
     - /home/clint/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: Clint Byrum (spamaps)
Date: 2010-11-02 15:19

Message:
Here is a very tiny patch that solves this issue.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28582&group_id=126

From noreply at rubyforge.org  Fri Nov 12 23:42:56 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Nov 2010 23:42:56 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28661 ] gem pristine does not
	observe installer options
Message-ID: <20101113044256.2B28C185837E@rubyforge.org>

Bugs item #28661, was opened at 2010-10-21 11:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28661&group_id=126

Category: `gem` commands (other)
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Charles Nutter (headius)
>Assigned to: John Barnette (jbarnette)
Summary: gem pristine does not observe installer options

Initial Comment:
In pristine_command.rb, there are the following lines:

      # TODO use installer options
      installer = Gem::Installer.new gem, :wrappers => true, :force => true
      installer.install

Obviously it was intended that this code eventually propagate installer options, but it has never been done. Unfortunately rvm's gemset support uses "gem pristine --all", which on JRuby will lose the --env-shebang default we require to allow using jruby's bash-based startup script in shebang likes for installed gem executables. This led to the following bug report: http://jira.codehaus.org/browse/JRUBY-5031

After a short exploration, I could not find the proper way to propagate installer options for pristine installs, so I ended up going with the following patch. RubyGems should be fixed to propagate installer options appropriately.

 diff --git a/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb b/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
 index ef11129..61897cc 100644
 --- a/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
 +++ b/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
 @@ -82,7 +82,11 @@ revert the gem.
        end
  
        # TODO use installer options
 -      installer = Gem::Installer.new gem, :wrappers => true, :force => true
 +      # Modified for JRUBY-5031, to propagate --env-shebang if set
 +      installer = Gem::Installer.new gem,
 +        :wrappers => true,
 +        :force => true,
 +        :env_shebang => !Gem::ConfigFile::PLATFORM_DEFAULTS['install'].to_s['--env-shebang'].nil?
        installer.install
  
        say "Restored #{spec.full_name}"


----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:42

Message:
I think this is a dupe. I brought this up a long time ago... but I haven't seen the ticket. keeping this one for now. *shrug*

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28661&group_id=126

From ryand-ruby at zenspider.com  Fri Nov 12 23:45:28 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Fri, 12 Nov 2010 22:45:28 -0600
Subject: [Rubygems-developers] first phase triage done
Message-ID: <87D1E7D8-BE92-425D-9A52-FE74C60E3C70@zenspider.com>

I just finished our first phase of triage, going through all tickets and closing anything that was stale or invalid.

JB will be doing second phase triage and assigning out tickets as appropriate.


From ryand-ruby at zenspider.com  Fri Nov 12 23:49:20 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Fri, 12 Nov 2010 22:49:20 -0600
Subject: [Rubygems-developers] first phase triage done
In-Reply-To: <87D1E7D8-BE92-425D-9A52-FE74C60E3C70@zenspider.com>
References: <87D1E7D8-BE92-425D-9A52-FE74C60E3C70@zenspider.com>
Message-ID: <BCEC7582-6BA0-4F20-88CB-314E04E5140C@zenspider.com>


On Nov 12, 2010, at 22:45 , Ryan Davis wrote:

> I just finished our first phase of triage, going through all tickets and closing anything that was stale or invalid.
> 
> JB will be doing second phase triage and assigning out tickets as appropriate.

I should add: FOURTY SEVEN! We're down to 47 open tickets.


From jbarnette at gmail.com  Sat Nov 13 01:00:27 2010
From: jbarnette at gmail.com (John Barnette)
Date: Sat, 13 Nov 2010 00:00:27 -0600
Subject: [Rubygems-developers] pushed failing tests
In-Reply-To: <9C393809-F29A-4749-9609-A9ED65CCB81C@zenspider.com>
References: <9C393809-F29A-4749-9609-A9ED65CCB81C@zenspider.com>
Message-ID: <64EBE5E7-A910-4563-8511-3331C0852115@gmail.com>

On Nov 12, 2010, at 3:20 PM, Ryan Davis wrote:
> Just a heads up. I've pushed failing tests while JB and I work through some scenarios.

I'll probably move these to a branch tomorrow since we're looking at an imminent 1.4, since major dependency resolution changes prolly aren't in the cards for a point release. Easy change tho.


~ j.


From ryand-ruby at zenspider.com  Sat Nov 13 02:15:18 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Sat, 13 Nov 2010 01:15:18 -0600
Subject: [Rubygems-developers] pushed failing tests
In-Reply-To: <64EBE5E7-A910-4563-8511-3331C0852115@gmail.com>
References: <9C393809-F29A-4749-9609-A9ED65CCB81C@zenspider.com>
	<64EBE5E7-A910-4563-8511-3331C0852115@gmail.com>
Message-ID: <103FB494-9420-4EBB-9675-88DCF55D9E6E@zenspider.com>


On Nov 13, 2010, at 00:00 , John Barnette wrote:

> On Nov 12, 2010, at 3:20 PM, Ryan Davis wrote:
>> Just a heads up. I've pushed failing tests while JB and I work through some scenarios.
> 
> I'll probably move these to a branch tomorrow since we're looking at an imminent 1.4, since major dependency resolution changes prolly aren't in the cards for a point release. Easy change tho.

my brain has gone to mush so I'm just futzing with tests at this point. 90 minutes ago I thought I had enough brain left to get at least one or two of these tests passing, but no more. 

That said, the tests are REALLY PRETTY NOW!

Dot format tests to come, maybe...

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 02:18:35 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 07:18:35 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build dd64b5d
	failed
Message-ID: <4cde3bcb1611c_7270..fdbe3138046d@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...dd64b5d05cf0d832b0ae26eee6f1113866dd4863 committed by Ryan Davis <ryand-ruby at zenspider.com> on 2010-11-13 06:56:25

    Added testcase brainstormed with raggi. Refactored tests with new assert_resolve

 test/test_gem_dependency_installer.rb |   61 +++++++++++++++++++--------------
 1 files changed, 35 insertions(+), 26 deletions(-)
Revision ...01da38355caf6cd16b8b081abbbe3ea0e0e2d1ee committed by Ryan Davis <ryand-ruby at zenspider.com> on 2010-11-13 06:55:53

    minor refactoring for readibility

 lib/rubygems/dependency_installer.rb |   55 +++++++++++++++++++---------------
 1 files changed, 31 insertions(+), 24 deletions(-)
Revision ...cc8088b8e8150b2c24bec981a28d0764d5dfc7fb committed by Ryan Davis <ryand-ruby at zenspider.com> on 2010-11-13 06:53:32

    Added minor clarification

 lib/rubygems/dependency_list.rb |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_gather_dependencies_raggi_the_edgecase_generator(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-1.1", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:654


Name: test_gather_dependencies_dropped(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-2", "c-1"], not ["a-1"].

./test/test_gem_dependency_installer.rb:635


Name: test_gather_dependencies_divergent(TestGemDependencyInstaller)
Type: Failure
Message: Gem::DependencyError expected but nothing was raised.

./test/test_gem_dependency_installer.rb:713


Name: test_gather_dependencies_over(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-2.0", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:671


Name: test_gather_dependencies_under(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-1.1", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:691




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/dd64b5d05cf0d832b0ae26eee6f1113866dd4863 for details.

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 02:44:14 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 07:44:14 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 39198cb
	failed
Message-ID: <4cde41ceb91c0_7270..fdbe31380560@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...39198cb438d46ab0e2ef16a7bd32af3f8e10c14c committed by raggi <jftucker at gmail.com> on 2010-11-13 07:41:04

    Merge branch 'master' of github.com:rubygems/rubygems
    * 'master' of github.com:rubygems/rubygems:
    Added testcase brainstormed with raggi. Refactored tests with new assert_resolve
    minor refactoring for readibility
    Added minor clarification
Revision ...2043c3d4122b8ce91e1e1c837d2488ba2feaf946 committed by raggi <jftucker at gmail.com> on 2010-11-13 07:40:24

    find_files should order by version

 lib/rubygems.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Revision ...52b7a760484e987f92720548da30e51453687d7c committed by raggi <jftucker at gmail.com> on 2010-11-13 07:40:12

    Ignore rbx compiled ruby

 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_gather_dependencies_raggi_the_edgecase_generator(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-1.1", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:654


Name: test_gather_dependencies_divergent(TestGemDependencyInstaller)
Type: Failure
Message: Gem::DependencyError expected but nothing was raised.

./test/test_gem_dependency_installer.rb:713


Name: test_gather_dependencies_under(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-1.1", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:691


Name: test_gather_dependencies_over(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-2.0", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:671


Name: test_gather_dependencies_dropped(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-2", "c-1"], not ["a-1"].

./test/test_gem_dependency_installer.rb:635




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/39198cb438d46ab0e2ef16a7bd32af3f8e10c14c for details.

From noreply at rubyforge.org  Sat Nov 13 04:31:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 04:31:26 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28561 ] Doesn't check that
	the current thread already has the mutex in Gem.searcher
Message-ID: <20101113093126.7324E185837B@rubyforge.org>

Bugs item #28561, was opened at 2010-09-12 17:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28561&group_id=126

Category: #gem and #require methods
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jeremy Evans (jeremyevans)
Assigned to: James Tucker (raggi)
Summary: Doesn't check that the current thread already has the mutex in Gem.searcher

Initial Comment:
Gem.search doesn't check that the current thread already has the mutex.  In certain cases, it's possible that it will call itself when it already has the mutex.  See http://github.com/jeremyevans/home_run/issues/issue/13.

For example, this backtrace shows that searcher can call itself recursively (see ****):

C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `synchronize': thread 0x4394f10 tried to join itself (ThreadError)
****from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in `require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/date.rb:2
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/1.8/yaml/rubytypes.rb:2
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/1.8/yaml.rb:396
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:220:in `load_file'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:168:in `initialize'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:385:in `new'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:385:in `configuration'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:635:in `path'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:68:in `installed_spec_directories'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:58:in `from_installed_gems'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:883:in `source_index'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/gem_path_searcher.rb:13:in `initialize'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:841:in `new'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:841:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `synchronize'
****from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:479:in `find_files'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:983:in `load_plugins'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:1139
    from ./script/../config/boot.rb:90:in `require'
    from ./script/../config/boot.rb:90:in `load_rubygems'
    from ./script/../config/boot.rb:53:in `load_initializer'
    from ./script/../config/boot.rb:38:in `run'
    from ./script/../config/boot.rb:11:in `boot!'
    from ./script/../config/boot.rb:114
    from script/console:2:in `require'
    from script/console:2

You can prevent this by checking if current thread already has the mutex, and not doing MUTEX.synchronize if so.

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 09:31

Message:
Merged.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-09-12 18:04

Message:
The following should be cherry picked into master at the appropriate time.

http://github.com/rubygems/rubygems/commit/cceab040bde07d567131ccea2bc707a1f7dd7c8b

We're not thread safe, this mutex is pointless and incorrect.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28561&group_id=126

From noreply at rubyforge.org  Sat Nov 13 04:30:44 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 04:30:44 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
Message-ID: <20101113093306.9014B1858378@rubyforge.org>

Bugs item #28494, was opened at 2010-08-21 23:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Michel Demazure (badal)
Assigned to: James Tucker (raggi)
Summary: C: hard coded in rubygems.rb

Initial Comment:
Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :

in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]

_md

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 09:30

Message:
https://github.com/rubygems/rubygems/commit/3c545e3d337524509ab135a466d27890291e2c88

minimal. done.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 04:37

Message:
james? update status pls.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-08-23 02:17

Message:
Ah yes, sorry, I should have pulled. I will update and commit tomorrow, thanks Luis.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-08-22 20:39

Message:
Hello James,

I believe the only missing thing is File.expand_path around the values from ENV, as master branch have:

http://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L501-507

But looks valid for a solution.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 04:35:15 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 09:35:15 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 3c545e3
	failed
Message-ID: <4cde5bd394b58_7270..fdbe3138069a@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...3c545e3d337524509ab135a466d27890291e2c88 committed by raggi <jftucker at gmail.com> on 2010-11-13 09:29:00

    closes #28494. ideally someone would sucker me into testing this too.

 lib/rubygems.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_27453/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_27453/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_27453/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_27453/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303


Name: test_gather_dependencies_dropped(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-2", "c-1"], not ["a-1"].

./test/test_gem_dependency_installer.rb:635


Name: test_gather_dependencies_over(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-2.0", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:671


Name: test_gather_dependencies_under(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-1.1", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:691


Name: test_gather_dependencies_raggi_the_edgecase_generator(TestGemDependencyInstaller)
Type: Failure
Message: Expected ["b-1.0", "c-1.0", "a-1.0"], not ["b-1.1", "c-1.0", "a-1.0"].

./test/test_gem_dependency_installer.rb:654


Name: test_gather_dependencies_divergent(TestGemDependencyInstaller)
Type: Failure
Message: Gem::DependencyError expected but nothing was raised.

./test/test_gem_dependency_installer.rb:713




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/3c545e3d337524509ab135a466d27890291e2c88 for details.

From noreply at rubyforge.org  Sat Nov 13 04:36:02 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 04:36:02 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-22617 ] Gem.loaded_specs does
	not work on 1.9
Message-ID: <20101113093602.CF1161858364@rubyforge.org>

Bugs item #22617, was opened at 2008-10-30 16:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

Category: other
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Paul Brannan (cout)
>Assigned to: Evan Phoenix (evan)
Summary: Gem.loaded_specs does not work on 1.9

Initial Comment:
The loaded_specs attribute seems to always be empty on 1.9:

[pbrannan at zem ruby]$ ruby -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
{"ruby-prof"=>#<Gem::Specification:0x402fd664 @extra_rdoc_files=["bin/ruby-prof", "ext/ruby_prof.c", "examples/flat.txt", "examples/graph.txt", "examples/graph.html", "README", "LICENSE"], @date=Sun Feb 03 00:00:00 -0500 2008, @new_platform="ruby", @executables=["ruby-prof"], @authors=["Shugo Maeda and Charlie Savage"], @cert_chain=[], @required_rubygems_version=#<Gem::Requirement:0x402fd470 @version=nil, @requirements=[[">=", #<Gem::Version "0">]]>, @version=#<Gem::Version "0.6.0">, @files=["Rakefile", "README", "LICENSE", "CHANGES", "bin/ruby-prof", "lib/ruby-prof", "lib/ruby-prof.rb", "lib/unprof.rb", "lib/ruby-prof/abstract_printer.rb", "lib/ruby-prof/call_tree_printer.rb", "lib/ruby-prof/call_tree_printer.rb.rej", "lib/ruby-prof/flat_printer.rb", "lib/ruby-prof/graph_html_printer.rb", "lib/ruby-prof/graph_printer.rb", "lib/ruby-prof/profile_test_case.rb", "lib/ruby-prof/task.rb", "rails_plugin/ruby-prof", "rails_plugin/ruby-prof/init.rb", "rails_plugin/ruby-prof/lib", "rails_plugin/ruby-prof/lib/profiling.rb", "examples/flat.txt", "examples/graph.html", "examples/graph.txt", "ext/extconf.rb", "ext/extconf.rb.rej", "ext/measure_allocations.h", "ext/measure_cpu_time.h", "ext/measure_memory.h", "ext/measure_process_time.h", "ext/measure_wall_time.h", "ext/ruby_prof.c", "test/basic_test.rb", "test/duplicate_names_test.rb", "test/line_number_test.rb", "test/measure_mode_test.rb", "test/module_test.rb", "test/no_method_class_test.rb", "test/prime.rb", "test/prime1.rb", "test/prime2.rb", "test/prime3.rb", "test/prime_test.rb", "test/printers_test.rb", "test/profile_unit_test.rb", "test/recursive_test.rb", "test/singleton_test.rb", "test/start_test.rb", "test/test_helper.rb", "test/test_suite.rb", "test/thread_test.rb", "test/timing_test.rb"], @has_rdoc=true, @specification_version=2, @loaded=true, @requirements=[], @signing_key=nil, @default_executable="ruby-prof", @email="shugo at ruby-lang.org and cfis at savagexi.com", @required_ruby_version=#<Gem::Requirement:0x402fcad4 @version=nil, @requirements=[[">=", #<Gem::Version "1.8.4">]]>, @rdoc_options=["--title", "ruby-prof", "--inline-source", "--line-numbers", "--main", "README"], @bindir="bin", @rubygems_version="1.2.0", @homepage="http://rubyforge.org/projects/ruby-prof/", @name="ruby-prof", @platform="ruby", @autorequire=nil, @rubyforge_project="ruby-prof", @extensions=["ext/extconf.rb"], @summary="Fast Ruby profiler", @loaded_from="/usr/local/lib/ruby/gems/1.8/specifications/ruby-prof-0.6.0.gemspec", @original_platform=nil, @post_install_message=nil, @description="ruby-prof is a fast code profiler for Ruby. It is a C extension and therefore is many times faster than the standard Ruby profiler. It supports both flat and graph profiles.  For each method, graph profiles show how long the method ran, which methods called it and which  methods it called. RubyProf generate both text and html and can output it to standard out or to a file.", @dependencies=[], @test_files=["test/test_helper.rb", "test/test_suite.rb"], @require_paths=["bin", "lib"]>}
[pbrannan at zem ruby]$ ruby1.9 -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 216:'def' and line 218:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 231:'def' and line 233:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 246:'def' and line 248:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 261:'def' and line 263:'end'
{}


----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 09:36

Message:
Yeah, Evan took this on, it's his game now.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 04:06

Message:
This was rejected because it is invalid. gem_prelude supersedes rubygems in 1.9. I doubt there is anything we can or should do (to rubygems).

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-12 23:28

Message:
This one appears to still be valid.
(standard users are unable to re-open tickets.)


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 22:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 17:23

Message:
I can't require 'gemname' on ruby1.9.1. Could it be related?

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-01-19 02:44

Message:
you can run ruby --disable-gems (I think) to disable gem prelude (auto loading of gem lib dirs).
Barring that, you could submit a patch that compares $LOADED_FEATURES with the load paths of existing gems and "infers" "we have already loaded those other gems via the normal mechanism"
Cheers!
-r

----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 20:36

Message:
Yes, I would love to be able to provide a patch, but I don?t see a solution.  To me it looks like this is an inherent flaw in how Ruby 1.9 and Rubygems interact.  Since Ruby 1.9 adds all the paths to gems installed on your system, Rubygems never gets a chance to load the specs and thus solve this problem.  I have no idea why it was decided that Ruby 1.9 should augment its $LOAD_PATH in this way, nor why these things weren?t considered at the time, but it would be great if someone came up with a solution.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-10-21 17:00

Message:
Whiny you sound, patches are welcome too :-)



----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 16:48

Message:
This is still the case on Windows 1.9.1-p243.  By extension, Config.datadir, which is what I care about, doesn?t work.

I don?t want to sound whiny, but I can?t see how this can have gone unfixed for close to a year now.  It seems like a rather central concept.

----------------------------------------------------------------------

Comment By: Matt Hulse (mhulse)
Date: 2009-08-04 23:27

Message:
Yes, this is still happening in 1.9.1-p129.  I'm on WinXP Pro using the mingw32 build from rubyinstaller.org/downloads.  I just updated to rubygems 1.3.5 using gem update --system and Gem.loaded_specs is still empty until I call gem('') or gem('nokogiri') (the gem I'm looking for).

----------------------------------------------------------------------

Comment By: Joeri Samson (joeri)
Date: 2009-03-29 18:42

Message:
with 1.9.1p0 and rubygems 1.3.1 I get the same error as Eric Hodel, except if I print/access Gem.loaded_specs before calling gem "rake":

joeri at alpha ~ $ ruby19 -rubygems -e 'p Gem.loaded_specs; gem("rake"); p Gem.loaded_specs'
{}
{"rake"=>#<Gem::Specification:0x81c8240 @new_platform="ruby", @name="rake", @version=#<Gem::Version "0.8.4">, @summary="Ruby based make-like utility.", @email="jim at weirichhouse.org", @homepage="http://rake.rubyforge.org", @rubyforge_project="rake", @description="Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax.", @autorequire=nil, @default_executable="rake", @signing_key=nil, @post_install_message=nil, @original_platform=nil, @rubygems_version="1.3.1", @specification_version=2, @date=2009-03-04 00:00:00 +0100, @require_paths=["bin", "lib"], @bindir="bin", @has_rdoc=true, @required_ruby_version=#<Gem::Requirement:0x81c8088 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @required_rubygems_version=#<Gem::Requirement:0x81c7778 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @platform="ruby", @cert_chain=[], @authors=["Jim Weirich"], @files=["install.rb", "CHANGES", "MIT-LICENSE", "Rakefile", "README", "TODO", "bin/rake", "lib/rake/classic_namespace.rb", "lib/rake/clean.rb", "lib/rake/contrib/compositepublisher.rb", "lib/rake/contrib/ftptools.rb", "lib/rake/contrib/publisher.rb", "lib/rake/contrib/rubyforgepublisher.rb", "lib/rake/contrib/sshpublisher.rb", "lib/rake/contrib/sys.rb", "lib/rake/gempackagetask.rb", "lib/rake/loaders/makefile.rb", "lib/rake/packagetask.rb", "lib/rake/rake_test_loader.rb", "lib/rake/rdoctask.rb", "lib/rake/repaired_system.rb", "lib/rake/ruby182_test_unit_fix.rb", "lib/rake/runtest.rb", "lib/rake/tasklib.rb", "lib/rake/testtask.rb", "lib/rake/win32.rb", "lib/rake.rb", "test/capture_stdout.rb", "test/check_expansion.rb", "test/contrib/test_sys.rb", "test/data/rakelib/test1.rb", "test/data/rbext/rakefile.rb", "test/filecreation.rb", "test/functional.rb", "test/in_environment.rb", "test/rake_test_setup.rb", "test/reqfile.rb", "test/reqfile2.rb", "test/session_functional.rb", "test/shellcommand.rb", "test/test_application.rb", "test/test_clean.rb", "test/test_definitions.rb", "test/test_earlytime.rb", "test/test_extension.rb", "test/test_file_creation_task.rb", "test/test_file_task.rb", "test/test_filelist.rb", "test/test_fileutils.rb", "test/test_ftp.rb", "test/test_invocation_chain.rb", "test/test_makefile_loader.rb", "test/test_multitask.rb", "test/test_namespace.rb", "test/test_package_task.rb", "test/test_pathmap.rb", "test/test_rake.rb", "test/test_rdoc_task.rb", "test/test_require.rb", "test/test_rules.rb", "test/test_task_arguments.rb", "test/test_task_manager.rb", "test/test_tasklib.rb", "test/test_tasks.rb", "test/test_test_task.rb", "test/test_top_level_functions.rb", "test/test_win32.rb", "test/data/imports/deps.mf", "test/data/sample.mf", "test/data/chains/Rakefile", "test/data/default/Rakefile", "test/data/dryrun/Rakefile", "test/data/file_creation_task/Rakefile", "test/data/imports/Rakefile", "test/data/multidesc/Rakefile", "test/data/namespace/Rakefile", "test/data/statusreturn/Rakefile", "test/data/unittest/Rakefile", "test/data/unittest/subdir", "doc/command_line_usage.rdoc", "doc/example", "doc/example/a.c", "doc/example/b.c", "doc/example/main.c", "doc/example/Rakefile1", "doc/example/Rakefile2", "doc/glossary.rdoc", "doc/jamis.rb", "doc/proto_rake.rdoc", "doc/rake.1.gz", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @test_files=[], @rdoc_options=["--line-numbers", "--inline-source", "--main", "README", "--title", "Rake -- Ruby Make"], @extra_rdoc_files=["README", "MIT-LICENSE", "TODO", "CHANGES", "doc/command_line_usage.rdoc", "doc/glossary.rdoc", "doc/proto_rake.rdoc", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @executables=["rake"], @extensions=[], @requirements=[], @dependencies=[], @loaded=true, @loaded_from="/home/joeri/.gem/ruby/1.9.1/specifications/rake-0.8.4.gemspec">}

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-03-27 21:29

Message:
With 1.9.1p0 and 1.9.2dev I see:

$ ruby19 -v -rubygems -e 'gem "rake"; p Gem.loaded_specs'
ruby 1.9.2dev (2009-03-28 trunk 23085) [i386-darwin9.6.0]
<internal:gem_prelude>:234:in `push_gem_version_on_load_path': Could not find RubyGem rake (>= 0) (Gem::LoadError)
	from <internal:gem_prelude>:14:in `gem'
	from -e:1:in `<main>'

This will take a bit more work than I planned for 1.3.1, and may require changes to gem_prelude :/

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 10:50

Message:
Ah, no, I hit .activate, which hits source_index.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 10:48

Message:
works for me

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-02 15:59

Message:
Is this still happening in 1.9.1?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

From luislavena at gmail.com  Sat Nov 13 07:03:20 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 13 Nov 2010 09:03:20 -0300
Subject: [Rubygems-developers] pushed failing tests
In-Reply-To: <103FB494-9420-4EBB-9675-88DCF55D9E6E@zenspider.com>
References: <9C393809-F29A-4749-9609-A9ED65CCB81C@zenspider.com>
	<64EBE5E7-A910-4563-8511-3331C0852115@gmail.com>
	<103FB494-9420-4EBB-9675-88DCF55D9E6E@zenspider.com>
Message-ID: <AANLkTimf3=z1=deH+QGAKYVVfdQoDAPS8gY=3SipOvcY@mail.gmail.com>

On Sat, Nov 13, 2010 at 4:15 AM, Ryan Davis <ryand-ruby at zenspider.com> wrote:
>
> On Nov 13, 2010, at 00:00 , John Barnette wrote:
>
>> On Nov 12, 2010, at 3:20 PM, Ryan Davis wrote:
>>> Just a heads up. I've pushed failing tests while JB and I work through some scenarios.
>>
>> I'll probably move these to a branch tomorrow since we're looking at an imminent 1.4, since major dependency resolution changes prolly aren't in the cards for a point release. Easy change tho.
>

Hey guys, so this is it? no heads-up, again?

Now I need to clear my queue of all the things I had scheduled just to
avoid another broken RubyGems release for Windows users.

Dunno if I should say to you guys thank you or not. Thanks for my
lovely birthday present.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From jbarnette at gmail.com  Sat Nov 13 08:18:13 2010
From: jbarnette at gmail.com (John Barnette)
Date: Sat, 13 Nov 2010 07:18:13 -0600
Subject: [Rubygems-developers] pushed failing tests
In-Reply-To: <AANLkTimf3=z1=deH+QGAKYVVfdQoDAPS8gY=3SipOvcY@mail.gmail.com>
References: <9C393809-F29A-4749-9609-A9ED65CCB81C@zenspider.com>
	<64EBE5E7-A910-4563-8511-3331C0852115@gmail.com>
	<103FB494-9420-4EBB-9675-88DCF55D9E6E@zenspider.com>
	<AANLkTimf3=z1=deH+QGAKYVVfdQoDAPS8gY=3SipOvcY@mail.gmail.com>
Message-ID: <AB10B6BA-20DB-4548-83F0-EA36CED2B210@gmail.com>

On Nov 13, 2010, at 6:03 AM, Luis Lavena wrote:
> On Sat, Nov 13, 2010 at 4:15 AM, Ryan Davis <ryand-ruby at zenspider.com> wrote:
>> 
>> On Nov 13, 2010, at 00:00 , John Barnette wrote:
>> 
>>> On Nov 12, 2010, at 3:20 PM, Ryan Davis wrote:
>>>> Just a heads up. I've pushed failing tests while JB and I work through some scenarios.
>>> 
>>> I'll probably move these to a branch tomorrow since we're looking at an imminent 1.4, since major dependency resolution changes prolly aren't in the cards for a point release. Easy change tho.
>> 
> 
> Hey guys, so this is it? no heads-up, again?
> 
> Now I need to clear my queue of all the things I had scheduled just to
> avoid another broken RubyGems release for Windows users.
> 
> Dunno if I should say to you guys thank you or not. Thanks for my
> lovely birthday present.

Relax. We're not pushing a release without suitable warning and your thumbs-up on Windows.


~ j.



From noreply at rubyforge.org  Sat Nov 13 08:30:01 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:30:01 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28714 ] RF admins
Message-ID: <20101113133016.35D981858390@rubyforge.org>

Bugs item #28714, was opened at 2010-11-13 05:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28714&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: John Barnette (jbarnette)
Assigned to: Eric Hodel (drbrain)
Summary: RF admins

Initial Comment:
Please add Evan and me as admins on the RubyForge project.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28714&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:35:55 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:35:55 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28155 ] source_index.rb uses
	1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues
Message-ID: <20101113133555.7D047185838C@rubyforge.org>

Bugs item #28155, was opened at 2010-04-29 12:10
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

Category: other
Group: v1.3.x
Status: Open
Resolution: None
>Priority: 1
Submitted By: Randall Lucas (rlucas)
Assigned to: John Barnette (jbarnette)
Summary: source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues

Initial Comment:
Facially, this looks like an argument TypeError, and manifests thus:

/usr/local/lib/site_ruby/1.9/rubygems/source_index.rb:91:in `IO#read': can't convert Hash into Integer (TypeError)

In fact, it's a very similar issue to #28154.

source_index.rb at line 88 checks RUBY_VERSION < '1.9' before using the new :encoding => 'UTF-8' calling syntax for File.read (IO#read).

However, this change didn't make it into Ruby 1.9.0 (see below from core Changelog).

Again, the fix here is to check RUBY_VERSION < '1.9.1'

Similar errors may be lurking in config_file.rb, defaults.rb, vanidator.rb, and in the tests.


---
$ irb1.9
irb(main):001:0> File.open '/tmp/thing.txt' , :encoding => 'UTF-8'
TypeError: can't convert Hash into String
        from (irb):1:in `initialize'
        from (irb):1:in `Kernel#binding'

---
Fri Feb 15 16:22:49 2008  Yukihiro Matsumoto  <matz at ruby-lang.org>

    * io.c (open_key_args): allow specifying both :mode and :encoding.
---
$ ruby -v
ruby 1.9.0 (2006-06-08) [x86_64-linux]

$ gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.6
  - RUBY VERSION: 1.9.0 (2006-06-08) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby1.9/gems/1.9
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby1.9/gems/1.9
     - /home/rlucas/.gem/ruby/1.9
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

>Comment By: John Barnette (jbarnette)
Date: 2010-11-13 05:35

Message:
I welcome a patch (preferably a pull request on GitHub) if this is still a concern. I'll close this ticket in a week or two if I don't see any activity.

----------------------------------------------------------------------

Comment By: Jason Frey (fryguy)
Date: 2010-06-23 13:40

Message:
I agree with Rob Anderson's disagreement.

I am using RubyGems 1.3.7 with both Ruby 1.8.6 and Ruby 1.8.7.  My project has REXML::Encoding loaded, so defined? Encoding passes when it shouldn't, and blows up with the can't convert Hash into Integer error.

I've changed source_index.rb:88 (similar to OP) to 
  spec_code = if RUBY_VERSION > '1.9.0' && defined? Encoding 
in order to get past the problem.

The mechanism of using defined? Encoding is insufficient if all that is needed is to determine the version of Ruby.  RUBY_VERSION feels like the more appropriate approach.

----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-25 22:13

Message:
I was using 1.9.0 because it was, and is, the Ruby 1.9 that
ships with Debian stable (both oldstable 4.x and current
stable 5.x).

It is bad to rely upon users not to use 1.9.0, because at
least one major *NIX distro includes it, and it is not
immediately apparent to the casual user/developer that 1.9.0
is special and untouchable.

That Rubygems should work on 1.8.X and 1.9.Y | Y >= 1
violates the principle of least surprise.  Whether or not
1.9.0 is intended for production is not the issue.  If
Rubygems is going to do version and/or symbol presence
checking that is known to break for this special case of
1.9.0, then it should do just one more version check and die
on invocation with 1.9.0, with a helpful message.

Seriously, for both this ticket and #28154, let's just
please stipulate that the API-change-induced version checks
should correspond to the actual versions in which the API
change is present.  The whole "> 1.9" vs. "> 1.9.0" shortcut
is bit-wise and byte-foolish.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-05-25 15:06

Message:
Why are you using 1.9.0?  AFAIK it was never intended for production use.

----------------------------------------------------------------------

Comment By: Rob Anderson (rabbashanks)
Date: 2010-05-24 04:30

Message:
I disagree that testing for the "Encoding" class name symbol is the better approach.  On my system (stats below), Encoding is defined by REXML as REXML::Encoding - so defined? Encoding returns true, despite my ruby version being 1.8.6

I have implemented the explicit check on RUBY_VERSION in my local copy of rubygems, but I would think this should be the way it is done for everyone.

ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]

gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]
  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /usr/local/lib/ruby/gems/1.8
     - /Users/robanderson/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-01 10:48

Message:
This appears to have been fixed in trunk.  Current code
takes the better approach of testing for the "Encoding"
class name symbol, and specifying encoding if it exists (as
it does in 1.9.1 and above).

Lurking cousin errors to this, with the version check
assumption of consistent behavior for >= 1.9 (when in fact,
1.9.0 and 1.9.1 have pretty major API diffs), may linger here:

rubygems/commands/install_command.rb:112:    ENV.delete
'GEM_PATH' if options[:install_dir].nil? and RUBY_VERSION >
'1.9'

rubygems/config_file.rb:54:      if RUBY_VERSION > '1.9' then

rubygems/validator.rb:168:  if RUBY_VERSION < '1.9' then

rubygems/validator.rb:215:    if RUBY_VERSION < '1.9' then

rubygems.rb:500:    unless RUBY_VERSION > '1.9' then

rubygems.rb:1135:require 'rubygems/custom_require' if
gem_disabled or RUBY_VERSION < '1.9'


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:40:28 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:40:28 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28371 ] Gem.find_home should
	expand all the paths, including Windows
Message-ID: <20101113134028.624921858392@rubyforge.org>

Bugs item #28371, was opened at 2010-07-10 09:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28371&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Luis Lavena (luislavena)
Assigned to: Luis Lavena (luislavena)
Summary: Gem.find_home should expand all the paths, including Windows

Initial Comment:
On Windows, find_home look for environment variables like HOME, USERPROFILE and HOMEDRIVE + HOMEPATH

The problem is that it directly assign the value obtained from it to user_home, disregarding if these variables contain slashes or backslashes.

On fetching of gems, RubyGems uses user_home to download and store remote specifications and quick indexes, which uses FileUtils.mkdir_p to create the folder structure.

The problem at this point is that FileUtils is not aware of backslashes and thus, failing.

Having consistent slashes using File.expand_path will be more consistent and reduce the chances of errors.


----------------------------------------------------------------------

>Comment By: John Barnette (jbarnette)
Date: 2010-11-13 05:40

Message:
Agreed. Commit this and close when you get a chance.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28371&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:41:46 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:41:46 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28399 ] rubygems should use
	RbConfig::CONFIG['make-prog']
Message-ID: <20101113134146.176941858390@rubyforge.org>

Bugs item #28399, was opened at 2010-07-17 18:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Greg Hazel (ghazel)
Assigned to: Luis Lavena (luislavena)
Summary: rubygems should use RbConfig::CONFIG['make-prog']

Initial Comment:
Similar to mkmf.rb, rubygems should use Config['make-prog'] if it is set. This allows per-ruby configuration of which "make" to use.


mkmf.rb does:

$make = with_config("make-prog", ENV["MAKE"] || "make")
make, = Shellwords.shellwords($make)
$nmake = nil
case
when $mswin
  $nmake = ?m if /nmake/i =~ make
when $bccwin
  $nmake = ?b if /Borland/i =~ `#{make} -h`
end


rubygems/ext/builder.rb does:

make_program = ENV['make']
unless make_program then
  make_program = (/mswin/ =~ RUBY_PLATFORM) ? 'nmake' : 'make'
end


I believe they should be the same, and that the mkmf.rb method is preferable.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-18 05:23

Message:
+1

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:43:03 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:43:03 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28404 ] Gem build does not
	check version carefully enough
Message-ID: <20101113134303.675C91858390@rubyforge.org>

Bugs item #28404, was opened at 2010-07-19 09:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28404&group_id=126

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Pierre Baillet (octplane)
Assigned to: John Barnette (jbarnette)
Summary: Gem build does not check version carefully enough

Initial Comment:
Hi,

When building a gem, Gem should check that the version indicated by the gem builder is the same as the Gem computed one. If this is not the case, then things can go weird later:

- On one of our server, we have a Gem server that contains genx4r version "0.05" and another library mongo_report version "0.5".

- Because of the way the Gem::Version comparator is implemented (and I think this way is correct today), the two version are identical

- When building the Gem server indices, the Marshal compress method attempts to create as less objects as possible and will reuse objects that already exists when assembling the specs

- In out case this result is assigning version "0.05" to mongo_report. The gem cannot be installed anymore.

I've forked rubygems on github ( following jbarnette suggestion on IRC) and implemented a very crude algorithm to check that the computed version number is the same as the one provided by the gem builder.

http://github.com/octplane/rubygems/commit/cc332c3165cadea8766cc54b42db78ba8dc53375

Please feel free to integrate this patch in the master if you feel this is useful.

Thank your for rubygem,
-- 
Pierre 
Admin at fotopedia.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28404&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:44:02 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:44:02 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28414 ] RubyGems 1.3.7
	default gem directory is wrong when used with ruby 1.9.1 with
	--program-suffix=1.9
Message-ID: <20101113134402.3BC1C1858392@rubyforge.org>

Bugs item #28414, was opened at 2010-07-22 05:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Svetoslav Agafonkin (svetlyo)
>Assigned to: Eric Hodel (drbrain)
Summary: RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9

Initial Comment:
RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9.

Gem.default_dir generates "/opt/local/lib/ruby/gems/1.9.1/"  instead of "/opt/local/lib/ruby1.9/gems/1.9.1/".

The change was introduced in lib/rubygems/defaults.rb in

http://github.com/rubygems/rubygems/commit/0495c7c0dd9878f9a7a74f5133d7892d28d01812

- a big import from the ruby trunk, right after 1.3.6 was released.

The original change comes from this commit:
http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=26048


---------------------
Mac OS X 10.5.8
ruby 1.9.1_429 (from Macports)
rubgygems 1.3.7

$ gem1.9 env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.1 (2010-07-02 patchlevel 429) [i386-darwin9]
  - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: /opt/local/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /opt/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-9
  - GEM PATHS:
     - /opt/local/lib/ruby/gems/1.9.1
     - /Users/fro/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

>Comment By: John Barnette (jbarnette)
Date: 2010-11-13 05:44

Message:
Eric, what do you think?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:44:49 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:44:49 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28454 ] gem install
	--development installs transitive development dependencies
Message-ID: <20101113134449.D29841858392@rubyforge.org>

Bugs item #28454, was opened at 2010-08-07 07:49
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28454&group_id=126

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: John Barnette (jbarnette)
Summary: gem install --development installs transitive development dependencies

Initial Comment:
Currently it appears that if you install a gem with --development, it installs not only its development dependencies, and also its development dependencies' development dependencies (not just runtime).  

This results in a failure, for example not being able to use 

$ jruby -S gem install sensible-cinema --development 

because though all of its development dependencies are jruby friendly, their respective development dependencies are not, and it ends up trying to build binary extensions which don't work, since this is C, but they are for gems that aren't actual development dependencies for sensible-cinema, so I don't need them anyway.

This prevents --development from being useful in this situation.

Suggestion: only install development dependencies' run-time dependencies if --development is passed.
Thanks.
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28454&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:45:22 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:45:22 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28481 ] 'gem install' always
	prefers local files with partial name match
Message-ID: <20101113134524.1B79D1858388@rubyforge.org>

Bugs item #28481, was opened at 2010-08-17 05:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28481&group_id=126

Category: `gem install` command
Group: v1.3.x
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Hirotsugu Asari (asarih)
Assigned to: John Barnette (jbarnette)
Summary: 'gem install' always prefers local files with partial name match

Initial Comment:
If you try to install gem with a shorter name (e.g., active_form) from a remote server but you have a .gem file of another gem with a longer name (e.g., active_forms) in the working directory, 'gem install' will use the gem file. The exact match should be preferred.

$ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_forms-0.2.1.gem
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0]
Successfully installed active_forms-0.2.1
1 gem installed
$ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_form
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0]
Successfully installed active_forms-0.2.1
1 gem installed

This was first reported by Stephen Bannasch in http://jira.codehaus.org/browse/JRUBY-4934.

----------------------------------------------------------------------

Comment By: Christof Spies (wingfire)
Date: 2010-08-19 23:59

Message:
seams to be the same bug as #26109 http://rubyforge.org/tracker/index.php?func=detail&aid=26109&group_id=126&atid=575

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28481&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:47:06 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:47:06 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28485 ] gem push is hardcoded
	to use GemCutter.
Message-ID: <20101113134706.32FAB1858392@rubyforge.org>

Bugs item #28485, was opened at 2010-08-18 15:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28485&group_id=126

Category: other
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: robert gleeson (robgleeson)
>Assigned to: John Barnette (jbarnette)
Summary: gem push is hardcoded to use GemCutter.

Initial Comment:
The RubyGems command `push` is hard-coded to use GemCutter as its destination. 
We talked about this on IRC and you confirmed that it is a bug.

Rob

----------------------------------------------------------------------

Comment By: Erik Hollensbe (erikh)
Date: 2010-08-18 16:30

Message:
An update based on some review comments by Eric: http://gist.github.com/536523

----------------------------------------------------------------------

Comment By: Erik Hollensbe (erikh)
Date: 2010-08-18 16:21

Message:
Greetings sirs, I have provided a patch for this issue!

http://gist.github.com/536509

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28485&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:48:16 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:48:16 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28661 ] gem pristine does not
	observe installer options
Message-ID: <20101113134816.48C001858392@rubyforge.org>

Bugs item #28661, was opened at 2010-10-21 11:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28661&group_id=126

Category: `gem` commands (other)
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Charles Nutter (headius)
Assigned to: John Barnette (jbarnette)
Summary: gem pristine does not observe installer options

Initial Comment:
In pristine_command.rb, there are the following lines:

      # TODO use installer options
      installer = Gem::Installer.new gem, :wrappers => true, :force => true
      installer.install

Obviously it was intended that this code eventually propagate installer options, but it has never been done. Unfortunately rvm's gemset support uses "gem pristine --all", which on JRuby will lose the --env-shebang default we require to allow using jruby's bash-based startup script in shebang likes for installed gem executables. This led to the following bug report: http://jira.codehaus.org/browse/JRUBY-5031

After a short exploration, I could not find the proper way to propagate installer options for pristine installs, so I ended up going with the following patch. RubyGems should be fixed to propagate installer options appropriately.

 diff --git a/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb b/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
 index ef11129..61897cc 100644
 --- a/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
 +++ b/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
 @@ -82,7 +82,11 @@ revert the gem.
        end
  
        # TODO use installer options
 -      installer = Gem::Installer.new gem, :wrappers => true, :force => true
 +      # Modified for JRUBY-5031, to propagate --env-shebang if set
 +      installer = Gem::Installer.new gem,
 +        :wrappers => true,
 +        :force => true,
 +        :env_shebang => !Gem::ConfigFile::PLATFORM_DEFAULTS['install'].to_s['--env-shebang'].nil?
        installer.install
  
        say "Restored #{spec.full_name}"


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:42

Message:
I think this is a dupe. I brought this up a long time ago... but I haven't seen the ticket. keeping this one for now. *shrug*

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28661&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:49:41 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:49:41 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28713 ] clean and remove
	should run in reverse topo sort
Message-ID: <20101113134941.6899F18583B6@rubyforge.org>

Bugs item #28713, was opened at 2010-11-12 13:46
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28713&group_id=126

Category: `gem` commands (other)
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: John Barnette (jbarnette)
Summary: clean and remove should run in reverse topo sort

Initial Comment:
kiss my ass rubyforge. see summary.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28713&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:49:52 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:49:52 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28714 ] RF admins
Message-ID: <20101113134952.DCF19167831F@rubyforge.org>

Bugs item #28714, was opened at 2010-11-13 05:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28714&group_id=126

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: John Barnette (jbarnette)
Assigned to: Eric Hodel (drbrain)
Summary: RF admins

Initial Comment:
Please add Evan and me as admins on the RubyForge project.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28714&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:51:49 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:51:49 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27588 ] Activating a
	dependency raises error even though a satisfactory version is
	already activated.
Message-ID: <20101113135149.6DF8918583B1@rubyforge.org>

Bugs item #27588, was opened at 2009-12-18 01:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
>Resolution: Out of Date
Priority: 3
Submitted By: Daniel Parker (dcparker)
Assigned to: Ryan Davis (zenspider)
Summary: Activating a dependency raises error even though a satisfactory version is already activated.

Initial Comment:
I have loaded a gem "A" that loaded version 0.9.13 of gem "B", and then continued to load gem "C" that needed version "~> 0.9.12" of gem "B". Under normal conditions, version 0.9.13 should suit just fine if I'm looking for "~> 0.9.12".

But in this case, since:
  (1) version 0.9.13 is *already loaded*, and
  (2) I have since changed my Gem path in such a way that 0.9.13 is not able to be found in the new Gem path,
 -> it fails and raises an error saying that it can't activate.

This happens because in rubygems.rb, line 268:

unless matches.any? { |spec| spec.version == existing_spec.version } then

This should look at the existing spec and test whether it passes the version-requirements. However, the way it is doing it depends on the already-loaded spec to be able to be found again in the most recent search. This fails if the Gem paths have changed and the already-loaded spec is a version that is no longer able to be found in the new Gem path.

This proposed change to this single line fixes the problem:

rubygems.rb at 268
- unless matches.any? { |spec| spec.version == existing_spec.version } then
+ unless gem.version_requirements.satisfied_by?(existing_spec.version) then


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 16:59

Message:
Please respond to Eric's question so I can write a failing test.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-02-06 22:02

Message:
Do you have a set of gems that can reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:52:02 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:52:02 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27975 ] "gemspec is valid"
	has different meaning locally versus at submit time.
Message-ID: <20101113135202.5C5A618583B1@rubyforge.org>

Bugs item #27975, was opened at 2010-03-16 09:49
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nick Quaranto (qrush)
>Summary: "gemspec is valid" has different meaning locally versus at submit time.

Initial Comment:
Currently the gemspec validity check doesn't check for a valid url (if there is one), however gemcutter does, so there's some surprisingness when your gemspec "is valid" but then later "is no longer valid" when you go to submit it.

suggestion: have the validity check check for valid url to avoid this surprisingness.

Thanks.
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:52:23 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:52:23 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28155 ] source_index.rb uses
	1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues
Message-ID: <20101113135223.3E22E185838C@rubyforge.org>

Bugs item #28155, was opened at 2010-04-29 12:10
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

Category: other
Group: v1.3.x
Status: Open
>Resolution: Out of Date
Priority: 1
Submitted By: Randall Lucas (rlucas)
Assigned to: John Barnette (jbarnette)
Summary: source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues

Initial Comment:
Facially, this looks like an argument TypeError, and manifests thus:

/usr/local/lib/site_ruby/1.9/rubygems/source_index.rb:91:in `IO#read': can't convert Hash into Integer (TypeError)

In fact, it's a very similar issue to #28154.

source_index.rb at line 88 checks RUBY_VERSION < '1.9' before using the new :encoding => 'UTF-8' calling syntax for File.read (IO#read).

However, this change didn't make it into Ruby 1.9.0 (see below from core Changelog).

Again, the fix here is to check RUBY_VERSION < '1.9.1'

Similar errors may be lurking in config_file.rb, defaults.rb, vanidator.rb, and in the tests.


---
$ irb1.9
irb(main):001:0> File.open '/tmp/thing.txt' , :encoding => 'UTF-8'
TypeError: can't convert Hash into String
        from (irb):1:in `initialize'
        from (irb):1:in `Kernel#binding'

---
Fri Feb 15 16:22:49 2008  Yukihiro Matsumoto  <matz at ruby-lang.org>

    * io.c (open_key_args): allow specifying both :mode and :encoding.
---
$ ruby -v
ruby 1.9.0 (2006-06-08) [x86_64-linux]

$ gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.6
  - RUBY VERSION: 1.9.0 (2006-06-08) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby1.9/gems/1.9
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby1.9/gems/1.9
     - /home/rlucas/.gem/ruby/1.9
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 05:35

Message:
I welcome a patch (preferably a pull request on GitHub) if this is still a concern. I'll close this ticket in a week or two if I don't see any activity.

----------------------------------------------------------------------

Comment By: Jason Frey (fryguy)
Date: 2010-06-23 13:40

Message:
I agree with Rob Anderson's disagreement.

I am using RubyGems 1.3.7 with both Ruby 1.8.6 and Ruby 1.8.7.  My project has REXML::Encoding loaded, so defined? Encoding passes when it shouldn't, and blows up with the can't convert Hash into Integer error.

I've changed source_index.rb:88 (similar to OP) to 
  spec_code = if RUBY_VERSION > '1.9.0' && defined? Encoding 
in order to get past the problem.

The mechanism of using defined? Encoding is insufficient if all that is needed is to determine the version of Ruby.  RUBY_VERSION feels like the more appropriate approach.

----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-25 22:13

Message:
I was using 1.9.0 because it was, and is, the Ruby 1.9 that
ships with Debian stable (both oldstable 4.x and current
stable 5.x).

It is bad to rely upon users not to use 1.9.0, because at
least one major *NIX distro includes it, and it is not
immediately apparent to the casual user/developer that 1.9.0
is special and untouchable.

That Rubygems should work on 1.8.X and 1.9.Y | Y >= 1
violates the principle of least surprise.  Whether or not
1.9.0 is intended for production is not the issue.  If
Rubygems is going to do version and/or symbol presence
checking that is known to break for this special case of
1.9.0, then it should do just one more version check and die
on invocation with 1.9.0, with a helpful message.

Seriously, for both this ticket and #28154, let's just
please stipulate that the API-change-induced version checks
should correspond to the actual versions in which the API
change is present.  The whole "> 1.9" vs. "> 1.9.0" shortcut
is bit-wise and byte-foolish.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-05-25 15:06

Message:
Why are you using 1.9.0?  AFAIK it was never intended for production use.

----------------------------------------------------------------------

Comment By: Rob Anderson (rabbashanks)
Date: 2010-05-24 04:30

Message:
I disagree that testing for the "Encoding" class name symbol is the better approach.  On my system (stats below), Encoding is defined by REXML as REXML::Encoding - so defined? Encoding returns true, despite my ruby version being 1.8.6

I have implemented the explicit check on RUBY_VERSION in my local copy of rubygems, but I would think this should be the way it is done for everyone.

ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]

gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]
  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /usr/local/lib/ruby/gems/1.8
     - /Users/robanderson/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-01 10:48

Message:
This appears to have been fixed in trunk.  Current code
takes the better approach of testing for the "Encoding"
class name symbol, and specifying encoding if it exists (as
it does in 1.9.1 and above).

Lurking cousin errors to this, with the version check
assumption of consistent behavior for >= 1.9 (when in fact,
1.9.0 and 1.9.1 have pretty major API diffs), may linger here:

rubygems/commands/install_command.rb:112:    ENV.delete
'GEM_PATH' if options[:install_dir].nil? and RUBY_VERSION >
'1.9'

rubygems/config_file.rb:54:      if RUBY_VERSION > '1.9' then

rubygems/validator.rb:168:  if RUBY_VERSION < '1.9' then

rubygems/validator.rb:215:    if RUBY_VERSION < '1.9' then

rubygems.rb:500:    unless RUBY_VERSION > '1.9' then

rubygems.rb:1135:require 'rubygems/custom_require' if
gem_disabled or RUBY_VERSION < '1.9'


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:52:46 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:52:46 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28212 ]
	UndefinedConversionError if Encoding.default_internal=ASCII-8BIT
Message-ID: <20101113135246.411441678317@rubyforge.org>

Bugs item #28212, was opened at 2010-05-18 08:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Mike Smith (msmith177)
Assigned to: John Barnette (jbarnette)
Summary: UndefinedConversionError if Encoding.default_internal=ASCII-8BIT

Initial Comment:
With ruby 1.9.1, the default internal string encoding can be set with Encoding.default_internal= or by passing ruby the -E":US-ASCII" option.

If the internal encoding is set to non-UTF-8 encodings such as US-ASCII, BINARY, or ISO-8859-1, then you will get an exception when trying to load rubygems if you have installed gemspecs that have non-ASCII characters.

==== To reproduce ====
* Install Nokogiri, or any other gem that has non-ascii characters in its gemspec.
* Run test.rb (attached)

==== Exception ====
$ ruby test.rb 
Encoding.default_internal = US-ASCII
/opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `read': "\xE9\x8B\xB8" from UTF-8 to US-ASCII (Encoding::UndefinedConversionError)
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:89:in `load_specification'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:153:in `block (2 levels) in load_gems_in'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `each'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:152:in `block in load_gems_in'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `reverse_each'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:149:in `load_gems_in'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:345:in `refresh!'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:78:in `from_gems_in'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/source_index.rb:58:in `from_installed_gems'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:883:in `source_index'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems/gem_path_searcher.rb:13:in `initialize'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `new'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:841:in `block in searcher'
        from <internal:prelude>:8:in `synchronize'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:840:in `searcher'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:479:in `find_files'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:983:in `load_plugins'
        from /opt/local/lib/ruby1.9/site_ruby/1.9.1/rubygems.rb:1139:in `<top (required)>'
        from <internal:gem_prelude>:235:in `require'
        from <internal:gem_prelude>:235:in `load_full_rubygems_library'
        from <internal:gem_prelude>:334:in `const_missing'
        from test.rb:12:in `<main>'

==== Suggested fix ====
Always specify the internal  encoding as UTF-8 when reading gemspec files.  Don't use the default internal encoding.  (see attached patch)

==== My environment ====
$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.1 (2010-01-10 patchlevel 378) [i386-darwin10]
  - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: /opt/local/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /opt/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /opt/local/lib/ruby/gems/1.9.1
     - /Users/msmith/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28212&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:52:59 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:52:59 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28226 ] Gem::PackageTask
	gem_dir incorrect
Message-ID: <20101113135259.E060618583B1@rubyforge.org>

Bugs item #28226, was opened at 2010-05-20 13:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28226&group_id=126

Category: other
Group: v1.3.x
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Nick Sieger (nicksieger)
Assigned to: John Barnette (jbarnette)
Summary: Gem::PackageTask gem_dir incorrect

Initial Comment:
The local variable "gem_dir" in Gem::PackageTask as added in r2471 incorrectly includes the platform (via gem_spec.full_name) when the parent is only expecting name-version. For gems that have platform names, this results in a bad rake prerequisite, since the actual directory is named without the '-java'.

Don't know how to build task 'pkg/activerecord-jdbc-adapter-0.9.7-java'

I think the intention is to just depend on the #package_dir_path name instead. Patch attached.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28226&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:53:18 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:53:18 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28237 ] gem outdated fails
	for gems that are outdated but have a prerelease installed
Message-ID: <20101113135318.6725C18583B1@rubyforge.org>

Bugs item #28237, was opened at 2010-05-23 10:58
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Caio Chassot (cchassot)
Assigned to: John Barnette (jbarnette)
Summary: gem outdated fails for gems that are outdated but have a prerelease installed

Initial Comment:
    $ sudo gem1.9 outdated --backtrace
    ERROR:  While executing gem ... (NoMethodError)
        undefined method `first' for nil:NilClass
            .../rubygems/commands/outdated_command.rb:26:in `block in execute'
            .../rubygems/commands/outdated_command.rb:21:in `each'
            .../rubygems/commands/outdated_command.rb:21:in `execute'
            .../rubygems/command.rb:270:in `invoke'
            .../rubygems/command_manager.rb:134:in `process_args'
            .../rubygems/command_manager.rb:104:in `run'
            .../rubygems/gem_runner.rb:58:in `run'
            /opt/local/bin/gem1.9:21:in `<main>'

That occurs on my machine because I have rails 3.0.0.beta3 and 2.3.5 installed, but 2.3.6 is out.

I can fix this by updating Gem::Commands::OutdatedCommand to exclude prereleases when listing the outdated gems. Not sure if you'll want to somehow handle prereleases with gem outdated, tho.

----------------------------------------------------------------------

Comment By: Caio Chassot (cchassot)
Date: 2010-05-23 11:06

Message:
I made a simple patch that fixes the bug but doesn't otherwise enhance outdated 
to handle prereleases.

Eg. if a prerelease itself is outdated, I'm not sure how that would be handled. I 
think prereleases are ignored by Gem::SourceIndex.outdated. (Our bug happens 
after that, during the printing of the outdated gems.)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28237&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:53:38 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:53:38 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28286 ] Removal of wrappers
	should occur *after* successful uninstallation
Message-ID: <20101113135338.1631F18583B1@rubyforge.org>

Bugs item #28286, was opened at 2010-06-08 21:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Sakuro OZAWA (sakuro)
Assigned to: John Barnette (jbarnette)
Summary: Removal of wrappers should occur *after* successful uninstallation

Initial Comment:
When one terminates uninstallation of a gem, he/she would expect wrapper scripts remain.

$ ruby --version
ruby 1.9.3dev (2010-06-08 trunk 28202) [i386-darwin9.8.0]
$ gem --version
1.3.7
$ gem uninstall nokogiri
Remove executables:
	nokogiri

in addition to the gem? [Yn]  y
Removing nokogiri

You have requested to uninstall the gem:
	nokogiri-1.4.2
cucumber-0.8.0 depends on [nokogiri (>= 1.4.2)]
mime-types-1.16 depends on [nokogiri (~> 1.2)]
webrat-0.7.1 depends on [nokogiri (>= 1.2.0)]
If you remove this gems, one or more dependencies will not be met.
Continue with Uninstall? [Yn]  n
ERROR:  While executing gem ... (Gem::DependencyRemovalException)
    Uninstallation aborted due to dependent gem(s)
$ which nokogiri
nokogiri not found


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:55:17 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:55:17 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28238 ] gem update fails when
	released gem is outdated but a prerelease is installed
Message-ID: <20101113135517.326E818583B6@rubyforge.org>

Bugs item #28238, was opened at 2010-05-23 11:23
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Caio Chassot (cchassot)
Assigned to: John Barnette (jbarnette)
Summary: gem update fails when released gem is outdated but a prerelease is installed

Initial Comment:
somewhat related to #28237

Eg. rails 2.3.5 won't update to 2.3.6 is 3.0.0.beta3 is installed.

I think I fixed this by handling option[:prerelease] in update_command, but now when I run `gem update --pre` it insists in installing sinatra 1.0.b every time.

FWIW:
$ gem1.9 list sinatra
*** LOCAL GEMS ***
sinatra (1.0, 1.0.b, 1.0.a, 0.9.4, 0.9.2)



----------------------------------------------------------------------

Comment By: Caio Chassot (cchassot)
Date: 2010-05-26 10:15

Message:
I hear what you're saying, but is there any downside to being smart about 
updating released gems regardless of having a larger version installed as pre-
release?


> (but that appears to be a separate issue, please file a separate ticket for it).

I'll gladly open said ticket, but what issue exactly are you talking about here?

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-05-25 15:27

Message:
2.3.6 is a lesser version than 3.0.0.beta3.

If you want to install a lesser version than one you already have installed use `gem install rails --version 2.3.6`.

If you elect to use prereleases you can expect to have to do more work in managing your gems.

`gem update --prerelease` means "allow updating to prerelease versions", so the behavior you're seeing is correct (but that appears to be a separate issue, please file a separate ticket for it).

----------------------------------------------------------------------

Comment By: Caio Chassot (cchassot)
Date: 2010-05-23 11:29

Message:
Obviously I meant:


Eg. rails 2.3.5 won't update to 2.3.6 BECAUSE 3.0.0.beta3 is installed.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28238&group_id=126

From noreply at rubyforge.org  Sat Nov 13 08:57:39 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 08:57:39 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28356 ] gem which only shows
	one possible option
Message-ID: <20101113135739.DBDF91858392@rubyforge.org>

Bugs item #28356, was opened at 2010-07-05 08:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: John Barnette (jbarnette)
Summary: gem which only shows one possible option

Initial Comment:
Situation: currently if there is a conflict among gems, i.e. 

gem1/lib/xxx.rb
and
gem2/lib/xxx.rb

gem which will only show one of the possibilities, which seems unexpected to me.

ex:

d:\dev>gem which ruby_to_ruby_c
(checking gem RubyToC-1.0.0.5 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/RubyToC-1.0.0.5/lib/ruby_to_ruby_c.rb

d:\dev> gem uninstall RubyToC
...
d:\dev>gem which ruby_to_ruby_c
(checking gem ruby2c-1.0.0.7 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/ruby2c-1.0.0.7/lib/ruby_to_ruby_c.rb

-r

----------------------------------------------------------------------

>Comment By: John Barnette (jbarnette)
Date: 2010-11-13 05:57

Message:
I understand the confusion, but I think having `gem which` return multiple files at this point would be really confusing/dangerous for folks who have come to depend on it returning only one.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

From noreply at rubyforge.org  Sat Nov 13 09:00:11 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 09:00:11 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27507 ] Remove -t from gem
	install
Message-ID: <20101113140011.B478F1858388@rubyforge.org>

Bugs item #27507, was opened at 2009-12-01 16:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: Ryan Davis (zenspider)
Summary: Remove -t from gem install

Initial Comment:
this is a message body.

----------------------------------------------------------------------

>Comment By: John Barnette (jbarnette)
Date: 2010-11-13 06:00

Message:
I think -t should die. Other folks?

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-03 08:29

Message:
I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb.  If this property existed, it would be used and the return code from the script would indicate test success/failure.

May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-03 00:15

Message:
Chad, what do you mean by a "test suite script"?

I was thinking a -r option to run the 'test' Rake task, if it exists.

I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-01 18:49

Message:
'Is there a reason we can't just make -t run "ruby -I spec.lib
spec.test_files"' - good idea.  And/or add an additional spec parameter for a test suite script...

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-01 18:45

Message:
Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

From luislavena at gmail.com  Sat Nov 13 09:05:36 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 13 Nov 2010 11:05:36 -0300
Subject: [Rubygems-developers] pushed failing tests
In-Reply-To: <AB10B6BA-20DB-4548-83F0-EA36CED2B210@gmail.com>
References: <9C393809-F29A-4749-9609-A9ED65CCB81C@zenspider.com>
	<64EBE5E7-A910-4563-8511-3331C0852115@gmail.com>
	<103FB494-9420-4EBB-9675-88DCF55D9E6E@zenspider.com>
	<AANLkTimf3=z1=deH+QGAKYVVfdQoDAPS8gY=3SipOvcY@mail.gmail.com>
	<AB10B6BA-20DB-4548-83F0-EA36CED2B210@gmail.com>
Message-ID: <AANLkTim58+PMfbTZNgt1Es-VXY_R6SAHAEcWAOfLBeaP@mail.gmail.com>

On Sat, Nov 13, 2010 at 10:18 AM, John Barnette <jbarnette at gmail.com> wrote:
>
> Relax. We're not pushing a release without suitable warning and your thumbs-up on Windows.
>

Thank you, previous issues with RubyGems release process made my
panic. Taking your word that this will not happen again.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From noreply at rubyforge.org  Sat Nov 13 09:10:53 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 09:10:53 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28371 ] Gem.find_home should
	expand all the paths, including Windows
Message-ID: <20101113141053.502F2185834E@rubyforge.org>

Bugs item #28371, was opened at 2010-07-10 13:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28371&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Luis Lavena (luislavena)
Assigned to: Luis Lavena (luislavena)
Summary: Gem.find_home should expand all the paths, including Windows

Initial Comment:
On Windows, find_home look for environment variables like HOME, USERPROFILE and HOMEDRIVE + HOMEPATH

The problem is that it directly assign the value obtained from it to user_home, disregarding if these variables contain slashes or backslashes.

On fetching of gems, RubyGems uses user_home to download and store remote specifications and quick indexes, which uses FileUtils.mkdir_p to create the folder structure.

The problem at this point is that FileUtils is not aware of backslashes and thus, failing.

Having consistent slashes using File.expand_path will be more consistent and reduce the chances of errors.


----------------------------------------------------------------------

>Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 11:10

Message:
Resolved by https://github.com/rubygems/rubygems/commit/147872fac455454379986010be04998f5fcc8adb


----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 10:40

Message:
Agreed. Commit this and close when you get a chance.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28371&group_id=126

From jbarnette at gmail.com  Sat Nov 13 09:26:41 2010
From: jbarnette at gmail.com (John Barnette)
Date: Sat, 13 Nov 2010 08:26:41 -0600
Subject: [Rubygems-developers] Ticket Triage
Message-ID: <2EA55885-C479-43D5-BBB0-A85A54375A2B@gmail.com>

I've gone through everything. Please take a look in the RF tracker, see what I've saddled you with, and move stuff around if it's not for you. Also, I'd appreciate everyone piling on in the comments of these tix:

http://rubyforge.org/tracker/index.php?func=detail&aid=28356&group_id=126&atid=575
http://rubyforge.org/tracker/index.php?func=detail&aid=27507&group_id=126&atid=575
http://rubyforge.org/tracker/index.php?func=detail&aid=28286&group_id=126&atid=575


~ j.


From noreply at rubyforge.org  Sat Nov 13 09:27:08 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 09:27:08 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27507 ] Remove -t from gem
	install
Message-ID: <20101113142708.989D018583C3@rubyforge.org>

Bugs item #27507, was opened at 2009-12-01 21:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: Ryan Davis (zenspider)
Summary: Remove -t from gem install

Initial Comment:
this is a message body.

----------------------------------------------------------------------

>Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 11:27

Message:
Yes please.

Lot of projects do testing differently. Even if you declare all the development dependencies it also depend on certain tools or certain services been installed in the user machine.

These are not self contained. If the user wants to run tests, then look for the source, clone/checkout and follow the developer instructions.

That is more easy than maintain a command that cannot solve all the aspects of "testing" a gem.

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 11:00

Message:
I think -t should die. Other folks?

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-03 13:29

Message:
I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb.  If this property existed, it would be used and the return code from the script would indicate test success/failure.

May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-03 05:15

Message:
Chad, what do you mean by a "test suite script"?

I was thinking a -r option to run the 'test' Rake task, if it exists.

I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-01 23:49

Message:
'Is there a reason we can't just make -t run "ruby -I spec.lib
spec.test_files"' - good idea.  And/or add an additional spec parameter for a test suite script...

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-01 23:45

Message:
Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

From jbarnette at gmail.com  Sat Nov 13 09:45:29 2010
From: jbarnette at gmail.com (John Barnette)
Date: Sat, 13 Nov 2010 08:45:29 -0600
Subject: [Rubygems-developers] pushed failing tests
In-Reply-To: <103FB494-9420-4EBB-9675-88DCF55D9E6E@zenspider.com>
References: <9C393809-F29A-4749-9609-A9ED65CCB81C@zenspider.com>
	<64EBE5E7-A910-4563-8511-3331C0852115@gmail.com>
	<103FB494-9420-4EBB-9675-88DCF55D9E6E@zenspider.com>
Message-ID: <D22DD239-7E8B-4E80-A796-F0210397B33B@gmail.com>

On Nov 13, 2010, at 1:15 AM, Ryan Davis wrote:
> On Nov 13, 2010, at 00:00 , John Barnette wrote:
>> On Nov 12, 2010, at 3:20 PM, Ryan Davis wrote:
>>> Just a heads up. I've pushed failing tests while JB and I work through some scenarios.
>> 
>> I'll probably move these to a branch tomorrow since we're looking at an imminent 1.4, since major dependency resolution changes prolly aren't in the cards for a point release. Easy change tho.

Moved from master to the "deps" branch. Let's work there.


~ j.


From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 09:47:32 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 14:47:32 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 2ceea95
	fixed
Message-ID: <4cdea50434694_7270..fdbe31380754@ci.pivotallabs.com.tmail>

The build has been fixed.

CHANGES
-------
Revision ...2ceea95bedc29ce76269c1e02108f7d1822edf32 committed by John Barnette <jbarnette at gmail.com> on 2010-11-13 14:41:25

    Move failing/new gather_dependencies tests to a 'deps' branch.

 test/test_gem_dependency_installer.rb |   88 ---------------------------------
 1 files changed, 0 insertions(+), 88 deletions(-)



See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/2ceea95bedc29ce76269c1e02108f7d1822edf32 for details.

From noreply at rubyforge.org  Sat Nov 13 10:06:29 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 10:06:29 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27507 ] Remove -t from gem
	install
Message-ID: <20101113150629.7171818583D3@rubyforge.org>

Bugs item #27507, was opened at 2009-12-01 17:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: Ryan Davis (zenspider)
Summary: Remove -t from gem install

Initial Comment:
this is a message body.

----------------------------------------------------------------------

>Comment By: Daniel Berger (djberg96)
Date: 2010-11-13 08:06

Message:
I would argue that requiring the user to check out the source and run the tests is generally going to be a burden most people won't waste their time on. They'll just assume that it works.

I'm tainted by my Perl background here, but with CPAN all tests are run automatically (by default) when installing via the CPAN shell. The module will not install if any tests fail, except by force. In addition, test failures can be automatically reported to the CI farm that they've setup.

Perl has multiple testing frameworks, yet somehow they manage to work.

I think we're going down the wrong path here. I'd rather establish that all gems follow some sort of convention (perhaps in the spec) with regards to testing, and how tests should be run, that the "-t" option could then hook into.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 07:27

Message:
Yes please.

Lot of projects do testing differently. Even if you declare all the development dependencies it also depend on certain tools or certain services been installed in the user machine.

These are not self contained. If the user wants to run tests, then look for the source, clone/checkout and follow the developer instructions.

That is more easy than maintain a command that cannot solve all the aspects of "testing" a gem.

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 07:00

Message:
I think -t should die. Other folks?

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-03 09:29

Message:
I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb.  If this property existed, it would be used and the return code from the script would indicate test success/failure.

May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-03 01:15

Message:
Chad, what do you mean by a "test suite script"?

I was thinking a -r option to run the 'test' Rake task, if it exists.

I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-01 19:49

Message:
'Is there a reason we can't just make -t run "ruby -I spec.lib
spec.test_files"' - good idea.  And/or add an additional spec parameter for a test suite script...

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-01 19:45

Message:
Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

From noreply at rubyforge.org  Sat Nov 13 10:12:16 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 10:12:16 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27507 ] Remove -t from gem
	install
Message-ID: <20101113151216.CF2251678318@rubyforge.org>

Bugs item #27507, was opened at 2009-12-01 21:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: Ryan Davis (zenspider)
Summary: Remove -t from gem install

Initial Comment:
this is a message body.

----------------------------------------------------------------------

>Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 12:12

Message:
Daniel

Please point me to the right CPAN of a module that does MySQL?

Also, point me to one CPAN module that also does Memcached.

How there are installed and tested if the user do not have MySQL or Memcached installed?

We are not talking about a pure-ruby or Ruby+C gems that these tests/specs can be run.

We are talking that for certain projects, preconditions are required.

Take for example testing ActiveRecord, see its dependencies:

https://rubygems.org/gems/activerecord

There is no declared development dependencies because the project is developed differently:

https://github.com/rails/rails

The gem is part of one single repository.

Will be aweomse if this worked during installation, but how you solve the issue for installation of gem binaries?

How you test it if your service/dependency is not local on the user machine?

Not counting with the fact that some tests might actually write stuff to these databases/memory of their users installation.

We want that?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2010-11-13 12:06

Message:
I would argue that requiring the user to check out the source and run the tests is generally going to be a burden most people won't waste their time on. They'll just assume that it works.

I'm tainted by my Perl background here, but with CPAN all tests are run automatically (by default) when installing via the CPAN shell. The module will not install if any tests fail, except by force. In addition, test failures can be automatically reported to the CI farm that they've setup.

Perl has multiple testing frameworks, yet somehow they manage to work.

I think we're going down the wrong path here. I'd rather establish that all gems follow some sort of convention (perhaps in the spec) with regards to testing, and how tests should be run, that the "-t" option could then hook into.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 11:27

Message:
Yes please.

Lot of projects do testing differently. Even if you declare all the development dependencies it also depend on certain tools or certain services been installed in the user machine.

These are not self contained. If the user wants to run tests, then look for the source, clone/checkout and follow the developer instructions.

That is more easy than maintain a command that cannot solve all the aspects of "testing" a gem.

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 11:00

Message:
I think -t should die. Other folks?

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-03 13:29

Message:
I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb.  If this property existed, it would be used and the return code from the script would indicate test success/failure.

May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-03 05:15

Message:
Chad, what do you mean by a "test suite script"?

I was thinking a -r option to run the 'test' Rake task, if it exists.

I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-01 23:49

Message:
'Is there a reason we can't just make -t run "ruby -I spec.lib
spec.test_files"' - good idea.  And/or add an additional spec parameter for a test suite script...

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-01 23:45

Message:
Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

From noreply at rubyforge.org  Sat Nov 13 10:44:35 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 10:44:35 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27507 ] Remove -t from gem
	install
Message-ID: <20101113154435.D766F167831C@rubyforge.org>

Bugs item #27507, was opened at 2009-12-01 17:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: Ryan Davis (zenspider)
Summary: Remove -t from gem install

Initial Comment:
this is a message body.

----------------------------------------------------------------------

>Comment By: Daniel Berger (djberg96)
Date: 2010-11-13 08:44

Message:
Luis, that doesn't even make sense to me. You aren't going to install a MySQL gem unless you already have MySQL installed. The installation would fail regardless of -t. CPAN modules do not (typically) bundle 3rd party dependencies.

I'm not sure what you're getting at with activerecord. Dependencies would be installed before the tests would be run for whatever gem you've installed. Also, activerecord may be part of the rails bundle, but it can be installed separately afaik.

I'm not sure how gem binaries would be different. The files + directory structure could still be created (as they are even for failed gem installs in the case of C extensions), and the tests could be run from there. Or it could be created in a temp directory. If the tests fail they're cleaned up.

Development dependencies would be necessary to install, at least temporarily, to run the tests. They could be deleted afterwards.

As to writing to the database, I really don't see that happening. What, they just guessed your username and password? Honestly, I would consider such behavior malicious. Note that there's nothing stopping people from doing something like that now via the extconf.rb file.

In practice what I've seen from CPAN database libraries is an interactive shell that asks me if it's ok to create a temporary schema, give it a username and password, and do its thing.

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 08:12

Message:
Daniel

Please point me to the right CPAN of a module that does MySQL?

Also, point me to one CPAN module that also does Memcached.

How there are installed and tested if the user do not have MySQL or Memcached installed?

We are not talking about a pure-ruby or Ruby+C gems that these tests/specs can be run.

We are talking that for certain projects, preconditions are required.

Take for example testing ActiveRecord, see its dependencies:

https://rubygems.org/gems/activerecord

There is no declared development dependencies because the project is developed differently:

https://github.com/rails/rails

The gem is part of one single repository.

Will be aweomse if this worked during installation, but how you solve the issue for installation of gem binaries?

How you test it if your service/dependency is not local on the user machine?

Not counting with the fact that some tests might actually write stuff to these databases/memory of their users installation.

We want that?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2010-11-13 08:06

Message:
I would argue that requiring the user to check out the source and run the tests is generally going to be a burden most people won't waste their time on. They'll just assume that it works.

I'm tainted by my Perl background here, but with CPAN all tests are run automatically (by default) when installing via the CPAN shell. The module will not install if any tests fail, except by force. In addition, test failures can be automatically reported to the CI farm that they've setup.

Perl has multiple testing frameworks, yet somehow they manage to work.

I think we're going down the wrong path here. I'd rather establish that all gems follow some sort of convention (perhaps in the spec) with regards to testing, and how tests should be run, that the "-t" option could then hook into.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 07:27

Message:
Yes please.

Lot of projects do testing differently. Even if you declare all the development dependencies it also depend on certain tools or certain services been installed in the user machine.

These are not self contained. If the user wants to run tests, then look for the source, clone/checkout and follow the developer instructions.

That is more easy than maintain a command that cannot solve all the aspects of "testing" a gem.

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 07:00

Message:
I think -t should die. Other folks?

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-03 09:29

Message:
I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb.  If this property existed, it would be used and the return code from the script would indicate test success/failure.

May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-03 01:15

Message:
Chad, what do you mean by a "test suite script"?

I was thinking a -r option to run the 'test' Rake task, if it exists.

I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-01 19:49

Message:
'Is there a reason we can't just make -t run "ruby -I spec.lib
spec.test_files"' - good idea.  And/or add an additional spec parameter for a test suite script...

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-01 19:45

Message:
Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

From noreply at rubyforge.org  Sat Nov 13 11:13:10 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 11:13:10 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28486 ] unable to use runtime
	dependencies in mkrf_conf.rb
Message-ID: <20101113161310.D6E4418583DF@rubyforge.org>

Bugs item #28486, was opened at 2010-08-19 00:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28486&group_id=126

Category: `gem install` command
Group: None
Status: Closed
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to use runtime dependencies in mkrf_conf.rb

Initial Comment:
Situation currently:

if you have the following in your mkrf_conf.rb file


require 'rubygems'
require 'some dependency gem'

and your gemspec lists "some dependency gem" as a runtime dependency, your gem will fail to install the first time, then install correctly when you attempt to install it a second time.  I would have expected runtime dependencies to be available at build time of the main gem.
Thanks!
-r

----------------------------------------------------------------------

>Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:13

Message:
why was this closed?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28486&group_id=126

From noreply at rubyforge.org  Sat Nov 13 11:19:14 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 11:19:14 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28356 ] gem which only shows
	one possible option
Message-ID: <20101113161914.9D98918583E4@rubyforge.org>

Bugs item #28356, was opened at 2010-07-05 15:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: John Barnette (jbarnette)
Summary: gem which only shows one possible option

Initial Comment:
Situation: currently if there is a conflict among gems, i.e. 

gem1/lib/xxx.rb
and
gem2/lib/xxx.rb

gem which will only show one of the possibilities, which seems unexpected to me.

ex:

d:\dev>gem which ruby_to_ruby_c
(checking gem RubyToC-1.0.0.5 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/RubyToC-1.0.0.5/lib/ruby_to_ruby_c.rb

d:\dev> gem uninstall RubyToC
...
d:\dev>gem which ruby_to_ruby_c
(checking gem ruby2c-1.0.0.7 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/ruby2c-1.0.0.7/lib/ruby_to_ruby_c.rb

-r

----------------------------------------------------------------------

>Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:19

Message:
people depend on it to show only one?

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 13:57

Message:
I understand the confusion, but I think having `gem which` return multiple files at this point would be really confusing/dangerous for folks who have come to depend on it returning only one.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

From noreply at rubyforge.org  Sat Nov 13 11:20:47 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 11:20:47 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28414 ] RubyGems 1.3.7
	default gem directory is wrong when used with ruby 1.9.1 with
	--program-suffix=1.9
Message-ID: <20101113162047.E704018583C6@rubyforge.org>

Bugs item #28414, was opened at 2010-07-22 12:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Svetoslav Agafonkin (svetlyo)
Assigned to: Eric Hodel (drbrain)
Summary: RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9

Initial Comment:
RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9.

Gem.default_dir generates "/opt/local/lib/ruby/gems/1.9.1/"  instead of "/opt/local/lib/ruby1.9/gems/1.9.1/".

The change was introduced in lib/rubygems/defaults.rb in

http://github.com/rubygems/rubygems/commit/0495c7c0dd9878f9a7a74f5133d7892d28d01812

- a big import from the ruby trunk, right after 1.3.6 was released.

The original change comes from this commit:
http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=26048


---------------------
Mac OS X 10.5.8
ruby 1.9.1_429 (from Macports)
rubgygems 1.3.7

$ gem1.9 env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.1 (2010-07-02 patchlevel 429) [i386-darwin9]
  - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: /opt/local/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /opt/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-9
  - GEM PATHS:
     - /opt/local/lib/ruby/gems/1.9.1
     - /Users/fro/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 16:20

Message:
This is also related to a ruby bug that I need to submit. Feel free to assign to me after the we decide what to do with the suffix.

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 13:44

Message:
Eric, what do you think?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126

From noreply at rubyforge.org  Sat Nov 13 11:31:45 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 11:31:45 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28715 ] unable to install
	rubygems from .tar.gz to 1.9.2
Message-ID: <20101113163145.E510418583DE@rubyforge.org>

Bugs item #28715, was opened at 2010-11-13 16:31
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28715&group_id=126

Category: RubyGems installer (setup.rb)
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to install rubygems from .tar.gz to 1.9.2

Initial Comment:
viz:

D:\dev\downloads\rubygems-1.3.7>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

D:\dev\downloads\rubygems-1.3.7>ruby setup.rb
D:/dev/downloads/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_directories': undefined method `path' for Gem:Module (NoMethodError)
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from_installed_gems'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in `initialize'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:841:in `new'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searcher'
        from <internal:prelude>:10:in `synchronize'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:1139:in `<top (required)>'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from setup.rb:24:in `<main>'



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28715&group_id=126

From luislavena at gmail.com  Sat Nov 13 11:37:52 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 13 Nov 2010 13:37:52 -0300
Subject: [Rubygems-developers] Ticket Triage
In-Reply-To: <2EA55885-C479-43D5-BBB0-A85A54375A2B@gmail.com>
References: <2EA55885-C479-43D5-BBB0-A85A54375A2B@gmail.com>
Message-ID: <AANLkTimFJ0jnb25rXku-zD_-CYE5pSk0x0d2eUyFpp2G@mail.gmail.com>

On Sat, Nov 13, 2010 at 11:26 AM, John Barnette <jbarnette at gmail.com> wrote:
> I've gone through everything. Please take a look in the RF tracker, see what I've saddled you with, and move stuff around if it's not for you. Also, I'd appreciate everyone piling on in the comments of these tix:
>
> http://rubyforge.org/tracker/index.php?func=detail&aid=28356&group_id=126&atid=575
> http://rubyforge.org/tracker/index.php?func=detail&aid=27507&group_id=126&atid=575
> http://rubyforge.org/tracker/index.php?func=detail&aid=28286&group_id=126&atid=575
>

RubyForge seems not to be working for me, but was 2 hours ago.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From noreply at rubyforge.org  Sat Nov 13 11:53:18 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 11:53:18 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28384 ] gem install doesn't
	refresh Rakefile (or something along those lines)
Message-ID: <20101113165318.4E42A18583E1@rubyforge.org>

Bugs item #28384, was opened at 2010-07-14 17:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28384&group_id=126

Category: `gem install` command
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gem install doesn't refresh Rakefile (or something along those lines)

Initial Comment:
Hi.  Noticed the following:




C:\installs\a space\ruby_1_8_installed\bin>gem install spork
Building native extensions.  This could take a while...
Successfully installed spork-0.8.4
1 gem installed

# reports success


C:\installs\a space\ruby_1_8_installed\bin>gem uninstall spork -a
Remove executables:
        spork

in addition to the gem? [Yn]  y
Removing spork
Successfully uninstalled spork-0.8.4

C:\installs\a space\ruby_1_8_installed\bin>gem install spork
Building native extensions.  This could take a while...
ERROR:  Error installing spork:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_8_installed/bin/ruby.exe" mkrf_conf.rb
Actually, there aren't any native extensions. I'm just dynamically installing dependencies based off of your operating system
installing windows dependencies

"C:/installs/a space/ruby_1_8_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/lib"
C:/installs/a space/ruby_1_8_installed/bin/ruby.exe:36: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4 for inspection.
Results logged to C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/ext/gem_make.out


now reports failure.  I would have expected them both to report failure.

Thanks.
-r

----------------------------------------------------------------------

>Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:53

Message:
I believe this is the same cause as 28385

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 04:11

Message:
I don't see what this has to do with anything... You didn't quote the path to rake. This has nothing to do with rubygems.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28384&group_id=126

From noreply at rubyforge.org  Sat Nov 13 11:53:58 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 11:53:58 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28385 ] gems with
	mkrf_conf.rb extensions fail to build when installed into a
	ruby in a directory name that includes spaces
Message-ID: <20101113165358.A973F18583E1@rubyforge.org>

Bugs item #28385, was opened at 2010-07-14 17:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

Category: `gem install` command
Group: None
>Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gems with mkrf_conf.rb extensions fail to build when installed into a ruby in a directory name that includes spaces

Initial Comment:

C:\installs\a space\ruby_1_9_2_installed\bin>gem install rdp-rb-readline
Building native extensions.  This could take a while...
ERROR:  Error installing rdp-rb-readline:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" mkrf_conf.rb

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib"
C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1 for inspection.
Results logged to C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/ext/gem_make.out

----------------------------------------------------------------------

>Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:53

Message:
This is still a problem.
How to reproduce: install ruby into a dir with space, install 
spork. Fails (spork installs fine elsewhere).  Rubygems 
should be quoting the path.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 04:12

Message:
What does this have to do with rubygems?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

From noreply at rubyforge.org  Sat Nov 13 11:57:24 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 11:57:24 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27507 ] Remove -t from gem
	install
Message-ID: <20101113165724.B44FA18583E5@rubyforge.org>

Bugs item #27507, was opened at 2009-12-01 16:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: Ryan Davis (zenspider)
Summary: Remove -t from gem install

Initial Comment:
this is a message body.

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 08:57

Message:
This has been discussed at length already. It just needs to go. We can not support all the different ways that people test.

"I'd rather establish that all gems follow some sort of convention"

This is just not realistic, considering we DID establish a convention and it obviously didn't work.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2010-11-13 07:44

Message:
Luis, that doesn't even make sense to me. You aren't going to install a MySQL gem unless you already have MySQL installed. The installation would fail regardless of -t. CPAN modules do not (typically) bundle 3rd party dependencies.

I'm not sure what you're getting at with activerecord. Dependencies would be installed before the tests would be run for whatever gem you've installed. Also, activerecord may be part of the rails bundle, but it can be installed separately afaik.

I'm not sure how gem binaries would be different. The files + directory structure could still be created (as they are even for failed gem installs in the case of C extensions), and the tests could be run from there. Or it could be created in a temp directory. If the tests fail they're cleaned up.

Development dependencies would be necessary to install, at least temporarily, to run the tests. They could be deleted afterwards.

As to writing to the database, I really don't see that happening. What, they just guessed your username and password? Honestly, I would consider such behavior malicious. Note that there's nothing stopping people from doing something like that now via the extconf.rb file.

In practice what I've seen from CPAN database libraries is an interactive shell that asks me if it's ok to create a temporary schema, give it a username and password, and do its thing.

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 07:12

Message:
Daniel

Please point me to the right CPAN of a module that does MySQL?

Also, point me to one CPAN module that also does Memcached.

How there are installed and tested if the user do not have MySQL or Memcached installed?

We are not talking about a pure-ruby or Ruby+C gems that these tests/specs can be run.

We are talking that for certain projects, preconditions are required.

Take for example testing ActiveRecord, see its dependencies:

https://rubygems.org/gems/activerecord

There is no declared development dependencies because the project is developed differently:

https://github.com/rails/rails

The gem is part of one single repository.

Will be aweomse if this worked during installation, but how you solve the issue for installation of gem binaries?

How you test it if your service/dependency is not local on the user machine?

Not counting with the fact that some tests might actually write stuff to these databases/memory of their users installation.

We want that?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2010-11-13 07:06

Message:
I would argue that requiring the user to check out the source and run the tests is generally going to be a burden most people won't waste their time on. They'll just assume that it works.

I'm tainted by my Perl background here, but with CPAN all tests are run automatically (by default) when installing via the CPAN shell. The module will not install if any tests fail, except by force. In addition, test failures can be automatically reported to the CI farm that they've setup.

Perl has multiple testing frameworks, yet somehow they manage to work.

I think we're going down the wrong path here. I'd rather establish that all gems follow some sort of convention (perhaps in the spec) with regards to testing, and how tests should be run, that the "-t" option could then hook into.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 06:27

Message:
Yes please.

Lot of projects do testing differently. Even if you declare all the development dependencies it also depend on certain tools or certain services been installed in the user machine.

These are not self contained. If the user wants to run tests, then look for the source, clone/checkout and follow the developer instructions.

That is more easy than maintain a command that cannot solve all the aspects of "testing" a gem.

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 06:00

Message:
I think -t should die. Other folks?

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-03 08:29

Message:
I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb.  If this property existed, it would be used and the return code from the script would indicate test success/failure.

May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-03 00:15

Message:
Chad, what do you mean by a "test suite script"?

I was thinking a -r option to run the 'test' Rake task, if it exists.

I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-01 18:49

Message:
'Is there a reason we can't just make -t run "ruby -I spec.lib
spec.test_files"' - good idea.  And/or add an additional spec parameter for a test suite script...

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-01 18:45

Message:
Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

From noreply at rubyforge.org  Sat Nov 13 12:40:30 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 12:40:30 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27507 ] Remove -t from gem
	install
Message-ID: <20101113174030.61F2518583BD@rubyforge.org>

Bugs item #27507, was opened at 2009-12-01 16:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: Ryan Davis (zenspider)
Summary: Remove -t from gem install

Initial Comment:
this is a message body.

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 09:40

Message:
done

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 08:57

Message:
This has been discussed at length already. It just needs to go. We can not support all the different ways that people test.

"I'd rather establish that all gems follow some sort of convention"

This is just not realistic, considering we DID establish a convention and it obviously didn't work.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2010-11-13 07:44

Message:
Luis, that doesn't even make sense to me. You aren't going to install a MySQL gem unless you already have MySQL installed. The installation would fail regardless of -t. CPAN modules do not (typically) bundle 3rd party dependencies.

I'm not sure what you're getting at with activerecord. Dependencies would be installed before the tests would be run for whatever gem you've installed. Also, activerecord may be part of the rails bundle, but it can be installed separately afaik.

I'm not sure how gem binaries would be different. The files + directory structure could still be created (as they are even for failed gem installs in the case of C extensions), and the tests could be run from there. Or it could be created in a temp directory. If the tests fail they're cleaned up.

Development dependencies would be necessary to install, at least temporarily, to run the tests. They could be deleted afterwards.

As to writing to the database, I really don't see that happening. What, they just guessed your username and password? Honestly, I would consider such behavior malicious. Note that there's nothing stopping people from doing something like that now via the extconf.rb file.

In practice what I've seen from CPAN database libraries is an interactive shell that asks me if it's ok to create a temporary schema, give it a username and password, and do its thing.

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 07:12

Message:
Daniel

Please point me to the right CPAN of a module that does MySQL?

Also, point me to one CPAN module that also does Memcached.

How there are installed and tested if the user do not have MySQL or Memcached installed?

We are not talking about a pure-ruby or Ruby+C gems that these tests/specs can be run.

We are talking that for certain projects, preconditions are required.

Take for example testing ActiveRecord, see its dependencies:

https://rubygems.org/gems/activerecord

There is no declared development dependencies because the project is developed differently:

https://github.com/rails/rails

The gem is part of one single repository.

Will be aweomse if this worked during installation, but how you solve the issue for installation of gem binaries?

How you test it if your service/dependency is not local on the user machine?

Not counting with the fact that some tests might actually write stuff to these databases/memory of their users installation.

We want that?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2010-11-13 07:06

Message:
I would argue that requiring the user to check out the source and run the tests is generally going to be a burden most people won't waste their time on. They'll just assume that it works.

I'm tainted by my Perl background here, but with CPAN all tests are run automatically (by default) when installing via the CPAN shell. The module will not install if any tests fail, except by force. In addition, test failures can be automatically reported to the CI farm that they've setup.

Perl has multiple testing frameworks, yet somehow they manage to work.

I think we're going down the wrong path here. I'd rather establish that all gems follow some sort of convention (perhaps in the spec) with regards to testing, and how tests should be run, that the "-t" option could then hook into.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-13 06:27

Message:
Yes please.

Lot of projects do testing differently. Even if you declare all the development dependencies it also depend on certain tools or certain services been installed in the user machine.

These are not self contained. If the user wants to run tests, then look for the source, clone/checkout and follow the developer instructions.

That is more easy than maintain a command that cannot solve all the aspects of "testing" a gem.

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 06:00

Message:
I think -t should die. Other folks?

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-03 08:29

Message:
I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb.  If this property existed, it would be used and the return code from the script would indicate test success/failure.

May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-03 00:15

Message:
Chad, what do you mean by a "test suite script"?

I was thinking a -r option to run the 'test' Rake task, if it exists.

I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-12-01 18:49

Message:
'Is there a reason we can't just make -t run "ruby -I spec.lib
spec.test_files"' - good idea.  And/or add an additional spec parameter for a test suite script...

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-12-01 18:45

Message:
Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126

From noreply at rubyforge.org  Sat Nov 13 12:41:49 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 12:41:49 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28155 ] source_index.rb uses
	1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues
Message-ID: <20101113174149.3316D1858390@rubyforge.org>

Bugs item #28155, was opened at 2010-04-29 19:10
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

Category: other
Group: v1.3.x
>Status: Closed
Resolution: Out of Date
Priority: 1
Submitted By: Randall Lucas (rlucas)
Assigned to: John Barnette (jbarnette)
Summary: source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues

Initial Comment:
Facially, this looks like an argument TypeError, and manifests thus:

/usr/local/lib/site_ruby/1.9/rubygems/source_index.rb:91:in `IO#read': can't convert Hash into Integer (TypeError)

In fact, it's a very similar issue to #28154.

source_index.rb at line 88 checks RUBY_VERSION < '1.9' before using the new :encoding => 'UTF-8' calling syntax for File.read (IO#read).

However, this change didn't make it into Ruby 1.9.0 (see below from core Changelog).

Again, the fix here is to check RUBY_VERSION < '1.9.1'

Similar errors may be lurking in config_file.rb, defaults.rb, vanidator.rb, and in the tests.


---
$ irb1.9
irb(main):001:0> File.open '/tmp/thing.txt' , :encoding => 'UTF-8'
TypeError: can't convert Hash into String
        from (irb):1:in `initialize'
        from (irb):1:in `Kernel#binding'

---
Fri Feb 15 16:22:49 2008  Yukihiro Matsumoto  <matz at ruby-lang.org>

    * io.c (open_key_args): allow specifying both :mode and :encoding.
---
$ ruby -v
ruby 1.9.0 (2006-06-08) [x86_64-linux]

$ gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.6
  - RUBY VERSION: 1.9.0 (2006-06-08) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby1.9/gems/1.9
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby1.9/gems/1.9
     - /home/rlucas/.gem/ruby/1.9
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 17:41

Message:
Not sure we want to support 1.9.0, besides, upgrades don't work right without rebuilding ruby due to the core integration, so we should just wontfix.

Closing, reopen if any of the committers disagree.

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 13:35

Message:
I welcome a patch (preferably a pull request on GitHub) if this is still a concern. I'll close this ticket in a week or two if I don't see any activity.

----------------------------------------------------------------------

Comment By: Jason Frey (fryguy)
Date: 2010-06-23 20:40

Message:
I agree with Rob Anderson's disagreement.

I am using RubyGems 1.3.7 with both Ruby 1.8.6 and Ruby 1.8.7.  My project has REXML::Encoding loaded, so defined? Encoding passes when it shouldn't, and blows up with the can't convert Hash into Integer error.

I've changed source_index.rb:88 (similar to OP) to 
  spec_code = if RUBY_VERSION > '1.9.0' && defined? Encoding 
in order to get past the problem.

The mechanism of using defined? Encoding is insufficient if all that is needed is to determine the version of Ruby.  RUBY_VERSION feels like the more appropriate approach.

----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-26 05:13

Message:
I was using 1.9.0 because it was, and is, the Ruby 1.9 that
ships with Debian stable (both oldstable 4.x and current
stable 5.x).

It is bad to rely upon users not to use 1.9.0, because at
least one major *NIX distro includes it, and it is not
immediately apparent to the casual user/developer that 1.9.0
is special and untouchable.

That Rubygems should work on 1.8.X and 1.9.Y | Y >= 1
violates the principle of least surprise.  Whether or not
1.9.0 is intended for production is not the issue.  If
Rubygems is going to do version and/or symbol presence
checking that is known to break for this special case of
1.9.0, then it should do just one more version check and die
on invocation with 1.9.0, with a helpful message.

Seriously, for both this ticket and #28154, let's just
please stipulate that the API-change-induced version checks
should correspond to the actual versions in which the API
change is present.  The whole "> 1.9" vs. "> 1.9.0" shortcut
is bit-wise and byte-foolish.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-05-25 22:06

Message:
Why are you using 1.9.0?  AFAIK it was never intended for production use.

----------------------------------------------------------------------

Comment By: Rob Anderson (rabbashanks)
Date: 2010-05-24 11:30

Message:
I disagree that testing for the "Encoding" class name symbol is the better approach.  On my system (stats below), Encoding is defined by REXML as REXML::Encoding - so defined? Encoding returns true, despite my ruby version being 1.8.6

I have implemented the explicit check on RUBY_VERSION in my local copy of rubygems, but I would think this should be the way it is done for everyone.

ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]

gem ENV
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0]
  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/local/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-10
  - GEM PATHS:
     - /usr/local/lib/ruby/gems/1.8
     - /Users/robanderson/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

Comment By: Randall Lucas (rlucas)
Date: 2010-05-01 17:48

Message:
This appears to have been fixed in trunk.  Current code
takes the better approach of testing for the "Encoding"
class name symbol, and specifying encoding if it exists (as
it does in 1.9.1 and above).

Lurking cousin errors to this, with the version check
assumption of consistent behavior for >= 1.9 (when in fact,
1.9.0 and 1.9.1 have pretty major API diffs), may linger here:

rubygems/commands/install_command.rb:112:    ENV.delete
'GEM_PATH' if options[:install_dir].nil? and RUBY_VERSION >
'1.9'

rubygems/config_file.rb:54:      if RUBY_VERSION > '1.9' then

rubygems/validator.rb:168:  if RUBY_VERSION < '1.9' then

rubygems/validator.rb:215:    if RUBY_VERSION < '1.9' then

rubygems.rb:500:    unless RUBY_VERSION > '1.9' then

rubygems.rb:1135:require 'rubygems/custom_require' if
gem_disabled or RUBY_VERSION < '1.9'


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126

From noreply at rubyforge.org  Sat Nov 13 13:06:52 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 13:06:52 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28715 ] unable to install
	rubygems from .tar.gz to 1.9.2
Message-ID: <20101113180652.87DEF18583D4@rubyforge.org>

Bugs item #28715, was opened at 2010-11-13 08:31
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28715&group_id=126

Category: RubyGems installer (setup.rb)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to install rubygems from .tar.gz to 1.9.2

Initial Comment:
viz:

D:\dev\downloads\rubygems-1.3.7>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

D:\dev\downloads\rubygems-1.3.7>ruby setup.rb
D:/dev/downloads/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_directories': undefined method `path' for Gem:Module (NoMethodError)
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from_installed_gems'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in `initialize'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:841:in `new'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searcher'
        from <internal:prelude>:10:in `synchronize'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:1139:in `<top (required)>'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from setup.rb:24:in `<main>'



----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 10:06

Message:
So don't do that.

% ~/.multiruby/install/1.9.2-p0/bin/ruby -S gem -v
1.3.7


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28715&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 13:29:18 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 18:29:18 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 54453fb
	failed
Message-ID: <4cded8fed064f_7270..fdbe313808b9@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...54453fba905c40c5d013ea2a81b8f0fbb486db9b committed by raggi <jftucker at gmail.com> on 2010-11-13 18:25:20

    Merge branch 'master' of github.com:rubygems/rubygems
    * 'master' of github.com:rubygems/rubygems:
    + Removed --test option from install. Fixes 27507
    Added zlib
    Move failing/new gather_dependencies tests to a 'deps' branch.
Revision ...95f518dc8e415024017c2692ab63080bbee39e8e committed by raggi <jftucker at gmail.com> on 2010-11-13 18:06:57

    use ENV['SystemDrive'] if it might matter

 lib/rubygems.rb |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_19134/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_19134/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_19134/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_19134/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/54453fba905c40c5d013ea2a81b8f0fbb486db9b for details.

From noreply at rubyforge.org  Sat Nov 13 14:39:30 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 14:39:30 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28385 ] gems with
	mkrf_conf.rb extensions fail to build when installed into a
	ruby in a directory name that includes spaces
Message-ID: <20101113193930.0CFA818583E0@rubyforge.org>

Bugs item #28385, was opened at 2010-07-14 17:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
>Assigned to: James Tucker (raggi)
Summary: gems with mkrf_conf.rb extensions fail to build when installed into a ruby in a directory name that includes spaces

Initial Comment:

C:\installs\a space\ruby_1_9_2_installed\bin>gem install rdp-rb-readline
Building native extensions.  This could take a while...
ERROR:  Error installing rdp-rb-readline:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" mkrf_conf.rb

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib"
C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1 for inspection.
Results logged to C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/ext/gem_make.out

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:53

Message:
This is still a problem.
How to reproduce: install ruby into a dir with space, install 
spork. Fails (spork installs fine elsewhere).  Rubygems 
should be quoting the path.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 04:12

Message:
What does this have to do with rubygems?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

From noreply at rubyforge.org  Sat Nov 13 14:48:00 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 14:48:00 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28385 ] gems with
	mkrf_conf.rb extensions fail to build when installed into a
	ruby in a directory name that includes spaces
Message-ID: <20101113194800.CC3DD18583D8@rubyforge.org>

Bugs item #28385, was opened at 2010-07-14 17:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

Category: `gem install` command
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: James Tucker (raggi)
Summary: gems with mkrf_conf.rb extensions fail to build when installed into a ruby in a directory name that includes spaces

Initial Comment:

C:\installs\a space\ruby_1_9_2_installed\bin>gem install rdp-rb-readline
Building native extensions.  This could take a while...
ERROR:  Error installing rdp-rb-readline:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" mkrf_conf.rb

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib"
C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1 for inspection.
Results logged to C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/ext/gem_make.out

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 19:48

Message:
Fixed in https://github.com/rubygems/rubygems/commit/c9765e122c8e5be5a00911fe59e15251c842a9f8

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:53

Message:
This is still a problem.
How to reproduce: install ruby into a dir with space, install 
spork. Fails (spork installs fine elsewhere).  Rubygems 
should be quoting the path.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 04:12

Message:
What does this have to do with rubygems?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 14:50:15 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 19:50:15 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build c9765e1
	failed
Message-ID: <4cdeebf76b000_7270..fdbe313809a5@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...c9765e122c8e5be5a00911fe59e15251c842a9f8 committed by raggi <jftucker at gmail.com> on 2010-11-13 19:46:28

    closes #28385 mkrf with ruby installed in a path with spaces

 lib/rubygems/ext/rake_builder.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_5128/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_5128/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_5128/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_5128/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/c9765e122c8e5be5a00911fe59e15251c842a9f8 for details.

From noreply at rubyforge.org  Sat Nov 13 15:02:07 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 15:02:07 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28356 ] gem which only shows
	one possible option
Message-ID: <20101113200207.3B98918583BE@rubyforge.org>

Bugs item #28356, was opened at 2010-07-05 15:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

Category: other
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
>Assigned to: James Tucker (raggi)
Summary: gem which only shows one possible option

Initial Comment:
Situation: currently if there is a conflict among gems, i.e. 

gem1/lib/xxx.rb
and
gem2/lib/xxx.rb

gem which will only show one of the possibilities, which seems unexpected to me.

ex:

d:\dev>gem which ruby_to_ruby_c
(checking gem RubyToC-1.0.0.5 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/RubyToC-1.0.0.5/lib/ruby_to_ruby_c.rb

d:\dev> gem uninstall RubyToC
...
d:\dev>gem which ruby_to_ruby_c
(checking gem ruby2c-1.0.0.7 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/ruby2c-1.0.0.7/lib/ruby_to_ruby_c.rb

-r

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 20:02

Message:
It has a -a option, but it's broken. I'm fixing it now, have failing tests.

I think this should move to using find_files too.

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:19

Message:
people depend on it to show only one?

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 13:57

Message:
I understand the confusion, but I think having `gem which` return multiple files at this point would be really confusing/dangerous for folks who have come to depend on it returning only one.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

From noreply at rubyforge.org  Sat Nov 13 15:49:52 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 15:49:52 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28385 ] gems with
	mkrf_conf.rb extensions fail to build when installed into a
	ruby in a directory name that includes spaces
Message-ID: <20101113204952.8666318583D7@rubyforge.org>

Bugs item #28385, was opened at 2010-07-14 10:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

Category: `gem install` command
Group: None
Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
>Assigned to: Nobody (None)
Summary: gems with mkrf_conf.rb extensions fail to build when installed into a ruby in a directory name that includes spaces

Initial Comment:

C:\installs\a space\ruby_1_9_2_installed\bin>gem install rdp-rb-readline
Building native extensions.  This could take a while...
ERROR:  Error installing rdp-rb-readline:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" mkrf_conf.rb

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib"
C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1 for inspection.
Results logged to C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/ext/gem_make.out

----------------------------------------------------------------------

>Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 12:49

Message:
We're not going to fix this. There isn't even an analog over in UNIX land as spaces in paths are invalid for shebang lines, so I can't even run gem, let alone rake.

Workaround: don't use spaces in your paths.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-11-13 11:48

Message:
Fixed in https://github.com/rubygems/rubygems/commit/c9765e122c8e5be5a00911fe59e15251c842a9f8

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 08:53

Message:
This is still a problem.
How to reproduce: install ruby into a dir with space, install 
spork. Fails (spork installs fine elsewhere).  Rubygems 
should be quoting the path.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 20:12

Message:
What does this have to do with rubygems?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

From noreply at rubyforge.org  Sat Nov 13 17:01:32 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 17:01:32 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Patches-28716 ] performance patches
Message-ID: <20101113220133.3F90218583D3@rubyforge.org>

Patches item #28716, was opened at 2010-11-13 17:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=577&aid=28716&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Aman Gupta (tmm1)
Assigned to: Nobody (None)
Summary: performance patches

Initial Comment:
See three commits at https://github.com/tmm1/rubygems/compare/master...performance to improve performance of Gem::Version and add a Gem::Dependency#matches_spec? which allows for faster matching against Gem::Specification objects directly.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=577&aid=28716&group_id=126

From noreply at rubyforge.org  Sat Nov 13 17:34:12 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 17:34:12 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28717 ] test_self_find_files
	is intermittent
Message-ID: <20101113223412.AE1781858379@rubyforge.org>

Bugs item #28717, was opened at 2010-11-13 22:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28717&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Tucker (raggi)
Assigned to: Evan Phoenix (evan)
Summary: test_self_find_files is intermittent

Initial Comment:
ruby -Ilib:test test/test_gem.rb --seed 48969 -v

The issue is that some earlier test is leaving foo-1 on the load path. The issue is actually a fuzz for another issue that items on the load path should appear first followed by gems in version order.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28717&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 17:36:18 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 22:36:18 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 495057f
	fixed
Message-ID: <4cdf12e215b01_7270..fdbe31380107b@ci.pivotallabs.com.tmail>

The build has been fixed.

CHANGES
-------
Revision ...495057fd62cca9dc071e86cf6bcea859ea1708c4 committed by John Barnette <jbarnette at gmail.com> on 2010-11-13 22:29:11

    Land Aman's perf. improvements and Dependency#matches_spec? addition. Fixes #28716.



See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/495057fd62cca9dc071e86cf6bcea859ea1708c4 for details.

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 17:41:52 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 22:41:52 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 16a5429
	failed
Message-ID: <4cdf1430577ac_7270..fdbe3138011b1@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...16a5429e533402bd11049c900a4bfc7ad6cb0085 committed by John Barnette <jbarnette at gmail.com> on 2010-11-13 22:36:36

    Land Aman's perf. improvements and Dependency#matches_spec? addition. Fixes #28716.
Revision ...602cd00f1804505dffdd2080d9b4bbd09cd38c3c committed by Aman Gupta <aman at tmm1.net> on 2010-11-13 21:53:40

    Add Gem::Dependency#matches_spec? to match directly against a Gem::Specification object.

 lib/rubygems/dependency.rb |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
Revision ...d5731757ad9fd0b9f98232eb8c1890cf54359848 committed by Aman Gupta <aman at tmm1.net> on 2010-11-13 21:51:33

    Improve performance of Gem::Version#<=> on 1.9 (slightly slower on 1.8)
    require "benchmark"
    require "rubygems"
    module Gem
    class NewVersion < Version # (Version here is from master before this commit)
    def <=> other
    return   1 unless other # HACK: comparable with nil? why?
    return nil unless self.class === other
    return   0     if version == other.version
    lhsegments = segments
    rhsegments = other.segments
    lhsize = lhsegments.size
    rhsize = rhsegments.size
    limit  = (lhsize > rhsize ? lhsize : rhsize) - 1
    i = 0
    while i <= limit
    lhs, rhs = lhsegments[i] || 0, rhsegments[i] || 0
    i += 1
    next               if lhs == rhs
    return  -1         if String  === lhs && Numeric === rhs
    return   1         if Numeric === lhs && String  === rhs
    return lhs <=> rhs
    end
    return 0
    end
    end
    end
    ver1 = Gem::Version.new('1.0.2.0.1')
    ver2 = Gem::Version.new('1.0.2.1.1')
    ver3 = Gem::NewVersion.new('1.0.2.0.1')
    ver4 = Gem::NewVersion.new('1.0.2.1.1')
    Benchmark.bmbm do |x|
    x.report("old <=>") do
    500_000.times { ver1 <=> ver2 }
    end
    x.report("new <=>") do
    500_000.times { ver3 <=> ver4 }
    end
    end
    __END__
    == ruby 1.8
    Rehearsal -------------------------------------------
    old <=>   6.130000   0.000000   6.130000 (  6.191443)
    new <=>   7.030000   0.010000   7.040000 (  7.095676)
    --------------------------------- total: 13.170000sec
    user     system      total        real
    old <=>   7.000000   0.010000   7.010000 (  7.110908)
    new <=>   7.310000   0.030000   7.340000 (  7.439800)
    == ruby 1.9
    Rehearsal -------------------------------------------
    old <=>   4.470000   0.020000   4.490000 (  4.524602)
    new <=>   3.660000   0.010000   3.670000 (  3.679220)
    ---------------------------------- total: 8.160000sec
    user     system      total        real
    old <=>   5.020000   0.010000   5.030000 (  5.096828)
    new <=>   3.930000   0.010000   3.940000 (  3.993851)

 lib/rubygems/version.rb |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)
Revision ...e0ae997e6d9d3fd3d619796df02da2f9dccdc321 committed by Aman Gupta <aman at tmm1.net> on 2010-11-13 21:28:14

    Improve performance of Gem::Version#prerelease?
    require "benchmark"
    require "rubygems"
    module Gem
    class NewVersion < Version
    def prerelease?
    @prerelease ||= @version =~ /[a-zA-Z]/
    end
    end
    end
    ver1 = Gem::Version.new('1.0.2.0.1')
    ver2 = Gem::Version.new('1.0.2.beta.1')
    ver3 = Gem::NewVersion.new('1.0.2.0.1')
    ver4 = Gem::NewVersion.new('1.0.2.beta.1')
    Benchmark.bmbm do |x|
    x.report("old prerelease") do
    200_000.times { ver1.prerelease?; ver2.prerelease? }
    end
    x.report("new prerelease") do
    200_000.times { ver3.prerelease?; ver4.prerelease? }
    end
    end
    __END__
    Rehearsal --------------------------------------------------
    old prerelease   1.080000   0.000000   1.080000 (  1.097570)
    new prerelease   0.330000   0.000000   0.330000 (  0.340355)
    ----------------------------------------- total: 1.410000sec
    user     system      total        real
    old prerelease   1.050000   0.010000   1.060000 (  1.071727)
    new prerelease   0.330000   0.000000   0.330000 (  0.341441)

 lib/rubygems/version.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_11951/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_11951/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_11951/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_11951/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/16a5429e533402bd11049c900a4bfc7ad6cb0085 for details.

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 17:47:27 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 22:47:27 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build de3b28e
	failed
Message-ID: <4cdf157fdde51_7270..fdbe3138012af@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...de3b28e752835996ccc894e23cd7bf2be36f311f committed by Sam Pierson <sam at sampierson.com> on 2010-10-19 01:47:57

    Fix exception error message in Dependency#new
    which was always printing 'nil' for the invalid dependency type as it was attempting to display @type before it had been initialized.  Use the type parameter instead.

 lib/rubygems/dependency.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_13226/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_13226/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_13226/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_13226/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/de3b28e752835996ccc894e23cd7bf2be36f311f for details.

From noreply at rubyforge.org  Sat Nov 13 17:57:54 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 17:57:54 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28718 ] Remote fetcher is not
	thread-safe
Message-ID: <20101113225754.EDC5C18583CA@rubyforge.org>

Bugs item #28718, was opened at 2010-11-14 09:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28718&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Aiden N (dismal_denizen)
Assigned to: Nobody (None)
Summary: Remote fetcher is not thread-safe

Initial Comment:
The caching of connections employed in RemoteFetcher is not thread-safe. Currently projects such as gem-dependent (https://github.com/grosser/gem-dependent) must spawn parallel processes to circumvent this problem, introducing unnecessary overhead.

See https://github.com/rubygems/rubygems/pull/6 for more the details of my investigation into the issue and a fix.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28718&group_id=126

From noreply at rubyforge.org  Sat Nov 13 18:27:14 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 18:27:14 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28715 ] unable to install
	rubygems from .tar.gz to 1.9.2
Message-ID: <20101113232714.0B771167831C@rubyforge.org>

Bugs item #28715, was opened at 2010-11-13 16:31
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28715&group_id=126

Category: RubyGems installer (setup.rb)
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to install rubygems from .tar.gz to 1.9.2

Initial Comment:
viz:

D:\dev\downloads\rubygems-1.3.7>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

D:\dev\downloads\rubygems-1.3.7>ruby setup.rb
D:/dev/downloads/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_directories': undefined method `path' for Gem:Module (NoMethodError)
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from_installed_gems'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in `initialize'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:841:in `new'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searcher'
        from <internal:prelude>:10:in `synchronize'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins'
        from D:/dev/downloads/rubygems-1.3.7/lib/rubygems.rb:1139:in `<top (required)>'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from setup.rb:24:in `<main>'



----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 23:27

Message:
We need to fix the backtrace though, as it's the same thing that's preventing me from testing easily against 1.9.2

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 18:06

Message:
So don't do that.

% ~/.multiruby/install/1.9.2-p0/bin/ruby -S gem -v
1.3.7


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28715&group_id=126

From noreply at rubyforge.org  Sat Nov 13 18:28:40 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 18:28:40 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28385 ] gems with
	mkrf_conf.rb extensions fail to build when installed into a
	ruby in a directory name that includes spaces
Message-ID: <20101113232840.D5F6818583C9@rubyforge.org>

Bugs item #28385, was opened at 2010-07-14 17:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

Category: `gem install` command
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gems with mkrf_conf.rb extensions fail to build when installed into a ruby in a directory name that includes spaces

Initial Comment:

C:\installs\a space\ruby_1_9_2_installed\bin>gem install rdp-rb-readline
Building native extensions.  This could take a while...
ERROR:  Error installing rdp-rb-readline:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" mkrf_conf.rb

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib"
C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1 for inspection.
Results logged to C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/ext/gem_make.out

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 23:28

Message:
I did fix it, it's done, and it works on unix. nothing more to discuss.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 20:49

Message:
We're not going to fix this. There isn't even an analog over in UNIX land as spaces in paths are invalid for shebang lines, so I can't even run gem, let alone rake.

Workaround: don't use spaces in your paths.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-11-13 19:48

Message:
Fixed in https://github.com/rubygems/rubygems/commit/c9765e122c8e5be5a00911fe59e15251c842a9f8

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:53

Message:
This is still a problem.
How to reproduce: install ruby into a dir with space, install 
spork. Fails (spork installs fine elsewhere).  Rubygems 
should be quoting the path.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 04:12

Message:
What does this have to do with rubygems?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

From noreply at rubyforge.org  Sat Nov 13 18:45:17 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 13 Nov 2010 18:45:17 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28356 ] gem which only shows
	one possible option
Message-ID: <20101113234521.D55481858396@rubyforge.org>

Bugs item #28356, was opened at 2010-07-05 15:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

Category: other
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: James Tucker (raggi)
Summary: gem which only shows one possible option

Initial Comment:
Situation: currently if there is a conflict among gems, i.e. 

gem1/lib/xxx.rb
and
gem2/lib/xxx.rb

gem which will only show one of the possibilities, which seems unexpected to me.

ex:

d:\dev>gem which ruby_to_ruby_c
(checking gem RubyToC-1.0.0.5 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/RubyToC-1.0.0.5/lib/ruby_to_ruby_c.rb

d:\dev> gem uninstall RubyToC
...
d:\dev>gem which ruby_to_ruby_c
(checking gem ruby2c-1.0.0.7 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/ruby2c-1.0.0.7/lib/ruby_to_ruby_c.rb

-r

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-13 23:45

Message:
Fixed in https://github.com/rubygems/rubygems/commit/a1e2051e6fd07eabd5a365bdf0b3d928bb78e191

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-11-13 20:02

Message:
It has a -a option, but it's broken. I'm fixing it now, have failing tests.

I think this should move to using find_files too.

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-11-13 16:19

Message:
people depend on it to show only one?

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-13 13:57

Message:
I understand the confusion, but I think having `gem which` return multiple files at this point would be really confusing/dangerous for folks who have come to depend on it returning only one.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 18:48:12 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sat, 13 Nov 2010 23:48:12 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 6a35f49
	fixed
Message-ID: <4cdf23bc81b46_7270..fdbe31380137b@ci.pivotallabs.com.tmail>

The build has been fixed.

CHANGES
-------
Revision ...6a35f498dfc482f2bacf0d4326fce1b7968eb305 committed by raggi <jftucker at gmail.com> on 2010-11-13 23:44:12

    Merge branch 'master' of github.com:rubygems/rubygems
    * 'master' of github.com:rubygems/rubygems:
    Fix exception error message in Dependency#new
    Add Gem::Dependency#matches_spec? to match directly against a Gem::Specification object.
    Improve performance of Gem::Version#<=> on 1.9 (slightly slower on 1.8)
    Improve performance of Gem::Version#prerelease?
Revision ...a1e2051e6fd07eabd5a365bdf0b3d928bb78e191 committed by raggi <jftucker at gmail.com> on 2010-11-13 23:39:02

    gem which -a now works again

 lib/rubygems/commands/which_command.rb  |   37 +++-----------------
 test/test_gem_commands_which_command.rb |   59 ++++++++++++++++++++++++++++--
 2 files changed, 60 insertions(+), 36 deletions(-)



See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/6a35f498dfc482f2bacf0d4326fce1b7968eb305 for details.

From devnull+rubygems-ci at pivotallabs.com  Sat Nov 13 21:25:36 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sun, 14 Nov 2010 02:25:36 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 925aca6
	failed
Message-ID: <4cdf48a07c2a8_7270..fdbe3138014a0@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...925aca6ce1a5b740bc4a5403740b082bdf73a1a9 committed by raggi <jftucker at gmail.com> on 2010-11-14 02:19:22

    there's no need for these to be lazy

 lib/rubygems/builder.rb |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_31020/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_31020/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_31020/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_31020/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/925aca6ce1a5b740bc4a5403740b082bdf73a1a9 for details.

From luislavena at gmail.com  Sun Nov 14 11:07:43 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 14 Nov 2010 13:07:43 -0300
Subject: [Rubygems-developers] RubyGems master results for 1.8.7 and 1.9.2
	(Windows)
Message-ID: <AANLkTik7rrjVuXxyPi822QMnyAoYVvKzS+R8DM2bf17o@mail.gmail.com>

https://gist.github.com/676284

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From jbarnette at gmail.com  Sun Nov 14 10:31:48 2010
From: jbarnette at gmail.com (John Barnette)
Date: Sun, 14 Nov 2010 09:31:48 -0600
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build
	925aca6 failed
In-Reply-To: <4cdf48a07c2a8_7270..fdbe3138014a0@ci.pivotallabs.com.tmail>
References: <4cdf48a07c2a8_7270..fdbe3138014a0@ci.pivotallabs.com.tmail>
Message-ID: <37D7AC56-485E-4453-976A-5A1D6C328E46@gmail.com>

On Nov 13, 2010, at 20:25, devnull+rubygems-ci at pivotallabs.com wrote:
> The build failed.
> 
> TEST FAILURES AND ERRORS
> -----------------------
> Name: test_self_find_files(TestGem)
> Type: Failure
> Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
> "/tmp/test_rubygems_31020/gemhome/gems/foo-2/lib/foo/discover.rb",
> "/tmp/test_rubygems_31020/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
> "/tmp/test_rubygems_31020/gemhome/gems/foo-1/lib/foo/discover.rb",
> "/tmp/test_rubygems_31020/gemhome/gems/foo-2/lib/foo/discover.rb"].
> 
> ./test/test_gem.rb:303

This is a test that's inconsistent: It started occasionally failing on my machine too. I'll make a ticket and look at it at some point unless somebody else gets to it first. 

From devnull+rubygems-ci at pivotallabs.com  Sun Nov 14 11:18:32 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Sun, 14 Nov 2010 16:18:32 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build c74de93
	fixed
Message-ID: <4ce00bd88e9dd_7270..fdbe313801511@ci.pivotallabs.com.tmail>

The build has been fixed.

CHANGES
-------
Revision ...c74de93aa09638c33f651f925b7f4caf753f0de0 committed by John Barnette <jbarnette at gmail.com> on 2010-11-14 16:13:34

    2011, not 2010.

 lib/rbconfig/datadir.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/c74de93aa09638c33f651f925b7f4caf753f0de0 for details.

From jftucker at gmail.com  Sun Nov 14 18:08:45 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 14 Nov 2010 17:08:45 -0600
Subject: [Rubygems-developers] RubyGems master results for 1.8.7 and
	1.9.2 (Windows)
In-Reply-To: <AANLkTik7rrjVuXxyPi822QMnyAoYVvKzS+R8DM2bf17o@mail.gmail.com>
References: <AANLkTik7rrjVuXxyPi822QMnyAoYVvKzS+R8DM2bf17o@mail.gmail.com>
Message-ID: <8494F315-EEAE-4B4C-9EA4-6400B9FF2E7B@gmail.com>

I can't get to this gist.

There is an intermittent fail on test_self_find_files right now.

On 14 Nov 2010, at 10:07, Luis Lavena wrote:

> https://gist.github.com/676284
> 
> -- 
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exup?ry
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From jftucker at gmail.com  Sun Nov 14 18:13:02 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 14 Nov 2010 17:13:02 -0600
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build
	925aca6 failed
In-Reply-To: <37D7AC56-485E-4453-976A-5A1D6C328E46@gmail.com>
References: <4cdf48a07c2a8_7270..fdbe3138014a0@ci.pivotallabs.com.tmail>
	<37D7AC56-485E-4453-976A-5A1D6C328E46@gmail.com>
Message-ID: <3B574B41-6D18-4224-94E7-FBF3D5E566A7@gmail.com>


On 14 Nov 2010, at 09:31, John Barnette wrote:

> On Nov 13, 2010, at 20:25, devnull+rubygems-ci at pivotallabs.com wrote:
>> The build failed.
>> 
>> TEST FAILURES AND ERRORS
>> -----------------------
>> Name: test_self_find_files(TestGem)
>> Type: Failure
>> Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
>> "/tmp/test_rubygems_31020/gemhome/gems/foo-2/lib/foo/discover.rb",
>> "/tmp/test_rubygems_31020/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
>> "/tmp/test_rubygems_31020/gemhome/gems/foo-1/lib/foo/discover.rb",
>> "/tmp/test_rubygems_31020/gemhome/gems/foo-2/lib/foo/discover.rb"].
>> 
>> ./test/test_gem.rb:303
> 
> This is a test that's inconsistent: It started occasionally failing on my machine too. I'll make a ticket and look at it at some point unless somebody else gets to it first. 

It's already there, and assigned to Evan, see #28717 [1]

Lets turn off plugin loading in rubygems.rb and then revert the find_files optimisations.

We do need to run through the test suite and make sure that it always cleans up installed gems and the load path. I think the helpers should take blocks with ensures, or record to test-local state and cleanup in teardown.

The source of the problem is that foo-1 is in the $LOAD_PATH in the failing cases, and not in the passing cases. I tried to fix this another way, but was partly misunderstanding the problem.

[1] http://rubyforge.org/tracker/?func=detail&aid=28717&group_id=126&atid=575

From luislavena at gmail.com  Sun Nov 14 19:10:34 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 14 Nov 2010 21:10:34 -0300
Subject: [Rubygems-developers] RubyGems master results for 1.8.7 and
	1.9.2 (Windows)
In-Reply-To: <8494F315-EEAE-4B4C-9EA4-6400B9FF2E7B@gmail.com>
References: <AANLkTik7rrjVuXxyPi822QMnyAoYVvKzS+R8DM2bf17o@mail.gmail.com>
	<8494F315-EEAE-4B4C-9EA4-6400B9FF2E7B@gmail.com>
Message-ID: <AANLkTi=YgN0-hZxvrZ7z7R72v1Xs_yrSZVPQayXsi-50@mail.gmail.com>

On Sun, Nov 14, 2010 at 8:08 PM, James Tucker <jftucker at gmail.com> wrote:
> I can't get to this gist.
>

GitHub is down.

> There is an intermittent fail on test_self_find_files right now.
>

There were 0 failures or errors under 1.8.7 while 1.9.2 didn't actually work.

Guess that gem_prelude is interfering with our test.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From jftucker at gmail.com  Sun Nov 14 22:24:20 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 14 Nov 2010 21:24:20 -0600
Subject: [Rubygems-developers] RubyGems master results for 1.8.7 and
	1.9.2 (Windows)
In-Reply-To: <AANLkTi=YgN0-hZxvrZ7z7R72v1Xs_yrSZVPQayXsi-50@mail.gmail.com>
References: <AANLkTik7rrjVuXxyPi822QMnyAoYVvKzS+R8DM2bf17o@mail.gmail.com>
	<8494F315-EEAE-4B4C-9EA4-6400B9FF2E7B@gmail.com>
	<AANLkTi=YgN0-hZxvrZ7z7R72v1Xs_yrSZVPQayXsi-50@mail.gmail.com>
Message-ID: <6483329C-B2B0-4467-89CF-15B7DF12BD61@gmail.com>


On 14 Nov 2010, at 18:10, Luis Lavena wrote:

> On Sun, Nov 14, 2010 at 8:08 PM, James Tucker <jftucker at gmail.com> wrote:
>> I can't get to this gist.
>> 
> 
> GitHub is down.
> 
>> There is an intermittent fail on test_self_find_files right now.
>> 
> 
> There were 0 failures or errors under 1.8.7 while 1.9.2 didn't actually work.
> 
> Guess that gem_prelude is interfering with our test.

Yes, that's a problem for me too. I need to look into it in more detail. Evan - we probably need to patch something in Quickgem for this, but I'm not certain, I haven't examined yet.

> -- 
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exup?ry
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From noreply at rubyforge.org  Sun Nov 14 23:33:21 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 14 Nov 2010 23:33:21 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Patches-28720 ] don't warn about
	no rubyforge_project set during `gem build`
Message-ID: <20101115043321.2D7001858356@rubyforge.org>

Patches item #28720, was opened at 2010-11-14 23:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=577&aid=28720&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Josh Nichols (techpickles)
Assigned to: Nobody (None)
Summary: don't warn about no rubyforge_project set during `gem build`

Initial Comment:
Because we publish to rubygems.org now, it's probably not necessary to warn about a missing `rubyforge_project` when building a gem.

Took a stab at removing this check here: https://github.com/technicalpickles/rubygems/tree/dont-validate-rubyforge-project

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=577&aid=28720&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Mon Nov 15 09:25:01 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Mon, 15 Nov 2010 14:25:01 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 540b956
	failed
Message-ID: <4ce142bd52c98_7270..fdbe3138016e@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...540b9568b3c7db56f191c3600483d9c4b1903c40 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 14:23:29

    Formatting.

 lib/rubygems/version.rb |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_29146/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_29146/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_29146/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_29146/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/540b9568b3c7db56f191c3600483d9c4b1903c40 for details.

From devnull+rubygems-ci at pivotallabs.com  Mon Nov 15 09:45:38 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Mon, 15 Nov 2010 14:45:38 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 3477362
	failed
Message-ID: <4ce14792d4969_7270..fdbe313801720@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...34773624a672c29d252ad0ee2902d2f75747580e committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 14:42:03

    Formatting.

 lib/rubygems/dependency.rb |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)
Revision ...306a975861f0c25ad3421b81ffd9698072228d36 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 14:38:56

    Simplify comparisons in Gem::Dependency.

 lib/rubygems/dependency.rb |   22 +++++-----------------
 1 files changed, 5 insertions(+), 17 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_2448/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_2448/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_2448/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_2448/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/34773624a672c29d252ad0ee2902d2f75747580e for details.

From devnull+rubygems-ci at pivotallabs.com  Mon Nov 15 10:16:17 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Mon, 15 Nov 2010 15:16:17 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 57ce085
	failed
Message-ID: <4ce14ec169187_7270..fdbe31380188@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...57ce085060f95f44a84170386aedff80c2526130 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 15:13:45

    Treat 1.0.a10 like 1.0.a.10 for sorting, etc. Fixes #27903. Hat tip to
    David Chelimsky.

 lib/rubygems/version.rb  |   11 +++++++----
 test/test_gem_version.rb |    1 +
 2 files changed, 8 insertions(+), 4 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_10426/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_10426/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_10426/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_10426/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/57ce085060f95f44a84170386aedff80c2526130 for details.

From devnull+rubygems-ci at pivotallabs.com  Mon Nov 15 15:07:40 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Mon, 15 Nov 2010 20:07:40 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 55db7a4
	fixed
Message-ID: <4ce1930ccb2d2_7270..fdbe313801988@ci.pivotallabs.com.tmail>

The build has been fixed.

CHANGES
-------
Revision ...55db7a400f504d87403898736920d443ef751366 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 19:56:10

    Silence and check for rbconfig/datadir deprecation warning in tests.

 test/test_config.rb |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)
Revision ...40b18063def7931cca2113c5551be3a9c5b22c67 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 19:43:30

    Make all tests inherit from RubyGemTestCase.

 test/test_gem_package_task.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Revision ...2799f27e6febf5df71626fdd9758ccc7c3d4a7c1 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 17:52:17

    Add --host to `gem push`. Fixes #28485. [Erik Hollensbe]
    This makes it much easier to push gems to private gem hosts. Fixed a
    few of the `gem push` messages to be less misleading with nonstandard
    hosts, and extracted all mentions of our API host into Gem.host.

 lib/rubygems.rb                         |   14 ++++++++++++
 lib/rubygems/commands/push_command.rb   |   15 +++++++++++-
 lib/rubygems/gemcutter_utilities.rb     |    4 +-
 test/test_gem_commands_owner_command.rb |   12 +++++-----
 test/test_gem_commands_push_command.rb  |   34 ++++++++++++++++++++++++------
 test/test_gem_gemcutter_utilities.rb    |    2 +-
 6 files changed, 63 insertions(+), 18 deletions(-)



See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/55db7a400f504d87403898736920d443ef751366 for details.

From devnull+rubygems-ci at pivotallabs.com  Mon Nov 15 15:23:17 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Mon, 15 Nov 2010 20:23:17 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 7265d8f
	failed
Message-ID: <4ce196b56854d_7270..fdbe31380203d@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...7265d8f6636f48e761607fdff86faa92825c1df2 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 20:21:20

    Formatting.

 lib/rubygems/version.rb  |    2 +-
 test/test_gem_version.rb |   14 +++++++-------
 2 files changed, 8 insertions(+), 8 deletions(-)
Revision ...965cf64e5ea2e33ebcaa12bed8e5de4c329f4fd4 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 20:16:40

    Don't warn about missing rubyforge_project. Fixes #28720 [Josh Nichols]

 lib/rubygems/specification.rb  |    2 +-
 test/test_gem_specification.rb |   15 ---------------
 2 files changed, 1 insertions(+), 16 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_25729/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_25729/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_25729/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_25729/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/7265d8f6636f48e761607fdff86faa92825c1df2 for details.

From noreply at rubyforge.org  Mon Nov 15 17:44:36 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 15 Nov 2010 17:44:36 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28714 ] RF admins
Message-ID: <20101115224436.181541858346@rubyforge.org>

Bugs item #28714, was opened at 2010-11-13 05:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28714&group_id=126

>Category: other
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: John Barnette (jbarnette)
Assigned to: Eric Hodel (drbrain)
Summary: RF admins

Initial Comment:
Please add Evan and me as admins on the RubyForge project.

----------------------------------------------------------------------

>Comment By: Eric Hodel (drbrain)
Date: 2010-11-15 14:44

Message:
Done!

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28714&group_id=126

From noreply at rubyforge.org  Mon Nov 15 20:52:35 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 15 Nov 2010 20:52:35 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28723 ] `uninitialized
	constant Hoe::Deps::URI` when running `rake test`
Message-ID: <20101116015236.0BA24185839E@rubyforge.org>

Bugs item #28723, was opened at 2010-11-15 20:52
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28723&group_id=126

Category: other
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Josh Nichols (techpickles)
Assigned to: Nobody (None)
Summary: `uninitialized constant Hoe::Deps::URI` when running `rake test`

Initial Comment:
I've noticed this a few times when running tests on master:

$ rake test --trace
(in /Users/technicalpickles/code/vendor/rubygems)
rake aborted!
uninitialized constant Hoe::Deps::URI
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2503:in `const_missing'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe/deps.rb:17
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:243:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:243:in `load_plugins'
/Users/technicalpickles/.rvm/rubies/ruby-1.8.7-p249/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `map'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `each'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `map'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `load_plugins'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:288:in `spec'
/Users/technicalpickles/code/vendor/rubygems/Rakefile:12
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2383:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2017:in `load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2000:in `run'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/bin/rake:31
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/bin/rake:19:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/bin/rake:19


For reference, this is ruby 1.8.7, with the relevant gems being hoe 2.5.0, rake 0.8.7, minitest 2.0.0.

I'm able to work around this by using `rake test -ruri`.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28723&group_id=126

From drbrain at segment7.net  Mon Nov 15 20:59:11 2010
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 15 Nov 2010 17:59:11 -0800
Subject: [Rubygems-developers] RubyGems install plugins
Message-ID: <B3FC0A03-1AE8-44FA-9BD5-3981B2C28F11@segment7.net>

I think we need at least the following hooks:

1) Before install, after download, "pre-install".  I'm not sure what this would be used for.  The hook should be able to abort the install.

2) After files have been written and extensions have been built but before executable stubs have been written or specification is written, "post-build".  This would be used for test tasks.  The hook should be able to abort the install, cleaning up the unpacked files and built extensions.

3) After executable stubs and specification has been written, "post-install".  This could be used for documentation generation.  Gem::DocManager should be rewritten to use this hook.  The hook should not be able to abort the install.

For each hook both the installer and the gemspec from the .gem file should be provided to the callback.

From noreply at rubyforge.org  Tue Nov 16 00:32:36 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 00:32:36 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28723 ] `uninitialized
	constant Hoe::Deps::URI` when running `rake test`
Message-ID: <20101116053236.7C09E1858387@rubyforge.org>

Bugs item #28723, was opened at 2010-11-16 01:52
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28723&group_id=126

Category: other
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Josh Nichols (techpickles)
Assigned to: Nobody (None)
Summary: `uninitialized constant Hoe::Deps::URI` when running `rake test`

Initial Comment:
I've noticed this a few times when running tests on master:

$ rake test --trace
(in /Users/technicalpickles/code/vendor/rubygems)
rake aborted!
uninitialized constant Hoe::Deps::URI
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2503:in `const_missing'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe/deps.rb:17
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:243:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:243:in `load_plugins'
/Users/technicalpickles/.rvm/rubies/ruby-1.8.7-p249/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `map'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `each'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `map'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `load_plugins'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:288:in `spec'
/Users/technicalpickles/code/vendor/rubygems/Rakefile:12
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2383:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2017:in `load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2000:in `run'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/bin/rake:31
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/bin/rake:19:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/bin/rake:19


For reference, this is ruby 1.8.7, with the relevant gems being hoe 2.5.0, rake 0.8.7, minitest 2.0.0.

I'm able to work around this by using `rake test -ruri`.

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-16 05:32

Message:
This is fixed in the latest Hoe.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28723&group_id=126

From noreply at rubyforge.org  Tue Nov 16 00:32:52 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 00:32:52 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28723 ] `uninitialized
	constant Hoe::Deps::URI` when running `rake test`
Message-ID: <20101116053252.2DCC21858387@rubyforge.org>

Bugs item #28723, was opened at 2010-11-16 01:52
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28723&group_id=126

Category: other
Group: v1.3.x
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Josh Nichols (techpickles)
Assigned to: Nobody (None)
Summary: `uninitialized constant Hoe::Deps::URI` when running `rake test`

Initial Comment:
I've noticed this a few times when running tests on master:

$ rake test --trace
(in /Users/technicalpickles/code/vendor/rubygems)
rake aborted!
uninitialized constant Hoe::Deps::URI
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2503:in `const_missing'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe/deps.rb:17
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:243:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:243:in `load_plugins'
/Users/technicalpickles/.rvm/rubies/ruby-1.8.7-p249/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `map'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `each'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `map'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `load_plugins'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:288:in `spec'
/Users/technicalpickles/code/vendor/rubygems/Rakefile:12
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2383:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2017:in `load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2000:in `run'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/bin/rake:31
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/bin/rake:19:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/bin/rake:19


For reference, this is ruby 1.8.7, with the relevant gems being hoe 2.5.0, rake 0.8.7, minitest 2.0.0.

I'm able to work around this by using `rake test -ruri`.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-11-16 05:32

Message:
This is fixed in the latest Hoe.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28723&group_id=126

From noreply at rubyforge.org  Tue Nov 16 00:41:25 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 00:41:25 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Patches-28724 ] add "WARNING: no
	license specified" when performing "gem build"
Message-ID: <20101116054126.0300B1858387@rubyforge.org>

Patches item #28724, was opened at 2010-11-16 00:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=577&aid=28724&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Josh Nichols (techpickles)
Assigned to: Nobody (None)
Summary: add "WARNING:  no license specified" when performing "gem build"

Initial Comment:
Having licenses are pretty sweet. We should warn about a gem not specifying one at build time :)

I've taken a stab at implementing this over yonder: https://github.com/technicalpickles/rubygems/tree/validate-license

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=577&aid=28724&group_id=126

From noreply at rubyforge.org  Tue Nov 16 00:45:47 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 00:45:47 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28723 ] `uninitialized
	constant Hoe::Deps::URI` when running `rake test`
Message-ID: <20101116054547.5B5821858387@rubyforge.org>

Bugs item #28723, was opened at 2010-11-15 20:52
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28723&group_id=126

Category: other
Group: v1.3.x
Status: Closed
Resolution: Out of Date
Priority: 3
Submitted By: Josh Nichols (techpickles)
Assigned to: Nobody (None)
Summary: `uninitialized constant Hoe::Deps::URI` when running `rake test`

Initial Comment:
I've noticed this a few times when running tests on master:

$ rake test --trace
(in /Users/technicalpickles/code/vendor/rubygems)
rake aborted!
uninitialized constant Hoe::Deps::URI
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2503:in `const_missing'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe/deps.rb:17
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:243:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:243:in `load_plugins'
/Users/technicalpickles/.rvm/rubies/ruby-1.8.7-p249/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `map'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `each'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `map'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:238:in `load_plugins'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/hoe-2.5.0/lib/hoe.rb:288:in `spec'
/Users/technicalpickles/code/vendor/rubygems/Rakefile:12
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2383:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2383:in `raw_load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2017:in `load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2016:in `load_rakefile'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2000:in `run'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/gems/rake-0.8.7/bin/rake:31
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/bin/rake:19:in `load'
/Users/technicalpickles/.rvm/gems/ruby-1.8.7-p249/bin/rake:19


For reference, this is ruby 1.8.7, with the relevant gems being hoe 2.5.0, rake 0.8.7, minitest 2.0.0.

I'm able to work around this by using `rake test -ruri`.

----------------------------------------------------------------------

>Comment By: Josh Nichols (techpickles)
Date: 2010-11-16 00:45

Message:
To follow up, hoe 2.7.0 works fine. Not sure if there's any way to either force the 
use of a recent enough hoe, or warn about an old version, but that'd be pretty 
nice.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-11-16 00:32

Message:
This is fixed in the latest Hoe.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28723&group_id=126

From luislavena at gmail.com  Tue Nov 16 08:03:20 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 16 Nov 2010 10:03:20 -0300
Subject: [Rubygems-developers] master and 1.9 results
Message-ID: <AANLkTi=nwvE9ab6ybKFE0z0eJ8wg3MWz7wG=M2v5j8ZL@mail.gmail.com>

Hello,

master against 1.8.7:
https://gist.github.com/701759

1.9 branch against 1.9.2:
https://gist.github.com/701803

Will post results of trunk (1.9.3) in a few minutes, need to update my
compilation.

Cheers,
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From luislavena at gmail.com  Tue Nov 16 09:16:29 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 16 Nov 2010 11:16:29 -0300
Subject: [Rubygems-developers] master and 1.9 results
In-Reply-To: <AANLkTi=nwvE9ab6ybKFE0z0eJ8wg3MWz7wG=M2v5j8ZL@mail.gmail.com>
References: <AANLkTi=nwvE9ab6ybKFE0z0eJ8wg3MWz7wG=M2v5j8ZL@mail.gmail.com>
Message-ID: <AANLkTik9YEFNStNnLWxj1A1vGKw1cY4aU9Ftj0urbhd3@mail.gmail.com>

On Tue, Nov 16, 2010 at 10:03 AM, Luis Lavena <luislavena at gmail.com> wrote:
>
> Will post results of trunk (1.9.3) in a few minutes, need to update my
> compilation.
>

ruby-trunk results against 1.9 branch:
https://gist.github.com/701863
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From jon.forums at gmail.com  Tue Nov 16 10:41:46 2010
From: jon.forums at gmail.com (Jon)
Date: Tue, 16 Nov 2010 10:41:46 -0500
Subject: [Rubygems-developers] RubyGems install plugins
In-Reply-To: <B3FC0A03-1AE8-44FA-9BD5-3981B2C28F11@segment7.net>
References: <B3FC0A03-1AE8-44FA-9BD5-3981B2C28F11@segment7.net>
Message-ID: <20101116104146.2847a0f5.jon.forums@gmail.com>

> 1) Before install, after download, "pre-install".  I'm not sure what this would be used for.  The hook should be able to abort the install.

FYI, as part of RubyInstaller's DevKit (MSYS+MinGW convenience build toolkit for Windows users) we use the pre-install hook [1] to temporarily inject toolchain artifacts into PATH and other ENV vars so as to limit their scope to just building the native extension.

Once the pre-install hook is installed via an operating_system.rb, a user can typically do a "gem install rdiscount --platform=ruby" and things just work.

The pre-install hook has worked great so far to allow MRI Window's users to use native extensions that don't have binary gems, and I'm in the process of testing my updates with JRuby's recent C-extension capabilities.  DevKit support for 64-bit and Rubinius is also being investigated which will also use RubyGems pre-install hook.

Jon


[1] https://github.com/oneclick/rubyinstaller/blob/dk32-451/resources/devkit/dk.rb.erb#L64-80

From jon.forums at gmail.com  Tue Nov 16 11:09:15 2010
From: jon.forums at gmail.com (Jon)
Date: Tue, 16 Nov 2010 11:09:15 -0500
Subject: [Rubygems-developers] RubyGems install plugins
In-Reply-To: <B3FC0A03-1AE8-44FA-9BD5-3981B2C28F11@segment7.net>
References: <B3FC0A03-1AE8-44FA-9BD5-3981B2C28F11@segment7.net>
Message-ID: <20101116110915.78becf2c.jon.forums@gmail.com>

> For each hook both the installer and the gemspec from the .gem file should be provided to the callback.

Would the gemspec need to be provided to the callback if https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L55 still exists in the updated codebase?

From noreply at rubyforge.org  Tue Nov 16 11:49:09 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 11:49:09 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27588 ] Activating a
	dependency raises error even though a satisfactory version is
	already activated.
Message-ID: <20101116164909.70D9918583BF@rubyforge.org>

Bugs item #27588, was opened at 2009-12-18 01:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126

Category: #gem and #require methods
>Group: v1.4.x
Status: Open
Resolution: Out of Date
Priority: 3
Submitted By: Daniel Parker (dcparker)
Assigned to: Ryan Davis (zenspider)
Summary: Activating a dependency raises error even though a satisfactory version is already activated.

Initial Comment:
I have loaded a gem "A" that loaded version 0.9.13 of gem "B", and then continued to load gem "C" that needed version "~> 0.9.12" of gem "B". Under normal conditions, version 0.9.13 should suit just fine if I'm looking for "~> 0.9.12".

But in this case, since:
  (1) version 0.9.13 is *already loaded*, and
  (2) I have since changed my Gem path in such a way that 0.9.13 is not able to be found in the new Gem path,
 -> it fails and raises an error saying that it can't activate.

This happens because in rubygems.rb, line 268:

unless matches.any? { |spec| spec.version == existing_spec.version } then

This should look at the existing spec and test whether it passes the version-requirements. However, the way it is doing it depends on the already-loaded spec to be able to be found again in the most recent search. This fails if the Gem paths have changed and the already-loaded spec is a version that is no longer able to be found in the new Gem path.

This proposed change to this single line fixes the problem:

rubygems.rb at 268
- unless matches.any? { |spec| spec.version == existing_spec.version } then
+ unless gem.version_requirements.satisfied_by?(existing_spec.version) then


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 16:59

Message:
Please respond to Eric's question so I can write a failing test.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-02-06 22:02

Message:
Do you have a set of gems that can reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126

From noreply at rubyforge.org  Tue Nov 16 11:49:11 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 11:49:11 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27588 ] Activating a
	dependency raises error even though a satisfactory version is
	already activated.
Message-ID: <20101116164911.6475718583C2@rubyforge.org>

Bugs item #27588, was opened at 2009-12-18 01:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126

Category: #gem and #require methods
Group: v1.4.x
Status: Open
Resolution: Out of Date
Priority: 3
Submitted By: Daniel Parker (dcparker)
Assigned to: Ryan Davis (zenspider)
Summary: Activating a dependency raises error even though a satisfactory version is already activated.

Initial Comment:
I have loaded a gem "A" that loaded version 0.9.13 of gem "B", and then continued to load gem "C" that needed version "~> 0.9.12" of gem "B". Under normal conditions, version 0.9.13 should suit just fine if I'm looking for "~> 0.9.12".

But in this case, since:
  (1) version 0.9.13 is *already loaded*, and
  (2) I have since changed my Gem path in such a way that 0.9.13 is not able to be found in the new Gem path,
 -> it fails and raises an error saying that it can't activate.

This happens because in rubygems.rb, line 268:

unless matches.any? { |spec| spec.version == existing_spec.version } then

This should look at the existing spec and test whether it passes the version-requirements. However, the way it is doing it depends on the already-loaded spec to be able to be found again in the most recent search. This fails if the Gem paths have changed and the already-loaded spec is a version that is no longer able to be found in the new Gem path.

This proposed change to this single line fixes the problem:

rubygems.rb at 268
- unless matches.any? { |spec| spec.version == existing_spec.version } then
+ unless gem.version_requirements.satisfied_by?(existing_spec.version) then


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 16:59

Message:
Please respond to Eric's question so I can write a failing test.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-02-06 22:02

Message:
Do you have a set of gems that can reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27588&group_id=126

From noreply at rubyforge.org  Tue Nov 16 11:49:48 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 11:49:48 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27975 ] "gemspec is valid"
	has different meaning locally versus at submit time.
Message-ID: <20101116164948.C582A18583BC@rubyforge.org>

Bugs item #27975, was opened at 2010-03-16 09:49
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126

Category: None
>Group: v1.3.x
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nick Quaranto (qrush)
>Summary: "gemspec is valid" has different meaning locally versus at submit time.

Initial Comment:
Currently the gemspec validity check doesn't check for a valid url (if there is one), however gemcutter does, so there's some surprisingness when your gemspec "is valid" but then later "is no longer valid" when you go to submit it.

suggestion: have the validity check check for valid url to avoid this surprisingness.

Thanks.
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27975&group_id=126

From noreply at rubyforge.org  Tue Nov 16 15:43:27 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 15:43:27 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28726 ] gem install
	--user-install as root adds cached .gem file outside of HOME
Message-ID: <20101116204327.8C5D218583C6@rubyforge.org>

Bugs item #28726, was opened at 2010-11-16 12:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28726&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Evans (jeremyevans)
Assigned to: Nobody (None)
Summary: gem install --user-install as root adds cached .gem file outside of HOME

Initial Comment:
I think the problem is at https://github.com/rubygems/rubygems/blob/master/lib/rubygems/remote_fetcher.rb#L80

Basically, in RemoteFetcher#download, it's checking whether the install_dir (Gem.dir by default) is writable, and if so, it uses that dir.  However, if the user is using the --user-install option, even if the user is root, it should not be writing outside of HOME/.gem.  Basically, if the --user-install option is given, it should always download to HOME/.gem.  This may require an API change.

This affects building OpenBSD ports for some gems, since the --user-install option is used (in combination with a fake HOME).  Usually, building is done as a regular user and is fine.  However, if the builder is root, rubygems adds the .gem files to the /usr/local/lib/ruby directory when the gem is installed to HOME/.gem.  Then when the package builder goes to install the package, the cached .gem file already exists and the package install fails.

This isn't a critical bug, as it can be trivially worked around by specifying GEM_HOME=$HOME/.gem in the environment when using gem install --user-install (which the OpenBSD ports system now does).

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28726&group_id=126

From drbrain at segment7.net  Tue Nov 16 16:27:01 2010
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 16 Nov 2010 13:27:01 -0800
Subject: [Rubygems-developers] RubyGems install plugins
In-Reply-To: <20101116110915.78becf2c.jon.forums@gmail.com>
References: <B3FC0A03-1AE8-44FA-9BD5-3981B2C28F11@segment7.net>
	<20101116110915.78becf2c.jon.forums@gmail.com>
Message-ID: <B183D76C-55DF-4EDD-A605-097BF1DF9F78@segment7.net>

On Nov 16, 2010, at 08:09, Jon wrote:

>> For each hook both the installer and the gemspec from the .gem file should be provided to the callback.
> 
> Would the gemspec need to be provided to the callback if https://github.com/rubygems/rubygems/blob/master/lib/rubygems/installer.rb#L55 still exists in the updated codebase?

Good point!

In that case, we should be sure spec is non-nil before the hook fires.


From jbarnette at gmail.com  Tue Nov 16 18:38:18 2010
From: jbarnette at gmail.com (John Barnette)
Date: Tue, 16 Nov 2010 15:38:18 -0800
Subject: [Rubygems-developers] The Deal
Message-ID: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>

All,

We had a RubyGems pow-wow at RubyConf. Along with a bunch of other good stuff, Evan and I will be actively maintaining RubyGems when Eric is focused on other things. Drunk on our newly-usurped power, we have a few notes for the future:

We're going to be releasing RubyGems much more regularly (and frequently). Some of this will depend on velocity, but we're shooting for 4-6 week cycles on point releases. The major version number may also begin to rapidly climb, but that depends on what we end up doing with version number vs. specification version vs. API version. Expect a bunch more talk about this.

To start this new era of magical prosperity and productivity, we're going to release 1.4.0 as soon as possible. We'll be creating a 1.4 branch in the next hour or so, and I'd like to have 1.4.0.pre.1 out in the next few days. We'll keep rolling prereleases off of the 1.4 branch until we're happy with stability. If you have stuff that desperately needs to be in 1.4.0, merge it to both the 1.4 branch and to master. Keep in mind there will be another release shortly, so it's not going to be a long wait for stuff that doesn't get in.

A word on Git: From now on, don't land broken code on master. If tests are breaking in master, don't land shit until they pass (Evan's working on the find_files test now). If you're working on bigger stuff, do it in feature branches.

We've created a rubygems-prereleases mailing list for folks from a lot of the larger hosting companies, as well as projects like Bundler that use RubyGems heavily. Drop me an email if you want on it, but keep in mind that we're not going to let it turn into another rubygems-developers: This is for getting more consistent prerelease feedback from the folks who get bit most severely by RubyGems releases.

Engine Yard (specifically Nic Williams) have offered to work with us on a serious CI grid for RubyGems, potentially covering 1.8.6, 1.8.7, 1.9.1, 1.9.2, mri-head, Rubinius, and JRuby on Linux, Mac OS X, and Windows. I'm talking about this with him later today, and I'll have more details soon. I hope this will take some stress off of Chad, since he's wanted to do a ton of this and hasn't had the time or support to do so.

I lost the coin flip and had to write this, but I expect Evan will chime in with anything I forgot or messed up. And, of course, Eric may swoop in at any time and cut our heads off.


~ j.

From luislavena at gmail.com  Tue Nov 16 19:11:25 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 16 Nov 2010 21:11:25 -0300
Subject: [Rubygems-developers] The Deal
In-Reply-To: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
References: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
Message-ID: <AANLkTikSMJbdxQOL0mDUjYK0tNqYUqqOc3iBTmFWSA08@mail.gmail.com>

On Tue, Nov 16, 2010 at 8:38 PM, John Barnette <jbarnette at gmail.com> wrote:
> All,
>
> We had a RubyGems pow-wow at RubyConf. Along with a bunch of other good stuff, Evan and I will be actively maintaining RubyGems when Eric is focused on other things. Drunk on our newly-usurped power, we have a few notes for the future:
>
> [...]

Thank you John for providing this not so brief but richful amount of
information.

I think integrate a proper progress information (re: Progress Bar pull
request) is important to hit on 1.4

More and more gems like java ones which bundle .jars or ones for
Windows with dlls and binaries are showing up on rubygems, and the
size of the gems are neither advertised on rubygems.org or during the
gem download.

Will email about my feature branch and proposal later this week.

Thank you.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From devnull+rubygems-ci at pivotallabs.com  Tue Nov 16 20:44:01 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Wed, 17 Nov 2010 01:44:01 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 9081b4c
	fixed
Message-ID: <4ce33361aba6_7270..fdbe31380216d@ci.pivotallabs.com.tmail>

The build has been fixed.

CHANGES
-------
Revision ...9081b4c5ee95b8910c79ecd02e0457bae929d288 committed by John Barnette <jbarnette at gmail.com> on 2010-11-17 01:40:44

    Land a few 1.9 fixes.
Revision ...1f628c7315c95f9dab062bcde697db3124492587 committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 19:52:42

    Fix shadowed local var.

 test/gemutilities.rb |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
Revision ...1ebe9f9fe4752d6ad6ecb0f9d5117d97632c150d committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 19:44:43

    Pass --disable-gems when invoking tests.

 Rakefile             |    2 ++
 test/gemutilities.rb |    2 +-
 2 files changed, 3 insertions(+), 1 deletions(-)
Revision ...54148343997461b668231e0e382e70f56742118f committed by John Barnette <jbarnette at gmail.com> on 2010-11-15 19:44:24

    Remove unnecessary 'require "rubygems"' in custom_require.

 lib/rubygems/custom_require.rb |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)
Revision ...95df4e4e53ac5d79afb058ba9ad1ac2ec35b39c7 committed by John Barnette <jbarnette at gmail.com> on 2010-11-16 00:35:17

    Add an additional bump test.

 test/test_gem_version.rb |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)



See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/9081b4c5ee95b8910c79ecd02e0457bae929d288 for details.

From jbarnette at gmail.com  Tue Nov 16 20:44:27 2010
From: jbarnette at gmail.com (John Barnette)
Date: Tue, 16 Nov 2010 17:44:27 -0800
Subject: [Rubygems-developers] 1.4 Branch
Message-ID: <CC9094DF-9948-4B46-8B63-C620CDF0AD97@gmail.com>

The 1.4 branch is pushed. It's currently identical to master. Any bugfixes or reeeeally necessary improvements from now 'til release need to be merged to both branches. Evan and I will be watching the repo and FaceTime trolling people who mess it up.


~ j.


From thewoolleyman at gmail.com  Tue Nov 16 20:56:00 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 16 Nov 2010 18:56:00 -0700
Subject: [Rubygems-developers] The Deal
In-Reply-To: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
References: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
Message-ID: <AANLkTim3usQ8mqRay4E3DmfyBEeVHdqJT2UgmG+8zJbc@mail.gmail.com>

On Tue, Nov 16, 2010 at 4:38 PM, John Barnette <jbarnette at gmail.com> wrote:
> Engine Yard (specifically Nic Williams) have offered to work with us on a serious CI grid for RubyGems, potentially covering 1.8.6, 1.8.7, 1.9.1, 1.9.2, mri-head, Rubinius, and JRuby on Linux, Mac OS X, and Windows. I'm talking about this with him later today, and I'll have more details soon. I hope this will take some stress off of Chad, since he's wanted to do a ton of this and hasn't had the time or support to do so.

True, and great news.  We need to get something going sooner than
later on this.  Please keep me in the loop, both to help as I can, and
so I can get ideas/inspiration for my own work in this area.

-- Chad

From ryand-ruby at zenspider.com  Tue Nov 16 23:02:52 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Tue, 16 Nov 2010 20:02:52 -0800
Subject: [Rubygems-developers] The Deal
In-Reply-To: <AANLkTikSMJbdxQOL0mDUjYK0tNqYUqqOc3iBTmFWSA08@mail.gmail.com>
References: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
	<AANLkTikSMJbdxQOL0mDUjYK0tNqYUqqOc3iBTmFWSA08@mail.gmail.com>
Message-ID: <EBCD2B07-8CE9-4662-A1C2-28676B62CAA8@zenspider.com>


On Nov 16, 2010, at 16:11 , Luis Lavena wrote:

> More and more gems like java ones which bundle .jars or ones for
> Windows with dlls and binaries are showing up on rubygems, and the
> size of the gems are neither advertised on rubygems.org or during the
> gem download.

I think we should enter a ticket to show the size on rubygems.org. That's a great idea too.


From noreply at rubyforge.org  Tue Nov 16 23:04:15 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 16 Nov 2010 23:04:15 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Feature Requests-28728 ] Please
	show the size of a gem on it's summary page
Message-ID: <20101117040415.6257D185835A@rubyforge.org>

Feature Requests item #28728, was opened at 2010-11-16 20:04
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=578&aid=28728&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ryan Davis (zenspider)
Assigned to: Nick Quaranto (qrush)
Summary: Please show the size of a gem on it's summary page

Initial Comment:
Per discussion on the rubygems-developer mailing list.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=578&aid=28728&group_id=126

From luislavena at gmail.com  Wed Nov 17 07:44:22 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 17 Nov 2010 09:44:22 -0300
Subject: [Rubygems-developers] The Deal
In-Reply-To: <EBCD2B07-8CE9-4662-A1C2-28676B62CAA8@zenspider.com>
References: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
	<AANLkTikSMJbdxQOL0mDUjYK0tNqYUqqOc3iBTmFWSA08@mail.gmail.com>
	<EBCD2B07-8CE9-4662-A1C2-28676B62CAA8@zenspider.com>
Message-ID: <AANLkTinztGXWAVhygogb2Or98CDpUQ+5N-iAw9_sOHxh@mail.gmail.com>

On Wed, Nov 17, 2010 at 1:02 AM, Ryan Davis <ryand-ruby at zenspider.com> wrote:
>
> On Nov 16, 2010, at 16:11 , Luis Lavena wrote:
>
>> More and more gems like java ones which bundle .jars or ones for
>> Windows with dlls and binaries are showing up on rubygems, and the
>> size of the gems are neither advertised on rubygems.org or during the
>> gem download.
>
> I think we should enter a ticket to show the size on rubygems.org. That's a great idea too.
>

https://github.com/rubygems/gemcutter/issues/issue/241

Will work on the pull request sent by Ryan Melton.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From nick at quaran.to  Wed Nov 17 12:19:32 2010
From: nick at quaran.to (Nick Quaranto)
Date: Wed, 17 Nov 2010 12:19:32 -0500
Subject: [Rubygems-developers] the autotest scandal
Message-ID: <AANLkTi=JFG8kphVZXrYO_ZMXyq857=5qz7VdzC4QoYFj@mail.gmail.com>

So, I was around last night but mostly feeling sick/disgusting thanks
to a post-rubyconf sinus infection. For those unaware, Ryan started a
discussion about the autotest gem ownership. I've made this tender
thread public (wasn't aware it was private in the first place)

http://help.rubygems.org/discussions/problems/406-zentest-vs-autotest-zentest-without-autotest

Clearly we need a few things here:

1) EULA as soon as possible that respects authors' intentions and the
original licenses they were posted under. This isn't the first "you
posted something like my gem name" we've had, and won't be the last.
2) A solid policy and process for resolving squabbles over gem names
like this, be it voting or a general agreement among the maintainers
*IN PUBLIC*. Luckily, grosser seems to be quite agreeable with what
was proposed in that thread, it could have very easily not been that
way.

If this project isn't interested in respecting the OSS licenses we
publish code under, I'm ready to step down. Let's work this out, for
my sanity and for everyone else's too.

-Nick

From jbarnette at gmail.com  Wed Nov 17 13:01:58 2010
From: jbarnette at gmail.com (John Barnette)
Date: Wed, 17 Nov 2010 10:01:58 -0800
Subject: [Rubygems-developers] the autotest scandal
In-Reply-To: <AANLkTi=JFG8kphVZXrYO_ZMXyq857=5qz7VdzC4QoYFj@mail.gmail.com>
References: <AANLkTi=JFG8kphVZXrYO_ZMXyq857=5qz7VdzC4QoYFj@mail.gmail.com>
Message-ID: <C0675249-D5EB-460A-BA53-7756AD0CA605@gmail.com>

On Nov 17, 2010, at 9:19 AM, Nick Quaranto wrote:
> 1) EULA as soon as possible that respects authors' intentions and the
> original licenses they were posted under. This isn't the first "you
> posted something like my gem name" we've had, and won't be the last.

Totally agree. I've started a discussion for this and looped in a bunch of Ruby Central:

http://help.rubygems.org/discussions/problems/411-rubygemsorg-toseula

> 2) A solid policy and process for resolving squabbles over gem names
> like this, be it voting or a general agreement among the maintainers
> *IN PUBLIC*. Luckily, grosser seems to be quite agreeable with what
> was proposed in that thread, it could have very easily not been that
> way.

Also agree. I'd really like to see an arbitration board as part of the TOS/EULA: See my comments in that discussion, based on suggestions raggi made a while ago.

> If this project isn't interested in respecting the OSS licenses we
> publish code under, I'm ready to step down. Let's work this out, for
> my sanity and for everyone else's too.

Slow your roll, player: Internet hyperbole is hyperbolic. This was ultimately a social issue, not a license issue, and I'm very glad it turned out the way it did. We'll get the currently ad-hoc nature of conflict resolution sorted as quickly as possible.


~ j.


From devnull+rubygems-ci at pivotallabs.com  Thu Nov 18 06:56:03 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Thu, 18 Nov 2010 11:56:03 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 71899b0
	failed
Message-ID: <4ce51453db2fb_7270..fdbe3138022de@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...71899b080a4f464e5e16ec7fd89a26334fe15b7b committed by John Barnette <jbarnette at gmail.com> on 2010-11-18 11:53:07

    Add some appropriate requires.

 lib/rubygems/installer.rb |    1 +
 lib/rubygems/security.rb  |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_17579/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_17579/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_17579/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_17579/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/71899b080a4f464e5e16ec7fd89a26334fe15b7b for details.

From drbrain at segment7.net  Thu Nov 18 17:22:26 2010
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 18 Nov 2010 14:22:26 -0800
Subject: [Rubygems-developers] The Deal
In-Reply-To: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
References: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
Message-ID: <AC423B30-5731-4787-B9BA-5115AD39BE71@segment7.net>

On Nov 16, 2010, at 15:38, John Barnette wrote:
> Engine Yard (specifically Nic Williams) have offered to work with us on a serious CI grid for RubyGems, potentially covering 1.8.6, 1.8.7, 1.9.1, 1.9.2, mri-head, Rubinius, and JRuby on Linux, Mac OS X, and Windows. I'm talking about this with him later today, and I'll have more details soon.

Is somebody going to be doing 1.8.6 maintenance?

I, personally, want to drop 1.8.6 for 1.8.7 and >= 1.9.1.  1.8.7 provides some backports from 1.9 that reduce the amount of alternate codepaths required.

From devnull+rubygems-ci at pivotallabs.com  Thu Nov 18 18:28:34 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Thu, 18 Nov 2010 23:28:34 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 596e8af
	failed
Message-ID: <4ce5b6a24be8d_7270..fdbe313802364@ci.pivotallabs.com.tmail>

The build failed.

CHANGES
-------
Revision ...596e8af6f41e15261e725dd452d718b7575bd056 committed by John Barnette <jbarnette at gmail.com> on 2010-11-18 23:25:41

    More requires.

 lib/rubygems/package/tar_input.rb |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)



TEST FAILURES AND ERRORS
-----------------------
Name: test_self_find_files(TestGem)
Type: Failure
Message: Expected ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_4834/gemhome/gems/foo-2/lib/foo/discover.rb",
 "/tmp/test_rubygems_4834/gemhome/gems/foo-1/lib/foo/discover.rb"], not ["/home/pivotal/.cruise/projects/RubyGemsGitHub/work/test/foo/discover.rb",
 "/tmp/test_rubygems_4834/gemhome/gems/foo-1/lib/foo/discover.rb",
 "/tmp/test_rubygems_4834/gemhome/gems/foo-2/lib/foo/discover.rb"].

./test/test_gem.rb:303




See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/596e8af6f41e15261e725dd452d718b7575bd056 for details.

From charley.baker at gmail.com  Thu Nov 18 18:46:48 2010
From: charley.baker at gmail.com (Charley Baker)
Date: Thu, 18 Nov 2010 16:46:48 -0700
Subject: [Rubygems-developers] The Deal
In-Reply-To: <AC423B30-5731-4787-B9BA-5115AD39BE71@segment7.net>
References: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
	<AC423B30-5731-4787-B9BA-5115AD39BE71@segment7.net>
Message-ID: <AANLkTimXQomv3BFcuL2m9mKoNcwd_+zGD+dNW=TE+v=a@mail.gmail.com>

Honestly this is a general question for the Ruby community. I'd be
interested if we have any stats on current usage. My guess is that
this will slant towards high adoption of 1.8.6 for Windows users
specifically as some guides mention still recommend this approach. The
new Ruby Installer may not have the presence yet that the old one
click installer had and there is a large installed base there. Luis,
feel free to jump in and correct me if that doesn't hold true.

-c

On Thu, Nov 18, 2010 at 3:22 PM, Eric Hodel <drbrain at segment7.net> wrote:
> On Nov 16, 2010, at 15:38, John Barnette wrote:
>> Engine Yard (specifically Nic Williams) have offered to work with us on a serious CI grid for RubyGems, potentially covering 1.8.6, 1.8.7, 1.9.1, 1.9.2, mri-head, Rubinius, and JRuby on Linux, Mac OS X, and Windows. I'm talking about this with him later today, and I'll have more details soon.
>
> Is somebody going to be doing 1.8.6 maintenance?
>
> I, personally, want to drop 1.8.6 for 1.8.7 and >= 1.9.1. ?1.8.7 provides some backports from 1.9 that reduce the amount of alternate codepaths required.
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>

From thewoolleyman at gmail.com  Thu Nov 18 19:38:22 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 18 Nov 2010 17:38:22 -0700
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build
 596e8af failed
In-Reply-To: <4ce5b6a24be8d_7270..fdbe313802364@ci.pivotallabs.com.tmail>
References: <4ce5b6a24be8d_7270..fdbe313802364@ci.pivotallabs.com.tmail>
Message-ID: <AANLkTikxmGjRFmxuiX6RZZH-e2cyr-h2hPHXQ2__AT39@mail.gmail.com>

On Thu, Nov 18, 2010 at 4:28 PM,  <devnull+rubygems-ci at pivotallabs.com> wrote:
> The build failed.

Links in CI emails are now fixed, machine hostname had changed:

http://cibuilder.pivotallabs.com:3333/

From noreply at rubyforge.org  Fri Nov 19 05:11:00 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 19 Nov 2010 05:11:00 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27946 ] gem install hangs
	indefinitely on a NAT-ed machine
Message-ID: <20101119101100.64BFF18583BB@rubyforge.org>

Bugs item #27946, was opened at 2010-03-09 12:59
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27946&group_id=126

Category: `gem install` command
Group: None
Status: Closed
Resolution: None
Priority: 3
Submitted By: Bret Weinraub (bretweinraub)
Assigned to: Nobody (None)
Summary: gem install hangs indefinitely on a NAT-ed machine

Initial Comment:
As described in this thread from ruby forum:

http://www.ruby-forum.com/topic/204146



----------------------------------------------------------------------

Comment By: Andrea Cuneo (kaildio)
Date: 2010-11-19 11:11

Message:
I've experienced the same problem using 'sudo gem install' but 'sudo su' + 'gem install ...' actually works.

----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 02:04

Message:
no response. closing. reopen if you answer raggi's q's.

----------------------------------------------------------------------

Comment By: Ben Corneau (bencorneau)
Date: 2010-11-11 05:42

Message:
This just happened to me.  I'm running the bitnami ubuntu redmine virtual machine on a VMWare server.

This is my first tango with ruby so could all be related to me being a ruby noob.

Running 'gem install activeresource' would hang indefinitly.

using wget to pull the gem down and then installing locally worked.

My Steps:
1. go to http://rubygems.org/, search for 'activeresource', and copy the link
2. run wget http://rubygems.org/downloads/activeresource-3.0.1.gem
4. run sudo /opt/bitnami/ruby/bin/gem install ./activeresource-3.0.1.gem --local

This worked.  (actually there were several other dependencies that I had to wget first, but once I had all the dependencies it worked)

Hope this helps,
Ben

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-19 15:38

Message:
I'm going to have to close this up unless I get more info to be able to replicate it locally.

----------------------------------------------------------------------

Comment By: Bradly Feeley (bradly)
Date: 2010-03-16 00:18

Message:
I've started seeing this today on an ec2 instance running Ubuntu.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-03-11 11:45

Message:
It seems to not be "NAT'd machines", being that every developer behind a router / on wireless is generally NAT'd.

That being said, the multiple layers of NAT can introduce more problems.

We do need to get to the bottom of this issue, however, it very much seems that this is a problem on a lower layer than our app layer.

It's possible that read(2) is causing some kind of blocking issue in some connection teardown / nat mapping release. On that note, it's worth mentioning that a lot (but far from all) of the complaints are linux in a VM on win32.

My first question, given the seemingly repeatable failure caused by using NAT rather than bridged mode, is what class of NAT is actually being used, is it symmetric / asymmetric, full / partial cone, etc?

Also, are you running any ipv6?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27946&group_id=126

From luislavena at gmail.com  Fri Nov 19 05:31:04 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 19 Nov 2010 07:31:04 -0300
Subject: [Rubygems-developers] The Deal
In-Reply-To: <AANLkTimXQomv3BFcuL2m9mKoNcwd_+zGD+dNW=TE+v=a@mail.gmail.com>
References: <F3F85C56-5C10-4773-88B2-1BE97885380D@gmail.com>
	<AC423B30-5731-4787-B9BA-5115AD39BE71@segment7.net>
	<AANLkTimXQomv3BFcuL2m9mKoNcwd_+zGD+dNW=TE+v=a@mail.gmail.com>
Message-ID: <AANLkTimf9=yPcZ329et53+yBp-GizCVePtD1fdjuQYQt@mail.gmail.com>

On Thu, Nov 18, 2010 at 8:46 PM, Charley Baker <charley.baker at gmail.com> wrote:
> Honestly this is a general question for the Ruby community. I'd be
> interested if we have any stats on current usage. My guess is that
> this will slant towards high adoption of 1.8.6 for Windows users
> specifically as some guides mention still recommend this approach. The
> new Ruby Installer may not have the presence yet that the old one
> click installer had and there is a large installed base there. Luis,
> feel free to jump in and correct me if that doesn't hold true.
>

Yes, there is still a huge Ruby 1.8.6 installed base, not just
Windows, but server side.

I think that these system will not upgrade to newer installations of
RubyGems because these systems are locked to these specific versions
of Ruby (already working systems)

Neither they will upgrade to Rails 3 for example, as 1.8.6 has been
deprecated for them.

In the case of RubyInstaller, we provided 1.8.6 installations to ease
the match of version and functionality of these scenarios, but we were
considering dropping it's support moving forward and keep 1.8.7 for
1.8.x and 1.9.2 for future releases.

The only thing that needs to be solved for dropping 1.8.6 support is
ensure "gem update --system" will not try to install rubygems-update
on those systems.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From noreply at rubyforge.org  Mon Nov 22 12:02:15 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Nov 2010 12:02:15 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28742 ] Manual states gemrc
	is looked up in home directory only whereas /etc/gemrc is
	also consulted
Message-ID: <20101122170215.80F5D1858364@rubyforge.org>

Bugs item #28742, was opened at 2010-11-22 17:02
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28742&group_id=126

Category: documentation
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Rich Meyers (richmeyers)
Assigned to: Nobody (None)
Summary: Manual states gemrc is looked up in home directory only whereas /etc/gemrc is also consulted

Initial Comment:
Documentation here: http://docs.rubygems.org/read/chapter/11 states:

gem looks for a configuration file .gemrc in your home directory, although you can specify another file on the command-line if you wish (with the ?config-file modifier). Only one configuration file will be processed: the rightmost one on the command-line, or the default $HOME/.gemrc, or none at all.

In actuality, configuration may be taken from /etc/gemrc if it exists.

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.7 (2009-12-24 patchlevel 248) [amd64-freebsd8]
  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/local/bin/ruby18
  - EXECUTABLE DIRECTORY: /usr/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - amd64-freebsd-8
  - GEM PATHS:
     - /usr/local/lib/ruby/gems/1.8
     - /home/rm/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://gems.rubyforge.org


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28742&group_id=126

From noreply at rubyforge.org  Mon Nov 22 12:55:15 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Nov 2010 12:55:15 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28703 ] Update not possible
	if user folder contains umlaut
Message-ID: <20101122175515.6E265185834E@rubyforge.org>

Bugs item #28703, was opened at 2010-11-09 10:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28703&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Bugger Off (bugmenot2)
Assigned to: Luis Lavena (luislavena)
Summary: Update not possible if user folder contains umlaut

Initial Comment:
Hello,

I'm from Germany and in the German language there are umlauts, the letters ?, ? and ?. My name contains an umlaut, and therefore my user folder und C:\Users\ (I'm using Win 7) contains one too. Since renaming the user folder is impossible, there is now way to use gem, since it tells me that there is an "Errno:ENOENT". I have already tested and this problem does not occur if i use another user account without an umlaut. Thought you should know this so you could fix it


C:\Users\Tim J?ger>gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.2 (2010-08-18 patchlevel 0) [i
  - INSTALLATION DIRECTORY: E:/Ruby/lib/ruby/gems/1.
  - RUBY EXECUTABLE: E:/Ruby/bin/ruby.exe
  - EXECUTABLE DIRECTORY: E:/Ruby/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mingw32
  - GEM PATHS:
     - E:/Ruby/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

C:\Users\Tim J?ger>gem update --system
Updating RubyGems
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - C:/Users/Tim J?ger

----------------------------------------------------------------------

>Comment By: John Barnette (jbarnette)
Date: 2010-11-22 09:55

Message:
The original poster used Bugmenot to sign in, and is almost certainly not getting any of our questions. Closing.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-09 10:45

Message:
Hello,

Any version of Ruby prior 1.9.2 do not manage properly unicode/accented characters in folders.

Have you tried a folder without spaces? IN your case, you have umlaut and space.

Please try setting GEM_HOME and GEM_PATH variables to a path without spaces but still containing the umlaut symbol and let us know.

Thank you.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28703&group_id=126

From noreply at rubyforge.org  Mon Nov 22 12:56:05 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Nov 2010 12:56:05 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28717 ] test_self_find_files
	is intermittent
Message-ID: <20101122175605.8DC6F185834E@rubyforge.org>

Bugs item #28717, was opened at 2010-11-13 14:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28717&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: James Tucker (raggi)
Assigned to: Evan Phoenix (evan)
Summary: test_self_find_files is intermittent

Initial Comment:
ruby -Ilib:test test/test_gem.rb --seed 48969 -v

The issue is that some earlier test is leaving foo-1 on the load path. The issue is actually a fuzz for another issue that items on the load path should appear first followed by gems in version order.

----------------------------------------------------------------------

>Comment By: John Barnette (jbarnette)
Date: 2010-11-22 09:56

Message:
KILL IT WITH FIRE EVAN

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28717&group_id=126

From devnull+rubygems-ci at pivotallabs.com  Mon Nov 22 15:15:52 2010
From: devnull+rubygems-ci at pivotallabs.com (devnull+rubygems-ci at pivotallabs.com)
Date: Mon, 22 Nov 2010 20:15:52 +0000
Subject: [Rubygems-developers] [CruiseControl] RubyGemsGitHub build 81cd691
	fixed
Message-ID: <4ceacf7857c86_7270..fdbe3138024c0@ci.pivotallabs.com.tmail>

The build has been fixed.

CHANGES
-------
Revision ...81cd69180a067d638d10cd88099015e3408a5ec0 committed by Evan Phoenix <ephoenix at engineyard.com> on 2010-11-22 20:11:24

    Save and restore $LOAD_PATH between tests

 test/gemutilities.rb |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)
Revision ...83d597826fc0209eef4a960eb5df635a1dcce371 committed by Evan Phoenix <ephoenix at engineyard.com> on 2010-11-22 20:05:25

    Fix random spec failure
    Too many things used a gem named foo, which seem to conflict within the
    tests sometimes, so I used a different name here. Also, removing the
    sort call gives things back in the same order as before, putting it at
    the mercy of the ordering within @gemspec

 lib/rubygems.rb      |    2 +-
 test/test_gem.rb     |   10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)



See http://ci.pivotallabs.com:3333/builds/RubyGemsGitHub/81cd69180a067d638d10cd88099015e3408a5ec0 for details.

From noreply at rubyforge.org  Mon Nov 22 15:18:01 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Nov 2010 15:18:01 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28717 ] test_self_find_files
	is intermittent
Message-ID: <20101122201801.697CB1858361@rubyforge.org>

Bugs item #28717, was opened at 2010-11-13 22:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28717&group_id=126

Category: other
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: James Tucker (raggi)
Assigned to: Evan Phoenix (evan)
Summary: test_self_find_files is intermittent

Initial Comment:
ruby -Ilib:test test/test_gem.rb --seed 48969 -v

The issue is that some earlier test is leaving foo-1 on the load path. The issue is actually a fuzz for another issue that items on the load path should appear first followed by gems in version order.

----------------------------------------------------------------------

>Comment By: Evan Phoenix (evan)
Date: 2010-11-22 20:18

Message:
Fixed in 83d5978!

----------------------------------------------------------------------

Comment By: John Barnette (jbarnette)
Date: 2010-11-22 17:56

Message:
KILL IT WITH FIRE EVAN

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28717&group_id=126

From noreply at rubyforge.org  Mon Nov 22 20:38:59 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Nov 2010 20:38:59 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28744 ] setup.rb fails on
	1.9.2
Message-ID: <20101123013859.718FB185831A@rubyforge.org>

Bugs item #28744, was opened at 2010-11-22 17:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28744&group_id=126

Category: RubyGems installer (setup.rb)
Group: next
Status: Open
Resolution: None
Priority: 3
Submitted By: Erik Hollensbe (erikh)
Assigned to: Nobody (None)
Summary: setup.rb fails on 1.9.2

Initial Comment:
https://gist.github.com/190251852fbe20370543

This is the error as found as late as commit 81cd69180a067d638d10cd88099015e3408a5ec0.

The problem is that rubygems cannibalizes on its own setup_command for setup.rb, which in turn gets required by gem_prelude and this error shows up. Something along these lines will massage it through, but then all gem commands fail once it's installed:

https://gist.github.com/b74973ec7a7418655797

If you dig further you'll find that any attempt for rubygems/custom_require, as provided by prelude, will raise this issue. Overriding it with lib/rubygems/custom_require was something I tried, and didn't get very far. Maybe some of you guys with more domain knowledge can help.

I can provide a full image of my patches (which are not pretty and may incite anger, rage, and politics, as they almost completely eliminate prelude from being useful) if so desired, as once down this rabbit hole there be dragons.

Thanks,

-Erik

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28744&group_id=126

From noreply at rubyforge.org  Tue Nov 23 04:39:11 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Nov 2010 04:39:11 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28746 ] gem install complains
	of frozen filename on 1.8.7-p302
Message-ID: <20101123093911.53A9E1858346@rubyforge.org>

Bugs item #28746, was opened at 2010-11-23 01:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28746&group_id=126

Category: `gem install` command
Group: next
Status: Open
Resolution: None
Priority: 3
Submitted By: Erik Hollensbe (erikh)
Assigned to: Nobody (None)
Summary: gem install complains of frozen filename on 1.8.7-p302

Initial Comment:
This patch solves this issue, although it may not be satisfactory. Best I can tell this is not a gems issue but a side-effect of it using optparse.

https://gist.github.com/b50b26a6e5cc2124ffee

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28746&group_id=126

From noreply at rubyforge.org  Tue Nov 23 04:39:36 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Nov 2010 04:39:36 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28746 ] gem install complains
	of frozen filename on 1.8.7-p302
Message-ID: <20101123093936.DF7D818582E2@rubyforge.org>

Bugs item #28746, was opened at 2010-11-23 01:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28746&group_id=126

Category: `gem install` command
Group: next
Status: Open
Resolution: None
Priority: 3
Submitted By: Erik Hollensbe (erikh)
Assigned to: Nobody (None)
Summary: gem install complains of frozen filename on 1.8.7-p302

Initial Comment:
This patch solves this issue, although it may not be satisfactory. Best I can tell this is not a gems issue but a side-effect of it using optparse.

https://gist.github.com/b50b26a6e5cc2124ffee

----------------------------------------------------------------------

>Comment By: Erik Hollensbe (erikh)
Date: 2010-11-23 01:39

Message:
gem build... gah! sorry.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28746&group_id=126

From noreply at rubyforge.org  Tue Nov 23 05:02:40 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Nov 2010 05:02:40 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Patches-28747 ] patch for
	Gem::SilentUI and yes/no defaulted methods
Message-ID: <20101123100240.D45451858367@rubyforge.org>

Patches item #28747, was opened at 2010-11-23 02:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=577&aid=28747&group_id=126

Category: other
Group: future
Status: Open
Resolution: None
Priority: 3
Submitted By: Erik Hollensbe (erikh)
Assigned to: Nobody (None)
Summary: patch for Gem::SilentUI and yes/no defaulted methods

Initial Comment:
Attached is a patch to have proper support for Gem::SilentUI. Currently, this class does not inherit from any of the other UI classes and has a basic method_missing wrapper. This causes things like bundler to improperly answer questions even if defaults are supplied.

Gem::StreamUI already has support for handling non-tty scenarios, so this patch makes Gem::SilentUI inherit from it with some additional initializer logic to have it call the superclass initializer with handles to /dev/null (nil on windows, but this is untested).

Additionally, as requested by Eric, there are two new methods to specify the defaults to yes/no questions, with the default answer supplied as upper-case: ask_Yes_no and ask_yes_No. These are just shims for ask_yes_no with the optional third argument.

There will be an additional patch to bundler for its complete support of this feature, I will comment here once it's filed so that if accepted, releases can be coordinated.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=577&aid=28747&group_id=126

From noreply at rubyforge.org  Tue Nov 23 14:47:23 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Nov 2010 14:47:23 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-16937 ] downcase gem name:
	can install RedCloth but not redcloth
Message-ID: <20101123194723.59A591858363@rubyforge.org>

Bugs item #16937, was opened at 2008-01-08 16:09
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=16937&group_id=126

Category: `gem install` command
Group: v1.0.x
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Suraj Kurapati (snk)
Assigned to: Eric Hodel (drbrain)
Summary: downcase gem name: can install RedCloth but not redcloth

Initial Comment:
`gem install` should accept lower-case gem names.  I am using Rubygems 1.0.1. 

I couldn't figure out why 'gem install redcloth' kept saying there was no such gem available, but I tried camel case (RedCloth) and it worked.  How is anybody expected to know the correct capitalization of a gem name?

Thanks for your consideration.

----------------------------------------------------------------------

>Comment By: Suraj Kurapati (snk)
Date: 2010-11-23 11:47

Message:
So... is this bug ever going to be fixed?  It's been more
than 2 years since I originally filed it. :-(

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2008-06-02 15:57

Message:
Please do not add comments to a bug that are orthogonal to the topic.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2008-06-02 15:42

Message:
Please do not add comments to a bug that are orthogonal to the topic.

----------------------------------------------------------------------

Comment By: Jason Garber (jgarber)
Date: 2008-04-14 21:12

Message:
Sorry, I cross-posted.  See http://rubyforge.org/tracker/index.php?func=detail&aid=19525&group_id=126&atid=575

----------------------------------------------------------------------

Comment By: Suraj Kurapati (snk)
Date: 2008-04-14 20:24

Message:
Re-opening bug so that our comments are heard.

----------------------------------------------------------------------

Comment By: Jason Garber (jgarber)
Date: 2008-04-14 14:28

Message:
+1

gem install RedCloth (or RubyInline, AsteriskRuby, DeliciousRuby, RedGreen, Ruby4Skype, etc) trips so many people up

At the very least, you could say, "gem redcloth not found.  Did you mean RedCloth? [y]"

----------------------------------------------------------------------

Comment By: Suraj Kurapati (snk)
Date: 2008-02-20 23:18

Message:
I request reconsideration!

This supposed case-sensitivity "feature" is a hindrance to
usability.  All you need to do is add a simple downcase()
call to the user's input... it's not a monumental effort!

Furthermore, this "feature" allows impostors to create bogus
projects with the same name as, say, RedCloth in many
case-sensitive variations.  Fast forward and you get the
same abysmal situation we have with domain squatters today
on the Internet.

Please reconsider!  The user interface should be simple and
*forgiving*!

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2008-02-20 11:42

Message:
Use `gem list` to get the correct capitalization.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=16937&group_id=126

From noreply at rubyforge.org  Tue Nov 23 14:56:27 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Nov 2010 14:56:27 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-16937 ] downcase gem name:
	can install RedCloth but not redcloth
Message-ID: <20101123195627.592091858363@rubyforge.org>

Bugs item #16937, was opened at 2008-01-08 21:09
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=16937&group_id=126

Category: `gem install` command
Group: v1.0.x
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Suraj Kurapati (snk)
Assigned to: Eric Hodel (drbrain)
Summary: downcase gem name: can install RedCloth but not redcloth

Initial Comment:
`gem install` should accept lower-case gem names.  I am using Rubygems 1.0.1. 

I couldn't figure out why 'gem install redcloth' kept saying there was no such gem available, but I tried camel case (RedCloth) and it worked.  How is anybody expected to know the correct capitalization of a gem name?

Thanks for your consideration.

----------------------------------------------------------------------

>Comment By: Luis Lavena (luislavena)
Date: 2010-11-23 16:56

Message:
There has been proposal to suggest gem names, please see this:

http://rubyforge.org/pipermail/rubygems-developers/2010-September/005532.html

Also see this:

http://blog.segment7.net/articles/2010/11/15/how-to-name-gems

Patches are welcome.

Closing this as is not a bug. RedCloth is not the same as redcloth or anything like that.


----------------------------------------------------------------------

Comment By: Suraj Kurapati (snk)
Date: 2010-11-23 16:47

Message:
So... is this bug ever going to be fixed?  It's been more
than 2 years since I originally filed it. :-(

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2008-06-02 19:57

Message:
Please do not add comments to a bug that are orthogonal to the topic.

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2008-06-02 19:42

Message:
Please do not add comments to a bug that are orthogonal to the topic.

----------------------------------------------------------------------

Comment By: Jason Garber (jgarber)
Date: 2008-04-15 01:12

Message:
Sorry, I cross-posted.  See http://rubyforge.org/tracker/index.php?func=detail&aid=19525&group_id=126&atid=575

----------------------------------------------------------------------

Comment By: Suraj Kurapati (snk)
Date: 2008-04-15 00:24

Message:
Re-opening bug so that our comments are heard.

----------------------------------------------------------------------

Comment By: Jason Garber (jgarber)
Date: 2008-04-14 18:28

Message:
+1

gem install RedCloth (or RubyInline, AsteriskRuby, DeliciousRuby, RedGreen, Ruby4Skype, etc) trips so many people up

At the very least, you could say, "gem redcloth not found.  Did you mean RedCloth? [y]"

----------------------------------------------------------------------

Comment By: Suraj Kurapati (snk)
Date: 2008-02-21 04:18

Message:
I request reconsideration!

This supposed case-sensitivity "feature" is a hindrance to
usability.  All you need to do is add a simple downcase()
call to the user's input... it's not a monumental effort!

Furthermore, this "feature" allows impostors to create bogus
projects with the same name as, say, RedCloth in many
case-sensitive variations.  Fast forward and you get the
same abysmal situation we have with domain squatters today
on the Internet.

Please reconsider!  The user interface should be simple and
*forgiving*!

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2008-02-20 16:42

Message:
Use `gem list` to get the correct capitalization.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=16937&group_id=126

From jftucker at gmail.com  Wed Nov 24 18:19:07 2010
From: jftucker at gmail.com (James Tucker)
Date: Wed, 24 Nov 2010 15:19:07 -0800
Subject: [Rubygems-developers] Rails breakage heads up
Message-ID: <B3533D9B-AE86-4C51-A5D7-2D664E0C132B@gmail.com>

Hi all,

My removal of loading thread breaks rails. I've given them a heads up, and sent them pull requests for the 3.x master, but they'll need to backport.

I'd like to recommend that we delay release of RubyGems 1.4 until they've their point releases out with these fixes to avoid major user support load.

I think it's going to be bad enough having to tell people to upgrade anyway.

Pull request: https://github.com/rails/rails/pull/116

Thanks,

James

From noreply at rubyforge.org  Thu Nov 25 13:32:48 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 25 Nov 2010 13:32:48 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-14943 ] rubygems should use
	the same arch specific subdirs in lib for the native
	extensions as ruby
Message-ID: <20101125183248.1457B18581B2@rubyforge.org>

Bugs item #14943, was opened at 2007-10-22 12:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

Category: RubyGems installer (setup.rb)
Group: v0.9.5
>Status: Open
Resolution: None
Priority: 1
Submitted By: Marcus Rueckert (darix)
Assigned to: Eric Hodel (drbrain)
Summary: rubygems should use the same arch specific subdirs in lib for the native extensions as ruby

Initial Comment:
quoting my my mail to ruby-core [1]
[[[
there is another feature that gem doesnt handle nicely atm:
with the standard ruby directory layout you can share the tree via nfs
for multiple architectures as the native extensions are in an arch
specific path. within an installed gem they are directly inside the
"lib" subdir. i wonder if gem should use the arch specific subdirs below
its "lib" subdir aswell.
]]]

Eric asked me in a follow up to open a ticket here. :)

Looking forward to the fix :)

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12724

----------------------------------------------------------------------

>Comment By: Marcus Rueckert (darix)
Date: 2010-11-25 19:32

Message:
1. i think this ticket is still very valid.
2. i didnt mean that gems should be able to describe native 
libraries.
while it would be nice it is not in the scope of this bug, 
so it should mostlikely be tracked in a different bug. If 
you open it, please CC me. I am sure i can give some tips 
and tricks how we solve it in the linux packaging world to 
achieve better cross distro support.



----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 23:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 23:37

Message:
My experience with package management (Dev-C++, Autopackage, Phusion Passenger) so far is that dependency rules, especially for cross-platform software, can get very complex. I'm not sure whether it's at all possible to cover all cases without a turing-complete dependency specification language. Autopackage's dependency checking mechanism is turing-complete (shell scripts) and it works wonderfully well, though few people understand it because it's so powerful. But maybe it's possible to have a "good enough" system that works for most people, and let developers who need more power write their own thing, kinda like what we did for Phusion Passenger by splitting native dependency checking to passenger-install-*-module.

For DebGem we didn't try to make RubyGems support native dependencies. We just manually maintained a per-gem native dependency list.

I agree with not bothering with C++ compatibility. Most native extensions are written in C anyways. Developers can always write their own thing to handle this. For example the next version of Phusion Passenger will no longer specify extconf.rb in the gem spec; instead it will automatically compile the native extension when it's require()'ed into an Ruby version-, OS- and architecture-specific subdirectory under $HOME.

As for Rubists being pitiful at dependency management: most Rubyists are on OS X which has no proper dependency management, so most people are not only unfamiliar with native dependency management but also wouldn't benefit from it. :) If RubyGems is to support native dependencies it should make it extremely easy for gem writers to specify them correctly.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 19:33

Message:
I mean, whilst GCC versions might be ok for C++, what about say, a lua plugin or a php plugin, etc, etc. Tracking external dependencies and binary level compatibility becomes a nightmare with more VMs / runtimes, combined too with platforms, heh.

Maybe, if we could pull in a more advanced extconf, that allowed arbitrary addition of dependency information, by reasonably formed keys, maybe such as:

dependencies << [:debian, :package, :gcc, gcc_version]
dependencies << [:debian, :package, :lua, lua_version]
etc

Then compute that based on some hash of the total dependency set (merged with rubys). So then you have a ruby dependency hash, from rbconfig (plus expanded info), and a gem dependency hash from install-time expansion data.

I've actually missed something here, which is to tell the dependencies list how to check if those dependencies are still available... Need to store some code for that really, so eval strings (nominally probably calls to Kernel#`)...

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 19:28

Message:
Hongli Lai - agreed completely.

A hash of some larger set of attributes may be most appropriate.

As far as dependencies like C++ are concerned, there's little we can do to be complete in that area. 

I try to encourage a move toward proper dependency management, but rubyists are extremely pitiful at this traditionally.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 19:26

Message:
I support the idea of putting a gem in an arch specific subdir.

I am strongly against this subdir being inside the gems installed path.

1. some platform specific gems pack different *ruby* code in their gemfiles for specific archs
2. some gems do not use the commonly accepted paths, or have multiple lib paths, i wouldn't want selection of the path to become arbitrary



----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 17:27

Message:
I support this change. This would make it possible for multiple Ruby interpreters, possibly on multiple machines with different platforms, to share the same gem directory.

However I don't think Gem::Platform in its current form is adequate. While Gem::Platform is a good enough description of the platform, it isn't a good enough description of Ruby extension binary compatibility, which is what matters more. A few examples:
- OS X Snow Leopard broke the ABI by switching to x86_64 by default, but uname and therefore RUBY_PLATFORM still report i386 as platform.
- Ruby breaks API compatibility even between teeny releases, e.g. RSTRING_PTR vs RSTRING(x)->ptr. The former didn't exist until 1.8.6. On 1.8.7 and later it became required so that the latter doesn't work anymore. It doesn't look like the ABI changes but the Ruby core team doesn't seem to make any ABI guarantees. The switch from 1.8 to 1.9 most definitely breaks some ABI though.

For Phusion Passenger we use the following code to identify Ruby extension binary compatibility: http://pastie.org/786648

But even this doesn't tell us the entire story. For example it doesn't include the C++ ABI version, which can be a problem for Ruby extensions written in C++ like EventMachine. GCC breaks the C++ ABI regularly, sometimes even multiple times within the same minor release. For example GCC 3.1 broke the C++ ABI about 3 times if I recall correctly.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-02-02 05:56

Message:
Luis,

Right, modification to the extension builder would be required as far as I know.

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-31 14:03

Message:
Sorry not to properly introduce my question.

Let's say I build a gem with VC6 (i386-mswin32), the gem platform is x86-mswin32-60

This means, my lib folder will be like this:

lib/my_lib.rb
lib/x86-mswin32-60/my_ext.so

my_lib.rb contains this:

require 'my_ext'

now, I'm in a IRB session:

require 'rubygems'
require 'my_lib'

It is supposed to work out.

But what about this:

require 'rubygems'
require 'my_ext'

Right now, since lib is added to LOAD_PATH on gem activation, there is no problem with that.

With the change, it indicates that:

If a gem contains a platform folder for libdir and the platform matches the current one, it should append that folder into LOAD_PATH.

That is the correct assumption?

I believe changes to Extension Builders bundled in rubygems will be required.


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-27 18:52

Message:
Luis, I'm not sure what you mean by "require of the extension directly". Can you explain?

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-27 18:01

Message:
So this will mean "lib/#{Gem::Platform}" will be added to the $LOAD_PATH if exist, correct?

What happens when users doing the require of the extension directly? it triggers the activation mechanism?

I kind of like this, but maybe I'm missing a drawback that will against us in the long run?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-26 21:24

Message:
For example, if you install a C extension gem called 'foo' on Windows you want it to install as:

C:/ruby/lib/ruby/gems/1.8/gems/foo/lib/i386-msvcr80/foo.so

And Rubygems should add this sitearch directory to its search path?

Is that about the sum of it?

Regards,

Dan

----------------------------------------------------------------------

Comment By: 7rans  (transami)
Date: 2007-11-06 11:27

Message:
After some trial and error with extensions, I
m starting to agree with this. It's more flexible.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

From noreply at rubyforge.org  Thu Nov 25 13:49:24 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 25 Nov 2010 13:49:24 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-14943 ] rubygems should use
	the same arch specific subdirs in lib for the native
	extensions as ruby
Message-ID: <20101125184924.439561779949@rubyforge.org>

Bugs item #14943, was opened at 2007-10-22 07:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

Category: RubyGems installer (setup.rb)
Group: v0.9.5
Status: Open
Resolution: None
Priority: 1
Submitted By: Marcus Rueckert (darix)
Assigned to: Eric Hodel (drbrain)
Summary: rubygems should use the same arch specific subdirs in lib for the native extensions as ruby

Initial Comment:
quoting my my mail to ruby-core [1]
[[[
there is another feature that gem doesnt handle nicely atm:
with the standard ruby directory layout you can share the tree via nfs
for multiple architectures as the native extensions are in an arch
specific path. within an installed gem they are directly inside the
"lib" subdir. i wonder if gem should use the arch specific subdirs below
its "lib" subdir aswell.
]]]

Eric asked me in a follow up to open a ticket here. :)

Looking forward to the fix :)

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12724

----------------------------------------------------------------------

>Comment By: Luis Lavena (luislavena)
Date: 2010-11-25 15:49

Message:
Hello Marcus,

There has been several conversations about the pollution of LOAD_PATH and a proposal of solution by Eric Hodel at ruby-core:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33206

I think making RubyGems add another PATH inside the same gem will be a problem.

Instead, what if the default path where gems are installed contains the platform information?

So Gem.dir and Gem.path uses ~/.gem/ENGINE/VERSION/PLATFORM

Where ENGINE is ruby/jruby
VERSION is 1.8 or 1.9.1
and PLATFORM is the one computed by Gem::Platform.local

That will not solve the coexistence of the same codebase for two different platforms, but at least will avoid having another performance discussion at Ruby-Core

Thoughts?




----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-11-25 15:32

Message:
1. i think this ticket is still very valid.
2. i didnt mean that gems should be able to describe native 
libraries.
while it would be nice it is not in the scope of this bug, 
so it should mostlikely be tracked in a different bug. If 
you open it, please CC me. I am sure i can give some tips 
and tricks how we solve it in the linux packaging world to 
achieve better cross distro support.



----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 19:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 19:37

Message:
My experience with package management (Dev-C++, Autopackage, Phusion Passenger) so far is that dependency rules, especially for cross-platform software, can get very complex. I'm not sure whether it's at all possible to cover all cases without a turing-complete dependency specification language. Autopackage's dependency checking mechanism is turing-complete (shell scripts) and it works wonderfully well, though few people understand it because it's so powerful. But maybe it's possible to have a "good enough" system that works for most people, and let developers who need more power write their own thing, kinda like what we did for Phusion Passenger by splitting native dependency checking to passenger-install-*-module.

For DebGem we didn't try to make RubyGems support native dependencies. We just manually maintained a per-gem native dependency list.

I agree with not bothering with C++ compatibility. Most native extensions are written in C anyways. Developers can always write their own thing to handle this. For example the next version of Phusion Passenger will no longer specify extconf.rb in the gem spec; instead it will automatically compile the native extension when it's require()'ed into an Ruby version-, OS- and architecture-specific subdirectory under $HOME.

As for Rubists being pitiful at dependency management: most Rubyists are on OS X which has no proper dependency management, so most people are not only unfamiliar with native dependency management but also wouldn't benefit from it. :) If RubyGems is to support native dependencies it should make it extremely easy for gem writers to specify them correctly.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 15:33

Message:
I mean, whilst GCC versions might be ok for C++, what about say, a lua plugin or a php plugin, etc, etc. Tracking external dependencies and binary level compatibility becomes a nightmare with more VMs / runtimes, combined too with platforms, heh.

Maybe, if we could pull in a more advanced extconf, that allowed arbitrary addition of dependency information, by reasonably formed keys, maybe such as:

dependencies << [:debian, :package, :gcc, gcc_version]
dependencies << [:debian, :package, :lua, lua_version]
etc

Then compute that based on some hash of the total dependency set (merged with rubys). So then you have a ruby dependency hash, from rbconfig (plus expanded info), and a gem dependency hash from install-time expansion data.

I've actually missed something here, which is to tell the dependencies list how to check if those dependencies are still available... Need to store some code for that really, so eval strings (nominally probably calls to Kernel#`)...

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 15:28

Message:
Hongli Lai - agreed completely.

A hash of some larger set of attributes may be most appropriate.

As far as dependencies like C++ are concerned, there's little we can do to be complete in that area. 

I try to encourage a move toward proper dependency management, but rubyists are extremely pitiful at this traditionally.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 15:26

Message:
I support the idea of putting a gem in an arch specific subdir.

I am strongly against this subdir being inside the gems installed path.

1. some platform specific gems pack different *ruby* code in their gemfiles for specific archs
2. some gems do not use the commonly accepted paths, or have multiple lib paths, i wouldn't want selection of the path to become arbitrary



----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 13:27

Message:
I support this change. This would make it possible for multiple Ruby interpreters, possibly on multiple machines with different platforms, to share the same gem directory.

However I don't think Gem::Platform in its current form is adequate. While Gem::Platform is a good enough description of the platform, it isn't a good enough description of Ruby extension binary compatibility, which is what matters more. A few examples:
- OS X Snow Leopard broke the ABI by switching to x86_64 by default, but uname and therefore RUBY_PLATFORM still report i386 as platform.
- Ruby breaks API compatibility even between teeny releases, e.g. RSTRING_PTR vs RSTRING(x)->ptr. The former didn't exist until 1.8.6. On 1.8.7 and later it became required so that the latter doesn't work anymore. It doesn't look like the ABI changes but the Ruby core team doesn't seem to make any ABI guarantees. The switch from 1.8 to 1.9 most definitely breaks some ABI though.

For Phusion Passenger we use the following code to identify Ruby extension binary compatibility: http://pastie.org/786648

But even this doesn't tell us the entire story. For example it doesn't include the C++ ABI version, which can be a problem for Ruby extensions written in C++ like EventMachine. GCC breaks the C++ ABI regularly, sometimes even multiple times within the same minor release. For example GCC 3.1 broke the C++ ABI about 3 times if I recall correctly.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-02-02 01:56

Message:
Luis,

Right, modification to the extension builder would be required as far as I know.

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-31 10:03

Message:
Sorry not to properly introduce my question.

Let's say I build a gem with VC6 (i386-mswin32), the gem platform is x86-mswin32-60

This means, my lib folder will be like this:

lib/my_lib.rb
lib/x86-mswin32-60/my_ext.so

my_lib.rb contains this:

require 'my_ext'

now, I'm in a IRB session:

require 'rubygems'
require 'my_lib'

It is supposed to work out.

But what about this:

require 'rubygems'
require 'my_ext'

Right now, since lib is added to LOAD_PATH on gem activation, there is no problem with that.

With the change, it indicates that:

If a gem contains a platform folder for libdir and the platform matches the current one, it should append that folder into LOAD_PATH.

That is the correct assumption?

I believe changes to Extension Builders bundled in rubygems will be required.


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-27 14:52

Message:
Luis, I'm not sure what you mean by "require of the extension directly". Can you explain?

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-27 14:01

Message:
So this will mean "lib/#{Gem::Platform}" will be added to the $LOAD_PATH if exist, correct?

What happens when users doing the require of the extension directly? it triggers the activation mechanism?

I kind of like this, but maybe I'm missing a drawback that will against us in the long run?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-26 17:24

Message:
For example, if you install a C extension gem called 'foo' on Windows you want it to install as:

C:/ruby/lib/ruby/gems/1.8/gems/foo/lib/i386-msvcr80/foo.so

And Rubygems should add this sitearch directory to its search path?

Is that about the sum of it?

Regards,

Dan

----------------------------------------------------------------------

Comment By: 7rans  (transami)
Date: 2007-11-06 07:27

Message:
After some trial and error with extensions, I
m starting to agree with this. It's more flexible.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

From noreply at rubyforge.org  Thu Nov 25 14:59:52 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 25 Nov 2010 14:59:52 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-14943 ] rubygems should use
	the same arch specific subdirs in lib for the native
	extensions as ruby
Message-ID: <20101125195952.9F75718582E2@rubyforge.org>

Bugs item #14943, was opened at 2007-10-22 12:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

Category: RubyGems installer (setup.rb)
Group: v0.9.5
Status: Open
Resolution: None
Priority: 1
Submitted By: Marcus Rueckert (darix)
Assigned to: Eric Hodel (drbrain)
Summary: rubygems should use the same arch specific subdirs in lib for the native extensions as ruby

Initial Comment:
quoting my my mail to ruby-core [1]
[[[
there is another feature that gem doesnt handle nicely atm:
with the standard ruby directory layout you can share the tree via nfs
for multiple architectures as the native extensions are in an arch
specific path. within an installed gem they are directly inside the
"lib" subdir. i wonder if gem should use the arch specific subdirs below
its "lib" subdir aswell.
]]]

Eric asked me in a follow up to open a ticket here. :)

Looking forward to the fix :)

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12724

----------------------------------------------------------------------

>Comment By: Marcus Rueckert (darix)
Date: 2010-11-25 20:59

Message:
would be an option. but then you still need 2 search paths:
1. for pure ruby gems
2. one for gems with native portions.

i just want consistent behavior, especially now that 
rubygems is in the core.

although the $(Gem.dir)/gems/foo-1.0/lib/<arch> method had 
the advantage for me that i could share the pure ruby stuff 
between all archs in my packages. but the other way would 
work for me aswell.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-25 19:49

Message:
Hello Marcus,

There has been several conversations about the pollution of LOAD_PATH and a proposal of solution by Eric Hodel at ruby-core:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33206

I think making RubyGems add another PATH inside the same gem will be a problem.

Instead, what if the default path where gems are installed contains the platform information?

So Gem.dir and Gem.path uses ~/.gem/ENGINE/VERSION/PLATFORM

Where ENGINE is ruby/jruby
VERSION is 1.8 or 1.9.1
and PLATFORM is the one computed by Gem::Platform.local

That will not solve the coexistence of the same codebase for two different platforms, but at least will avoid having another performance discussion at Ruby-Core

Thoughts?




----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-11-25 19:32

Message:
1. i think this ticket is still very valid.
2. i didnt mean that gems should be able to describe native 
libraries.
while it would be nice it is not in the scope of this bug, 
so it should mostlikely be tracked in a different bug. If 
you open it, please CC me. I am sure i can give some tips 
and tricks how we solve it in the linux packaging world to 
achieve better cross distro support.



----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 23:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 23:37

Message:
My experience with package management (Dev-C++, Autopackage, Phusion Passenger) so far is that dependency rules, especially for cross-platform software, can get very complex. I'm not sure whether it's at all possible to cover all cases without a turing-complete dependency specification language. Autopackage's dependency checking mechanism is turing-complete (shell scripts) and it works wonderfully well, though few people understand it because it's so powerful. But maybe it's possible to have a "good enough" system that works for most people, and let developers who need more power write their own thing, kinda like what we did for Phusion Passenger by splitting native dependency checking to passenger-install-*-module.

For DebGem we didn't try to make RubyGems support native dependencies. We just manually maintained a per-gem native dependency list.

I agree with not bothering with C++ compatibility. Most native extensions are written in C anyways. Developers can always write their own thing to handle this. For example the next version of Phusion Passenger will no longer specify extconf.rb in the gem spec; instead it will automatically compile the native extension when it's require()'ed into an Ruby version-, OS- and architecture-specific subdirectory under $HOME.

As for Rubists being pitiful at dependency management: most Rubyists are on OS X which has no proper dependency management, so most people are not only unfamiliar with native dependency management but also wouldn't benefit from it. :) If RubyGems is to support native dependencies it should make it extremely easy for gem writers to specify them correctly.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 19:33

Message:
I mean, whilst GCC versions might be ok for C++, what about say, a lua plugin or a php plugin, etc, etc. Tracking external dependencies and binary level compatibility becomes a nightmare with more VMs / runtimes, combined too with platforms, heh.

Maybe, if we could pull in a more advanced extconf, that allowed arbitrary addition of dependency information, by reasonably formed keys, maybe such as:

dependencies << [:debian, :package, :gcc, gcc_version]
dependencies << [:debian, :package, :lua, lua_version]
etc

Then compute that based on some hash of the total dependency set (merged with rubys). So then you have a ruby dependency hash, from rbconfig (plus expanded info), and a gem dependency hash from install-time expansion data.

I've actually missed something here, which is to tell the dependencies list how to check if those dependencies are still available... Need to store some code for that really, so eval strings (nominally probably calls to Kernel#`)...

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 19:28

Message:
Hongli Lai - agreed completely.

A hash of some larger set of attributes may be most appropriate.

As far as dependencies like C++ are concerned, there's little we can do to be complete in that area. 

I try to encourage a move toward proper dependency management, but rubyists are extremely pitiful at this traditionally.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 19:26

Message:
I support the idea of putting a gem in an arch specific subdir.

I am strongly against this subdir being inside the gems installed path.

1. some platform specific gems pack different *ruby* code in their gemfiles for specific archs
2. some gems do not use the commonly accepted paths, or have multiple lib paths, i wouldn't want selection of the path to become arbitrary



----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 17:27

Message:
I support this change. This would make it possible for multiple Ruby interpreters, possibly on multiple machines with different platforms, to share the same gem directory.

However I don't think Gem::Platform in its current form is adequate. While Gem::Platform is a good enough description of the platform, it isn't a good enough description of Ruby extension binary compatibility, which is what matters more. A few examples:
- OS X Snow Leopard broke the ABI by switching to x86_64 by default, but uname and therefore RUBY_PLATFORM still report i386 as platform.
- Ruby breaks API compatibility even between teeny releases, e.g. RSTRING_PTR vs RSTRING(x)->ptr. The former didn't exist until 1.8.6. On 1.8.7 and later it became required so that the latter doesn't work anymore. It doesn't look like the ABI changes but the Ruby core team doesn't seem to make any ABI guarantees. The switch from 1.8 to 1.9 most definitely breaks some ABI though.

For Phusion Passenger we use the following code to identify Ruby extension binary compatibility: http://pastie.org/786648

But even this doesn't tell us the entire story. For example it doesn't include the C++ ABI version, which can be a problem for Ruby extensions written in C++ like EventMachine. GCC breaks the C++ ABI regularly, sometimes even multiple times within the same minor release. For example GCC 3.1 broke the C++ ABI about 3 times if I recall correctly.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-02-02 05:56

Message:
Luis,

Right, modification to the extension builder would be required as far as I know.

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-31 14:03

Message:
Sorry not to properly introduce my question.

Let's say I build a gem with VC6 (i386-mswin32), the gem platform is x86-mswin32-60

This means, my lib folder will be like this:

lib/my_lib.rb
lib/x86-mswin32-60/my_ext.so

my_lib.rb contains this:

require 'my_ext'

now, I'm in a IRB session:

require 'rubygems'
require 'my_lib'

It is supposed to work out.

But what about this:

require 'rubygems'
require 'my_ext'

Right now, since lib is added to LOAD_PATH on gem activation, there is no problem with that.

With the change, it indicates that:

If a gem contains a platform folder for libdir and the platform matches the current one, it should append that folder into LOAD_PATH.

That is the correct assumption?

I believe changes to Extension Builders bundled in rubygems will be required.


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-27 18:52

Message:
Luis, I'm not sure what you mean by "require of the extension directly". Can you explain?

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-27 18:01

Message:
So this will mean "lib/#{Gem::Platform}" will be added to the $LOAD_PATH if exist, correct?

What happens when users doing the require of the extension directly? it triggers the activation mechanism?

I kind of like this, but maybe I'm missing a drawback that will against us in the long run?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-26 21:24

Message:
For example, if you install a C extension gem called 'foo' on Windows you want it to install as:

C:/ruby/lib/ruby/gems/1.8/gems/foo/lib/i386-msvcr80/foo.so

And Rubygems should add this sitearch directory to its search path?

Is that about the sum of it?

Regards,

Dan

----------------------------------------------------------------------

Comment By: 7rans  (transami)
Date: 2007-11-06 11:27

Message:
After some trial and error with extensions, I
m starting to agree with this. It's more flexible.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

From noreply at rubyforge.org  Fri Nov 26 18:25:01 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 26 Nov 2010 18:25:01 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-14943 ] rubygems should use
	the same arch specific subdirs in lib for the native
	extensions as ruby
Message-ID: <20101126232501.E0CA91858356@rubyforge.org>

Bugs item #14943, was opened at 2007-10-22 10:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

Category: RubyGems installer (setup.rb)
Group: v0.9.5
Status: Open
Resolution: None
Priority: 1
Submitted By: Marcus Rueckert (darix)
Assigned to: Eric Hodel (drbrain)
Summary: rubygems should use the same arch specific subdirs in lib for the native extensions as ruby

Initial Comment:
quoting my my mail to ruby-core [1]
[[[
there is another feature that gem doesnt handle nicely atm:
with the standard ruby directory layout you can share the tree via nfs
for multiple architectures as the native extensions are in an arch
specific path. within an installed gem they are directly inside the
"lib" subdir. i wonder if gem should use the arch specific subdirs below
its "lib" subdir aswell.
]]]

Eric asked me in a follow up to open a ticket here. :)

Looking forward to the fix :)

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/12724

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-11-26 23:25

Message:
VERSION should include prefix, suffix and full version.

RubyCores idea that the contents of 1.9.1 are compatible with 1.9.x is a completely invalid assumption. I spoke to Matz about this at RubyConf. He suggested we speak to nobu.

----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-11-25 19:59

Message:
would be an option. but then you still need 2 search paths:
1. for pure ruby gems
2. one for gems with native portions.

i just want consistent behavior, especially now that 
rubygems is in the core.

although the $(Gem.dir)/gems/foo-1.0/lib/<arch> method had 
the advantage for me that i could share the pure ruby stuff 
between all archs in my packages. but the other way would 
work for me aswell.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-11-25 18:49

Message:
Hello Marcus,

There has been several conversations about the pollution of LOAD_PATH and a proposal of solution by Eric Hodel at ruby-core:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33206

I think making RubyGems add another PATH inside the same gem will be a problem.

Instead, what if the default path where gems are installed contains the platform information?

So Gem.dir and Gem.path uses ~/.gem/ENGINE/VERSION/PLATFORM

Where ENGINE is ruby/jruby
VERSION is 1.8 or 1.9.1
and PLATFORM is the one computed by Gem::Platform.local

That will not solve the coexistence of the same codebase for two different platforms, but at least will avoid having another performance discussion at Ruby-Core

Thoughts?




----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-11-25 18:32

Message:
1. i think this ticket is still very valid.
2. i didnt mean that gems should be able to describe native 
libraries.
while it would be nice it is not in the scope of this bug, 
so it should mostlikely be tracked in a different bug. If 
you open it, please CC me. I am sure i can give some tips 
and tricks how we solve it in the linux packaging world to 
achieve better cross distro support.



----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-12 22:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 22:37

Message:
My experience with package management (Dev-C++, Autopackage, Phusion Passenger) so far is that dependency rules, especially for cross-platform software, can get very complex. I'm not sure whether it's at all possible to cover all cases without a turing-complete dependency specification language. Autopackage's dependency checking mechanism is turing-complete (shell scripts) and it works wonderfully well, though few people understand it because it's so powerful. But maybe it's possible to have a "good enough" system that works for most people, and let developers who need more power write their own thing, kinda like what we did for Phusion Passenger by splitting native dependency checking to passenger-install-*-module.

For DebGem we didn't try to make RubyGems support native dependencies. We just manually maintained a per-gem native dependency list.

I agree with not bothering with C++ compatibility. Most native extensions are written in C anyways. Developers can always write their own thing to handle this. For example the next version of Phusion Passenger will no longer specify extconf.rb in the gem spec; instead it will automatically compile the native extension when it's require()'ed into an Ruby version-, OS- and architecture-specific subdirectory under $HOME.

As for Rubists being pitiful at dependency management: most Rubyists are on OS X which has no proper dependency management, so most people are not only unfamiliar with native dependency management but also wouldn't benefit from it. :) If RubyGems is to support native dependencies it should make it extremely easy for gem writers to specify them correctly.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 18:33

Message:
I mean, whilst GCC versions might be ok for C++, what about say, a lua plugin or a php plugin, etc, etc. Tracking external dependencies and binary level compatibility becomes a nightmare with more VMs / runtimes, combined too with platforms, heh.

Maybe, if we could pull in a more advanced extconf, that allowed arbitrary addition of dependency information, by reasonably formed keys, maybe such as:

dependencies << [:debian, :package, :gcc, gcc_version]
dependencies << [:debian, :package, :lua, lua_version]
etc

Then compute that based on some hash of the total dependency set (merged with rubys). So then you have a ruby dependency hash, from rbconfig (plus expanded info), and a gem dependency hash from install-time expansion data.

I've actually missed something here, which is to tell the dependencies list how to check if those dependencies are still available... Need to store some code for that really, so eval strings (nominally probably calls to Kernel#`)...

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 18:28

Message:
Hongli Lai - agreed completely.

A hash of some larger set of attributes may be most appropriate.

As far as dependencies like C++ are concerned, there's little we can do to be complete in that area. 

I try to encourage a move toward proper dependency management, but rubyists are extremely pitiful at this traditionally.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-01-20 18:26

Message:
I support the idea of putting a gem in an arch specific subdir.

I am strongly against this subdir being inside the gems installed path.

1. some platform specific gems pack different *ruby* code in their gemfiles for specific archs
2. some gems do not use the commonly accepted paths, or have multiple lib paths, i wouldn't want selection of the path to become arbitrary



----------------------------------------------------------------------

Comment By: Hongli Lai (hongli)
Date: 2010-01-20 16:27

Message:
I support this change. This would make it possible for multiple Ruby interpreters, possibly on multiple machines with different platforms, to share the same gem directory.

However I don't think Gem::Platform in its current form is adequate. While Gem::Platform is a good enough description of the platform, it isn't a good enough description of Ruby extension binary compatibility, which is what matters more. A few examples:
- OS X Snow Leopard broke the ABI by switching to x86_64 by default, but uname and therefore RUBY_PLATFORM still report i386 as platform.
- Ruby breaks API compatibility even between teeny releases, e.g. RSTRING_PTR vs RSTRING(x)->ptr. The former didn't exist until 1.8.6. On 1.8.7 and later it became required so that the latter doesn't work anymore. It doesn't look like the ABI changes but the Ruby core team doesn't seem to make any ABI guarantees. The switch from 1.8 to 1.9 most definitely breaks some ABI though.

For Phusion Passenger we use the following code to identify Ruby extension binary compatibility: http://pastie.org/786648

But even this doesn't tell us the entire story. For example it doesn't include the C++ ABI version, which can be a problem for Ruby extensions written in C++ like EventMachine. GCC breaks the C++ ABI regularly, sometimes even multiple times within the same minor release. For example GCC 3.1 broke the C++ ABI about 3 times if I recall correctly.

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-02-02 04:56

Message:
Luis,

Right, modification to the extension builder would be required as far as I know.

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-31 13:03

Message:
Sorry not to properly introduce my question.

Let's say I build a gem with VC6 (i386-mswin32), the gem platform is x86-mswin32-60

This means, my lib folder will be like this:

lib/my_lib.rb
lib/x86-mswin32-60/my_ext.so

my_lib.rb contains this:

require 'my_ext'

now, I'm in a IRB session:

require 'rubygems'
require 'my_lib'

It is supposed to work out.

But what about this:

require 'rubygems'
require 'my_ext'

Right now, since lib is added to LOAD_PATH on gem activation, there is no problem with that.

With the change, it indicates that:

If a gem contains a platform folder for libdir and the platform matches the current one, it should append that folder into LOAD_PATH.

That is the correct assumption?

I believe changes to Extension Builders bundled in rubygems will be required.


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-27 17:52

Message:
Luis, I'm not sure what you mean by "require of the extension directly". Can you explain?

Dan

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-01-27 17:01

Message:
So this will mean "lib/#{Gem::Platform}" will be added to the $LOAD_PATH if exist, correct?

What happens when users doing the require of the extension directly? it triggers the activation mechanism?

I kind of like this, but maybe I'm missing a drawback that will against us in the long run?


----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-26 20:24

Message:
For example, if you install a C extension gem called 'foo' on Windows you want it to install as:

C:/ruby/lib/ruby/gems/1.8/gems/foo/lib/i386-msvcr80/foo.so

And Rubygems should add this sitearch directory to its search path?

Is that about the sum of it?

Regards,

Dan

----------------------------------------------------------------------

Comment By: 7rans  (transami)
Date: 2007-11-06 10:27

Message:
After some trial and error with extensions, I
m starting to agree with this. It's more flexible.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=14943&group_id=126

From transfire at gmail.com  Mon Nov 29 14:42:18 2010
From: transfire at gmail.com (Trans)
Date: Mon, 29 Nov 2010 11:42:18 -0800 (PST)
Subject: [Rubygems-developers] Remove RDoc generation
Message-ID: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>

With YARD becoming so popular and working in a more intuitive way
(i.e. live updating of documentation), I see  the automatic RDdoc
generation done by RubyGems as outmoded. At very least I would like to
see it as an option we have to turn ON rather than OFF. Better still
would be to add live rdoc building to the gem server. Though it might
make sense to make the rdoc server a separate tool altogether.

From jftucker at gmail.com  Mon Nov 29 16:17:08 2010
From: jftucker at gmail.com (James Tucker)
Date: Mon, 29 Nov 2010 13:17:08 -0800
Subject: [Rubygems-developers] Remove RDoc generation
In-Reply-To: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>
References: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>
Message-ID: <33E66203-92EC-4A4F-AFE8-2734EF62B448@gmail.com>


On 29 Nov 2010, at 11:42, Trans wrote:

> With YARD becoming so popular and working in a more intuitive way
> (i.e. live updating of documentation), I see  the automatic RDdoc
> generation done by RubyGems as outmoded. At very least I would like to
> see it as an option we have to turn ON rather than OFF. Better still
> would be to add live rdoc building to the gem server. Though it might
> make sense to make the rdoc server a separate tool altogether.

Please build one, then send us a patch.

Not all users prefer YARD at this point in time.

From ryand-ruby at zenspider.com  Mon Nov 29 18:38:20 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Mon, 29 Nov 2010 15:38:20 -0800
Subject: [Rubygems-developers] Remove RDoc generation
In-Reply-To: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>
References: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>
Message-ID: <9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com>


On Nov 29, 2010, at 11:42 , Trans wrote:

> With YARD becoming so popular

You can just stop right there.

yard only has 50k downloads, 2.5k for the last version.

rdoc has 250k downloads, 73k for the last version.



From transfire at gmail.com  Tue Nov 30 05:17:21 2010
From: transfire at gmail.com (Trans)
Date: Tue, 30 Nov 2010 02:17:21 -0800 (PST)
Subject: [Rubygems-developers] Remove RDoc generation
In-Reply-To: <9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com>
References: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>
	<9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com>
Message-ID: <95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com>



On Nov 29, 6:38?pm, Ryan Davis <ryand-r... at zenspider.com> wrote:
> On Nov 29, 2010, at 11:42 , Trans wrote:
>
> > With YARD becoming so popular
>
> You can just stop right there.
>
> yard only has 50k downloads, 2.5k for the last version.
>
> rdoc has 250k downloads, 73k for the last version.

I would think 2,500 users is fairly significant. But that's not the
main point. On demand generation of docs is a better idea.

From thewoolleyman at gmail.com  Tue Nov 30 10:50:00 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 30 Nov 2010 15:50:00 +0000
Subject: [Rubygems-developers] Remove RDoc generation
In-Reply-To: <95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com>
References: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>
	<9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com>
	<95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com>
Message-ID: <AANLkTi=zQBcfZRvpV-T=q0Qi49NEh5GHEA3A=quyXq8K@mail.gmail.com>

On Tue, Nov 30, 2010 at 10:17 AM, Trans <transfire at gmail.com> wrote:
> On Nov 29, 6:38?pm, Ryan Davis <ryand-r... at zenspider.com> wrote:
>> On Nov 29, 2010, at 11:42 , Trans wrote:
>>
>> > With YARD becoming so popular
>>
>> You can just stop right there.
>>
>> yard only has 50k downloads, 2.5k for the last version.
>>
>> rdoc has 250k downloads, 73k for the last version.
>
> I would think 2,500 users is fairly significant. But that's not the
> main point. On demand generation of docs is a better idea.

The significant statistic would be how many people who install a gem
actually USE the autogenerated rdocs.  I personally always turn them
off to speed installation.

I'm +1 on making it default to off, if only to increase the perceived
speed of gem installation in the default case.  If you know enough to
want rdoc, you should know enough to enable autogeneration.

-- Chad

From luislavena at gmail.com  Tue Nov 30 11:00:28 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 30 Nov 2010 13:00:28 -0300
Subject: [Rubygems-developers] Remove RDoc generation
In-Reply-To: <AANLkTi=zQBcfZRvpV-T=q0Qi49NEh5GHEA3A=quyXq8K@mail.gmail.com>
References: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>
	<9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com>
	<95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com>
	<AANLkTi=zQBcfZRvpV-T=q0Qi49NEh5GHEA3A=quyXq8K@mail.gmail.com>
Message-ID: <AANLkTinv7jOfZDktnnq9oCcv3FJR2z44s9aBjfUGQVhT@mail.gmail.com>

On Tue, Nov 30, 2010 at 12:50 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>
> The significant statistic would be how many people who install a gem
> actually USE the autogenerated rdocs. ?I personally always turn them
> off to speed installation.
>
> I'm +1 on making it default to off, if only to increase the perceived
> speed of gem installation in the default case. ?If you know enough to
> want rdoc, you should know enough to enable autogeneration.
>

I turned it off since installing Rails generate sometimes error, also
speed. Pretty much never rely on generated documentation (rubydoc.info
or apidock.com to the rescue)

And when I really need to digg into the code, I most of the time do
gem/bundle open and browse the source code.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From jftucker at gmail.com  Tue Nov 30 13:21:12 2010
From: jftucker at gmail.com (James Tucker)
Date: Tue, 30 Nov 2010 10:21:12 -0800
Subject: [Rubygems-developers] Remove RDoc generation
In-Reply-To: <95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com>
References: <bc7ab2fb-9664-4d02-b61b-faa6691faa75@h17g2000pre.googlegroups.com>
	<9A715088-1DC2-4BD8-B013-C71C2966861C@zenspider.com>
	<95590ec2-6bfd-4253-9c26-fe187416dd9c@z9g2000yqz.googlegroups.com>
Message-ID: <2A905ED8-53BB-4BFB-8B47-BBDCDB3BCA2A@gmail.com>


On 30 Nov 2010, at 02:17, Trans wrote:

> 
> 
> On Nov 29, 6:38 pm, Ryan Davis <ryand-r... at zenspider.com> wrote:
>> On Nov 29, 2010, at 11:42 , Trans wrote:
>> 
>>> With YARD becoming so popular
>> 
>> You can just stop right there.
>> 
>> yard only has 50k downloads, 2.5k for the last version.
>> 
>> rdoc has 250k downloads, 73k for the last version.
> 
> I would think 2,500 users is fairly significant. But that's not the
> main point. On demand generation of docs is a better idea.

Patch please.

From noreply at rubyforge.org  Tue Nov 30 14:22:54 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 30 Nov 2010 14:22:54 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-28759 ] Print message when no
	gems matching your platform are found, or could not be installed
Message-ID: <20101130192255.01159185836C@rubyforge.org>

Bugs item #28759, was opened at 2010-11-30 11:22
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody (None)
Summary: Print message when no gems matching your platform are found, or could not be installed

Initial Comment:
reopening: http://rubyforge.org/tracker/?func=detail&atid=575&aid=21325&group_id=126

Example of the problem today:

$ uname -a
Linux hostname 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

$ sudo gem search -r nokogiri

*** REMOTE GEMS ***

glebm-nokogiri (1.4.2.1)
jwagener-nokogiri (1.4.1)
nokogiri (1.4.4.1, 1.4.4, 1.2.3)
nokogiri-diff (0.1.0)
nokogiri-happymapper (0.3.4)
nokogiri-plist (0.3.1)
nokogiri-pretty (0.1.0)
revo-nokogiri (1.4.1)
rsolr-nokogiri (0.0.0)
rubyjedi-nokogiri_java (1.4.0.20100513161003)
superfeedr-nokogiri (1.4.0.20091116183308)

$ sudo gem install nokogiri --version ">= 1.4.4.1"
ERROR:  could not find gem nokogiri locally or in a repository


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28759&group_id=126

From noreply at rubyforge.org  Tue Nov 30 22:52:24 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 30 Nov 2010 22:52:24 -0500 (EST)
Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is
	sometimes too large.
Message-ID: <20101201035224.B45021858377@rubyforge.org>

Bugs item #27154, was opened at 2009-09-21 22:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126

Category: `gem install` command
Group: None
Status: Closed
Resolution: None
Priority: 3
Submitted By: Ryan Riley (panesofglass)
Assigned to: Nobody (None)
Summary: Computed hash is sometimes too large.

Initial Comment:
The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value:

class C
  def hash
    100000000000000000000
  end
end

[C.new].hash  # => in `hash': bignum too big to convert into 
`long' (RangeError)

REXML has a similar issue. http://redmine.ruby-
lang.org/issues/show/1883 tracks the issue, and MRI will be 
fixing the issue.

Suggested fixes are:

edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659
File: dependency.rb
===================================================================
--- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659  (server)    6/23/2009 1:21 PM
+++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb
@@ -112,7 +112,7 @@
   end
 
   def hash # :nodoc:
-    name.hash + type.hash + version_requirements.hash
+    name.hash ^ type.hash ^ version_requirements.hash
   end
 
 end
===================================================================
edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357
File: specification.rb
===================================================================
--- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357  (server)    6/23/2009 1:24 PM
+++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb
@@ -661,9 +661,8 @@
     private :same_attributes?
 
     def hash # :nodoc:
-      @@attributes.inject(0) { |hash_code, (name, default_value)|
-        n = self.send(name).hash
-        hash_code + n
+      @@attributes.inject(612553) { |hash_code, (name, default_value)|
+        hash_code ^ self.send(name).hash
       }
     end
 
===================================================================

----------------------------------------------------------------------

Comment By: George Mendoza (gsmendoza)
Date: 2010-12-01 11:52

Message:
Hello,

Appreciate if anybody can re-open this ticket. I am also getting the error when I try to install the dmitryv-backup gem via bundle. Please let me know if I need to provide any other information in order to fix this bug. Thanks!

Gemfile:
----------------------------------------
source :rubygems
source "http://gems.github.com"

#...

gem 'dmitryv-backup', '2.4.0', :require => "backup"

#...

----------------------------------------

Running:
----------------------------------------
bundle install --local
/usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash': bignum too big to convert into `long' (RangeError)
  from /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash'
  from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:675:in `hash'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/index.rb:36:in `inject'
  from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `each'
  from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `inject'
  from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:674:in `hash'
  from /usr/lib/ruby/1.8/tsort.rb:204:in `include?'
  from /usr/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child'
  from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from'
  from /usr/lib/ruby/1.8/tsort.rb:209:in `each_strongly_connected_component_from'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `each'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:130:in `tsort_each_child'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `each'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:128:in `tsort_each_child'
  from /usr/lib/ruby/1.8/tsort.rb:203:in `each_strongly_connected_component_from'
  from /usr/lib/ruby/1.8/tsort.rb:182:in `each_strongly_connected_component'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `each'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:124:in `tsort_each_node'
  from /usr/lib/ruby/1.8/tsort.rb:180:in `each_strongly_connected_component'
  from /usr/lib/ruby/1.8/tsort.rb:148:in `tsort_each'
  from /usr/lib/ruby/1.8/tsort.rb:135:in `tsort'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:107:in `sorted'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/spec_set.rb:12:in `each'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:44:in `run'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/installer.rb:8:in `install'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/cli.rb:225:in `install'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `send'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/task.rb:22:in `run'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor.rb:246:in `dispatch'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/lib/bundler/vendor/thor/base.rb:389:in `start'
  from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.7/bin/bundle:13
  from /usr/bin/bundle:19:in `load'
  from /usr/bin/bundle:19
----------------------------------------

Thanks,

George Mendoza
Philippines


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2010-11-13 06:46

Message:
This ticket has been deemed stale and we're closing it in order to catch up 
with our ticket list. If you think it is still valid, please reopen.

----------------------------------------------------------------------

Comment By: Craig Cook (ccook)
Date: 2010-10-19 05:08

Message:
Hello,

I tried this patch, but I am still getting the error, at the same place in the code.  The error is the same with or without the patch to specification.rb; dependency.rb was already like the patched part shown above.  This happened when installing using bundler, executed via capistrano.

We  had been using hpricot, it wasn't needed, it was giving this error first.  I took it out, but then the same  RangeError happened with mysql.  I've seen it before also with nokogiri.  (Always with native gems, though).

Here's the relevant part of the log:
----------- begin log ----------------------------
 ** [out :: 192.168.10.63] Installing mysql (2.8.1)
 ** [out :: 192.168.10.63] with native extensions
 ** [out :: 192.168.10.62] /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash'
 ** [out :: 192.168.10.62] :
 ** [out :: 192.168.10.62] bignum too big to convert into `long'
 ** [out :: 192.168.10.62] (
 ** [out :: 192.168.10.62] RangeError
 ** [out :: 192.168.10.62] )
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/requirement.rb:109:in `hash'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:675:in `hash'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/fileutils.rb:243:in `inject'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `each'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `inject'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/site_ruby/1.8/rubygems/specification.rb:674:in `hash'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `include?'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/1.8/tsort.rb:205:in `each_strongly_connected_component_from'
 ** [out :: 192.168.10.62] ... 22 levels...
 ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/lib/bundler/vendor/thor/base.rb:389:in `start'
 ** [out :: 192.168.10.62] from /usr/lib/ruby/gems/1.8/gems/bundler-1.0.2/bin/bundle:13
 ** [out :: 192.168.10.62] from /usr/bin/bundle:19:in `load'
 ** [out :: 192.168.10.62] from /usr/bin/bundle:19
----------- end cap output -------------------


running:
------------ system & ruby info ------------------
[ccook at ev2-stage ~]$ ruby -v
ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux]
[ccook at ev2-stage ~]$ gem  -v
1.3.7
[ccook at ev2-stage ~]$ uname -a
Linux ev2-stage 2.6.18-194.11.4.el5xen #1 SMP Tue Sep 21 06:28:04 EDT 2010 i686 i686 i386 GNU/Linux
------ end system / ruby info  ----------

Gemfile:

----------- begin Gemfile -----------------
  source :gemcutter
             
  gem 'rails',          '2.3.8'    
  gem 'mysql',          '2.8.1'
  gem "geokit"
  gem "geokit-rails" 
  gem "builder"
  gem 'chronic'
  gem 'whenever'
  gem 'database_cleaner'       
  gem 'apn_on_rails'
  gem 'factory_girl'
  gem 'net-sftp'   
  gem 'will_paginate'    # dependency for squirrel & jqgrid
  gem 'nokogiri'           # only for test/functional/auth_controller_test.rb           
  
  gem 'cucumber'
  gem 'cucumber-rails'
  gem 'webrat'
  gem 'rspec'

---------- end Gemfile -----------------


So, is this the same issue? It sure looks like it to me.  I hope not to have to dive into the innards of rubygems if  possible.  But we need to be able to deploy.  The app is working and passing tests on development, but hard to say on staging as we can't get it over there with cap.  I suppose it could all be done by hand once anyway, but we (other dev on my team and I ) need to be able to do this over again.

Thanks for your time in this!

Cheers,
Craig

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126