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 debian-bugs-rc-requ...@lists.debian.org
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
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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-rc-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
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
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
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
Source: gofigure2
Version: 0.9.0-3
Severity: serious
You can see the log from the recent build failure on arm64 here:
https://buildd.debian.org/status/package.php?p=gofigure2suite=sid
I got the same error on amd64.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a
Source: ginkgocadx
Version: 3.7.0.1465.37+dfsg-1
Severity: serious
You can see the log from the recent build failure on arm64 here:
https://buildd.debian.org/status/package.php?p=ginkgocadxsuite=sid
I got the same error on amd64.
--
To UNSUBSCRIBE, email to
Source: itksnap
Version: 2.2.0-1.1
Severity: serious
You can see the log from the recent build failure on arm64 here:
https://buildd.debian.org/status/package.php?p=itksnapsuite=sid
I got the same error on amd64.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a
Source: texlive-bin
Version: 2015.20150524.37493-2
Severity: serious
texlive-binaries depends unconditionally on libtexluajit2, which is
only built for
Architecture: amd64 armel armhf hurd-i386 i386 kfreebsd-amd64
kfreebsd-i386 mips mipsel powerpc
according to debian/control, but that list may
Source: dogtag-pki
Version: 10.2.0-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
It recently failed to build on arm64 with this error:
com/netscape/cms/tomcat/ProxyRealm.java:22: error: ProxyRealm is not
abstract and does not override abstract
I was able to build pgplot5 like this:
apt-get source pgplot5
dpkg-source --skip-patches -x pgplot5_5.2.2-19.dsc
cd pgplot5-5.2.2/
perl -i -pe 's/:.*/:/ if m!/usr/include/zconf!;' \
debian/patches/linker-specific-changes
dpkg-buildpackage -b
So the fix could be a one-line change in that
Upstream 0.8.4 seems to build easily on Debian unstable
(the build system has changed since 0.7.6):
apt-get install debhelper cdbs libtool automake1.11 autoconf \
pkg-config libxerces-c-dev libboost-signals-dev libboost-regex-dev \
libfreetype6-dev libtiff-dev libgl1-mesa-dev libglu1-mesa-dev
Is the source for 5.9.0-1 still available somewhere?
I tried to reconstruct it from git, and it looked as though I got the
same build failure on arm64 unstable as 5.11.0-1 gave on 2015-06-26,
although 5.9.0-1 was built successfully on 2015-04-23. So it looks as
though a change in some other
Ideally we should tests the tests on an arm* machine running X11 and see what
happens there (and that means not calling xvfb too).
Do you mean running an X server? Why would that be necessary? Could
the test be making use of an X server other than in the usual way,
through DISPLAY?
It is
Source: gstreamermm-1.0
Version: 1.4.3+dfsg-2
Severity: serious
The changelog has full month names (June/July) instead of three-letter
abbreviations (Jun/Jul):
https://sources.debian.net/src/gstreamermm-1.0/1.4.3%2Bdfsg-2/debian/changelog/
This is wrong:
Source: docker.io
Version: 1.7.1~dfsg1-1
Severity: serious
It failed to build on arm64, ppc64 and ppc64el:
https://buildd.debian.org/status/package.php?p=docker.io=sid
There is a different error in each case, unfortunately, and on an
up-to-date amd64 system there is a yet another, different
The new docker.io 1.8.2~ds1-1 is BD-Uninstallable on arm64 and several
other architectures because of mongodb. On arm64:
(https://buildd.debian.org/status/package.php?p=docker.io=sid)
docker.io build-depends on:
- arm64:golang-github-hashicorp-go-msgpack-dev (>= 0.0~git20140221~)
This line in debian/control seems to be wrong:
Provides: libgd2-dev, libgd2-xmp-dev, libgd2-noxpm-dev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
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.
> 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
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
You don't have this patch, I think:
https://reviews.llvm.org/D22095
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
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.
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,
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.
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.
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
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
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
swarmkit should build-dep on golang-github-docker-docker-dev (>=
1.13.1~), or something like that.
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
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
39 matches
Mail list logo
