Bug#1051978: ITP: python-yamlfix -- Simple opionated yaml formatter that keeps your comments

[Carsten Schoenert]

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

* Package name: python-yamlfix
  Version : 1.13.0
  Upstream Contact: Lyz 
* URL : https://github.com/lyz-code/yamlfix
* License : GPL-3
  Programming Lang: Python
  Description : Simple opionated yaml formatter that keeps your comments

 yamlfix is a Python based YAML file formatter which will fix any known
 formatting issue within your YAML files automatically.
 .
 It can read configuration settings from pyproject.toml, from configuration
 files or environment variables while it is called from the CLI or by
 including as Python library.
 .
 Main feature are:
  * Add the header --- to your file.
  * Correct truthy strings: 'True' -> true, 'no' -> 'false'
  * Remove unnecessary apostrophes:
title: 'Why we sleep' -> title: Why we sleep.
  * Correct comments
  * Ensure that there is exactly one newline at the end of each file, to
comply with the POSIX standard.
  * Split long lines.
  * Respect Jinja2 syntax.
  * Convert short lists to flow-style list: [item, item]
  * Convert lists longer than line-width to block-style

This package will get maintained within the Debian Python Team.

Bug#1051983: ITP: golang-github-katalix-go-l2tp -- L2TP and PPPoE tools built using the go-l2tp package

[Tom Parkin]

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

* Package name: golang-github-katalix-go-l2tp
  Version : 0.1.1
  Upstream Contact: Tom Parkin 
* URL : https://github.com/katalix/go-l2tp
* License : BSD
  Programming Lang: golang
  Description : L2TP and PPPoE tools built using the go-l2tp package

go-l2tp is a suite of Go libraries for building L2TP applications on
Linux systems.
.
It includes a set of daemons for managing various related connections:
 * kl2tpd is a client (LAC-mode) L2TPv2 daemon,
 * ql2tpd manages static L2TPv3 Ethernet connections,
 * kpppoed is a PPPoE server daemon which can be used alongside kl2tpd
   to implement L2TP Access Concentrator connections.
.
The go-l2tp daemons use the Linux kernel L2TP and PPP subsystems for
data transport.  PPP termination is delegated to pppd.

Since go-l2tp's initial release on GitHub, the NetworkManager-l2tp
project (a VPN plugin for NetworkManager), has adopted kl2tpd as
its default L2TP daemon, falling back to xl2tpd if kl2tpd is not
available.

kl2tpd offers several benefits over xl2tpd, including the use of
ephemeral ports by default, and supporting the use of IPSec with
kernel-mode L2TP data transport.

Offering kl2tpd as a part of a Debian package will make
NetworkManager-l2tp easier to maintain and make it easier for users to
use kl2tpd for their VPN connections.

As a golang package, golang-github-katalix-go-l2tp would fall under the
aegis of the Debian Go Packaging team.  However the upstream authors
would be happy to provide collaborative ongoing support with the
maintenance of the package.

Re: Default font: Transition from DejaVu to Noto

[Gunnar Hjalmarsson]

On 2023-09-15 05:03, Paul Wise wrote:

On Wed, 2023-09-13 at 21:09 +0200, Gunnar Hjalmarsson wrote:

So we have a conflict of goals here. The good news is that a user
who speaks some latin language, and who thinks it's important to be
able to easily select font directly in various applications, can
do:

apt purge fonts-noto-core


That won't work on some systems because various packages hard-depend
on the various fonts-noto packages and metapackages.


To the extent there are such hard depends which are not motivated, bugs 
should be submitted.


I see at least one apparent case (maybe there are more): The meta 
package cinnamon-desktop-environment depends on the fonts-noto meta package.


--
Gunnar

Bug#1051991: ITP: node-sixel -- Node.js library to manage Sixel images

[Yadd]

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

* Package name: node-sixel
  Version : 0.16.0
  Upstream Contact: Joerg Breitbart 
* URL : https://github.com/jerch/node-sixel/
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to manage Sixel images

node-sixel is a image decoding / encoding library for node and the browser.

It is a build dependency of node-xterm 5 which is required for
node-jupyterlab. Will be maintained under JS Team umbrella.

armhf NEON exception for chromium

[Andres Salomon]

Hi,

The latest chromium is failing to build on armhf because upstream broke 
non-NEON builds. While that is technically an upstream bug, I'm not 
sure upstream is going to care enough to even accept a patch to fix it. 
I understand that the baseline for the armhf architecture is to not 
support NEON, but folks in #debian-arm suggested that I specifically 
ask for an exception for chromium.


At this point I'm pretty confident in assuming that folks running 13 
year old arm  boards or newer rpi zero boards with 512MB of ram will 
not be using that hardware to browse the web with debian's chromium 
package. That leaves those using chromium for scripts or ci tests (eg, 
jquery-timepicker) on older armhf boards. The ci.debian.net 
infrastructure is newer than buildds, so I hopeful that they're mostly 
(or entirely?) machines that support NEON. And of course, chromium 
built with NEON support should be at least a small speed improvement 
for users running the browser on newer arm v7 hardware, although I lack 
the hardware to quantify that.


So my proposal for chromium is this:
a) Enable NEON for chromium's armhf build.
b) Add a check in debian/rules for 'neon' in /proc/cpuinfo's Features: 
line, and fail to build if NEON is not present. This should ensure that 
any buildds or downstream builders don't waste resources 
configuring/building chromium on a non-NEON board only to have it fail 
somewhere in the middle.
c) Using the current shell script wrapper for chromium (which already 
checks for things like SSE3 cpu instructions on x86), check for NEON 
support at startup by also looking for the string 'neon' in 
/proc/cpuinfo; if NEON is not supported, print an error message and 
exit before launching the chromium binary.
d) Ask the buildd admins to restrict building of chromium from any 
Armada XP buildds, which appear to be the only armhf buildds left in 
rotation that lack NEON support. If they are unwilling/unable to do 
this, then I'll have to play the giveback game for armhf (step right 
up! everyone's a winner!), which I often end up having to do currently 
because the 2-3 day armhf builds will sometimes hang/crash halfway 
through.


Any thoughts on this? Please explicitly Cc me on replies, as I'm not 
subscribed to any of the lists.


Thanks,
Andres

Re: armhf NEON exception for chromium

[Sam Hartman]

> "Andres" == Andres Salomon  writes:

Andres> Any thoughts on this? Please explicitly Cc me on replies, as
Andres> I'm not subscribed to any of the lists.

Makes sense to me.

Re: armhf NEON exception for chromium

[Paul Tagliamonte]

On Fri, Sep 15, 2023 at 12:18 PM Andres Salomon  wrote:
> So my proposal for chromium is this:
> a) Enable NEON for chromium's armhf build.
> b) Add a check in debian/rules for 'neon' in /proc/cpuinfo's Features: line, 
> and fail to build if NEON is not present. This should ensure that any buildds 
> or downstream builders don't waste resources configuring/building chromium on 
> a non-NEON board only to have it fail somewhere in the middle.
> c) Using the current shell script wrapper for chromium (which already checks 
> for things like SSE3 cpu instructions on x86), check for NEON support at 
> startup by also looking for the string 'neon' in /proc/cpuinfo; if NEON is 
> not supported, print an error message and exit before launching the chromium 
> binary.
> d) Ask the buildd admins to restrict building of chromium from any Armada XP 
> buildds, which appear to be the only armhf buildds left in rotation that lack 
> NEON support. If they are unwilling/unable to do this, then I'll have to play 
> the giveback game for armhf (step right up! everyone's a winner!), which I 
> often end up having to do currently because the 2-3 day armhf builds will 
> sometimes hang/crash halfway through.

This seems like a very good idea to me. I doubt anyone running
chromium on an armhf at this point would try to do so on anything that
doesn't support NEON. As a user (and developer targeting armhf) this
seems like a win for users, IMVHO.

  paultag

-- 
:wq

Re: armhf NEON exception for chromium

[Timothy Pearson]

- Original Message -
> From: "Paul Tagliamonte" 
> To: "Andres Salomon" 
> Cc: debian-devel@lists.debian.org, "Timothy Pearson" 
> , debian...@lists.debian.org
> Sent: Friday, September 15, 2023 11:29:56 AM
> Subject: Re: armhf NEON exception for chromium

> On Fri, Sep 15, 2023 at 12:18 PM Andres Salomon  wrote:
>> So my proposal for chromium is this:
>> a) Enable NEON for chromium's armhf build.
>> b) Add a check in debian/rules for 'neon' in /proc/cpuinfo's Features: line, 
>> and
>> fail to build if NEON is not present. This should ensure that any buildds or
>> downstream builders don't waste resources configuring/building chromium on a
>> non-NEON board only to have it fail somewhere in the middle.
>> c) Using the current shell script wrapper for chromium (which already checks 
>> for
>> things like SSE3 cpu instructions on x86), check for NEON support at startup 
>> by
>> also looking for the string 'neon' in /proc/cpuinfo; if NEON is not 
>> supported,
>> print an error message and exit before launching the chromium binary.
>> d) Ask the buildd admins to restrict building of chromium from any Armada XP
>> buildds, which appear to be the only armhf buildds left in rotation that lack
>> NEON support. If they are unwilling/unable to do this, then I'll have to play
>> the giveback game for armhf (step right up! everyone's a winner!), which I
>> often end up having to do currently because the 2-3 day armhf builds will
>> sometimes hang/crash halfway through.
> 
> This seems like a very good idea to me. I doubt anyone running
> chromium on an armhf at this point would try to do so on anything that
> doesn't support NEON. As a user (and developer targeting armhf) this
> seems like a win for users, IMVHO.
> 
>  paultag
> 
> --
> :wq

I am also in agreement here.  Chromium is resource intensive enough that it 
basically needs vector instructions (notably in skia), if not a full-blown GPU, 
to be useful.

Re: armhf NEON exception for chromium

[Paul Gevers]

Hi,

On 15-09-2023 17:52, Andres Salomon wrote:

Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty on 
armel ci.debian.net workers. (I'm failing to spot neon in the list of 
features of that machine.)


Paul

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036818


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: /usr/-only image

[Luca Boccassi]

On Mon, 11 Sept 2023 at 15:09, Simon McVittie  wrote:
>
> On Mon, 11 Sep 2023 at 08:58:09 +0200, Gioele Barabucci wrote:
> > An even bigger prerequisite is that many upstream projects does not yet
> > support working without /etc or (orthogonally) reading their default
> > configuration from /usr.
>
> I agree that an "upstream first" approach is good here - even if we might
> want Debian maintainers to backport upstream changes that haven't made it
> into a release yet. Loading defaults from /usr is a behaviour change, and
> many downstream maintainers are (IMO correctly) reluctant to make
> Debian-specific behaviour changes for things that would ideally go
> upstream but have not yet been accepted upstream, because that carries a
> risk of the change never happening upstream and the Debian delta therefore
> becoming permanent.
>
> There are a couple of inter-related things here, which might make sense
> to treat as separate topics.
>
> Integration hooks
> =
>
> Quite a lot of packages have some sort of integration hook, where package A
> installs a file in a location "owned" by package B, to make the two
> packages integrate nicely together. It's best if we can change package B
> to load these integration hooks from /usr, and then systematically change
> all examples of package A to install there.
>
> Because this involves a large number of often trivially small files,
> working on this will probably have the largest impact on the number of
> files in /etc that would need special management for anyone who wants to
> use a /usr-only filesystem image.
>
> For instance, dbus-daemon (and other D-Bus implementations like
> dbus-broker) used to require system services to install a snippet into
> /etc/dbus-1/system.d. It's now deprecated for packages to install files
> into that directory, and instead, they should install into
> /usr/share/dbus-1/system.d, reserving /etc/dbus-1/system.d for sysadmin
> overrides.
>
> The steps to take here are:
>
> 1. Change package B to load from /usr in addition to /etc. This should
>usually be done upstream, because it's a behaviour change.
>(For instance where B = dbus-daemon, we did this in 2015.)
>If multiple packages all load from the same location (like dbus-daemon
>and dbus-broker) then all of them need this change.
>
> 2. For each package A, move the integration/configuration snippet from
>/etc to /usr. This should ideally be done upstream too, but it's usually
>straightforward (low maintenance cost) to do this in our packaging,
>and it doesn't necessarily *need* to happen upstream.
>
> Configuration defaults
> ==
>
> Some packages rely on their own configuration existing in /etc. For these
> packages, ideally they'd try loading from /etc as highest priority, but
> fall back to /usr as a lower-priority location. This is a
> package-by-package change, and probably best achieved upstream.

Actually this upstream work has already been happening, for years,
spearheaded by SUSE, who are the authors of libeconf
(https://github.com/openSUSE/libeconf) which provides a turn key
solution to implement this pattern of config loading.

In fact, Marco yesterday told me the only blocker to boot a minimal
Debian image with only /usr is PAM, and that's exclusively because of
downstream-specific changes - upstream not only has supported the
hermetic-usr config model for years, but the upstream maintainer is
one of the main drivers of the generic effort at SUSE.
Given this, it seems to me the first order of business should be to
get our downstream PAM sorted first.

In the meanwhile, we discussed this issue both at this week's
Image-Based Linux Summit and ASG2023, and I've got AIs on me to make
the hermetic-usr/libeconf format into a standalone spec under
uapi-group.org, and to see if we can get a cross-distro tracker for
the common upstreams (required for minimal/reduced images, it will
never be a 100% coverage affair as the problem space is too vast) that
still need changes. I'll try to get to those next week.

Re: armhf NEON exception for chromium

[Andres Salomon]

On Fri, Sep 15 2023 at 08:30:20 PM +02:00:00, Paul Gevers 
 wrote:

Hi,

On 15-09-2023 17:52, Andres Salomon wrote:

Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty 
on

armel ci.debian.net workers. (I'm failing to spot neon in the list of
features of that machine.)

Paul

[1] 


Thanks for the heads-up!

Ugh, even with that fix (which was merged upstream today), it looks 
like when you have arm64 bare metal with a qemu armhf VM, neon doesn't 
get included in /proc/cpuinfo despite arm64 supporting it as part of 
the core architecture. So my plan to deal with autopkgtest won't work..

Re: armhf NEON exception for chromium

[Steve Langasek]

On Fri, Sep 15, 2023 at 08:30:20PM +0200, Paul Gevers wrote:
> Hi,

> On 15-09-2023 17:52, Andres Salomon wrote:
> > Any thoughts on this?
> Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty on
> armel ci.debian.net workers. (I'm failing to spot neon in the list of
> features of that machine.)

armel != armhf and nobody should be running armel on a NEON-capable CPU...
or chromium on an armel-only system.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Do not plan to support /usr/lib/pam.d for Debian pam

[Sam Hartman]

Apropos of the discussion about removing default configuration from
/etc.
Upstream PAM now supports doing that.  You can set up a vendor directory
such as /usr/lib where pam.d and security live.

I thought about doing that for Debian PAM, and have decided against.
My rationale is that I actually think dpkg gives superior handling of
upstream configuration changes to what we'd get with the pam vendor dir
*in the specific case of PAM*.

In particular, dpkg will let you know if the conf file has changed
upstream and you have local changes.
If we create a vendor directory,  you will have to diff yourself to
discover that.

I do think that in the case of programs like systemd that do a complex
merge of drop in fragments, the split of vendor dir from sysadmin dir
makes a lot of sense.

But for the most part PAM appears to just override on a file-by-file
basis.
And for that use case, I think dpkg's handling is at least as good.
I appreciate others might differ.  With dpkg's conffile handling you get
better notification of changes but is it is hard to see at a glance
which files might be changed.

I am in favor of having a mechanism to easily reset the state in /etc.
Personally I'm not convinced that deleting /etc is the best way for
Debian to do that.
I think we might be able to find dpkg-based solutions that are superior.

If Debian  does develop a project consensus behind  minimizing
/etc--especially if there is a policy recommendation or encouragement in
this direction, then I'll revisit how we handle this for PAM.

If Debian develops another approach for resetting local state, I'll be
eager to look at that for PAM.

--Sam


signature.asc
Description: PGP signature

Re: armhf NEON exception for chromium

[Paul Gevers]

Hi Steve,

On 15-09-2023 21:54, Steve Langasek wrote:

armel != armhf


Of course


and nobody should be running armel on a NEON-capable CPU...


Not sure why you say it like that, I guess you don't meen CI purposes 
here. But anyways, it seems that also the arm64 host that runs our armel 
and armhf VM's doesn't have NEON in the feature list.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Luca Boccassi]

On Fri, 15 Sept 2023 at 21:08, Sam Hartman  wrote:
>
>
>
> Apropos of the discussion about removing default configuration from
> /etc.
> Upstream PAM now supports doing that.  You can set up a vendor directory
> such as /usr/lib where pam.d and security live.
>
> I thought about doing that for Debian PAM, and have decided against.
> My rationale is that I actually think dpkg gives superior handling of
> upstream configuration changes to what we'd get with the pam vendor dir
> *in the specific case of PAM*.
>
> In particular, dpkg will let you know if the conf file has changed
> upstream and you have local changes.
> If we create a vendor directory,  you will have to diff yourself to
> discover that.
>
> I do think that in the case of programs like systemd that do a complex
> merge of drop in fragments, the split of vendor dir from sysadmin dir
> makes a lot of sense.
>
> But for the most part PAM appears to just override on a file-by-file
> basis.
> And for that use case, I think dpkg's handling is at least as good.
> I appreciate others might differ.  With dpkg's conffile handling you get
> better notification of changes but is it is hard to see at a glance
> which files might be changed.
>
> I am in favor of having a mechanism to easily reset the state in /etc.
> Personally I'm not convinced that deleting /etc is the best way for
> Debian to do that.
> I think we might be able to find dpkg-based solutions that are superior.
>
> If Debian  does develop a project consensus behind  minimizing
> /etc--especially if there is a policy recommendation or encouragement in
> this direction, then I'll revisit how we handle this for PAM.
>
> If Debian develops another approach for resetting local state, I'll be
> eager to look at that for PAM.

With the provision that I know next to nothing about pam - if I
understood correctly how it works, why not simply do both? Ship the
default file in the package under both /usr and /etc. Then, you get
the semantics you want with local changes tracking, and /etc wins over
the defaults. And we can have a working, bootable Debian container
with only /usr. As far as I've been told, pam is the only blocker
there - for a minimal image of course, but that's still quite a good
achievement. Wouldn't this work, or am I missing something?

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Peter Pentchev]

On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> On Fri, 15 Sept 2023 at 21:08, Sam Hartman  wrote:
> >
> >
> >
> > Apropos of the discussion about removing default configuration from
> > /etc.
> > Upstream PAM now supports doing that.  You can set up a vendor directory
> > such as /usr/lib where pam.d and security live.
> >
> > I thought about doing that for Debian PAM, and have decided against.
> > My rationale is that I actually think dpkg gives superior handling of
> > upstream configuration changes to what we'd get with the pam vendor dir
> > *in the specific case of PAM*.
> >
> > In particular, dpkg will let you know if the conf file has changed
> > upstream and you have local changes.
> > If we create a vendor directory,  you will have to diff yourself to
> > discover that.
> >
> > I do think that in the case of programs like systemd that do a complex
> > merge of drop in fragments, the split of vendor dir from sysadmin dir
> > makes a lot of sense.
> >
> > But for the most part PAM appears to just override on a file-by-file
> > basis.
> > And for that use case, I think dpkg's handling is at least as good.
> > I appreciate others might differ.  With dpkg's conffile handling you get
> > better notification of changes but is it is hard to see at a glance
> > which files might be changed.
> >
> > I am in favor of having a mechanism to easily reset the state in /etc.
> > Personally I'm not convinced that deleting /etc is the best way for
> > Debian to do that.
> > I think we might be able to find dpkg-based solutions that are superior.
> >
> > If Debian  does develop a project consensus behind  minimizing
> > /etc--especially if there is a policy recommendation or encouragement in
> > this direction, then I'll revisit how we handle this for PAM.
> >
> > If Debian develops another approach for resetting local state, I'll be
> > eager to look at that for PAM.
> 
> With the provision that I know next to nothing about pam - if I
> understood correctly how it works, why not simply do both? Ship the
> default file in the package under both /usr and /etc. Then, you get
> the semantics you want with local changes tracking, and /etc wins over
> the defaults. And we can have a working, bootable Debian container
> with only /usr. As far as I've been told, pam is the only blocker
> there - for a minimal image of course, but that's still quite a good
> achievement. Wouldn't this work, or am I missing something?

Hm, what happens if a sysadmin deliberately removed a file that
the distribution ships in /etc, trying to make sure that some specific
service could never possibly succeed if it should ever attempt
PAM authentication? Then, if there is a default shipped in /usr,
the service authentication attempts may suddenly start succeeding
when the PAM packages are upgraded on an existing system.

Yes, I know that the override/drop-in mechanism provides a way to
do that by creating a /dev/null override symlink, but the sysadmin
would not have needed to do that - until now, when they suddenly do.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> With the provision that I know next to nothing about pam - if
Luca> I understood correctly how it works, why not simply do both?
Luca> Ship the default file in the package under both /usr and
Luca> /etc. Then, you get the semantics you want with local changes
Luca> tracking, and /etc wins over the defaults.

I honestly had not considered this.
It's a bit more tricky than you imply because it's not just pam that is
involved with this but also all pam applications.

We'd have to do active work to get every pam application to ship in both
places.

But as I said I had not considered this, and so it's something that I'm
open to thinking more about.


Luca> And we can have a
Luca> working, bootable Debian container with only /usr.

I'm not actually convinced this is a good thing.
(I don't think it's a bad thing--I just am not convinced it's something
we should be working toward).
I'd rather see project level discussion of this and a decision that is
something we want.

I have significant discomfort aligning what you say (pam is the last
blocker) with what several people said earlier in the week.
What I heard is that there was no project consensus to do this, and that
people were running experiments to see what is possible.

If I make a change in pam and we're suddenly at a place where  there are
no blockers and we're moving forward, I think people in the project
would understandably feel disenfranchised.
To bystanders, "we're running experiments to see what's possible," means
a decision is far off.


I feel like if I were to fall in on this, I might be helping cause
something to happen  at a technical level, bypassing discussion that I
believe would be healthy for the project.
I appreciate the value of doing work and  having people who  are willing
to do the work have a larger share of power in the decision making.

And yet I feel like especially for project level things, it's valuable
to present an idea, give people an opportunity to start working on
alternatives, give people an opportunity for their objections to be
heard, and see where we are *before* it's all but done technically.
I think we've not done such a great job of the above in the past.  Oh,
we've had the discussions and the flame wars, but I think our past
discussions have had a number of problems in common:

* Because things were effectively close to done technically in the minds
  of those driving the change, they had a degree of power that made
  others feel disadvantaged and defensive in the discussions.

* Sometimes when people have raised objections, they haven't understood
  the goals of people driving change.  So while their objections might
  in principle be valid, they were not actionable because they didn't
  understand what the goals were.  We've done a bad job of bringing
  those people into the discussion.  Doing better would probably be part
  clearly articulating why the proposed fix doesn't meet the goals, and
  clearly articulating that if the person with the objection will do the
  work to understand the goal, then the rest of us will do the work to
  bring them into the discussions.

* We have sometimes not done a job of giving people a chance to build
  alternatives--somehow saying that we've gotten to a place where there
  is interest in some particular goal, and it's serious enough that
  people need to either fall in on the plan that currently has momentum
  or quickly start putting energy into alternatives.  Finding the point
  for this is tricky; it's important that if people really are motivated
  to find another solution they still have time to do so, but it's also
  important to realize that people may not focus on something until they
  see that an approach they do not like has momentum.  ( Init systems
  are not an example where I think we had this problem; people knew that
  decision was coming and had a chance to explore alternatives.)

* Sometimes people have walked away from our discussions confused about
  the outcome or feeling like their opinion/input was not considered.
  We've actually be improving significantly on this lately.  I think the
  recent usrmerge discussions (say last two years) have been much better
  than earlier discussions at  considering input and making it clear
  where the discussion ended up.
  


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Sam Hartman]

> "Peter" == Peter Pentchev  writes:

Peter> On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
>> On Fri, 15 Sept 2023 at 21:08, Sam Hartman  wrote:

Peter> Hm, what happens if a sysadmin deliberately removed a file
Peter> that the distribution ships in /etc, trying to make sure that
Peter> some specific service could never possibly succeed if it
Peter> should ever attempt PAM authentication? Then, if there is a
Peter> default shipped in /usr, the service authentication attempts
Peter> may suddenly start succeeding when the PAM packages are
Peter> upgraded on an existing system.

This might be an issue in general, but it is not an issue for PAM.
PAM falls back on the other service if a service configuration cannot be
found.

--Sam

Re: Bug#1052004: libcbor: requires source-only upload to transition

[Vincent Bernat]

On 2023-09-15 21:04, Sebastian Ramacher wrote:

Source: libcbor
Version: 0.10.2-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://qa.debian.org/excuses.php?package=libcbor

Issues preventing migration:

 Not built on buildd: arch amd64 binaries uploaded by bernat
 Not built on buildd: arch all binaries uploaded by bernat, a new 
source-only upload is needed to allow migration


What's the status of throwing away the binaries when doing a 
non-source-only upload? This is a major pain point for me. You upload 
the package a first time as a source-only upload and get an error 15 
minutes later telling you it's NEW and you have to do a binary upload. 
Then, it gets accepted and you need another source-only upload.

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Russ Allbery]

Sam Hartman  writes:
>> "Peter" == Peter Pentchev  writes:

> Peter> Hm, what happens if a sysadmin deliberately removed a file
> Peter> that the distribution ships in /etc, trying to make sure that
> Peter> some specific service could never possibly succeed if it
> Peter> should ever attempt PAM authentication? Then, if there is a
> Peter> default shipped in /usr, the service authentication attempts
> Peter> may suddenly start succeeding when the PAM packages are
> Peter> upgraded on an existing system.

> This might be an issue in general, but it is not an issue for PAM.  PAM
> falls back on the other service if a service configuration cannot be
> found.

I think that makes it an even more subtle problem, doesn't it?

Currently, my understanding is that if I delete /etc/pam.d/lightdm, PAM
falls back on /etc/pam.d/other.  But if we define a search path for PAM
configuration such that it first looks in /etc/pam.d and then in
/usr/lib/pam.d, and I delete /etc/pam.d/lightdm, wouldn't PAM then fall
back on /usr/lib/pam.d/lightdm and not /etc/pam.d/other?  Unlike Peter's
example, that would be a silent error; authentication may well succeed,
but without running, say, pam_limits.so.

I don't know if anyone is making this specific configuration change, but
if they are, I think that result would be surprising.

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

Re: Bug#1052004: libcbor: requires source-only upload to transition

[Holger Levsen]

On Fri, Sep 15, 2023 at 11:29:27PM +0200, Vincent Bernat wrote:
> What's the status of throwing away the binaries when doing a non-source-only
> upload? 

it's an existing feature of dak waiting to be enabled by ftp-master. I'd guess
that nowish would be a good time to enable it.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Do yo ever think about how capitalism is forcing us to work up until the
eminent extinction of our species as the earth heats to an unlivable
temperature? (@aishamadeit)


signature.asc
Description: PGP signature

sysadmin configuration of sparse-/etc vs prepopulated-/etc?

[Josh Triplett]

Sam Hartman wrote:
> Apropos of the discussion about removing default configuration from
> /etc.
> Upstream PAM now supports doing that.  You can set up a vendor directory
> such as /usr/lib where pam.d and security live.
> 
> I thought about doing that for Debian PAM, and have decided against.
> My rationale is that I actually think dpkg gives superior handling of
> upstream configuration changes to what we'd get with the pam vendor dir
> *in the specific case of PAM*.
> 
> In particular, dpkg will let you know if the conf file has changed
> upstream and you have local changes.
> If we create a vendor directory,  you will have to diff yourself to
> discover that.
> 
> I do think that in the case of programs like systemd that do a complex
> merge of drop in fragments, the split of vendor dir from sysadmin dir
> makes a lot of sense.
[...]
> I think we might be able to find dpkg-based solutions that are superior.

If we're talking about developing a solution that doesn't already exist,
why not have that solution *be* the
notification-and-diff/show-the-defaults mechanism you're describing? For
instance, provide a declarative mechanism to say "this file/directory in
/usr is the default version of this configuration file in /etc", with
standard schemes like 'merge' or 'override'", and then offer a tool
(similar to the existing systemd-delta but generalized) to show all the
configuration files that differ, as well as automatic support for
flagging changes on upgrades and suggesting a three-way merge (similar
to ucf)? With some care for convention-over-configuration, debhelper
could auto-populate this declarative data in many cases.

One advantage of this scheme is that everyone *can* get the behavior
they want, with configuration in a single place. We could easily have a
system-wide setting for whether you want all the defaults copied to /etc
so you can edit them in-place, versus never installing any of the
defaults files and leaving /etc sparse until you populate it. And it'd
be easy and safe to toggle between the two. (This is similar to the
systemd "vendor preset" mechanism, but again, generalized.) We can, of
course, have an epic argument about which should be the *default*
behavior, but hopefully the ability for everyone to get the behavior
they prefer would make that a little less *vigorous* than usual.

On top of that, people could extend this with other mechanisms. For
instance, it'd be feasible to integrate that with something like
etckeeper, making all the base configuration files into an "upstream"
git branch that needs merging into your system's etc, and letting people
use the full power of git merging and three-way diffs to resolve issues.

Something like this would be a lot more ideal than a Debian-specific
mechanism that only supports one scheme (sparse-/etc versus
prepopulated-/etc). And it'd be more ideal than the current state that
varies from package-to-package, where people who prefer sparse-/etc are
frustrated with packages that keep defaults in /etc, and people who
prefer prepopulated-/etc are frustrated with packages that keep defaults
only in /usr and leave /etc empty.

Perhaps we could get consensus around the idea that people want the
ability to make this choice, and packages should integrate with such a
mechanism rather than choosing on a package-by-package basis?

- Josh Triplett

Re: armhf NEON exception for chromium

[Andres Salomon]

On Fri, Sep 15 2023 at 03:00:05 PM -04:00:00, Andres Salomon 
 wrote:



On Fri, Sep 15 2023 at 08:30:20 PM +02:00:00, Paul Gevers 
 wrote:

Hi,

On 15-09-2023 17:52, Andres Salomon wrote:

Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is 
empty on

armel ci.debian.net workers. (I'm failing to spot neon in the list of
features of that machine.)

Paul

[1] 


Thanks for the heads-up!

Ugh, even with that fix (which was merged upstream today), it looks 
like when you have arm64 bare metal with a qemu armhf VM, neon 
doesn't get included in /proc/cpuinfo despite arm64 supporting it as 
part of the core architecture. So my plan to deal with autopkgtest 
won't work..



Actually it sounds like there's a lot of overlap with arm64's asimd, so 
maybe checking for 'neon' *or* 'asimd' is the way to go.

Re: armhf NEON exception for chromium

[Steve Langasek]

On Fri, Sep 15, 2023 at 10:15:53PM +0200, Paul Gevers wrote:
> Hi Steve,

> On 15-09-2023 21:54, Steve Langasek wrote:
> > armel != armhf

> Of course

> > and nobody should be running armel on a NEON-capable CPU...

> Not sure why you say it like that, I guess you don't meen CI purposes here.

I mean "no user should be choosing armel as the architecture for software to
run on a NEON-capable machine".  CI is something different.

> But anyways, it seems that also the arm64 host that runs our armel and armhf
> VM's doesn't have NEON in the feature list.

That sounds like a bug then since NEON is a required part of the ARMv8-A
ISA.[1]

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[1] 
https://developer.arm.com/documentation/102525/0100/Compiling-for-Neon-with-Arm-Compiler-6


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Steve Langasek]

On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> With the provision that I know next to nothing about pam - if I
> understood correctly how it works, why not simply do both? Ship the
> default file in the package under both /usr and /etc. Then, you get
> the semantics you want with local changes tracking, and /etc wins over
> the defaults. And we can have a working, bootable Debian container
> with only /usr. As far as I've been told, pam is the only blocker
> there - for a minimal image of course, but that's still quite a good
> achievement. Wouldn't this work, or am I missing something?

While I have applications downstream which also care about empty /etc, the
current situation is that this wouldn't help because almost all the
PAM application configs in Debian reference one or more of
common-{account,auth,password,session,session-noninteractive} which are
constructed at package install time and therefore are inappropriate to ship
in /usr.

Shipping the same file in both /usr and /etc from application packages seems
like it would be a reasonable workaround as far as it goes, but doesn't let
us empty /etc/pam.d.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: sysadmin configuration of sparse-/etc vs prepopulated-/etc?

[Marco d'Itri]

On Sep 16, Josh Triplett  wrote:

> If we're talking about developing a solution that doesn't already exist,
> why not have that solution *be* the
> notification-and-diff/show-the-defaults mechanism you're describing? For
> instance, provide a declarative mechanism to say "this file/directory in
> /usr is the default version of this configuration file in /etc", with
This is upcoming in a future systemd release, with a new tmpfiles.d(5) 
flag adding the semantics "this rule should be only considered on the
first boot".
("first boot" is a systemd term of art which has exactly the semantics 
that we need here.)

> standard schemes like 'merge' or 'override'", and then offer a tool
> (similar to the existing systemd-delta but generalized) to show all the
> configuration files that differ, as well as automatic support for
> flagging changes on upgrades and suggesting a three-way merge (similar
> to ucf)?
This is not, but it could be added on top of it by anybody interested.

> With some care for convention-over-configuration, debhelper
> could auto-populate this declarative data in many cases.
This is intriguing. :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: /usr/-only image

[Steve Langasek]

On Fri, Sep 15, 2023 at 07:44:45PM +0100, Luca Boccassi wrote:
> In fact, Marco yesterday told me the only blocker to boot a minimal
> Debian image with only /usr is PAM, and that's exclusively because of
> downstream-specific changes - upstream not only has supported the
> hermetic-usr config model for years, but the upstream maintainer is
> one of the main drivers of the generic effort at SUSE.

That's not accurate at all.  Debian carries no patches to the code for
handling paths to pam config files.

pam-auth-update is also not a "downstream change" to pam, it's integration
with the OS that has been done in /etc.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Marco d'Itri]

On Sep 15, Sam Hartman  wrote:

> But for the most part PAM appears to just override on a file-by-file
> basis.
Just like udev, kmod, dbus, etc...
PAM is not different.

> I have significant discomfort aligning what you say (pam is the last
> blocker) with what several people said earlier in the week.
> What I heard is that there was no project consensus to do this, and that
> people were running experiments to see what is possible.
Indeed. I did the experiments and they where unexpectedly positive:
pam is the only blocker for booting _the base system_.
I never expected that everything would immediately work just fine with 
an empty /etc: my goal is to have support for this in the base system 
and selected packages.

See for yourself:

mkdir /var/lib/machines/empty/
ln -s usr/bin usr/sbin usr/lib usr/lib64 /var/lib/machines/empty/
# this is a workaround for PAM
mkdir /var/lib/machines/empty/etc/
cp -a /etc/pam.d /etc/security /var/lib/machines/empty/etc/
# this is a workaround for https://github.com/systemd/systemd/issues/29185
echo ID=unknown > /var/lib/machines/empty/etc/os-release

systemd-nspawn --private-network --network-veth -b \
  --bind-ro=/usr --tmpfs=/var/ --tmpfs=/tmp/ \
  -D /var/lib/machines/empty/

You could add --tmpfs=/etc/ too, but then logins would fail.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Do not plan to support /usr/lib/pam.d for Debian pam

[Steve Langasek]

On Fri, Sep 15, 2023 at 03:17:42PM -0600, Sam Hartman wrote:
> Luca> And we can have a
> Luca> working, bootable Debian container with only /usr.

> I'm not actually convinced this is a good thing.
> (I don't think it's a bad thing--I just am not convinced it's something
> we should be working toward).
> I'd rather see project level discussion of this and a decision that is
> something we want.

> I have significant discomfort aligning what you say (pam is the last
> blocker) with what several people said earlier in the week.
> What I heard is that there was no project consensus to do this, and that
> people were running experiments to see what is possible.

> If I make a change in pam and we're suddenly at a place where  there are
> no blockers and we're moving forward, I think people in the project
> would understandably feel disenfranchised.
> To bystanders, "we're running experiments to see what's possible," means
> a decision is far off.

I agree with you that these sorts of changes should be discussed openly in
debian-devel, and plans talked about, before we get too far down the path.
Just as I advocated for when it came to DPKG_ROOT support in base packages.
I do not want to see the fact that maintainers of base packages have
individually decided it's worthwhile to support a thing, to be used to
strong-arm other maintainers into feeling they also have to support a thing
for which there may be no consensus.

However, I do not think that *reaching* a consensus about this being a good
thing needs to be a blocker for maintainers deciding to support it.  As
pointed out, there is nothing in Policy requiring any package to ship any
files in /etc, it's only required that if a user wants to change the
defaults for a package they should be able to do so via /etc (or /var).  If
it happens that all maintainers of base packages believe they can
satisfactorily meet the needs of their users to configure those packages
without shipping any default configs in /etc, those maintainers are free to
make such changes to support this, without waiting for project consensus.

Doing so doesn't penalize existing users and use cases of Debian (unless
the maintainer is wrong about meeting users' needs, or makes a hash of the
upgrade handling).  And it would allow Debian to be used in contexts where
it can't be today.  It's basically a win-win.

> I feel like if I were to fall in on this, I might be helping cause
> something to happen  at a technical level, bypassing discussion that I
> believe would be healthy for the project.
> I appreciate the value of doing work and  having people who  are willing
> to do the work have a larger share of power in the decision making.

I would like to see that discussion happen.  I don't think this thread is
that discussion, and I'm not stepping forward to drive it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

[idea]: Switch default compression from "xz" to "zstd" for .deb packages

[Hideki Yamane]

Hi,

 Today I want to propose you to change default compression format in .deb,
 {data,control}.tar."xz" to ."zst".

 I want to hear your thought about this.


# Compared to past change to xz proposal (in DebConf12)

  There are reasons why I propose this

  * More bandwidth
  * More CPUs
  * More storage bandwidth

## More bandwidth

 According to https://www.speedtest.net/global-index, broadband bandwidth
 in Nicaragua becomes almost 10x

 - 2012: 1.7Mbps
 - 2023: 17.4Mbps

 10x faster than past: it means that file size is not so much problem for us


## More CPUs

 2012: ThinkPad L530 has Core i5-3320M (2 cores, 4 threads)
 2023: ThinkPad L15 has Core i5-1335U (10 cores, 12 threads)

 https://www.cpubenchmark.net/compare/817vs5294/Intel-i5-3320M-vs-Intel-i5-1335U
  - i5-3320M: single 1614, multicore 2654
  - i5-1335U: single 3650, multicore 18076 points.

 And, xz cannot use multi core CPUs for decompression but zstd can.
 It means that if we use xz, we just get 2x CPU power, but change to zst,
 we can get more than 10x CPU power than 2012.

 It reduces a lot of time for package installation.

## More storage bandwidth

 SSD + PCIe 3/4/5 is enough, not be a blocker for decompression, now.


# Conclusion

  * More bandwidth
  * More CPUs
  * More storage bandwidth
  
+

  * Still limited: our resources (time!)


* So, if we change {data,control}.tar file format in .deb from xz to zst,
  we can reduce package installation time than ever since less decompression
  time. It saves our lifetime a bit :)

* Downside: package file size is a bit larger than now, but enough bandwidth
  will ease it for download time
  - Not sure how repository size will be, need an experiment




-- 
Hideki Yamane 

Bug#1052019: ITP: golang-github-gookit-color -- A command-line color library with 16/256/True color support

[Afeedh Shaji]

Package: wnpp
Severity: wishlist
Owner: Afeedh Shaji 

* Package name: golang-github-gookit-color
  Version : 1.5.4-1
  Upstream Author : Gookit
* URL : https://github.com/gookit/color
* License : Expat
  Programming Lang: Go
  Description : A command-line color library with 16/256/True color support

  This package provides the library for rendering colored outputs in terminal, 
supporting 8/16 colors, 256 colors, RGB color rendering output, and offering 
Print/Sprintf methods.

This package is in the dependency tree of lazygit (#908894)[1].

[1] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph

Re: /usr/-only image

[Gioele Barabucci]

On 15/09/23 20:44, Luca Boccassi wrote:

In fact, Marco yesterday told me the only blocker to boot a minimal
Debian image with only /usr is PAM


Related: For compat >= 14 dh_installpam will install PAM modules in 
/usr, not /etc:


https://salsa.debian.org/debian/debhelper/-/merge_requests/63

--
Gioele Barabucci