Re: Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

Hi, I've updated the caffe package in the git repo, one of the major changes is that `python-caffe-cpu` was changed to `python3-caffe-cpu`. On 2 June 2016 at 07:00, Ghislain Vaillant wrote: > > > The build time testsuite, autopkgtest and piuparts serve different > purposes.

Re: Deep learning subteam of Debian Science team

> I read your mail as a random rant on how evil and stingy is the world, which I > don't think it's a useful thought to have... > > > On Fri, 31 Aug 2018, 8:28 a.m. Mo Zhou, wrote: > > I need the FULL permission on all the deep learning related packages > ma

Re: Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code

> Currently I can build it manually on my daily Debian experimental > system (amd64) and another unclean chroot (amd64). However I'm > still not sure whether the other can build it successfully like I do. Preliminary lintian-clean binary packages are available on debomatic-amd64:

Re: Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code

control: retitle -1 RFS: tensorflow/1.10.1+dfsg-A1 [ITP] control: tag -1 -moreinfo Hello science team and mentors, I did a right choice to write the python+ninja build system from scratch (I call this build system TF-Shogun in the source code). Now I started to sort out any possible FTBFS with

Deep learning subteam of Debian Science team

Hi folks, I need the FULL permission on all the deep learning related packages maintained by myself, while at the same time I don't bother to create another team mail address because the team will be very tiny or even only myself. In many Salsa teams my new DD account permission is lower than my

Re: Deep learning subteam of Debian Science team

ût 2018 à 08:28, Mo Zhou a écrit : > > Hi folks, > > I need the FULL permission on all the deep learning related packages > maintained by myself, while at the same time I don't bother to create > another team mail address because the team will be very tin

[done] Re: RFS: tensorflow/1.10.0+dfsg-A1 [ITP]

control: close -1 I'll sponsor myself shortly as long as nothing goes wrong in the last build. This will be an ~300MB initial upload. On Fri, Sep 07, 2018 at 01:23:03PM +, Mo Zhou wrote: > Hi mentors, > > Does anyone have idea about the following very last blocker for libtensorf

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

Hi Wookey and Bastian, On Sun, Oct 21, 2018 at 06:51:16PM +0100, Wookey wrote: > On 2018-10-21 17:16 +0200, Bastian Blank wrote: > > Hi > > > > On Sun, Oct 21, 2018 at 09:51:15AM +, Mo Zhou wrote: > > > about naming convention of SONAME and package name. > &g

RFC: Naming convention for ILP64 variant of BLAS/LAPACK

Hi folks, This is an informal RFC about naming convention of SONAME and package name. As discussed in [1][2][3], Debian will need a set of ILP64[4] interface to BLAS/LAPACK in the future. However, adding this set of interface will bring changes and NEW binary packages to all packages that fill

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

On Mon, Oct 22, 2018 at 09:57:56PM +0200, Florian Weimer wrote: > > Proposal: > > > > * The "-ilp64" postfix should be appended to the SONAME of all the new > > shared objects that provide ILP64 interface. For example: > > > > libblas.so.3 (LP64) -> libblas-ilp64.so.3 (ILP64) > > > >

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

On Mon, Oct 22, 2018 at 07:58:38PM +0200, Bastian Blank wrote: > On Mon, Oct 22, 2018 at 07:55:10PM +0200, Sébastien Villemot wrote: > > For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they > > will be compiled using LP64, and not ILP64. Only integers exposed > > through the

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

On Tue, Oct 23, 2018 at 02:12:16PM +, Mo Zhou wrote: > (1) bin:libblas3 from src:lapack > (2) bin:libatlas3-base from src:atlas > (3) bin:libopenblas-base from src:openblas > (4) bin:libblis1 from src:blis [WIP] > (5) bin:libmkl-rt from src:intel-mkl

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

Ben Hutchings wrote: > > > On Mon, 2018-10-22 at 15:07 +, Mo Zhou wrote: > > > > Here are some references: > > > > > > > > 1. > > > > https://software.intel.com/en-us/mkl-linux-developer-guide-using-the-ilp64-interface-vs-lp64-interface &

Bug#911698: ITS: tbb

Package: libtbb-dev Version: 2017~U7-8 Severity: important X-Debbugs-CC: steven.cap...@gmail.com, debian-science-maintain...@lists.alioth.debian.org, debian-science@lists.debian.org tbb packaging repo is hosted under debian-science team's namespace on Salsa. However the maintainer is not set

Aborting all plan about deep learning frameworks.

Hi Science Team, Sorry for the depressing mail subject. Some of you may have an impression on my past endeavor to introduce some deep learning software to Debian, including TensorFlow etc. But now I cannot bear them anymore. Indeed my research field is computer vision and deep learning, and

Re: Aborting all plan about deep learning frameworks.

On Tue, Nov 06, 2018 at 12:18:48PM +0100, Stephen Sinclair wrote: > It's true that this field is rapidly moving these days and it's hard > to keep up with upstream releases. My interest in taking the Keras > and Lasagne packages was mainly to help provide stable and well-tested > targets for

Bug#909793: RFS: intel-mkl/2019.0.117-2~bpo9+1 [NEW,stable-backports]

requirement to (>= 3.5) + * Downgrade debhelper compat level to 10. + * Enable control.bpo.py script in rules. + * Backport to stretch. + + -- Mo Zhou Tue, 25 Sep 2018 08:19:29 + + intel-mkl (2019.0.117-2) unstable; urgency=medium * Export HOME=/tmp/ to fix FTBFS due to the failure that rpm

Bug#909500: nvBLAS as an alternative to libblas.so.3

Package: libnvblas9.2 Version: 9.2.148-1 Severity: wishlist X-Debbugs-CC: debian-science@lists.debian.org Nvidia says nvBLAS is a "drop-in" BLAS library however it merely provides several level-3 BLAS symbols. That being said, nvBLAS is indeed a valid candidate for libblas.so.3 if explicitly

Re: Bug#909457: ITP: blis -- BLAS-like Library Instantiation Software Framework

simple benchmark result here: https://github.com/flame/blis/issues/255 On Mon, Sep 24, 2018 at 07:06:44AM +0000, Mo Zhou wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-science@lists.debian.org > Owner: Mo Zhou > > * Package name: blis > Version

Dropping python2 support for numba?

Hi Daniel, Eventually python2 will die out and in order to get rid of python2, the leaf node packages should drop python2 first. I think numba is a good start to drop python2. Numba is too buggy. I tried to use numba in my research code for many many times and it never worked. You filed 10 RC

Re: Updates about BLAS64

variants where any two of the variants are compatible to each other but not co-installable) [1] deb-symbols(5) On Tue, Dec 18, 2018 at 03:12:57PM +, Mo Zhou wrote: > > > BTW, what is the "-base" (in libopenblas-base) supposed to mean? > > > > I do

Re: dwz: libsleef3.debug: .debug_line reference above end of section

Hi, Thanks for the pointers. But I think I'm not able to fix it even if I tried to diagnose the debug information. ATM I asked several people and it is likely that the dwz error stems from toolchain support problem. Now the build log on non-release archivectures are also available, and it seems

Best practice to copy(reuse) a shared object and assign it with another SONAME?

Hi mentors, I'm wondering if there is any shared object trick that allows me to create some "stub" shared object that reuses all symbols from another shared object, but has different SONAME compared to the original one. Background: * We have a shared object named libopenblas.so.0, with

Updates about BLAS64

Hi -science, Some time ago we discussed about packages for BLAS64 ABI/API. Here are some updates about the subsequent works: * blas64 and lapack64 symlinks and alternatives have been added to intel-mkl. src:intel-mkl bin:libmkl-rt enhances: libblas.so.3, libblas64.so.3,

Re: Updates about BLAS64

Hi, On Sun, Dec 16, 2018 at 09:15:03AM +0100, Sébastien Villemot wrote: > >    src:blis > >  bin:libblis1 (meta) > >    deps: libblis1-openmp | libblis1-pthread | libblis1-serial > >    provides: libblas.so.3 > >  bin:libblis64-1 (meta) > >    deps: libblis64-1-openmp | ... >

Re: Updates about BLAS64

On Tue, Dec 18, 2018 at 12:42:22PM +0100, Sébastien Villemot wrote: > >   src: openblas > > > > bin: libopenblas-base (meta) > >   deps: libopenblasX-openmp | libopenblasX-pthread, > > bin: libopenblasX-openmp > >   conflict: libopenblasX-pthread > > bin: libopenblasX-pthread

Re: python3-tensorflow; lintian tag for pretrained neural net

Hi -science and -devel, this section is for -science As said by Yunqiang, tensorflow itself is a very complex system and it is even worse that we have to write our own build system for it. Our current build system for Tensorflow 1.X (in

Re: spaCy: Create repository, merge bugs

Hi Andreas, Please always search on Salsa before really starting to package any dependency of spaCy. IIRC I've finished nearly all the dependencies, except for thinc. There are around ten packages but I aborted the whole package chain because thinc, the backend of spaCy, is yet another deep

Re: Debian Maintainer requesting upload permission for selected packages

Hi Maarten, Thanks for your great work for the science team, and congratulations for your DM status. When you are requesting for the DM upload permission, the first person to contact should be your main sponsor(s) instead of the team, because most of your audiences have not reviewed any of the

Bug#915186: RFA: caffe -- Fast, open framework for Deep Learning

Package: wnpp Severity: normal X-Debbugs-CC: debian-science@lists.debian.org As time goes by, the DL framework is more and more likely an educational code base. It's architecture and design is old, compared to PyTorch or TensorFlow 2.0. The last time I use caffe for neural network training is

Re: Test error in python-cytoolz

e__', repr(x))} > > > > -- Docs: https://docs.pytest.org/en/latest/warnings.html > > == 1 failed, 189 passed, 177 warnings in 2.00 seconds > > == > > E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd > > /build

Re: spaCy: Create repository, merge bugs

On Thu, Nov 29, 2018 at 03:06:14PM +0100, Andreas Tille wrote: > > The dependency chain is basically ready to be uploaded. Specifically, > > for thinc and spaCy, please drop my name from control if there is any. > (Uhmmm, I see I left it on thinc when uploading to new - I'll fix it in > Git

Re: Updates about BLAS64

Hi, On Thu, Jan 03, 2019 at 03:13:00PM +0100, Drew Parsons wrote: > I'd say it's more common for non-coinstallable packages to be installed in > subdirs (e.g. using DESTDIR facilities during configuration and build), and Theoretically yes, but in fact I don't want to make different variants

Re: cblas library abstraction

Hi, Debian's default (generic, no optimization) Atlas is really SLOW, such that I can write a faster BLAS by simply following this guide: https://github.com/flame/how-to-optimize-gemm Debian's reference BLAS (netlib) contains both BLAS and CBLAS API/ABI, which should be able to be linked

Pre- and post- Buster plans for Julia language related packaging

Hello folks, I think I should talk about the pre- and post- Buster plan for Debian's Julia related packages publically rather than inside the three-person Julia team, because neither me nor Graham is heavy Julia user. Peter is too busy. Any suggestion and feedback will help us make Julia related

Re: hwloc and openblas backports for AMD Zen

Hi Frederik, I think backporting openblas is possible, and it won't require much work. Recently I've worked on some similar packages. intel-mkl has been backported to stable but I suspect whether MKL's performance is guaranteed on AMD CPUs. Another new BLAS library called BLIS is waiting in the

Re: Bug#926019: RM: clsparse -- ROM; dead upstream

On Mon, Apr 01, 2019 at 05:41:59PM +0200, Ghislain Vaillant wrote: > Agreed, though I was warned by the upstream developer that the CLMath suite > was > not much of a priority at AMD. > > CLBlas and CLFFT are in a similar state and might face a similar outcome. Sounds like that AMD has totally

Re: Bug#868355: Any reason not to simply upload ceres-solver with adjusted version of libeigen3-dev

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

Re: Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition

Hi Sébastien, On Sun, Feb 03, 2019 at 12:07:20PM +, Mo Zhou wrote: > It turns out that the incorrect matrix product is a result of > gomp + iomp library clash: octave is linked against the GNU OMP, > while libmkl-rt.so invokes Intel(LLVM) OMP by default. I got in touch with

Re: libopencv 3.2 for buster or some other version ?

Hi shirish, On Sat, Feb 23, 2019 at 08:43:50AM +, shirish शिरीष wrote: > I know we are close to the freeze but is there a possibility of any > other version of libopencv apart from 3.2 to come to buster ? Impossible. It's too late to get any newer version into Buster and every OpenCV

SIMDebian: Debian Partial Fork with Radical ISA Baseline

Hi folks, For most programs the "-march=native" option is not expected to bring any significant performance improvement. However for some scientific applications this proposition doesn't hold. When I was creating the tensorflow debian package, I observed a significant performance gap between

Re: IBM POWER9 SIMD support? (Was: SIMDebian: ...)

Hi Kingsley, On Sat, Feb 16, 2019 at 11:43:46AM -0800, Kingsley G. Morse Jr. wrote: > My understanding is IBMs "POWER9" CPUs > > 1.) have SIMD instructions[1] and > > 2.) are used by the new, and very cool, open > *hardware* Talos II workstations[2], which > > 3.) already

Started working on OpenBLAS flavors: six variants in total

Hi Sébastien, I started working on the 6 variants of OpenBLAS: (32-bit, 64-bit) x (pthread, openmp, serial) The priorities of pthread, openmp, serial variants are 100, 99, 98 respectively. The work-in-progress updates can be found in the "lumin" branch at

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

Hi Drew, On Sat, Feb 09, 2019 at 01:07:47PM +1100, Drew Parsons wrote: > On 2019-02-09 03:25, Mo Zhou wrote: > > I think it would be more constructive to provide arch-specific packages for > eigen/blas etc on amd64 which Conflict/Replace/Provide the standard > packages. >

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

On Sat, Feb 09, 2019 at 01:14:43PM +0800, Benda Xu wrote: > Hi Mo, > > Very interesting initiative. I understand it will Intel-specific for > the moment. What is your vision in opitmizing with AMD CPUs? Thanks for your interest. This project didn't mention AMD CPU because I have no experience

Is multiple-layers of alternatives a good thing to users?

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

Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition

Package: octave Version: 4.4.1-4 Severity: grave X-Debbugs-CC: debian-science@lists.debian.org, ido...@neto.net.il Dear octave maintainer, I received an astonishing bug report[1] saying that MKL returns wrong result for matrix multiplication. However, my further investigation suggests that the

Re: Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition

control: severity -1 important Hi Sébastien and Sylvestre, On Sun, Feb 03, 2019 at 10:16:05AM +0100, Sébastien Villemot wrote: > Control: tags -1 unreproducible > > Dear Lumin, > > I've tried to reproduce the problem with Netlib BLAS, OpenBLAS and > BLIS, but without success (I did not try

Re: Is multiple-layers of alternatives a good thing to users?

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,

Re: freefem3d #897752 and clsparse #897722 RC fixes

On Mon, Feb 04, 2019 at 10:56:25PM +, Rebecca N. Palmer wrote: > I have posted (but can't upload) fixes for both. Thank you for your effort. Initially I was planning to take a look and team upload them. > I don't know if these packages are worth saving (both of them appear > to be dead

Re: Updates about BLAS64, co-installable variants

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

Re: Is multiple-layers of alternatives a good thing to users?

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

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

Hi Guillem, Thanks for your helpful pointers. On Sat, Apr 06, 2019 at 10:55:35PM +0200, Guillem Jover wrote: > If what you are interested in though is just a small subset of the > archive, another option that would benefit everyone and is perhaps > less cumbersome than having to jugle around

Towards lapack / lapack64 packaging

Hi science team, I'm trying to add multi-flavor support to the openblas package, as a part of the ongoing BLAS64 + LAPACK64 work. However, there is some problems need to be discussed. Two problems will be discussed in this email: (1) building problem about OpenBLAS's liblapack64.so (2)

Re: Towards lapack / lapack64 packaging

Hi Gard, On 2019-05-16 20:39, Gard Spreemann wrote: > Incidentally, and somewhat off-topic: Do you know if a similar effort is > being made for the PETSc and SLEPc packages (src petsc and slepc)? Do you mean 64-bit array indexing support for them? According to our dependency chain, they are

Re: Towards lapack / lapack64 packaging

Hi Sébastien, On 2019-05-15 16:23, Sébastien Villemot wrote: >> Sébastien provided some possible solutions: >> >> 1. build a 64-bit indexing variant of src:lapack >> 2. provide a liblapack64-pic (Sébastien prefer this) > > First, note that solution 1 is a superset of solution 2 (i.e. we

Re: is it safe to "try" gcc 9 from experimental in Debian/testing

Hi Christophe, I personally recommend you to try it within a docker container, or a chroot environment. On 2019-05-24 14:23, Christophe Trophime wrote: > Hi, > I would like to try gcc-9 on a Debian/testing. > It seems that install gcc-9 from experimental will update libatomic1 > and libgcc1 > I

Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"

Hi, On 2019-05-21 23:52, Paul Wise wrote: > Has anyone repeated the training of Mozilla DeepSpeech for example? By chance I found a paper from a pile of papers (that attacks AI models) that Berkeley researchers have successfully attacked DeepSpeech: https://arxiv.org/pdf/1801.01944.pdf IHMO

Re: Concern for: A humble draft policy on "deep learning v.s. freedom"

Hi Osamu, On 2019-06-09 08:28, Osamu Aoki wrote: > Although I understand the intent of "SemiFree" or "Tainted" (by Yao), I > don't think these are a good choice. We need to draw a line between > FREE(=main) and NON-FREE(non-free) as a organization. I think there are There is no such a line as

Re: Concern for: A humble draft policy on "deep learning v.s. freedom"

Hi Osamu, On 2019-06-08 18:43, Osamu Aoki wrote: >> This draft is conservative and overkilling, and currently >> only focus on software freedom. That's exactly where we >> start, right? > > OK but it can't be where we end-up-with. That's why I said the two words "conservative" and

Re: Concern for: A humble draft policy on "deep learning v.s. freedom"

Hello guys, On 2019-06-10 13:14, Sam Hartman wrote: > I really like the term toxic candy. > In two words it explains both that the model is appealing and > problematic. So let's keep this name :-) > If there are subdivisions of toxic candy that we decide are free, we > should come back and

Re: Concern for: A humble draft policy on "deep learning v.s. freedom"

Hi Charles, On 2019-06-13 13:11, Charles Plessy wrote: >> 1. Free datasets used to train FreeModel are not required to upload >>to our main section, for example those Osamu mentioned and wikipedia >>dump. We are not scientific data archiving organization and these >>data will blow up

Re: libtrilinos-teuchos-dev depends on libblas-dev

Hi, Linking programs against reference blas enables us to switch the underlying library smoothly: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries However, in general libopenblas-dev provides libblas.so, that should be enough to replace the reference blas. The possible reason is that

Annoying stderr message when importing sklearn

Hi list, Can someone look into fixing the following bug? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923937 The deprecation warning is very annoying and I've already seen that useless noise in my terminal for hundreds of times. This not only affects sklearn but also all it's reverse

Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"

Hi Paul, On 2019-05-21 23:52, Paul Wise wrote: > Are there any other case studies we could add? Anybody is welcome to open an issue and add more cases to the document. I can dig into them in the future. > Has anyone repeated the training of Mozilla DeepSpeech for example? Generally speaking,

Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"

Hi Ben, Good catch! I'm quite sure that the 3 categories are not overlapping with each other. And I've fixed the language to make it logically correct: A **ToxicCandy Model** refers to an explicitly free software licensed model, trained from unknown or non-free dataset. A model is

Re: Bug#929296: libopenblas-base: is libopenblas.so needed?

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

Anyone tried to build 64-bit-indexing reference *c*blas?

Hi science team, I'm talking about the future updates to src:lapack, the reference implementation. BLAS (fortran), LAPACK (fortran), LAPACKE (C), all of them support building the 64-bit-indexing variant. For fortran we just need to add the "-fdefault-integer-8" flag (for some other fortran

Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"

Hi Paul, They are added to the case study section. And I like that question from ffmpeg-devel: Where is the source for all those numbers? On 2019-05-21 08:02, Paul Wise wrote: > On Tue, May 21, 2019 at 3:11 PM Mo Zhou wrote: > >> I'd better write a draft and shed some light

Bits from /me: A humble draft policy on "deep learning v.s. freedom"

Hi people, A year ago I raised a topic on -devel, pointing out the "deep learning v.s. software freedom" issue. We drew no conclusion at that time, and linux distros who care about software freedom may still have doubt on some fundamental problems, e.g. "is this piece of deep learning software

Re: Bug#929296: libopenblas-base: is libopenblas.so needed?

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

Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"

problem: In the definition of "Free Model", I mentioned that the model *should be reproducible* with a fixed random seed. This is also a good practice for ML/DL engineers and researchers. On 2019-05-21 12:10, julien.pu...@laposte.net wrote: > Hi > > Le 21 mai 2019 13:4

Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"

Hi Andreas, On 2019-05-21 09:07, Andreas Tille wrote: > Not sure whether this is sensible to be added to the issue > tracker. I always abuse issue track in my personal repository. > Quoting from your section "Questions Not Easy to Answer" > > > 1. Must the dataset for training a Free Model

Please start reviewing the updated OpenBLAS packaging for six different flavors

Hi Sébastien and science team, Please start checking the updated openblas packaging here, I'm almost finalizing the changes. The experimental package can be built and installed: https://salsa.debian.org/science-team/openblas/tree/lumin I say "almost" because this is a hell of detail. I still

Re: scientific python stack transitions

Hi science team, By the way, when do we start dropping python2 support? The upstreams of the whole python scientific computing stack had already started dropping it. On 2019-07-07 14:40, Drew Parsons wrote: > On 2019-07-07 21:11, Rebecca N. Palmer wrote: >> matplotlib and scikit-learn have also

Re: Help with package a library with python bindings

Hi Christophe, On Wed, Apr 17, 2019 at 01:35:13PM +0200, Christophe Trophime wrote: > I'm moving their build system from scons to cmake to be able to build python > bindings for both python and python3. Please don't create more python2 packages, as per the python policy. > I've managed to get

Re: h5py and hdf5-mpi

Hi Drew, thanks for the commits to h5py. On 2019-08-12 03:10, Drew Parsons wrote: > We need to change h5py to support hdf5-mpi. h5py is somewhat crippled > as serial-only. I didn't even notice that since my use case for hdf5 is light-weight. (training data is fully loaded from hdf5 into

Re: h5py and hdf5-mpi

On 2019-08-14 03:59, Drew Parsons wrote: > Shall we go ahead with Alastair's "minimal" change now, or should we > discuss further? If the MPI build can correctly work for the serial use case, I vote for the "minimal" change. I roughly went through the h5py documentation and found nothing special

Cross-distro Call for BLAS64/LAPACK64 Convention Alignment

Dear BLAS/LAPACK maintainers[0], (Please invite more distribution maintainers to join the discussion if you know the right contact, thanks. Please keep the debian-science public mailing list in CC to keep the discussion public.) Mordern BLAS/LAPACK implementations, such as OpenBLAS, BLIS, etc

Re: RFR: src:lapack's 64bit-indexing variant

On 2019-08-20 16:15, Sébastien Villemot wrote: > Le mardi 20 août 2019 à 18:11 +0200, Sébastien Villemot a écrit : >> Le mardi 20 août 2019 à 09:00 -0700, Mo Zhou a écrit : >> > Got it. But keep in mind that we haven't adapted the rules/control >> > for 32-bit architec

Re: RFR: src:lapack's 64bit-indexing variant

Hi Sébastien, On 2019-08-20 15:26, Sébastien Villemot wrote: > I pushed a few further commits from myself to address some remaining > issues. The main one concerns the override to dh_makeshlibs that you > had removed, but which is really needed so that packages have the > correct DEBIAN/shlibs

Re: RFR: src:lapack's 64bit-indexing variant

a few seconds. On 2019-08-20 17:40, Sébastien Villemot wrote: > Le mardi 20 août 2019 à 19:29 +0200, Gilles Filippini a écrit : >> Mo Zhou a écrit le 20/08/2019 à 18:21 : >> > On 2019-08-20 16:15, Sébastien Villemot wrote: >> > > I realize that I don’t know what we

RFR: src:lapack's 64bit-indexing variant

Hi science team, My 64bit-indexing updates for src:lapack are ready for review. Please have a look at my git commits on the "lumin" branch: g...@salsa.debian.org:science-team/lapack.git -b lumin Several points to note: 1. I merged the content of liblapack-pic into liblapack-dev. 2.

Re: dwz: .debug_line reference above end of section [now in mpi4py]

Hi Drew, FYI I got no update at this point... still noop'ing dh_dwz once it went wrong. On 2019-07-18 15:17, Drew Parsons wrote: > On 15 Jan 2019 Andreas Tille wrote: >> On Tue, Jan 15, 2019 at 02:19:40PM +, Mo Zhou wrote: >> > Temporarily overriding dh_dwz to noop it is an

Re: RFR: src:lapack's 64bit-indexing variant

reason. Should we disable the BLAS64/LAPACK64 builds for the 4 architectures and head towards openblas64? mips64el, s390x, ppc64, sparc64, they are not typical architectures used for intensive scientific computing. On 2019-09-04 02:21, Mo Zhou wrote: > Finally the 3.8.0-3 build result on

RFR: src:openblas Multi-Flavour updates

Hi Sébastien, I've updated the git branch for this feature: https://salsa.debian.org/science-team/openblas/commits/lumin It can be built against the git master version of src:lapack (i.e. 3.8.0-4 + 1 commit that fixes installation path). Problems pointed out in the previous round of review have

Re: RFR: src:lapack's 64bit-indexing variant

Hi Sébastien, On 2019-09-30 11:59, Sébastien Villemot wrote: > > I have uploaded 3.8.0-5 to experimental, that fixes this issue and > several other ones. The package now builds everywhere, and passes both > piuparts and autopkgtests. saw that. > Lumin: Do you have other pending changes? Or

Re: Bug#941569: RFS: sentencepiece/0.1.83+dfsg-1 [ITP] -- Unsupervised text tokenizer for Neural Network-based text generation

FYI, Science team policy described the standard workflow inside team: https://science-team.pages.debian.net/policy/ When you can create new repos, you should already have the "Maintainer" permission on salsa, that means nothing would be blocked. Please follow the science team policy and see if

Re: MBF: don't build against libatlas3-base if possible

Hi Ian, On Wed, Oct 30, 2019 at 01:17:20PM +, Ian Jackson wrote: > Hi. I would like to congratulate you on your work so far. I am no > expert on this area but from what I read, I want to encourage you :-). :-) > I think it's important to give the MBF recipients a clear set of >

uploading lapack 3.8.0-8 and openblas to unstable?

Hi Sébastien, Shall we upload lapack 3.8.0-8 + [ Sébastien Villemot ] + * Migrate to Python 3 ++ python3.patch: new patch ++ d/control, d/tests/control: replace python by python3 (Closes: #943142) + * Bump to debhelper compat level 12. +On mipsel, disable dh_dwz. + + [ Mo Zhou

science application + opencl/rocm + AMD GPU?

Hi science team, I'd like to request the team for sharing some experience on this topic: "scientific application + opencl/rocm + AMD GPU". Any experience will be very helpful to me in terms of the being-investigated ROCm integration[1] to Debian. I'd like to ask you the following questions: 1.

[need mentor] GSoC Proposal: Enhancement to Debian's BLAS/LAPACK Ecosys

Hi science team, I'm proposing the following project for GSoC 2020: "Enhancement to Debian's BLAS/LAPACK Ecosys" To some extent this is basically making some portion of my todo-list well-funded by Google :-) I cannot "mentor" myself as I'm the participating student... So I think I need a GSoC

Re: priority score of libflame (LAPACK alternative)?

unit tests failed with libflame::lapack.so backend. On Mon, Dec 02, 2019 at 01:13:04PM +0000, Mo Zhou wrote: > Hi science team, > > As usual, I'd like to inform the team before registering a new lapack > implementation into our blas/lapack ecosystem. The new implementation > i

Re: RFR: src:openblas Multi-Flavour updates

min, > > Le samedi 21 septembre 2019 à 22:59 -0700, Mo Zhou a écrit : > >> I've updated the git branch for this feature: >> >> https://salsa.debian.org/science-team/openblas/commits/lumin >> >> >> It can be built against the git master version of s

Re: pandas: Python 2 removal, 0.23 -> 0.25 transition

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

theano: remove python2

Hi Rebecca, Theano is a leaf package blocking python2 removal. What's the blocker for the pending commits on the master branch? It can be successfully built in a clean chroot. May I team upload it on behalf of py2 removal?

Summary: BLAS/LAPACK Ecosys Massive Update

Hi fellow developers, A good news especially for Debian scientific computing users. I shall call it a massive update, even if the whole update was decomposed into many tiny steps where some of them had already been finished 1 year ago. BLAS/LAPACK are two typical and classical dense linear

MBF: don't build against libatlas3-base if possible

Type: performance improvement, integration Affected: `apt rdepends libatlas3-base` Severity: important BLAS is a basic dense linear algebra library, so important like an mathematical "libc". The standard fortran implementation is included in src:lapack, which is often *hundreds* times slower than

priority score of libflame (LAPACK alternative)?

Hi science team, As usual, I'd like to inform the team before registering a new lapack implementation into our blas/lapack ecosystem. The new implementation is called "libflame", from the upstream of BLIS: https://github.com/flame/libflame Similar to BLIS, it is a lapack-like object-based

Re: Is Alink something interesting for us?

Hi Andreas, quote: "Alink is ... based on Flink" (Flink = Apache Flink) Alibaba builds everything with Java. Java is the core language of this company. I don't think it's easy to maintain anything on top of Apache's Java XXX (e.g. Flink) for Debian, especially given that Debian don't have too

  1   2   >