Re: Bug#995722: Not running tests because tests miss source code is not useful

On Sat, 2021-10-09 at 18:52 +0200, Jonas Smedegaard wrote: > It is not source code. > > It is not binary code. > > It is not... > > The appropriate question is how it fits Debian Free Software > Guidelines. Programs with a license on the one hand which demands the right to study and modify the

Bug#996021: ITP: cvelib -- library and a command line interface for the CVE Services API

Package: wnpp Owner: Salvatore Bonaccorso Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: cvelib Version : 0.4.0 Upstream Author : Red Hat Security Response Team * URL : https://github.com/RedHatProductSecurity/cvelib * License :

Re: Bug#995722: Not running tests because tests miss source code is not useful

Hi Le sam. 9 oct. 2021 à 18:52, Jonas Smedegaard a écrit : > Quoting Julien Puydt (2021-10-09 18:48:07) > > Hi > > > > Le sam. 9 oct. 2021 à 17:40, Jeremy Stanley a écrit > : > > > > > On 2021-10-09 08:53:57 +0200 (+0200), Yadd wrote: > > > [...] > > > > If you really consider minified files as

Re: Bug#995722: Not running tests because tests miss source code is not useful

Quoting Stephan Verbücheln (2021-10-10 14:03:51) > On Sat, 2021-10-09 at 18:52 +0200, Jonas Smedegaard wrote: > > It is not source code. > > > > It is not binary code. > > > > It is not... > > > > The appropriate question is how it fits Debian Free Software > > Guidelines. > > Programs with a l

Re: Bug#995722: Not running tests because tests miss source code is not useful

Quoting Julien Puydt (2021-10-10 14:34:34) > Le sam. 9 oct. 2021 à 18:52, Jonas Smedegaard a écrit : > > Quoting Julien Puydt (2021-10-09 18:48:07) > > > Le sam. 9 oct. 2021 à 17:40, Jeremy Stanley a > > > écrit > > > > On 2021-10-09 08:53:57 +0200 (+0200), Yadd wrote: [...] > > > > > If you rea

Re: Bug#995722: Not running tests because tests miss source code is not useful

Julien Puydt writes: > There was the case years ago of the smarteiffel compiler. It was supposed > to be open source, but upstream only released C code. And that was bad, > because it wasn't what *they* worked with: they had eiffel sources, and the > C code was preprocessed and didn't allow/permi

Bug#996053: ITP: grate -- SQL scripts migration runner

Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Introducing grate = I have created a database migration tool, named grate. It is in active development, and written in .NET 6. It is compiled as a static binary, independent of any installation of .NET framew

Bug#996087: ITP: typeshed -- collection of library stubs for Python, with static types

Package: wnpp Severity: wishlist Owner: Antonio Terceiro X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: typeshed Version : n/a Upstream Author : Several authors * URL : https://github.com/python/typeshed * License :

Bug#996088: ITP: r-cran-mpoly -- symbolic computing with multivariate polynomials in R

Package: wnpp Severity: wishlist Owner: Doug Torrance X-Debbugs-Cc: debian-devel@lists.debian.org, dtorra...@piedmont.edu, * Package name: r-cran-mpoly Version : 1.1.1 Upstream Author : David Kahle * URL : https://github.com/dkahle/mpoly * License : GPL Progra

Question about source tarballs for packaging

Hello everyone, I'm packaging the V programming language for Debian. However, V is bit weird at the moment. It's not really ready for stable production/use. so for a while it will live in experimental. Currently the way building it works is that there is a repo that is the compiler translated

Re: Question about source tarballs for packaging

On Sun, Oct 10, 2021 at 09:40:54PM +, Joshua Peisach wrote: > This doesn't really matter; the above means that we will have to build > on weekly tags rather than the current '0.2.4' tag. Here is the issue. > uscan and gbp aren't happy with the tag because by all means, it isn't a > number. Not