Re: Fixed release dates are hurting quality

[Gard Spreemann]

Adrian Bunk  writes:

> On Sun, Feb 07, 2021 at 05:19:17PM +0100, Gard Spreemann wrote:
>> and instead try to track positive attributes like fitness for
>> release, though?
>
> Can you provide a less lofty description of what you want to implement?

I didn't suggest that anything be implemented. I (mis-)read the parent
message as suggesting that instead of absence of bugs being sufficient
for release, we should consider instead "presence of quality"
(anti-bugs, if you will). That felt like a major paradigm shift, but I
was misunderstanding.

 -- Gard


signature.asc
Description: PGP signature

Re: Possible DEP proposal - contribution preferences

[Mattia Rizzolo]

On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
>  * Whether or not contributors can feel free to reformat
>files (e.g. wrap-and-sort -a -v).
>("allow-reformatting" in lintian-brush.conf)

On this, please also read https://bugs.debian.org/895570#13

tl;dr: I honestly believe we should just decide on a format, and
converge towards it.
It apparently works quite well for python as a whole ecosystem, where
now pretty much nobody is "against" pep8 (or even black!).  There is no
reason we can't manage to decide on a wrapping format and stick with it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Possible DEP proposal - contribution preferences

[Jonas Smedegaard]

Quoting Mattia Rizzolo (2021-02-09 18:21:46)
> On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
> >  * Whether or not contributors can feel free to reformat
> >files (e.g. wrap-and-sort -a -v).
> >("allow-reformatting" in lintian-brush.conf)
> 
> On this, please also read https://bugs.debian.org/895570#13
> 
> tl;dr: I honestly believe we should just decide on a format, and
> converge towards it.

> It apparently works quite well for python as a whole ecosystem, where 
> now pretty much nobody is "against" pep8 (or even black!).  There is 
> no reason we can't manage to decide on a wrapping format and stick 
> with it.

Heh, I am not surprised that users of the scripting language driven by 
"There should be one-- and preferably only one --obvious way to do it" 
are more comfortable than most in aligning to a single normalization.

Let's see if Debian can agree on a single normalization of 822-ish 
files.  For starters, I disagree that "wrap-and-sort -a" is a suitable 
normalization, as that will involve re-indentation when keys change.  
Instead, I propose this as starting point:

  wrap-and-sort -ast


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Possible DEP proposal - contribution preferences

[Russ Allbery]

Jonas Smedegaard  writes:

> Let's see if Debian can agree on a single normalization of 822-ish
> files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
> normalization, as that will involve re-indentation when keys change.
> Instead, I propose this as starting point:

>   wrap-and-sort -ast

I've been using wrap-and-sort -ast on all of my packages for a while, with
much the same justification.

My recollection is that the relevant Config::Model model has a slightly
different preferred normalization form?  Those are the two most common
tools used for this, I think, so if the two of them could agree, that
would go a long way towards having a common format (and this may have
already happened without me knowing).

-- 
Russ Allbery (r...@debian.org)  

Virtual Debian BSP Salzburg

[Luna Jernberg]

Hello!

Is it okay to only attend some of the BSP Event?, Noticed now in my
calendar that i was double booked on that weekend

Re: Possible DEP proposal - contribution preferences

[Mattia Rizzolo]

On Tue, Feb 09, 2021 at 10:40:39AM -0800, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> 
> > Let's see if Debian can agree on a single normalization of 822-ish
> > files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
> > normalization, as that will involve re-indentation when keys change.
> > Instead, I propose this as starting point:
> 
> >   wrap-and-sort -ast
> 
> I've been using wrap-and-sort -ast on all of my packages for a while, with
> much the same justification.

Indeed, same here :)

> My recollection is that the relevant Config::Model model has a slightly
> different preferred normalization form?  Those are the two most common
> tools used for this, I think, so if the two of them could agree, that
> would go a long way towards having a common format (and this may have
> already happened without me knowing).

That's exactly what I'm saying in the above bug.
That bug asks to change wrap-and-sort's defaults, and my answer is
saying that if the default change, we should do the same to cme.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Proposal: plocate as standard for bookworm

[Adrian Bunk]

On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:
>...
> users on
> shared systems can expect it to be available without asking an administrator
> first. To me, locate has always been a standard tool on a UNIX system, so it
> makes sense to install it by default.
>...

"Shared systems" have become pretty rare.

And there are now also many non-technical Linux users who have never
used a shell.

cu
Adrian

Re: Proposal: plocate as standard for bookworm

[Steinar H. Gunderson]

On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote:
> And there are now also many non-technical Linux users who have never
> used a shell.

Well, why do we include netcat, telnet or hdparm? lsof? pciutils?
traceroute? host? All of these are irrelevant for a non-technical
non-shell user, yet a fairly common part of a Linux installation.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Re: Virtual Debian BSP Salzburg

[Bernd Zeimetz]

On Tue, 2021-02-09 at 19:31 +0100, Luna Jernberg wrote:
> Hello!
> 
> Is it okay to only attend some of the BSP Event?, Noticed now in my
> calendar that i was double booked on that weekend 

Of course. Every single minute spent on fixing bugs is welcome :)


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Possible DEP proposal - contribution preferences

[Thomas Goirand]

On 2/9/21 6:21 PM, Mattia Rizzolo wrote:
> On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
>>  * Whether or not contributors can feel free to reformat
>>files (e.g. wrap-and-sort -a -v).
>>("allow-reformatting" in lintian-brush.conf)
> 
> On this, please also read https://bugs.debian.org/895570#13
> 
> tl;dr: I honestly believe we should just decide on a format, and
> converge towards it.
> It apparently works quite well for python as a whole ecosystem, where
> now pretty much nobody is "against" pep8 (or even black!).  There is no
> reason we can't manage to decide on a wrapping format and stick with it.

I've been flamed a few times for (ab)using wrap-and-sort in some teams,
I do believe it's not justified. Sometimes, it's up to a point one can
hardly read the dependency list...

What probably would make things a bit better, would be a lintian warning
that would compare the source package, and it's result after running
"wrap-and-sort -bastk", and then yell if there's a difference,
suggesting strongly to use wrap-and-sort.

I never wrote a lintian thing, does anyone want to implement it? It
should be super easy for anyone comfortable with Lintian, I guess... no?

Cheers,

Thomas Goirand (zigo)

Re: Possible DEP proposal - contribution preferences

[Thomas Goirand]

On 2/9/21 7:40 PM, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> 
>> Let's see if Debian can agree on a single normalization of 822-ish
>> files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
>> normalization, as that will involve re-indentation when keys change.
>> Instead, I propose this as starting point:
> 
>>   wrap-and-sort -ast
> 
> I've been using wrap-and-sort -ast on all of my packages for a while, with
> much the same justification.
> 
> My recollection is that the relevant Config::Model model has a slightly
> different preferred normalization form?  Those are the two most common
> tools used for this, I think, so if the two of them could agree, that
> would go a long way towards having a common format (and this may have
> already happened without me knowing).

For packages generating a lot of binaries, the -b option is also quite
useful, don't you think?

Cheers,

Thomas Goirand (zigo)

RE:Possible DEP proposal - contribution preferences

[PICCA Frederic-Emmanuel]

cme should not use wrap-and-sort instead of implementing its own logic ?

Re: Possible DEP proposal - contribution preferences

[Russ Allbery]

Thomas Goirand  writes:
> On 2/9/21 7:40 PM, Russ Allbery wrote:

>> I've been using wrap-and-sort -ast on all of my packages for a while, with
>> much the same justification.

>> My recollection is that the relevant Config::Model model has a slightly
>> different preferred normalization form?  Those are the two most common
>> tools used for this, I think, so if the two of them could agree, that
>> would go a long way towards having a common format (and this may have
>> already happened without me knowing).

> For packages generating a lot of binaries, the -b option is also quite
> useful, don't you think?

I'd support that.  I only recently became aware of it.

-- 
Russ Allbery (r...@debian.org)  

Re: Proposal: plocate as standard for bookworm

[Russ Allbery]

Adrian Bunk  writes:
> On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:
>>...
>> users on
>> shared systems can expect it to be available without asking an administrator
>> first. To me, locate has always been a standard tool on a UNIX system, so it
>> makes sense to install it by default.
>>...

> "Shared systems" have become pretty rare.

They've become *rarer*, but they're still very common in the academic and
scientific research world.

-- 
Russ Allbery (r...@debian.org)  

Re: Proposal: plocate as standard for bookworm

[Marvin Renich]

* Steinar H. Gunderson  [210209 14:27]:
> On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote:
> > And there are now also many non-technical Linux users who have never
> > used a shell.
> 
> Well, why do we include netcat, telnet or hdparm? lsof? pciutils?
> traceroute? host? All of these are irrelevant for a non-technical
> non-shell user, yet a fairly common part of a Linux installation.

These have come to be expected to be on a typical Linux system by almost
every technically-knowledgeable Linux user.  Locate does not satisfy
that criterion, and I think the dissension in this thread is evidence of
that.  Most of the ones you mention above might be necessary when trying
to fix a broken system.  Locate might save a little time, but find,
which is standard, will suffice for that purpose.

I just tried plocate, and it certainly looks faster to update than
mlocate.  Thanks for packaging this!  I've just removed mlocate.

However, I agree with others here that anyone who wants a locate
implementation will know how to find all the packages with "locate" in
their names and plocate looks to me, from the descriptions, to be the
best choice.  I don't think it deserves "Priority: standard".

...Marvin

Re: Proposal: plocate as standard for bookworm

[Ansgar]

"Steinar H. Gunderson" writes:
> On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
>> Furthermore, any mechanism they use to configure one of them
>> (e.g. for privacy or performance reasons) will not control the other,
>> and again they may well be unaware of the existence of the other one.
>
> I'm not sure what privacy reasons you're referring to? I'm not aware that
> neither mlocate/plocate nor e.g. tracker will leak data across users.

If you have an encrypted /home (or /home/), but unencrypted
/var/lib/plocate, you leak information about the encrypted files.

File indexing services run as a user would at least write only to
/home/ which would be encrypted.

Admittedly Debian's other defaults like making every file in $HOME
world-readable by default are very unfriendly too on both multi-user
systems (obviously) and single-user systems where suddenly even the
"nobody" user has access to lots of interesting files...

Ansgar

Re: Possible DEP proposal - contribution preferences

[Jonas Smedegaard]

Quoting Thomas Goirand (2021-02-09 20:48:12)
> On 2/9/21 6:21 PM, Mattia Rizzolo wrote:
> > On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
> >>  * Whether or not contributors can feel free to reformat
> >>files (e.g. wrap-and-sort -a -v).
> >>("allow-reformatting" in lintian-brush.conf)
> > 
> > On this, please also read https://bugs.debian.org/895570#13
> > 
> > tl;dr: I honestly believe we should just decide on a format, and
> > converge towards it.
> > It apparently works quite well for python as a whole ecosystem, where
> > now pretty much nobody is "against" pep8 (or even black!).  There is no
> > reason we can't manage to decide on a wrapping format and stick with it.
> 
> I've been flamed a few times for (ab)using wrap-and-sort in some teams,
> I do believe it's not justified. Sometimes, it's up to a point one can
> hardly read the dependency list...

Tools like wrap-and-sort are certainly a no-go for NMUs!

Yes, it is harder for me to read packages not maintained in _my_ style, 
but really I have *no* say on styling when only a quest making changes 
to a package maintained by someone else.

If a package is too hard for me to help edit, then that is a reason so 
not NMU that package, not a reason to re-style the package!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Possible DEP proposal - contribution preferences

[Jelmer Vernooij]

On Mon, Feb 08, 2021 at 10:29:13PM +0100, Raphael Hertzog wrote:
> On Tue, 02 Feb 2021, Jelmer Vernooij wrote:
> > One of the things that I've been wondering about is whether it would make
> > sense to have a configuration file in Debian packages that allows
> > maintainers to specify preferences for contributions. At the
> > moment, this is not a well-formed proposal yet - but I'm curious as to
> > your thoughts.
> 
> I must say that we keep adding layers of complexity and this would
> just extend the amount of things that one should know about packaging.
> 
> We need more consistency and not more choices. But in the end, those
> choices are differences that do already exist in practice.
> 
> In the grand scheme of things, we should have a Debian-wide
> recommended way of handling packages and this configuration file
> would only be needed when a maintainer really wants to deviate from
> this recommended way.
> 
> The DEP we need is the one that defines this default way of handling
> packages and contributions, and the file you want would only be a
> by-product of this.

On Tue, Feb 09, 2021 at 06:21:46PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
> >  * Whether or not contributors can feel free to reformat
> >files (e.g. wrap-and-sort -a -v).
> >("allow-reformatting" in lintian-brush.conf)
> 
> On this, please also read https://bugs.debian.org/895570#13
> 
> tl;dr: I honestly believe we should just decide on a format, and
> converge towards it.
> It apparently works quite well for python as a whole ecosystem, where
> now pretty much nobody is "against" pep8 (or even black!).  There is no
> reason we can't manage to decide on a wrapping format and stick with it.

The argument you're both making is that we should have a single sensible
standard and then provide a way for those packages that currently
diverge (and possibly want to diverge in the future?) for specifying
so. That makes a lot of sense, and it would mean that:

* the cost of adding this file is only borne by those who diverge from
  the standard
* requiring per-package files is less costly - larger teams could
  (should?) just stick to the standard - and there is less need to
  support a complicated per-team configuration

That addresses the main concerns I raised in my original message.

Using heuristics to figure out the style for a package is somewhat at
odds with defining defaults in the absence of explicit configuration.

However, in the absence of explicit configuration we can still use
heuristics to determine that the explicit configuration or standards
are blatantly not being followed by the package and acting
appropriately. This could result in:

 1) not reformatting according to the selected style, i.e.
making changes but not reformatting, if supported by the tool
 2) formatting according to whatever other style is being followed
(and detected)[1]
 3) simply refusing to make any changes until the user reformats using
the (explicit or default) configured style

I don't think this needs to be explicitly mandated in the DEP, but it
would be relevant for any actual implementations of the DEP for the
reasons mentioned by Jonas in
https://lists.debian.org/debian-devel/2021/02/msg00138.html

On Mon, Feb 08, 2021 at 10:29:13PM +0100, Raphael Hertzog wrote:
> On Tue, 02 Feb 2021, Jelmer Vernooij wrote:
> >  * Generally speaking, the preferences would be the same for
> >all packages maintained by a specific team/person. Having to copy
> >these preferences into every git repository in a set (e.g.
> >perl-team) seems tedious and unnecessarily repetitive. Maybe this
> >should live in a separate database somewhere, or perhaps it can be
> >specified in salsa somehow on a per-team basis?
> Somehow this ship has sailed, plenty of teams do commit debian/gbp.conf
> and debian/salsa-ci.yml in all their repositories. At least the GitLab CI
> has an URL include mechanism that makes it possible to create a team-wide
> configuration and include it.
Agreed that it's a common practice to have the same files duplicated
for all of the packages maintained by a specific team, but it still
doesn't seem ideal...

Since this is a common practice for other control files that would
benefit from per-team configuration, perhaps that's a problem that
should be solved separately for all of these files rather than
as part of this DEP.

> >  * Should this really be a separate file, or could it be folded
> >in elsewhere?
> I don't know of anything else but if we create a new file, I'd rather have
> it in debian/source/ rather than right below debian.
+1.

What about one of:

* debian/source/style
* debian/source/preferences
* debian/source/contrib

Once these standards are defined and diverge can be specified, lintian
could also check for packages confirming to the standards.

Some of the things to standardize:

 * a canonical style for debian control files and .dirs, .docs,
   .exam

Bug#982417: ITP: python-louvain-igraph -- Louvain is an algorithm for methods of community detection

[Diane Trout]

Package: wnpp
Severity: wishlist
Owner: Diane Trout 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-louvain-igraph
  Version : 0.7.0
  Upstream Author : V.A. Tragg 
* URL : https://github.com/vtraag/louvain-igraph
* License : GPL-3+
  Programming Lang: (Python
  Description : Louvain is an algorithm for methods of community detection

 Louvain is a general algorithm for methods of community detection in
 large networks.
 .
 This provides a python module named 'louvain'.

This is the version of louvain used by ScanPy
https://scanpy.readthedocs.io/en/stable/

It's also based on igraph and not networkx like the other louvain
implementation python-louvain.

It should probably live in the Debian med team.

Re: Proposal: plocate as standard for bookworm

[Paul Wise]

On Tue, Feb 9, 2021 at 9:12 PM Ansgar wrote:

> Admittedly Debian's other defaults like making every file in $HOME
> world-readable by default are very unfriendly too on both multi-user
> systems (obviously) and single-user systems where suddenly even the
> "nobody" user has access to lots of interesting files...

Ubuntu are changing this, perhaps Debian should too for bookworm:

https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Debian-wide firmware prober

[積丹尼 Dan Jacobson]

Hey everybody,
wouldn't it be nice if there was a prober,
like lshw,
that probed all the firmware one needed?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982402
It would say:
"
 You need the following Debian firmware packages
 firmware-X
 firmware-Y
 firmware-Z
 Remember, a proper system needs proper firmware.
 Not too much, but also not too little.
"

Re: Debian-wide firmware prober

[Zlatan]

There is isenkram-cli which can detect and autoinstall the needed firmware.

Z

On February 10, 2021 3:11:29 AM GMT+01:00, "積丹尼 Dan Jacobson" 
 wrote:
>Hey everybody,
>wouldn't it be nice if there was a prober,
>like lshw,
>that probed all the firmware one needed?
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982402
>It would say:
>"
> You need the following Debian firmware packages
> firmware-X
> firmware-Y
> firmware-Z
> Remember, a proper system needs proper firmware.
> Not too much, but also not too little.
>"

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Proposal: plocate as standard for bookworm

[Andrey Rahmatullin]

On Tue, Feb 09, 2021 at 03:58:39PM -0500, Marvin Renich wrote:
> These have come to be expected to be on a typical Linux system by almost
> every technically-knowledgeable Linux user.  Locate does not satisfy
> that criterion
(I'm surprised by this, if this is true)

-- 
WBR, wRAR


signature.asc
Description: PGP signature