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
> libpcap-ruby: 212265
librmagick-ruby: 212272 (waiting for sponsor upload)
> libsdl-ruby: 212266
> libshadow-ruby: 212268
> 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
/usr/lib/ruby/1.8/rd/rdinlineparser.tab.rb:13:in `require': No such file
to load -- strscan (LoadError)
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.