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 -O--paral
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
&
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 atac-driver/alig
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
#
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
- arm64:
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 float
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
/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vx
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 Bun
control: close -1
closing because 0.2.8 has been uploaded.
I forgot to close this bug.
, 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
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 (2.8
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 "/usr/bin/pius"
control: tags -1 +pending
fixed in master branch.
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:
>
> >
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
@@ -39
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
Control: severity -1 important
julia_0.6.3-5 was just uploaded to unstable, it depends on llvm-4.0 .
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/l
control: found -1 0.37.0-1
control: forwarded -1 https://github.com/numba/numba/issues/3053
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
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
control: forwarded -1 https://github.com/numba/numba/issues/3050
still exists in 0.37.0
numba 0.37.0-1
https://github.com/numba/numba/issues/3049
https://buildd.debian.org/status/fetch.php?pkg=numba&arch=s390x&ver=0.37.0-1&stamp=1521778366&raw=0
= test session starts ==
platform linux2 -- Python 2.7.14+, pytest-3.3.2, py-1
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 (>= 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 appl
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 /usr/lib/ruby/2.5.0/tmpdir.rb:8
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
(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 地址[
Team, 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
Sorry, I made a stupid mistake.
uint8 ranges from 0 to 255.
signature.asc
Description: PGP signature
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
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.
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 cre
ation 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,
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
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 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
>> autopkgtest fai
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,
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 useful:
https://st
> 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,
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:
*
https://github.com/pandas-dev/
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.
> try: grep-excuses nvidia-cuda-toolkit
> :-)
I find it's already unblocked, and get a new tool :-)
Thanks.
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.
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: [PATCH] README.Debian: disc
>> 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.
>
>
@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 files
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 N
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 tes
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 numba-0
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 guys. We have chance t
Hello,
Is there any update on this bug?
python3-skimage is the only problem for one of my
packages to enter testing.
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 .
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 work
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,
loongson
54 matches
Mail list logo
