Bug#956546: ITP: json-schema-test-suite -- Language agnostic test suite for the JSON Schema specifications
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
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
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
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
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
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
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
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-
