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.
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.a
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
h
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
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: ad
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_
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
Source: sivp
Version: 0.5.3+svn287-2.1
I think this package can probably be built on arm64, now that scilab
is working (bug #791990). Should it be "Architecture: any"?
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi
Source: polyml
Version: 5.5.2-2
Tags: patch
I was able to build this on arm64 with the attached trivial patch,
though I've done no other testing.
diff -ru polyml-5.5.2.orig/configure.ac polyml-5.5.2/configure.ac
--- polyml-5.5.2.orig/configure.ac
+++ polyml-5.5.2/configure.ac
@@ -408,6 +408,10 @@
I see now that there's already a separate bug for this issue on arm64:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791990
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-mai
There's the same problem on arm64:
$ /usr/bin/scilab
Could not find the Java configuration for the model . Please
contact us on http://bugzilla.scilab.org
/usr/bin/scilab-bin: error while loading shared libraries: libjava.so:
cannot open shared object file: No such file or directory
(However, get
Source: ovito
Version: 2.3.3+dfsg1-1
Severity: wishlist
It is being built for a variety of architectures:
https://buildd.debian.org/status/package.php?p=ovito&suite=sid
I didn't notice anything architecture-specific in the source code.
It seems to build on arm64.
Should arm64 be added to the A
The upstream trunk has support for arm64 since 2015-07-13:
https://github.com/polyml/polyml/commit/9d84a491c4ec5fa95c085ddcc8f9cca84bbea870
It looks like a simple patch that might apply to the last released
version (still 5.5.2).
--
debian-science-maintainers mailing list
debian-science-maintai
Source: arrayfire
Version: 3.1.2+dfsg1-1
There have been 3 attempts to build this version on the arm64 buildds
between 12:00 and 16:00 today:
https://buildd.debian.org/status/logs.php?pkg=arrayfire&arch=arm64
It was a different machine each time, but each time one of the tests
failed with a segf
The same test failed on ppc64el:
https://buildd.debian.org/status/fetch.php?pkg=mclibs&arch=ppc64el&ver=20061220%2Bdfsg3-3&stamp=1438302711
Also on arm64, where the failure looks very like the mips64el failure
reported above:
https://buildd.debian.org/status/fetch.php?pkg=mclibs&arch=arm64&ver=2
Control: tag -1 patch
> Then those two changes can be turned into a patch that can be
> installed at debian/patches/140-arm64.dpatch
Perhaps they can, but I can't now see how to do it. I don't understand
the package's patch management system.
However, the changes described above belong quite log
Package: libcolpack0v5
Version: 1.0.9-3.2
Severity: important
https://packages.debian.org/sid/libcolpack0v5 says:
dep: libstdc++6 (>= 4.9) [arm64, sparc64]
GNU Standard C++ Library v3
dep: libstdc++6 (>= 5.2) [not arm64, hurd-i386, sparc64]
I think the recent shogun build failure on arm64 w
> Gmsh fails to build on weak archs often. It is annoying to
> request "give-backs" all the time or even remove accidental
> builds on those platforms.
What do you mean by "weak arch" here? If you mean architectures with
unreliable or slow buildds then arm64 should be no weaker than armel
and armh
Firstly, I wasn't able, just now, to reproduce the build failure in
either jessie or unstable.
Secondly, I found a couple of old build logs from March. They were
done with sbuild on different but identical systems, and there is no
difference in the versions of the packages installed as reported ne
Source: dolfin
Version: 1.5.0-3
See https://buildd.debian.org/status/package.php?p=dolfin&suite=sid
The relevant part of the log is, I think:
-- The Fortran compiler identification is unknown
...
-- Try OpenMP Fortran flag = [ ]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_F
Source: freemat
Version: 4.0-5
Is there a good reason that this package Build-Depends on libffcall1-dev?
Note that the binary "freemat" package does not depend on libffcall1.
I built freemat on amd64 then rebuilt it after uninstalling libffcall1
and libffcall1-dev and found no significant differ
Source: 3depict
Version: 0.0.18-1
Tags: patch
I think you need to apply something like the attached patch. However,
you should probably read https://wiki.debian.org/Autoreconf yourself.
With the patch it built on arm64 for me. It wasn't in a fresh chroot,
but I've probably got the build-dependenc
Source: gmsh
Version: 2.8.5+dfsg-1.1
I was unable to build this from source on amd64. It went wrong near
the end:
make[1]: Leaving directory '/tmp/gmsh/gmsh-2.8.5+dfsg/debian/build'
dh_install -O--buildsystem=cmake
-O--builddirectory=/tmp/gmsh/gmsh-2.8.5\+dfsg/debian/build -O--parallel
dh_ins
Source: atlas
Version: 3.10.2-7
It failed to build on arm64 in Jessie. The error was:
make[3]: Entering directory '/«PKGBUILDDIR»/build/atlas-base/lib'
mkdir tmp
cd tmp && \
ar x ../libatlas.a && \
if test -f ../libptf77blas.a -a -f ../libptcblas.a; then \
ar x ../
The changes described above are now in the git repo:
http://github.com/b-k/apophenia
Do you want to add them as a patch to the Debian version?
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/de
The patch "fftw3_3.3.3-7-arm64-neon-support-config.patch", posted to
this bug on 2014-01-09, is still basically good, I think, and there
seem to be no internal compiler errors any more.
A good set of changes against 3.3.4-2 is:
In configure.ac, do what the earlier patch says:
- if test "$h
Here are my latest thoughts on what the run-time test for NEON should
probably look like.
Previous proposals used two static variables instead of just one, but
I think that would be less thread-safe.
The variable "cached" is used in only two places, so, provided the
access to it is atomic, the co
Some good news: the code doesn't seem to need a lot of changes to make
it work on arm64. I did this:
* Changed the type of the local variables to which the value returned
from fgetc, getopt or get_next is assigned from char to int.
* Made get_next return int instead of char, and, to make it ret
There are also several places where the value returned from getopt is
assigned to a variable of type char before being compared with -1. I
would guess that the programs are going into an infinite loop while
trying to parse their command-line arguments when char is unsigned.
--
debian-science-main
>> By the way, it might be a good idea to remove the ">/dev/null 2>&1"
>> from the command lines in case the compiler wants to warn you about
>> this sort of thing. (I don't know whether GCC does in this particular
>> case.)
>>
>
> Please could you specify the place of this code.
I was wrong. The
By the way, it might be a good idea to remove the ">/dev/null 2>&1"
from the command lines in case the compiler wants to warn you about
this sort of thing. (I don't know whether GCC does in this particular
case.)
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.d
>From the buildd logs it appears that the tests are timing out.
A quick look at apop_conversions.c suggests a plausible explanation.
In that file there is code like this:
char c = fgetc(infile);
...
while(c!='\n' && c !=EOF){
EOF is negative, and plain char is unsigned on ARM architectu
> really_have_neon is probably inlined into fftwf_have_simd_neon, because
The assembler code you quoted looks like the translation of
X(have_simd_neon) with "bl 0xa9f84" being the call to
really_have_neon().
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debi
> > Is this signal-handling approach the best way of detecting NEON? The
> > following blog suggests using HWCAP, but I don't know if that would
> > work with the freebsd kernels:
>
> looks like a better way to do it, freebsd doesn't matter for us as we
> don't have a arm port of that.
> I don't k
Source: fftw3
Version: 3.3.4-1.1
In simd-support/neon.c I found:
static int really_have_neon(void)
{
void (*oldsig)(int);
oldsig = signal(SIGILL, sighandler);
if (setjmp(jb)) {
signal(SIGILL, oldsig);
return 0;
} else {
/* parano
Source: cernlib
Version: 20061220+dfsg3-4.1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=cernlib&suite=sid
The error was:
gcc -g OptimizationLevel -D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -
35 matches
Mail list logo
