Hi folks,
I have completely no idea about what this error message is supposed to
mean and how it can happen (the results surprised me since there are
only domestic changes since the last upload):
|dh_dwz -a
| dwz: debian/libsleef3/usr/lib/debug/.dwz/s390x-linux-gnu/libsleef3.debug:
On Wed, 2021-05-05 at 14:57 +0200, Drew Parsons wrote:
>
>
> The "disaster" is that they can point to different implementations.
> So
> if you check the symlinks for libblas.so, you think you're using one
> implementation, while the different libblas.so.3 means you're
> actually
> running
Hi folks,
---
Q: How far should Debian go along the way for supporting hardware
acceleration solutions like CUDA?
Choice 1: this game belongs to the big companies. we should offload
such burden to third-party providers such as Anaconda.
Choice 2: we may try to provide what the users need.
Hi Drew,
On Sun, 2021-05-02 at 13:50 +0200, Drew Parsons wrote:
> Mo Zhou did the good work of setting up an alternatives framework for
> our BLAS libraries, which is great. We can select between OpenBLAS,
> BLIS, whatever is best for the local system (even intel-mkl).
Actually that alternative
For your information,
the upstream holds a very negative attitude towards debian packaging.
https://github.com/explosion/cython-blis/issues/32
CC'ed pabs.
On Wed, 2021-03-03 at 17:51 +0100, Andreas Tille wrote:
> On Wed, Mar 03, 2021 at 05:26:11PM +0100, Gard Spreemann wrote:
> >
> > Andreas
On Thu, 2021-03-04 at 08:09 +0100, Andreas Tille wrote:
>
> I also intend to negotiate this again. While the copyright holders
> are
>
> 2018 The University of Texas at Austin
> 2016 Hewlett Packard Enterprise Development LP
> 2018 Advanced Micro Devices, Inc.
> 2019 ExplosionAI GmbH
Part
On Mon, 2021-09-20 at 19:52 +0200, Christian Kastner wrote:
> >
> > Or should we not build these jupyter notebooks for the -doc package?
>
> I don't think anyone would stop you from packaging the datasets but to
> be honest, I think that would be overkill. The -doc package has a
> popcon
> of
Hi all,
I'm back.
I've just finished my final exams so I could do something during
the holiday. That TBB repository is still work-in-progress and
FTBFS from the master branch is something expected. I will finalize
it soon. Andreas said in previous posts that we prefer a faster
NEW queue process.
Hi,
At this point I have some doubt on "what should be moved to
math team." The borderline and the expected outcome are
not discussed in some specific cases.
In my understanding, domain-specific mathematical applications,
such as theorem prover, would be a good fit for the new team.
And this is
Hi Anton,
My first impression is the same -- that may increase fragmentation.
But in fact, as long as the main contributors on these packages are
happy, why should we stop them :-)
Debian contributors are already scarce. If a new team help a group
of maintainers retain their enthusiasm, it will
Hi Ole,
On Tue, 2021-11-02 at 08:04 +0100, Ole Streicher wrote:
> Instead, I would suggest to keep (and improve) the Science Team
> policy,
> and then to have a *tiny* Math team policy, which could just be a
> 5..10-liner, like
>
> > We inherit the Science Team policy, except:
> > * The
Even more complicated is the underlying software dependency tree.
alphafold depends on dm-haiku, jax, tensorflow.
dm-haiku depends on jax.
jax depends on XLA from tensorflow.
tensorflow still in NEW.
Long way to go. Mhhh.
What's also complicated is the GPU support. Currently the only
working
API changes. So I guess the
transition won't be easy.
On Wed, 2021-12-29 at 23:27 -0800, Diane Trout wrote:
On Thu, 2021-12-23 at 11:03 -0500, M. Zhou wrote:
> Hi all,
>
> I'm back.
>
> I've just finished my final exams so I could do something during
> the holiday. That TBB r
since some of the core APIs have been changed.
Please expect a relatively negative rebuild result.
Help is welcome.
On Mon, 2022-03-14 at 01:30 +0530, Nilesh Patra wrote:
> Hi Mo,
>
> On 2/23/22 11:01 AM, M. Zhou wrote:
> > Hello guys. Finally it's all green on our releas
Hello guys. Finally it's all green on our release architectures
https://buildd.debian.org/status/package.php?p=onetbb=experimental
I shall request the slot for transition once finished the rebuild
of its reverse dependencies and filed FTBFS bugs if any.
On Tue, 2022-02-08 at 17:59 -0500, M. Zhou
On Tue, 2022-02-22 at 12:52 +0100, Drew Parsons wrote:
>
> Also useful to report their performance with the various BLAS
> alternatives.
Looking forward to it. I'm glad to provide pointers in terms of
our BLAS and LAPACK packaging.
Hi,
Thanks a lot to Scott for the review!
@Andreas: Thanks, please go ahead. Ping me if it FTBFS or any patch
needs a rebase.
On Thu, 2022-02-03 at 17:22 +0100, Andreas Tille wrote:
> Hi Scott,
>
> Am Thu, Feb 03, 2022 at 03:00:08PM + schrieb Scott Kitterman:
> >
> > Normally for a
Hi Diane,
Thank you. I have added that patch in the git repository.
On Tue, 2022-02-08 at 13:49 -0800, Diane Trout wrote:
> Hi,
>
> After Andreas pointed it out I looked through some of the build
> failures for onetbb and talked to upstream about the i386 failure.
>
On Mon, 2023-09-11 at 11:15 +0300, Andrius Merkys wrote:
>
> >
> > Then it is the dh_pytorch processing logic in pseudo code:
> > (dh_pytorch is inserted before dh_gencontrol)
> >
> > for each binary package $pkg {
> >
> > if $pkg.architecture is all {
> > # does not require specific
Hi folks,
I'm writing down my draft design for dh_pytorch here in order to hear
some comments or feedbacks. If you maintain a package that depends
on python3-torch or relevant pytorch packages, please let me have
your attention.
We need a custom dh module for pytorch because we have multiple
Hi,
Long story short. Julia debian package seriously lacks of volunteer
to work on it and keep it up to date properly. Initially I planned
to get this package to the latest 1.7.3 version and solve a bunch
of bugs.
Then I discovered that the latest version downloads a million
code snapshots that
Hi Norbert,
It's good to see you around, and thanks for the comment!
Let's see how the other people think.
Basically at this point I think Debian's strict policy
feels like a double-blade sword. It is good as long as we
want to make elegant offline builds and ensure reproducibility.
It is
There is a tbb -> onetbb transition guide:
https://oneapi-src.github.io/oneTBB/main/tbb_userguide/Migration_Guide.html
On Sat, 2022-06-18 at 14:42 +0200, Andreas Tille wrote:
> Hi,
>
> Am Wed, Jun 08, 2022 at 08:46:27AM +0300 schrieb Andrius Merkys:
> > On 2022-06-07 22:11, Nilson Silva wrote:
>
~ ❯❯❯ apt list libtbb-dev -a (base) 20:49
Listing... Done
libtbb-dev/experimental 2021.5.0-9 amd64
libtbb-dev/unstable,now 2020.3-2.1 amd64 [installed,automatic]
On Tue, 2022-06-07 at 19:11 +, Nilson Silva wrote:
>
> Good evening!
>
> I would like to know when the team will upload the new
address this issue in timely manner.
On Thu, 2022-07-28 at 10:15 +0200, Andreas Tille wrote:
> Hi Graham,
>
> Am Thu, Jul 28, 2022 at 09:15:06AM +0200 schrieb Graham Inggs:
> > Hi
> >
> > On Wed, 27 Jul 2022 at 17:57, M. Zhou wrote:
> > > The previous
The previous segfault on armel becomes Bus Error on armel and armhf.
I can build it on Power9, but it seems that the test fails on power8 (our
buildd).
On Wed, 2022-07-27 at 09:56 +0200, Andreas Tille wrote:
> Control: tags -1 unreproducible
> Control: tags -1 moreinfo
> Control: severity -1
, M. Zhou wrote:
> Control: affects -1 src:onetbb
>
> It's due to a regression bug in GCC-12 that caused linker internal
> error on ppc64el:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017772
> Does not look like something I can look into.
>
> If you need it so
Control: affects -1 src:onetbb
It's due to a regression bug in GCC-12 that caused linker internal
error on ppc64el:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017772
Does not look like something I can look into.
If you need it soon in testing, please go ahead and downgrade compiler
to
Currently, I'd say PyTorch and TensorFlow are the two most
popular libraries. And I even worry google is trying to
write something new like Jax to replace TensorFlow in some aspects.
On Sat, 2023-01-14 at 11:12 +, Rebecca N. Palmer wrote:
> theano has been mostly abandoned upstream since
Don't know how to address this issue but have some relevant comments.
Eigen library does not support run time dispatch for CPU ISAs.
When a package is built upon the amd64 baseline ISA but ran on a modern
CPU, the performance can be very poor.
This is why I build the tensorflow and pytorch
I did something similar. Here is my example:
The linker script is here:
https://salsa.debian.org/science-team/blis/-/blob/master/debian/version_script.lds
This script is used like this:
https://salsa.debian.org/science-team/blis/-/blob/master/debian/patches/libblas-provider.patch
This patch
On Fri, 2023-07-14 at 01:51 +0200, Sébastien Villemot wrote:
>
> Your fix looks good. Note that an even better fix is to simply Build-
> Depend on libblas-dev. Linking against an optimized BLAS does not
> really help at build time, because since all variants are ABI
> compatible and use the same
I agree. The usage of ATLAS is more suitable for source based distros
like Gentoo. Plus, according to my past benchmarks, ATLAS, even if
compiled locally with -march=native flags, still falls behind OpenBLAS
and BLIS in terms of performance.
Both OpenBLAS and BLIS are still healthy, actively
Hi team,
This is a message on my future plan to overhaul the intel-mkl package.
Some people (bcc'ed) from intel are interested as well,
so I'm sharing the plan to a public list.
The current MKL version in our archive has been outdated for 3 years
https://salsa.debian.org/science-team/intel-mkl
34 matches
Mail list logo
