On 27/02/11 19:49, Evgeny Burmentyev wrote:

On Sun, Feb 27, 2011 at 07:33:32PM +1000, Allan McRae wrote:

...

On 27/02/11 18:38, Emmanuel Benisty wrote:

...

On Sun, Feb 27, 2011 at 8:55 AM, Allan McRae wrote:

...

On 27/02/11 10:40, Allan McRae wrote:

...

Major upstream update.

Test well. There is no soname bump, but experience tells me that some rebuilds will probably be required to fix minor issues.

just FTR, it breaks rtorrent.

eb64@drama:~$rtorrent Caught Segmentation fault, dumping stack: 0 rtorrent() [0x439274] 1 rtorrent() [0x43d737] 2 /lib/libc.so.6(+0x326d0) [0x7f60f5e6e6d0] 3 rtorrent() [0x482f9e] 4 rtorrent() [0x439988] 5 /lib/libc.so.6(__libc_start_main+0xfd) [0x7f60f5e5adcd] 6 rtorrent() [0x40d959] Aborted

simple rebuild doesn't seem to help, downgrading does.

Seems this is x86_64 only. I tried building a few things in its dependency chain too but that did not help.

Added to the TODO list for the maintainer to look into.

Allan

No, it is not. It breaks rtorrent on i686 as well.

Hmmm... I do not get the segfault on i686. Anyway... rebuilding without the --disable-debug flag and adding options=(!strip), I get: Program received signal SIGSEGV, Segmentation fault. __pop_heap<__gnu_cxx::__normal_iteratorrak::priority_item* >

, rak::priority_compare> (this=0x32332f3020485b20) at /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_heap.h:331 331 *__result = _GLIBCXX_MOVE(*__first); (gdb) bt #0 __pop_heap<__gnu_cxx::__normal_iteratorrak::priority_item* > , rak::priority_compare> (this=0x32332f3020485b20) at /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_heap.h:331 #1 pop_heap<__gnu_cxx::__normal_iteratorrak::priority_item* > , rak::priority_compare> (this=0x32332f3020485b20) at /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_heap.h:360 #2 pop (this=0x32332f3020485b20) at ../../rak/priority_queue.h:72 #3 priority_queue_perform (this=0x32332f3020485b20) at ../../rak/priority_queue_default.h:92 #4 display::Manager::receive_update (this=0x32332f3020485b20) at manager.cc:100 #5 0x000000000044a074 in operator() (argc=1, argv=0x7fffffffebf8) at ../rak/functional_fun.h:102 #6 call (argc=1, argv=0x7fffffffebf8) at ../rak/priority_queue_default.h:62 #7 priority_queue_perform (argc=1, argv=0x7fffffffebf8) at ../rak/priority_queue_default.h:95 #8 main (argc=1, argv=0x7fffffffebf8) at main.cc:301

which looks nothing to do with ncurses...