Bug#919984: ITP: r-cran-sys -- Powerful and Reliable Tools for Running System Commands in GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-sys
  Version : 2.1
  Upstream Author : Jeroen Ooms, Gábor Csárdi
* URL : https://cran.r-project.org/package=sys
* License : MIT
  Programming Lang: GNU R
  Description : Powerful and Reliable Tools for Running System Commands in 
GNU R
 Drop-in replacements for the base system2() function with fine control
 and consistent behavior across platforms. Supports clean interruption,
 timeout, background tasks, and streaming STDIN / STDOUT / STDERR over
 binary or text connections. Arguments on Windows automatically get
 encoded and quoted to work on different locales. On Unix platforms the
 package also provides functions for evaluating expressions inside a
 temporary fork. Such evaluations have no side effects on the main R
 process, and support reliable interrupts and timeouts. This provides the
 basis for a sandboxing mechanism.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-sys
This package is needed to upgrade r-cran-openssl to its latest upstream version.

Bug#919986: ITP: r-cran-askpass -- safe password entry for GNU R, Git, and SSH

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-askpass
  Version : 1.1
  Upstream Author : Jeroen Ooms
* URL : https://cran.r-project.org/package=askpass
* License : MIT
  Programming Lang: GNU R
  Description : safe password entry for GNU R, Git, and SSH
 Cross-platform utilities for prompting the user for credentials or a
 passphrase, for example to authenticate with a server or read a protected key.
 Includes native programs for MacOS and Windows, hence no 'tcltk' is required.
 Password entry can be invoked in two different ways: directly from R via the
 askpass() function, or indirectly as password-entry back-end for 'ssh-agent'
 or 'git-credential' via the SSH_ASKPASS and GIT_ASKPASS environment variables.
 Thereby the user can be prompted for credentials or a passphrase if needed
 when R calls out to git or ssh.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-askpass
This package is needed to upgrade r-cran-openssl to its latest upstream version.

Bug#919997: ITP: node-domino -- server-side DOM implementation based on Mozilla's dom.js

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-domino
  Version : 2.1.1
  Upstream Author : Felix Gnass 
* URL : https://github.com/fgnass/domino
* License : BSD-2-clause
  Programming Lang: JavaScript
  Description : server-side DOM implementation based on Mozilla's dom.js

 Domino provides a fast but insecure DOM in Node.js.
 .
 The Document Object Model (DOM)
 is a cross-platform and language-independent
 application programming interface
 that treats an HTML, XHTML, or XML document as a tree structure
 wherein each node is an object representing a part of the document.
 .
 Node.js is an event-based server-side JavaScript engine.

NB! Felix Gnass is the main _author_ only -
and The Mozilla Foundation is the main copyright holder.

This package will be maintained in the Debian JavaScript team

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxFu8YACgkQLHwxRsGg
ASEGXw//crSWPh5JcG2fA1w7nGOfYO9HQbNvHWN0tjP2gn90/aoJbvGMbMldMRAI
584yZVVx/u8UeV9/YW91JnXG1RSIlpZM4puoT+2nfoosAwSmDt0W4oAPycHAQnTs
zjRJrxtt29iBGbxbeWoaNxbf+lQfjrT0pMV0WemC8z+78Qy9Lb1qqZ322RBLTvLx
SLKFK0NpKQRkkmVvOXqwWUdibCqlUoGKXG5ZxeCccFC8P92k0N++/UqYCWNJ9I2F
wl/kKbHclT0olf/j2TLFFEAbE9evBJRDV1RwxKbN2v0nsKhENuhBnkCpp0uCypSI
O9D/bHWyvBSK71IXv89Nxij/FUKWhykc8Ki/OoUUclEgKthUoFLxnLGTrcloMOiI
Ti/QpjA7fd6419Rb11zvKzu59jW9jw82VETuATY+ITvVlCKZcd8qEF1CDWkw4ntX
4b6cHIEDjJUIfKA5iLRpLuH9v+waE28+RN8Gz3ObYKB/B+IG3UGkxhrzToMsIMIk
znzYQMp/lSQuk+KQgEXCVLFfFON29fbXnNOGFxOl9CmvCTAl8UxbsUXab/OpIcEU
btSNM/uGfkGLsFpySz7rGHgfCL6h4sUcuztv2yyKiPYEEefgYTCNBstRXoJIkfeO
gCoB4omVcy2WkI7esnx6+kqTmFNXW7LTlvvzVp+URaKjGxsUUv4=
=kF9I
-END PGP SIGNATURE-

Bug#920016: ITP: gst-plugins-rtp -- GStreamer libraries for handling RTP/RTCP streams on the network

[Marc Leeman]

Package: wnpp
Severity: wishlist
Owner: Marc Leeman 

* Package name: gst-plugins-rtp
  Version : 1.14.4.1
  Upstream Author : Marc Leeman 
* URL : https://github.com/mleeman/gst-plugins-rtp
* License : LGPL
  Programming Lang: C
  Description : GStreamer libraries for handling RTP/RTCP streams on the 
network

 GStreamer is a streaming media framework, based on graphs of filters
 which operate on media data.  Applications using this library can do
 anything from real-time sound processing to playing videos, and just
 about anything else media-related.  Its plugin-based architecture means
 that new data types or processing capabilities can be added simply by
 installing new plug-ins.
 .
 GStreamer RTP plugins provide elements that handle RTP streaming to
 and from the network and provide bindings to the rtp:// URI interface.
This message is subject to the following terms and conditions: MAIL 
DISCLAIMER

Bug#920036: ITP: libpmemobj-cpp -- C++ bindings to libpmemobj

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: libpmemobj-cpp
  Version : 1.5
  Upstream Author : Intel
* URL : https://pmem.io/pmdk/cpp_obj/
* License : BSD
  Programming Lang: C++
  Description : C++ bindings to libpmemobj
 The C++ bindings provide an easier to use (and thus less error prone
 version) of libpmemobj -- the persistent memory object store -- through
 the implementation of a pmem-resident property, persistent pointers,
 scoped and closure transactions, locking primitives and many others.

Bug#920040: ITP: waybar -- Highly customizable Wayland bar for Sway and Wlroots based compositors

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: waybar
  Version : 0.2.4
  Upstream Author : Alexis Rouillard
* URL : https://github.com/Alexays/Waybar/
* License : MIT
  Programming Lang: C
  Description : Highly customizable Wayland bar for Sway and Wlroots based 
compositors

Waybar is a highly customizable wayland bar for Sway and Wlroots based
compositors. It features applets displaying information about Sway
(Workspaces, Binding mode, Focused window name), Local time, Battery,
Network, Pulseaudio, Memory, Cpu load average and custom scripts

Re: Handling of entropy during boot

[Andy Simpkins]

Hi,

This thread seems to have gone quite for some time.  Re-Reading the
thread I don't see any solutions being proposed that will truly suit
everyone.

If I have correctly understood the problem we are seeing a change from a
more open and trusting software environment to one with more emphasis on
security that is also less trusting:
* More packages are requiring the use of the kernel's high quality
entropy pool (including aspects of the kernel itself)
* At the same time questions are being asked over how much we can trust
our entropy sources. There is no agreement of which sources we should
trust; this appears to be based upon a cultural perspective rather than
evidence based.
* Different platforms may have different entropy sources available to
them (think desktops, mobile devices, headless servers, small IoT
devices & virtualised instances)

What does this mean for Buster?

Some services may take a long time to start.  I am not talking about a
few seconds here, but instead minutes or even hours.  I myself see sshd
timing out and being restarted by systemd several times before finally
starting some 7 min after the rest of the system on my ARM64 Mustang
platform.  I have seen reports of taking literally several hours for all
services to start on some NAS boxes.

Unfortunately some services fail to start completely, others are
terminated and unlimited restart attempts are made.

In all cases, that I have seen, there is no mention of the reason for
the failed start being that there is insufficient entropy available.
This itself is a bug whatever your view on how to address lack of
available entropy during start-up.

We should at the very least state the reason a service has not started.
I believe that systemd has the ability to only start services when a
given event has happened (i.e. wait for network).  Should we be asking
for wait for “entropy pool > x bytes” before starting a given service?



Should we add to or change the possible entropy sources?

Increasing the number of different sources of entropy may well reduce
the time waiting for sufficient entropy, (although this is not an excuse
not to explain why a service has failed to start).

There has been some discussion about adding in further possible entropy
sources, and whether or not that source is enabled by default of not.
In general nobody appears to be arguing against having  the ability to
use additional entropy sources, the only debate is over which should be
enabled by default within debian.

This debate appears to boil down to ‘do I trust this source’ and it is
accepted that this is very much dependant upon what the installation is
going to be used for AND your geo-political leanings.  i.e. you may well
trust a HRNG for an Intel device if you are an American, but be less
inclined to trust one from China, and vice versa.

I don't think that we can OR SHOULD make a sensible decision for an out
of the box experience that will suitable for all users.
Perhaps instead we should consider a tool (to be included in DI as well
as just the archive) that can present the different options and allow
the user to decide?

If this is the way we as a project decide to go I would very much like
to be involved in this new package.  Such a tool is probably beyond my
ability to write, however I would be very happy to work on the design,
UI and testing.

Is this the right approach to take?

Best regards

Andy

Re: Handling of entropy during boot

[Ben Hutchings]

On Mon, 2019-01-21 at 20:49 +, Andy Simpkins wrote:
[...]
> Should we add to or change the possible entropy sources?
[...]

Yes, we should (by default) enable use of available hardware RNGs to
produce entropy and if none is available then we should (by default)
install one of the various software entropy gathering daemons.

We should also document this so that users that distrust certain
entropy sources will know how to disable them.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.




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

Bug#920145: ITP: libdate-tiny-perl -- date object, with as little code as possible

[Nick Morrott]

Package: wnpp
Owner: Nick Morrott 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdate-tiny-perl
  Version : 1.07
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/Date-Tiny
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : date object, with as little code as possible

Date::Tiny is a member of the DateTime::Tiny suite of time modules.

It implements an extremely lightweight object that represents a date, without
any time data.

Date::Tiny is recommended by Task::Kensho, a list of recommended modules for 
Enlightened Perl development maintained by the Enlightened Perl Organisation.

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

Re: Remainings of old versions of packages in UDD / tracker

[Andreas Tille]

On Thu, Jan 10, 2019 at 12:51:46PM +0100, Andreas Tille wrote:
> Hi Mattia,
> 
> On Thu, Jan 10, 2019 at 11:38:18AM +0100, Mattia Rizzolo wrote:
> > > using rmadison is a very quick way to notice this, as you will see the
> > > discrepancy in the architecture list.
> > 
> > I see that you started filing a lot of RM requests to remove many of
> > such outdated binaries.

This has settled for R packages now but I found another really strange one:

$ rmadison muparser | grep "unstable "
muparser   | 2.2.3-6| unstable   | source
muparser   | 2.2.6.1+dfsg-1 | unstable   | source

According to buildd[1] muparser was build on all architectures.  There is
a remaining version 2.2.3-6 and I have no idea why (neither why rmadison
does not list binaries).

Kind regards

  Andreas.


[1] https://buildd.debian.org/status/package.php?p=muparser

-- 
http://fam-tille.de