Bug#870676: ffmpeg requires NEON on armhf, which is not part of the ARMv7 ABI

2017-08-09 Thread Edmund Grimley Evans 
James:

> I think the runtime is working, but this is the testcase from the SIGBUS
> bug which you can use:
>
> ffmpeg -f lavfi -i testsrc=s=32x32:d=0.1 -strict -2 -c:v libx264rgb -f avi 
> libx264rgb.avi -y -hide_banner -nostdin
> ffmpeg -strict -2 -i libx264rgb.avi -t 1 -c:v rawvideo -c:a pcm_s32le -f nut 
> /dev/null -y -hide_banner -nostdin
>
> Since the SIGBUS bug occurs in NEON code, if the runtime detection is
> working, this will _only_ fail on machines with NEON and work on
> non-NEON machines.

This bug was closed while I was sleeping, but I will mention anyway
that with 7:3.3.3-1 those commands give a SIGBUS, as expected, but
only if /proc is mounted.

Presumably with the fixed version, 7:3.3.3-2, performance will be
measurably worse on a system with NEON when /proc is not mounted.

Upstream should probably switch to using getauxval(). Do you want to
suggest it to them?

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29

2017-08-06 Thread Edmund Grimley Evans 
On 5 August 2017 at 17:33, James Cowgill  wrote:
> Hi,
>
> On 04/08/17 09:58, Jiong Wang wrote:
>> Change
>>
>>   "adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB"
>>
>> Into:
>>
>> .eqv ff_h264_idct_add_neon_without_func_type, X(ff_h264_idct_add_neon)
>> adreq lr,  ff_h264_idct_add_neon_without_func_type +CONFIG_THUMB
>>
>> might be a solution.  The idea is we use .eqv to remove the function
>> attribute, so the assembler won't set LSB in any case.

> On the technical side, does having the LSB clear when executing a blx
> instruction cause a mode change out of Thumb, or does it retain the
> mode? I think all the code in that file is compiled in the same mode, so
> if the mode is retained then simply dropping +CONFIG_THUMB might work.

All the usual register branch instructions set or reset T32 (Thumb)
mode according to bit 0 of the target address. This is to enable
"interworking": an A32 function can call a T32 function and vice
versa.

What Jiong suggested, above, looks like the right solution for now.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#870676: ffmpeg requires NEON on armhf, which is not part of the ARMv7 ABI

2017-08-06 Thread Edmund Grimley Evans 
As far as I know, the best way to implement run-time detection of
hardware capabilities is with getauxval(AT_HWCAP) and
getauxval(AT_HWCAP2).

There is some kind of NEON detection in ffmeg. See, for example:

https://sources.debian.net/src/ffmpeg/7:3.3.3-1/libavutil/arm/cpu.c/

That code appears to use /proc rather than getauxval. Is there a good
reason for that?

In case someone reading this has access to hardware (or a simulator)
without NEON but is not familiar with ffmpeg, what is a quick and easy
way of checking whether ffmpeg is working?

There are other libraries in Debian that do run-time detection of
NEON: fftw3 is one, I think.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#870668: handbrake: Could this be "Architecture: any"?

2017-08-03 Thread Edmund Grimley Evans 
Source: handbrake
Version: 1.0.7+ds1-2
User: debian-...@lists.debian.org
Usertag: arm64

Could this be "Architecture: any"? It seems to build on arm64.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#846499: qstopmotion: FTBFS: tries to compare va_list to NULL

2017-06-07 Thread Edmund Grimley Evans 
The comparison makes no sense on any arch. Just replace "if (args !=
NULL)" with "if (1)".
It then builds on arm64.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#796532: kodi: FTBFS on arm64

2015-08-22 Thread Edmund Grimley Evans 
Source: kodi
Version: 15.1+dfsg1-2
Tags: patch

Thanks for sorting out the configuration on unknown architectures.

Here's a patch for arm64. You should probably reverse some of the
tests: test for Intel instead of listing all the non-Intel
architectures we can think of. But this patch did get it to build for
me on arm64.
diff -ru kodi-15.1+dfsg1.orig/xbmc/cores/DllLoader/DllLoader.h kodi-15.1+dfsg1/xbmc/cores/DllLoader/DllLoader.h
--- kodi-15.1+dfsg1.orig/xbmc/cores/DllLoader/DllLoader.h
+++ kodi-15.1+dfsg1/xbmc/cores/DllLoader/DllLoader.h
@@ -23,7 +23,7 @@
 #include coffldr.h
 #include LibraryLoader.h
 
-#if defined(__linux__)  !defined(__powerpc__)  !defined(__arm__)  !defined(__mips__)
+#if defined(__linux__)  !defined(__powerpc__)  !defined(__arm__)  !defined(__mips__)  !defined(__aarch64__)
 #define USE_LDT_KEEPER
 #include ldt_keeper.h
 #endif
diff -ru kodi-15.1+dfsg1.orig/xbmc/cores/DllLoader/ldt_keeper.c kodi-15.1+dfsg1/xbmc/cores/DllLoader/ldt_keeper.c
--- kodi-15.1+dfsg1.orig/xbmc/cores/DllLoader/ldt_keeper.c
+++ kodi-15.1+dfsg1/xbmc/cores/DllLoader/ldt_keeper.c
@@ -19,7 +19,7 @@
  */
 
 //#ifndef __powerpc__
-#if !defined(__powerpc__)  !defined(__ppc__)  !defined(__arm__)  !defined(__mips__)
+#if !defined(__powerpc__)  !defined(__ppc__)  !defined(__arm__)  !defined(__mips__)  !defined(__aarch64__)
 
 #include ldt_keeper.h
 
diff -ru kodi-15.1+dfsg1.orig/xbmc/cores/VideoRenderers/LinuxRendererGL.h kodi-15.1+dfsg1/xbmc/cores/VideoRenderers/LinuxRendererGL.h
--- kodi-15.1+dfsg1.orig/xbmc/cores/VideoRenderers/LinuxRendererGL.h
+++ kodi-15.1+dfsg1/xbmc/cores/VideoRenderers/LinuxRendererGL.h
@@ -323,7 +323,7 @@
 
 
 inline int NP2( unsigned x ) {
-#if defined(TARGET_POSIX)  !defined(__POWERPC__)  !defined(__PPC__)  !defined(__arm__)  !defined(__mips__)
+#if defined(TARGET_POSIX)  !defined(__POWERPC__)  !defined(__PPC__)  !defined(__arm__)  !defined(__mips__)  !defined(__aarch64__)
   // If there are any issues compiling this, just append a '  0'
   // to the above to make it '#if defined(TARGET_POSIX)  0'
 
diff -ru kodi-15.1+dfsg1.orig/xbmc/threads/Atomics.cpp kodi-15.1+dfsg1/xbmc/threads/Atomics.cpp
--- kodi-15.1+dfsg1.orig/xbmc/threads/Atomics.cpp
+++ kodi-15.1+dfsg1/xbmc/threads/Atomics.cpp
@@ -106,7 +106,7 @@
 ///
 long long cas2(volatile long long* pAddr, long long expectedVal, long long swapVal)
 {
-#if defined(__ppc__) || defined(__powerpc__) || defined(__arm__)// PowerPC and ARM
+#if defined(__ppc__) || defined(__powerpc__) || defined(__arm__) || defined(__aarch64__) // PowerPC and ARM
 // Not available/required
 // Hack to allow compilation
   throw cas2 is not implemented;
diff -ru kodi-15.1+dfsg1.orig/xbmc/utils/MathUtils.h kodi-15.1+dfsg1/xbmc/utils/MathUtils.h
--- kodi-15.1+dfsg1.orig/xbmc/utils/MathUtils.h
+++ kodi-15.1+dfsg1/xbmc/utils/MathUtils.h
@@ -35,7 +35,7 @@
 #if defined(__ppc__) || \
 defined(__powerpc__) || \
 defined(__mips__) || \
-defined(__arm__)
+defined(__arm__) || defined(__aarch64__)
   #define DISABLE_MATHUTILS_ASM_ROUND_INT
 #endif
 
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#789754: musescore: FTBFS on architectures with unsigned char

2015-06-24 Thread Edmund Grimley Evans 
Source: musescore
Version: 2.0.1+dfsg-2
Tags: patch

It is failing to build on several architectures with errors like:

/«BUILDDIR»/musescore-2.0.1+dfsg/libmscore/element.h:48:18: error: enumerator 
value -1 is outside the range of underlying type 'char'

See https://buildd.debian.org/status/package.php?p=musescoresuite=sid

Here's a patch:

perl -i -pe 's/char/signed char/ if /^enum class (Grip|NoteCaseType) : char/;' \
`find -name '*.h'`

One might want to change some other enums to signed char, for
consistency, but that patch is sufficient, it seems. Tested on
arm64.


((
I think there's another problem, not so easy to reproduce, some kind
of race condition that can occasionally result in:

Error copying file [...]/musescore-2.0.1+dfsg/all.h to 
[...]/musescore-2.0.1+dfsg/build.release/all.h.

But I doubt that's worth investigating. If it became a frequent
problem one could presumably just disable parallel building.
))

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#787905: openni: FTBFS on arm64

2015-06-06 Thread Edmund Grimley Evans 
Source: openni
Version: 1.5.4.0-10
Tags: patch

Here's a patch, rather similar to the ppc one.
diff -N -ru openni-1.5.4.0.orig/Include/Linux-AArch64/XnPlatformLinux-AArch64.h openni-1.5.4.0/Include/Linux-AArch64/XnPlatformLinux-AArch64.h
--- openni-1.5.4.0.orig/Include/Linux-AArch64/XnPlatformLinux-AArch64.h	1970-01-01 01:00:00.0 +0100
+++ openni-1.5.4.0/Include/Linux-AArch64/XnPlatformLinux-AArch64.h	2015-06-06 00:05:38.0 +0100
@@ -0,0 +1,43 @@
+/
+*   *
+*  OpenNI 1.x Alpha *
+*  Copyright (C) 2011 PrimeSense Ltd.   *
+*   *
+*  This file is part of OpenNI. *
+*   *
+*  OpenNI is free software: you can redistribute it and/or modify   *
+*  it under the terms of the GNU Lesser General Public License as published *
+*  by the Free Software Foundation, either version 3 of the License, or *
+*  (at your option) any later version.  *
+*   *
+*  OpenNI is distributed in the hope that it will be useful,*
+*  but WITHOUT ANY WARRANTY; without even the implied warranty of   *
+*  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
+*  GNU Lesser General Public License for more details.  *
+*   *
+*  You should have received a copy of the GNU Lesser General Public License *
+*  along with OpenNI. If not, see http://www.gnu.org/licenses/.   *
+*   *
+/
+#ifndef _XN_PLATFORM_LINUX_AARCH64_H_
+#define _XN_PLATFORM_LINUX_AARCH64_H_
+
+// Start with Linux-x86, and override what's different
+#include ../Linux-x86/XnPlatformLinux-x86.h
+
+//---
+// Platform Basic Definition
+//---
+#undef XN_PLATFORM
+#undef XN_PLATFORM_STRING
+#undef XN_PLATFORM_ENDIAN_TYPE
+#define XN_PLATFORM XN_PLATFORM_LINUX_AARCH64
+#define XN_PLATFORM_STRING Linux-AArch64
+
+#ifdef __AARCH64EB__
+#define XN_PLATFORM_ENDIAN_TYPE XN_PLATFORM_IS_BIG_ENDIAN
+#else
+#define XN_PLATFORM_ENDIAN_TYPE XN_PLATFORM_IS_LITTLE_ENDIAN
+#endif // __AARCH64EB__
+
+#endif //_XN_PLATFORM_LINUX_AARCH64_H_
diff -N -ru openni-1.5.4.0.orig/Include/XnOS.h openni-1.5.4.0/Include/XnOS.h
--- openni-1.5.4.0.orig/Include/XnOS.h	2015-06-06 00:13:43.0 +0100
+++ openni-1.5.4.0/Include/XnOS.h	2015-06-06 00:06:31.0 +0100
@@ -44,7 +44,7 @@
 //---
 #if (XN_PLATFORM == XN_PLATFORM_WIN32)
 	#include Win32/XnOSWin32.h
-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_ANDROID_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC)
+#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM == XN_PLATFORM_LINUX_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_AARCH64 || XN_PLATFORM == XN_PLATFORM_MACOSX || XN_PLATFORM == XN_PLATFORM_ANDROID_ARM || XN_PLATFORM == XN_PLATFORM_LINUX_POWERPC)
 	#include Linux-x86/XnOSLinux-x86.h
 #elif defined(_ARC)
 	#include ARC/XnOSARC.h
diff -N -ru openni-1.5.4.0.orig/Include/XnPlatform.h openni-1.5.4.0/Include/XnPlatform.h
--- openni-1.5.4.0.orig/Include/XnPlatform.h	2015-06-06 00:13:43.0 +0100
+++ openni-1.5.4.0/Include/XnPlatform.h	2015-06-06 00:07:21.0 +0100
@@ -36,6 +36,7 @@
 #define XN_PLATFORM_MACOSX 8
 #define XN_PLATFORM_ANDROID_ARM 9
 #define XN_PLATFORM_LINUX_POWERPC 10
+#define XN_PLATFORM_LINUX_AARCH64 11
 
 #define XN_PLATFORM_IS_LITTLE_ENDIAN 1
 #define XN_PLATFORM_IS_BIG_ENDIAN2
@@ -67,6 +68,8 @@
 	#include Linux-x86/XnPlatformLinux-x86.h
 #elif (__linux__  __arm__)
 	#include Linux-Arm/XnPlatformLinux-Arm.h
+#elif (__linux__  __aarch64__)
+	#include Linux-AArch64/XnPlatformLinux-AArch64.h
 #elif (__linux__  __powerpc__)
 	#include Linux-Powerpc/XnPlatformLinux-Powerpc.h
 #elif _ARC
diff -N -ru openni-1.5.4.0.orig/Include/XnUSBDevice.h openni-1.5.4.0/Include/XnUSBDevice.h
--- openni-1.5.4.0.orig/Include/XnUSBDevice.h	2015-06-06 00:13:43.0 +0100
+++ openni-1.5.4.0/Include/XnUSBDevice.h	2015-06-06 00:07:56.0 +0100
@@ -48,7 +48,7 @@
 	#define USB_DT_DEVICE_SIZE 0
 	#define USB_DT_DEVICE 0
 
-#elif (XN_PLATFORM == XN_PLATFORM_LINUX_X86 || XN_PLATFORM

Bug#783824: pd-chaos: FTBFS on arm64

2015-04-30 Thread Edmund Grimley Evans 
Source: pd-chaos
Version: 0.2-1

It failed to build on arm64. The error was:

cc -I/usr/include/pd -DPD -DVERSION='0.2' -fPIC -Wall -W -g -O6
-funroll-loops -fomit-frame-pointer -o libchaos.o -c libchaos.c
libchaos.c: In function 'lyapunov_eval':
libchaos.c:29:3: error: too many arguments to function 'calc'
   calc(fractal, vars);
   ^
libchaos.c:30:3: error: too many arguments to function 'calc'
   calc(fractal, test);
   ^

See aarch64-specific definition of t_gotfn in /usr/include/pd/m_pd.h.
However, the comment there might be misleading and this could be a bug
in puredata.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#783838: blender: FTBFS in Jessie

2015-04-30 Thread Edmund Grimley Evans 
Source: blender
Version: 2.72.b+dfsg0-3

It failed to build in Jessie, amd64 and arm64. In each case the error
was:

/«BUILDDIR»/blender-2.72.b+dfsg0/source/blender/blenfont/intern/blf_glyph.c: In
function 'blf_glyph_add':
/«BUILDDIR»/blender-2.72.b+dfsg0/source/blender/blenfont/intern/blf_glyph.c:265:13:
error: conversion to 'int' from 'unsigned int' may change the sign of
the result [-Werror=sign-conversion]
  g-width = bitmap.width;
 ^
/«BUILDDIR»/blender-2.72.b+dfsg0/source/blender/blenfont/intern/blf_glyph.c:266:14:
error: conversion to 'int' from 'unsigned int' may change the sign of
the result [-Werror=sign-conversion]
  g-height = bitmap.rows;
  ^
cc1: some warnings being treated as errors

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#772568: libsoxr: FTBFS on several architectures

2014-12-08 Thread Edmund Grimley Evans 
Source: libsoxr
Version: 0.1.1-1

I reported this to debian-arm a while ago:

http://lists.debian.org/debian-arm/2014/11/msg00016.html

I'm now reporting it as a bug because I have seen the same failure in
a fresh chroot on amd64. The last part of the log is:

The following tests FAILED:
  1 - 20-bit-perfect-44100-96000 (Failed)
  2 - 20-bit-perfect-96000-44100 (Failed)
  3 - 20-bit-perfect-44100-65537 (Failed)
  4 - 20-bit-perfect-65537-44100 (Failed)
  5 - 24-bit-perfect-44100-96000 (Failed)
  6 - 24-bit-perfect-96000-44100 (Failed)
  7 - 24-bit-perfect-44100-65537 (Failed)
  8 - 24-bit-perfect-65537-44100 (Failed)

As you can see, it worked on the arm64 and ppc64el buildds 107 days ago:

http://buildd.debian.org/status/package.php?p=libsoxrsuite=sid

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#762016: ladish FTBFS on parisc architecture, patch attached

2014-11-18 Thread Edmund Grimley Evans 
While you're at it, could you add defined(__aarch64__) to that test
so that it will build on arm64?

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers