Re: Bug#767138: libfftw3 SIGILL on armhf

2014-11-19 Thread Julian Taylor
sorry for the lack of reply, I have been traveling for the last 1.5 weeks. I'll try to look at this weekend. Feel free to NMU if you need a faster solution. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.o

Re: Bug#767138: libfftw3 SIGILL on armhf

2014-11-19 Thread Sébastien Villemot
Control: severity -1 serious Control: block 760271 by -1 Control: block 769974 by -1 Control: reopen 752514 Control: block 752514 by -1 Le mercredi 19 novembre 2014 à 12:15 -0800, Kamal Mostafa a écrit : > I'm investigating an armhf FTBFS of my package 'minimodem'[0], which I > now suspect might b

Re: libfftw3 SIGILL on armhf

2014-11-19 Thread Lennart Sorensen
On Wed, Nov 19, 2014 at 08:37:15PM +, Edmund Grimley Evans wrote: > Finding out which armhf machines have NEON is depressingly difficult, > but I think that abel ("Marvell Armada 370/XP CPU @ 1.6GHz on a > Marvell MV78460 SoC Development Board (ARM v7)") doesn't have NEON and > the others do, s

Re: libfftw3 SIGILL on armhf

2014-11-19 Thread Edmund Grimley Evans
Kamal Mostafa : > Edmund et al., I would appreciate your expertise here... Does it also appear > to > you that my minimodem (0.20-1) failure[0] could be caused by the fftw3 "NEON > is > perhaps broken" bug?   Does it make sense that abel.d.o would be affected by > it, but harris and asachi would

libfftw3 SIGILL on armhf

2014-11-19 Thread Kamal Mostafa
I'm investigating an armhf FTBFS of my package 'minimodem'[0], which I now suspect might be caused by this libfftw3 bug in unstable: #767138 "fftw3: runtime detection of NEON is perhaps broken" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767138 There, Edmund points out that "#752514 ruby-ff

Re: Debian on TS-221: cannot power off

2014-11-19 Thread Peter Nagel
Hi Simon, Hi Peter, thanks for the information. To me it looks like the management PIC is in some kind of weird state, since all the kernel does on shutdown is send an `A` to /dev/ttyS1, which causes the NAS to be powered off [1]. Unfortunately I was unable to find a command reference for that