Bug#873586: lua-torch-torch7: please add arm64

2017-10-31 Thread Edmund Grimley Evans
As described in https://github.com/torch/torch7/issues/1035, it seems that LuaJIT provides only "a limited range of 47 bits for the legacy lightuserdata data type". Therefore, lua-torch-torch7 can only be built and run on systems that use virtual addresses with no more than 47 bits. Today many

Bug#861281: rnahybrid: FTBFS on armel

2017-09-28 Thread Edmund Grimley Evans
I was able to build rnahybrid 2.1.2-3 on armel in 104 minutes on some more powerful hardware. I must definitely retract what I've said about an "infinite loop". Replacing loop nests with memset did not make a huge difference (I gave up after 26 minutes).

Bug#876825: gcc: not-actually-infinite loop targeting armel

2017-09-28 Thread Edmund Grimley Evans
Yes, it's not an infinite loop; it just takes an inordinate amount of time. The code that triggers this seems to be a long sequence of assignments initialising elements of a multi-dimensional array. There are some big variations in the build times on some other architectures, too. For example on

Bug#861281: rnahybrid: FTBFS on armel

2017-09-27 Thread Edmund Grimley Evans
Those loop nests that set every element of a multi-dimensional array to (floating-point) zero could perhaps be replaced with memset (not officially portable) or memcpy (from a local variable of the same type with an initialiser).

Bug#876825: gcc: infinite loop targeting armel

2017-09-27 Thread Edmund Grimley Evans
The problem still seems to occurs with: - version 6.4.0-3cross1 of gcc-6-arm-linux-gnueabi (on amd64) - version 7.2.0-7 of gcc-7 (on armel) It's perhaps not really an infinite loop but just an unreasonably long time. Perhaps someone should try running it over the weekend...

Bug#861281: rnahybrid: FTBFS on armel

2017-09-27 Thread Edmund Grimley Evans
For what it's worth, rnahybrid seems to build on armel with this in debian/rules: export DEB_CFLAGS_MAINT_APPEND=-O0 Perhaps it would work with -O1 if I had more patience.

Bug#861281: rnahybrid: FTBFS on armel

2017-09-26 Thread Edmund Grimley Evans
> The failure in build may in fact just be because the build machine is > too slow. It's a possibility to bear in mind, definitely, but the perhaps-infinite loop can be observed with a cross-compiler: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876825 (I will test with the compilers in

Bug#861281: rnahybrid: FTBFS on armel

2017-09-26 Thread Edmund Grimley Evans
The infinite loop is still there with gcc-7. I've created bug #876825. Before you exclude armel, you could perhaps try doing something about this warning, which is given not just on armel and may or may not be related to the compiler going into an infinite loop: energy.c:539:104: warning:

Bug#876825: gcc: infinite loop targeting armel

2017-09-26 Thread Edmund Grimley Evans
Package: gcc-6-arm-linux-gnueabi Version: 6.3.0-18cross1 This is not specific to cross-compiling and not even to gcc-6. We noticed the infinite loop when the buildd tries to build rnahybrid: https://buildd.debian.org/status/logs.php?pkg=rnahybrid=armel It seems to be easy to reproduce with the

Bug#818616: luajit: laujit segfaults on arm64

2017-09-21 Thread Edmund Grimley Evans
I think this bug was fixed in 2.1.0~beta3. Can it be closed please? Any objections? # tail -n 1 /proc/self/maps eb71-eb731000 rw-p 00:00 0 [stack] # dpkg -i libluajit-5.1-2_2.1.0~beta2+dfsg-1_arm64.deb

Bug#874549: jellyfish1: Please add arm64

2017-09-07 Thread Edmund Grimley Evans
Source: jellyfish1 Version: 1.1.11-1 User: debian-...@lists.debian.org Usertags: arm64 This package builds on arm64 if you change the type of dna_codes from "char" to "signed char": perl -i -pe 's/char/signed char/;' jellyfish/dna_codes.cc jellyfish/dna_codes.hpp It may build on other

Bug#873866: [Debian-med-packaging] Bug#873866: tophat: Please add arm64

2017-09-04 Thread Edmund Grimley Evans
> Well, technically it might be correct, but I doubt that there is a > working pipeline involving tophat, bowtie and friends on non-amd64 > architectures. On the other hand, if you have a heterogeneous cluster then perhaps you don't need or want all elements of the pipeline to run on the same

Bug#873866: tophat: Please add arm64

2017-09-04 Thread Edmund Grimley Evans
> It might be that tophat builds on other architectures but it Depends > bowtie2 | bowtie and these are only available on the explicitly > specified architectures. Bowtie2 is not yet available on arm64, but bowtie is, so a dependency on "bowtie2 | bowtie" should not be an obstacle.

Bug#871697: jellyfish: Please add arm64

2017-09-01 Thread Edmund Grimley Evans
> unfortunately the bug does not seem to be sufficient. See > > > https://buildd.debian.org/status/fetch.php?pkg=jellyfish=arm64=2.2.6-5=1504220784=0 > > Any further hints? "portability.patch" is commented out in debian/patches/series and was not applied?

Bug#873866: tophat: Please add arm64

2017-08-31 Thread Edmund Grimley Evans
Source: tophat Version: 2.1.1+dfsg-3 User: debian-...@lists.debian.org Usertags: arm64 It seems to be possible to build this package on arm64. Is there any reason why it would not work on arm64?

Bug#873864: mrs: Please add arm64

2017-08-31 Thread Edmund Grimley Evans
Source: mrs Version: 6.0.5+dfsg-2 User: debian-...@lists.debian.org Usertags: arm64 It seems to be possible to build this package on arm64. Is there any reason why it would not work on arm64?

Bug#873865: relion: Please add arm64

2017-08-31 Thread Edmund Grimley Evans
Source: relion Version: 1.4+dfsg-2 User: debian-...@lists.debian.org Usertags: arm64 It seems to be possible to build this package on arm64. Is there any reason why it would not work on arm64?

Bug#873859: gasic: Please add arm64

2017-08-31 Thread Edmund Grimley Evans
Source: gasic Version: 0.0.r19-1 User: debian-...@lists.debian.org Usertags: arm64 It seems to be possible to build this package on arm64. Is there any reason why it would not work on arm64?

Bug#780428: beast-mcmc: or replace "amd64" with "any"?

2017-08-31 Thread Edmund Grimley Evans
It might be possible to replace libnucleotidelikelihoodcore0's "Architecture: amd64" with "Architecture: any". It seems to build and install on arm64 at least. (I've not tried using it.)

Bug#871697: jellyfish: Please add arm64

2017-08-31 Thread Edmund Grimley Evans
Instead of: "pand " off It should be: "pand " #off (It may be necessary to disable "-Werror": an unrelated issue.)

Bug#873586: lua-torch-torch7: please add arm64

2017-08-29 Thread Edmund Grimley Evans
Source: lua-torch-torch7 Version: 0~20170720-gaed3171-2 User: debian-...@lists.debian.org Usertags: arm64 This package may work on arm64 now that luajit is available on that architecture.

Bug#800546: guymager: please add arm64

2017-08-17 Thread Edmund Grimley Evans
> Why I don't use "Architecture: any" in guymager is that its > Build-Dependency libguytools2 is known to support only those > architectures: > > Architecture: i386 amd64 powerpc armhf arm64 > > If I'm using "Architecture: any" in guymager and it fails to build > on those unsupported

Bug#871697: jellyfish: Please add arm64

2017-08-10 Thread Edmund Grimley Evans
Source: jellyfish Version: 2.2.6-1 User: debian-...@lists.debian.org Usertags: arm64 Jellyfish seems to be easy to port. Just provide alternatives to the inline assembler in rectangular_binary_matrix.hpp: #ifdef __x86_64__ #define AND_XOR(off)\

Bug#813559: ngs-sdk: FTBFS: most platforms explicitly unsupported

2017-08-10 Thread Edmund Grimley Evans
It was very easy to "build" this package on arm64. All I did was: * Modify each konfigure.perl to set $BITS = 64 instead of die "unrecognized Architecture '$ARCH'". * Provide ngs-sdk/ngs/unix/aarch64/atomic32.h containing stubs. Now, if you wanted the package to actually work, you would

Bug#871696: ggcov: Please add arm64

2017-08-10 Thread Edmund Grimley Evans
Source: ggcov Version: 0.9-15 User: debian-...@lists.debian.org Usertags: arm64 Would it be possible to add arm64? With gcc-7 there's #853417, but with gcc-6 the only test failure on arm64 is test033, where all the asserts are "PC" rather than "CO", and the abort is "UN" rather than "SU". Does

Bug#724711: [Debian-med-packaging] Bug#724711: insighttoolkit4: Drops architecture support

2017-08-10 Thread Edmund Grimley Evans
> As far as I can see all tests are disabled, failing tests means that > the software has bugs, and I'm not sure whether we want to allow > software with known bugs into the archives. Yes, but if the bug is in the test then disabling the test is one way of fixing the bug. On the other hand, a

Bug#871593: mlucas: Please add arm64

2017-08-09 Thread Edmund Grimley Evans
Source: mlucas Version: 14.1-2 User: debian-...@lists.debian.org Usertags: arm64 This package can easily be ported to arm64: in src/platform.h recognise the architecture with defined(__aarch64__) and configure it the same as amd64. Also, the many mentions of "unknown" in platform.h suggest that

Bug#724711: insighttoolkit4: Drops architecture support

2017-08-09 Thread Edmund Grimley Evans
Control: user debian-...@lists.debian.org Control: usertag -1 + arm64 Please consider adding arm64. Ubuntu built 4.9.0, 4.10.0 and 4.10.1 on arm64: http://ports.ubuntu.com/ubuntu-ports/pool/universe/i/insighttoolkit4/ Though it looks like they may have ignored a few test failures to get there:

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

Bug#871515: picolisp: Please add arm64

2017-08-08 Thread Edmund Grimley Evans
Source: picolisp Version: 17.6-1 User: debian-...@lists.debian.org Usertags: arm64 The arm64 version of PicoLisp was announced on 16 Nov 2015: http://www.mail-archive.com/picolisp@software-lab.de/msg05727.html And "arm64" is mentioned in INSTALL:

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,

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

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.

Bug#791976: Please support ARM64

2017-07-25 Thread Edmund Grimley Evans
This is being worked on upstream: https://github.com/ldc-developers/ldc/issues/1931 https://github.com/ldc-developers/ldc/issues/2150 https://github.com/ldc-developers/ldc/issues/2153

Bug#868165: emacs25: FTBFS on arm64

2017-07-21 Thread Edmund Grimley Evans
The Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/emacs25/+bug/1656474 Memory corruption reported on mailing list: http://lists.gnu.org/archive/html/emacs-devel/2017-03/msg00827.html It looks like Emacs Lisp may be involved. Does Emacs Lisp use tagged pointers? Pointers have fairly

Bug#867273: purify FTBFS on arm64 due to long-running test

2017-07-05 Thread Edmund Grimley Evans
I think that test takes a long time because it is using long double, which on arm64 has 128 bits and is implemented in software. Possible things to do: * Change the default type (however and wherever it is defined) from "long double" to "double" on arm64, and perhaps other architectures. * Get

Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

2017-06-29 Thread Edmund Grimley Evans
This robopatch seems to fix the problem on arm64 with 48-bit addresses: perl -i -pe 's/longlong/ulonglong/g if /\(\s*longlong.*(<<|>>)/ && !/gen\(longlong/;' src/*.cc The idea is to change the type whenever there seems to be a cast followed by a shift. The last condition is to avoid a couple of

Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

2017-06-29 Thread Edmund Grimley Evans
So giac was supposed to be working now on arm64, but it failed on the buildd: https://buildd.debian.org/status/package.php?p=giac=sid Having recently seen something similar I think I can guess what's happening. User virtual addresses on Linux arm64 may have 39, 42 or 48 bits, depending on how

Bug#864847: ghc: on armhf should not use deprecated memory barrier instructions

2017-06-15 Thread Edmund Grimley Evans
Source: ghc Version: 8.0.1-17+b1 If I try to run "ghc" in one of my armhf chroots, it does not work very well: $ ghc Illegal instruction The offending instruction is this one: mcr 15, 0, r6, cr7, cr10, {5} This is, I think, an ARMv6 memory barrier, and these instructions are, if I recall

Bug#864846: ghc: on armhf should have load address of at least 0x10000

2017-06-15 Thread Edmund Grimley Evans
Source: ghc Version: 8.0.1-17+b1 If I try to run "ghc" in one of my armhf chroots, it does not work very well: $ ghc Segmentation fault $ wget http://ftp.debian.org/debian/pool/main/g/ghc/ghc_8.0.1-17+b1_armhf.deb $ ar pf ghc_8.0.1-17+b1_armhf.deb data.tar.xz | tar xJf - $ readelf -l

Bug#864809: gocryptfs: FTBFS: "does not implement nodefs.File (missing Flock method)"

2017-06-15 Thread Edmund Grimley Evans
Source: gocryptfs Version: 1.2.1-1 Severity: serious This arm64 build log shows the error: https://buildd.debian.org/status/fetch.php?pkg=gocryptfs=arm64=1.2.1-1=1497480941=0 The same error also happens on amd64 with the latest golang-github-hanwen-go-fuse-dev from unstable,

Bug#599993: u3-tool: Unsupported architectures

2017-06-14 Thread Edmund Grimley Evans
Control: user debian-...@lists.debian.org Control: usertag -1 + arm64 It built on arm64 when I tried it. I didn't test it in any other way, but perhaps you could add "arm64" to the Architecture line (replacing the obsolete "arm").

Bug#832502: xorp: Build for arm too

2017-06-14 Thread Edmund Grimley Evans
Control: user debian-...@lists.debian.org Control: usertag -1 + arm64 No experimentation seems to be required. Ubuntu's "xorp_1.8.6~wip.20160715-2ubuntu1" is identical to Debian's "xorp_1.8.6~wip.20160715-2" apart from debian/changelog and debian/control, where Ubuntu has "Architecture: any".

Bug#618273: gambc: Version upgrade request

2017-06-13 Thread Edmund Grimley Evans
An update to this ancient bug: Debian is still on version 4.2.8, released in 2008, and is including this antique version with Stretch. Upstream is now on 4.8.8, released in Feb 2017. It looks as though Fedora has version 4.8.8, packaged under the name "gambit-c", with "aarch64" (~ arm64) and

Bug#864682: xine-plugin: FTBFS on arm64

2017-06-12 Thread Edmund Grimley Evans
Source: xine-plugin Version: 1.0.2-4 User: debian-...@lists.debian.org Usertags: arm64 On arm64 it failed to build like this (see https://buildd.debian.org/status/package.php?p=xine-plugin=sid): In file included from ../include/prtypes.h:58:0, from ../include/npapi.h:51,

Bug#760701: "make check" has runaway memory usage on arm64

2017-06-12 Thread Edmund Grimley Evans
The pattern of failures certainly looks like that of a program that assumes char is signed... and, indeed, this seems to fix it: - In io.web, change the return type of get() and peek() from char to int. - In scan.web, change the type of prev_char, curr_char and next_char from char to int.

Bug#727388: id-utils: run dh-autoreconf to update config.{sub,guess} and {libtool,aclocal}.m4

2017-06-12 Thread Edmund Grimley Evans
I was able to build this package on arm64 after adding "dh_autoreconf" just before the "./configure" line, and "dh_autoreconf_clean" just before "dh_clean", in debian/rules. One must presumably also add "dh-autoreconf" to the Build-Depends.

Bug#728988: libpacklib1-dev: crash on call to hropen

2017-06-09 Thread Edmund Grimley Evans
Trying this same short program with version 20061220+dfsg3-4.3 of cernlib in a Stretch chroot on amd64: $ gfortran hbktst.f -o hbktst `cernlib packlib` $ ./hbktst RZMAKE. Unit 1003 Initializing with LREC= 1024, OPT= X?C LOCB/LOCF:

Bug#856234: haskell-cryptol FTBFS on !x86: #error unknown max width for gmp on this architecture

2017-06-07 Thread Edmund Grimley Evans
This is easy to fix: in "Arch.hs" just use the smaller value of maxBigIntWidth on any unrecognised architecture.

Bug#863139: mongo-tools FTBFS on arm64: _build/src/github.com/spacemonkeygo/spacelog/capture_other.go:26: undefined: syscall.Dup2

2017-06-07 Thread Edmund Grimley Evans
The fix is described here: https://github.com/spacemonkeygo/spacelog/issues/6 Add golang-golang-x-sys-dev to the Build-Depends, and in capture_other.go replace "syscall" with "golang.org/x/sys/unix", and each "syscall." with "unix.".

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.

Bug#863140: libretro-desmume FTBFS everywhere except armhf and x86: src/utils/AsmJit/x86/x86cpuinfo.cpp:151:56: error: impossible constraint in asm

2017-06-07 Thread Edmund Grimley Evans
I was able to build this package on arm64 by disabling the "JIT" as follows. Please implement something similar in the next upload. --- libretro-desmume-0.9.11+git20160819+dfsg1.orig/debian/rules +++ libretro-desmume-0.9.11+git20160819+dfsg1/debian/rules @@ -12,11 +12,15 @@

Bug#863998: golang-defaults: Getpagesize() always returns 65536 on arm64

2017-06-02 Thread Edmund Grimley Evans
Source: golang-defaults Version: 2:1.7~5 User: debian-...@lists.debian.org Usertags: arm64 This issue has been fixed upstream and in 1.8: https://github.com/golang/go/issues/13191 If you follow the links from there you can read how this bug apparently affects Kubernetes and how the fix has been

Bug#863994: golang-github-hanwen-go-fuse: PAGESIZE is fixed at 4096

2017-06-02 Thread Edmund Grimley Evans
Source: golang-github-hanwen-go-fuse Version: 0.0~git20161210.0.6c2b7d8-2 Control: affects -1 + gocryptfs "const PAGESIZE = 4096": https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hanwen-go-fuse.git/tree/fuse/types.go#n11 This is not portable. On arm64, the page size can be 4096,

Bug#838424: casacore: FTBFS on arm64 and s390x: several tests fail

2017-06-01 Thread Edmund Grimley Evans
The tests "tStatisticsUtilities" and "tLatticeStatistics" can be made to pass on arm64 with these adjustments to the expected accuracy: --- casacore-2.2.0.orig/lattices/LatticeMath/test/tLatticeStatistics.cc +++ casacore-2.2.0/lattices/LatticeMath/test/tLatticeStatistics.cc @@ -419 +419 @@ -

Bug#835108: lepton: probably using its own "md5.h" but calling system library functions

2017-05-27 Thread Edmund Grimley Evans
It seems to me likely that both #835108 and #853479 are caused by the thing I mentioned at 2.1 in #863446: the program uses the "md5.h" included in the package's source, but calls the system library functions, which use a different MD5_CTX.

Bug#863446: lepton: Please make "Architecture: any"

2017-05-26 Thread Edmund Grimley Evans
Source: lepton Version: 1.2.1+20170405-1 I was able to build it on arm64 with just a few changes: 1. Change to "Architecture: any" in debian/control, obviously. 2. In debian/rules, use: CPPFLAGS="-DUSE_SYSTEM_MD5_DEPENDENCY" dh_auto_configure -- --enable-system-dependencies

Bug#791976: ldc: Please support ARM64

2017-05-24 Thread Edmund Grimley Evans
I've played a bit with trying to build this package on arm64: sudo apt-get install ... dpkg-source -x ldc*.dsc cd ldc-1.1.1/ dpkg-buildpackage -b -d The first five or so errors were compile-time "static assert" errors in code that looks like floating-point library code. In each case I could

Bug#863192: python-numpy: numpy.abs(numpy.nan) inconsistently gives RuntimeWarning

2017-05-23 Thread Edmund Grimley Evans
This has been fixed upstream. The fix is here: https://github.com/numpy/numpy/pull/8713 https://github.com/numpy/numpy/commit/2fe5a4757e840362b7158e8548e26ffc9ef8b562 Only the one-line addition to loops.c.src is required; the rest is a test. Could we have this fixed in Stretch?

Bug#863192: python-numpy: numpy.abs(numpy.nan) inconsistently gives RuntimeWarning

2017-05-23 Thread Edmund Grimley Evans
Package: python-numpy Version: 1:1.12.1-2 On amd64: $ python Python 2.7.13 (default, Jan 19 2017, 14:48:08) [GCC 6.3.0 20170118] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> abs(numpy.nan) nan >>> numpy.abs(numpy.nan) nan >>> On arm64: $

Bug#861249: FTBFS: math_test.Vector2TypeTest.test_cross fails

2017-05-21 Thread Edmund Grimley Evans
On arm64 and at least one other architecture, the error says: -3.2862601528904633e-16 != 0 It looks as though the test is computing (1.2 * 3.4 - 3.4 * 1.2). Now, the log to base 2 of (1.2 * 3.4) divided by 3.286e-16 is about 53.5. There are 52 bits in the mantissa of a 64-bit float, or 53

Bug#862919: traildb: FTBFS on non-x86: emmintrin.h absent

2017-05-21 Thread Edmund Grimley Evans
The package builds on arm64 if you comment out the "HAVE_SSE2" line in configure.ac, so replacing the unconditional AC_DEFINE with an actual test seems like a good first step.

Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

2017-05-17 Thread Edmund Grimley Evans
I was able to build giac 1.2.3.25+dfsg1-3 on arm64 with this "patch": perl -i -pe 's/^#ifdef __x86_64__$/#if 1/;' src/gen.h perl -i -pe 's/^#ifndef __x86_64__$/#if 0/;' src/first.h Obviously that change would break it on 32-bit architectures. A proper fix might be to use something like

Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

2017-05-12 Thread Edmund Grimley Evans
On arm64, if you run under GDB and look at the address that faulted it's clear that the address has been truncated to 32 bits. And there's some obvious code in src/gen.h that looks as if it's truncating addresses to 32 bits on any architecture that isn't x86_64. However, I don't think gen.h is the

Bug#862360: llvm-toolchain-3.8: Fix R_AARCH64_MOVW_UABS_G3 relocation

2017-05-12 Thread Edmund Grimley Evans
You don't have this patch, I think: https://reviews.llvm.org/D22095

Bug#862360: llvm-toolchain-3.8: Fix R_AARCH64_MOVW_UABS_G3 relocation

2017-05-12 Thread Edmund Grimley Evans
> Unfortunately, this one line fix does not solve the problem of the LLVM > build hanging during the sanitizer tests. > > Both issues appeared around the same time and seem to be linked to specific > kernel versions. Julia started failing when the kernel started using more bits in virtual

Bug#861484: julia: FTBFS on arm64

2017-05-11 Thread Edmund Grimley Evans
This problem is caused by: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862360 How I discovered this, would be a long story. The effect of the LLVM bug is to OR the register field of a "movz xD, #IMM, lsl #48" with bits 43-47 of an address. With some kernels those bits are always zero, so

Bug#862360: llvm-toolchain-3.8: Fix R_AARCH64_MOVW_UABS_G3 relocation

2017-05-11 Thread Edmund Grimley Evans
Source: llvm-toolchain-3.8 Version: 1:3.8.1-23 Please apply this upstream bug fix to Debian's llvm-toolchain-3.8 before the release: https://reviews.llvm.org/D27609?id=80860 See line 360 of RuntimeDyldELF.cpp. The bug prevents julia from running on some arm64 systems and may have other bad

Bug#857855: redis FTBFS on arm64: Executing test client: NOREPLICAS Not enough good slaves to write..

2017-05-02 Thread Edmund Grimley Evans
It built on arm64 on the second attempt. So you can probably downgrade this bug, or close it altogether if nobody can reproduce the build failure.

Bug#845786: gammaray FTBFS on arm64, armel, mips* and s390x: QFatal in quickinspectortest

2017-05-02 Thread Edmund Grimley Evans
It worked on arm64 on the third attempt. The second failure was different from the first failure. So perhaps worth trying several times on other architectures.

Bug#861281: rnahybrid: FTBFS on armel

2017-04-28 Thread Edmund Grimley Evans
There may be no demand for this package (rnahybrid) on armel, but the FTBFS might be caused by a bug in gcc-6, which would be worth reporting if someone can confirm it.

Bug#858548: ntp: Use of CLOCK_TAI should return correct value

2017-03-23 Thread Edmund Grimley Evans
Source: ntp Version: 1:4.2.8p10+dfsg-1 Severity: wishlist I posted a question to debian-users (https://lists.debian.org/debian-user/2017/03/msg00591.html) and nobody said "This already works" or "This is a bad idea", so I'm filing this bug. It would be nice if clock_gettime(CLOCK_TAI, ...) would

Bug#856056: tangerine: FTBFS on arm64

2017-02-24 Thread Edmund Grimley Evans
Source: tangerine Version: 0.3.4-6 Tags: patch User: debian-...@lists.debian.org Usertags: arm64 It failed to build on arm64: http://buildd.debian.org/status/package.php?p=tangerine=sid The error was: src/inotify-syscalls.h:47:3: error: #error "Unsupported architecture!" # error "Unsupported

Bug#835567: installation-reports: Debian testing failed to install on ThinkPad T43p

2016-08-27 Thread Edmund Grimley Evans
Me: > Another thing: I went for "Graphical install" but ended up using the > keyboard rather than the mouse. If I remember correctly, buttons at > the bottom of the screen were not accessible using the mouse because > the mouse pointer would wrap around back to the top of the screen a > few

Bug#835567: installation-reports: Debian testing failed to install on ThinkPad T43p

2016-08-27 Thread Edmund Grimley Evans
Package: installation-reports Yesterday I tried to install Debian testing on a ThinkPad T43p using the then current version of debian-testing-i386-netinst.iso, which was dated 2016-08-22. I chose the default at almost all stages and everything seemed to work up to the bit where it told me to

Bug#789771: mono: please add arm64

2016-04-01 Thread Edmund Grimley Evans
An "ARM64 port of the Mono runtime" has been released under the MIT licence, according to this announcement (31 Mar 2016): http://www.mono-project.com/news/2016/03/31/mono-relicensed-mit/ Source code seems to be here: https://github.com/mono/mono

Bug#818737: gpx: FTBFS on many architectures

2016-03-20 Thread Edmund Grimley Evans
Source: gpx Version: 2.4.1+markwal-1 User: debian-...@lists.debian.org Usertags: arm64 It failed to build on many architectures, apparently the ones with plain char unsigned: https://buildd.debian.org/status/package.php?p=gpx=sid The error was an infinite loop and a time-out: make[3]: ***

Bug#814530: libcereal: uninstallable on architectures without multilib

2016-02-12 Thread Edmund Grimley Evans
Source: libcereal Version: 1.1.2-3 User: debian-...@lists.debian.org Usertags: arm64 Thanks for applying the upstream patch that fixes what appeared to be a problem for architectures with unsigned plain char. Version 1.1.2-3 builds on arm64 if you remove the Build-Depends on g++-multilib. The

Bug#814040: afnix: FTBFS on arm64

2016-02-07 Thread Edmund Grimley Evans
Source: afnix Version: 2.6.2-1 Tags: patch User: debian-...@lists.debian.org Usertags: arm64 It failed to build on arm64: https://buildd.debian.org/status/package.php?p=afnix=sid The error was: ./cnf/bin/afnix-setup -o --prefix=/usr afnix-setup: cannot determine linking type I'm attaching a

Bug#813101: nordlicht: FTBFS on various architectures

2016-01-29 Thread Edmund Grimley Evans
Source: nordlicht Version: 0.4.4-1 Tags: patch User: debian-...@lists.debian.org Usertags: arm64 It failed to build on ARM architectures and presumably on other architectures with plain char unsigned: https://buildd.debian.org/status/package.php?p=nordlicht=sid There's a "char c" in main.c.

Bug#810505: irqbalance: FTBFS on arm64

2016-01-09 Thread Edmund Grimley Evans
Source: irqbalance Version: 1.1.0-1 Tags: patch User: debian-...@lists.debian.org Usertags: arm64 It failed to build on arm64: https://buildd.debian.org/status/package.php?p=irqbalance=sid It built with the attached patch, which corrects two typos, apparently. diff -ru

Bug#765200: dbacl: run dh-autoreconf to update for new architectures

2016-01-05 Thread Edmund Grimley Evans
Control: tags -1 patch Here's a patch made by following the instructions at https://wiki.debian.org/Autoreconf It seems to work on arm64. diff -ru dbacl-1.12.orig/debian/control dbacl-1.12/debian/control --- dbacl-1.12.orig/debian/control +++ dbacl-1.12/debian/control @@ -1,7 +1,7 @@ Source:

Bug#807830: arm: -fstack-protector-strong adds dependency on ld-linux-aarch64.so.1 on arm64

2015-12-21 Thread Edmund Grimley Evans
I'd say this is a bug in dpkg-shlibdeps in dpkg-dev. Referring to the example above, on arm64 "test" does depend on ld-linux-aarch64.so.1 because, although "__stack_chk_guard" is defined in "test", there's also a relocation referring to the one in /lib/ld-linux-aarch64.so.1: $ nm test | grep

Bug#807701: julia: FTBFS on arm64

2015-12-11 Thread Edmund Grimley Evans
Source: julia Version: 0.4.2-2 Tags: patch User: debian-...@lists.debian.org Usertags: arm64 It failed to build on arm64: https://buildd.debian.org/status/package.php?p=julia=sid The error was: signal (6): Aborted gsignal at /lib/aarch64-linux-gnu/libc.so.6 (unknown line) Aborted The problem

Bug#806675: hmmer: nhmmer fails with fatal exception on armhf

2015-12-02 Thread Edmund Grimley Evans
> Presumably you can manually configure it to use the "dummy" > implementation on an Intel processor. Does that work? It appears not to. The 3 failures that occurred on armhf can be obtained on amd64 thus: ./configure --enable-dummy make make check

Bug#806675: hmmer: nhmmer fails with fatal exception on armhf

2015-12-02 Thread Edmund Grimley Evans
ftp://selab.janelia.org/pub/software/hmmer3/3.1b2/Userguide.pdf says: """ Processor: HMMER depends on vector parallelization methods that are supported on most modern processors. H3 requires either an x86-compatible (IA32, IA64, or Intel64) processor that supports the SSE2 vector instruction set,

Bug#806675: hmmer: nhmmer fails with fatal exception on armhf

2015-12-01 Thread Edmund Grimley Evans
A lot of the test failures seen in https://buildd.debian.org/status/fetch.php?pkg=hmmer=arm64=3.1b2-1=1436134634 are not easily reproducible. For example, when I tried cd testsuite/ touch tmp ; rm tmp* ; ./i9-optional-annotation.pl .. .. tmp it gave "ok" most of the time, but every now

Bug#806705: quantlib: fails to build on some arm64 buildds

2015-11-30 Thread Edmund Grimley Evans
> Should we even consider not building at all? I think you should build it on arm64, where it could easily be useful. I'm not so sure about people using quantlib on armel systems, which are typically very low-performance, but, seeing as it builds there (without the tests), I don't see a reason

Bug#806705: quantlib: fails to build on some arm64 buildds

2015-11-30 Thread Edmund Grimley Evans
Source: quantlib Version: 1.7-1 User: debian-...@lists.debian.org Usertags: arm64 You've probably noticed that quantlib sometimes fails to build on the arm64 builds: https://buildd.debian.org/status/logs.php?pkg=quantlib=arm64 The symptoms are: make[4]: Entering directory

Bug#806300: s-nail: FTBFS on arm64,...

2015-11-26 Thread Edmund Grimley Evans
Source: s-nail Version: 14.8.5-2 User: debian-...@lists.debian.org Usertags: arm64 It failed to build on several architectures: https://buildd.debian.org/status/package.php?p=s-nail=sid It seems to go into an infinite loop while running tests. This symptom and the pattern of failures is

Bug#805621: miller: FTBFS on many architectures

2015-11-20 Thread Edmund Grimley Evans
Source: miller Version: 2.3.2-1 User: debian-...@lists.debian.org Usertags: arm64 It failed to build on many architectures: http://buildd.debian.org/status/package.php?p=miller=sid In some cases the error was: FAIL: test_peek_file_reader I noticed this line of code in there:

Bug#786905: tcc miscompiles current GMP on x86{, _64} (tcc_0.9.26-1 compiles correctly)

2015-11-20 Thread Edmund Grimley Evans
Thank you for the interesting bug report! The test case reveals two bugs in the old version of tcc: firstly, "1 ? 1 : 1" was not recognised as a constant expression, so "unsigned ip[1 ? 1 : 1]" was treated as a variable-length array (VLA), and, secondly, there was a bug in the handling of VLAs.

Bug#789170: tcc: problem with const array argument

2015-11-19 Thread Edmund Grimley Evans
I think this bug was fixed by this upstream commit: commit 30c54c9d433f5cc213912afd2ed04808cd9a4a23 Date: Thu Nov 19 23:45:33 2015 + http://repo.or.cz/tinycc.git/commit/30c54c9d433f5cc213912afd2ed04808cd9a4a23

Bug#775992: tcc: null pointer dereference

2015-11-19 Thread Edmund Grimley Evans
In case anyone wants to know, the upstream commit that fixed this bug: commit 5bcc3eed7b93f5e75b0bb121913f84f574b7c46a Date: Tue Mar 10 23:23:00 2015 +0800 http://repo.or.cz/tinycc.git/commit/5bcc3eed7b93f5e75b0bb121913f84f574b7c46a

Bug#804944: Acknowledgement (dtach seems broken on arm64)

2015-11-17 Thread Edmund Grimley Evans
> It seems this is not a problem on all arm64 boxes. On IRC suihkulokki > found that it worked on his self compiled 4.2 kernel. Some poking about > with strace revealed that in the cases where dtach worked (whether > arm64, or my amd64 box), statfs("/dev/pts") returns DEVPTS_SUPER_MAGIC, > while

Bug#804304: [Pkg-pascal-devel] rebuilding with fpc 3.0.0

2015-11-07 Thread Edmund Grimley Evans
Paul Gevers: > On 02-11-15 20:11, Edmund Grimley Evans wrote: > > I was able to build libqt4pas, lazarus and pasdoc using the new fpc. > > I just had to update the symbols file for libqt4pas. > > Do you still have your update for the symbols file? I suggest filing a

Bug#727455: mcrypt: run dh-autoreconf to update config.{sub,guess} and {libtool,aclocal}.m4

2015-11-04 Thread Edmund Grimley Evans
Control: tags -1 patch Patch attached. diff -ru mcrypt-2.6.8.orig/debian/control mcrypt-2.6.8/debian/control --- mcrypt-2.6.8.orig/debian/control +++ mcrypt-2.6.8/debian/control @@ -6,7 +6,7 @@ Homepage: http://mcrypt.sourceforge.net/ Vcs-Browser:

Bug#765217: gnome-speech: run dh-autoreconf to update for new architectures

2015-11-03 Thread Edmund Grimley Evans
As far as I can tell, to fix this bug it is sufficient to add autotools-dev to the Build-Depends.

Bug#803984: doublecmd: FTBFS on arm64

2015-11-03 Thread Edmund Grimley Evans
Source: doublecmd Version: 0.6.6-1 I tried to build this on arm64 with fpc 3.0.0 and got this error: .../doublecmd-0.6.6/components/doublecmd/dcosutils.pas(240,24) Error: (5000) Identifier not found "syscall_nr_lchown" On arm64, and other recent architectures, the lchown system call has been

Bug#803986: transgui: regenerate Makefile from Makefile.fpc

2015-11-03 Thread Edmund Grimley Evans
Source: transgui Version: 5.0.1-2 The Debian build script seems to be using upstream's Makefile, which was "generated by FPCMake Version 2.0.0 [2011/12/25]". It would be better to regenerate this file for two reasons: - It becomes possible to build the package on new architectures, such as

  1   2   3   4   >