Bug#911937: FTBFS on architecture=all

Package: zfsutils-linux Version: 0.7.11-2 Severity: serious Owner: ! https://buildd.debian.org/status/package.php?p=zfs-linux dh_python3 -i -O--parallel E: dh_python3 dh_python3:176: no package to act on (python3-foo or one with ${python3:Depends} in Depends) dh_systemd_enable -i

Bug#906932: kmer FTBFS in clean unstable chroot

Yes, I'm doing parallel build with -j4 On Wed, Aug 22, 2018 at 23:34 Adrian Bunk wrote: > On Wed, Aug 22, 2018 at 01:58:15PM +0000, Lumin wrote: > > Package: kmer > > Version: 0~20150903+r2013-4 > > Severity: serious > > Justification: FTBFS in clean chroot > &

Bug#906932: kmer FTBFS in clean unstable chroot

Package: kmer Version: 0~20150903+r2013-4 Severity: serious Justification: FTBFS in clean chroot I cannot build kmer under both Debian experimental, and the debian unstable docker. ``` ^ In file included from

Bug#906708: Bug#906753: Acknowledgement (GCC's -O2 optimization breaks floating point precision or something else)

This is the minimal code for repro #906753: OK with -O0, FAIL with -O2 on i386, ppc64el, ... masssq1 and masssq2 are computed from the same vector [1.1, 2.2, 3.3, 4.4], but the results are different! == #include #include // for swap

Bug#906753: GCC's -O2 optimization breaks floating point precision or something else

Package: g++-8 Version: 8.2.0-4 Severity: serious Justification: -O2 results in different double precision number result. Affects: 906708 This bug is found in package src:hepmc, which currently FTBFS on i386, arm64, ppc64el and s390x. https://buildd.debian.org/status/package.php?p=hepmc -

Bug#906708: hepmc: FTBFS on i386 / arm64 / ppc64el / s390x

control: tags -1 +patch +confirmed > Fix attached. > - double eps = 1.e-15; // allowed differnce between doubles > + double eps = 4.e-15; // allowed difference between doubles No no no, please DON'T do this! This precision issue is triggered by a GCC optimization bug, and simply bumping

Bug#906645: FTBFS due to "Dunno about this gcc"

Source: insighttoolkit4 Version: 4.13.0-dfsg1 Severity: serious Justification: FTBFS in sid/experimental. [ 14%] Building CXX object Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/vcl_deprecated.cxx.o cd

Bug#897767: closed by Mo Zhou (Bug#897767: fixed in highwayhash 0~20180209-g14dedec-5)

control: retitle -1 non-x86 symbols out of date control: severity -1 normal This non-x86 arches are not my priorities currently. It doesn't deserve another RFS bug to the mentors list, and it can be easily fixed by me when I get my Debian Developer account. On Mon, Aug 6, 2018 at 00:45 Adrian

Bug#904781: closing because h5py 2.8.0 has been uploaded

control: close -1 closing because 0.2.8 has been uploaded. I forgot to close this bug.

Bug#905439: su from util-linux breaks autopkgtest

, 2018 at 01:31:27PM -0300, Antonio Terceiro wrote: > Control: tag -1 + moreinfo unreproducible > > On Sat, Aug 04, 2018 at 03:11:17PM +0000, Lumin wrote: > > Package: autopkgtest > > Version: 5.4.2 > > Severity: serious > > > > the "su" command

Bug#905439: su from util-linux breaks autopkgtest

Package: autopkgtest Version: 5.4.2 Severity: serious the "su" command from util-linux breaks autopkgtest. The previous working one comes from shadow. python-h5py-dbg is already the newest version (2.8.0-1). python-h5py-dbg set to manually installed. python-h5py is already the newest version

Bug#905101: not working with python3

Package: pius Version: 2.2.6-1 Severity: serious Justification: totally unusable with python3. ~ ❯❯❯ pius -A -s -r ~/.gnupg/pubring.kbx -m Welcome to PIUS, the PGP Individual UID Signer. Traceback (most recent call last): File "/usr/bin/pius", line 328, in main() File

Bug#904434: intel-mkl: FTBFS in C locale

control: tags -1 +pending fixed in master branch.

Bug#904319: FTBFS when building binary-packages only

Thanks for the full log, very helpful! I can reproduce the failure with LC_ALL=POSIX python3 ... and it could be avoided by LC_ALL=C.UTF-8 python3 ... On Mon, Jul 23, 2018 at 02:43:41PM +0200, Santiago Vila wrote: > On Mon, Jul 23, 2018 at 12:16:45PM +0000, Lumin wrote: > >

Bug#904319: FTBFS when building binary-packages only

Hi Santiago, Thanks for the report, but could you please provider a more verbose failure report? And could you please test this patch: LC_ALL=C.UTF-8 python3 debian/control.py ``` diff --git a/debian/rules b/debian/rules index 212c9aa..8d21adc 100755 --- a/debian/rules +++ b/debian/rules @@

Bug#903659: OpenBLAS 0.3.1 gives incorrect SVD result

Package: libopenblas-base Version: 0.3.1+ds-1 Severity: serious https://github.com/JuliaLang/julia/pull/28002 https://github.com/JuliaLang/julia/issues/27960 https://github.com/xianyi/OpenBLAS/issues/1666

Bug#873408: lowering severity

Control: severity -1 important julia_0.6.3-5 was just uploaded to unstable, it depends on llvm-4.0 .

Bug#901377: skimage: FTBFS and Debci failure with NumPy 1.14

X-Debbugs-CC: gin...@debian.org, stef...@berkeley.edu, deb...@onerussian.com control: owner -1 ! I'm working on this. It would take days for me to finish it due to my final terms... But I think it doesn't matter because we still have a month until AUTORM. https://salsa.debian.org/lumin-guest

Bug#863507: [numba/armel,armhf] tests broken

control: found -1 0.37.0-1 control: forwarded -1 https://github.com/numba/numba/issues/3053

Bug#863508: [numba/armel] LLVM error duing sphinx build

control: retitle -1 [numba/armel] LLVM Error during sphinx build control: found -1 0.37.0-1 control: forwarded -1 https://github.com/numba/numba/issues/3052 This problem didn't appear in armhf/0.37.0-1

Bug#863509: [numba/mips,mipsel] bus error during test

control: forwarded -1 https://github.com/numba/numba/issues/3051 control: retitle -1 [numba/mips,mipsel] Bus Error at test_sum control: found 0.37.0-1

Bug#863511: [numba/ppc64el] segfault

control: forwarded -1 https://github.com/numba/numba/issues/3050 still exists in 0.37.0

Bug#863512: numba/x390x: segfault

numba 0.37.0-1 https://github.com/numba/numba/issues/3049 https://buildd.debian.org/status/fetch.php?pkg=numba=s390x=0.37.0-1=1521778366=0 = test session starts == platform linux2 -- Python 2.7.14+, pytest-3.3.2, py-1.5.2, pluggy-0.6.0

Bug#901377: ping (was: Re: skimage: FTBFS and Debci failure with NumPy 1.14)

Dear skimage maintainer, Briefly speaking, we plan to team-upload skimage (= 0.14.0) to resolve this RC bug if the original maintainers allows us to do so. We'll try to fix this after one week if the original maintainers didn't take action. skimage failed to build from source since numpy (>=

Bug#901377: skimage: FTBFS and Debci failure with NumPy 1.14

> Since the recent upload of python-numpy on 2018-05-05, skimage has been > failing its autopkgtests [1] and has now also started to FTBFS in > unstable [2] with several errors similar to the following: I see some changes adapting numpy 1.14 api change at upstream repo, however they doesn't

Bug#901383: whalebuilder is broken after the ruby upgrade

Package: whalebuilder Version: 0.6 Severity: serious Justification: functionality totally broken ~/p/skimage.pkg ❯❯❯ whalebuilder build debdev ./skimage_0.13.1-3.dsc Traceback (most recent call last): 13: from /usr/bin/whalebuilder:331:in `' 12: from

Bug#896295: Tensorflow is missing

Hello Debian-Science folks, Please feel free to CC me if you need any input about deep learning. > From: Andreas Tille > the description says: > > ... Alternatively, Keras could run on Google's > TensorFlow (not yet available in Debian, but coming up). > > Is there some estimated time frame

Bug#899513: Debian中文团队邮件地址即将失效，可能需要一位DD在5月末前采取行动

(In order to draw attention from admins of debian-chinese team, this mail is written in Simplified Chinese deliberately.) // Encoding: UTF-8, Simplified Chinese 致 Debian 中文团队： 随着 Alioth 逐步被弃用，相关的邮件列表服务也受到波及。虽然数月前 Boyuan 已经在 debian-chinese-gb 邮件列表提出邮件列表迁移问题[1]，但并 没有的到任何答复。 现在仍然在使用中文团队 Alioth

Bug#899513: Invalid maintainer address chinese-develop...@lists.alioth.debian.org

, asking them to preserve this email address. (The deadline is May 31) Which one to choose? Regards, lumin On Thu, May 24, 2018 at 09:43:55AM +0200, Christoph Biedl wrote: > Package: src:fortune-zh > Version: 2.7 > Severity: serious > User: ad...@alioth-lists.debian.net >

Bug#899159: Acknowledgement ([numpy/grave] Incorrect Memory offset in numpy.uint8 arrays)

Sorry, I made a stupid mistake. uint8 ranges from 0 to 255. signature.asc Description: PGP signature

Bug#899159: [numpy/grave] Incorrect Memory offset in numpy.uint8 arrays

Package: python3-numpy Version: 1:1.14.3-2 Severity: grave X-Debbugs-CC: debian-scie...@lists.debian.org Dear Numpy maintainers, As a student/researcher, I cannot bear any library that *SILENTLY* produces totally wrong result. This time numpy just triggered me, and I wish you can understand that

Bug#899133: FTBFS on Architecture:all

Package: caffe-cpu Version: 1.0.0-7 Severity: serious d/rules will install a file that won't be built during an arch-indep build. That's the root of this FTBFS.

Bug#898483: Acknowledgement (failed creating configuration directroy: unsupported)

control: tag -1 +patch I think the problem lays in main.cpp : 81 // Set configuration directory 82 //sprintf(writedir, "%s.%s", userdir, application); 83 sprintf(writedir, "%s%s", userdir, application); 84 if(!PHYSFS_setWriteDir(writedir)) { 85 // try to

Bug#898483: failed creating configuration directroy: unsupported

directory '/home/lumin/.lincity-ng': unsupported The user must manually delete the plain file ~/.lincity-ng, and manually create the directory ~/.lincity-ng to make it work. For a user who doesn't know the way to fix, the package is totally unusable, hence I'm marking this bug as RC. Best,

Bug#897506: Cannot reproduce

control: severity -1 important Hi, Thank you for this report, but I cannot reproduce this build failure neither on my computer, nor DoM-amd64. Hence I'm lowering the severity of this bug. http://debomatic-amd64.debian.net/distribution#unstable/caffe/1.0.0-6/buildlog

Bug#889539: pandas FTBFS: test failures

Yaroslav has just uploaded pandas 0.22.0, let's see if this problem still exists. On 7 February 2018 at 14:57, Andreas Tille <andr...@an3as.eu> wrote: > On Tue, Feb 06, 2018 at 03:51:27PM +0000, Lumin wrote: >> Apart from that, the pandas packaging needs a patch [2] to reduce

Bug#877130: highwayhash: FTBFS with GCC 7: symbols files need to be updated

On 7 February 2018 at 00:27, Andreas Beckmann wrote: > The new upstream snapshot probably cuased further symbol changes: Indeed and thanks. I was just waiting for an upstream build fix for ppc64el. -- Best,

Bug#889539: pandas FTBFS: test failures

Hi Andreas, On 6 February 2018 at 11:10, Andreas Tille wrote: > you did a really good job on latest pandas issues. Do you think you can > have a look at this problem as well? I found no related upsteam issue about the failed tests. However there are some links that might be

Bug#884294: Patch for pandas RC 884294, someone to sponsor?

> I'd volunteer to upload once it is pushed. Please ping me after pushing > since there is not commit mailing list and I'm not sure whether the > tracker solution is implemented yet. Done. https://salsa.debian.org/science-team/pandas/commits/debian -- Best,

Bug#884294: Patch for pandas RC 884294, someone to sponsor?

Control: tags -1 +patch Pandas FTBFS on amd64 due to test failure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884294 I reproduced this FTBFS on my machine (sid/amd64). This test failure was due to a numpy problem. Upstream workaround (bypass) is available: *

Bug#870029: Missing new dependency "moses"

Package: lua-torch-nn Version: 0~20170726-gf613412+dfsg-1 Severity: serious Recently the upstream added a new package "moses" as its runtime dependency, which is not packaged for Debian. The missing of 'moses' package renders 'lua-torch-nn' unusable.

Bug#861878: fixed in nvidia-cuda-toolkit 8.0.44-4

> try: grep-excuses nvidia-cuda-toolkit > :-) I find it's already unblocked, and get a new tool :-) Thanks.

Bug#861878: fixed in nvidia-cuda-toolkit 8.0.44-4

Hi, We should either lower the severity of this bug or request for an unblock for this package to prevent it and its r-deps from autoremoval.

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

Control: tags -1 +patch This patch simply discussed about the way getting NVCC working with the compiler in README.Debian. Please review.From a9c1cc803ddc531c06e0f51c50c8b2f2eba22510 Mon Sep 17 00:00:00 2001 From: Zhou Mo Date: Mon, 22 May 2017 07:53:07 + Subject:

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

>> That means, the "build your whole application with clang-3.8" >> advise is temporary and specific to CUDA 8.0. Before uploading >> CUDA 9.0 to unstable/experimental, we can change the default >> compiler back to GCC. And backporting CUDA 9.0 to stretch >> will eliminate the compiler trouble. >

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

@doko GCC-5 may be removed from unstable when CUDA 9.0 is uploaded. See below. (Maybe doko is already in some of these lists.) > The problem is the move of some parts of the toolchain to pie by > default, without updating the whole toolchain. Whenever not using only > gcc for building object

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

Hi, > This was documented in NEWS.Debian.gz. Having to use "--compiler-options > -fPIC" was however not documented in NEW.Debian.gz, at least that should > be done. > > Ok, but that's still something difficult to the user to work out, while > it is needed for basically any use of nvcc. Currently

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

Hi Samuel, I'm not sure whether this bug should be marked as serious. Since your test cases are mixing the default cc (GCC-6) and clang-3.8 together. I reproduced the failure you reported, but there is a simpler solution to the issue as shown below. test$ CC=clang-3.8 make clang-3.8-c -o

Bug#851578: add nmu patch for this bug, however encountered FTBFS due to testsuite failure

Control: tags -1 +patch Here is an NMU patch for this package. I intended to file an RFS but the debomatic build failure stopped me to do so. The build failure was caused by testsuite failure: http://debomatic-amd64.debian.net/distribution#experimental/numba/0.30.0-2.1/buildlog diff -Nru

Bug#835940: Bug#851871: RM: remove gcc-5 from stretch

Control: tags 835940 +patch On Fri, 20 Jan 2017 14:50:43 +0100 Sylvestre Ledru wrote: > >> What is the final decision regarding LLVM versions in stretch? > >  > > We are shipping with 3.7 (for ghc), 3.8 and 3.9. > >  > And 3.8 has the default. >  > Sylvestre Thank you LLVM

Bug#840589: skimage: any update?

Hello, Is there any update on this bug? python3-skimage is the only problem for one of my packages to enter testing.

Bug#842082: torch-core-free: uninstallable on architectures without lua-torch-image

Hi, Thank you for pointing this out, I noticed it. Actually I plan to add all of its runtime dependencies to its B-D list and add autopkgtest support for this package. In this way the installation failure issue on any architecture will be eliminated. Will fix it in 1~exp2 .

Bug#838789: Fwd: caffe-contrib: FTBFS: libcaffe.so.1.0.0-rc3: undefined reference to `H5LTget_dataset_ndims'

Control: affects -1 caffe On Sat, 2016-09-24 at 22:51 +0200, Andreas Beckmann wrote: > This is Bug#838789, but for some reason the BTS considers this as an > unknown package, so you didn't get this forwarded ... Thank you for forwarding. :-) > Oh, you did a source-only upload. That does not

Bug#771387: siliconmotion graphic card driver segfault and unusable.

Package: xserver-xorg-video-siliconmotion Source: xserver-xorg-video-siliconmotion (1:1.7.7-2) Version: 1:1.7.7-2+b2 Severity: serious Tags: moreinfo Hi, The xserver-xorg-video-siliconmotion segfaults right away once I started X, and then the X is totally unuseable on my machine (mipsel,