Re: libzstd should not be maintained by Debian Med team - could some core team please take over (Was: libzstd 1.5.2 in Debian)

[Andreas Tille]

Hi Peter,

Am Mon, Feb 21, 2022 at 07:40:26PM +0200 schrieb Peter Pentchev:
> > Please consider this mail a team-orphane of the package.
> 
> I'm sorry; I do indeed intend to bring it into pkg-rpm, and I will try
> to do that in the next couple of days. Apologies for the months of
> delay, and thanks a lot for all of your team's work!

That's really appreciated.  Please let me know if you need help /
permissions to transfer the packaging repository.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1006262: ITP: camlp-streams -- Stream and Genlex libraries for use with Camlp4 and Camlp5

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: camlp-streams
  Version : 5.0
  Upstream Author : Daniel de Rauglaudre and Xavier Leroy
* URL : https://github.com/ocaml/camlp-streams
* License : LGPL-2.1 with OCaml linking exception
  Programming Lang: OCaml
  Description : Stream and Genlex libraries for use with Camlp4 and Camlp5

 The camlp-streams package provides two library modules:
 * Stream: imperative streams, with in-place update and memoization of
   the latest element produced.
 * Genlex: a small parameterized lexical analyzer producing streams of
   tokens from streams of characters.
 The two modules are designed for use with Camlp4 and Camlp5. The
 Stream module can also be used by hand-written recursive-descent
 parsers.

The Stream and Genlex modules have been part of the OCaml standard
library for a long time, and have been distributed as part of the core
OCaml system. They will be removed from the OCaml standard library at
some future point, but will be maintained and distributed separately
in this package.

The latest version of camlp5 (8.00.03) depends on it.

This package will be maintained in the OCaml team.

Bug#1006264: RFH: dhcpcd5 -- DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

[Martin-Éric Racine]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: affects -1 src:dhcpcd5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Given how upstream ISC will stop development of its DHCP suite by the end of 
2022 [1], Debian will need to select a new stock DHCP client to ship with 
Priority:Important.

dhcpcd5 seems like the most potential replacement. It covers most IPv4 and IPv6 
usage cases, and upstream regularly updates the code. However, the Debian 
package hasn't been updated in ages.

A bug was filed asking for the latest upstream release to be packaged was filed 
[2] but remains unanswered nearly 2 years later. A recent comment by Michael 
Biebl suggests that current versions of Network-Manager ship with support for 
this, but it would require a MUCH more recent version than what Debian 
currently ships.

I therefore think that dhcpcd5 deserves plenty of maintainance help, perhaps 
even a new maintainer.

Martin-Éric

The package description is:
 dhcpcd is a one stop network management daemon which includes
  * RFC compliant DHCPv4 and DHCPv6 clients
  * DHCPv6 Prefix Delegation support
  * IPv4LL (aka ZeroConf) support
  * ARP address conflict resolution
  * Link carrier detection
  * Wireless SSID profiles
  * ARP ping profiles

1. 
2. 

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmIUqzkACgkQrh+Cd8S0
17ZAwg/+Oy+N3Hw15+5MJ/VtdhZotqzROhyRjVp9JRVs9ql/43jea4LZFQjwvmfx
he/KZlN/iYPR8Ky8PWD5U02ywN+wtlfxC39DLwtsPhylT70hNMydAh1+IHQKgope
IbYIfDG2V90nat42GNU7v0+PPHey8OXnvgmXuffhm2I8q43qMd1CJ/Q8HYlILtu6
ApbNAeo8i/q17BhqqKoT6YfS0o83MgMvSdSCZQhBLg/r1tZUMeONbkc2fNeC8sif
AdZEBDiiXN2blRAwDEHj6uCOEuucxfCWdp3zZEiw7konCilYuCejB479B+UiJtlY
rgdBvrrffb/E38S0q/04PlOG40R9BfJ79ksvvYvo0uzNwg6X+7u102Vy/ZXAxAIW
x0myHLmg3npaq9bFP/w8hK12Vsi+BfDZ7aZCH3VIu72scaFgjxIYWSdd9MGDDhP1
prs91poRDFAvlS5cuolz4wHntexkG4VB14fDaHmmTY9g+IiF5CGFmcLxdtmiJwNN
oQanaK9K8EU4uaF5VT8IYymSeO0HsSqZre9dIaF9d3HOUWYTtopRpAxhmbH6F0UO
2YUAJ/PO22ygprwubz+AfhFJwp1o6kLd+0ui0Kca3t8GwEHw+y3NBvTCnIfayXxp
jbSRipyvtkRK1+n8uK97sty7B+HMG9T5D4vQjrdynmNUcDYx69I=
=hiw9
-END PGP SIGNATURE-

Re: What are the most important projects that Debian ought to work on?

[Raphael Hertzog]

Hello,

On Mon, 24 Jan 2022, Sébastien Delafond wrote:
> As part of an upcoming survey that we are preparing, we plan to ask
> Debian developers to rank, by order of importance, the most popular
> ideas of improvements for Debian.

So I have finalized the question with all the choices. Given the large
number of choices, I opted to not require a ranking but to give a mark
between 0 to 10 to evaluate the importance of the idea:
https://salsa.debian.org/freexian-team/misc-drafts/-/commit/b0073480657fae493df905821ee01b4ca3547c7f

It looks like this:


For each of the ideas listed below, please rate its importance for Debian
from 1 (not important at all) to 10 (very important). If you are against
the idea, please rate it with 0 (unacceptable).

Ideas related to Debian's purpose:
* [Debian should track issues in user stories and not just 
packages](https://salsa.debian.org/debian/grow-your-ideas/-/issues/29)
* [Debian should provide high quality ansible roles (and/or salt formulas, 
etc.)](https://salsa.debian.org/debian/grow-your-ideas/-/issues/18)

Ideas related to packaging workflows:
* [Debian should allow to upload packages by pushing a signed git 
tag](https://salsa.debian.org/debian/grow-your-ideas/-/issues/9)
* [Debian should provide personal/extra package repositories for Debian 
developers/teams](https://salsa.debian.org/debian/grow-your-ideas/-/issues/6)
* [Debian should have a default standard packaging 
workflow](https://salsa.debian.org/debian/grow-your-ideas/-/issues/24)
* [Debian should rethink/clarify the objectives of the NEW queue 
review](https://salsa.debian.org/debian/grow-your-ideas/-/issues/11)
* [Debian should create a unified workflow for package review and use it 
everywhere 
applicable](https://salsa.debian.org/debian/grow-your-ideas/-/issues/19)
* [Debian should migrate packages without any VCS into 
salsa](https://salsa.debian.org/debian/grow-your-ideas/-/issues/10)
* [Debian should provide a better infrastructure to manage 
transitions](https://salsa.debian.org/debian/grow-your-ideas/-/issues/21)

Ideas of other organizational changes:
* [Debian should build a packaging team to maintain vital system 
components](https://salsa.debian.org/debian/grow-your-ideas/-/issues/30)
* [Debian should publicly support usage of the testing 
release](https://salsa.debian.org/debian/grow-your-ideas/-/issues/12)
* [Debian should have a unstable-proposed-updates suite for use during 
freeze](https://salsa.debian.org/debian/grow-your-ideas/-/issues/25)
* [Debian should formalize its reimbursement process to reduce extra 
paperwork](https://salsa.debian.org/debian/grow-your-ideas/-/issues/1)

Ideas of technical changes:
* [Debian should make it easy for blends and derivatives to build and host 
images](https://salsa.debian.org/debian/grow-your-ideas/-/issues/27)
* [Debian should make it easy to fork packages and/or the 
distribution](https://salsa.debian.org/debian/grow-your-ideas/-/issues/23)
* [Debian should further trim the base system for the benefits of containers 
and embedded 
systems](https://salsa.debian.org/debian/grow-your-ideas/-/issues/20)
* [Debian should complete the merged-/usr 
transition](https://salsa.debian.org/debian/grow-your-ideas/-/issues/22)
* [Debian should switch wiki.debian.org from MoinMoin to 
Mediawiki](https://salsa.debian.org/debian/grow-your-ideas/-/issues/2)
* [ports.debian.org should be managed with dak and 
britney](https://salsa.debian.org/debian/grow-your-ideas/-/issues/5)

Note that all the ideas are linked to a corresponding issue in the "grow your
ideas" project. Please consider upvoting the ideas there that you
consider worthwhile to pursue. You do that by clicking the "thumbs up"
button at the top of each issue on salsa.debian.org.


I have left out a few low-impact and really uncontroversial ideas (like
"port UDD to Python 3", we all agree on that, it's more a matter of
finding the right volunteer).

If you think I badly rephrased some of the ideas in there, please let me
know. Feel free to suggest improvements by mail reply or with a MR here:
https://salsa.debian.org/freexian-team/misc-drafts/

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

History doesn't repeat itself, but it often rhymes

[Paul Tagliamonte]

Hello, Debianites,

Allow me, if you will, to talk a bit about something that's been on my mind
a bit over the last handful of years in Debian. It's something that's pretty
widely circulated in particular circles, but I don't think I've seen it on
a Debian list before, so here's some words that I've decided to put together.


I've intentionally not drawn lines to the 'discussions' going on (or the
'discussions' in the past I could point to) to avoid getting dragged into more
thrash, so if you reply, please do try to keep this clear of any specific
argument that you feel this may or may not apply to. This is a more general
note that I think could use some thought from anyone who's interested.


During World War II, the OSS (Office of Strategic Services)[1] distributed a
manual[2] (the Simple Sabotage Field Manual), which was used to train
"citizen-saboteur" resistance fighters, some of whom were told, not to pick up
arms, but to confound the bureaucracy by tying it up with an unmanageable
tangle of "innocent" behavior.

While no one is working within the Debian community member attempting to
subvert us sent from the shady conglomerate of nonfree operating systems by
following this playbook, this playbook is an outstanding illustration of how
some innocent behavior can destroy the effectiveness of an organization.  It's
effective, precisely *because* it's not overly malicious, and these behaviors
-- while harmful -- are explainable or innocent. Section (3) covers this in
detail.

Most of the OSS Simple Sabotage Field Manual covers things like breaking
equipment or destroying tanks, but section (11) is "General Interference with
Organizations and Production". I'm just going to focus here.

Let's take a look at section (11):

> (1) Insist on doing everything through "channels." Never permit short-cuts
> to be taken in order to expedite decisions.
>
> (2) Make "speeches." Talk as frequently as possible and at great length.
> Illustrate your "points" by long anecdotes and accounts of personal
> experiences. Never hesitate to make a few appropriate "patriotic" 
> comments.
>
> (3) When possible, refer all matters to committees for "further study and
> consideration." Attempt to make committees as large as possible -- never
> less than five.
>
> (4) Bring up irrelevant issues as frequently as possible.
>
> (5) Haggle over precise wordings of communications, minutes, resolutions.
>
> (6) Refer back to matters decided upon at the last meeting and attempt to
> re-open the advisability of that decision.
>
> (7) Advocate "caution." Be "reasonable" and urge your fellow co-conferees to
> be "reasonable" and avoid haste which might result in embarrassments or
> difficulties later on.
>
> (8) Be worried about the propriety of any decision - raise the question of
> whether such action as is contemplated lies within the jurisdiction of
> the group or whether it might conflict with the policy of some higher
> echelon.

I won't go through each of these point-by-point since everyone reading this is
likely sharp enough to see how this relates to Debian (although I will point
out I find it particularly interesting to replace "patrotic" here with the
Debian-specific-patriotism -- Debianism? -- and re-read some of the more
heated threads)



I have a theory of large organizations I've been thinking a lot about that came
from conversations with a colleague, which is to think about an organization's
"metabolic overhead" -- i.e., the amount of energy that an organization
devotes to intra-organization communication. If you think about a car
manufacturing plant, the "metabolic overhead" is all the time spent on things
like paperwork, communication, planning. It's not possible (or desirable!) for
an organization to have 0% overhead, nor is it desirable (although this one *is*
possible) to spend 100% time on overhead. I think it *may* be possible to get
to above 100% overhead, if workplace contention spills out into drinks after
work.

All of the points in the OSS Simple Sabotage Manual are things designed to
increase the metabolic overhead of an organization, and to force organization
members to spend time *not* doing their core function (like making cars,
running trash pickup or ensuring the city has electricity), but rather, spend
their time litigating amongst themselves as the core function begins to
become harder and harder to maintain. This has the effect of degrading the
output/core function of an organization, without any specific cause
(like a power loss, etc).

I'd ask those who are reading this to consider how this relates to their time
spent in Debian. Is what you find something you're happy about with a hobby
project you're choosing to spend your free time on? Are you taking actions to
be a good participant?



To do a bit of grandstanding myself, do remember that it's not just your time
here -- when we spend significant resources litigating and playing bureaucracy
games, we spend o

Re: History doesn't repeat itself, but it often rhymes

[Jonathan Carter]

Hi Paul

On 2022/02/22 19:29, Paul Tagliamonte wrote:

We don't need to be hostile or expel people for doing things outlined in the
OSS Simple Sabotage Manual, since a lot of that behavior is -- at times --
desirable, but I think we do need a*LOT*  of self-reflection (from*everyone*
who actively engages with Debian politics) to consider our actions, and
determine how (if at all) we feel that we (as individuals) should change.


Thanks for that mail, it was an interesting read and I think I'll try to 
get a copy of that manual!


As for the paragraph quoted above, I do think we need to deal with 
people who are indistinguishable from a saboteur. I value my time a lot, 
and also of those who spend all their love and energy and years of their 
lives into this project, so I find it incredibly offensive when someone 
comes and things that it's their god given right to piss all over it and 
keep wasting everyone's time.


As a courtesy, I think it's fine to tell them that we find that behavior 
problematic, and that they should stop it if they wish to remain part of 
the project. But failing that, whether I'm DPL or not, I will strongly 
campaign with DAM or whoever makes those kind of decisions to kick them 
out. If we have leadership that can't take those kind of decisions then 
I'd rather not be part of Debian at all.


-Jonathan

Bug#1006296: ITP: git-credential-libsecret -- Git helper for accessing credentials via libsecret.

[M Hickford]

Package: wnpp
Severity: wishlist
Owner: M Hickford 
X-Debbugs-Cc: debian-devel@lists.debian.org, mirth.hickf...@gmail.com

* Package name: git-credential-libsecret
* URL : 
https://github.com/git/git/commits/master/contrib/credential/libsecret/git-credential-libsecret.c
* License : GPL
  Programming Lang: C
  Description : Git helper for accessing credentials via libsecret.