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

> Can you please try with the latest version of GHC available in unstable > (9.4.7-1)? I think the problem still exists: $ wget http://ftp.debian.org/debian/pool/main/g/ghc/ghc_9.4.7-1_armhf.deb $ ar pf ghc_9.4.7-1_armhf.deb data.tar.xz | tar xJf - $ file usr/lib/ghc/bin/ghc-9.4.7

Bug#922728: arch-test: reports armel invalid on arm64 system

I have observed a similar situation: my armel chroot seems to work all right, but arch-test does not list "armel" as working. In my case, SWPB is causing a SIGILL. It seems that a lot of armel binaries don't use SWPB, but perhaps SWPB (and SWP) are still "officially" required for armel? Who knows?

Bug#920835: mlucas FTBFS on !amd64: test failures

In 17.1-2 there's a simple omission in a script, which can be fixed with: perl -i -pe 's!DIRNAME"!DIRNAME/mlucas-generic-c"!' scripts/mlucas.in

Bug#920767: e2fsprogs: [REGRESSION] e4defrag version 1.44.5-1 segfaults on an armel system (but 1.44.4-2 doesn't)

grep defraged_file_count `find * -type f` reveals suspicious discrepency between declaration and format strings: misc/e4defrag.c:static unsigned long longdefraged_file_count; misc/e4defrag.c:" extents: %d -> %d\n", defraged_file_count, misc/e4defrag.c:"

Bug#917859: vim FTBFS building for armel,armhf on arm64

I'd guess this is a problem with the locale. In my case an unknown locale adds 8, rather than 10, additional lines, but still: $ LANG=C ./foo.pl Global symbol "$foo" requires explicit package name at ./foo.pl line 3. Execution of ./foo.pl aborted due to compilation errors. $ LANG=sq ./foo.pl

Bug#912167: dpuser FTBFS on arm64: Segmentation fault

This may be caused by a bug in "giza". Someone please tell the giza developers. The segfault happens when _giza_parse_string tries to return. The return address on the stack was corrupted by this call to cairo_get_current_point: https://sources.debian.org/src/giza/1.0.0-1/src/lex.yy.c/#L2285 If

Bug#871566: swarmkit FTBFS: cannot find package "github.com/docker/docker/api/types"

swarmkit should build-dep on golang-github-docker-docker-dev (>= 1.13.1~), or something like that.

Bug#871566: swarmkit FTBFS: cannot find package "github.com/docker/docker/api/types"

I was able to build swarmkit on arm64 after I manually installed a newer golang-github-docker-docker-dev. There's some kind of circular dependency between swarmkit and docker.io. I think someone will have to break it with a binary upload. (There was a binary upload on amd64, I notice.) According

Bug#695489: sort -u and uniq "lose" non-identical lines with some locales

Control: retitle -1 uniq "loses" non-identical lines with some locales I'm changing the title to refer to just "uniq" because it seems that this behaviour of "sort -u" is specified; only "uniq" is behaving incorrectly. The upstream bug only talks about "sort -u" so should perhaps be unlinked. Is

Bug#695489: sort -u and uniq "lose" non-identical lines with some locales

Control: retitle -1 sort -u and uniq "lose" non-identical lines with some locales I was hurt by this bug, too. I had a simple-minded script to check files for dodgy characters before publishing them. How was I to know that em-dash and en-dash would be considered identical in a standard GB

Bug#871566: swarmkit FTBFS: cannot find package "github.com/docker/docker/api/types"

The build failure quoted above is not reproducible with the current state of sid, I think. However, it is still not possible to build swarmkit for a different reason: an indirect dependency on golang-github-juju-ansiterm. See #886613 and the "Dependency installability problem for swarmkit" on

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

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

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

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

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

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

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

> 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

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

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

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

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

> 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

> 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

> 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

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

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

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

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"?

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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"?

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

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

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

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)

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)

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

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

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)"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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"

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

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

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

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

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

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)

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)

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

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

> 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

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

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..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

> 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

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

  1   2   3   4   >