Re: Alternative signature mechanisms for upstream source verification

2024-10-05 Thread Marco d'Itri
On Oct 06, Otto Kekäläinen wrote: > Also some projects release tarballs with extra additions that are not > in the same git, or they strip away directories/files that are in git, I am sure that there are counterexamples, but usually they exclude things that we want to rebuild anyway, like config

Re: Alternative signature mechanisms for upstream source verification

2024-10-05 Thread Otto Kekäläinen
> No objections to have this kind of capability, but I still strongly > believe that importing tar archives is highly suboptimal and directly > branching off the upstream git repository is an highly superior workflow > and should be used as much as possible. > > This being said, I maintain some pac

Bug#1084169: ITP: libsyntax-operator-is-perl -- match operator using Data::Checks constraints

2024-10-05 Thread gregor herrmann
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libsyntax-operator-is-perl Version : 0.02 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Syntax-Operato

Bug#1084168: ITP: libdata-checks-perl -- value constraint checking module

2024-10-05 Thread gregor herrmann
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdata-checks-perl Version : 0.10 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Data-Checks * License

Bug#1084165: ITP: libsyntax-keyword-assert-perl -- assert keyword for Perl

2024-10-05 Thread gregor herrmann
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libsyntax-keyword-assert-perl Version : 0.12 Upstream Author : kobaken * URL : https://metacpan.org/release/Syntax-Keyword

Bug#1084163: ITP: golang-github-esiqveland-notify -- Go library to deliver desktop notifications over D-Bus

2024-10-05 Thread Philipp Kern
Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: golang-github-esiqveland-notify Version : 0.13.3-1 Upstream Author : Eivind Siqveland Larsen * URL : https://github.com/esiqveland/notify * License : BSD-3-clause Programming Lang: Go Desc

Bug#1084160: ITP: wego -- weather app for the terminal

2024-10-05 Thread Philipp Kern
Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: wego Version : 2.3-1 Upstream Author : Markus Teich * URL : https://github.com/schachmat/wego * License : ISC Programming Lang: Go Description : weather app for the terminal wego is

Re: signify and signify-openbsd names

2024-10-05 Thread Ben Hutchings
On Sat, 2024-10-05 at 20:15 +0200, Simon Josefsson wrote: > Ben Hutchings writes: > > > On Sat, 2024-10-05 at 12:31 +0200, Simon Josefsson wrote: > > [...] > > > This will rename the binary package to 'signify-mail', as suggested in > > > the first bug report above, and add a 'signify (<< 1.14-8~

Re: Debian policy 9.2.1 needs --allow-bad-names

2024-10-05 Thread Vincent Blut
Hi Joachim, Le 2024-10-05 17:21, Joachim Zobel a écrit : > Hi. > > Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or > dynamically generated username for packages to use, they should start > this username with an underscore." By now this requires an  > > adduser --allow-bad-n

Bug#1084153: ITP: python-ratelimit -- API rate limit decorator

2024-10-05 Thread Ananthu C V
Package: wnpp Severity: wishlist Owner: Ananthu C V X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-ratelimit Version : 2.2.1 Upstream Contact: Tomas Basham * URL : https://github.com/tomasbasham/ratelimit * License : Expat Programming Lan

Bug#1084150: ITP: libppr-perl -- Pattern-based Perl Recognizer

2024-10-05 Thread gregor herrmann
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libppr-perl Version : 0.001009 Upstream Author : Damian Conway * URL : https://metacpan.org/release/PPR * License

Re: signify and signify-openbsd names

2024-10-05 Thread Simon Josefsson
Ben Hutchings writes: > On Sat, 2024-10-05 at 12:31 +0200, Simon Josefsson wrote: > [...] >> This will rename the binary package to 'signify-mail', as suggested in >> the first bug report above, and add a 'signify (<< 1.14-8~)' Replaces >> header. >> >> Is anything more required here? > [...] >

Re: Debian policy 9.2.1 needs --allow-bad-names

2024-10-05 Thread Andrey Rakhmatullin
On Sat, Oct 05, 2024 at 05:21:10PM +0200, Joachim Zobel wrote: > Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or > dynamically generated username for packages to use, they should start > this username with an underscore." By now this requires an  > > adduser --allow-bad-names

Re: Debian policy 9.2.1 needs --allow-bad-names

2024-10-05 Thread Andreas Metzler
On 2024-10-05 Joachim Zobel wrote: > Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or > dynamically generated username for packages to use, they should start > this username with an underscore." By now this requires an  > adduser --allow-bad-names > in the script creating th

Re: signify and signify-openbsd names

2024-10-05 Thread Ben Hutchings
On Sat, 2024-10-05 at 12:31 +0200, Simon Josefsson wrote: [...] > This will rename the binary package to 'signify-mail', as suggested in > the first bug report above, and add a 'signify (<< 1.14-8~)' Replaces > header. > > Is anything more required here? [...] Yes, I think you should also rename

Debian policy 9.2.1 needs --allow-bad-names

2024-10-05 Thread Joachim Zobel
Hi. Debian policy 9.2.1 says: "When maintainers choose a new hardcoded or dynamically generated username for packages to use, they should start this username with an underscore." By now this requires an  adduser --allow-bad-names in the script creating the user. Since I followed this policy, I'l

Re: signify and signify-openbsd names

2024-10-05 Thread Marco d'Itri
On Oct 05, Simon Josefsson wrote: > I would like that 'apt install signify' install OpenBSD's signify (from > the Debian 'signify-openbsd' package) and not the 2003 mail-related > signify perl script from the Debian 'signify' source package. Agreed: the current signify package is a niche tool mai

Re: Alternative signature mechanisms for upstream source verification

2024-10-05 Thread Marco d'Itri
No objections to have this kind of capability, but I still strongly believe that importing tar archives is highly suboptimal and directly branching off the upstream git repository is an highly superior workflow and should be used as much as possible. This being said, I maintain some packages wh

Bug#1084119: ITP: golang-github-schachmat-ingo -- persistent storage for flags in go

2024-10-05 Thread Philipp Kern
Package: wnpp Severity: wishlist Owner: Philipp Kern * Package name: golang-github-schachmat-ingo Version : 0.0~git20170403.a4bdc07-1 * URL : https://github.com/schachmat/ingo * License : ISC Programming Lang: Go Description : persistent storage for flags

Re: signify and signify-openbsd names

2024-10-05 Thread Simon Josefsson
Hi I would like that 'apt install signify' install OpenBSD's signify (from the Debian 'signify-openbsd' package) and not the 2003 mail-related signify perl script from the Debian 'signify' source package. I would also like that /usr/bin/signify is OpenBSD's signify, after doing the 'apt install s

Re: Alternative signature mechanisms for upstream source verification

2024-10-05 Thread Simon Josefsson
Stefano Rivera writes: > Should we expand this to include some of these new mechanisms? > Things brought up in the debian-python thread include: > 1. sigstore https://docs.sigstore.dev/ > 2. ssh signatures > 3. signify https://man.openbsd.org/signify.1 +1 I believe all signatures we trust shoul

Re: Alternative signature mechanisms for upstream source verification

2024-10-05 Thread Martin
On 2024-10-05 03:32, Guillem Jover wrote: > For an example of the activity that is going on in the OpenPGP ecosystem, > here's a list of some of the non-GnuPG implementations already present > in Debian, by programming language: Thanks for the list! I was aware of some of them, but not all. > *