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,
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
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
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
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 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
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
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,
> 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
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
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
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
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
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,
> >
>
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
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
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
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
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
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
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
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: 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
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
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.
>
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 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 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 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,
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,
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...
>
>
") 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
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.
&
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
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: 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 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: 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
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
100, 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-interf
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 interf
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)
> >
> >
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
Hi Damir,
On Mon, Oct 22, 2018 at 10:36:12AM +, Damir Porobic wrote:
> I was not sure to which Mailing list my question belongs so I'm writing here,
> if I should use a different list, let me know.
According to the content of your mail I think debian-u...@lists.debian.org
is a more proper pl
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 th
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org
Owner: Mo Zhou
* Package name: blis
Version : 0.4.1
Upstream Author : The University of Texas at Austin, HP Enterprise, AMD Inc.
* URL : https://github.com/flame/blis
* License
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 p
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: vim-julia
Version : 0.0~git20180821.120a0b6
Upstream Author : Carlo Baldassi and other contributors
* URL : https://github.com/JuliaEditorSupport/julia-vim
* License : Expat
Programming Lang
Package: wnpp
Severity: normal
I request assistance with maintaining the julia package.
Specifically I need a ppc64el porter (or anyone who has root access to
a ppc64el box) to help me:
1. Apply patch[1] to Debian's llvm-toolchain-6.0 (= 1:6.0.1-4) and build it.
2. Install the resulting llvm-6
Hi folks,
(Keep me in CC list please)
I'm working on some packages whose upstream (github)
doesn't make releases. So I need to invent upstream
versions, that's OK. However when one is going to
maintain a number of packages that watch is not present,
upstream update tracking by hand would be a nig
201 - 250 of 250 matches
Mail list logo
