Hey, ran into the same problem. The first problem I ran into was related to ncursesw using STR2CSTR () and not StringValuePtr, this has been obsolete for a while, but was apparently removed in 1.9.2. I got ncurses to work; see attached PKGBUILD with patch. But there were some problems with the tmpfile stuff, sup would start (complain about ncurses not being ncursesw, which i don't think is correct because i didn't seem to have problems with wide chars.. but well well, probably just a matter of names). But when creating a new message it would fail. So I gave up :p and downgraded to 1.9.1-p378 from arch, I jumped a few revisions back in Arch'es ABS (PKGBUILD's), I'll attach the PKGBUILD here for you, but you could grab it yourself from ArchLinux's repository. Still rebuilding some gems so haven't been able to test if something else is the cause yet.. but this should work. To be able to build the old ruby I first had to delete the 1.9.2 ruby.. (otherwise the build will segfault). I just removed it with pacman -Ud ruby ( or actually yaourt.. but..) The attached files should be put in their own folder and you can create the packages with makepkg, and install the resulting *.pkg..* with pacman -U filename. - gaute On Fri, Sep 3, 2010 at 7:57 PM, <hollunder@lavabit.com> wrote: >> Excerpts from Daren Lord's message of 2010-09-03 15:13:40 +0200: >>> There must have been an arch package update that is now causing my sup >>> mail to >>> fail with this error. >>> >>> /usr/lib/ruby/1.9.1/rubygems.rb:762:in `report_activate_error': Could >>> not find >>> RubyGem ncurses (>= 0) (Gem::LoadError) >>> from /usr/lib/ruby/1.9.1/rubygems.rb:219:in `activate' >>> from /usr/lib/ruby/1.9.1/rubygems.rb:254:in `block in activate' >>> from /usr/lib/ruby/1.9.1/rubygems.rb:253:in `each' >>> from /usr/lib/ruby/1.9.1/rubygems.rb:253:in `activate' >>> from /usr/lib/ruby/1.9.1/rubygems.rb:1065:in `gem' >>> from /usr/bin/sup:18:in `<main>' >>> >>> I have both ncurses and ncursesw installed through the aur branch. >>> >>> Any ideas? Use this at work so I am down right now. >>> >>> aur/ruby-ncurses 1.2.4-1 [installed] (17) >>> This ruby extension makes most functions, constants, and external >>> variables >>> of the C library ncurses accessible >>> >>> from the Ruby programming language. >>> aur/ruby-ncursesw 1.2.4.1-2 [installed] (17) >>> Ruby wrapper for ncurses providing wide character support. >>> >>> Thanks, >>> >>> dalord >>> >> >> Hi, I just had the same thing this morning. I reinstalled sup from aur >> (there's been a new package version, upgraded me from 0.11-1 to 0.11-2) >> and just in case backed ruby (upgraded recently to 1.9.2) to 1.9.1. I'm >> not sure the latter was necessary but I'm up and running again. I'm >> using this at work too so I have no time to experiment with upgrading >> ruby, but I'll try when I get a chance (especially if somebody here can >> confirm sup works with ruby 1.9.2 on their box). >> >> The new package release -2 depends on ruby-ncursesw instead of >> ruby-ncurses the -1 depended on - this might have something to do with >> the whole error (but it's just a guess). >> >> Try respawning sup from aur and if this doesn't help, downgrade ruby to >> 1.9.1. >> >> Good luck! >> Piotr > > The situation looks grim. I don't seem to have the 1.9.1 package anymore > due to a recent cache cleaning. Read all the things I tried: > http://aur.archlinux.org/packages.php?ID=26439 > > How can a stupid minor version change break things so badly? And no one > knows what's wrong or how to solve this mess? I'm kinda pissed. > > Maybe we can get sup into community, so it's kinda supported and might get > some testing that would catch this kind of breakage before it hits users. > > > _______________________________________________ > sup-talk mailing list > sup-talk@rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk >
Attachment:
ruby-ncursesw-fixed-stringvalueptr.tar.xz
Description: application/xz
Attachment:
ruby-1.9.1p378.pkgbuild.tar.xz
Description: application/xz