Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-14 Thread Lennart Sorensen
On Sat, Nov 12, 2016 at 10:00:53PM +0200, Adrian Bunk wrote: > I do not understand this part. > > -maltivec should only be set for the code that is behind the runtime > feature check, so this code is only run on hardware that has AltiVec. Well a mistake in the configure script is making it set

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-08 Thread Lennart Sorensen
On Fri, Nov 04, 2016 at 01:33:36PM -0400, Lennart Sorensen wrote: > And of course I made a typo while copying things into the patch. > > Doing another build test of it now. > > --- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400 > +++ vlc-2.2.4/configure.a

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-04 Thread Lennart Sorensen
And of course I made a typo while copying things into the patch. Doing another build test of it now. --- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0 -0400 +++ vlc-2.2.4/configure.ac 2016-11-04 12:22:02.543265439 -0400 @@ -1422,25 +1422,24 @@ VLC_SAVE_FLAGS

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-04 Thread Lennart Sorensen
Actually maybe this simpler version is better. I think I just figured out why libdeinterlace wasn't getting the altivec flags, which was that it was listed as deinterlace rather than libdeinterlace. Doing a build test of it now. --- vlc-2.2.4.orig/configure.ac 2016-05-31 12:11:07.0

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-03 Thread Lennart Sorensen
On Tue, Nov 01, 2016 at 01:42:17PM -0400, Lennart Sorensen wrote: > Well that looks like it only adds it for libvlccore. So at least something like this is needed, but I think the VLCCORE is wrong too, and maybe the deinterlace has to be moved to only merge.c rather than all of deinterl

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-01 Thread Lennart Sorensen
On Tue, Nov 01, 2016 at 07:37:33PM +0200, Adrian Bunk wrote: > On Tue, Nov 01, 2016 at 01:08:03PM -0400, Lennart Sorensen wrote: > > On Tue, Nov 01, 2016 at 12:22:19PM -0400, Lennart Sorensen wrote: > > > On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote: > > >

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-01 Thread Lennart Sorensen
On Tue, Nov 01, 2016 at 12:22:19PM -0400, Lennart Sorensen wrote: > On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote: > > This doesn't looks wrong to me. > > > > Note that depending on the software --enable-altivec can either mean > > - compile

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-01 Thread Lennart Sorensen
On Tue, Nov 01, 2016 at 04:34:01PM +0200, Adrian Bunk wrote: > This doesn't looks wrong to me. > > Note that depending on the software --enable-altivec can either mean > - compile unconditionally for AltiVec, or > - enable AltiVec parts with autodetection to only use them when the > hardware

Bug#842513: vlc: immediate crash on launch on powerpc

2016-11-01 Thread Lennart Sorensen
On Mon, Oct 31, 2016 at 11:13:00PM +0200, Adrian Bunk wrote: > This actually looks like a bug in upstream configure.ac to me: > VLC_ADD_CFLAGS([libvlccore],[${ac_cv_c_altivec}]) > ALTIVEC_CFLAGS="$ALTIVEC_FLAGS ${ac_cv_c_altivec} ${ac_cv_c_altivec_abi}" >

Bug#774651: liblo7 is not multiarch enabled preventing installation of amd64 and i386 versions at the same time

2015-01-05 Thread Lennart Sorensen
Package: liblo7 Version: 0.28-3 Severity: important Tags: patch I was helping a friend figure out why he couldn't install dssi-vst:i386 on his amd64 Linux Mint 17 without it wanting to remove some other packages. I pretty quickly noticed that the problem was in fact that installing liblo7:i386

Bug#774651: liblo7 is not multiarch enabled preventing installation of amd64 and i386 versions at the same time

2015-01-05 Thread Lennart Sorensen
On Mon, Jan 05, 2015 at 05:03:08PM -0300, Felipe Sateler wrote: Excellent! I am unfortunately fairly busy these days. I would welcome a team upload or even an NMU to experimental with this patch. I am just a user. One of these days I should apply to become a DD. Unfortunately, given the

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-03-04 Thread Lennart Sorensen
On Tue, Mar 04, 2014 at 02:59:44AM +, peter green wrote: Seems sane to me. armv7 devices without neon are relatively uncommon so while it's important that they are supported it's IMO not vitally important to squeeze out every last drop of performance from them. I don't agree. At least the

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-03-03 Thread Lennart Sorensen
On Sun, Mar 02, 2014 at 12:02:40PM +0100, Thomas Orgis wrote: After Tahei didn't stop at this (big thanks from here!), we got a new snapshot, http://mpg123.org/snapshot/mpg123-20140302115523.tar.bz2 , that will hopefully become mpg123 1.19.0 soon (not 1.18.x because of feature

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-03-03 Thread Lennart Sorensen
On Sun, Mar 02, 2014 at 09:06:44AM -0500, Reinhard Tartler wrote: That sounds like if the mpg123 package should use: on armel: --with-cpu=arm_nofpu on armhf: --with-cpu=arm_fpu Does this make sense to everybody? I think so. armhf's current debian rules automatically picked arm_fpu with

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-25 Thread Lennart Sorensen
On Tue, Feb 25, 2014 at 11:18:50AM +0100, Thomas Orgis wrote: Am Tue, 25 Feb 2014 17:37:41 +0900 schrieb Taihei Momma t...@mac.com: #0 0xb6fb9332 in INT123_dct64_neon () at dct64_neon.S:48 ^ not a multiple of 4. Oh, d'oh! It could be that simple. I've just committed

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-25 Thread Lennart Sorensen
On Wed, Feb 26, 2014 at 01:59:12AM +0900, Taihei Momma wrote: On 2014/02/26, at 1:44, Thomas Orgis wrote: That address didn't change. Well, the function itself is properly aligned (so my fix didn't take effect anyway). 0xb6fb9330 +0: vpush {d8-d15} 0xb6fb9334 +4: sub

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-24 Thread Lennart Sorensen
On Sat, Feb 22, 2014 at 10:05:35AM +0100, Thomas Orgis wrote: Am Fri, 21 Feb 2014 11:25:12 -0500 schrieb Lennart Sorensen lsore...@csclub.uwaterloo.ca: Testing with the neon build I get a return code of 4, and it seems to be failing to run. It was a pain to even get it to compile. Using

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

2014-02-21 Thread Lennart Sorensen
On Fri, Feb 21, 2014 at 01:29:40AM +, peter green wrote: Thomas Orgis wrote: So, I got conversion to float implemented now and tested with the generic_nofpu decoder on x86-64. It _should_ of course work with ARM, too;-) If you'd like to check the current snapshot of mpg123,

Bug#641478: Patch to fix ffmpeg 0.5.5-1 build on powerpc.

2011-11-09 Thread Lennart Sorensen
On Tue, Nov 08, 2011 at 04:42:56PM -0500, wrote: This patched fixes building of ffmpeg 0.5.5-1 on powerpc for me. It matches what the code is now like in newer versions of ffmpeg. diff -urN ffmpeg-0.5.5/libavcodec/cavs.h ffmpeg-0.5.5.powerpcfix/libavcodec/cavs.h ---

Bug#641478: Patch to fix ffmpeg 0.5.5-1 build on powerpc.

2011-11-08 Thread Lennart Sorensen
This patched fixes building of ffmpeg 0.5.5-1 on powerpc for me. It matches what the code is now like in newer versions of ffmpeg. diff -urN ffmpeg-0.5.5/libavcodec/cavs.h ffmpeg-0.5.5.powerpcfix/libavcodec/cavs.h --- ffmpeg-0.5.5/libavcodec/cavs.h 2011-11-05 07:57:22.0 -0400 +++

Bug#639948: Bug#638250: Needs to be adapted for libav/0.7

2011-09-04 Thread Lennart Sorensen
On Sun, Sep 04, 2011 at 08:47:59AM +0200, Reinhard Tartler wrote: I strongly disagree that this arch specific defect on ppc is in any way a blocking bug for recompiling moc-ffmpeg-plugin against the new libav libraries. It only affects (some?) altivec enabled machines and can be easily

Bug#639948: Bug#638250: Needs to be adapted for libav/0.7

2011-09-04 Thread Lennart Sorensen
On Sun, Sep 04, 2011 at 04:13:52PM -0400, Lennart Sorensen wrote: Are there any that don't experience it? I just tried running ffmpeg on a power6+ machine under gdb and got: Program received signal SIGSEGV, Segmentation fault. 0x0f6ff37c in ff_fft_calc_altivec () at /root/libav-0.7.1