Bug#889147: abyss: PairedDBG_LoadAlgorithm test fails on sparc64 due to strict alignment violation

Package: abyss Severity: normal Tags: patch upstream Usertags: sparc64 Dear Maintainer, This package currently FTBFS on sparc64 due to the PairedDBG_LoadAlgorithm test failing with a SIGBUS. The Kmer.load and Kmer.storeReverse methods in the Common/Kmer.cpp file cast a uint8_t* to a size_t*

Bug#835973: openjdk-8: please enable hotspot for sparc64

Source: openjdk-8 Severity: wishlist Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 Dear Maintainer,

Bug#714923: opencv FTBFS on sparc64

Source: opencv Followup-For: Bug #714923 User: debian-sp...@lists.debian.org Usertags: sparc64 The _Atomic_word problem was reintroduced in two places and it's breaking the sparc64 build again. You can see the problem in this build log:

Bug#806992: ffcall: New upstream release 1.12, fixes sparc64 and ppc64el

Package: ffcall Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 There's a new upstream release of this package that includes newer sparc64 asm files that have a different syntax that modern gcc accepts. It also claims to fix the ppc64el build but I don't have the ability to

Bug#806816: webkit2gtk: FTBFS on sparc64

Alberto Garcia writes: > Thanks! Did you check if the browser works fine? You can use the > shipped MiniBrowser binary for that. > > Berto Hi Berto Thanks for the reply. Unfortunately the MiniBrowser fails with a Bus Error. The problem doesn't appear to be with webkit though.

Bug#806837: qtwebkit: FTBFS on sparc64

Source: qtwebkit Severity: normal Tags: patch User: debian-sp...@lists.debian.org Usertags: sparc64 Dear Maintainer, qtwebkit currently fails to build for sparc64. I was able to fix the build by adding sparc64 to the list of non-JIT archs in debian/rules, fixing a declaration of UChar32, and

Bug#806816: webkit2gtk: FTBFS on sparc64

Source: webkit2gtk Severity: normal Tags: upstream patch User: debian-sp...@lists.debian.org Usertags: sparc64 The webkit2gtk build currently fails on sparc64. You can see an example build failure log here:

Bug#806667: emacs24: FTBFS on sparc64, Bus Error during lucid build

Source: emacs24 Severity: normal Tags: upstream patch User: debian-sp...@lists.debian.org Usertags: sparc64 Dear Maintainer, The emacs24 build is currently failing on sparc64 with a Bus Error. You can see an example build log here:

Bug#805904: emacs24: FTBFS anywhere after 24.5+1-4

Source: emacs24 Version: 24.5+1-4 Severity: serious Justification: 4 With version 24.5+1-4 emacs24 fails to build on all archs because of a missing file. For example, you can find the build log for i386 here: https://buildd.debian.org/status/fetch.php?pkg=emacs24=i386=24.5%2B1-4=1446934624 And

Bug#805884: ion: FTBFS on sparc64, tv_usec wrong type in printf

Source: ion Severity: important Tags: upstream patch User: debian-sp...@lists.debian.org Usertags: sparc64 Dear Maintainer, The ion package currently fails to build on sparc64. The build log can be seen here: https://buildd.debian.org/status/fetch.php?pkg=ion=sparc64=3.2.1%2Bdfsg-1=1448045105

Bug#805846: openjdk-7: FTBFS on sparc64, missing asm/ptrace header, patch attached

Source: openjdk-7 Severity: important Tags: patch Justification: fails to build from source User: debian-sp...@lists.debian.org Usertags: sparc64 Dear Maintainer, Currently openjdk-7 is configured to use the zero vm on sparc64. However zero doesn't seem to build. If hotspot is enabled for

Bug#805211: libffado: FTBFS: error: function ‘int* __errno_location()’ is initialized like a variable

Source: libffado Followup-For: Bug #805211 Dear Maintainer, In several of the tests in this package 'errno' is declared as an int. However, errno is provided by the c runtime and may be a macro so declaring it again as an int is an error. This is breaking the build on, at least, sparc64.

Bug#805072: protobuf: FTBFS on sparc64 - apparently tries to build x86 code

Source: protobuf Followup-For: Bug #805072 Dear Maintainer, The x86 sources are actually included on every platform. If you look at the build logs for powerpc for example you can see them being included. The contents are just preprocessed out everywhere except on intel. The build is failing

Bug#789180: linux: Register corruption bug on sparc, please enable SLUB as workaround

Source: linux Severity: important Tags: upstream Dear Maintainer, The kernel has a register corruption bug on sparc that is causing corruption and failed builds. Enabling SLUB instead of SLAB in the kernel is an effective workaround. James Y Knight observed it here

Bug#688246: qgis fails to build on powerpc due to internal spatialite

Package: qgis Version: 1.7.4+1.7.5~20120320-1.1 Severity: important Tags: Dear Maintainer, qgis currently fails to build on powerpc. The problem seems to be the src/core/spatialite/spatialite.c file which somehow makes gcc emit code that the assembler rejects. I have two powerpc systems that

Bug#578588: spu-tools: spu-top segfaults when /spu directory doesn't exist

Package: spu-tools Version: 2.3.0.136-1 Severity: normal Tags: patch upstream The spu-top program will segfault if the system doesn't have a /spu directory. Also if the directory is removed while spu-top is running it will segfault. A simple fix is attached that just checks if the call to read

Bug#503255: sbcl: Error using null pointer in ffi

, David Matthew Mattli wrote: Package: sbcl Version: 1:1.0.18.0-1 Severity: important Whenever uses sbcl uses a null pointer in a cffi call it gives the following error: #.(SB-SYS:INT-SAP #X) fell through ETYPECASE expression. Wanted one of (CHARACTER SYMBOL INTEGER

Bug#503255: sbcl: Error using null pointer in ffi

Package: sbcl Version: 1:1.0.18.0-1 Severity: important Whenever uses sbcl uses a null pointer in a cffi call it gives the following error: #.(SB-SYS:INT-SAP #X) fell through ETYPECASE expression. Wanted one of (CHARACTER SYMBOL INTEGER). This problem was not present in sbcl-1.0.17