Re: [arch-general] [arch-dev-public] [signoff] ncurses-5.8-1
On Sun, Feb 27, 2011 at 8:55 AM, Allan McRae <allan@archlinux.org> 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.
On 27/02/11 18:38, Emmanuel Benisty wrote:
On Sun, Feb 27, 2011 at 8:55 AM, Allan McRae<allan@archlinux.org> 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
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<allan@archlinux.org> 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.
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<allan@archlinux.org> 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_iterator<rak::priority_item**, std::vector<rak::priority_item*, std::allocator<rak::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_iterator<rak::priority_item**, std::vector<rak::priority_item*, std::allocator<rak::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_iterator<rak::priority_item**, std::vector<rak::priority_item*, std::allocator<rak::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...
participants (3)
-
Allan McRae
-
Emmanuel Benisty
-
Evgeny Burmentyev