Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: onnx
Version : 1.3.0
Upstream Author : Facebook and Microsoft
* URL : https://onnx.ai/
* License : Expat
Programming Lang: C++, Python
Description : Open Neural Network Exchange
Open
Hi Bastian,
I've uploaded julia_1.0.2-1 to unstable (NEW) yesterday. There are
already six uploads being piled up in NEW. These uploads already have
been tested by Ubuntu devel extensively, and are suitable for the
Buster release.
I totally understand that for traditional C/C++ shared object, str
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: cpuinfo
Version : git HEAD
Upstream Author : PyTorch developers
* URL : https://github.com/pytorch/cpuinfo
* License : BSD-2-Clause
Programming Lang: C
Description : CPU INFOrmation
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 e
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: gym
Version : 0.10.9
Upstream Author : OpenAI
* URL : https://gym.openai.com/
* License : MIT/Expat
Programming Lang: Python
Description : A toolkit for developing and comparing
55PM +0000, Mo Zhou wrote:
> Hi Bastian,
>
> I've uploaded julia_1.0.2-1 to unstable (NEW) yesterday. There are
> already six uploads being piled up in NEW. These uploads already have
> been tested by Ubuntu devel extensively, and are suitable for the
> Buster release.
&
") to NEW queue.
Only in this way can I get rid of the fear that Julia wouldn't enter
Buster in time... Sigh...
On Mon, Dec 17, 2018 at 12:38:25PM +, Mo Zhou wrote:
> Hi,
>
> Another fortnight has passed. Any update?
>
> I've just uploaded Julia 1.0.3 to the N
Hi,
On Thu, Dec 20, 2018 at 09:29:15PM +0100, Ansgar Burchardt wrote:
> Hi,
>
> Mo Zhou writes:
> > Another fortnight has passed. Any update?
>
> Sorry for taking so long; I wanted to put this on our meeting agenda,
> but currently don't find much time...
>
>
Hi,
On Thu, Dec 20, 2018 at 09:01:06PM +0100, Bastian Blank wrote:
> > One of Julia's tests checks this, and hence autopkgtests fail if debug
> > symbols are missing from sys.so, which is compiled from .jl scripts, not
> > C/CXX source.
>
> This could be also interpreted as "this test is broken".
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
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, Prov
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 usi
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 gener
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.
>
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 a
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: gotop
Version : 2.0.1
Upstream Author : Caleb Bassi
* URL : https://github.com/cjbassi/gotop
* License : AGPL-3.0
Programming Lang: Go
Description : terminal based graphical activity
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 r
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: simdjson
Version : git master
Upstream Author : Daniel Lemire
* URL : https://github.com/lemire/simdjson
* License : Apache-2
Programming Lang: C++
Description : Parsing gigabytes of JSON
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: python-fire
Version : 0.1.3
Upstream Author : google
* URL : https://github.com/google/python-fire
* License : apache-2
Programming Lang: Python
Description : library for automatically
Hi Alexander,
On Wed, Mar 06, 2019 at 07:05:34PM +0100, Alexander Wirt wrote:
> Thats where you come in, please tell me how tools like salsa, alioth,
> git, tracker and so on changed to way you work. I want to know everything,
> the good, the bad and so on.
I started to use Alioth since 2014 an
Hi folks,
As we know the Debian CI Infrastructure, which runs autopkgtest upon
relevant package updates to help us improve distribution quality.
However, it still doesn't support the isolation-machine feature, which
associates to tests that require interaction with the kernel, such as
kernel modul
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: python-pynvml
Version : 7.352.0
Upstream Author : NVIDIA
* URL :
* License : BSD-3-Clause
Programming Lang:
Description : Python3 bindings to the NVIDIA Management Library
https
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: gpustat
Version : 0.5.0
Upstream Author : https://github.com/wookayin
* URL : https://github.com/wookayin/gpustat
* License : expat
Programming Lang: py
Description : just less than nvidia
Hello guys,
I'm talking about the src:double-conversion package (popcon >= 70k),
and a choice for the post-Buster stage.
The upstream doesn't follow semantic versioning convention at all.
Recently they have changed the SOVERSION to 3:
https://github.com/google/double-conversion/commit/4199ef3d456
Hi,
I realized that it's too late to ask the upstream to revert the SONAME bump.
And I decided to bump the soversion after the Buster release.
On Tue, Mar 19, 2019 at 06:49:39PM +0100, Bernd Zeimetz wrote:
> On 3/19/19 2:25 AM, Mo Zhou wrote:
> > Hello guys,
> >
>
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: diff-so-fancy
Version : 1.2.5
Upstream Author :
* URL : https://github.com/so-fancy/diff-so-fancy
* License : MIT
Programming Lang: Perl
Description : Good-lookin' diffs. Actually
Hello guys,
To my surprise multiple people expressed their interest in
productivity-friendly diff highlighting. So let me write a brief
summary on this topic, after some investigation.
Mattia told me privately about the alternative of diff-so-fancy:
diff a b | colordiff | diff-highlight | les
control: reassign -1 git
control: severity -1 wishlist
control: retitle -1 please privde separated binary package for diff-highlight
On Sat, Mar 23, 2019 at 10:51:14AM +, Simon McVittie wrote:
> On Sat, 23 Mar 2019 at 07:41:06 +0000, Mo Zhou wrote:
> > In fact the diff-highlight
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: jsonnet
Version : x.y.z
Upstream Author : Google
* URL : https://github.com/google/jsonnet
* License : Apache-2.0
Programming Lang: C++, Python
Description : The data templating language
Hi,
> I think the default should be reconsidered.
I second that since I always refuse to use Wayland, due to
1. Gnome's keyboard configuration under wayland is definitely rubbish.
I need extremely high keyboard repeat rate and short latency:
xset r rate 160 160
The fastest repeat ra
Hi folks,
The absense of a centralized, informal Debian package repository where
trusted users could upload their own packaging scripts has been
long-forgotten. As an inevitable result, many user packaging scripts
exist in the wild, scattered like stars in the sky, with varied
packaging quality. T
Hi,
This single sentence is quite ambiguous to non-native english speakers.
At the first glance I interpreted the sentence as
"This will only lead to flamewars"
due to the meaning of bikeshed[1].
However, I got a hint from a fellow developer and learned that
"Bikeshed" has its own meaning unde
On Sun, Apr 07, 2019 at 10:05:35PM +0800, Shengjing Zhu wrote:
>
> Why not just start this as a personal project? And prove it works.
This is going to be a non-trivial initial work. On a non-business
and free-software basis, listen to the others first would be very
helpful. Positive feedbacks alw
asn’t joined Debian yet...
>
> Ondrej -- Ondřej Surý
>
> > On 7 Apr 2019, at 15:26, Mo Zhou wrote:
> >
> > Can we implement it?
On Sun, Apr 07, 2019 at 04:31:24PM +0200, Jonathan Carter wrote:
> +1, it's a good idea and I've thought of it before as well.
Nice!
> Reading some of the initial replies to your post, it seems like people
> don't entirely understand what you mean by an AUR-like service. This
> would definitely
overhead.
If I were a rookie, I'd really like single-file specifications
which allows simple copy&pasting.
On Mon, Apr 08, 2019 at 04:54:51AM +, Mo Zhou wrote:
> On Sun, Apr 07, 2019 at 04:31:24PM +0200, Jonathan Carter wrote:
> > +1, it's a good idea and I've th
Hi,
As you wish, I added a disclaimer to the toolkit, and replaced every
single "Debian" keyword in the repo with "D**ian", except for those
in disclaimer.
```
Everything included in this repository is totoally unrelated to the Debian
Project, or any OFFICIAL Debian development. Debian Project is
nt (virtually) zero-overhead naive prototype, still allows the
reuse of existing debian packaging scripts and documentations.
Plus, letting users write PKGBUILD doesn't help them learn
Debian packaging at all...
On Mon, Apr 08, 2019 at 03:29:12PM +0800, Paul Wise wrote:
> On Sun, Apr 7, 2019 at
Hi,
On Mon, Apr 08, 2019 at 08:54:27AM +0100, Phil Morrell wrote:
> On Mon, Apr 08, 2019 at 05:00:21AM +0000, Mo Zhou wrote:
>
> Obviously working implementation > perfect theoretical, but I'm confused
> by your insistence on a single file without abstraction. Even an
> u
On Mon, Apr 08, 2019 at 03:46:15PM +0800, Paul Wise wrote:
> On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote:
>
> > However, the translator itself is not trivial, as it might need
> > it's own shell parser or something alike to be reliable enough.
>
> Couldn't you
o use these scripts/tools. That said, I want a better name
too.
On Mon, Apr 08, 2019 at 12:05:56PM +0200, W. Martin Borgert wrote:
> Quoting Mo Zhou :
> > As you wish, I added a disclaimer to the toolkit, and replaced every
> > single "Debian" keyword in the repo with "D
Hi,
On Mon, Apr 08, 2019 at 03:31:21PM +0500, Andrey Rahmatullin wrote:
> On Mon, Apr 08, 2019 at 09:58:26AM +0000, Mo Zhou wrote:
> > AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> > all of them are single-file format. The advantages of single
Hi,
On Mon, Apr 08, 2019 at 12:37:36PM +0200, Ondřej Surý wrote:
>
> I very much dislike the idea of inventing yet another format. Your
> energy would be much better used if you rather added support for
> external tarballs to the packaging tools (with hashes, etc.) and turn
> this into DEP.
There
On Mon, Apr 08, 2019 at 12:51:15PM +0200, Jonathan Carter wrote:
> On 2019/04/08 12:37, Ondřej Surý wrote:
>
> Indeed. I can see why Mo would want to put it in one file, but the
> Debian package format can work just fine if you work from git
> repositories as you suggest, plus if it looks like a m
Hi,
The proposed idea is source-only-based, and is totally different
from PPA (source+binary-based). I'm a PPA user and I don't have
any reason to re-invent yet another PPA.
The proposed idea is to take some advantages from source-based
software distribution tools. Examples are available here:
ht
Hi,
On Mon, Apr 08, 2019 at 08:18:53AM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2019 at 06:49:10AM +0000, Mo Zhou wrote:
> > Hi,
> >
> > As you wish, I added a disclaimer to the toolkit, and replaced every
> > single "Debian" keyword in the repo w
at 08:26:53AM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2019 at 10:47:20AM +0000, Mo Zhou wrote:
> If I interpret this correctly, your idea becomes, "use a single file
> package specification, except for the parts that live somewhere
> completely external and separate
On Mon, Apr 08, 2019 at 08:36:45AM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2019 at 11:02:35AM +0000, Mo Zhou wrote:
> In such a large community of volunteers it may not be enough to propose
> something that is only marginally better because the cost (even just in
> cognitiv
On Mon, Apr 08, 2019 at 03:50:19PM +0300, Tzafrir Cohen wrote:
> Hi,
>
> The README states a directory structure with a top-level collection
> directory, but the repository currently does not include one.
The github.com:dupr/DefaultCollection.git repo is indeed a specification
compliant if you ma
Hi,
On Mon, Apr 08, 2019 at 01:59:04PM +0200, W. Martin Borgert wrote:
> Quoting Mo Zhou :
> > Plus, letting users write PKGBUILD doesn't help them learn
> > Debian packaging at all...
>
> Then I would try to diverge as little as possible
> from the classical way how
Hi,
On Mon, Apr 08, 2019 at 10:22:42AM -0400, Roberto C. Sánchez wrote:
>
> Two suggestions:
>
> - Stop claiming that what you propose is "zero-cost", "only 1 second of
> work", etc.*
And, I'm already tired of saying that again and again.
> - Find the individuals who currently experience the
Hi list,
I drafted a 0.0 alpha release[1] for the toolkit, and created a logo for
the DUPR project. From now on I'll try to add more packaging scripts
(maybe I should call them recipes) to the default collection[2].
Packaing plans are tracked here[3], and maybe further discussion about
the DUPR (D
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 with
Hi list,
I'd like to present some significant changes to the DUPR prototype[1].
A helper library[4] has been added to automatically generate debian/* from
shell variables. The HFT[2] file or an auxiliary debian/ directory could
be used to override the default debian/* file templates.
Although my
2PM +0000, Mo Zhou wrote:
> > https://github.com/dupr/DefaultCollection/blob/master/rover/rover.durpkg
> > The last example is the shortest yet complete one -- only 25 lines.
>
> I only looked at this one and I am disappointed: there's just git clone,
> but n
Hi,
On Tue, Apr 09, 2019 at 04:34:58PM +, Holger Levsen wrote:
> it's breaking the logic of reading. Why is top posting bad?
Some email clients folds the whole thread disregarding the Subject change.
Maybe doing so is a bad practise here.
> On Tue, Apr 09, 2019 at 04:27:48PM +00
Hi,
On Tue, Apr 09, 2019 at 06:53:44PM -0700, Russ Allbery wrote:
> Mo Zhou writes:
>
> This is one of those vi vs. Emacs things: I don't think you're going to
> convince anyone who prefers it the other way. Possibly my least favorite
> thing about RPMs is the spec f
Hi,
On Wed, Apr 10, 2019 at 09:46:28AM +0200, Marc Haber wrote:
> On Wed, 10 Apr 2019 03:17:39 +0000, Mo Zhou wrote:
> >The design of .durpkg is permissive enough because the header part, i.e.
> >the shell script is fully controled by the user. In this shell script,
> >on
Hi,
On Thu, Apr 11, 2019 at 08:40:07AM +0200, Thomas Goirand wrote:
> On 4/7/19 4:34 PM, Mo Zhou wrote:
> > I as the
> > initiator of the idea would definitely take action if I got enough
> > positive feedbacks.
>
> Great! Go ahead, and get in touch with the FTP te
Hi Helmut,
Thank you very much for the detailed review! :-)
On Wed, Apr 10, 2019 at 04:56:51PM +0200, Helmut Grohne wrote:
> It seems that a key aspect of this thing is avoiding to (re)distribute
> sources. You give good reasons for why this is needed and I see no need
> to reiterate or discuss t
Hi,
On Thu, Apr 11, 2019 at 09:26:15AM +0100, Simon McVittie wrote:
> On Thu, 11 Apr 2019 at 07:44:30 +0000, Mo Zhou wrote:
> It might be interesting to look at game-data-packager, which is another
> tool that builds and optionally installs .deb files for data that is
> not suit
Hi people,
This message is neither a good news, nor asking for help. I'm writing
to share some of my points about Deep Learning Framework packaging,
after a re-evaluation of the status of TensorFlow's latest build
systems. My thoughts are concluded from failures instead of success.
That said, they
Hi Andreas,
On Tue, Apr 16, 2019 at 02:29:54PM +0200, Andreas Tille wrote:
> Thanks a lot for the summary and all your previous work you've spent
> into this. As far as I understand your summary it would be even
> "burning" a student if we would throw theses packaging task on a
> student in a GSo
Hi Adrian,
On Tue, Apr 16, 2019 at 11:07:34PM +0300, Adrian Bunk wrote:
>
> How many percent of the paid GSoC and Outreachy student workers
> continue unpaid afterwards and become a DM or DD?
It's not realistic to expect a student to continue any unpaid effort
after the GSoC / Outreachy particip
Hi Ondřej,
On Wed, Apr 17, 2019 at 01:12:12PM +0200, Ondřej Surý wrote:
> The only single person I’ve been mentoring in GSoC did as little as
> possible to pass the half-time, cashed the money and stopped
> responding to emails.
>
> So, experience might wildly vary...
Sorry to hear that. It must
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: blingfire
Version : git-HEAD
Upstream Author : Microsoft
* URL : https://github.com/Microsoft/BlingFire
* License : MIT
Programming Lang: C++, Python, Perl, Batch, etc
Description
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: onnxruntime
Version : 0.4.0
Upstream Author : Microsoft, et al.
* URL : https://github.com/Microsoft/onnxruntime
* License : MIT
Programming Lang: C++
Description : scoring engine for Open
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: ngraph
Version :
Upstream Author : Nervana / Intel
* URL : https://github.com/NervanaSystems/ngraph
* License : Apache-2.0
Programming Lang: C++
Description : C++ library, compiler and
Hi Sam,
On 2019-05-13 12:33, Sam Hartman wrote:
> The New Maintainer's Guide [1] already is based around debhelper and dh
> and effectively recommends it strongly. So it wouldn't mean that.
>
> [1]: https://www.debian.org/doc/manuals/maint-guide/
Several years ago I nearly re-translated maint
Hi Ben,
On 2019-05-13 15:10, Ben Hutchings wrote:
> On Mon, 2019-05-13 at 06:08 -0700, Mo Zhou wrote:
> [...]
>> In brief:
>> * if maintained by person: no restriction, given that
>> the maintainer is not MIA
>> * if team-maintained: recommend dh
>
> I woul
Hi,
On 2019-05-14 07:59, IOhannes m zmölnig wrote:
> i've migrated many of my packages from cdbs to dh, but there's one
> feature which cdbs sports and which i miss strongly (at least: the last
> time i checked) in dh (so much, that i haven't converted a couple of
> packages): building of multiple
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) confirming
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 would
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 built
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
rea
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
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 **Non-fr
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, tr
Hi Tzafrir,
On 2019-05-21 19:58, Tzafrir Cohen wrote:
> Is there a way to prove in some way (reproducible build or something
> similar) that the results were obtained from that set using the specific
> algorithm?
I wrote a dedicated section about reproducibility:
https://salsa.debian.org/lumin/de
..
I need some time to think about it, verify, and
refine the definition.
On 2019-05-22 08:49, Holger Levsen wrote:
> On Tue, May 21, 2019 at 07:53:34PM -0700, Mo Zhou wrote:
>> I wrote a dedicated section about reproducibility:
>> https://salsa.debian.org/lumin/deeplearning-policy#neu
Hi,
On 2019-05-22 12:43, Sam Hartman wrote:
> So, I think it's problematic to apply old assumptions to new areas. The
> reproducible builds world has gotten a lot further with bit-for-bit
> identical builds than I ever imagined they would.
I overhauled the reproducibility section. And lowered th
Hi Andy,
Thanks for you comments.
On 2019-05-23 09:28, Andy Simpkins wrote:
> Your wording "The model /should/be reproducible with a fixed random seed."
> feels
> correct but wonder if guidance notes along the following lines should be
> added?
>
> *unless* we can reproduce the same result
Hi Sam,
On 2019-05-23 15:33, Sam Hartman wrote:
> I don't think that's entirely true.
Yes, that's a bit cruel to upstream.
> Reproducibility is still an issue, but is no more or less an issue than
> with any other software.
Bit-by-bit reproducibility is not quite practical for now. The
refined
Hi Andy,
On 2019-05-23 17:52, Andy Simpkins wrote:
> Sam.
> Whilst i agree that "assets" in some packages may not have sources
> with them and the application may still be in main if it pulls in
> those assets from contrib or non free.
> I am trying to suggest the same thing here. If the data set
On 2019-05-23 17:58, Sam Hartman wrote:
> So for deep learning models we would require that they be retrainable
> and typically require that we have retrained them.
The two difficulties make the above point not easy to achieve:
https://salsa.debian.org/lumin/deeplearning-policy#difficulties-questi
On 2019-05-24 15:59, Paul Wise wrote:
> On Fri, May 24, 2019 at 1:58 AM Sam Hartman wrote:
>
>> So for deep learning models we would require that they be retrainable
>> and typically require that we have retrained them.
>
> I don't think it is currently feasible for Debian to retrain the
> models
Hi Adam,
On 2019-05-24 10:19, Adam Borowski wrote:
>
> I'm not so sure this model would be unacceptable. It's no different than
> a game's image being a photo of a tree in your garden -- not reproducible by
> anyone but you (or someone you invite). Or, a wordlist frequency produced
> by analyzi
Hi Paul,
On 2019-05-24 11:50, Paul Wise wrote:
> On Fri, 2019-05-24 at 03:14 -0700, Mo Zhou wrote:
>
>> Non-free nvidia driver is inevitable.
>> AMD GPUs and OpenCL are not sane choices.
>
> So no model which cannot be CPU-trained is suitable for Debian main.
I'
Hi PICCA,
On 2019-05-24 12:01, PICCA Frederic-Emmanuel wrote:
> What about ibm power9 with pocl ?
>
> it seems that this is better than the latest NVIDIA GPU.
The typical workload for training neural networks is linear
operations such as general matrix-matrix multiplication and
convolution.
I k
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: dataset-fashion-mnist
* URL : https://github.com/zalandoresearch/fashion-mnist
* License : MIT
Description : A MNIST-like fashion product database.
This is a part of DL-Policy[1]'s experiments.
Hi Thomas,
On 2019-05-28 07:48, Thomas Dettbarn wrote:
> Debian was quite more complicated, and the documentation on that
> topic was scattered all over the interwebs. Here I had to download
> the sources, rename the directories, rename the package, repackage,
> change some files, count the numbe
Hi,
On 2019-05-29 08:38, Raphael Hertzog wrote:
> Use the $300,000 on our bank accounts?
I totally support the idea that we should find more valuable usage
of our fund. For example, if developers don't have enough time or
don't want to do something difficult, we could hire somebody else
to fix th
Hi,
With my Debian ZoL maintainer hat + FTP trainee hat on, I didn't wish
to jump into this topic too early without a in-depth investigation...
On 2019-05-29 14:14, Sam Hartman wrote:
> And if you take the Software Freedom Conservancy (SFC)'s position
> https://sfconservancy.org/blog/2016/feb/25/
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
Hi Dan and Jonathan,
On 2019-05-28 18:49, Jonathan Carter wrote:
> On 2019/05/28 18:43, Dan wrote:
>> ZFS 0.8 has been released with lots of improvements, notably encryption.
> Yep, it's an exciting feature.
I've already uploaded ZFS 0.8 to experimental. But beware, the original
0.8.0 release has
Hi,
On 2019-06-03 14:47, Mo Zhou wrote:
> It seems that persuading the kernel team to patch the kernel
> specifically for ZFS is impossible -- that's an dead end.
I made a mistake at this point. There is no SIMD bug in zfs
0.7.12-2. The true bug lies in the stable kernel update that
b
control: severity -1 grave
Dear kernel maintainers,
Buster will be released with 4.19.37 kernel. That's fine
and it doesn't break ZFS. However, the changes introduced
in 4.19.38 and linux 5.0 break ZFS. That means the current
0.7.12-2 will fail to build everywhere after the first
Buster point rel
Hi Boyuan,
On 2019-06-06 21:44, Boyuan Yang wrote:
> I do remember there's still some source packages / binary packages in Debian
> using the bzip2 format. If we are going to do that (which looks reasonable,
> BTW), a serious archive-wide scan should be made in advance to see how great
> the impac
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 "overkilling".
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 a
1 - 100 of 262 matches
Mail list logo
