From noreply at rubyforge.org Wed Jun 9 00:11:27 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 9 Jun 2010 00:11:27 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28286 ] Removal of wrappers should occur *after* successful uninstallation Message-ID: <20100609041127.7D1CE1858368@rubyforge.org> Bugs item #28286, was opened at 2010-06-09 13:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Sakuro OZAWA (sakuro) Assigned to: Nobody (None) Summary: Removal of wrappers should occur *after* successful uninstallation Initial Comment: When one terminates uninstallation of a gem, he/she would expect wrapper scripts remain. $ ruby --version ruby 1.9.3dev (2010-06-08 trunk 28202) [i386-darwin9.8.0] $ gem --version 1.3.7 $ gem uninstall nokogiri Remove executables: nokogiri in addition to the gem? [Yn] y Removing nokogiri You have requested to uninstall the gem: nokogiri-1.4.2 cucumber-0.8.0 depends on [nokogiri (>= 1.4.2)] mime-types-1.16 depends on [nokogiri (~> 1.2)] webrat-0.7.1 depends on [nokogiri (>= 1.2.0)] If you remove this gems, one or more dependencies will not be met. Continue with Uninstall? [Yn] n ERROR: While executing gem ... (Gem::DependencyRemovalException) Uninstallation aborted due to dependent gem(s) $ which nokogiri nokogiri not found ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28286&group_id=126 From luislavena at gmail.com Sat Jun 12 01:32:00 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 12 Jun 2010 01:32:00 -0400 Subject: [Rubygems-developers] Adding contributors to newer GitHub repository Message-ID: Hello guys, First congratulations for the repository relocation. Wonder when the developers with access to svn repo will gain access to the Git one? btw, my username is "luislavena" 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 nick at quaran.to Sat Jun 12 11:38:57 2010 From: nick at quaran.to (Nick Quaranto) Date: Sat, 12 Jun 2010 11:38:57 -0400 Subject: [Rubygems-developers] Adding contributors to newer GitHub repository In-Reply-To: References: Message-ID: Thanks Luis, sorry I missed you at RailsConf! I just brought all of the authors John picked out during the transition and put them into the RubyGems team, collaborators on the repo are now: chad dblack djberg96 drbrain evanphx gsinclair jbarnette jimweirich lstoll luislavena qrush raggi richkilmer tcopeland technomancy thewoolleyman wilson zenspider If I'm missing anyone just give a shout. -Nick On Sat, Jun 12, 2010 at 1:32 AM, Luis Lavena wrote: > Hello guys, > > First congratulations for the repository relocation. > > Wonder when the developers with access to svn repo will gain access to > the Git one? > > btw, my username is "luislavena" > > 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 > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From luislavena at gmail.com Sat Jun 12 12:14:22 2010 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 12 Jun 2010 12:14:22 -0400 Subject: [Rubygems-developers] Adding contributors to newer GitHub repository In-Reply-To: References:

Message-ID: On Sat, Jun 12, 2010 at 11:38 AM, Nick Quaranto wrote: > Thanks Luis, sorry I missed you at RailsConf! Thank you Nick, things were pretty busy but I had the chance to see you receive your well deserved Hero award :-) > I just brought all of the > authors John picked out during the transition and put them into the RubyGems > team, collaborators on the repo are now: > Wow, first time seeing the organization stuff at GitHub, looks interesting. I believe those users are all, but I guess that someone will let you know if he is missing from it :-) Thank you again for the expedited response. -- 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 Sun Jun 13 14:07:25 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 Jun 2010 14:07:25 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-28300 ] gem env platform Message-ID: <20100613180725.E03331858357@rubyforge.org> Feature Requests item #28300, was opened at 2010-06-13 12:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28300&group_id=126 Category: `gem` commands Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel DeLeo (danielsdeleo) Assigned to: Nobody (None) Summary: gem env platform Initial Comment: In the chef project, we support managing a secondary rubygems installation. The only information about this gems installation provided by the user is the path to the `gem` command. Now that we are using the rubygems ruby API from within the chef process, we temporarily change the gem platform to match the target gem installation's platform, so that we get the correct gem, e.g., when the target gem installation is for jruby. The problem is that the gem command only reports this information via the full `gem env` command so we are currently using a hacky regexp to detect jruby and special-case it. It would be ideal if the gem command would report the platforms of the target gem installation via `gem env platform`, maybe as a list separated by File::PATH_SEPARATOR. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28300&group_id=126 From noreply at rubyforge.org Sun Jun 13 14:14:16 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 Jun 2010 14:14:16 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-28301 ] Force cache invalidation via Gem.something Message-ID: <20100613181416.D9F7C185835A@rubyforge.org> Feature Requests item #28301, was opened at 2010-06-13 12:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28301&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Daniel DeLeo (danielsdeleo) Assigned to: Nobody (None) Summary: Force cache invalidation via Gem.something Initial Comment: Currently, if one wishes to invalidate rubygems' caches, the only way is to find and delete them from the system. Doing this in a script or application is problematic because information about rubygems' implementation will be duplicated outside of rubygems' code. Therefore, rubygems should provide a mechanism to delete/invalidate its caches via its ruby API. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28301&group_id=126 From noreply at rubyforge.org Mon Jun 21 14:14:55 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 Jun 2010 14:14:55 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-28313 ] gem locate command to find the location of a gem Message-ID: <20100621181455.833201858370@rubyforge.org> Feature Requests item #28313, was opened at 2010-06-21 18:14 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28313&group_id=126 Category: `gem` commands Group: None Status: Open Resolution: None Priority: 3 Submitted By: Dave Nolan (dpdnolan) Assigned to: Nobody (None) Summary: gem locate command to find the location of a gem Initial Comment: I'd like to float the idea of 'gem locate' to find the location of a gem. A 'gem locate' command would be roughly equivalent to 'locate', just like 'gem which' is roughly equivalent to 'which'. There does seem to some demand for it e.g. http://stackoverflow.com/questions/2261981/gem-which-cannot-find-gem-despite-it-being-installed and feature request [#27053] http://rubyforge.org/tracker/index.php?func=detail&aid=27053&group_id=126&atid=578. It would side-step some people's confusion over what 'gem which' is intended to do. I'm happy to contribute a patch but I'd like to get soundings, especially on what options to support. Cheers, Dave ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=28313&group_id=126 From noreply at rubyforge.org Wed Jun 23 16:40:52 2010 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 Jun 2010 16:40:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-28155 ] source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues Message-ID: <20100623204052.DCEB3185835E@rubyforge.org> Bugs item #28155, was opened at 2010-04-29 15:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126 Category: other Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Randall Lucas (rlucas) Assigned to: Nobody (None) Summary: source_index.rb uses 1.9.1 IO#read API under RUBY_VERSION 1.9.0; other 1.9.0 issues Initial Comment: Facially, this looks like an argument TypeError, and manifests thus: /usr/local/lib/site_ruby/1.9/rubygems/source_index.rb:91:in `IO#read': can't convert Hash into Integer (TypeError) In fact, it's a very similar issue to #28154. source_index.rb at line 88 checks RUBY_VERSION < '1.9' before using the new :encoding => 'UTF-8' calling syntax for File.read (IO#read). However, this change didn't make it into Ruby 1.9.0 (see below from core Changelog). Again, the fix here is to check RUBY_VERSION < '1.9.1' Similar errors may be lurking in config_file.rb, defaults.rb, vanidator.rb, and in the tests. --- $ irb1.9 irb(main):001:0> File.open '/tmp/thing.txt' , :encoding => 'UTF-8' TypeError: can't convert Hash into String from (irb):1:in `initialize' from (irb):1:in `Kernel#binding' --- Fri Feb 15 16:22:49 2008 Yukihiro Matsumoto * io.c (open_key_args): allow specifying both :mode and :encoding. --- $ ruby -v ruby 1.9.0 (2006-06-08) [x86_64-linux] $ gem ENV RubyGems Environment: - RUBYGEMS VERSION: 1.3.6 - RUBY VERSION: 1.9.0 (2006-06-08) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby1.9/gems/1.9 - RUBY EXECUTABLE: /usr/bin/ruby1.9 - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby1.9/gems/1.9 - /home/rlucas/.gem/ruby/1.9 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- Comment By: Jason Frey (fryguy) Date: 2010-06-23 16:40 Message: I agree with Rob Anderson's disagreement. I am using RubyGems 1.3.7 with both Ruby 1.8.6 and Ruby 1.8.7. My project has REXML::Encoding loaded, so defined? Encoding passes when it shouldn't, and blows up with the can't convert Hash into Integer error. I've changed source_index.rb:88 (similar to OP) to spec_code = if RUBY_VERSION > '1.9.0' && defined? Encoding in order to get past the problem. The mechanism of using defined? Encoding is insufficient if all that is needed is to determine the version of Ruby. RUBY_VERSION feels like the more appropriate approach. ---------------------------------------------------------------------- Comment By: Randall Lucas (rlucas) Date: 2010-05-26 01:13 Message: I was using 1.9.0 because it was, and is, the Ruby 1.9 that ships with Debian stable (both oldstable 4.x and current stable 5.x). It is bad to rely upon users not to use 1.9.0, because at least one major *NIX distro includes it, and it is not immediately apparent to the casual user/developer that 1.9.0 is special and untouchable. That Rubygems should work on 1.8.X and 1.9.Y | Y >= 1 violates the principle of least surprise. Whether or not 1.9.0 is intended for production is not the issue. If Rubygems is going to do version and/or symbol presence checking that is known to break for this special case of 1.9.0, then it should do just one more version check and die on invocation with 1.9.0, with a helpful message. Seriously, for both this ticket and #28154, let's just please stipulate that the API-change-induced version checks should correspond to the actual versions in which the API change is present. The whole "> 1.9" vs. "> 1.9.0" shortcut is bit-wise and byte-foolish. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2010-05-25 18:06 Message: Why are you using 1.9.0? AFAIK it was never intended for production use. ---------------------------------------------------------------------- Comment By: Rob Anderson (rabbashanks) Date: 2010-05-24 07:30 Message: I disagree that testing for the "Encoding" class name symbol is the better approach. On my system (stats below), Encoding is defined by REXML as REXML::Encoding - so defined? Encoding returns true, despite my ruby version being 1.8.6 I have implemented the explicit check on RUBY_VERSION in my local copy of rubygems, but I would think this should be the way it is done for everyone. ruby -v ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0] gem ENV RubyGems Environment: - RUBYGEMS VERSION: 1.3.7 - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin10.0.0] - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/local/bin/ruby - EXECUTABLE DIRECTORY: /usr/local/bin - RUBYGEMS PLATFORMS: - ruby - x86-darwin-10 - GEM PATHS: - /usr/local/lib/ruby/gems/1.8 - /Users/robanderson/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://rubygems.org/ ---------------------------------------------------------------------- Comment By: Randall Lucas (rlucas) Date: 2010-05-01 13:48 Message: This appears to have been fixed in trunk. Current code takes the better approach of testing for the "Encoding" class name symbol, and specifying encoding if it exists (as it does in 1.9.1 and above). Lurking cousin errors to this, with the version check assumption of consistent behavior for >= 1.9 (when in fact, 1.9.0 and 1.9.1 have pretty major API diffs), may linger here: rubygems/commands/install_command.rb:112: ENV.delete 'GEM_PATH' if options[:install_dir].nil? and RUBY_VERSION > '1.9' rubygems/config_file.rb:54: if RUBY_VERSION > '1.9' then rubygems/validator.rb:168: if RUBY_VERSION < '1.9' then rubygems/validator.rb:215: if RUBY_VERSION < '1.9' then rubygems.rb:500: unless RUBY_VERSION > '1.9' then rubygems.rb:1135:require 'rubygems/custom_require' if gem_disabled or RUBY_VERSION < '1.9' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28155&group_id=126 From thewoolleyman at gmail.com Tue Jun 29 03:23:33 2010 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 29 Jun 2010 00:23:33 -0700 Subject: [Rubygems-developers] Problems compiling native gems under Snow Leopard + Homebrew Message-ID: (also at http://gist.github.com/456916) Hopefully somebody here can help with this, I've asked a few other places with no success. I've got Snow Leopard running on an older macbook, with Homebrew. My problem is that some native gems have problems compiling for the correct architecture when I use a compiled ruby (e.g. RVM) instead of the system ruby. Under System ruby, it works (mysql_api.bundle can load): $ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -v 2.8.1 -- --with-mysql-config=/usr/local/bin/mysql_config $ file /Library/Ruby/Gems/1.8/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle /Library/Ruby/Gems/1.8/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle: Mach-O 64-bit bundle x86_64 $ ruby -e "require '/Library/Ruby/Gems/1.8/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle'" Under RVM 1.8.7, it fails (wrong architecture when loading mysql_api.bundle): $ rvm use 1.8.7 at test1 info: Using ruby 1.8.7 p174 with gemset test1 $ env ARCHFLAGS="-arch x86_64" gem install mysql -v 2.8.1 -- --with-mysql-config=/usr/local/bin/mysql_config $ file /Users/woolley/.rvm/gems/ruby-1.8.7-p174 at test1/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle /Users/woolley/.rvm/gems/ruby-1.8.7-p174 at test1/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle: Mach-O 64-bit bundle x86_64 $ ruby -e "require '/Users/woolley/.rvm/gems/ruby-1.8.7-p174 at test1/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle'" /Users/woolley/.rvm/gems/ruby-1.8.7-p174 at test1/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle: dlopen(/Users/woolley/.rvm/gems/ruby-1.8.7-p174 at test1/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle, 9): no suitable image found. Did find: (LoadError) /Users/woolley/.rvm/gems/ruby-1.8.7-p174 at test1/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle: mach-o, but wrong architecture - /Users/woolley/.rvm/gems/ruby-1.8.7-p174 at test1/gems/mysql-2.8.1/ext/mysql_api/mysql_api.bundle from -e:1 Here's the error from mkmf.log: "gcc -o conftest -I. -I/Users/woolley/.rvm/rubies/ruby-1.8.7-p174/lib/ruby/1.8/i686-darwin9.6.0 -I. -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/usr/local/Cellar/mysql/5.1.47/include/mysql -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL -g -O2 -pipe -fno-common conftest.c -L. -L/Users/woolley/.rvm/rubies/ruby-1.8.7-p174/lib -L. -L/usr/local/Cellar/readline/6.0/lib -L/usr/local/Cellar/readline/6.0/lib -L/usr/local/Cellar/mysql/5.1.47/lib/mysql -lmysqlclient -lz -lm -lruby-static -L/usr/local/Cellar/readline/6.0/lib -L/usr/local/Cellar/readline/6.0/lib -L/usr/local/Cellar/mysql/5.1.47/lib/mysql -lmysqlclient -lz -lm -ldl -lobjc " ld: warning: in /Users/woolley/.rvm/rubies/ruby-1.8.7-p174/lib/libruby-static.a, file was b uilt for unsupported file format which is not the architecture being linked (x86_64) checked program was: /* begin */ 1: /*top*/ 2: int main() { return 0; } 3: int t() { mysql_ssl_set(); return 0; } /* end */ Looking at the 'file' architecture for other .bundle files is inconclusive. Some are i386, some of x86_64, and the apple-provided ones are universal/multi architecture. Looking at these two links, I'm not even sure which one my machine should be. I can't boot into 64-bit kernel by holding 6+4 when I boot, which makes sense since my machine is not on the list in the second article: http://www.macobserver.com/tmo/article/checking_32_or_64-bit_kernel_boot_mode_in_snow_leopard/ http://www.osnews.com/story/22009/Snow_Leopard_Seeds_Use_32bit_Kernel_Drivers_by_Default I don't know enough to dig into the C compilation and debug what is wrong. Any help is appreciated. Thanks, -- Chad