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

[Stephan Lachnit]

I think it's a good idea now that dpkg supports it [1]. Ubuntu already
did it years ago [2], and some non-deb based distros as well (e.g.
Fedora, Arch).

Cheers,
Stephan

[1]: https://bugs.debian.org/892664
[2]: https://balintreczey.hu/blog/hello-zstd-compressed-debs-in-ubuntu/

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

[Matthew Garrett]

On Fri, Sep 15, 2023 at 02:08:06PM -0600, 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.

What are other distributions doing here?

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

[Guillem Jover]

Hi!

On Sat, 2023-09-16 at 10:31:20 +0530, Hideki Yamane wrote:
> ## More bandwidth
> 
>  According to https://www.speedtest.net/global-index, broadband bandwidth
>  in Nicaragua becomes almost 10x
> 
>  - 2012: 1.7Mbps
>  - 2023: 17.4Mbps

Well that page still does not look too great for many other countries,
including with fixed broadband.

> ## 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.

That's not correct. dpkg-deb is doing multi-threaded xz decompression
since 1.21.13, and dpkg-source is doing multi-threaded xz compression
and decompression since 1.21.14.

Also the Ubuntu zstd implementation did not have multi-threaded support
at all, the one implemented in dpkg 1.21.18 does have explicit
multi-threaded support for _compression_, but AFIUI (from zstd code and
its API being used in libdpkg) not for decompression.

>  It reduces a lot of time for package installation.

> * 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

Thus these seem rather hand-wavy.

And in addition support for zstd at least in Debian seems rather poor:

  https://wiki.debian.org/Teams/Dpkg/DebSupport

(Support in dpkg was mainly added to overcome the schism that Ubuntu
had created in the .deb format. :/)

Thanks,
Guillem

Bug#1052045: ITP: rust-ed25519-dalek -- fast and efficient ed25519 EdDSA key handling

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-ed25519-dalek
  Version : 2.0.0
  Upstream Contact: isis agora lovecruft 
* URL : https://github.com/dalek-cryptography/curve25519-dalek
* License : BSD-3-clause
  Programming Lang: Rust
  Description : fast and efficient ed25519 EdDSA key handling

 ed25519-dalek is a fast and efficient Rust implementation
 of ed25519 key generation, signing, and verification.
 .
 Edwards-curve Digital Signature Algorithm (EdDSA)
 is a digital signature scheme
 using the elliptic curve Curve25519.

This package will be maintained in the collaborative debian section of
Salsa, at .
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUFtw0ACgkQLHwxRsGg
ASEMeA//V6RHC+y4TRyY4rUBxyRY0IXq7kj7FQhvOIt/jSrOx6Vc5yKFimb5Zd9n
QpJ98CQxuIpx+EGA5bX54iiQBrDzU/1gwJ1NS3KsugwN2/xzh67s3kbNgxMGDewl
JUntRsg1SI2en5P+ZqlQjtmlbqQuB7+9rVUsb6LSGxsnK842c3/0Y7tdNNomrNkH
TIUrhW0PKRdGjX3QtELsQlySotdUNp5i36UhRPOOz06ltTPWu9f23w8f5hfILd0Q
va2Rx76t7JpMafgL4MRoRr70HiiiPm5HGdLUk+pCrzUNLsv4kWKAOAFkC+dtda31
2wboqzReGhpu0eagZkxZtqRPpeGv4/0YWlwJwb1Xr5H/yMcIfa6OGTUDppCELk2a
HCdCb06MljwC9NK6wnyMg3gPhgL8JcYjeRwP8gymevOg4X5joE9l5NXFRaxGOBo/
JT7V9PlzR5lHajVYvX/B9lbqAwxhtXTgD4ntBZWZWNOzjSWUHPnLvG8FNRQaZYAs
cDsxQ8n8VYQlKbSEhNc8NXmbqhTX7DmvNNgitSM77su8dL5dIZ91r3kvxlTtquuy
MENFshzg5PSYjul0WP1PjI0nYnsx2EJf7HzHINiSkIZ+Oayx16KcMu59OFemuJm4
Pb/11kljMaI9ELf5MfZOXIFhnbM/rS077bC7QpxfTXlzZgfToP8=
=u5Ku
-END PGP SIGNATURE-

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

[Adam Borowski]

On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
>  Today I want to propose you to change default compression format in .deb,
>  {data,control}.tar."xz" to ."zst".

>  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

That's broadband, a lot of folks have nothing but crappy 5G.

I just happen to have a package converted to multiple formats on the disk
because I tested/benchmarked format 0.939 vs 2.0[1].  And:

  -h bytes
tar 5.5G5839735844
gz  897M 939926960
xz  375M 392874208
zst 774M 811105258

For this particular package zst gives over twice as big file.  You can pick
a stronger compression level but at that point we're just going up the
tradeoff curve.

> ## 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.

As someone with a 64-way amd64 desktop, and a purchased-but-not-delivered
64-core riscv64 box on the way, I understand the sentiment -- but, what
about parallelizing by unpacking multiple packages at the same time instead?
That's safer and doesn't cost compressing ratio[2].  I've prototyped this,
and even with current dpkg internals it shouldn't be hard to do (even if
dpkg runs keep switching between unpacking and configuring too often).

>  It reduces a lot of time for package installation.

There's a lot lot lot of other places in dpkg that could use a speedup, and
they don't come with such a tradeoff.  Especially fsync abuse: dpkg writes
all of its status every. single. step., fully. flushing. it. to. persistent.
storage. even. if. it's. a. dingy. SD. card.  So it does for every file it
unpacks; to a semi-ignorant onlooker it seems as if it uses some sort of
range coder just so it can fsync between fractional bits.

Even though there's no good generic way to ensure consistency of extracted
payload (POSIX lacks such API, you can use btrfs snapshots), at least the
dpkg state could win a lot by stopping assuming the limitations of ext2
apply to other filesystems.  On ext2 a crash may do unbounded damage to
the filesystem, using flat text files and fsyncs between every operation
improves recoverability, but any filesystem newer than that adds better
guarantees.  There are so many techniques that would avoid full state
rewrites...

> ## More storage bandwidth
> 
>  SSD + PCIe 3/4/5 is enough, not be a blocker for decompression, now.

So wishing Optane NVDIMMs didn't get cancelled... :/


On the other hand, we could switch the compression for _some_ packages.
There's stuff that gets unpacked by buildds over and over.  Compilers and
library headers are not used much by end-users on dingy connections (and
us hackers tend to prioritize computing device spending compared to regular
people), thus what about switching stuff that's 1. not in build-essential
but 2. in a set shared by many Build-Deps?



Meow!

[1]. https://lists.debian.org/debian-dpkg/2023/09/msg00014.html
[2]. Parallel compression, and especially decompression, is done by
 flushing and dropping old state every block.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line:
⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day."
⠈⠳⣄

Bug#1052054: ITP: node-sort-package-json -- Node.js library to sort package.json

[Yadd]

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

* Package name: node-sort-package-json
  Version : 2.5.1
  Upstream Contact: Keith Cirkel 
* URL : https://github.com/fisker/git-hooks-list
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to sort package.json

node-sort-package-json is a small library useful to sort package.json files
of Node.js modules, not in alphabetic order but in logical order (starting
by name and version).

It's a dependency of node-jupyterlab and will be maintained under JS
Team umbrella.

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

[M. Zhou]

Just one comment.

Be careful if it bloats up our mirrors. Is there any estimate on
the extra space cost for a full debian mirror?

If we trade-off the disk space with decompression speed, zstd -19
is not necessarily very fast. I did not benchmark, but it is slow.


On Sat, 2023-09-16 at 10:31 +0530, Hideki Yamane wrote:
> 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.

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> 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.

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

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


Yes, thanks for pointing this out.

--Sam

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

[Sam Hartman]

> "Josh" == Josh Triplett  writes:

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

Yeah, I was thinking about something like this.  But I think details
about where the vendor config lives should be part of the design work.
I.E.  we could accomplish roughly the same thing by taking the files
that packages populate into /etc as the vendor config and still meet the
standard unix assumptions of a populated /etc.

There are trade offs.  If you come from the place of believing that
supporting empty /etc is valuable, then what you propose is an obvious
way forward.
If you have not accepted that value proposition, I think you may be
closing off design space by going that route.

Like Steve, I do not want to drive the discussion, but like Steve, I do
think the discussion needs to happen.
I strongly encourage those who value empty /etc to drive such a
discussion and to explain to the project why we want that.

--Sam

Re: /usr/-only image

[Luca Boccassi]

On Sat, 16 Sept 2023 at 00:46, Steve Langasek  wrote:
>
> 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.

Perhaps 'modifications' was the wrong term, I meant the whole system
that handles the configuration. Correct me if I'm wrong, but AFAIK
that is all Debian-specific. Arch, Fedora and Suse do not have this
issue.

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

[Robert Edmonds]

M. Zhou wrote:
> Just one comment.
> 
> Be careful if it bloats up our mirrors. Is there any estimate on
> the extra space cost for a full debian mirror?
> 
> If we trade-off the disk space with decompression speed, zstd -19
> is not necessarily very fast. I did not benchmark, but it is slow.

Anecdotally, for "linux-image-6.5.0-1-amd64_6.5.3-1_amd64.deb" the
data.tar component takes 72 MB when compressed with xz -6, and 80 MB
when compressed with zstd -19, so about 10% larger with zstd.

This is specifically with multi-threaded compression. The behavior of
-T0 between xz and zstd is slightly different. (It looks like xz -T0
uses the number of threads supported by the CPU while zstd -T0 uses the
number of physical cores in the CPU.) The most direct multi-threaded
compression comparison between the two compressors was:

$ time xz -v -k -T0 -6 data.tar
data.tar (1/1)
  100 %71.9 MiB / 452.5 MiB = 0.15921 MiB/s   0:21

 Performance counter stats for 'xz -v -k -T0 -6 data.tar':

206,070.39 msec task-clock   #9.602 CPUs 
utilized
10,333  context-switches #   50.143 /sec
35  cpu-migrations   #0.170 /sec
73,502  page-faults  #  356.684 /sec
   925,351,049,292  cycles   #4.490 GHz
   945,596,486,369  instructions #1.02  insn per 
cycle
   106,039,632,660  branches #  514.580 M/sec
 6,702,750,057  branch-misses#6.32% of all 
branches

  21.460119122 seconds time elapsed

 205.460711000 seconds user
   0.567559000 seconds sys

Versus:

$ time zstd -T0 --auto-threads=logical -19 data.tar
data.tar : 17.54%   (   452 MiB =>   79.3 MiB, data.tar.zst)

 Performance counter stats for 'zstd -T0 --auto-threads=logical -19 data.tar':

293,120.46 msec task-clock   #8.649 CPUs 
utilized
21,754  context-switches #   74.215 /sec
78  cpu-migrations   #0.266 /sec
 9,806  page-faults  #   33.454 /sec
 1,317,565,940,985  cycles   #4.495 GHz
 1,430,204,017,430  instructions #1.09  insn per 
cycle
   266,246,644,005  branches #  908.318 M/sec
 5,762,322,300  branch-misses#2.16% of all 
branches

  33.889831439 seconds time elapsed

 292.501337000 seconds user
   0.56756 seconds sys


So, 71.9 MiB in 21 seconds for xz -6 versus 79.3 MiB in 34 seconds for
zstd -19. In other words, xz is 91% the size and 63% the wallclock time
of zstd here.

zstd decompression is much, much faster than xz decompression, but
apparently zstd does not support multi-threaded decompression while xz
does. Here xz decompresses in about 120% the wallclock time of zstd
(about 0.6 seconds for xz vs 0.5 seconds for zstd) but is only able to
perform that well by occupying most of the CPU:

$ time xzcat -v -T12 data.tar.xz > /dev/null
data.tar.xz (1/1)
  100 %71.9 MiB / 452.5 MiB = 0.159

 Performance counter stats for 'xzcat -v -T12 data.tar.xz':

  5,434.51 msec task-clock   #8.720 CPUs 
utilized
 1,187  context-switches #  218.419 /sec
22  cpu-migrations   #4.048 /sec
24,119  page-faults  #4.438 K/sec
24,311,239,346  cycles   #4.473 GHz
21,196,398,588  instructions #0.87  insn per 
cycle
 2,841,057,067  branches #  522.781 M/sec
   296,751,808  branch-misses#   10.45% of all 
branches

   0.623224953 seconds time elapsed

   5.304562000 seconds user
   0.127532000 seconds sys


$ time zstdcat -v -T12 data.tar.zst > /dev/null
Warning : decompression does not support multi-threading

 Performance counter stats for 'zstdcat -v -T12 data.tar.zst':

559.03 msec task-clock   #1.075 CPUs 
utilized
 4,245  context-switches #7.593 K/sec
 5  cpu-migrations   #8.944 /sec
 1,032  page-faults  #1.846 K/sec
 2,519,428,855  cycles   #4.507 GHz
 5,752,165,946  instructions #2.28  insn per 
cycle
   943,510,461  branches #1.688 G/sec
17,026,238  branch-misses#1.80% of all 
branches

   0.520219563 seconds time elapsed

   0.518084000 seconds user
   0.044177000 seconds sys

If xzcat is restricted to a single core the performance is

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

[Luca Boccassi]

On Sat, 16 Sept 2023 at 11:20, Matthew Garrett  wrote:
>
> On Fri, Sep 15, 2023 at 02:08:06PM -0600, 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.
>
> What are other distributions doing here?

I have been told by an upstream PAM maintainer, and by
Fedora/Suse/Arch folks at the image-based linux summit this week that
this is not an issue in their respective distros, and that the way
they ship the default PAM configuration works using only /usr.

Re: /usr/-only image

[Russ Allbery]

Luca Boccassi  writes:

> Perhaps 'modifications' was the wrong term, I meant the whole system
> that handles the configuration. Correct me if I'm wrong, but AFAIK that
> is all Debian-specific. Arch, Fedora and Suse do not have this issue.

Speaking as the author of several PAM modules, Debian's PAM configuration
system is also vastly superior to that of Arch, Fedora, and SuSE, which
require that I as upstream provide complicated and tedious installation
documentation for how people can configure my modules.  It's a stark
contrast with Debian, where I can just ship a configuration file and have
everything happen automatically and correctly despite requiring some quite
complex PAM syntax.

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

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

[Russ Allbery]

Marco d'Itri  writes:
> On Sep 15, Sam Hartman  wrote:

>> 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.

This started as an experiment: you were going to try running the base
system in this mode with existing packages and see what happens.  You ran
that experiment and got results: it doesn't work, but it appears to only
work because of PAM.  So far, so good.  You ran an experiment, the result
was that the thing you want to do doesn't work, and now you understand
what changes would be required to move forward.

However, and this is very important, *no one has decided that you get to
do that work in Debian*.

Insofar as this is just a personal goal, sure, that's none of the business
of anyone else.  But if you want this to be a *project* goal, you're
skipping a few important steps.

The biggest ones is that there is no *plan* and no *agreement*.  By plan,
I mean an actual document spelling out in detail, not email messages with
a few sentences about something that is familiar to you but not to other
people who haven't been thinking about this, what base system support
would look like.  And by agreement, I mean that the maintainers of base
system components agree that this is something that we are working towards
as a project and something that they would not break lightly.

Right now, any base system package maintainer could decide that putting
configuration files in /etc makes sense for reasons of their own limited
to their specific package and further break support for booting a system
in this mode, and there are no grounds to ask them not to do this.
Because you don't have an *agreement*.

I feel like there is a tendency to consider work on Debian to be purely
technical.  If you turn it on and smoke doesn't come out, it works, so we
have implemented that thing, and the goal is accomplished.  This doesn't
work, precisely because other people break your goal later (because they
were never asked or never agreed with that goal), and then they are very
confused about why you're upset and why your problems are now their
problems.  Or, worse, their packages are broken as collateral damage in
accomplishing some goal, and you then argue that it's their problem to fix
their packages, even though there was no agreement about that goal.

Accomplishing things like this in Debian has a large social component that
I think is being neglected.

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

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

[Steve Robbins]

It would be lovely to get this enabled!  It's a pain point for me also, on
occasion.

-Steve

Bug#1052071: ITP: node-esniff -- Low footprint JavaScript source code parser

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: node-esniff
  Version : 1.1.0
  Upstream Contact: Mariusz Nowak 
* URL : https://github.com/medikoo/esniff
* License : MIT
  Programming Lang: javascript
  Description : Low footprint JavaScript source code parser


Tool that allows you to analyze ECMAScript (JavaScript) code efficiently
 and with low resource usage. The main objective is to examine the JavaScript
 source code for various information such as accessed properties, dependencies,
 and other code-related details.
 .
 Here are some of the key features and functionalities of the project:
  - Code Analysis: “esniff” is capable of analyzing ECMAScript source code and
providing detailed information about how the code is structured.
  - Detection of accessed properties: Can identify properties that are accessed
in the code by providing a list of the properties and their locations in the
source code.
  - Dependency Detection: The project is useful for identifying code
dependencies by telling which other modules or libraries the code
uses.
  - Efficient use of resources: "esniff" is designed to consume few resources,
making it suitable for large-scale analysis of JavaScript code
  - Compatibility: It is compatible with the ECMAScript specification and can be
used to parse modern JavaScript code.

Performance counter stats Was Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

[Lee]

On 9/16/23, Robert Edmonds wrote:

> $ time xz -v -k -T0 -6 data.tar
> data.tar (1/1)
>   100 %71.9 MiB / 452.5 MiB = 0.15921 MiB/s   0:21
>
>  Performance counter stats for 'xz -v -k -T0 -6 data.tar':
>
> 206,070.39 msec task-clock   #9.602 CPUs
> utilized
> 10,333  context-switches #   50.143 /sec
> 35  cpu-migrations   #0.170 /sec
> 73,502  page-faults  #  356.684 /sec
>925,351,049,292  cycles   #4.490 GHz
>945,596,486,369  instructions #1.02  insn per
> cycle
>106,039,632,660  branches #  514.580 M/sec
>  6,702,750,057  branch-misses#6.32% of all
> branches
>
>   21.460119122 seconds time elapsed
>
>  205.460711000 seconds user
>0.567559000 seconds sys

What did you do to get the "Performance counter stats" section in the
results for time?

TIA,
Lee

Re: Performance counter stats Was Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

[Robert Edmonds]

Lee wrote:
> What did you do to get the "Performance counter stats" section in the
> results for time?

alias time="perf stat"

-- 
Robert Edmonds
edmo...@debian.org

Bug#1052075: ITP: node-speech-rule-engine -- NodeJS version of the ChromeVox speech rule engine

[Yadd]

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

* Package name: node-speech-rule-engine
  Version : 3.2.2
  Upstream Contact: Volker Sorge 
* URL : https://github.com/zorkow/speech-rule-engine
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : NodeJS version of the ChromeVox speech rule engine

node-speech-rule-engine (SRE) can translate XML expressions into speech
strings according to rules that can be specified in a syntax using Xpath
expressions.

It's a dependnecy of node-mathjax-full, needed to build node-jupyterlab.
Will be maintained under JS Team upbrella.

Bug#1052076: ITP: node-mathjax-full -- JavaScript library to display math in browsers

[Yadd]

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

* Package name: node-mathjax-full
  Version : 3.2.2
  Upstream Contact: The MathJax Consortium
  
* URL : https://github.com/mathjax/Mathjax-src
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : JavaScript library to display math in browsers

MathJax is an open-source JavaScript display engine for LaTeX, MathML,
and AsciiMath notation that works in all modern browsers. It was
designed with the goal of consolidating the recent advances in web
technologies into a single, definitive, math-on-the-web platform
supporting the major browsers and operating systems.  It requires no
setup on the part of the user (no plugins to download or software to
install), so the page author can write web documents that include
mathematics and be confident that users will be able to view it
naturally and easily.  Simply include MathJax and some mathematics in
a web page, and MathJax does the rest.

node-mathjax-full is a dependency of node-jupyterlab. It will be
maintained under JS Team umbrella.

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

[Hideki Yamane]

On Sat, 16 Sep 2023 13:34:02 +0200
Guillem Jover  wrote:
> That's not correct. dpkg-deb is doing multi-threaded xz decompression
> since 1.21.13, and dpkg-source is doing multi-threaded xz compression
> and decompression since 1.21.14.
> 
> Also the Ubuntu zstd implementation did not have multi-threaded support
> at all, the one implemented in dpkg 1.21.18 does have explicit
> multi-threaded support for _compression_, but AFIUI (from zstd code and
> its API being used in libdpkg) not for decompression.

 Thank you, that was my fault, correct information is very welcoming.
 
 Is there any plan to improve zstd implementation in dpkg?


-- 
Hideki Yamane 

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

[Hideki Yamane]

On Sat, 16 Sep 2023 14:25:48 -0400
"M. Zhou"  wrote:
> Be careful if it bloats up our mirrors. Is there any estimate on
> the extra space cost for a full debian mirror?

 Yes, sure, I'll do some experiment for it later.
 Thank you for your comment!


-- 
Hideki Yamane 

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

[Marco d'Itri]

On Sep 16, Russ Allbery  wrote:

> However, and this is very important, *no one has decided that you get to
> do that work in Debian*.
I am confident that I have never said otherwise.

> Right now, any base system package maintainer could decide that putting
> configuration files in /etc makes sense for reasons of their own limited
> to their specific package and further break support for booting a system
> in this mode, and there are no grounds to ask them not to do this.
> Because you don't have an *agreement*.
I think that I am allowed to ask all I want at any time (severity: 
wishlist), but they can also choose to not care.

> Accomplishing things like this in Debian has a large social component that
> I think is being neglected.
After having initiated a few things like this in Debian I suspect that 
I am beginning to understand why this may happen.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Marco d'Itri]

On Sep 16, Steve Langasek  wrote:

> 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.
Actually it would still help a lot, because pam-auth-update can be run 
on the first boot to rebuild the /etc/pam.d/*common-* files.

-- 
ciao,
Marco


signature.asc
Description: PGP signature