Bug#1051401: marked as done (general: PATH variable definition in debian 12)

[Debian Bug Tracking System]

Your message dated Tue, 19 Sep 2023 08:35:05 +0200 (CEST)
with message-id <10e42929-f4db-dc2d-ea8-cb9a8cfaf...@sourcepole.ch>
and subject line closing bug report
has caused the Debian Bug report #1051401,
regarding general: PATH variable definition in debian 12
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1051401: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051401
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal
X-Debbugs-Cc: robinhodges...@yahoo.co.uk

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


Had a problem when I installed debian 12 onto my PC. As root the reboot and 
shutdown commands wouldnt work.
I have solved this on my PC by including the following into the root .bashrc 
file

export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin


Thank you
--- End Message ---
--- Begin Message ---
I am closing this bug report since there was no answer a simple follow up 
question [1] in nearly two weeks.

*t

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051401#10--- End Message ---

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

[Thomas Goirand]

On 9/16/23 07:01, Hideki Yamane wrote:

* 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


Hi,

I'm not sure if we should switch to zstd, or if xz will do the work, 
though I'd be delighted if the dpkg performances could be improved. I'm 
spending all of my days installing server, sometimes with 1.5 TB of RAM 
and 128 core (AMD Epyc...), on last gen NVMe, using a local mirror, it's 
really painful to see how slow the debootstrap process is, compared to 
what it could be. Unpacking multiple .deb at the same time seems a very 
good idea to me, as well as parallelizing everything we can.


Just my 2 cents, as I wont be working on this,
Cheers,

Thomas Goirand (zigo)

Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libalien-base-modulebuild-perl
  Version : 1.17
  Upstream Contact: Joel A Berger 
* URL : https://metacpan.org/release/Alien-Base-ModuleBuild
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : subclass of Module::Build for building Alien:: modules and 
their libraries

 This is a subclass of Module::Build, that with Alien::Base allows for easy
 creation of Alien distributions. Alien::Base::ModuleBuild is used during the
 build step of your distribution. When properly configured it will
 use pkg-config to find and use the system version of the library
 download, build and install the library if the system does not provide it.
 .
 This module is in maintenance mode, use Alien::Build for new stuff.

-- 
Francesco P. Lovergine

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

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Thomas Goirand (2023-09-19 09:50:45)
> I'm not sure if we should switch to zstd, or if xz will do the work, though
> I'd be delighted if the dpkg performances could be improved. I'm spending all
> of my days installing server, sometimes with 1.5 TB of RAM and 128 core (AMD
> Epyc...), on last gen NVMe, using a local mirror, it's really painful to see
> how slow the debootstrap process is, compared to what it could be. Unpacking
> multiple .deb at the same time seems a very good idea to me, as well as
> parallelizing everything we can.

I was about to say that zdebootstrap by Adam Borowski used to be a thing four
years ago but now I see another commit from two days ago so maybe it's still
alive and usable?

https://git.sr.ht/~kilobyte/zdebootstrap

There is also my package mmdebstrap which gives you a Debian chroot a few times
faster than debootstrap does. Here are some benchmarks from my laptop:

| variant   | mmdebstrap | debootstrap  |
| - | -- |  |
| essential | 9.52 s | n.a  |
| apt   | 10.98 s| n.a  |
| minbase   | 13.54 s| 26.37 s  |
| buildd| 21.31 s| 34.85 s  |
| standard  | 23.01 s| 48.83 s  |

Depending on your use-case you might be interested in the essential or apt
variants which are even faster because they install less stuff than "minbase".

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1052225: ITP: greenbone-feed-sync -- script for syncing the Greenbone Community Feed

[Sophie Brun]

Package: wnpp
Severity: wishlist
Owner: Sophie Brun 
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: debian-devel@lists.debian.org, 
debian-security-to...@lists.debian.org, sop...@offensive-security.com

* Package name: greenbone-feed-sync
  Version : 23.8.0
  Upstream Contact: Björn Ricks 
* URL : https://github.com/greenbone/greenbone-feed-sync/
* License : GPL-3+
  Programming Lang: Python
  Description : script for syncing the Greenbone Community Feed

This package contains a new tool for downloading the Greenbone Community
Feed.
It is required for the recent versions of gvm* packages (Greenbone 
Vulnerability Manager).

I plan to maintain this package within the pkg-security-team.

Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

[Diederik de Haas]

Hopefully I'm not too late and I hope I won't make any ('dumb') mistakes as 
I'm not as well-versed in licenses and packaging as other participants.

On Sunday, 10 September 2023 18:16:07 CEST Russ Allbery wrote:
> > * The license is DFSG-free.
> > * Exactly the same license wording is used by all works covered by it.

I think both of these criteria are excellent.

> > * The license applies to at least 100 source packages in Debian.
> 
> In the thread so far, there's been a bit of early convergence around my
> threshold of 100 packages above.  I want to make sure people realize that
> this is a very conservative threshold that would mean saying no to most
> new license inclusion requests.

On Sunday, 10 September 2023 05:35:27 CEST Russ Allbery wrote:
> Here are various concerns that people have had in this area in the past.
> 
> * common-licenses consumes disk space on every installed Debian system of
>   any size, and therefore should be kept small to avoid wasting system
>   resources.

The only reason for not doing so that I've detected is worry about disk space? 
If we were talking about several Megabytes (or even larger) then I could see 
that point. But license text is max several Kilobytes?

diederik@bagend:/usr/share/doc$ find . -name copyright | wc -l
3759

I suspect I have an enormous amount of duplicate license texts on this system 
and replacing those with references to common-licenses will likely reduce the 
waste of system resources.

Optionally the license texts in common-licenses could be gz compressed (gzip 
is Priority: required) to reduce disk-space even further.

So I would be in favor of dropping the threshold.

> > * The license text is longer than 25 lines.

The primary reason I'm in favor of dropping this too is consistency.

On Sunday, 10 September 2023 05:35:27 CEST Russ Allbery wrote:
> Here are various concerns that people have had in this area in the past.
> 
> * Including long legal texts in debian/copyright, particularly if one
>   wants to format them for copyright-format, is tedious and annoying and
>   doesn't benefit our users in any significant way, and therefore we
>   should include as many licenses as possible in common-licenses to spare
>   people that work.

This is an important reason why I'd want to have most/all licenses that are 
used in Debian included in common-licenses.
It's not only tedious and annoying, but also (because of that) error prone. 
And then you run the risk of the included license text not being (word-for-
word) the same.
Getting rid of tedious/annoying/repeating busy work seems like a win for 
everyone.

And IMO it's not only not beneficial to our users, but actually provides extra 
work. If I want to make sure the license text is indeed the same as my 
(hopefully correct) local copy, I'd have to run a `diff` with the included text 
in the copyright file. And that applies to every user who'd want to do that. 
And also for a prospective (new) maintainer of a package.

I'm a (big) fan of SPDX because it simplifies and clarifies things (a lot IMO) 
and makes things more consistent. And I'm a sucker for consistency.

I do think that the license should be provided locally (and its availability 
not be dependent on a build step in some other tool).
Having a link to an online version may be a useful extra service, but having a 
working internet connection should not be a requirement (IMO).

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.

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

[Adam Borowski]

On Tue, Sep 19, 2023 at 11:39:49AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> I was about to say that zdebootstrap by Adam Borowski used to be a thing four
> years ago but now I see another commit from two days ago so maybe it's still
> alive and usable?
> 
> https://git.sr.ht/~kilobyte/zdebootstrap

At the moment, all it can do is unpack packages, but a blocker for even
continuing with dpkg would be registering triggers.

Other problems:
 * the base set includes diverts now; I would need to know them
   _beforehand_.  This means available from the control tarball, or
   preferably even Packages.  Shipping a list would notoriously get
   out of sync, thus is only an option for past packages.
 * parallel debootstrapping is for obvious reasons utterly incompatible
   with usrmerge or any other kind of random package sabotaging the layout
   behind dpkg's back.  When/if DEP17 gets implemented, such alias
   mangling would be doable but symlinks would still be a nasty thing.

I'd also need to see what Pre-Depends can't be cheated away; as far as
I've found so far, all are needed for upgrades or preinst, otherwise
degrading them to Depends is workable -- but potential for breakage is
huge.  Likewise cheating on preinst.

Also I'd really need to mark zdebootstrapped systems as tainted somehow,
as they wouldn't be trustworthy until a lot of polishing and testing is
done.

> There is also my package mmdebstrap which gives you a Debian chroot a few 
> times
> faster than debootstrap does. Here are some benchmarks from my laptop:
> 
> | variant   | mmdebstrap | debootstrap  |
> | - | -- |  |
> | essential | 9.52 s | n.a  |
> | apt   | 10.98 s| n.a  |
> | minbase   | 13.54 s| 26.37 s  |
> | buildd| 21.31 s| 34.85 s  |
> | standard  | 23.01 s| 48.83 s  |

That's so insanely bad...  if we only could put dpkg developers' time to
some productive task instead of you-know-what.  Even without breaking any
of current guarantees, you can easily:
 * parallelize unpack stages
 * replace the status database with something not terrible

WRT the second point: the only benefit of the current scheme is that, on a
filesystem that corrupts the data on crash even if you do everything right,
the user can do hail-mary manual recovery.  If you stop caring about ext2
and vfat, we can do much better.  And even dropping the flat text file
format wouldn't be required if we 1. extended the "updates" log, 2. didn't
rewrite the status file so often.  Of course, this would require all
readers to understand "updates" at which point we can just as well go with
a binary database, but it's not like good key-value stores are far between,
nor hard to devise from scratch.

It's depressing how lesser distributions can be so much faster, despite us
being supposed to be the bestest, prettiest, and so on :p


(I'd continue this discussion, but ATM stuck in Abu Dhabi for 14 hours
with no power source, then needing a week of sleep...)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up.  This
⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project.
⠈⠳⣄

Bug#1052240: ITP: pontos -- collection of utilities, tools, classes and functions for Greenbone Networks

[Sophie Brun]

Package: wnpp
Severity: wishlist
Owner: Sophie Brun 
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: debian-devel@lists.debian.org, 
debian-security-to...@lists.debian.org, sop...@offensive-security.com

* Package name: pontos
  Version : 23.9.0
  Upstream Contact: Greenbone AG 
* URL : https://github.com/greenbone/pontos
* License : GPL-3+
  Programming Lang: Python
  Description : collection of utilities, tools, classes and functions for 
Greenbone Networks

This package contains common utilities and tools maintained by Greenbone 
Networks.
It is a requirement for the new package greenbone-feed-sync (component of
Greenbone Vulnerability Manager).

I plan to maintain this package within the pkg-security-team.

Bug#1052244: ITP: python-colorful -- Python module for terminal string styling

[Sophie Brun]

Package: wnpp
Severity: wishlist
Owner: Sophie Brun 
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: debian-devel@lists.debian.org, sop...@offensive-security.com

* Package name: python-colorful
  Version : 0.5.5
  Upstream Contact: Timo Furrer 
* URL : https://github.com/timofurrer/colorful
* License : Exapt
  Programming Lang: Python
  Description : Python module for terminal string styling

This is a Python module for terminal string styling.
This is a requirement for pontos, a new package for GVM (Greenbone
Vulnerability Manager).

I plan to maintain this package within the python team.

Bug#1052246: ITP: node-vdom-to-html -- Node.js library to turn virtual-dom nodes into HTML

[Yadd]

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

* Package name: node-vdom-to-html
  Version : 2.3.1
  Upstream Contact: Nathan Tran 
* URL : https://github.com/nthtran/vdom-to-html
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to turn virtual-dom nodes into HTML

node-vdom-to-html turn virtual-dom nodes into HTML. virtual-dom is a
collection of modules designed to provide a declarative way of
representing the DOM.

This is a dependency of node-stdlib which is needed to build
node-jupyterlab. Will be maintained under JS Team umbrella.

Bug#1052262: ITP: obs-time-source -- Plugin for OBS Studio that displays current date and time

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-devel@lists.debian.org, Krystian Chachuła 


* Package name: obs-time-source
  Version : 0.1
  Upstream Contact: Krystian Chachuła <~krystianch/public-in...@lists.sr.ht>
* URL : 
https://obsproject.com/forum/resources/time-and-date-source.1781/
* License : GPL-3
  Programming Lang: C
  Description : Plugin for OBS Studio that displays current date and time

 This plugin provides a source that displays current date and time. It is
 possible to configure the time format, text font, background and text colors
 and outline in source properties.

Bug#1052276: ITP: jbig2enc -- encoder for JBIG2

[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: jbig2enc
  Version : 0.29
  Upstream Contact: https://github.com/agl/jbig2enc/issues
* URL : https://github.com/agl/jbig2enc
* License : Apache-2.0
  Programming Lang: C++
  Description : encoder for JBIG2

 jbig2enc is an encoder for JBIG2.
 .
 JBIG2 encodes bi-level (1 bpp) images
 using a number of clever tricks to get better compression than G4.
 This encoder can:
  * Generate JBIG2 files, or fragments for embedding in PDFs
  * Generic region encoding
  * Perform symbol extraction, classification and text region coding
  * Perform refinement coding and,
  * Compress multipage documents

This package is optionally used by ocrmypdf.
It will be maintained in the collaborative debian section of Salsa, at
.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUJ6jkACgkQLHwxRsGg
ASGyLw/9GCokfYiMAMMLLRZLA+auOpPNSPOWOATunsucWm1S9Z3Bbai0ELzaTyUM
E0lIf4KT+TjTMEk0aFgKMpQ6EbcGUPpjn3Rq/Zv/UuC+WZCPcWH7S9THuJ6K8HjJ
JamsKksLQ9F0atN48d/9iI57cOt96DL3je0Gcy5gj9ZaV3FpNRR3SahcL3w9Vy+M
W52R/JuWrHf8jRXwIXXltPvSQ5UmO22pVLvvN6RpB3n+k4SU4IhUHq8yj7DFlJ27
GIKBLJluWq0ZWJlBQVzwptQNMTSurdy4NuM3mzTOXjPNPw3LCMg5WzX3WDZCotTD
en4+qYj3oTiKrDL8ZBKAQzTtVxQupXlr0d0JYMGkzFCAAvCtBZDWR5lXYRcUWYKh
rlXtzReC7cecgeUh6YI/B0e+D4uW0mKzuwNMxu1E3Ol9vXYIQRS+4MEohRN602RF
qf6ertUoweMBKVf/8dQjCU+wsFjS1YU2X3JtDqU6b2mFTwdSSvylABLJyIAyvtYT
hUOEoXad1tfZtJM8LNasVYRHZpg675BKkdypS+asfj03xLT+HbJNCmxnzLTIkJZ+
avWqWHD8+nxwlv9pXKq9HEQx19/uD+FM+sEeyWuLX3oGDUO9RDIelVk6eQpxNSBm
ZRdAHgHaMK3/obUplNXzt9ohw5T5slv5SKUKZir68O3a6yecX5M=
=lc09
-END PGP SIGNATURE-

Bug#1052280: ITP: erlang-hex -- Package manager for the Erlang ecosystem

[John Lines]

Package: wnpp
Severity: wishlist
Owner: John Lines 
X-Debbugs-Cc: debian-devel@lists.debian.org, j...@paladyn.org

* Package name: erlang-hex
  Version : 2.0.5
* URL : https://github.com/hexpm/hex
* License : Apache-2.0
  Programming Lang: Elixir
  Description : Package manager for the Erlang ecosystem

Hex is package manager required to build Pleroma (a Federated
Social Media application).

It is primarily intended as a stepping stone towards a pleroma
package

Bug#1052291: ITP: r-cran-writexl -- GNU R package for export Excel xlsx format

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-writexl
  Version : 1.4.2
  Upstream Author : Jeroen Ooms 
* URL or Web page : https://cran.r-project.org/package=writexl
* License : BSD-2
  Description : GNU R package to write xlsx file

This zero-dependency export helper package is now a dependency of package rio
(aka r-cran-rio) which has been in Debian since May 2018.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

allow missing description fields and empty long descriptions for Rust/etc packages?

[Paul Wise]

Hi all,

I have noticed that almost all Rust packages in Debian have boilerplate
long descriptions that aren't very useful to Debian users. The only
useful info is the crate name, but that is also in the package name.

As far as I know they inherit this property from the upstream Rust
crates, which only have a synopsis or even no description at all.

Having the Rust team and other folks add non-upstream descriptions for
crates seems like not very useful work, since the Rust packages are
basically only used as build-deps and therefore have no human users.

So I would like to suggest Debian relax our requirements around binary
package descriptions, especially for Rust binary packages.

Does anyone object to this change?

Are apt/dpkg or the repo creation tools likely to need fixing?

Are there any other places that would need changes? (eg DDTP)

Are there any other ecosystems that this could apply to?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1052297: ITP: node-heya-globalize -- Convert JavaScript files using UMD or AMD global

[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-heya-globalize
  Version : 1.2.1
  Upstream Contact: Eugene Lazutkin 
* URL : https://github.com/heya/globalize
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Convert JavaScript files using UMD or AMD global

 The "heya-globalize" package is a tool that transforms JavaScript modules
 written in UMD Heya style or plain AMD style into different formats. It can
 generate JavaScript modules that utilize global browser dependencies and
 exports. These modules can be directly included in HTML pages using the
 

Re: allow missing description fields and empty long descriptions for Rust/etc packages?

[Jonas Smedegaard]

Quoting Paul Wise (2023-09-20 04:10:58)
> I have noticed that almost all Rust packages in Debian have boilerplate
> long descriptions that aren't very useful to Debian users. The only
> useful info is the crate name, but that is also in the package name.
> 
> As far as I know they inherit this property from the upstream Rust
> crates, which only have a synopsis or even no description at all.

Not quite true: Upstream Rust crates have no long description as part of
the crate manifest (i.e. in the Cargo.toml file), but such info is
commonly found upstream embedded in the main library file (i.e. near the
opp of src/lib.rs file) which is liftet out as part of upstream
documentation generation.

This is somewhat similar to how perl CPAN modules include POD
documentation - with the difference that upstream perl packaging tools
commonly lift out the embedded "long description" text and includes it
in an autogenerated README file (whereas upstream rust distributes that
documentation on a separate website.


> Having the Rust team and other folks add non-upstream descriptions for
> crates seems like not very useful work, since the Rust packages are
> basically only used as build-deps and therefore have no human users.
> 
> So I would like to suggest Debian relax our requirements around binary
> package descriptions, especially for Rust binary packages.
> 
> Does anyone object to this change?
> 
> Are apt/dpkg or the repo creation tools likely to need fixing?
> 
> Are there any other places that would need changes? (eg DDTP)
> 
> Are there any other ecosystems that this could apply to?

I find it useful to be able to read changelogs for Debian packages
offline, not only for packages containing user-facing ABIs.

Similarly I find it useful to search for relevant packages e.g. with
axi-cache search or apt-cache search, again not only for packages
containing user-facing ABIs.

I would find it sad if Debian "optimized" away this ability.

Personally I have not found it a too burdening work to grab
documentation from upstream unstructured sources, and occationally
update that information if it later changes.


 - Jonas

> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Re: allow missing description fields and empty long descriptions for Rust/etc packages?

[Julien Puydt]

Hi

Le mer. 20 sept. 2023, 04:11, Paul Wise  a écrit :

>
> So I would like to suggest Debian relax our requirements around binary
> package descriptions, especially for Rust binary packages.
>
> Does anyone object to this change?
>

Yes, definitely.

I know it is a pain to write those texts, but they are the most user-bound
part of packaging, and Debian is about user service.

I would be very surprised if the required information weren't available
somewhere in each and every rust package. Perhaps the ecosystem doesn't
have it in a specific and easy to extract automatically place. Perhaps the
packaging tools for rust crates don't know how to get it. But those are no
good reasons to stop looking for it for our users' benefit.

I would go as far as to say: open an upstream issue if someone just pushed
a pile of code out the door without even the shortest description!

Cheers,

J.Puydt

>

Bug#1052301: ITP: node-stdlib -- Standard library for JavaScript and Node.js

[Yadd]

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

* Package name: node-stdlib
  Version : 0.0.96
  Upstream Contact: The Stdlib Authors
  
* URL : https://github.com/stdlib-js/stdlib
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Standard library for JavaScript and Node.js

node-stdlib is a standard library for JavaScript and Node.js, with an
emphasis on numerical and scientific computing applications. The library
provides a collection of robust, high performance libraries for mathematics,
statistics, data processing, streams, and more and includes many utilities
expected from a standard library.

node-stdlib is a build dependency of node-jupyterlab. Will be maintained
under JS Team umbrella.