Ivan Sergio Borgonovo: > calling aptitude [] runs apt-listbugs that fails with > > /usr/lib/ruby/vendor_ruby/gettext/mo.rb:46: undefined method > `force_encoding' for "\225\004\022\336":String (NoMethodError) > from /usr/lib/ruby/vendor_ruby/gettext/text_domain.rb:16:in > `require' > from /usr/lib/ruby/vendor_ruby/gettext/text_domain.rb:16 > from > /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:14:in `require' > from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:14 > from /usr/lib/ruby/vendor_ruby/gettext.rb:19:in `require' > from /usr/lib/ruby/vendor_ruby/gettext.rb:19 > from /usr/sbin/apt-listbugs:274:in `require' > from /usr/sbin/apt-listbugs:274
Oh crap… my bad. gettext 3.0 dropped support for Ruby 1.8. But given this is still our default interpreter, its reverse dependencies are likely to fail. Given the following: $ git grep 'respond_to?' upstream/2.3.9 | grep -v bindtextdomain upstream/2.3.9:lib/gettext/runtime/mo.rb: if "".respond_to?(:force_encoding) upstream/2.3.9:lib/gettext/runtime/mo.rb: if "".respond_to?(:encode) upstream/2.3.9:lib/gettext/tools/parser/erb.rb: if src.respond_to?(:encode) upstream/2.3.9:lib/gettext/tools/parser/ruby.rb: if source.respond_to?(:encode) upstream/2.3.9:lib/gettext/tools/parser/ruby.rb: return nil unless source.respond_to?(:force_encoding) upstream/2.3.9:lib/gettext/tools/xgettext.rb: if string.respond_to?(:encode) upstream/2.3.9:test/gettext-test-utils.rb: return unless string.respond_to?(:force_encoding) upstream/2.3.9:test/gettext-test-utils.rb: if string.respond_to?(:encode) upstream/2.3.9:test/run-test.rb:$KCODE = "utf8" unless "".respond_to?(:encoding) Trying to re-introduce compatibility with Ruby 1.8 is probably doable, but this might be a little flacky. Any opinions? -- Lunar .''`. lu...@debian.org : :Ⓐ : # apt-get install anarchism `. `'` `-
signature.asc
Description: Digital signature