Source: s-nail
Version: 14.8.5-2
User: debian-...@lists.debian.org
Usertags: arm64
It failed to build on several architectures:
https://buildd.debian.org/status/package.php?p=s-nail&suite=sid
It seems to go into an infinite loop while running tests.
This symptom and the pattern of failures is t
Source: miller
Version: 2.3.2-1
User: debian-...@lists.debian.org
Usertags: arm64
It failed to build on many architectures:
http://buildd.debian.org/status/package.php?p=miller&suite=sid
In some cases the error was:
FAIL: test_peek_file_reader
I noticed this line of code in there:
mu_
Thank you for the interesting bug report!
The test case reveals two bugs in the old version of tcc: firstly,
"1 ? 1 : 1" was not recognised as a constant expression, so
"unsigned ip[1 ? 1 : 1]" was treated as a variable-length array (VLA),
and, secondly, there was a bug in the handling of VLAs.
T
In case anyone wants to know, the upstream commit that fixed this bug:
commit 5bcc3eed7b93f5e75b0bb121913f84f574b7c46a
Date: Tue Mar 10 23:23:00 2015 +0800
http://repo.or.cz/tinycc.git/commit/5bcc3eed7b93f5e75b0bb121913f84f574b7c46a
I think this bug was fixed by this upstream commit:
commit 30c54c9d433f5cc213912afd2ed04808cd9a4a23
Date: Thu Nov 19 23:45:33 2015 +
http://repo.or.cz/tinycc.git/commit/30c54c9d433f5cc213912afd2ed04808cd9a4a23
> It seems this is not a problem on all arm64 boxes. On IRC suihkulokki
> found that it worked on his self compiled 4.2 kernel. Some poking about
> with strace revealed that in the cases where dtach worked (whether
> arm64, or my amd64 box), statfs("/dev/pts") returns DEVPTS_SUPER_MAGIC,
> while i
Paul Gevers:
> On 02-11-15 20:11, Edmund Grimley Evans wrote:
> > I was able to build libqt4pas, lazarus and pasdoc using the new fpc.
> > I just had to update the symbols file for libqt4pas.
>
> Do you still have your update for the symbols file? I suggest filing a
Control: tags -1 patch
Patch attached.
diff -ru mcrypt-2.6.8.orig/debian/control mcrypt-2.6.8/debian/control
--- mcrypt-2.6.8.orig/debian/control
+++ mcrypt-2.6.8/debian/control
@@ -6,7 +6,7 @@
Homepage: http://mcrypt.sourceforge.net/
Vcs-Browser: http://git.debian.org/?p=collab-maint/mcrypt.git
Source: transgui
Version: 5.0.1-2
The Debian build script seems to be using upstream's Makefile,
which was "generated by FPCMake Version 2.0.0 [2011/12/25]".
It would be better to regenerate this file for two reasons:
- It becomes possible to build the package on new architectures,
such as arm6
Source: doublecmd
Version: 0.6.6-1
I tried to build this on arm64 with fpc 3.0.0 and got this error:
.../doublecmd-0.6.6/components/doublecmd/dcosutils.pas(240,24) Error: (5000)
Identifier not found "syscall_nr_lchown"
On arm64, and other recent architectures, the lchown system call has
been re
As far as I can tell, to fix this bug it is sufficient to add
autotools-dev to the Build-Depends.
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"?
> I will try to upload the arm64 packages and then I will upload
> 3.0.0~rc2+dfsg-2 to apply the arm64 patches and to fix the armhf FTBFS.
> When that has landed, the arm64 package should be build natively.
I see you've uploaded the arm64 binaries. Perhaps just 3 lines need to
be changed now:
-
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
> Do you by any chance would have a recipe to build this ppca64 by
> cross-compiling, starting with the current source in Debian?
Here's a recipe using the source in the Debian repo, if that counts.
I don't think the AArch64 back-end has been uploaded yet.
apt-get install binutils-aarch64-linux-
Here's a patch that I've tested on arm64, amd64 and i386.
The file aarch64_fpmath.h is copied from upstream.
Although the build finished on amd64, I now realise that I presumably
got it wrong when I added "(arch=i386 kfreebsd-i386 hurd-i386)" to the
symbols file: amd64 should be in that list too.
Source: openlibm
Version: 0.4.1+dfsg-3
Tags: patch
This builds on arm64 with very few changes. With the attached patch it
passed the test suite and only failed at the dh_makeshlibs stage
because of the list of symbols.
A few notes on the patch:
In several places Intel becomes another architectur
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: etcd
Version: 2.2.0+dfsg-2
It failed to build:
https://buildd.debian.org/status/package.php?p=etcd&suite=sid
In each case the error was:
# github.com/boltdb/bolt
src/github.com/boltdb/bolt/db.go:85: undefined: maxMapSize
src/github.com/boltdb/bolt/db.go:85: invalid array bound maxMapSiz
I must have been thinking of an entirely different programming
language. For some reason I was thinking that the undefined syscall
was a run-time rather than a compile-time error. Clearly you can't use
Dup2 at all on arm64. Does that mean you need two additional source
files, one with "// +build ar
Source: golang-ginkgo
Version: 1.2.0-1
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=golang-ginkgo&suite=sid
The error was:
src/github.com/onsi/ginkgo/internal/remote/output_interceptor_unix.go:34:
undefined: syscall.Dup2
src/github.com/onsi/ginkgo/internal/remote
Source: aspectc++
Version: 1:1.2+svn20150823-1
Tags: patch
It failed to build on arm64 and some other architectures:
https://buildd.debian.org/status/package.php?p=aspectc%2B%2B&suite=sid
Those are architectures with plain char unsigned, I presume.
The error was:
/build/aspectc++-Rtfj1g/aspect
Source: libkmfl
Version: 0.9.8-1
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=libkmfl&suite=sid
You can make it build simply by adding autotools-dev to the Build-Depends.
Source: sipgrep
Version: 2.1.0-1
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=sipgrep&suite=sid
The error was:
tcpreasm.o: In function `tcpreasm_ip_next_tcp':
/«PKGBUILDDIR»/tcpreasm.c:244:(.text+0x200): relocation truncated to fit:
R_AARCH64_LDST32_ABS_LO12_NC a
Source: flashrom
Version: 0.9.7+r1852-1.1
Tags: patch
I have no idea whether this package is useful on arm64, but it's easy
enough to build it with the attached trivial patch.
diff -ru flashrom-0.9.7+r1852.orig/arch.h flashrom-0.9.7+r1852/arch.h
--- flashrom-0.9.7+r1852.orig/arch.h
+++ flashrom-0.
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 @@
The members are printed in an arbitrary order, so the test should
order them before comparing. I think this "patch" does it:
perl -i -wpe 's/$/ \| sort/ if /^tar x/;' tests/T-dir0[01].at
Control: tags -1 patch
Here's a tested patch. Also removes duplicate "en.xml" in dic/Makefile.am.
diff -ru ots-0.5.0.orig/debian/control ots-0.5.0/debian/control
--- ots-0.5.0.orig/debian/control
+++ ots-0.5.0/debian/control
@@ -2,7 +2,7 @@
Section: devel
Priority: optional
Maintainer: Masayuki
Control: tags -1 patch
Here's a tested patch. Note that gtk-doc-tools is required.
diff -ru gtkimageview-1.6.4+dfsg.orig/debian/control gtkimageview-1.6.4+dfsg/debian/control
--- gtkimageview-1.6.4+dfsg.orig/debian/control
+++ gtkimageview-1.6.4+dfsg/debian/control
@@ -2,7 +2,7 @@
Section: libs
Control: tags -1 patch
Here's a patch, tested on arm64, where adding autotools-dev to
Build-Depends seems to be enough; dh-autoreconf is less straightforward.
diff -ru kmflcomp-0.9.8.orig/debian/control kmflcomp-0.9.8/debian/control
--- kmflcomp-0.9.8.orig/debian/control
+++ kmflcomp-0.9.8/debian/
Control: tags -1 patch
This patch might fix all these bugs and require less maintainance
as new architectures are added. Please review and test.
If you're on alpha, ia64, mips or mipsel you could also try without
the extra rule in debian/rules (lines 28-42).
Makedefs.in: SHELL=/bin/bash, require
Here's a recipe for generating fpc-arm64-part1.patch, or something
very like it:
mkdir a b
wget
http://http.debian.net/debian/pool/main/f/fpc/fpc_3.0.0~rc1+dfsg.orig.tar.gz
tar xzf fpc_3.0.0~rc1+dfsg.orig.tar.gz -C a --strip-components=1
svn export http://svn.freepascal.org/svn/fpc/branches/fixes
Source: libc++
Version: 3.7.0-1
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=libc%2B%2B&suite=sid
The error was a segmentation fault in 'Greedy Register Allocator'.
There are similar reports elsewhere, such as bug #796343:
https://bugs.debian.org/cgi-bin/bugreport
To summarise, if you were doing an rc1+dfsg-2 without arm64, this
(untested) might be the diff from rc1+dfsg-1. However, rc2 should be
out tonight, so you might want to wait for that.
--- a/debian/rules
+++ b/debian/rules
@@ -131,9 +131,9 @@
ifeq ($(CPU_TARGET),arm)
DEBIANARCH := $(shell dpkg-
Control: tag -1 patch
The patch fpc-arm64-part2.patch is WRONG! See
http://lists.freepascal.org/pipermail/fpc-devel/2015-October/036024.html
Please replace it with fpc-aarch64-cprt0.patch, which includes a fix
for i386 (see bug #800811).
Here's what I tested:
dpkg-source -x fpc_3.0.0~rc1+dfsg-1
On armhf the solution may be to disable optimisations on the first
build, when running 2.6.4. See
http://lists.freepascal.org/pipermail/fpc-devel/2015-October/036017.html
http://lists.freepascal.org/pipermail/fpc-pascal/2015-June/044565.html
and the rest of those threads.
Source: fpc
Version: 3.0.0~rc1+dfsg-1
Tags: patch
The new upload to experimental hasn't fared too well on the buildds:
https://buildd.debian.org/status/package.php?p=fpc&suite=experimental
I was able to make it build on i386 with this patch, though I wouldn't
be surprised if there's a better, mo
In Jan 2006 it was stated (see above):
> Scsh is based on (and includes a copy of) Scheme48. Here's what
> for...@debian.org said about Scheme48:
>
> Scheme48 is using a virtual machine and bit field type tags, and
> sadly, the assumptions on 32 bit are deeply ingrained into the
> whole system.
A
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
Source: rakudo
Version: 2014.07-4
It appears that nqp can be made to work on arm64:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800551
Perhaps the same is true for rakudo.
Source: parafly
Version: 0.0.2013.01.21-2
Currently debian/control has:
Architecture: amd64 ppc64el s390x
Perhaps the other 64-bit official architecture should be added:
Architecture: amd64 arm64 ppc64el s390x
It seems to build on arm64.
Source: pyopencl
Version: 2015.1-2
Is there a reason for this package being on amd64 and i386 only?
It seems to build on arm64.
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: nqp
Version: 2014.07-3
For arm64 it seems to be more a matter of updating the bundled copy of
dyncall than the nqp package itself:
dpkg-source -x nqp_2014.07-3.dsc
cd nqp-2014.07/3rdparty/
rm -r dyncall/
hg clone http://hg.dyncall.org/pub/dyncall/dyncall
cd ..
perl -i -pe 's/armel/arm64 a
Source: bowtie
Version: 1.1.2-1
Tags: patch
It seems to build on arm64 with just a tiny change on top of
ppc64el.patch:
--- bowtie-1.1.2.orig/Makefile
+++ bowtie-1.1.2/Makefile
@@ -125,7 +125,7 @@
VERSION = $(shell cat VERSION)
BITS=32
-ifneq (,$(filter $(shell uname -m), ppc64le x86_64))
+if
Source: guymager
Version: 0.7.4-2
It seems to build on arm64. Perhaps it should be "Architecture: any".
Source: libextractor-java
Version: 0.6.0-6
It seems to build on arm64. Perhaps it should be "Architecture: any".
> (I need to drop ones that the previous maintainer added but the package
> is non-functional on.)
Do you have any information on what failed on which architectures?
If a C/C++ program works on i386 and amd64, and builds but doesn't
work on ARM architectures, then it probably assumes somewhere th
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).
I think I've resolved a couple of the issues:
* Not building with gccgo:
I thought I was joking when I wrote that I sometimes forget to mount
/proc. Well, it turns out that the build system runs "go env GOROOT",
and that command fails obscurely if /proc is not mounted:
$ go env GOROOT
fatal erro
Tianon:
> Hmm, were you using sbuild? I haven't yet figured out how the best
> way to handle what sbuild calls "alternatives" here yet -- it has a
> flag to attempt them (--resolve-alternatives), but it's disabled by
> default (and thus most of the buildds have it disabled too). The
> dependency
Control: tags -1 patch
Here's a patch that's tested on amd64 and i386. This was found in the log in
both cases:
116 tests, 448 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0
notifications
100% passed
It would be nice if someone could test it on some other architectures,
but perha
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
Control: found -1 1.5.1-1~exp1
I tried golang_1.5.1-1~exp1 over the weekend.
Firstly, I wasn't able to bootstrap it with gccgo-5, so I'm not sure
that the "golang-go (>= 2:1.4.2-2~) | gccgo-5" in debian/control is
correct.
With golang installed, it built but there were some test failures,
though
peter green :
> From the ppc64 build log (s390x was much the same).
Thank you for taking the trouble to look at the build logs; I just saw
that it was "Installed" and naively assumed it had worked!
Perhaps then the architectures for which "INTEGER" is "long" (or
whatever) really are exactly thos
Source: libf2c2
Version: 20090411-2
This package is very old. Is anyone still using it? Does it get tested
in any way?
The file
https://sources.debian.net/src/libf2c2/20090411-2/f2c.h0/
contains (repeatedly) the line:
#if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) ||
defi
> There are lots of warnings like this:
> > sspsv.c:67:5: warning: format '%d' expects argument of type 'int', but
> > argument 3 has type 'integer'
>
> Which I'm guessing cause the buffer overflow when the tests are run:
I don't think those warnings cause the crash, though that should be
fixed,
Source: crrcsim
Version: 0.9.12-6.1
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=crrcsim&suite=sid
The error was:
.../src/mod_inputdev/inputdev_parallel/inputdev_parallel.cpp:41:25: fatal
error: asm/io.h: No such file or directory
To fix it, all you have to do i
As far as I know, the best portable equivalent of Intel rdtsc is:
#include
clock_gettime(CLOCK_MONOTONIC, &ts)
It might not be quite as good as some architecture-specific methods,
but there are some clever mechanisms in place on Linux to make it work
accurately without a system call, so it's not
Source: libfont-freetype-perl
Version: 0.06-1
It's failing to build on architectures with plain char unsigned:
https://buildd.debian.org/status/package.php?p=libfont-freetype-perl&suite=sid
A couple of tests are failing:
not ok 601 - no fallback glyph
not ok 603 - missing glyph has horizontal a
http://luajit.org/ now says:
"2015-08-25
LuaJIT 2.1.0-beta1 has been released ...
The final release will follow soon"
This version adds support for arm64, with the interpreter (LJ_GC64 mode).
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
> Sorry guys:
>
> ifeq (armel, $(DEB_HOST_ARCH))
> CC = gcc -march=armv6
> CXX = g++ -march=armv6
> export CC
> export CXX
> endif
>
> That's actually not going to work for "armel" hardware... "armel" is
> currently built as "armv4t", so "-march=armv6" is going to cause
> invalid instruction fau
I was able to build it on armel with the attached patch. I only tested
in a chroot under QEMU, so perhaps it won't work on real hardware.
However, if you could include this patch, or something like it, with
the next upload I'd be interested to see what happens.
diff -ru nodejs-4.0.0~dfsg.orig/confi
Source: nagios-plugins-contrib
Version: 15.20150818
Tags: patch
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=nagios-plugins-contrib&suite=sid
Just remove "!arm64" from debian/control.
--- nagios-plugins-contrib-15.20150818.orig/debian/control
+++ nagios-plugins-con
Apparently there's now a Node.js v4.0.0 that contains V8 v4.5
(4.5.103.30):
https://nodejs.org/en/blog/release/v4.0.0/
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
Source: softhsm2
Version: 2.0.0-2
Tags: patch
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=softhsm2&suite=sid
You can fix it with the attached patch, though you might want to
investigate whether and why it is necessary for debian/rules to add
"CONFIGURE_FLAGS = --e
Control: tags -1 patch
I think you can fix this with the attached patch.
diff -ru liblunar-2.0.1.orig/debian/control liblunar-2.0.1/debian/control
--- liblunar-2.0.1.orig/debian/control
+++ liblunar-2.0.1/debian/control
@@ -3,7 +3,7 @@
Maintainer: LI Daobing
Build-Depends: debhelper (>= 7), gtk
I think the package nvidia-settings should probably be built for all
architectures, even if there's no prospect of a working driver.
See this:
https://buildd.debian.org/status/package.php?p=mate-sensors-applet&suite=sid
It's failing to build on most architectures because nvidia-settings is
not a
Control: tags -1 patch
It wasn't built on arm64:
https://buildd.debian.org/status/package.php?p=h323plus&suite=sid
https://wiki.debian.org/Autoreconf says: "So this means that using
dh-autoreconf on packages which only use autoconf (but not automake)
(even with debhelper or CDBS) is not enough t
> I'd be happy with a binNMU here. Do I need to ask the RMs for one myself?
I'm not sure. Wookey's done the binNMU for arm64 so you don't need to
worry about that. The other, sh4, is an "unofficial port" so it might
be treated differently somehow. I'm copying s...@buildd.debian.org in
case that re
Source: sarg
Version: 2.3.10-1
Tags: patch
It failed to build on arm64:
https://buildd.debian.org/status/package.php?p=sarg&suite=sid
The attached patch should help. I think it's what bugs #727959 and
#744505 were asking for, really.
See https://wiki.debian.org/Autoreconf for background.
diff -
Source: cl-sql
Version: 6.6.3-1
It failed to build on most architectures:
https://buildd.debian.org/status/package.php?p=cl-sql&suite=sid
Line 74 of db-mysql/Makefile is adding "-m32" to anything that isn't
amd64, I think, while only a few architectures accept that option.
(Interestingly, ppc64e
To reproduce the problem:
wget
https://sources.debian.net/data/main/s/synfigstudio/1.0-1/images/animate_mode_icons.sif
synfig -q animate_mode_icons.sif -o animate_mode_off_iconxx.png --time 0
Replacing /usr/lib/aarch64-linux-gnu/libsigc-2.0.so.0.0.0 with file
from rebuilt libsigc++-2.0 fixes it.
> Could you outline why you believe a binNMU would fix the issue please?
On arm64, libsigc++-2.0_2.4.1-2 (and thus libsigc++-2.0-0v5) was built
with g++-4.9, although it was built on Aug 6, after build-essential_12
was installed. This happened because arm-arm-03 failed to regenerate
its chroot on
Control: severity -1 important
synfigstudio is failing to build because of this:
https://buildd.debian.org/status/fetch.php?pkg=synfigstudio&arch=arm64&ver=1.0-1%2Bb2&stamp=1441235058
The "synfig" command gives:
*** Error in `synfig': munmap_chunk(): invalid pointer: 0x14e27940 ***
Package: libmovit2v5
Version: 1.1.3-3
Severity: important
https://packages.debian.org/sid/libmovit2v5 says:
dep: libstdc++6 (>= 4.9) [arm64, sh4]
GNU Standard C++ Library v3
dep: libstdc++6 (>= 5.2) [not arm64, hurd-i386, sh4]
On arm64 this happened because arm-arm-03 failed to regenerate i
Package: libctemplate2v5
Version: 2.2-5
Severity: important
https://packages.debian.org/sid/libctemplate2v5 says:
dep: libstdc++6 (>= 4.9) [arm64, sh4, sparc64]
GNU Standard C++ Library v3
dep: libstdc++6 (>= 5.2) [not arm64, hurd-i386, sh4, sparc64]
On arm64 this happened because arm-arm-0
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
The underlying issue seems to have been fixed on binutils trunk. I've
put in a wishlist bug requesting that the fix be added to Debian's
binutils:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797666
Source: mathgl
Version: 2.3.3-1
Tags: patch
It's failing on architectures with unsigned plain char:
https://buildd.debian.org/status/package.php?p=mathgl&suite=sid
diff -ru mathgl-2.3.3.orig/utils/make_bin.cpp mathgl-2.3.3/utils/make_bin.cpp
--- mathgl-2.3.3.orig/utils/make_bin.cpp
+++ mathgl-2.3
Here's a better patch. It might be even better to get rid of
CompatPrim.hs altogether and not have any functions with
architecture-specific behaviour.
(I hope nobody will tell me that GHC is incapable of generating
good code without the help of the C preprocessor.)
diff --git a/Crypto/Internal/Com
Source: haskell-cryptonite
Version: 0.5-1
Tags: patch
This package fails to build on non-Intel architectures:
https://buildd.debian.org/status/package.php?p=haskell-cryptonite&suite=sid
I found I could build it on arm64 with this patch:
--- haskell-cryptonite-0.5/cryptonite.cabal.orig
+++ haske
Source: kodi
Version: 15.1+dfsg1-2
Tags: patch
Thanks for sorting out the configuration on unknown architectures.
Here's a patch for arm64. You should probably reverse some of the
tests: test for Intel instead of listing all the non-Intel
architectures we can think of. But this patch did get it t
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
A library transition is probably not needed, according to:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791173
I think that means a binNMU on all architectures is needed instead:
http
Ubuntu's stuff for 1.5~rc1 seems to work for 1.5 on Debian unstable if
you just remove the two patches (which are for armhf and ppc64el with
the latter already included in 1.5):
tar xzf .../go1.5.src.tar.gz
cd go/
tar xJf .../golang_1.5~rc1-0ubuntu1.debian.tar.xz
rm debian/patches/series
dpkg-buil
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
I think gtkspellmm needs a binNMU on arm64.
https://buildd.debian.org/status/package.php?p=gimagereader&suite=sid says:
Dependency installability problem for gimagereader on arm64:
gimagereader build-depen
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
I think libgnomecanvasmm2.6 needs a binNMU on arm64.
https://buildd.debian.org/status/package.php?p=ardour3&suite=sid says:
Dependency installability problem for ardour3 on arm64:
ardour3 build-depends on:
There's also bug #795358, which mentions some other packages.
> 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
Some more for the list:
bear
cython
fltk1.3
paprefs
pykcs11
qtscript-opensource-src
r-cran-fastcluster
varconf
vocproc
I got these additions by looking for anything built after Aug 2 with
"build-essential_11" mentioned in the log and also 'g\+\+.*\.so'. I
think that's a better test than what I di
Package: release.debian.org
Usertags: binnmu
These 12 packages appear to have been built recently (Aug 6-9) for
arm64 by arm-arm-03 using an out-of-date version of build-essential,
and therefore with g++-4.9 instead of g++-5, and they also seem to
involve a C++ library ("libtool: link: g++"). You
Source: libsigc++-2.0
Version: 2.4.1-2
Looking at the build logs at
https://buildd.debian.org/status/package.php?p=libsigc%2B%2B-2.0&suite=sid
I note that on arm64 this package was built with build-essential_11.7
and g++-4.9, unlike on the other architectures, which used g++-5. Is
this deliberate,
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
> > The patch simulavr_0.1.2.2-6.2ubuntu1.debdiff applies cleanly to
> > simulavr 0.1.2.2-7, is still required, and still works.
>
> What confuses me is that the bug report proposes to "run
> dh-autoreconf to update config.{sub,guess} and {libtool,aclocal}.m4"
> but the patch only adds dh-autotool
Tags: patch
Control: found -1 0.1.2.2-7
The patch simulavr_0.1.2.2-6.2ubuntu1.debdiff applies cleanly to
simulavr 0.1.2.2-7, 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...@lis
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
Is this bug now fixed?
1.18-2.1 failed "make -j6 check" on arm64 recently in a way that isn't
easy to reproduce. If there is a race condition in the tests, perhaps
"make check" should be run without parallelisation. Or just disable
parallelisation throughout.
--
To UNSUBSCRIBE, email to debian-
101 - 200 of 361 matches
Mail list logo
