From noreply at rubyforge.org Thu Jan 7 14:28:59 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 7 Jan 2010 14:28:59 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Feature Requests-27671 ] data path on Windows (~/.gem is not correct) Message-ID: <20100107192859.8287615B8034@rubyforge.org> Feature Requests item #27671, was opened at 2010-01-07 11:28 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=27671&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody (None) Summary: data path on Windows (~/.gem is not correct) Initial Comment: rubygems puts things in ~/.gem and ~/.gemrc on Windows, which is not correct. Data like that should be placed in the Application Data folder. This path can be acquired for the current user from the APPDATA environment variable. In addition, the path used by rubygems should not include a dot. So, these would be good: gem_path = File.join(ENV['APPDATA'], 'gem') gemrc_path = File.join(ENV['APPDATA'], 'gemrc') ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=27671&group_id=126 From noreply at rubyforge.org Sat Jan 9 15:11:20 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 9 Jan 2010 15:11:20 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Patches-27677 ] fixes many JRuby tests (ensure_gem_subdirectories ordering in test/gemutilities.rb) Message-ID: <20100109201120.D27C318582C3@rubyforge.org> Patches item #27677, was opened at 2010-01-09 20:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=27677&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Colin Jones (trptcolin) Assigned to: Nobody (None) Summary: fixes many JRuby tests (ensure_gem_subdirectories ordering in test/gemutilities.rb) Initial Comment: This patch fixes ~225 failing tests under JRuby. MRI tests are not affected. In test/gemutilities.rb, we have both: Gem.ensure_gem_subdirectories @gemhome and FileUtils.mkdir_p @gemhome but the mkdir_p previously came last, so if the directory didn't already exist, Gem.ensure_gem_subdirectories would never do its job. I've just switched the order so that the subdirectories are properly verified regardless of whether @gemhome already existed. Thanks, Colin Jones trptcolin AT gmail ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=27677&group_id=126 From noreply at rubyforge.org Mon Jan 11 12:16:06 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 11 Jan 2010 12:16:06 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Patches-27681 ] gem which should output to strerr and exit > 0 when no path is found Message-ID: <20100111171606.1F782177993F@rubyforge.org> Patches item #27681, was opened at 2010-01-11 15:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=27681&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Caio Chassot (cchassot) Assigned to: Nobody (None) Summary: gem which should output to strerr and exit > 0 when no path is found Initial Comment: diff --git a/trunk/lib/rubygems/commands/which_command.rb b/trunk/lib/rubygems/commands/which_command.rb index 7c2d188..0ae9a36 100644 --- a/trunk/lib/rubygems/commands/which_command.rb +++ b/trunk/lib/rubygems/commands/which_command.rb @@ -52,7 +52,8 @@ class Gem::Commands::WhichCommand < Gem::Command paths = find_paths arg, dirs if paths.empty? then - say "Can't find ruby library file or shared library #{arg}" + alert_error "Can't find ruby library file or shared library #{arg}" + raise Gem::SystemExitException, 1 else say paths end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=27681&group_id=126 From noreply at rubyforge.org Thu Jan 14 13:51:54 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 14 Jan 2010 13:51:54 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-25826 ] Uninstalling executables created with --format-executable Message-ID: <20100114185154.E216D1D788AD@rubyforge.org> Bugs item #25826, was opened at 2009-05-07 12:43 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25826&group_id=126 Category: None Group: None Status: Open 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: Sven Schwyn (svoop) Date: 2010-01-14 19: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 Thu Jan 14 18:31:08 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 14 Jan 2010 18:31:08 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Patches-27691 ] Patch: Manual Page support Message-ID: <20100114233108.BD50718582E3@rubyforge.org> Patches item #27691, was opened at 2010-01-14 23:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=27691&group_id=126 Category: `gem install` (extensions) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Michael Edgar (adgar) Assigned to: Nobody (None) Summary: Patch: Manual Page support Initial Comment: This patch adds support for manual page installation to RubyGems. FEATURES ====== Manfiles can be: explicitly specified in the specification (via the array attribute :manual_pages) implicitly discovered in the man/ directory of a gem. Implicitly discovered manfiles are only installed if they have a filename acceptable as a manfile (.1, .2, ... .8, .9, .n, .l) OR if they contain required groff macros for manfiles. Manfiles are installed and updated with the install/update commands. There is an option for these (in the install/update section) :install_manual, which defaults to false if you are windows, and true otherwise. Manfiles are removed during the uninstall command. Currently manfiles are installed into /usr/share/man/ . Since this requires superuser permissions, gems installed/updated/removed without "sudo" will print a friendly message explaining that their manuals were not affected. Installation will still succeed. Lastly, all manuals installed by the rubygems extension are "watermarked" - a small comment is put at the top of the manfile saying it was installed by Rubygems. No manual files will ever be deleted unless they have that watermark, preventing a maliciously crafted gem from removing crucial built-in manfiles. 24 tests containing a total of 40 assertions are included. Every method in the "manual manager" is covered. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=27691&group_id=126 From noreply at rubyforge.org Mon Jan 18 11:20:13 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Jan 2010 11:20:13 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27641 ] Gem.default_bindir is hardcoded on Mac Message-ID: <20100118162013.BD5E519782DB@rubyforge.org> Bugs item #27641, was opened at 2009-12-30 17:47 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27641&group_id=126 Category: other Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Max Howell (mxcl) Assigned to: Nobody (None) Summary: Gem.default_bindir is hardcoded on Mac Initial Comment: The following code in defaults.rb means `gem --bindir /foo/bin` won't work on OS X: def self.default_bindir if defined? RUBY_FRAMEWORK_VERSION then # mac framework support '/usr/bin' else # generic install ConfigMap[:bindir] end end It also means setting: `gem: --bindir /foo/bin` in .gemrc doesn't work. ---------------------------------------------------------------------- Comment By: Christopher Lerum (chrislerum) Date: 2010-01-18 11:20 Message: Oh good, someone else has noticed this. I sure hope this gets fixed. Don't like hack hack ;) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27641&group_id=126 From noreply at rubyforge.org Mon Jan 18 11:31:14 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Jan 2010 11:31:14 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27698 ] Inconsistent handling of Strings versus Symbols in gemrc Message-ID: <20100118163114.4A9A61D7889F@rubyforge.org> Bugs item #27698, was opened at 2010-01-18 11:31 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27698&group_id=126 Category: `gem` commands (other) Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: J Smith (darkpanda) Assigned to: Nobody (None) Summary: Inconsistent handling of Strings versus Symbols in gemrc Initial Comment: It seems that the gem command can't make up its mind whether it should be using Symbols or Strings in the gemrc configuration file. As an example, given the following gemrc: --- sources: - http://gems.rubyforge.org/ - http://gems.github.com/ :gem: --no-ri --no-rdoc Look at how the following commands execute: [user at testbox ~]% sudo gem install activerecord Password: Successfully installed activerecord-2.3.5 1 gem installed Installing ri documentation for activerecord-2.3.5... Installing RDoc documentation for activerecord-2.3.5... [user at testbox ~]% gem sources *** CURRENT SOURCES *** http://gems.rubyforge.org/ The install command is ignoring the arguments that were set using :gem and proceeded to install ri and rdoc documentation and the sources command ignored the github repository. Now, take that same gemrc but switch up the 'sources' String for a Symbol and the :gem Symbol for a String: --- :sources: - http://gems.rubyforge.org/ - http://gems.github.com/ gem: --no-ri --no-rdoc And issue the same commands to gem: [user at testbox ~]% sudo gem install activerecord Successfully installed activerecord-2.3.5 1 gem installed [user at testbox ~]% gem sources *** CURRENT SOURCES *** http://gems.rubyforge.org/ http://gems.github.com/ Now the arguments set on 'gem' in the configuration file work and the so does the github repository added via :sources. This is very wtf -- is the gemrc configuration file supposed to be using Strings as keys, Symbols as keys, both or neither? Here's my environment output: RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.6 (2009-03-31 patchlevel 368) [i686-darwin10.0.0] - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /opt/local/bin/ruby - EXECUTABLE DIRECTORY: /opt/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-10 - GEM PATHS: - /opt/local/lib/ruby/gems/1.8 - /Users/test/.gem/ruby/1.8 - GEM CONFIGURATION: - "gem" => "--no-ri --no-rdoc" - :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=27698&group_id=126 From drbrain at segment7.net Mon Jan 18 18:38:36 2010 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 18 Jan 2010 15:38:36 -0800 Subject: [Rubygems-developers] RubyGems 1.3.5 dependency chain installation seems broken? In-Reply-To: <71166b3b0912310900j4b64a770uf123ac9223be2e40@mail.gmail.com> References: <71166b3b0912310900j4b64a770uf123ac9223be2e40@mail.gmail.com> Message-ID: On Dec 31, 2009, at 09:00, Luis Lavena wrote: > Let's take the example: thin. > > http://gemcutter.org/gems/thin/versions/1.2.5 > > Version 1.2.5 depends on: > > daemons >= 1.0.9 > eventmachine >= 0.12.6 > rack >= 1.0.0 > > daemons 1.0.10 suffices the first dependency: > http://gemcutter.org/gems/daemons/versions/1.0.10 > > eventmachine 0.12.10 does the second: > http://gemcutter.org/gems/eventmachine/versions/0.12.10 > > rack 1.0.1 completes the chain: > http://gemcutter.org/gems/rack/versions/1.0.1 > > none of thin dependencies depends on other libraries at runtime. so > clearly is: > > thin: > - daemons > - eventmachine > - rack > > With that scenario, the order gems are supposed to be installed are: > > eventmachine, daemons, rack, thin > > BUT, for some reason, RubyGems does this: > > eventmachine, daemons, thin, rack > > And when reaches thin, it fails due missing rack. DependencyList isn't smart enough to know about runtime vs. development, and there's a circular dependency between rack and thin, so the order ends up wrong. I'm working on it. From noreply at rubyforge.org Mon Jan 18 19:31:47 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Jan 2010 19:31:47 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27608 ] installation of some dependencies fails Message-ID: <20100119003149.4137C3C8051@rubyforge.org> Bugs item #27608, was opened at 2009-12-21 06:35 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27608&group_id=126 Category: `gem install` command >Group: v1.3.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Roger Pack (rogerdpack) >Assigned to: Eric Hodel (drbrain) Summary: installation of some dependencies fails Initial Comment: Originally reported here http://www.ruby-forum.com/topic/200649#new "gem install sane" fails with shot at devielle:~$ gem install google_hash ERROR: Error installing google_hash: sane requires os (>= 0, runtime) more info (from different computer). C:\dev\ruby\downloads\jruby\bin>gem install --debug -V sane Exception `Gem::LoadError' at C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem jruby-openssl (>= 0) JRuby limited openssl loaded. http://jruby.org/openssl gem install jruby-openssl for full support. Exception `Gem::LoadError' at C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem jruby-openssl (>= 0) Exception `LoadError' at C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/shared/jruby/openssl/autoloads/x509.rb:8 - OpenSSL::X509 requires the jruby-openssl gem Exception `Gem::LoadError' at C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem test-unit (>= 0) GET 200 OK: http://gems.rubyforge.org/latest_specs.4.8.gz GET 200 OK: http://gems.github.com/latest_specs.4.8.gz Installing gem sane-0.16.0 Exception `Gem::InstallError' at C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/rubygems/installer.rb:255 - sane requires os (>= 0, runtime) ERROR: Error installing sane: sane requires os (>= 0, runtime) Exception `Gem::SystemExitException' at C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:170 - Exiting RubyGems with exit_code 1 C:\dev\ruby\downloads\jruby\bin>gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.7 (2009-12-21 patchlevel 174) [java] - INSTALLATION DIRECTORY: C:/dev/ruby/downloads/jruby/lib/ruby/gems/1.8 - RUBY EXECUTABLE: C:/dev/ruby/downloads/jruby/bin/jruby.exe - EXECUTABLE DIRECTORY: C:/dev/ruby/downloads/jruby/bin - RUBYGEMS PLATFORMS: - ruby - universal-java-1.6 - GEM PATHS: - C:/dev/ruby/downloads/jruby/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "install" => "--env-shebang" - "update" => "--env-shebang" - :sources => ["http://gems.rubyforge.org/"] - "gem" => "--no-ri --no-rdoc" - "gemcutter_key" => "1fac3373c066bf27dd8ad967f1bb7505" - REMOTE SOURCES: - http://gems.rubyforge.org/ ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2010-01-18 16:31 Message: Fixed in r2337. RubyGems was not ignoring development dependencies and (for thin) rack had a development dependency on thin which created a cycle. As a workaround you can gem install --force. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-12-30 18:53 Message: Ok, last attempt tested locally, with a gem server (Webrick) having only latest rack, eventmachine, daemons and thin. It fails to install rack gem in tandem, but works with any of the others gems missing when requested to install "thin" Checking inside the code, found this: lib/rubygems/dependency_installer.rb:159 @gems_to_install = dependency_list.dependency_order.reverse And checking at runtime: *** GEMS to INSTALL ## Removing the reverse, works, but not from a fresh start. So, seems that the dependency chain is not being solved properly. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-12-30 17:29 Message: OK, this is not only applicable to RubyGems 1.3.5 on Ruby 1.9.1, but also on Ruby 1.8.6: http://pastie.org/762053 Even worse, it happens the same using RVM on Ubuntu: http://pastie.org/762055 Did a simple test: Installed rack manually Uninstalled daemons. Attempt to install think again worked. Appears that rack gem has something bogus? ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2009-12-30 16:38 Message: E:\installs\ruby-1.9.1-p376_installed\bin>gem install --debug -V thin Exception `NameError' at E:/installs/ruby-1.9.1-p376_installed/lib/ruby/1.9.1/rubygems/command_manager.rb:134 - uninitialized constant Gem::Commands::InstallCommand GET 200 OK: http://gems.rubyforge.org/latest_specs.4.8.gz Exception `Errno::EEXIST' at E:/installs/ruby-1.9.1-p376_installed/lib/ruby/1.9.1/fileutils.rb:243 - File exists - C:\Documents and Settings\packrd/.gem/specs/gems.rubyforge.org%80 Installing gem thin-1.2.5 Exception `NoMethodError' at E:/installs/ruby-1.9.1-p376_installed/lib/ruby/1.9.1/rubygems/package/tar_input.rb:50 - undefined method `readpartial' for # Exception `IOError' at E:/installs/ruby-1.9.1-p376_installed/lib/ruby/1.9.1/rubygems/format.rb:50 - closed stream Exception `Errno::EEXIST' at E:/installs/ruby-1.9.1-p376_installed/lib/ruby/1.9.1/fileutils.rb:243 - File exists - E:/installs/ruby-1.9.1-p376_installed/lib/ruby/gems/1.9.1 Exception `Gem::InstallError' at E:/installs/ruby-1.9.1-p376_installed/lib/ruby/1.9.1/rubygems/installer.rb:250 - thin requires rack (>= 1.0.0, runtime) ERROR: Error installing thin: thin requires rack (>= 1.0.0, runtime) ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-12-30 14:37 Message: Roger: I've asked if you could run the command with --debug and -V options, and you didn't Please do so we can trace it out. Thank you. ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2009-12-30 14:25 Message: Appears I already had the eventmachine gem installed, in this instance, since it doesn't build except by hand. Here's with 1.9.1p376 "from source" (after installing eventmachine by hand, since it doesn't build cleanly) E:\>\installs\ruby-1.9.1-p376_installed\bin\gem -v 1.3.1 E:\>\installs\ruby-1.9.1-p376_installed\bin\gem install thin ERROR: Error installing thin: thin requires rack (>= 1.0.0, runtime) ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-12-30 12:21 Message: When you install thin, it compiles eventmachine. Seems that it only resolves the first dependency and then fails. Can you please try with the version of RubyGems that cames with 1.9.1 instead of the 1.3.5 on top of it? Thank you. ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2009-12-30 10:27 Message: here's another manifestation of it E:\dev\ruby\allgems\lib>gem install thin Building native extensions. This could take a while... ERROR: Error installing thin: thin requires rack (>= 1.0.0, runtime) E:\dev\ruby\allgems\lib>gem install rack Successfully installed rack-1.0.1 1 gem installed E:\dev\ruby\allgems\lib>gem install thin Building native extensions. This could take a while... Successfully installed thin-1.2.5 1 gem installed E:\dev\ruby\allgems\lib>ruby -v ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-mingw32] E:\dev\ruby\allgems\lib>gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.9.1 (2009-12-07 patchlevel 376) [i386- mingw32] - INSTALLATION DIRECTORY: E:/installs/ruby191p376/lib/ruby/gems/1.9.1 - RUBY EXECUTABLE: E:/installs/ruby191p376/bin/ruby.exe - EXECUTABLE DIRECTORY: E:/installs/ruby191p376/bin - RUBYGEMS PLATFORMS: - ruby - x86-mingw32 - GEM PATHS: - E:/installs/ruby191p376/lib/ruby/gems/1.9.1 - C:/Documents and Settings/packrd/.gem/ruby/1.9.1 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org/"] - "gem" => "--no-ri --no-rdoc" - "gemcutter_key" => "1fac3373c066bf27dd8ad967f1bb7505" - REMOTE SOURCES: - http://gems.rubyforge.org/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27608&group_id=126 From noreply at rubyforge.org Mon Jan 18 21:44:29 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Jan 2010 21:44:29 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-22617 ] Gem.loaded_specs does not work on 1.9 Message-ID: <20100119024429.9382A177993B@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: Open 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"=>#=", #]]>, @version=#, @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=#=", #]]>, @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-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"=>#, @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=#=", #]], @version=nil>, @required_rubygems_version=#=", #]], @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] :234:in `push_gem_version_on_load_path': Could not find RubyGem rake (>= 0) (Gem::LoadError) from :14:in `gem' from -e:1:in `
' 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 Mon Jan 18 21:49:04 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Jan 2010 21:49:04 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27699 ] possible to require the wrong version Message-ID: <20100119024904.7C53E177993F@rubyforge.org> Bugs item #27699, was opened at 2010-01-19 02:49 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27699&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: possible to require the wrong version Initial Comment: Currently this code fails (install test-unit gem v 2.0.6 and 1.2.3 first). gem 'rails', '= 2.3.5' $LOAD_PATH.uniq! # active_support (?) does this internally all the time # now attempt to load a gem: gem 'test-unit', '= 1.2.3' require 'test/unit/version' puts Test::Unit::VERSION # should be 1.2.3, but is 2.0.6 This reason for this is that $LOAD_PATH.uniq! is throwing out the "marker" path that has :@gem_prelude_index set, thus it is placing new gems at the end of the $LOAD_PATH, which causes it to always use the highest version of gems. So my question is...is this a bug of rubygems (it should set :@gem_prelude_index on every path it every loads ever) or is rails in error? Thanks. -r refs: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/4dad285825c52532 http://groups.google.com/group/rspec/browse_thread/thread/c5ba2311ca2b7d93# ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27699&group_id=126 From luislavena at gmail.com Mon Jan 18 22:03:41 2010 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 19 Jan 2010 00:03:41 -0300 Subject: [Rubygems-developers] RubyGems 1.3.5 dependency chain installation seems broken? In-Reply-To: References: <71166b3b0912310900j4b64a770uf123ac9223be2e40@mail.gmail.com> Message-ID: <71166b3b1001181903n1c717c7bxa2172bb0ede311f4@mail.gmail.com> On Mon, Jan 18, 2010 at 8:38 PM, Eric Hodel wrote: > On Dec 31, 2009, at 09:00, Luis Lavena wrote: > >> Let's take the example: thin. >> >> http://gemcutter.org/gems/thin/versions/1.2.5 >> >> Version 1.2.5 depends on: >> >> daemons >= 1.0.9 >> eventmachine >= 0.12.6 >> rack >= 1.0.0 >> >> daemons 1.0.10 suffices the first dependency: >> http://gemcutter.org/gems/daemons/versions/1.0.10 >> >> eventmachine 0.12.10 does the second: >> http://gemcutter.org/gems/eventmachine/versions/0.12.10 >> >> rack 1.0.1 completes the chain: >> http://gemcutter.org/gems/rack/versions/1.0.1 >> >> none of thin dependencies depends on other libraries at runtime. so >> clearly is: >> >> thin: >> - daemons >> - eventmachine >> - rack >> >> With that scenario, the order gems are supposed to be installed are: >> >> eventmachine, daemons, rack, thin >> >> BUT, for some reason, RubyGems does this: >> >> eventmachine, daemons, thin, rack >> >> And when reaches thin, it fails due missing rack. > > DependencyList isn't smart enough to know about runtime vs. development, and > there's a circular dependency between rack and thin, so the order ends up > wrong. ?I'm working on it. Thank you Eric. As I explained, my understanding on the issue was pretty rough for not saying nil. Now it worked as expected: C:\Users\Luis\Projects\oss\rubygems>ruby -Ilib bin\gem install thin Building native extensions. This could take a while... Building native extensions. This could take a while... Successfully installed rack-1.1.0 Successfully installed eventmachine-0.12.10 Successfully installed daemons-1.0.10 Successfully installed thin-1.2.5 4 gems installed 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 noreply at rubyforge.org Mon Jan 18 23:37:07 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Jan 2010 23:37:07 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27700 ] unable to load gems *ever* if --disable-gems is passed [1.9] Message-ID: <20100119043707.7A9F518582E0@rubyforge.org> Bugs item #27700, was opened at 2010-01-19 04:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27700&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: unable to load gems *ever* if --disable-gems is passed [1.9] Initial Comment: Appears that this file fails require 'rubygems' require 'os' in 1.9 if you start Ruby with --disable-gems This was surprising to me, because I assumed that doing a require 'rubygems' would "re-enable" rubygems. Perhaps I am wrong? Thanks. -r ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27700&group_id=126 From noreply at rubyforge.org Mon Jan 18 23:38:56 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Jan 2010 23:38:56 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27169 ] unable to resolve transitive dependencies? Message-ID: <20100119043856.C242318582E2@rubyforge.org> Bugs item #27169, was opened at 2009-09-23 18:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: unable to resolve transitive dependencies? Initial Comment: Appears that if you have a gem on github which depends on gems from rubyforge, which gems from rubyforge also have dependencies on gems from rubyforge, the install fails. Ex: (a fresh install of ruby) $ gem install rogerdpack-desc_method -v0.1.5 ERROR: Error installing rogerdpack-desc_method: ruby2ruby requires ruby_parser (~> 2.0, runtime) Thanks. -r [1] http://osdir.com/ml/ruby-talk/2009-08/msg00955.html ---------------------------------------------------------------------- >Comment By: Roger Pack (rogerdpack) Date: 2010-01-19 04:38 Message: I believe this is a duplicate of http://rubyforge.org/tracker/? func=detail&atid=575&aid=27608&group_id=126 (now fixed) Thanks. -r ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-09-23 18:55 Message: That is a known issue: there is no cross repository gem dependency resolution. Patches are welcome. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&group_id=126 From noreply at rubyforge.org Mon Jan 18 23:59:24 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 18 Jan 2010 23:59:24 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27169 ] unable to resolve transitive dependencies? Message-ID: <20100119045924.32C5218582E4@rubyforge.org> Bugs item #27169, was opened at 2009-09-23 15:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&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 resolve transitive dependencies? Initial Comment: Appears that if you have a gem on github which depends on gems from rubyforge, which gems from rubyforge also have dependencies on gems from rubyforge, the install fails. Ex: (a fresh install of ruby) $ gem install rogerdpack-desc_method -v0.1.5 ERROR: Error installing rogerdpack-desc_method: ruby2ruby requires ruby_parser (~> 2.0, runtime) Thanks. -r [1] http://osdir.com/ml/ruby-talk/2009-08/msg00955.html ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2010-01-19 01:38 Message: I believe this is a duplicate of http://rubyforge.org/tracker/? func=detail&atid=575&aid=27608&group_id=126 (now fixed) Thanks. -r ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-09-23 15:55 Message: That is a known issue: there is no cross repository gem dependency resolution. Patches are welcome. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&group_id=126 From noreply at rubyforge.org Tue Jan 19 18:52:56 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 19 Jan 2010 18:52:56 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27705 ] Gem installer places a mis-named *.rb file in /usr/local/lib Message-ID: <20100119235256.8A73F18582F4@rubyforge.org> Bugs item #27705, was opened at 2010-01-19 18:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27705&group_id=126 Category: RubyGems installer (setup.rb) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Forrest Aldrich (forrie) Assigned to: Nobody (None) Summary: Gem installer places a mis-named *.rb file in /usr/local/lib Initial Comment: I have been having some trouble installing rubygems on a new system. The following error I encountered: # gem /usr/local/bin/gem:8:in `require': no such file to load -- rubygems (LoadError) from /usr/local/bin/gem:8 After looking around, I found this under /usr/local/lib: -rw-r--r-- 1 root root 29096 Jan 19 18:32 rubygems.rb -rw-r--r-- 1 root root 268 Jan 19 18:32 ubygems.rb the second file should not be there and I have no idea how was created. Removing the obviously misnamed-file solved the problem. The command I used to install: ruby setup.rb --prefix=/usr/local This applies to the latest version of rubygems-1.3.5 on RHEL 5.4. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27705&group_id=126 From noreply at rubyforge.org Tue Jan 19 23:18:18 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 19 Jan 2010 23:18:18 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27705 ] Gem installer places a mis-named *.rb file in /usr/local/lib Message-ID: <20100120041818.AA9ED167830B@rubyforge.org> Bugs item #27705, was opened at 2010-01-19 15:52 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27705&group_id=126 Category: RubyGems installer (setup.rb) Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Forrest Aldrich (forrie) Assigned to: Nobody (None) Summary: Gem installer places a mis-named *.rb file in /usr/local/lib Initial Comment: I have been having some trouble installing rubygems on a new system. The following error I encountered: # gem /usr/local/bin/gem:8:in `require': no such file to load -- rubygems (LoadError) from /usr/local/bin/gem:8 After looking around, I found this under /usr/local/lib: -rw-r--r-- 1 root root 29096 Jan 19 18:32 rubygems.rb -rw-r--r-- 1 root root 268 Jan 19 18:32 ubygems.rb the second file should not be there and I have no idea how was created. Removing the obviously misnamed-file solved the problem. The command I used to install: ruby setup.rb --prefix=/usr/local This applies to the latest version of rubygems-1.3.5 on RHEL 5.4. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2010-01-19 20:18 Message: The file isn't misnamed and it was not the cause of your problems. It is there so you can use the '-r' flag like so: % ruby -rubygems blah.rb instead of: % ruby -rrubygems blah.rb (which you can still do, obviously). (It would have been obvious had you read the file) Further, you shouldn't be specifying --prefix to setup.rb. I think this is your real problem. You shouldn't have ruby files under /usr/local/lib. You should have them under /usr/local/lib/ruby/site_ruby/1.8 or some-such. Don't specify anything and let ruby figure out where the files should go. You should remove all the .rb files installed under /usr/local/lib. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27705&group_id=126 From nick at quaran.to Wed Jan 20 10:33:00 2010 From: nick at quaran.to (Nick Quaranto) Date: Wed, 20 Jan 2010 10:33:00 -0500 Subject: [Rubygems-developers] RubyGems/Gemcutter Support Site Message-ID: Thanks to the entp staff, we're now trying out Tender's new Open Source plan, and we now have a dedicated support forum for both RubyGems and Gemcutter: http://help.rubygems.org/ I'll be moving over a lot of the static pages on Gemcutter over to this support site, and I'd like to make it the new home for those who want help with either projects. If you have any suggestions for content that should be included in the knowledge base, please let me know! -Nick From jftucker at gmail.com Wed Jan 20 11:24:33 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 20 Jan 2010 16:24:33 +0000 Subject: [Rubygems-developers] RubyGems/Gemcutter Support Site In-Reply-To: References: Message-ID: <665FB9A4-C0E2-44B9-AF53-4A924FDC5DD8@gmail.com> FAQS: 1.2.0 upgrade bugs Debian introduced bugs libc upgrades on OSX build tools and paths on windows On 20 Jan 2010, at 15:33, Nick Quaranto wrote: > Thanks to the entp staff, we're now trying out Tender's new Open Source > plan, and we now have a dedicated support forum for both RubyGems and > Gemcutter: > > http://help.rubygems.org/ > > I'll be moving over a lot of the static pages on Gemcutter over to this > support site, and I'd like to make it the new home for those who want help > with either projects. If you have any suggestions for content that should be > included in the knowledge base, please let me know! > > -Nick > _______________________________________________ > 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 Wed Jan 20 11:27:15 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 20 Jan 2010 11:27:15 -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: <20100120162715.6F21718582F1@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: 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 Wed Jan 20 13:26:01 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 20 Jan 2010 13:26: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: <20100120182601.C5AFF18582F3@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-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 noreply at rubyforge.org Wed Jan 20 13:28:19 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 20 Jan 2010 13:28:19 -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: <20100120182820.F31AD18582F1@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-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 noreply at rubyforge.org Wed Jan 20 13:33:52 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 20 Jan 2010 13:33: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: <20100120183352.200FC18582F1@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-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 thewoolleyman at gmail.com Wed Jan 20 15:02:42 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 20 Jan 2010 13:02:42 -0700 Subject: [Rubygems-developers] RubyGems/Gemcutter Support Site In-Reply-To: References: Message-ID: On Wed, Jan 20, 2010 at 8:33 AM, Nick Quaranto wrote: > I'll be moving over a lot of the static pages on Gemcutter over to this > support site, and I'd like to make it the new home for those who want help > with either projects. If you have any suggestions for content that should be > included in the knowledge base, please let me know! Is the plan for this to eventually replace the Rubyforge Tracker? http://rubyforge.org/tracker/?group_id=126 -- Chad From luislavena at gmail.com Wed Jan 20 15:12:12 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 20 Jan 2010 17:12:12 -0300 Subject: [Rubygems-developers] RubyGems/Gemcutter Support Site In-Reply-To: References: Message-ID: <71166b3b1001201212x51c0dc0fr8506445576600a44@mail.gmail.com> On Wed, Jan 20, 2010 at 5:02 PM, Chad Woolley wrote: > On Wed, Jan 20, 2010 at 8:33 AM, Nick Quaranto wrote: >> I'll be moving over a lot of the static pages on Gemcutter over to this >> support site, and I'd like to make it the new home for those who want help >> with either projects. If you have any suggestions for content that should be >> included in the knowledge base, please let me know! > > Is the plan for this to eventually replace the Rubyforge Tracker? > > http://rubyforge.org/tracker/?group_id=126 > I think the idea is to replace all the support request and provide more information about the new gem repository instead of dealing with them "off the list" and overwhelm poor Nick. -- 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 thewoolleyman at gmail.com Wed Jan 20 15:51:46 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 20 Jan 2010 13:51:46 -0700 Subject: [Rubygems-developers] RubyGems/Gemcutter Support Site In-Reply-To: <71166b3b1001201212x51c0dc0fr8506445576600a44@mail.gmail.com> References: <71166b3b1001201212x51c0dc0fr8506445576600a44@mail.gmail.com> Message-ID: On Wed, Jan 20, 2010 at 1:12 PM, Luis Lavena wrote: > I think the idea is to replace all the support request and provide > more information about the new gem repository instead of dealing with > them "off the list" and overwhelm poor Nick. Sure, and that's a good thing. However, if the Tender site is a "dedicated support forum for RubyGems", and the Rubyforge Tracker isn't shut down or migrated, there will be two places to enter RubyGems bugs/issues/feature requests, resulting in duplication and confusion. -- Chad From drbrain at segment7.net Wed Jan 20 16:43:11 2010 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 20 Jan 2010 13:43:11 -0800 Subject: [Rubygems-developers] RubyGems/Gemcutter Support Site In-Reply-To: References: <71166b3b1001201212x51c0dc0fr8506445576600a44@mail.gmail.com> Message-ID: On Jan 20, 2010, at 12:51, Chad Woolley wrote: > On Wed, Jan 20, 2010 at 1:12 PM, Luis Lavena > wrote: >> I think the idea is to replace all the support request and provide >> more information about the new gem repository instead of dealing with >> them "off the list" and overwhelm poor Nick. > > Sure, and that's a good thing. However, if the Tender site is a > "dedicated support forum for RubyGems", and the Rubyforge Tracker > isn't shut down or migrated, there will be two places to enter > RubyGems bugs/issues/feature requests, resulting in duplication and > confusion. I think that if there's duplication between the two of issues we can figure out what to do when it happens. It's not as if there's hundreds of bugs being filed between releases. There's already two places I look for bugs against RubyGems, the rubyforge tracker and redmine.ruby-lang.org. A third just isn't that big of a deal to me (and I'm the one who ends up closing most of the bugs). From noreply at rubyforge.org Wed Jan 20 17:37:04 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 20 Jan 2010 17:37:04 -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: <20100120223704.CA2571858301@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: 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 Jan 21 01:51:04 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 21 Jan 2010 01:51:04 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27712 ] RubyGems Plugins: odd behavior when gem w/ plugin has multiple installed versions. Message-ID: <20100121065104.3EC1418582E5@rubyforge.org> Bugs item #27712, was opened at 2010-01-21 00:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27712&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nick Howard (baroquebobcat) Assigned to: Nobody (None) Summary: RubyGems Plugins: odd behavior when gem w/ plugin has multiple installed versions. Initial Comment: When I run gem rdoc with multiple copies of yard installed, I get a SystemStackError because each version of yard installed's rubygems_plugin.rb file is loaded. I think that rubygems shouldn't load the rubygems_plugin.rb files for all installed versions of a gem, it should only load the latest version of the plugins. $ sudo gem rdoc sinatra --backtrace ERROR: While executing gem ... (SystemStackError) stack level too deep /usr/lib/ruby/gems/1.8/gems/yard-0.5.2/lib/rubygems_plugin.rb:19:in `has_rdoc?' /usr/lib/ruby/gems/1.8/gems/yard-0.4.0/lib/rubygems_plugin.rb:77:in `install_ri_yard_orig' /usr/lib/ruby/gems/1.8/gems/yard-0.4.0/lib/rubygems_plugin.rb:77:in `install_ri_yard_orig' /usr/lib/ruby/gems/1.8/gems/yard-0.5.2/lib/rubygems_plugin.rb:79:in `install_ri' /usr/local/lib/site_ruby/1.8/rubygems/doc_manager.rb:109:in `generate_ri' ... yard's maintainer has added a fix, but it only works going forward(since Gem.find_files returns the newer one first). I wrote something that fixes the problem by replacing /lib/rubygems.rb:1103, but it is kind of ugly due to my unfamiliarity with rubygems internals. plugins = Gem.latest_load_paths.map do |path| path = path+'/rubygems_plugin.rb' path if File.exists? path end.compact my notes are also at http://gist.github.com/281456 Thanks, Nick Howard ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27712&group_id=126 From noreply at rubyforge.org Thu Jan 21 04:39:05 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 21 Jan 2010 04:39:05 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27712 ] RubyGems Plugins: odd behavior when gem w/ plugin has multiple installed versions. Message-ID: <20100121093905.42B2918582DE@rubyforge.org> Bugs item #27712, was opened at 2010-01-20 22:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27712&group_id=126 Category: other Group: None >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Nick Howard (baroquebobcat) >Assigned to: Eric Hodel (drbrain) Summary: RubyGems Plugins: odd behavior when gem w/ plugin has multiple installed versions. Initial Comment: When I run gem rdoc with multiple copies of yard installed, I get a SystemStackError because each version of yard installed's rubygems_plugin.rb file is loaded. I think that rubygems shouldn't load the rubygems_plugin.rb files for all installed versions of a gem, it should only load the latest version of the plugins. $ sudo gem rdoc sinatra --backtrace ERROR: While executing gem ... (SystemStackError) stack level too deep /usr/lib/ruby/gems/1.8/gems/yard-0.5.2/lib/rubygems_plugin.rb:19:in `has_rdoc?' /usr/lib/ruby/gems/1.8/gems/yard-0.4.0/lib/rubygems_plugin.rb:77:in `install_ri_yard_orig' /usr/lib/ruby/gems/1.8/gems/yard-0.4.0/lib/rubygems_plugin.rb:77:in `install_ri_yard_orig' /usr/lib/ruby/gems/1.8/gems/yard-0.5.2/lib/rubygems_plugin.rb:79:in `install_ri' /usr/local/lib/site_ruby/1.8/rubygems/doc_manager.rb:109:in `generate_ri' ... yard's maintainer has added a fix, but it only works going forward(since Gem.find_files returns the newer one first). I wrote something that fixes the problem by replacing /lib/rubygems.rb:1103, but it is kind of ugly due to my unfamiliarity with rubygems internals. plugins = Gem.latest_load_paths.map do |path| path = path+'/rubygems_plugin.rb' path if File.exists? path end.compact my notes are also at http://gist.github.com/281456 Thanks, Nick Howard ---------------------------------------------------------------------- >Comment By: Eric Hodel (drbrain) Date: 2010-01-21 01:39 Message: This behavior is clearly spelled out in the documentation: # == RubyGems Plugins # # As of RubyGems 1.3.2, RubyGems will load plugins installed in gems or # $LOAD_PATH. Plugins must be named 'rubygems_plugin' (.rb, .so, etc) and # placed at the root of your gem's #require_path. Plugins are discovered via # Gem::find_files then loaded. Take care when implementing a plugin as your # plugin file may be loaded multiple times if multiple versions of your gem # are installed. I'm sorry that it has inconvenienced yard, but rubygems_plugin.rb is not a place to fill with random code (See http://github.com/lsegal/yard/blob/master/lib/rubygems_plugin.rb). You need to restrict yourself to requiring the files you need and nothing more. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27712&group_id=126 From noreply at rubyforge.org Fri Jan 22 06:37:57 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 22 Jan 2010 06:37:57 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27721 ] install zena cms - on FreeBSD Message-ID: <20100122113757.B36D115B8028@rubyforge.org> Bugs item #27721, was opened at 2010-01-22 11:37 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27721&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: evgen gribov (doc555) Assigned to: Nobody (None) Summary: install zena cms - on FreeBSD Initial Comment: gem --debug install zena -V Exception `NameError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand Exception `Gem::LoadError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:827 - Could not find RubyGem test-unit (>= 0) GET 302 Found: http://gems.rubyforge.org/latest_specs.4.8.gz GET 200 OK: http://production.s3.rubygems.org/latest_specs.4.8.gz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80 Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - end of file reached connection reset after 2 requests, retrying GET 302 Found: http://gems.rubyforge.org/specs.4.8.gz GET 200 OK: http://production.s3.rubygems.org/specs.4.8.gz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80 Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - end of file reached connection reset after 2 requests, retrying GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/ruby-recaptcha-1.0.0.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/ruby-recaptcha-1.0.0.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/tzinfo-0.3.16.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/tzinfo-0.3.16.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/rubyless-0.3.5.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/rubyless-0.3.5.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - end of file reached connection reset after 4 requests, retrying GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/rails-2.3.4.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/rails-2.3.4.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - end of file reached connection reset after 2 requests, retrying GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/uuidtools-2.0.0.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/uuidtools-2.0.0.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - end of file reached connection reset after 2 requests, retrying GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/authlogic-2.1.3.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/authlogic-2.1.3.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/ts-delayed-delta-1.0.2.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/ts-delayed-delta-1.0.2.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/shoulda-2.10.3.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/shoulda-2.10.3.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - end of file reached connection reset after 4 requests, retrying GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/fast_gettext-0.4.16.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/fast_gettext-0.4.16.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/fast_gettext-0.4.17.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/fast_gettext-0.4.17.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/delayed_job-1.8.4.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/delayed_job-1.8.4.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - end of file reached connection reset after 4 requests, retrying GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/syntax-1.0.0.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/syntax-1.0.0.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/yamltest-0.5.3.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/yamltest-0.5.3.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/thinking-sphinx-1.3.14.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/thinking-sphinx-1.3.14.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/json-1.2.0.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/json-1.2.0.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:135 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/protocol.rb:120 - end of file reached Exception `EOFError' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - end of file reached connection reset after 5 requests, retrying GET 302 Found: http://gems.rubyforge.org/quick/Marshal.4.8/will_paginate-2.3.12.gemspec.rz GET 200 OK: http://production.s3.rubygems.org/quick/Marshal.4.8/will_paginate-2.3.12.gemspec.rz Exception `Errno::EEXIST' at /usr/local/lib/ruby/1.8/fileutils.rb:243 - File exists - /root/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8 Killed *** RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.7 (2009-12-24 patchlevel 248) [i386-freebsd6] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/local/bin/ruby18 - EXECUTABLE DIRECTORY: /usr/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-freebsd-6 - GEM PATHS: - /usr/local/lib/ruby/gems/1.8 - /root/.gem/ruby/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=27721&group_id=126 From nick at quaran.to Sat Jan 23 11:46:12 2010 From: nick at quaran.to (Nick Quaranto) Date: Sat, 23 Jan 2010 11:46:12 -0500 Subject: [Rubygems-developers] RubyGems/Gemcutter Support Site In-Reply-To: <665FB9A4-C0E2-44B9-AF53-4A924FDC5DD8@gmail.com> References: <665FB9A4-C0E2-44B9-AF53-4A924FDC5DD8@gmail.com> Message-ID: I found some information on 1.2.0 upgrade bugs (and in general) and put them here: http://help.rubygems.org/faqs/rubygems/rubygems-upgrade-issues I'm not sure about the libc or windows issues, if you can point me to blog posts or the mailing list posts I'll be glad to bring them in. Or, if you want access to help out on the site let me know. I'm going to announce this site now, we can just add stuff as time goes on. -Nick On Wed, Jan 20, 2010 at 11:24 AM, James Tucker wrote: > FAQS: > > 1.2.0 upgrade bugs > > Debian introduced bugs > > libc upgrades on OSX > > build tools and paths on windows > > > On 20 Jan 2010, at 15:33, Nick Quaranto wrote: > > > Thanks to the entp staff, we're now trying out Tender's new Open Source > > plan, and we now have a dedicated support forum for both RubyGems and > > Gemcutter: > > > > http://help.rubygems.org/ > > > > I'll be moving over a lot of the static pages on Gemcutter over to this > > support site, and I'd like to make it the new home for those who want > help > > with either projects. If you have any suggestions for content that should > be > > included in the knowledge base, please let me know! > > > > -Nick > > _______________________________________________ > > Rubygems-developers mailing list > > http://rubyforge.org/projects/rubygems > > Rubygems-developers at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > 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 Fri Jan 29 18:41:42 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 29 Jan 2010 18:41:42 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27749 ] local gem install hits network even when gemfile exists locally Message-ID: <20100129234142.9CBCF18582CE@rubyforge.org> Bugs item #27749, was opened at 2010-01-29 16: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: Open Resolution: None Priority: 3 Submitted By: Joel Duffin (oxtralite) Assigned to: Nobody (None) 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. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27749&group_id=126 From noreply at rubyforge.org Sat Jan 30 00:08:13 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 30 Jan 2010 00:08:13 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27751 ] post install hooks are run for outdated versions of gems Message-ID: <20100130050813.26FAF18582EF@rubyforge.org> Bugs item #27751, was opened at 2010-01-30 05:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27751&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: post install hooks are run for outdated versions of gems Initial Comment: viz: E:\dev\ruby\old\faster_rubygems>gem install *.gem in E:/dev/ruby/downloads/jruby/lib/ruby/gems/1.8/gems/faster_gem_script-0.1.5/lib/rubygems_plugin.rb in E:/dev/ruby/downloads/jruby/lib/ruby/gems/1.8/gems/faster_gem_script-0.1.4/lib/rubygems_plugin.rb (it ran both the 0.1.5 and 0.1.4 version of the hooks). ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27751&group_id=126 From noreply at rubyforge.org Sat Jan 30 14:08:47 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 30 Jan 2010 14:08:47 -0500 (EST) Subject: [Rubygems-developers] [ rubygems-Bugs-27751 ] post install hooks are run for outdated versions of gems Message-ID: <20100130190847.DC7811858302@rubyforge.org> Bugs item #27751, was opened at 2010-01-29 21:08 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27751&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: post install hooks are run for outdated versions of gems Initial Comment: viz: E:\dev\ruby\old\faster_rubygems>gem install *.gem in E:/dev/ruby/downloads/jruby/lib/ruby/gems/1.8/gems/faster_gem_script-0.1.5/lib/rubygems_plugin.rb in E:/dev/ruby/downloads/jruby/lib/ruby/gems/1.8/gems/faster_gem_script-0.1.4/lib/rubygems_plugin.rb (it ran both the 0.1.5 and 0.1.4 version of the hooks). ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2010-01-30 11:08 Message: Intentional AND documented. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27751&group_id=126