Bug#956546: ITP: json-schema-test-suite -- Language agnostic test suite for the JSON Schema specifications

2020-04-12 Thread Adam Cecile
Package: wnpp
Severity: wishlist
Owner: Adam Cecile 

* Package name: json-schema-test-suite
  Version : 2.0.0
  Upstream Author : Julian Berman
* URL : https://github.com/json-schema-org/JSON-Schema-Test-Suite
* License : Expat
  Programming Lang: YAML
  Description : Language agnostic test suite for the JSON Schema
specifications

This package contains a set of JSON objects that implementors of JSON Schema
validation libraries can use to test their validators.
.
It is meant to be language agnostic and should require only a JSON parser.
.
The conversion of the JSON objects into tests within your test framework of
choice is still the job of the validator implementor.



Bug#956547: ITP: golang-github-harenber-ptc-go -- A driver for SCS PACTOR modems for Pat

2020-04-12 Thread Taowa Munene-Tardif
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Taowa Munene-Tardif 

* Package name: golang-github-harenber-ptc-go
  Version : 2.0.3-1
  Upstream Author :
* URL : https://github.com/harenber/ptc-go
* License : [1]
  Programming Lang: Go
  Description : A driver for SCS PACTOR modems for Pat

 ptc-go is a plug-in/driver to support PACTOR modems manufacted by SCS
 in the Pat Winlink-client (http://getpat.io/). It does this by
 communicating with the PACTOR modems using the WA8DED hostmode, 
 enabling full binary transparency.

[1] Unfortunately, I have to write to the three upstream authors to get
them to license ptc-go. I'll ask that they reply to the bug to have it
on record :).

-- 
Taowa Munene-Tardif
taowa.ca
Montréal



Re: trends.debian.net updated

2020-04-12 Thread Peter Wienemann
On 11.04.20 17:20, Mattia Rizzolo wrote:
> On Sat, Apr 11, 2020 at 11:10:48AM +0200, Wouter Verhelst wrote:
>> On Fri, Apr 03, 2020 at 10:41:55PM +0200, Lucas Nussbaum wrote:
>>> https://trends.debian.net/ was just updated (with data until April 1st).
>>
>> There is a significant bump in the number of co-maintained packages
>> during the buster release cycle. It is not at all clear to me what
>> happened there.
>>
>> Do you have any idea?
> 
> My assumption is that the deprecation of alioth lead many "team" formed
> by 1 or 2 people to be replaced by simply comaintained packages.
> That, together with the the @packages.d.o maintainer address, I reckon
> those might also be considered "comaintained" instead of "team
> maintained".

I have no good explanation to offer for the mentioned effect but you can
find the precise definition of "team-maintained" and "co-maintained" in
the description of this commit:

https://salsa.debian.org/lintian/lintian/commit/0eec0ad48fb95a00181daaa97bb60e76d77f131f

Peter



Re: trends.debian.net updated

2020-04-12 Thread Ole Streicher
Wouter Verhelst  writes:
> On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
>> Adam Borowski  writes:
>> > Idea: perhaps we could make no unrestricted (maintainer, team, or QA) 
>> > upload
>> > for 10 years a RC bug on its own?  That threshold could then be gradually
>> > reduced to eg. 5 years, as worst offenders get fixed.
>> 
>> One could deprecate old Standards-Version and require a version not that
>> was not superceded for more than five years.
>
> That's not what Standards-Version means.
>
> You don't get to say "I know my package does not comply with current
> Policy, but the Standards-Version claims an old version of Policy so
> that's fine". You must always be compliant with current policy (in
> unstable), and if policy changes in ways that apply to your package, you
> need to update it.
>
> One of my packages, logtool, hasn't seen an upstream change since the
> early naughties, and as a result there are 7 years between logtool
> 1.2.8-8 and logtool 1.2.8-9.
>
> That however didn't mean it wasn't maintained, just that it didn't need
> any update in 7 years.
>
> The only reason for Standards-Version to exist is so that when you or
> whoever comes after you look at things a few days/weeks/months/years
> down the line, you know what has changed in Policy since it was last
> touched and can use upgrading-checklist.txt

In my understanding the Standards-Version documents up to which policy
version a package was checked for compliance.

One could expect from maintainers that they check their packages for
compliance regularly and that they document that. For a package that had no
documented check for seven years it is OK to file an RC bug in order to
clarify the compliance.

Cheers

Ole



Re: trends.debian.net updated

2020-04-12 Thread Scott Kitterman



On April 12, 2020 7:11:57 PM UTC, Ole Streicher  wrote:
>Wouter Verhelst  writes:
>> On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
>>> Adam Borowski  writes:
>>> > Idea: perhaps we could make no unrestricted (maintainer, team, or
>QA) upload
>>> > for 10 years a RC bug on its own?  That threshold could then be
>gradually
>>> > reduced to eg. 5 years, as worst offenders get fixed.
>>> 
>>> One could deprecate old Standards-Version and require a version not
>that
>>> was not superceded for more than five years.
>>
>> That's not what Standards-Version means.
>>
>> You don't get to say "I know my package does not comply with current
>> Policy, but the Standards-Version claims an old version of Policy so
>> that's fine". You must always be compliant with current policy (in
>> unstable), and if policy changes in ways that apply to your package,
>you
>> need to update it.
>>
>> One of my packages, logtool, hasn't seen an upstream change since the
>> early naughties, and as a result there are 7 years between logtool
>> 1.2.8-8 and logtool 1.2.8-9.
>>
>> That however didn't mean it wasn't maintained, just that it didn't
>need
>> any update in 7 years.
>>
>> The only reason for Standards-Version to exist is so that when you or
>> whoever comes after you look at things a few days/weeks/months/years
>> down the line, you know what has changed in Policy since it was last
>> touched and can use upgrading-checklist.txt
>
>In my understanding the Standards-Version documents up to which policy
>version a package was checked for compliance.
>
>One could expect from maintainers that they check their packages for
>compliance regularly and that they document that. For a package that
>had no
>documented check for seven years it is OK to file an RC bug in order to
>clarify the compliance.
>
>Cheers
>
>Ole

'I think something might possibly be wrong, but I can't be bothered to check' 
isn't a category of 'problem' that qualifies for an RC bug.  RC bugs are for 
real problems.

Scott K



Re: length of Debian copyright files

2020-04-12 Thread Thomas Goirand
On 4/11/20 4:47 PM, Wouter Verhelst wrote:
> My point is that the machine-readable format is being "abused" to
> deep-check the copyright status of all the files, and to reject
> stuff/file bugs/... based on that.

Probably, but you're not forced into doing it. For example, if you find
that some files have different copyright holders with the same license,
it's fine to just merge both in a single paragraph, if you mention both
copyright holders. I believe you could generalize this by also merging
multiple license and copyright holders in a single paragraph.

> Yes, a machine-readable copyright format is useful for our users. It
> is, however, not useful if it is being used to inspect packages and kick
> maintainers for not doing useless busywork. It is my belief that this is
> actually happening, and therefore I don't want to do the
> machine-readable copyright format.
> 
> People who care enough about the license of a piece of software that
> they *do* need to know *all* these details can do the damn busywork
> themselves; I will not.

With what I wrote above, you don't need to go into details, but still
use a format which can be parsed by a machine.

Something like this:

Files: *
Copyright: (c) YEAR copyright holder 1
 (c) YEAR copyright holder 2
Comments: Parts of this software are released with license-1 and others
 with license-2. See individual files for details.
License: license-1-or-license-2
 License-1
 .
 foo
 .
 license-2
 .
 bar

As much as I know, writing the above is still Debian compliant, you
don't go into each file details, and everyone is happy.

If the above is wrong, please someone (from the FTP team?!?), explain me
(and everyone else) why it's legally wrong.

Cheers,

Thomas Goirand (zigo)

P.S: I personally don't do the above, and make the extra effort of
copyright holding and license attribution to each individual files.



Bug#956558: ITP: ylva -- command line password manager

2020-04-12 Thread Francisco Vilmar Cardoso Ruviaro
Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 

* Package name: ylva
  Version : 1.5
  Upstream Author : Niko Rosvall 
* URL : https://github.com/nrosvall/ylva
* License : MIT
  Programming Lang: C
  Description : command line password manager

 Password management belongs to the command line, deep into the Unix
 heartland, the shell. Ylva makes managing passwords easy and secure.
 It's a traditional command line software written in C. Ylva is very
 portable and should run fine on most Unix-like operating systems.
 Ylva is mainly developed on Linux.
 .
 Command line password manager is useful. You may choose to run it on
 a remote server to make your passwords available remotely (over SSH
 etc.). No need to sync your password database between machines.
 .
 Ylva uses OpenSSL (or LibreSSL) for encryption. For password database
 SQLite is used. Ylva encrypts the database using AES with 256 keys.
 Encrypted database is authenticated using HMAC. For key generation
 PKBDF2-SHA256 is used with 200 000 iterations.
 .
 Ylva does not stay running, so possible plain text passwords are not
 in memory except for a very short while. For example, running command
 ylva --auto-encrypt --list-all would list all the password entries,
 encrypt the database and then exit. Plain text passwords will be in
 memory only couple of seconds. This makes it very hard for malware
 to steal them.
 .
 When the database is decrypted, it's readable only by the owner
 (chmod 600). Ylva does that automatically for the database file
 so you don't have to change the permissions.



Bug#956562: ITP: ruby-rexml -- XML toolkit for Ruby

2020-04-12 Thread Daniel Leidert
Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-rexml
  Version : 3.2.4
  Upstream Author : Yukihiro Matsumoto
* URL : https://github.com/ruby/rexml
* License : BSD-2-clause
  Programming Lang: Ruby
  Description : XML toolkit for Ruby

REXML was inspired by the Electric XML library for Java, which features an
easy-to-use API, small size, and speed. Hopefully, REXML, designed with the
same philosophy, has these same features. It supports both tree and stream
document parsing. Stream parsing is faster (about 1.5 times as fast). However,
with stream parsing, one doesn't get access to features such as XPath.


The gem has been split out of Ruby's standard library and needs packaging.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl6Tn5UACgkQS80FZ8KW
0F2PzxAApIjXjZdbcM/Z5QNhV/m2fIMlg5VkhV4KdM4Hdhar2111fQ5/utGGCnkl
QgCbVtbr/TTj/ksOlwaTXAhFgzNnjcjzvfwVTwiAQPnV3MJQADLo9XQumjbA/KDu
nBwZCrQe0C6J0CkUAKF6LZBieP1qBm9M5ijLs5W/K9XHfOUidCxaCBi+xR97jHYt
9xydHIvGVvEOiZ2bTOjkP1Bo0BFaYeznQw6Vs/5VyBj8iUG80mNRj8HlisQQMhrl
BEEt8N77rQv1VCqmJEoIlLMQks3NCtmPgrTOLvYHQSaJF5nSXzHfobFXN2PMAzF3
C3AZad60xZW1imTcgYYrJkXb3j3ptDggevyxQ9obc+u+S1qd79v/uKD9cB5G6Rzm
VKqzinXGS/kNVlErBQSDPrR1hX2PbKhVu6kj9hD6glrv74vZ3bn9UpdK9U84bC7J
tmfSNWb/+6aJfIsytMwBpvQ7mQAFp8dzRg5sp+t3x37B9SDft6z8ka209XpsyL1T
cB9sAy8brGdlVlYwC47azTVdp+/hqn5DMNzrTMELAbEY2jrEjO3g4ZbxUdGnrv6B
HFD2SnafN13hWRrRZOz1BL5pQ7cNASH3ME5Omg/+tDViCHCFJtBs9RZdmssHBAbD
XV+4l6ooAQiaJQb3i2rUdn0bYoEmPJy2elTYw0b6/8SOVQzLmOo=
=PDx8
-END PGP SIGNATURE-