Bug#887967: closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)

On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk wrote: This problem is unfortunately still present with fpc 3.0.4+dfsg-14: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html This can be worked around by the following change in debian/rules:

Bug#890748: [Debian-med-packaging] Bug#890748: python-pysam: autopkgtest failures in pbsuite, python-pbcore

On 18 February 2018 at 19:05, Andreas Tille wrote: > and see that there are files fitting the libchtslib.*so pattern. > I have no idea how dynamic linking in this case works - do you > think some additional symlinks > > ln -s libchtslib.x86_64-linux-gnu.so >

Bug#890748: python-pysam: autopkgtest failures in pbsuite, python-pbcore

Source: python-pysam Version: 0.14+ds-1 Severity: serious User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu bionic autopkgtest Affects: pbsuite python-pbcore Hi Maintainer Since the upload of python-pysam 0.14+ds-1, autopkgtests of pbsuite [1] and python-pbcore [2] have been failing

Bug#890704: [Debian-med-packaging] Bug#890704: bcftools FTBFS on 32bit: test_vcf_query failure

This is a new test that was added in 1.7, so it is not a regression. One option is to simply skip it for now. --- a/test/test.pl +++ b/test/test.pl @@ -132,7 +132,7 @@ test_vcf_query($opts,in=>'query.filter.3',out=>'query.51.out',args=>q[-f'[\\t%GT\\n]\\n' -i'GT~"1" && GT~"2"']);

Bug#890405: maffilter: undefined symbol

Hi Maintainer maffilter is affected by the same dropped symbol as in #890400: $ maffilter maffilter:symbol lookup error: maffilter: undefined symbol:

Bug#890400: physamp: autopkgtest failure

Source: physamp Version: 1.0.3-1 Severity: serious User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu bionic autopkgtest Hi Maintainer Since the upload of libbpp-core 2.3.2-1, physamp's autopkgtests have been failing [1] with the following error: autopkgtest [03:46:54]: test

Bug#888412: sphinx-gallery: FTBFS without network access

Source: sphinx-gallery Version: 0.1.13-1 Severity: serious Hi Maintainer sphinx-gallery FTBFS without network access, as can be seen in the following build log excerpt from reproducible builds [1]: Unexpected failing examples:

Bug#873468: CUDA 9.0 transition

On 10/01/2018 06:19, Andreas Beckmann wrote: CUDA 9.0 finally reached experimental. Did someone get around testing it, yet? I sync'd it into Ubuntu as soon as it cleared NEW, and have been testing since then. As usual, the Ubuntu drivers require modification [1], so I built them locally for

Bug#883987: rheolef: FTBFS error: partial specialization ... after instantiation ...

On 12 December 2017 at 21:58, Pierre Saramito wrote: >> I think the thing to do here is reassign this bug to src:boost1.62 and >> mark that it affects src:rheolef. > > Do you known how to do that with the Debian bug system ? You can send mail to cont...@bugs.debian.org

Bug#883987: rheolef: FTBFS error: partial specialization ... after instantiation ...

Hi Pierre (cc-ing Andreas in case he is not subscribed) On 12 December 2017 at 15:13, Pierre Saramito wrote: > Hi Andreas, > > This problem do neither comes from Rheolef-6.7 nor from CGAL-4.11: > it comes from Boost-1.62 combined with g++ 7.2 in Debian sid and testing.

Bug#873408: [Pkg-julia-devel] Bug#873408: julia: Please update to llvm-toolchain 4.0 or, better, 5.0

On 20 November 2017 at 20:54, Emilio Pozuelo Monfort wrote: > It should be fine now with 4.0. Would be good if this could move to either > unversioned llvm/clang (which defaults to 4.0 now) or to versioned 4.0. > Bumping > to serious as we want to remove 3.8 soon to reduce the

Bug#881149: htslib FTBFS: test failures on i386

Control: tags -1 + patch I found the documentation of the optimization flags for GCC 7.2.0 [1]. I was then able to bisect the list of flags enabled for -O2 and determine which ones needed to be disabled in order to build htslib on i386. Patch follows. --- a/debian/rules +++ b/debian/rules @@

Bug#881149: htslib FTBFS: test failures on i386

Another FWIW, building on i386 with -O1 instead of -O2 and dropping -fno-strict-aliasing is successful. Where can one find the differences between -O1 and -O2 in GCC 7? What changed between GCC 6 and 7 would be useful too. --- a/debian/rules +++ b/debian/rules @@ -7,7 +7,10 @@ include

Bug#881149: htslib FTBFS: test failures on i386

So it turns out this is a re-hash of #865012. See upstream issue reported by Sascha: https://github.com/samtools/htslib/issues/565 Also proposed patch (which was not accepted by upstream): https://github.com/samtools/htslib/pull/571 FWIW, the proposed patch "works for me" on amd64 and i386.

Bug#881149: htslib FTBFS: test failures on i386

On 8 November 2017 at 20:21, Adrian Bunk wrote: > Assuming your CPU and kernel support 64bit, this is working. TIL, thanks!

Bug#881149: htslib FTBFS: test failures on i386

On 8 November 2017 at 19:57, Adrian Bunk wrote: > All combinations are possible, for example: ... > bash: /usr/bin/hello: cannot execute binary file: Exec format error OK, but you can't actually execute amd64 binaries on i386, right? So I don't understand how being able to

Bug#881149: htslib FTBFS: test failures on i386

On 8 November 2017 at 17:10, Adrian Bunk wrote: > The relevant change is gcc 6 -> 7. Thanks. I've just checked, and the last successful i386 build in Ubuntu was on 2017-08-04 against gcc 6. > With multiarch allowing installation of amd64 packages even on an i386 >

Bug#881149: htslib FTBFS: test failures on i386

Better link: https://tests.reproducible-builds.org/debian/history/i386/htslib.html

Bug#881149: htslib FTBFS: test failures on i386

Package: htslib Version: 1.5-1 Severity: serious Tags: buster sid As per logs from reproducible builds [1], htslib 1.5-1 recently (around 2017-09-25) started to FTBFS on i386 with the following test failures: test_vcf_api: /build/1st/htslib-1.5/test/test-vcf-api /tmp/o6gEIzeYrS/test-vcf-api.bcf

Bug#877670: [Debian-med-packaging] Bug#877670: Bug#877670: bcftools FTBFS on armel armhf and ppc64el

://bugs.debian.org/877670 Forwarded: https://github.com/samtools/htslib/pull/617 Author: Graham Inggs <gin...@debian.org> Last-Update: 2017-11-08 --- a/errmod.c +++ b/errmod.c @@ -82,10 +82,11 @@ double le1 = log(1.0 - e); for (n = 1; n <= 255; ++n) { double *beta =

Bug#877670: [Debian-med-packaging] Bug#877670: Bug#877670: bcftools FTBFS on armel armhf and ppc64el

FWIW, I tried building htslib 1.6 and bcftools 1.6, but the issue is still present. I also tried building htslib 1.5 and becftools 1.5 with -fsigned-char but that didn't help either. Looking closer at test/test.pl, I noticed the failing test is new, so this is not a regression. Simply dropping

Bug#877670: [Debian-med-packaging] Bug#877670: bcftools FTBFS on armel armhf and ppc64el

On 14 October 2017 at 03:12, peter green wrote: > Here is the diff I got on my armhf system. > > --- test/mpileup/indel-AD.1.out 2017-06-20 11:49:44.0 + > +++ test/mpileup/indel-AD.1.out.new 2017-10-14 01:06:23.687285852 + > @@ -154,7 +154,7 @@ > 00F

Bug#876934: openorienteering-mapper FTBFS: test failures

Control: tags -1 + unreproducible sid Control: severity -1 normal I've just tried sbuild in an amd64 sid schroot and openorienteering-mapper builds fine for me. I noticed it also still builds in testing on the reproducible-builds buildds. Why don't co-maintainers (uploaders) receive bug

Bug#868958: [Debian-med-packaging] Bug#868958: bcftools FTBFS on 32bit: test failures

On 3 October 2017 at 13:52, peter green wrote: > Unfortunately while 1.4-3 built successfully on armel, armhf and mipsel > 1.5-1 did not. I think some patches were missed from the update_1.4.1 branch.

Bug#876509: deal.ii FTBFS with lapack

Control: reassign -1 src:trilinos 12.10.1-4 Control: affects -1 src:deal.ii Control: block -1 by 876958 Hi Anton On 23 September 2017 at 01:23, Anton Gladky wrote: > deal.ii FTBFS in the sid. Probably due to the new upload of lapack. Yes indeed, thanks for picking this up.

Bug#876416: libzstd FTBFS on mips(el): Allocation error : not enough memory

Source: libzstd Version: 1.3.1+dfsg-1 Severity: serious Hi Maintainer Builds of libzstd/1.3.1+dfsg-1 FTBFS on mips and mipsel where they were successful in the past. /*stdin*\: 5.90% (9900 => 5842431 bytes, /*stdout*\) roundTripTest: ./datagen -g60 -P99 |

Bug#868786: shogun FTBFS on arm64 with libeigen3-dev 3.3.4-2

Control: reassign -1 src:eigen3 3.3.4-1 Control: affects -1 src:shogun Control tags -1 + fixed-upstream patch Hi Anton This turned out to be fixed in Eigen upstream (patch attached). Let me know if I should go ahead with a team upload. Regards Graham Description: Fix compilation of Jacobi

Bug#868922: r-cran-randomfieldsutils: FTBFS: init_RandomFieldsUtils.cc:62:10: error: 'R_NativeArgStyle' does not name a type

Control: tags -1 - buster r-cran-randomfieldsutils 0.3.15-1 builds fine in testing

Bug#871333: r-bioc-rtracklayer: FTBFS: Error: package or namespace load failed for 'rtracklayer' in dyn.load(file, DLLpath = DLLpath, ...):

Control: tags -1 - buster r-bioc-rtracklayer 1.34.1-1 builds fine in testing

Bug#873800: node-babylon FTBFS without network access

Source: node-babylon Version: 6.14.1-1 Severity: serious Hi Maintainer Node-babylon has a build dependency on nodejs-legacy which is no longer in the archive. With this dependency removed, the build fails on a machine without external network access: ... HOME=/tmp npm install babel-cli

Bug#873801: node-babel FTBFS without network access

Source: node-babel Version: 6.25.0+dfsg-1 Severity: serious Hi Maintainer Node-babel fails to build on a machine without external network access: ... npm install npm ERR! Linux 4.4.0-92-generic npm ERR! argv "/usr/bin/node" "/usr/bin/npm" "install" npm ERR! node v6.11.2 npm ERR! npm v3.5.2

Bug#873713: node-foreground-child FTBFS: test failures

Source: node-foreground-child Version: 1.5.6-1 Severity: serious Hi Maintainer Node-foreground-child FTBFS in unstable: https://tests.reproducible-builds.org/debian/history/node-foreground-child.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-foreground-child.html

Bug#871820: openorienteering-mapper FTBFS: Test map_t Failed

Control: tags -1 + fixed-upstream Control: tags -1 + fixed-in-experimental Control: fixed -1 openorienteering-mapper/0.6.8-1 OpenOrienteering Mapper 0.6.8-1 in experimental builds fine with GCC 7.

Bug#869589: libunwind: needs maintainer

On 25 July 2017 at 16:44, Al Stone wrote: > Woof. I had not realized I was the only one left. Please orphan the > package -- I really do not have time to maintain it and it's important > enough it really needs someone who can pay attention to it. Thanks for your prompt

Bug#869589: libunwind: needs maintainer

Source: libunwind Version: 1.1-4.1 Severity: serious X-Debbugs-CC: a...@debian.org Hi Al As per #863770 and #868643, Matthieu Delahaye and Daigo Moriwaki are no longer maintaining libunwind. Al Stone, you are our only hope! You are the last listed uploader for this package. If you intend

Bug#868958: [Debian-med-packaging] Bug#868958: Bug#868958: bcftools FTBFS on 32bit: test failures

On 21/07/2017 13:34, Graham Inggs wrote: The two test_vcf_norm failures are caused by the following differing output on 32-bit architectures: The tests were modified here: https://github.com/samtools/bcftools/commit/e43ca8c70bbc78a4ef29be723c60a2ec7a029436 The difference was introduced here

Bug#868958: [Debian-med-packaging] Bug#868958: bcftools FTBFS on 32bit: test failures

On 19/07/2017 23:12, Adrian Bunk wrote: test_vcf_query: /<>/bcftools view -Ob /tmp/f0hqBlggDJ/view.filter.vcf.gz | /<>/bcftools query -f'%POS %CIGAR\n' -i'strlen(CIGAR[*])=4' *** Error in `/<>/bcftools': free(): invalid next size (fast): 0x80abd7a0 *** /bin/bash: line 1: 11930 Done

Bug#869126: augustus: explicit dependency on libhts1, blocks transition

Source: augustus Version: 3.2.3+dfsg-1 Severity: serious Hi Maintainer Package augustus has an explicit dependency on libhts1, so even though it was uploaded after libhts2, it still blocks the htslib transition [1]. I would suggest testing whether you can simply drop the explicit dependencies

Bug#868288: doublecmd: FTBFS due to use of obsoleted Lazarus functions

Control: tags -1 fixed-upstream On 14/07/2017 10:35, Paul Gevers wrote: You are already aware, but to show the world: doublecmd in unstable FTBFS due to the use of obsoleted Lazarus functions. I've just tested building an SVN snapshot of 0.8.0 alpha. The gtk2 and qt5 versions built fine

Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

Uploaded, please downgrade the severity of this bug once the builds are successful.

Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

On 16 July 2017 at 20:40, Nico Schlömer wrote: > I've disabled the phalanx tests in master, and also fixed two other things. > Perhaps it's time for an upload? Doing a test build now, will upload if successful.

Bug#868523: FTBFS: test failed 617 ML_MLP_NonSym_MPI_4, 668 Phalanx_dag_manager_MPI_1

On 16 July 2017 at 13:12, Drew Parsons wrote: > Testing trilinos build on a porterbox for the mumps 5.1.1 transition. > > The following tests FAILED: > 617 - ML_MLP_NonSym_MPI_4 (Failed) > 668 - Phalanx_dag_manager_MPI_1 (Failed) > > Not sure if it's the new mumps,

Bug#864443: pytables: ftbfs on armhf

This package subsequently built in Ubuntu and I have just confirmed that it now builds on harris.d.o. There is already a binNMU pending for armhf, so if that is successful, this bug may be closed.

Bug#867057: [Debichem-devel] Bug#867057: Bug#867057: avogadro: Avogadro refuses to start due to missing dependency

tags -1 + moreinfo severity -1 normal I've just tested in a clean Stretch installation and did not see the issue. Please paste the output of: apt-cache policy libavogadro1 python-avogadro Sorry Jonathan for the duplicate email.

Bug#867057: [Debichem-devel] Bug#867057: avogadro: Avogadro refuses to start due to missing dependency

On 3 July 2017 at 20:27, Jonathan Sutton wrote: > The application never starts. It appears that the current packaged version > of avogadro relies on libboost_python-py27.so.1.55.0, but the current > version of this library is libboost_python-py27.so.1.62.0. The package >

Bug#864439: [Debian-med-packaging] Bug#864448: bowtie FTBFS on mips64el: /usr/bin/ld: .gnu.hash is incompatible with the MIPS ABI

I'm re-posting this to bug visible from the BTS. On 09/06/2017 10:13, Dejan Latinovic wrote: There were the patch for this issue in earlier bowtie version: https://sources.debian.net/src/bowtie/1.1.2-6/debian/patches/no_hash_style_both_for_mips.patch/ This patch prevents using hash style both

Bug#863929: falcon: FTBFS: Test failures ("Task Node(0-rawreads/job_0001) failed with exit-code=256")

According to the reproducible build history [1], this package has FTBFS on i386 for a long time. It also never successfully built on i386 in Ubuntu [2]. If there are no objections, I will file a bug requesting removal of the i386 binary package. [1]

Bug#863686: freemat: fails to start with llvm error

On 30/05/2017 06:45, Stuart Prescott wrote: Starting a fresh installation of freemat fails: $ freemat : CommandLine Error: Option 'x86-machine-combiner' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options I see the same here. A no-change rebuild with

Bug#862360: llvm-toolchain-3.8: Fix R_AARCH64_MOVW_UABS_G3 relocation

On 12 May 2017 at 22:11, Sylvestre Ledru wrote: > This should be probably reported as a separate bug! You could clone this bug, or retitle as 'arm64 48-bit VMA issues with recent kernels' :)

Bug#862360: llvm-toolchain-3.8: Fix R_AARCH64_MOVW_UABS_G3 relocation

Confirming that the second patch does fix hanging during the sanitizer_common tests on arm64.

Bug#862360: llvm-toolchain-3.8: Fix R_AARCH64_MOVW_UABS_G3 relocation

On 12/05/2017 14:59, Edmund Grimley Evans wrote: You don't have this patch, I think: https://reviews.llvm.org/D22095 Thanks, you are correct, we don't have this patch. Testing now...

Bug#861484: llvm-toolchain-3.8: Fix R_AARCH64_MOVW_UABS_G3 relocation

The one line fix on its own: -*TargetPtr |= Result >> (48 - 5); +*TargetPtr |= (Result & 0xULL) >> (48 - 5); ...allows julia from the archive to run on my Raspberry Pi 3. Building julia now also succeeds. On 11/05/2017 20:42, Edmund Grimley Evans wrote: There is

Bug#861484: [Pkg-julia-devel] Bug#861484: Bug#861484: Bug#861484: Bug#861484: julia: FTBFS on arm64

Julia builds successfully on a Raspberry Pi 3 running an image prepared by xylnao, dated 2016-04-14 [1] with kernel 4.5.0. It fails in the same way as on arm-arm-04 and arm-conova-01 on a Raspberry Pi 3 running an image prepared by Michael Stapelberg, dated 2017-03-22 [2] with kernel 4.9.18-1.

Bug#861484: [Pkg-julia-devel] Bug#861484: Bug#861484: Bug#861484: julia: FTBFS on arm64

On 7 May 2017 at 10:26, Graham Inggs <gin...@debian.org> wrote: > Always succeeds on: > Linux 3.16.0-4-arm64 armhf (aarch64) I just noticed this line has armhf and I thought that was a bit odd. It seems arm-linaro-01 and arm-linaro-03 have machine architecture: armhf and ho

Bug#861484: [Pkg-julia-devel] Bug#861484: Bug#861484: julia: FTBFS on arm64

On 2 May 2017 at 13:10, Graham Inggs <gin...@debian.org> wrote: > I've been unable to reproduce this failure on asachi.debian.org. > It built without failure ten times yesterday, and again once today. I requested a give back by mailing debian-wb-team, but it hasn't

Bug#861486: julia: FTBFS on mips64el (segmentation fault)

Control: reassign -1 src:openblas 0.2.19-2 Control: retitle -1 openblas: random segfaults on mips64el Control: affects -1 src:julia Hi Sébastien I was able to reproduce this on eller.debian.org by running utest/openblas_utest repeatedly: TEST 1/2 amax:samax [OK] TEST 2/2 potrf:bug_695 [OK]

Bug#861486: julia: FTBFS on mips64el (segmentation fault)

Possibly related to bug #684344 in libopenblas-base: please install OpenMP version.

Bug#861486: [Pkg-julia-devel] Bug#861486: Bug#861486: Bug#861486: Bug#861486: julia: FTBFS on mips64el (segmentation fault)

On 3 May 2017 at 13:17, Aurelien Jarno wrote: > The problem only happens when using multiple OpenMP threads, it can be > workarounded by setting OMP_NUM_THREADS=1. Thanks for investigating! Modifying debian/rules as follows did work: override_dh_link-arch: # Create

Bug#861486: [Pkg-julia-devel] Bug#861486: Bug#861486: Bug#861486: julia: FTBFS on mips64el (segmentation fault)

On 2 May 2017 at 18:58, Peter Colberg wrote: > Could you comment all lines and then successively uncomment to see > which line triggers the segfault? I commented out practically your entire program and it still randomly segfaults. > You could also try querying a symbol in

Bug#861486: julia: FTBFS on mips64el (segmentation fault)

A quick way to reproduce this on a porterbox, without having to build the entire julia package: Install julia's build-dependencies Change root to sid_mips64el-dchroot $ apt source julia $ cd julia-0.4.7/ $ debian/rules override_dh_link-arch If it manages to generate the links without a

Bug#861484: [Pkg-julia-devel] Bug#861484: julia: FTBFS on arm64

Hi Julien On 29/04/2017 17:13, Julien Cristau wrote: julia's build looks unreliable on arm64, it sometimes (often?) segfaults: https://buildd.debian.org/status/fetch.php?pkg=julia=arm64=0.4.7-6%2Bb3=1493471432=0

Bug#861486: [Pkg-julia-devel] Bug#861486: julia: FTBFS on mips64el (segmentation fault)

Hi Julien On 29 April 2017 at 17:19, Julien Cristau wrote: > https://buildd.debian.org/status/fetch.php?pkg=julia=mips64el=0.4.7-6%2Bb3=1493472677=0 I've been unable to reproduce the build failure above. I see it was subsequently given back and built successfully:

Bug#860697: deal.ii: FTBFS on i386: build-dependency not installable: trilinos-all-dev

Control: severity -1 wishlist On 19 April 2017 at 09:14, Lucas Nussbaum wrote: >> The following packages have unmet dependencies: >> sbuild-build-depends-deal.ii-dummy : Depends: trilinos-all-dev but it is >> not installable >> E: Unable to correct problems, you have held

Bug#859864: r-bioc-genomeinfodb: Reorganization of ftp://ftp.ncbi.nlm.nih.gov/genomes/all

Source: r-bioc-genomeinfodb Version: 1.10.2-1 Severity: grave Affects: r-bioc-annotationhub Tags: upstream fixed-upstream Hi Maintainer Autopkgtests of r-bioc-annotationhub started failing on 2017-0126 [1] with the following error: Error in checkIdentical(setNames(rep(c(FALSE, TRUE), c(4, 1)),

Bug#851830: khmer FTBFS on arm64: test failures

Hi Maintainer You disabled arm64 for khmer and liboxli1 binary packages, but not for liboxli-dev. This prevented khmer from migrating [1] for the following reason: liboxli-dev/arm64 unsatisfiable Depends: liboxli1 (= 2.0+dfsg-9) However, I suspect that the build failure on arm64 was transient

Bug#858133: python-tz: diff for NMU version 2016.7-0.3

On 02/04/2017 18:33, Simon McVittie wrote: See attached patch, which is very heavily based on what Graham Inggs attached. (Graham, if you want to NMU this yourself, I'm happy to step aside.) Not at all. Thank you for uploading!

Bug#859421: src:python-tz: Please orphan python-tz

Source: python-tz Severity: serious Hi Maintainers For the past two years and more, bugs requesting new upstream versions and RC bugs affecting other packages have received no maintainer response. The last five uploads have been non-maintainer uploads. Please orphan python-tz so that the

Bug#859257: libngs-sdk-dev: installs .a files to the incorrect directory

After filing #859260 and #859261, I looked at this again. The attached patch uses DEB_HOST_MULTIARCH instead of DEB_BUILD_GNU_TYPE throughout debian/rules. --- a/debian/rules +++ b/debian/rules @@ -8,9 +8,9 @@ OS := $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS) CPU := $(shell

Bug#859260: libncbi-vdb-dev: installs .a files to the incorrect directory

Package: libncbi-vdb-dev Version: 2.8.0+dfsg-1 Severity: serious Tags: patch Hi Maintainer Similar to #859257 in libngs-sdk-dev, .a files are installed to the incorrect directory (e.g. /usr/lib/i686-linux-gnu/ instead of /usr/lib/i386-linux-gnu/). The attached patch use s DEB_HOST_MULTIARCH

Bug#859257: libngs-sdk-dev: installs .a files to the incorrect directory

Package: libngs-sdk-dev Version: 1.2.3-3 Severity: serious Tags: patch Hi Maintainer .a files are installed to the incorrect directory (e.g. /usr/lib/i686-linux-gnu/ instead of /usr/lib/i386-linux-gnu/) , as can be seen in the following excerpt from a recent buildlog [1]:

Bug#858133: python-tz: FTBFS with tzdata/2017a-1

The tests have been fixed upstream, and a new version released (see #859096). Attached is an updated patch against 2016.7-0.2 taken from upstream. Description: Fix tests for 2017a tz abbreviation changes Bug: https://bugs.launchpad.net/pytz/+bug/1677177 Bug-Debian:

Bug#858133: python-tz: FTBFS: AssertionError: '+0020+0020' != 'NET+0020'

://bugs.debian.org/858133 Author: Graham Inggs <gin...@debian.org> Last-Update: 2017-03-28 --- a/pytz/tests/test_tzinfo.py +++ b/pytz/tests/test_tzinfo.py @@ -488,6 +488,7 @@ } +''' class NoumeaHistoryStartTestCase(USEasternDSTStartTestCase): # Noumea adopted a whole hour offset i

Bug#856926: rekall: package not installable after no-change rebuild

Source: rekall Version: 1.6.0+dfsg-1 Severity: serious Hi Maintainer Rebuilding rekall in sid or testing results in package python-rekall-core not being installable due to a strict versioned dependency on python-crypto (= 2.6.1). See contents of python-rekall-core.substvars:

Bug#851834: mricron FTBFS on armhf: parconvert.s:3121: Error: co-processor offset out of range

Control: severity -1 important Control: block -1 by 852798 Downgrading severity since armhf binaries were removed in #853296. Marked as blocked by #852798 in fpc.

Bug#813718: mricron FTBFS because fpc check got more strict

Ping to reset autoremoval counter.

Bug#851042: [Debichem-devel] Bug#851042: Bug#851042: molds: FTBFS: liblapacke.so: undefined reference to `sgemqr_'

I requested for reproducible build tests of molds to be scheduled. Builds were successful in unstable and testing on amd64. 2017-01-26 14:39 0.3.1-1 unstable amd64 unreproducible 47m 18s profitbricks-build5-amd64 profitbricks-build1-amd64 amd64_26/10223 2017-01-26 14:38 0.3.1-1 testing amd64

Bug#851834: [Pkg-pascal-devel] Bug#851834: mricron FTBFS on armhf: parconvert.s:3121: Error: co-processor offset out of range

Weird, I tried various values of kMaxnSLices down to 1500 with no effect. I was able to work around the problem by moving lScanResX and friends to global variables, as per the attached patch. It builds on armhf, but someone familiar should verify program functionality (on amd64 should be fine).

Bug#851834: [Pkg-pascal-devel] Bug#851834: mricron FTBFS on armhf: parconvert.s:3121: Error: co-processor offset out of range

The patch below adds line number information to the generated parconvert.s: --- a/dcm2nii/dcm2nii.lpi +++ b/dcm2nii/dcm2nii.lpi @@ -482,6 +482,7 @@ + Because of the additional lines, this changes the assembler messages to: (9009) Assembling

Bug#851834: [Pkg-pascal-devel] Bug#851834: mricron FTBFS on armhf: parconvert.s:3121: Error: co-processor offset out of range

I see the same failure with 0.20140804.1~dfsg.1-1. According to reproducible builds [1], the last successful build on armhf was on 2016-02-19. Can we request removal of the armhf binary, so this can at least migrate before the final freeze? I have some ideas on how to debug this further. [1]

Bug#826069: libghemical5v5: breaks color rendering and atom generation in ghemical

Control: severity -1 important Has anyone else confirmed this bug report? I saw the greyscale issue on two different amd64 machines. I was able to add atoms to a molecule, but they didn't appear where I expected them. That could just be me not being familiar with the interface. It

Bug#851042: [Debichem-devel] Bug#851042: molds: FTBFS: liblapacke.so: undefined reference to `sgemqr_'

On 23/01/2017 17:52, Sébastien Villemot wrote: The rebuilding for both atlas and openblas has been requested on Jan 12, and became effective on Jan 17 (see ##851133). Ah thanks! I checked on reproducible builds [1] and it was still failing, but it seems they suddenly stopped building molds on

Bug#851042: [Debichem-devel] Bug#851042: molds: FTBFS: liblapacke.so: undefined reference to `sgemqr_'

On 11/01/2017 20:55, Lucas Nussbaum wrote: /usr//lib//liblapacke.so: undefined reference to `sgemqr_' /usr//lib//liblapacke.so: undefined reference to `zhbevd_2stage_' /usr//lib//liblapacke.so: undefined reference to `zsytrf_rk_' This seems to be a recurring problem, see #810230. openblas seem

Bug#852296: yade FTBFS on arm64: compiler processes terminated (machine runs out of RAM?)

On 23/01/2017 14:08, Adrian Bunk wrote: This buildd has 6 CPUs, but it has only 8 GB of RAM. From the last changelog entry: * [d763fbf] Set compat level to 10. The switch to debhelper 10 enabled parallel builds. Yade 2017.01a-1 FTBFS on most architectures in Ubuntu. The following changed

Bug#852283: libopenblas-dev: missing on mips64el

Source: openblas Version: 0.2.19-1 Severity: serious Hi Maintainer Architecture: mips64el was added to libopenblas-base but not libopenblas-dev. Was this an oversight? Regards Graham

Bug#851726: liggghts: FTBFS on single-CPU machines (not enough slots available)

See #850229.

Bug#848781: [Debichem-devel] Bug#848781: tiledarray: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

On 13 January 2017 at 13:40, Graham Inggs <gin...@debian.org> wrote: > Do we need to request ageing of 0.6.0-4, or will this email be sufficient to > reset the autoremoval counter? The previous mail was sufficient. Version 0.4.4-2 of tiledarray is marked for autoremoval from testing on 2017-01-28.

Bug#848917: nautic FTBFS on architectures where char is unsigned: error: narrowing conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing]

On 13/01/2017 14:02, Andreas Beckmann wrote: you could have done that QA upload yourself (even without filing a bug) :-) Yeah, I know :( and I would have, seeing it is a QA package, but I thought it was too late for Stretch.

Bug#848917: nautic FTBFS on architectures where char is unsigned: error: narrowing conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing]

Thanks for the upload, Andreas! If this bug had been tagged [1] like #811740 was, I might have seen it sooner. I only saw it when I noticed nautic was not migrating in Ubuntu. :( [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-6;users=debian-...@lists.debian.org

Bug#850229: dune-grid: FTBFS (not enough slots available)

On 5 January 2017 at 13:46, Ansgar Burchardt wrote: > On my laptop with 4 cores + HT (so 8 threads), I see `mpirun` complain > once I start more than 4 processes, i.e. more processes than real > cores. Did you count threads or cores when you tried? I haven't been able to

Bug#848917: nautic FTBFS on architectures where char is unsigned: error: narrowing conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing]

://bugs.debian.org/848917 Author: Graham Inggs <gin...@debian.org> Last-Update: 2017-01-10 --- a/plant.h +++ b/plant.h @@ -30,7 +30,7 @@ char maxargs; char max_harmonic[NARGS]; char max_power_of_t; - char *arg_tbl; + signed char *arg_tbl; void *lon_tbl; void *lat_tbl;

Bug#850456: [Debichem-devel] Bug#850456: elpa: FTBFS (not enough slots available)

Hi On 6 January 2017 at 20:00, Santiago Vila wrote: > -- > There are not enough slots available in the system to satisfy the 2 slots > that were requested by the application: >

Bug#850229: dune-grid: FTBFS (not enough slots available)

Hi On 05/01/2017 12:05, Santiago Vila wrote: Status:FAILED Output: -- There are not enough slots available in the system to satisfy the 2 slots that were requested by the application:

Bug#849991: breathe: FTBFS with new doxygen?

Control: affects -1 src:gyoto Control: tags -1 patch I found a similar problem building the gyoto package. Confirming that Albert's patch from the upstream bug report fixes building breathe and gyoto. --- a/src/xmlgen.cpp +++ b/src/xmlgen.cpp @@ -620,7 +620,7 @@ if (md->isInline()) t <<

Bug#848770: trilinos: FTBFS: Test failures

Control: tags -1 - pending Control: retitle -1 trilinos: test failure with openmpi 2.0.2~ Control: severity -1 normal The Isorropia, ShyLUCore and Teko tests were disabled in trilinos 12.10.1-2 because they were failing since the recent upload of openmpi 2.0.2~. Downgrading severity, but leaving

Bug#811986: qwtplot3d: diff for NMU version 0.2.7+svn191-10.1

Hi Arto On 23 December 2016 at 14:59, Arto Jantunen wrote: > I've prepared an NMU for qwtplot3d (versioned as 0.2.7+svn191-10.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. Thanks for the upload. I'm not the maintainer, but I

Bug#848744: [Debichem-devel] Bug#848744: python-ase: FTBFS: Test failures

Hi Lucas On 19/12/2016 23:17, Lucas Nussbaum wrote: Traceback (most recent call last): File "/<>/.pybuild/pythonX.Y_2.7/build/ase/test/__init__.py", line 53, in testfile {'display': self.display}) File "/<>/.pybuild/pythonX.Y_2.7/build/ase/test/franck_condon.py", line 38, in

Bug#848506: [Pkg-julia-devel] Bug#848506: julia: FTBFS (Memory limit reached : 687558656 > 524288000)

Control: severity -1 normal Hi Santiago On 17/12/2016 21:11, Santiago Vila wrote: The failure happens always on the machines I use, which have different amounts of RAM from 2 GB to 6 GB, but the error message is always similar: ERROR: LoadError: Halting tests. Memory limit reached : 686624768

Bug#846617: seqan2: FTBFS with Boost 1.62

Source: seqan2 Version: 2.2.0+dfsg-4 Severity: serious Tags: patch Hi Maintainer seqan2 FTBFS with Boost 1.62 and outputs the following error: In file included from /<>/seqan2-2.2.0+dfsg/apps/bs_tools/casbar.cpp:67:0: /usr/include/boost/math/tools/tuple.hpp:10:60: error: missing binary operator

Bug#846573: pion: FTBFS with GCC 6: narrowing conversion

Control: tags -1 patch Patch attached. There may still be actual test failures. Description: Fix FTBFS with GCC 6 Fix narrowing conversion on architectures where char is unsigned by default. Bug-Debian: https://bugs.debian.org/846573 Author: Graham Inggs <gin...@debian.org> For

Bug#846573: pion: FTBFS with GCC 6: narrowing conversion

Source: pion Version: 5.0.7+dfsg-1 Severity: serious Hi maintainer Thanks for uploading the new version of pion! The tests fail on architectures where char is unsigned by default with the following error: http_message_tests.cpp:245:55: error: narrowing conversion of '-1' from 'int' to

<    5   6   7   8   9   10   11   12   >