Bug#1011194: ITP: mkdocstrings-python-handlers -- Python handler for mkdocstrings

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

* Package name: mkdocstrings-python-handlers
  Version : 0.6.6
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/python
* License : ISC
  Programming Lang: Python
  Description : Python handler for mkdocstrings

 MkDocs is a fast, simple and downright gorgeous static site generator
 that's geared towards building project documentation. Documentation
 source files are written in Markdown, and configured with a single YAML
 configuration file.
 .
 This package contains a Python handler required by various helping libraries
 around mkdocstrings.

This package is a new direct dependency for mkdocstrings >= 0.18.0
because mkdocstrings got refactored into more dedicated libraries and
tools since version 0.18.0.
In detail mkdocstings-python-handlers is a dependency of
mkdocstings-python-legacy which is now required by mkdocstrings
>= 0.18.0.

It will be maintained within the Debian Python Team.


Bug#1011192: ITP: python-griffe -- Signatures for entire Python programs

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

* Package name: python-griffe
  Version : 0.18.0
  Upstream Author : Timothée Mazzucotelli 
* URL : https://github.com/mkdocstrings/griffe
* License : ISC
  Programming Lang: Python
  Description : Signatures for entire Python programs

 Extract the structure, the frame, the skeleton of your project,
 to generate API documentation or find breaking changes in your API.

This package is a new indirect dependency for mkdocstrings >= 0.18.0
because mkdocstrings got refactored into more dedicated libraries and
tools since version 0.18.0.
In detail python-griffe is a dependency of mkdocstings-python-handlers
which itself is a dependency of mkdocstrings-python-legacy.

It will be maintained within the Debian Python Team.


Bug#1011149: ITP: mogan -- structured editor for science and technology

2022-05-17 Thread Shengjing Zhu
Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 
X-Debbugs-Cc: debian-devel@lists.debian.org, z...@debian.org

* Package name: mogan
  Version : 1.0.3
  Upstream Author : Darcy Shen 
* URL : https://github.com/XmacsLabs/mogan
* License : GPL-3+
  Programming Lang: Tcl, Scheme, C++
  Description : structured editor for science and technology

Mogan Editor is a fork of GNU TeXmacs using S7 Scheme and Qt 5 with massive
online TeXmacs documents provided by Xmacs Planet and TMML wiki.
.
The software includes a text editor with support for mathematical formulas,
a small technical picture editor and a tool for making presentations from
a laptop. Moreover, Mogan can be used as an interface for many external
systems for computer algebra, numerical analysis, statistics, etc.
.
New presentation styles can be written by the user and new features can be
added to the editor using the Scheme extension language. A native spreadsheet
and tools for collaborative authoring are planned for later.
.
Mogan runs on all major Unix platforms and Windows. Documents can be
saved in TeXmacs, Xml or Scheme format and printed as Postscript or
Pdf files. Converters exist for TeX/LaTeX and Html/Mathml.



Re: use of Recommends by vlc to force users to use pipewire

2022-05-17 Thread Marvin Renich
* Marvin Renich  [220517 08:55]:
> I do not fully understand the relationships between the different sound
> servers, for example I think pulseaudio can use ALSA as one of its
> backends, but do I think that they all need to be co-installable without
 I do
> interfering with the operation of each other, because some applications



Re: use of Recommends by vlc to force users to use pipewire

2022-05-17 Thread Marvin Renich
* Vincent Lefevre  [220517 06:36]:
> On 2022-05-16 16:14:02 +, Bill Allombert wrote:
> > On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
> > > And for the record: you get pipewire installed because libpipewire-0.3-0
> > > recommends it.
> > 
> > For a similar situation, I advocated to add a apt option so that apt
> > only install Recommends of the packages on the command line, but not
> > Recommends of dependencies (and not Recommends of Recommends).
> > This would make recommends more usable but less deterministic.
> 
> So, if I understand correctly, this implies that if a package A needs
> package B and package B recommends package C, and if it happens that
> A needs C, then package A should also depend on or recommend C.
> 
> And what about upgrades? Should Recommends be checked only for
> manually installed packages?

I disagree with making Recommends non-transitive.  The problem is
incorrect use of Depends and Recommends.  This used to be a much bigger
problem; at least one large packaging group in the past had
intentionally abused Depends in metapackages because they felt too many
users had turned off automatic Recommends, and they were getting too
many bug reports about features not being available.  Turning off
automatic Recommends was (and still is, I think) common because too many
packages inflate the dependencies.  Inflating dependencies creates a
positive feedback loop, which will only end with the entire archive
using _Depends_ for everything.

The situation seems to be much better now, but it is still not as good
as it could be.

Let's analyze the Recommends in libpipewire-0.3.0.  First, the
definition of Recommends:

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

Because pipewire, pulseaudio, and ALSA each provide sound middleware,
and the user may have a preference for one of them, a number of
applications (e.g. mpd, obs-studio, and webcamoid-plugins) link the
libraries for all three sound servers.  Somehow they each choose which
library to use at runtime.

It is clear from this that libpipewire is commonly installed in
situations where pipewire is not only not used, but actually not
_wanted_.  Using Recommends is clearly wrong in this case, both from a
practical point of view and by any reasonable interpretation of Policy.

This same analysis, when applied to other situations, is why making
Recommends non-transitive is the wrong solution to the problem; fixing
the level of dependency is the right solution.

There is, unfortunately, a catch here.  In order for any of the
applications that require a sound server to work, one of them must be
installed.  For example, mpd links with libasound, libpipewire, and
libpulse.  If each of these libs simply provides the glue to another
package that provides the middleware and drivers, and for the reasons
stated above they each only Suggest their middleware package, then it is
possible for _none_ of the sound servers to be installed.

I do not fully understand the relationships between the different sound
servers, for example I think pulseaudio can use ALSA as one of its
backends, but do I think that they all need to be co-installable without
interfering with the operation of each other, because some applications
appear to only use pulseaudio and others only pipewire.  Clearly from
the original message in this thread, installing pipewire breaks at least
some setups when using VLC and ogg123.  This is definitely a bug, either
of severity "serious" (violates Debian Policy definition of
"Recommends") or "critical" (breaks other software).  But I think to
sort this out will require the sound server maintainers to come up with
a way for the user specify which sound server to use, and then have a
metapackage that forces at least one of them to be installed.

I think you (Vincent) are fully justified in filing a bug against
libpipewire of severity at least "serious", however it may take more
than just downgrading the Recommends to Suggests in order to straighten
this out correctly.

...Marvin



Bug#1011136: ITP: node-busboy -- Node.js module for parsing incoming HTML form data

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

* Package name: node-busboy
  Version : 1.6.0
  Upstream Author : Brian White 
* URL : https://github.com/mscdex/busboy
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js module for parsing incoming HTML form data

busboy is a Node.js module for parsing incoming HTML form data. It is a
highly used module, especially in node-express apps.

It's also a test dependency of node-undici (ITP #1010470), needed to
enable some Node.js features.



Re: use of Recommends by vlc to force users to use pipewire

2022-05-17 Thread Vincent Lefevre
On 2022-05-16 16:14:02 +, Bill Allombert wrote:
> On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
> > And for the record: you get pipewire installed because libpipewire-0.3-0
> > recommends it.
> 
> For a similar situation, I advocated to add a apt option so that apt
> only install Recommends of the packages on the command line, but not
> Recommends of dependencies (and not Recommends of Recommends).
> This would make recommends more usable but less deterministic.

So, if I understand correctly, this implies that if a package A needs
package B and package B recommends package C, and if it happens that
A needs C, then package A should also depend on or recommend C.

And what about upgrades? Should Recommends be checked only for
manually installed packages?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)