Description of problem: It seems that if the locale_rails gem is installed, as well as the I18n::Locale Module, applications running against Rails 2.3.8 will spit out the following error: NoMethodError: undefined method `clear' for I18n::Locale:Module This is fixed in the following upstream patch, which hasn't made its way into an upstream release tarball yet (patch is from 04/10, latest tarball is from 11/09) http://github.com/mutoh/locale_rails/commit/2bad60660127683c259fed711092e6b419f97e42 Version-Release number of selected component (if applicable): rubygem-locale_rails = 2.0.4 How reproducible: This was encountered when running the deltacloud aggregator web app, which can be setup via the instructions here. http://deltacloud.org/contribute.html Undoubtedly this occurs in other situations (hence the upstream patch), but this was not tested. Once the aggregator is up and running with its dependencies (only the aggregator is needed, not core or condor), simply run 'rake spec' or visit any page on the website to reproduce the issue. Actual results: Both the rails log and the web user interface reports NoMethodError: undefined method `clear' for I18n::Locale:Module Stemming from lib/locale_rails/i18n.rb line 34 Expected results: No errors should be raised.
Would you provide the way to reproduce this issue so that I can check if the proposed patch really fixes the issue you see? By the way I appreciate it if you update your srpms based on http://lists.fedoraproject.org/pipermail/ruby-sig/2010-August/000265.html
Also it is appreciated if rails 2.3.8 rpms are imported into F-14/rawhide tree first.
Rubygems actionpack and activerecord have been updated based on feedback. Comments are in the reply to your email. When you say import those rpms (which I don't own) into rawhide are you referring to updating the devel branch in cvs (well now in git)? Building them in Koji with a certain tag? Updating them via bodhi? etc? As far as this bug at hand, here is a simpler way you can reproduce the issue: 1) Install the Ruby 1.8.7 rpms and latest Rails 2.3.8 rpms 2) yum install rubygem-locale_rails 3) yum install rubygem-gettext_rails 3) Create a new rails application via: "$ rails foobar" 4) $ cd foobar 5) Create a new controller via "$ ./script/generate controller hello" 6) Configure the gettext rails rpm, by adding the following to config/environment.rb: 'config.gem "gettext", :lib => "gettext_rails"' 7) Start the server via: "$ ./script/server" 8) Open a web browser, navigate to http://localhost:3000/hello and view error: "undefined method 'clear' for I18n::Locale:Module" Applying the upstream patch to locale_rails resolves this issue.
Updated Spec / SRPM to include this fix: http://mo.morsi.org/files/rpms/rubygem-locale_rails.spec http://mo.morsi.org/files/rpms/rubygem-locale_rails-2.0.5-3.fc13.1.src.rpm
(In reply to comment #4) > Updated Spec / SRPM to include this fix: > > http://mo.morsi.org/files/rpms/rubygem-locale_rails.spec > http://mo.morsi.org/files/rpms/rubygem-locale_rails-2.0.5-3.fc13.1.src.rpm Well, - it seems you passed "--no-ri" to "gem install", however currently shipped rubygem-locale_rails-doc binary rpm includes ri document files. Any reason you want to disable ri files generation? ( I think ri files are needed for "ri foo" (/usr/bin/ri is in ruby-ri ) - Also it is time we can revert to use <integer>%{?dist} for release number. ! By the way I usually add "-V" option to "gem install".
(In reply to comment #5) > (In reply to comment #4) > > Updated Spec / SRPM to include this fix: > > > > http://mo.morsi.org/files/rpms/rubygem-locale_rails.spec > > http://mo.morsi.org/files/rpms/rubygem-locale_rails-2.0.5-3.fc13.1.src.rpm > Most of these changes worked their way in when moving the gem install stuff to the %prep section so that %patch could be used. > Well, > - it seems you passed "--no-ri" to "gem install", however currently > shipped rubygem-locale_rails-doc binary rpm includes ri document > files. Any reason you want to disable ri files generation? > ( I think ri files are needed for "ri foo" (/usr/bin/ri is > in ruby-ri ) The reason I'll often do this is to quiet the rpmlint warnings about 'unused macros'. That being said, thats always been for new packages, and I agree since it was there before it should be kept, So I removed the "--no-ri" > - Also it is time we can revert to use <integer>%{?dist} for release > number. Removed > ! By the way I usually add "-V" option to "gem install". Readded There were also quite a few tabs that was causing rpmlint to complain and many of the doc files were marked as executable with shebangs, so I removed those. New spec / srpm uploaded: http://mo.morsi.org/files/rpms/rubygem-locale_rails.spec http://mo.morsi.org/files/rpms/rubygem-locale_rails-2.0.5-4.fc13.1.src.rpm
Sorry, that new src rpm url should be http://mo.morsi.org/files/rpms/rubygem-locale_rails-2.0.5-4.fc13.src.rpm
(In reply to comment #6) > (In reply to comment #5) > > Well, > > - it seems you passed "--no-ri" to "gem install", however currently > > shipped rubygem-locale_rails-doc binary rpm includes ri document > > files. Any reason you want to disable ri files generation? > > ( I think ri files are needed for "ri foo" (/usr/bin/ri is > > in ruby-ri ) > > The reason I'll often do this is to quiet the rpmlint warnings about 'unused > macros'. That being said, thats always been for new packages, and I agree since > it was there before it should be kept, So I removed the "--no-ri" - If rpmlint warnings is the only reason you usually use "--no-ri", then it is better that you ignore rpmlint warning for this issue and enable ri generation until other reason exists, otherwise "ri foo" command cannot be used. > There were also quite a few tabs that was causing rpmlint to complain and many > of the doc files were marked as executable with shebangs, so I removed those. - Sorry, however - I prefer to use tab (because for me the spec files not using tabs are harder to read), so please use tab again. - Also listing files to fix shebangs in this way makes spec file harder to maintain. Would you fix shebangs (if needed) in the way which are easire to maintain?
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #5) > > > Well, > > > - it seems you passed "--no-ri" to "gem install", however currently > > > shipped rubygem-locale_rails-doc binary rpm includes ri document > > > files. Any reason you want to disable ri files generation? > > > ( I think ri files are needed for "ri foo" (/usr/bin/ri is > > > in ruby-ri ) > > > > The reason I'll often do this is to quiet the rpmlint warnings about 'unused > > macros'. That being said, thats always been for new packages, and I agree since > > it was there before it should be kept, So I removed the "--no-ri" > > - If rpmlint warnings is the only reason you usually use > "--no-ri", then it is better that you ignore rpmlint warning for > this issue and enable ri generation until other reason exists, > otherwise "ri foo" command cannot be used. > Ah ok, I wasn't all that familiar w/ ri. Looking into it a bit, I see now why we'd want to include it. > > > There were also quite a few tabs that was causing rpmlint to complain and many > > of the doc files were marked as executable with shebangs, so I removed those. > > - Sorry, however > - I prefer to use tab (because for me the spec files not using > tabs are harder to read), so please use tab again. Wouldn't this be against Fedora's package guidelines, namely satisfying rpmlint which is complaining about the mixed tabs and spaces. We can align things using spaces for clarity's purposes (which is what I try to do anyways). > - Also listing files to fix shebangs in this way makes spec file > harder to maintain. Would you fix shebangs (if needed) in the > way which are easire to maintain? Done. Also removed the 'do_check' bits since we don't need that check anymore. New spec / srpm: http://mo.morsi.org/files/rpms/rubygem-locale_rails.spec http://mo.morsi.org/files/rpms/rubygem-locale_rails-2.0.5-5.fc13.src.rpm
Okay, please commit this. By the way, please request ACLs also for F-14 (I think we should push rails 2.3.8 also for F-14).
Pushed to and built against rawhide. I had forgotten to apply for ACLs for the F13/F14 branches. If you could grant, I'll push this update to those branches as well. Will be pushing the Rails 2.3.8 rpms to rawhide momentarily.
rubygem-locale_rails-2.0.5-5.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/rubygem-locale_rails-2.0.5-5.fc14
rubygem-locale_rails-2.0.5-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/rubygem-locale_rails-2.0.5-5.fc13
rubygem-locale_rails-2.0.5-5.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rubygem-locale_rails'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/rubygem-locale_rails-2.0.5-5.fc14
rubygem-locale_rails-2.0.5-5.fc14 has been pushed to the Fedora 13 and Fedora 14 updates. Closing this issue.
rubygem-locale_rails-2.0.5-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
rubygem-locale_rails-2.0.5-5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.