Bug#819043: ITP: python-stringtemplate3 -- template engine with strict model-view separation

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-stringtemplate3
  Version : 3.1
  Upstream Author : Terence Parr 
* URL : http://www.stringtemplate.org/
* License : BSD-3
  Programming Lang: Python
  Description : template engine with strict model-view separation

 StringTemplate is a template engine for generating source code, web pages,
 emails, or any other formatted text output. StringTemplate is particularly
 good at multi-targeted code generators, multiple site skins, and
 internationalization/localization. It evolved over years of effort developing
 jGuru.com. StringTemplate also powers the ANTLR v3 code generator. Its
 distinguishing characteristic is that it strictly enforces model-view
 separation unlike other engines.

Note from package maintainer: python-stringtemplate3 is needed for
python-antlr3, which I would like to package so I can upload Congress, which
is OpenStack Policy as a Service (ie: policy enforcement in your OpenStack
deployment).

Re: migrating to Debian gitlab

[Pirate Praveen]

[adding backports to cc]

On Sunday 21 February 2016 05:01 PM, Pirate Praveen wrote:
> I have started backporting gitlab for jessie #815216 has status updates.

I have built it on jessie (with tests disabled for some packages).

http://mahishasura.pxq.in/ has the gitlab package for jessie. I have
automated the build process to a large extend here
https://gitlab.com/debian-ruby/backportr

https://git.pxq.in is running gitlab on jessie (its a test instance).
But we'll soon have git.fosscommunity.in open public (for those who want
to be on 100% Free Software, as gitlab.com is running on GitLab EE). You
can track its progress at
https://www.loomio.org/g/Qu3O8mSf/fosscommunity-in-git-fosscommunity-in-maintainers
if you are interested.

https://gitlab.com/debian-ruby/backportr/blob/master/lib/gitlab_notes-install.txt
gives you additional packages you need to manually install before
installing gitlab.

https://gitlab.com/debian-ruby/backportr/blob/master/lib/gitlab_notes.txt has
the manual steps I had to take for backporting.

I'm wondering if it is worth the effort to upload it to
jessie-backports. Looking for comments from the backports team. Also any
help in maintaining the backports is welcome.

The last major issue we have to fix is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814871 Any help in
debugging and fixing this is welcome.

I think once this bug is fixed, we can start working on a gitlab
instance for debian, finally!



signature.asc
Description: OpenPGP digital signature

Bug#819046: ITP: python-antlr3 -- ANother Tool for Language Recognition - Python 2.7 bindings

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-antlr3
  Version : 3.5.2
  Upstream Author : Terence Parr 
* URL : http://www.antlr.org/
* License : BSD-3
  Programming Lang: Python
  Description : ANother Tool for Language Recognition - Python 2.7 bindings

 ANTLR, ANother Tool for Language Recognition, (formerly PCCTS) is a language
 tool that provides a framework for constructing recognizers, compilers, and
 translators from grammatical descriptions containing C++ or Java actions (You
 can use PCCTS 1.xx to generate C-based parsers).
 .
 Computer language translation has become a common task. While compilers and
 tools for traditional computer languages (such as C or Java) are still being
 built, their number is dwarfed by the thousands of mini-languages for which
 recognizers and translators are being developed. Programmers construct
 translators for database formats, graphical data files (e.g., PostScript,
 AutoCAD), text processing files (e.g., HTML, SGML).  ANTLR is designed to
 handle all of your translation tasks.
 .
 This package provides the Python 2.7 bindings.

Note from package maintainer: upstream has a different source for Py2 and Py3,
I'm currently only packaging the version for Py2, and will probably do the Py3
when upstream for OpenStack Congress switches to that. This package aims at
packaging the remaining (build-)depends for Congress, which is OpenStack
Policy as a Service (ie: general purpose policies in your OpenStack
deployments).

Bug#819052: ITP: golang-github-xeipuuv-gojsonpointer -- JSON Pointer implementation in Golang

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-xeipuuv-gojsonpointer
Version: 0.0~git20151027
License: Apache-2.0
URL: https://github.com/xeipuuv/gojsonpointer
Description: JSON Pointer implementation in Golang
 An implementation of JSON Pointer in Golang


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

Bug#819053: ITP: golang-github-xeipuuv-gojsonreference -- short description

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block -1 by 819052

   Package name: golang-github-xeipuuv-gojsonreference
Version: 0.0~git20150808
License: Apache-2.0
URL: https://github.com/xeipuuv/gojsonreference
Description: JSON Reference implementation in Golang
 An implementation of JSON Reference in Golang.


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

Bug#819055: ITP: golang-github-xeipuuv-gojsonschema -- implementation of JSON Schema, draft v4

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block -1 by 819053
Control: affects -1 golang-github-opencontainers-specs

   Package name: golang-github-xeipuuv-gojsonschema
Version: 0.0~git20160323
License: Apache-2.0
URL: https://github.com/xeipuuv/gojsonschema
Description: implementation of JSON Schema, draft v4
 Golang implementation of JSON Schema, based on IETF's draft v4.


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

Bug#819056: ITP: golang-github-mattn-go-runewidth -- functions to get fixed width of the character or string

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 etcd

   Package name: golang-github-mattn-go-runewidth
Version: 0.0.1
Upstream Author: Yasuhiro Matsumoto
License: Expat
URL: https://github.com/mattn/go-runewidth
Description: functions to get fixed width of the character or string
 Golang library provinding functions to get fixed width of the character or
 string.


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

Bug#819058: ITP: octave-netcdf -- Matlab compatible NetCDF interface for Octave

[Rafael Laboissière]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere 

* Package name: octave-netcdf
  Version : 1.0.9
  Upstream Author : Alexander Barth 
* URL : http://octave.sourceforge.net/netcdf/
* License : GPL-2+
  Programming Lang: Octave, C++
  Description : Matlab compatible NetCDF interface for Octave

This package contains the Octave binding to the NetCDF library, 
allowing the creation, the reading, and the display of meta-data of 
NetCDF files.


This Octave add-on package is part of the Octave-Forge project.

The octave-netcdf package will replace the deprecated octave-octcdf 
package.  A preliminary version of the package can be found at the 
following Git repository:


https://anonscm.debian.org/gitweb/?p=pkg-octave/octave-netcdf.git

Re: Bug#818996: Please enable -Wabi-tag warning for C++ programs

[Matthias Klose]

On 22.03.2016 17:36, Simon McVittie wrote:

Package: g++
Control: submitter -1 Jeffrey Walton 

On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote:

We just took a report due to
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

It appears Debian built the library with GCC, and GCC used
_GLIBCXX_USE_CXX11_ABI. The user then compiled with Clang and caught a
link error. The tools did not warn him about the problems, so the
report trickled downhill to us.

Would Debian please enable -Wabi-tag by default for C++ programs in
its compilers.

I think it can be done in a spec file for GCC. My apologies for not
offering the string for the specs file. Also see
http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html.

Thank you in advance.


Turning this into a g++ bug report.


If you want to change that, that change should be made in dpkg-buildflags.

Bug#819068: ITP: r-cran-adegraphics -- GNU R lattice-based package for the representation of multivariate data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-adegraphics
  Version : 1.0-5
  Upstream Author : Aurélie Siberchicot 
* URL : https://cran.r-project.org/web/packages/adegraphics/
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R lattice-based package for the representation of 
multivariate data
 This GNU R package provides graphical functionalities for the
 representation of multivariate data. It is a complete re-implementation
 of the functions available in the 'ade4' package.


Remark: This package belongs to a pyramid of dependencies for r-cran-treescape
and will be maintained by the Debian Med team at
  svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-adegraphics/trunk/

Re: a poll for Dgit workflows

[Ian Jackson]

Adam Borowski writes ("Re: a poll for Dgit workflows"):
> On Mon, Mar 21, 2016 at 10:19:01AM +0100, Daniel Stender wrote:
> > Ah yes, source format 1.0 fits better here. Thanks for the pointer and
> > comments (Manoj, too).
> 
> Please don't use source format 1.0, it sucks.  Instead, you can:
>   echo single-debian-patch >debian/source/options
> which gives you all upsides of 3.0 without the big downside, aka quilt.

Please don't use source format `3.0 (quilt)', it sucks.

Ian.

Bug#819070: ITP: r-cran-htmltools -- r-cran-htmltools

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-htmltools
  Version : 0.3.5
  Upstream Author : Joe Cheng 
* URL : https://cran.r-project.org/web/packages/shiny/
* License : GPL-2+
  Programming Lang: GNU R
  Description : r-cran-htmltools
 This GNU R package provides tools for HTML generation and output.


Remark: This package belongs to a pyramid of dependencies for the
  r-cran-treescape package and will be maintained by the Debian Med
  team at
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-htmltools/trunk/

Re: a poll for Dgit workflows

[Adam Borowski]

On Wed, Mar 23, 2016 at 01:32:59PM +, Ian Jackson wrote:
> Adam Borowski writes ("Re: a poll for Dgit workflows"):
> > On Mon, Mar 21, 2016 at 10:19:01AM +0100, Daniel Stender wrote:
> > > Ah yes, source format 1.0 fits better here. Thanks for the pointer and
> > > comments (Manoj, too).
> > 
> > Please don't use source format 1.0, it sucks.  Instead, you can:
> >   echo single-debian-patch >debian/source/options
> > which gives you all upsides of 3.0 without the big downside, aka quilt.
> 
> Please don't use source format `3.0 (quilt)', it sucks.

Could you tell us what other downsides it has, besides quilt?
All other differences I'm aware of are upsides: .xz, multiple tarballs
or ambivalent: purging upstream debian/

-- 
A tit a day keeps the vet away.

Re: a poll for Dgit workflows

[Ian Jackson]

Brian May writes ("Re: a poll for Dgit workflows"):
> I think the single-debian-patch makes doing security updates a lot
> harder. Particularly if one distribution has been patched, and the patch
> needs to be ported to other distributions.
> 
> Sure, you might be able to retrieve/store the individual patches from
> git, however we don't have any one standard for storing the patches in
> git. This means in order to do security updates, the first step would be
> to learn how this particular packages stores the patches in git. Unlike
> 3.0-quilt format which is a standard that most packages use (or some
> similar storing of patches in debian/patches at least).

There is essentially only one reasonable way to export a patch stack
in git, which is as a git branch with one commit per patch.  There
will usually be a synthetic merge commit at the top, to make the
result a fast forward from the previous version.  Most of the popular
git workflow tools we already have work with some form of this
representation.

(NB that dgit is not a git workflow tool; it's a publication tool.)

If one does this, right now, there are rather too many manual git
runes and rather too much understanding, required, for simply
exchanging such git branches to be sensible recommendation as a
default workflow.

But it does work.  And if you want to do a new upstream version, you
can do it by rebasing the branch onto the new upstream version in
git.  (Your new upstream version is in git already, right?)

I have plans for ways to improve the workflow to be more automatic
more cooked, but for now I'm concentrating on getting the git-dpm and
gbp integration to work right.

> I haven't looked at dgit in sometime, so I can't recall how well it
> works - assuming it does work - with 3.0-quilt format.

It works just fine with `3.0 (quilt)'.  The import/export could be
improved but it meets its basic design goals.

There are difficulties with the data models of some of the existing
git workflow tools.  In particular, dgit is hard to use with
git-buildpackage.  I'm working on that.

Ian.

Re: a poll for Dgit workflows

[Ian Jackson]

Marco d'Itri writes ("Re: a poll for Dgit workflows"):
> I like the general idea of dgit, but I will never use it as long as it 
> requires committing patched trees.

Obviously, for dgit to be useful, it has to define a standard
interchange format.  That format has to be patches-applied because
otherwise naive users can't work with the source code properly.

But that doesn't necessarily mean that a maintainer who likes to work
with patches-unapplied trees has to change their workflow to use dgit.

I have a work-in-progress dgit branch which will convert,
automatically, a patches-unapplied branch, to a patches-applied
branch, during dgit push.  The maintainer never has to look at the
patches-applied branch, but it appears on the dgit git server for
other dgit users to see.

Ian.

Re: a poll for Dgit workflows

[Marco d'Itri]

On Mar 23, Ian Jackson  wrote:

> Obviously, for dgit to be useful, it has to define a standard
> interchange format.  That format has to be patches-applied because
> otherwise naive users can't work with the source code properly.
Having the alleged needs of naive users dictate the design of our tools 
looks like a very bad choice to me...
I want something that is useful to me, not to mythical random naive 
users who may want to work on Debian packages without understanding the 
basics of how they are created.

> But that doesn't necessarily mean that a maintainer who likes to work
> with patches-unapplied trees has to change their workflow to use dgit.
No, I do not want to have patches-applied *repositories*.

> I have a work-in-progress dgit branch which will convert,
> automatically, a patches-unapplied branch, to a patches-applied
> branch, during dgit push.  The maintainer never has to look at the
> patches-applied branch, but it appears on the dgit git server for
> other dgit users to see.
I am not sure of what benefits dgit would bring to me if I am not going 
to use the repositories that it creates.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: a poll for Dgit workflows

[Ian Jackson]

Adam Borowski writes ("Re: a poll for Dgit workflows"):
> On Wed, Mar 23, 2016 at 01:32:59PM +, Ian Jackson wrote:
> > Please don't use source format `3.0 (quilt)', it sucks.
> 
> Could you tell us what other downsides it has, besides quilt?
> All other differences I'm aware of are upsides: .xz, multiple tarballs
> or ambivalent: purging upstream debian/

The main problem is that it can't be safely manipulated without
knowledge of the quilt system.  So it is not really a source package
format.  It's an attempt at a version control system.

(Purging upstream debian/ is only a feature because none of our source
formats cope with deleting files.)

Ian.

Re: a poll for Dgit workflows

[Manoj Srivastava]

On Wed, Mar 23 2016, Ian Jackson wrote:

> Marco d'Itri writes ("Re: a poll for Dgit workflows"):
>> I like the general idea of dgit, but I will never use it as long as it 
>> requires committing patched trees.
>
> Obviously, for dgit to be useful, it has to define a standard
> interchange format.  That format has to be patches-applied because
> otherwise naive users can't work with the source code properly.

It’s not just naive users that prefer working with git and
 branches natively. My preferred form of modification is pull requests
 for my git repositories (my packaging repositories are mirrored on
 alioth and github). I can build and test the tip of any of my feature
 branches or upstream, or the fully merged debian branch, so I can make
 sure that the features I submit upstream actually work. I think that is
 harder to do if the repository has just a jumble of patches in a
 directory, and is missing the development history of the features.


While git-debcherry does automate the pain
 point of serializing commits on different feature branches, the
 commits are out of order for each feature, and it is a lot of busy work
 getting the series of patches properly ordered, and there are always
 merge artifacts in the patch series as slightly overlapping branches
 are brought back into conformance.

I prefer not to get patches to the source predicated on how the
 feature branches have been serialized; most people in this era of
 github can and do work with remote git repositories, and others can
 still send me patches by mail that I’ll break down into changes to a
 fix branch that I shall send upstream.

Given the number of times that most projects get sent changes
 versus the maintainer having to work with version control themselves, I
 think that debian-single-patch is acceptable (well, in my opinion, of
 course).

manoj
-- 
Today is the first day of the rest of your life.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#782264: grub-install fails in nested LVM

[Ian Jackson]

Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
LVM"):
> Anyway, I was more concerned by the non-ack of my report.

You received an ack of your report from the bug tracking system.

But it seems that you are concerned that this bug is not getting
enough human attention.  That is quite possibly true.  Debian as a
whole has too much work to do with too few people.  Maintainers have
to choose which packages and which bug reports are going to receive
their attention.

Maintainers will try to work on those tasks which they think will give
the biggest gain for the lowest effort.  Or - as volunteers - which
they think are most fun.

To try to escalate the priority of a bug you are interested in, by
sending content-free pings, is rude.  Debian contributors should
ignore a submitter who behaves in that way.

As a user, or a bug submitter, you do not have a right to a fix.  You
do not even have a right to a reply from a human.

If you are dissatisfied with the progress of the work to investigate
and fix a bug, then the Debian maintainainers will generally welcome
your constructive help.  In this case that probably means: Feel Free
To (Investigate And) Submit A Patch.

If neither you nor your friends have the skills to work on the bug
yourselves, and you would like to ensure you have a right to a reply
to your emails and bug reports, I suggest you employ someone (an
individual or a company), on a commercial basis, to provide you with
the support you require.

Thanks,
Ian.

Re: a poll for Dgit workflows

[Manoj Srivastava]

On Wed, Mar 23 2016, Marco d'Itri wrote:

> On Mar 23, Ian Jackson  wrote:
>
>> Obviously, for dgit to be useful, it has to define a standard
>> interchange format.  That format has to be patches-applied because
>> otherwise naive users can't work with the source code properly.
> Having the alleged needs of naive users dictate the design of our tools 
> looks like a very bad choice to me...

That would be correct, it it were only true 

> I want something that is useful to me, not to mythical random naive 
> users who may want to work on Debian packages without understanding the 
> basics of how they are created.

I think dgit should address the needs of all kinds of people,
 as it does not. Not all the people who disagree with you are mythic
 (though I quite like the appelation).

I appreciate the fact that dgit does indeed do things that are
 useful to me. Thanks, Ian.
>
>> But that doesn't necessarily mean that a maintainer who likes to work
>> with patches-unapplied trees has to change their workflow to use dgit.
> No, I do not want to have patches-applied *repositories*.

Sure. I do. Always have. Now er both have opinions, but I doubt
 mere opinions are useful to the rest of the readers here.

>> I have a work-in-progress dgit branch which will convert,
>> automatically, a patches-unapplied branch, to a patches-applied
>> branch, during dgit push.  The maintainer never has to look at the
>> patches-applied branch, but it appears on the dgit git server for
>> other dgit users to see.
> I am not sure of what benefits dgit would bring to me if I am not going 
> to use the repositories that it creates.

I don’t think there is a contention that dgit is for everyone. I
 think it offers  a useful publication medium; and if it allos other
 people to work with developers who do or do not prefer the repositories
 to reflect the tree the software is actually built from, then it is a
 net plus.

manoj

-- 
Life is like an egg stain on your chin -- you can lick it, but it still
won't go away.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Bug#819086: ITP: r-cran-httr -- GNU R tools for working with URLs and HTTP

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-httr
  Version : 1.1.0
  Upstream Author : Hadley Wickham 
* URL : https://cran.r-project.org/web/packages/httr/
* License : MIT
  Programming Lang: GNU R
  Description : GNU R tools for working with URLs and HTTP
 Useful tools for working with HTTP organised by HTTP verbs (GET(),
 POST(), etc). Configuration functions make it easy to control additional
 request components (authenticate(), add_headers() and so on).


Remark: This package belongs to a pyramid of dependencies for r-cran-treescape
and will be maintained by the Debian Med team at
 svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-httr/trunk/

Re: CVE-2016-0800 status for openssl 0.9.8o

[Julien Cristau]

On Wed, Mar 23, 2016 at 15:09:19 +, Mike LI wrote:

> Dear Debian developers:
> We still use 0.9.8 with Debian squeeze (lts) dist in production systems. 
> 
> As shown below,
> https://security-tracker.debian.org/tracker/CVE-2016-0800
> 
> openssl (PTS)squeeze, squeeze (security)0.9.8o-4squeeze14vulnerable
> squeeze (lts)0.9.8o-4squeeze23 vulnerable
> Do you have plan/schedule when it will be fixed?
> 
squeeze-lts reached end of life last month.  No new fixes will be
released for it.  You should upgrade to a supported release ASAP.
https://www.debian.org/News/2016/20160212

Cheers,
Julien

Bug#819095: ITP: golang-github-mvdan-xurls -- extract urls from text

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 795652 by -1

   Package name: golang-github-mvdan-xurls
Version: 0.8.0
Upstream Author: Daniel Martí
License: BSD-3-Clause
URL: https://github.com/mvdan/xurls
Description: extract urls from text
 Extract urls from text using regular expressions.


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

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Hey,

First, I'd like to apologize for the way I asked for a fix or any solution
in that issue. I realize that it was inappropriate.

Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
> LVM"):
> > Anyway, I was more concerned by the non-ack of my report.
> 
> You received an ack of your report from the bug tracking system.
> 
> But it seems that you are concerned that this bug is not getting
> enough human attention.  That is quite possibly true.  Debian as a
> whole has too much work to do with too few people.  Maintainers have
> to choose which packages and which bug reports are going to receive
> their attention.

That's true, but I got used to see at least a human ack on bug reports, that
does not imply any commitment to solve the issue, but that is a way to say
that not only an automatized system received the report.

Maybe I should not get used to that human interaction, but I beleive that it
is exactly what makes a community, and that's what I thought I saw in the
social contract.

> Maintainers will try to work on those tasks which they think will give
> the biggest gain for the lowest effort.  Or - as volunteers - which
> they think are most fun.

That's fair.

> To try to escalate the priority of a bug you are interested in, by
> sending content-free pings, is rude.  Debian contributors should
> ignore a submitter who behaves in that way.

My apologies if that's what I made anybody think. My point was not to
escalate the priority of this bug but really to see a human being at the
other end.

> As a user, or a bug submitter, you do not have a right to a fix.

That's true, and I clearly shouldn't have been that though in my second and
third mail for this bug. Again, I'd like to apologize.

> You do not even have a right to a reply from a human.

I'm not sure to agree with that.

As far as I understood, -- and let me be clear, I *know* that I know less
about Debian than you do --, Debian, by its social contract, intends, as a
community, to focus on users needs and on the fact that nothing is made to
be hidden. In my opinion, there is no community if there is no human
interaction.

As someone becomes maintainer of a package, I'm keen on beleiving that he
chose to, and that he agrees to provide user support regarding the package
(not the software). In a public project, that relies on a community concept,
it appears to me as a very bad move to say "the automatized response is
enough", or to say "I do not have to make user support".

I have no right, but I beleive that there is commitment from a maintainer to
provide support (not fixes, just say that I'm not speaking in the wind). If
I'm wrong, -- and I guess that's your point --, then I'm sorry that I
misbeleived about Debian concept and philosophy.

> If you are dissatisfied with the progress of the work to investigate
> and fix a bug, then the Debian maintainainers will generally welcome
> your constructive help.  In this case that probably means: Feel Free
> To (Investigate And) Submit A Patch.
>
> If neither you nor your friends have the skills to work on the bug
> yourselves, and you would like to ensure you have a right to a reply
> to your emails and bug reports, I suggest you employ someone (an
> individual or a company), on a commercial basis, to provide you with
> the support you require.

I'm not dissatisfied with the progress of the work, I was dissatisfied with
the silence around my report, which seemed like "burying" the issue.

As you can see, I made a lot of investigations, especially to make sure that
the bug was really in the Debian package, but I did not succeed in finding
the exact issue, since I'm not able to reproduce the same behaviour with
bare grub2 software. I guess the issue is hidden in Debian patches, but I've
no proof of that, and not enough skills in that part of packaging to
bissect.

That was in my opinion a good move to ask someone who knows for some help.
The support could have been a simple ack, but at least, I'd have reached a
human.

Anyway, sorry, I shouldn't have been aggressive. I'll try again to find the
exact issue when I'll have some time to.

Cheers,

-- 
PEB

Re: a poll for Dgit workflows

[Manoj Srivastava]

On Wed, Mar 23 2016, Adam Borowski wrote:

> On Wed, Mar 23, 2016 at 01:32:59PM +, Ian Jackson wrote:
>> Adam Borowski writes ("Re: a poll for Dgit workflows"):
>> > On Mon, Mar 21, 2016 at 10:19:01AM +0100, Daniel Stender wrote:
>> > > Ah yes, source format 1.0 fits better here. Thanks for the pointer and
>> > > comments (Manoj, too).
>> > 
>> > Please don't use source format 1.0, it sucks.  Instead, you can:
>> >   echo single-debian-patch >debian/source/options
>> > which gives you all upsides of 3.0 without the big downside, aka quilt.


And creates a source package that does not correspond to my
 repository. I don’t need to have a ./debian/patches in my repository;
 all that information, along with a rich history of changes, is already
 in git.

I admit, I don’t much care whether the source debian.tar.xz
 reflects my repository or not, if it didn’t leave artifacts that
 dirtied my working tree when creating the source package.  I also
 sometimes unpack debian source packages on machines without dpkg on
 them; source format 1.0 makes it somewhat easier.

And it does interfere with using dgit as a publication
 mechanism. 


>> Please don't use source format `3.0 (quilt)', it sucks.
>
> Could you tell us what other downsides it has, besides quilt?
> All other differences I'm aware of are upsides: .xz, multiple tarballs
> or ambivalent: purging upstream debian/

The source format 1.0 can also use .xz, if it so desired, right?
 Or a source format 1.1?  Perhaps at some point someone, perhaps I, will
 take a stab at that.

And, if I ma channel Marco here, multiple tarballs and purging
 upstream debian/ does nothing for me. But there is nothing in that that
 is tied to source format 3.0 (quilt); in theory all these features, if
 deemed important enough an itch to scratch, can be addressed.

As long as arbitrarily serialized patch sets are not my
 preferred form of modification, ./debian/patches seems like busy work.

manoj
-- 
Everyone has a purpose in life.  Perhaps yours is watching
television. David Letterman
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature

Re: a poll for Dgit workflows

[Adam Borowski]

On Wed, Mar 23, 2016 at 12:57:59PM -0700, Manoj Srivastava wrote:
> On Wed, Mar 23 2016, Adam Borowski wrote:
> 
> > On Wed, Mar 23, 2016 at 01:32:59PM +, Ian Jackson wrote:
> >> Adam Borowski writes ("Re: a poll for Dgit workflows"):
> >> > On Mon, Mar 21, 2016 at 10:19:01AM +0100, Daniel Stender wrote:
> >> > > Ah yes, source format 1.0 fits better here. Thanks for the pointer and
> >> > > comments (Manoj, too).
> >> > 
> >> > Please don't use source format 1.0, it sucks.  Instead, you can:
> >> >   echo single-debian-patch >debian/source/options
> >> > which gives you all upsides of 3.0 without the big downside, aka quilt.
> 
> And creates a source package that does not correspond to my
>  repository. I don’t need to have a ./debian/patches in my repository;
>  all that information, along with a rich history of changes, is already
>  in git.

echo .pc/ >>.gitignore
echo debian/patches/ >>.gitignore

> I admit, I don’t much care whether the source debian.tar.xz
>  reflects my repository or not, if it didn’t leave artifacts that
>  dirtied my working tree when creating the source package.

These artifacts are no different from the rest of build droppings, ie, they
can be gitignored just the same.

>  I also sometimes unpack debian source packages on machines without dpkg
>  on them; source format 1.0 makes it somewhat easier.

Valid point.


[snip]
> And, if I ma channel Marco here, multiple tarballs and purging
>  upstream debian/ does nothing for me. But there is nothing in that that
>  is tied to source format 3.0 (quilt); in theory all these features, if
>  deemed important enough an itch to scratch, can be addressed.

I'd argue it's far less work to beat 3.0 into shape than to reimplent stuff
for 1.0.

> As long as arbitrarily serialized patch sets are not my
>  preferred form of modification, ./debian/patches seems like busy work.

Hell yeah!  Quilt is a (primitive) VCS, trying to put that into git is
VCS-in-VCS which is lossage that breaks a good amount of git's upsides, such
as bisect.  Most upstreams today use git as well, using the same VCS means
taking patches both ways is a cherry-pick away, and git deals with already
applied patches without any user intervention.

These days it's git and non-linear history that's a preferred form of
modification.

-- 
A tit a day keeps the vet away.

Bug#819117: ITP: berkshelf-api -- A server which indexes cookbooks from various sources and hosts it over a REST API

[Hleb Valoshka]

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

* Package name: berkshelf-api
  Version : 2.1.3
  Upstream Author : Jamie Winsor , Andrew Garson 

* URL : https://github.com/berkshelf/berkshelf-api
* License : Apache 2.0
  Programming Lang: ruby
  Description : A server which indexes cookbooks from various sources and 
hosts it over a REST API

We need it mostly as build-dependency for ruby-berkshelf-api, which is a 
dependency for berkshelf.

ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)

[Pierre-Elliott Bécue]

Control: owner -1 !
Control: retitle -1 ITP: python-browserid -- Python library for the BrowserID 
Protocol (Mozilla Persona)

Hey,

I intend to package. VCS is up, the package builds correctly.

VCS: https://github.com/P-EB/python-browserid
Build results: https://peb.pimeys.fr/packages/python-browserid/

Comments welcome, and if everything seems okay, please, I'd like to request
for sponsorship on this package.

-- 
PEB

Re: Bug#782264: grub-install fails in nested LVM

[Ian Jackson]

Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
LVM"):
> Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > You do not even have a right to a reply from a human.
> 
> I'm not sure to agree with that.

There are too many bugs and too few humans to deal with them.  We are
not able to reply to every bug.  At least, if we prioritised writing a
reply (even if only a vacuous one) to every bug, there would be other
more important work that would go undone.

If you'd like to make a human connection with the project, it is best
if you do that as a contributor.  Debian has many millions of users,
and we can't make a personal connection with each one.

Thanks,
Ian.

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le jeudi 24 mars 2016 à 00:23:40+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
> LVM"):
> > Le mercredi 23 mars 2016 à 14:56:01+, Ian Jackson a écrit :
> > > You do not even have a right to a reply from a human.
> > 
> > I'm not sure to agree with that.
> 
> There are too many bugs and too few humans to deal with them.  We are
> not able to reply to every bug.  At least, if we prioritised writing a
> reply (even if only a vacuous one) to every bug, there would be other
> more important work that would go undone.
> 
> If you'd like to make a human connection with the project, it is best
> if you do that as a contributor.  Debian has many millions of users,
> and we can't make a personal connection with each one.

Thanks for your anwser. I understand.

And I intend to become a contributor (currently working on it).

Cheers,

-- 
PEB

Bug#819126: ITP: tzlocal -- tzinfo object for the local timezone

[Brian May]

Package: wnpp
Severity: wishlist
Owner: Brian May 

* Package name: tzlocal
  Version : 2.1
  Upstream Author : Lennart Regebro 
* URL : https://github.com/regebro/tzlocal
* License : CC0
  Programming Lang: Python2 and Python3
  Description : tzinfo object for the local timezone

 This module attempts to fix a glaring hole in pytz, that there is no way to
 get the local timezone information, unless you know the zoneinfo name, and
 under several Linux distros that’s hard or impossible to figure out.
 .
 With tzlocal you only need to call get_localzone() and you will get a tzinfo
 object with the local time zone info. On some Unices you will still not get to
 know what the timezone name is, but you don’t need that when you have the
 tzinfo file. However, if the timezone name is readily available it will be
 used.
 .
 This package contains the Python 2 module.

This is required for the latest version of apscheduler. I plan to
maintain it as part of the Debian Python Modules Team.

Re: a poll for Dgit workflows

[Ian Jackson]

(I'm replying to Manoj and Marco, almost alternately, in one message.
Sorry if that's confusing...)

Manoj Srivastava writes ("Re: a poll for Dgit workflows"):
> On Wed, Mar 23 2016, Marco d'Itri wrote:
> > Having the alleged needs of naive users dictate the design of our tools 
> > looks like a very bad choice to me...

Sorry, Marco, I was unclear.  By "naive users" I meant people who
weren't familiar with the workflow practices of the maintainers of the
specific package.  I don't mean people who don't know how to write
software, or don't know roughly what a Debian package is like, or
don't know how to use git.

But I think that someone who knows how to use git should be able to
get the source code for a package in Debian, as a git branch, and
modify that source code, and share it, and so on, without needing to
deal with quilt, or learn any of dpkg-source --commit, git-dpm, gbp,
git-debcherry, debian-git-patch-spoogler, Uncle Tom Cobbly and all.

> I think dgit should address the needs of all kinds of people,
>  as it does not. Not all the people who disagree with you are mythic
>  (though I quite like the appelation).

I too think that dgit should address the needs of all kinds of people.
(There are obviously some limitations to how a tool like dgit might
serve the needs of people who don't use git, but even having a
standard source code repo browsing tool would be a benefit for
non-git-users.)

> I appreciate the fact that dgit does indeed do things that are
>  useful to me. Thanks, Ian.

You're welcome.  I'm sorry it's not currently as widely useful as it
could be.  Coping with all the different varieties of strange things
people do, and making something from them that doesn't depend on the
strangeness, turns out to be technically challenging.  But not, I
think, impossible in the most common cases.

> > I am not sure of what benefits dgit would bring to me if I am not going 
> > to use the repositories that it creates.

Marco: The users of dgit would benefit if you were to use it.

Of course making the lives of your users and collaborators easier, is
not a _direct_ benefit to you, but it may improve the quality of the
contributions you get.  And, of course, we're not generally in this
for selfish reasons: I'm hoping you'll see the value in publishing a
dgit format version of your history, even if you don't use that
history yourself.

I appreciate that currently dgit can't work for you.  I'm working on
making it able to take your existing git branches as input, and
publish them its the standard form.  But for now you probably don't
want to be investigating dgit.

> I don’t think there is a contention that dgit is for everyone. I
>  think it offers  a useful publication medium; and if it allos other
>  people to work with developers who do or do not prefer the repositories
>  to reflect the tree the software is actually built from, then it is a
>  net plus.

I want dgit to be for everyone who uses git.

Ian.

Re: Bug#782264: grub-install fails in nested LVM

[Ian Jackson]

Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
LVM"):
> Thanks for your anwser. I understand.

Thanks.

> And I intend to become a contributor (currently working on it).

Thanks, and good luck.

There are of course many ways to be a contributor to Debian that don't
involve formally joining the project and gaining some kind of approved
status.  We have a lot of bugs that could do with investigation and
perhaps need patches writing and testing, for example :-).

Regards,
Ian.

Re: Bug#782264: grub-install fails in nested LVM

[Pierre-Elliott Bécue]

Le jeudi 24 mars 2016 à 00:56:47+, Ian Jackson a écrit :
> Pierre-Elliott Bécue writes ("Re: Bug#782264: grub-install fails in nested 
> LVM"):
> > Thanks for your anwser. I understand.
> 
> Thanks.
> 
> > And I intend to become a contributor (currently working on it).
> 
> Thanks, and good luck.
> 
> There are of course many ways to be a contributor to Debian that don't
> involve formally joining the project and gaining some kind of approved
> status.  We have a lot of bugs that could do with investigation and
> perhaps need patches writing and testing, for example :-).

I'm currently working on packaging mailman3 suite, but I'm also following
some packages I've interests in.

Cheers,

-- 
PEB

Re: a poll for Dgit workflows

[Marco d'Itri]

On Mar 24, Ian Jackson  wrote:

> But I think that someone who knows how to use git should be able to
> get the source code for a package in Debian, as a git branch, and
> modify that source code, and share it, and so on, without needing to
> deal with quilt, or learn any of dpkg-source --commit, git-dpm, gbp,
> git-debcherry, debian-git-patch-spoogler, Uncle Tom Cobbly and all.
I cannot comment on other the workflows of specific tools, mostly 
because I have never managed to find one that would solve some problems 
that I have, but my own packages do not require anything like that, not 
even quilt. E.g.:

git clone git://anonscm.debian.org/users/md/kmod.git
cd kmod

# if you do not have the upstream source archive then you can make your own
git checkout v22
cd ..
tar cJf kmod_22.orig.tar.xz kmod
cd kmod
git checkout master

# and now you can start hacking
echo meh >> TODO
# if you do not know about this step then dpkg-buildpackage will 
# helpfully tell you about it
dpkg-source --commit
debuild

There is nothing here but pure git and standard Debian tools.

Also, considering that most Debian packages nowadays use the 3.0 quilt 
format I do not think that asking developers to use quilt is an 
excessive burden.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#819138: ITP: r-bioc-rgraphviz -- GNU R interface with the Graphviz library

[Chris Lawrence]

Package: wnpp
Severity: wishlist
Owner: Chris Lawrence 

* Package name: r-bioc-rgraphviz
  Version : 2.14.0
  Upstream Author : Kasper Daniel Hansen 
* URL : 
http://bioconductor.org/packages/release/bioc/html/Rgraphviz.html
* License : Eclipse Public License
  Programming Lang: C, R
  Description : GNU R interface with the Graphviz library

This package provides an interface for plotting objects from the
Bioconductor 'graph' package via the Graphviz graphics library.

It is a dependency of MCMCpack (r-cran-mcmcpack) 1.3-5.

Bug#819137: ITP: r-cran-mcmc -- Markov Chain Monte Carlo simulations for GNU R

[Chris Lawrence]

Package: wnpp
Severity: wishlist
Owner: Chris Lawrence 

* Package name: r-cran-mcmc
  Version : 0.9-4
  Upstream Author : Charles J. Geyer 
* URL : http://www.stat.umn.edu/geyer/mcmc/
* License : MIT
  Programming Lang: C, R
  Description : Markov Chain Monte Carlo simulations for GNU R

Simulates continuous distributions of random vectors using Markov
chain Monte Carlo (MCMC). Users specify the distribution by an R
function that evaluates the log unnormalized density. Algorithms are
random walk Metropolis algorithm (function metrop), simulated
tempering (function temper), and morphometric random walk Metropolis
(Johnson and Geyer, Annals of Statistics, 2012, function
morph.metrop), which achieves geometric ergodicity by change of
variable.

This package is a dependency for r-cran-mcmcpack version 1.3-5.

Bug#819143: ITP: golang-github-coreos-ioprogress -- progress bars around io.Reader/Writers

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

   Package name: golang-github-coreos-ioprogress
Version: 0.0~git20151023
Upstream Author: Mitchell Hashimoto
License: Expat
URL: https://github.com/coreos/ioprogress
Description: progress bars around io.Reader/Writers
 Ioprogress is a Goolang library with implementations of io.Reader and
 io.Writer that draws progress bars. The primary use case for these are for
 CLI applications.


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

Bug#819144: ITP: golang-github-appc-docker2aci -- library and CLI tool to convert Docker images to ACIs

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block -1 by 819143

   Package name: golang-github-appc-docker2aci
Version: 0.9.2
License: Apache-2.0
URL: https://github.com/appc/docker2aci
Description: library and CLI tool to convert Docker images to ACIs
 docker2aci is a small library and CLI binary that converts Docker images to
 ACI (https://github.com/appc/spec/blob/master/SPEC.md#app-container-image).
 It takes as input either a file generated by "docker save" or a Docker
 registry URL. It gets all the layers of a Docker image and squashes them
 into an ACI image. Optionally, it can generate one ACI for each layer,
 setting the correct dependencies.


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

Re: a poll for Dgit workflows

[Manoj Srivastava]

On Wed, Mar 23 2016, Adam Borowski wrote:

> On Wed, Mar 23, 2016 at 12:57:59PM -0700, Manoj Srivastava wrote:
>> On Wed, Mar 23 2016, Adam Borowski wrote:

>> And creates a source package that does not correspond to my
>>  repository. I don’t need to have a ./debian/patches in my repository;
>>  all that information, along with a rich history of changes, is already
>>  in git.

> echo .pc/ >>.gitignore
> echo debian/patches/ >>.gitignore

OK. I guess I could do that. Scrub that.

>> I admit, I don’t much care whether the source debian.tar.xz
>>  reflects my repository or not, if it didn’t leave artifacts that
>>  dirtied my working tree when creating the source package.

> These artifacts are no different from the rest of build droppings, ie, they
> can be gitignored just the same.

No, since the other artifact are created on my build daemon
 remotely; just the dpkg-source -b bits are left. However, adding to the
 .gitignore would address that.

>>  I also sometimes unpack debian source packages on machines without dpkg
>>  on them; source format 1.0 makes it somewhat easier.

> Valid point.

:-)

The bit about my source repo not being the same as tghe source
 package does irritate dgit; and I care more about that publication
 channel than I do about 3.0 (quilt)

manoj
-- 
"Don't hate me because I'm beautiful.  Hate me because I'm beautiful,
smart and rich." -- Calvin Keegan
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature