Re: New Essential package procps-base

[Andreas Henriksson]

Hello,

On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote:
> Hello,
>   For quite some time (since 2006!) there has been a discussion at[1] about
> changing from the sysvinit-utils version of pidof to the procps one. A
> quick scan of the various distributions shows that only Debian and Ubuntu
> (and I assume most other downstreams) use the sysvinit-utils version.

I support using procps implementation in Debian, to align us with the
rest of the world.

> 
> So to rehash some old drafts, here's the proposal.
> 
> What:
> Create a new package procps-base. This uses the existing procps source
> package and just enable building of pidof. procps-base will be an Essential
> package and only contain pidof.

I however do not think pidof needs to be part of the Essential set.

Instead I think pidof can just be part of procps package. The
sysvinit-utils package will then pull in procps via a dependency (once
sysvinit-utils stops being Essential), which would smooth the transition
for all sysvinit users until LSB pidofproc has been implemented in all
init scripts.

> 
> Why:
> This would bring the pidof variant in line with other distributions.
> sysvinit-utils would no longer need to be Essential (though that's a
> separate issue) and would only have init-d-script, fstab-decode, and
> killall5.
> 
> The majority of usage of pidof is in init or pre/post scripts, which really
> should be using the LSB pidofproc function. That function in turn
> optionally uses pidof if the pidfile parameter is not given. That's
> probably a way forward for sometime in the future to not need procps-base
> Essential, but it is a way off.

Additionally most uses of pidof is `if pidof [...]; then` which will
expand to false/else when the pidof command is not available (which it
should be on all "normal" systems, as procps is already Priority
important).

A number of years ago I tested booting a regular debootstrapped system
(with all priority important packages, etc) with sysvinit-utils excluded
and that did not show a single warning about missing pidof. Someone
might want to repeat that experiment.

> 
> sysvinit-utils requires only libc6 while procps-base require libproc-2 but
> this is the same library used for the ps,top,w etc tools which are
> installed on most systems.
> 
> 
> 1: https://bugs.debian.org/810018


Regards,
Andreas Henriksson

Re: New Essential package procps-base

[Simon Richter]

Hi,

On 11/14/23 18:42, Andreas Henriksson wrote:


Instead I think pidof can just be part of procps package. The
sysvinit-utils package will then pull in procps via a dependency (once
sysvinit-utils stops being Essential), which would smooth the transition
for all sysvinit users until LSB pidofproc has been implemented in all
init scripts.


Makes sense, but this effectively means that "pidof" is no longer in the 
essential set unless you are using sysvinit.


This will need to be communicated to Devuan at least (because they also 
support runit and openrc, and I believe neither pulls in sysvinit-utils 
explicitly, relying on its Essential status.


We should also check systemd units for pidof invocations.


A number of years ago I tested booting a regular debootstrapped system
(with all priority important packages, etc) with sysvinit-utils excluded
and that did not show a single warning about missing pidof. Someone
might want to repeat that experiment.


This check should probably use a dummy "pidof" on the path, I'd expect a 
lot of people use "if pidof x >/dev/null 2>&1" because of muscle memory, 
when they should not be redirecting stderr.


   Simon

Re: New Essential package procps-base

[Helmut Grohne]

Hi Craig,

On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote:
> Hello,
>   For quite some time (since 2006!) there has been a discussion at[1] about
> changing from the sysvinit-utils version of pidof to the procps one. A
> quick scan of the various distributions shows that only Debian and Ubuntu
> (and I assume most other downstreams) use the sysvinit-utils version.
> 
> So to rehash some old drafts, here's the proposal.
> 
> What:
> Create a new package procps-base. This uses the existing procps source
> package and just enable building of pidof. procps-base will be an Essential
> package and only contain pidof.

I welcome the effort in general. Like Andreas, I question whether having
pidof remain essential is useful. A quick codesearch
https://codesearch.debian.net/search?q=%5Cbpidof%5Cb&literal=0 suggests
that we have less than 500 source packages that even mention it. Many
uses are in test suites or documentation, so the final number will be
lower still.

If we agree that pidof should not be essential, the next question is
whether we need that procps vs procps-base split. Andreas suggests "no".
I don't have a strong opinion on that one.

Let me suggest an alternative transition plan. We extend sysvinit-utils
with a new virtual package "pidof". Then we MBF packages using pidof to
add a dependency on pidof. Once a significant portion of those bugs is
fixed, we move pidof out of sysvinit-utils and have it drop that virtual
package. procps or procps-base can then add pidof (with Breaks+Replaces
for sysvinit-utils and Provides: pidof) moving it out of the essential
set in the process. Any remaining bugs would be bumped to rc-severity at
that point.

> Why:
> This would bring the pidof variant in line with other distributions.
> sysvinit-utils would no longer need to be Essential (though that's a
> separate issue) and would only have init-d-script, fstab-decode, and
> killall5.

I fear sysvinit-utils being essential is not separate (see below). It
really needs to be done together, so additionally there would have to be
another MBF for those other tools asking to add dependencies.

> The majority of usage of pidof is in init or pre/post scripts, which really
> should be using the LSB pidofproc function. That function in turn
> optionally uses pidof if the pidfile parameter is not given. That's
> probably a way forward for sometime in the future to not need procps-base
> Essential, but it is a way off.

For as long as sysvinit-utils contains /lib/lsb/init-functions, it'll
have to include pidof or depend on it. Therefore the pidof provider can
only become non-essential once sysvinit-utils is non-essential. If you
see the change in implementation as more urgent than making all of it
non-essential, then procps-base is needed indeed.

> sysvinit-utils requires only libc6 while procps-base require libproc-2 but
> this is the same library used for the ps,top,w etc tools which are
> installed on most systems.

Yeah, please don't increase the essential set. The addition would be
very unwelcome to embedded systems.

So in essence, you asked for changing the pidof implementation and
Andreas and me try to turn this into a much bigger quest of making it
non-essential. While these matters are related, they can be done
independently in principle and if you do not want to take on the
non-essential part, I fear I see little alternatives to that procps-base
proposal.

Pulling procps-base into the essential set also adds it to the bootstrap
set. That also adds numactl to the bootstrap set. I'd rather not have it
grown if possible. Both are currently cross buildable, so it's not the
end of the world.

Helmut

Re: New Essential package procps-base

[Luca Boccassi]

On Tue, 14 Nov 2023 at 10:13, Helmut Grohne  wrote:
> So in essence, you asked for changing the pidof implementation and
> Andreas and me try to turn this into a much bigger quest of making it
> non-essential. While these matters are related, they can be done
> independently in principle and if you do not want to take on the
> non-essential part, I fear I see little alternatives to that procps-base
> proposal.

Yeah, let's not make this task impossibly huge and lengthy, please.
Using the same implementation as every other distro has immediate
benefits for everybody, packagers and users. Rearranging the packaging
details and priorities and whatnot is pretty much an internal-only
detail - which doesn't mean it's not good or useful or worth doing,
just that I don't think it's worth blocking the first part for it, as
it can happen just as well later. The procps-base proposal looks good
to me.

Re: New Essential package procps-base

[Gioele Barabucci]

On 14/11/23 11:11, Helmut Grohne wrote:

I welcome the effort in general. Like Andreas, I question whether having
pidof remain essential is useful. A quick codesearch
https://codesearch.debian.net/search?q=%5Cbpidof%5Cb&literal=0 suggests
that we have less than 500 source packages that even mention it. Many
uses are in test suites or documentation, so the final number will be
lower still.


Last year Andreas and I had a quick look at what it would take to remove 
all pidof instances from maintscripts. In a couple of days we fixed a 
dozen packages.


This is our progress log: .

In short, there are only 23 packages whose maintscripts assume the 
presence of pidof and that need to be fixed.


Regards,

--
Gioele Barabucci

Bug#1055930: ITP: yte -- YAML template engine with Python expressions

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: yte
  Version : 1.5.1
  Upstream Author : Johannes K��ster 
* URL : https://github.com/yte-template-engine/yte
* License : Expat
  Programming Lang: Python
  Description : YAML template engine with Python expressions

Binary package names: python3-yte
 YTE is a template engine for YAML format that utilizes the YAML structure
 in combination with Python expressions for enabling to dynamically build
 YAML documents.
 .
 The key idea of YTE is to rely on the YAML structure to enable conditionals,
 loops and other arbitrary Python expressions to dynamically render YAML
 files. Python expressions are thereby declared by prepending them with a ?
 anywhere in the YAML. Any such value will be automatically evaluated by YTE,
 yielding plain YAML as a result. Importantly, YTE templates are still valid
 YAML files (for YAML, the ? expressions are just strings).

Bug#1055943: ITP: asahi-audio -- PipeWire DSP profiles for Apple Silicon machines

[Tobias Heider]

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

* Package name: asahi-audio
  Version : 0.5
  Upstream Authors: The Asahi Linux Contributors
  URL : https://github.com/AsahiLinux/asahi-audio
* License : MIT
  Description : PipeWire DSP profiles for Apple Silicon machines

PipeWire and WirePlumber DSP profiles and configurations to
drive the speaker arrays in Apple Silicon laptops and desktops.

I hope to maintain this package as part in the bananas-team.

See also:
https://wiki.debian.org/Teams/Bananas

- Tobias

Bug#1055954: ITP: controku -- Control Roku devices from the comfort of your own desktop

[Ben Westover]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: controku
  Version : 1.1.0
  Upstream Contact: Ben Westover 
* URL : https://github.com/benthetechguy/controku
* License : GPL-3
  Programming Lang: Python
  Description : Control Roku devices from the comfort of your own desktop

Controku is a library and GTK3 application that allows you to control
Roku devices from the comfort of your own desktop.

I am the developer of this program. I find it very useful, and it would
be nice to have in Debian. I plan to maintain it inside of the Python
team. I will need a sponsor for the initial upload, as I am only a DM.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEOGnacqRhdU6eNmtFwxHF9U6JtpgFAmVTr6kACgkQwxHF9U6J
tphZVxAAps/BL8t83IiPaA5EoTlx5SlIs1me9g266vzAVaootjg5vJ5uUa86snA1
efdCdKfBvNgXyECQxM1yK0TFp4utM0yRAYg1f4JfZ2pZBI2/cyNenlUizvD3Qdp7
jSzHpdBHpEv0O+yzhU9F6PhO+jfUBRubKMjFheUU/8n1VWYNnGdbLvH4hIIO2pEi
aNtlqX95BA2jxNwpJldkMYqIxKKrY1pnu8iXaOGZ6gen8Ru6e1hQ4RxmHva5odh3
5ws6rwLsAW+Butlsa4dRWfS5+tpzbjsf780bvu2oI1Anqrp04CaiKyvGlIV2V0TA
QLk6vFLVT8Y0TZHuTJxYmUHBYt+gZ9TVIj/hIkQZLCRpWRXEj2SKAPe8t2ZimcXU
Zbes0u8QdakmMT52swvL1Wv8AOd+Xfi4DSuYhM8ZJ+18PQ/Cwa2X3Pqre9JGPkQ8
GPiHDY3ff57kaun7inSMrKU0gYqisuLVq2MrFSyt2YckEfdHenzp5o5xMg6Y22xI
1OKMNTh99N/qkrPl0v4ueX0B6XE2NagDF/Jo55U0jxmOc1Hin3i0iE8Xz9Wu2qwk
eKZxbbwnF5x3CLAHcuDTSsqvE8deqxHSXJNuBFh9iMNm1JrnTqmWSDrpEG2lmpZz
uAKMzGqgfeKQIT7cjqXM5Dk8mOwObthvR5weg2hTUg+LMDVtpJ4=
=BtbR
-END PGP SIGNATURE-

Bug#1055956: ITP: kooha -- elegantly record your screen

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: kooha
  Version : 2.2.4
  Upstream Contact: Dave Patrick Caberto 
* URL : https://github.com/SeaDve/Kooha
* License : GPL-3+
  Programming Lang: Rust
  Description : elegantly record your screen

kooha is a small app to record ones screen. It supports both X11 and
Wayland desktops. Furthermore, audio-only and selective screen recording
is supported. This package with bee maintained wuth the Debian GNOME
team.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmVTwJkVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1jiEP/2OjFw32pzz7C5kq4calpX8g/zVk
vTnYfBRVGgovCzov4WnfwFxl0/G3TOqYaPagYDKzLgdlDxJGw9AI/bZ4U4aNSsuv
9R4aB3dOPiPPKpY53OPq8++xyr+70pkHOHle6+/D+Ajh8PC+QE9Qfk4UwsIOm9sC
UBaRWiNvA53y9p9GWPoLebI3i+HjkBAkKx5wrKKDf3gJBQBOBRX4HlI0MGXdBVuN
kPbL0yhuBgGCGMFy2ppp9c37VromLftd5ufdvDQbXlpt6XYCChSPROTwxtIc+9D7
WfcGcxpTn+dxr1C0Xmb0Unp7KBaug424UdYwp6r7Ob0rdPkkYYNWqFlmPit/LCb6
ICk4I7NRPR4ha/stdFcr/Oadq+MbC9yQ8THyCpY01y0Aqyw8e/wCu59HRC+m6VqD
LFq3cIzcTp3qrC8gfzo8f5nHmAYP7Y8YdM357FgMmJe8IQ92IpHLhGX70RJf5XyH
kmZ1eCE7CwRP2CDTt515MIJitAuhWBvRo1po/hit7prGBUzY0DvImQWJMS0THaxW
y3PpWt4XtstTyrkbqpZMfovuJ0kovECdzMRbLmXAJ/XhBziYoefDs8IBiLukyPh9
JH9vAAxMw9QzgaYphUP/P/2gJfVCrYhDcp82yENZPvCIqxHRZj1uO9zof3zKFMbF
X1JkVZE5Qs3MFbCj
=Bbq3
-END PGP SIGNATURE-

RFC: advise against using Proton Mail for Debian work?

[Nicholas D Steeves]

Hello,

Please retain me in CC for all replies.

Everyone reading this most likely believes that PGP/GPG is a good thing;
Many will advocate for its use-by-default for even unimportant
correspondences, because privacy is a right.  Meanwhile, everyday usage
of encryption normalises it, which is important because the means to
privacy should not a niche crypto enthusiast thing...

On the surface, this means Proton Mail (free account) is great!  And for
general use, I feel like we should be supportive of them; however, I'm
starting to wonder if we need to recommend against the use of Proton
mail for Debian work for the following two reasons:

1. I've received a report that this provider is not appropriate for DM
and DD use, because the key pair is stored on their servers.  Ie: The
applicant doesn't control the means to validating identity and
authorship.

2. The Proton Mail web client automatically encrypts email to anyone who
it has a key for.  Usually, this would be a great thing, but it means
that emailing 1234 at bugs.debian.org while CCing
uploader_since_this_is_an_rc_...@debian.org will encrypt the email that
is sent to the BTSe...which has the effect of making Debian development
veiled in plain sight rather than "in the open".

I see three outcomes:

A) Continue to explain this to new contributors on a one-by-one basis.
B) Advise against using Proton Mail for Debian work (where?  our wiki?)
C) Proton Mail begins to do something differently on their end, such as
offering some features to Debian contributors that currently require a
subscription.

What do you think?
Nicholas

P.S. Also, at what point should we add them to CC and/or write them an
open letter?


signature.asc
Description: PGP signature

Re: RFC: advise against using Proton Mail for Debian work?

[Simon Richter]

Hi,

On 11/15/23 08:40, Nicholas D Steeves wrote:


1. I've received a report that this provider is not appropriate for DM
and DD use, because the key pair is stored on their servers.  Ie: The
applicant doesn't control the means to validating identity and
authorship.


Correct. I'd even go as far and say that using it should be a 
disqualifying factor. Upload permissions are tied to a gpg key, and the 
holder of the key needs to at least demonstrate good practices in using 
gpg, ideally also have enough understanding to be able to derive good 
practices and not just follow a set of rules.


The gpg signature is not just a formal requirement where it doesn't 
matter how it is generated, but an integral part of the trust chain.



A) Continue to explain this to new contributors on a one-by-one basis.


I think that is part of Tasks&Skills.


C) Proton Mail begins to do something differently on their end, such as
offering some features to Debian contributors that currently require a
subscription.


Unless that feature is "you control your own secrets", that makes no 
difference, it remains unsuitable and anyone using it in this manner 
demonstrates that they are not yet ready for the responsibilities of 
Debian membership.


And "control your own secrets" as a perk of paid membership would be an 
even bigger level of wrong.


   Simon

Re: RFC: advise against using Proton Mail for Debian work?

[M. Zhou]

On Tue, 2023-11-14 at 18:40 -0500, Nicholas D Steeves wrote:
> 
> I see three outcomes:
> 
> A) Continue to explain this to new contributors on a one-by-one
> basis.
> B) Advise against using Proton Mail for Debian work (where?  our
> wiki?)
> C) Proton Mail begins to do something differently on their end, such
> as
> offering some features to Debian contributors that currently require
> a
> subscription.

Instead, is it possible to make BTS reject encrypted (unreadable)
mails? In that way no particular service name has to be mentioned
and Debian members will be able to figure out the mail service
has got an issue.

Discouraging the usage of a certain service publically just
because of some technical issues (instead of ethical/moral/legal)
is very much likely problematic, as an organization.
Plus, the 5-th clause if DFSG is "no discrimination against
persons or groups". People outside the community will mock us
if we ban it like this.

I just felt some sort of resemblance to "XXX operating system
is evil, do not use it". Whether or not people agrees with it
personally, it is inappropriate to make such opinion official.

Re: RFC: advise against using Proton Mail for Debian work?

[Nilesh Patra]

On 15 November 2023 5:10:50 am IST, Nicholas D Steeves  wrote:
>On the surface, this means Proton Mail (free account) is great!  And for
>general use, I feel like we should be supportive of them; however, I'm
>starting to wonder if we need to recommend against the use of Proton
>mail for Debian work for the following two reasons:
>
>1. I've received a report that this provider is not appropriate for DM
>and DD use, because the key pair is stored on their servers.  Ie: The
>applicant doesn't control the means to validating identity and
>authorship.

100% agreed.

I once advocated a DM who uses protonmail and a few months (after they became a 
DM), I came to know about PM's storing keys in the server.
So I quickly checked with the person in question if they pushed their keys to 
PM's servers, and to my utter horror, they did.

I quickly made the keyring maint know and their keys were removed immediately 
and a new pair of keys were later added back after a few months when enough 
trust was established for those.

This is not the only instance I faced this. Another individual whom I advocated 
for being a DM also did this, but we found out about it before the process 
started.

People who are new to the GPG thing end up thinking it's okay to add their keys 
to PM - which is fine, but this is as good as compromised from the debian view 
which I think is correct.

Due to this, I'm always skeptical whenever I receive a PGP signed or encrypted 
email from protonmail.

>2. The Proton Mail web client automatically encrypts email to anyone who
>it has a key for.  Usually, this would be a great thing, but it means
>that emailing 1234 at bugs.debian.org while CCing
>uploader_since_this_is_an_rc_...@debian.org will encrypt the email that
>is sent to the BTSe...which has the effect of making Debian development
>veiled in plain sight rather than "in the open".

Does it not encrypt email per-sender?

>I see three outcomes:
>
>A) Continue to explain this to new contributors on a one-by-one basis.
>B) Advise against using Proton Mail for Debian work (where?  our wiki?)

It might be good to give a warning about pushing PGP keys to proton mail's 
servers and it's implication on debian work *and* also inform new contributors 
on one by one basis who may not have seen the wiki.

I also think that providers that do not offer IMAP/POP3 are not very 
recommended for debian work too as you lose the ability to use a mailing client 
(and sign your mails). I think it'd be good to add a note about that as well. 
I've seen at least 2 people start with a tutanota email address and later 
switch due to this reason.

>C) Proton Mail begins to do something differently on their end, such as
>offering some features to Debian contributors that currently require a
>subscription.

This does not look feasible since 'Debian contributors' is a broad term and 
it'd be impractical to classify people there and give them access.
What could _maybe_ make sense is to have case-by-case endorsements for debian 
contributors to get such features.

>P.S. Also, at what point should we add them to CC and/or write them an
>open letter?

I think whenever we reach a sensible way forward :)

If they don't already, probably adding a warning regarding PGP keys in their 
webUI could be good as well.

Best,
Nilesh