Thanks Norbert,
I overlooked its outdated status!
On 2021-11-11 23:53, Norbert Preining wrote:
> Dear all,
>
> I am Norbert Preining from Fujitsu Research, member of the Scikit-learn
> Consortium and Debian Developer
> https://qa.debian.org/developer.php?login=prein...@debian.org
>
> Together
Source: ros-vision-opencv
Version: 1.15.0+ds-2
Severity: important
Tags: +ftbfs
Dear maintainer,
package ros-vision-opencv FTBFS against opencv 4.5.0 (experimental).
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: ros-opencv-apps
Version: 2.0.2-1
Severity: important
Tags: +ftbfs
Dear maintainer,
package ros-opencv-apps FTBFS against opencv 4.5.0 (experimental).
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Hi Aisha,
On Sun, Oct 25, 2020 at 08:55:17AM -0400, Aisha Tammy wrote:
> Actually this should not be a problem.
> The blas-lapack switch only changed paths in the runtime ld.so search
> file /etc/ld.so.conf.
> So the compile time linker actually only builds against the
> reference blas/lapack
gentoo and was asking for details on how the debian packages are
> made.
>
> Specifically I was wondering on which binary sources are used for creating the
> packages
>
> There seem to be multiple versions and splits of software from intel.
>
> The gentoo mkl-rt package was o
Hi Drew,
Thanks for the report. python3-opencv is built using cmake. I have no
idea on the way of enabling multiple python3 builds for the current
cmake build system.
On Tue, Oct 20, 2020 at 07:40:44PM +0800, Drew Parsons wrote:
> Package: python3-opencv
> Version: 4.2.0+dfsg-6+b4
> Severity:
On Mon, Oct 12, 2020 at 12:05:31PM +0800, Drew Parsons wrote:
> This would be an extra set of packages (e.g. libarpack2-64-dev,
> libarpack2-64) providing libarpack64.so (or libarpack-64.so) alongside
> libarpack.so (i.e. coinstallable). It would be built against
> libblas64-dev instead of
Hi Sébastien,
I'm going to upload src:lapack and src:openblas sequentially, with
the following changes:
1. enable building DEPRECATED routines for BLAS64 in src:lapack, which
were enabled for BLAS32.
2. B-D on src:lapack (>= 3.9.0-3) for src:openblas. The resulting
openblas64 libraries will
nd why we should aim at identical
> behaviour of armel and armhf in the field of number crunching. Those
> two architectures are very different in that area, in a number of
> respects, and this is unavoidable given the hardware differences.
We should not expect the same bahaviour of hardwar
> Just one question: did you try to rebuild it from source without
> changing anything? Maybe it’s just the rebuild that fixed it, and not
> the flag change.
Rebuilt without change: hang with libopenblas0-pthread
Rebuilt with USE_TLS=0: hang
Rebuilt with USE_SIMPLE_THREADED_LEVEL3=1: hang
> Just one question: did you try to rebuild it from source without
> changing anything? Maybe it’s just the rebuild that fixed it, and not
> the flag change.
Rebuilt without change: hang with libopenblas0-pthread
Rebuilt with USE_TLS=0: hang
Rebuilt with USE_SIMPLE_THREADED_LEVEL3=1: hang
Control: tags -1 -moreinfo
Hi Sébastien,
Good catch! I tried to remove the mentioned LDFLAG
DEB_LDFLAGS_MAINT_STRIP="-Wl,-Bsymbolic-functions"
and rebuilt the openblas 3.8 package.
Then deadlock issue disappeared.
--
debian-science-maintainers mailing list
Control: severity -1 important
Control: tags -1 +moreinfo
Clarification: possibly a Ubuntu bug
Hello guys,
The way to reproduce with docker + ubuntu devel (20.10)
1. docker image pull ubuntu:devel
2. docker run -ti ubuntu:devel
3. apt update -y ; apt upgrade -y
4. apt install -y r-base-core
5.
Hi Paul,
Thanks for pointing that out. It has been fixed in the subsequent upload,
and is landing onto the archive.
On Tue, Apr 28, 2020 at 02:48:20PM +, Paul Richards Tagliamonte wrote:
> Hey there lumin,
>
> I've marked this package for accept, but I have a note:
>
> The full text of the
Hi Paul,
On Tue, Apr 28, 2020 at 09:14:28AM -0400, Paul Tagliamonte wrote:
> On Tue, Apr 28, 2020 at 03:23:41AM +0000, Mo Zhou wrote:
> > Could you please accept it first? I'm sure it will be fixed in the next
> > upload? :-)
>
> Hurm, I wouldn't reject over this, and I th
Hi Paul,
Fixed and re-uploaded.
Thank for you diligent work!
On Tue, Apr 28, 2020 at 02:10:14AM +, Paul Richards Tagliamonte wrote:
>
> Hey lumin,
>
> Thanks for your work on this package as well.
>
> Unfortunately, this one also needs to be marked for REJECT.
>
> In the copyright file,
Hi Paul,
Thanks for the quick response.
Fixed and reuploaded.
On Tue, Apr 28, 2020 at 02:10:14AM +, Paul Richards Tagliamonte wrote:
>
> Hey lumin,
>
> Thanks for your work on this package as well.
>
> Unfortunately, this one also needs to be marked for REJECT.
>
> In the copyright file,
Hi Paul,
Thank you very much for the work!
On Tue, Apr 28, 2020 at 01:44:03AM +, Paul Richards Tagliamonte wrote:
> Hey lumin,
>
> Package looks good, I've marked it for accept.
>
> A trainee noticed that debian/patches/clog.patch is empty. Is that
> intentional?
That's a mistake, and
o patch at input line 7
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --
> |Description: prevent cmake from downloading binary blob from internet.
> |Author: Mo Zhou
> |diff --git a/contrib/modules/face/CMakeLists.
Package: libblas-dev
Version: 3.8.0-7
Severity: normal
Hi,
Besides the proposal to remove libcblas from atlas,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943712
I also propose to add a readme file in libblas-dev, e.g.
/usr/share/doc/libblas-dev/libcblas.so.README
which describes why
Package: libatlas3-base
Version: 3.10.3-8
Severity: normal
Hi Sébastien,
I propose to remove the libcblas.so in order to avoid trapping
more maintainer into the performance problem.
See the MBF bug:
https://lists.debian.org/debian-devel/2019/10/msg00273.html
If you agree with that, I'll
Hi Rebecca,
Personally I fully support the option (a). Afterall nobody likes
taking extra burden especially when there is no upstream support
anymore. (b) is for good wish but impractical. (c) means we just
let pandas package rot and die.
Even if some portion of users still need the python2
Source: opencv
Version: 4.1.2+dfsg-3
Severity: serious
Opencv's cmake files unconditionally use the MSA
ISA baseline once detected MIPS architecture.
It resulted in mips64el sigill and caffe (rdep
of opencv) ftbfs on mips64el. mipsel should have
been affected too.
--
debian-science-maintainers
(re-sent due to incorrect CC address in last post)
Hi NOKUBI,
Thank you for working on this.
Although it may sound boring or even frustrating, data used for training
machine learning models, or pre-trained machine learning models
should be carefully dealt with.
Your copyright file is not
Hi NOKUBI,
Thank you for working on this.
Although it may sound boring or even frustrating, data used for training
machine learning models, or pre-trained machine learning models
should be carefully dealt with.
Your copyright file is not complete
On 2019-05-21 09:13, Drew Parsons wrote:
>
> This seems to be the problem. libopenblas.so.0 is used to resolve
> symbols instead of liblapack.so.3. The symbol in question in
> Bug#914655 is ilaver_ which is part of lapack, not specific to
> libopenblas.
ilaver_ is indeed a standard fortran
Hi Drew,
I didn't closely investigate into the scipy bug, but I can answer
some of your questions. BTW, does anything break in a clean chroot?
I mean, making sure a thing works fine in an unclean environment
is difficult.
On 2019-05-21 04:57, Drew Parsons wrote:
> Why is
Hi Drew,
Thanks for the report! I didn't even notice that...
I think this will fix the bug, after updating symbols for all
architectures likewise and refreshing the symbol lists:
https://salsa.debian.org/science-team/blis/commit/ca29b285093acc602b891a993fa38a33f79a
--
control: tags -1 +wontfix
Hi Enrico,
> It would have been an entirely different story if the datasets that nltk
> needs were also packaged in Debian, so that it could have worked out of
> the box.
I totally understand your preference and I also prefer the libraries
that work out of box without
On Tue, Feb 26, 2019 at 11:25:49AM +0100, Andreas Tille wrote:
> > The eigen3 maintainer and I are happy to simply rebuild affected
> > packages after every eigen3 update, but Emilio considers it an upstream bug.
> > Unfortunately I could not find anybody able to shed more light on the
> > eigen3
Source: intel-mkl
Version: 2019.1.144-3~bpo9+1
Severity: normal
Hi Frederik,
Thank you for reporting this issue. To some extent I don't like
to restore the old behavior as it increases the differential
between the unstable version and the one for stable-backports.
I'll leave it as a bug. Maybe
Source: visp
Version: 3.1.0-2
Severity: important
maybe opencv4 broke it due to api change
visp_3.1.0-2_ppc64el-2019-02-15T12:00:30Z.build.zst
Description: Binary data
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: ros-vision-opencv
Version: 1.13.0+ds-2
Severity: important
the cmake build simply rejected OpenCV 4 because it asks for 3 ...
ros-vision-opencv_1.13.0+ds-2_ppc64el-2019-02-15T11:39:35Z.build.zst
Description: Binary data
--
debian-science-maintainers mailing list
Source: ros-opencv-apps
Version: 1.12.0-2
Severity: important
Opencv4 broke it due to API change.
ros-opencv-apps_1.12.0-2_ppc64el-2019-02-15T11:35:50Z.build.zst
Description: Binary data
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: limereg
Version: 1.4.1-4
Severity: important
limereg_1.4.1-4_ppc64el-2019-02-15T10:59:23Z.build.zst
Description: Binary data
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Source: caffe-contrib
Version: 1.0.0+git20180821.99bd997-2
Severity: important
Opencv4 breaks caffe-contrib due to API change.
caffe-contrib_1.0.0+git20180821.99bd997-2_ppc64el-2019-02-15T08:09:29Z.build.zst
Description: Binary data
--
debian-science-maintainers mailing list
Source: caffe
Version: 1.0.0+git20180821.99bd997-2
Severity: important
Opencv4 breaks caffe due to API change.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Source: ceres-solver
Version: 1.14.0-3
Severity: important
-
Build Architecture: ppc64el
Build Type: any
Build-Space: 25989336
Build-Time: 810
Distribution: unstable
Fail-Stage: build
Host Architecture: ppc64el
Install-Time: 30
Job: /home/debian/x/AUTORB/ceres-solver_1.14.0-3.dsc
Package: libopenblas-base
Version: 0.3.5+ds-1
Severity: important
https://github.com/xianyi/OpenBLAS/issues/1955
https://github.com/JuliaLang/julia/pull/30661
Julia's workaround to this issue is disablibg some kernels.
diff --git a/kernel/x86_64/KERNEL.SKYLAKEX b/kernel/x86_64/KERNEL.SKYLAKEX
control: tags -1 +wontfix
Hi Ido,
As discussed in [1], I think this issue is not fixable because there
is no bug in either MKL or Octave. The GEMM computation error is just
because the clash between libgomp and libiomp.
If you need to use Octave against MKL, please set the environment
variable
bug while writing this email. The alternative name
should be libblis64.so.***2***-x86_64-linux-gnu)
On Fri, Jan 04, 2019 at 10:09:15AM +0100, Sébastien Villemot wrote:
> Le mardi 18 décembre 2018 à 15:12 +0000, Mo Zhou a écrit :
> > On Tue, Dec 18, 2018 at 12:42:22PM +0100, Sébastien Vi
Hi Guus,
On Mon, Feb 04, 2019 at 07:55:41AM +0100, Guus Sliepen wrote:
> > libblis.so.2 libblis2 #MINVER#
>
> If the ABI and API are the same for all variants, a much better
> solutions seems to me to have a single libblis2 that can switch at
> runtime between the different variants, perhaps
Hi Ian and Thibaut,
Inspired by Thibaut's comment, I worked out a good solution for
the co-installation problem, which only results in a single layer
of alternatives.
Thibaut's proposed layout:
> Package: libblis2-openmp, Provides: libblas.so.3, libblis.so.2
> Package: libblis2-pthread,
Hi devel,
A user suggested[1] that the 6 variants[2] of BLIS should be
co-installable. However, making them co-installable would result in
multiple layers of alternatives in the update-alternatives system and
will possibly confuse users, as discussed in [3]. I wrote this mail
in case anyone has a
control: severity -1 wishlist
control: tag -1 wontfix
Moving headers out of mkl/ subsirectory would mess up user's /usr/include
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
control: tags -1 +fixed-in-experimental
3.4.4+dfsg-1~exp1
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
control: tags -1 +fixed-in-experimental
3.4.4+dfsg-1~exp1
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Package: ros-opencv-apps
Version: 1.12.0-1
Severity: important
Tags: patch
https://patch-diff.githubusercontent.com/raw/ros-perception/opencv_apps/pull/71.diff
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Package: libmkl-dev
Version: 2019.0.117-2
Severity: important
MKL's mkl_cblas.h header can be used as a CBlas header alternative.
However when it is really used in this way, the preprocessor won't be
able to find another header "mkl_types.h" in public directory. That
means, I'd better move the
Package: python3-sklearn
Version: 0.20.0+dfsg-1
Severity: serious
https://buildd.debian.org/status/package.php?p=scikit-learn
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
Package: libtbb-dev
Version: 2017~U7-8
Severity: important
X-Debbugs-CC: steven.cap...@gmail.com,
debian-science-maintain...@lists.alioth.debian.org,
debian-scie...@lists.debian.org
tbb packaging repo is hosted under debian-science team's namespace on
Salsa. However the maintainer is not set
and ILP64 interface
I will send a RFC proposal about the NEW ILP64 interface on science list.
[1] you can find it on salsa under science-team's namespace
On Fri, Oct 19, 2018 at 10:18:53AM +0200, Sébastien Villemot wrote:
> Hi,
>
> Le samedi 13 octobre 2018 à 13:22 +, Mo Zho
Package: libgmp-dev
Version: 2:6.1.2+dfsg-3
Severity: important
Tag: patch
Justification: affects Julia's functionality on non-x86 arches
This patch is cherry-picked from upstream repo:
https://gmplib.org/repo/gmp/rev/c59c3879f982
Related discussions:
Package: libopenblas-dev
Version: 0.3.3+ds-1
Severity: wishlist
Hi Sebastien,
The range between priority numbers of OpenBLAS and Atlas is a bit narrow.
I think it isn't enough for furture usage when BLIS landed onto the
archive, especially when we wanted to provide libraries in different
Package: intel-mkl
Version: 2018.3.222-3
Severity: wishlist
https://software.intel.com/en-us/articles/intel-math-kernel-library-release-notes-and-new-features
I should also write a watch file monitoring this page:
https://pypi.org/project/mkl/
--
debian-science-maintainers mailing list
control: tags -1 +pending
Hi Helge,
Thanks for the translation. Already fixed in git repo:
1d28203424cf7f84851157f7372ef00c39098d74
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
control: tags + unreproducible
control: close -1
This doc build failure, which was likely triggered by latex, has not
been reproduced for a long time. I determined to close it because
it's no longer a valid bug.
--
debian-science-maintainers mailing list
Package: lua-torch-torch7
Version: 0~20170926-g89ede3b-5
Severity: important
The headers such as TH.h are moved to lua's private include path
instead of the global include path /usr/include . This move allows
me to install PyTorch's headers to /usr/include in the future because
PyTorch ships
Package: lua-torch-nn
Version: 0~20171002-g8726825+dfsg-3
Severity: normal
I forgot to add Breaks: fields in torch7 package.
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
59 matches
Mail list logo
