Re: Reconsider sending ITP bugs to debian-devel: a new list?

Thomas Goirand writes: > On 6/12/21 1:06 PM, Marc Haber wrote: >> On Sat, 12 Jun 2021 01:04:21 +0300, Nicholas Guriev >> wrote: >>> For the record, the latest digest of the debian-devel@ list #194 >>> consists of 17 emails. 13 of them are ITP forwards, the remaining 4 >>> emails are about ITP fo

Re: What are desired semantics for /etc/shells?

Hi! On Thu, 2021-06-10 at 20:00:02 +0200, Helmut Grohne wrote: > Due to working on installation bootstrap, I was looking into > `/etc/shells`. > > Introduction > > > `/etc/shells` contains valid login shells. Some programs match the configured > shell of a user against this file to

Bug#989877: ITP: golang-github-jpillora-go-tld -- Top Level Domain (TLD) Parser

Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro X-Debbugs-Cc: debian-devel@lists.debian.org, francisco.ruvi...@riseup.net * Package name: golang-github-jpillora-go-tld Version : 1.1.1 Upstream Author : Jaime Pillora

Re: Kernel building question (Is -j8 safe and correct?)

On Sun, 2021-06-13 at 15:07 +0200, Philipp Hahn wrote: [...] > > 3. If both of the above are true, why isn't something like that suggested > > on [1]? > > Debian does not know your specifics and thus does not use parallel build > by default. > Debian *does* use parallel builds by default. But

Re: What are desired semantics for /etc/shells?

On Mon, Jun 14, 2021 at 02:50:29PM -0600, Sam Hartman wrote: > As an admin, I expect to be able to install a shell, say because I want > to write scripts in it, without allowing users to select it as a login > shell. > I expect installing a shell, and remove-shelling that shell to work for > this p

Re: Kernel building question (Is -j8 safe and correct?)

On Fri, 2021-06-11 at 19:34 -0600, Antonio Russo wrote: > Hello, > > I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's > irrelevant). > I'm following [1], and the critical command > > $ fakeroot make -f debian/rules.gen binary-arch_i386_none_real > > does not suggest

Re: Unique kernel with my own backup of all Debian repositories

On Mon, Jun 14, 2021 at 12:36:30PM -0400, Polyna-Maude Racicot-Summerside wrote: > I only repeated in a different way what was already explained (fair use > for servers not meant to be sucked up). My point was not about the technical content of your message, but the phrasing, that had started to a

Re: What are desired semantics for /etc/shells?

> "Helmut" == Helmut Grohne writes: Helmut> Hi, Due to working on installation bootstrap, I was looking Helmut> This raises the question of what the desired semantics for Helmut> `/etc/shells` are. Do we want the strict interpretation of Helmut> the policy to be followed and

Bug#989859: ITP: golang-github-weppos-publicsuffix-go -- Domain name parser for Go based on the Public Suffix List.

Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-weppos-publicsuffix-go Version : 0.15.0-1 Upstream Author : Simone Carletti * URL : https://github.com/weppos/publicsuffix-go * License : Expat Programming Lang: Go Descrip

Bug#989858: ITP: golang-github-smallstep-zcrypto -- Liberal Go TLS + X.509 Library for Research

Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-smallstep-zcrypto Version : 0.0~git20200203.fbc32cf-1 Upstream Author : Smallstep * URL : https://github.com/smallstep/zcrypto * License : ISC and Apache 2.0 Programming Lang

Bug#989857: ITP: step-cli -- toolkit for working with public key infrastructure

Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: step-cli Version : 0.15.16 Upstream Author : Smallstep * URL : https://github.com/smallstep/cli * License : Apache 2.0 Programming Lang: Go Description : toolkit for working with pu

Re: What are desired semantics for /etc/shells?

On 6/14/21 7:39 AM, Helmut Grohne wrote: At this time, my personal preference would be turning /etc/shells into a symbolic link to an autogenerated file. Is there a harm in /etc/shells containing shells that are not installed on the system? If not, then we could ship a single /etc/shells in b

Re: Unique kernel with my own backup of all Debian repositories

On 2021-06-14 12:55 p.m., Marc Haber wrote: > On Mon, 14 Jun 2021 07:23:45 -0700, John E Petersen > wrote: >> Thanks Paul, but I'm having a hard time finding the precise version I would >> like to archive on any ftp mirror. My scrape is actually working quite >> correctly now, though, since I ad

Re: Reconsider sending ITP bugs to debian-devel: a new list?

On Mon, 14 Jun 2021 16:01:32 +, Jeremy Stanley wrote: >If these were aggregated into a digest, fitting the names of all the >relevant software into the subject would be unlikely a lot of the >time. As such, list subscribers are far less likely to spot one for >software they might care about.

Re: Unique kernel with my own backup of all Debian repositories

On Mon, 14 Jun 2021 07:23:45 -0700, John E Petersen wrote: >Thanks Paul, but I'm having a hard time finding the precise version I would >like to archive on any ftp mirror. My scrape is actually working quite >correctly now, though, since I added a sleep in there -- the source and >machine-installa

Re: What are desired semantics for /etc/shells?

Hello, I have no personal stake either, the same as the others who already replied, but I guess I'll chime in as well. On Mon, Jun 14, 2021 at 02:39:30PM +0200, Helmut Grohne wrote: > > I think using triggers has an obvious benefit here, but depending in the > > intended semantics of `/etc/shells

Re: Unique kernel with my own backup of all Debian repositories

Hi, On 2021-06-14 8:13 a.m., Jonathan Dowland wrote: > On Sat, Jun 12, 2021 at 04:47:26PM -0400, Polyna-Maude Racicot-Summerside > wrote: >> This is why your address is being blocked and will continue to do so. > > Writing something like this runs the risk of giving the impression that > you are

Re: Reconsider sending ITP bugs to debian-devel: a new list?

On Mon, Jun 14, 2021 at 04:22:31PM +0200, Stephan Lachnit wrote: > On Fri, Jun 11, 2021 at 4:26 PM Steve McIntyre wrote: > > > > To be honest, I think if we did that we'd lose just about all the > > reviews that currently happen. The whole point of sending ITPs to > > d-devel is that they will be s

Re: Reconsider sending ITP bugs to debian-devel: a new list?

On 2021-06-14 16:22:31 +0200 (+0200), Stephan Lachnit wrote: [...] > How about sending a digest of a potential debian-itp to d-d on a > weekly basis? I think we wouldn't lose any reviews with this, I > would even go as far and claim that there will be more reviews, > since it's less of an "annoyanc

Re: Unique kernel with my own backup of all Debian repositories

Thanks Paul, but I'm having a hard time finding the precise version I would like to archive on any ftp mirror. My scrape is actually working quite correctly now, though, since I added a sleep in there -- the source and machine-installation instructions are tidily tucked away in different directorie

Re: Reconsider sending ITP bugs to debian-devel: a new list?

On Fri, Jun 11, 2021 at 4:26 PM Steve McIntyre wrote: > > Jon Dowland wrote: > > > >I think the ITP mails can make reading the rest of the list difficult > >without extra local filtering or steps. Some times they are the > >majority of the list traffic. I think it would be better if > >ITP mail w

Bug#989835: ITP: r-cran-orthopolynom -- functions for orthogonal and orthonormal 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-orthopolynom Version : 1.0.5 Upstream Author : Frederick Novomestky * URL : https://cran.r-project.org/package=orthopolynom

Re: What are desired semantics for /etc/shells?

Hi, On Thu, Jun 10, 2021 at 08:00:02PM +0200, Helmut Grohne wrote: > Desired behaviour > = > > This raises the question of what the desired semantics for `/etc/shells` are. > Do we want the strict interpretation of the policy to be followed and update > all those packages to condi

Re: Reconsider sending ITP bugs to debian-devel: a new list?

On Fri, Jun 11, 2021 at 11:05:02AM -0500, Gunnar Wolf wrote: > I concur with Steve. Often, I decide to ignore ITPs, or get annoyed or > overwhelmed when very prolific teams (hi nodejs!) announce and set to > package hundreds of packages I won't have any interest on. Yeah; I often ignore ITPs too.

Re: Reconsider sending ITP bugs to debian-devel: a new list?

On Fri, Jun 11, 2021 at 12:28:33PM +0200, Jonathan Carter wrote: > Wouldn't it just be far simpler for those who wish not to receive the > ITPs to filter them out to a subfolder of debian-devel or discard them? Others have covered the specifics of NNTP here; and at least one person has re-iterated

Re: Unique kernel with my own backup of all Debian repositories

On Sat, Jun 12, 2021 at 04:47:26PM -0400, Polyna-Maude Racicot-Summerside wrote: > This is why your address is being blocked and will continue to do so. Writing something like this runs the risk of giving the impression that you are somehow involved in, or authoritative for, the official Debian mi

-1: (was Re: Reconsider sending ITP bugs to debian-devel: a new list?)

On Fri, Jun 11, 2021 at 01:45:20PM +, Steve McIntyre wrote: > To be honest, I think if we did that we'd lose just about all the > reviews that currently happen. The whole point of sending ITPs to > d-devel is that they will be seen by a wider audience, but I can't see > many signing up for YA m

Re: What are desired semantics for /etc/shells?

On Sun, Jun 13, 2021 at 12:06:43PM +0200, Marco d'Itri wrote: > On Jun 10, Helmut Grohne wrote: > > This raises the question of what the desired semantics for `/etc/shells` > > are. > > Do we want the strict interpretation of the policy to be followed and update > > all those packages to conditio