Martin v. Löwis [EMAIL PROTECTED]:
#include ncurses.h
#include unistd.h
int main()
{
WINDOW *win = initscr();
waddstr(win, \303\244\n);
waddstr(win, \342\200\242\n);
waddstr(win, \344\272\272\n);
refresh();
sleep(3);
endwin();
-08 -- public domain
+ */
+
+/* Adapted for mpg321 by Edmund Grimley Evans.
+ */
+
+#include mpg321.h
+#include id3tag.h
+
+/* These functions define the column width of an ISO 10646 character
+ * as follows:
+ *
+ *- The null character (U+) has a column width of 0.
+ *
+ *- Other C0/C1
Hi,
Have you looked into this idzebra bug at all?
Sorry that I can't easily contribute to bugs.debian.org.
Some observations for you:
1. There are three places in the source code where a char is passed to
isalpha or isspace. You should cast to unsigned char here, I think, to
avoid getting
Package: zlibc
Version: 0.9k-4.1
Currently it fails to build thus:
filetype.c: In function 'zlib_initialise':
filetype.c:167:16: error: 'SYS_open' undeclared (first use in this function)
fd=syscall(SYS_open,/proc/self/cmdline, O_RDONLY);
^
filetype.c:167:16: note: each
Package: gcc-4.9
Version: 4.9.0-11
When I try to build gnupg2 2.0.25-1 on arm64 using gcc-4.9 some of
the tests fail.
The object file involved is: agent/gpg_agent-gpg-agent.o
A particular test that fails is:
( cd tests/openpgp/ make check TESTS=genkey1024.test )
Other, non-Debian, binaries
Source: ogre-1.8
Version: 1.8.0+dfsg1-7
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ogre-1.8suite=sid
The error was:
/«BUILDDIR»/ogre-1.8-1.8.0+dfsg1/OgreMain/include/OgreStringConverter.h:
At global scope:
Source: libtrio
Version: 1.16+dfsg1-2
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=libtriosuite=sid
The error was:
Verification failed in regression.c:620.
Expected 03.142e+03
Got 03.141e+03
The test is expecting 3141.5 to be rounded up to 3142 rather
Source: scalapack
Version: 1.8.0-10
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=scalapacksuite=sid
The error was:
# The shared library is installed via debian/*.install, to avoid
# creating an empty package if default MPI implementation changes on
# the arch
Did you accidentally upload this without the change in debian/rules?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Source: cernlib
Version: 20061220+dfsg3-4.1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=cernlibsuite=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
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 {
/*
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 know arm
The build failure on the buildds may be caused by this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767138
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Source: sope
Version: 2.2.9-1
Thanks for trying to patch for arm64 in 2.2.9-1. Unfortunately it
still failed to build:
https://buildd.debian.org/status/package.php?p=sopesuite=sid
EOSQLQualifier.m: In function '-[EOSQLQualifier
initWithEntity:qualifierFormat:argumentsArray:]':
Source: erlang-jiffy
Version: 0.8.5+dfsg-1
It didn't build on arm64:
https://buildd.debian.org/status/package.php?p=erlang-jiffysuite=sid
The error was:
c_src/double-conversion/utils.h:71:2: error: #error Target
architecture was not detected as supported by Double-Conversion.
#error Target
In case anyone still wants to build guile-1.8, a fix (remove
declarations of 'yy*' functions in c-tokenize.lex) is described here:
http://lists.gnu.org/archive/html/guile-devel/2010-03/msg00081.html
It seems to work on arm64.
--
To UNSUBSCRIBE, email to
Source: pyzmq
Version: 14.3.1-1
It's not building on arm64:
http://buildd.debian.org/status/fetch.php?pkg=pyzmqarch=arm64ver=14.3.1-1stamp=1412167624
The error is:
Assertion failed: pfd.revents POLLIN (signaler.cpp:193)
This is exactly what used to happen on mips:
Source: blacs-mpi
Version: 1.1-32
It's not building on arm64:
http://buildd.debian.org/status/package.php?p=blacs-mpisuite=sid
The error is:
dh_install: libblacs-mpich1 missing files (libblacs-mpich.so.*), aborting
Seeing the recent changelog and bug #761946, and the dependencies of
This looks just like bug #745969, where a fix is described:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745969
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: qtbase-opensource-src
Version: 5.3.2+dfsg-2
See:
https://buildd.debian.org/status/package.php?p=qtbase-opensource-srcsuite=sid
The error is this:
.obj/qcryptographichash.o: In function `__bswap_32':
/usr/include/aarch64-linux-gnu/bits/byteswap.h:46: undefined reference
to
Source: aegisub
Version: 3.1.2-1
See http://buildd.debian.org/status/package.php?p=aegisubsuite=sid
The error is: internal compiler error: Segmentation fault
It looks like a problem with precompiled headers, quite possibly the
same bug (762702) that prevented qtbase-opensource-src from
Package: gcc-4.9
Version: 4.9.1-16
There are a couple of Debian packages that failed to build on arm64
apparently because of problems with precompiled headers:
qtbase-opensource-src
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762702
aegisub
See
please recheck with 4.9.2 and trunk (gcc-snapshot). In the past I had mixed
results with precompiled headers on AArch64.
I was able to reproduce the problem with aegisub and with qtbase-opensource-src.
Replacing 4.9.1-16 with 4.9.2-1 or 20141017-1 made no difference.
It seems strange to me
Source: doomsday
Version: 1.10.4-2
It failed to build on several ARM architectures:
http://buildd.debian.org/status/package.php?p=doomsdaysuite=sid
In each case the error was:
src/con_main.cpp: In function 'void conPrintf(int, const char*, va_list)':
src/con_main.cpp:1842:31: error: invalid
Source: inotail
Version: 0.5-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=inotailsuite=sid
The error was:
In file included from inotail.c:37:0:
inotify-syscalls.h:83:3: error: #error inotify not supported on this
architecture!
# error inotify not supported on
Source: fhist
Version: 1.18-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=fhistsuite=sid
The error was:
/bin/sh test/00/t0001a.sh
Segmentation fault
FAILED test of basic fcomp functionality
This seems to be an example of a kind of bug that has become quite
While you're at it, could you add defined(__aarch64__) to that test
so that it will build on arm64?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Source: uc-echo
Version: 1.12-7
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=uc-echosuite=sid
The error was:
g++ -c -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -m64 -Wall -O3 -D_FORTIFY_SOURCE=2 DNASeq.cpp
-o DNASeq.o
g++: error: unrecognized
Source: ltrsift
Version: 1.0.2-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ltrsiftsuite=sid
The error was:
[compile obj/src/preprocess_visitor.o]
cc: error: unrecognized command line option '-m64'
cc: error: unrecognized command line option '-m64'
make[2]: ***
Source: htslib
Version: 1.1-1
The code looks like this:
faidx_t *fai_build_core(BGZF *bgzf)
{
char c, *name;
...
while ( (c=bgzf_getc(bgzf))=0 ) {
Clearly on architectures where plain char is unsigned (arm64, armhf,
...) this won't work (infinite loop).
I'd suggest changing the type of
This can be fixed on arm64 at least by fixed this bug in htslib:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770162
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Source: uhub
Version: 0.4.1-3
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=uhubsuite=sid
The error was:
/«PKGBUILDDIR»/src/core/hub.c: In function 'hub_set_variables':
/«PKGBUILDDIR»/src/core/hub.c:929:71: error: expected ')' before 'CPUINFO'
tmp =
Source: octave
Version: 3.8.2-3
On arm64 mkoctfile -M goes into an infinite loop:
echo t.c
mkoctfile -M t.c
# it runs for ever
This may be because of this code in src/mkoctfile.in.cc:
get_line (FILE *fp)
{
static std::vectorchar buf (100);
unsigned int idx = 0;
char c;
while (true)
There is no need for the cast. Just use:
int c;
while (true)
{
c = gnulib::fgetc (fp);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Kamal Mostafa ka...@debian.org:
Edmund et al., I would appreciate your expertise here... Does it also appear
to
you that my minimodem (0.20-1) failure[0] could be caused by the fftw3 NEON
is
perhaps broken bug? Does it make sense that abel.d.o would be affected by
it, but harris and
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
Source: uid-wrapper
Version: 1.0.2-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=uid-wrappersuite=sid
The error was:
/«PKGBUILDDIR»/tests/testsuite.c: In function 'test_uwrap_syscall':
/«PKGBUILDDIR»/tests/testsuite.c:201:15: error: 'SYS_access'
undeclared (first
Source: trafficserver
Version: 5.1.1-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=trafficserversuite=sid
The error was:
Building LuaJIT 2.0.3
make -C src
make[5]: Entering directory '/«PKGBUILDDIR»/lib/luajit/src'
lj_arch.h:55:2: error: #error No
Source: librep
Version: 0.90.2-1.4
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=librepsuite=sid
The error was:
REPLISPDIR=../lisp REP_DL_LOAD_PATH=../src/.libexec REPDOCFILE=../doc-strings
../src/rep --batch -l rep.vm.compiler \
-f compile-batch rep-xgettext.jl
Source: libkqueue
Version: 2.0.3-1.1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=libkqueuesuite=sid
The error was:
src/linux/platform.c: In function 'linux_eventfd_init':
src/linux/../common/../linux/platform.h:29:31: error: 'SYS_eventfd' undeclared
(first use
Source: fribid
Version: 1.0.4-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=fribidsuite=sid
The error was:
../npapi/prcpucfg.h:705:2: error: #error Unknown CPU architecture
#error Unknown CPU architecture
It seems easy to fix. You could replace
#elif
Source: openvdb
Version: 2.3.0-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=openvdbsuite=sid
The error was:
dh_auto_test || true
make[2]: Entering directory '/«PKGBUILDDIR»'
Testing libopenvdb
export LD_LIBRARY_PATH=:/«PKGBUILDDIR»; ./vdb_test /dev/null
E:
Source: readahead-fedora
Version: 2:1.5.6-5.2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=readahead-fedorasuite=sid
The error was:
readahead-collector.c: In function 'parse_events':
readahead-collector.c:1081:21: error: '__NR_open' undeclared (first use in this
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
By the way, it might be a good idea to remove the /dev/null 21
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.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
By the way, it might be a good idea to remove the /dev/null 21
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 /dev/null 21
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.
--
To UNSUBSCRIBE,
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
Source: nwchem
Version: 6.5+r26243-3
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=nwchemsuite=sid
The error was:
gfortran -c -m64 -ffast-math -Warray-bounds -fdefault-integer-8 -O2
-g -fno-aggressive-loop-optimizations -I.
That patch, flexpart_mcmodel.patch, would fix the FTBFS on arm64, too.
(So, if you're thinking of making it conditional on the architecture
in some way, test for arm64 as well as ppc64el.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
Source: gcc-h8300-hms
Version: 1:3.4.6+dfsg2-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=gcc-h8300-hmssuite=sid
The error was:
/«BUILDDIR»/gcc-h8300-hms-3.4.6+dfsg2/builddir-h8300-hitachi-coff/gcc/../../gcc/emit-rtl.c:571:(.text+0xfd4):
relocation truncated to
And to make it work on arm64 too, please make it:
#if defined(__x86_64) || defined(__PPC64__) || defined(__aarch64__)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Source: lttngtop
Version: 0.2-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=lttngtopsuite=sid
The error was:
iostreamtop.c: In function 'add_file':
iostreamtop.c:60:22: error: '__NR_open' undeclared (first use in this function)
tmp_file-flag = __NR_open;
Source: libexplain
Version: 1.4.D001-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=libexplainsuite=sid
The error was:
libexplain/buffer/enfile.c: In function 'get_maxfile':
libexplain/buffer/enfile.c:74:21: error: 'SYS__sysctl' undeclared
(first use in this
Source: ruby-inotify
Version: 0.0.2-7
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ruby-inotifysuite=sid
The error was:
ext/inotify.c: In function 'inotify_init':
ext/inotify.c:20:18: error: '__NR_inotify_init' undeclared (first use
in this function)
return
Source: cigi-ccl
Version: 3.3.3a+svn818-7
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=cigi-cclsuite=sid
The error was:
/usr/bin/c++ -DCIGI_LITTLE_ENDIAN -Dcigicl_shared_EXPORTS -g -O2
-fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2
Source: ruby-ferret
Version: 0.11.8.5-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ruby-ferretsuite=sid
The error was:
posh.h:516:4: error: #error POSH cannot determine target CPU
# error POSH cannot determine target CPU
It seems trivial to fix. You can just
Source: kmplayer
Version: 1:0.11.3d-2
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=kmplayersuite=sid
The error was:
/«PKGBUILDDIR»/src/moz-sdk/prcpucfg.h:764:2: error: #error Unknown
CPU architecture
#error Unknown CPU architecture
The values needed for arm64
Source: bup
Version: 0.25-1
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=bupsuite=sid
The warnings and error were:
! t/test.sh save --strip-path (no match):
df: Warning: cannot read table of mounted file systems: No such file
or directory
df:
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
It seems this can be fixed on arm64 by replacing -1 with 2 in
these two lines in Kmeans/kmeans.pp:
($_tmp = $var_a($ibad, )) .= -1;
$var_a-inplace-setvaltobad(-1);
However, I don't know whether that's the right way to fix the problem
as I don't know how Perl's and PDL's type system is
This bug may be related to a problem that we observed on the arm64
buildds in 2014.
On both buildd.debian-ports.org and buildd.debian.org a number of
packages using DocBook for a long time failed to build, but then later
started working. Some of the packages involved were:
aboot dossizola
Source: libsoxr
Version: 0.1.1-1
I reported this to debian-arm a while ago:
http://lists.debian.org/debian-arm/2014/11/msg00016.html
I'm now reporting it as a bug because I have seen the same failure in
a fresh chroot on amd64. The last part of the log is:
The following tests FAILED:
1 -
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?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Almost! Instead of arm64-linux-gnu it should be aarch64-linux-gnu
in debian/rules:
-ifeq ($(DEB_HOST_GNU_TYPE),arm64-linux-gnu)
+ifeq ($(DEB_HOST_GNU_TYPE),aarch64-linux-gnu)
Thanks!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Source: masscan
Version: 1.0.3-90-g2441f18~ds0-1
It failed to build on most architectures:
http://buildd.debian.org/status/package.php?p=masscansuite=sid
In many cases the error was something like:
/tmp/ccDGfkrV.s: Assembler messages:
/tmp/ccDGfkrV.s:323: Error: unknown mnemonic `lfence' --
Probably the safest thing to do is to make hash unsigned long and
replace if (hash 0) with if (hash (unsigned long)INFINITY).
That way you have the same hash function as before, but with valid C.
In addition to that you could also make ch an unsigned char if
you think it might be helpful to
I wouldn't now of any real typographical use of the MIDDLE DOT.
It's a proper, traditional decimal point, isn't it, as taught in
British primary schools and still the normal way of doing a decimal
point in handwriting when there are no technological obstacles?
Thank you for sorting that out. Your patch (arm64-ftbfs.patch) worked for me.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: dpkg-dev
Version: 1.17.24
I'm not sure that this is a bug in dpkg-buildpackage, but there's a
problem which could perhaps be fixed there, or at least documented in
dpkg-buildpackage's man page.
The problem is that when I tried to build a random sample of packages
with sbuild -j4 there
Package: expect
Version: 5.45-6
$ perl -e 'print ((x x 5000 . \n) x 3);' | cat | wc
3 3 15003
$ perl -e 'print ((x x 5000 . \n) x 3);' | unbuffer -p cat | wc
1 1 906
It doesn't just truncate the long line; it loses the rest of the output.
If this is a hard-to-avoid
Package: sbuild
Version: 0.65.2-1
A chroot created with sbuild-createchroot seems to inherit /etc/passwd
and /etc/group from the host. In a couple of cases this resulted in
packages failing to build in the chroot:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783695
Source: apg
Version: 2.2.3.dfsg.1-2
This failed to build for me with an error like this:
./install-sh -c -m 0755 -o root -g `grep '^root:' /etc/passwd | awk
-F: '{ print $4 }'` ./apg /«PKGBUILDDIR»/debian/apg/usr/bin; \
./install-sh -c -m 0444 ./doc/man/apg.1
Source: audit
Version: 1:2.4-1
If there happens to be a user with uid 890, one of the tests fails.
adduser --uid 890 user890
The log output looks like:
./auparse_test auparse_test.cur
diff -u ../../../../auparse/test/auparse_test.ref auparse_test.cur
...
@@ -113,14 +113,14 @@
Source: skimage
Version: 0.10.1-2
It failed to build in Jessie on amd64 and arm64. In each case the
error was:
test_freeimage.TestSave.test_imsave_roundtrip(type 'numpy.uint8',
array([[ 36, 71, 111, 195, 141, 45, 192, 162, 4, 16], ... FAIL
...
FAIL:
Source: puredata
Version: 0.46.6-1
There's this code in m_pd.h:
/* in ARM 64 a varargs prototype generates a different function call sequence
from a fixed one, so in that special case we maek a more restrictive
definition for t_gotfn. This will break some code in the chaos package
in Pd
Source: pd-chaos
Version: 0.2-1
It failed to build on arm64. The error was:
cc -I/usr/include/pd -DPD -DVERSION='0.2' -fPIC -Wall -W -g -O6
-funroll-loops -fomit-frame-pointer -o libchaos.o -c libchaos.c
libchaos.c: In function 'lyapunov_eval':
libchaos.c:29:3: error: too many arguments to
I noticed that there were a couple of aarch64-related commits on Apr 20/21:
https://git.haskell.org/ghc.git/commit/0bbc2ac6dae9ce2838f23a75a6a989826c06f3f5
https://git.haskell.org/ghc.git/commit/1e8c9b81a819da8eb54405a029fc33a9f5220321
I wondered what would happen if I applied them on top of
great! Can you provide me the precise patches/files that you were using,
or simple the complete source, so I can upload them to unstable?
Here's a simplified patch based on the following two commits:
https://git.haskell.org/ghc.git/commit/0bbc2ac6dae9ce2838f23a75a6a989826c06f3f5
Source: ghc
Version: 7.8.4-3
It failed to build on arm64:
http://buildd.debian.org/status/package.php?p=ghcsuite=sid
The error was:
Registering ghc-prim-0.3.1.0...
inplace/bin/ghc-cabal register libraries/integer-gmp dist-install
/«PKGBUILDDIR»/debian/tmp/usr/lib/ghc/bin/ghc
Source: ghc
Version: 7.8.4-3
Severity: wishlist
There's been some recent talk of enabling ghci on arm64:
https://git.haskell.org/ghc.git/commit/1e8c9b81a819da8eb54405a029fc33a9f5220321
https://bugzilla.redhat.com/show_bug.cgi?id=1203951
Is there any chance of ghci on arm64 coming to Debian?
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
Source: blender
Version: 2.72.b+dfsg0-3
It failed to build in Jessie, amd64 and arm64. In each case the error
was:
/«BUILDDIR»/blender-2.72.b+dfsg0/source/blender/blenfont/intern/blf_glyph.c: In
function 'blf_glyph_add':
Source: freeorion
Version: 0.4.4-2
It failed to build in Jessie, amd64 and arm64. In each case the error
was:
/«PKGBUILDDIR»/FreeOrion/GG/src/Font.cpp: In member function 'void GG::Font::Ini
t(FT_FaceRec_*)':
/«PKGBUILDDIR»/FreeOrion/GG/src/Font.cpp:1289:41: error: ambiguous
overload for
Source: openimageio
Version: 1.4.14~dfsg0-1
It failed to build in Jessie, amd64 and arm64. In each case the error
was:
/«PKGBUILDDIR»/src/libOpenImageIO/imagebufalgo.cpp: In function 'bool
OpenImageIO::v1_4::ImageBufAlgo::render_text(OpenImageIO::v1_4::ImageBuf,
int, int, const string, int,
Source: openttd
Version: 1.4.4-2
It failed to build in Jessie, amd64 and arm64. In each case the error
was:
/«PKGBUILDDIR»/src/fontcache.cpp: In member function 'virtual const Sprite* Free
TypeFontCache::GetGlyph(GlyphID)':
/«PKGBUILDDIR»/src/fontcache.cpp:530:66: error: no matching function
for
Source: golang
Version: 1.4.2-2
Severity: wishlist
It would be nice to have Go on arm64. Upstream has it.
According to https://github.com/golang/go/milestones
they are aiming to release 1.5 around Jul 31 so perhaps
you'll want to wait till then, or perhaps a 1.5~pre would
be a good idea at some
Source: golang-ginkgo
Version: 1.1.0-1
It didn't build for me just now. The error was:
dh_auto_test: go test -v github.com/onsi/ginkgo
github.com/onsi/ginkgo/config github.com/onsi/ginkgo/ginkgo
github.com/onsi/ginkgo/ginkgo/convert
github.com/onsi/ginkgo/ginkgo/nodot
Source: pgplot5
Version: 5.2.2-19
Severity: serious
I found it failed to build in jessie or unstable on amd64. In each
case the error was the same as the one reported by the arm64 and
ppc64el buildds:
gfortran -c -u -Wall -O2 -fPIC /tmp/pgplot5/pgplot5-5.2.2/drivers/pgdriv.f
make[1]: *** No
http://gccxml.github.io/HTML/News.html says:
2015-03-26: GCC-XML has been succeeded by CastXML.
If adding arm64 to gccxml really is easy, perhaps it would be worth
doing, as it's blocking a few other packages. However, packaging
CastXML might be more useful in the longer term.
--
To
Source: fpc
Version: 2.6.4+dfsg-4
Severity: wishlist
Support for the iOS/AArch64 platform has been added to svn trunk,
and adding Linux support should not be difficult, according to:
http://www.freepascal.org/
http://lists.freepascal.org/pipermail/fpc-devel/2015-February/035397.html
Does
Source: subread
Version: 1.4.6-p2+dfsg-2
It failed to build on several architectures:
https://buildd.debian.org/status/package.php?p=subreadsuite=sid
There seems to be a problem with (unsigned) char. See this file, for
example:
Thanks for confirming.
I also had some (apparently somewhat different) problems when trying
to build golang-ginkgo on arm64 with the 1.5~pre golang which I
described in bug #784543, though the 1.5~pre golang was able to build
some other packages (golang-goprotobuf, golang-doozer, golang-log4go)
Source: cpputest
Version: 3.7.1-1
It failed to build on arm64, powerpc, ppc64el:
https://buildd.debian.org/status/package.php?p=cpputestsuite=sid
The error in the build log was:
make[3]: *** [test-suite.log] Error 1
The upstream documentation is a bit unclear, but I read somewhere that
statsmodels' documentation can be built with pandoc.
On amd64 I was able to build statsmodels after uninstalling nodejs and
installing pandoc instead.
A package called pandoc sounds like a more obvious choice for
building
I can confirm that the patch pygoocanvas-arm64.patch is still
required and still works.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Source: libv8-3.14
Version: 3.14.5.8-8.1
Severity: wishlist
Hi,
The version of libv8 currently in Debian unstable is very old. It
would be nice to have a newer version that works on arm64 so all the
dependencies could be built and tested.
Obviously you don't want lots of different versions of
Source: adplug
Version: 2.2.1+dfsg3-0.1
Tags: patch
It does not build on arm64:
https://buildd.debian.org/status/package.php?p=adplugsuite=sid
Some patches were suggested in bug #757896 to make it build on
ppc64el. It seems to have built on ppc64el without those patches, but
the same patches
Source: make-dfsg
Version: 4.0-8.1
When building with binutils 2.25-6, the version currently in unstable,
it fails to build. The output is:
features/archives ... FAILED (3/10 passed)
It's clear what's happening here. This entry in the changelog for
binutils
Source: libffi
Version: 3.1-2
Tags: patch
The latest python-cffi (0.9.2-2) seems to have exposed a bug in libffi
on arm64:
https://buildd.debian.org/status/package.php?p=python-cffisuite=sid
It seems to involve the case of small structs, that could be passed in
registers, being passed on the
1 - 100 of 361 matches
Mail list logo
