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

[Edmund Grimley Evans]

> 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

[Edmund Grimley Evans]

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

[Edmund Grimley Evans]

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)

[Edmund Grimley Evans]

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

[Edmund Grimley Evans]

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

[Edmund Grimley Evans]

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"

[Edmund Grimley Evans]

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"

[Edmund Grimley Evans]

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

[Edmund Grimley Evans]

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

[Edmund Grimley Evans]

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"

[Edmund Grimley Evans]

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=sid

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

[Edmund Grimley Evans]

As described in https://github.com/torch/torch7/issues/1035, it seems
that LuaJIT provides only "a limited range of 47 bits for the legacy
lightuserdata data type". Therefore, lua-torch-torch7 can only be
built and run on systems that use virtual addresses with no more than
47 bits. Today many 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

[Edmund Grimley Evans]

I was able to build rnahybrid 2.1.2-3 on armel in 104 minutes on some
more powerful hardware. I must definitely retract what I've said about
an "infinite loop".

Replacing loop nests with memset did not make a huge difference (I
gave up after 26 minutes).

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

[Edmund Grimley Evans]

Yes, it's not an infinite loop; it just takes an inordinate amount of time.

The code that triggers this seems to be a long sequence of assignments
initialising elements of a multi-dimensional array.

There are some big variations in the build times on some other
architectures, too. For example on 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

[Edmund Grimley Evans]

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

Bug#876825: gcc: infinite loop targeting armel

[Edmund Grimley Evans]

The problem still seems to occurs with:

- version 6.4.0-3cross1 of gcc-6-arm-linux-gnueabi (on amd64)

- version 7.2.0-7 of gcc-7 (on armel)

It's perhaps not really an infinite loop but just an unreasonably long time.
Perhaps someone should try running it over the weekend...

Bug#861281: rnahybrid: FTBFS on armel

[Edmund Grimley Evans]

For what it's worth, rnahybrid seems to build on armel with this in
debian/rules:

export DEB_CFLAGS_MAINT_APPEND=-O0

Perhaps it would work with -O1 if I had more patience.

Bug#861281: rnahybrid: FTBFS on armel

[Edmund Grimley Evans]

> The failure in build may in fact just be because the build machine is
> too slow.

It's a possibility to bear in mind, definitely, but the
perhaps-infinite loop can be observed with a cross-compiler:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876825

(I will test with the compilers in 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=armel

Bug#861281: rnahybrid: FTBFS on armel

[Edmund Grimley Evans]

The infinite loop is still there with gcc-7. I've created bug #876825.

Before you exclude armel, you could perhaps try doing something about
this warning, which is given not just on armel and may or may not be
related to the compiler going into an infinite loop:

energy.c:539:104: warning: 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

[Edmund Grimley Evans]

Package: gcc-6-arm-linux-gnueabi
Version: 6.3.0-18cross1

This is not specific to cross-compiling and not even to gcc-6.

We noticed the infinite loop when the buildd tries to build rnahybrid:

https://buildd.debian.org/status/logs.php?pkg=rnahybrid=armel

It seems to be easy to reproduce with the 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

[Edmund Grimley Evans]

I think this bug was fixed in 2.1.0~beta3. Can it be closed please?
Any objections?

# tail -n 1 /proc/self/maps
eb71-eb731000 rw-p  00:00 0  [stack]

# dpkg -i libluajit-5.1-2_2.1.0~beta2+dfsg-1_arm64.deb
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

[Edmund Grimley Evans]

Source: jellyfish1
Version: 1.1.11-1
User: debian-...@lists.debian.org
Usertags: arm64

This package builds on arm64 if you change the type of dna_codes from
"char" to "signed char":

perl -i -pe 's/char/signed char/;' jellyfish/dna_codes.cc
jellyfish/dna_codes.hpp

It may build on other 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

[Edmund Grimley Evans]

> Well, technically it might be correct, but I doubt that there is a
> working pipeline involving tophat, bowtie and friends on non-amd64
> architectures.

On the other hand, if you have a heterogeneous cluster then perhaps
you don't need or want all elements of the pipeline to run on the same
architecture.

Bug#873866: tophat: Please add arm64

[Edmund Grimley Evans]

> It might be that tophat builds on other architectures but it Depends
> bowtie2 | bowtie and these are only available on the explicitly
> specified architectures.

Bowtie2 is not yet available on arm64, but bowtie is, so a dependency
on "bowtie2 | bowtie" should not be an obstacle.

Bug#871697: jellyfish: Please add arm64

[Edmund Grimley Evans]

> unfortunately the bug does not seem to be sufficient.  See
>
> 
> https://buildd.debian.org/status/fetch.php?pkg=jellyfish=arm64=2.2.6-5=1504220784=0
>
> Any further hints?

"portability.patch" is commented out in debian/patches/series and was
not applied?

Bug#873866: tophat: Please add arm64

[Edmund Grimley Evans]

Source: tophat
Version: 2.1.1+dfsg-3
User: debian-...@lists.debian.org
Usertags: arm64

It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?

Bug#873864: mrs: Please add arm64

[Edmund Grimley Evans]

Source: mrs
Version: 6.0.5+dfsg-2
User: debian-...@lists.debian.org
Usertags: arm64

It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?

Bug#873865: relion: Please add arm64

[Edmund Grimley Evans]

Source: relion
Version: 1.4+dfsg-2
User: debian-...@lists.debian.org
Usertags: arm64

It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?

Bug#873859: gasic: Please add arm64

[Edmund Grimley Evans]

Source: gasic
Version: 0.0.r19-1
User: debian-...@lists.debian.org
Usertags: arm64

It seems to be possible to build this package on arm64.
Is there any reason why it would not work on arm64?

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

[Edmund Grimley Evans]

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

Bug#871697: jellyfish: Please add arm64

[Edmund Grimley Evans]

Instead of:   "pand " off
It should be: "pand " #off

(It may be necessary to disable "-Werror": an unrelated issue.)

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

[Edmund Grimley Evans]

Source: lua-torch-torch7
Version: 0~20170720-gaed3171-2
User: debian-...@lists.debian.org
Usertags: arm64

This package may work on arm64 now that luajit is available on that
architecture.

Bug#800546: guymager: please add arm64

[Edmund Grimley Evans]

> Why I don't use "Architecture: any" in guymager is that its
> Build-Dependency libguytools2 is known to support only those
> architectures:
>
>   Architecture: i386 amd64 powerpc armhf arm64
>
> If I'm using "Architecture: any" in guymager and it fails to build
> on those unsupported 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=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

[Edmund Grimley Evans]

Source: jellyfish
Version: 2.2.6-1
User: debian-...@lists.debian.org
Usertags: arm64

Jellyfish seems to be easy to port. Just provide alternatives to the
inline assembler in rectangular_binary_matrix.hpp:

#ifdef __x86_64__
#define AND_XOR(off)\
asm("movdqa (%[s],%[i]), %[load]\n\t"   \
"pand " #off "(%[p]),%[load]\n\t"   \
"pxor %[load],%[acc]\n\t"   \
: [acc]"="(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

[Edmund Grimley Evans]

It was very easy to "build" this package on arm64. All I did was:

* Modify each konfigure.perl to set $BITS = 64 instead of
  die "unrecognized Architecture '$ARCH'".

* Provide ngs-sdk/ngs/unix/aarch64/atomic32.h containing stubs.

Now, if you wanted the package to actually work, you would 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

[Edmund Grimley Evans]

Source: ggcov
Version: 0.9-15
User: debian-...@lists.debian.org
Usertags: arm64

Would it be possible to add arm64?

With gcc-7 there's #853417, but with gcc-6 the only test failure on
arm64 is test033, where all the asserts are "PC" rather than "CO", and
the abort is "UN" rather than "SU". Does 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

[Edmund Grimley Evans]

> As far as I can see all tests are disabled, failing tests means that
> the software has bugs, and I'm not sure whether we want to allow
> software with known bugs into the archives.

Yes, but if the bug is in the test then disabling the test is one way
of fixing the bug.

On the other hand, a 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

[Edmund Grimley Evans]

Source: mlucas
Version: 14.1-2
User: debian-...@lists.debian.org
Usertags: arm64

This package can easily be ported to arm64: in src/platform.h
recognise the architecture with defined(__aarch64__) and configure
it the same as amd64.

Also, the many mentions of "unknown" in platform.h suggest
that 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

[Edmund Grimley Evans]

Control: user debian-...@lists.debian.org
Control: usertag -1 + arm64

Please consider adding arm64.

Ubuntu built 4.9.0, 4.10.0 and 4.10.1 on arm64:

http://ports.ubuntu.com/ubuntu-ports/pool/universe/i/insighttoolkit4/

Though it looks like they may have ignored a few test failures to get there:

https://launchpad.net/ubuntu/+source/insighttoolkit4/+changelog

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

[Edmund Grimley Evans]

James:

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

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

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

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

Bug#871515: picolisp: Please add arm64

[Edmund Grimley Evans]

Source: picolisp
Version: 17.6-1
User: debian-...@lists.debian.org
Usertags: arm64

The arm64 version of PicoLisp was announced on 16 Nov 2015:

http://www.mail-archive.com/picolisp@software-lab.de/msg05727.html

And "arm64" is mentioned in INSTALL:

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

[Edmund Grimley Evans]

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

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

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

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

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

[Edmund Grimley Evans]

As far as I know, the best way to implement run-time detection of
hardware capabilities is with getauxval(AT_HWCAP) and
getauxval(AT_HWCAP2).

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

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

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

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

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

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

[Edmund Grimley Evans]

Source: handbrake
Version: 1.0.7+ds1-2
User: debian-...@lists.debian.org
Usertag: arm64

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

Bug#791976: Please support ARM64

[Edmund Grimley Evans]

This is being worked on upstream:

https://github.com/ldc-developers/ldc/issues/1931
https://github.com/ldc-developers/ldc/issues/2150
https://github.com/ldc-developers/ldc/issues/2153

Bug#868165: emacs25: FTBFS on arm64

[Edmund Grimley Evans]

The Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/emacs25/+bug/1656474

Memory corruption reported on mailing list:
http://lists.gnu.org/archive/html/emacs-devel/2017-03/msg00827.html

It looks like Emacs Lisp may be involved. Does Emacs Lisp use tagged
pointers? Pointers have fairly 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

[Edmund Grimley Evans]

I think that test takes a long time because it is using long double,
which on arm64 has 128 bits and is implemented in software. Possible
things to do:

* Change the default type (however and wherever it is defined) from
"long double" to "double" on arm64, and perhaps other architectures.

* Get 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)

[Edmund Grimley Evans]

This robopatch seems to fix the problem on arm64 with 48-bit addresses:

perl -i -pe 's/longlong/ulonglong/g if /\(\s*longlong.*(<<|>>)/ &&
!/gen\(longlong/;' src/*.cc

The idea is to change the type whenever there seems to be a cast
followed by a shift. The last condition is to avoid a couple of
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)

[Edmund Grimley Evans]

So giac was supposed to be working now on arm64, but it failed on the buildd:

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

Having recently seen something similar I think I can guess what's happening.

User virtual addresses on Linux arm64 may have 39, 42 or 48 bits,
depending on how 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 *) ) >> 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

[Edmund Grimley Evans]

Source: ghc
Version: 8.0.1-17+b1

If I try to run "ghc" in one of my armhf chroots, it does not work very well:

$ ghc
Illegal instruction

The offending instruction is this one:

mcr 15, 0, r6, cr7, cr10, {5}

This is, I think, an ARMv6 memory barrier, and these instructions are,
if I recall 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

[Edmund Grimley Evans]

Source: ghc
Version: 8.0.1-17+b1

If I try to run "ghc" in one of my armhf chroots, it does not work very well:

$ ghc
Segmentation fault

$ wget http://ftp.debian.org/debian/pool/main/g/ghc/ghc_8.0.1-17+b1_armhf.deb
$ ar pf ghc_8.0.1-17+b1_armhf.deb data.tar.xz | tar xJf -
$ readelf -l 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)"

[Edmund Grimley Evans]

Source: gocryptfs
Version: 1.2.1-1
Severity: serious

This arm64 build log shows the error:

https://buildd.debian.org/status/fetch.php?pkg=gocryptfs=arm64=1.2.1-1=1497480941=0

The same error also happens on amd64 with the latest
golang-github-hanwen-go-fuse-dev from unstable,
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

[Edmund Grimley Evans]

Control: user debian-...@lists.debian.org
Control: usertag -1 + arm64

It built on arm64 when I tried it. I didn't test it in any other way,
but perhaps you could add "arm64" to the Architecture line (replacing
the obsolete "arm").

Bug#832502: xorp: Build for arm too

[Edmund Grimley Evans]

Control: user debian-...@lists.debian.org
Control: usertag -1 + arm64

No experimentation seems to be required. Ubuntu's
"xorp_1.8.6~wip.20160715-2ubuntu1" is identical to Debian's
"xorp_1.8.6~wip.20160715-2" apart from debian/changelog and
debian/control, where Ubuntu has "Architecture: any".

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

[Edmund Grimley Evans]

An update to this ancient bug:

Debian is still on version 4.2.8, released in 2008, and is including
this antique version with Stretch.

Upstream is now on 4.8.8, released in Feb 2017.

It looks as though Fedora has version 4.8.8, packaged under the name
"gambit-c", with "aarch64" (~ arm64) and "armv7hl" (~ armhf) among its
architectures.

Bug#864682: xine-plugin: FTBFS on arm64

[Edmund Grimley Evans]

Source: xine-plugin
Version: 1.0.2-4
User: debian-...@lists.debian.org
Usertags: arm64

On arm64 it failed to build like this (see
https://buildd.debian.org/status/package.php?p=xine-plugin=sid):

In file included from ../include/prtypes.h:58:0,
 from ../include/npapi.h:51,
 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

[Edmund Grimley Evans]

The pattern of failures certainly looks like that of a program that
assumes char is signed... and, indeed, this seems to fix it:

- In io.web, change the return type of get() and peek() from char to int.

- In scan.web, change the type of prev_char, curr_char and next_char
from char to int.

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

[Edmund Grimley Evans]

I was able to build this package on arm64 after adding
"dh_autoreconf" just before the "./configure" line, and
"dh_autoreconf_clean" just before "dh_clean", in debian/rules.

One must presumably also add "dh-autoreconf" to the
Build-Depends.

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

[Edmund Grimley Evans]

Trying this same short program with version 20061220+dfsg3-4.3 of
cernlib in a Stretch chroot on amd64:

$ gfortran hbktst.f -o hbktst `cernlib packlib`
$ ./hbktst
 RZMAKE. Unit   1003 Initializing with LREC=  1024, OPT= X?C

LOCB/LOCF: 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=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

[Edmund Grimley Evans]

This is easy to fix: in "Arch.hs" just use the smaller value of
maxBigIntWidth on any unrecognised architecture.

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

[Edmund Grimley Evans]

The fix is described here:

https://github.com/spacemonkeygo/spacelog/issues/6

Add golang-golang-x-sys-dev to the Build-Depends, and in capture_other.go
replace "syscall" with "golang.org/x/sys/unix",
and each "syscall." with "unix.".

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

[Edmund Grimley Evans]

The comparison makes no sense on any arch. Just replace "if (args !=
NULL)" with "if (1)".
It then builds on arm64.

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

[Edmund Grimley Evans]

I was able to build this package on arm64 by disabling the "JIT" as follows.
Please implement something similar in the next upload.

--- libretro-desmume-0.9.11+git20160819+dfsg1.orig/debian/rules
+++ libretro-desmume-0.9.11+git20160819+dfsg1/debian/rules
@@ -12,11 +12,15 @@
 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

[Edmund Grimley Evans]

Source: golang-defaults
Version: 2:1.7~5
User: debian-...@lists.debian.org
Usertags: arm64

This issue has been fixed upstream and in 1.8:

https://github.com/golang/go/issues/13191

If you follow the links from there you can read how this bug
apparently affects Kubernetes and how the fix has been 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

[Edmund Grimley Evans]

Source: golang-github-hanwen-go-fuse
Version: 0.0~git20161210.0.6c2b7d8-2
Control: affects -1 + gocryptfs

"const PAGESIZE = 4096":

https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hanwen-go-fuse.git/tree/fuse/types.go#n11

This is not portable. On arm64, the page size can be 4096, 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

[Edmund Grimley Evans]

The tests "tStatisticsUtilities" and "tLatticeStatistics" can be made
to pass on arm64 with these adjustments to the expected accuracy:

--- casacore-2.2.0.orig/lattices/LatticeMath/test/tLatticeStatistics.cc
+++ casacore-2.2.0/lattices/LatticeMath/test/tLatticeStatistics.cc
@@ -419 +419 @@
-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

[Edmund Grimley Evans]

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

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

[Edmund Grimley Evans]

Source: lepton
Version: 1.2.1+20170405-1

I was able to build it on arm64 with just a few changes:

1. Change to "Architecture: any" in debian/control, obviously.

2. In debian/rules, use:
CPPFLAGS="-DUSE_SYSTEM_MD5_DEPENDENCY" dh_auto_configure --
--enable-system-dependencies --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

[Edmund Grimley Evans]

I've played a bit with trying to build this package on arm64:

sudo apt-get install ...
dpkg-source -x ldc*.dsc
cd ldc-1.1.1/
dpkg-buildpackage -b -d

The first five or so errors were compile-time "static assert" errors
in code that looks like floating-point library code. In each case I
could 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

[Edmund Grimley Evans]

This has been fixed upstream. The fix is here:

https://github.com/numpy/numpy/pull/8713
https://github.com/numpy/numpy/commit/2fe5a4757e840362b7158e8548e26ffc9ef8b562

Only the one-line addition to loops.c.src is required; the rest is a test.

Could we have this fixed in Stretch?

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

[Edmund Grimley Evans]

Package: python-numpy
Version: 1:1.12.1-2

On amd64:

$ python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> abs(numpy.nan)
nan
>>> numpy.abs(numpy.nan)
nan
>>>

On arm64:

$ 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=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

[Edmund Grimley Evans]

On arm64 and at least one other architecture, the error says:

-3.2862601528904633e-16 != 0

It looks as though the test is computing (1.2 * 3.4 - 3.4 * 1.2).

Now, the log to base 2 of (1.2 * 3.4) divided by 3.286e-16 is about
53.5. There are 52 bits in the mantissa of a 64-bit float, or 53
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

[Edmund Grimley Evans]

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

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

[Edmund Grimley Evans]

I was able to build giac 1.2.3.25+dfsg1-3 on arm64 with this "patch":

perl -i -pe 's/^#ifdef __x86_64__$/#if 1/;' src/gen.h
perl -i -pe 's/^#ifndef __x86_64__$/#if 0/;' src/first.h

Obviously that change would break it on 32-bit architectures. A proper
fix might be to use something like ~(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)

[Edmund Grimley Evans]

On arm64, if you run under GDB and look at the address that faulted it's
clear that the address has been truncated to 32 bits. And there's some
obvious code in src/gen.h that looks as if it's truncating addresses
to 32 bits on any architecture that isn't x86_64. However, I don't
think gen.h is the 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=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

[Edmund Grimley Evans]

You don't have this patch, I think:

https://reviews.llvm.org/D22095

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

[Edmund Grimley Evans]

> Unfortunately, this one line fix does not solve the problem of the LLVM
> build hanging during the sanitizer tests.
>
> Both issues appeared around the same time and seem to be linked to specific
> kernel versions.

Julia started failing when the kernel started using more bits in
virtual 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

[Edmund Grimley Evans]

This problem is caused by:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862360

How I discovered this, would be a long story.

The effect of the LLVM bug is to OR the register field of a
"movz xD, #IMM, lsl #48" with bits 43-47 of an address. With some
kernels those bits are always zero, so 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

[Edmund Grimley Evans]

Source: llvm-toolchain-3.8
Version: 1:3.8.1-23

Please apply this upstream bug fix to Debian's llvm-toolchain-3.8
before the release:

https://reviews.llvm.org/D27609?id=80860

See line 360 of RuntimeDyldELF.cpp.

The bug prevents julia from running on some arm64 systems and may
have other bad 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..

[Edmund Grimley Evans]

It built on arm64 on the second attempt. So you can probably downgrade
this bug, or close it altogether if nobody can reproduce the build
failure.

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

[Edmund Grimley Evans]

It worked on arm64 on the third attempt. The second failure was
different from the first failure. So perhaps worth trying several
times on other architectures.

Bug#861281: rnahybrid: FTBFS on armel

[Edmund Grimley Evans]

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

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

[Edmund Grimley Evans]

Source: ntp
Version: 1:4.2.8p10+dfsg-1
Severity: wishlist

I posted a question to debian-users
(https://lists.debian.org/debian-user/2017/03/msg00591.html) and
nobody said "This already works" or "This is a bad idea", so I'm
filing this bug.

It would be nice if clock_gettime(CLOCK_TAI, ...) would 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, _utc1)) {
printf("clock_gettime(CLOCK_UTC, ...) failed\n");
exit(1);
}
if (clock_gettime(CLOCK_TAI, _tai)) {
printf("clock_gettime(CLOCK_TAI, ...) failed\n");
exit(1);
}
if (clock_gettime(CLOCK_UTC, _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

[Edmund Grimley Evans]

Source: tangerine
Version: 0.3.4-6
Tags: patch
User: debian-...@lists.debian.org
Usertags: arm64

It failed to build on arm64:

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

The error was:

src/inotify-syscalls.h:47:3: error: #error "Unsupported architecture!"
 # error "Unsupported 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

[Edmund Grimley Evans]

Me:

> Another thing: I went for "Graphical install" but ended up using the
> keyboard rather than the mouse. If I remember correctly, buttons at
> the bottom of the screen were not accessible using the mouse because
> the mouse pointer would wrap around back to the top of the screen a
> few 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

[Edmund Grimley Evans]

Package: installation-reports

Yesterday I tried to install Debian testing on a ThinkPad T43p
using the then current version of debian-testing-i386-netinst.iso,
which was dated 2016-08-22. I chose the default at almost all stages
and everything seemed to work up to the bit where it told me to 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

[Edmund Grimley Evans]

An "ARM64 port of the Mono runtime" has been released under the MIT
licence, according to this announcement (31 Mar 2016):

http://www.mono-project.com/news/2016/03/31/mono-relicensed-mit/

Source code seems to be here:

https://github.com/mono/mono

Bug#818737: gpx: FTBFS on many architectures

[Edmund Grimley Evans]

Source: gpx
Version: 2.4.1+markwal-1
User: debian-...@lists.debian.org
Usertags: arm64

It failed to build on many architectures, apparently the ones with
plain char unsigned:

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

The error was an infinite loop and a time-out:

make[3]: *** [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

[Edmund Grimley Evans]

Source: libcereal
Version: 1.1.2-3
User: debian-...@lists.debian.org
Usertags: arm64

Thanks for applying the upstream patch that fixes what appeared to be
a problem for architectures with unsigned plain char.

Version 1.1.2-3 builds on arm64 if you remove the Build-Depends on
g++-multilib. The 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

[Edmund Grimley Evans]

Source: afnix
Version: 2.6.2-1
Tags: patch
User: debian-...@lists.debian.org
Usertags: arm64

It failed to build on arm64:

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

The error was:

./cnf/bin/afnix-setup -o --prefix=/usr
afnix-setup: cannot determine linking type

I'm attaching a 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

[Edmund Grimley Evans]

Source: nordlicht
Version: 0.4.4-1
Tags: patch
User: debian-...@lists.debian.org
Usertags: arm64

It failed to build on ARM architectures and presumably on other
architectures with plain char unsigned:

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

There's a "char c" in main.c.
Change it to "int c", because poptGetNextOpt returns int.
That's your patch.

Bug#810505: irqbalance: FTBFS on arm64

[Edmund Grimley Evans]

Source: irqbalance
Version: 1.1.0-1
Tags: patch
User: debian-...@lists.debian.org
Usertags: arm64

It failed to build on arm64:

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

It built with the attached patch, which corrects two typos,
apparently.
diff -ru 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

[Edmund Grimley Evans]

Control: tags -1 patch

Here's a patch made by following the instructions at
https://wiki.debian.org/Autoreconf

It seems to work on arm64.
diff -ru dbacl-1.12.orig/debian/control dbacl-1.12/debian/control
--- dbacl-1.12.orig/debian/control
+++ dbacl-1.12/debian/control
@@ -1,7 +1,7 @@
 Source: 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

[Edmund Grimley Evans]

I'd say this is a bug in dpkg-shlibdeps in dpkg-dev.

Referring to the example above, on arm64 "test" does depend on
ld-linux-aarch64.so.1 because, although "__stack_chk_guard" is defined
in "test", there's also a relocation referring to the one in
/lib/ld-linux-aarch64.so.1:

$ nm test | grep 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

[Edmund Grimley Evans]

Source: julia
Version: 0.4.2-2
Tags: patch
User: debian-...@lists.debian.org
Usertags: arm64

It failed to build on arm64:

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

The error was:

signal (6): Aborted
gsignal at /lib/aarch64-linux-gnu/libc.so.6 (unknown line)
Aborted

The problem 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

[Edmund Grimley Evans]

> Presumably you can manually configure it to use the "dummy"
> implementation on an Intel processor. Does that work?

It appears not to. The 3 failures that occurred on armhf can be
obtained on amd64 thus:

./configure --enable-dummy
make
make check

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

[Edmund Grimley Evans]

ftp://selab.janelia.org/pub/software/hmmer3/3.1b2/Userguide.pdf says:

"""
Processor: HMMER depends on vector parallelization methods that are
supported on most modern processors. H3 requires either an
x86-compatible (IA32, IA64, or Intel64) processor that supports the
SSE2 vector instruction set, 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

[Edmund Grimley Evans]

A lot of the test failures seen in
https://buildd.debian.org/status/fetch.php?pkg=hmmer=arm64=3.1b2-1=1436134634
are not easily reproducible.

For example, when I tried

cd testsuite/
touch tmp ; rm tmp* ; ./i9-optional-annotation.pl .. .. tmp

it gave "ok" most of the time, but every now 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

[Edmund Grimley Evans]

> Should we even consider not building at all?

I think you should build it on arm64, where it could easily be useful.

I'm not so sure about people using quantlib on armel systems, which
are typically very low-performance, but, seeing as it builds there
(without the tests), I don't see a reason to specially remove it.

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

[Edmund Grimley Evans]

Source: quantlib
Version: 1.7-1
User: debian-...@lists.debian.org
Usertags: arm64

You've probably noticed that quantlib sometimes fails to build on the
arm64 builds:

https://buildd.debian.org/status/logs.php?pkg=quantlib=arm64

The symptoms are:

make[4]: Entering directory '/«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.)