Bug#919367: ITP: omemo-backend-signal -- backend for python-omemo offering compatibility with libsignal

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" 

* Package name: omemo-backend-signal
  Version : 0.2.2
  Upstream Author : Tim Henkes 
* URL : https://pypi.org/project/omemo-backend-signal/
* License : GPL-3
  Programming Lang: Python
  Description : backend for python-omemo offering compatibility with 
libsignal

This library implements a backend for python-omemo offering
compatibility with libsignal (C, Java, JavaScript). Look at python-omemo
for further usage information.

This package is needed for future version of salutatoi.

Debian Bug Squashing Party (BSP) in Bratislava, Slovakia: 9—10 February 2019

[Andrej Shadura]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

There will be a bug squashing party in Bratislava on the same dates as
in Berlin, which is 9—10 February 2019. So if Berlin is too far for you
to come to for a weekend, consider coming to Bratislava. (Actually, I
think it may be worth creating a common IRC channel to co-ordinate.)

The venue is yet to be determined (there’s a choice between two
depending on the number of people).

Please confirm your attendance here:

https://framadate.org/debian-bsp-bratislava-2019-02

Or, alternatively, by email to me.

[0]: https://wiki.debian.org/BSP/2019/02/sk/Bratislava

- -- 
Cheers,
  Andrej
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAlw9sA0ACgkQXkCM2RzY
OdIO1wgAiB48/QF32QEelOZEfyt6KEVQwsDE6S9Xq8P36ND/sdXOjfAwUw/hnVO8
WBRwDXcSUSocA0u1b1tJMdXEwnwKmKhxk0RvF9zb1M6lxG8DiMvYBfQsD/crUCjL
kYROVpjWdHltKCL42Bp5eE9Jx87uW+VXbc2xYK+89qC9RHShJ/dUTix4aD0ikoCI
h1VSAdlMh6ev8tOYv3O1fEsq7magcQxsPlloaaQOBbdqT8C9PRazjKA0J9ijEXon
dTDjSevLznfOnnh+ja06GHL0lGiY6YwL1UkCIaUOON3li3l4Qymshzgd9SZDd+vH
GH9I+uM0SkcbDPuFHvdhGZMzDBaU7w==
=DsEH
-END PGP SIGNATURE-

Bug#919378: ITP: libtest-bits-perl -- Perl module for for testing binary data

[Florian Schlichting]

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

* Package name: libtest-bits-perl
  Version : 0.02
  Upstream Author : Dave Rolsky 
* URL : https://metacpan.org/release/Test-Bits
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl module for for testing binary data

Test::Bits provides a single subroutine, bits_is(), for testing binary data.

This module is quite similar to Test::BinaryData and Test::HexString in
concept. The difference is that this module shows failure diagnostics in a
different way, and has a slightly different calling style. Depending on the
nature of the data you're working with, this module may be easier to work
with.

In particular, when you're doing a lot of bit twiddling, this module's
diagnostic output may make it easier to diagnose failures. A typical failure
diagnostic will look like this:

The two pieces of binary data are not the same length (got 2, expected 3).

Binary data begins differing at byte 1.

Got: 0000

Expect: 0001

The package will be maintained under the umbrella of the Debian Perl Group.
It is part of the dependency chain for GeoIP2.

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

Bug#919380: ITP: r-cran-globaloptions -- Generate Functions to Get or Set Global Options

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: r-cran-globaloptions
* URL : 
https://cran.r-project.org/web/packages/GlobalOptions/index.html
* License : MIT
  Programming Lang: R
  Description : Generate Functions to Get or Set Global Options

To be team-maintained on 
https://salsa.debian.org/r-pkg-team/r-cran-globaloptions

Profesjonalne Strony i Sklepy internetowe.

[Strony, sklepy internetowe.]

Dzień dobry,



tworzymy nowoczesne */Stron i Sklepów WWW.
/*


Jeżeli chcieliby Państwo otrzymać propozycję w tym zakresie dla Państwa firmy 
prosimy o odpowiedź "*TAK"*.







Serdecznie Pozdrawiamy

Bug#919386: ITP: r-cran-circlize -- Circular Visualization

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: r-cran-circlize
  Version : 0.4.5
* URL : https://cran.r-project.org/web/packages/circlize/
* License : MIT
  Programming Lang: R
  Description : Circular Visualization

To be team-maintained at https://salsa.debian.org/r-pkg-team/r-cran-circlize

Bug#919400: ITP: libnet-works-perl -- Perl module providing improved APIs for IP addresses and networks

[Florian Schlichting]

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

* Package name: libnet-works-perl
  Version : 0.22
  Upstream Author : Dave Rolsky  Greg Oschwald 
 Olaf Alders 
* URL : https://metacpan.org/release/Net-Works
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module providing improved APIs for IP addresses and 
networks

The NetAddr::IP module is very complete, correct, and useful. However, its
API design is a bit crufty. Net::Works provides an alternative API that aims
to address the biggest problems with that module's API, as well as adding
some additional features.

This distro contains two main modules, Net::Works::Address and
Net::Works::Network.

NOTE: This distro's APIs are still in flux. Use at your own risk.

The package will be maintained under the umbrella of the Debian Perl Group.
It is part of the dependency chain for GeoIP2.

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

Bug#919401: ITP: libmath-int128-perl -- Perl module to anipulate 128 bits integers

[Florian Schlichting]

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

* Package name: libmath-int128-perl
  Version : 0.22
  Upstream Author : Salvador Fandino  Dave Rolsky 

* URL : https://metacpan.org/release/Math-Int128
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to anipulate 128 bits integers

Math::Int128 adds support for 128 bit integers, signed and unsigned, to Perl.

The API is comparable to Math::Int64, just s/64/128/g ;-)

Besides that, as object allocation and destruction has been found to be a
bottleneck, an alternative set of operations that use their first argument as
the output (instead of the return value) is also provided.

The package will be maintained under the umbrella of the Debian Perl Group.
It is part of the dependency chain for GeoIP2.

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

Re: [MBF] Moving mountnfs.sh script to runlevel 2

[Dmitry Bogatov]

[2019-01-13 16:47] Ansgar 
> Dmitry Bogatov writes:
> > [...]
> > I ask corresponding maintainers (list at bottom of email) to either
> >  * move their scripts to runlevel (2 3 4 5) [preferred]
> >  * remove dependency on $remote_fs, if all they need is /usr
> >  * replace with dependency on `mountall', if they need 
> >one of (/run /dev/shm /tmp)
> 
> What will happen on systems where users changed the configuration files
> and these changes are not applied automatically?

If I correctly understand your question, answer is:

If users (admins) changed scripts in /etc/init.d/*, then on upgrade they
will be proposed to merge changes, since initscripts are conffiles.

Given feedback, I apologize, that I did not mentioned in inital email,
that I do /not/ intend/hope to resolve this issue before buster release.
I just follow mass-bug-filling procedure.

PS. Please keep me in CC, I am not subscribed to debian-devel@.


pgpiAPGrWquSk.pgp
Description: PGP signature

Bug#919403: ITP: r-cran-rpact -- Confirmatory Adaptive Clinical Trial Design and Analysis

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-rpact
  Version : 1.0.0
  Upstream Author : Gernot Wassmer, Friedrich Pahlke
* URL : https://cran.r-project.org/package=rpact
* License : GPL-3
  Programming Lang: GNU R
  Description : Confirmatory Adaptive Clinical Trial Design and Analysis
 Design and analysis of confirmatory adaptive clinical trials with
 continuous, binary, and survival endpoints according to the methods
 described in the monograph by Wassmer and Brannath (2016). This
 includes classical group sequential as well as multi-stage adaptive
 hypotheses tests that are based on the combination testing principle.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-rpact

Bug#919404: ITP: libdata-ieee754-perl -- Perl module to pack and unpack big-endian IEEE754 floats and doubles

[Florian Schlichting]

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

* Package name: libdata-ieee754-perl
  Version : 0.02
  Upstream Author : Dave Rolsky 
* URL : https://metacpan.org/release/Data-IEEE754
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl module to pack and unpack big-endian IEEE754 floats 
and doubles

Data::IEEE754 provides some simple convenience functions for packing and
unpacking IEEE 754 floats and doubles.

Currently this module only implements big-endian order. Patches to add
little-endian order subroutines are welcome.

The package will be maintained under the umbrella of the Debian Perl Group.
It is part of the dependency chain for GeoIP2.

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

Json-c library installed into /lib/ instead of /usr/lib/ ... is that relevant anymore?

[Boyuan Yang]

Dear -devel list,

Recently I am looking into an orphaned but rather important library package,
libjson-c (popcon >35000, with udeb package). Suprisingly the library libjson-
c3 was installed into /lib// instead of /usr/lib//.

I digged a little bit into it and found out that it was originally due to
upstart that needed it during bootup [2] so the lib should be placed into /lib
according to FHS. However, with upstart disappeared from Debian archive (since
2016), other init systems seem not having dependency on json-c and that
usrmerge is approaching, I'm wondering if we should move the installation path
back to /usr/lib. Will there be any side effects?

I plan to make a clean-up upload for json-c based on current version in sid
(instead of starting a transition). Since it provides a udeb package, words
from the d-i team is also valuable. Please also let me know your suggestions.

--
Regards,
Boyuan Yang

[1] https://tracker.debian.org/pkg/json-c
[2] https://bugs.debian.org/695566


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

Re: Json-c library installed into /lib/ instead of /usr/lib/ ... is that relevant anymore?

[Cyril Brulebois]

Hi,

Boyuan Yang  (2019-01-15):
> I plan to make a clean-up upload for json-c based on current version in sid
> (instead of starting a transition). Since it provides a udeb package, words
> from the d-i team is also valuable. Please also let me know your suggestions.

Thanks for checking with us.

The loader will look into /usr/lib/ in d-i as well, so I don't
anticipate any issues here (unless something in another package
hardcodes the path to this library, which we would notice and fix).

So feel free to go ahead as far as d-i is concerned.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#919440: ITP: owlrl -- A simple implementation of the OWL2 RL Profile on top of RDFLib: it expands the graph with all possible triples that RDFS and OWL-RL defines. It can be used together with RDF

[Ashley Sommer]

Package: wnpp
Severity: wishlist
Owner: Ashley Sommer 

* Package name: owlrl
  Version : 5.2.0
  Upstream Author : Ivan Herman 
* URL : https://github.com/RDFLib/OWL-RL
* License : W3C
  Programming Lang: Python
  Description : A simple implementation of the OWL2 RL Profile on top of 
RDFLib: it expands the graph with all possible triples that RDFS and OWL-RL 
defines. It can be used together with RDFLib to expand an RDFLib Graph object, 
or as a stand alone service with its own serialization.

The useful python application called RDFClosure by Ivan Herman was recently 
updated to v5 and released on pypi. I am an active developer on owlrl and I 
maintain the pypi release.
I indend to package another tool called pySHACL for debian, but it relies on 
owlrl, so I need owlrl released as a debian package first.
The only requirement of owlrl is rdflib, which is already an actively 
maintained debian package.

I intend to personally be the active maintainer of this package (via a 
sponsor). 
I have not released a debain package before, I will be looking for a sponsor to 
get this (owlrl) and pySHACL packaged and published, perhaps the maintainer or 
rdflib would like to sponsor this package.

Bug#919441: ITP: pyshacl -- A pure Python packages which allows for the validation of RDF graphs against Shapes Constraint Language (SHACL) files.

[Ashley Sommer]

Package: wnpp
Severity: wishlist
Owner: Ashley Sommer 

* Package name: pyshacl
  Version : 0.9.9
  Upstream Author : Ashley Sommer 
* URL : https://github.com/RDFLib/pyshacl
* License : Apache License 2.0
  Programming Lang: Python
  Description : A pure Python packages which allows for the validation of 
RDF graphs against Shapes Constraint Language (SHACL) files.

This is a pure Python package which allows for the validation of RDF graphs 
against Shapes Constraint Language (SHACL) graphs. This module uses the rdflib 
Python library for working with RDF and is dependent on the OWL-RL Python 
module for OWL2 RL Profile-based expansion of data graphs.
This module is developed to adhere to the SHACL Recommendation:
>Holger Knublauch; Dimitris Kontokostas. Shapes Constraint Language (SHACL). 20 
>July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/ ED: 
>https://w3c.github.io/data-shapes/shacl/

It has been suggested to me by several users that they find pySHACL to be a 
very useful tool and would like to see it available as a debian package. I 
agree.
I am the lead developer of pySHACL and I maintain the release on pypi.
As well as rdflib, this packages relies on the owlrl python module as a 
prerequisite. I've already filed an ITP for owlrl.
I will be looking for a sponsor to get this software packaged, perhaps the 
maintainer for rdflib could help with sponsorship.

Re: Json-c library installed into /lib/ instead of /usr/lib/ ... is that relevant anymore?

[Marco d'Itri]

On Jan 15, Boyuan Yang  wrote:

> I digged a little bit into it and found out that it was originally due to
> upstart that needed it during bootup [2] so the lib should be placed into /lib
> according to FHS. However, with upstart disappeared from Debian archive (since
> 2016), other init systems seem not having dependency on json-c and that
> usrmerge is approaching, I'm wondering if we should move the installation path
> back to /usr/lib. Will there be any side effects?
Please do. Nowadays /usr/ is always available at early boot anyway.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Handling of entropy during boot

[Anthony DeRobertis]

On 1/14/19 7:07 AM, Thomas Goirand wrote:

On 12/18/18 8:11 PM, Theodore Y. Ts'o wrote:

If you are firmly convinced that there is a good
chance that the NSA has suborned Intel in putting a backdoor into
RDRAND, you won't want to use that boot option.

I have read numerous times that some people trust this or that part of
the instruction set, and I always found it silly. Why should some
instruction or part of the Intel CPU be more trusted? To me, either you
trust the entire CPU, or you just don't trust it at all and consider
using other CPU brands. Am I wrong with this reasoning?


I think the idea behind that is that the rest of the CPU has defined, 
verifiable behaviors. If NSA makes 1+1 sometimes equal 3, then that's 
detectable. So it'd be a fairly risky attack, someone might notice it. 
It also risks that other countries' NSA-equivalents make use of the 
backdoor.


OTOH, the RNG is not verifiable. It's supposed to take two entropy 
sources and apply AES to them to combine them. But how do you know it 
actually did that? You can't tell what the input to AES was, at least as 
long as AES remains secure. It could well be giving you the equivalent 
of 1, 2, 3, 4, etc. encrypted with a key known only to NSA. And there is 
much less risk of another country taking advantage as the numbers still 
are fully CSPRNG — to everyone but NSA.


(Also, see Dual_EC_DRBG)