Forum: wxRuby Packaging wxRuby fails

85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-03-09 16:44
(Received via mailing list)
Hi there,

I (once again) just compiled wxRuby 2.0.1 successfully, but I can't get
"rake gem" to work:

===========================================
$ rake gem
(in /home/quintus/Downloads/wxruby-2.0.1)
Enabling DYNAMIC build
Enabling RELEASE build
Enabling UNICODE build
The following wxWidgets features are not available and will be skipped:
  PrinterDC
rake aborted!
undefined method `write' for #<Syck::Emitter:0x0000000303dba0>
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in
`end_document'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:17:in
`visit_Psych_Nodes_Document'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/visitor.rb:10:in
`accept'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in
`block in visit_Psych_Nodes_Stream'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in
`each'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/emitter.rb:10:in
`visit_Psych_Nodes_Stream'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/visitors/visitor.rb:11:in
`accept'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/nodes/node.rb:36:in
`to_yaml'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych.rb:166:in `dump'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/psych/core_ext.rb:13:in
`psych_to_yaml'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:715:in
`node_export'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:715:in
`add'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:715:in
`encode_with'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:737:in
`block (2 levels) in to_yaml'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:736:in
`map'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:736:in
`block in to_yaml'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/syck.rb:401:in `call'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/syck.rb:401:in `emit'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/syck.rb:401:in `quick_emit'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:735:in
`to_yaml'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:78:in
`block (2 levels) in write_package'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:73:in
`block (3 levels) in add_gem_contents'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:83:in
`new'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:67:in
`block (2 levels) in add_gem_contents'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in
`wrap'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:65:in
`block in add_gem_contents'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_writer.rb:113:in
`add_file'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:63:in
`add_gem_contents'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package/tar_output.rb:31:in
`open'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/package.rb:68:in
`open'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:77:in
`block in write_package'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:76:in
`open'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:76:in
`write_package'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/builder.rb:39:in
`build'
/home/quintus/Downloads/wxruby-2.0.1/rake/rakepackage.rb:68:in `block in
create_gem_tasks'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:634:in `call'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:634:in `block in
execute'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:629:in `each'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:629:in `execute'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:595:in `block in
invoke_with_call_chain'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/monitor.rb:201:in
`mon_synchronize'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:588:in
`invoke_with_call_chain'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:581:in `invoke'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2041:in `invoke_task'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in `block (2
levels) in top_level'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in `each'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2019:in `block in
top_level'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2058:in
`standard_exception_handling'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:2013:in `top_level'
/opt/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/rake.rb:1992:in `run'
/opt/rubies/ruby-1.9.2-p180/bin/rake:31:in `<main>'
===========================================

It seems the Rakefiles are mixing up Psych with Syck. What's happening
here? And how do I get a gem file?

Valete,
Marvin
00109e19a784b64f81b483a5dbec690a?d=identicon&s=25 Chauk-Mean Proum (chauk-mean)
on 2011-03-12 23:22
(Received via mailing list)
Hi Marvin,

2011/3/9 Quintus <sutniuq@gmx.net>:
> Hi there,
>
> I (once again) just compiled wxRuby 2.0.1 successfully, but I can't get
> "rake gem" to work:

Are you on Ubuntu / Linux ?
If so, may be the following page from the wiki will help :
http://wxruby.rubyforge.org/wiki/wiki.pl?BuildingForUbuntu

Cheers,
Chauk-Mean
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-03-13 08:38
(Received via mailing list)
Am 12.03.2011 23:07, schrieb Chauk-Mean Proum:
> http://wxruby.rubyforge.org/wiki/wiki.pl?BuildingForUbuntu
>

Nope, I'm running Arch Linux. And the actual *building* of wxRuby went
well, I end up with wxruby2.so, but the command to build the gem, which
doesn't do any compiling anymore but is just supposed to grab all
necessary files and put them into the gem file, fails. "rake" (without
arguments) works fine, but then "rake gem" fails.

In the meantime I've solved the problem by buiding a second Ruby without
Psych support--all went well and I got my gem, but sadly it segfaults. I
suspect it's that incredible libcairo/libpixman error I've been
expierencing so many times now, and if wxRuby hadn't been my favourite
GUI toolkit for such a long time, I wouldn't hesitate to look for a new
one. The minimal sample runs without problems, but any other more
complex thing crashes. Here's the output of running bigdemo.rb:

=====================================================================
$ ruby bigdemo.rb

(wxruby:2222): Gtk-WARNING **: Error parsing gtk-icon-sizes string:
  'panel-menu=24,24
panel=20,20
gtk-button=18,18
gtk-large-toolbar=24,24'
bigdemo.rb:345: [BUG] Segmentation fault
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]

-- control frame ----------
c:0010 p:---- s:0047 b:0047 l:000046 d:000046 CFUNC  :set_active_target
c:0009 p:1359 s:0043 b:0043 l:000c68 d:000c68 METHOD bigdemo.rb:345
c:0008 p:---- s:0024 b:0024 l:000023 d:000023 FINISH
c:0007 p:---- s:0022 b:0022 l:000021 d:000021 CFUNC  :new
c:0006 p:0047 s:0016 b:0016 l:000015 d:000015 METHOD bigdemo.rb:814
c:0005 p:---- s:0012 b:0012 l:000011 d:000011 FINISH
c:0004 p:---- s:0010 b:0010 l:000009 d:000009 CFUNC  :main_loop
c:0003 p:0300 s:0007 b:0007 l:000ba8 d:002360 EVAL   bigdemo.rb:823
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:000ba8 d:000ba8 TOP
---------------------------
-- Ruby level backtrace information
----------------------------------------
bigdemo.rb:823:in `<main>'
bigdemo.rb:823:in `main_loop'
bigdemo.rb:814:in `on_init'
bigdemo.rb:814:in `new'
bigdemo.rb:345:in `initialize'
bigdemo.rb:345:in `set_active_target'

-- C level backtrace information
-------------------------------------------
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_vm_bugreport+0x5f)
[0x7f199b9e135f]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x62b04)
[0x7f199b8c0b04]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_bug+0xb3)
[0x7f199b8c1a33]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x116715)
[0x7f199b974715]
/lib/libpthread.so.0(+0xf150) [0x7f199b650150]
/usr/lib/libpixman-1.so.0(pixman_image_composite32+0x400)
[0x7f198f15a000]
/usr/lib/libcairo.so.2(+0x3a31c) [0x7f1992bbc31c]
/usr/lib/libcairo.so.2(+0x6480c) [0x7f1992be680c]
/usr/lib/libcairo.so.2(+0x65cac) [0x7f1992be7cac]
/usr/lib/libcairo.so.2(+0x4848b) [0x7f1992bca48b]
/usr/lib/libcairo.so.2(+0x4b000) [0x7f1992bcd000]
/usr/lib/libcairo.so.2(+0x4a123) [0x7f1992bcc123]
/usr/lib/libcairo.so.2(+0x4ac02) [0x7f1992bccc02]
/usr/lib/libcairo.so.2(+0x4b9d1) [0x7f1992bcd9d1]
/usr/lib/libcairo.so.2(+0x48073) [0x7f1992bca073]
/usr/lib/libcairo.so.2(+0x216ed) [0x7f1992ba36ed]
/usr/lib/libcairo.so.2(cairo_fill_preserve+0x20) [0x7f1992b9a2e0]
/usr/lib/libcairo.so.2(cairo_fill+0x9) [0x7f1992b9a2f9]
/usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so(+0x14a5e)
[0x7f198d472a5e]
/usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so(+0x18fa9)
[0x7f198d476fa9]
/usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so(+0x947f)
[0x7f198d46747f]
/usr/lib/libgtk-x11-2.0.so.0(+0x8d01b) [0x7f1996dc401b]
/usr/lib/libgtk-x11-2.0.so.0(+0x8d24f) [0x7f1996dc424f]
/usr/lib/libgtk-x11-2.0.so.0(+0x1363a8) [0x7f1996e6d3a8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7f1996844e09]
/usr/lib/libgobject-2.0.so.0(+0x1f618) [0x7f1996856618]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x625)
[0x7f199685f9e5]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f199685fe13]
/usr/lib/libgtk-x11-2.0.so.0(+0x25181f) [0x7f1996f8881f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_container_propagate_expose+0x1c6)
[0x7f1996defc96]
/usr/lib/libgtk-x11-2.0.so.0(+0x8399b) [0x7f1996dba99b]
/usr/lib/libgtk-x11-2.0.so.0(+0xb7804) [0x7f1996dee804]
/usr/lib/libgtk-x11-2.0.so.0(+0x1363a8) [0x7f1996e6d3a8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7f1996844e09]
/usr/lib/libgobject-2.0.so.0(+0x1f618) [0x7f1996856618]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x625)
[0x7f199685f9e5]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f199685fe13]
/usr/lib/libgtk-x11-2.0.so.0(+0x25181f) [0x7f1996f8881f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_container_propagate_expose+0x1c6)
[0x7f1996defc96]
/usr/lib/libgtk-x11-2.0.so.0(+0x8399b) [0x7f1996dba99b]
/usr/lib/libgtk-x11-2.0.so.0(+0xb7804) [0x7f1996dee804]
/usr/lib/libgtk-x11-2.0.so.0(+0x1363a8) [0x7f1996e6d3a8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9) [0x7f1996844e09]
/usr/lib/libgobject-2.0.so.0(+0x1f618) [0x7f1996856618]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x625)
[0x7f199685f9e5]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f199685fe13]
/usr/lib/libgtk-x11-2.0.so.0(+0x25181f) [0x7f1996f8881f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_container_propagate_expose+0x1c6)
[0x7f1996defc96]
/usr/lib/libgtk-x11-2.0.so.0(+0xb7804) [0x7f1996dee804]
/usr/lib/libgtk-x11-2.0.so.0(+0x1363a8) [0x7f1996e6d3a8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x15e) [0x7f1996844ebe]
/usr/lib/libgobject-2.0.so.0(+0x1f618) [0x7f1996856618]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x625)
[0x7f199685f9e5]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83) [0x7f199685fe13]
/usr/lib/libgtk-x11-2.0.so.0(+0x25181f) [0x7f1996f8881f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x58a) [0x7f1996e6bbca]
/usr/lib/libgdk-x11-2.0.so.0(+0x42cf2) [0x7f1996ac8cf2]
/usr/lib/libgdk-x11-2.0.so.0(+0x3dc1b) [0x7f1996ac3c1b]
/usr/lib/libgdk-x11-2.0.so.0(gdk_window_process_all_updates+0x129)
[0x7f1996ac5e39]
/usr/lib/libgtk-x11-2.0.so.0(+0xb74b1) [0x7f1996dee4b1]
/usr/lib/libgdk-x11-2.0.so.0(+0x1d366) [0x7f1996aa3366]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f3)
[0x7f199628cbf3]
/usr/lib/libglib-2.0.so.0(+0x423d0) [0x7f199628d3d0]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x182) [0x7f199628da42]
/usr/lib/libgtk-x11-2.0.so.0(gtk_dialog_run+0x19b) [0x7f1996df174b]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN15wxMessageDialog9ShowModalEv+0x4a)
[0x7f1997e30bca]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_Z12wxMessageBoxRK8wxStringS1_lP8wxWindowii+0x4e)
[0x7f1997dad02e]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN8wxLogGui5FlushEv+0x279)
[0x7f1997edabe9]
/usr/lib/libwx_baseu-2.8.so.0(_ZN5wxLog15SetActiveTargetEPS_+0x27)
[0x7f199792c867]
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wxruby2.so(+0x45ccb8)
[0x7f1999b02cb8]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17d206)
[0x7f199b9db206]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x172d8e)
[0x7f199b9d0d8e]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x1791ab)
[0x7f199b9d71ab]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17a488)
[0x7f199b9d8488]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_class_new_instance+0x30)
[0x7f199b911b70]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17d206)
[0x7f199b9db206]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x172d8e)
[0x7f199b9d0d8e]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x1791ab)
[0x7f199b9d71ab]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17a488)
[0x7f199b9d8488]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_funcall+0xba)
[0x7f199b9d90ea]
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wxruby2.so(_ZN9wxRubyApp6OnInitEv+0x5c)
[0x7f19998b808c]
/usr/lib/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x54) [0x7f1997920c64]
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/wxruby-ruby19-2.0.1-x86_64-linux/lib/wxruby2.so(+0x20f060)
[0x7f19998b5060]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x17d206)
[0x7f199b9db206]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x172d8e)
[0x7f199b9d0d8e]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x1791ab)
[0x7f199b9d71ab]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(rb_iseq_eval_main+0xb1)
[0x7f199b9dc6a1]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(+0x68eba)
[0x7f199b8c6eba]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(ruby_exec_node+0x1d)
[0x7f199b8c7e1d]
/opt/rubies/ruby-1.9.2-p180/lib/libruby.so.1.9(ruby_run_node+0x1e)
[0x7f199b8ca08e]
ruby(main+0x4b) [0x40099b]
/lib/libc.so.6(__libc_start_main+0xfd) [0x7f199aa38dcd]
ruby() [0x400889]

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension
libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
=====================================================================

This is my libpixman:

=====================================================================
$ LANG=EN_US pacman -Qi pixman
Name           : pixman
Version        : 0.20.2-1
URL            : http://xorg.freedesktop.org
Licenses       : custom
Groups         : None
Provides       : None
Depends On     : glibc
Optional Deps  : None
Required By    : cairo  lib32-pixman  xorg-server
Conflicts With : None
Replaces       : None
Installed Size : 528.00 K
Packager       : Jan de Groot <jgc@archlinux.org>
Architecture   : x86_64
Build Date     : Wed Jan 19 15:45:12 2011
Install Date   : Sat Jan 22 14:50:33 2011
Install Reason : Installed as a dependency for another package
Install Script : No
Description    : Pixman library
=====================================================================

Btw. this was the reason why I wanted to compile wxRuby myself. But
appearently it didn't help.

Vale,
Marvin
00109e19a784b64f81b483a5dbec690a?d=identicon&s=25 Chauk-Mean Proum (chauk-mean)
on 2011-03-16 21:59
(Received via mailing list)
Hi Marvin,

2011/3/13 Quintus <sutniuq@gmx.net>:
>> Are you on Ubuntu / Linux ?
>> If so, may be the following page from the wiki will help :
>> http://wxruby.rubyforge.org/wiki/wiki.pl?BuildingForUbuntu
>
> Nope, I'm running Arch Linux. And the actual *building* of wxRuby went
> well, I end up with wxruby2.so, but the command to build the gem, which
> doesn't do any compiling anymore but is just supposed to grab all
> necessary files and put them into the gem file, fails. "rake" (without
> arguments) works fine, but then "rake gem" fails.

That's strange.
What options did you use for building ruby-1.9.2-p180 ?
Do you use the built-in rubygems or have you upgraded rubygems ?

FWIW, you can also install wxRuby without creating the gem via :
rake install.

Cheers,
Chauk-Mean.
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-03-16 23:09
(Received via mailing list)
Am 16.03.2011 21:56, schrieb Chauk-Mean Proum:
>> necessary files and put them into the gem file, fails. "rake" (without
>> arguments) works fine, but then "rake gem" fails.
>
> That's strange.
> What options did you use for building ruby-1.9.2-p180 ?

$ ./configure --prefix=/opt/rubies/ruby-1.9.2-p180 --enable-shared
CFLAGS=-I/usr/src/linux-2.6.37-ARCH/include
$ make
$ sudo make install

I have to provide the extra CFLAGS, because on Arch recently some header
files in /usr/inclide/asm-generic/ disappeared and made Ruby fail to
compile when it came to socket (which I need). The files are present in
the bare kernel header directory, so I put that into CFLAGS.

> Do you use the built-in rubygems or have you upgraded rubygems ?

I upgraded via gem update --system. At the moment I'm running:

$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.6.2
  - RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-linux]
  - INSTALLATION DIRECTORY:
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: /opt/rubies/ruby-1.9.2-p180/bin/ruby
  - EXECUTABLE DIRECTORY: /opt/rubies/ruby-1.9.2-p180/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1
     - /home/quintus/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - "install" => "--format-executable"
     - "update" => "--format-executable"
     - "rdoc" => "--format=hanna"
  - REMOTE SOURCES:
     - http://rubygems.org/


> FWIW, you can also install wxRuby without creating the gem via :
> rake install.

As I already said, I compiled a Ruby without Psych support (by deleting
the psych extension's directory from the Ruby sources prior to the
building commands), then I recompiled wxRuby with
$ rake
$ rake gem
and got the gem file. I took it and installed it onto the Ruby with
Psych support--works fine. However, I don't want to have an extra Ruby
installation solely for building wxRuby. Which then segfaults.

If I remember correctly, in Rails one can force the YAML engine to Syck
like this:

YAML::Engine.default_yamler = Syck

I'm not sure wheather this is rails-specific or not (can't try today),
but if not including this line in the main Rakefile should be a possible
workaround.

Vale,
Quintus
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-03-17 09:55
(Received via mailing list)
Am 16.03.2011 22:45, schrieb Quintus:
> If I remember correctly, in Rails one can force the YAML engine to Syck
> like this:
>
> YAML::Engine.default_yamler = Syck
>
> I'm not sure wheather this is rails-specific or not (can't try today),
> but if not including this line in the main Rakefile should be a possible
> workaround.

It's not specific to Rails and works like this:

require "yaml"
YAML::ENGINE.yamler = "syck"

Note the uppercase ENGINE and the "syck" string. However, adding it to
the top of wxRuby's Rakefile didn't do the trick, I'm still getting the
same error.

Vale,
Marvin
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-03-22 22:27
(Received via mailing list)
Am 17.03.2011 09:20, schrieb Quintus:
> It's not specific to Rails and works like this:
>
Regarding the pixman segfault I can now narrow this down between three
versions of libpixman. I just downgraded my pixman lib to 0.20.0,
leaving everything else on my system untouched and I got wxRuby working
again. Previously installed was 0.20.2, so somewhere between those
versions there must be something wrong with libpixman. Tomorrow I'm
going to file a bug on the Arch tracker, and hopfully I'll get some
informative input there because pinning pixman to 0.20.0 is not a real
solution I think (first I'll try to get a hold on pixman 0.20.1, but
getting Arch packages for versions out of date that are not cached on
your system is kinda difficult). Btw. what's with Ubuntu? Does it work
there at the moment?

Valete,
Marvin
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-03-23 16:18
(Received via mailing list)
Am 22.03.2011 21:17, schrieb Quintus:
> getting Arch packages for versions out of date that are not cached on
> your system is kinda difficult). Btw. what's with Ubuntu? Does it work
> there at the moment?
>
> Valete,
> Marvin

Just thinking that the Arch tracker is not the correct place to file
this bug--it's not in Arch, it's in cairo/pixman. However, filing a bug
"pixman 0.20.2 breaks wxRuby and segfaults" on bugs.freedesktop.org
doesn't seem an adequate information for the pixman developers (btw.
there has never been a 0.20.1 version of pixman, so the change breaking
wxRuby happened between the 0.20.0 release and the 0.20.2 one). As I'm
not familiar with wxRuby's internals I cannot be of much help on
tracking down the problem--I don't even know if it's really a pixman
problem or a wxRuby one.

Suggestions?

Valete,
Marvin
3396e4a3df8a840faec520af8555a400?d=identicon&s=25 Mario Steele (Guest)
on 2011-03-24 01:06
(Received via mailing list)
This isn't so much a wxRuby issue, as it is a wxWidgets issue.
 Specifically, the version we use with wxRuby.  Newer versions I believe
does not have this issue.  But the main issue that happens, is that the
change between 0.20.0 and 0.20.2, is that pixman_image_composite32()
changed
the function signature from what wxWidgets is expecting, and what pixman
is
expecting.  I tracked this problem down, specifically to that issue, and
difference in signatures.  Sadly, I haven't been able to get newer
versions
of wxWidgets to work with wxRuby 2.0.1, and I haven't been working on
wxRuby
as of lately, as I've been having issues in Real Life to deal with.
Hence
for the lateness in the conversation.  Basically, what is happening, is
Ruby
is catching the C/C++ Side of the system error, that attempts to access
invalid memory, when pixman_image_composite32() attempts to access a
memory
location, that is not valid.  I believe that the previous method
signature
in question, had an integer at the position of question, where it's now
expecting a memory address.

Again, sadly, I don't remember all of the specifics, and I know it is an
issue with the older version of wxWidgets that is being used, that is at
fault.  Not wxRuby.  I apologize for the lateness in this reply, and
hope
this helps you to track down the problem, or find a way for wxRuby 2.0.1
to
compile against a newer version of wxWidgets.

hth,

Mario
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-03-26 00:10
(Received via mailing list)
Am 24.03.2011 00:11, schrieb Mario Steele:
> is catching the C/C++ Side of the system error, that attempts to access
>
> hth,
>
> Mario
>

Not sure why my mail didn't make it to the list, but I'll try again.

First, thanks for your answer. If it's not a wxRuby issue, there's some
hope to get the whole thing resolved. I really do like the wxRuby GUI
toolkit, and unless I'm forced to I wouldn't like to change it.
But before further developing, solve the Real Life problems. Although
Open-Source software is a great way to spend time, tough. :-)

I've just started learning C++ one week ago, and when I've gathered some
experience, I'll take a look at the wxRuby code and hopefully get it to
compile with newer wxWidgets versons. I'm however not familiar with SVN
(always used Git until now), but that can be worked out either.

Vale,
Marvin
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-04-02 01:48
Hi Marvin and Mario, I'm coming up against the same issue and have done
some investigation too.

(I previously sent a message about this to wxruby-developers but I don't
think that was the right list. Sorry about that.)

I'm not sure that Mario's assessment of it being a wxWidgets issue is
right, because on systems that show the problem, the wxWidgets sample
apps work fine but wxruby fails.

After reading Mario's message I tried to compile wxRuby with the latest
development version, but the number of code changes to wxWidgets was too
great and I couldn't get it to compile. Mario, do you know of a
wxWidgets version that allows wxRuby to work?

I have managed to get wxRuby up and running on Ubuntu by modifying
pixman. I got this insight by debugging the crash with gdb.

In the file pixman/pixman.c, function "lookup_composite_function", I
ifdef-ed out the following code:

 for (i = 0; i < N_CACHED_FAST_PATHS; ++i)
 {
    const pixman_fast_path_t *info = &(cache->cache[i].fast_path);

    /* Note that we check for equality here, not whether
     * the cached fast path matches. This is to prevent
     * us from selecting an overly general fast path
     * when a more specific one would work.
     */
    if (info->op == op            &&
        info->src_format == src_format    &&
        info->mask_format == mask_format    &&
        info->dest_format == dest_format    &&
        info->src_flags == src_flags    &&
        info->mask_flags == mask_flags    &&
        info->dest_flags == dest_flags    &&
        info->func)
    {
        *out_imp = cache->cache[i].imp;
        *out_func = cache->cache[i].fast_path.func;

        goto update_cache;
    }
}

And then wxruby works. So it looks like disabling the "fast path
caching" feature of pixman fixes the bug.

If you want to try it, download the pixman source, modify the file, then
compile and install pixman. Rebuild wxWidgets and wxRuby, and then you
should have a working wxRuby.

I don't know where to go next to get a proper resolution to this
problem. As I said, because the wxWidgets sample works, and apps such as
the Ubuntu GUI work otherwise with their use of pixman, I'm thinking it
must be some particular way that wxRuby interacts with wxWidgets that
causes the problem. Can anyone suggest a next step?

Thanks,
David
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-04-02 10:32
(Received via mailing list)
Am 02.04.2011 01:48, schrieb David Beswick:
> I don't know where to go next to get a proper resolution to this
> problem. As I said, because the wxWidgets sample works, and apps such as
> the Ubuntu GUI work otherwise with their use of pixman, I'm thinking it
> must be some particular way that wxRuby interacts with wxWidgets that
> causes the problem. Can anyone suggest a next step?

If it wasn't only wxRuby not working (which is not really related to
pixman), I'd file a bug against pixman. What about other wxWidgets
bindings, such as e.g. wxpython? Do they face the same problems? If not,
maybe the outdated version of SWIG used by wxRuby is in fault
(disclaimer: I never used SWIG)?

A "proper resultion" however can't be achieved by telling wxRuby users
"oh, and you have to patch pixman, recompile it, wxWidgets and wxRuby".
If the pixman team doesn't want to reenable their code again, we're
kinda stuck. I don't know what to do either, but if I can be of any
help... You know. For the moment, I'll just continue learning C++.

Vale,
Marvin
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-04-10 03:38
Thanks for your response Marvin, sorry it took a while, I forgot to
subscribe to the list.

Those were good suggestions, I didn't think of those. About SWIG --
since the version in stable supports newer swig versions I tried
compiling and installing that, but I got the same issue. So nothing in
the newer swig fixes the issue.

I installed wxpython with apt-get and was able to run a sample app with
no issues. So the problem doesn't seem to affect wxpython.

I definitely agree this isn't a solution for users. I'm thinking I'll
have to annoy the pixman team. I just reproduced the problem on the
recent pixman 0.21.6 release.

For anyone wanting to help, you can test your theories quickly by
compiling the modified pixman and installing into /usr/local. As long as
/usr/local/lib is on your dynamic lib path then you can switch back and
forth by renaming the pixman libs in /usr/local/lib to hide them. The
standard pixman libs in /usr/lib should be loaded when nothing's found
in /usr/local/lib.

I'll let you know how I get on.
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-04-10 04:00
I thought I'd start at Ubuntu and reported a bug here:

https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/756237
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-04-10 10:38
(Received via mailing list)
Am 10.04.2011 04:00, schrieb David Beswick:
> I thought I'd start at Ubuntu and reported a bug here:
>
> https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/756237
>

Thanks, lets see where we get...

In your bug report you suggest to install the wxRuby gem for 1.8 rather
than that one for 1.9, maybe you can correct this? I posted a comment
about it, but I think I can't update the original bug report.

Vale,
Marvin
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-04-12 14:56
(Received via mailing list)
Thanks for your help Marvin, I've done that
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-05-09 18:46
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 12.04.2011 14:33, schrieb David Beswick:
>> Thanks, lets see where we get...
>>
>> In your bug report you suggest to install the wxRuby gem for 1.8 rather
>> than that one for 1.9, maybe you can correct this? I posted a comment
>> about it, but I think I can't update the original bug report.
>>
>> Vale,
>> Marvin

Some progress seems to have been made, but wxRuby still doesn't run on
any Ubuntu > Lucid. The bug at
https://bugs.launchpad.net/ubuntu/+source/wxwidget... has
finally been fixed (for Oneiric), just to reveal another one (see my
last comment on that bug) that still prevents the main bug at
https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/756237 to get
flagged for Natty.

Semms fate is against wxRuby at the moment :-|

Valete,
Marvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNyBfiAAoJELh1XLHFkqhas2IIAJDxyG7GRxxNPokfuVlqB214
Ocmkt6fod9Q89i+FDtNSUN/+FmoF9O0aNXAf+SURtot0PO8/PF2swnyiL1QiUd2C
sByJGK4U3mjJC0GkvIR1OqKulm7nsxU8LGuMpdZDbEco0MU42R6FmguLMMeBU8uG
Y1rOWhKC2rkf8znOMoiwU8j6Z4A2UbxMPoK4u7BZu2otDFcUSu1A7UBO/HvisBxE
2y1BKclxV/uFiVoYeiGTKZQBRt58zxuJOdtnqVQtEbw0XjM6KzvoRXgtbTcUU1zc
Gd4LoXtET6etDQ/q0vrc3arCyLLdW4z3bUJno1YLmnQmpK3ck2gV6NqR8xmRg5A=
=98fJ
-----END PGP SIGNATURE-----
06f6780c99d4a8dd71f2b474082ea9ce?d=identicon&s=25 Alex Fenton (Guest)
on 2011-05-09 22:31
(Received via mailing list)
On 09/05/11 17:36, Quintus wrote:
> Some progress seems to have been made, but wxRuby still doesn't run on
> any Ubuntu>  Lucid. The bug at
> https://bugs.launchpad.net/ubuntu/+source/wxwidget... has
> finally been fixed (for Oneiric), just to reveal another one (see my
> last comment on that bug) that still prevents the main bug at
> https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/756237 to get
> flagged for Natty.

thanks for the update - and thanks also for reporting on and documenting
the issues on the Ubuntu bugtracker. I was half-thinking of switching to
Fedora anyway before the next Ubuntu came out - maybe this will tip me
over.

best
alex
04d1dcca8d15e7640920df71d50ee23c?d=identicon&s=25 Don Wilde (Guest)
on 2011-05-10 04:18
(Received via mailing list)
On Mon, May 9, 2011 at 9:36 AM, Quintus <sutniuq@gmx.net> wrote:

> >>>
> >> Marvin
>
> Martin, I have been quite successful at deploying both 32 bit and 64-bit
10.04 installations of wxRuby. I had to go back to the 2.0.0 gem for 64,
but
it seems to work quite fine with our rather elaborate application.
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-05-10 08:13
(Received via mailing list)
Hi Don, on which distributions and versions of those distributions were
you
deploying your apps on? We've found this bug is triggered by the version
of
pixman that the distribution is using.

I found a discussion that I think is the same issue here, I'll add it to
the
bug:

http://lists.debian.org/debian-x/2011/02/msg01021.html
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-05-10 08:24
(Received via mailing list)
Here's the bug that discussion references, in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613221
04d1dcca8d15e7640920df71d50ee23c?d=identicon&s=25 Don Wilde (Guest)
on 2011-05-10 08:53
(Received via mailing list)
Ubuntu 10.04, with ruby 1.8.7p330, IIRC. All updated to -stableAny more
details will have to wait until. I get back to Arizona next week. I can
check the pixman tarball, though I know I never deliberately messed with
it
on either 32 or 64,
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-05-10 09:07
(Received via mailing list)
No worries, thanks heaps for your input Don. No rush either, this is a
pretty longstanding bug by now.
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-05-10 19:20
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 09.05.2011 22:01, schrieb Alex Fenton:
> the issues on the Ubuntu bugtracker. I was half-thinking of switching to
> Fedora anyway before the next Ubuntu came out - maybe this will tip me
> over.

I think I already mentioned it, but it was exaktly wxRuby that was the
final reason for me to switch from Ubuntu to Arch Linux. I really enjoy
the rolling release model now--no way back. :-)

However, Ubuntu is the most-widespread Linux distribution out there.
It's not wise to drop support for it I think, because it would
significantly state a contrast to the platform-indepentness wxRuby aims
to provide.

> Martin, I have been quite successful at deploying both 32 bit and
> 64-bit
> 10.04 installations of wxRuby. I had to go back to the 2.0.0 gem for
> 64, but
> it seems to work quite fine with our rather elaborate application.

Ubuntu Lucid 64bit worked without a problem for me, even though I had to
compile wxRuby 2.0.1 myself. It's just that wxRuby doesn't work on each
and every Ubuntu *after* Lucid.

And btw. my name is Marvin, note the v. :-)

> Hi Don, on which distributions and versions of those distributions
> were you
> deploying your apps on?

I can confirm wxRuby not working for Ubuntu Maverick 64bit, Ubuntu
Maverick 32bit, Ubuntu Natty 32bit (the last to being virtual machines)
and Arch Linux 64bit (completely updated last Friday)*. But I suppose it
doesn't work for different reasons on each machine... :-(

> Here's the bug that discussion references, in Debian:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613221

Thanks! It really looks like a bug in pixman then.

###########################

So, what can we do now? wxRuby's obviously not at fault, it's

a) pixman that is broken and
b) Debian/Ubuntu that ships broken wxWidgets packages

b) is marked as fixed for Oneiric, but I doubt wheather wxRuby will run
then, because of a) and a symbol lookup error I already described on
Launchpad (this would be c) then I think).

The pixman bug breaks wxRuby on nearly every recent Linux distribution,
and Debian/Ubuntu breaks it a second time due to their package
management, which is especially problementic because of their
popularity.

To conclude: I'm worried about wxRuby's future, although it seems that
wxRuby can't do much about the mentioned problems.

> best
> alex

Valete,
Marvin

* The distros I were using "normally", i.e. not as virtual machines,
were like this:
Ubuntu Lucid 64bit -> Ubuntu Maverick 64bit [broke wxRuby] -> Arch Linux
64bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNyXOBAAoJELh1XLHFkqhajpYIAK0/ZBrho5fd9fGaEkGGQbal
+uwRxdavIldM38I8wolfIomPEZxTzupim+NPLigB1NHToUrSjhhCGkg482YuJR9u
HMncfRInw5eK/rXo1xHwF213sY3bZtxy9EOG+lJ/qLCm6qrke5tAGBKLzsY62QtG
v4KOXGNOyC+NEtdHFyPhancvwqrjfnyL/OjgUMku03saLq58vDZMiv1rAz++m69c
RO5h6sIZ+ZHp4tVIKSMKjLYoyQrVfuNK/A0RJMdpnLlsz+oAiP36sS65wKEL1wB4
+F62p7Ow/yjgItqAeG2HgKRcJyKwRT9tXSK8M83dsxWk9hyJVubILa2dWpvsD70=
=12Su
-----END PGP SIGNATURE-----
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-10-01 11:52
(Received via mailing list)
Hi everyone, an update on this problem and wxruby's gem and build
troubles.
I was just able to build wxruby and run bigdemo with the help of a
proposed
natty (11.04) fix for Ubuntu's apt wxwidgets package. This is great
progress! As soon as the natty fix is released, binary gems might be
ready
to go again.

To summarise the problems and their fixes so far:

1. Previously, running any wxruby app would cause a crash in pixman.
This
has possibly been narrowed down to a problem with mesa or opengl drivers
and
it affects many projects that link dynamically to wxwidgets as well as
other
gui toolkits. Excluding opengl support seems to fix this for wxruby. See
https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/756237

2. An additional problem cropped up in Natty, and maybe other versions.
The
Xinerama library is in an unusual place in Ubuntu 64-bit. wxwidget's
configure script can't find it and so it disables support for the
wxDisplay
class (as if --disable-display was given,) and this causes rake compile
to
fail because there's no definition of wxDisplay::ResetMode. There is an
official proposed fix for this now, see
https://bugs.launchpad.net/ubuntu/+source/wxwidget..., and
follow the directions to get the fixed package. Please take a moment to
verify the fix on the bug page, if you try it.

3. Just today, I discovered a problem with the wxruby rake files. The
rake
files exclude various classes from the build on linux, but the logic
fails
because code reads the array $excluded_classes in rakeunixish.rb before
the
array is actually set up at the bottom of rakeconfigure.rb. This causes
link
to fail because libgtk-media isn't present, and MediaCtrl should be
excluded
from the build. I added a class to wrap the functionality of extracting
and
testing for wx features, and it's implemented such that querying wx
features
should be insensitive to the order of different bits of code. Please
apply
the attached patch to fix this, let me know if you have problems with
it.
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-10-06 08:27
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 05.10.2011 03:28, schrieb David Beswick:
>> 1. Previously, running any wxruby app would cause a crash in
>> pixman. This has possibly been narrowed down to a problem with
>> mesa or opengl drivers and it affects many projects that link
>> dynamically to wxwidgets as well as other gui toolkits. Excluding
>> opengl support seems to fix this for wxruby. See
>> https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/756237

Maybe I'm a bit too optimistic, but wxRuby works again with pixman
version 0.22.2, at least on my system (Arch Linux). It seems the bug
has been fixed. Hopefully it stays like this...

Valete,
Marvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOjFmvAAoJELh1XLHFkqhaLWUH/2v6HwKgghqsOEA7j8hbyagP
5cwZrd+5xl8io4dHG7w454gpQsuP4tohQjs29+RPg9doUy7Y0OseXuv3A4+28jfX
YkreGzLG4RxyagFIdGJM/kQDIjo/GclIiAp72fmtx6hXFJOjox5nDPZMY+erKlh/
XP1AhktqX+Ia8WqF31C6vDHoOgjRBDJimL6wY+RQnhVbtpLfIgPxxmqyXMDKfVGl
ce5PL14zNSqCx/S9XbbRz1Bgxp+Ko0B+w3/2Mx1YxfmxZGgoF8M6aSWO8ofTQ+Fs
FQni3ItsaKHaqIIfoK0nZOYutLatNFeOaVysO6lw6gl0z7ldPefVkIGRacwi3zM=
=I8GM
-----END PGP SIGNATURE-----
06f6780c99d4a8dd71f2b474082ea9ce?d=identicon&s=25 Alex Fenton (Guest)
on 2011-10-20 03:29
(Received via mailing list)
hello all - have now committed this patch - looks excellent and works
fine on my main Ubuntu box (11.10). Thanks again and sorry to be slow -
have just started a new job and moved hosts.

We should look to release a bug-fix 2.0.2 soon - I have a little bit of
time this weekend. There are some uncommitted patches I'd like to review
at http://rubyforge.org/tracker/?atid=220&group_id=35...

We had thought that we wouldn't add features to 2.0.x line, but I'd
favour merging these given our slow (!) release schedule. Discussion
welcome (preferably on wxruby-dev).

best
alex
This topic is locked and can not be replied to.