This help site has been deprecated. Please send your requests to email@example.com
Broken UTF-8 handling in newest Rubygems when environment locales are not set
I'm encountering some problems after upgrade to newest Rubygems.
It happens when locale settings from the environment are empty (not even "C" locale) and someone tries to install some gem that was created using the newest Rubygems. The major precondition for error to occur is a UTF-8 character in some descriptive field (e.g. developer). The locale settings used when building a gem are irrevelant.
Steps to reproduce:
unset LANG unset LC_ALL gem install i18n-inflector ERROR: While executing gem ... (ArgumentError) invalid byte sequence in US-ASCII
But the same package built one day before (before Rubygems upgrade):
unset LANG unset LC_ALL gem install i18n-inflector --version 2.5.0 Fetching: i18n-inflector-2.5.0.gem (100%) Successfully installed i18n-inflector-2.5.0 1 gem installed
Discussions are closed to public comments.
If you need help with RubyGems.org please start a new discussion.
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
Support Staff 1 Posted by Nick Quaranto on 27 Feb, 2011 06:29 PM
Wow, strange...not sure what's up here, the guys that work on the RG client library will most likely have a better idea.
What OS is this on? Can you show us your
2 Posted by Paweł Wilk on 28 Feb, 2011 12:38 AM
The problem is OS-independent. It happened on Mac OS X Snow Leopard and on Ubuntu Server. The problem was detected on Ruby 1.9.
BTW, prerequisites to trigger the error when installing a gem:
First failing env:
Second failing env:
RubyGems 1.5.2 on Ruby 1.8 seems unaffected (but since 1.8 is often encoding-unaware
it might be just a bug covering other bug).
Note, that this error occurs when installing packages containing
UTF-8 characters in some fields that were built with RubyGems 1.5.2.
Packages built using previous version of RubyGems are installed successully.
There is a difference in specfiles, that might help in tracking cause
of this problem. Package i18n-inflector-2.5.0 was build with old RG,
package i18n-inflector-2.5.1 with new RG. Both were installed using
new RG, but in case of i18n-inflector-2.5.1 installation failed
with the error quoted in my previous post.
(I used Pastie since this markup makes backslashes with character codes interpretable)
authorsline. New RubyGems produce unescaped version.
I don't know, maybe that's intended, but the new RG client
has some problems with installing such a gem when environment
locales are not set.
3 Posted by Paweł Wilk on 06 Mar, 2011 11:04 PM
It seems that exists in many previous RG versions and it's not a bug of RG itself but it would be nice to have some workaround for that in RG.
Support Staff 4 Posted by Nick Quaranto on 27 May, 2011 12:29 AM
Is this still happening in later versions? Digging up open tickets, I haven't heard or seen other reports of this.
5 Posted by Grzegorz Kazula... on 27 May, 2011 10:34 PM
I got this today when using "pusher-gem" (https://github.com/pusher/pusher-gem) on Ruby 1.9.2-p180 and RG 1.8.4
6 Posted by Luis Lavena on 19 Jun, 2011 04:07 PM
Can you guys open a bug report / issue for RubyGems itself:
For us to better work on fixes for RubyGems that is the right place.
7 Posted by Luis Lavena on 19 Jun, 2011 04:14 PM
Sorry, by mistake I provided the wrong link to RubyGems issue tracker.
Please use this: https://github.com/rubygems/rubygems/issues
8 Posted by zoras on 10 Aug, 2011 08:57 AM
Use following command to fix the problem
9 Posted by Paweł Wilk on 10 Aug, 2011 09:32 AM
Since I am not in control of systems that are using my gem this workaround cannot be applied by me.
Yesterday I've discovered that it may be related to psych parser. When using syck parser whlie building gem the problem dissapears during installation since UTF-8 characters are escaped in a gem manifest file.
To apply the workaround the developer has to set the YAML engine to syck in the Rakefile and/or gemspec:
Support Staff 10 Posted by Eric Hodel on 10 Oct, 2011 05:43 PM
This is fixed.
Eric Hodel closed this discussion on 10 Oct, 2011 05:43 PM.