I''m pleased to announce the release of Sup 0.12. Sup is a console-based email client for people with a lot of email. It supports tagging, very fast full-text search, automatic contact- list management, and more. If you''re the type of person who treats email as an extension of your long-term memory, Sup is for you. Get it: gem install sup Learn it: http://sup.rubyforge.org Love it: sup-talk at rubyforge.org Release notes: Deprecated remote sources have been removed. Maildir support has been improved to gracefully handle messages that move or disappear. The "out of sync" errors should no longer occur. Inline GPG is now supported. Changelog for 0.12: * Remove deprecated IMAP, IMAPS, and mbox+ssh sources * Inline GPG support * Robust maildir support * sup-dump compatibility between Sup versions * New hook: sendmail * Better Ruby 1.9/UTF8 support * As always, many bugfixes and tweaks.
That''s nice. Can I make a criticism? Perhaps there should have been a warning that upgrading is not just a matter of running "gem upgrade sup" because there are engine changes, with a link to the detailed description on the web of how to upgrade? And perhaps you should put a detailed descrption on the web of how to upgrade? "This Sup version expects a v4 index, but you have an existing v2 index. Please run sup-dump to save your labels, move /home/fred/.sup/xapian out of the way, and run sup-sync --restore." Perhaps it really is as simple as this, but this is my "live" data we are talking about here. A little hand-holding would not have gone amis. On Sat, Jan 15, 2011 at 7:07 AM, Rich Lane <rlane at club.cc.cmu.edu> wrote:> I''m pleased to announce the release of Sup 0.12. > > Sup is a console-based email client for people with a lot of email. > It supports tagging, very fast full-text search, automatic contact- > list management, and more. If you''re the type of person who treats > email as an extension of your long-term memory, Sup is for you. > > Get it: gem install sup > Learn it: http://sup.rubyforge.org > Love it: sup-talk at rubyforge.org > > Release notes: > > Deprecated remote sources have been removed. > > Maildir support has been improved to gracefully handle messages that > move or disappear. The "out of sync" errors should no longer occur. > > Inline GPG is now supported. > > Changelog for 0.12: > > * Remove deprecated IMAP, IMAPS, and mbox+ssh sources > * Inline GPG support > * Robust maildir support > * sup-dump compatibility between Sup versions > * New hook: sendmail > * Better Ruby 1.9/UTF8 support > * As always, many bugfixes and tweaks. > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk >-- What a tangled web we weave / Go ''round with circumstance / Someone show me how to tell / The dancer from the dance... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20110117/51fcfcfa/attachment.html>
Excerpts from Shadowfirebird''s message of 2011-01-17 11:44:42 +0100:> That''s nice. > > Can I make a criticism? Perhaps there should have been a warning that > upgrading is not just a matter of running "gem upgrade sup" because there > are engine changes, with a link to the detailed description on the web of > how to upgrade? > > And perhaps you should put a detailed descrption on the web of how to > upgrade? > > "This Sup version expects a v4 index, but you have an existing v2 index. > Please run sup-dump to save your labels, move /home/fred/.sup/xapian out of > the way, and run sup-sync --restore." > > Perhaps it really is as simple as this, but this is my "live" data we are > talking about here. A little hand-holding would not have gone amis. > > On Sat, Jan 15, 2011 at 7:07 AM, Rich Lane <rlane at club.cc.cmu.edu> wrote: > > > I''m pleased to announce the release of Sup 0.12. > > > > Sup is a console-based email client for people with a lot of email. > > It supports tagging, very fast full-text search, automatic contact- > > list management, and more. If you''re the type of person who treats > > email as an extension of your long-term memory, Sup is for you. > > > > Get it: gem install sup > > Learn it: http://sup.rubyforge.org > > Love it: sup-talk at rubyforge.org > > > > Release notes: > > > > Deprecated remote sources have been removed. > > > > Maildir support has been improved to gracefully handle messages that > > move or disappear. The "out of sync" errors should no longer occur. > > > > Inline GPG is now supported. > > > > Changelog for 0.12: > > > > * Remove deprecated IMAP, IMAPS, and mbox+ssh sources > > * Inline GPG support > > * Robust maildir support > > * sup-dump compatibility between Sup versions > > * New hook: sendmail > > * Better Ruby 1.9/UTF8 support > > * As always, many bugfixes and tweaks. > > _______________________________________________ > > sup-talk mailing list > > sup-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/sup-talk > >There also seem to be huge problems building and installing sup 0.12, have a look here to get an idea how much frustration it already caused: http://aur.archlinux.org/packages.php?ID=26439
Excerpts from Philipp ?berbacher''s message of Mon Jan 17 17:03:23 -0500 2011:> There also seem to be huge problems building and installing sup 0.12, > have a look here to get an idea how much frustration it already caused: > http://aur.archlinux.org/packages.php?ID=26439I use Arch myself so I''m surprised there''s been so much trouble packaging for it. Does gettext need to be a gem dependency? I''ve reconsidered the ncurses mess and master now requires ncursesw. I''m not convinced an Arch package should be using xapian-full - I only made that gem because I wanted the install process to be as simple as "gem install sup". The normal Arch Xapian package should work fine. Besides the ncursesw change is there anything else you want in 0.12.1?
On Mon, Jan 17, 2011 at 10:36 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:> Excerpts from Philipp ?berbacher''s message of Mon Jan 17 17:03:23 -0500 2011: >> There also seem to be huge problems building and installing sup 0.12, >> have a look here to get an idea how much frustration it already caused: >> http://aur.archlinux.org/packages.php?ID=26439 > > I use Arch myself so I''m surprised there''s been so much trouble > packaging for it. Does gettext need to be a gem dependency? I''ve > reconsidered the ncurses mess and master now requires ncursesw. I''m not > convinced an Arch package should be using xapian-full - I only made that > gem because I wanted the install process to be as simple as "gem install > sup". The normal Arch Xapian package should work fine.Hey there Rich. I''m the package maintainer there and have certainly had a never-ending cascade of trouble packaging it. Stuff ranging from dire lack of aur packages for the dependencies (which prompted me to write a system to automatically create them) to broken dependencies to massive Sup errors in the upgrade to Ruby 1.9. Anyway, I still can''t get it to run even with 0.12.1. Here''s the general situation (reposted partially from my comments there): * use ruby-xapian-full * need gettext to be a gem and not a regular install... -- pacman -Rd your ruby-gettext and sudo gem install ruby-gettext (STILL A PROBLEM, SHOULD TALK TO THE MAINTAINER OF THAT PACKAGE) * gem install sup: - Won''t install in local mode (i.e. into your ~), fyi (not that I care a lot) - Still attempts to build ncurses (which fails)? Why''s that? If I override and install it without dependencies it seems to use ncursesw happily enough. * The new package throws up this runtime error without a .sup directory: --- RuntimeError from thread: main can''t modify frozen string /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in `force_encoding'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in `block in add_account'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in `each'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in `add_account'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:38:in `initialize'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:613:in `new'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:613:in `init'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup.rb:164:in `start'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/bin/sup:153:in `<module:Redwood>'' /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/bin/sup:69:in `<top (required)>'' /usr/bin/sup:19:in `load'' /usr/bin/sup:19:in `<main>'' The above I''ve seen to be bug 98 on the bugtracker... but for whatever reason, the bugtracker has been down for a week or two on my end. What xapian package do you recommend using? Maybe that''s the source of my problems.
On Tue, Jan 25, 2011 at 11:24 AM, Andrei Thorp <garoth at gmail.com> wrote:> On Mon, Jan 17, 2011 at 10:36 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote: >> Excerpts from Philipp ?berbacher''s message of Mon Jan 17 17:03:23 -0500 2011: >>> There also seem to be huge problems building and installing sup 0.12, >>> have a look here to get an idea how much frustration it already caused: >>> http://aur.archlinux.org/packages.php?ID=26439 >> >> I use Arch myself so I''m surprised there''s been so much trouble >> packaging for it. Does gettext need to be a gem dependency? I''ve >> reconsidered the ncurses mess and master now requires ncursesw. I''m not >> convinced an Arch package should be using xapian-full - I only made that >> gem because I wanted the install process to be as simple as "gem install >> sup". The normal Arch Xapian package should work fine. > > Hey there Rich. I''m the package maintainer there and have certainly > had a never-ending cascade of trouble packaging it. Stuff ranging from > dire lack of aur packages for the dependencies (which prompted me to > write a system to automatically create them) to broken dependencies to > massive Sup errors in the upgrade to Ruby 1.9. > > Anyway, I still can''t get it to run even with 0.12.1. Here''s the > general situation (reposted partially from my comments there): > > * use ruby-xapian-full > * need gettext to be a gem and not a regular install... -- pacman -Rd > your ruby-gettext and sudo gem install ruby-gettext (STILL A PROBLEM, > SHOULD TALK TO THE MAINTAINER OF THAT PACKAGE) > * gem install sup: > ?- Won''t install in local mode (i.e. into your ~), fyi (not that I care a lot) > ?- Still attempts to build ncurses (which fails)? Why''s that? If I > override and install it without dependencies it seems to use ncursesw > happily enough. > * The new package throws up this runtime error without a .sup directory: > > --- RuntimeError from thread: main > can''t modify frozen string > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in > `force_encoding'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in > `block in add_account'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in `each'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in `add_account'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:38:in `initialize'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:613:in `new'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:613:in `init'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup.rb:164:in `start'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/bin/sup:153:in `<module:Redwood>'' > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/bin/sup:69:in `<top (required)>'' > /usr/bin/sup:19:in `load'' > /usr/bin/sup:19:in `<main>'' > > The above I''ve seen to be bug 98 on the bugtracker... but for whatever > reason, the bugtracker has been down for a week or two on my end. > > What xapian package do you recommend using? Maybe that''s the source of > my problems.It also likes to indulge in this error on occasion: /usr/bin/ruby: symbol lookup error: /usr/lib/ruby/gems/1.9.1/gems/ncursesw-1.2.4.1/lib/ncursesw_bin.so: undefined symbol: STR2CSTR
Hi Andrei, These problems are all 1.9 related. But I''m very interested in getting Sup working with 1.9, so let''s see if we can figure something out. Reformatted excerpts from Andrei Thorp''s message of 2011-01-25:> * use ruby-xapian-fullYou may not need this; see Rich''s comments earlier.> * need gettext to be a gem and not a regular install... -- pacman -Rd > your ruby-gettext and sudo gem install ruby-gettext (STILL A PROBLEM, > SHOULD TALK TO THE MAINTAINER OF THAT PACKAGE)Perhaps the package has not been updated to 1.9?> * gem install sup: > - Won''t install in local mode (i.e. into your ~), fyi (not that I care a lot)What is ther error? Sup shouldn''t care where its source files go.> - Still attempts to build ncurses (which fails)? Why''s that? If I > override and install it without dependencies it seems to use ncursesw > happily enough.This is weird. Sup doesn''t depend on the ncurses gem any more. And that gem doesn''t build under 1.9. Sup now depends on the ncursesw gem (which Rich has been releasing newer versions of) which *does* support 1.9.> * The new package throws up this runtime error without a .sup directory: > > --- RuntimeError from thread: main > can''t modify frozen string > /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in > `force_encoding''This is the most troubling. I will see if I can figure out what''s going on here. I''ve seen this before and it''s another symptom of Ruby 1.9 string insanity.> The above I''ve seen to be bug 98 on the bugtracker... but for whatever > reason, the bugtracker has been down for a week or two on my end.Due to spam reasons I''ve shut it down, at least for the time being.> What xapian package do you recommend using? Maybe that''s the source of > my problems.I suspect not, given the above. -- William <wmorgan-sup at masanjin.net>
Reformatted excerpts from Andrei Thorp''s message of 2011-01-25:> It also likes to indulge in this error on occasion: > > /usr/bin/ruby: symbol lookup error: > /usr/lib/ruby/gems/1.9.1/gems/ncursesw-1.2.4.1/lib/ncursesw_bin.so: > undefined symbol: STR2CSTRCan you try with the 1.2.4.3? This is a 1.9 compability issue. If it''s still not working, Rich may have an idea (Rich, perhaps compat.h is not being included somewhere?) -- William <wmorgan-sup at masanjin.net>
Excerpts from William Morgan''s message of 2011-01-26 10:52:52 -0500:> Reformatted excerpts from Andrei Thorp''s message of 2011-01-25: > > It also likes to indulge in this error on occasion: > > > > /usr/bin/ruby: symbol lookup error: > > /usr/lib/ruby/gems/1.9.1/gems/ncursesw-1.2.4.1/lib/ncursesw_bin.so: > > undefined symbol: STR2CSTR > > Can you try with the 1.2.4.3? This is a 1.9 compability issue. If it''s > still not working, Rich may have an idea (Rich, perhaps compat.h is not > being included somewhere?)Yeah, 1.2.4.3 fixes compat.h not being included in menu_wrap.c.
Reformatted excerpts from Rich Lane''s message of 2011-01-26:> Yeah, 1.2.4.3 fixes compat.h not being included in menu_wrap.c.Damn I''m good. -- William <wmorgan-sup at masanjin.net>
On Wed, Jan 26, 2011 at 10:50 AM, William Morgan <wmorgan-sup at masanjin.net> wrote:> Hi Andrei, > > These problems are all 1.9 related. But I''m very interested in getting > Sup working with 1.9, so let''s see if we can figure something out. > > Reformatted excerpts from Andrei Thorp''s message of 2011-01-25: >> * use ruby-xapian-full > > You may not need this; see Rich''s comments earlier.Yeah, I tried it with regular xapian-ruby-bindings, but sup seems to insist on wanting "ruby-full" as a dependency. However, I haven''t checked this just now, so I might be misremembering!> >> * need gettext to be a gem and not a regular install... -- pacman -Rd >> your ruby-gettext and sudo gem install ruby-gettext (STILL A PROBLEM, >> SHOULD TALK TO THE MAINTAINER OF THAT PACKAGE) > > Perhaps the package has not been updated to 1.9?The package is up to date, I think. It''s just doing an actual source download and compile, so it''s being installed in a non-gem format, if I understand correctly. Sup then doesn''t find it. This should be something I can sort out myself though amongst the AUR. Again, not 100% sure on this one.>> * gem install sup: >> ? - Won''t install in local mode (i.e. into your ~), fyi (not that I care a lot) > > What is ther error? Sup shouldn''t care where its source files go.Yeah, ignore this. I think rubygems changed the behaviour I used to remember where if you weren''t sudo''d, it''d install as your local user in ~/.gems or something. Nothing to worry about.>> ? - Still attempts to build ncurses (which fails)? Why''s that? If I >> override and install it without dependencies it seems to use ncursesw >> happily enough. > > This is weird. Sup doesn''t depend on the ncurses gem any more. And that > gem doesn''t build under 1.9. Sup now depends on the ncursesw gem (which > Rich has been releasing newer versions of) which *does* support 1.9.I did experience this, but for whatever reason, gem is taking ages at the moment so I can''t test. Anyway, it doesn''t matter for the package, since I ignore gem dependencies during install and get them from the Arch repos instead.>> * The new package throws up this runtime error without a .sup directory: >> >> --- RuntimeError from thread: main >> can''t modify frozen string >> /usr/lib/ruby/gems/1.9.1/gems/sup-0.12.1/lib/sup/account.rb:54:in >> `force_encoding'' > > This is the most troubling. I will see if I can figure out what''s going > on here. I''ve seen this before and it''s another symptom of Ruby 1.9 > string insanity. > >> The above I''ve seen to be bug 98 on the bugtracker... but for whatever >> reason, the bugtracker has been down for a week or two on my end. > > Due to spam reasons I''ve shut it down, at least for the time being.Ew, spam :(>> What xapian package do you recommend using? Maybe that''s the source of >> my problems. > > I suspect not, given the above.PHENOMENAL NEWS! For the first time in ages, Sup now works properly on Archlinux with ruby 1.9. The update to ncursesw fixes the frozen string issue, and sup seems to be running properly! Fantastic! Ahh, it''s so pretty and blue. :D Anyway, so hopefully things should be smoother now since Ruby should be more stable and its libs are finally catching up. It''s been a bit of a pain to get sup to run on Arch in the past, but hopefully that''s largely behind us now. Thanks everyone.