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 usr/lib/ghc/bin/ghc-9.4.7: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=363ee1eef5ed7a7df5782524eb2734e366865c9c, stripped $ readelf -l usr/lib/ghc/bin/ghc-9.4.7 | grep LOAD LOAD 0x00 0x8000 0x8000 0x1f767c 0x1f767c R E 0x1000 LOAD 0x1f7df8 0x00200df8 0x00200df8 0x12ea8 0x12ea9 RW 0x1000 So the binary is non-PIE and loads at 0x8000 but many systems have mmap_min_addr set to 0x1 (I believe). But perhaps it's not such a serious problem. It looks like people can change the value if they need to: https://wiki.debian.org/mmap_min_addr So I won't object if you want to close this ancient bug.
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:" extents: %d -> %d\n", defraged_file_count, misc/e4defrag.c:printf("[%u/%u]", defraged_file_count, total_count); misc/e4defrag.c:printf("[%u/%u]", defraged_file_count, total_count); Note that other declarations changed between 1.44.4 and 1.44.5 so there may be other similar problems. Something like printf("...%d...%s...", long_long_int, pointer_to_char) could lead to a segfault on armel, though usually there would be a conspicuous warning from the compiler.
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 perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = "en_GB:", LC_ALL = (unset), LC_COLLATE = "C", LANG = "sq" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Global symbol "$foo" requires explicit package name at ./foo.pl line 3. Execution of ./foo.pl aborted due to compilation errors.
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 you add this assertion just before that line you should see the assertion fail: assert(0 <= nGlyph && nGlyph < lenstr);
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 to my "history", I did something like: apt-get build-dep docker.io apt-get build-dep swarmkit apt-get install golang-github-docker-docker-dev wget http://ftp.uk.debian.org/debian/pool/main/d/docker.io/golang-github-docker-docker-dev_1.13.1~ds2-3_all.deb dpkg -i golang-github-docker-docker-dev_1.13.1~ds2-3_all.deb apt-get install golang-github-opencontainers-docker-runc-dev apt --fix-broken install dpkg -i golang-github-docker-docker-dev_1.13.1~ds2-3_all.deb apt-get source swarmkit cd swarmkit-1.12.0+git20170111.763.296fcfcf dpkg-buildpackage -b
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 there a separate upstream bug somewhere for "uniq"?
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 locale, as provided by Debian's installer? Spotting inconsistent use of characters that look alike is exactly what my script was supposed to achieve. LANG=en_GB.UTF-8 $ printf "\xe2\x80\x93\n\xe2\x80\x94\n" – — $ printf "\xe2\x80\x93\n\xe2\x80\x94\n" | od -An -tx1 e2 80 93 0a e2 80 94 0a $ printf "\xe2\x80\x93\n\xe2\x80\x94\n" | uniq | od -An -tx1 e2 80 93 0a It's true that the man page for "uniq" mentions LC_COLLATE, though I don't consider that adequate warning. However, it's also true that the official-looking spec at http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uniq.html says: > To remove duplicate lines based on whether they collate equally > instead of whether they are identical, applications should use: > > sort -u > > instead of: > > sort | uniq Also, the spec does not mention LC_COLLATE in the ENVIRONMENT VARIABLES section. Does coreutils attempt to follow that spec? The work-around, of course, is to set LC_COLLATE to C when uniq is invoked: $ printf "\xe2\x80\x93\n\xe2\x80\x94\n" | uniq | od -An -tx1 e2 80 93 0a $ printf "\xe2\x80\x93\n\xe2\x80\x94\n" | LC_COLLATE=C uniq | od -An -tx1 e2 80 93 0a e2 80 94 0a
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 arm64 and other architectures: https://buildd.debian.org/status/package.php?p=swarmkit&suite=sid
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 arm64 systems, including the buildds, use 48-bit virtual addresses. For what it's worth, I have seen lua-torch-torch7 built successfully on an arm64 system with 42-bit virtual addresses (and 64K pages) so there does not seem to be any other obstacle to making it work on arm64.
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 powerpc, "praetorius" built rnahybrid 2.1-2 in 3m, and 2.1.2-1 in 46m, the former with GCC 4.3, the latter with GCC 5.3, though obviously there are other differences in that comparison. Also the differences in build times between architectures look suspicious when compared with the differences in building other packages.
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 unstable, as requested, if no one else gets there first.) > The file it timed out on takes almost 1 minute to compile on a 2GHz x86. > That one file is about 90% of the total build time of the package. > > How long does it take on the armel build box and how much memory does > it use while doing it? I don't think the buildds report memory usage, but the time is 150 minutes: https://buildd.debian.org/status/logs.php?pkg=rnahybrid&arch=armel
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: iteration 6 invokes undefined behavior [-Waggressive-loop-optimizations] There are other warnings, too, but undefined behaviour is particularly scary.
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&arch=armel It seems to be easy to reproduce with the cross-compiler. On Debian amd64 Stretch: sudo apt-get install gcc-6-arm-linux-gnueabi apt-get source rnahybrid cd rnahybrid-2.1.2/ export CC=arm-linux-gnueabi-gcc-6 ./configure --host=xx make # cc1 runs forever with 100% CPU, not much memory, compiling "energy.c" There's a warning about undefined behaviour, and I've not looked at the source at all, but an infinite loop like this is presumably a GCC bug in any case (though perhaps not such a serious one if it only happens with code that invokes undefined behaviour).
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 libluajit-5.1-common_2.1.0~beta2+dfsg-1_arm64.deb luajit_2.1.0~beta2+dfsg-1_arm64.deb ... # luajit -e 'print("x");' Segmentation fault (core dumped) # dpkg -i libluajit-5.1-2_2.1.0~beta2+dfsg-3_arm64.deb libluajit-5.1-common_2.1.0~beta2+dfsg-3_arm64.deb luajit_2.1.0~beta2+dfsg-3_arm64.deb ... # luajit -e 'print("x");' Segmentation fault (core dumped) # dpkg -i libluajit-5.1-2_2.1.0~beta3+dfsg-1_arm64.deb libluajit-5.1-common_2.1.0~beta3+dfsg-1_all.deb luajit_2.1.0~beta3+dfsg-1_arm64.deb # luajit -e 'print("x");' x # dpkg -i libluajit-5.1-2_2.1.0~beta3+dfsg-2_arm64.deb libluajit-5.1-common_2.1.0~beta3+dfsg-2_all.deb luajit_2.1.0~beta3+dfsg-2_arm64.deb # luajit -e 'print("x");' x
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 architectures too. Perhaps it should be "Architecture: any". (The tests, when enabled in debian/rules, fail for me on amd64 anyway so I'm not sure what to do about testing.)
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 architecture.
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&arch=arm64&ver=2.2.6-5&stamp=1504220784&raw=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 architectures then it needs extra steps to > avoid RC bugs/autoremovals, nor? I think it would be all right. Firstly, there is a difference between "fails to build" and "BD-Uninstallable" (build dependencies were not satisfied). Secondly, it is only a bug or an obstacle to migration, as I understand it, when a package which was previously built successfully later fails to build. If you look at https://buildd.debian.org/status/architecture.php?a=arm64&suite=sid you'll see that there are currently 90 BD-Uninstallable and 129 Build-Attempted packages on that architecture. Click on the package "love", then on "Tracker", and you'll see that "love", which is "Architecture: any" but can't be built on arm64 because we don't yet have luajit, has still successfully migrated to stable and testing on the architectures where it can be built. So I think you can make your package "Architecture: any" without suffering any inconvenience, and it might be more convenient in the long run to do that. However, I am not a DD and have never myself maintained a Debian package so I could be wrong.
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)\ asm("movdqa (%[s],%[i]), %[load]\n\t" \ "pand " #off "(%[p]),%[load]\n\t" \ "pxor %[load],%[acc]\n\t" \ : [acc]"=&x"(acc) \ : "[acc]"(acc), [i]"r"(i), [p]"r"(p), [s]"r"(smear), [load]"x"(load)) #else #define AND_XOR(off) do { \ xmm_t a = { smear[i / 8], smear[i / 8 + 1] }; \ xmm_t b = { p[(off) / 8], p[(off) / 8 + 1] }; \ acc ^= a & b; \ } while (0) #endif #ifdef __x86_64__ uint64_t res1, res2; asm("movd %[acc], %[res1]\n\t" "psrldq $8, %[acc]\n\t" "movd %[acc], %[res2]\n\t" : [res1]"=r"(res1), [res2]"=r"(res2) : [acc]"x"(acc)); return res1 ^ res2; #else return acc[0] ^ acc[1]; #endif Then replace AND_XOR("0x30") with AND_XOR(0x30), AND_XOR("") with AND_XOR(0), and so on. You might find the non-assembler version performs just as well on amd64, too, in which case you could simplify the code. Tested on arm64. Likely to work on some other architectures.
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 presumably provide proper implementations in atomic32.h. They could use inline assembler, like in x86_64/atomic32.h, but perhaps it would be better to use GCC built-ins.
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 that mean anything to you? (It seems that CO = COVERED, PC = PARTCOVERED, SU = SUPPRESED, UN = UNINSTRUMENTED, but I'm not sure what "PARTCOVERED" means.)
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 test failure on one architecture might (and, in a sense, quite likely does) indicate a bug in all architectures, so perhaps, to be on the safe side... Has anyone looked at the failures in detail? If they look like they could easily be a consequence of differences in the results of floating-point calculations I'd say just disable them for now. If there's a segfault, that might be worth investigating.
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 the code is intended to work on any system with a working C compiler, so perhaps it could be made "Architecture: any".
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: https://launchpad.net/ubuntu/+source/insighttoolkit4/+changelog
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 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?
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: https://sources.debian.net/src/picolisp/17.6-1/INSTALL/#L44 There's also an upstream precompiled release for arm64: https://picolisp.com/wiki/?listversions The Debian packaging will presumably need to be adjusted for arm64, but with any luck it won't be a lot of work.
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, 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.
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 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.
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 recently become 48-bit on arm64, which has broken some other programs. (However, the symptoms aren't a very good match: breakage from the move to 48 bits would typically give you a consistent failure on systems that use 48-bit pointers with the faulting address looking like a correct address but with the top bits wrong, which isn't what's described on the mailing list; see link above.)
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 that particular test to use 64-bit floats. * Get that test to generate some output as it runs so that it does not seem to be inactive.
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 harmful false positives. For easier maintenance you might want to move the code that packs and unpacks addresses into one place rather than have it scattered all over the place.
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&suite=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 the kernel is configured: https://www.kernel.org/doc/Documentation/arm64/memory.txt It seems that giac now works with the smaller virtual addresses, but fails on the buildd, which uses 48-bit addresses. According to the comment in src/gen.h, SMARTPTR64 should handle 48-bit addresses, but up to now it has probably only been tested on amd64, which uses 47-bit addresses. A problem with the top bit? Sign extension perhaps? Sure enough, in src/gen.cc there is code like this: #ifdef SMARTPTR64 (*((longlong *) &e) >> 16) I suspect that the fix will be to replace some of those longlong with ulonglong.
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 correctly, deprecated in ARMv7 and removed entirely in ARMv8, though the kernel can be configured to emulate them. Since armhf requires at least ARMv7, GHC should not be using or generating these instructions on armhf. I presume this problem concerns all binaries generated by GHC. However, I hope it does not prevent any armhf binary from running under a Debian armhf stock kernel image, even on ARMv8 hardware, though someone should perhaps check that last point and raise the severity if it turns out there is a problem on any standard installation.
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 usr/lib/ghc/bin/ghc | grep LOAD LOAD 0x00 0x8000 0x8000 0x19bc74 0x19bc74 R E 0x1000 LOAD 0x19beb0 0x001a4eb0 0x001a4eb0 0x21d8c 0x21d8d RW 0x1000 Probably this binary should be a PIE, like nearly all other executables in the system. Failing that, it should have a load address of 0x1 instead of 0x8000 because many kernels are configured not to allow an mmap below 0x1. I presume this problem concerns all binaries generated by GHC. However, I hope it does not prevent any armhf binary from running under a Debian armhf stock kernel image.
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&arch=arm64&ver=1.2.1-1&stamp=1497480941&raw=0 The same error also happens on amd64 with the latest golang-github-hanwen-go-fuse-dev from unstable, 0.0~git20170609.0.5690be4-1. There seems to be a new upstream version of gocryptfs in any case...
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". When I changed the Architecture to "any" in the Debian package it built in a Debian Stretch arm64 chroot.
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 "armv7hl" (~ armhf) among its architectures.
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&suite=sid): In file included from ../include/prtypes.h:58:0, from ../include/npapi.h:51, from npentry.c:29: ../include/prcpucfg.h:645:2: error: #error "Unknown CPU architecture" #error "Unknown CPU architecture" ^ This is the same problem as #770966 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770966) and can be fixed in the same way.
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: address 0x7f7d935b338c exceeds the 32 bit address space or is not in the data segments This may result in program crash or incorrect results Therefore we will stop here On arm64, armhf and i386, I observed a similar, apparently identical, failure to that reported above on 7 Nov 2013. This library is used by one of the tests run by mclibs' build, which fails on some architectures with a SIGSEGV: https://buildd.debian.org/status/package.php?p=mclibs&suite=sid On arm64, I think that test passes if you arrange for the library to be linked statically rather than dynamically: you can see in the build logs how it runs `cernlib -dy eurodec packlib`; the segfault does not happen if you run the test manually without the "-dy", if I recall correctly. Perhaps all these observations mean something to somebody...
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 @@ PLATFORM=platform="armv hardfloat" endif +ifneq (,$(filter-out amd64 armhf i386 %-amd64 %-i386 x32, $(ARCH))) +NO_JIT=DESMUME_JIT=0 +endif + %: dh $@ --sourcedirectory=desmume/ override_dh_auto_build: -dh_auto_build -- -f Makefile.libretro $(PLATFORM) +dh_auto_build -- -f Makefile.libretro $(PLATFORM) $(NO_JIT) override_dh_auto_clean: dh_auto_clean -- -f Makefile.libretro
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 backported into Go 1.6 and 1.7 in Ubuntu. Perhaps it should be fixed in Debian Stretch.
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, 16384, or 65536, and arm64 seems not to be the only Debian architecture on which the page size must be determined at run time: https://wiki.debian.org/ArchitectureSpecificsMemo Usually the auxiliary vector (getauxval) is the best way to find the page size, though it can be discovered with a sequence of mmap and munmap system calls if for some reason the auxiliary vector is inaccessible.
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 @@ -AlwaysAssert(near(sumsq(pos), expSumSq), AipsError); +AlwaysAssert(near(sumsq(pos), expSumSq, 1e-9), AipsError); @@ -422 +422 @@ -AlwaysAssert(near(rms(pos), expRMS), AipsError); +AlwaysAssert(near(rms(pos), expRMS, 1e-10), AipsError); diff -ru0 casacore-2.2.0.orig/scimath/Mathematics/test/tStatisticsUtilities.cc casacore-2.2.0/scimath/Mathematics/test/tStatisticsUtilities.cc --- casacore-2.2.0.orig/scimath/Mathematics/test/tStatisticsUtilities.cc +++ casacore-2.2.0/scimath/Mathematics/test/tStatisticsUtilities.cc @@ -268 +268 @@ -AlwaysAssert(got.sumsq == expec.sumsq, AipsError); +AlwaysAssert(near(got.sumsq, expec.sumsq), AipsError); The test "tLCEllipsoid" seems to be converting ellipses into bitmaps. I'm guessing it gives different output on amd64 and arm64 because the real curve passes through a critical point and numerical inaccuracy puts it on different sides of the point on the two architectures. One way to fix that might be to use non-round numbers in the parameters so that the curve does not pass through a critical point. That's what I tried to do, and with the following changes to the program and the expected output the test passes on both amd64 and arm64: --- casacore-2.2.0.orig/lattices/LRegions/test/tLCEllipsoid.cc +++ casacore-2.2.0/lattices/LRegions/test/tLCEllipsoid.cc @@ -215,2 +215,2 @@ -major = 36; -minor = 16; +major = 36.01; +minor = 16.01; diff -ru0 casacore-2.2.0.orig/lattices/LRegions/test/tLCEllipsoid.out casacore-2.2.0/lattices/LRegions/test/tLCEllipsoid.out --- casacore-2.2.0.orig/lattices/LRegions/test/tLCEllipsoid.out +++ casacore-2.2.0/lattices/LRegions/test/tLCEllipsoid.out @@ -166 +166 @@ -0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 26] +0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 26] @@ -180 +180 @@ -1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 [35, 12] +1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 [35, 12] @@ -210 +210 @@ -0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 19] +0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 [35, 19] @@ -213 +213 @@ -0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 [35, 16] +0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 [35, 16] @@ -225 +225 @@ -0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [35, 4] +0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [35, 4] @@ -229 +229 @@ -0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [35, 0] +0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [35, 0] @@ -243 +243 @@ -0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [35, 23] +0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [35, 23] @@ -257 +257 @@ -0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 9] +0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 [35, 9] @@ -268 +268 @@ -1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 35] +1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 35] @@ -272 +272 @@ -1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 31] +1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 31] @@ -284 +284 @@ -1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 19] +1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 19] @@ -287 +287 @@ -0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 16] +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [35, 16] I'm not sure what to do about the other two tests that fail on arm64, "tLSQaips" and "tLSQFit", because those two generate a load of output text containing floating-point numbers and compare that text with an expected output. It might not be so easy to make that work on all architectures. Perhaps one could simply disable those two tests. Preferably one would still run them, so that we can see what happens in the logs, but not have the build fail if only those tests fail. With the above changes and the following one, the package builds on arm64: --- casacore-2.2.0.orig/scimath/Fitting/test/CMakeLists.txt +++ casacore-2.2.0/scimath/Fitting/test/CMakeLists.txt @@ -6,2 +6,2 @@ -tLSQaips -tLSQFit +#tLSQaips +#tLSQFit Can anyone test these changes on other architectures?
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 --disable-vectorization Note 2.1: The "USE_SYSTEM_MD5_DEPENDENCY" might fix bug #835108 for you. I saw a similar problem where the local "md5.h" was used together with the system library. Note 2.2: You should make the "--disable-vectorization" conditional on the Debian architecture, of course. Don't disable it on Intel architectures. 3. Add the obvious pair of lines in srcio/Seccomp.cc: #elif defined(__aarch64__) # define ARCH_NR AUDIT_ARCH_AARCH64 4. In src/lepton/jpgcoder.cc replace "#ifndef _ARCH_PPC" with something like "#if defined(__i386__) || defined(__x86_64__)". Probably the same or similar changes would make this package build on most architectures, so please try it some time.
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 temporarily avoid the problem by changing the preceding condition to something like "else static if (true)": it might give an inaccurate result, but that is unlikely to matter for now. The next error was much more interesting: a segfault in a program containing D code. GDB revealed that the segfault was in glibc's (_IO_)vsnprintf, called from D code, and from the disassembly it's clear that there had been a calling convention mismatch: the caller (D code) is putting the va_list (which on arm64 Linux is a 32-byte struct) onto the stack, but the callee (C code) is expecting to find a pointer to the struct in register X3. I then wrote a few 6-line programs and compiled them with the D compiler (bootstrap/b/bin/ldc2, if I recall correctly). It was clear that this compiler is passing structs of size greater than 16 bytes in a different way from the normal AArch64 calling convention on Linux. This is quite a plausible bug to find here, because LDC has mostly been used on iOS, it seems, and on iOS va_list is just a pointer, while in general it is fairly unusual to pass a larger struct as an argument in C, so it's quite plausible that a bug like this might not have been discovered. Perhaps this is the only remaining major bug. Perhaps if the calling convention could be modified appropriately (bootstrap/gen/abi-aarch64.cpp) then the package could be built. Of course there must already be code somewhere in LLVM/Clang for implementing the standard/Linux AArch64 calling convention... (I'm assuming, of course, that D is supposed to use the same calling convention as C throughout, rather than use one calling convention internally and a different one for calling C code.) The are versions of LDC upstream with higher version numbers, so one could look at those, but I haven't seen any mention of them working better on arm64 Linux.
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: $ 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) __main__:1: RuntimeWarning: invalid value encountered in absolute nan >>> I do not see why the behaviour would intentionally be different on different architectures so I suspect that this is a bug. Unfortunately I could not discover where abs/absolute is implemented so the bug might not be in python-numpy itself. This inconsistency seems to be the reason for pandas failing to build on arm64 and mips64el: https://buildd.debian.org/status/package.php?p=pandas&suite=sid If there is a simple fix that does not change the behaviour on amd64 it would be nice to have this fixed in Stretch. (Would we then get pandas in Stretch 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 including the implicit "1". So I would guess that the error comes from multiply and subtract being combined into a single operation, so that the error in computing 1.2 * 3.4 is revealed. If this is a real problem, perhaps "cross" could be implemented in a way that prevents multiply-subtract from being used. If it is not a real problem, then the test should be made less sensitive, perhaps by requiring the absolute value of the result to be less than 1e-12 or some other arbitrary epsilon.
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 ~(uintptr_t)3 in gen.h, avoiding the preprocessor, and in first.h something like: #include #if UINTPTR_MAX < 0x
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 only problem. I'd recommend grepping all the code for __x86_64__ to see if there are other places where it's assumed that all other architectures are 32-bit. In src/gen.h you could just use something like (_ptr & (uintptr_t)-4): no need for the preprocessor. Even if you do have to use the preprocessor I'd advise against listing all the 64-bit architectures you can think of. You could use UINTPTR_MAX from , for example. It's encouraging that a statically linked icas was reported to have worked on arm64: http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1785 That suggests that pointer truncation is perhaps the only problem (and the pointers happen to be 32-bit with static linking on that system). So perhaps quite a small patch would make this package work on other 64-bit architectures.
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 addresses. (I think it changed from 39 to 48 bits.) It seems very plausible that an address sanitizer might stop working for the same reason.
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 no harm is done. If you can build julia, which is just a matter of using an appropriate system, then you might as well ship it. It will be useful for some people even if the LLVM bug does not get fixed. There is probably no need to rebuild julia when the LLVM bug has been fixed, but you should probably check that with someone who properly understands how julia works.
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 consequences: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861484 You could just change that one line: -*TargetPtr |= Result >> (48 - 5); +*TargetPtr |= (Result & 0xULL) >> (48 - 5); (Is there some way of searching for all such simple upstream bug fixes that should perhaps be applied to Debian's llvm-toolchain-3.8?)
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 give the correct answer either with no special configuration or with very little extra reconfiguration. This would probably be achieved by downloading a table of leap seconds so it is related to #851096. See also: https://superuser.com/questions/1156693/is-there-a-way-of-getting-correct-clock-tai-on-linux A test program to print out the difference between CLOCK_TAI and CLOCK_UTC or CLOCK_REALTIME is attached. (Right-justification of this bug report happened by accident.) #include #include #include #ifndef CLOCK_TAI # error CLOCK_TAI is not defined. Your C library is too old. #endif #ifndef CLOCK_UTC # warning CLOCK_UTC is not defined, no surprise. Using CLOCK_REALTIME instead. # define CLOCK_UTC CLOCK_REALTIME #endif int main() { struct timespec ts_utc1, ts_tai, ts_utc2; long long diff1, diff2; if (clock_gettime(CLOCK_UTC, &ts_utc1)) { printf("clock_gettime(CLOCK_UTC, ...) failed\n"); exit(1); } if (clock_gettime(CLOCK_TAI, &ts_tai)) { printf("clock_gettime(CLOCK_TAI, ...) failed\n"); exit(1); } if (clock_gettime(CLOCK_UTC, &ts_utc2)) { printf("clock_gettime(CLOCK_UTC, ...) failed\n"); exit(1); } diff1 = ((ts_tai.tv_nsec - ts_utc1.tv_nsec) + (ts_tai.tv_sec - ts_utc1.tv_sec ) * 10LL); diff2 = ((ts_tai.tv_nsec - ts_utc2.tv_nsec) + (ts_tai.tv_sec - ts_utc2.tv_sec ) * 10LL); printf("Expected (TAI - UTC) in 2017:\n"); printf("%16lld\n", 37 * 10LL); printf("Difference between CLOCK_TAI and CLOCK_UTC is in range:\n"); printf("%16lld\n", diff2); printf("%16lld\n", diff1); return 0; }
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&suite=sid The error was: src/inotify-syscalls.h:47:3: error: #error "Unsupported architecture!" # error "Unsupported architecture!" I think the attached trivial patch fixes it. diff -ru tangerine-0.3.4.orig/libtangglue/src/inotify-syscalls.h tangerine-0.3.4/libtangglue/src/inotify-syscalls.h --- tangerine-0.3.4.orig/libtangglue/src/inotify-syscalls.h +++ tangerine-0.3.4/libtangglue/src/inotify-syscalls.h @@ -43,13 +43,21 @@ # define __NR_inotify_init 318 # define __NR_inotify_add_watch 319 # define __NR_inotify_rm_watch 320 +#elif defined (__aarch64__) +# define __NR_inotify_init1 26 +# define __NR_inotify_add_watch 27 +# define __NR_inotify_rm_watch 28 #else # error "Unsupported architecture!" #endif static inline int inotify_init (void) { +#ifdef __NR_inotify_init return syscall (__NR_inotify_init); +#else + return syscall (__NR_inotify_init1, 0); +#endif } static inline int inotify_add_watch (int fd, const char *name, __u32 mask)
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 centimetres before the bottom. The screen is 1600x1200. I realised that this is very unlikely and booted the installer again to check. What's really happening is that the touchpad is in "absolute mode". I didn't even know there was such a thing. Now I do.
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 remove the installation media and reboot. It started to reboot, but I don't think it got as far as mounting the disc. It complained about some missing firmware (not a bug), then just stopped, with some sporadic disc activity continuing for a while, according to the LED. I left it for ages in case it was running fsck invisibly (which is a stupid thing to do but I've seen Linux systems do that) but it never got anywhere. I tried the whole thing twice, with and without disc encryption. With disc encryption it did get as far as asking for the passphrase, which it recognised when I typed it correctly the second time, so it must have read some data from the disc. Afterwards I successfully installed using debian-8.5.0-i386-netinst.iso on the same hardware. 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 centimetres before the bottom. The screen is 1600x1200.
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&suite=sid The error was an infinite loop and a time-out: make[3]: *** [machines] Terminated E: Caught signal ‘Terminated’: terminating immediately It looks very much like the usual bug, for which the fix is: in src/utils/machines.c and src/utils/s3gdump.c replace "char c" with "int c", which is what getopt returns. Thanks.
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 same is likely to be true for other architectures for which g++-multilib does not exist. You should probably check that g++-multilib really is required on amd64, i386, and so on. Perhaps there is a standard way of asking for g++-multilib "where applicable". If not, presumably you'll just have to list the applicable architectures in debian/control. Thanks.
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&suite=sid The error was: ./cnf/bin/afnix-setup -o --prefix=/usr afnix-setup: cannot determine linking type I'm attaching a trivial patch that seems to work. diff -ru afnix-2.6.2.orig/cnf/bin/afnix-guess afnix-2.6.2/cnf/bin/afnix-guess --- afnix-2.6.2.orig/cnf/bin/afnix-guess +++ afnix-2.6.2/cnf/bin/afnix-guess @@ -115,6 +115,7 @@ sun4*) cpunam=sparc;; sparc*)cpunam=sparc;; arm*) cpunam=arm;; +aarch64*) cpunam=aarch64;; ppc) cpunam=ppc;; ppc64le) cpunam=ppc64el;; m68k) cpunam=m68k;; diff -ru afnix-2.6.2.orig/src/lib/plt/acf/ccnf.cpp afnix-2.6.2/src/lib/plt/acf/ccnf.cpp --- afnix-2.6.2.orig/src/lib/plt/acf/ccnf.cpp +++ afnix-2.6.2/src/lib/plt/acf/ccnf.cpp @@ -54,6 +54,7 @@ #define AFNIX_PROCTYPE_MIPS6414 #define AFNIX_PROCTYPE_MIPS64EL 15 #define AFNIX_PROCTYPE_PPC64EL 16 +#define AFNIX_PROCTYPE_AARCH64 17 // recognized processor name #define AFNIX_PROCNAME_UNKNOWN "unknown" @@ -73,6 +74,7 @@ #define AFNIX_PROCNAME_SH"sh" #define AFNIX_PROCNAME_MIPS64"mips64" #define AFNIX_PROCNAME_MIPS64EL "mips64el" +#define AFNIX_PROCNAME_AARCH64 "aarch64" // force size type with S390/clang #if defined(__s390__) || defined(__clang__) @@ -128,6 +130,9 @@ // arm if (strcmp (proc, AFNIX_PROCNAME_ARM) == 0) return AFNIX_PROCTYPE_ARM; + // aarch64 + if (strcmp (proc, AFNIX_PROCNAME_AARCH64) == 0) +return AFNIX_PROCTYPE_AARCH64; // ppc if (strcmp (proc, AFNIX_PROCNAME_PPC) == 0) return AFNIX_PROCTYPE_PPC; @@ -183,6 +188,7 @@ if (id == AFNIX_PROCTYPE_SPARC)return AFNIX_PROCNAME_SPARC; if (id == AFNIX_PROCTYPE_ALPHA)return AFNIX_PROCNAME_ALPHA; if (id == AFNIX_PROCTYPE_ARM) return AFNIX_PROCNAME_ARM; + if (id == AFNIX_PROCTYPE_AARCH64) return AFNIX_PROCNAME_AARCH64; if (id == AFNIX_PROCTYPE_PPC) return AFNIX_PROCNAME_PPC; if (id == AFNIX_PROCTYPE_PPC64EL) return AFNIX_PROCNAME_PPC64EL; if (id == AFNIX_PROCTYPE_M68K) return AFNIX_PROCNAME_M68K; @@ -331,6 +337,8 @@ AFNIX_PROCTYPE_ALPHA); fprintf (stdout, "#define AFNIX_PROCTYPE_ARM %d\n", AFNIX_PROCTYPE_ARM); + fprintf (stdout, "#define AFNIX_PROCTYPE_AARCH64 %d\n", + AFNIX_PROCTYPE_AARCH64); fprintf (stdout, "#define AFNIX_PROCTYPE_PPC %d\n", AFNIX_PROCTYPE_PPC); fprintf (stdout, "#define AFNIX_PROCTYPE_PPC64EL %d\n", @@ -369,6 +377,8 @@ AFNIX_PROCNAME_ALPHA); fprintf (stdout, "#define AFNIX_PROCNAME_ARM \"%s\"\n", AFNIX_PROCNAME_ARM); + fprintf (stdout, "#define AFNIX_PROCNAME_AARCH64 \"%s\"\n", + AFNIX_PROCNAME_AARCH64); fprintf (stdout, "#define AFNIX_PROCNAME_PPC \"%s\"\n", AFNIX_PROCNAME_PPC); fprintf (stdout, "#define AFNIX_PROCNAME_PPC64EL \"%s\"\n",
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&suite=sid There's a "char c" in main.c. Change it to "int c", because poptGetNextOpt returns int. That's your patch.
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&suite=sid It built with the attached patch, which corrects two typos, apparently. diff -ru irqbalance-1.1.0.orig/procinterrupts.c irqbalance-1.1.0/procinterrupts.c --- irqbalance-1.1.0.orig/procinterrupts.c +++ irqbalance-1.1.0/procinterrupts.c @@ -80,7 +80,7 @@ rc = 0; goto out; } else if (!strncmp(ent->d_name, "net", strlen("net"))) { - info->IRQ_TYPE_LEGACY; + info->type = IRQ_TYPE_LEGACY; info->class = IRQ_ETH; rc = 0; goto out; @@ -94,7 +94,7 @@ out: closedir(dirfd); - log(TO_ALL, LOG_DEBUG, "IRQ %s is of type %d and class %d\n", name, info->type, info->class) + log(TO_ALL, LOG_DEBUG, "IRQ %s is of type %d and class %d\n", name, info->type, info->class); return rc; }
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: dbacl Section: text Priority: optional -Build-Depends: cdbs, debhelper (>= 5.0.0), libreadline-gplv2-dev, libslang2-dev +Build-Depends: cdbs, debhelper (>= 5.0.0), libreadline-gplv2-dev, libslang2-dev, dh-autoreconf Maintainer: Zak B. Elep Standards-Version: 3.8.0 Homepage: http://www.lbreyer.com/gpl.html diff -ru dbacl-1.12.orig/debian/rules dbacl-1.12/debian/rules --- dbacl-1.12.orig/debian/rules +++ dbacl-1.12/debian/rules @@ -6,6 +6,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/rules/simple-patchsys.mk include /usr/share/cdbs/1/class/autotools.mk +include /usr/share/cdbs/1/rules/autoreconf.mk # Move installed docs to proper Debian location install/dbacl::
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 stack_chk_guard 00410a38 B __stack_chk_guard@@GLIBC_2.17 $ objdump -R test | grep stack_chk_guard 00410a38 R_AARCH64_COPY__stack_chk_guard@@GLIBC_2.17 $ nm -D /lib/ld-linux-aarch64.so.1 | grep stack_chk_guard 0002bdd8 D __stack_chk_guard So dpkg-shlibdeps should be a bit cleverer, I would guess. As I understand it, the difference between amd64 and arm64 comes from how the stack-protector stuff is implemented differently on the two architectures: on amd64 thread-local storage is used instead of a global variable. The kind of linking that's happening on arm64 can be demonstrated on amd64 like this: echo 'int foo = 7;' > lib.c gcc -fPIC -c lib.c gcc -shared lib.o -o liblib.so nm -D liblib.so | grep foo echo 'extern int foo; int main() { return foo; }' > prog.c gcc -c prog.c gcc prog.o -L. -llib -o prog nm prog | grep foo $ ./prog ./prog: error while loading shared libraries: liblib.so: cannot open shared object file: No such file or directory $ LD_LIBRARY_PATH=. ./prog $ echo $? 7 The value 7 comes from the shared library. Please reassign this bug if you agree with my reasoning.
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&suite=sid The error was: signal (6): Aborted gsignal at /lib/aarch64-linux-gnu/libc.so.6 (unknown line) Aborted The problem seems to be that there is no system call epoll_wait on arm64, only epoll_pwait, so you need a patch like this: --- julia-0.4.2.orig/deps/libuv/src/unix/linux-syscalls.c +++ julia-0.4.2/deps/libuv/src/unix/linux-syscalls.c @@ -310,6 +310,8 @@ int timeout) { #if defined(__NR_epoll_wait) return syscall(__NR_epoll_wait, epfd, events, nevents, timeout); +#elif defined(__NR_epoll_pwait) + return syscall(__NR_epoll_pwait, epfd, events, nevents, timeout, 0); #else return errno = ENOSYS, -1; #endif By the way, if the code had had assert(0) instead of abort() it would probably have been easier to find 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, or a PowerPC processor that supports the Altivec/VMX instruction set. SSE2 is supported on Intel processors from Pentium 4 on, and AMD processors from K8 (Athlon 64) on; we believe this includes almost all Intel processors since 2000 and AMD processors since 2003. Altivec/VMX is supported on Motorola G4, IBM G5, and IBM PowerPC processors starting with the Power6, which we believe includes almost all PowerPC-based desktop systems since 1999 and servers since 2007. If your platform does not support one of these vector instruction sets, the configure script will revert to an unoptimized implementation called the “dummy” implementation. The dummy implementation is two orders of magnitude slower. It will enable you to see H3’s scientific features on a much wider range of processors, but is not suited for real production work. We do aim to be portable to all modern processors. The acceleration algorithms are designed to be portable despite their use of specialized SIMD vector instructions. We hope to add support for the Sun SPARC VIS instruction set, for example. We believe that the code will be able to take advantage of GPGPUs and FPGAs in the future. """ So it seems that the failures on non-Intel architectures are not, in fact, expected. The "dummy" implementation may be buggy. Presumably you can manually configure it to use the "dummy" implementation on an Intel processor. Does that work?
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&arch=arm64&ver=3.1b2-1&stamp=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 and then it gave "FAIL: on line 0 target name, dtbl1". One of the few easily reproducible failures I found on arm64 was this: touch tmp1 ; rm tmp1* ; ./i8-nonresidues.pl .. .. tmp1 I didn't see that test ever produce a different output from "FAIL: expected one line in domtbl; saw 2". The "nonresidues" test also failed on ppc64el. Perhaps you should look at that one first. Or perhaps you're more worried about the general non-determinism that affects many of the tests. The obvious question to ask is: does this non-determinism only exist in the test suite, or does it also exist in the packaged programs?
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 to specially remove it.
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&arch=arm64 The symptoms are: make[4]: Entering directory '/«PKGBUILDDIR»/test-suite' ... make[4]: *** Deleting file 'quantlib-test-suite.log' E: Caught signal ‘Terminated’: terminating immediately ... Build killed with signal TERM after 150 minutes of inactivity There are two kinds of arm64 buildd at present: Juno and Mustang. On a Mustang the build typically succeeds, but on a Juno it times out after "150 minutes of inactivity". There were 332 minutes of inactivity when I tried it on a different (possibly faster because the entire build took only 8 hours) machine, so it's missing by a wide margin. Since there's currently no mechanism for getting particular packages to be built by particular buildds you should probably for now just disable the test suite on arm64 by adding "aarch64" in https://sources.debian.net/src/quantlib/1.7-1/debian/rules/#L135 Alternatively, you could modify the test so that it generates some kind of output as it runs. A new line character every hour would presumably be sufficient. (Without a new line other characters might not get through the buffering so you shouldn't just print dots, for example.)