Bug#1009811: ITP: python-pcre -- Python bindings for the Perl Compatible Regex Engine

2022-04-18 Thread Jelmer Vernooij
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-pcre
  Version : 0.7
  Upstream Author : Name 
* URL : https://github.com/awahlig/python-pcre
* License : BSD-3
  Programming Lang: Python, C
  Description : Python bindings for the Perl Compatible Regex Engine

This Python module provides bindings for PCRE, useful in situations
where strict compatibility is necessary.



Bug#1009817: ITP: liblist-keywords-perl -- selection of list utility keywords

2022-04-18 Thread gregor herrmann
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: liblist-keywords-perl
  Version : 0.08
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/List-Keywords
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : selection of list utility keywords

List::Keywords provides keywords that behave (almost) identically to familiar
functions from List::Util, but implemented as keyword plugins instead of
functions. As a result these run more efficiently, especially in small code
cases.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature


Re: Concerns about Security of packages in Debain OS and the Operating system itself.

2022-04-18 Thread Stephan Verbücheln
> i did the analysis (took 3 weeks)

Do you have a publication of that analysis? I was thinking the same
about the organization of Debian for some time but never did analysis
or compared it to other distros.

Also I like to add that reproducible builds are an excellent addition
to the mechanisms you are describing.

Regards 



Firmware - what are we going to do about it?

2022-04-18 Thread Steve McIntyre
TL;DR: firmware support in Debian sucks, and we need to change this. See the
"My preference, and rationale" Section below.

In my opinion, the way we deal with (non-free) firmware in Debian is a mess,
and this is hurting many of our users daily. For a long time we've been
pretending that supporting and including (non-free) firmware on Debian systems
is not necessary. We don't want to have to provide (non-free) firmware to our
users, and in an ideal world we wouldn't need to. However, it's very clearly no
longer a sensible path when trying to support lots of common current hardware.

Background - why has (non-free) firmware become an issue?
=

Firmware is the low-level software that's designed to make hardware devices
work. Firmware is tightly coupled to the hardware, exposing its features,
providing higher-level functionality and interfaces for other software to use.
For a variety of reasons, it's typically not Free Software.

For Debian's purposes, we typically separate firmware from software by
considering where the code executes (does it run on a separate processor? Is it
visible to the host OS?) but it can be difficult to define a single reliable
dividing line here. Consider the Intel/AMD CPU microcode packages, or the
U-Boot firmware packages as examples.

In times past, all necessary firmware would normally be included directly in
devices / expansion cards by their vendors. Over time, however, it has become
more and more attractive (and therefore more common) for device manufacturers
to not include complete firmware on all devices. Instead, some devices just
embed a very simple set of firmware that allows for upload of a more complete
firmware "blob" into memory. Device drivers are then expected to provide that
blob during device initialisation.

There are a couple of key drivers for this change:

  • Cost: it's typically cheaper to fit smaller flash memory (or no flash at
all) onto a device. The cost difference may seem small in many cases, but
reducing the bill of materials (BOM) even by a few cents can make a
substantial difference to the economics of a product. For most vendors,
they will have to implement device drivers anyway and it's not difficult to
include firmware in that driver.

  • Flexibility: it's much easier to change the behaviour of a device by simply
changing to a different blob. This can potentially cover lots of different
use cases:

  □ separating deadlines for hardware and software in manufacturing
(drivers and firmware can be written and shipped later);
  □ bug fixes and security updates (e.g. CPU microcode changes);
  □ changing configuration of a device for different users or products
(e.g. potentially different firmware to enable different frequencies on
a radio product);
  □ changing fundamental device operation (e.g. switching between RAID and
JBOD functionality on a disk controller).

Due to these reasons, more and more devices in a typical computer now need
firmware to be uploaded at runtime for them to function correctly. This has
grown:

  • Going back 10 years or so, most computers only needed firmware uploads to
make WiFi hardware work.

  • A growing number of wired network adapters now demand firmware uploads.
Some will work in a limited way but depend on extra firmware to allow
advanced features like TCP segmentation offload (TSO). Others will refuse
to work at all without a firmware upload.

  • More and more graphics adapters now also want firmware uploads to provide
any non-basic functions. A simple basic (S)VGA-compatible framebuffer is
not enough for most users these days; modern desktops expect 3D
acceleration, and a lot of current hardware will not provide that without
extra firmware.

  • Current generations of common Intel-based laptops also need firmware
uploads to make audio work (see the firmware-sof-signed package).

At the beginning of this timeline, a typical Debian user would be able to use
almost all of their computer's hardware without needing any firmware blobs. It
might have been inconvenient to not be able to use the WiFi, but most laptops
had wired ethernet anyway. The WiFi could always be enabled and configured
after installation.

Today, a user with a new laptop from most vendors will struggle to use it at
all with our firmware-free Debian installation media. Modern laptops normally
don't come with wired ethernet now. There won't be any usable graphics on the
laptop's screen. A visually-impaired user won't get any audio prompts. These
experiences are not acceptable, by any measure. There are new computers still
available for purchase today which don't need firmware to be uploaded, but they
are growing less and less common.

Current state of firmware in Debian
===

For clarity: obviously not all devices need extra firmware uploading like this.

Bug#1009849: ITP: node-cliclopts -- CLI options helper and usage printer

2022-04-18 Thread Michael Ikwuegbu
Package: wnpp
Severity: wishlist
Owner: Michael Ikwuegbu 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-cliclopts
  Version : 1.1.1
  Upstream Author  : Finn Pauls
* URL  : https://github.com/finnp/cliclopts
* License : Expat
  Programming Lang: JavaScript
  Description: CLI options helper and usage printer
Cliclopts is a library that provides command line options for users.
.
Node.js is an event-based server-side JavaScript engine.


Re: Firmware - what are we going to do about it?

2022-04-18 Thread Ansgar
Hi,

On Tue, 2022-04-19 at 01:27 +0100, Steve McIntyre wrote:
> TL;DR: firmware support in Debian sucks, and we need to change this.

Thanks for proposing changes here.

>  5. We could split out the non-free firmware packages into a new
>     non-free-firmware component in the archive [...]

> What would I choose to do? My personal preference would be to go with
> option 5: split the non-free firmware into a special new component
> and include that on official media.

Having proposed that in the past that is also my preference (unless
someone should come up with a better idea).

> Does that make me a sellout? I don't think so.

I simply see this as a change how non-free software is delivered. To
me, it doesn't make much difference whether non-free firmware comes
preinstalled on a ROM or is loaded by the kernel as a blob and just
pushed to the device: the firmware is the same; it doesn't become more
or less free depending how it is loaded.

Users just /see/ more easily that their device uses non-free firmware
if the kernel states it loads it / is visible in the filesystem.

(This assumes that all firmware we include is at least freely
redistributable and licenses not specific to Debian, but I think that
is the case. Maybe we should make that an explicit requirement for
firmware in non-free-firmware.)

Ansgar