Bug#820777: ITP: gradle-plugin-protobuf -- Protobuf Plugin for Gradle

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: gradle-plugin-protobuf
  Version : 0.9.2
  Upstream Author : Alex Antonov
* URL : https://github.com/aantono/gradle-plugin-protobuf
* License : BSD-3-clause
  Programming Lang: Groovy
  Description : Protobuf Plugin for Gradle

The Protobuf plugin processes the Protocol Buffers files (.proto) in the
src/main/proto directory of Gradle projects. It generates the Java classes
and compiles them automatically.

This plugin is required to upgrade the libspring-java package.
It'll be maintained by the Java Team.

Re: gitlab package (was Re: Opt out style recommends)

[Tollef Fog Heen]

]] Pirate Praveen 

> On 2016, ഏപ്രിൽ 11 3:44:09 PM IST, Tollef Fog Heen  wrote:
> >I'd really like this to be an optional addon, since there's no way you
> >could know how to integrate with how I acquire my certs.  I also
> >question whether it's the job of an application to set up
> >certificates. Does that mean you're configuring various application
> >servers (for vhosting) and TLS terminators too?
> 
> It is optional. I do configure a site for nginx (add virtual host in
> /etc/nginx/sites-available). TLS is enabled when it is selected. I can
> make nginx configuration optional.

I think it should be, nginx is just one of many HTTP servers in the
archive, and just one of many ways to terminate TLS.  (Unless gitlab in
some way depends on nginx specific features.)

> >Minor comment, but hopefully you're asking about TLS and not SSL in any
> >questions you ask the admin.
> 
> Isn't that just semantics? OpenSSL is still not renamed to OpenTLS
> (yes there is gnuTLS). I think SSL term is still widely used referring
> to TLS.

It's true that SSL is still used to refer to both SSL and TLS, but it's
imprecise and we should move away from that usage.  Use TLS if you mean
TLS and SSL/TLS if you mean either.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: gitlab package (was Re: Opt out style recommends)

[Tollef Fog Heen]

]] Michael Lustfield 

> In this particular case, I would suggest first making letsencrypt a
> Suggests. Then, I would suggest considering snakeoil for the https or
> just installing with http-only and providing a documented tool for
> moving to using letsencrypt. You and I both know that we're only
> talking about a web server configuration... shouldn't the web server
> be the one suggesting it? ... it doesn't because the web server
> packages consider SSL/TLS to be its own thing entirely that shouldn't
> be mixed in with other package deployments.

The web app might well need to know whether it's being accessed over TLS
or not.  If it is, any cookies it sets should be marked with «secure» so
they're never sent in plaintext.

An option that might satisfy everyone is to have a gitlab package and a
gitlab-bells-and-whistles package (or gitlab-minimal and gitlab) where
the latter includes full integration with nginx and letsencrypt and
whatnot, while the former is a more limited package that does the bare
minimum.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#820779: ITP: golang-github-masterzen-xmlpath -- subset of the XPath specification for Go

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 
Control: block 808773 by -1

* Package name: golang-github-masterzen-xmlpath
  Version : 0.0~git20140218.13f4951
  Upstream Author : Gustavo Niemeyer 
* URL : https://github.com/masterzen/xmlpath
* License : LGPL-3
  Programming Lang: Go
  Description : subset of the XPath specification for Go

This is the mirror of an old version of the xmlpath library for Go
(launchpad.net/xmlpath), the latest version is packaged as 
golang-gopkg-xmlpath.v2.
However, this is needed by winrm [1], which is a requirement for Packer [2].
Unfortunately, winrm isn't upward compatible (the experimental namespace
support especially of this repository is build on), so that's just needed to 
have.

DS

[1] https://bugs.debian.org/808773 (RFP: golang-github-masterzen-winrm)

[2] https://bugs.debian.org/740753 (ITP: Packer)

Re: Packaging of static libraries

[Vincent Lefevre]

On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote:
> (1) When performance matters. Here we need the static library to be
> built without position independent code. This can still give several
> percent gains depending on arch / programming language.

Yes, but in that case, the best thing to do is to recompile everything
for the target processor (instead of generic x86_64, for instance),
with LTO. For GMP+MPFR, I noticed a gain of up to 37% a few years ago.

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

Re: Opt out style recommends

[Jakub Wilk]

* Ben Hutchings , 2016-04-11, 02:22:
Would it be useful to have a linker option to omit a NEEDED entry for a 
particular library?  The application could then call 
dlopen("libfoo.so.42", RTLD_NOW|RTLD_GLOBAL) before it starts using the 
library, typically right before calling foo_init(), but it wouldn't 
need to use dlsym().  However this would absolutely depend on lazy 
binding, i.e. the application would break if LD_BIND_NOW was set.


It's kinda possible already: just remove -lfoo from the linker command 
line (and add -Wl,--unresolved-symbols=ignore-all if you're building an 
executable). The downside is that the unresolved symbols will be 
unversioned, and that you have to hardcode soname in the code... which 
means it'll all explode sooner or later.


--
Jakub Wilk

Bug#820801: ITP: ruby-mixlib-versioning -- Ruby library allowing to parse, compare and manipulate version strings

[Hleb Valoshka]

Package: wnpp
Severity: wishlist
Owner: Hleb Valoshka <375...@gmail.com>

* Package name: ruby-mixlib-versioning
  Version : 1.1.0
  Upstream Author : OpsCode, Inc
* URL : https://github.com/opscode/mixlib-versioning
* License : Apache 2.0
  Programming Lang: Ruby
  Description : Ruby library allowing to parse, compare and manipulate 
version strings

General purpose Ruby library that allows you to parse, compare and manipulate
version strings in multiple formats.

Yet another dependency for test-kitchen.

Re: Packaging of static libraries

[Ian Jackson]

Vincent Lefevre writes ("Re: Packaging of static libraries"):
> On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote:
> > (1) When performance matters. Here we need the static library to be
> > built without position independent code. This can still give several
> > percent gains depending on arch / programming language.
> 
> Yes, but in that case, the best thing to do is to recompile everything
> for the target processor (instead of generic x86_64, for instance),
> with LTO. For GMP+MPFR, I noticed a gain of up to 37% a few years ago.

I'm afraid that LTO is probably too dangerous to be used as a
substitute for static linking.  See my comments in the recent LTO
thread here, where I referred to the problem of undefined behaviour,
and pointed at John Regehr's blog.

Thanks,
Ian.

Re: Packaging of static libraries

[Vincent Lefevre]

On 2016-04-12 14:52:33 +0100, Ian Jackson wrote:
> I'm afraid that LTO is probably too dangerous to be used as a
> substitute for static linking.  See my comments in the recent LTO
> thread here, where I referred to the problem of undefined behaviour,
> and pointed at John Regehr's blog.

This is not specific to LTO at all. Other form of optimization can
yield "non-working" code (not expected by the developers). Note that
by default, shared libraries would still be used, so that this would
affect only users with specific applications, who would want to
optimize as much as possible. And code should also be tested with an
UB sanitizer (which could possibly enabled by default in cases where
it is shown that it does not slow things down[*]); this would allow
one to detect most UB related bugs.

[*] For instance, I use a patched Mutt built with the UB sanitizer,
as I could not see time differences, even on slow operations.

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

Bug#820810: ITP: art-nextgen-simulation-tools -- simulation tools to generate synthetic next-generation sequencing reads

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: art-nextgen-simulation-tools
  Version : 3.19.15
  Upstream Author : Weichun Huang 
* URL : 
http://www.niehs.nih.gov/research/resources/software/biostatistics/art/
* License : GPL
  Programming Lang: C++
  Description : simulation tools to generate synthetic next-generation 
sequencing reads
 ART is a set of simulation tools to generate synthetic next-generation
 sequencing reads. ART simulates sequencing reads by mimicking real
 sequencing process with empirical error models or quality profiles
 summarized from large recalibrated sequencing data. ART can also
 simulate reads using user own read error model or quality profiles. ART
 supports simulation of single-end, paired-end/mate-pair reads of three
 major commercial next-generation sequencing platforms: Illumina's
 Solexa, Roche's 454 and Applied Biosystems' SOLiD. ART can be used to
 test or benchmark a variety of method or tools for next-generation
 sequencing data analysis, including read alignment, de novo assembly,
 SNP and structure variation discovery. ART was used as a primary tool
 for the simulation study of the 1000 Genomes Project . ART is
 implemented in C++ with optimized algorithms and is highly efficient in
 read simulation. ART outputs reads in the FASTQ format, and alignments
 in the ALN format. ART can also generate alignments in the SAM
 alignment or UCSC BED file format. ART can be used together with genome
 variants simulators (e.g. VarSim) for evaluating variant calling tools
 or methods.


Remark: The package is maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/art-nextgen-simulation-tools.git

Re: Packaging of static libraries

[Adam Borowski]

On Tue, Apr 12, 2016 at 02:52:33PM +0100, Ian Jackson wrote:
> Vincent Lefevre writes ("Re: Packaging of static libraries"):
> > On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote:
> > > (1) When performance matters. Here we need the static library to be
> > > built without position independent code. This can still give several
> > > percent gains depending on arch / programming language.
> > 
> > Yes, but in that case, the best thing to do is to recompile everything
> > for the target processor (instead of generic x86_64, for instance),
> > with LTO. For GMP+MPFR, I noticed a gain of up to 37% a few years ago.
> 
> I'm afraid that LTO is probably too dangerous to be used as a
> substitute for static linking.  See my comments in the recent LTO
> thread here, where I referred to the problem of undefined behaviour,
> and pointed at John Regehr's blog.

LTO is no different from just concatenating all source files and making
functions static.  If your code blows after this, it is your fault not
LTO's.  LTO just allows interprocedural optimizations to work between
functions that were originally in different source files.

-- 
A tit a day keeps the vet away.

Bug#820821: ITP: magit-svn -- git-svn extension for magit, a git interface for emacs.

[Alberto Luaces]

Package: wnpp
Severity: wishlist
Owner: Alberto Luaces 

* Package name: magit-svn
  Version : 2.1.1
  Upstream Author : The Magit Project Contributors
* URL : https://magit.vc/
* License : GPL
  Programming Lang: elisp
  Description : git-svn extension for magit, a git interface for emacs.

This package provides basic support for Git-Svn.
.
Git-Svn is a Git command that aims to provide bidirectional
operation between a Subversion repository and Git.
.
When `magit-svn-mode' is turned on then the unpushed and unpulled
commit relative to the Subversion repository are displayed in the
status buffer, and `N' is bound to a popup with commands that wrap
the `git svn' subcommands fetch, rebase, dcommit, branch and tag,
as well as a few extras.

This package will be supported by the Debian Emacs addons Team.

Re: gitlab package (was Re: Opt out style recommends)

[Michael Lustfield]

On Apr 12, 2016 00:34, "Tollef Fog Heen"  wrote:
>
> ]] Michael Lustfield
>
> > In this particular case, I would suggest first making letsencrypt a
> > Suggests. Then, I would suggest considering snakeoil for the https or
> > just installing with http-only and providing a documented tool for
> > moving to using letsencrypt. You and I both know that we're only
> > talking about a web server configuration... shouldn't the web server
> > be the one suggesting it? ... it doesn't because the web server
> > packages consider SSL/TLS to be its own thing entirely that shouldn't
> > be mixed in with other package deployments.
>
> The web app might well need to know whether it's being accessed over TLS
> or not.  If it is, any cookies it sets should be marked with «secure» so
> they're never sent in plaintext.

An app should know about HTTP vs. HTTPS, yes. However, that's not relevant
to this discussion because an app should be finding that information via a
header the web server sends it. It's one of the standard headers that
nobody pays much attention to. :)

I think party of the problem here is the whole omnibus logic that wants to
configure the whole environment which immediately steps on sys admin toes.

The best thing I can think of is to stick with HTTP out of the box and have
another utility that handles modifying configuration.

You could have all of these prompts (http vs. https; managed certs vs.
letsencrypt) be debconf questions with a post install script that reads
those answers. If nothing was selected, use the default. Otherwise, do
whatever else. This would provide flexibility to rerun and modify later as
well. At least this would be suitable to how gitlab-omnibus likes to
configure itself and it's "modules."

For admins with config management tools, they can pre-answer your debconf
questions and have SSL right away if they so choose. The reconfiguration
can easily be triggered via dpkg reconfigure, which tends to be a first
step for extra config in Debian.

This lets you deploy gitlab out of the box in a manner that is the most
likely to work on all systems and leaves the ability to configure extras to
your heart's content.

Either that or I'm missing something. If I am, please teach me my lesson! :)

Bug#820848: ITP: phcpack -- General-purpose solver for polynomial systems

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 

* Package name: phcpack
  Version : 2.4.14
  Upstream Author : Jan Verschelde 
* URL : https://github.com/janverschelde/PHCpack
* License : GPL-2+
  Programming Lang: Ada
  Description : General-purpose solver for polynomial systems

PHCpack is a software package to solve polynomial systems by homotopy
continuation methods.

A polynomial system is given as a sequence of polynomials in several variables.
Homotopy continuation methods operate in two stages. In the first stage, a
family of polynomial systems (the so-called homotopy) is constructed. This
homotopy contains a polynomial system with known solutions. In the second stage,
numerical continuation methods are applied to track the solution paths defined
by the homotopy, starting at the known solutions and leading to the solutions of
the given polynomial system.

I intend to package PHCpack under the umbrella of the Debian Science team.

Bug#820851: ITP: sprai -- single-pass sequencing read accuracy improver

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: sprai
  Version : 0.9.9.12
  Upstream Author : Takamasa Imai 
* URL : http://zombie.cb.k.u-tokyo.ac.jp/sprai/index.html
* License : MIT
  Programming Lang: C, Perl, Python
  Description : single-pass sequencing read accuracy improver

 Sprai is a tool to correct sequencing errors in single-pass reads for
 de novo assembly. It is originally designed for correcting sequencing
 errors in single-molecule DNA sequencing reads, especially in Continuous
 Long Reads (CLRs) generated by PacBio RS sequencers. The goal of Sprai is
 not maximizing the accuracy of error-corrected reads. Instead, Sprai aims
 at maximizing the continuity (i.e., N50 contig length) of assembled contigs
 after error correction.

This package will be maintained by the Debian Med team.