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
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
swarmkit should build-dep on golang-github-docker-docker-dev (>=
1.13.1~), or something like that.
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
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
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
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 recent
Source: gocryptfs
Version: 1.2.1-1
Severity: serious
This arm64 build log shows the error:
https://buildd.debian.org/status/fetch.php?pkg=gocryptfs&arch=arm64&ver=1.2.1-1&stamp=1497480941&raw=0
The same error also happens on amd64 with the latest
golang-github-hanwen-go-fuse-dev from unstable,
0
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.
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
includ
You don't have this patch, I think:
https://reviews.llvm.org/D22095
> 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 addresse
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 n
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.
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.
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.
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&suite=sid)
docker.io build-depends on:
- arm64:golang-github-hashicorp-go-msgpack-dev (>= 0.0~git20140221~)
arm64:gola
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&suite=sid
There is a different error in each case, unfortunately, and on an
up-to-date amd64 system there is a yet another, differen
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:
https://www.debian.org/doc/debian-policy
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
> 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 poss
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 packag
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 b
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=gofigure2&suite=sid
I got the same error on amd64.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a su
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=ginkgocadx&suite=sid
I got the same error on amd64.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debia
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=itksnap&suite=sid
I got the same error on amd64.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subj
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
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
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 patc
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 do
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 rule
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
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
Kamal Mostafa :
> 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 asachi would
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
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 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
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 diffe
39 matches
Mail list logo