Re: Let's stop using CVS for debian.org website

[Boyuan Yang]

在 2016年11月20日星期日 SGT 下午12:08:04，您写道：
> For what it's worth, there's also git-cvsimport(1) and
> git-cvsexportcommit(1) that can be used if someone really wants to
> contribute and doesn't want to touch cvs itself.

Sure. I tried git-cvsimport to convert the cvs repo into a git repo (with -r 
option enabled and -A disabled). The whole process took ~60 hours and the final 
git bare repo is ~260MiB large.

I also found that the process is incremental after the initial import as long 
as the history is not modified, which is a really good news for those who wants 
to work on the transition.

I think we can make a smooth transition through the following process:

* open a git repository under the webwml alioth team, make an initial import.
* set up a crontab job somewhere (e.g., directly on alioth.d.o) and sync from 
the cvs repository to git repository several times every day. Incremental 
update is easy and can be finished within 10 minutes every time we sync them.
* gradually port all potential infrastructures (e.g., tools used to update 
debian.org website) from cvs repository to git repository.
* set up a "transition day". After that given day, all the commits have to go 
into the git repository. Done.

What do you think?


--
Sincerely,
Boyuan Yang

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

Bug#845190: ITP: node-babel-types -- Babel Types is a Lodash-esque utility library for AST nodes

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-babel-types
  Version : 6.19.0
  Upstream Author : Sebastian McKenzie 
* URL : https://babeljs.io/
* License : Expat
  Programming Lang: JavaScript
  Description : Babel Types is a Lodash-esque utility library for
AST nodes



signature.asc
Description: OpenPGP digital signature

Re: OpenSSL 1.1.0

[Tino Mettler]

On Thu, Nov 17, 2016 at 13:10:40 +0200, Adrian Bunk wrote:

[...]

> Is everyone aware that this choice is per-cluster and not per-package?

Hi,

one of my packages uses OpenSSL and Qt.  I tried to inform upstream
regarding the plans for 1.1 in Stretch because the package FTBFS with
1.1 as it uses a lot of structures that got opaque (which requires some
non-trivial changes).  It wasn't that easy to get the current state and
plans for the transition when digging in bug reports, changelogs,
mailing lists and helpful hints I got on IRC by accident.

At the end I noticed that Qt will stay at 1.0 (by glancing into the
changelog of the relevant upload) which means that my package also has
to to stay at 1.0 and the whole excitement resulted in just a changed
build-dep.

I was somewhat puzzled that I did not read anything about the whole
subject at debian-devel-announce, as it is not one of the usual
transitions.

Regards,
Tino

Re: OpenSSL 1.1.0

[Jan Niehusmann]

Hi,

On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> At the end I noticed that Qt will stay at 1.0 (by glancing into the
> changelog of the relevant upload) which means that my package also has
> to to stay at 1.0 and the whole excitement resulted in just a changed
> build-dep.

I'm not so sure about this any more:

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
Golosunov wrote that according to his understanding of dlsym(3), it
should be fine to link a program with OpenSSL 1.1 and Qt at the same
time, even though Qt links to OpenSSL 1.0.

Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
that?

If that's true, it would (IMHO) be a major step towards a timely release
of stretch with OpenSSL 1.1 as the default version.

Jan

Re: OpenSSL 1.1.0

[Henrique de Moraes Holschuh]

On Mon, Nov 21, 2016, at 11:06, Jan Niehusmann wrote:
> On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> > At the end I noticed that Qt will stay at 1.0 (by glancing into the
> > changelog of the relevant upload) which means that my package also has
> > to to stay at 1.0 and the whole excitement resulted in just a changed
> > build-dep.
> 
> I'm not so sure about this any more:
> 
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
> Golosunov wrote that according to his understanding of dlsym(3), it
> should be fine to link a program with OpenSSL 1.1 and Qt at the same
> time, even though Qt links to OpenSSL 1.0.
> 
> Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
> that?

The linking is fine, I believe even any eventual globals (if any) will
be correctly handled in Debian nowadays.  What causes extremely nasty
issues is layering violations causing openssl data structures to leak
from something linked to one version of the library, to something else
linked to another version of the library.

 If, at any point, internal data structures from openssl are exposed, or
 OpenSSL contextes are passed between two libraries, or a library and an
 application, *they must all be from the same openssl*.

This is not something the linker or dlopen/dlsym can enforce.  And you
need to manually inspect the code to be sure... usually.

So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe.   If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.

-- 
  Henrique de Moraes Holschuh 

Bug#845214: ITP: fonts-go -- high-quality WGL4 TrueType fonts for Go project

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: fonts-go
  Version : 0~20161116
  Upstream Author : Name 
* URL : https://blog.golang.org/go-fonts
* License : BSD-3-clause
  Programming Lang: fonts
  Description : high-quality WGL4 TrueType fonts for Go project

 The Go font family includes proportional and fixed width faces in
 normal, bold, and italic renderings. It is designed for technical uses,
 particularly programming.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Re: Debian Installer Stretch Alpha 8 release

[Raphael Hertzog]

Hello Guillem,

On Mon, 14 Nov 2016, Michael Biebl wrote:
> Just for the record: I can confirm it fixes the problem in dpkg-shlibdeps.
[...]
> Guillem, it would be great if you can upload a fixed dpkg soon.

A full week went by already. What's your plan?

I can offer to upload dpkg 1.18.15.1 to sid with just those patches if
it relieves you from handling an intermediary upload until you
release 1.18.16 on your usual schedule.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Re: OpenSSL 1.1.0

[Lisandro Damián Nicanor Pérez Meyer]

On lunes, 21 de noviembre de 2016 11:30:13 ART Henrique de Moraes Holschuh 
wrote:
> On Mon, Nov 21, 2016, at 11:06, Jan Niehusmann wrote:
> > On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> > > At the end I noticed that Qt will stay at 1.0 (by glancing into the
> > > changelog of the relevant upload) which means that my package also has
> > > to to stay at 1.0 and the whole excitement resulted in just a changed
> > > build-dep.
> > 
> > I'm not so sure about this any more:
> > 
> > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
> > Golosunov wrote that according to his understanding of dlsym(3), it
> > should be fine to link a program with OpenSSL 1.1 and Qt at the same
> > time, even though Qt links to OpenSSL 1.0.
> > 
> > Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
> > that?
> 
> The linking is fine, I believe even any eventual globals (if any) will
> be correctly handled in Debian nowadays.  What causes extremely nasty
> issues is layering violations causing openssl data structures to leak
> from something linked to one version of the library, to something else
> linked to another version of the library.
> 
>  If, at any point, internal data structures from openssl are exposed, or
>  OpenSSL contextes are passed between two libraries, or a library and an
>  application, *they must all be from the same openssl*.
> 
> This is not something the linker or dlopen/dlsym can enforce.  And you
> need to manually inspect the code to be sure... usually.
> 
> So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> says "use SSL", etc), then it should be fine.

Qt uses ssl in QtNetwork, so at very least I would say that if you don't use 
QtNetwork you should be fine.

But this is only theory.

-- 
Bebe a bordo (pero con moderación)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Let's stop using CVS for debian.org website

[Neil McGovern]

Hi there,

On Mon, Nov 21, 2016 at 04:17:27PM +0800, Boyuan Yang wrote:
> 在 2016年11月20日星期日 SGT 下午12:08:04，您写道：
> > For what it's worth, there's also git-cvsimport(1) and
> > git-cvsexportcommit(1) that can be used if someone really wants to
> > contribute and doesn't want to touch cvs itself.
> 
> Sure. I tried git-cvsimport to convert the cvs repo into a git repo (with -r 
> option enabled and -A disabled). The whole process took ~60 hours and the 
> final 
> git bare repo is ~260MiB large.
> 
> I also found that the process is incremental after the initial import as long 
> as the history is not modified, which is a really good news for those who 
> wants 
> to work on the transition.
> 

Thanks for that, it's certainly useful data!

> I think we can make a smooth transition through the following process:
> 
> * open a git repository under the webwml alioth team, make an initial import.
> * set up a crontab job somewhere (e.g., directly on alioth.d.o) and sync from 
> the cvs repository to git repository several times every day. Incremental 
> update is easy and can be finished within 10 minutes every time we sync them.
> * gradually port all potential infrastructures (e.g., tools used to update 
> debian.org website) from cvs repository to git repository.

This is the main issue - the actual tooling is fairly straightforward in
terms of the get-from-git-and-compile system, but there's a large
non-trivial amount of work for the translation systems.

Laura Arjona Reina is currently looking at this, and the current
thinking (AIUI) is that we need to:
* Update the translation system to use Po4a::Wml
* Deploy weblate for translations, or modify the process to use hashes
rather than version numbers
* Update large chunks of the site to use pofiles. Some files use it but
not for all content, and there's a number of files that don't use it at
all.

Help with the above is welcome :)

Neil


signature.asc
Description: PGP signature

Bug#845219: ITP: node-vali-date -- Validate a date

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-vali-date
  Version : 1.0.0
  Upstream Author : Sam Verschueren 
(github.com/SamVerschueren)
* URL : https://github.com/samverschueren/vali-date#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Validate a date

Re: Debian Installer Stretch Alpha 8 release

[Guillem Jover]

Just a brief reply.

On Mon, 2016-11-21 at 16:38:07 +0100, Raphael Hertzog wrote:
> On Mon, 14 Nov 2016, Michael Biebl wrote:
> > Just for the record: I can confirm it fixes the problem in dpkg-shlibdeps.
> [...]
> > Guillem, it would be great if you can upload a fixed dpkg soon.
> 
> A full week went by already. What's your plan?

First I have to go over a list of queued pending items and then I'll
get to this during this week. I have not yet reviewed the patches (in
part because I didn't do much Debian stuff last week due to lack of
motivation after an unpleasant interaction precisely due to this
issue, and TBH it has become one of those energey drainers), there's
a pending run in rebootstrap by Helmut (which is now waiting for a
gixed gcc), and then I need to write a mail summary of the current
situation and implications.

> I can offer to upload dpkg 1.18.15.1 to sid with just those patches if
> it relieves you from handling an intermediary upload until you
> release 1.18.16 on your usual schedule.

No, thanks. That's not the blocker. Also the release intervals will be
shorter for a while, at least until deeper freeze stages.

Regards,
Guillem

Re: Let's stop using CVS for debian.org website

[W. Martin Borgert]

Quoting Neil McGovern :

* Deploy weblate for translations,


This would require http://bugs.debian.org/745661 to be fixed.
Which would also help others who want to use the tool.


* Update large chunks of the site to use pofiles. Some files use it but
not for all content, and there's a number of files that don't use it at
all.


I agree, that PO is the way to go.
I had less issues with PO as with full-text translation
e.g. for the release notes.

Re: Debian Installer Stretch Alpha 8 release

[Guillem Jover]

On Mon, 2016-11-21 at 17:09:50 +0100, Guillem Jover wrote:
> On Mon, 2016-11-21 at 16:38:07 +0100, Raphael Hertzog wrote:
> > I can offer to upload dpkg 1.18.15.1 to sid with just those patches if
> > it relieves you from handling an intermediary upload until you
> > release 1.18.16 on your usual schedule.
> 
> No, thanks. That's not the blocker. Also the release intervals will be
> shorter for a while, at least until deeper freeze stages.

Oh, and forgot to mention, this issue has been known for over 8
months, and now there's this need to be pushy and rush things, etc.
I certainly do not appreciate that.

Regards,
Guillem

Bug#845221: ITP: node-is-valid-glob -- Return true if a value is a valid glob pattern or patterns

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-is-valid-glob
  Version : 0.3.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/is-valid-glob
* License : Expat
  Programming Lang: JavaScript
  Description : Return true if a value is a valid glob pattern or
patterns

Re: Bug#843073: Debian Installer Stretch Alpha 8 release

[Marco d'Itri]

On Nov 21, Guillem Jover  wrote:

> Oh, and forgot to mention, this issue has been known for over 8
> months, and now there's this need to be pushy and rush things, etc.
> I certainly do not appreciate that.
No, not really: it was not clear (e.g. I could never reproduce it) until 
very recently.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Debian Installer Stretch Alpha 8 release

[Raphael Hertzog]

On Mon, 21 Nov 2016, Guillem Jover wrote:
> Oh, and forgot to mention, this issue has been known for over 8
> months, and now there's this need to be pushy and rush things, etc.
> I certainly do not appreciate that.

I have not been involved in this project so I don't know its history
but #843073 is not 8 months old and I only discovered the problem
when I read about in on debian-devel and yet I have followed former
discussions on debian-devel about merged-/usr.

I can understand that this project was of no interest to you and that
while you were aware of the problem for 8 months, you did not want to fix
it by yourself. But then I'm also sympathetic to people who want
to get their project moving forward and I'm always happy to assist them
when it touches code that I wrote in dpkg. Feel free to direct such people
towards me when you are not interested yourself.

In this specific case, the merged-/usr was mostly done and ready before
the freeze but then this problem (which was possibly underrated by Marco
or whoever else was aware of it) came into light. I would not like that we
end up with this feature reverted at freeze time because you did not find
the time to merge the patch. Hence my query.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#845224: ITP: node-replace-ext -- Replaces a file extension with another one

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-replace-ext
  Version : 1.0.0
  Upstream Author : Gulp Team  (http://gulpjs.com/)
* URL : https://github.com/gulpjs/replace-ext#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Replaces a file extension with another one

Bug#845226: ITP: node-remove-trailing-separator -- Removes separators from the end of the string

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-remove-trailing-separator
  Version : 1.0.1
  Upstream Author : darsain
* URL :
https://github.com/darsain/remove-trailing-separator#readme
* License : ISC
  Programming Lang: JavaScript
  Description : Removes separators from the end of the string

Re: Let's stop using CVS for debian.org website

[Laura Arjona Reina]

Hi

El 21 de noviembre de 2016 17:11:12 CET, "W. Martin Borgert" 
 escribió:
>Quoting Neil McGovern :
>> * Deploy weblate for translations,
>
>This would require http://bugs.debian.org/745661 to be fixed.
>Which would also help others who want to use the tool.
>

Small clarification:

I was exploring if weblate allowed to handle the wml files directly, but it 
doesn't (and it's ok).

So  #745661 is not a blocker for cvs to git migration.

(It would be awesome to have weblate in Debian, in any case!)

I'll go on exploring other options.

>> * Update large chunks of the site to use pofiles. Some files use it
>but
>> not for all content, and there's a number of files that don't use it
>at
>> all.
>
>I agree, that PO is the way to go.
>I had less issues with PO as with full-text translation
>e.g. for the release notes.

Despite of the migration from cvs to git, any contribution towards making the 
webpages use more gettext is very appreciated.

Anybody interested in helping on this (for example, explain some things) please 
ping me, because I'm mostly learning by try-error using the already 
gettextified wml files.

Cheers

Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#845231: ITP: node-is-stream -- Check if something is a Node.js stream

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-is-stream
  Version : 1.1.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/is-stream#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Check if something is a Node.js stream

Bug#845234: ITP: node-y18n -- the bare-bones internationalization library used by yargs

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-y18n
  Version : 3.2.1
  Upstream Author : Ben Coe 
* URL : https://github.com/yargs/y18n
* License : ISC
  Programming Lang: JavaScript
  Description : the bare-bones internationalization library used by
yargs



signature.asc
Description: OpenPGP digital signature

Bug#845235: ITP: node-clone-stats -- Safely clone node's fs.Stats instances without losing their class methods

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-clone-stats
  Version : 1.0.0
  Upstream Author : Hugh Kennedy 
(http://hughsk.io/)
* URL : https://github.com/hughsk/clone-stats
* License : Expat
  Programming Lang: JavaScript
  Description : Safely clone node's fs.Stats instances without
losing their class methods

Bug#845236: ITP: node-window-size -- Reliable way to to get the height and width of the terminal/console in a node.js environment

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-window-size
  Version : 0.2.0
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/window-size
* License : Expat
  Programming Lang: JavaScript
  Description : Reliable way to to get the height and width of the
terminal/console in a node.js environment.



signature.asc
Description: OpenPGP digital signature

Bug#845233: ITP: node-set-blocking -- set blocking stdio and stderr ensuring that terminal output does not truncate

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-set-blocking
  Version : 2.0.0
  Upstream Author : Ben Coe 
* URL : https://github.com/yargs/set-blocking#readme
* License : ISC
  Programming Lang: JavaScript
  Description : set blocking stdio and stderr ensuring that terminal
output does not truncate



signature.asc
Description: OpenPGP digital signature

Bug#845237: ITP: node-clone-buffer -- Takes a Buffer object and returns a clone

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-clone-buffer
  Version : 1.0.0
  Upstream Author : Gulp Team  (http://gulpjs.com/)
* URL : https://github.com/gulpjs/clone-buffer#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Takes a Buffer object and returns a clone

Bug#845238: ITP: node-detect-newline -- Detect the dominant newline character of a string

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-detect-newline
  Version : 2.1.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/detect-newline#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Detect the dominant newline character of a string

Bug#845240: ITP: node-string-width -- Get the visual width of a string

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 
X-Debbugs-Cc: paolo.gre...@libpf.com, debian-devel@lists.debian.org,
pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-string-width
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  sindresorhus.com)
* URL : https://github.com/sindresorhus/string-width
* License : Expat
  Programming Lang: JavaScript
  Description : Get the visual width of a string

 Some Unicode characters are use more or less than the normal width when
output to the command-line.
 .
 This nodejs module gets the visual width of a string i.e. the actual
number of columns required to display it.
 .
 Node.js is an event-based server-side JavaScript engine.

The interest in this module is that it is required for yargs which in
turn is required for updating uglifyjs (see
https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2016-November/015501.html)

The plan is:
1. to maintain it inside the JavaScript packaging team
2. to host the code in a git repo on alioth
3. to patch it to replace the dependency on is-fullwidth-code-point with
node-wcwidth.js (https://packages.debian.org/sid/node-wcwidth.js) as per
this suggestion: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842191#10




signature.asc
Description: OpenPGP digital signature

Bug#845245: ITP: node-input-output-return-identity-function-common -- Convert input values to output values using the identity function mapping

[Eduard Bloch]

* Package name: node-remove-trailing-separator
  Version : 2017.04.01
  Upstream Author : majorobvious
* URL : 
https://github.com/majorobvious/input-output-return-identity-function-base
* License : WTFPL
  Programming Lang: JavaScript (what else...)
  Description : Convert input values to output values using the identity 
function mapping

input-output-return-identity-function-base is a highly sophisticated
value conversion system which allows all NodeJS users to convert any
input value to another input value of the same type and having the same
contents.

Re: OpenSSL 1.1.0

[Bernd Zeimetz]

On 11/21/2016 03:35 AM, Clint Adams wrote:
> On Sun, Nov 20, 2016 at 01:57:52PM +0100, Marco d'Itri wrote:
>> I do not think that anybody has been considering GnuTLS as a credible 
>> replacement for a very long time.
> 
> That's very silly.

No, its the truth unfortunately.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: OpenSSL 1.1.0

[Russ Allbery]

Bernd Zeimetz  writes:
> On 11/21/2016 03:35 AM, Clint Adams wrote:
>> On Sun, Nov 20, 2016 at 01:57:52PM +0100, Marco d'Itri wrote:

>>> I do not think that anybody has been considering GnuTLS as a credible 
>>> replacement for a very long time.

>> That's very silly.

> No, its the truth unfortunately.

It's a ton of work to maintain a high-quality SSL implementation.  Even
apart from the multitude of security issues that constantly arise, you
have to deal with interoperability with a bunch of half-assed, semi-broken
SSL implementations in the wild.  It needs resources, and the GnuTLS
development team doesn't seem to have those resources (and hasn't for a
while).  This in turn makes it hard to persuade upstreams to even consider
it, since they're usually very worried about interopability (and GnuTLS
has a spotty track record there).

It also really hurts for GnuTLS to have a completely different API,
whatever the merits of that API over OpenSSL's.  (The OpenSSL
compatibility layer is missing so much that it's not really usable.  For
instance, it offers no way to set cipher suite preferences at all and
disables TLSv1.1 and newer, at least as far as I was able to determine
from looking at the code while trying to solve another reported bug.)

-- 
Russ Allbery (r...@debian.org)   

Bug#845266: ITP: node-cliui -- easily create complex multi-column CLIs

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-cliui
  Version : 3.2.0
  Upstream Author : Ben Coe 
* URL : https://github.com/yargs/cliui#readme
* License : ISC
  Programming Lang: JavaScript
  Description : easily create complex multi-column CLIs

 Exposes a simple layout Domain Specific Language (DSL), reminiscent
 of HTML (with div and span elements) that makes it possible to easily
 create command-line-interfaces (CLIs).
 .
 Node.js is an event-based server-side JavaScript engine.


The interest in this module is that it is required for yargs which in
turn is required for updating uglifyjs (see
https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2016-November/015501.html)

The plan is:
1. to maintain it inside the JavaScript packaging team
2. to host the code in this git repo:
https://anonscm.debian.org/git/pkg-javascript/node-cliui.git/



signature.asc
Description: OpenPGP digital signature

Bug#845272: ITP: libopenhmd -- API and drivers for immersive technology (shared library)

[Balint Reczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libopenhmd
  Version : 0.2.0
* URL : http://openhmd.net/
* License : BSL-1.0
  Programming Lang: FIXME
  Description : API and drivers for immersive technology (shared
library)

OpenHMD aims to provide a Free and Open Source API and drivers for
immersive technology, such as head mounted displays with built in head
tracking.

This package provides the shared library.

Certbot in Debian Stretch

[Peter Eckersley]

Hi!

I'm an upstream developer for Certbot, previously known as the Let's Encrypt
client (https://certbot.eff.org). Certbot is a flexible and very popular way
to get certificates from Let's Encrypt; it's issued about 300,000 currently
active TLS certs to Debian servers (and a lot more to Ubuntu servers). We hope
that over time, a lot of server software can be well-integrated with Certbot
in order to use authenticated TLS connections by default (see
https://certbot.eff.org/docs/using.html#plugins for some of the integration
efforts to date).

We're writing to figure out a plan for Certbot versioning and updates for
Stretch's stable lifetime. Certbot is still a fairly rapidly-improving,
not-quite-1.0 piece of software. The ACME protocol that it uses to talk to Let's
Encrypt is also rapidly evolving through an IETF working group
(https://datatracker.ietf.org/wg/acme/charter/), and the Let's Encrypt
server-side codebase (https://github.com/letsencrypt/boulder) is 
currently working with an ACME backwards compatibilty window of 6-12 months,
but probably not longer than that.

In order to both ensure that Certbot remains compatible with the deployed
Let's Encrypt service, and to ensure that users have as good an experience as
possible when they use Certbot, we do not think it would be wise to support a
specific version of Certbot from the Stretch freeze early next year through to
the EOL of that release.

There seem to be a few options available:

1. Leave Certbot out of the Debian Stretch release, and rely on
backports as the recommended way to run Certbot on Debian. That's what we
currently do with Jessie:

https://certbot.eff.org/#debianjessie-apache

2. Periodically declare a released version of Certbot to be well-tested,
stable, and free of detectable regressions or breakage of existing workflows,
and include it in Stretch's stable-updates repo.  We're currently trying the
Ubuntu equivalent of this process out with a proposed xenial SRU from
letsencrypt 0.4.1 to Certbot 0.9.3:

https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978

We expect that such updates would occur every ~3-6 months. If the Debian
development community agreed to such a plan, we'd feel comfortable working
with it.

3. Someone could maintain a fork of a near-future Certbot release for the ~5
year lifecycle of the Stretch Debian release. The upstream team definitely
doesn't think this is a good idea, and we don't have the resources to support
such an effort.

Looking at the three options above, I think we'd default to doing 1, but we
would be open to pursuing option 2 if the Debian developer community supports
it, and think there could be advantages in terms of allowing other packages to
assume that Certbot is installable, or even Depend: on it, for enabling TLS.


-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

Re: Certbot in Debian Stretch

[Peter Colberg]

On Mon, Nov 21, 2016 at 05:40:22PM -0800, Peter Eckersley wrote:
> The ACME protocol that it uses to talk to Let's
> Encrypt is also rapidly evolving through an IETF working group
> (https://datatracker.ietf.org/wg/acme/charter/), and the Let's Encrypt
> server-side codebase (https://github.com/letsencrypt/boulder) is 
> currently working with an ACME backwards compatibilty window of 6-12 months,
> but probably not longer than that.

This issue affects many more clients in Debian besides certbot:

https://wiki.debian.org/LetsEncrypt

Peter

Bug#845292: ITP: node-require-directory -- Recursively require files in a directory

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-require-directory
  Version : 2.1.1
  Upstream Author : Troy Goode 
(http://github.com/troygoode/)
* URL : https://github.com/troygoode/node-require-directory/
* License : Expat
  Programming Lang: JavaScript
  Description : Recursively iterates over specified directory,
require()'ing each file, and returning a nested hash structure
containing those modules.




signature.asc
Description: OpenPGP digital signature

Bug#845294: ITP: node-lcid -- Mapping between standard locale identifiers and Windows locale identifiers (LCID)

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-lcid
  Version : 1.0.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/lcid
* License : Expat
  Programming Lang: JavaScript
  Description : Mapping between standard locale identifiers and
Windows locale identifiers (LCID)



signature.asc
Description: OpenPGP digital signature

Bug#845293: ITP: node-mimic-fn -- Make a function mimic another one

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-mimic-fn
  Version : 1.1.0
  Upstream Author : Sindre Sorhus 
(sindresorhus.com)
* URL : https://github.com/sindresorhus/mimic-fn#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Make a function mimic another one



signature.asc
Description: OpenPGP digital signature

Re: Certbot, Ring in Debian Stretch

[Daniel Pocock]

On 22/11/16 02:40, Peter Eckersley wrote:
> Hi!
> 
> I'm an upstream developer for Certbot, previously known as the Let's Encrypt
> client (https://certbot.eff.org). Certbot is a flexible and very popular way
> to get certificates from Let's Encrypt; it's issued about 300,000 currently
> active TLS certs to Debian servers (and a lot more to Ubuntu servers). We hope
> that over time, a lot of server software can be well-integrated with Certbot
> in order to use authenticated TLS connections by default (see
> https://certbot.eff.org/docs/using.html#plugins for some of the integration
> efforts to date).
> 
> We're writing to figure out a plan for Certbot versioning and updates for
> Stretch's stable lifetime. Certbot is still a fairly rapidly-improving,
> not-quite-1.0 piece of software. The ACME protocol that it uses to talk to 
> Let's
> Encrypt is also rapidly evolving through an IETF working group
> (https://datatracker.ietf.org/wg/acme/charter/), and the Let's Encrypt
> server-side codebase (https://github.com/letsencrypt/boulder) is 
> currently working with an ACME backwards compatibilty window of 6-12 months,
> but probably not longer than that.
> 

Thanks for raising this Peter

This is not just an issue for certbot, it is also an issue for any
package that supports an evolving networked service.  It is a particular
challenge for software in the real-time communications space (e.g. SIP,
XMPP, WebRTC).  The exciting new peer-to-peer Ring[1] client is also
evolving quite rapidly like certbot and stale versions will impact the
success of that initiative.

The approach we take with the freeze is good for certain types of things
(e.g. compilers and scripting languages) and backports has helped
mitigate this as you already observe.


> In order to both ensure that Certbot remains compatible with the deployed
> Let's Encrypt service, and to ensure that users have as good an experience as
> possible when they use Certbot, we do not think it would be wise to support a
> specific version of Certbot from the Stretch freeze early next year through to
> the EOL of that release.
> 
> There seem to be a few options available:

I'd like to suggest an additional point relevant to all of the options:
how well does the certbot client react when it is no longer usable?
Does the protocol include a mechanism to check the version?  Does the
client give an explicit error telling the user to update the client and
can it be tweaked so that Debian users are shown a message about getting
the latest package from stable-backports?  Or will the user see some
random error that doesn't mention the client version at all?


> 
> 1. Leave Certbot out of the Debian Stretch release, and rely on
> backports as the recommended way to run Certbot on Debian. That's what we
> currently do with Jessie:
> 
> https://certbot.eff.org/#debianjessie-apache
> 
> 2. Periodically declare a released version of Certbot to be well-tested,
> stable, and free of detectable regressions or breakage of existing workflows,
> and include it in Stretch's stable-updates repo.  We're currently trying the
> Ubuntu equivalent of this process out with a proposed xenial SRU from
> letsencrypt 0.4.1 to Certbot 0.9.3:
> 
> https://bugs.launchpad.net/ubuntu/+source/python-letsencrypt/+bug/1640978
> 
> We expect that such updates would occur every ~3-6 months. If the Debian
> development community agreed to such a plan, we'd feel comfortable working
> with it.
> 


>From my experience as an upstream developer, trying to do this type of
thing for multiple distributions becomes time consuming and tedious and
it takes time away from the upstream work.  If your primary focus is
upstream development and standards work it can be difficult to also be
fluent in the rules of every distribution, it becomes quite tedious.
This workflow tends to work better where other volunteers within the
distribution are willing to prepare the uploads to stable-updates and
equivalents.


> 3. Someone could maintain a fork of a near-future Certbot release for the ~5
> year lifecycle of the Stretch Debian release. The upstream team definitely
> doesn't think this is a good idea, and we don't have the resources to support
> such an effort.
> 
> Looking at the three options above, I think we'd default to doing 1, but we
> would be open to pursuing option 2 if the Debian developer community supports
> it, and think there could be advantages in terms of allowing other packages to
> assume that Certbot is installable, or even Depend: on it, for enabling TLS.
> 
> 





1. https://packages.qa.debian.org/r/ring.html