Re: Status of ruby transition in testing
On Sun, Oct 05, 2003 at 01:53:52PM -0500, Steve Langasek wrote:
> These packages all have outstanding RC bugs in unstable which keep the
> respective packages out of testing:
Update and more details on RC bugs on Ruby packages:
This bug is closed:
> libsufary-ruby: 212269
Vim is ok wrt. Ruby transition, and doesn't list any RC bugs:
> vim: 211710; also out of date on sparc due to what looks like buildd
> breakage, and waiting on python2.3.
Following bugs are "FTBFS/ruby-dev no longer exists":
> libdb-ruby: 212103
> libgd-ruby: 212105
libnet-irc-ruby: 212262
liboptparse-ruby: 212263
> libpcap-ruby: 212265
librmagick-ruby: 212272 (waiting for sponsor upload)
libromkan-ruby: 212295
> libsdl-ruby: 212266
> libshadow-ruby: 212268
rubymagick: 212294
rubyunit: 212296
> xmlrpc4r: 212298
I am planning to produce patches and prepare NMUs for these starting
this weekend. I expect that it would only involve updating build-depends
and depends in debian/control, and changing invocations of ruby to
ruby1.8 in debian/rules. Split-p work?
I've also started to think about adding a dummy ruby-dev package to
ruby-defaults. This solution would require a change to Debian Ruby
Policy wrt. dependencies, but in that case packages won't have to be
updated for future Ruby transitions, and will be able to depend and
build-depend on default Ruby version implicitly. What is the argument
behind explicit Ruby version in depends and build-depends?
This bug also has to do with Ruby transition:
> libiconv-ruby: 214035
Package: libruby-iconv1.6
[...]
/usr/lib/ruby/1.8/rd/rdinlineparser.tab.rb:13:in `require': No such file
to load -- strscan (LoadError)
from /usr/lib/ruby/1.8/rd/rdinlineparser.tab.rb:13
Obviously, it loads libraries from wrong ruby version. Requires analysis
of control and rules to see where 1.8 comes from.
This package has a bug that needs help:
libfilesystem-ruby: 189964 (segfault on ia64)
Someone with experience in 64-bit Ruby porting and/or with access to
ia64 hardware should take a look into that tiny 106-line C module.
--
Dmitry Borodaenko
Reply to: